From nobody Mon Mar 1 02:40:23 2021 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 907CF3A19A3 for ; Mon, 1 Mar 2021 02:40:21 -0800 (PST) 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=[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=0.878, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=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 4R_5FdoP-k-U for ; Mon, 1 Mar 2021 02:40:20 -0800 (PST) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 2923A3A19A1 for ; Mon, 1 Mar 2021 02:40:20 -0800 (PST) Received: by mail-ed1-x52b.google.com with SMTP id w21so19996840edc.7 for ; Mon, 01 Mar 2021 02:40:20 -0800 (PST) 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=gj4Q+n3+7MBWJHeztnBbe7AOGkeIkw61NgPoDBa5oa4=; b=VaEVFPnk2pb4Z5gH185T+1TNyiodop248V1WCaDpYuez1alXAXUhqPuvCtxpJUJXvR uhnFsCPQlKGs/gwVsIxmfsed/OsA7i7XsKSK5XwYYpiLCdOoqcaOu9umHmNbhKezf5zF Qc1rfNmoU2I3gbUCz9L2eg0JCnAhN2Tjvwwsd0CM4ZdpMxjT5/zCRmVnRKg4avtzet6Q il+Bguup8jzcfYAYlnAGt8McTBIkB71MuQE0ZXOrP7M65rguSB8MjG4jtKH99/97E2Kp F5t1MLzzDTXge6TFMOMpOp3/6CCCblbpufnfvi2VfomglzHo2Wo3I6Dw1Kg9ldo9Id1j cxOA== 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=gj4Q+n3+7MBWJHeztnBbe7AOGkeIkw61NgPoDBa5oa4=; b=hiz7Zz8x1p1t8KlyI/5lZBSGRLSr+rXS34pOPxgc2XMr6iSFg1GTgQd0m8BckPHLzp 6s9pND4I0fFQhwW5V2wSdmLKMxd90Pecw3v0lt+NUoopZSmS7C1Qz2boBOBdPFgD88M1 kHKWCPqYCodZEaWd9/25VdjlvrvfIfEJUNML01itcJxDM0qELFk57RDnWoaTk22cRKYY lg8qHUA/VgrkAjWbqpbzCDgQ8oFVLWL3xQVGBmXKU0aA1ONJFNiPa4wrrNxSCiPSkbpT PnJwdOtXeF/Ef0RGG5PK/1UZeJLLGp53Jdo7vNEmH6ziMtje7K/kPK2ha+D0OCmXqPOR C7nQ== X-Gm-Message-State: AOAM5334+NyAGiXYPKLBdwwosZgrYQUI+FcxOXwDb61WucV5FBp0XmT0 X4cb3Zuk8blthndNdagR+5B4Hjs+xQ0= X-Google-Smtp-Source: ABdhPJwvkb55Sf+MpPvnTDGdgF37ShJAoZrUPINemcVclAsG+mIs8QOSVYB+SefyGdUYluhebHQ+Ng== X-Received: by 2002:a05:6402:1d95:: with SMTP id dk21mr6072324edb.280.1614595216471; Mon, 01 Mar 2021 02:40:16 -0800 (PST) Received: from [192.168.68.103] (bzq-79-181-28-102.red.bezeqint.net. [79.181.28.102]) by smtp.gmail.com with ESMTPSA id hq14sm12486813ejc.30.2021.03.01.02.40.15 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Mar 2021 02:40:16 -0800 (PST) User-Agent: Microsoft-MacOutlook/16.46.21021202 Date: Mon, 01 Mar 2021 12:40:14 +0200 From: Yaron Sheffer To: GNAP Mailing List Message-ID: Thread-Topic: Agenda for next week's meeting Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3697447215_180564378" Archived-At: Subject: [GNAP] Agenda for next week's meeting X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2021 10:40:22 -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_3697447215_180564378 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi everyone, =20 We will be meeting for 2 hours at IETF-110 next week. We expect the bulk of= the meeting to be focused on the core protocol and led by the editorial tea= m. However, please let us know if you have any other agenda items in mind. =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 --B_3697447215_180564378 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi everyone,

 

We will be meeting for 2 hours at IETF-110 next = week. We expect the bulk of the meeting to be focused on the core protocol a= nd led by the editorial team. However, please let us know if you have any ot= her agenda items in mind.

 

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

--B_3697447215_180564378-- From nobody Sat Mar 6 07:59:10 2021 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 445133A0BB3 for ; Sat, 6 Mar 2021 07:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.218 X-Spam-Level: X-Spam-Status: No, score=-1.218 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, MALFORMED_FREEMAIL=0.878, 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 k5PYSEgW7VmF for ; Sat, 6 Mar 2021 07:59:07 -0800 (PST) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 C780E3A0BB2 for ; Sat, 6 Mar 2021 07:59:06 -0800 (PST) Received: by mail-ed1-x52f.google.com with SMTP id v13so7455672edw.9 for ; Sat, 06 Mar 2021 07:59:06 -0800 (PST) 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=ecURUAPe9D261pTVV1uBm/q9tSuI0L0k4YTQ7ged1TE=; b=SoZ2TwR2ZTqiJz2UwPn4a8NVrxaZvzz1TuwQepoLoBc03doFABZN9CklpIvfB55UYf YQRE0gNghCzSXXccxr4qDqpteVk0yG34T8ESfz6ES/EWrEbuTHL60SFSUCzYmYln4Oov HSYmSZHedIp6GbFYPOt9ovRJzWeBy8olJ6FWv+jlAiC2n4Cl97DJ4ETy6Ep7kxH6KatD FU4Uv4GoZknZun0qJCIJGQ4K5iVWj5yC7eCjxQd3/rQwpsM0v9MXbsrO0vpVCqCrwL8x CgUAvd+fKar38bhRa7ph1QCylFgaTOVDJl1TBIr+b+z6S7N4dH0u9qVa2Nwl2d90/2fK Uhvw== 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=ecURUAPe9D261pTVV1uBm/q9tSuI0L0k4YTQ7ged1TE=; b=EppnIf7kIGq2WFB5pECXERuZcRLhFDl3beGATbck6eeHNthdQZak0J1F2yJ+BiRMxd KXk9mVNLNX/RMYpejMsVkg47UcFA1jJcAqv/B2WVQJYlxVaJt9/x54/clndakcBBp2da vxKx9FK1mx1vRWFxIAaNyvqZ4qfiW7tfcKZnzM1YpW3scZTttuYrv/+yM4XZfCrd7y46 CN3P9Whicl7VH7YRUSsPNsK/y+wNwl/l4mFd8b+RAgrVm0lDztP6LgCXHwMlzcXTC3Cx x1jSsi3F6i8Idfqhp8QRZz2HIxq1Yt7e4GGb4+aBZXbmGOtJ3idiVfy0I0JqBHzDkUP5 NLyg== X-Gm-Message-State: AOAM532VJbb7lAu/ukIHd46CQ0GOAeDq+L85J89pybTjsL7H6UPEG0tO I0AhJaYJfYy1REzcukG/9NZ0Ew51yq4= X-Google-Smtp-Source: ABdhPJzbsDyhLcfLTaQtVhjHhMxw7kDt4a/SnATJNJheP9BIX+hCLZLtQriEozLfJrQq0BTByD5QcA== X-Received: by 2002:aa7:c9cf:: with SMTP id i15mr14331327edt.296.1615046343912; Sat, 06 Mar 2021 07:59:03 -0800 (PST) Received: from [192.168.68.103] (bzq-79-181-28-102.red.bezeqint.net. [79.181.28.102]) by smtp.gmail.com with ESMTPSA id u59sm3551370edc.73.2021.03.06.07.59.02 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Mar 2021 07:59:02 -0800 (PST) User-Agent: Microsoft-MacOutlook/16.46.21021202 Date: Sat, 06 Mar 2021 17:59:01 +0200 From: Yaron Sheffer To: GNAP Mailing List Message-ID: <3DAA7AE5-919D-4347-BD00-8C0683D5DEC9@gmail.com> Thread-Topic: Agenda for GNAP at IETF-110 Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3697898342_1026669807" Archived-At: Subject: [GNAP] Agenda for GNAP at IETF-110 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Mar 2021 15:59:08 -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_3697898342_1026669807 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable We have uploaded the agenda: https://datatracker.ietf.org/meeting/110/mater= ials/agenda-110-gnap-00 =20 See you all on Tuesday! =20 =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 --B_3697898342_1026669807 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

We have uploaded the agenda: https://datatracker.ietf.= org/meeting/110/materials/agenda-110-gnap-00

 

See you all on Tuesday!

 =

=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

--B_3697898342_1026669807-- From nobody Sun Mar 7 00:16:09 2021 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 442E03A0650 for ; Sun, 7 Mar 2021 00:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_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=mnot.net header.b=WLyVQnt1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MqoMGxxH 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 of5S-1uT0qht for ; Sun, 7 Mar 2021 00:16:02 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 733363A05AC for ; Sun, 7 Mar 2021 00:16:02 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id EEF1826D4 for ; Sun, 7 Mar 2021 02:38:04 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 07 Mar 2021 02:38:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=jF+L9VU5pOoC9ph6n+/fshiKNjnVPJadfZQhWkPk6YU=; b=WLyVQnt1 3kSQpGkYrmuOuDNSfEtpLLJ3EEd5rN/61yDap13WsvrILJNBE0VDensfeFYwfEi7 7lV0z7H/PPzNoR0TznurdKfaPg805FpvljWdV91Jp0lsQ0pzksR+8CsJ/Vdg9uHx d2Kub2+wOPEHpIh5IWAEXfmbzhAJ8Deb02/9lp/NJce/bPpq9NFExyVuK+ECvGKk q0EydJZNyVJJrb2qeQb4JhcQmW3NuUZx6Bs6mybm1QJ5FtSCpWB5pQmF+N5p05Aq JmqMi83DEsSLiG4awE8h/MWMW5QfSASwCCU0S1xo5CklBYtJHhP5y2mzazgWE1j0 IG+zvfUIIMsC3g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=jF+L9VU5pOoC9ph6n+/fshiKNjnVP JadfZQhWkPk6YU=; b=MqoMGxxHgeUEp7SNvS001lWhJlz1iv9RapM8X7nyuMKWX 4+Uf6ZR3IRjlCrFQJkZhjcmMUYlsi1psu4NRyFvnuY4zjHz3XHhoq818G+qhn+H8 tuXNerga6nO3KK47XutkxZJoTBQQ+WwxTb0hHOCeIFw8MtM+X2O4CTzX2ySPOQCa B1ctCyFUfOzarS2wFqgWxOXfJD/UG+6zXNoMLpmiFApY7EJEJVZVcTDSHfw+iDpv zpRSibDDQFH6gEgRUTzHM6A8jC6lxrLrzZkWVSEm3gf6D1ZJn/ZuKuNyLzPtTS+m ovhkJSFk5YcL/QINHiEMbMEr8mGuCQWEJEBd+alQQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddtledguddthecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeehvddrudejledrudeige drudegleenucevlhhushhtvghrufhiiigvpeeknecurfgrrhgrmhepmhgrihhlfhhrohhm peguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az186-442.internal.cloudapp.net (unknown [52.179.164.149]) by mail.messagingengine.com (Postfix) with ESMTPA id 6D047240054 for ; Sun, 7 Mar 2021 02:38:04 -0500 (EST) Content-Type: multipart/alternative; boundary="===============9126913848618142208==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20210307073804.6D047240054@mailuser.nyi.internal> Date: Sun, 7 Mar 2021 02:38:04 -0500 (EST) Archived-At: Subject: [GNAP] Weekly github digest (GNAP Weekly GitHub Activity Summary) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2021 08:16:05 -0000 --===============9126913848618142208== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * ietf-wg-gnap/core-protocol (+2/-1/=F0=9F=92=AC70) 2 issues created: - Make sure prose and property names are consistent (by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/205 [Editoria= l]=20 - Requesting resources with insufficient access (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/203=20 16 issues received 70 new comments: - #203 Requesting resources with insufficient access (10 by Denisthemalic= e, agropper, fimbault, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/203=20 - #198 Definition of a Subject in section 1.3 (6 by Denisthemalice, fimba= ult) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/198=20 - #197 Requesting User Information (7 by Denisthemalice, fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/197=20 - #193 Requesting Resources With Insufficient Access (2 by Denisthemalice= , fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/193=20 - #192 The first figure in section 1.4 should be split and revisited (10 = by Denisthemalice, agropper, fimbault, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/192=20 - #191 Validity of an access token (5 by Denisthemalice, fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/191=20 - #190 Tentative proposal for a RS discovery mechanism (4 by Denisthemali= ce, fimbault, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/190=20 - #189 Token format (4 by Denisthemalice, fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/189=20 - #188 Prior relationship or not between a RS and an AS (5 by Denisthemal= ice, fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/188=20 - #187 The case of a RS trusting more that one AS (2 by Denisthemalice, f= imbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/187=20 - #186 User consent and user notice (4 by Denisthemalice, fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/186=20 - #185 Protected and Public Resources (5 by Denisthemalice, fimbault, jri= cher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/185=20 - #163 Split redirect and post callback into separate modes (1 by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/163=20 - #79 Error responses (1 by adeinega) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/79=20 - #51 User reference as an assertion (2 by fimbault, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/51=20 - #41 Assertion format names (2 by adeinega, fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/41=20 1 issues closed: - Split redirect and post callback into separate modes https://github.com= /ietf-wg-gnap/gnap-core-protocol/issues/163=20 Pull requests ------------- * ietf-wg-gnap/core-protocol (+3/-2/=F0=9F=92=AC9) 3 pull requests submitted: - Mnr editorial changes for jws and jwsd (by adeinega) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/207=20 - An HTTP 400 status code for the error response (by adeinega) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/206=20 - Minor typos (by yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/204=20 4 pull requests received 9 new comments: - #207 Mnr editorial changes for jws and jwsd (3 by adeinega, jricher, ne= tlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/207=20 - #206 An HTTP 400 status code for the error response (3 by adeinega, jri= cher, netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/206=20 - #204 Minor typos (1 by netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/204=20 - #184 sub_ids and different contexts (2 by adeinega, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/184 [Pending Me= rge]=20 2 pull requests merged: - Minor typos https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/204 [Editorial]= =20 - fix token example https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/200 [Editorial]= =20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol --===============9126913848618142208== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (GNAP Weekly GitHub Activity Summary)

Sunday March 07, 2021

Events without label "editorial"

Issues

ietf-wg-gnap/core-protocol (+2/-1/=F0=9F=92=AC70)

2 issues created:

16 issues received 70 new comments:

1 issues closed:

Pull requests

ietf-wg-gnap/core-protocol (+3/-2/=F0=9F=92=AC9)

3 pull requests submitted:

4 pull requests received 9 new comments:

2 pull requests merged:

Repositories tracked by this digest:

--===============9126913848618142208==-- From nobody Tue Mar 9 16:51:04 2021 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 DA00C3A1487 for ; Tue, 9 Mar 2021 16:51:02 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 2Y_UCvsRBjqD for ; Tue, 9 Mar 2021 16:51:00 -0800 (PST) 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 C25633A147E for ; Tue, 9 Mar 2021 16:51:00 -0800 (PST) Received: from [192.168.1.22] (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 12A0owFR026438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 9 Mar 2021 19:50:59 -0500 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_CFD7EC43-B2DF-4D6B-BC9C-5E43446D07FC" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: Date: Tue, 9 Mar 2021 19:50:58 -0500 To: txauth gnap X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [GNAP] PRs Pending Merge X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 00:51:03 -0000 --Apple-Mail=_CFD7EC43-B2DF-4D6B-BC9C-5E43446D07FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi everyone, At the last editor=E2=80=99s meeting we marked the following pull = requests Pending Merge. Most of these are small changes, but they do = affect the syntax or normative language so please read them over. = We=E2=80=99ll be merging them one week from today. sub_ids and different contexts https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/184 = Suggested changes for Discovery field names https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/194 = Update DPoP Syntax https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/195 = Adding information about the Cache-Control header and its value https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/199 = Syntax and schema based normalization for URI in the htu claim https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/202 = There are a number of other PRs in flight right now that haven=E2=80=99t = been pulled in yet, but please look through the tracker and take a look = at what=E2=80=99s there. =E2=80=94 Justin --Apple-Mail=_CFD7EC43-B2DF-4D6B-BC9C-5E43446D07FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = everyone,

At the = last editor=E2=80=99s meeting we marked the following pull requests = Pending Merge. Most of these are small changes, but they do affect the = syntax or normative language so please read them over. We=E2=80=99ll be = merging them one week from today.

 sub_ids and different = contexts
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/184=

Suggested changes for Discovery field = names
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/194=

Update DPoP Syntax
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/195=

Adding information about the Cache-Control header = and its value
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/199=

Syntax and schema based normalization for URI in the = htu claim
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/202=


There are a number of other PRs in = flight right now that haven=E2=80=99t been pulled in yet, but please = look through the tracker and take a look at what=E2=80=99s = there.

 =E2=80=94 = Justin

= --Apple-Mail=_CFD7EC43-B2DF-4D6B-BC9C-5E43446D07FC-- From nobody Wed Mar 10 01:11:10 2021 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 7699D3A1FD3 for ; Wed, 10 Mar 2021 01:11:08 -0800 (PST) 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 yo-t2hd_nz0x for ; Wed, 10 Mar 2021 01:11:05 -0800 (PST) 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 951D23A1FD1 for ; Wed, 10 Mar 2021 01:11:05 -0800 (PST) Received: by mail-il1-x12a.google.com with SMTP id e7so14867329ile.7 for ; Wed, 10 Mar 2021 01:11:05 -0800 (PST) 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=bLttPsKGfcXYmjSt/KBH2o9JUySY5yfsYVvxe9b1vyE=; b=QzY5BZ4fGR+pR3ZyKewfuBG7SfsqyaJSQzdfB0y1Bm+oi3U9VAhY9jsgiYKxoYO1Uo FEemu3NffzjjofwsfXbpKJInK9MilKDtC/3vboVKCLaSVeUpztk3WfKXjV/6k04ih61D zv61oIp4MctRYauxVLJCfSHjG/JGMdMg4GHe/x0N+aGylJHbC3CfmSxoDIQFuvMqduMb QU8w+tp5QjgRCzizmKECJdEwS7uoFyeL0RURJLH983eGL91L3UeTHAQkEvWXXrYqTKZ3 zOV7gqk5U3ghor9x6LNMTvjV/1w6UIYGsw/XKfjHTpMUqRcb+I97me+JyGPSBY6TTxfc 9gRA== 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=bLttPsKGfcXYmjSt/KBH2o9JUySY5yfsYVvxe9b1vyE=; b=rD2PI/DDBhxzcxl9CFq4GFsmzT8X8pIR4wIFaAR/cVUeOKAs6Yl3iSYTwrfhJCod0Y jm8G974RlHpcJP8+m65fosXnFQskGUlXsoxDoTlvhrztTlxXBAE2DhYiIYS3RcxAB00c sGri0fCFyyNu/M/rQTT68rGWHbi/N2ZFyJdWgmiB2a7Y/wjXNq6lvF6SdG2N0OvjXrbr im5tFA7y8+xOTFoBQvAaNiTO4MGKvtVM6SdcpayCSkEMwn51XuFeWvYLB1ZTw5QYLKLq 4jg7AZWNHjKZFYBJ98Jlp/93iFcAnK2eWT65LTxFpCQ9gnXcYeJT0Yu830fat0wahZ5W wazw== X-Gm-Message-State: AOAM530KXOY+N/hHU2S7BejG0sDgt36UGGWWhReKpU8bCcvpxtBLYncI etTXhafSNPNN5nH/24quuml2lFfOBO/DHnSrwaRVMsz127YODw== X-Google-Smtp-Source: ABdhPJyOJm/f2HKalmrRMFL07Q9voIonxilCiZdPUAsQh8Sc7X71FerwQg+lCoScpfwxTr+JLVHk8L7L84IhdUOUOCM= X-Received: by 2002:a92:d84f:: with SMTP id h15mr425730ilq.178.1615367463728; Wed, 10 Mar 2021 01:11:03 -0800 (PST) MIME-Version: 1.0 From: Fabien Imbault Date: Wed, 10 Mar 2021 10:10:52 +0100 Message-ID: To: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000db7a0105bd2b0bc1" Archived-At: Subject: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 09:11:08 -0000 --000000000000db7a0105bd2b0bc1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, Notice the question mark in the title. Not to be considered as an editor's comment. This thread intends to provide a detailed comment on the interesting feedback by Kristina: "I would catch up on the thread to understand why DIDs are thought to be treated as assertions". In the chat, I answered: "Happy to get the discussion on DIDs. Actually, could be either or, depending on what we intend to do." Let me expand a bit on that, to make it understandable (didn't have the time during the meeting, unfortunately). This relates to the items described on slides 20 and 34, which I'll explain further. I'll highlight as transparently as possible what I think would be the benefits and downsides of each. Both are probably viable options, but they correspond to different scopes and objectives. I'll spend a bit more time on option 2, since it is a different approach compared to the current draft. *1. The first possibility is to use SECEVENT throughout. * In that case, DIDs should be a part of sub_ids (in the core or in the extension registry, depending on what Annabelle's WG decides). More generally, the WG would have to decide which additional sub_ids it needs (as per Yaron's comment). That's obviously the closest to what is described in draft-04. It allows a communication of subject information between the client and the AS, by using global identifiers (mail, phone, etc.), or using a local opaque reference - i.e. governed by the AS (that's probably what we would put in the examples, unless someone has a better idea - cf issues #16 and #42). Assertions relate for instance to the proof of presence of the RO. The current draft-04 therefore plans for id_tokens and saml2, maybe there could be other needs later (extension registry). - Benefits: identifiers are a key component of GNAP, which makes integration easier. Possibly one could choose to use DIDs throughout. - Downsides: email/phone identifiers will probably be used throughout by most devs (since that's correlation information they have in their user DB). Which means we should limit what assertions contain, to avoid doing links between weak global identifiers and hopefully stronger assertions. That's not really a problem if it's limited to authentication events mostly (in that perspective, samlv2 could make sense in the core). An assertion is probably a single value then (not an array). Option 1 can be summarized as: "subject": { "sub_ids": { }, // request and response (SECEVENT -> including DID possibly) "assertions": [ ], // request and response (id_token or samlv2) } ("hints" do not exist currently, but are partially covered separately via "request.user" / the relevance of "principal", discussed in the slide, is a question mark too - which is a different discussion on end-user !=3D RO). *2. An alternate possibility is to use SECEVENT only as input/hint* In that case, DIDs should be a part of assertions (which have a different meaning compared to option 1). The AS only returns an local opaque reference as_ref (while in option 1, it was only one of many possibilities). Its only job is to help the client differentiate the response subject. The AS policy might further define the scope of that reference, as suggested in https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210, although I personally viewed that by default as (2) "as_id" an identifier locally unique to that AS for all the RSs. SECEVENTS are still useful as an input, that's what I presented in request.hints.self.sub_ids (but it's the responsibility of the AS to match it with its own reference system - from instance from the email to AS's local record XUT2MFM1XBIKJKSDU8Q). Note: since the slides, a new draft-ietf-secevent-subject-identifiers-07 has been published. Notably this includes an opaque identifier, which the client can use to pass the as_ref hint to the AS. Thus we wouldn't need any further addition to SECEVENT, although hints would benefit from further additions (like DIDs for instance). Notice also that subject_types_supported becomes less important, because in the worst case scenario, it's simply a hint that wouldn't be understood and therefore taken into account by the AS. The assertions array has a more important role than in option 1 (with the explicit aim of separating between client hints and validated info asserted by the AS). It serves as a generic/extendible mapping structure, e.g. "the AS asserts that opaque reference XUT2MFM1XBIKJKSDU8Q is matching with these (more or less verifiable) statements." The name assertion therefore corresponds to the responsibility of the AS in delivering those statements (cf should/must, issue #49). Some of these statements relate to identity or auth events (ex: DID, id_token), some might directly be useful for authorization decisions (like ZKP example in the parental control example). Possibly some of these validated assertions could be reused in next interactions. Another question that popped-up is the scope of sub_ids. Should they be about the same user? (I think so). In the case of remote ROs especially, it might be important that DID be considered as an assertion (about someone else's) and not as sub_ids, because the AS needs to be careful about who the client wants to reach (avoid spam, etc.). This is consistent with the rest of discussion on what to do when end-user !=3D RO, although using DIDComm might seem a bit early (the paint is very fresh). Option 2 was summarized as: // (suggestion only, not as an editor) "subject": { "as_ref": { // response only (wouldn=E2=80=99t require SECEVENT) =E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D, =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D }, "assertions": [ ], // request and response (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validated by the AS) "hints": { // request only (optional) "self": { // replaces request.user (support SECEVENT here) =E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque in draft-0= 7 - that could contain the ref) =E2=80=9Cassertions=E2=80=9D: [ ] // see examples: VC on DOB or ZKP on a= ge (wider scope, possibly through extensions) }, "principal": { // new proposal presented at IETF110 (just an idea) =E2=80=9Cautomated=E2=80=9D: true, // rule engine =E2=80=9Casync=E2=80=9D: { } // remote ROs } } } - Benefits: as_ref is self supporting (no strong coupling with SECEVENT), but can still take SECEVENT as an input hint for the AS. It avoids the risk of making an official association between a weak global identifier (e.g. email, used elsewhere) and hopefully stronger local assertions. GNAP would be fully agnostic to whatever identity system is used, only facilitating interoperability through assertions (second only in importance compared to the AS opaque reference). Some assertions (possibly extensions) could also be useful for the AS decision (e.g. VC or ZKP). - Downsides: opaqueness of as_ref is a feature, not a bug. The opaque reference is fully managed by the AS, therefore not inherently portable (cf portability discussions in OIDC currently). There's no explicit binding to an official identity, only a contextual mapping to AS validated assertions. It makes it more difficult to match the identifiers from one AS to another or to correlate with the client user DB (still possible via assertions, if the AS allows it). Assertions are much more generic (possibly via extensions), but might require a more advanced mechanism to request/response only the most relevant information (which makes the AS policy critical here). I hope that clarifies the reasoning for both options. Again I'm not saying option 2 is better, just saying the trade-offs are different (+ knowing that we need to keep it simple). - option 1 puts more in sub_ids and less in assertions - option 2 puts less in the reference and more in assertions All of this is open to discussion. More generally speaking, on every part in orange and question mark (?) I would love your ideas and criticisms. What I intended as an editor is only to highlight where the WG has important choices to make, before we can make the related PRs. A further side comment: IETF EAT RATS was suggested for assertions, but relates more to the client attestations. It was added as a comment in https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, which is a distinct topic we'll work on. Fabien (editor's hat off) --000000000000db7a0105bd2b0bc1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

Notice the question mark in the = title. Not to be considered as an editor's comment.
This thre= ad intends to provide a detailed comment on the interesting=C2=A0feedback b= y Kristina: "I would catch up on the thread to understand why DIDs are= thought to be treated as assertions".
In the chat, I answer= ed: "Happy to get the discussion on DIDs. Actually, could be either or= , depending on what we intend to do." Let me expand a bit on that, to = make it understandable (didn't have the time during the meeting, unfort= unately).

This relates to the items described on s= lides 20 and 34, which I'll explain further. I'll highlight as tran= sparently as possible what I think would be the benefits and downsides of e= ach. Both are probably viable options, but they correspond to different sco= pes and objectives. I'll spend a bit more time on option 2, since it is= a different approach compared to the current draft.

1. The fir= st possibility is to use SECEVENT throughout.=C2=A0
In that c= ase, DIDs should be a part of sub_ids (in the core or in the extension regi= stry, depending on what Annabelle's WG decides). More generally, the WG= would have to decide which additional sub_ids it needs (as per Yaron's= comment).

That's obviously the closest to wha= t is described in draft-04. It allows a communication of subject informatio= n between the client and the AS, by using global identifiers (mail, phone, = etc.), or using a local opaque reference=C2=A0- i.e. governed by the AS (th= at's probably what we would=C2=A0put in the examples, unless someone ha= s a better idea - cf issues #16 and #42).=C2=A0

As= sertions relate for instance to the proof of presence of the RO. The curren= t draft-04 therefore plans for id_tokens and saml2, maybe there could be ot= her needs later (extension registry).

- Benefits: = identifiers are a key component of GNAP, which makes integration easier. Po= ssibly one could choose to use DIDs throughout.
- Downsides: emai= l/phone identifiers will probably be used throughout by most devs (since th= at's correlation information they=C2=A0have in their user DB). Which me= ans we should limit what assertions contain, to avoid doing links between w= eak global identifiers and hopefully stronger assertions. That's not re= ally a problem if it's limited to authentication events mostly (in that= perspective, samlv2 could make sense in the core). An assertion is probabl= y a single value then (not an array).=C2=A0 =C2=A0

Option 1 can be summarized as:=C2=A0

"= ;subject": {

=C2=A0=C2=A0=C2=A0"sub_ids": = { }, <= span style=3D"font-family:"Courier New";color:rgb(51,51,51);backg= round-color:rgb(247,247,247);font-variant-numeric:normal;font-variant-east-= asian:normal;vertical-align:baseline;white-space:pre-wrap"> // request and response (SECEVENT ->= ; including DID possibly)=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=C2=A0=C2= =A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0"assertions": [ ], = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request and respons= e (id_token or samlv2)

}

("hints" do not ex= ist currently, but are partially covered separately via "request.user&= quot; / the relevance of "principal", discussed in the slide, is = a question mark too - which is a different discussion on end-user !=3D RO).=


<= /span>

2. An alternate possibility is to = use SECEVENT only as input/hint
In that case, DIDs should be = a part of assertions (which have a different meaning compared to option 1).=

The AS only returns an local opaque reference as_= ref (while in option 1, it was only one of many possibilities). Its only jo= b is to help the client differentiate the response subject. The AS policy m= ight further define the scope of that reference, as suggested in=C2=A0https:= //github.com/ietf-wg-gnap/gnap-core-protocol/issues/210, although I per= sonally=C2=A0viewed that by default as=C2=A0(2) "as_id" an identi= fier locally unique to that AS for all the RSs.

SE= CEVENTS are still useful as an input, that's what I presented in reques= t.hints.self.sub_ids (but it's the responsibility=C2=A0of the AS to mat= ch it with its own reference system - from instance from the email to AS= 9;s local record XUT2MFM1XBIKJKSDU8Q).=C2=A0Note: since the slides, a new d= raft-ietf-secevent-subject-identifiers-07 has been published. Notably this = includes an opaque identifier, which the client can use to pass the as_ref = hint to the AS. Thus we wouldn't need any further addition to SECEVENT,= =C2=A0although hints would benefit from further additions (like DIDs for in= stance). Notice also that subject_types_supported becomes less important, b= ecause in the worst case scenario, it's simply=C2=A0a hint that wouldn&= #39;t be understood and therefore taken into account by the AS.
<= br>
The assertions array has a more important role than in option= 1 (with the explicit aim of separating between client hints and validated = info asserted by the AS). It serves as a generic/extendible mapping structu= re, e.g. "the AS asserts that opaque reference=C2=A0XUT2MFM1XBIKJKSDU8Q= =C2=A0is matching with these (more or less verifiable) statements." Th= e name assertion therefore corresponds to the responsibility=C2=A0of the AS= in delivering those statements (cf should/must, issue #49). Some of these = statements relate to identity or auth events (ex: DID, id_token), some migh= t directly be useful for authorization decisions (like ZKP example in the p= arental control example). Possibly some of these validated assertions could= be reused in next interactions.

Another question = that popped-up is the scope of sub_ids. Should they be about the same user?= (I think so). In the case of remote ROs especially, it might be important = that DID be considered as an assertion=C2=A0(about someone else's) and = not as sub_ids, because the AS needs to be careful about who the client wan= ts to reach (avoid spam, etc.). This is consistent with the rest of discuss= ion on what to do when end-user !=3D RO, although using DIDComm might seem = a bit early (the paint is very fresh).=C2=A0

Optio= n 2 was summarized as:=C2=A0

// = (suggestion only, not as an editor)

"subject"= : {

=C2=A0=C2=A0=C2=A0"as_ref": { // response only (wouldn=E2=80=99t require SECEVENT)

=E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D,

=E2=80=9Cref=E2=80=9D: = =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D=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=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"assertions": [ ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 // request and response (id_token/jwkthumb/DID/VC/etc. -&= gt; whatever info can be validated by the AS)


=C2=A0=C2=A0=C2=A0"hints": { =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request = only (optional)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"= ;self": { <= /span>// replac= es request.user (support SECEVENT here)

= =C2=A0=C2=A0=C2=A0=E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque in draft-07 - that could con= tain the ref)

=C2=A0=C2=A0=C2=A0=E2=80= =9Cassertions=E2=80=9D: [ ] // see examples: VC on DOB or ZKP on= age (wider scope, possibly through extensions)

},=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=C2=A0=C2=A0=C2=A0

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"principal": { // new proposal presented at IETF110 (just an idea)=

=C2=A0= =E2=80=9Cautomated=E2=80=9D: true, // rule engine =

= = =C2=A0 =E2=80=9Casync=E2=80=9D: { } = // remot= e ROs

}=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=C2=A0=C2=A0}

}

- Benefits: as_ref is self supporting (no strong coupling with = SECEVENT), but can still take SECEVENT as an input hint for the AS. It avoi= ds the risk of making an official association between a weak global identif= ier (e.g. email, used elsewhere) and hopefully stronger local assertions. G= NAP would be fully agnostic to whatever identity system is used, only facil= itating interoperability through assertions (second only in importance=C2= =A0compared to the AS opaque reference). Some assertions (possibly extensio= ns) could also be useful for the AS decision (e.g. VC or ZKP).
- = Downsides: opaqueness of as_ref is a feature, not a bug. The opaque referen= ce is fully managed by the AS, therefore not inherently portable (cf portab= ility discussions in OIDC currently). There's no explicit binding to an= official identity, only a contextual mapping to AS validated assertions. I= t makes it more difficult to match the identifiers from one AS to another o= r to correlate with the client user DB (still possible via assertions, if t= he AS allows it). Assertions are much more generic (possibly via extensions= ), but might require a more advanced mechanism=C2=A0to request/response onl= y the most relevant information (which makes the AS policy critical here).<= /div>

I hope that clarifies the=C2=A0reasoning for both = options. Again I'm not saying option 2 is better, just saying the trade= -offs are different (+ knowing that we need to keep it simple).
-= option 1 puts more in sub_ids and less in assertions
- option 2 = puts less in the reference and more in assertions=C2=A0
All of th= is is open to discussion. More generally speaking, on every part in orange = and question mark (?) I would love your ideas and criticisms. What I intend= ed as an editor is only to highlight where the WG has important choices to = make, before we can make the related PRs.

A furthe= r side comment: IETF EAT RATS was suggested for assertions, but relates mor= e to the client attestations. It was added as a comment in=C2=A0https://githu= b.com/ietf-wg-gnap/gnap-core-protocol/issues/44, which is a distinct to= pic we'll work on.

Fabien (editor's hat of= f)

--000000000000db7a0105bd2b0bc1-- From nobody Wed Mar 10 09:30:49 2021 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 DEA963A140F for ; Wed, 10 Mar 2021 09:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 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, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mattr-global.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 1We_QYY-VayS for ; Wed, 10 Mar 2021 09:30:44 -0800 (PST) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 ADBE43A140E for ; Wed, 10 Mar 2021 09:30:44 -0800 (PST) Received: by mail-qt1-x829.google.com with SMTP id h26so9250265qtm.5 for ; Wed, 10 Mar 2021 09:30:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattr-global.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xAaMNX1HqCVEJKuS4UtU+14MMxDdm7S1BIkmv1Qf0iU=; b=p2wOjk5dFnFiZJkiHlnSFBSXIfSib0NJYePY9j12Z1myWpH5fhxqvVx8oRNu72lQi8 i67fO+x5Fos/Rc8gO/zCPWQhPDtv0MeJCcUJargCttNOeKsbdpnREmUduDrATIGKxC9Z KR1jOMpNQy2a2BQxjK7HJfc04b8LdwVfFrk61dEg8dC8y9ei1y/MC/pAYPgyy46+N0M4 xljT5YQ+3M7n7WQBh/HNK+08wvn1YTrmaw596ZxO41HAJAk2TDIdJ/tDqF8R4uZ/2VVb rT9lUQ+g9uVat/3rPW+uShjBa/Z0DbIOUGzrcsaeyOVDiJD0qgKWajNeTvdrHb1ZkXdL 0Dhg== 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=xAaMNX1HqCVEJKuS4UtU+14MMxDdm7S1BIkmv1Qf0iU=; b=FwZ0EPpsPOQMdIhrE4AsOe2FWR4hnzZm33rRn/D4ZCsWGQdytbRZdOxSnhcRBnZKDm PR0Tu+7OMe1gElOn9W751tDEn6/IXdN7O6X7xS7jzCvFpkuL9dWUSpHhhRpTUxte4yCv No5c0C4g4Yp6IRBtpz3quIyLkyW4ucbK0QEyFGY69vhitfag+SeT5u/kLv1P0LreLL6X W+yskLvhQTXPJgUCkGqEo0HnMw6RojE8MNFg98eYyrkelq5gL4x9hsr4b/sY0KD+5rXg ovLm/oBQhR1Z2KW5V/1ugfjuGnrNXeiJ8BQKhG//286SC+ky7u0/OSIWzk/BzSdLZagL Kong== X-Gm-Message-State: AOAM533BFyKczXDKf/kNWo+SPykzqWZeULDUWg/9l7EMRIPKh8uhPdYu WD/R/B2oqJ9FDuFB17CnzbiVBrG7Xcf4yhCwg7kdTE4+6NH5dAV+oGc4L+lCzNeJ1kp5Zbl0VAE f/wVhyNp7LrPYTieRDw== X-Google-Smtp-Source: ABdhPJyn1LkL4VbRHVXwgZmv+2HrlOdrecyGLGowA+DZ10xFG2zWeA4M7Loc1IeFRdNvYiixfo5PtKlwXt2TQSihooU= X-Received: by 2002:ac8:6f2e:: with SMTP id i14mr3674045qtv.277.1615397443707; Wed, 10 Mar 2021 09:30:43 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tobias Looker Date: Thu, 11 Mar 2021 06:30:32 +1300 Message-ID: To: Fabien Imbault Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000cdbbfa05bd320675" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 17:30:48 -0000 --000000000000cdbbfa05bd320675 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All, Just my two cents, I don't understand why a DID on its own would be regarded as an assertion about the subject. A DID is just an identifier like any other, the fact the identifier is also resolvable to cryptographic material like public keys that *can *be used to validate cryptographic assertions does not make the DID itself an assertion. On first glance of your proposals Fabien I like the simplicity of option 1, option 2 feels too abstracted. Thanks, [image: Mattr website] *Tobias Looker* Mattr +64 (0) 27 378 0461 tobias.looker@mattr.global [image: Mattr website] [image: Mattr on LinkedIn] [image: Mattr on Twitter] [image: Mattr on Github] This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002. On Wed, Mar 10, 2021 at 10:11 PM Fabien Imbault wrote: > Hello, > > Notice the question mark in the title. Not to be considered as an editor'= s > comment. > This thread intends to provide a detailed comment on the > interesting feedback by Kristina: "I would catch up on the thread to > understand why DIDs are thought to be treated as assertions". > In the chat, I answered: "Happy to get the discussion on DIDs. Actually, > could be either or, depending on what we intend to do." Let me expand a b= it > on that, to make it understandable (didn't have the time during the > meeting, unfortunately). > > This relates to the items described on slides 20 and 34, which I'll > explain further. I'll highlight as transparently as possible what I think > would be the benefits and downsides of each. Both are probably viable > options, but they correspond to different scopes and objectives. I'll spe= nd > a bit more time on option 2, since it is a different approach compared to > the current draft. > > *1. The first possibility is to use SECEVENT throughout. * > In that case, DIDs should be a part of sub_ids (in the core or in the > extension registry, depending on what Annabelle's WG decides). More > generally, the WG would have to decide which additional sub_ids it needs > (as per Yaron's comment). > > That's obviously the closest to what is described in draft-04. It allows = a > communication of subject information between the client and the AS, by > using global identifiers (mail, phone, etc.), or using a local opaque > reference - i.e. governed by the AS (that's probably what we would put in > the examples, unless someone has a better idea - cf issues #16 and #42). > > Assertions relate for instance to the proof of presence of the RO. The > current draft-04 therefore plans for id_tokens and saml2, maybe there cou= ld > be other needs later (extension registry). > > - Benefits: identifiers are a key component of GNAP, which makes > integration easier. Possibly one could choose to use DIDs throughout. > - Downsides: email/phone identifiers will probably be used throughout by > most devs (since that's correlation information they have in their user > DB). Which means we should limit what assertions contain, to avoid doing > links between weak global identifiers and hopefully stronger assertions. > That's not really a problem if it's limited to authentication events most= ly > (in that perspective, samlv2 could make sense in the core). An assertion = is > probably a single value then (not an array). > > Option 1 can be summarized as: > > "subject": { > > "sub_ids": { }, // request and response (SECEVENT -> including DID > possibly) > > "assertions": [ ], // request and response (id_token or > samlv2) > > } > > ("hints" do not exist currently, but are partially covered separately via > "request.user" / the relevance of "principal", discussed in the slide, is= a > question mark too - which is a different discussion on end-user !=3D RO). > > > > *2. An alternate possibility is to use SECEVENT only as input/hint* > In that case, DIDs should be a part of assertions (which have a different > meaning compared to option 1). > > The AS only returns an local opaque reference as_ref (while in option 1, > it was only one of many possibilities). Its only job is to help the clien= t > differentiate the response subject. The AS policy might further define th= e > scope of that reference, as suggested in > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210, although I > personally viewed that by default as (2) "as_id" an identifier locally > unique to that AS for all the RSs. > > SECEVENTS are still useful as an input, that's what I presented in > request.hints.self.sub_ids (but it's the responsibility of the AS to matc= h > it with its own reference system - from instance from the email to AS's > local record XUT2MFM1XBIKJKSDU8Q). Note: since the slides, a new > draft-ietf-secevent-subject-identifiers-07 has been published. Notably th= is > includes an opaque identifier, which the client can use to pass the as_re= f > hint to the AS. Thus we wouldn't need any further addition to > SECEVENT, although hints would benefit from further additions (like DIDs > for instance). Notice also that subject_types_supported becomes less > important, because in the worst case scenario, it's simply a hint that > wouldn't be understood and therefore taken into account by the AS. > > The assertions array has a more important role than in option 1 (with the > explicit aim of separating between client hints and validated info assert= ed > by the AS). It serves as a generic/extendible mapping structure, e.g. "th= e > AS asserts that opaque reference XUT2MFM1XBIKJKSDU8Q is matching with > these (more or less verifiable) statements." The name assertion therefore > corresponds to the responsibility of the AS in delivering those statement= s > (cf should/must, issue #49). Some of these statements relate to identity = or > auth events (ex: DID, id_token), some might directly be useful for > authorization decisions (like ZKP example in the parental control example= ). > Possibly some of these validated assertions could be reused in next > interactions. > > Another question that popped-up is the scope of sub_ids. Should they be > about the same user? (I think so). In the case of remote ROs especially, = it > might be important that DID be considered as an assertion (about someone > else's) and not as sub_ids, because the AS needs to be careful about who > the client wants to reach (avoid spam, etc.). This is consistent with the > rest of discussion on what to do when end-user !=3D RO, although using > DIDComm might seem a bit early (the paint is very fresh). > > Option 2 was summarized as: > > // (suggestion only, not as an editor) > > "subject": { > > "as_ref": { // response only (wouldn=E2=80=99t require SECEVENT) > > =E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D, > > =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D > > }, > > "assertions": [ ], // request and response > (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validated by the A= S) > > "hints": { // request only (optional) > > "self": { // replaces request.user (support SECEVENT here) > > =E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque in draft= -07 - that could > contain the ref) > > =E2=80=9Cassertions=E2=80=9D: [ ] // see examples: VC on DOB or ZKP on= age (wider > scope, possibly through extensions) > > }, > > "principal": { // new proposal presented at IETF110 (just an idea) > > =E2=80=9Cautomated=E2=80=9D: true, // rule engine > > =E2=80=9Casync=E2=80=9D: { } // remote ROs > > } > > } > > } > > - Benefits: as_ref is self supporting (no strong coupling with SECEVENT), > but can still take SECEVENT as an input hint for the AS. It avoids the ri= sk > of making an official association between a weak global identifier (e.g. > email, used elsewhere) and hopefully stronger local assertions. GNAP woul= d > be fully agnostic to whatever identity system is used, only facilitating > interoperability through assertions (second only in importance compared t= o > the AS opaque reference). Some assertions (possibly extensions) could als= o > be useful for the AS decision (e.g. VC or ZKP). > - Downsides: opaqueness of as_ref is a feature, not a bug. The opaque > reference is fully managed by the AS, therefore not inherently portable (= cf > portability discussions in OIDC currently). There's no explicit binding t= o > an official identity, only a contextual mapping to AS validated assertion= s. > It makes it more difficult to match the identifiers from one AS to anothe= r > or to correlate with the client user DB (still possible via assertions, i= f > the AS allows it). Assertions are much more generic (possibly via > extensions), but might require a more advanced mechanism to > request/response only the most relevant information (which makes the AS > policy critical here). > > I hope that clarifies the reasoning for both options. Again I'm not sayin= g > option 2 is better, just saying the trade-offs are different (+ knowing > that we need to keep it simple). > - option 1 puts more in sub_ids and less in assertions > - option 2 puts less in the reference and more in assertions > All of this is open to discussion. More generally speaking, on every part > in orange and question mark (?) I would love your ideas and criticisms. > What I intended as an editor is only to highlight where the WG has > important choices to make, before we can make the related PRs. > > A further side comment: IETF EAT RATS was suggested for assertions, but > relates more to the client attestations. It was added as a comment in > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, which is a > distinct topic we'll work on. > > Fabien (editor's hat off) > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --=20 This communication, including any attachments, is confidential. If you are= =20 not the intended recipient, you should not read it - please contact me=20 immediately, destroy it, and do not copy or use any part of this=20 communication or disclose anything about it. Thank you. Please note that=20 this communication does not designate an information system for the=20 purposes of the Electronic Transactions Act 2002. --000000000000cdbbfa05bd320675 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

Just my two cents, I don't = understand why a DID on its own would be regarded as an assertion about the= subject. A DID is just an identifier like any other, the fact the identifi= er is also resolvable to cryptographic material like public keys that ca= n be used to validate cryptographic assertions does not make the DID it= self an assertion.

On first glance of your proposa= ls Fabien I like the simplicity of option 1, option 2 feels too abstracted.=

Thank= s,
=
3D"Mattr=C2=A0
Tobias Looker
Mattr
+64 (0) 27 378 0461
tobias.looker@mattr.global
=3D"Mattr3D"Matt== 3D"Mattr

This communication, including a= ny attachments, is confidential. If you are not the intended recipient, you= should not read it - please contact me immediately, destroy it, and do not= copy or use any part of this communication or disclose anything about it. = Thank you. Please note that this communication does not designate an inform= ation system for the purposes of the Electronic Transactions Act 2002.


On Wed, Mar 10, 2021 at 10:11 PM Fabien = Imbault <fabien.imbault@gmai= l.com> wrote:
Hello,

Notice the question mark in= the title. Not to be considered as an editor's comment.
This= thread intends to provide a detailed comment on the interesting=C2=A0feedb= ack by Kristina: "I would catch up on the thread to understand why DID= s are thought to be treated as assertions".
In the chat, I a= nswered: "Happy to get the discussion on DIDs. Actually, could be eith= er or, depending on what we intend to do." Let me expand a bit on that= , to make it understandable (didn't have the time during the meeting, u= nfortunately).

This relates to the items described= on slides 20 and 34, which I'll explain further. I'll highlight as= transparently as possible what I think would be the benefits and downsides= of each. Both are probably viable options, but they correspond to differen= t scopes and objectives. I'll spend a bit more time on option 2, since = it is a different approach compared to the current draft.

1. The= first possibility is to use SECEVENT throughout.=C2=A0
In th= at case, DIDs should be a part of sub_ids (in the core or in the extension = registry, depending on what Annabelle's WG decides). More generally, th= e WG would have to decide which additional sub_ids it needs (as per Yaron&#= 39;s comment).

That's obviously the closest to= what is described in draft-04. It allows a communication of subject inform= ation between the client and the AS, by using global identifiers (mail, pho= ne, etc.), or using a local opaque reference=C2=A0- i.e. governed by the AS= (that's probably what we would=C2=A0put in the examples, unless someon= e has a better idea - cf issues #16 and #42).=C2=A0

Assertions relate for instance to the proof of presence of the RO. The cu= rrent draft-04 therefore plans for id_tokens and saml2, maybe there could b= e other needs later (extension registry).

- Benefi= ts: identifiers are a key component of GNAP, which makes integration easier= . Possibly one could choose to use DIDs throughout.
- Downsides: = email/phone identifiers will probably be used throughout by most devs (sinc= e that's correlation information they=C2=A0have in their user DB). Whic= h means we should limit what assertions contain, to avoid doing links betwe= en weak global identifiers and hopefully stronger assertions. That's no= t really a problem if it's limited to authentication events mostly (in = that perspective, samlv2 could make sense in the core). An assertion is pro= bably a single value then (not an array).=C2=A0 =C2=A0

=
Option 1 can be summarized as:=C2=A0

"subject": {

=C2=A0= =C2=A0=C2=A0"sub_ids": { }, <= /span> // request= and response (SECEVENT -> including DID possibly)=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=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0= "assertions": [ ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 // request and response (id_token or samlv2)

}

("hints" do not exist currently, but are partially covered sepa= rately via "request.user" / the relevance of "principal"= ;, discussed in the slide, is a question mark too - which is a different di= scussion on end-user !=3D RO).



2. A= n alternate possibility is to use SECEVENT only as input/hint
In that case, DIDs should be a part of assertions (which have a different = meaning compared to option 1).

The AS only returns= an local opaque reference as_ref (while in option 1, it was only one of ma= ny possibilities). Its only job is to help the client differentiate the res= ponse subject. The AS policy might further define the scope of that referen= ce, as suggested in=C2=A0https://github.com/ietf-wg-gnap/g= nap-core-protocol/issues/210, although I personally=C2=A0viewed that by= default as=C2=A0(2) "as_id" an identifier locally unique to that= AS for all the RSs.

SECEVENTS are still useful as= an input, that's what I presented in request.hints.self.sub_ids (but i= t's the responsibility=C2=A0of the AS to match it with its own referenc= e system - from instance from the email to AS's local record XUT2MFM1XB= IKJKSDU8Q).=C2=A0Note: since the slides, a new draft-ietf-secevent-subject-= identifiers-07 has been published. Notably this includes an opaque identifi= er, which the client can use to pass the as_ref hint to the AS. Thus we wou= ldn't need any further addition to SECEVENT,=C2=A0although hints would = benefit from further additions (like DIDs for instance). Notice also that s= ubject_types_supported becomes less important, because in the worst case sc= enario, it's simply=C2=A0a hint that wouldn't be understood and the= refore taken into account by the AS.

The assertion= s array has a more important role than in option 1 (with the explicit aim o= f separating between client hints and validated info asserted by the AS). I= t serves as a generic/extendible mapping structure, e.g. "the AS asser= ts that opaque reference=C2=A0XUT2MFM1XBIKJKSDU8Q=C2=A0is matching with these= (more or less verifiable) statements." The name assertion therefore c= orresponds to the responsibility=C2=A0of the AS in delivering those stateme= nts (cf should/must, issue #49). Some of these statements relate to identit= y or auth events (ex: DID, id_token), some might directly be useful for aut= horization decisions (like ZKP example in the parental control example). Po= ssibly some of these validated assertions could be reused in next interacti= ons.

Another question that popped-up is the scope = of sub_ids. Should they be about the same user? (I think so). In the case o= f remote ROs especially, it might be important that DID be considered as an= assertion=C2=A0(about someone else's) and not as sub_ids, because the = AS needs to be careful about who the client wants to reach (avoid spam, etc= .). This is consistent with the rest of discussion on what to do when end-u= ser !=3D RO, although using DIDComm might seem a bit early (the paint is ve= ry fresh).=C2=A0

Option 2 was summarized as:=C2=A0=

// = (suggestion only, not as an editor)

"subject"= : {

=C2=A0=C2=A0=C2=A0"as_ref": { // response only (would= n=E2=80=99t require SECEVENT)

=E2=80= =9Cas=E2=80=9D: =E2=80=9Ch= ttps://ex1.as.com=E2=80=9D, =

=E2=80= =9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D=C2=A0=C2=A0=C2=A0

=

<= span style=3D"font-family:"Courier New";color:rgb(51,51,51);backg= round-color:rgb(247,247,247);font-variant-numeric:normal;font-variant-east-= asian:normal;vertical-align:baseline;white-space:pre-wrap">=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<= /p>

=C2=A0=C2=A0=C2=A0"assertions": [ ], =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 // request and response (id_token/jwkthumb/DID= /VC/etc. -> whatever info can be validated by the AS)

<= font size=3D"1">

=C2=A0=C2=A0=C2=A0"hints": { =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /= / request only (optional)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0"self": { // replaces request.user (support SECEVENT here)

=C2=A0=C2=A0=C2=A0=E2=80=9Csub_ids=E2=80= =9D: { }, = = // SECEVENT (including opaque in draft-07 - that could contain the ref)

=C2=A0=C2=A0=C2=A0=E2=80=9Cassertions=E2=80= =9D: [ ] // see examples: VC on DOB or ZKP on age (wider scope, = possibly through extensions)

},=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=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0"principal": { // new propo= sal presented at IETF110 (just an idea)

=C2=A0 =E2=80=9Cautomated=E2=80=9D: true, // rule engine<= span style=3D"font-family:"Courier New";color:rgb(51,51,51);backg= round-color:rgb(247,247,247);font-variant-numeric:normal;font-variant-east-= asian:normal;vertical-align:baseline;white-space:pre-wrap">

=C2=A0 =E2=80=9Casync=E2= =80=9D: { } // remote ROs

}=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=C2=A0=C2=A0}

}


- Benefits: as_r= ef is self supporting (no strong coupling with SECEVENT), but can still tak= e SECEVENT as an input hint for the AS. It avoids the risk of making an off= icial association between a weak global identifier (e.g. email, used elsewh= ere) and hopefully stronger local assertions. GNAP would be fully agnostic = to whatever identity system is used, only facilitating interoperability thr= ough assertions (second only in importance=C2=A0compared to the AS opaque r= eference). Some assertions (possibly extensions) could also be useful for t= he AS decision (e.g. VC or ZKP).
- Downsides: opaqueness of as_re= f is a feature, not a bug. The opaque reference is fully managed by the AS,= therefore not inherently portable (cf portability discussions in OIDC curr= ently). There's no explicit binding to an official identity, only a con= textual mapping to AS validated assertions. It makes it more difficult to m= atch the identifiers from one AS to another or to correlate with the client= user DB (still possible via assertions, if the AS allows it). Assertions a= re much more generic (possibly via extensions), but might require a more ad= vanced mechanism=C2=A0to request/response only the most relevant informatio= n (which makes the AS policy critical here).

I hop= e that clarifies the=C2=A0reasoning for both options. Again I'm not say= ing option 2 is better, just saying the trade-offs are different (+ knowing= that we need to keep it simple).
- option 1 puts more in sub_ids= and less in assertions
- option 2 puts less in the reference and= more in assertions=C2=A0
All of this is open to discussion. More= generally speaking, on every part in orange and question mark (?) I would = love your ideas and criticisms. What I intended as an editor is only to hig= hlight where the WG has important choices to make, before we can make the r= elated PRs.

A further side comment: IETF EAT RATS = was suggested for assertions, but relates more to the client attestations. = It was added as a comment in=C2=A0https://github.com/ietf-w= g-gnap/gnap-core-protocol/issues/44, which is a distinct topic we'l= l work on.

Fabien (editor's hat off)

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

This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.
--000000000000cdbbfa05bd320675-- From nobody Wed Mar 10 09:48:36 2021 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 440823A1477 for ; Wed, 10 Mar 2021 09:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, T_REMOTE_IMAGE=0.01, 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 CziNLosQgbSO for ; Wed, 10 Mar 2021 09:48:32 -0800 (PST) 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 D69403A1458 for ; Wed, 10 Mar 2021 09:48:31 -0800 (PST) Received: by mail-io1-xd2a.google.com with SMTP id u8so18800529ior.13 for ; Wed, 10 Mar 2021 09:48:31 -0800 (PST) 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=ioCZlMhKBOATnxkWGxUifRvsopQQXU+d5dCzqdbQH2U=; b=COzZuZz+OJu8wvv/qMHyXMw4CNJEXUfpEQNgEVrPfaaevUXz0lLi71DoTX+iDcalee 0uJGuNy9ny6MHKM7yqSbruTwTbvDRoyOJ/6o0O+SO54lkfzda2YicWvf/w6753u6jlVf MIHOSh6QmjGl//ey44oN+B+Zj116uwkpGUsVSfARKYSOcPQzh8d6Y6VQjGCvJP3u2mbe nQxIsrWkxd/k1pjwX1ZeT7cXxukxzdpxstT/99Ys8LsCPkNCLaKIwndXJJt0Ml9Ah6oA nKT2XEgEoXw8yClAC6qXkB/ldTPnYcrBPDAqGhpfIl+jZeOALUu3pQsYFYVwtYB8ys4W Bdvw== 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=ioCZlMhKBOATnxkWGxUifRvsopQQXU+d5dCzqdbQH2U=; b=ZBHSCx+3+b4+e8WCucr/MP7XAG91TFRH/HR5i+MPYNLOCgrzJqG8AyOGoppnrjJQfv 2Q1AVgmCfKshulqE2KG6WWMFGERONIF6018RRzNGrwZNPw5VX/X89LPO4YVstjMrKkkl Hg4UXBEL9LZvOu3soarCIY4PvgzwkpQvXgrAGGw5PNWtEtuUpLZVBi3wm9IbQ3Uevf3M hGbhq77NYPvEDdQhBOIqWVf4YTqHD4cc1irrQJK729KsbSdNZ+JKP9k9DkACBcWXSAwb oxLzrDrqSoIc6J/1bF/SG1KOkoBSpGnWXfGbjrbNt8zGJS9VQU8vt/lJq4je2buqYXV8 TChQ== X-Gm-Message-State: AOAM5333Pm8tJ1m6nSD/BfEpHYIbQA6OlBKslefS4rO2Wih+fKuwEata oDtMdW6sH/bUdyWcSEluY4NQFVFah8zd04222yQ= X-Google-Smtp-Source: ABdhPJzAyBePz75qZ7snaztQXW97OlAXsgwfvofmu0KRLrd96C+9ORfHN2T+ncSB+XdO/wzSDgcKjVudJaWAXjRCCig= X-Received: by 2002:a02:c6b4:: with SMTP id o20mr4057671jan.124.1615398511000; Wed, 10 Mar 2021 09:48:31 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Wed, 10 Mar 2021 18:48:19 +0100 Message-ID: To: Tobias Looker Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000006b41c605bd32467a" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 17:48:35 -0000 --0000000000006b41c605bd32467a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the feedback, although I'm not sure what you mean by too abstract. Just a quick comment: an assertion in option 2 is not "the fact the identifier is resolvable to cryptographic material that *can *be used to validate cryptographic assertions". It is merely a statement by the AS that "the subject corresponding to the reference has a DID" ("has" is the assertion here). Or said otherwise, it is the mapping between as_ref and the DID (for that specific case). On Wed, Mar 10, 2021 at 6:30 PM Tobias Looker wrote: > Hi All, > > Just my two cents, I don't understand why a DID on its own would be > regarded as an assertion about the subject. A DID is just an identifier > like any other, the fact the identifier is also resolvable to cryptograph= ic > material like public keys that *can *be used to validate cryptographic > assertions does not make the DID itself an assertion. > > On first glance of your proposals Fabien I like the simplicity of option > 1, option 2 feels too abstracted. > > Thanks, > [image: Mattr website] > *Tobias Looker* > Mattr > +64 (0) 27 378 0461 > tobias.looker@mattr.global > [image: Mattr website] [image: Mattr on LinkedIn] > [image: Mattr on Twitter] > [image: Mattr on Github] > > This communication, including any attachments, is confidential. If you ar= e > not the intended recipient, you should not read it - please contact me > immediately, destroy it, and do not copy or use any part of this > communication or disclose anything about it. Thank you. Please note that > this communication does not designate an information system for the > purposes of the Electronic Transactions Act 2002. > > > On Wed, Mar 10, 2021 at 10:11 PM Fabien Imbault > wrote: > >> Hello, >> >> Notice the question mark in the title. Not to be considered as an >> editor's comment. >> This thread intends to provide a detailed comment on the >> interesting feedback by Kristina: "I would catch up on the thread to >> understand why DIDs are thought to be treated as assertions". >> In the chat, I answered: "Happy to get the discussion on DIDs. Actually, >> could be either or, depending on what we intend to do." Let me expand a = bit >> on that, to make it understandable (didn't have the time during the >> meeting, unfortunately). >> >> This relates to the items described on slides 20 and 34, which I'll >> explain further. I'll highlight as transparently as possible what I thin= k >> would be the benefits and downsides of each. Both are probably viable >> options, but they correspond to different scopes and objectives. I'll sp= end >> a bit more time on option 2, since it is a different approach compared t= o >> the current draft. >> >> *1. The first possibility is to use SECEVENT throughout. * >> In that case, DIDs should be a part of sub_ids (in the core or in the >> extension registry, depending on what Annabelle's WG decides). More >> generally, the WG would have to decide which additional sub_ids it needs >> (as per Yaron's comment). >> >> That's obviously the closest to what is described in draft-04. It allows >> a communication of subject information between the client and the AS, by >> using global identifiers (mail, phone, etc.), or using a local opaque >> reference - i.e. governed by the AS (that's probably what we would put i= n >> the examples, unless someone has a better idea - cf issues #16 and #42). >> >> Assertions relate for instance to the proof of presence of the RO. The >> current draft-04 therefore plans for id_tokens and saml2, maybe there co= uld >> be other needs later (extension registry). >> >> - Benefits: identifiers are a key component of GNAP, which makes >> integration easier. Possibly one could choose to use DIDs throughout. >> - Downsides: email/phone identifiers will probably be used throughout by >> most devs (since that's correlation information they have in their user >> DB). Which means we should limit what assertions contain, to avoid doing >> links between weak global identifiers and hopefully stronger assertions. >> That's not really a problem if it's limited to authentication events mos= tly >> (in that perspective, samlv2 could make sense in the core). An assertion= is >> probably a single value then (not an array). >> >> Option 1 can be summarized as: >> >> "subject": { >> >> "sub_ids": { }, // request and response (SECEVENT -> including DID >> possibly) >> >> "assertions": [ ], // request and response (id_token or >> samlv2) >> >> } >> >> ("hints" do not exist currently, but are partially covered separately vi= a >> "request.user" / the relevance of "principal", discussed in the slide, i= s a >> question mark too - which is a different discussion on end-user !=3D RO)= . >> >> >> >> *2. An alternate possibility is to use SECEVENT only as input/hint* >> In that case, DIDs should be a part of assertions (which have a differen= t >> meaning compared to option 1). >> >> The AS only returns an local opaque reference as_ref (while in option 1, >> it was only one of many possibilities). Its only job is to help the clie= nt >> differentiate the response subject. The AS policy might further define t= he >> scope of that reference, as suggested in >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210, although >> I personally viewed that by default as (2) "as_id" an identifier locally >> unique to that AS for all the RSs. >> >> SECEVENTS are still useful as an input, that's what I presented in >> request.hints.self.sub_ids (but it's the responsibility of the AS to mat= ch >> it with its own reference system - from instance from the email to AS's >> local record XUT2MFM1XBIKJKSDU8Q). Note: since the slides, a new >> draft-ietf-secevent-subject-identifiers-07 has been published. Notably t= his >> includes an opaque identifier, which the client can use to pass the as_r= ef >> hint to the AS. Thus we wouldn't need any further addition to >> SECEVENT, although hints would benefit from further additions (like DIDs >> for instance). Notice also that subject_types_supported becomes less >> important, because in the worst case scenario, it's simply a hint that >> wouldn't be understood and therefore taken into account by the AS. >> >> The assertions array has a more important role than in option 1 (with th= e >> explicit aim of separating between client hints and validated info asser= ted >> by the AS). It serves as a generic/extendible mapping structure, e.g. "t= he >> AS asserts that opaque reference XUT2MFM1XBIKJKSDU8Q is matching with >> these (more or less verifiable) statements." The name assertion therefor= e >> corresponds to the responsibility of the AS in delivering those statemen= ts >> (cf should/must, issue #49). Some of these statements relate to identity= or >> auth events (ex: DID, id_token), some might directly be useful for >> authorization decisions (like ZKP example in the parental control exampl= e). >> Possibly some of these validated assertions could be reused in next >> interactions. >> >> Another question that popped-up is the scope of sub_ids. Should they be >> about the same user? (I think so). In the case of remote ROs especially,= it >> might be important that DID be considered as an assertion (about someone >> else's) and not as sub_ids, because the AS needs to be careful about who >> the client wants to reach (avoid spam, etc.). This is consistent with th= e >> rest of discussion on what to do when end-user !=3D RO, although using >> DIDComm might seem a bit early (the paint is very fresh). >> >> Option 2 was summarized as: >> >> // (suggestion only, not as an editor) >> >> "subject": { >> >> "as_ref": { // response only (wouldn=E2=80=99t require SECEVENT) >> >> =E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D, >> >> =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D >> >> }, >> >> "assertions": [ ], // request and response >> (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validated by the = AS) >> >> "hints": { // request only (optional) >> >> "self": { // replaces request.user (support SECEVENT here) >> >> =E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque in draf= t-07 - that >> could contain the ref) >> >> =E2=80=9Cassertions=E2=80=9D: [ ] // see examples: VC on DOB or ZKP o= n age (wider >> scope, possibly through extensions) >> >> }, >> >> "principal": { // new proposal presented at IETF110 (just an idea) >> >> =E2=80=9Cautomated=E2=80=9D: true, // rule engine >> >> =E2=80=9Casync=E2=80=9D: { } // remote ROs >> >> } >> >> } >> >> } >> >> - Benefits: as_ref is self supporting (no strong coupling with SECEVENT)= , >> but can still take SECEVENT as an input hint for the AS. It avoids the r= isk >> of making an official association between a weak global identifier (e.g. >> email, used elsewhere) and hopefully stronger local assertions. GNAP wou= ld >> be fully agnostic to whatever identity system is used, only facilitating >> interoperability through assertions (second only in importance compared = to >> the AS opaque reference). Some assertions (possibly extensions) could al= so >> be useful for the AS decision (e.g. VC or ZKP). >> - Downsides: opaqueness of as_ref is a feature, not a bug. The opaque >> reference is fully managed by the AS, therefore not inherently portable = (cf >> portability discussions in OIDC currently). There's no explicit binding = to >> an official identity, only a contextual mapping to AS validated assertio= ns. >> It makes it more difficult to match the identifiers from one AS to anoth= er >> or to correlate with the client user DB (still possible via assertions, = if >> the AS allows it). Assertions are much more generic (possibly via >> extensions), but might require a more advanced mechanism to >> request/response only the most relevant information (which makes the AS >> policy critical here). >> >> I hope that clarifies the reasoning for both options. Again I'm not >> saying option 2 is better, just saying the trade-offs are different (+ >> knowing that we need to keep it simple). >> - option 1 puts more in sub_ids and less in assertions >> - option 2 puts less in the reference and more in assertions >> All of this is open to discussion. More generally speaking, on every par= t >> in orange and question mark (?) I would love your ideas and criticisms. >> What I intended as an editor is only to highlight where the WG has >> important choices to make, before we can make the related PRs. >> >> A further side comment: IETF EAT RATS was suggested for assertions, but >> relates more to the client attestations. It was added as a comment in >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, which is a >> distinct topic we'll work on. >> >> Fabien (editor's hat off) >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > This communication, including any attachments, is confidential. If you ar= e not the intended recipient, you should not read it - please contact me im= mediately, destroy it, and do not copy or use any part of this communicatio= n or disclose anything about it. Thank you. Please note that this communica= tion does not designate an information system for the purposes of the Elect= ronic Transactions Act 2002. > > --0000000000006b41c605bd32467a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the feedback, although I'm not sure what yo= u mean by too abstract.
Just a quick comment: an assertion in option 2 = is not "the fact the identifier is resolvable to cryptographic materia= l that=C2=A0can=C2=A0be used to validate cryptographic assertions&qu= ot;. It is merely a statement by the AS that "the subject correspondin= g to the reference has a DID" ("has" is the assertion here).= Or said otherwise, it is the mapping between as_ref and the DID (for that = specific case).

On Wed, Mar 10, 2021 at 6:30 PM Tobias Looker <tobi= as.looker@mattr.global> wrote:
Hi All,

Just my two c= ents, I don't understand why a DID on its own would be regarded as an a= ssertion about the subject. A DID is just an identifier like any other, the= fact the identifier is also resolvable to cryptographic material like publ= ic keys that can be used to validate cryptographic assertions does n= ot make the DID itself an assertion.

On first glan= ce of your proposals Fabien I like the simplicity of option 1, option 2 fee= ls too abstracted.
=
Thanks,
3D"Mattr=C2=A0<= /tr>
Tobias Looker
Mattr
+64 (0)= 27 378 0461
tobias.looker@mattr.global
3D"Mattr3D"Mattr3D"Mattr3D"Mattr

This communication, including any attachments, is c= onfidential. If you are not the intended recipient, you should not read it = - please contact me immediately, destroy it, and do not copy or use any par= t of this communication or disclose anything about it. Thank you. Please no= te that this communication does not designate an information system for the= purposes of the Electronic Transactions Act 2002.
<= /div>

On Wed, Mar 10, 2021 at 10:11 PM Fabien Imbault <fabien.imbault@gmail= .com> wrote:
Hello,

Notice the question mark in = the title. Not to be considered as an editor's comment.
This = thread intends to provide a detailed comment on the interesting=C2=A0feedba= ck by Kristina: "I would catch up on the thread to understand why DIDs= are thought to be treated as assertions".
In the chat, I an= swered: "Happy to get the discussion on DIDs. Actually, could be eithe= r or, depending on what we intend to do." Let me expand a bit on that,= to make it understandable (didn't have the time during the meeting, un= fortunately).

This relates to the items described = on slides 20 and 34, which I'll explain further. I'll highlight as = transparently as possible what I think would be the benefits and downsides = of each. Both are probably viable options, but they correspond to different= scopes and objectives. I'll spend a bit more time on option 2, since i= t is a different approach compared to the current draft.

1. The = first possibility is to use SECEVENT throughout.=C2=A0
In tha= t case, DIDs should be a part of sub_ids (in the core or in the extension r= egistry, depending on what Annabelle's WG decides). More generally, the= WG would have to decide which additional sub_ids it needs (as per Yaron= 9;s comment).

That's obviously the closest to = what is described in draft-04. It allows a communication of subject informa= tion between the client and the AS, by using global identifiers (mail, phon= e, etc.), or using a local opaque reference=C2=A0- i.e. governed by the AS = (that's probably what we would=C2=A0put in the examples, unless someone= has a better idea - cf issues #16 and #42).=C2=A0

Assertions relate for instance to the proof of presence of the RO. The cur= rent draft-04 therefore plans for id_tokens and saml2, maybe there could be= other needs later (extension registry).

- Benefit= s: identifiers are a key component of GNAP, which makes integration easier.= Possibly one could choose to use DIDs throughout.
- Downsides: e= mail/phone identifiers will probably be used throughout by most devs (since= that's correlation information they=C2=A0have in their user DB). Which= means we should limit what assertions contain, to avoid doing links betwee= n weak global identifiers and hopefully stronger assertions. That's not= really a problem if it's limited to authentication events mostly (in t= hat perspective, samlv2 could make sense in the core). An assertion is prob= ably a single value then (not an array).=C2=A0 =C2=A0

<= div>
Option 1 can be summarized as:=C2=A0

"subject": {<= /font>

=C2=A0=C2=A0=C2=A0"sub_ids": { }, // request and response (SECEVENT -> including DID possibl= y)=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=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0"assertions": [ ], =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request and response (id_token or samlv2= )

}

("hints" do not exist currently, but ar= e partially covered separately via "request.user" / the relevance= of "principal", discussed in the slide, is a question mark too -= which is a different discussion on end-user !=3D RO).



2. An alternate possibility is to use SECEVENT only as = input/hint
In that case, DIDs should be a part of assertions = (which have a different meaning compared to option 1).

=
The AS only returns an local opaque reference as_ref (while in option = 1, it was only one of many possibilities). Its only job is to help the clie= nt differentiate the response subject. The AS policy might further define t= he scope of that reference, as suggested in=C2=A0https://g= ithub.com/ietf-wg-gnap/gnap-core-protocol/issues/210, although I person= ally=C2=A0viewed that by default as=C2=A0(2) "as_id" an identifie= r locally unique to that AS for all the RSs.

SECEV= ENTS are still useful as an input, that's what I presented in request.h= ints.self.sub_ids (but it's the responsibility=C2=A0of the AS to match = it with its own reference system - from instance from the email to AS's= local record XUT2MFM1XBIKJKSDU8Q).=C2=A0Note: since the slides, a new draf= t-ietf-secevent-subject-identifiers-07 has been published. Notably this inc= ludes an opaque identifier, which the client can use to pass the as_ref hin= t to the AS. Thus we wouldn't need any further addition to SECEVENT,=C2= =A0although hints would benefit from further additions (like DIDs for insta= nce). Notice also that subject_types_supported becomes less important, beca= use in the worst case scenario, it's simply=C2=A0a hint that wouldn'= ;t be understood and therefore taken into account by the AS.

=
The assertions array has a more important role than in option 1 = (with the explicit aim of separating between client hints and validated inf= o asserted by the AS). It serves as a generic/extendible mapping structure,= e.g. "the AS asserts that opaque reference=C2=A0XUT2MFM1XBIKJKSDU8Q=C2= =A0is matching with these (more or less verifiable) statements." The n= ame assertion therefore corresponds to the responsibility=C2=A0of the AS in= delivering those statements (cf should/must, issue #49). Some of these sta= tements relate to identity or auth events (ex: DID, id_token), some might d= irectly be useful for authorization decisions (like ZKP example in the pare= ntal control example). Possibly some of these validated assertions could be= reused in next interactions.

Another question tha= t popped-up is the scope of sub_ids. Should they be about the same user? (I= think so). In the case of remote ROs especially, it might be important tha= t DID be considered as an assertion=C2=A0(about someone else's) and not= as sub_ids, because the AS needs to be careful about who the client wants = to reach (avoid spam, etc.). This is consistent with the rest of discussion= on what to do when end-user !=3D RO, although using DIDComm might seem a b= it early (the paint is very fresh).=C2=A0

Option 2= was summarized as:=C2=A0

// (suggestion only, not as= an editor)

"subject": {

=C2= =A0=C2=A0=C2=A0"as_ref": { <= /span> // response only (wouldn=E2=80=99t require SECEV= ENT)

=E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2=80= =9D,

=E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIK= JKSDU8QM= =E2=80=9D=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=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"as= sertions": [ ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /= / request and response (id_token/jwkthumb/DID/VC/etc. -> whatever info c= an be validated by the AS)


= =C2=A0=C2=A0=C2=A0"hints": { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request only (optional)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"self": { = // r= eplaces request.user (support SECEVENT here)

=C2=A0=C2=A0=C2=A0=E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque = in draft-07 - that could contain the ref)

= =C2=A0=C2=A0=C2=A0=E2=80=9Cassertions=E2=80=9D: [ ] // see exa= mples: VC on DOB or ZKP on age (wider scope, possibly through extensions) =

},=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=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"principal": = { = // new proposal presented at IETF110 (just an = idea)

=C2=A0 =E2=80= =9Cautomated=E2=80=9D: true, // rule engine

=C2=A0 =E2=80=9Casync=E2=80=9D: { } // remote ROs

}=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=C2=A0=C2=A0}

}


- Benefits: as_ref is self supporting (no strong coup= ling with SECEVENT), but can still take SECEVENT as an input hint for the A= S. It avoids the risk of making an official association between a weak glob= al identifier (e.g. email, used elsewhere) and hopefully stronger local ass= ertions. GNAP would be fully agnostic to whatever identity system is used, = only facilitating interoperability through assertions (second only in impor= tance=C2=A0compared to the AS opaque reference). Some assertions (possibly = extensions) could also be useful for the AS decision (e.g. VC or ZKP).
- Downsides: opaqueness of as_ref is a feature, not a bug. The opaque= reference is fully managed by the AS, therefore not inherently portable (c= f portability discussions in OIDC currently). There's no explicit bindi= ng to an official identity, only a contextual mapping to AS validated asser= tions. It makes it more difficult to match the identifiers from one AS to a= nother or to correlate with the client user DB (still possible via assertio= ns, if the AS allows it). Assertions are much more generic (possibly via ex= tensions), but might require a more advanced mechanism=C2=A0to request/resp= onse only the most relevant information (which makes the AS policy critical= here).

I hope that clarifies the=C2=A0reasoning f= or both options. Again I'm not saying option 2 is better, just saying t= he trade-offs are different (+ knowing that we need to keep it simple).
- option 1 puts more in sub_ids and less in assertions
- o= ption 2 puts less in the reference and more in assertions=C2=A0
A= ll of this is open to discussion. More generally speaking, on every part in= orange and question mark (?) I would love your ideas and criticisms. What = I intended as an editor is only to highlight where the WG has important cho= ices to make, before we can make the related PRs.

= A further side comment: IETF EAT RATS was suggested for assertions, but rel= ates more to the client attestations. It was added as a comment in=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, which is a distinct topic we'll work on.


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

This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.
--0000000000006b41c605bd32467a-- From nobody Wed Mar 10 10:21:28 2021 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 6E0F43A1503 for ; Wed, 10 Mar 2021 10:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, T_REMOTE_IMAGE=0.01, 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 hDBBLz3FDdvI for ; Wed, 10 Mar 2021 10:21:24 -0800 (PST) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 1550F3A1501 for ; Wed, 10 Mar 2021 10:21:24 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id k2so18981303ioh.5 for ; Wed, 10 Mar 2021 10:21:24 -0800 (PST) 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=k4gc5q8QBDucu/ckR2o/MX4rhp6yU3ikY99Vs2pLhcE=; b=DOK09h8Z7P9pbyEeJ/x8IGwfvXE/JQRAQ8Pw7g3a59zWXefz8Bze1OM4TCdOShEMxT MaKwX+gMmvJQKGq7Owk1R89rs9Z8KlhVS7/vVyP/3Kck3NPRWvva+6b2at8WKb4ImRC6 TQUvtFpNCZ73j48I0m984Qbh2jiw5M8wgvYBFnQxEJ/foVzfL+bQu7nqvyXWzya0+5W0 oXp9SxOi4PL2IrRw5O4v8YMmWYvlCA/isJWEui8+aJG5q8VVr0dBa/BMkZ2V3nVuywQk XNNYAHhR/8b6ZEeGUwjLV35+nPtkBae3S5gfUnD0o1XT2mWQ+ECXeVPggM/FsyfqBvu9 qJZw== 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=k4gc5q8QBDucu/ckR2o/MX4rhp6yU3ikY99Vs2pLhcE=; b=TMetKhuP/RXmTI8ybEvzD4hLRB4QysoJXgDcbPUwtokobiivW7A32DkZXVb0aX926/ QAhYQiYQyZmQWZ4EYS6EkJVfGX5xa1jOOPTye/D/c0EjUPp3bt1/FrYX6M3Y4Etriop9 4yANhU0EmC880VO/8kPRLI7ZyB5BRYr1gwLgORpDQpRsrb4JmchWbGL3Ux5HFVZyhOhy o6oIjTmLuunsaXD7dYvaLEEQfLHVwiz4P4pcLfjR3YBH1nbKM4t9f8JGcXeNNIlGSGaE Xo52XBS267jqdfNF6zmRDOjavL6ge0a+QQl1fk5A7XwDCxz5me9GK1VCxwqb9665FtSH 9kRA== X-Gm-Message-State: AOAM533sXIozupQ1jAuP4fow4Jk8Xz+msg0wGZHwSxlG5X5g5OGlsb1W G1H4ZgSMOL1Ga+4zyzqqQEWZRZgE42URb7/YT518gcOFySINBw== X-Google-Smtp-Source: ABdhPJwMqU4i16C0mV6nXYZEYX+ExGy/C0Mo2MyawUpVG78Rsj9sqjD7Jj3vsfKePl+H3ptD5ShklIzbypIJC1MhBnQ= X-Received: by 2002:a5d:8c8f:: with SMTP id g15mr3230740ion.162.1615400481937; Wed, 10 Mar 2021 10:21:21 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Wed, 10 Mar 2021 19:21:10 +0100 Message-ID: To: Tobias Looker Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000e55d8505bd32bb62" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 18:21:27 -0000 --000000000000e55d8505bd32bb62 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi there, A complementary set of questions for option 1 (SECEVENT): - are you happy with the current list of subject identifiers? (i.e. account/email/phone/iss_sub/aliases/opaque) - what else would you need (in the context of GNAP, please indicate if important or nice to have)? - do you agree with having opaque examples in the text? If needed, you can have a look at https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-07 Thanks. Fabien On Wed, Mar 10, 2021 at 6:48 PM Fabien Imbault wrote: > Thanks for the feedback, although I'm not sure what you mean by too > abstract. > Just a quick comment: an assertion in option 2 is not "the fact the > identifier is resolvable to cryptographic material that *can *be used to > validate cryptographic assertions". It is merely a statement by the AS th= at > "the subject corresponding to the reference has a DID" ("has" is the > assertion here). Or said otherwise, it is the mapping between as_ref and > the DID (for that specific case). > > On Wed, Mar 10, 2021 at 6:30 PM Tobias Looker > wrote: > >> Hi All, >> >> Just my two cents, I don't understand why a DID on its own would be >> regarded as an assertion about the subject. A DID is just an identifier >> like any other, the fact the identifier is also resolvable to cryptograp= hic >> material like public keys that *can *be used to validate cryptographic >> assertions does not make the DID itself an assertion. >> >> On first glance of your proposals Fabien I like the simplicity of option >> 1, option 2 feels too abstracted. >> >> Thanks, >> [image: Mattr website] >> *Tobias Looker* >> Mattr >> +64 (0) 27 378 0461 >> tobias.looker@mattr.global >> [image: Mattr website] [image: Mattr on LinkedIn] >> [image: Mattr on Twitter] >> [image: Mattr on Github] >> >> This communication, including any attachments, is confidential. If you >> are not the intended recipient, you should not read it - please contact = me >> immediately, destroy it, and do not copy or use any part of this >> communication or disclose anything about it. Thank you. Please note that >> this communication does not designate an information system for the >> purposes of the Electronic Transactions Act 2002. >> >> >> On Wed, Mar 10, 2021 at 10:11 PM Fabien Imbault >> wrote: >> >>> Hello, >>> >>> Notice the question mark in the title. Not to be considered as an >>> editor's comment. >>> This thread intends to provide a detailed comment on the >>> interesting feedback by Kristina: "I would catch up on the thread to >>> understand why DIDs are thought to be treated as assertions". >>> In the chat, I answered: "Happy to get the discussion on DIDs. Actually= , >>> could be either or, depending on what we intend to do." Let me expand a= bit >>> on that, to make it understandable (didn't have the time during the >>> meeting, unfortunately). >>> >>> This relates to the items described on slides 20 and 34, which I'll >>> explain further. I'll highlight as transparently as possible what I thi= nk >>> would be the benefits and downsides of each. Both are probably viable >>> options, but they correspond to different scopes and objectives. I'll s= pend >>> a bit more time on option 2, since it is a different approach compared = to >>> the current draft. >>> >>> *1. The first possibility is to use SECEVENT throughout. * >>> In that case, DIDs should be a part of sub_ids (in the core or in the >>> extension registry, depending on what Annabelle's WG decides). More >>> generally, the WG would have to decide which additional sub_ids it need= s >>> (as per Yaron's comment). >>> >>> That's obviously the closest to what is described in draft-04. It allow= s >>> a communication of subject information between the client and the AS, b= y >>> using global identifiers (mail, phone, etc.), or using a local opaque >>> reference - i.e. governed by the AS (that's probably what we would put = in >>> the examples, unless someone has a better idea - cf issues #16 and #42)= . >>> >>> Assertions relate for instance to the proof of presence of the RO. The >>> current draft-04 therefore plans for id_tokens and saml2, maybe there c= ould >>> be other needs later (extension registry). >>> >>> - Benefits: identifiers are a key component of GNAP, which makes >>> integration easier. Possibly one could choose to use DIDs throughout. >>> - Downsides: email/phone identifiers will probably be used throughout b= y >>> most devs (since that's correlation information they have in their user >>> DB). Which means we should limit what assertions contain, to avoid doin= g >>> links between weak global identifiers and hopefully stronger assertions= . >>> That's not really a problem if it's limited to authentication events mo= stly >>> (in that perspective, samlv2 could make sense in the core). An assertio= n is >>> probably a single value then (not an array). >>> >>> Option 1 can be summarized as: >>> >>> "subject": { >>> >>> "sub_ids": { }, // request and response (SECEVENT -> including DID >>> possibly) >>> >>> "assertions": [ ], // request and response (id_token o= r >>> samlv2) >>> >>> } >>> >>> ("hints" do not exist currently, but are partially covered separately >>> via "request.user" / the relevance of "principal", discussed in the sli= de, >>> is a question mark too - which is a different discussion on end-user != =3D RO). >>> >>> >>> >>> *2. An alternate possibility is to use SECEVENT only as input/hint* >>> In that case, DIDs should be a part of assertions (which have a >>> different meaning compared to option 1). >>> >>> The AS only returns an local opaque reference as_ref (while in option 1= , >>> it was only one of many possibilities). Its only job is to help the cli= ent >>> differentiate the response subject. The AS policy might further define = the >>> scope of that reference, as suggested in >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210, although >>> I personally viewed that by default as (2) "as_id" an identifier locall= y >>> unique to that AS for all the RSs. >>> >>> SECEVENTS are still useful as an input, that's what I presented in >>> request.hints.self.sub_ids (but it's the responsibility of the AS to ma= tch >>> it with its own reference system - from instance from the email to AS's >>> local record XUT2MFM1XBIKJKSDU8Q). Note: since the slides, a new >>> draft-ietf-secevent-subject-identifiers-07 has been published. Notably = this >>> includes an opaque identifier, which the client can use to pass the as_= ref >>> hint to the AS. Thus we wouldn't need any further addition to >>> SECEVENT, although hints would benefit from further additions (like DID= s >>> for instance). Notice also that subject_types_supported becomes less >>> important, because in the worst case scenario, it's simply a hint that >>> wouldn't be understood and therefore taken into account by the AS. >>> >>> The assertions array has a more important role than in option 1 (with >>> the explicit aim of separating between client hints and validated info >>> asserted by the AS). It serves as a generic/extendible mapping structur= e, >>> e.g. "the AS asserts that opaque reference XUT2MFM1XBIKJKSDU8Q is >>> matching with these (more or less verifiable) statements." The name >>> assertion therefore corresponds to the responsibility of the AS in >>> delivering those statements (cf should/must, issue #49). Some of these >>> statements relate to identity or auth events (ex: DID, id_token), some >>> might directly be useful for authorization decisions (like ZKP example = in >>> the parental control example). Possibly some of these validated asserti= ons >>> could be reused in next interactions. >>> >>> Another question that popped-up is the scope of sub_ids. Should they be >>> about the same user? (I think so). In the case of remote ROs especially= , it >>> might be important that DID be considered as an assertion (about someon= e >>> else's) and not as sub_ids, because the AS needs to be careful about wh= o >>> the client wants to reach (avoid spam, etc.). This is consistent with t= he >>> rest of discussion on what to do when end-user !=3D RO, although using >>> DIDComm might seem a bit early (the paint is very fresh). >>> >>> Option 2 was summarized as: >>> >>> // (suggestion only, not as an editor) >>> >>> "subject": { >>> >>> "as_ref": { // response only (wouldn=E2=80=99t require SECEVENT) >>> >>> =E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D, >>> >>> =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D >>> >>> }, >>> >>> "assertions": [ ], // request and response >>> (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validated by the= AS) >>> >>> "hints": { // request only (optional) >>> >>> "self": { // replaces request.user (support SECEVENT here) >>> >>> =E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque in dra= ft-07 - that >>> could contain the ref) >>> >>> =E2=80=9Cassertions=E2=80=9D: [ ] // see examples: VC on DOB or ZKP = on age (wider >>> scope, possibly through extensions) >>> >>> }, >>> >>> "principal": { // new proposal presented at IETF110 (just an idea= ) >>> >>> =E2=80=9Cautomated=E2=80=9D: true, // rule engine >>> >>> =E2=80=9Casync=E2=80=9D: { } // remote ROs >>> >>> } >>> >>> } >>> >>> } >>> >>> - Benefits: as_ref is self supporting (no strong coupling with >>> SECEVENT), but can still take SECEVENT as an input hint for the AS. It >>> avoids the risk of making an official association between a weak global >>> identifier (e.g. email, used elsewhere) and hopefully stronger local >>> assertions. GNAP would be fully agnostic to whatever identity system is >>> used, only facilitating interoperability through assertions (second onl= y in >>> importance compared to the AS opaque reference). Some assertions (possi= bly >>> extensions) could also be useful for the AS decision (e.g. VC or ZKP). >>> - Downsides: opaqueness of as_ref is a feature, not a bug. The opaque >>> reference is fully managed by the AS, therefore not inherently portable= (cf >>> portability discussions in OIDC currently). There's no explicit binding= to >>> an official identity, only a contextual mapping to AS validated asserti= ons. >>> It makes it more difficult to match the identifiers from one AS to anot= her >>> or to correlate with the client user DB (still possible via assertions,= if >>> the AS allows it). Assertions are much more generic (possibly via >>> extensions), but might require a more advanced mechanism to >>> request/response only the most relevant information (which makes the AS >>> policy critical here). >>> >>> I hope that clarifies the reasoning for both options. Again I'm not >>> saying option 2 is better, just saying the trade-offs are different (+ >>> knowing that we need to keep it simple). >>> - option 1 puts more in sub_ids and less in assertions >>> - option 2 puts less in the reference and more in assertions >>> All of this is open to discussion. More generally speaking, on every >>> part in orange and question mark (?) I would love your ideas and >>> criticisms. What I intended as an editor is only to highlight where the= WG >>> has important choices to make, before we can make the related PRs. >>> >>> A further side comment: IETF EAT RATS was suggested for assertions, but >>> relates more to the client attestations. It was added as a comment in >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, which is >>> a distinct topic we'll work on. >>> >>> Fabien (editor's hat off) >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> >> This communication, including any attachments, is confidential. If you a= re not the intended recipient, you should not read it - please contact me i= mmediately, destroy it, and do not copy or use any part of this communicati= on or disclose anything about it. Thank you. Please note that this communic= ation does not designate an information system for the purposes of the Elec= tronic Transactions Act 2002. >> >> --000000000000e55d8505bd32bb62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi there,=C2=A0

A complementary set of = questions for option 1 (SECEVENT):

- are you happy= with the current list of subject identifiers? (i.e. account/email/phone/is= s_sub/aliases/opaque)
- what else would you need (in the context = of GNAP, please indicate if important or nice to have)?=C2=A0 =C2=A0
<= div>- do you agree with having opaque examples in the text?=C2=A0


Thanks.

Fabien

On Wed, Mar 10, 2021= at 6:48 PM Fabien Imbault <= fabien.imbault@gmail.com> wrote:
Thanks for the feedback, although = I'm not sure what you mean by too abstract.
Just a quick comment: a= n assertion in option 2 is not "the fact the identifier is resolvable = to cryptographic material that=C2=A0can=C2=A0be used to validate cry= ptographic assertions". It is merely a statement by the AS that "= the subject corresponding to the reference has a DID" ("has"= is the assertion here). Or said otherwise, it is the mapping between as_re= f and the DID (for that specific case).

On Wed, Mar 10, 2021 at 6:30 P= M Tobias Looker <tobias.looker@mattr.global> wrote:
Hi All,

=
Just my two cents, I don't understand why a DID on its own w= ould be regarded as an assertion about the subject. A DID is just an identi= fier like any other, the fact the identifier is also resolvable to cryptogr= aphic material like public keys that can be used to validate cryptog= raphic assertions does not make the DID itself an assertion.

=
On first glance of your proposals Fabien I like the simplicity o= f option 1, option 2 feels too abstracted.

Thanks,

This communication, i= ncluding any attachments, is confidential. If you are not the intended reci= pient, you should not read it - please contact me immediately, destroy it, = and do not copy or use any part of this communication or disclose anything = about it. Thank you. Please note that this communication does not designate= an information system for the purposes of the Electronic Transactions Act = 2002.


On Wed, Mar 10, 2021 at 10:11 = PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hello,

Notice the question mark in the title. Not to be considered as an editor&#= 39;s comment.
This thread intends to provide a detailed comment o= n the interesting=C2=A0feedback by Kristina: "I would catch up on the = thread to understand why DIDs are thought to be treated as assertions"= .
In the chat, I answered: "Happy to get the discussion on D= IDs. Actually, could be either or, depending on what we intend to do."= Let me expand a bit on that, to make it understandable (didn't have th= e time during the meeting, unfortunately).

This re= lates to the items described on slides 20 and 34, which I'll explain fu= rther. I'll highlight as transparently as possible what I think would b= e the benefits and downsides of each. Both are probably viable options, but= they correspond to different scopes and objectives. I'll spend a bit m= ore time on option 2, since it is a different approach compared to the curr= ent draft.
1. The first possibility is to use SECEVENT throughou= t.=C2=A0
In that case, DIDs should be a part of sub_ids (in t= he core or in the extension registry, depending on what Annabelle's WG = decides). More generally, the WG would have to decide which additional sub_= ids it needs (as per Yaron's comment).

That= 9;s obviously the closest to what is described in draft-04. It allows a com= munication of subject information between the client and the AS, by using g= lobal identifiers (mail, phone, etc.), or using a local opaque reference=C2= =A0- i.e. governed by the AS (that's probably what we would=C2=A0put in= the examples, unless someone has a better idea - cf issues #16 and #42).= =C2=A0

Assertions relate for instance to the proof= of presence of the RO. The current draft-04 therefore plans for id_tokens = and saml2, maybe there could be other needs later (extension registry).

- Benefits: identifiers are a key component of GNAP, = which makes integration easier. Possibly one could choose to use DIDs throu= ghout.
- Downsides: email/phone identifiers will probably be used= throughout by most devs (since that's correlation information they=C2= =A0have in their user DB). Which means we should limit what assertions cont= ain, to avoid doing links between weak global identifiers and hopefully str= onger assertions. That's not really a problem if it's limited to au= thentication events mostly (in that perspective, samlv2 could make sense in= the core). An assertion is probably a single value then (not an array).=C2= =A0 =C2=A0

Option 1 can be summarized as:=C2= =A0

"subject": {

= = <= span style=3D"white-space:pre-wrap"> <= /span>//= request and response (SECEVENT -> including DID possibly)= =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=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0= =C2=A0"assertions": [ ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 // request and response (id_token or samlv2)

}

("hints" do not exist currently, but are partially cover= ed separately via "request.user" / the relevance of "princip= al", discussed in the slide, is a question mark too - which is a diffe= rent discussion on end-user !=3D RO).



= 2. An alternate possibility is to use SECEVENT only as input/hint
In that case, DIDs should be a part of assertions (which have a dif= ferent meaning compared to option 1).

The AS only = returns an local opaque reference as_ref (while in option 1, it was only on= e of many possibilities). Its only job is to help the client differentiate = the response subject. The AS policy might further define the scope of that = reference, as suggested in=C2=A0https://github.com/ietf-wg= -gnap/gnap-core-protocol/issues/210, although I personally=C2=A0viewed = that by default as=C2=A0(2) "as_id" an identifier locally unique = to that AS for all the RSs.

SECEVENTS are still us= eful as an input, that's what I presented in request.hints.self.sub_ids= (but it's the responsibility=C2=A0of the AS to match it with its own r= eference system - from instance from the email to AS's local record XUT= 2MFM1XBIKJKSDU8Q).=C2=A0Note: since the slides, a new draft-ietf-secevent-s= ubject-identifiers-07 has been published. Notably this includes an opaque i= dentifier, which the client can use to pass the as_ref hint to the AS. Thus= we wouldn't need any further addition to SECEVENT,=C2=A0although hints= would benefit from further additions (like DIDs for instance). Notice also= that subject_types_supported becomes less important, because in the worst = case scenario, it's simply=C2=A0a hint that wouldn't be understood = and therefore taken into account by the AS.

The as= sertions array has a more important role than in option 1 (with the explici= t aim of separating between client hints and validated info asserted by the= AS). It serves as a generic/extendible mapping structure, e.g. "the A= S asserts that opaque reference=C2=A0XUT2MFM1XBIKJKSDU8Q=C2=A0is matching wit= h these (more or less verifiable) statements." The name assertion ther= efore corresponds to the responsibility=C2=A0of the AS in delivering those = statements (cf should/must, issue #49). Some of these statements relate to = identity or auth events (ex: DID, id_token), some might directly be useful = for authorization decisions (like ZKP example in the parental control examp= le). Possibly some of these validated assertions could be reused in next in= teractions.

Another question that popped-up is the= scope of sub_ids. Should they be about the same user? (I think so). In the= case of remote ROs especially, it might be important that DID be considere= d as an assertion=C2=A0(about someone else's) and not as sub_ids, becau= se the AS needs to be careful about who the client wants to reach (avoid sp= am, etc.). This is consistent with the rest of discussion on what to do whe= n end-user !=3D RO, although using DIDComm might seem a bit early (the pain= t is very fresh).=C2=A0

Option 2 was summarized as= :=C2=A0

// (suggestion only= , not as an editor)

"subject": {<= /p>

=C2=A0=C2=A0=C2=A0"as_ref": { <= /span> // response only (wouldn=E2=80=99t requir= e SECEVENT)

=E2=80=9Cas=E2=80=9D: =E2= =80=9Chttps://ex1.as.com=E2=80=9D,

=E2=80=9Cref=E2=80=9D: =E2= =80=9CXU= T2MFM1XBIKJKSDU8QM=E2=80=9D=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=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"assertions": [ ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 // request and response (id_token/jwkthumb/DID/VC/etc. ->= whatever info can be validated by the AS)


=C2=A0=C2=A0=C2=A0"hints": { =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request only= (optional)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"sel= f": { // replaces request.user (support SECEVENT here)

=C2=A0=C2=A0=C2=A0=E2=80=9Csub_ids=E2=80=9D: { },= <= span style=3D"font-family:"Courier New";color:rgb(51,51,51);backg= round-color:rgb(247,247,247);font-variant-numeric:normal;font-variant-east-= asian:normal;vertical-align:baseline;white-space:pre-wrap">// SECEVENT (inc= luding opaque in draft-07 - that could contain the ref)

<= font size=3D"1">=C2=A0=C2=A0=C2=A0=E2=80=9Cassertions=E2=80=9D: [ ] = // see examples: VC on DOB or ZKP on age (wider scope, possibly through= extensions)

},=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=C2=A0= =C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"pr= incipal": { // new proposal presented at IE= TF110 (just an idea)

=C2=A0 =E2=80=9Cautomated=E2=80=9D: true, // rule engine

=C2=A0 =E2=80=9Casync=E2=80=9D: { } // remote ROs

}=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=C2=A0=C2=A0}

}=





Fabien (editor's hat off)

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

This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.
--000000000000e55d8505bd32bb62-- From nobody Wed Mar 10 11:18:22 2021 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 EECC73A1622 for ; Wed, 10 Mar 2021 11:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 IIAhcNo4Lw_D for ; Wed, 10 Mar 2021 11:18:16 -0800 (PST) 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 CE90F3A1621 for ; Wed, 10 Mar 2021 11:18:15 -0800 (PST) Received: from [192.168.1.22] (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 12AJID38026142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Mar 2021 14:18:13 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_7062E67D-0005-480C-8BDD-4E3B8DC62412" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 10 Mar 2021 14:18:13 -0500 In-Reply-To: Cc: GNAP Mailing List To: Fabien Imbault References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 19:18:20 -0000 --Apple-Mail=_7062E67D-0005-480C-8BDD-4E3B8DC62412 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Fabien, First, thanks for doing the heavy lift of writing this topic up. Of = these options, I would strongly prefer option (1). The difference = between assertions and identifiers is that an assertion is a fully = packaged set of attributes, one of which can be an identifier. They are, = generally speaking, cryptographically protected bundles. They=E2=80=99re = designed to carry a bunch of different information about a user and the = authentication event in a form that=E2=80=99s independently verifiable = and auditable. SAML assertions (XML document) and ID Tokens (signed = JWTs) are the most common ones we see today, but other formats exist and = will keep being invented.=20 An identifier is a different kind of creature. It is a single statement = that identifies the party in question in the context of the party doing = the identification. It=E2=80=99s this full context that the receiver of = the identifier needs to interpret it in. When using a federated identity = protocol, each RP is going to have :some: kind of local user information = store that they=E2=80=99re going to tie into, some field in a database = they=E2=80=99ll key off of. It=E2=80=99s just never going to be the case = that all RPs will be able to use server-provided opaque identifiers for = all cases. Account recovery and binding is one such use case where a = user-facing identifier like an email address makes a LOT of sense, for = one small example. This is an array in the request and response = precisely because a user could be known by several different identifiers = to a party, and an RP will have a better idea about what kinds of things = it wants to correlate against, and it=E2=80=99s up to the AS to provide = that mapping. I think that if we don=E2=80=99t define a way to describe = the format, the =E2=80=9Cas_id=E2=80=9D field is going to get structure = back-patched onto it like is being proposed here: https://mattrglobal.github.io/oidc-portable-identities/ = I=E2=80=99m personally not a fan of that approach as it mixes the data = layering too much, and you end up making guesses about whether a field = is meaningful or a pointer. I think GNAP will be much better served by = using a data structure for this from the start. DIDs should be another = =E2=80=9Cformat=E2=80=9D of the subject identifier. I don=E2=80=99t = think GNAP should define this format, and I=E2=80=99ve dropped a note to = the SECEVENT mailing list asking about adding DIDs to the subject = identifiers draft before it gets published. DIDs are not assertions, = even in the cases where they point to fully functional DID documents = with user information in them. (And for what it=E2=80=99s worth, I think = the OIDC world should also use the SECEVENT draft inside ID Tokens to = solve the use case of the draft above). For the user !=3D RO cases, I think that potentially having a way to = signal those two items separately in the request and response could be = useful. Right now all the user/subject stuff is about identifying =E2=80=9C= the user that=E2=80=99s currently here at the client instance=E2=80=9D, = in a variety of forms that the client instance and AS can negotiate. If = the client or AS has some other notion about who the RO is and how that = could be separate from the current user, we could provide a way to = signal that like you=E2=80=99re proposing below. In my mental model, = there are going to be a lot of use cases where the =E2=80=9CRO=E2=80=9D = isn=E2=80=99t known to the client at all, but rather to the AS and is = based on what the client=E2=80=99s asking for. So I could identify the = current user and ask for a specific medical record, and the AS realizes = it has to go bug a particular doctor to approve things directly. This is = instead of interacting with the current user and failing in an awkward = way when the current user doesn=E2=80=99t have the rights to do things, = but someone else would. But we=E2=80=99d want the system to be able to = detect if the current user is the doctor, so we can just interact with = them directly. Does that all track? =E2=80=94 Justin > On Mar 10, 2021, at 4:10 AM, Fabien Imbault = wrote: >=20 > Hello, >=20 > Notice the question mark in the title. Not to be considered as an = editor's comment. > This thread intends to provide a detailed comment on the interesting = feedback by Kristina: "I would catch up on the thread to understand why = DIDs are thought to be treated as assertions". > In the chat, I answered: "Happy to get the discussion on DIDs. = Actually, could be either or, depending on what we intend to do." Let me = expand a bit on that, to make it understandable (didn't have the time = during the meeting, unfortunately). >=20 > This relates to the items described on slides 20 and 34, which I'll = explain further. I'll highlight as transparently as possible what I = think would be the benefits and downsides of each. Both are probably = viable options, but they correspond to different scopes and objectives. = I'll spend a bit more time on option 2, since it is a different approach = compared to the current draft. >=20 > 1. The first possibility is to use SECEVENT throughout.=20 > In that case, DIDs should be a part of sub_ids (in the core or in the = extension registry, depending on what Annabelle's WG decides). More = generally, the WG would have to decide which additional sub_ids it needs = (as per Yaron's comment). >=20 > That's obviously the closest to what is described in draft-04. It = allows a communication of subject information between the client and the = AS, by using global identifiers (mail, phone, etc.), or using a local = opaque reference - i.e. governed by the AS (that's probably what we = would put in the examples, unless someone has a better idea - cf issues = #16 and #42).=20 >=20 > Assertions relate for instance to the proof of presence of the RO. The = current draft-04 therefore plans for id_tokens and saml2, maybe there = could be other needs later (extension registry). >=20 > - Benefits: identifiers are a key component of GNAP, which makes = integration easier. Possibly one could choose to use DIDs throughout. > - Downsides: email/phone identifiers will probably be used throughout = by most devs (since that's correlation information they have in their = user DB). Which means we should limit what assertions contain, to avoid = doing links between weak global identifiers and hopefully stronger = assertions. That's not really a problem if it's limited to = authentication events mostly (in that perspective, samlv2 could make = sense in the core). An assertion is probably a single value then (not an = array). =20 >=20 > Option 1 can be summarized as:=20 >=20 > "subject": { > "sub_ids": { }, // request and response = (SECEVENT -> including DID possibly) =20 > "assertions": [ ], // request and response = (id_token or samlv2) > } > ("hints" do not exist currently, but are partially covered separately = via "request.user" / the relevance of "principal", discussed in the = slide, is a question mark too - which is a different discussion on = end-user !=3D RO). >=20 >=20 > 2. An alternate possibility is to use SECEVENT only as input/hint > In that case, DIDs should be a part of assertions (which have a = different meaning compared to option 1). >=20 > The AS only returns an local opaque reference as_ref (while in option = 1, it was only one of many possibilities). Its only job is to help the = client differentiate the response subject. The AS policy might further = define the scope of that reference, as suggested in = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210 = , = although I personally viewed that by default as (2) "as_id" an = identifier locally unique to that AS for all the RSs. >=20 > SECEVENTS are still useful as an input, that's what I presented in = request.hints.self.sub_ids (but it's the responsibility of the AS to = match it with its own reference system - from instance from the email to = AS's local record XUT2MFM1XBIKJKSDU8Q). Note: since the slides, a new = draft-ietf-secevent-subject-identifiers-07 has been published. Notably = this includes an opaque identifier, which the client can use to pass the = as_ref hint to the AS. Thus we wouldn't need any further addition to = SECEVENT, although hints would benefit from further additions (like DIDs = for instance). Notice also that subject_types_supported becomes less = important, because in the worst case scenario, it's simply a hint that = wouldn't be understood and therefore taken into account by the AS. >=20 > The assertions array has a more important role than in option 1 (with = the explicit aim of separating between client hints and validated info = asserted by the AS). It serves as a generic/extendible mapping = structure, e.g. "the AS asserts that opaque reference = XUT2MFM1XBIKJKSDU8Q is matching with these (more or less verifiable) = statements." The name assertion therefore corresponds to the = responsibility of the AS in delivering those statements (cf should/must, = issue #49). Some of these statements relate to identity or auth events = (ex: DID, id_token), some might directly be useful for authorization = decisions (like ZKP example in the parental control example). Possibly = some of these validated assertions could be reused in next interactions. >=20 > Another question that popped-up is the scope of sub_ids. Should they = be about the same user? (I think so). In the case of remote ROs = especially, it might be important that DID be considered as an assertion = (about someone else's) and not as sub_ids, because the AS needs to be = careful about who the client wants to reach (avoid spam, etc.). This is = consistent with the rest of discussion on what to do when end-user !=3D = RO, although using DIDComm might seem a bit early (the paint is very = fresh).=20 >=20 > Option 2 was summarized as:=20 >=20 > // (suggestion only, not as an editor) > "subject": { > "as_ref": { // response only = (wouldn=E2=80=99t require SECEVENT) > =E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com = =E2=80=9D, =09 > =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D =20 > }, =20 > "assertions": [ ], // request and response = (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validated by the = AS) >=20 > "hints": { // request only (optional) > "self": { // replaces request.user = (support SECEVENT here) > =E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including = opaque in draft-07 - that could contain the ref) > =E2=80=9Cassertions=E2=80=9D: [ ] // see examples: VC on = DOB or ZKP on age (wider scope, possibly through extensions) =20 > }, =20 > "principal": { // new proposal presented at = IETF110 (just an idea) > =E2=80=9Cautomated=E2=80=9D: true, // rule engine =09= > =E2=80=9Casync=E2=80=9D: { } // remote ROs > } =20 > } > } >=20 > - Benefits: as_ref is self supporting (no strong coupling with = SECEVENT), but can still take SECEVENT as an input hint for the AS. It = avoids the risk of making an official association between a weak global = identifier (e.g. email, used elsewhere) and hopefully stronger local = assertions. GNAP would be fully agnostic to whatever identity system is = used, only facilitating interoperability through assertions (second only = in importance compared to the AS opaque reference). Some assertions = (possibly extensions) could also be useful for the AS decision (e.g. VC = or ZKP). > - Downsides: opaqueness of as_ref is a feature, not a bug. The opaque = reference is fully managed by the AS, therefore not inherently portable = (cf portability discussions in OIDC currently). There's no explicit = binding to an official identity, only a contextual mapping to AS = validated assertions. It makes it more difficult to match the = identifiers from one AS to another or to correlate with the client user = DB (still possible via assertions, if the AS allows it). Assertions are = much more generic (possibly via extensions), but might require a more = advanced mechanism to request/response only the most relevant = information (which makes the AS policy critical here). >=20 > I hope that clarifies the reasoning for both options. Again I'm not = saying option 2 is better, just saying the trade-offs are different (+ = knowing that we need to keep it simple). > - option 1 puts more in sub_ids and less in assertions > - option 2 puts less in the reference and more in assertions=20 > All of this is open to discussion. More generally speaking, on every = part in orange and question mark (?) I would love your ideas and = criticisms. What I intended as an editor is only to highlight where the = WG has important choices to make, before we can make the related PRs. >=20 > A further side comment: IETF EAT RATS was suggested for assertions, = but relates more to the client attestations. It was added as a comment = in https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44 = , which is = a distinct topic we'll work on. >=20 > Fabien (editor's hat off) >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_7062E67D-0005-480C-8BDD-4E3B8DC62412 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Fabien,

First, = thanks for doing the heavy lift of writing this topic up. Of these = options, I would strongly prefer option (1). The difference between = assertions and identifiers is that an assertion is a fully packaged set = of attributes, one of which can be an identifier. They are, generally = speaking, cryptographically protected bundles. They=E2=80=99re designed = to carry a bunch of different information about a user and the = authentication event in a form that=E2=80=99s independently verifiable = and auditable. SAML assertions (XML document) and ID Tokens (signed = JWTs) are the most common ones we see today, but other formats exist and = will keep being invented. 

An identifier is a different kind of = creature. It is a single statement that identifies the party in question = in the context of the party doing the identification. It=E2=80=99s this = full context that the receiver of the identifier needs to interpret it = in. When using a federated identity protocol, each RP is going to have = :some: kind of local user information store that they=E2=80=99re going = to tie into, some field in a database they=E2=80=99ll key off of. It=E2=80= =99s just never going to be the case that all RPs will be able to use = server-provided opaque identifiers for all cases. Account recovery and = binding is one such use case where a user-facing identifier like an = email address makes a LOT of sense, for one small example. This is an = array in the request and response precisely because a user could be = known by several different identifiers to a party, and an RP will have a = better idea about what kinds of things it wants to correlate against, = and it=E2=80=99s up to the AS to provide that mapping. I think that if = we don=E2=80=99t define a way to describe the format, the =E2=80=9Cas_id=E2= =80=9D field is going to get structure back-patched onto it like is = being proposed here:

https://mattrglobal.github.io/oidc-portable-identities/

I=E2=80=99m = personally not a fan of that approach as it mixes the data layering too = much, and you end up making guesses about whether a field is meaningful = or a pointer. I think GNAP will be much better served by using a data = structure for this from the start. DIDs should be another =E2=80=9Cformat=E2= =80=9D of the subject identifier. I don=E2=80=99t think GNAP should = define this format, and I=E2=80=99ve dropped a note to the SECEVENT = mailing list asking about adding DIDs to the subject identifiers draft = before it gets published. DIDs are not assertions, even in the cases = where they point to fully functional DID documents with user information = in them. (And for what it=E2=80=99s worth, I think the OIDC world should = also use the SECEVENT draft inside ID Tokens to solve the use case of = the draft above).

For the user !=3D RO cases, I think that potentially having a = way to signal those two items separately in the request and response = could be useful. Right now all the user/subject stuff is about = identifying =E2=80=9Cthe user that=E2=80=99s currently here at the = client instance=E2=80=9D, in a variety of forms that the client instance = and AS can negotiate. If the client or AS has some other notion about = who the RO is and how that could be separate from the current user, we = could provide a way to signal that like you=E2=80=99re proposing below. = In my mental model, there are going to be a lot of use cases where the = =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the client at all, but = rather to the AS and is based on what the client=E2=80=99s asking for. = So I could identify the current user and ask for a specific medical = record, and the AS realizes it has to go bug a particular doctor to = approve things directly. This is instead of interacting with the current = user and failing in an awkward way when the current user doesn=E2=80=99t = have the rights to do things, but someone else would. But we=E2=80=99d = want the system to be able to detect if the current user is the doctor, = so we can just interact with them directly. Does that all = track?

 =E2= =80=94 Justin

On Mar 10, 2021, at 4:10 AM, = Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hello,

Notice the question mark in the title. = Not to be considered as an editor's comment.
This = thread intends to provide a detailed comment on the = interesting feedback by Kristina: "I would catch up on the thread = to understand why DIDs are thought to be treated as = assertions".
In the chat, I answered: "Happy to get = the discussion on DIDs. Actually, could be either or, depending on what = we intend to do." Let me expand a bit on that, to make it understandable = (didn't have the time during the meeting, unfortunately).

This relates to the = items described on slides 20 and 34, which I'll explain further. I'll = highlight as transparently as possible what I think would be the = benefits and downsides of each. Both are probably viable options, but = they correspond to different scopes and objectives. I'll spend a bit = more time on option 2, since it is a different approach compared to the = current draft.

1. The first = possibility is to use SECEVENT throughout. 
In that case, DIDs should be a part of sub_ids (in the core = or in the extension registry, depending on what Annabelle's WG decides). = More generally, the WG would have to decide which additional sub_ids it = needs (as per Yaron's comment).

That's obviously the closest to what is = described in draft-04. It allows a communication of subject information = between the client and the AS, by using global identifiers (mail, phone, = etc.), or using a local opaque reference - i.e. governed by the AS = (that's probably what we would put in the examples, unless someone = has a better idea - cf issues #16 and #42). 
Assertions relate for instance to the = proof of presence of the RO. The current draft-04 therefore plans for = id_tokens and saml2, maybe there could be other needs later (extension = registry).

- = Benefits: identifiers are a key component of GNAP, which makes = integration easier. Possibly one could choose to use DIDs = throughout.
- Downsides: email/phone identifiers = will probably be used throughout by most devs (since that's correlation = information they have in their user DB). Which means we should = limit what assertions contain, to avoid doing links between weak global = identifiers and hopefully stronger assertions. That's not really a = problem if it's limited to authentication events mostly (in that = perspective, samlv2 could make sense in the core). An assertion is = probably a single value then (not an array).   

Option 1 = can be summarized as: 

"subject": = {
   "sub_ids": { = }, // request and response (SECEVENT -> = including DID possibly)          &nb= sp;        
   "assertions": [ ],       =         // request and response (id_token or = samlv2)
}
("hints" do not exist = currently, but are partially covered separately via "request.user" / the = relevance of "principal", discussed in the slide, is a question mark too = - which is a different discussion on end-user !=3D RO).


2. An alternate = possibility is to use SECEVENT only as input/hint
In that case, DIDs should be a part of assertions (which have = a different meaning compared to option 1).

The AS only returns an local opaque = reference as_ref (while in option 1, it was only one of many = possibilities). Its only job is to help the client differentiate the = response subject. The AS policy might further define the scope of that = reference, as suggested in https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210, although I personally viewed that by default as (2) = "as_id" an identifier locally unique to that AS for all the = RSs.

SECEVENTS = are still useful as an input, that's what I presented in = request.hints.self.sub_ids (but it's the responsibility of the AS = to match it with its own reference system - from instance from the email = to AS's local record XUT2MFM1XBIKJKSDU8Q). Note: since the slides, = a new draft-ietf-secevent-subject-identifiers-07 has been published. = Notably this includes an opaque identifier, which the client can use to = pass the as_ref hint to the AS. Thus we wouldn't need any further = addition to SECEVENT, although hints would benefit from further = additions (like DIDs for instance). Notice also that = subject_types_supported becomes less important, because in the worst = case scenario, it's simply a hint that wouldn't be understood and = therefore taken into account by the AS.

The assertions array has a more = important role than in option 1 (with the explicit aim of separating = between client hints and validated info asserted by the AS). It serves = as a generic/extendible mapping structure, e.g. "the AS asserts that = opaque reference XUT2MFM1XBIKJKSDU8Q is matching with these (more = or less verifiable) statements." The name assertion therefore = corresponds to the responsibility of the AS in delivering those = statements (cf should/must, issue #49). Some of these statements relate = to identity or auth events (ex: DID, id_token), some might directly be = useful for authorization decisions (like ZKP example in the parental = control example). Possibly some of these validated assertions could be = reused in next interactions.

Another question that popped-up is the = scope of sub_ids. Should they be about the same user? (I think so). In = the case of remote ROs especially, it might be important that DID be = considered as an assertion (about someone else's) and not as = sub_ids, because the AS needs to be careful about who the client wants = to reach (avoid spam, etc.). This is consistent with the rest of = discussion on what to do when end-user !=3D RO, although using DIDComm = might seem a bit early (the paint is very fresh). 

Option 2 was summarized = as: 

// (suggestion only, not as an = editor)
"subject": = {
   "as_ref": { = // response only (wouldn=E2=80=99t = require SECEVENT)
=E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D,
=E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D   
   },       &= nbsp;           
   "assertions": [ ],       =         // request and response = (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validated by = the AS)

   "hints": {         =               // request only = (optional)
      "self": { // replaces request.user (support = SECEVENT here)
   =E2=80=9Csub_ids=E2=80=9D= : { }, // SECEVENT (including opaque in = draft-07 - that could contain the ref)
   =E2=80=9Cassertions=E2=80=9D: [ ] = // see examples: VC on DOB or ZKP on age (wider scope, possibly through = extensions)
},          &= nbsp;       
      "principal": = { // new proposal presented at IETF110 = (just an idea)
  =E2=80=9Cautomated=E2=80=9D: = true, // rule engine
  =E2=80=9Casync=E2=80=9D: { = } // remote ROs
}          &n= bsp;   
   }
}

- Benefits: as_ref is self supporting = (no strong coupling with SECEVENT), but can still take SECEVENT as an = input hint for the AS. It avoids the risk of making an official = association between a weak global identifier (e.g. email, used = elsewhere) and hopefully stronger local assertions. GNAP would be fully = agnostic to whatever identity system is used, only facilitating = interoperability through assertions (second only in = importance compared to the AS opaque reference). Some assertions = (possibly extensions) could also be useful for the AS decision (e.g. VC = or ZKP).
- Downsides: opaqueness of as_ref is a = feature, not a bug. The opaque reference is fully managed by the AS, = therefore not inherently portable (cf portability discussions in OIDC = currently). There's no explicit binding to an official identity, only a = contextual mapping to AS validated assertions. It makes it more = difficult to match the identifiers from one AS to another or to = correlate with the client user DB (still possible via assertions, if the = AS allows it). Assertions are much more generic (possibly via = extensions), but might require a more advanced mechanism to = request/response only the most relevant information (which makes the AS = policy critical here).

I hope that clarifies the reasoning for both options. = Again I'm not saying option 2 is better, just saying the trade-offs are = different (+ knowing that we need to keep it simple).
- option 1 puts more in sub_ids and less in = assertions
- option 2 puts less in the reference = and more in assertions 
All of this is open to = discussion. More generally speaking, on every part in orange and = question mark (?) I would love your ideas and criticisms. What I = intended as an editor is only to highlight where the WG has important = choices to make, before we can make the related PRs.

A further side comment: = IETF EAT RATS was suggested for assertions, but relates more to the = client attestations. It was added as a comment in https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, which is a distinct topic we'll work on.

Fabien (editor's hat off)

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

= --Apple-Mail=_7062E67D-0005-480C-8BDD-4E3B8DC62412-- From nobody Wed Mar 10 12:20:01 2021 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 9B5013A174E for ; Wed, 10 Mar 2021 12:19:59 -0800 (PST) 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 NgwEWRrmv0nf for ; Wed, 10 Mar 2021 12:19:56 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 2C8303A174F for ; Wed, 10 Mar 2021 12:19:56 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id o9so19379445iow.6 for ; Wed, 10 Mar 2021 12:19:56 -0800 (PST) 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=ION8MbFyO7iKu1RzCRXJqycvG6ffdj5CQsHuyRIPkwU=; b=Ep9bFsNcGh/gOjXV+1vb5YezzLOMNrFtlxVQApydxxB7TfbJNZ6UPqH0YmGH+c6619 21abfKtFEOVLhD4SN/YpGeHDcLfjhwwVdhWwi8R2mbWr1nIRZZVDrJByEwWsFZlrHYgZ gLMwNj1kTC5S6pU/JvyqmstGsD69wXoym1GhySKJ/7lq8my8p5ALAZ82RW0H/J1XOVrO 7Jw9iL6XjCmXK81pJNnQEh692+BvCj6CMeFrxCwmK4tdwkxt0mf47itWmIOs00cR0M0A 10nzzTLDL5Wi/uhzLat/4TBIIWqxYL7C/AGWVX51AHYl/6srjG/Yesz5cN896sDlYfGy KRYg== 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=ION8MbFyO7iKu1RzCRXJqycvG6ffdj5CQsHuyRIPkwU=; b=opjNbYxcBRSoCIVTKkR3SwImFbbIW1IxOF657rfbNMEaskDInieY6IbQy2LGhy36p+ sRE0pAKEHOikucV7vxLN/DvMwCBD46MUyRgtXDLe7Mm+KperzJCbZZ4bHAqboHHkebQa DqcxpLUE0+l0LBMdtHbanW29zhi2rrg/SdH1ToAluTLWjNKXLKTIUp8oEsQWdpJPchvy vASpqVe1NQS8d4Cg/n742rn7Sga9ETM7v6QZnlcvSfBLEkha6/1VJgzXfX7ABAzZC+3n rcWkD7SxbnivnB2iidF//TyfXI5eVWtEq4fxbmqXAg0tSge75ukgOc84Hz3PUI7Hqlsu NXyQ== X-Gm-Message-State: AOAM530AqZYklIb2LrLoZBJTs/E8DIjvjtQ4BYQ+H5xwN6rM9i7ajE6A 4x4ofHnwLXlG4w1xldxWUkzrwLic0DMJt1fA0Ac= X-Google-Smtp-Source: ABdhPJwMJSCXDaOzV0Iizjp+W8KVURew2slPPB1y+zd8DKjBOn5q7CvzI3k5iYJgOqSrzgtRVUQQ9Ar2ISjn1DsyEdE= X-Received: by 2002:a02:ca13:: with SMTP id i19mr217289jak.47.1615407594477; Wed, 10 Mar 2021 12:19:54 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Wed, 10 Mar 2021 21:19:42 +0100 Message-ID: To: Justin Richer Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000d61c1705bd3463e1" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 20:20:00 -0000 --000000000000d61c1705bd3463e1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Justin. It's good to clarify what we mean by assertion. I used a more mundane meaning. I dislike email/phone as security disasters waiting to happen. I get that they are practical. I think I have what I need to write the PRs based on sub_ids (based on the current draft-07). Fabien Le mer. 10 mars 2021 =C3=A0 20:18, Justin Richer a =C3=A9= crit : > Hi Fabien, > > First, thanks for doing the heavy lift of writing this topic up. Of these > options, I would strongly prefer option (1). The difference between > assertions and identifiers is that an assertion is a fully packaged set o= f > attributes, one of which can be an identifier. They are, generally > speaking, cryptographically protected bundles. They=E2=80=99re designed t= o carry a > bunch of different information about a user and the authentication event = in > a form that=E2=80=99s independently verifiable and auditable. SAML assert= ions (XML > document) and ID Tokens (signed JWTs) are the most common ones we see > today, but other formats exist and will keep being invented. > > An identifier is a different kind of creature. It is a single statement > that identifies the party in question in the context of the party doing t= he > identification. It=E2=80=99s this full context that the receiver of the i= dentifier > needs to interpret it in. When using a federated identity protocol, each = RP > is going to have :some: kind of local user information store that they=E2= =80=99re > going to tie into, some field in a database they=E2=80=99ll key off of. I= t=E2=80=99s just > never going to be the case that all RPs will be able to use server-provid= ed > opaque identifiers for all cases. Account recovery and binding is one suc= h > use case where a user-facing identifier like an email address makes a LOT > of sense, for one small example. This is an array in the request and > response precisely because a user could be known by several different > identifiers to a party, and an RP will have a better idea about what kind= s > of things it wants to correlate against, and it=E2=80=99s up to the AS to= provide > that mapping. I think that if we don=E2=80=99t define a way to describe t= he format, > the =E2=80=9Cas_id=E2=80=9D field is going to get structure back-patched = onto it like is > being proposed here: > > https://mattrglobal.github.io/oidc-portable-identities/ > > I=E2=80=99m personally not a fan of that approach as it mixes the data la= yering > too much, and you end up making guesses about whether a field is meaningf= ul > or a pointer. I think GNAP will be much better served by using a data > structure for this from the start. DIDs should be another =E2=80=9Cformat= =E2=80=9D of the > subject identifier. I don=E2=80=99t think GNAP should define this format,= and I=E2=80=99ve > dropped a note to the SECEVENT mailing list asking about adding DIDs to t= he > subject identifiers draft before it gets published. DIDs are not > assertions, even in the cases where they point to fully functional DID > documents with user information in them. (And for what it=E2=80=99s worth= , I think > the OIDC world should also use the SECEVENT draft inside ID Tokens to sol= ve > the use case of the draft above). > > For the user !=3D RO cases, I think that potentially having a way to sign= al > those two items separately in the request and response could be useful. > Right now all the user/subject stuff is about identifying =E2=80=9Cthe us= er that=E2=80=99s > currently here at the client instance=E2=80=9D, in a variety of forms tha= t the > client instance and AS can negotiate. If the client or AS has some other > notion about who the RO is and how that could be separate from the curren= t > user, we could provide a way to signal that like you=E2=80=99re proposing= below. In > my mental model, there are going to be a lot of use cases where the =E2= =80=9CRO=E2=80=9D > isn=E2=80=99t known to the client at all, but rather to the AS and is bas= ed on what > the client=E2=80=99s asking for. So I could identify the current user and= ask for a > specific medical record, and the AS realizes it has to go bug a particula= r > doctor to approve things directly. This is instead of interacting with th= e > current user and failing in an awkward way when the current user doesn=E2= =80=99t > have the rights to do things, but someone else would. But we=E2=80=99d wa= nt the > system to be able to detect if the current user is the doctor, so we can > just interact with them directly. Does that all track? > > =E2=80=94 Justin > > On Mar 10, 2021, at 4:10 AM, Fabien Imbault > wrote: > > Hello, > > Notice the question mark in the title. Not to be considered as an editor'= s > comment. > This thread intends to provide a detailed comment on the > interesting feedback by Kristina: "I would catch up on the thread to > understand why DIDs are thought to be treated as assertions". > In the chat, I answered: "Happy to get the discussion on DIDs. Actually, > could be either or, depending on what we intend to do." Let me expand a b= it > on that, to make it understandable (didn't have the time during the > meeting, unfortunately). > > This relates to the items described on slides 20 and 34, which I'll > explain further. I'll highlight as transparently as possible what I think > would be the benefits and downsides of each. Both are probably viable > options, but they correspond to different scopes and objectives. I'll spe= nd > a bit more time on option 2, since it is a different approach compared to > the current draft. > > *1. The first possibility is to use SECEVENT throughout. * > In that case, DIDs should be a part of sub_ids (in the core or in the > extension registry, depending on what Annabelle's WG decides). More > generally, the WG would have to decide which additional sub_ids it needs > (as per Yaron's comment). > > That's obviously the closest to what is described in draft-04. It allows = a > communication of subject information between the client and the AS, by > using global identifiers (mail, phone, etc.), or using a local opaque > reference - i.e. governed by the AS (that's probably what we would put in > the examples, unless someone has a better idea - cf issues #16 and #42). > > Assertions relate for instance to the proof of presence of the RO. The > current draft-04 therefore plans for id_tokens and saml2, maybe there cou= ld > be other needs later (extension registry). > > - Benefits: identifiers are a key component of GNAP, which makes > integration easier. Possibly one could choose to use DIDs throughout. > - Downsides: email/phone identifiers will probably be used throughout by > most devs (since that's correlation information they have in their user > DB). Which means we should limit what assertions contain, to avoid doing > links between weak global identifiers and hopefully stronger assertions. > That's not really a problem if it's limited to authentication events most= ly > (in that perspective, samlv2 could make sense in the core). An assertion = is > probably a single value then (not an array). > > Option 1 can be summarized as: > > "subject": { > "sub_ids": { }, // request and response (SECEVENT -> including DID > possibly) > "assertions": [ ], // request and response (id_token or > samlv2) > } > ("hints" do not exist currently, but are partially covered separately via > "request.user" / the relevance of "principal", discussed in the slide, is= a > question mark too - which is a different discussion on end-user !=3D RO). > > > *2. An alternate possibility is to use SECEVENT only as input/hint* > In that case, DIDs should be a part of assertions (which have a different > meaning compared to option 1). > > The AS only returns an local opaque reference as_ref (while in option 1, > it was only one of many possibilities). Its only job is to help the clien= t > differentiate the response subject. The AS policy might further define th= e > scope of that reference, as suggested in > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210, although I > personally viewed that by default as (2) "as_id" an identifier locally > unique to that AS for all the RSs. > > SECEVENTS are still useful as an input, that's what I presented in > request.hints.self.sub_ids (but it's the responsibility of the AS to matc= h > it with its own reference system - from instance from the email to AS's > local record XUT2MFM1XBIKJKSDU8Q). Note: since the slides, a new > draft-ietf-secevent-subject-identifiers-07 has been published. Notably th= is > includes an opaque identifier, which the client can use to pass the as_re= f > hint to the AS. Thus we wouldn't need any further addition to > SECEVENT, although hints would benefit from further additions (like DIDs > for instance). Notice also that subject_types_supported becomes less > important, because in the worst case scenario, it's simply a hint that > wouldn't be understood and therefore taken into account by the AS. > > The assertions array has a more important role than in option 1 (with the > explicit aim of separating between client hints and validated info assert= ed > by the AS). It serves as a generic/extendible mapping structure, e.g. "th= e > AS asserts that opaque reference XUT2MFM1XBIKJKSDU8Q is matching with > these (more or less verifiable) statements." The name assertion therefore > corresponds to the responsibility of the AS in delivering those statement= s > (cf should/must, issue #49). Some of these statements relate to identity = or > auth events (ex: DID, id_token), some might directly be useful for > authorization decisions (like ZKP example in the parental control example= ). > Possibly some of these validated assertions could be reused in next > interactions. > > Another question that popped-up is the scope of sub_ids. Should they be > about the same user? (I think so). In the case of remote ROs especially, = it > might be important that DID be considered as an assertion (about someone > else's) and not as sub_ids, because the AS needs to be careful about who > the client wants to reach (avoid spam, etc.). This is consistent with the > rest of discussion on what to do when end-user !=3D RO, although using > DIDComm might seem a bit early (the paint is very fresh). > > Option 2 was summarized as: > > // (suggestion only, not as an editor) > "subject": { > "as_ref": { // response only (wouldn=E2=80=99t require SECEVENT) > =E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D, > =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D > }, > "assertions": [ ], // request and response > (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validated by the A= S) > > "hints": { // request only (optional) > "self": { // replaces request.user (support SECEVENT here) > =E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque in draft= -07 - that could > contain the ref) > =E2=80=9Cassertions=E2=80=9D: [ ] // see examples: VC on DOB or ZKP on= age (wider > scope, possibly through extensions) > }, > "principal": { // new proposal presented at IETF110 (just an idea) > =E2=80=9Cautomated=E2=80=9D: true, // rule engine > =E2=80=9Casync=E2=80=9D: { } // remote ROs > } > } > } > > - Benefits: as_ref is self supporting (no strong coupling with SECEVENT), > but can still take SECEVENT as an input hint for the AS. It avoids the ri= sk > of making an official association between a weak global identifier (e.g. > email, used elsewhere) and hopefully stronger local assertions. GNAP woul= d > be fully agnostic to whatever identity system is used, only facilitating > interoperability through assertions (second only in importance compared t= o > the AS opaque reference). Some assertions (possibly extensions) could als= o > be useful for the AS decision (e.g. VC or ZKP). > - Downsides: opaqueness of as_ref is a feature, not a bug. The opaque > reference is fully managed by the AS, therefore not inherently portable (= cf > portability discussions in OIDC currently). There's no explicit binding t= o > an official identity, only a contextual mapping to AS validated assertion= s. > It makes it more difficult to match the identifiers from one AS to anothe= r > or to correlate with the client user DB (still possible via assertions, i= f > the AS allows it). Assertions are much more generic (possibly via > extensions), but might require a more advanced mechanism to > request/response only the most relevant information (which makes the AS > policy critical here). > > I hope that clarifies the reasoning for both options. Again I'm not sayin= g > option 2 is better, just saying the trade-offs are different (+ knowing > that we need to keep it simple). > - option 1 puts more in sub_ids and less in assertions > - option 2 puts less in the reference and more in assertions > All of this is open to discussion. More generally speaking, on every part > in orange and question mark (?) I would love your ideas and criticisms. > What I intended as an editor is only to highlight where the WG has > important choices to make, before we can make the related PRs. > > A further side comment: IETF EAT RATS was suggested for assertions, but > relates more to the client attestations. It was added as a comment in > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, which is a > distinct topic we'll work on. > > Fabien (editor's hat off) > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > > --000000000000d61c1705bd3463e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Justin.

It's good to clarify what we mean by assertion. I used a more mundan= e meaning.=C2=A0

I disli= ke email/phone as security disasters waiting to happen. I get that they are= practical.=C2=A0

I thin= k I have what I need to write the PRs based on sub_ids (based on the curren= t draft-07).=C2=A0

Fabie= n=C2=A0

Le mer. 10 mars 2021 =C3=A0 20:18, Justin Richer <jricher@mit.edu> a =C3=A9crit=C2=A0:
Hi Fabien,

First, thanks for doing the h= eavy lift of writing this topic up. Of these options, I would strongly pref= er option (1). The difference between assertions and identifiers is that an= assertion is a fully packaged set of attributes, one of which can be an id= entifier. They are, generally speaking, cryptographically protected bundles= . They=E2=80=99re designed to carry a bunch of different information about = a user and the authentication event in a form that=E2=80=99s independently = verifiable and auditable. SAML assertions (XML document) and ID Tokens (sig= ned JWTs) are the most common ones we see today, but other formats exist an= d will keep being invented.=C2=A0

An identifier is= a different kind of creature. It is a single statement that identifies the= party in question in the context of the party doing the identification. It= =E2=80=99s this full context that the receiver of the identifier needs to i= nterpret it in. When using a federated identity protocol, each RP is going = to have :some: kind of local user information store that they=E2=80=99re go= ing to tie into, some field in a database they=E2=80=99ll key off of. It=E2= =80=99s just never going to be the case that all RPs will be able to use se= rver-provided opaque identifiers for all cases. Account recovery and bindin= g is one such use case where a user-facing identifier like an email address= makes a LOT of sense, for one small example. This is an array in the reque= st and response precisely because a user could be known by several differen= t identifiers to a party, and an RP will have a better idea about what kind= s of things it wants to correlate against, and it=E2=80=99s up to the AS to= provide that mapping. I think that if we don=E2=80=99t define a way to des= cribe the format, the =E2=80=9Cas_id=E2=80=9D field is going to get structu= re back-patched onto it like is being proposed here:

https://= mattrglobal.github.io/oidc-portable-identities/

I=E2=80=99m personally not a fan of that approach as it mixes the data la= yering too much, and you end up making guesses about whether a field is mea= ningful or a pointer. I think GNAP will be much better served by using a da= ta structure for this from the start. DIDs should be another =E2=80=9Cforma= t=E2=80=9D of the subject identifier. I don=E2=80=99t think GNAP should def= ine this format, and I=E2=80=99ve dropped a note to the SECEVENT mailing li= st asking about adding DIDs to the subject identifiers draft before it gets= published. DIDs are not assertions, even in the cases where they point to = fully functional DID documents with user information in them. (And for what= it=E2=80=99s worth, I think the OIDC world should also use the SECEVENT dr= aft inside ID Tokens to solve the use case of the draft above).
<= br>
For the user !=3D RO cases, I think that potentially having a= way to signal those two items separately in the request and response could= be useful. Right now all the user/subject stuff is about identifying =E2= =80=9Cthe user that=E2=80=99s currently here at the client instance=E2=80= =9D, in a variety of forms that the client instance and AS can negotiate. I= f the client or AS has some other notion about who the RO is and how that c= ould be separate from the current user, we could provide a way to signal th= at like you=E2=80=99re proposing below. In my mental model, there are going= to be a lot of use cases where the =E2=80=9CRO=E2=80=9D isn=E2=80=99t know= n to the client at all, but rather to the AS and is based on what the clien= t=E2=80=99s asking for. So I could identify the current user and ask for a = specific medical record, and the AS realizes it has to go bug a particular = doctor to approve things directly. This is instead of interacting with the = current user and failing in an awkward way when the current user doesn=E2= =80=99t have the rights to do things, but someone else would. But we=E2=80= =99d want the system to be able to detect if the current user is the doctor= , so we can just interact with them directly. Does that all track?

=C2=A0=E2=80=94 Justin

On Mar 10, 2021, at 4:10 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hello,

Notice the question mark i= n the title. Not to be considered as an editor's comment.
Thi= s thread intends to provide a detailed comment on the interesting=C2=A0feed= back by Kristina: "I would catch up on the thread to understand why DI= Ds are thought to be treated as assertions".
In the chat, I = answered: "Happy to get the discussion on DIDs. Actually, could be eit= her or, depending on what we intend to do." Let me expand a bit on tha= t, to make it understandable (didn't have the time during the meeting, = unfortunately).

This relates to the items describe= d on slides 20 and 34, which I'll explain further. I'll highlight a= s transparently as possible what I think would be the benefits and downside= s of each. Both are probably viable options, but they correspond to differe= nt scopes and objectives. I'll spend a bit more time on option 2, since= it is a different approach compared to the current draft.

1. Th= e first possibility is to use SECEVENT throughout.=C2=A0
In t= hat case, DIDs should be a part of sub_ids (in the core or in the extension= registry, depending on what Annabelle's WG decides). More generally, t= he WG would have to decide which additional sub_ids it needs (as per Yaron&= #39;s comment).

That's obviously the closest t= o what is described in draft-04. It allows a communication of subject infor= mation between the client and the AS, by using global identifiers (mail, ph= one, etc.), or using a local opaque reference=C2=A0- i.e. governed by the A= S (that's probably what we would=C2=A0put in the examples, unless someo= ne has a better idea - cf issues #16 and #42).=C2=A0

Assertions relate for instance to the proof of presence of the RO. The c= urrent draft-04 therefore plans for id_tokens and saml2, maybe there could = be other needs later (extension registry).

- Benef= its: identifiers are a key component of GNAP, which makes integration easie= r. Possibly one could choose to use DIDs throughout.
- Downsides:= email/phone identifiers will probably be used throughout by most devs (sin= ce that's correlation information they=C2=A0have in their user DB). Whi= ch means we should limit what assertions contain, to avoid doing links betw= een weak global identifiers and hopefully stronger assertions. That's n= ot really a problem if it's limited to authentication events mostly (in= that perspective, samlv2 could make sense in the core). An assertion is pr= obably a single value then (not an array).=C2=A0 =C2=A0

Option 1 can be summarized as:=C2=A0

= "subject": {
=C2=A0=C2=A0=C2=A0"sub_ids": { }= , = // request and response (SECEVENT -> includ= ing DID possibly)=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=C2=A0=C2=A0=C2= =A0=C2=A0
=C2=A0=C2=A0=C2=A0"assertions": [ ], =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request and response (id_token or= samlv2)
}
("hints" do not exist currently, but= are partially covered separately via "request.user" / the releva= nce of "principal", discussed in the slide, is a question mark to= o - which is a different discussion on end-user !=3D RO).


2. An alternate possibility is to use SECEVE= NT only as input/hint
In that case, DIDs should be a part of = assertions (which have a different meaning compared to option 1).

The AS only returns an local opaque reference as_ref (while= in option 1, it was only one of many possibilities). Its only job is to he= lp the client differentiate the response subject. The AS policy might furth= er define the scope of that reference, as suggested in=C2=A0https://github.com/ie= tf-wg-gnap/gnap-core-protocol/issues/210, although I personally=C2=A0vi= ewed that by default as=C2=A0(2) "as_id" an identifier locally un= ique to that AS for all the RSs.

SECEVENTS are sti= ll useful as an input, that's what I presented in request.hints.self.su= b_ids (but it's the responsibility=C2=A0of the AS to match it with its = own reference system - from instance from the email to AS's local recor= d XUT2MFM1XBIKJKSDU8Q).=C2=A0Note: since the slides, a new draft-ietf-secev= ent-subject-identifiers-07 has been published. Notably this includes an opa= que identifier, which the client can use to pass the as_ref hint to the AS.= Thus we wouldn't need any further addition to SECEVENT,=C2=A0although = hints would benefit from further additions (like DIDs for instance). Notice= also that subject_types_supported becomes less important, because in the w= orst case scenario, it's simply=C2=A0a hint that wouldn't be unders= tood and therefore taken into account by the AS.

T= he assertions array has a more important role than in option 1 (with the ex= plicit aim of separating between client hints and validated info asserted b= y the AS). It serves as a generic/extendible mapping structure, e.g. "= the AS asserts that opaque reference=C2=A0XUT2MFM1XBIKJKSDU8Q=C2=A0is matchin= g with these (more or less verifiable) statements." The name assertion= therefore corresponds to the responsibility=C2=A0of the AS in delivering t= hose statements (cf should/must, issue #49). Some of these statements relat= e to identity or auth events (ex: DID, id_token), some might directly be us= eful for authorization decisions (like ZKP example in the parental control = example). Possibly some of these validated assertions could be reused in ne= xt interactions.

Another question that popped-up i= s the scope of sub_ids. Should they be about the same user? (I think so). I= n the case of remote ROs especially, it might be important that DID be cons= idered as an assertion=C2=A0(about someone else's) and not as sub_ids, = because the AS needs to be careful about who the client wants to reach (avo= id spam, etc.). This is consistent with the rest of discussion on what to d= o when end-user !=3D RO, although using DIDComm might seem a bit early (the= paint is very fresh).=C2=A0

Option 2 was summariz= ed as:=C2=A0

// (suggestion only= , not as an editor)
"subject": {
=C2=A0=C2=A0= =C2=A0"as_ref": { // response only (wouldn=E2=80=99t require SECEVENT)
=E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D, =
=E2=80= =9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D=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=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
<= div style=3D"line-height:1.2;margin-top:0pt;margin-bottom:0pt">=C2=A0=C2= =A0=C2=A0"assertions": [ ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 // request and response (id_token/jwkthumb/DID/VC/etc. -&= gt; whatever info can be validated by the AS)

=C2=A0=C2=A0=C2=A0"hints": { =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request only (opti= onal)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"self": { = // r= eplaces request.user (support SECEVENT here)
= =C2=A0=C2=A0=C2=A0=E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque in dr= aft-07 - that could contain the ref)
=C2=A0=C2= =A0=C2=A0=E2=80=9Cassertions=E2=80=9D: [ ] // see examples: VC o= n DOB or ZKP on age (wider scope, possibly through extensions)
= },=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=C2=A0=C2=A0=C2=A0
<= div style=3D"line-height:1.2;margin-top:0pt;margin-bottom:0pt">=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"principal": { // new proposal presented at IETF110 (just an idea)
=C2=A0 =E2=80=9Cautomated=E2=80=9D: true, // rule eng= ine
=C2=A0 =E2=80=9Casync=E2= =80=9D: { } // remote ROs
}=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=C2=A0=C2=A0}
}<= /div>

- Benefits: as_ref is self supporting= (no strong coupling with SECEVENT), but can still take SECEVENT as an inpu= t hint for the AS. It avoids the risk of making an official association bet= ween a weak global identifier (e.g. email, used elsewhere) and hopefully st= ronger local assertions. GNAP would be fully agnostic to whatever identity = system is used, only facilitating interoperability through assertions (seco= nd only in importance=C2=A0compared to the AS opaque reference). Some asser= tions (possibly extensions) could also be useful for the AS decision (e.g. = VC or ZKP).
- Downsides: opaqueness of as_ref is a feature, not a= bug. The opaque reference is fully managed by the AS, therefore not inhere= ntly portable (cf portability discussions in OIDC currently). There's n= o explicit binding to an official identity, only a contextual mapping to AS= validated assertions. It makes it more difficult to match the identifiers = from one AS to another or to correlate with the client user DB (still possi= ble via assertions, if the AS allows it). Assertions are much more generic = (possibly via extensions), but might require a more advanced mechanism=C2= =A0to request/response only the most relevant information (which makes the = AS policy critical here).

I hope that clarifies th= e=C2=A0reasoning for both options. Again I'm not saying option 2 is bet= ter, just saying the trade-offs are different (+ knowing that we need to ke= ep it simple).
- option 1 puts more in sub_ids and less in assert= ions
- option 2 puts less in the reference and more in assertions= =C2=A0
All of this is open to discussion. More generally speaking= , on every part in orange and question mark (?) I would love your ideas and= criticisms. What I intended as an editor is only to highlight where the WG= has important choices to make, before we can make the related PRs.

A further side comment: IETF EAT RATS was suggested for a= ssertions, but relates more to the client attestations. It was added as a c= omment in=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, w= hich is a distinct topic we'll work on.

Fabien= (editor's hat off)

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


--000000000000d61c1705bd3463e1-- From nobody Wed Mar 10 13:02:39 2021 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 821E03A1819 for ; Wed, 10 Mar 2021 13:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mattr-global.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 WVudxjOhGW1z for ; Wed, 10 Mar 2021 13:02:34 -0800 (PST) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 E72893A1817 for ; Wed, 10 Mar 2021 13:02:33 -0800 (PST) Received: by mail-qk1-x729.google.com with SMTP id l4so18441152qkl.0 for ; Wed, 10 Mar 2021 13:02:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattr-global.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5r21KP1uC3Ec0aarlM/3qT0R8dhUwO4vFiOWcVLzDvc=; b=hzMXJCJpfMSkWu9VBboahhO50wxFu18sAQJaP7JBXflRvvkgUhOq7AxLqP+yQQNES0 225EpypPs/ooGgKSHSfiY7HNUfDROkDo7/HsORh7oK/tRvkc8GWCpnE8C8zmrqhS9NLI Sn+gfw++WyXXD42Yzn/gkWl2GE5WKWqbBanu8n64Xqgp7HvC8dqYI9350J37OQaUMbQp 2yJERfZRSYMzuWyaIc3WmijTJpkeKsvuYBe8X1mVip2zIu4olVZCk0rq2eydIdr+H3K7 2sOymZhGGaxgj0r6QSIflSrX7LCfqQ1HRH1pmm8YklRIVep1EJnx397HgKBc1a5Igi8F Nogg== 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=5r21KP1uC3Ec0aarlM/3qT0R8dhUwO4vFiOWcVLzDvc=; b=Ukyw+7v5nmZ3KRVfJ/38kkNOpxgSHsHKb1LaFkf6s2HRnvtGSNICcWN8GCo8WyTel6 YkAL+/Oo1+jFdmqUMI3zS1lUdwDL5nVf9kh1BPMj9v7AVyRO44xQRNjh1UmuBhQuXFFS pv8xU1L4HSKVtIZwdF4yz3yWWPxs+i8mcqLbpMT8vUM9q8miWWqXCLxCURXgZy7dZrMS gFOPBZP+0H4cYJ/AOHx14V0+xKAz+0FLs0j3j9onZexmGFG/5nGg8VzPFX4RPzEFi9rl x+LBStMVSi9yJPKXHN+XSacJt6IP4+I+PzHAdukdVL5KCapfIf9iRbtngYZ8rwJcQdmI tGQA== X-Gm-Message-State: AOAM5321hzlFIhQTM3x5UZzQgfTdHgzw45hHfv/vIQMq8ofNz86n6VuS Ktd/Gn3k9ehzkTRVNZhUKrmyhj2H1OUUNulFCn06Zb6zoeGzNJW/J78W4gBxM9V00s+EfXfCHnr DskoZpZRAUumvKjZQeg== X-Google-Smtp-Source: ABdhPJzxgivZ1on2ItgubqCtZQXzm59VUmZZi0V9L87oY3qRs0zO7hwC5eY2oy6xvMw1zJP/xFmUK5hrrwTWmwu6tX4= X-Received: by 2002:a05:620a:914:: with SMTP id v20mr4749517qkv.140.1615410152929; Wed, 10 Mar 2021 13:02:32 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tobias Looker Date: Thu, 11 Mar 2021 10:02:21 +1300 Message-ID: To: Fabien Imbault Cc: Justin Richer , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000055101b05bd34fc73" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 21:02:38 -0000 --00000000000055101b05bd34fc73 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Thanks for the feedback, although I'm not sure what you mean by too abstract. Apologies what I mean by that was I feel like Option 2 would expose too much complexity to clients that would be required to construct a request to the AS. Option 1 IMO strikes a better balance by still offering the required flexibility but keeping things relatively simple. > Just a quick comment: an assertion in option 2 is not "the fact the identifier is resolvable to cryptographic material that *can *be used to validate cryptographic assertions". It is merely a statement by the AS that "the subject corresponding to the reference has a DID" ("has" is the assertion here). Yes I understand to drill down on this more though couldn't the entire request made by the client to the AS also be considered to be an assertion? Therefore the "sub_ids" request element is an assertion by the client about who it believes the subject to be identified as? If this is true then to me the "assertions" request element is there for assertions that parties other than the client are making about the subject (e.g an id_token). Thanks, [image: Mattr website] *Tobias Looker* Mattr +64 (0) 27 378 0461 tobias.looker@mattr.global [image: Mattr website] [image: Mattr on LinkedIn] [image: Mattr on Twitter] [image: Mattr on Github] This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002. On Thu, Mar 11, 2021 at 9:20 AM Fabien Imbault wrote: > Thanks Justin. > > It's good to clarify what we mean by assertion. I used a more mundane > meaning. > > I dislike email/phone as security disasters waiting to happen. I get that > they are practical. > > I think I have what I need to write the PRs based on sub_ids (based on th= e > current draft-07). > > Fabien > > Le mer. 10 mars 2021 =C3=A0 20:18, Justin Richer a =C3= =A9crit : > >> Hi Fabien, >> >> First, thanks for doing the heavy lift of writing this topic up. Of thes= e >> options, I would strongly prefer option (1). The difference between >> assertions and identifiers is that an assertion is a fully packaged set = of >> attributes, one of which can be an identifier. They are, generally >> speaking, cryptographically protected bundles. They=E2=80=99re designed = to carry a >> bunch of different information about a user and the authentication event= in >> a form that=E2=80=99s independently verifiable and auditable. SAML asser= tions (XML >> document) and ID Tokens (signed JWTs) are the most common ones we see >> today, but other formats exist and will keep being invented. >> >> An identifier is a different kind of creature. It is a single statement >> that identifies the party in question in the context of the party doing = the >> identification. It=E2=80=99s this full context that the receiver of the = identifier >> needs to interpret it in. When using a federated identity protocol, each= RP >> is going to have :some: kind of local user information store that they= =E2=80=99re >> going to tie into, some field in a database they=E2=80=99ll key off of. = It=E2=80=99s just >> never going to be the case that all RPs will be able to use server-provi= ded >> opaque identifiers for all cases. Account recovery and binding is one su= ch >> use case where a user-facing identifier like an email address makes a LO= T >> of sense, for one small example. This is an array in the request and >> response precisely because a user could be known by several different >> identifiers to a party, and an RP will have a better idea about what kin= ds >> of things it wants to correlate against, and it=E2=80=99s up to the AS t= o provide >> that mapping. I think that if we don=E2=80=99t define a way to describe = the format, >> the =E2=80=9Cas_id=E2=80=9D field is going to get structure back-patched= onto it like is >> being proposed here: >> >> https://mattrglobal.github.io/oidc-portable-identities/ >> >> I=E2=80=99m personally not a fan of that approach as it mixes the data l= ayering >> too much, and you end up making guesses about whether a field is meaning= ful >> or a pointer. I think GNAP will be much better served by using a data >> structure for this from the start. DIDs should be another =E2=80=9Cforma= t=E2=80=9D of the >> subject identifier. I don=E2=80=99t think GNAP should define this format= , and I=E2=80=99ve >> dropped a note to the SECEVENT mailing list asking about adding DIDs to = the >> subject identifiers draft before it gets published. DIDs are not >> assertions, even in the cases where they point to fully functional DID >> documents with user information in them. (And for what it=E2=80=99s wort= h, I think >> the OIDC world should also use the SECEVENT draft inside ID Tokens to so= lve >> the use case of the draft above). >> >> For the user !=3D RO cases, I think that potentially having a way to sig= nal >> those two items separately in the request and response could be useful. >> Right now all the user/subject stuff is about identifying =E2=80=9Cthe u= ser that=E2=80=99s >> currently here at the client instance=E2=80=9D, in a variety of forms th= at the >> client instance and AS can negotiate. If the client or AS has some other >> notion about who the RO is and how that could be separate from the curre= nt >> user, we could provide a way to signal that like you=E2=80=99re proposin= g below. In >> my mental model, there are going to be a lot of use cases where the =E2= =80=9CRO=E2=80=9D >> isn=E2=80=99t known to the client at all, but rather to the AS and is ba= sed on what >> the client=E2=80=99s asking for. So I could identify the current user an= d ask for a >> specific medical record, and the AS realizes it has to go bug a particul= ar >> doctor to approve things directly. This is instead of interacting with t= he >> current user and failing in an awkward way when the current user doesn= =E2=80=99t >> have the rights to do things, but someone else would. But we=E2=80=99d w= ant the >> system to be able to detect if the current user is the doctor, so we can >> just interact with them directly. Does that all track? >> >> =E2=80=94 Justin >> >> On Mar 10, 2021, at 4:10 AM, Fabien Imbault >> wrote: >> >> Hello, >> >> Notice the question mark in the title. Not to be considered as an >> editor's comment. >> This thread intends to provide a detailed comment on the >> interesting feedback by Kristina: "I would catch up on the thread to >> understand why DIDs are thought to be treated as assertions". >> In the chat, I answered: "Happy to get the discussion on DIDs. Actually, >> could be either or, depending on what we intend to do." Let me expand a = bit >> on that, to make it understandable (didn't have the time during the >> meeting, unfortunately). >> >> This relates to the items described on slides 20 and 34, which I'll >> explain further. I'll highlight as transparently as possible what I thin= k >> would be the benefits and downsides of each. Both are probably viable >> options, but they correspond to different scopes and objectives. I'll sp= end >> a bit more time on option 2, since it is a different approach compared t= o >> the current draft. >> >> *1. The first possibility is to use SECEVENT throughout. * >> In that case, DIDs should be a part of sub_ids (in the core or in the >> extension registry, depending on what Annabelle's WG decides). More >> generally, the WG would have to decide which additional sub_ids it needs >> (as per Yaron's comment). >> >> That's obviously the closest to what is described in draft-04. It allows >> a communication of subject information between the client and the AS, by >> using global identifiers (mail, phone, etc.), or using a local opaque >> reference - i.e. governed by the AS (that's probably what we would put i= n >> the examples, unless someone has a better idea - cf issues #16 and #42). >> >> Assertions relate for instance to the proof of presence of the RO. The >> current draft-04 therefore plans for id_tokens and saml2, maybe there co= uld >> be other needs later (extension registry). >> >> - Benefits: identifiers are a key component of GNAP, which makes >> integration easier. Possibly one could choose to use DIDs throughout. >> - Downsides: email/phone identifiers will probably be used throughout by >> most devs (since that's correlation information they have in their user >> DB). Which means we should limit what assertions contain, to avoid doing >> links between weak global identifiers and hopefully stronger assertions. >> That's not really a problem if it's limited to authentication events mos= tly >> (in that perspective, samlv2 could make sense in the core). An assertion= is >> probably a single value then (not an array). >> >> Option 1 can be summarized as: >> >> "subject": { >> "sub_ids": { }, // request and response (SECEVENT -> including DID >> possibly) >> "assertions": [ ], // request and response (id_token or >> samlv2) >> } >> ("hints" do not exist currently, but are partially covered separately vi= a >> "request.user" / the relevance of "principal", discussed in the slide, i= s a >> question mark too - which is a different discussion on end-user !=3D RO)= . >> >> >> *2. An alternate possibility is to use SECEVENT only as input/hint* >> In that case, DIDs should be a part of assertions (which have a differen= t >> meaning compared to option 1). >> >> The AS only returns an local opaque reference as_ref (while in option 1, >> it was only one of many possibilities). Its only job is to help the clie= nt >> differentiate the response subject. The AS policy might further define t= he >> scope of that reference, as suggested in >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210, although >> I personally viewed that by default as (2) "as_id" an identifier locally >> unique to that AS for all the RSs. >> >> SECEVENTS are still useful as an input, that's what I presented in >> request.hints.self.sub_ids (but it's the responsibility of the AS to mat= ch >> it with its own reference system - from instance from the email to AS's >> local record XUT2MFM1XBIKJKSDU8Q). Note: since the slides, a new >> draft-ietf-secevent-subject-identifiers-07 has been published. Notably t= his >> includes an opaque identifier, which the client can use to pass the as_r= ef >> hint to the AS. Thus we wouldn't need any further addition to >> SECEVENT, although hints would benefit from further additions (like DIDs >> for instance). Notice also that subject_types_supported becomes less >> important, because in the worst case scenario, it's simply a hint that >> wouldn't be understood and therefore taken into account by the AS. >> >> The assertions array has a more important role than in option 1 (with th= e >> explicit aim of separating between client hints and validated info asser= ted >> by the AS). It serves as a generic/extendible mapping structure, e.g. "t= he >> AS asserts that opaque reference XUT2MFM1XBIKJKSDU8Q is matching with >> these (more or less verifiable) statements." The name assertion therefor= e >> corresponds to the responsibility of the AS in delivering those statemen= ts >> (cf should/must, issue #49). Some of these statements relate to identity= or >> auth events (ex: DID, id_token), some might directly be useful for >> authorization decisions (like ZKP example in the parental control exampl= e). >> Possibly some of these validated assertions could be reused in next >> interactions. >> >> Another question that popped-up is the scope of sub_ids. Should they be >> about the same user? (I think so). In the case of remote ROs especially,= it >> might be important that DID be considered as an assertion (about someone >> else's) and not as sub_ids, because the AS needs to be careful about who >> the client wants to reach (avoid spam, etc.). This is consistent with th= e >> rest of discussion on what to do when end-user !=3D RO, although using >> DIDComm might seem a bit early (the paint is very fresh). >> >> Option 2 was summarized as: >> >> // (suggestion only, not as an editor) >> "subject": { >> "as_ref": { // response only (wouldn=E2=80=99t require SECEVENT) >> =E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D, >> =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D >> }, >> "assertions": [ ], // request and response >> (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validated by the = AS) >> >> "hints": { // request only (optional) >> "self": { // replaces request.user (support SECEVENT here) >> =E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque in draf= t-07 - that >> could contain the ref) >> =E2=80=9Cassertions=E2=80=9D: [ ] // see examples: VC on DOB or ZKP o= n age (wider >> scope, possibly through extensions) >> }, >> "principal": { // new proposal presented at IETF110 (just an idea) >> =E2=80=9Cautomated=E2=80=9D: true, // rule engine >> =E2=80=9Casync=E2=80=9D: { } // remote ROs >> } >> } >> } >> >> - Benefits: as_ref is self supporting (no strong coupling with SECEVENT)= , >> but can still take SECEVENT as an input hint for the AS. It avoids the r= isk >> of making an official association between a weak global identifier (e.g. >> email, used elsewhere) and hopefully stronger local assertions. GNAP wou= ld >> be fully agnostic to whatever identity system is used, only facilitating >> interoperability through assertions (second only in importance compared = to >> the AS opaque reference). Some assertions (possibly extensions) could al= so >> be useful for the AS decision (e.g. VC or ZKP). >> - Downsides: opaqueness of as_ref is a feature, not a bug. The opaque >> reference is fully managed by the AS, therefore not inherently portable = (cf >> portability discussions in OIDC currently). There's no explicit binding = to >> an official identity, only a contextual mapping to AS validated assertio= ns. >> It makes it more difficult to match the identifiers from one AS to anoth= er >> or to correlate with the client user DB (still possible via assertions, = if >> the AS allows it). Assertions are much more generic (possibly via >> extensions), but might require a more advanced mechanism to >> request/response only the most relevant information (which makes the AS >> policy critical here). >> >> I hope that clarifies the reasoning for both options. Again I'm not >> saying option 2 is better, just saying the trade-offs are different (+ >> knowing that we need to keep it simple). >> - option 1 puts more in sub_ids and less in assertions >> - option 2 puts less in the reference and more in assertions >> All of this is open to discussion. More generally speaking, on every par= t >> in orange and question mark (?) I would love your ideas and criticisms. >> What I intended as an editor is only to highlight where the WG has >> important choices to make, before we can make the related PRs. >> >> A further side comment: IETF EAT RATS was suggested for assertions, but >> relates more to the client attestations. It was added as a comment in >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, which is a >> distinct topic we'll work on. >> >> Fabien (editor's hat off) >> >> -- >> 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 This communication, including any attachments, is confidential. If you are= =20 not the intended recipient, you should not read it - please contact me=20 immediately, destroy it, and do not copy or use any part of this=20 communication or disclose anything about it. Thank you. Please note that=20 this communication does not designate an information system for the=20 purposes of the Electronic Transactions Act 2002. --00000000000055101b05bd34fc73 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Thanks for the feedback, although I'm not sure wh= at you mean by too abstract.

Apologies what I mean by th= at was I feel like Option 2 would expose too much complexity to clients tha= t would be required to construct a request to the AS. Option 1 IMO strikes = a better balance by still offering the required flexibility but keeping thi= ngs relatively simple.

> Just a quick comment: = an assertion in option 2 is not "the fact the identifier is resolvable= to cryptographic material that=C2=A0can=C2=A0be used to validate cr= yptographic assertions". It is merely a statement by the AS that "= ;the subject corresponding to the reference has a DID" ("has"= ; is the assertion here).=C2=A0

Yes I understand t= o drill down on this more though couldn't the entire request made by th= e client to the AS also be considered to be an assertion? Therefore the=C2= =A0"sub_ids" request element is an assertion by the client about = who it believes the subject to be identified as? If this is true then to me= the "assertions" request element is there for assertions that pa= rties other than the client are making about the subject (e.g an id_token).=

Thanks,
3D"==C2=A0
Tobias Looker
Mattr=
+64 (0) 27 378 0461
t= obias.looker@mattr.global
3D"Mat=3D"Mattr=
= 3D"Mattr=C2=A0
Tobias Looker=
Mattr
+64 (0) 27 378 0461
tobias.looker@mattr.global
3D==3D"Mattr3D"Mattr=<= /td>3D"Mattr

This communication, including a= ny attachments, is confidential. If you are not the intended recipient, you= should not read it - please contact me immediately, destroy it, and do not= copy or use any part of this communication or disclose anything about it. = Thank you. Please note that this communication does not designate an inform= ation system for the purposes of the Electronic Transactions Act 2002.


On Thu, Mar 11, 2021 at 9:20= AM Fabien Imbault <fabien.i= mbault@gmail.com> wrote:
Thanks Justin.

It's good to clarify what we mean by assertion. I us= ed a more mundane meaning.=C2=A0

I dislike email/phone as security disasters waiting to happen. I = get that they are practical.=C2=A0

I think I have what I need to write the PRs based on sub_ids (ba= sed on the current draft-07).=C2=A0

Fabien=C2=A0

<= div dir=3D"ltr" class=3D"gmail_attr">Le mer. 10 mars 2021 =C3=A0 20:18, Jus= tin Richer <jricher@mit.edu> a =C3=A9crit=C2= =A0:
Hi Fabien,

First, thanks= for doing the heavy lift of writing this topic up. Of these options, I wou= ld strongly prefer option (1). The difference between assertions and identi= fiers is that an assertion is a fully packaged set of attributes, one of wh= ich can be an identifier. They are, generally speaking, cryptographically p= rotected bundles. They=E2=80=99re designed to carry a bunch of different in= formation about a user and the authentication event in a form that=E2=80=99= s independently verifiable and auditable. SAML assertions (XML document) an= d ID Tokens (signed JWTs) are the most common ones we see today, but other = formats exist and will keep being invented.=C2=A0

= An identifier is a different kind of creature. It is a single statement tha= t identifies the party in question in the context of the party doing the id= entification. It=E2=80=99s this full context that the receiver of the ident= ifier needs to interpret it in. When using a federated identity protocol, e= ach RP is going to have :some: kind of local user information store that th= ey=E2=80=99re going to tie into, some field in a database they=E2=80=99ll k= ey off of. It=E2=80=99s just never going to be the case that all RPs will b= e able to use server-provided opaque identifiers for all cases. Account rec= overy and binding is one such use case where a user-facing identifier like = an email address makes a LOT of sense, for one small example. This is an ar= ray in the request and response precisely because a user could be known by = several different identifiers to a party, and an RP will have a better idea= about what kinds of things it wants to correlate against, and it=E2=80=99s= up to the AS to provide that mapping. I think that if we don=E2=80=99t def= ine a way to describe the format, the =E2=80=9Cas_id=E2=80=9D field is goin= g to get structure back-patched onto it like is being proposed here:
<= div>

I=E2=80=99m personally not a fan of that approach as it mi= xes the data layering too much, and you end up making guesses about whether= a field is meaningful or a pointer. I think GNAP will be much better serve= d by using a data structure for this from the start. DIDs should be another= =E2=80=9Cformat=E2=80=9D of the subject identifier. I don=E2=80=99t think = GNAP should define this format, and I=E2=80=99ve dropped a note to the SECE= VENT mailing list asking about adding DIDs to the subject identifiers draft= before it gets published. DIDs are not assertions, even in the cases where= they point to fully functional DID documents with user information in them= . (And for what it=E2=80=99s worth, I think the OIDC world should also use = the SECEVENT draft inside ID Tokens to solve the use case of the draft abov= e).

For the user !=3D RO cases, I think that poten= tially having a way to signal those two items separately in the request and= response could be useful. Right now all the user/subject stuff is about id= entifying =E2=80=9Cthe user that=E2=80=99s currently here at the client ins= tance=E2=80=9D, in a variety of forms that the client instance and AS can n= egotiate. If the client or AS has some other notion about who the RO is and= how that could be separate from the current user, we could provide a way t= o signal that like you=E2=80=99re proposing below. In my mental model, ther= e are going to be a lot of use cases where the =E2=80=9CRO=E2=80=9D isn=E2= =80=99t known to the client at all, but rather to the AS and is based on wh= at the client=E2=80=99s asking for. So I could identify the current user an= d ask for a specific medical record, and the AS realizes it has to go bug a= particular doctor to approve things directly. This is instead of interacti= ng with the current user and failing in an awkward way when the current use= r doesn=E2=80=99t have the rights to do things, but someone else would. But= we=E2=80=99d want the system to be able to detect if the current user is t= he doctor, so we can just interact with them directly. Does that all track?=

=C2=A0=E2=80=94 Justin

On Mar 10, 2021, at 4:10 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:=

Hello,

Notice the questi= on mark in the title. Not to be considered as an editor's comment.
This thread intends to provide a detailed comment on the interesting= =C2=A0feedback by Kristina: "I would catch up on the thread to underst= and why DIDs are thought to be treated as assertions".
In th= e chat, I answered: "Happy to get the discussion on DIDs. Actually, co= uld be either or, depending on what we intend to do." Let me expand a = bit on that, to make it understandable (didn't have the time during the= meeting, unfortunately).

This relates to the item= s described on slides 20 and 34, which I'll explain further. I'll h= ighlight as transparently as possible what I think would be the benefits an= d downsides of each. Both are probably viable options, but they correspond = to different scopes and objectives. I'll spend a bit more time on optio= n 2, since it is a different approach compared to the current draft.
<= div>
1. The first possibility is to use SECEVENT throughout.=C2=A0
In that case, DIDs should be a part of sub_ids (in the core or in the= extension registry, depending on what Annabelle's WG decides). More ge= nerally, the WG would have to decide which additional sub_ids it needs (as = per Yaron's comment).

That's obviously the= closest to what is described in draft-04. It allows a communication of sub= ject information between the client and the AS, by using global identifiers= (mail, phone, etc.), or using a local opaque reference=C2=A0- i.e. governe= d by the AS (that's probably what we would=C2=A0put in the examples, un= less someone has a better idea - cf issues #16 and #42).=C2=A0
Assertions relate for instance to the proof of presence of the= RO. The current draft-04 therefore plans for id_tokens and saml2, maybe th= ere could be other needs later (extension registry).

- Benefits: identifiers are a key component of GNAP, which makes integra= tion easier. Possibly one could choose to use DIDs throughout.
- = Downsides: email/phone identifiers will probably be used throughout by most= devs (since that's correlation information they=C2=A0have in their use= r DB). Which means we should limit what assertions contain, to avoid doing = links between weak global identifiers and hopefully stronger assertions. Th= at's not really a problem if it's limited to authentication events = mostly (in that perspective, samlv2 could make sense in the core). An asser= tion is probably a single value then (not an array).=C2=A0 =C2=A0

Option 1 can be summarized as:=C2=A0

"subject": {<= /div>
=C2= =A0=C2=A0=C2=A0"sub_ids": { }, // requ= est and response (SECEVENT -> including DID possibly)=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=C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0"= ;assertions": [ ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = // request and response (id_token or samlv2)
}
("h= ints" do not exist currently, but are partially covered separately via= "request.user" / the relevance of "principal", discuss= ed in the slide, is a question mark too - which is a different discussion o= n end-user !=3D RO).


2. An al= ternate possibility is to use SECEVENT only as input/hint
In = that case, DIDs should be a part of assertions (which have a different mean= ing compared to option 1).

The AS only returns an = local opaque reference as_ref (while in option 1, it was only one of many p= ossibilities). Its only job is to help the client differentiate the respons= e subject. The AS policy might further define the scope of that reference, = as suggested in=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/21= 0, although I personally=C2=A0viewed that by default as=C2=A0(2) "= as_id" an identifier locally unique to that AS for all the RSs.
<= div>
SECEVENTS are still useful as an input, that's what = I presented in request.hints.self.sub_ids (but it's the responsibility= =C2=A0of the AS to match it with its own reference system - from instance f= rom the email to AS's local record XUT2MFM1XBIKJKSDU8Q).=C2=A0Note: sin= ce the slides, a new draft-ietf-secevent-subject-identifiers-07 has been pu= blished. Notably this includes an opaque identifier, which the client can u= se to pass the as_ref hint to the AS. Thus we wouldn't need any further= addition to SECEVENT,=C2=A0although hints would benefit from further addit= ions (like DIDs for instance). Notice also that subject_types_supported bec= omes less important, because in the worst case scenario, it's simply=C2= =A0a hint that wouldn't be understood and therefore taken into account = by the AS.

The assertions array has a more importa= nt role than in option 1 (with the explicit aim of separating between clien= t hints and validated info asserted by the AS). It serves as a generic/exte= ndible mapping structure, e.g. "the AS asserts that opaque reference= =C2=A0XUT= 2MFM1XBIKJKSDU8Q=C2=A0is matching with these (more or less verifiabl= e) statements." The name assertion therefore corresponds to the respon= sibility=C2=A0of the AS in delivering those statements (cf should/must, iss= ue #49). Some of these statements relate to identity or auth events (ex: DI= D, id_token), some might directly be useful for authorization decisions (li= ke ZKP example in the parental control example). Possibly some of these val= idated assertions could be reused in next interactions.

Another question that popped-up is the scope of sub_ids. Should they = be about the same user? (I think so). In the case of remote ROs especially,= it might be important that DID be considered as an assertion=C2=A0(about s= omeone else's) and not as sub_ids, because the AS needs to be careful a= bout who the client wants to reach (avoid spam, etc.). This is consistent w= ith the rest of discussion on what to do when end-user !=3D RO, although us= ing DIDComm might seem a bit early (the paint is very fresh).=C2=A0

Option 2 was summarized as:=C2=A0

// (suggestion only, not as= an editor)
"subject": {
=C2=A0=C2=A0=C2=A0&= quot;as_ref": { // response only (wouldn=E2=80=99t require SECEVENT)
=E2=80=9Cas=E2=80=9D: =E2=80=9Ch= ttps://ex1.as.com=E2=80=9D, =
=E2=80=9Cref=E2= =80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D=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=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&= quot;assertions": [ ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 // request and response (id_token/jwkthumb/DID/VC/etc. -> whatev= er info can be validated by the AS)
= =C2=A0=C2=A0=C2=A0"hints": { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request only (optional)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"self": { // replaces = request.user (support SECEVENT here)
=C2=A0=C2= =A0=C2=A0=E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque in draft-07 - = that could contain the ref)
=C2=A0=C2=A0=C2=A0= =E2=80=9Cassertions=E2=80=9D: [ ] // see examples: VC on DOB or = ZKP on age (wider scope, possibly through extensions)
=
},=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=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0"principal": { // ne= w proposal presented at IETF110 (just an idea)
=C2=A0 =E2=80=9Cautomated=E2=80=9D: true, // rule engine
<= font size=3D"1"> =C2=A0 =E2=80=9Casync=E2=80=9D: { }<= /span> // remote ROs
}=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=C2=A0=C2=A0}
}

- Benefits: as_ref is self supporting (no strong cou= pling with SECEVENT), but can still take SECEVENT as an input hint for the = AS. It avoids the risk of making an official association between a weak glo= bal identifier (e.g. email, used elsewhere) and hopefully stronger local as= sertions. GNAP would be fully agnostic to whatever identity system is used,= only facilitating interoperability through assertions (second only in impo= rtance=C2=A0compared to the AS opaque reference). Some assertions (possibly= extensions) could also be useful for the AS decision (e.g. VC or ZKP).
- Downsides: opaqueness of as_ref is a feature, not a bug. The opaqu= e reference is fully managed by the AS, therefore not inherently portable (= cf portability discussions in OIDC currently). There's no explicit bind= ing to an official identity, only a contextual mapping to AS validated asse= rtions. It makes it more difficult to match the identifiers from one AS to = another or to correlate with the client user DB (still possible via asserti= ons, if the AS allows it). Assertions are much more generic (possibly via e= xtensions), but might require a more advanced mechanism=C2=A0to request/res= ponse only the most relevant information (which makes the AS policy critica= l here).

I hope that clarifies the=C2=A0reasoning = for both options. Again I'm not saying option 2 is better, just saying = the trade-offs are different (+ knowing that we need to keep it simple).
- option 1 puts more in sub_ids and less in assertions
- = option 2 puts less in the reference and more in assertions=C2=A0
= All of this is open to discussion. More generally speaking, on every part i= n orange and question mark (?) I would love your ideas and criticisms. What= I intended as an editor is only to highlight where the WG has important ch= oices to make, before we can make the related PRs.

A further side comment: IETF EAT RATS was suggested for assertions, but re= lates more to the client attestations. It was added as a comment in=C2=A0https://= github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, which is a distin= ct topic we'll work on.

Fabien (editor's h= at off)

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


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

This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.
--00000000000055101b05bd34fc73-- From nobody Wed Mar 10 13:14:54 2021 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 6DC713A1859 for ; Wed, 10 Mar 2021 13:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 piwrAlXmD-M7 for ; Wed, 10 Mar 2021 13:14:50 -0800 (PST) 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 39D863A1853 for ; Wed, 10 Mar 2021 13:14:50 -0800 (PST) Received: from [192.168.1.22] (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 12ALEl1Z005935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Mar 2021 16:14:47 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_AB04426E-673D-4634-B37A-6D7D084FDCF0" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 10 Mar 2021 16:14:47 -0500 In-Reply-To: Cc: Fabien Imbault , GNAP Mailing List To: Tobias Looker References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 21:14:52 -0000 --Apple-Mail=_AB04426E-673D-4634-B37A-6D7D084FDCF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >=20 > > Just a quick comment: an assertion in option 2 is not "the fact the = identifier is resolvable to cryptographic material that can be used to = validate cryptographic assertions". It is merely a statement by the AS = that "the subject corresponding to the reference has a DID" ("has" is = the assertion here).=20 >=20 > Yes I understand to drill down on this more though couldn't the entire = request made by the client to the AS also be considered to be an = assertion? Therefore the "sub_ids" request element is an assertion by = the client about who it believes the subject to be identified as? If = this is true then to me the "assertions" request element is there for = assertions that parties other than the client are making about the = subject (e.g an id_token). > =20 That=E2=80=99s my reading of it, on a wider sense. The assertions in the = =E2=80=9Cassertions=E2=80=9D part of the request have been given to the = client by some other party, and the client is passing them along to the = AS to say =E2=80=9Cthis is who I believe is here right now=E2=80=9D. = It=E2=80=99s up to the AS to decide if it trusts that. Now around that, = the client itself is making a larger statement to the AS and signed with = the client instance key, so in a way the request is a kind of assertion. = (it=E2=80=99s not really a separable unit of data so I wouldn=E2=80=99t = go quite that far, when you drill into it.) But yes, in that context the = =E2=80=9Csub_ids=E2=80=9D and =E2=80=9Cassertions=E2=80=9D are both = elements in the =E2=80=9Cassertion=E2=80=9D the client instance is = making to the AS about who=E2=80=99s there. =E2=80=94 Justin= --Apple-Mail=_AB04426E-673D-4634-B37A-6D7D084FDCF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

> Just a quick comment: an assertion in option 2 is not = "the fact the identifier is resolvable to cryptographic material = that can be used to validate cryptographic = assertions". It is merely a statement by the AS that "the subject = corresponding to the reference has a DID" ("has" is the assertion = here). 

Yes= I understand to drill down on this more though couldn't the entire = request made by the client to the AS also be considered to be an = assertion? Therefore the "sub_ids" request element is an assertion = by the client about who it believes the subject to be identified as? If = this is true then to me the "assertions" request element is there for = assertions that parties other than the client are making about the = subject (e.g an id_token).
 

That=E2=80=99s my reading of it, on a wider sense. = The assertions in the =E2=80=9Cassertions=E2=80=9D part of the request = have been given to the client by some other party, and the client is = passing them along to the AS to say =E2=80=9Cthis is who I believe is = here right now=E2=80=9D. It=E2=80=99s up to the AS to decide if it = trusts that. Now around that, the client itself is making a larger = statement to the AS and signed with the client instance key, so in a way = the request is a kind of assertion. (it=E2=80=99s not really a separable = unit of data so I wouldn=E2=80=99t go quite that far, when you drill = into it.) But yes, in that context the =E2=80=9Csub_ids=E2=80=9D and = =E2=80=9Cassertions=E2=80=9D are both elements in the =E2=80=9Cassertion=E2= =80=9D the client instance is making to the AS about who=E2=80=99s = there.

 =E2=80=94 = Justin
= --Apple-Mail=_AB04426E-673D-4634-B37A-6D7D084FDCF0-- From nobody Wed Mar 10 14:58:01 2021 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 254983A0A79 for ; Wed, 10 Mar 2021 14:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.087 X-Spam-Level: X-Spam-Status: No, score=-7.087 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_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 eGGTmiLBcrNJ for ; Wed, 10 Mar 2021 14:57:56 -0800 (PST) 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 62F883A0A86 for ; Wed, 10 Mar 2021 14:57:56 -0800 (PST) Received: by mail-il1-x12d.google.com with SMTP id z9so17207504iln.1 for ; Wed, 10 Mar 2021 14:57:56 -0800 (PST) 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=HOlgoj6bF+pqsei4uvcNJN6AUm5PGhhlQ7ugp89uIgg=; b=XwAxANil2kbBMNGZXbfpl5h5g7sgZN1H98vQvLF3HS/sNkFzduQx33l/nMzo+tAfFT h/ZCjwuLlHlk0kUS0OAd6ldjiZ3BoYXuMHwvL+vewfroaHigM54yE4xuINuKG/iTevJn eOuD7ZQIVvsyFYPJryjvapw8ANaO+WrLb7FyfjR6pS7b5RgdReKeuh9z6L7X9cgGO5r8 4s5J6RgmBQExDpgK0FoltZFzifCwZbogBRJcq4rpSNCeUJ+O0FAE14i3SXr6Ubf+U23T j0Ysn2oXIQJnrgt2Bfrchj2EHwpCddw2rBAu6jK1cNFYq8+dwjvAHit8Nh6Y0CMU/ysa Ag1A== 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=HOlgoj6bF+pqsei4uvcNJN6AUm5PGhhlQ7ugp89uIgg=; b=TszjAM+ruTGDGkTk8O/PKljQHDiTo5KgdQP54TGNDtzA2cDlMF/IxD6jwBLdx/Tcgl vgP7r3XvUNqfNqftUdwc8QWSB2h+C6cwqwHWRwKXLTucte97kcSIvYtg8p2XrNJ6AC4W DHn3PgwK/1PLRQ6zQm1sV7XAx5a2GPNB3RcQgyseeRFpFmjS5H05+JXXiSp0A1EC4dFH FqrlczJZ+cMssjF9Qj1T3YAWvBtkwk+HO6uGL4HnKz5K1Y5LJkvrLDnmQvub2pId3F1A YtkfNx61yY/RIErizyGjMyDjcgsX43jl2wF4nO22WKL/J+jBmdohI5tdXTH0RCQ77mOg JH3g== X-Gm-Message-State: AOAM530km7Vbz9GZeoGHzdfmAJ1pb6db9/83nrO4p7xY/hyjeYU+wTa7 M8zcmcOv4DrFkCf/3XxNbO8vITe+9EmEdF49+RY= X-Google-Smtp-Source: ABdhPJxgaeTcSxUxLoMukgDfeM1WHnpXN60Rjn2leRHOQQns25u1btAynNvlhz6gC97v0+gHAGWs2/N2LNlqEurX7vk= X-Received: by 2002:a05:6e02:1cac:: with SMTP id x12mr4812570ill.188.1615417074574; Wed, 10 Mar 2021 14:57:54 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Wed, 10 Mar 2021 23:57:42 +0100 Message-ID: To: Tobias Looker Cc: Justin Richer , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000e4e9f405bd3698bc" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 22:58:00 -0000 --000000000000e4e9f405bd3698bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tobias, Option 2's pros and cons are the consequence of solely relying only on an opaque identifier managed by the AS, independantly from external identifiers. That's an additional level of indirection, not unlike how indexes are usually managed in a database. But there's obviously the additional complexity of making a just in time translation into a practical identifier (like email for account recovery, as discussed by Justin). "Assertions" should be what the AS (possibly with the assistance of other parties) can confidently say about the subject. Thanks for the great feedback, as well as Justin's. Since the slides were written, SECEVENT draft-07 already offers new possibilities which is good news. Fabien Le mer. 10 mars 2021 =C3=A0 22:02, Tobias Looker a =C3=A9crit : > > Thanks for the feedback, although I'm not sure what you mean by too > abstract. > > Apologies what I mean by that was I feel like Option 2 would expose too > much complexity to clients that would be required to construct a request = to > the AS. Option 1 IMO strikes a better balance by still offering the > required flexibility but keeping things relatively simple. > > > Just a quick comment: an assertion in option 2 is not "the fact the > identifier is resolvable to cryptographic material that *can *be used to > validate cryptographic assertions". It is merely a statement by the AS th= at > "the subject corresponding to the reference has a DID" ("has" is the > assertion here). > > Yes I understand to drill down on this more though couldn't the entire > request made by the client to the AS also be considered to be an assertio= n? > Therefore the "sub_ids" request element is an assertion by the client abo= ut > who it believes the subject to be identified as? If this is true then to = me > the "assertions" request element is there for assertions that parties oth= er > than the client are making about the subject (e.g an id_token). > > Thanks, > [image: Mattr website] > *Tobias Looker* > Mattr > +64 (0) 27 378 0461 > tobias.looker@mattr.global > [image: Mattr website] [image: Mattr on LinkedIn] > [image: Mattr on Twitter] > [image: Mattr on Github] > > This communication, including any attachments, is confidential. If you ar= e > not the intended recipient, you should not read it - please contact me > immediately, destroy it, and do not copy or use any part of this > communication or disclose anything about it. Thank you. Please note that > this communication does not designate an information system for the > purposes of the Electronic Transactions Act 2002. > > > On Thu, Mar 11, 2021 at 9:20 AM Fabien Imbault > wrote: > >> Thanks Justin. >> >> It's good to clarify what we mean by assertion. I used a more mundane >> meaning. >> >> I dislike email/phone as security disasters waiting to happen. I get tha= t >> they are practical. >> >> I think I have what I need to write the PRs based on sub_ids (based on >> the current draft-07). >> >> Fabien >> >> Le mer. 10 mars 2021 =C3=A0 20:18, Justin Richer a =C3= =A9crit : >> >>> Hi Fabien, >>> >>> First, thanks for doing the heavy lift of writing this topic up. Of >>> these options, I would strongly prefer option (1). The difference betwe= en >>> assertions and identifiers is that an assertion is a fully packaged set= of >>> attributes, one of which can be an identifier. They are, generally >>> speaking, cryptographically protected bundles. They=E2=80=99re designed= to carry a >>> bunch of different information about a user and the authentication even= t in >>> a form that=E2=80=99s independently verifiable and auditable. SAML asse= rtions (XML >>> document) and ID Tokens (signed JWTs) are the most common ones we see >>> today, but other formats exist and will keep being invented. >>> >>> An identifier is a different kind of creature. It is a single statement >>> that identifies the party in question in the context of the party doing= the >>> identification. It=E2=80=99s this full context that the receiver of the= identifier >>> needs to interpret it in. When using a federated identity protocol, eac= h RP >>> is going to have :some: kind of local user information store that they= =E2=80=99re >>> going to tie into, some field in a database they=E2=80=99ll key off of.= It=E2=80=99s just >>> never going to be the case that all RPs will be able to use server-prov= ided >>> opaque identifiers for all cases. Account recovery and binding is one s= uch >>> use case where a user-facing identifier like an email address makes a L= OT >>> of sense, for one small example. This is an array in the request and >>> response precisely because a user could be known by several different >>> identifiers to a party, and an RP will have a better idea about what ki= nds >>> of things it wants to correlate against, and it=E2=80=99s up to the AS = to provide >>> that mapping. I think that if we don=E2=80=99t define a way to describe= the format, >>> the =E2=80=9Cas_id=E2=80=9D field is going to get structure back-patche= d onto it like is >>> being proposed here: >>> >>> https://mattrglobal.github.io/oidc-portable-identities/ >>> >>> I=E2=80=99m personally not a fan of that approach as it mixes the data = layering >>> too much, and you end up making guesses about whether a field is meanin= gful >>> or a pointer. I think GNAP will be much better served by using a data >>> structure for this from the start. DIDs should be another =E2=80=9Cform= at=E2=80=9D of the >>> subject identifier. I don=E2=80=99t think GNAP should define this forma= t, and I=E2=80=99ve >>> dropped a note to the SECEVENT mailing list asking about adding DIDs to= the >>> subject identifiers draft before it gets published. DIDs are not >>> assertions, even in the cases where they point to fully functional DID >>> documents with user information in them. (And for what it=E2=80=99s wor= th, I think >>> the OIDC world should also use the SECEVENT draft inside ID Tokens to s= olve >>> the use case of the draft above). >>> >>> For the user !=3D RO cases, I think that potentially having a way to >>> signal those two items separately in the request and response could be >>> useful. Right now all the user/subject stuff is about identifying =E2= =80=9Cthe user >>> that=E2=80=99s currently here at the client instance=E2=80=9D, in a var= iety of forms that >>> the client instance and AS can negotiate. If the client or AS has some >>> other notion about who the RO is and how that could be separate from th= e >>> current user, we could provide a way to signal that like you=E2=80=99re= proposing >>> below. In my mental model, there are going to be a lot of use cases whe= re >>> the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the client at all, but = rather to the AS and is >>> based on what the client=E2=80=99s asking for. So I could identify the = current user >>> and ask for a specific medical record, and the AS realizes it has to go= bug >>> a particular doctor to approve things directly. This is instead of >>> interacting with the current user and failing in an awkward way when th= e >>> current user doesn=E2=80=99t have the rights to do things, but someone = else would. >>> But we=E2=80=99d want the system to be able to detect if the current us= er is the >>> doctor, so we can just interact with them directly. Does that all track= ? >>> >>> =E2=80=94 Justin >>> >>> On Mar 10, 2021, at 4:10 AM, Fabien Imbault >>> wrote: >>> >>> Hello, >>> >>> Notice the question mark in the title. Not to be considered as an >>> editor's comment. >>> This thread intends to provide a detailed comment on the >>> interesting feedback by Kristina: "I would catch up on the thread to >>> understand why DIDs are thought to be treated as assertions". >>> In the chat, I answered: "Happy to get the discussion on DIDs. Actually= , >>> could be either or, depending on what we intend to do." Let me expand a= bit >>> on that, to make it understandable (didn't have the time during the >>> meeting, unfortunately). >>> >>> This relates to the items described on slides 20 and 34, which I'll >>> explain further. I'll highlight as transparently as possible what I thi= nk >>> would be the benefits and downsides of each. Both are probably viable >>> options, but they correspond to different scopes and objectives. I'll s= pend >>> a bit more time on option 2, since it is a different approach compared = to >>> the current draft. >>> >>> *1. The first possibility is to use SECEVENT throughout. * >>> In that case, DIDs should be a part of sub_ids (in the core or in the >>> extension registry, depending on what Annabelle's WG decides). More >>> generally, the WG would have to decide which additional sub_ids it need= s >>> (as per Yaron's comment). >>> >>> That's obviously the closest to what is described in draft-04. It allow= s >>> a communication of subject information between the client and the AS, b= y >>> using global identifiers (mail, phone, etc.), or using a local opaque >>> reference - i.e. governed by the AS (that's probably what we would put = in >>> the examples, unless someone has a better idea - cf issues #16 and #42)= . >>> >>> Assertions relate for instance to the proof of presence of the RO. The >>> current draft-04 therefore plans for id_tokens and saml2, maybe there c= ould >>> be other needs later (extension registry). >>> >>> - Benefits: identifiers are a key component of GNAP, which makes >>> integration easier. Possibly one could choose to use DIDs throughout. >>> - Downsides: email/phone identifiers will probably be used throughout b= y >>> most devs (since that's correlation information they have in their user >>> DB). Which means we should limit what assertions contain, to avoid doin= g >>> links between weak global identifiers and hopefully stronger assertions= . >>> That's not really a problem if it's limited to authentication events mo= stly >>> (in that perspective, samlv2 could make sense in the core). An assertio= n is >>> probably a single value then (not an array). >>> >>> Option 1 can be summarized as: >>> >>> "subject": { >>> "sub_ids": { }, // request and response (SECEVENT -> including DID >>> possibly) >>> "assertions": [ ], // request and response (id_token o= r >>> samlv2) >>> } >>> ("hints" do not exist currently, but are partially covered separately >>> via "request.user" / the relevance of "principal", discussed in the sli= de, >>> is a question mark too - which is a different discussion on end-user != =3D RO). >>> >>> >>> *2. An alternate possibility is to use SECEVENT only as input/hint* >>> In that case, DIDs should be a part of assertions (which have a >>> different meaning compared to option 1). >>> >>> The AS only returns an local opaque reference as_ref (while in option 1= , >>> it was only one of many possibilities). Its only job is to help the cli= ent >>> differentiate the response subject. The AS policy might further define = the >>> scope of that reference, as suggested in >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210, although >>> I personally viewed that by default as (2) "as_id" an identifier locall= y >>> unique to that AS for all the RSs. >>> >>> SECEVENTS are still useful as an input, that's what I presented in >>> request.hints.self.sub_ids (but it's the responsibility of the AS to ma= tch >>> it with its own reference system - from instance from the email to AS's >>> local record XUT2MFM1XBIKJKSDU8Q). Note: since the slides, a new >>> draft-ietf-secevent-subject-identifiers-07 has been published. Notably = this >>> includes an opaque identifier, which the client can use to pass the as_= ref >>> hint to the AS. Thus we wouldn't need any further addition to >>> SECEVENT, although hints would benefit from further additions (like DID= s >>> for instance). Notice also that subject_types_supported becomes less >>> important, because in the worst case scenario, it's simply a hint that >>> wouldn't be understood and therefore taken into account by the AS. >>> >>> The assertions array has a more important role than in option 1 (with >>> the explicit aim of separating between client hints and validated info >>> asserted by the AS). It serves as a generic/extendible mapping structur= e, >>> e.g. "the AS asserts that opaque reference XUT2MFM1XBIKJKSDU8Q is >>> matching with these (more or less verifiable) statements." The name >>> assertion therefore corresponds to the responsibility of the AS in >>> delivering those statements (cf should/must, issue #49). Some of these >>> statements relate to identity or auth events (ex: DID, id_token), some >>> might directly be useful for authorization decisions (like ZKP example = in >>> the parental control example). Possibly some of these validated asserti= ons >>> could be reused in next interactions. >>> >>> Another question that popped-up is the scope of sub_ids. Should they be >>> about the same user? (I think so). In the case of remote ROs especially= , it >>> might be important that DID be considered as an assertion (about someon= e >>> else's) and not as sub_ids, because the AS needs to be careful about wh= o >>> the client wants to reach (avoid spam, etc.). This is consistent with t= he >>> rest of discussion on what to do when end-user !=3D RO, although using >>> DIDComm might seem a bit early (the paint is very fresh). >>> >>> Option 2 was summarized as: >>> >>> // (suggestion only, not as an editor) >>> "subject": { >>> "as_ref": { // response only (wouldn=E2=80=99t require SECEVENT) >>> =E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D, >>> =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D >>> }, >>> "assertions": [ ], // request and response >>> (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validated by the= AS) >>> >>> "hints": { // request only (optional) >>> "self": { // replaces request.user (support SECEVENT here) >>> =E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque in dra= ft-07 - that >>> could contain the ref) >>> =E2=80=9Cassertions=E2=80=9D: [ ] // see examples: VC on DOB or ZKP = on age (wider >>> scope, possibly through extensions) >>> }, >>> "principal": { // new proposal presented at IETF110 (just an idea= ) >>> =E2=80=9Cautomated=E2=80=9D: true, // rule engine >>> =E2=80=9Casync=E2=80=9D: { } // remote ROs >>> } >>> } >>> } >>> >>> - Benefits: as_ref is self supporting (no strong coupling with >>> SECEVENT), but can still take SECEVENT as an input hint for the AS. It >>> avoids the risk of making an official association between a weak global >>> identifier (e.g. email, used elsewhere) and hopefully stronger local >>> assertions. GNAP would be fully agnostic to whatever identity system is >>> used, only facilitating interoperability through assertions (second onl= y in >>> importance compared to the AS opaque reference). Some assertions (possi= bly >>> extensions) could also be useful for the AS decision (e.g. VC or ZKP). >>> - Downsides: opaqueness of as_ref is a feature, not a bug. The opaque >>> reference is fully managed by the AS, therefore not inherently portable= (cf >>> portability discussions in OIDC currently). There's no explicit binding= to >>> an official identity, only a contextual mapping to AS validated asserti= ons. >>> It makes it more difficult to match the identifiers from one AS to anot= her >>> or to correlate with the client user DB (still possible via assertions,= if >>> the AS allows it). Assertions are much more generic (possibly via >>> extensions), but might require a more advanced mechanism to >>> request/response only the most relevant information (which makes the AS >>> policy critical here). >>> >>> I hope that clarifies the reasoning for both options. Again I'm not >>> saying option 2 is better, just saying the trade-offs are different (+ >>> knowing that we need to keep it simple). >>> - option 1 puts more in sub_ids and less in assertions >>> - option 2 puts less in the reference and more in assertions >>> All of this is open to discussion. More generally speaking, on every >>> part in orange and question mark (?) I would love your ideas and >>> criticisms. What I intended as an editor is only to highlight where the= WG >>> has important choices to make, before we can make the related PRs. >>> >>> A further side comment: IETF EAT RATS was suggested for assertions, but >>> relates more to the client attestations. It was added as a comment in >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, which is >>> a distinct topic we'll work on. >>> >>> Fabien (editor's hat off) >>> >>> -- >>> 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 >> > > This communication, including any attachments, is confidential. If you ar= e not the intended recipient, you should not read it - please contact me im= mediately, destroy it, and do not copy or use any part of this communicatio= n or disclose anything about it. Thank you. Please note that this communica= tion does not designate an information system for the purposes of the Elect= ronic Transactions Act 2002. > > --000000000000e4e9f405bd3698bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tobias,

O= ption 2's pros and cons are the consequence of solely relying only on a= n opaque identifier managed by the AS, independantly from external identifi= ers.=C2=A0

That's an= additional level of indirection, not unlike how indexes are usually manage= d in a database. But there's obviously the additional complexity of mak= ing a just in time translation into a practical identifier (like email for = account recovery, as discussed by Justin).=C2=A0
"Asser= tions" should be what=C2=A0the AS (possibly with the assistance= of other parties) can confidently say about the subject.=C2=A0

Thanks for the great feedback, as well as Justin's.=C2=A0Sin= ce the slides were written, SECEVENT draft-07 already offers new possibilit= ies which is good news.=C2=A0

Fabien

Le mer. 10 mars 2021 =C3=A0 22:02, Tobias Looker <= ;tobias.looker@mattr.global> a =C3=A9crit=C2=A0:
> Thanks for the feedback, although I&= #39;m not sure what you mean by too abstract.

Apologies = what I mean by that was I feel like Option 2 would expose too much complexi= ty to clients that would be required to construct a request to the AS. Opti= on 1 IMO strikes a better balance by still offering the required flexibilit= y but keeping things relatively simple.

> Just = a quick comment: an assertion in option 2 is not "the fact the identif= ier is resolvable to cryptographic material that=C2=A0can=C2=A0be us= ed to validate cryptographic assertions". It is merely a statement by = the AS that "the subject corresponding to the reference has a DID"= ; ("has" is the assertion here).=C2=A0

Y= es I understand to drill down on this more though couldn't the entire r= equest made by the client to the AS also be considered to be an assertion? = Therefore the=C2=A0"sub_ids" request element is an assertion by t= he client about who it believes the subject to be identified as? If this is= true then to me the "assertions" request element is there for as= sertions that parties other than the client are making about the subject (e= .g an id_token).

Thanks,
=
3D"Mattr=C2=A0
Tobias Loo= ker
Mattr
+64 (0) 27 378 0461
tobias.looker@mattr.global
3D"Mattr<= a href=3D"https://www.linkedin.com/company/mattrglobal" style=3D"border:non= e;color:rgb(51,49,50);margin-right:12px" target=3D"_blank" rel=3D"noreferre= r">3D"Matt=3D"Mattr3D"Mattr
=
T= his communication, including any attachments, is confidential. If you are n= ot the intended recipient, you should not read it - please contact me immed= iately, destroy it, and do not copy or use any part of this communication o= r disclose anything about it. Thank you. Please note that this communicatio= n does not designate an information system for the purposes of the Electron= ic Transactions Act 2002.


On Thu, Mar 11, 2021 at 9:20 AM Fabien Imbault <fabien.imbault@g= mail.com> wrote:
Thanks Justin.

It's good to clarify what we mean by assertion. I used a mor= e mundane meaning.=C2=A0

I dislike email/phone as security disasters waiting to happen. I get that = they are practical.=C2=A0

I think I have what I need to write the PRs based on sub_ids (based on th= e current draft-07).=C2=A0

Fabien=C2=A0

Le mer. 10 mars 2021 =C3=A0 20:18, Justin Ric= her <jricher@mit.edu> a =C3=A9crit= =C2=A0:
Hi = Fabien,

First, thanks for doing the heavy lift of writin= g this topic up. Of these options, I would strongly prefer option (1). The = difference between assertions and identifiers is that an assertion is a ful= ly packaged set of attributes, one of which can be an identifier. They are,= generally speaking, cryptographically protected bundles. They=E2=80=99re d= esigned to carry a bunch of different information about a user and the auth= entication event in a form that=E2=80=99s independently verifiable and audi= table. SAML assertions (XML document) and ID Tokens (signed JWTs) are the m= ost common ones we see today, but other formats exist and will keep being i= nvented.=C2=A0

An identifier is a different kind o= f creature. It is a single statement that identifies the party in question = in the context of the party doing the identification. It=E2=80=99s this ful= l context that the receiver of the identifier needs to interpret it in. Whe= n using a federated identity protocol, each RP is going to have :some: kind= of local user information store that they=E2=80=99re going to tie into, so= me field in a database they=E2=80=99ll key off of. It=E2=80=99s just never = going to be the case that all RPs will be able to use server-provided opaqu= e identifiers for all cases. Account recovery and binding is one such use c= ase where a user-facing identifier like an email address makes a LOT of sen= se, for one small example. This is an array in the request and response pre= cisely because a user could be known by several different identifiers to a = party, and an RP will have a better idea about what kinds of things it want= s to correlate against, and it=E2=80=99s up to the AS to provide that mappi= ng. I think that if we don=E2=80=99t define a way to describe the format, t= he =E2=80=9Cas_id=E2=80=9D field is going to get structure back-patched ont= o it like is being proposed here:


I=E2=80= =99m personally not a fan of that approach as it mixes the data layering to= o much, and you end up making guesses about whether a field is meaningful o= r a pointer. I think GNAP will be much better served by using a data struct= ure for this from the start. DIDs should be another =E2=80=9Cformat=E2=80= =9D of the subject identifier. I don=E2=80=99t think GNAP should define thi= s format, and I=E2=80=99ve dropped a note to the SECEVENT mailing list aski= ng about adding DIDs to the subject identifiers draft before it gets publis= hed. DIDs are not assertions, even in the cases where they point to fully f= unctional DID documents with user information in them. (And for what it=E2= =80=99s worth, I think the OIDC world should also use the SECEVENT draft in= side ID Tokens to solve the use case of the draft above).

For the user !=3D RO cases, I think that potentially having a way t= o signal those two items separately in the request and response could be us= eful. Right now all the user/subject stuff is about identifying =E2=80=9Cth= e user that=E2=80=99s currently here at the client instance=E2=80=9D, in a = variety of forms that the client instance and AS can negotiate. If the clie= nt or AS has some other notion about who the RO is and how that could be se= parate from the current user, we could provide a way to signal that like yo= u=E2=80=99re proposing below. In my mental model, there are going to be a l= ot of use cases where the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the c= lient at all, but rather to the AS and is based on what the client=E2=80=99= s asking for. So I could identify the current user and ask for a specific m= edical record, and the AS realizes it has to go bug a particular doctor to = approve things directly. This is instead of interacting with the current us= er and failing in an awkward way when the current user doesn=E2=80=99t have= the rights to do things, but someone else would. But we=E2=80=99d want the= system to be able to detect if the current user is the doctor, so we can j= ust interact with them directly. Does that all track?

<= div>=C2=A0=E2=80=94 Justin

On Mar 10, 2021, at 4:10 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

<= div>
Hello,

Notice the question mark in = the title. Not to be considered as an editor's comment.
This = thread intends to provide a detailed comment on the interesting=C2=A0feedba= ck by Kristina: "I would catch up on the thread to understand why DIDs= are thought to be treated as assertions".
In the chat, I an= swered: "Happy to get the discussion on DIDs. Actually, could be eithe= r or, depending on what we intend to do." Let me expand a bit on that,= to make it understandable (didn't have the time during the meeting, un= fortunately).

This relates to the items described = on slides 20 and 34, which I'll explain further. I'll highlight as = transparently as possible what I think would be the benefits and downsides = of each. Both are probably viable options, but they correspond to different= scopes and objectives. I'll spend a bit more time on option 2, since i= t is a different approach compared to the current draft.

1. The = first possibility is to use SECEVENT throughout.=C2=A0
In tha= t case, DIDs should be a part of sub_ids (in the core or in the extension r= egistry, depending on what Annabelle's WG decides). More generally, the= WG would have to decide which additional sub_ids it needs (as per Yaron= 9;s comment).

That's obviously the closest to = what is described in draft-04. It allows a communication of subject informa= tion between the client and the AS, by using global identifiers (mail, phon= e, etc.), or using a local opaque reference=C2=A0- i.e. governed by the AS = (that's probably what we would=C2=A0put in the examples, unless someone= has a better idea - cf issues #16 and #42).=C2=A0

Assertions relate for instance to the proof of presence of the RO. The cur= rent draft-04 therefore plans for id_tokens and saml2, maybe there could be= other needs later (extension registry).

- Benefit= s: identifiers are a key component of GNAP, which makes integration easier.= Possibly one could choose to use DIDs throughout.
- Downsides: e= mail/phone identifiers will probably be used throughout by most devs (since= that's correlation information they=C2=A0have in their user DB). Which= means we should limit what assertions contain, to avoid doing links betwee= n weak global identifiers and hopefully stronger assertions. That's not= really a problem if it's limited to authentication events mostly (in t= hat perspective, samlv2 could make sense in the core). An assertion is prob= ably a single value then (not an array).=C2=A0 =C2=A0

<= div>
Option 1 can be summarized as:=C2=A0

"subject": {
=C2=A0=C2=A0=C2=A0"sub_ids": { }, // request and response (SECEVENT -> including DID possibly)=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=C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0=C2= =A0"assertions": [ ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 // request and response (id_token or samlv2)
=
}<= /span>
("hints" do not exist currently, but are partially covered separ= ately via "request.user" / the relevance of "principal"= , discussed in the slide, is a question mark too - which is a different dis= cussion on end-user !=3D RO).


2. An alternate possibility is to use SECEVENT only as input/hint
In that case, DIDs should be a part of assertions (which have a diffe= rent meaning compared to option 1).

The AS only re= turns an local opaque reference as_ref (while in option 1, it was only one = of many possibilities). Its only job is to help the client differentiate th= e response subject. The AS policy might further define the scope of that re= ference, as suggested in=C2=A0https://github.com/ietf-wg-gnap/gnap-cor= e-protocol/issues/210, although I personally=C2=A0viewed that by defaul= t as=C2=A0(2) "as_id" an identifier locally unique to that AS for= all the RSs.

SECEVENTS are still useful as an inp= ut, that's what I presented in request.hints.self.sub_ids (but it's= the responsibility=C2=A0of the AS to match it with its own reference syste= m - from instance from the email to AS's local record XUT2MFM1XBIKJKSDU= 8Q).=C2=A0Note: since the slides, a new draft-ietf-secevent-subject-identif= iers-07 has been published. Notably this includes an opaque identifier, whi= ch the client can use to pass the as_ref hint to the AS. Thus we wouldn'= ;t need any further addition to SECEVENT,=C2=A0although hints would benefit= from further additions (like DIDs for instance). Notice also that subject_= types_supported becomes less important, because in the worst case scenario,= it's simply=C2=A0a hint that wouldn't be understood and therefore = taken into account by the AS.

The assertions array= has a more important role than in option 1 (with the explicit aim of separ= ating between client hints and validated info asserted by the AS). It serve= s as a generic/extendible mapping structure, e.g. "the AS asserts that= opaque reference=C2=A0XUT2MFM1XBIKJKSDU8Q=C2=A0is matching with these (more = or less verifiable) statements." The name assertion therefore correspo= nds to the responsibility=C2=A0of the AS in delivering those statements (cf= should/must, issue #49). Some of these statements relate to identity or au= th events (ex: DID, id_token), some might directly be useful for authorizat= ion decisions (like ZKP example in the parental control example). Possibly = some of these validated assertions could be reused in next interactions.

Another question that popped-up is the scope of sub_= ids. Should they be about the same user? (I think so). In the case of remot= e ROs especially, it might be important that DID be considered as an assert= ion=C2=A0(about someone else's) and not as sub_ids, because the AS need= s to be careful about who the client wants to reach (avoid spam, etc.). Thi= s is consistent with the rest of discussion on what to do when end-user != =3D RO, although using DIDComm might seem a bit early (the paint is very fr= esh).=C2=A0

Option 2 was summarized as:=C2=A0

// (suggestion only, not as an editor)
"subject= ": {
=C2=A0=C2=A0=C2=A0"as_ref": { // response only (wouldn= =E2=80=99t require SECEVENT)
=E2=80=9Cas=E2=80= =9D: =E2=80=9Chttps://ex1.as.com= =E2=80=9D,
=E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJK= SDU8QM= =E2=80=9D=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=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"assertions"= : [ ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request and = response (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validate= d by the AS)

=C2=A0=C2=A0=C2=A0"= hints": { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 // request only (optional)
<= span style=3D"font-family:"Courier New";color:rgb(51,51,51);backg= round-color:rgb(247,247,247);font-variant-numeric:normal;font-variant-east-= asian:normal;vertical-align:baseline;white-space:pre-wrap">=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0"self": { // replaces request.user (support S= ECEVENT here)
=C2=A0=C2=A0=C2=A0=E2=80=9Csub_ids= =E2=80=9D: { }, // SECEVENT (including opaque in draft-07 - that could contain the re= f)
=C2=A0=C2=A0=C2=A0=E2=80=9Cassertions=E2=80= =9D: [ ] // see examples: VC on DOB or ZKP on age (wider scope, = possibly through extensions)
},=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= =C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"prin= cipal": { // new proposal presented at IETF= 110 (just an idea)
<= /span> =C2=A0 = =E2=80=9Cautomated=E2=80=9D: true, // rule engine
=C2=A0 =E2=80=9Casync=E2=80=9D: { } // remote ROs
}=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
<= div style=3D"line-height:1.2;margin-top:0pt;margin-bottom:0pt">=C2=A0=C2= =A0=C2=A0}
}

= - Benefits: as_ref is self supporting (no strong coupling with SECEVENT), b= ut can still take SECEVENT as an input hint for the AS. It avoids the risk = of making an official association between a weak global identifier (e.g. em= ail, used elsewhere) and hopefully stronger local assertions. GNAP would be= fully agnostic to whatever identity system is used, only facilitating inte= roperability through assertions (second only in importance=C2=A0compared to= the AS opaque reference). Some assertions (possibly extensions) could also= be useful for the AS decision (e.g. VC or ZKP).
- Downsides: opa= queness of as_ref is a feature, not a bug. The opaque reference is fully ma= naged by the AS, therefore not inherently portable (cf portability discussi= ons in OIDC currently). There's no explicit binding to an official iden= tity, only a contextual mapping to AS validated assertions. It makes it mor= e difficult to match the identifiers from one AS to another or to correlate= with the client user DB (still possible via assertions, if the AS allows i= t). Assertions are much more generic (possibly via extensions), but might r= equire a more advanced mechanism=C2=A0to request/response only the most rel= evant information (which makes the AS policy critical here).

=
I hope that clarifies the=C2=A0reasoning for both options. Again= I'm not saying option 2 is better, just saying the trade-offs are diff= erent (+ knowing that we need to keep it simple).
- option 1 puts= more in sub_ids and less in assertions
- option 2 puts less in t= he reference and more in assertions=C2=A0
All of this is open to = discussion. More generally speaking, on every part in orange and question m= ark (?) I would love your ideas and criticisms. What I intended as an edito= r is only to highlight where the WG has important choices to make, before w= e can make the related PRs.

A further side comment= : IETF EAT RATS was suggested for assertions, but relates more to the clien= t attestations. It was added as a comment in=C2=A0https://github.com/ie= tf-wg-gnap/gnap-core-protocol/issues/44, which is a distinct topic we&#= 39;ll work on.

Fabien (editor's hat off)
=

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


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

This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.
--000000000000e4e9f405bd3698bc-- From nobody Thu Mar 11 02:44:39 2021 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 502643A18AF for ; Thu, 11 Mar 2021 02:44:37 -0800 (PST) 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 M18AykSw6393 for ; Thu, 11 Mar 2021 02:44:33 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 5B9503A18B1 for ; Thu, 11 Mar 2021 02:44:33 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id n14so21394403iog.3 for ; Thu, 11 Mar 2021 02:44:33 -0800 (PST) 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=z96uwMl5hiBAb9EKiiSoFSaVjp9opkE2VDZ/C6bB1Is=; b=j580FWLOfTdtt9QVeXCZJ0BTBV4bq4/kLr68LldItEWXvXiz6dEI/EtvB4PaaeqTpx FtMn3LHkw6Wrs2SDU6JauAITab2hMixU9zed5am9ANcKjvM9yAp/pfgYylYTZp08LA9e dh5hOgcKguNprQ6QOGMGOJqC+6ZOqi9rOk3W6W6x3FMgCgwyVUvbWXxLcPWMN+EN1UjI uqhhH5OaKomevmJTJu7SueZvGaC5ha81b2/aIBetPG0O7ybBZjcN220Gslbsgvl30M1K bwVRvckMwhRFZnm85bVgCi2znrZ8u12HK5DCl5Rspgp1UE60U3/JGoQl7DKR0U/OZgh0 HdIQ== 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=z96uwMl5hiBAb9EKiiSoFSaVjp9opkE2VDZ/C6bB1Is=; b=ErUBMzy6s8I0YQsaRSj6waWHrCtS+6JKlRmiCy4ZAA/UFSi3FPyfihNMbZyKFmu0Sz Wvm/FcJGfjRS1n5OBXyoQhousGXeFqrfwAK6+fDe+pZsEQmYCJfwh4qybPdcgzqfP4oe +M28Q/+7afPAPqJt2/6QwAHCxW3sWTGz8d35bz2LkRBwcARgotqynvCuJONbn4EOXsDZ N5Fz3L+SLmUS5aUcGQG4dsru4rZpcMUjRUGc1M/0XyWIyWK8J/4J/Zu4Fq4j3uyQOo0V jqhyt/ZlCcsX6v459LQtxLWlQ0UTyTv3+1ldnlDo8kpztuVaHAQyzqgd9UqdWimPjmeh juHg== X-Gm-Message-State: AOAM530I7CQXOPjOYpxQjMoklAun34b0HF/yZ1K3BdCKNmSUgQbJBkfU ovOih8uQWHmsxPzK51i5O9tly/EjUZ7GSviI44s= X-Google-Smtp-Source: ABdhPJz1R0vWbdVaL7lXfqRNnrwBj1QftdhtgKDXqmUFZOGh/R2Oufm2MrKjTM9XJjOUL2gkiOwNp/qSnQj0gu2czoo= X-Received: by 2002:a02:94cb:: with SMTP id x69mr3019113jah.8.1615459471506; Thu, 11 Mar 2021 02:44:31 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Thu, 11 Mar 2021 11:44:20 +0100 Message-ID: To: Justin Richer Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000f2c3bc05bd407728" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 10:44:37 -0000 --000000000000f2c3bc05bd407728 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Justin, I think that's interesting: "For the user !=3D RO cases, I think that potentially having a way to signa= l those two items separately in the request and response could be useful. Right now all the user/subject stuff is about identifying =E2=80=9Cthe user= that=E2=80=99s currently here at the client instance=E2=80=9D, in a variety of forms that = the client instance and AS can negotiate. If the client or AS has some other notion about who the RO is and how that could be separate from the current user, we could provide a way to signal that like you=E2=80=99re proposing b= elow. In my mental model, there are going to be a lot of use cases where the =E2=80= =9CRO=E2=80=9D isn=E2=80=99t known to the client at all, but rather to the AS and is based= on what the client=E2=80=99s asking for. So I could identify the current user and a= sk for a specific medical record, and the AS realizes it has to go bug a particular doctor to approve things directly. This is instead of interacting with the current user and failing in an awkward way when the current user doesn=E2= =80=99t have the rights to do things, but someone else would. But we=E2=80=99d want= the system to be able to detect if the current user is the doctor, so we can just interact with them directly. Does that all track?" I agree with the general idea. In the end, that's the AS's responsibility (and also a big part of its value as a policy engine). Even in the cases - as I suggested - where the client would be able to signal what it knows (or thinks it knows) about the subject, the AS still needs to validate what it can. The client could be an attacker lying to the AS. Or there could be an unintended bug. The client still seems like a straightforward source to gather optional/declarative hints. Which is what request.user is already doing in spirit. In many cases, the AS should go a step further. Validate cryptographic statements from a more reputable issuer, whatever helps. Contacts might be one of the possibilities. I'm not suggesting interact/fail scenarii at all, which I see as anti-ergonomic (composability with timeouts and fallback is the answer to that). The failure I was considering is only for async calls explicitly requested by the client (which is considered in sequence 1.4.3, and not coming from me), there's obviously no way to ensure a remote RO would actually respond when the client expects it. If that sequence is considered, realistic failure modes should be anticipated and dealt with internally (just like any distributed program would do), is all I'm saying. And so from the outside, there's no interact/fail. That's the same as in real life: when booking a business trip, an employee could either follow the generic rule (2nd class train ticket) or reach out to his manager, explaining that it's a long trip and that 1st class would be better. The employee knows the manager might not instantly respond, and knows that the absence of an answer means he'll have to go for the 2nd class. There will be cases when the client doesn't know the RO. I'm not sure if that's a majority of cases, but it will definitely happen. It could happen when you interact with an organization or a team and have no idea who's responsible or what delegations are in place (some of those cases have been described by Adrian for instance). There could also be cases where the ownership could be distributed (an example was provided when considering remote ROs). Again in real life, it's not unusual for a decision to fallback on a deputy when the main decision maker is unavailable. Or there could be an open governance even, but maybe that's one step too far. Of course, if the AS has internal knowledge or other ways to get the information it should use it. Remains to be seen how we can specify that (cf issue #49 on should/must). The example with doctor/patient is fine if hardcoded, but it becomes a problem when we fail to understand the real relationships in environments of various sensitive nature. How the AS identifies that a specific record requires approval from Doctor Bob might be context dependent (sometimes it could be a nurse, a team of doctors, another medical organization, etc.). Maybe you could have various levels of authorizations (extreme example: military style classifications), so that it might even be impossible to tell who can be contacted. That's also why I was suggesting assertions could go beyond authentication events, and include cryptographic assertions for authorization purposes. Maybe we can even imagine a risk based approach, as in some cases we won't know for sure. The difficulty will be to be sufficiently generic but simple enough. Maybe we can rule out some cases. Maybe remote async contacts are out of scope, because we only want instantaneous authorizations. Most of those cases are way beyond what OAuth2 does. I don't know. But what's certain is that the WG should decide what support for cases where end-user !=3D RO it intends to provide. My discussion was just a very small Chesterston's Fence contribution, even if that seems to have surprised. Fabien On Wed, Mar 10, 2021 at 8:18 PM Justin Richer wrote: > Hi Fabien, > > First, thanks for doing the heavy lift of writing this topic up. Of these > options, I would strongly prefer option (1). The difference between > assertions and identifiers is that an assertion is a fully packaged set o= f > attributes, one of which can be an identifier. They are, generally > speaking, cryptographically protected bundles. They=E2=80=99re designed t= o carry a > bunch of different information about a user and the authentication event = in > a form that=E2=80=99s independently verifiable and auditable. SAML assert= ions (XML > document) and ID Tokens (signed JWTs) are the most common ones we see > today, but other formats exist and will keep being invented. > > An identifier is a different kind of creature. It is a single statement > that identifies the party in question in the context of the party doing t= he > identification. It=E2=80=99s this full context that the receiver of the i= dentifier > needs to interpret it in. When using a federated identity protocol, each = RP > is going to have :some: kind of local user information store that they=E2= =80=99re > going to tie into, some field in a database they=E2=80=99ll key off of. I= t=E2=80=99s just > never going to be the case that all RPs will be able to use server-provid= ed > opaque identifiers for all cases. Account recovery and binding is one suc= h > use case where a user-facing identifier like an email address makes a LOT > of sense, for one small example. This is an array in the request and > response precisely because a user could be known by several different > identifiers to a party, and an RP will have a better idea about what kind= s > of things it wants to correlate against, and it=E2=80=99s up to the AS to= provide > that mapping. I think that if we don=E2=80=99t define a way to describe t= he format, > the =E2=80=9Cas_id=E2=80=9D field is going to get structure back-patched = onto it like is > being proposed here: > > https://mattrglobal.github.io/oidc-portable-identities/ > > I=E2=80=99m personally not a fan of that approach as it mixes the data la= yering > too much, and you end up making guesses about whether a field is meaningf= ul > or a pointer. I think GNAP will be much better served by using a data > structure for this from the start. DIDs should be another =E2=80=9Cformat= =E2=80=9D of the > subject identifier. I don=E2=80=99t think GNAP should define this format,= and I=E2=80=99ve > dropped a note to the SECEVENT mailing list asking about adding DIDs to t= he > subject identifiers draft before it gets published. DIDs are not > assertions, even in the cases where they point to fully functional DID > documents with user information in them. (And for what it=E2=80=99s worth= , I think > the OIDC world should also use the SECEVENT draft inside ID Tokens to sol= ve > the use case of the draft above). > > For the user !=3D RO cases, I think that potentially having a way to sign= al > those two items separately in the request and response could be useful. > Right now all the user/subject stuff is about identifying =E2=80=9Cthe us= er that=E2=80=99s > currently here at the client instance=E2=80=9D, in a variety of forms tha= t the > client instance and AS can negotiate. If the client or AS has some other > notion about who the RO is and how that could be separate from the curren= t > user, we could provide a way to signal that like you=E2=80=99re proposing= below. In > my mental model, there are going to be a lot of use cases where the =E2= =80=9CRO=E2=80=9D > isn=E2=80=99t known to the client at all, but rather to the AS and is bas= ed on what > the client=E2=80=99s asking for. So I could identify the current user and= ask for a > specific medical record, and the AS realizes it has to go bug a particula= r > doctor to approve things directly. This is instead of interacting with th= e > current user and failing in an awkward way when the current user doesn=E2= =80=99t > have the rights to do things, but someone else would. But we=E2=80=99d wa= nt the > system to be able to detect if the current user is the doctor, so we can > just interact with them directly. Does that all track? > > =E2=80=94 Justin > > On Mar 10, 2021, at 4:10 AM, Fabien Imbault > wrote: > > Hello, > > Notice the question mark in the title. Not to be considered as an editor'= s > comment. > This thread intends to provide a detailed comment on the > interesting feedback by Kristina: "I would catch up on the thread to > understand why DIDs are thought to be treated as assertions". > In the chat, I answered: "Happy to get the discussion on DIDs. Actually, > could be either or, depending on what we intend to do." Let me expand a b= it > on that, to make it understandable (didn't have the time during the > meeting, unfortunately). > > This relates to the items described on slides 20 and 34, which I'll > explain further. I'll highlight as transparently as possible what I think > would be the benefits and downsides of each. Both are probably viable > options, but they correspond to different scopes and objectives. I'll spe= nd > a bit more time on option 2, since it is a different approach compared to > the current draft. > > *1. The first possibility is to use SECEVENT throughout. * > In that case, DIDs should be a part of sub_ids (in the core or in the > extension registry, depending on what Annabelle's WG decides). More > generally, the WG would have to decide which additional sub_ids it needs > (as per Yaron's comment). > > That's obviously the closest to what is described in draft-04. It allows = a > communication of subject information between the client and the AS, by > using global identifiers (mail, phone, etc.), or using a local opaque > reference - i.e. governed by the AS (that's probably what we would put in > the examples, unless someone has a better idea - cf issues #16 and #42). > > Assertions relate for instance to the proof of presence of the RO. The > current draft-04 therefore plans for id_tokens and saml2, maybe there cou= ld > be other needs later (extension registry). > > - Benefits: identifiers are a key component of GNAP, which makes > integration easier. Possibly one could choose to use DIDs throughout. > - Downsides: email/phone identifiers will probably be used throughout by > most devs (since that's correlation information they have in their user > DB). Which means we should limit what assertions contain, to avoid doing > links between weak global identifiers and hopefully stronger assertions. > That's not really a problem if it's limited to authentication events most= ly > (in that perspective, samlv2 could make sense in the core). An assertion = is > probably a single value then (not an array). > > Option 1 can be summarized as: > > "subject": { > "sub_ids": { }, // request and response (SECEVENT -> including DID > possibly) > "assertions": [ ], // request and response (id_token or > samlv2) > } > ("hints" do not exist currently, but are partially covered separately via > "request.user" / the relevance of "principal", discussed in the slide, is= a > question mark too - which is a different discussion on end-user !=3D RO). > > > *2. An alternate possibility is to use SECEVENT only as input/hint* > In that case, DIDs should be a part of assertions (which have a different > meaning compared to option 1). > > The AS only returns an local opaque reference as_ref (while in option 1, > it was only one of many possibilities). Its only job is to help the clien= t > differentiate the response subject. The AS policy might further define th= e > scope of that reference, as suggested in > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210, although I > personally viewed that by default as (2) "as_id" an identifier locally > unique to that AS for all the RSs. > > SECEVENTS are still useful as an input, that's what I presented in > request.hints.self.sub_ids (but it's the responsibility of the AS to matc= h > it with its own reference system - from instance from the email to AS's > local record XUT2MFM1XBIKJKSDU8Q). Note: since the slides, a new > draft-ietf-secevent-subject-identifiers-07 has been published. Notably th= is > includes an opaque identifier, which the client can use to pass the as_re= f > hint to the AS. Thus we wouldn't need any further addition to > SECEVENT, although hints would benefit from further additions (like DIDs > for instance). Notice also that subject_types_supported becomes less > important, because in the worst case scenario, it's simply a hint that > wouldn't be understood and therefore taken into account by the AS. > > The assertions array has a more important role than in option 1 (with the > explicit aim of separating between client hints and validated info assert= ed > by the AS). It serves as a generic/extendible mapping structure, e.g. "th= e > AS asserts that opaque reference XUT2MFM1XBIKJKSDU8Q is matching with > these (more or less verifiable) statements." The name assertion therefore > corresponds to the responsibility of the AS in delivering those statement= s > (cf should/must, issue #49). Some of these statements relate to identity = or > auth events (ex: DID, id_token), some might directly be useful for > authorization decisions (like ZKP example in the parental control example= ). > Possibly some of these validated assertions could be reused in next > interactions. > > Another question that popped-up is the scope of sub_ids. Should they be > about the same user? (I think so). In the case of remote ROs especially, = it > might be important that DID be considered as an assertion (about someone > else's) and not as sub_ids, because the AS needs to be careful about who > the client wants to reach (avoid spam, etc.). This is consistent with the > rest of discussion on what to do when end-user !=3D RO, although using > DIDComm might seem a bit early (the paint is very fresh). > > Option 2 was summarized as: > > // (suggestion only, not as an editor) > "subject": { > "as_ref": { // response only (wouldn=E2=80=99t require SECEVENT) > =E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D, > =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D > }, > "assertions": [ ], // request and response > (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validated by the A= S) > > "hints": { // request only (optional) > "self": { // replaces request.user (support SECEVENT here) > =E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque in draft= -07 - that could > contain the ref) > =E2=80=9Cassertions=E2=80=9D: [ ] // see examples: VC on DOB or ZKP on= age (wider > scope, possibly through extensions) > }, > "principal": { // new proposal presented at IETF110 (just an idea) > =E2=80=9Cautomated=E2=80=9D: true, // rule engine > =E2=80=9Casync=E2=80=9D: { } // remote ROs > } > } > } > > - Benefits: as_ref is self supporting (no strong coupling with SECEVENT), > but can still take SECEVENT as an input hint for the AS. It avoids the ri= sk > of making an official association between a weak global identifier (e.g. > email, used elsewhere) and hopefully stronger local assertions. GNAP woul= d > be fully agnostic to whatever identity system is used, only facilitating > interoperability through assertions (second only in importance compared t= o > the AS opaque reference). Some assertions (possibly extensions) could als= o > be useful for the AS decision (e.g. VC or ZKP). > - Downsides: opaqueness of as_ref is a feature, not a bug. The opaque > reference is fully managed by the AS, therefore not inherently portable (= cf > portability discussions in OIDC currently). There's no explicit binding t= o > an official identity, only a contextual mapping to AS validated assertion= s. > It makes it more difficult to match the identifiers from one AS to anothe= r > or to correlate with the client user DB (still possible via assertions, i= f > the AS allows it). Assertions are much more generic (possibly via > extensions), but might require a more advanced mechanism to > request/response only the most relevant information (which makes the AS > policy critical here). > > I hope that clarifies the reasoning for both options. Again I'm not sayin= g > option 2 is better, just saying the trade-offs are different (+ knowing > that we need to keep it simple). > - option 1 puts more in sub_ids and less in assertions > - option 2 puts less in the reference and more in assertions > All of this is open to discussion. More generally speaking, on every part > in orange and question mark (?) I would love your ideas and criticisms. > What I intended as an editor is only to highlight where the WG has > important choices to make, before we can make the related PRs. > > A further side comment: IETF EAT RATS was suggested for assertions, but > relates more to the client attestations. It was added as a comment in > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, which is a > distinct topic we'll work on. > > Fabien (editor's hat off) > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --000000000000f2c3bc05bd407728 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Justin,

I think that's interesti= ng:
"For the user !=3D RO cases, I think that potential= ly having a way to signal those two items separately in the request and res= ponse could be useful. Right now all the user/subject stuff is about identi= fying =E2=80=9Cthe user that=E2=80=99s currently here at the client instanc= e=E2=80=9D, in a variety of forms that the client instance and AS can negot= iate. If the client or AS has some other notion about who the RO is and how= that could be separate from the current user, we could provide a way to si= gnal that like you=E2=80=99re proposing below. In my mental model, there ar= e going to be a lot of use cases where the =E2=80=9CRO=E2=80=9D isn=E2=80= =99t known to the client at all, but rather to the AS and is based on what = the client=E2=80=99s asking for. So I could identify the current user and a= sk for a specific medical record, and the AS realizes it has to go bug a pa= rticular doctor to approve things directly. This is instead of interacting = with the current user and failing in an awkward way when the current user d= oesn=E2=80=99t have the rights to do things, but someone else would. But we= =E2=80=99d want the system to be able to detect if the current user is the = doctor, so we can just interact with them directly. Does that all track?&qu= ot;

I agree with the general idea. In the end, tha= t's the AS's responsibility (and also a big part of its value as a = policy engine). =C2=A0

Even in the cases - as I su= ggested - where the client would be able to signal what it knows (or thinks= it knows) about the subject, the AS still needs to validate what it can. T= he client could be an attacker lying to the AS. Or there could be an uninte= nded bug.=C2=A0

The=C2=A0client still seems like a= straightforward source to gather optional/declarative hints. Which is what= request.user is already doing in spirit. In many cases, the AS should go a= step further. Validate cryptographic statements from a more reputable issu= er, whatever helps.

Contacts might be one of the p= ossibilities. I'm not suggesting interact/fail scenarii at all, which I= see as anti-ergonomic (composability with timeouts and fallback is the ans= wer to that). The failure I was considering is only for async calls explici= tly requested by the client (which is considered in sequence 1.4.3, and not= coming from me), there's obviously no way to ensure a remote RO would = actually respond when the client expects it. If that sequence is considered= , realistic failure modes should be anticipated and dealt with internally (= just like any distributed program would do), is all I'm saying. And so = from the outside, there's no interact/fail.=C2=A0=C2=A0
That&= #39;s the same as in real life: when booking a business trip, an employee c= ould either follow the generic rule (2nd class train ticket) or reach out t= o his manager, explaining that it's a long trip and that 1st class woul= d be better. The employee knows the manager might not instantly respond, an= d knows that the absence of an answer means he'll have to go for the 2n= d class.=C2=A0

There will be cases when the=C2= =A0client doesn't know the=C2=A0RO. I'm not sure if that's a ma= jority of cases, but it will definitely happen. It could happen when you in= teract with an organization or a team and have no idea who's responsibl= e or what delegations are in place (some of those cases have been described= by Adrian for instance).=C2=A0
There could also be cases where t= he ownership could be distributed (an example was provided when considering= remote ROs). Again in real life, it's not unusual for a decision to fa= llback on a deputy when the main decision maker is unavailable. Or there co= uld be an open governance even, but maybe that's one step too far.

Of course, if the AS has internal knowledge or other w= ays to get the information it should use it. Remains to be seen how we can = specify that (cf issue #49 on should/must). The example with doctor/patient= is fine if hardcoded, but it becomes a problem when we fail to understand = the real relationships in environments of various sensitive nature. How the= AS identifies that a specific record requires approval from Doctor Bob mig= ht be context dependent (sometimes it could be a nurse, a team of doctors, = another medical organization, etc.). Maybe you could have various levels of= authorizations (extreme example: military style classifications), so that = it might even be impossible to tell who can be contacted.=C2=A0
<= br>
That's also why I was suggesting assertions could go beyo= nd authentication events, and include cryptographic assertions for authoriz= ation purposes. Maybe we can even imagine a risk based approach, as in some= cases we won't know for sure.=C2=A0

The diffi= culty will be to be sufficiently generic but simple enough. Maybe we can ru= le out some cases. Maybe remote async contacts are out of scope,=C2=A0becau= se we only want instantaneous authorizations. Most of those cases are way b= eyond what OAuth2 does. I don't know. But what's certain is that th= e WG should decide what support for cases where end-user !=3D RO it intends= to provide. My discussion was just a very small Chesterston's Fence co= ntribution, even if that seems to have surprised.

= Fabien


<= div class=3D"gmail_quote">
On Wed, Mar= 10, 2021 at 8:18 PM Justin Richer <j= richer@mit.edu> wrote:
Hi Fabien,

=
First, thanks for doing the heavy lift of writing this topic up.= Of these options, I would strongly prefer option (1). The difference betwe= en assertions and identifiers is that an assertion is a fully packaged set = of attributes, one of which can be an identifier. They are, generally speak= ing, cryptographically protected bundles. They=E2=80=99re designed to carry= a bunch of different information about a user and the authentication event= in a form that=E2=80=99s independently verifiable and auditable. SAML asse= rtions (XML document) and ID Tokens (signed JWTs) are the most common ones = we see today, but other formats exist and will keep being invented.=C2=A0

An identifier is a different kind of creature. It i= s a single statement that identifies the party in question in the context o= f the party doing the identification. It=E2=80=99s this full context that t= he receiver of the identifier needs to interpret it in. When using a federa= ted identity protocol, each RP is going to have :some: kind of local user i= nformation store that they=E2=80=99re going to tie into, some field in a da= tabase they=E2=80=99ll key off of. It=E2=80=99s just never going to be the = case that all RPs will be able to use server-provided opaque identifiers fo= r all cases. Account recovery and binding is one such use case where a user= -facing identifier like an email address makes a LOT of sense, for one smal= l example. This is an array in the request and response precisely because a= user could be known by several different identifiers to a party, and an RP= will have a better idea about what kinds of things it wants to correlate a= gainst, and it=E2=80=99s up to the AS to provide that mapping. I think that= if we don=E2=80=99t define a way to describe the format, the =E2=80=9Cas_i= d=E2=80=9D field is going to get structure back-patched onto it like is bei= ng proposed here:


I=E2=80=99m= personally not a fan of that approach as it mixes the data layering too mu= ch, and you end up making guesses about whether a field is meaningful or a = pointer. I think GNAP will be much better served by using a data structure = for this from the start. DIDs should be another =E2=80=9Cformat=E2=80=9D of= the subject identifier. I don=E2=80=99t think GNAP should define this form= at, and I=E2=80=99ve dropped a note to the SECEVENT mailing list asking abo= ut adding DIDs to the subject identifiers draft before it gets published. D= IDs are not assertions, even in the cases where they point to fully functio= nal DID documents with user information in them. (And for what it=E2=80=99s= worth, I think the OIDC world should also use the SECEVENT draft inside ID= Tokens to solve the use case of the draft above).

For the user !=3D RO cases, I think that potentially having a way to signa= l those two items separately in the request and response could be useful. R= ight now all the user/subject stuff is about identifying =E2=80=9Cthe user = that=E2=80=99s currently here at the client instance=E2=80=9D, in a variety= of forms that the client instance and AS can negotiate. If the client or A= S has some other notion about who the RO is and how that could be separate = from the current user, we could provide a way to signal that like you=E2=80= =99re proposing below. In my mental model, there are going to be a lot of u= se cases where the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the client a= t all, but rather to the AS and is based on what the client=E2=80=99s askin= g for. So I could identify the current user and ask for a specific medical = record, and the AS realizes it has to go bug a particular doctor to approve= things directly. This is instead of interacting with the current user and = failing in an awkward way when the current user doesn=E2=80=99t have the ri= ghts to do things, but someone else would. But we=E2=80=99d want the system= to be able to detect if the current user is the doctor, so we can just int= eract with them directly. Does that all track?

=C2= =A0=E2=80=94 Justin

On Ma= r 10, 2021, at 4:10 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:
=
Hello,

Notice the question mar= k in the title. Not to be considered as an editor's comment.
= This thread intends to provide a detailed comment on the interesting=C2=A0f= eedback by Kristina: "I would catch up on the thread to understand why= DIDs are thought to be treated as assertions".
In the chat,= I answered: "Happy to get the discussion on DIDs. Actually, could be = either or, depending on what we intend to do." Let me expand a bit on = that, to make it understandable (didn't have the time during the meetin= g, unfortunately).

This relates to the items descr= ibed on slides 20 and 34, which I'll explain further. I'll highligh= t as transparently as possible what I think would be the benefits and downs= ides of each. Both are probably viable options, but they correspond to diff= erent scopes and objectives. I'll spend a bit more time on option 2, si= nce it is a different approach compared to the current draft.

1.= The first possibility is to use SECEVENT throughout.=C2=A0
I= n that case, DIDs should be a part of sub_ids (in the core or in the extens= ion registry, depending on what Annabelle's WG decides). More generally= , the WG would have to decide which additional sub_ids it needs (as per Yar= on's comment).

That's obviously the closes= t to what is described in draft-04. It allows a communication of subject in= formation between the client and the AS, by using global identifiers (mail,= phone, etc.), or using a local opaque reference=C2=A0- i.e. governed by th= e AS (that's probably what we would=C2=A0put in the examples, unless so= meone has a better idea - cf issues #16 and #42).=C2=A0

Assertions relate for instance to the proof of presence of the RO. Th= e current draft-04 therefore plans for id_tokens and saml2, maybe there cou= ld be other needs later (extension registry).

- Be= nefits: identifiers are a key component of GNAP, which makes integration ea= sier. Possibly one could choose to use DIDs throughout.
- Downsid= es: email/phone identifiers will probably be used throughout by most devs (= since that's correlation information they=C2=A0have in their user DB). = Which means we should limit what assertions contain, to avoid doing links b= etween weak global identifiers and hopefully stronger assertions. That'= s not really a problem if it's limited to authentication events mostly = (in that perspective, samlv2 could make sense in the core). An assertion is= probably a single value then (not an array).=C2=A0 =C2=A0

Option 1 can be summarized as:=C2=A0

"subject": {
=C2=A0=C2=A0=C2=A0"= ;sub_ids": { }, // request and response (S= ECEVENT -> including DID possibly)=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=C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0"assertions": [ = ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request and resp= onse (id_token or samlv2)
}
("hints" do not exi= st currently, but are partially covered separately via "request.user&q= uot; / the relevance of "principal", discussed in the slide, is a= question mark too - which is a different discussion on end-user !=3D RO).<= /div>


2. An alternate possibility i= s to use SECEVENT only as input/hint
In that case, DIDs shoul= d be a part of assertions (which have a different meaning compared to optio= n 1).

The AS only returns an local opaque referenc= e as_ref (while in option 1, it was only one of many possibilities). Its on= ly job is to help the client differentiate the response subject. The AS pol= icy might further define the scope of that reference, as suggested in=C2=A0= https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/= 210, although I personally=C2=A0viewed that by default as=C2=A0(2) &quo= t;as_id" an identifier locally unique to that AS for all the RSs.

SECEVENTS are still useful as an input, that's wha= t I presented in request.hints.self.sub_ids (but it's the responsibilit= y=C2=A0of the AS to match it with its own reference system - from instance = from the email to AS's local record XUT2MFM1XBIKJKSDU8Q).=C2=A0Note: si= nce the slides, a new draft-ietf-secevent-subject-identifiers-07 has been p= ublished. Notably this includes an opaque identifier, which the client can = use to pass the as_ref hint to the AS. Thus we wouldn't need any furthe= r addition to SECEVENT,=C2=A0although hints would benefit from further addi= tions (like DIDs for instance). Notice also that subject_types_supported be= comes less important, because in the worst case scenario, it's simply= =C2=A0a hint that wouldn't be understood and therefore taken into accou= nt by the AS.

The assertions array has a more impo= rtant role than in option 1 (with the explicit aim of separating between cl= ient hints and validated info asserted by the AS). It serves as a generic/e= xtendible mapping structure, e.g. "the AS asserts that opaque referenc= e=C2=A0XU= T2MFM1XBIKJKSDU8Q=C2=A0is matching with these (more or less verifiab= le) statements." The name assertion therefore corresponds to the respo= nsibility=C2=A0of the AS in delivering those statements (cf should/must, is= sue #49). Some of these statements relate to identity or auth events (ex: D= ID, id_token), some might directly be useful for authorization decisions (l= ike ZKP example in the parental control example). Possibly some of these va= lidated assertions could be reused in next interactions.

Another question that popped-up is the scope of sub_ids. Should they= be about the same user? (I think so). In the case of remote ROs especially= , it might be important that DID be considered as an assertion=C2=A0(about = someone else's) and not as sub_ids, because the AS needs to be careful = about who the client wants to reach (avoid spam, etc.). This is consistent = with the rest of discussion on what to do when end-user !=3D RO, although u= sing DIDComm might seem a bit early (the paint is very fresh).=C2=A0
<= div>
Option 2 was summarized as:=C2=A0

// (suggestion only, not as an editor)=
"subject": {
=C2=A0=C2=A0=C2=A0"as_ref&= quot;: { = = = /= / response only (wouldn=E2=80=99t require SECEVENT)
=E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D, <= /span>
= =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D=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= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<= /div>
=C2= =A0=C2=A0=C2=A0"assertions": [ ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 // request and response (id_token/jwkthumb/DID/VC/etc= . -> whatever info can be validated by the AS)

=C2=A0=C2=A0=C2=A0"hints": { =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request only= (optional)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"self":= { =C2=A0=C2=A0=C2=A0=E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque in= draft-07 - that could contain the ref)
=C2=A0= =C2=A0=C2=A0=E2=80=9Cassertions=E2=80=9D: [ ] // see examples: V= C on DOB or ZKP on age (wider scope, possibly through extensions) <= /span>
},=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=C2=A0=C2=A0=C2=A0
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"principal": { // new proposal presented at IETF110 (just an idea)
=C2=A0 =E2=80=9Cautomated=E2=80=9D: true, // rule eng= ine
=C2=A0 =E2=80=9Casync=E2= =80=9D: { } // remote ROs
}=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=C2=A0=C2=A0}
}<= /div>

- Benefits: as_ref is self supporting= (no strong coupling with SECEVENT), but can still take SECEVENT as an inpu= t hint for the AS. It avoids the risk of making an official association bet= ween a weak global identifier (e.g. email, used elsewhere) and hopefully st= ronger local assertions. GNAP would be fully agnostic to whatever identity = system is used, only facilitating interoperability through assertions (seco= nd only in importance=C2=A0compared to the AS opaque reference). Some asser= tions (possibly extensions) could also be useful for the AS decision (e.g. = VC or ZKP).
- Downsides: opaqueness of as_ref is a feature, not a= bug. The opaque reference is fully managed by the AS, therefore not inhere= ntly portable (cf portability discussions in OIDC currently). There's n= o explicit binding to an official identity, only a contextual mapping to AS= validated assertions. It makes it more difficult to match the identifiers = from one AS to another or to correlate with the client user DB (still possi= ble via assertions, if the AS allows it). Assertions are much more generic = (possibly via extensions), but might require a more advanced mechanism=C2= =A0to request/response only the most relevant information (which makes the = AS policy critical here).

I hope that clarifies th= e=C2=A0reasoning for both options. Again I'm not saying option 2 is bet= ter, just saying the trade-offs are different (+ knowing that we need to ke= ep it simple).
- option 1 puts more in sub_ids and less in assert= ions
- option 2 puts less in the reference and more in assertions= =C2=A0
All of this is open to discussion. More generally speaking= , on every part in orange and question mark (?) I would love your ideas and= criticisms. What I intended as an editor is only to highlight where the WG= has important choices to make, before we can make the related PRs.

A further side comment: IETF EAT RATS was suggested for a= ssertions, but relates more to the client attestations. It was added as a c= omment in=C2=A0https://github.com/ietf-wg-gnap/gnap-core-pr= otocol/issues/44, which is a distinct topic we'll work on.

Fabien (editor's hat off)

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

--000000000000f2c3bc05bd407728-- From nobody Thu Mar 11 10:50:49 2021 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 4E3693A0CF5 for ; Thu, 11 Mar 2021 10:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_REMOTE_IMAGE=0.01, 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 01VW3_Y3pguW for ; Thu, 11 Mar 2021 10:50:42 -0800 (PST) Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr [80.12.242.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 122DC3A0D01 for ; Thu, 11 Mar 2021 10:50:39 -0800 (PST) Received: from [192.168.1.11] ([90.79.53.231]) by mwinf5d56 with ME id f6qY2400A4zJUWJ036qYtm; Thu, 11 Mar 2021 19:50:38 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Thu, 11 Mar 2021 19:50:38 +0100 X-ME-IP: 90.79.53.231 To: Fabien Imbault Cc: GNAP Mailing List , Justin Richer , Tobias Looker References: From: Denis Message-ID: <67a11cda-a06a-4e03-0d99-05cf6ab14474@free.fr> Date: Thu, 11 Mar 2021 19:50:34 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------53B8E44290D494B79CAA4081" Content-Language: fr Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 18:50:47 -0000 This is a multi-part message in MIME format. --------------53B8E44290D494B79CAA4081 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Fabien, Thank you for launching the discussion. SECEVENT draft-07 does not really offer new possibilities over draft-06. The major change is simply  in the syntax naming. The response to your question is not limited to an exclusive choice between option 1 and option 2. :-) The definition of a subject identifier in draft-07 is : *3.Subject Identifiers * *A Subject Identifier is a JSON [RFC7159] object whose contents may beused to identify a subject within some context.An Identifier Formatis a named definition of a set of information that may be used toidentify a subject, and the rules for encoding that information as aSubject Identifier; they define the syntax and semantics of Subject Identifiers.* With such a definition is it possible to request some _/types /_of subject identifiers to be placed into an access token, to place subjects identifiers (with their values) into an access token and for a RS to compare these subjects identifiers (with their values) against validation rules enacted by a RO acting as an ADF (Access Decision Function) which also use the same subjects identifiers (with their values). A DID is a persistent global unique identifier. In issue #210  ("sub_id" claims #210) I already proposed the following examples for globally unique identifiers (gu_id) : (1) For a globally unique identifier: "sub_id": { "format": "gu_id", "gu_id": " email", "email: "john@hughes.com", } or "sub_id": { "format": "gu_id", "gu_id": "ssn", "ssn": { "cn": "250" "value": "160087404506527", }, } In order to address DIDs, I would simply add the following example: "sub_id": { "format": "gu_id", "gu_id": " did", "did: "did:/DID:Method:DID Method Specific String/", } "sub_ids" claims are much better when compared to "sub" claims. The definition of Subject Identifier in the draft-07 (section 3) is :    A Subject Identifier is a JSON [RFC7159] object whose contents may be    used to identify a subject /within some context/. However, page 2 of the draft-07 states:    As described in Section 1.2 of SET [RFC8417], subjects /related to// //   security events/ may take a variety of forms, including but not    limited to a JWT [RFC7519] principal, an IP address, a URL, etc. RFC 8417 (Security Event Token (SET)) states in its abstract: Abstract    This specification defines the /Security Event Token (SET) data// //   structure/.  A SET describes statements of fact from the perspective    of an issuer about a subject.  These statements of fact represent an    event that occurred directly to or about a security subject, for    example, a statement about the issuance or revocation of a token on    behalf of a subject.  This specification is intended to enable    representing security- and identity-related events.  A SET is a JSON    Web Token (JWT), which can be optionally signed and/or encrypted.    SETs can be distributed via protocols such as HTTP. There is a need to be able to use subject identifiers that will not necessarily be used in a Security Event Token (SET) data structure. These Subject Identifiers might still be used in a Security Event Token (SET) data structure, /but not necessarilly/. * When supporting RBAC (Role Based Access Control), it would be nice to define "sub_ids" able to support roles. * When supporting ABAC (Attribute Bases Access Control), it would be nice to define "sub_ids" able to support group memberships with two flavours of them : (a) hierarchical groups and (b) functional groups; The current title of the draft is: "Subject Identifiers for Security Event Tokens" . More appropriate titles would be: Subject Identifiers for Security Event Tokens /a//nd other purposes/ or simply Subject Identifiers The first sentence of the abstract should also be slightly modified. Denis > Hi Tobias, > > Option 2's pros and cons are the consequence of solely relying only on > an opaque identifier managed by the AS, independantly from external > identifiers. > > That's an additional level of indirection, not unlike how indexes are > usually managed in a database. But there's obviously the additional > complexity of making a just in time translation into a practical > identifier (like email for account recovery, as discussed by Justin). > > "Assertions" should be what the AS (possibly with the assistance of > other parties) can confidently say about the subject. > > Thanks for the great feedback, as well as Justin's. Since the slides > were written, SECEVENT draft-07 already offers new possibilities which > is good news. > > Fabien > > Le mer. 10 mars 2021 à 22:02, Tobias Looker > a écrit : > > > Thanks for the feedback, although I'm not sure what you mean by > too abstract. > > Apologies what I mean by that was I feel like Option 2 would > expose too much complexity to clients that would be required to > construct a request to the AS. Option 1 IMO strikes a better > balance by still offering the required flexibility but keeping > things relatively simple. > > > Just a quick comment: an assertion in option 2 is not "the fact > the identifier is resolvable to cryptographic material that /can > /be used to validate cryptographic assertions". It is merely a > statement by the AS that "the subject corresponding to the > reference has a DID" ("has" is the assertion here). > > Yes I understand to drill down on this more though couldn't the > entire request made by the client to the AS also be considered to > be an assertion? Therefore the "sub_ids" request element is an > assertion by the client about who it believes the subject to be > identified as? If this is true then to me the "assertions" request > element is there for assertions that parties other than the client > are making about the subject (e.g an id_token). > > Thanks, > Mattr website > *Tobias Looker* > Mattr > +64 (0) 27 378 0461 > tobias.looker@mattr.global > Mattr website Mattr on LinkedIn > Mattr on Twitter > Mattr on Github > > > > This communication, including any attachments, is confidential. If > you are not the intended recipient, you should not read it - > please contact me immediately, destroy it, and do not copy or use > any part of this communication or disclose anything about it. > Thank you. Please note that this communication does not designate > an information system for the purposes of the Electronic > Transactions Act 2002. > > > On Thu, Mar 11, 2021 at 9:20 AM Fabien Imbault > > wrote: > > Thanks Justin. > > It's good to clarify what we mean by assertion. I used a more > mundane meaning. > > I dislike email/phone as security disasters waiting to happen. > I get that they are practical. > > I think I have what I need to write the PRs based on sub_ids > (based on the current draft-07). > > Fabien > > Le mer. 10 mars 2021 à 20:18, Justin Richer > a écrit : > > Hi Fabien, > > First, thanks for doing the heavy lift of writing this > topic up. Of these options, I would strongly prefer option > (1). The difference between assertions and identifiers is > that an assertion is a fully packaged set of attributes, > one of which can be an identifier. They are, generally > speaking, cryptographically protected bundles. They’re > designed to carry a bunch of different information about a > user and the authentication event in a form that’s > independently verifiable and auditable. SAML assertions > (XML document) and ID Tokens (signed JWTs) are the most > common ones we see today, but other formats exist and will > keep being invented. > > An identifier is a different kind of creature. It is a > single statement that identifies the party in question in > the context of the party doing the identification. It’s > this full context that the receiver of the identifier > needs to interpret it in. When using a federated identity > protocol, each RP is going to have :some: kind of local > user information store that they’re going to tie into, > some field in a database they’ll key off of. It’s just > never going to be the case that all RPs will be able to > use server-provided opaque identifiers for all cases. > Account recovery and binding is one such use case where a > user-facing identifier like an email address makes a LOT > of sense, for one small example. This is an array in the > request and response precisely because a user could be > known by several different identifiers to a party, and an > RP will have a better idea about what kinds of things it > wants to correlate against, and it’s up to the AS to > provide that mapping. I think that if we don’t define a > way to describe the format, the “as_id” field is going to > get structure back-patched onto it like is being proposed > here: > > https://mattrglobal.github.io/oidc-portable-identities/ > > > I’m personally not a fan of that approach as it mixes the > data layering too much, and you end up making guesses > about whether a field is meaningful or a pointer. I think > GNAP will be much better served by using a data structure > for this from the start. DIDs should be another “format” > of the subject identifier. I don’t think GNAP should > define this format, and I’ve dropped a note to the > SECEVENT mailing list asking about adding DIDs to the > subject identifiers draft before it gets published. DIDs > are not assertions, even in the cases where they point to > fully functional DID documents with user information in > them. (And for what it’s worth, I think the OIDC world > should also use the SECEVENT draft inside ID Tokens to > solve the use case of the draft above). > > For the user != RO cases, I think that potentially having > a way to signal those two items separately in the request > and response could be useful. Right now all the > user/subject stuff is about identifying “the user that’s > currently here at the client instance”, in a variety of > forms that the client instance and AS can negotiate. If > the client or AS has some other notion about who the RO is > and how that could be separate from the current user, we > could provide a way to signal that like you’re proposing > below. In my mental model, there are going to be a lot of > use cases where the “RO” isn’t known to the client at all, > but rather to the AS and is based on what the client’s > asking for. So I could identify the current user and ask > for a specific medical record, and the AS realizes it has > to go bug a particular doctor to approve things directly. > This is instead of interacting with the current user and > failing in an awkward way when the current user doesn’t > have the rights to do things, but someone else would. But > we’d want the system to be able to detect if the current > user is the doctor, so we can just interact with them > directly. Does that all track? > >  — Justin > >> On Mar 10, 2021, at 4:10 AM, Fabien Imbault >> > > wrote: >> >> Hello, >> >> Notice the question mark in the title. Not to be >> considered as an editor's comment. >> This thread intends to provide a detailed comment on the >> interesting feedback by Kristina: "I would catch up on >> the thread to understand why DIDs are thought to be >> treated as assertions". >> In the chat, I answered: "Happy to get the discussion on >> DIDs. Actually, could be either or, depending on what we >> intend to do." Let me expand a bit on that, to make it >> understandable (didn't have the time during the meeting, >> unfortunately). >> >> This relates to the items described on slides 20 and 34, >> which I'll explain further. I'll highlight as >> transparently as possible what I think would be the >> benefits and downsides of each. Both are probably viable >> options, but they correspond to different scopes and >> objectives. I'll spend a bit more time on option 2, since >> it is a different approach compared to the current draft. >> >> *1. The first possibility is to use SECEVENT throughout. * >> In that case, DIDs should be a part of sub_ids (in the >> core or in the extension registry, depending on what >> Annabelle's WG decides). More generally, the WG would >> have to decide which additional sub_ids it needs (as per >> Yaron's comment). >> >> That's obviously the closest to what is described in >> draft-04. It allows a communication of subject >> information between the client and the AS, by using >> global identifiers (mail, phone, etc.), or using a local >> opaque reference - i.e. governed by the AS (that's >> probably what we would put in the examples, unless >> someone has a better idea - cf issues #16 and #42). >> >> Assertions relate for instance to the proof of presence >> of the RO. The current draft-04 therefore plans for >> id_tokens and saml2, maybe there could be other needs >> later (extension registry). >> >> - Benefits: identifiers are a key component of GNAP, >> which makes integration easier. Possibly one could choose >> to use DIDs throughout. >> - Downsides: email/phone identifiers will probably be >> used throughout by most devs (since that's correlation >> information they have in their user DB). Which means we >> should limit what assertions contain, to avoid doing >> links between weak global identifiers and hopefully >> stronger assertions. That's not really a problem if it's >> limited to authentication events mostly (in that >> perspective, samlv2 could make sense in the core). An >> assertion is probably a single value then (not an array). >> >> Option 1 can be summarized as: >> >> "subject": { >>    "sub_ids": { },// request and response (SECEVENT -> >> including DID possibly) >>    "assertions": [ ],               // request and >> response (id_token or samlv2) >> } >> ("hints" do not exist currently, but are partially >> covered separately via "request.user" / the relevance of >> "principal", discussed in the slide, is a question mark >> too - which is a different discussion on end-user != RO). >> >> >> *2. An alternate possibility is to use SECEVENT only as >> input/hint* >> In that case, DIDs should be a part of assertions (which >> have a different meaning compared to option 1). >> >> The AS only returns an local opaque reference as_ref >> (while in option 1, it was only one of many >> possibilities). Its only job is to help the client >> differentiate the response subject. The AS policy might >> further define the scope of that reference, as suggested >> in >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210 >> , >> although I personally viewed that by default as (2) >> "as_id" an identifier locally unique to that AS for all >> the RSs. >> >> SECEVENTS are still useful as an input, that's what I >> presented in request.hints.self.sub_ids (but it's the >> responsibility of the AS to match it with its own >> reference system - from instance from the email to AS's >> local record XUT2MFM1XBIKJKSDU8Q). Note: since the >> slides, a new draft-ietf-secevent-subject-identifiers-07 >> has been published. Notably this includes an opaque >> identifier, which the client can use to pass the as_ref >> hint to the AS. Thus we wouldn't need any further >> addition to SECEVENT, although hints would benefit from >> further additions (like DIDs for instance). Notice also >> that subject_types_supported becomes less important, >> because in the worst case scenario, it's simply a hint >> that wouldn't be understood and therefore taken into >> account by the AS. >> >> The assertions array has a more important role than in >> option 1 (with the explicit aim of separating between >> client hints and validated info asserted by the AS). It >> serves as a generic/extendible mapping structure, e.g. >> "the AS asserts that opaque reference >> XUT2MFM1XBIKJKSDU8Q is matching with these (more or less >> verifiable) statements." The name assertion therefore >> corresponds to the responsibility of the AS in delivering >> those statements (cf should/must, issue #49). Some of >> these statements relate to identity or auth events (ex: >> DID, id_token), some might directly be useful for >> authorization decisions (like ZKP example in the parental >> control example). Possibly some of these validated >> assertions could be reused in next interactions. >> >> Another question that popped-up is the scope of sub_ids. >> Should they be about the same user? (I think so). In the >> case of remote ROs especially, it might be important that >> DID be considered as an assertion (about someone else's) >> and not as sub_ids, because the AS needs to be careful >> about who the client wants to reach (avoid spam, etc.). >> This is consistent with the rest of discussion on what to >> do when end-user != RO, although using DIDComm might seem >> a bit early (the paint is very fresh). >> >> Option 2 was summarized as: >> >> // (suggestion only, not as an editor) >> "subject": { >>    "as_ref": { // response only (wouldn’t require SECEVENT) >> “as”: “https://ex1.as.com ”, >> “ref”: “XUT2MFM1XBIKJKSDU8QM” >>    }, >>    "assertions": [ ],               // request and >> response (id_token/jwkthumb/DID/VC/etc. -> whatever info >> can be validated by the AS) >> >>    "hints": {                       // request only >> (optional) >>       "self": { // replaces request.user (support >> SECEVENT here) >>    “sub_ids”: { },// SECEVENT (including opaque in >> draft-07 - that could contain the ref) >>    “assertions”: [ ] // see examples: VC on DOB or ZKP on >> age (wider scope, possibly through extensions) >> }, >>       "principal": {// new proposal presented at IETF110 >> (just an idea) >>   “automated”: true,// rule engine >>   “async”: { }// remote ROs >> } >>    } >> } >> >> - Benefits: as_ref is self supporting (no strong coupling >> with SECEVENT), but can still take SECEVENT as an input >> hint for the AS. It avoids the risk of making an official >> association between a weak global identifier (e.g. email, >> used elsewhere) and hopefully stronger local assertions. >> GNAP would be fully agnostic to whatever identity system >> is used, only facilitating interoperability through >> assertions (second only in importance compared to the AS >> opaque reference). Some assertions (possibly extensions) >> could also be useful for the AS decision (e.g. VC or ZKP). >> - Downsides: opaqueness of as_ref is a feature, not a >> bug. The opaque reference is fully managed by the AS, >> therefore not inherently portable (cf portability >> discussions in OIDC currently). There's no explicit >> binding to an official identity, only a contextual >> mapping to AS validated assertions. It makes it more >> difficult to match the identifiers from one AS to another >> or to correlate with the client user DB (still possible >> via assertions, if the AS allows it). Assertions are much >> more generic (possibly via extensions), but might require >> a more advanced mechanism to request/response only the >> most relevant information (which makes the AS policy >> critical here). >> >> I hope that clarifies the reasoning for both options. >> Again I'm not saying option 2 is better, just saying the >> trade-offs are different (+ knowing that we need to keep >> it simple). >> - option 1 puts more in sub_ids and less in assertions >> - option 2 puts less in the reference and more in assertions >> All of this is open to discussion. More generally >> speaking, on every part in orange and question mark (?) I >> would love your ideas and criticisms. What I intended as >> an editor is only to highlight where the WG has important >> choices to make, before we can make the related PRs. >> >> A further side comment: IETF EAT RATS was suggested for >> assertions, but relates more to the client attestations. >> It was added as a comment in >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44 >> , >> which is a distinct topic we'll work on. >> >> Fabien (editor's hat off) >> >> -- >> 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 > > > > This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002. > > --------------53B8E44290D494B79CAA4081 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+DQogIDxoZWFkPg0KICAgIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PVVURi04Ij4NCiAgPC9oZWFkPg0KICA8Ym9k eT4NCiAgICA8ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPg0KICAgICAgPGRpdiBjbGFz cz0ibW96LWNpdGUtcHJlZml4Ij5IaSBGYWJpZW4sPC9kaXY+DQogICAgICA8ZGl2IGNsYXNz PSJtb3otY2l0ZS1wcmVmaXgiPjxicj4NCiAgICAgIDwvZGl2Pg0KICAgICAgPGRpdiBjbGFz cz0ibW96LWNpdGUtcHJlZml4Ij5UaGFuayB5b3UgZm9yIGxhdW5jaGluZyB0aGUNCiAgICAg ICAgZGlzY3Vzc2lvbi4gPGJyPg0KICAgICAgPC9kaXY+DQogICAgICA8ZGl2IGNsYXNzPSJt b3otY2l0ZS1wcmVmaXgiPjxicj4NCiAgICAgIDwvZGl2Pg0KICAgICAgPGRpdiBjbGFzcz0i bW96LWNpdGUtcHJlZml4Ij5TRUNFVkVOVCBkcmFmdC0wNyBkb2VzIG5vdCByZWFsbHkNCiAg ICAgICAgb2ZmZXIgbmV3IHBvc3NpYmlsaXRpZXMgb3ZlciBkcmFmdC0wNi4gVGhlIG1ham9y IGNoYW5nZSBpcw0KICAgICAgICBzaW1wbHnCoCBpbiB0aGUgc3ludGF4IG5hbWluZy48L2Rp dj4NCiAgICAgIDxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+PGJyPg0KICAgICAgPC9k aXY+DQogICAgICA8ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPlRoZSByZXNwb25zZSB0 byB5b3VyIHF1ZXN0aW9uIGlzIG5vdA0KICAgICAgICBsaW1pdGVkIHRvIGFuIGV4Y2x1c2l2 ZSBjaG9pY2UgYmV0d2VlbiBvcHRpb24gMSBhbmQgb3B0aW9uIDIuDQogICAgICAgIDotKTxi cj4NCiAgICAgIDwvZGl2Pg0KICAgICAgPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij48 YnI+DQogICAgICA8L2Rpdj4NCiAgICAgIDxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+ VGhlIGRlZmluaXRpb24gb2YgYSBzdWJqZWN0DQogICAgICAgIGlkZW50aWZpZXIgaW4gZHJh ZnQtMDcgaXMgOjwvZGl2Pg0KICAgICAgPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij48 YnI+DQogICAgICA8L2Rpdj4NCiAgICAgIDxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+ DQogICAgICAgIDxwcmU+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTIiBsYW5nPSJFTi1VUyI+My48 c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPsKgIDwvc3Bhbj5TdWJqZWN0IElkZW50 aWZpZXJzIA0KPC9zcGFuPjwvYj48L3ByZT4NCiAgICAgICAgPHByZT48Yj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWFuc2ktbGFuZ3Vh Z2U6RU4tVVMiIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMi PsKgwqAgPC9zcGFuPkEgU3ViamVjdCBJZGVudGlmaWVyIGlzIGEgSlNPTiBbUkZDNzE1OV0g b2JqZWN0IHdob3NlIGNvbnRlbnRzIG1heSBiZTxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46 IHllcyI+DQrCoMKgIDwvc3Bhbj51c2VkIHRvIGlkZW50aWZ5IGEgc3ViamVjdCB3aXRoaW4g c29tZSBjb250ZXh0LjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+wqAgPC9zcGFu PkFuIElkZW50aWZpZXIgRm9ybWF0PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4N CsKgwqAgPC9zcGFuPmlzIGEgbmFtZWQgZGVmaW5pdGlvbiBvZiBhIHNldCBvZiBpbmZvcm1h dGlvbiB0aGF0IG1heSBiZSB1c2VkIHRvPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVz Ij4NCsKgwqAgPC9zcGFuPmlkZW50aWZ5IGEgc3ViamVjdCwgYW5kIHRoZSBydWxlcyBmb3Ig ZW5jb2RpbmcgdGhhdCBpbmZvcm1hdGlvbiBhcyBhPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1 bjogeWVzIj4NCsKgwqAgPC9zcGFuPlN1YmplY3QgSWRlbnRpZmllcjsgdGhleSBkZWZpbmUg dGhlIHN5bnRheCBhbmQgc2VtYW50aWNzIG9mIFN1YmplY3QgDQogICBJZGVudGlmaWVycy48 L3NwYW4+PC9iPjwvcHJlPg0KICAgICAgPC9kaXY+DQogICAgICA8ZGl2IGNsYXNzPSJtb3ot Y2l0ZS1wcmVmaXgiPldpdGggc3VjaCBhIGRlZmluaXRpb24gaXMgaXQgcG9zc2libGUNCiAg ICAgICAgdG8gcmVxdWVzdCBzb21lIDx1PjxpPnR5cGVzIDwvaT48L3U+b2Ygc3ViamVjdCBp ZGVudGlmaWVycyB0bw0KICAgICAgICBiZSBwbGFjZWQgaW50byBhbiBhY2Nlc3MgdG9rZW4s IDxicj4NCiAgICAgICAgdG8gcGxhY2Ugc3ViamVjdHMgaWRlbnRpZmllcnMgKHdpdGggdGhl aXIgdmFsdWVzKSBpbnRvIGFuIGFjY2Vzcw0KICAgICAgICB0b2tlbiBhbmQgZm9yIGEgUlMg dG8gY29tcGFyZSB0aGVzZSBzdWJqZWN0cyBpZGVudGlmaWVycyA8YnI+DQogICAgICAgICh3 aXRoIHRoZWlyIHZhbHVlcykgYWdhaW5zdCB2YWxpZGF0aW9uIHJ1bGVzIGVuYWN0ZWQgYnkg YSBSTw0KICAgICAgICBhY3RpbmcgYXMgYW4gQURGIChBY2Nlc3MgRGVjaXNpb24gRnVuY3Rp b24pIHdoaWNoIGFsc28gdXNlPGJyPg0KICAgICAgICB0aGUgc2FtZSBzdWJqZWN0cyBpZGVu dGlmaWVycyAod2l0aCB0aGVpciB2YWx1ZXMpLjwvZGl2Pg0KICAgICAgPGRpdiBjbGFzcz0i bW96LWNpdGUtcHJlZml4Ij48YnI+DQogICAgICA8L2Rpdj4NCiAgICAgIDxkaXYgY2xhc3M9 Im1vei1jaXRlLXByZWZpeCI+QSBESUQgaXMgYSBwZXJzaXN0ZW50IGdsb2JhbCB1bmlxdWUN CiAgICAgICAgaWRlbnRpZmllci4gPGJyPg0KICAgICAgPC9kaXY+DQogICAgICA8ZGl2IGNs YXNzPSJtb3otY2l0ZS1wcmVmaXgiPjxicj4NCiAgICAgIDwvZGl2Pg0KICAgICAgPGRpdiBj bGFzcz0ibW96LWNpdGUtcHJlZml4Ij5JbiBpc3N1ZSAjMjEwwqAgKCJzdWJfaWQiIGNsYWlt cyAjMjEwKQ0KICAgICAgICBJIGFscmVhZHkgcHJvcG9zZWQgdGhlIGZvbGxvd2luZyBleGFt cGxlcyBmb3IgPHNwYW4NCiAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseTpBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseToNCiAgICAgICAgICAmcXVv dDtUaW1lcyBOZXcNClJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTO21zby1m YXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAg IGxhbmc9IkVOLVVTIj48L3NwYW4+PHNwYW4NCiAgICAgICAgICBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDttc28tYmlkaS1mb250LXNpemU6DQoyMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7 bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6K21uLWVhO2NvbG9yOmJsYWNrO21zby1mb250LWtl cm5pbmc6DQoxMi4wcHQ7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgbGFuZz0iRU4t VVMiPmdsb2JhbGx5IHVuaXF1ZSBpZGVudGlmaWVycyAoPC9zcGFuPmd1X2lkKSA6PC9kaXY+ DQogICAgICA8ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPg0KICAgICAgICA8YmxvY2tx dW90ZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAg ICAgICAgIENhbGlicmk7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 DQogICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYmlkaS1mb250LWZhbWlseTpBcmlhbDsN Cm1zby1hbnNpLWxhbmd1YWdlOkVOLVVTO21zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1i aWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgbGFuZz0iRU4tVVMiPigxKSBGPC9z cGFuPjxzcGFuDQogICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTpBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseToNCiAgICAgICAgICAgICZxdW90 O1RpbWVzIE5ldw0KUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAg ICBsYW5nPSJFTi1VUyI+b3IgYSA8L3NwYW4+PHNwYW4NCiAgICAgICAgICAgIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToNCjIwLjBwdDtmb250LWZhbWls eTpBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTorbW4tZWE7Y29sb3I6YmxhY2s7bXNv LWZvbnQta2VybmluZzoNCjEyLjBwdDttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzttc28tZmFy ZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAg IGxhbmc9IkVOLVVTIj5nbG9iYWxseSB1bmlxdWUgaWRlbnRpZmllcjo8L3NwYW4+PHNwYW4N CiAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAg ICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 DQogICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAg ICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFS LVNBIg0KICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjwvc3Bhbj48YnI+DQogICAgICAgICAg PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAg ICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAg ICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAg ICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQog ICAgICAgICAgICBsYW5nPSJFTi1VUyI+IDwvc3Bhbj48YnI+DQogICAgICAgICAgPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICBBcmlh bDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAg IFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAg ICAgICBsYW5nPSJFTi1VUyI+ICJzdWJfaWQiOiB7PC9zcGFuPjxicj4NCiAgICAgICAgICA8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAg IEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAg ICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAg ICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAg ICAgICAgICAgIGxhbmc9IkVOLVVTIj4gPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVz Ij7CoMKgwqDCoMKgwqAgPC9zcGFuPiJmb3JtYXQiOg0KICAgICAgICAgICAgImd1X2lkIiw8 L3NwYW4+PGJyPg0KICAgICAgICAgIDxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5Og0KICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5n dWFnZTpFTi1VUzsNCiAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1i aWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgbGFuZz0iRU4tVVMiPiA8c3BhbiBz dHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPsKgwqDCoMKgwqDCoCA8L3NwYW4+Imd1X2lkIjoN CiAgICAgICAgICAgICIgZW1haWwiLDwvc3Bhbj48YnI+DQogICAgICAgICAgPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICBBcmlhbDtt c28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgIFJv bWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAg ICBsYW5nPSJFTi1VUyI+IDxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+wqDCoMKg wqDCoMKgIDwvc3Bhbj4iZW1haWw6DQogICAgICAgICAgICA8YSBjbGFzcz0ibW96LXR4dC1s aW5rLXJmYzIzOTZFIg0KICAgICAgICAgICAgICBocmVmPSJtYWlsdG86am9obkBodWdoZXMu Y29tIj4iam9obkBodWdoZXMuY29tIjwvYT4sPC9zcGFuPjxicj4NCiAgICAgICAgICA8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAgIEFy aWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAg ICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgICBt c28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAg ICAgICAgIGxhbmc9IkVOLVVTIj4gPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj7C oMKgwqDCoCA8L3NwYW4+fTwvc3Bhbj48YnI+DQogICAgICAgICAgPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICBBcmlhbDttc28tZmFy ZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgIFJvbWFuJnF1 b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgbXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICBsYW5n PSJFTi1VUyI+IDwvc3Bhbj48YnI+DQogICAgICAgICAgPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1m b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21z by1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICBsYW5nPSJFTi1V UyI+IG9yPC9zcGFuPjxicj4NCiAgICAgICAgICA8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFu c2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpG Ujttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAgIGxhbmc9IkVOLVVTIj4g PC9zcGFuPjxicj4NCiAgICAgICAgICA8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseToNCiAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFu Z3VhZ2U6RU4tVVM7DQogICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28t YmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAgIGxhbmc9IkVOLVVTIj4gInN1Yl9p ZCI6IHs8L3NwYW4+PGJyPg0KICAgICAgICAgIDxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5z aS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZS O21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgbGFuZz0iRU4tVVMiPiA8 c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPsKgwqDCoMKgwqDCoCA8L3NwYW4+ImZv cm1hdCI6DQogICAgICAgICAgICAiZ3VfaWQiLDwvc3Bhbj48YnI+DQogICAgICAgICAgPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICBB cmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAg ICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAg bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAg ICAgICAgICBsYW5nPSJFTi1VUyI+IDxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+ wqDCoMKgwqDCoMKgIDwvc3Bhbj4iZ3VfaWQiOg0KICAgICAgICAgICAgInNzbiIsPC9zcGFu Pjxicj4NCiAgICAgICAgICA8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseToNCiAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldw0KICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6 RU4tVVM7DQogICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1s YW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAgIGxhbmc9IkVOLVVTIj4gPHNwYW4gc3R5bGU9 Im1zby1zcGFjZXJ1bjogeWVzIj7CoMKgwqDCoMKgwqAgPC9zcGFuPiJzc24iOg0KICAgICAg ICAgICAgeyA8L3NwYW4+PGJyPg0KICAgICAgICAgIDxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICBSb21hbiZxdW90Ozttc28t YW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdl OkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgbGFuZz0iRU4tVVMi PiA8c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPsKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgDQogICAgICAgICAgICA8L3NwYW4+ImNuIjogIjI1MCI8L3Nw YW4+PGJyPg0KICAgICAgICAgIDxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5Og0KICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3DQogICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFn ZTpFTi1VUzsNCiAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRp LWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgbGFuZz0iRU4tVVMiPiA8c3BhbiBzdHls ZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgDQogICAgICAgICAgICA8L3NwYW4+InZhbHVlIjogIjE2MDA4NzQwNDUwNjUyNyIs PC9zcGFuPjxicj4NCiAgICAgICAgICA8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseToNCiAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFu Z3VhZ2U6RU4tVVM7DQogICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28t YmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAgIGxhbmc9IkVOLVVTIj4gPHNwYW4g c3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgDQogICAgICAgICAgICA8L3NwYW4+fSw8L3NwYW4+PGJyPg0KICAgICAgICAgIDxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAg QXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAg ICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAg IG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAg ICAgICAgICAgbGFuZz0iRU4tVVMiPiA8c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMi PsKgwqDCoMKgIDwvc3Bhbj59PC9zcGFuPjxicg0KICAgICAgICAgICAgc3R5bGU9Im1zby1z cGVjaWFsLWNoYXJhY3RlcjogbGluZS1icmVhayI+DQogICAgICAgICAgPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICBBcmlhbDttc28t ZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgIFJvbWFu JnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICBs YW5nPSJFTi1VUyI+PC9zcGFuPjwvYmxvY2txdW90ZT4NCiAgICAgICAgPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgQXJpYWw7bXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgUm9tYW4mcXVv dDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgbXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiIGxhbmc9IkVOLVVTIj4NCiAgICAg ICAgICBJbiBvcmRlciB0byBhZGRyZXNzIERJRHMsIEkgd291bGQgc2ltcGx5IGFkZCB0aGUg Zm9sbG93aW5nDQogICAgICAgICAgZXhhbXBsZTo8L3NwYW4+PC9kaXY+DQogICAgICA8ZGl2 IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPjxicj4NCiAgICAgICAgPGJsb2NrcXVvdGU+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICBB cmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAg ICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAg bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAg ICAgICAgICBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6DQogICAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1s YW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7 bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICAgIGxhbmc9IkVOLVVTIj4i c3ViX2lkIjogezwvc3Bhbj48L3NwYW4+PGJyPg0KICAgICAgICAgIDxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgQXJpYWw7bXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICBSb21hbiZx dW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgIG1zby1mYXJlYXN0 LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgbGFu Zz0iRU4tVVMiPiA8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToN CiAgICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3DQogICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVO LVVTOw0KICAgICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1s YW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPiA8c3BhbiBzdHls ZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPsKgwqDCoMKgwqDCoCA8L3NwYW4+ImZvcm1hdCI6DQog ICAgICAgICAgICAgICJndV9pZCIsPC9zcGFuPjwvc3Bhbj48YnI+DQogICAgICAgICAgPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICBB cmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAg ICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAg bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAg ICAgICAgICBsYW5nPSJFTi1VUyI+IDxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5Og0KICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2kt bGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZS O21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+ IDxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+wqDCoMKgwqDCoMKgIDwvc3Bhbj4i Z3VfaWQiOg0KICAgICAgICAgICAgICAiIGRpZCIsPC9zcGFuPjwvc3Bhbj48YnI+DQogICAg ICAgICAgPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAg ICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcN CiAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAg ICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVIt U0EiDQogICAgICAgICAgICBsYW5nPSJFTi1VUyI+IDxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1m b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7 bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxh bmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICBsYW5n PSJFTi1VUyI+IDxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+wqDCoMKgwqDCoMKg IDwvc3Bhbj4iZGlkOg0KICAgICAgICAgICAgICAiZGlkOjxpPkRJRDpNZXRob2Q6RElEIE1l dGhvZCBTcGVjaWZpYyBTdHJpbmc8L2k+Iiw8L3NwYW4+PC9zcGFuPjxicj4NCiAgICAgICAg ICA8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAg ICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAg ICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAg ICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIN CiAgICAgICAgICAgIGxhbmc9IkVOLVVTIj4gPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28t YW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICAgIGxhbmc9IkVO LVVTIj4gPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj7CoMKgwqDCoCA8L3NwYW4+ fTwvc3Bhbj48L3NwYW4+PC9ibG9ja3F1b3RlPg0KICAgICAgPC9kaXY+DQogICAgICA8ZGl2 IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPjxzcGFuDQogICAgICAgICAgc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgUm9tYW4mcXVvdDs7bXNv LWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiIGxhbmc9IkVOLVVTIj4ic3ViX2lkcyINCiAg ICAgICAgICBjbGFpbXMgYXJlIG11Y2ggYmV0dGVyIHdoZW4gY29tcGFyZWQgdG8gInN1YiIg Y2xhaW1zLjxicj4NCiAgICAgICAgPC9zcGFuPjwvZGl2Pg0KICAgICAgPGRpdiBjbGFzcz0i bW96LWNpdGUtcHJlZml4Ij48c3Bhbg0KICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxh bmd1YWdlOkVOLVVTOw0KICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1i aWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+DQogICAgICAgIDwvc3Bhbj48L2Rp dj4NCiAgICAgIDxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+PHNwYW4NCiAgICAgICAg ICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICBBcmlh bDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICBS b21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICBtc28tZmFy ZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMi Pjxicj4NCiAgICAgICAgPC9zcGFuPjwvZGl2Pg0KICAgICAgPGRpdiBjbGFzcz0ibW96LWNp dGUtcHJlZml4Ij48c3Bhbg0KICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5Og0KICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldw0KICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdl OkVOLVVTOw0KICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxh bmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgQXJpYWw7bXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICBSb21hbiZx dW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgIG1zby1mYXJlYXN0 LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgbGFu Zz0iRU4tVVMiPlRoZSBkZWZpbml0aW9uIG9mIDwvc3Bhbj48L3NwYW4+PHNwYW4NCiAgICAg ICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICBB cmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAg ICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICBtc28t ZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4t VVMiPjxzcGFuDQogICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseToNCiAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldw0KICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6 RU4tVVM7DQogICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1s YW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAgIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAgICAgQXJpYWw7bXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgIFJv bWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgICBtc28t ZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAg ICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5Og0KICAgICAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNp LWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdl OkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICAgIGxhbmc9IkVO LVVTIj5TdWJqZWN0IElkZW50aWZpZXIgPC9zcGFuPjwvc3Bhbj5pbiA8L3NwYW4+PC9zcGFu PjxzcGFuDQogICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 DQogICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3DQogICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQog ICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVIt U0EiIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1h bnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICBsYW5nPSJFTi1VUyI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAg ICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAg ICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAg ICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVIt U0EiDQogICAgICAgICAgICAgIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFz dC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICBSb21hbiZx dW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgICAgICBtc28tZmFy ZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAg ICAgICBsYW5nPSJFTi1VUyI+dGhlIGRyYWZ0LTA3IDwvc3Bhbj48L3NwYW4+KHNlY3Rpb24g MykgaXMNCiAgICAgICAgICAgIDogPGJyPg0KICAgICAgICAgIDwvc3Bhbj48L3NwYW4+DQog ICAgICAgIDxibG9ja3F1b3RlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5Og0KICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3DQogICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFn ZTpFTi1VUzsNCiAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRp LWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICBBcmlhbDtt c28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAg Um9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgICAgIG1z by1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAg ICAgICAgICBsYW5nPSJFTi1VUyI+wqDCoCBBIFN1YmplY3QgSWRlbnRpZmllciBpcyBhIEpT T04gW1JGQzcxNTldDQogICAgICAgICAgICAgIG9iamVjdCB3aG9zZSBjb250ZW50cyBtYXkg YmU8L3NwYW4+PC9zcGFuPjxicj4NCiAgICAgICAgICA8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNv LWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFn ZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAgIGxhbmc9IkVOLVVT Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAg ICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQog ICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAg ICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpB Ui1TQSINCiAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPsKgwqAgdXNlZCB0byBpZGVudGlm eSBhIHN1YmplY3QgPGk+d2l0aGluIHNvbWUNCiAgICAgICAgICAgICAgICBjb250ZXh0PC9p Pi7CoCA8L3NwYW4+PC9zcGFuPjxicj4NCiAgICAgICAgICA8c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgUm9tYW4mcXVvdDs7 bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5n dWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAgIGxhbmc9IkVO LVVTIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAg ICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 DQogICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0K ICAgICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFn ZTpBUi1TQSINCiAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjwvc3Bhbj48L3NwYW4+PC9i bG9ja3F1b3RlPg0KICAgICAgICA8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseToNCiAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcNCiAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpF Ti1VUzsNCiAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5n dWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAgIEFyaWFsO21zby1mYXJl YXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgUm9tYW4mcXVv dDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgICBtc28tZmFyZWFzdC1s YW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAgIGxhbmc9 IkVOLVVTIj48L3NwYW4+PC9zcGFuPkg8c3Bhbg0KICAgICAgICAgIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1h bnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZS O21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAg ICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAg QXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAg ICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAg IG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAg ICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5Og0KICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2kt bGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZS O21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+ b3dldmVyLCA8L3NwYW4+cGFnZSAyIG9mIHRoZSBkcmFmdC0wNw0KICAgICAgICAgICAgc3Rh dGVzOjwvc3Bhbj48L3NwYW4+PC9kaXY+DQogICAgICA8YmxvY2txdW90ZT4NCiAgICAgICAg PGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij48c3Bhbg0KICAgICAgICAgICAgc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICBBcmlhbDttc28t ZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgIFJvbWFu JnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICBs YW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 DQogICAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldw0KICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpF Ti1VUzsNCiAgICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGkt bGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICAgIGxhbmc9IkVOLVVTIj7CoMKgIEFzIGRl c2NyaWJlZCBpbiBTZWN0aW9uIDEuMiBvZiBTRVQNCiAgICAgICAgICAgICAgW1JGQzg0MTdd LCBzdWJqZWN0cyA8aT5yZWxhdGVkIHRvPC9pPjxpPjxicj4NCiAgICAgICAgICAgICAgPC9p PjxpPsKgwqAgc2VjdXJpdHkgZXZlbnRzPC9pPiBtYXkgdGFrZSBhIHZhcmlldHkgb2YgZm9y bXMsDQogICAgICAgICAgICAgIGluY2x1ZGluZyBidXQgbm90PGJyPg0KICAgICAgICAgICAg ICDCoMKgIGxpbWl0ZWQgdG8gYSBKV1QgW1JGQzc1MTldIHByaW5jaXBhbCwgYW4gSVAgYWRk cmVzcywgYQ0KICAgICAgICAgICAgICBVUkwsIGV0Yy48YnI+DQogICAgICAgICAgICA8L3Nw YW4+PC9zcGFuPjwvZGl2Pg0KICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgPGRpdiBjbGFz cz0ibW96LWNpdGUtcHJlZml4Ij48c3Bhbg0KICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNp LWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21z by1iaWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAg IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgQXJp YWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAg ICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgIG1z by1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAg ICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5Og0KICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFu Z3VhZ2U6RU4tVVM7DQogICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21z by1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICAg ICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAg ICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAg ICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6 QVItU0EiDQogICAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPlJGQyA4NDE3IChTPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PC9zcGFuPjxzcGFuDQogICAgICAgICAgc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFu c2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7 bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAg ICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICBB cmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAg ICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAg bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAg ICAgICAgICBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6DQogICAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1s YW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7 bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICAgIGxhbmc9IkVOLVVTIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAg ICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAg ICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAg ICAgICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFn ZTpBUi1TQSINCiAgICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICAgICAgICBBcmlhbDtt c28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAg ICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAg ICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0Ei DQogICAgICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAg ICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAg ICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dw0KICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpF Ti1VUzsNCiAgICAgICAgICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNv LWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICAgICAgICAgIGxhbmc9IkVOLVVT Ij48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAgICAgIFJv bWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgICAgICAg ICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0K ICAgICAgICAgICAgICAgICAgICAgIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAg ICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAg ICAgICAgICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1h bnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgICAgICAgICAgICAgbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICAg ICAgICAgICAgICBsYW5nPSJFTi1VUyI+ZWN1cml0eSBFdmVudCBUb2tlbiAoU0VUKSkgPC9z cGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPnN0YXRlcw0KICAgICAgICAgICAgICAgIGluIGl0 cyBhYnN0cmFjdDo8YnI+DQogICAgICAgICAgICAgIDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwv c3Bhbj4NCiAgICAgICAgPGJsb2NrcXVvdGU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNp LWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7 bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICBsYW5nPSJFTi1VUyI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICAg IEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAg ICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAg ICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0Ei DQogICAgICAgICAgICAgIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1m b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICBSb21hbiZxdW90 Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgICAgICBtc28tZmFyZWFz dC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAgICAg ICBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6DQogICAgICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNp LWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICAgICAgICBsYW5n PSJFTi1VUyI+QWJzdHJhY3Q8L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PGJyPg0KICAg ICAgICAgIDxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAg ICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 DQogICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAg ICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFS LVNBIg0KICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1m b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7 bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxh bmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICBsYW5n PSJFTi1VUyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQog ICAgICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3DQogICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6 RU4tVVM7DQogICAgICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJp ZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAg ICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAg ICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAg ICAgICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1 YWdlOkFSLVNBIg0KICAgICAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwvc3Bhbj48YnI+DQogICAgICAgICAgPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1m b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21z by1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICBsYW5nPSJFTi1V UyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAg ICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0K ICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAg ICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6 QVItU0EiDQogICAgICAgICAgICAgIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAgICAgICBBcmlhbDttc28tZmFy ZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICBSb21h biZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgICAgICBtc28t ZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAg ICAgICAgICBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6DQogICAgICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21z by1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgICAgICAgbXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICAgICAg ICBsYW5nPSJFTi1VUyI+wqDCoCBUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyB0aGUgPGk+ U2VjdXJpdHkNCiAgICAgICAgICAgICAgICAgICAgRXZlbnQgVG9rZW4gKFNFVCkgZGF0YTwv aT48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PGk+PGJyPg0KICAgICAgICAgIDwvaT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAg IEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAg ICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAg ICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAg ICAgICAgICAgIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseToNCiAgICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNp LWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpG Ujttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAgICAgbGFuZz0iRU4tVVMi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAg ICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0K ICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0K ICAgICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1 YWdlOkFSLVNBIg0KICAgICAgICAgICAgICAgIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAgICAgICAgIEFyaWFs O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAg ICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAg ICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1T QSINCiAgICAgICAgICAgICAgICAgIGxhbmc9IkVOLVVTIj48aT7CoMKgIHN0cnVjdHVyZTwv aT4uwqAgQSBTRVQgZGVzY3JpYmVzDQogICAgICAgICAgICAgICAgICBzdGF0ZW1lbnRzIG9m IGZhY3QgZnJvbSB0aGUgcGVyc3BlY3RpdmU8L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+ PGJyPg0KICAgICAgICAgIDxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5Og0KICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3DQogICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpF Ti1VUzsNCiAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxh bmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICBBcmlhbDttc28t ZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgUm9t YW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgICAgIG1zby1m YXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAg ICAgICBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6DQogICAgICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2kt bGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICAgICAgbGFuZz0iRU4t VVMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAg ICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3DQogICAgICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpF Ti1VUzsNCiAgICAgICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1i aWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPsKg wqAgb2YgYW4gaXNzdWVyIGFib3V0IGEgc3ViamVjdC7CoCBUaGVzZQ0KICAgICAgICAgICAg ICAgICAgc3RhdGVtZW50cyBvZiBmYWN0IHJlcHJlc2VudCBhbjwvc3Bhbj48L3NwYW4+PC9z cGFuPjwvc3Bhbj48YnI+DQogICAgICAgICAgPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNp LWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7 bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICBsYW5nPSJFTi1VUyI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICAg IEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAg ICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAg ICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0Ei DQogICAgICAgICAgICAgIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1m b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICBSb21hbiZxdW90 Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgICAgICBtc28tZmFyZWFz dC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAgICAg ICBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6DQogICAgICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNp LWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICAgICAgICBsYW5n PSJFTi1VUyI+wqDCoCBldmVudCB0aGF0IG9jY3VycmVkIGRpcmVjdGx5IHRvIG9yDQogICAg ICAgICAgICAgICAgICBhYm91dCBhIHNlY3VyaXR5IHN1YmplY3QsIGZvcjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwvc3Bhbj48YnI+DQogICAgICAgICAgPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1m b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21z by1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICBsYW5nPSJFTi1V UyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAg ICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0K ICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAg ICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6 QVItU0EiDQogICAgICAgICAgICAgIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAgICAgICBBcmlhbDttc28tZmFy ZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICBSb21h biZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgICAgICBtc28t ZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAg ICAgICAgICBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6DQogICAgICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21z by1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgICAgICAgbXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICAgICAg ICBsYW5nPSJFTi1VUyI+wqDCoCBleGFtcGxlLCBhIHN0YXRlbWVudCBhYm91dCB0aGUNCiAg ICAgICAgICAgICAgICAgIGlzc3VhbmNlIG9yIHJldm9jYXRpb24gb2YgYSB0b2tlbiBvbjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48YnI+DQogICAgICAgICAgPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICBBcmlhbDttc28t ZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgIFJvbWFu JnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICBs YW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 DQogICAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldw0KICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpF Ti1VUzsNCiAgICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGkt bGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICAgIGxhbmc9IkVOLVVTIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAgICAgICBBcmlh bDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAg ICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAg ICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIN CiAgICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFz dC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgIFJvbWFu JnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgICAgICAgbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAg ICAgICAgICAgICBsYW5nPSJFTi1VUyI+wqDCoCBiZWhhbGYgb2YgYSBzdWJqZWN0LsKgIFRo aXMNCiAgICAgICAgICAgICAgICAgIHNwZWNpZmljYXRpb24gaXMgaW50ZW5kZWQgdG8gZW5h YmxlPC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjxicj4NCiAgICAgICAgICA8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAgIEFyaWFs O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAg Um9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgICBtc28t ZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAg ICAgIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseToNCiAgICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1 YWdlOkVOLVVTOw0KICAgICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28t YmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAg IEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAg ICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAg ICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFS LVNBIg0KICAgICAgICAgICAgICAgIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAgICAgICAgIEFyaWFsO21zby1m YXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAg Um9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgICAgICAg ICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAg ICAgICAgICAgICAgICAgIGxhbmc9IkVOLVVTIj7CoMKgIHJlcHJlc2VudGluZyBzZWN1cml0 eS0gYW5kDQogICAgICAgICAgICAgICAgICBpZGVudGl0eS1yZWxhdGVkIGV2ZW50cy7CoCBB IFNFVCBpcyBhIEpTT048L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PGJyPg0KICAgICAg ICAgIDxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAg ICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQog ICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAg ICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNB Ig0KICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNv LWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1 YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICBsYW5nPSJF Ti1VUyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAg ICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3DQogICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4t VVM7DQogICAgICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGkt bGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAg QXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAg ICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAg ICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdl OkFSLVNBIg0KICAgICAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPsKgwqAgV2ViIFRva2Vu IChKV1QpLCB3aGljaCBjYW4gYmUNCiAgICAgICAgICAgICAgICAgIG9wdGlvbmFsbHkgc2ln bmVkIGFuZC9vciBlbmNyeXB0ZWQuPC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjxicj4N CiAgICAgICAgICA8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToN CiAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldw0KICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7 DQogICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFn ZTpBUi1TQSINCiAgICAgICAgICAgIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgIFJvbWFuJnF1 b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgICBtc28tZmFyZWFz dC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAgICAg bGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 Og0KICAgICAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1 YWdlOkVOLVVTOw0KICAgICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21z by1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICAgIGxhbmc9IkVOLVVTIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAg ICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0K ICAgICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7 DQogICAgICAgICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1s YW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAgICAgICAgIGxhbmc9IkVOLVVTIj7CoMKgIFNF VHMgY2FuIGJlIGRpc3RyaWJ1dGVkIHZpYSBwcm90b2NvbHMNCiAgICAgICAgICAgICAgICAg IHN1Y2ggYXMgSFRUUC48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PGJyPg0KICAgICAg ICAgIDxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAg ICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQog ICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAg ICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNB Ig0KICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNv LWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1 YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICBsYW5nPSJF Ti1VUyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAg ICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3DQogICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4t VVM7DQogICAgICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGkt bGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAg QXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAg ICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAg ICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdl OkFSLVNBIg0KICAgICAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwvc3Bhbj4NCiAgICAgICAgICA8ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgi PjxzcGFuDQogICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5Og0KICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3Vh Z2U6RU4tVVM7DQogICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1i aWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICAgICAg QXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAg ICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAg ICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVIt U0EiDQogICAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAgQXJpYWw7bXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgICBS b21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgICAgICAg IG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAg ICAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAg IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAg ICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAg ICAgICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7 DQogICAgICAgICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRp LWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+PGJy Pg0KICAgICAgICAgICAgICAgICAgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFz dC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgICAgUm9t YW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgICAgICAgICAg IG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAg ICAgICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+VGhlcmUgaXMgYSBuZWVkIHRvIGJlIGFi bGUgdG8gdXNlDQogICAgICAgICAgICAgICAgICAgIHN1YmplY3QgaWRlbnRpZmllcnMgdGhh dCB3aWxsIG5vdCBuZWNlc3NhcmlseSBiZQ0KICAgICAgICAgICAgICAgICAgICB1c2VkIGlu PC9zcGFuPjwvc3Bhbj48c3Bhbg0KICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICAgICAgICBBcmlhbDttc28tZmFy ZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgIFJv bWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgICAgICAg bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAg ICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+PC9zcGFuPjwvc3Bhbj48c3Bhbg0KICAgICAg ICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAg ICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dw0KICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVT Ow0KICAgICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxh bmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICAgIGxhbmc9IkVOLVVTIj48L3NwYW4+PC9z cGFuPjxzcGFuDQogICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5Og0KICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFu Z3VhZ2U6RU4tVVM7DQogICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21z by1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+PC9z cGFuPjxzcGFuDQogICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5Og0KICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFu Z3VhZ2U6RU4tVVM7DQogICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21z by1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICAg ICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAg ICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAg ICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6 QVItU0EiDQogICAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAgQXJpYWw7bXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAg ICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgICAg ICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0K ICAgICAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAg ICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAg ICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcN CiAgICAgICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4t VVM7DQogICAgICAgICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1i aWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+ PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseToNCiAgICAgICAgICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1m b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgICAgICBSb21h biZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgICAgICAgICAg ICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAg ICAgICAgICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAg ICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAg ICAgICAgICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3DQogICAgICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5z aS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgICAgICAgICAgICAgIG1zby1mYXJlYXN0 LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICAg ICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICAg IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAg ICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFu Z3VhZ2U6RU4tVVM7DQogICAgICAgICAgICAgICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxh bmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICAgICAg ICAgICAgICBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1l cw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5ldyBSb21hbiZxdW90Ozttc28tYW5z aS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxh bmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PGJyPg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGEgU2VjdXJpdHkgRXZlbnQgVG9rZW4gKFNFVCkgZGF0YSA8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48L3NwYW4+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAgICAgICAgICAgICBBcmlh bDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAg ICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAg ICAgICAgICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5n dWFnZTpBUi1TQSINCiAgICAgICAgICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+PHNwYW4N CiAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5Og0KICAgICAgICAgICAgICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgICAgICAgICBSb21h biZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgICAgICAgICAg ICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0K ICAgICAgICAgICAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAg ICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0K ICAgICAgICAgICAgICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgUm9tYW4mcXVv dDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgICAgICAgICAgICAgICAg IG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAg ICAgICAgICAgICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZh bWlseTomcXVvdDtUaW1lcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5ldyBSb21h biZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdl OkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+c3RydWN0dXJlPC9z cGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48 c3Bhbg0KICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eToNCiAgICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3DQogICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdl OkVOLVVTOw0KICAgICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlk aS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgIEFy aWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAg ICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAg ICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNB Ig0KICAgICAgICAgICAgICAgIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAgICAgICAgIEFyaWFsO21zby1mYXJl YXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAgUm9t YW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgICAgICAgICBt c28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAg ICAgICAgICAgICAgIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAgICAgICAg ICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAg ICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0K ICAgICAgICAgICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1s YW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFu DQogICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6DQogICAgICAgICAgICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgICAgICAgUm9tYW4mcXVv dDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgICAgICAgICAgICAgbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAg ICAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAg ICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAg ICAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldw0KICAgICAgICAgICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFu Z3VhZ2U6RU4tVVM7DQogICAgICAgICAgICAgICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5n dWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAgICAgICAgICAg ICAgIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQog ICAgICAgICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdl OkVOLVVTOw0KICAgICAgICAgICAgICAgICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFn ZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAgICAgICAgICAgICAg ICAgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICBOZXcgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFu Z3VhZ2U6RU4tVVM7DQptc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFn ZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOZXcgUm9tYW4mcXVvdDs7 bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28t YmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 Og0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1m b250LWZhbWlseTomcXVvdDtUaW1lcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBOZXcgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFyZWFz dC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxz cGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQpBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb21h biZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdl OkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5Og0KQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90 Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21z by1iaWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+Ljwvc3Bhbj48L3NwYW4+PC9z cGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwvZGl2Pg0KICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICA8L2Rp dj4NCiAgICAgIDxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+PHNwYW4NCiAgICAgICAg ICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICBBcmlh bDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICBS b21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICBtc28tZmFy ZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMi PjxzcGFuDQogICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eToNCiAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldw0KICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4t VVM7DQogICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5n dWFnZTpBUi1TQSINCiAgICAgICAgICAgIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAgICAgQXJpYWw7bXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgIFJvbWFu JnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgICBtc28tZmFy ZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAg ICAgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5Og0KICAgICAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxh bmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZS O21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICAgIGxhbmc9IkVOLVVT Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAg ICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dw0KICAgICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4t VVM7DQogICAgICAgICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlk aS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAgICAgICAgIGxhbmc9IkVOLVVTIj48c3Bh bg0KICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseToNCiAgICAgICAgICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21z by1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgICAgICAgICBtc28tZmFyZWFz dC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAgICAg ICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICAgICAgICAgICAg QXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAg ICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQog ICAgICAgICAgICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGkt bGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxz cGFuDQogICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseToNCiAgICAgICAgICAgICAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAgICAgICAg Um9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgICAgICAg ICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1T QSINCiAgICAgICAgICAgICAgICAgICAgICAgIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAg ICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eToNCiAgICAgICAgICAgICAgICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgICAgICAgICAgIFJvbWFu JnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgICAgICAgICAg ICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIN CiAgICAgICAgICAgICAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBOZXcg Um9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFyZWFzdC1sYW5n dWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxzcGFuDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseToNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFyaWFsO21zby1m YXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBOZXcgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28t ZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4t VVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcw0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBOZXcgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFu Z3VhZ2U6RU4tVVM7DQptc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFn ZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvZGl2Pg0KICAgICAgPGRpdiBj bGFzcz0ibW96LWNpdGUtcHJlZml4Ij48c3Bhbg0KICAgICAgICAgIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1h bnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZS O21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAg ICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAg QXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAg ICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAg IG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAg ICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5Og0KICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2kt bGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZS O21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAg ICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQog ICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQog ICAgICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3Vh Z2U6QVItU0EiDQogICAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAgQXJpYWw7 bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAg ICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAg ICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNB Ig0KICAgICAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAg ICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAg ICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcNCiAgICAgICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6 RU4tVVM7DQogICAgICAgICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21z by1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICAgICAgICBsYW5nPSJFTi1V UyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseToNCiAgICAgICAgICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFz dC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgICAgICBS b21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgICAgICAg ICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIN CiAgICAgICAgICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAg ICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAg ICAgICAgICAgICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28t YW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgICAgICAgICAgICAgIG1zby1mYXJl YXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAg ICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAg ICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAg ICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2kt bGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgICAgICAgICAgICAgICAgIG1zby1mYXJlYXN0 LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICAg ICAgICAgICAgICBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtU aW1lcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5ldyBSb21hbiZxdW90Ozttc28t YW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRp LWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5ldyBSb21h biZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdl OkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFyaWFsO21zby1m YXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIE5ldyBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1z by1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJF Ti1VUyI+VGhlc2UgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4NCiAgICAg ICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICBB cmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAg ICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICBtc28t ZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4t VVMiPjxzcGFuDQogICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseToNCiAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldw0KICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6 RU4tVVM7DQogICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1s YW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAgIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAgICAgQXJpYWw7bXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgIFJv bWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgICBtc28t ZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAg ICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5Og0KICAgICAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNp LWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdl OkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICAgIGxhbmc9IkVO LVVTIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAg ICAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldw0KICAgICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6 RU4tVVM7DQogICAgICAgICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28t YmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAgICAgICAgIGxhbmc9IkVOLVVTIj48 c3Bhbg0KICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseToNCiAgICAgICAgICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7 O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgICAgICAgICBtc28tZmFy ZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAg ICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICAgICAgICAg ICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAg ICAgICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7 DQogICAgICAgICAgICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJp ZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICAgICAgICAgICAgbGFuZz0iRU4tVVMi PjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseToNCiAgICAgICAgICAgICAgICAgICAgICAgIEFyaWFsO21zby1mYXJl YXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAgICAg ICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgICAg ICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpB Ui1TQSINCiAgICAgICAgICAgICAgICAgICAgICAgIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAg ICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseToNCiAgICAgICAgICAgICAgICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgICAgICAgICAgIFJv bWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgICAgICAg ICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1T QSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBO ZXcgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFyZWFzdC1s YW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxzcGFu DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseToNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFyaWFsO21z by1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBOZXcgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQpt c28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0i RU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcw0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOZXcgUm9tYW4mcXVvdDs7bXNvLWFuc2kt bGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5n dWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQpBcmlh bDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpF Ti1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNB IiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KQXJpYWw7bXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsN Cm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5n PSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQpBcmlhbDttc28tZmFyZWFz dC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQpt c28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0i RU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQpBcmlhbDttc28tZmFyZWFz dC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsN Cm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5n PSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KQXJpYWw7bXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpF Ti1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNB IiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQpBcmlh bDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2kt bGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5n dWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6DQpBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb21hbiZx dW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdlOkZS O21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1m YXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1V UyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQpBcmlhbDttc28t ZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2kt bGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5n dWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6DQpBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0 LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNw YW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KQXJpYWw7bXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5z aS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxh bmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6DQpBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQpt c28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0i RU4tVVMiPlN1YmplY3QNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgSWRlbnRpZmllcnMNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWlnaHQgc3RpbGwgYmUNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdXNl ZCBpbiA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bh bj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9z cGFuPjwvc3Bhbj48c3Bhbg0KICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5Og0KICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldw0KICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdl OkVOLVVTOw0KICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxh bmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgQXJpYWw7bXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICBSb21hbiZx dW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgIG1zby1mYXJlYXN0 LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgbGFu Zz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0K ICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcNCiAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4t VVM7DQogICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxh bmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICAgICAgQXJpYWw7 bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAg ICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgICAg ICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQog ICAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgICBSb21hbiZx dW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgICAgICAgIG1zby1m YXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAg ICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAgICBB cmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAg ICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAg ICAgICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1 YWdlOkFSLVNBIg0KICAgICAgICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+PHNwYW4NCiAg ICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eToNCiAgICAgICAgICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90Oztt c28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgICAgICAgICAgICBtc28tZmFy ZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAg ICAgICAgICAgICBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAg IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAg ICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 DQogICAgICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFn ZTpFTi1VUzsNCiAgICAgICAgICAgICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdl OkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICAgICAgICAgICAg bGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAgICAgICAg ICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4t VVM7DQogICAgICAgICAgICAgICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZS O21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICAgICAgICAgICAgICBs YW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcw0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgIE5ldyBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFn ZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFS LVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5ldyBSb21hbiZxdW90Ozttc28t YW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRp LWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5l dyBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxh bmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseToNCkFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1 b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7 bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6DQpBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21z by1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJp ZGktbGFuZ3VhZ2U6QVItU0EiIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseToNCkFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28t YW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRp LWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseToNCkFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21z by1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJp ZGktbGFuZ3VhZ2U6QVItU0EiIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6DQpBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1 b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7 bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseToNCkFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxh bmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCkFyaWFsO21zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0K bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiIGxhbmc9 IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQpBcmlhbDtt c28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNp LWxhbmd1YWdlOkVOLVVTOw0KbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFu Z3VhZ2U6QVItU0EiIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseToNCkFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxh bmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCkFyaWFsO21zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1 YWdlOkVOLVVTOw0KbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6 QVItU0EiIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6DQpBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KbXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiIGxhbmc9IkVOLVVTIj48c3Bh bg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCkFyaWFsO21zby1m YXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28t YW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRp LWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseToNCkFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVO LVVTOw0KbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0Ei IGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5Og0KQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFyZWFz dC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxz cGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQpBcmlhbDtt c28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90 Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21z by1iaWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCkFyaWFsO21zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1 YWdlOkVOLVVTOw0KbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6 QVItU0EiIGxhbmc9IkVOLVVTIj5hIDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48c3Bh bg0Kc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQpBcmlhbDttc28tZmFy ZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28t YW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRp LWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseToNCkFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVO LVVTOw0KbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0Ei IGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5Og0KQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFyZWFz dC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxz cGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQpBcmlhbDtt c28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90 Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21z by1iaWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCkFyaWFsO21zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1 YWdlOkVOLVVTOw0KbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6 QVItU0EiIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5Og0KQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28t ZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4t VVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQpB cmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb21h biZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdl OkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCkFyaWFsO21zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNp LWxhbmd1YWdlOkVOLVVTOw0KbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFu Z3VhZ2U6QVItU0EiIGxhbmc9IkVOLVVTIj5TZWN1cml0eQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEV2ZW50IFRva2VuDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKFNFVCkgZGF0YSA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4NCnN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KQXJpYWw7bXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFu Z3VhZ2U6RU4tVVM7DQptc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFn ZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6DQpBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1z by1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJF Ti1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToN CkFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJv bWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KQXJpYWw7bXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFu c2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1s YW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPnN0cnVjdHVyZSw8L3NwYW4+PC9zcGFuPjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8aT5idXQgbm90 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgbmVjZXNzYXJpbGx5PC9pPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPi48 YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3NwYW4+PC9zcGFuPjwvc3Bh bj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9z cGFuPjwvc3Bhbj48L2Rpdj4NCiAgICAgIDx1bD4NCiAgICAgICAgPGxpPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgQXJpYWw7bXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICBSb21h biZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgIG1zby1mYXJl YXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAg bGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 Og0KICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcNCiAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6 RU4tVVM7DQogICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRp LWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICAgICAgQXJp YWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAg ICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAg ICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0Ei DQogICAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgICBSb21h biZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgICAgICAgIG1z by1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAg ICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAg ICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAg ICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQog ICAgICAgICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxh bmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+PHNwYW4N CiAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseToNCiAgICAgICAgICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90 Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgICAgICAgICAgICBtc28t ZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAg ICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAg ICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAg ICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3DQogICAgICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5n dWFnZTpFTi1VUzsNCiAgICAgICAgICAgICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1 YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICAgICAgICAg ICAgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAgICAg ICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6 RU4tVVM7DQogICAgICAgICAgICAgICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdl OkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICAgICAgICAgICAg ICBsYW5nPSJFTi1VUyI+V2hlbiBzdXBwb3J0aW5nIFJCQUMgKFJvbGUgQmFzZWQNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgQWNjZXNzIENvbnRyb2wpLCBpdCB3b3VsZCBiZSBuaWNl IHRvIGRlZmluZSA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjxzcGFuDQogICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseToNCiAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2kt bGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjtt c28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAgIGxhbmc9IkVOLVVTIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAgICAg QXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAg ICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAg ICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIN CiAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7 O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgICAgIG1zby1mYXJlYXN0 LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICAg IGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eToNCiAgICAgICAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2kt bGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFn ZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAgICAgICAgIGxhbmc9 IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgICAgIFJv bWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgICAgICAg ICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAg ICAgICAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAg ICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAg ICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3DQogICAgICAgICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3Vh Z2U6RU4tVVM7DQogICAgICAgICAgICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICAgICAgICAgICAgbGFu Zz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAgICAgICAgICAgICAgIEFyaWFs O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAg ICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAg ICAgICAgICAgICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1s YW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAgICAgICAgICAgICAgIGxhbmc9IkVOLVVTIj48 c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseToNCiAgICAgICAgICAgICAgICAgICAgICAgICAgQXJpYWw7bXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgICAg ICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAg ICAgICAgICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5n dWFnZTpBUi1TQSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxz cGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgQXJpYWw7bXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICBOZXcgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28t ZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4t VVMiPiJzdWJfaWRzIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFibGUgdG8gc3Vw cG9ydCByb2xlcy48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwvc3Bhbj48L2xpPg0KICAgICAgICA8bGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICBBcmlhbDttc28tZmFy ZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgIFJvbWFuJnF1 b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgbXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICBsYW5n PSJFTi1VUyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQog ICAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldw0KICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1V UzsNCiAgICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFu Z3VhZ2U6QVItU0EiDQogICAgICAgICAgICAgIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAgICAgICBBcmlhbDtt c28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAg ICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgICAg ICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAg ICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1m b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgIFJvbWFuJnF1 b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgICAgICAgbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAg ICAgICAgICBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICAgICAgICAgIEFy aWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAg ICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAg ICAgICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3Vh Z2U6QVItU0EiDQogICAgICAgICAgICAgICAgICAgIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAg ICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 Og0KICAgICAgICAgICAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21z by1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgICAgICAgICAgIG1zby1mYXJl YXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAg ICAgICAgICAgIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAg c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICAgICAg ICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcN CiAgICAgICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdl OkVOLVVTOw0KICAgICAgICAgICAgICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICAgICAgICAgICAgICBs YW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICAgICAgICAgICAgICAg IEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAg ICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1V UzsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7 bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICAgICAgICAgICAgICAgIGxh bmc9IkVOLVVTIj5XaGVuIHN1cHBvcnRpbmcgQUJBQyAoQXR0cmlidXRlDQogICAgICAgICAg ICAgICAgICAgICAgICAgIEJhc2VzIEFjY2VzcyBDb250cm9sKSwgPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48c3Bhbg0KICAgICAg ICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAg ICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAg ICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAg ICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQog ICAgICAgICAgICBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6DQogICAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5z aS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICAgIGxhbmc9IkVOLVVT Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAg ICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcN CiAgICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsN CiAgICAgICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5n dWFnZTpBUi1TQSINCiAgICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICAgICAgICBBcmlh bDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAg ICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAg ICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVIt U0EiDQogICAgICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAg ICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAg ICAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldw0KICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFn ZTpFTi1VUzsNCiAgICAgICAgICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7 bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICAgICAgICAgIGxhbmc9IkVO LVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAgICAgIEFyaWFsO21zby1mYXJl YXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAgICAg IFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgICAg ICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNB Ig0KICAgICAgICAgICAgICAgICAgICAgIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAg ICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQog ICAgICAgICAgICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21z by1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAgICAgICAgICAgICAgbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAg ICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAg ICAgICAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldw0KICAgICAgICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5z aS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICAg ICAgICAgICAgICAgIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgTmV3IFJvbWFuJnF1b3Q7O21z by1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJp ZGktbGFuZ3VhZ2U6QVItU0EiIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZh bWlseTomcXVvdDtUaW1lcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTmV3IFJv bWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseToNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQXJpYWw7bXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgTmV3IFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0K bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiIGxhbmc9 IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KQXJpYWw7bXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFyZWFz dC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxz cGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseToNCkFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Um9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFyZWFzdC1sYW5n dWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxzcGFuDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5Og0KQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJv bWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5Og0KQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Um9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFyZWFzdC1sYW5n dWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxzcGFuDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseToNCkFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFyZWFz dC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPml0 IHdvdWxkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBiZSBu aWNlIHRvIGRlZmluZSA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bh bj48L3NwYW4+PC9zcGFuPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICBOZXcgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFu Z3VhZ2U6RU4tVVM7DQptc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFn ZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOZXcgUm9tYW4mcXVvdDs7 bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28t YmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 Og0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1m b250LWZhbWlseTomcXVvdDtUaW1lcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBOZXcgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFyZWFz dC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxz cGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQpBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb21h biZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdl OkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5Og0KQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90 Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21z by1iaWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6DQpBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7 bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28t YmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6DQpBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90 Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21z by1iaWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5Og0KQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb21h biZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdl OkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQpBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFyZWFz dC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPiJz dWJfaWRzIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBh YmxlIHRvIHN1cHBvcnQ8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGdyb3VwIG1lbWJlcnNoaXBzIHdpdGggdHdvDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZsYXZvdXJzIG9mIHRoZW0gOiAoYSkNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaGllcmFyY2hpY2Fs IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwv c3Bhbj48L3NwYW4+PHNwYW4NCiAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1s YW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21z by1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICBB cmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAg ICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAg ICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0K ICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7 bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgICAgICAgbXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICAgICAg bGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 Og0KICAgICAgICAgICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1s YW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdl OkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICAgICAgbGFuZz0i RU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFz dC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgICAgUm9t YW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAgICAgICAgICAg IG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIg0KICAg ICAgICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAg ICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAg ICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcNCiAgICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFn ZTpFTi1VUzsNCiAgICAgICAgICAgICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFnZTpG Ujttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAgICAgICAgICAgICBsYW5n PSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAgICAgICAgQXJpYWw7 bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAg ICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAg ICAgICAgICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxh bmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICAgICAgICAgICAgbGFuZz0iRU4tVVMiPjxz cGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAgICAgICAgICBBcmlhbDttc28tZmFy ZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQogICAgICAgICAg ICAgICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1 YWdlOkFSLVNBIg0KICAgICAgICAgICAgICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+PHNw YW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseToNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBBcmlhbDttc28t ZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcw0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgIE5ldyBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1m YXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1V UyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg QXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIE5ldyBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpF Ti1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNB IiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5ldyBSb21hbiZxdW90Oztt c28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1i aWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eToNCkFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxh bmd1YWdlOkVOLVVTOw0KbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3Vh Z2U6QVItU0EiIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQpBcmlh bDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdl OkVOLVVTOw0KbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVIt U0EiIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCkFyaWFsO21z by1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpF Ti1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNB IiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCkFyaWFsO21z by1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdl OkVOLVVTOw0KbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVIt U0EiIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQpBcmlh bDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxh bmd1YWdlOkVOLVVTOw0KbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3Vh Z2U6QVItU0EiIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eToNCkFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90Oztt c28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1i aWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseToNCkFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KbXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiIGxhbmc9IkVOLVVTIj48c3Bhbg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQpBcmlhbDttc28tZmFyZWFzdC1mb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVT Ow0KbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiIGxh bmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCkFy aWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90Oztt c28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1i aWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseToNCkFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiIGxhbmc9IkVO LVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQpBcmlh bDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7 O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNv LWJpZGktbGFuZ3VhZ2U6QVItU0EiIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCkFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpF Ti1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNB IiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseToNCkFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiIGxhbmc9IkVOLVVTIj48 c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KQXJpYWw7 bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9tYW4mcXVv dDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFyZWFzdC1sYW5ndWFnZTpGUjtt c28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQpBcmlhbDttc28tZmFyZWFzdC1mb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5n dWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdl OkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseToNCkFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiIGxhbmc9IkVO LVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0K QXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9t YW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFyZWFzdC1sYW5ndWFn ZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQpBcmlhbDttc28tZmFyZWFz dC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5z aS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxh bmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseToNCkFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVT Ow0KbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiIGxh bmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5Og0KQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFyZWFzdC1s YW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxzcGFu DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQpBcmlhbDttc28t ZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90Oztt c28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1i aWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCkFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdl OkVOLVVTOw0KbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVIt U0EiIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5Og0KQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFy ZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMi Pmdyb3VwcyBhbmQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAoYikgZnVuY3Rpb25hbA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvc3Bhbj48L3NwYW4+PC9z cGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFu Pjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwv c3Bhbj48c3Bhbg0KICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6DQogICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcNCiAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdl OkVOLVVTOw0KICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGkt bGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICAgIEFyaWFsO21z by1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICBS b21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgICAgbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAg ICAgICAgIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseToNCiAgICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5z aS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgICAgICBtc28tZmFyZWFzdC1sYW5ndWFn ZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSINCiAgICAgICAgICAgICAgICBsYW5nPSJF Ti1VUyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQogICAg ICAgICAgICAgICAgICBBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcNCiAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdl OkVOLVVTOw0KICAgICAgICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNv LWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+ PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6DQogICAgICAgICAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90 Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgICAgICAgICAgbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiDQogICAgICAgICAg ICAgICAgICAgIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAg ICAgIEFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAg ICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVT Ow0KICAgICAgICAgICAgICAgICAgICAgIG1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1i aWRpLWxhbmd1YWdlOkFSLVNBIg0KICAgICAgICAgICAgICAgICAgICAgIGxhbmc9IkVOLVVT Ij48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICAgICAgICAgICAgICBBcmlhbDttc28tZmFy ZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgICAg ICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KICAgICAgICAgICAg ICAgICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6 QVItU0EiDQogICAgICAgICAgICAgICAgICAgICAgICBsYW5nPSJFTi1VUyI+PHNwYW4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6DQogICAgICAgICAgICAgICAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0LWZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAgICAgICAgICBS b21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVIt U0EiDQogICAgICAgICAgICAgICAgICAgICAgICAgIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5Og0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFyaWFsO21zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg TmV3IFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KbXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiIGxhbmc9IkVOLVVTIj48c3Bh bg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBcmlhbDtt c28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcw0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgTmV3IFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0K bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiIGxhbmc9 IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTmV3IFJvbWFuJnF1b3Q7O21zby1hbnNp LWxhbmd1YWdlOkVOLVVTOw0KbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFu Z3VhZ2U6QVItU0EiIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KQXJp YWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6 RU4tVVM7DQptc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1T QSIgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCkFyaWFsO21zby1m YXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7 DQptc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFu Zz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KQXJpYWw7bXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0K bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiIGxhbmc9 IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KQXJpYWw7bXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7 DQptc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFu Zz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCkFyaWFsO21zby1m YXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6 RU4tVVM7DQptc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1T QSIgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KQXJp YWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNp LWxhbmd1YWdlOkVOLVVTOw0KbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFu Z3VhZ2U6QVItU0EiIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5Og0KQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9tYW4m cXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFyZWFzdC1sYW5ndWFnZTpG Ujttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseToNCkFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28t ZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4t VVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KQXJpYWw7bXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNp LWxhbmd1YWdlOkVOLVVTOw0KbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFu Z3VhZ2U6QVItU0EiIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5Og0KQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFyZWFz dC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxz cGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCkFyaWFsO21zby1m YXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFu c2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1s YW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5Og0KQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0K bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiIGxhbmc9 IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 Og0KQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Um9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFyZWFzdC1sYW5n dWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxzcGFuDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQpBcmlhbDttc28tZmFy ZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28t YW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRp LWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseToNCkFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVO LVVTOw0KbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0Ei IGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5Og0KQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFyZWFz dC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxz cGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQpBcmlhbDtt c28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90 Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21z by1iaWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCkFyaWFsO21zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1 YWdlOkVOLVVTOw0KbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6 QVItU0EiIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5Og0KQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28t ZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4t VVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQpB cmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb21h biZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdl OkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCkFyaWFsO21zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNp LWxhbmd1YWdlOkVOLVVTOw0KbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFu Z3VhZ2U6QVItU0EiIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5Og0KQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7 DQptc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFu Zz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6DQpBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxh bmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCkFyaWFsO21zby1m YXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21z by1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJp ZGktbGFuZ3VhZ2U6QVItU0EiIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6 RU4tVVM7DQptc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1T QSIgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6DQpBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1zby1mYXJl YXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+ PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCkFyaWFs O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbWFuJnF1 b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7 bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KQXJpYWw7bXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFu Z3VhZ2U6RU4tVVM7DQptc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1sYW5ndWFn ZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6DQpBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNCm1z by1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIiBsYW5nPSJF Ti1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToN CkFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJv bWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiIGxhbmc9IkVOLVVTIj48c3Bhbg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KQXJpYWw7bXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7bXNvLWFu c2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28tYmlkaS1s YW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQpBcmlhbDttc28tZmFyZWFzdC1mb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1V UzsNCm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFSLVNBIiBs YW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseToNCkFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldw0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KbXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiIGxhbmc9IkVOLVVTIj48c3Bh bg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KQXJpYWw7bXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9tYW4mcXVvdDs7 bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFyZWFzdC1sYW5ndWFnZTpGUjttc28t YmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQpBcmlhbDttc28tZmFyZWFzdC1mb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFn ZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1YWdlOkFS LVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseToNCkFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0KbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiIGxhbmc9IkVOLVVT Ij48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KQXJp YWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9tYW4m cXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFyZWFzdC1sYW5ndWFnZTpG Ujttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPjxzcGFuDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6DQpBcmlhbDttc28tZmFyZWFzdC1m b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb21hbiZxdW90Ozttc28tYW5zaS1s YW5ndWFnZTpFTi1VUzsNCm1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO21zby1iaWRpLWxhbmd1 YWdlOkFSLVNBIiBsYW5nPSJFTi1VUyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseToNCkFyaWFsO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTOw0K bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7bXNvLWJpZGktbGFuZ3VhZ2U6QVItU0EiIGxhbmc9 IkVOLVVTIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 Og0KQXJpYWw7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Um9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM7DQptc28tZmFyZWFzdC1sYW5n dWFnZTpGUjttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSIgbGFuZz0iRU4tVVMiPmdyb3Vwczsg PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bh bj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9z cGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFu Pjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9saT4NCiAgICAgIDwvdWw+DQog ICAgICA8Zm9udCBmYWNlPSJBcmlhbCI+VGhlIGN1cnJlbnQgdGl0bGUgb2YgdGhlIGRyYWZ0 IGlzOiAiU3ViamVjdA0KICAgICAgICBJZGVudGlmaWVycyBmb3IgU2VjdXJpdHkgRXZlbnQg VG9rZW5zIiAuPGJyPg0KICAgICAgICBNb3JlIGFwcHJvcHJpYXRlIHRpdGxlcyB3b3VsZCBi ZTo8L2ZvbnQ+DQogICAgICA8YmxvY2txdW90ZT48Zm9udCBmYWNlPSJBcmlhbCI+U3ViamVj dCBJZGVudGlmaWVycyBmb3IgU2VjdXJpdHkNCiAgICAgICAgICBFdmVudCBUb2tlbnMgPGk+ YTwvaT48aT5uZCBvdGhlciBwdXJwb3NlczwvaT48L2ZvbnQ+PC9ibG9ja3F1b3RlPg0KICAg ICAgPGZvbnQgZmFjZT0iQXJpYWwiPm9yIHNpbXBseTxicj4NCiAgICAgIDwvZm9udD4NCiAg ICAgIDxibG9ja3F1b3RlPjxmb250IGZhY2U9IkFyaWFsIj5TdWJqZWN0IElkZW50aWZpZXJz PGJyPg0KICAgICAgICA8L2ZvbnQ+PC9ibG9ja3F1b3RlPg0KICAgICAgPGZvbnQgZmFjZT0i QXJpYWwiPlRoZSBmaXJzdCBzZW50ZW5jZSBvZiB0aGUgYWJzdHJhY3Qgc2hvdWxkIGFsc28N CiAgICAgICAgYmUgc2xpZ2h0bHkgbW9kaWZpZWQuPGJyPg0KICAgICAgPC9mb250PjwvZGl2 Pg0KICAgIDxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+PGZvbnQgZmFjZT0iQXJpYWwi Pjxicj4NCiAgICAgIDwvZm9udD48L2Rpdj4NCiAgICA8ZGl2IGNsYXNzPSJtb3otY2l0ZS1w cmVmaXgiPjxmb250IGZhY2U9IkFyaWFsIj5EZW5pczwvZm9udD48L2Rpdj4NCiAgICA8ZGl2 IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPjxicj4NCiAgICA8L2Rpdj4NCiAgICA8ZGl2IGNs YXNzPSJtb3otY2l0ZS1wcmVmaXgiPjxicj4NCiAgICA8L2Rpdj4NCiAgICA8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIg0KY2l0ZT0ibWlkOkNBTThmZXVTTzhBR2tiUEV2aFlpSk9pVXZZaHd0 TzdrZjBlSjNvZ1R6SE5uYnRxTFBQUUBtYWlsLmdtYWlsLmNvbSI+DQogICAgICA8bWV0YSBo dHRwLWVxdWl2PSJjb250ZW50LXR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1V VEYtOCI+DQogICAgICA8ZGl2IGRpcj0iYXV0byI+SGkgVG9iaWFzLA0KICAgICAgICA8ZGl2 IGRpcj0iYXV0byI+PGJyPg0KICAgICAgICA8L2Rpdj4NCiAgICAgICAgPGRpdiBkaXI9ImF1 dG8iPk9wdGlvbiAyJ3MgcHJvcyBhbmQgY29ucyBhcmUgdGhlIGNvbnNlcXVlbmNlIG9mDQog ICAgICAgICAgc29sZWx5IHJlbHlpbmcgb25seSBvbiBhbiBvcGFxdWUgaWRlbnRpZmllciBt YW5hZ2VkIGJ5IHRoZSBBUywNCiAgICAgICAgICBpbmRlcGVuZGFudGx5IGZyb20gZXh0ZXJu YWwgaWRlbnRpZmllcnMuwqA8L2Rpdj4NCiAgICAgICAgPGRpdiBkaXI9ImF1dG8iPjxicj4N CiAgICAgICAgPC9kaXY+DQogICAgICAgIDxkaXYgZGlyPSJhdXRvIj5UaGF0J3MgYW4gYWRk aXRpb25hbCBsZXZlbCBvZiBpbmRpcmVjdGlvbiwgbm90DQogICAgICAgICAgdW5saWtlIGhv dyBpbmRleGVzIGFyZSB1c3VhbGx5IG1hbmFnZWQgaW4gYSBkYXRhYmFzZS4gQnV0DQogICAg ICAgICAgdGhlcmUncyBvYnZpb3VzbHkgdGhlIGFkZGl0aW9uYWwgY29tcGxleGl0eSBvZiBt YWtpbmcgYSBqdXN0DQogICAgICAgICAgaW4gdGltZSB0cmFuc2xhdGlvbiBpbnRvIGEgcHJh Y3RpY2FsIGlkZW50aWZpZXIgKGxpa2UgZW1haWwNCiAgICAgICAgICBmb3IgYWNjb3VudCBy ZWNvdmVyeSwgYXMgZGlzY3Vzc2VkIGJ5IEp1c3RpbikuwqA8L2Rpdj4NCiAgICAgICAgPGRp diBkaXI9ImF1dG8iPjxicj4NCiAgICAgICAgPC9kaXY+DQogICAgICAgIDxkaXYgZGlyPSJh dXRvIj4iQTxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpzYW5zLXNlcmlmIj5zc2VydGlvbnMi DQogICAgICAgICAgICBzaG91bGQgYmUgd2hhdDwvc3Bhbj7CoHRoZSBBUyAocG9zc2libHkg d2l0aCB0aGUgYXNzaXN0YW5jZQ0KICAgICAgICAgIG9mIG90aGVyIHBhcnRpZXMpIGNhbiBj b25maWRlbnRseSBzYXkgYWJvdXQgdGhlIHN1YmplY3QuwqA8L2Rpdj4NCiAgICAgICAgPGRp diBkaXI9ImF1dG8iPjxicj4NCiAgICAgICAgPC9kaXY+DQogICAgICAgIDxkaXYgZGlyPSJh dXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6c2Fucy1zZXJpZiI+VGhhbmtzIGZvcg0K ICAgICAgICAgICAgdGhlIGdyZWF0IGZlZWRiYWNrLCBhcyB3ZWxsIGFzIEp1c3RpbidzLsKg PC9zcGFuPlNpbmNlIHRoZQ0KICAgICAgICAgIHNsaWRlcyB3ZXJlIHdyaXR0ZW4sIFNFQ0VW RU5UIGRyYWZ0LTA3IGFscmVhZHkgb2ZmZXJzIG5ldw0KICAgICAgICAgIHBvc3NpYmlsaXRp ZXMgd2hpY2ggaXMgZ29vZCBuZXdzLsKgPC9kaXY+DQogICAgICAgIDxkaXYgZGlyPSJhdXRv Ij48YnI+DQogICAgICAgIDwvZGl2Pg0KICAgICAgICA8ZGl2IGRpcj0iYXV0byI+RmFiaWVu PGJyPg0KICAgICAgICAgIDxicj4NCiAgICAgICAgICA8ZGl2IGNsYXNzPSJnbWFpbF9xdW90 ZSIgZGlyPSJhdXRvIj4NCiAgICAgICAgICAgIDxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFp bF9hdHRyIj5MZSBtZXIuIDEwIG1hcnMgMjAyMSDDoA0KICAgICAgICAgICAgICAyMjowMiwg VG9iaWFzIExvb2tlciA8YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJt YWlsdG86dG9iaWFzLmxvb2tlckBtYXR0ci5nbG9iYWwiPiZsdDt0b2JpYXMubG9va2VyQG1h dHRyLmdsb2JhbCZndDs8L2E+IGENCiAgICAgICAgICAgICAgw6ljcml0wqA6PGJyPg0KICAg ICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICA8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf cXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDANCiAgICAgICAgICAgICAgLjhleDtib3JkZXIt bGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCiAgICAgICAgICAgICAg PGRpdiBkaXI9Imx0ciI+Jmd0OyBUaGFua3MgZm9yIHRoZSBmZWVkYmFjaywgYWx0aG91Z2gg SSdtDQogICAgICAgICAgICAgICAgbm90IHN1cmUgd2hhdCB5b3UgbWVhbiBieSB0b28gYWJz dHJhY3QuDQogICAgICAgICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAgICAgICAgPC9k aXY+DQogICAgICAgICAgICAgICAgPGRpdj5BcG9sb2dpZXMgd2hhdCBJIG1lYW4gYnkgdGhh dCB3YXMgSSBmZWVsIGxpa2UNCiAgICAgICAgICAgICAgICAgIE9wdGlvbiAyIHdvdWxkIGV4 cG9zZSB0b28gbXVjaCBjb21wbGV4aXR5IHRvIGNsaWVudHMNCiAgICAgICAgICAgICAgICAg IHRoYXQgd291bGQgYmUgcmVxdWlyZWQgdG8gY29uc3RydWN0IGEgcmVxdWVzdCB0byB0aGUN CiAgICAgICAgICAgICAgICAgIEFTLiBPcHRpb24gMSBJTU8gc3RyaWtlcyBhIGJldHRlciBi YWxhbmNlIGJ5IHN0aWxsDQogICAgICAgICAgICAgICAgICBvZmZlcmluZyB0aGUgcmVxdWly ZWQgZmxleGliaWxpdHkgYnV0IGtlZXBpbmcgdGhpbmdzDQogICAgICAgICAgICAgICAgICBy ZWxhdGl2ZWx5IHNpbXBsZS48L2Rpdj4NCiAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAg ICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICA8ZGl2PiZndDsgSnVzdCBh IHF1aWNrIGNvbW1lbnQ6IGFuIGFzc2VydGlvbiBpbiBvcHRpb24gMg0KICAgICAgICAgICAg ICAgICAgaXMgbm90ICJ0aGUgZmFjdCB0aGUgaWRlbnRpZmllciBpcyByZXNvbHZhYmxlIHRv DQogICAgICAgICAgICAgICAgICBjcnlwdG9ncmFwaGljIG1hdGVyaWFsIHRoYXTCoDxpPmNh bsKgPC9pPmJlIHVzZWQgdG8NCiAgICAgICAgICAgICAgICAgIHZhbGlkYXRlIGNyeXB0b2dy YXBoaWMgYXNzZXJ0aW9ucyIuIEl0IGlzIG1lcmVseSBhDQogICAgICAgICAgICAgICAgICBz dGF0ZW1lbnQgYnkgdGhlIEFTIHRoYXQgInRoZSBzdWJqZWN0IGNvcnJlc3BvbmRpbmcgdG8N CiAgICAgICAgICAgICAgICAgIHRoZSByZWZlcmVuY2UgaGFzIGEgRElEIiAoImhhcyIgaXMg dGhlIGFzc2VydGlvbg0KICAgICAgICAgICAgICAgICAgaGVyZSkuwqA8L2Rpdj4NCiAgICAg ICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAg ICAgICAgICA8ZGl2PlllcyBJIHVuZGVyc3RhbmQgdG8gZHJpbGwgZG93biBvbiB0aGlzIG1v cmUgdGhvdWdoDQogICAgICAgICAgICAgICAgICBjb3VsZG4ndCB0aGUgZW50aXJlIHJlcXVl c3QgbWFkZSBieSB0aGUgY2xpZW50IHRvIHRoZQ0KICAgICAgICAgICAgICAgICAgQVMgYWxz byBiZSBjb25zaWRlcmVkIHRvIGJlIGFuIGFzc2VydGlvbj8gVGhlcmVmb3JlDQogICAgICAg ICAgICAgICAgICB0aGXCoCJzdWJfaWRzIiByZXF1ZXN0IGVsZW1lbnQgaXMgYW4gYXNzZXJ0 aW9uIGJ5IHRoZQ0KICAgICAgICAgICAgICAgICAgY2xpZW50IGFib3V0IHdobyBpdCBiZWxp ZXZlcyB0aGUgc3ViamVjdCB0byBiZQ0KICAgICAgICAgICAgICAgICAgaWRlbnRpZmllZCBh cz8gSWYgdGhpcyBpcyB0cnVlIHRoZW4gdG8gbWUgdGhlDQogICAgICAgICAgICAgICAgICAi YXNzZXJ0aW9ucyIgcmVxdWVzdCBlbGVtZW50IGlzIHRoZXJlIGZvciBhc3NlcnRpb25zDQog ICAgICAgICAgICAgICAgICB0aGF0IHBhcnRpZXMgb3RoZXIgdGhhbiB0aGUgY2xpZW50IGFy ZSBtYWtpbmcgYWJvdXQNCiAgICAgICAgICAgICAgICAgIHRoZSBzdWJqZWN0IChlLmcgYW4g aWRfdG9rZW4pLjwvZGl2Pg0KICAgICAgICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAg ICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgIDxkaXY+VGhhbmtzLDwvZGl2Pg0KICAg ICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAg ICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAg ICAgICAgICAgICAgICAgICA8ZGl2IGRpcj0ibHRyIiBkYXRhLXNtYXJ0bWFpbD0iZ21haWxf c2lnbmF0dXJlIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBkaXI9Imx0ciI+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgPHRhYmxlDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtmb250LWZhbWlseTpUaW1l cztmb250LXNpemU6bWVkaXVtO2JvcmRlcjowcHgiDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB3aWR0aD0iYXV0byIgY2VsbHNwYWNpbmc9IjAiDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBjZWxscGFkZGluZz0iMCIgYm9yZGVyPSIwIj4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDx0Ym9keT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPHRyIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2ENCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBOZXVlJnF1b3Q7LEhlbHZldGljYSxBcmlhbCxz YW5zLXNlcmlmO2ZvbnQtc2l6ZToxMXB4O2xpbmUtaGVpZ2h0OjE2cHgiPg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0iMTI1IiB2YWxpZ249InRvcCI+ PGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0iaHR0cHM6 Ly9tYXR0ci5nbG9iYWwiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHN0eWxlPSJib3JkZXI6bm9uZTtjb2xvcjpyZ2IoMTUsMTczLDIyNSkiDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIiByZWw9Im5vcmVm ZXJyZXIiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1u b3Qtc2VuZD0idHJ1ZSI+PGltZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHNyYz0iaHR0cHM6Ly9tYXR0ci5nbG9iYWwvYXNzZXRzL2ltYWdlcy9NYXR0ckxv Z28ucG5nIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFsdD0i TWF0dHIgd2Vic2l0ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBzdHlsZT0iaGVpZ2h0OmF1dG8iDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHdpZHRoPSIxMjUiIGhlaWdodD0iMTI1Ij48L2E+PC90ZD4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8dGQgd2lkdGg9IjE2Ij7CoDwv dGQ+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHRkDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iY29sb3I6cmdiKDUxLDQ5LDUwKTtm b250LXNpemU6MTJweCINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdp ZHRoPSIxNTkiIHZhbGlnbj0idG9wIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDx0YWJsZSBzdHlsZT0iYm9yZGVyOjBweCINCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBib3JkZXI9IjAiPg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8dGJvZHk+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPHRyDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh DQpOZXVlJnF1b3Q7LEhlbHZldGljYSxBcmlhbCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxMXB4 O2xpbmUtaGVpZ2h0OjE2cHgiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPHRkPjxzdHJvbmcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEycHgiPlRvYmlhcw0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIExvb2tlcjwvc3Ryb25nPjxi cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvdGQ+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90cj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8dHINCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2ENCk5ldWUmcXVvdDssSGVsdmV0aWNhLEFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXpl OjExcHg7bGluZS1oZWlnaHQ6MTZweCI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8dGQgc3R5bGU9ImxpbmUtaGVpZ2h0OjE2cHgiPk1hdHRyPC90ZD4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RyPg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx0cg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYQ0KTmV1ZSZxdW90OyxIZWx2ZXRpY2EsQXJpYWwsc2Fucy1zZXJpZjtmb250LXNp emU6MTFweDtsaW5lLWhlaWdodDoxNnB4Ij4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDx0ZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBzdHlsZT0ibGluZS1oZWlnaHQ6MTZweDtwYWRkaW5nLXRvcDoxMnB4Ij4r NjQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKDApIDI3 IDM3OCAwNDYxPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGhyZWY9Im1haWx0bzp0b2JpYXMubG9va2VyQG1hdHRyLmdsb2JhbCINCnN0eWxlPSJib3Jk ZXI6bm9uZTtjb2xvcjpyZ2IoNTEsNDksNTApIiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub3Jl ZmVycmVyIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+dG9iaWFzLmxvb2tlckBtYXR0ci5nbG9iYWw8L2E+ PC90ZD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RyPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx0cg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYQ0KTmV1ZSZxdW90OyxIZWx2ZXRpY2EsQXJpYWwsc2Fucy1zZXJpZjtm b250LXNpemU6MTFweDtsaW5lLWhlaWdodDoxNnB4Ij4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDx0ZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEycHg7cGFkZGluZy10b3A6MTJw eCI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx0YWJs ZSBzdHlsZT0iYm9yZGVyOjBweCINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBjZWxsc3BhY2luZz0iMCINCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBjZWxscGFkZGluZz0iMCIgYm9yZGVyPSIwIj4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8dGJvZHk+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8dHINCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYQ0KTmV1ZSZxdW90OyxIZWx2ZXRpY2EsQXJp YWwsc2Fucy1zZXJpZjtmb250LXNpemU6MTFweDtsaW5lLWhlaWdodDoxNnB4Ij4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHRkIHdpZHRo PSI0MCI+PGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGhyZWY9Imh0dHBzOi8vbWF0dHIuZ2xvYmFsIg0Kc3R5bGU9ImJvcmRlcjpu b25lO2NvbG9yOnJnYig1MSw0OSw1MCk7bWFyZ2luLXJpZ2h0OjEycHgiDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9i bGFuayINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHJlbD0ibm9yZWZlcnJlciINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+PGltZw0K c3JjPSJodHRwczovL21hdHRyLmdsb2JhbC9hc3NldHMvaW1hZ2VzL3dlYnNpdGUucG5nIiBh bHQ9Ik1hdHRyIHdlYnNpdGUiDQpzdHlsZT0iYm9yZGVyOjBweDtoZWlnaHQ6NDBweDt3aWR0 aDoyNHB4IiBtb3otZG8tbm90LXNlbmQ9InRydWUiDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdpZHRoPSIyNCI+PC9hPjwvdGQ+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx0 ZCB3aWR0aD0iNDAiPjxhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBocmVmPSJodHRwczovL3d3dy5saW5rZWRpbi5jb20vY29tcGFu eS9tYXR0cmdsb2JhbCINCnN0eWxlPSJib3JkZXI6bm9uZTtjb2xvcjpyZ2IoNTEsNDksNTAp O21hcmdpbi1yaWdodDoxMnB4Ig0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsiDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZWw9Im5vcmVmZXJyZXIi DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBtb3otZG8tbm90LXNlbmQ9InRydWUiPjxpbWcNCnNyYz0iaHR0cHM6Ly9tYXR0ci5nbG9i YWwvYXNzZXRzL2ltYWdlcy9saW5rZWRpbi5wbmciIGFsdD0iTWF0dHIgb24NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTGlua2Vk SW4iDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHN0eWxlPSJib3JkZXI6MHB4O2hlaWdodDo0MHB4O3dpZHRoOjI0cHgiDQptb3ot ZG8tbm90LXNlbmQ9InRydWUiIHdpZHRoPSIyNCI+PC9hPjwvdGQ+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0iNDAiPjxh DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBocmVmPSJodHRwczovL3R3aXR0ZXIuY29tL21hdHRyZ2xvYmFsIg0Kc3R5bGU9ImJvcmRl cjpub25lO2NvbG9yOnJnYig1MSw0OSw1MCk7bWFyZ2luLXJpZ2h0OjEycHgiDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9 Il9ibGFuayINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHJlbD0ibm9yZWZlcnJlciINCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+PGlt Zw0Kc3JjPSJodHRwczovL21hdHRyLmdsb2JhbC9hc3NldHMvaW1hZ2VzL3R3aXR0ZXIucG5n IiBhbHQ9Ik1hdHRyIG9uDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFR3aXR0ZXIiDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJib3JkZXI6MHB4O2hlaWdo dDo0MHB4O3dpZHRoOjI0cHgiDQptb3otZG8tbm90LXNlbmQ9InRydWUiIHdpZHRoPSIyNCI+ PC9hPjwvdGQ+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDx0ZCB3aWR0aD0iNDAiPjxhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vbWF0 dHJnbG9iYWwiDQpzdHlsZT0iYm9yZGVyOm5vbmU7Y29sb3I6cmdiKDUxLDQ5LDUwKTttYXJn aW4tcmlnaHQ6MTJweCINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVsPSJub3JlZmVycmVyIg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96 LWRvLW5vdC1zZW5kPSJ0cnVlIj48aW1nDQpzcmM9Imh0dHBzOi8vbWF0dHIuZ2xvYmFsL2Fz c2V0cy9pbWFnZXMvZ2l0aHViLnBuZyIgYWx0PSJNYXR0ciBvbg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHaXRodWIiDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0 eWxlPSJib3JkZXI6MHB4O2hlaWdodDo0MHB4O3dpZHRoOjI0cHgiDQptb3otZG8tbm90LXNl bmQ9InRydWUiIHdpZHRoPSIyNCI+PC9hPjwvdGQ+DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RyPg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDwvdGJvZHk+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDwvdGFibGU+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8L3RkPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDwvdGJvZHk+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 L3RhYmxlPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvdGQ+DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8L3Rib2R5Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvdGFi bGU+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtmb250LWZhbWlseTpUaW1l cztmb250LXNpemU6bWVkaXVtIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8c21h bGwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJjb2xvcjpyZ2IoMTE4 LDExOCwxMTgpO2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYQ0KTmV1ZSZxdW90OyxIZWx2 ZXRpY2EsQXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6OHB4O2xpbmUtaGVpZ2h0OjE0cHgi PlRoaXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbW11bmljYXRpb24sIGlu Y2x1ZGluZyBhbnkgYXR0YWNobWVudHMsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBpcyBjb25maWRlbnRpYWwuIElmIHlvdSBhcmUgbm90IHRoZQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3Ugc2hvdWxkIG5vdCByZWFk IGl0DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtIHBsZWFzZSBjb250YWN0IG1l IGltbWVkaWF0ZWx5LCBkZXN0cm95DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBp dCwgYW5kIGRvIG5vdCBjb3B5IG9yIHVzZSBhbnkgcGFydCBvZg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgdGhpcyBjb21tdW5pY2F0aW9uIG9yIGRpc2Nsb3NlIGFueXRoaW5n DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhYm91dCBpdC4gVGhhbmsgeW91LiBQ bGVhc2Ugbm90ZSB0aGF0IHRoaXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNv bW11bmljYXRpb24gZG9lcyBub3QgZGVzaWduYXRlIGFuDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBpbmZvcm1hdGlvbiBzeXN0ZW0gZm9yIHRoZSBwdXJwb3NlcyBvZiB0aGUN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVsZWN0cm9uaWMgVHJhbnNhY3Rpb25z IEFjdCAyMDAyLjwvc21hbGw+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rp dj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAg ICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAg ICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAg ICA8L2Rpdj4NCiAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgIDxicj4NCiAg ICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KICAgICAgICAgICAgICAg IDxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9hdHRyIj5PbiBUaHUsIE1hciAxMSwgMjAy MQ0KICAgICAgICAgICAgICAgICAgYXQgOToyMCBBTSBGYWJpZW4gSW1iYXVsdCAmbHQ7PGEN CiAgICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOmZhYmllbi5pbWJhdWx0QGdtYWls LmNvbSINCiAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsiIHJlbD0ibm9yZWZl cnJlciINCiAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5mYWJp ZW4uaW1iYXVsdEBnbWFpbC5jb208L2E+Jmd0Ow0KICAgICAgICAgICAgICAgICAgd3JvdGU6 PGJyPg0KICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgIDxibG9ja3F1 b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4DQogICAgICAg ICAgICAgICAgICAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkDQogICAgICAgICAg ICAgICAgICByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KICAgICAgICAg ICAgICAgICAgPGRpdiBkaXI9ImF1dG8iPlRoYW5rcyBKdXN0aW4uDQogICAgICAgICAgICAg ICAgICAgIDxkaXYgZGlyPSJhdXRvIj48YnI+DQogICAgICAgICAgICAgICAgICAgIDwvZGl2 Pg0KICAgICAgICAgICAgICAgICAgICA8ZGl2IGRpcj0iYXV0byI+SXQncyBnb29kIHRvIGNs YXJpZnkgd2hhdCB3ZSBtZWFuIGJ5DQogICAgICAgICAgICAgICAgICAgICAgYXNzZXJ0aW9u LiBJIHVzZWQgYSBtb3JlIG11bmRhbmUgbWVhbmluZy7CoDwvZGl2Pg0KICAgICAgICAgICAg ICAgICAgICA8ZGl2IGRpcj0iYXV0byI+PGJyPg0KICAgICAgICAgICAgICAgICAgICA8L2Rp dj4NCiAgICAgICAgICAgICAgICAgICAgPGRpdiBkaXI9ImF1dG8iPkkgZGlzbGlrZSBlbWFp bC9waG9uZSBhcyBzZWN1cml0eQ0KICAgICAgICAgICAgICAgICAgICAgIGRpc2FzdGVycyB3 YWl0aW5nIHRvIGhhcHBlbi4gSSBnZXQgdGhhdCB0aGV5IGFyZQ0KICAgICAgICAgICAgICAg ICAgICAgIHByYWN0aWNhbC7CoDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8ZGl2IGRp cj0iYXV0byI+PGJyPg0KICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAg ICAgICAgICAgPGRpdiBkaXI9ImF1dG8iPkkgdGhpbmsgSSBoYXZlIHdoYXQgSSBuZWVkIHRv IHdyaXRlDQogICAgICAgICAgICAgICAgICAgICAgdGhlIFBScyBiYXNlZCBvbiBzdWJfaWRz IChiYXNlZCBvbiB0aGUgY3VycmVudA0KICAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LTA3 KS7CoDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8ZGl2IGRpcj0iYXV0byI+PGJyPg0K ICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgPGRpdiBk aXI9ImF1dG8iPkZhYmllbsKgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgIDxicj4NCiAg ICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiIGRpcj0iYXV0byI+ DQogICAgICAgICAgICAgICAgICAgICAgPGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsX2F0 dHIiPkxlIG1lci4gMTAgbWFycw0KICAgICAgICAgICAgICAgICAgICAgICAgMjAyMSDDoCAy MDoxOCwgSnVzdGluIFJpY2hlciAmbHQ7PGENCiAgICAgICAgICAgICAgICAgICAgICAgICAg aHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgcmVsPSJub3JlZmVycmVyDQogICAgICAg ICAgICAgICAgICAgICAgICAgIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIg0K ICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1z ZW5kPSJ0cnVlIj5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0Ow0KICAgICAgICAgICAgICAgICAg ICAgICAgYSDDqWNyaXTCoDo8YnI+DQogICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQog ICAgICAgICAgICAgICAgICAgICAgPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBz dHlsZT0ibWFyZ2luOjBweA0KICAgICAgICAgICAgICAgICAgICAgICAgMHB4IDBweCAwLjhl eDtib3JkZXItbGVmdDoxcHggc29saWQNCiAgICAgICAgICAgICAgICAgICAgICAgIHJnYigy MDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQogICAgICAgICAgICAgICAgICAgICAg ICA8ZGl2PkhpIEZhYmllbiwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+ DQogICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAg ICAgICAgICA8ZGl2PkZpcnN0LCB0aGFua3MgZm9yIGRvaW5nIHRoZSBoZWF2eSBsaWZ0IG9m DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgd3JpdGluZyB0aGlzIHRvcGljIHVwLiBP ZiB0aGVzZSBvcHRpb25zLCBJDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgd291bGQg c3Ryb25nbHkgcHJlZmVyIG9wdGlvbiAoMSkuIFRoZQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGRpZmZlcmVuY2UgYmV0d2VlbiBhc3NlcnRpb25zIGFuZA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGlkZW50aWZpZXJzIGlzIHRoYXQgYW4gYXNzZXJ0aW9uIGlzIGEg ZnVsbHkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBwYWNrYWdlZCBzZXQgb2YgYXR0 cmlidXRlcywgb25lIG9mIHdoaWNoIGNhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg IGJlIGFuIGlkZW50aWZpZXIuIFRoZXkgYXJlLCBnZW5lcmFsbHkNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICBzcGVha2luZywgY3J5cHRvZ3JhcGhpY2FsbHkgcHJvdGVjdGVkDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgYnVuZGxlcy4gVGhleeKAmXJlIGRlc2lnbmVk IHRvIGNhcnJ5IGEgYnVuY2gNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBvZiBkaWZm ZXJlbnQgaW5mb3JtYXRpb24gYWJvdXQgYSB1c2VyIGFuZA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHRoZSBhdXRoZW50aWNhdGlvbiBldmVudCBpbiBhIGZvcm0gdGhhdOKAmXMN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbmRlcGVuZGVudGx5IHZlcmlmaWFibGUg YW5kIGF1ZGl0YWJsZS4gU0FNTA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFzc2Vy dGlvbnMgKFhNTCBkb2N1bWVudCkgYW5kIElEIFRva2Vucw0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgIChzaWduZWQgSldUcykgYXJlIHRoZSBtb3N0IGNvbW1vbiBvbmVzIHdlDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgc2VlIHRvZGF5LCBidXQgb3RoZXIgZm9ybWF0 cyBleGlzdCBhbmQgd2lsbA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGtlZXAgYmVp bmcgaW52ZW50ZWQuwqA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj48 YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAg ICAgICAgICAgICA8ZGl2PkFuIGlkZW50aWZpZXIgaXMgYSBkaWZmZXJlbnQga2luZCBvZg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNyZWF0dXJlLiBJdCBpcyBhIHNpbmdsZSBz dGF0ZW1lbnQgdGhhdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlkZW50aWZpZXMg dGhlIHBhcnR5IGluIHF1ZXN0aW9uIGluIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGNvbnRleHQgb2YgdGhlIHBhcnR5IGRvaW5nIHRoZQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGlkZW50aWZpY2F0aW9uLiBJdOKAmXMgdGhpcyBmdWxsIGNvbnRleHQgdGhh dA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSByZWNlaXZlciBvZiB0aGUgaWRl bnRpZmllciBuZWVkcyB0bw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludGVycHJl dCBpdCBpbi4gV2hlbiB1c2luZyBhIGZlZGVyYXRlZA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGlkZW50aXR5IHByb3RvY29sLCBlYWNoIFJQIGlzIGdvaW5nIHRvIGhhdmUNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICA6c29tZToga2luZCBvZiBsb2NhbCB1c2VyIGlu Zm9ybWF0aW9uIHN0b3JlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhhdCB0aGV5 4oCZcmUgZ29pbmcgdG8gdGllIGludG8sIHNvbWUgZmllbGQNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICBpbiBhIGRhdGFiYXNlIHRoZXnigJlsbCBrZXkgb2ZmIG9mLiBJdOKAmXMg anVzdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5ldmVyIGdvaW5nIHRvIGJlIHRo ZSBjYXNlIHRoYXQgYWxsIFJQcyB3aWxsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg YmUgYWJsZSB0byB1c2Ugc2VydmVyLXByb3ZpZGVkIG9wYXF1ZQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGlkZW50aWZpZXJzIGZvciBhbGwgY2FzZXMuIEFjY291bnQgcmVjb3Zl cnkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBhbmQgYmluZGluZyBpcyBvbmUgc3Vj aCB1c2UgY2FzZSB3aGVyZSBhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgdXNlci1m YWNpbmcgaWRlbnRpZmllciBsaWtlIGFuIGVtYWlsIGFkZHJlc3MNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICBtYWtlcyBhIExPVCBvZiBzZW5zZSwgZm9yIG9uZSBzbWFsbCBleGFt cGxlLg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoaXMgaXMgYW4gYXJyYXkgaW4g dGhlIHJlcXVlc3QgYW5kIHJlc3BvbnNlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg cHJlY2lzZWx5IGJlY2F1c2UgYSB1c2VyIGNvdWxkIGJlIGtub3duIGJ5DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgc2V2ZXJhbCBkaWZmZXJlbnQgaWRlbnRpZmllcnMgdG8gYSBw YXJ0eSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBhbmQgYW4gUlAgd2lsbCBoYXZl IGEgYmV0dGVyIGlkZWEgYWJvdXQgd2hhdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg IGtpbmRzIG9mIHRoaW5ncyBpdCB3YW50cyB0byBjb3JyZWxhdGUNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICBhZ2FpbnN0LCBhbmQgaXTigJlzIHVwIHRvIHRoZSBBUyB0byBwcm92 aWRlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhhdCBtYXBwaW5nLiBJIHRoaW5r IHRoYXQgaWYgd2UgZG9u4oCZdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRlZmlu ZSBhIHdheSB0byBkZXNjcmliZSB0aGUgZm9ybWF0LCB0aGUNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICDigJxhc19pZOKAnSBmaWVsZCBpcyBnb2luZyB0byBnZXQgc3RydWN0dXJl DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgYmFjay1wYXRjaGVkIG9udG8gaXQgbGlr ZSBpcyBiZWluZyBwcm9wb3NlZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhlcmU6 PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAg ICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPGRp dj48YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0iaHR0cHM6Ly9tYXR0 cmdsb2JhbC5naXRodWIuaW8vb2lkYy1wb3J0YWJsZS1pZGVudGl0aWVzLyINCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHJlbD0ibm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVm ZXJyZXINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5vcmVmZXJyZXIgbm9yZWZl cnJlciIgdGFyZ2V0PSJfYmxhbmsiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBt b3otZG8tbm90LXNlbmQ9InRydWUiPmh0dHBzOi8vbWF0dHJnbG9iYWwuZ2l0aHViLmlvL29p ZGMtcG9ydGFibGUtaWRlbnRpdGllcy88L2E+PC9kaXY+DQogICAgICAgICAgICAgICAgICAg ICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj5J4oCZbSBwZXJzb25hbGx5IG5vdCBhIGZh biBvZiB0aGF0IGFwcHJvYWNoDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgYXMgaXQg bWl4ZXMgdGhlIGRhdGEgbGF5ZXJpbmcgdG9vIG11Y2gsIGFuZA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHlvdSBlbmQgdXAgbWFraW5nIGd1ZXNzZXMgYWJvdXQgd2hldGhlciBh DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgZmllbGQgaXMgbWVhbmluZ2Z1bCBvciBh IHBvaW50ZXIuIEkgdGhpbmsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBHTkFQIHdp bGwgYmUgbXVjaCBiZXR0ZXIgc2VydmVkIGJ5IHVzaW5nIGENCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICBkYXRhIHN0cnVjdHVyZSBmb3IgdGhpcyBmcm9tIHRoZSBzdGFydC4gRElE cw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNob3VsZCBiZSBhbm90aGVyIOKAnGZv cm1hdOKAnSBvZiB0aGUgc3ViamVjdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlk ZW50aWZpZXIuIEkgZG9u4oCZdCB0aGluayBHTkFQIHNob3VsZCBkZWZpbmUNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICB0aGlzIGZvcm1hdCwgYW5kIEnigJl2ZSBkcm9wcGVkIGEg bm90ZSB0byB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBTRUNFVkVOVCBtYWls aW5nIGxpc3QgYXNraW5nIGFib3V0IGFkZGluZw0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgIERJRHMgdG8gdGhlIHN1YmplY3QgaWRlbnRpZmllcnMgZHJhZnQgYmVmb3JlDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgaXQgZ2V0cyBwdWJsaXNoZWQuIERJRHMgYXJlIG5v dCBhc3NlcnRpb25zLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGV2ZW4gaW4gdGhl IGNhc2VzIHdoZXJlIHRoZXkgcG9pbnQgdG8gZnVsbHkNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICBmdW5jdGlvbmFsIERJRCBkb2N1bWVudHMgd2l0aCB1c2VyDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgaW5mb3JtYXRpb24gaW4gdGhlbS4gKEFuZCBmb3Igd2hhdCBp dOKAmXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB3b3J0aCwgSSB0aGluayB0aGUg T0lEQyB3b3JsZCBzaG91bGQgYWxzbw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVz ZSB0aGUgU0VDRVZFTlQgZHJhZnQgaW5zaWRlIElEIFRva2VucyB0bw0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHNvbHZlIHRoZSB1c2UgY2FzZSBvZiB0aGUgZHJhZnQgYWJvdmUp LjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDxk aXY+Rm9yIHRoZSB1c2VyICE9IFJPIGNhc2VzLCBJIHRoaW5rIHRoYXQNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICBwb3RlbnRpYWxseSBoYXZpbmcgYSB3YXkgdG8gc2lnbmFsIHRo b3NlIHR3bw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGl0ZW1zIHNlcGFyYXRlbHkg aW4gdGhlIHJlcXVlc3QgYW5kIHJlc3BvbnNlDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgY291bGQgYmUgdXNlZnVsLiBSaWdodCBub3cgYWxsIHRoZQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHVzZXIvc3ViamVjdCBzdHVmZiBpcyBhYm91dCBpZGVudGlmeWluZyDi gJx0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB1c2VyIHRoYXTigJlzIGN1cnJl bnRseSBoZXJlIGF0IHRoZSBjbGllbnQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBp bnN0YW5jZeKAnSwgaW4gYSB2YXJpZXR5IG9mIGZvcm1zIHRoYXQgdGhlDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgY2xpZW50IGluc3RhbmNlIGFuZCBBUyBjYW4gbmVnb3RpYXRl LiBJZiB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBjbGllbnQgb3IgQVMgaGFz IHNvbWUgb3RoZXIgbm90aW9uIGFib3V0IHdobw0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHRoZSBSTyBpcyBhbmQgaG93IHRoYXQgY291bGQgYmUgc2VwYXJhdGUNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICBmcm9tIHRoZSBjdXJyZW50IHVzZXIsIHdlIGNvdWxkIHBy b3ZpZGUgYQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdheSB0byBzaWduYWwgdGhh dCBsaWtlIHlvdeKAmXJlIHByb3Bvc2luZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg IGJlbG93LiBJbiBteSBtZW50YWwgbW9kZWwsIHRoZXJlIGFyZSBnb2luZw0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHRvIGJlIGEgbG90IG9mIHVzZSBjYXNlcyB3aGVyZSB0aGUg 4oCcUk/igJ0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBpc27igJl0IGtub3duIHRv IHRoZSBjbGllbnQgYXQgYWxsLCBidXQgcmF0aGVyDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgdG8gdGhlIEFTIGFuZCBpcyBiYXNlZCBvbiB3aGF0IHRoZSBjbGllbnTigJlzDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgYXNraW5nIGZvci4gU28gSSBjb3VsZCBpZGVu dGlmeSB0aGUgY3VycmVudA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVzZXIgYW5k IGFzayBmb3IgYSBzcGVjaWZpYyBtZWRpY2FsIHJlY29yZCwNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICBhbmQgdGhlIEFTIHJlYWxpemVzIGl0IGhhcyB0byBnbyBidWcgYQ0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHBhcnRpY3VsYXIgZG9jdG9yIHRvIGFwcHJvdmUg dGhpbmdzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgZGlyZWN0bHkuIFRoaXMgaXMg aW5zdGVhZCBvZiBpbnRlcmFjdGluZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdp dGggdGhlIGN1cnJlbnQgdXNlciBhbmQgZmFpbGluZyBpbiBhbg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGF3a3dhcmQgd2F5IHdoZW4gdGhlIGN1cnJlbnQgdXNlciBkb2VzbuKA mXQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBoYXZlIHRoZSByaWdodHMgdG8gZG8g dGhpbmdzLCBidXQgc29tZW9uZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVsc2Ug d291bGQuIEJ1dCB3ZeKAmWQgd2FudCB0aGUgc3lzdGVtIHRvIGJlDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgYWJsZSB0byBkZXRlY3QgaWYgdGhlIGN1cnJlbnQgdXNlciBpcyB0 aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBkb2N0b3IsIHNvIHdlIGNhbiBqdXN0 IGludGVyYWN0IHdpdGggdGhlbQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRpcmVj dGx5LiBEb2VzIHRoYXQgYWxsIHRyYWNrPzwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAg ICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAg ICAgICAgICAgICAgICAgICAgICAgIDxkaXY+wqDigJQgSnVzdGluPC9kaXY+DQogICAgICAg ICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg PGRpdj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj5PbiBN YXIgMTAsIDIwMjEsIGF0IDQ6MTAgQU0sIEZhYmllbg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEltYmF1bHQgJmx0OzxhDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBocmVmPSJtYWlsdG86ZmFiaWVuLmltYmF1bHRAZ21haWwuY29tIg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVsPSJub3JlZmVycmVyIG5vcmVm ZXJyZXINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5vcmVmZXJyZXIg bm9yZWZlcnJlciBub3JlZmVycmVyIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgdGFyZ2V0PSJfYmxhbmsiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPmZhYmllbi5pbWJhdWx0QGdtYWlsLmNvbTwv YT4mZ3Q7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd3JvdGU6PC9kaXY+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8ZGl2IGRpcj0ibHRyIj5IZWxsbywNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pk5v dGljZSB0aGUgcXVlc3Rpb24gbWFyayBpbiB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgdGl0bGUuIE5vdCB0byBiZSBjb25zaWRlcmVkIGFzIGFuDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVkaXRvcidzIGNvbW1lbnQuPC9k aXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PlRoaXMgdGhy ZWFkIGludGVuZHMgdG8gcHJvdmlkZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBhIGRldGFpbGVkIGNvbW1lbnQgb24gdGhlDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGludGVyZXN0aW5nwqBmZWVkYmFjayBieSBLcmlzdGluYToN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIkkgd291bGQgY2F0Y2gg dXAgb24gdGhlIHRocmVhZCB0bw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB1bmRlcnN0YW5kIHdoeSBESURzIGFyZSB0aG91Z2h0IHRvDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGJlIHRyZWF0ZWQgYXMgYXNzZXJ0aW9ucyIuPC9k aXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PkluIHRoZSBj aGF0LCBJIGFuc3dlcmVkOiAiSGFwcHkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgdG8gZ2V0IHRoZSBkaXNjdXNzaW9uIG9uIERJRHMuDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEFjdHVhbGx5LCBjb3VsZCBiZSBlaXRoZXIgb3Is DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRlcGVuZGluZyBvbiB3 aGF0IHdlIGludGVuZCB0bw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBkby4iIExldCBtZSBleHBhbmQgYSBiaXQgb24gdGhhdCwNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgdG8gbWFrZSBpdCB1bmRlcnN0YW5kYWJsZSAoZGlkbid0 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhhdmUgdGhlIHRpbWUg ZHVyaW5nIHRoZSBtZWV0aW5nLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB1bmZvcnR1bmF0ZWx5KS48L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PlRo aXMgcmVsYXRlcyB0byB0aGUgaXRlbXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgZGVzY3JpYmVkIG9uIHNsaWRlcyAyMCBhbmQgMzQsDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHdoaWNoIEknbGwgZXhwbGFpbiBmdXJ0aGVyLiBJ J2xsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhpZ2hsaWdodCBh cyB0cmFuc3BhcmVudGx5IGFzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHBvc3NpYmxlIHdoYXQgSSB0aGluayB3b3VsZCBiZSB0aGUNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgYmVuZWZpdHMgYW5kIGRvd25zaWRlcyBvZiBlYWNo Lg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCb3RoIGFyZSBwcm9i YWJseSB2aWFibGUgb3B0aW9ucywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgYnV0IHRoZXkgY29ycmVzcG9uZCB0byBkaWZmZXJlbnQNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgc2NvcGVzIGFuZCBvYmplY3RpdmVzLiBJJ2xsIHNw ZW5kDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGEgYml0IG1vcmUg dGltZSBvbiBvcHRpb24gMiwgc2luY2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgaXQgaXMgYSBkaWZmZXJlbnQgYXBwcm9hY2gNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgY29tcGFyZWQgdG8gdGhlIGN1cnJlbnQgZHJhZnQuPC9k aXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PjxzcGFuDQpz dHlsZT0iY29sb3I6cmdiKDM2LDQxLDQ2KTtmb250LWZhbWlseTotYXBwbGUtc3lzdGVtLEJs aW5rTWFjU3lzdGVtRm9udCwmcXVvdDtTZWdvZQ0KVUkmcXVvdDssSGVsdmV0aWNhLEFyaWFs LHNhbnMtc2VyaWYsJnF1b3Q7QXBwbGUgQ29sb3INCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBFbW9qaSZxdW90OywmcXVvdDtTZWdvZSBVSQ0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVtb2ppJnF1b3Q7O2ZvbnQtc2l6ZTox NHB4Ij48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvc3Bh bj48L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+PGI+ MS4gVGhlIGZpcnN0IHBvc3NpYmlsaXR5IGlzDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgdG8gdXNlIFNFQ0VWRU5UIHRocm91Z2hvdXQuwqA8L2I+PC9kaXY+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PkluIHRoYXQgY2Fz ZSwgRElEcyBzaG91bGQgYmUgYQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBwYXJ0IG9mIHN1Yl9pZHMgKGluIHRoZSBjb3JlIG9yIGluDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBleHRlbnNpb24gcmVnaXN0cnksIGRlcGVu ZGluZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvbiB3aGF0IEFu bmFiZWxsZSdzIFdHIGRlY2lkZXMpLg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBNb3JlIGdlbmVyYWxseSwgdGhlIFdHIHdvdWxkIGhhdmUNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgdG8gZGVjaWRlIHdoaWNoIGFkZGl0aW9uYWwg c3ViX2lkcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpdCBuZWVk cyAoYXMgcGVyIFlhcm9uJ3MgY29tbWVudCkuPC9kaXY+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PGRpdj5UaGF0J3Mgb2J2aW91c2x5IHRoZSBjbG9zZXN0IHRvDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHdoYXQgaXMgZGVzY3JpYmVkIGluIGRyYWZ0LTA0LiBJ dA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhbGxvd3MgYSBjb21t dW5pY2F0aW9uIG9mIHN1YmplY3QNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgaW5mb3JtYXRpb24gYmV0d2VlbiB0aGUgY2xpZW50IGFuZA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgQVMsIGJ5IHVzaW5nIGdsb2JhbA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpZGVudGlmaWVycyAobWFpbCwg cGhvbmUsIGV0Yy4pLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBv ciB1c2luZyBhIGxvY2FsIG9wYXF1ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICByZWZlcmVuY2XCoC0gaS5lLiBnb3Zlcm5lZCBieSB0aGUNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgQVMgKHRoYXQncyBwcm9iYWJseSB3aGF0IHdl DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdvdWxkwqBwdXQgaW4g dGhlIGV4YW1wbGVzLCB1bmxlc3MNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgc29tZW9uZSBoYXMgYSBiZXR0ZXIgaWRlYSAtIGNmDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGlzc3VlcyAjMTYgYW5kICM0MikuwqA8L2Rpdj4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8ZGl2PkFzc2VydGlvbnMgcmVsYXRlIGZvciBpbnN0YW5jZQ0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0byB0aGUgcHJvb2Ygb2Yg cHJlc2VuY2Ugb2YgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFJPLiBUaGUgY3VycmVudCBkcmFmdC0wNCB0aGVyZWZvcmUNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgcGxhbnMgZm9yIGlkX3Rva2VucyBhbmQgc2FtbDIsDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1heWJlIHRoZXJlIGNvdWxk IGJlIG90aGVyIG5lZWRzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGxhdGVyIChleHRlbnNpb24gcmVnaXN0cnkpLjwvZGl2Pg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDxkaXY+LSBCZW5lZml0czogaWRlbnRpZmllcnMgYXJlIGENCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAga2V5IGNvbXBvbmVudCBvZiBHTkFQLCB3aGljaCBtYWtl cw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnRlZ3JhdGlvbiBl YXNpZXIuIFBvc3NpYmx5IG9uZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBjb3VsZCBjaG9vc2UgdG8gdXNlIERJRHMNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgdGhyb3VnaG91dC48L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDxkaXY+LSBEb3duc2lkZXM6IGVtYWlsL3Bob25lDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlkZW50aWZpZXJzIHdpbGwgcHJvYmFi bHkgYmUgdXNlZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aHJv dWdob3V0IGJ5IG1vc3QgZGV2cyAoc2luY2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgdGhhdCdzIGNvcnJlbGF0aW9uIGluZm9ybWF0aW9uDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZXnCoGhhdmUgaW4gdGhlaXIgdXNlciBE QikuIFdoaWNoDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1lYW5z IHdlIHNob3VsZCBsaW1pdCB3aGF0DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGFzc2VydGlvbnMgY29udGFpbiwgdG8gYXZvaWQgZG9pbmcNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgbGlua3MgYmV0d2VlbiB3ZWFrIGdsb2JhbA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpZGVudGlmaWVycyBhbmQg aG9wZWZ1bGx5IHN0cm9uZ2VyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGFzc2VydGlvbnMuIFRoYXQncyBub3QgcmVhbGx5IGENCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgcHJvYmxlbSBpZiBpdCdzIGxpbWl0ZWQgdG8NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYXV0aGVudGljYXRpb24gZXZlbnRz IG1vc3RseSAoaW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhh dCBwZXJzcGVjdGl2ZSwgc2FtbHYyIGNvdWxkDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIG1ha2Ugc2Vuc2UgaW4gdGhlIGNvcmUpLiBBbg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBhc3NlcnRpb24gaXMgcHJvYmFibHkgYSBzaW5n bGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdmFsdWUgdGhlbiAo bm90IGFuIGFycmF5KS7CoCDCoDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+T3B0aW9uIDEgY2Fu IGJlIHN1bW1hcml6ZWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBhczrCoDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+PHNwYW4NCmlk PSJtXzQxNTUyNzQ3MzcxMjg0OTEzNDdnbWFpbC1tXy03MzU2OTY0MTc2MTYxNzMxMDkzbV8t NDY5NTk2MDQzNzE3MjYxODE3Mm1fLTg2MTUxOTA5MjA0NDQ2MDQ2NjVtXzQ4MDgyMDg0Njcz MzQ2NTE4MjNtXzU1NjQ2MjY1ODcxMjExMjM0ODBnbWFpbC1kb2NzLWludGVybmFsLWd1aWQt Y2Q4MzUwMTItN2ZmZi1mOTJiLTQ0NDQtNzUxNTQwYTJjMmY3Ij4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImxpbmUtaGVpZ2h0OjEuMjttYXJnaW4t dG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOnJnYig1MSw1MSw1MSk7YmFja2dyb3VuZC1j b2xvcjpyZ2IoMjQ3LDI0NywyNDcpO2ZvbnQtdmFyaWFudC1udW1lcmljOm5vcm1hbDtmb250 LXZhcmlhbnQtZWFzdC1hc2lhbjpub3JtYWw7dmVydGljYWwtYWxpZ246YmFzZWxpbmU7d2hp dGUtc3BhY2U6cHJlLXdyYXAiPjxmb250IHNpemU9IjEiPiJzdWJqZWN0IjogezwvZm9udD48 L3NwYW4+PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8ZGl2DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0 eWxlPSJsaW5lLWhlaWdodDoxLjI7bWFyZ2luLXRvcDowcHQ7bWFyZ2luLWJvdHRvbTowcHQi Pjxmb250DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg c2l6ZT0iMSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOnJnYig1MSw1MSw1MSk7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjQ3LDI0Nywy NDcpO2ZvbnQtdmFyaWFudC1udW1lcmljOm5vcm1hbDtmb250LXZhcmlhbnQtZWFzdC1hc2lh bjpub3JtYWw7dmVydGljYWwtYWxpZ246YmFzZWxpbmU7d2hpdGUtc3BhY2U6cHJlLXdyYXAi PsKgwqDCoCJzdWJfaWRzIjogeyB9LDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cmdiKDUxLDUxLDUxKTtiYWNrZ3JvdW5k LWNvbG9yOnJnYigyNDcsMjQ3LDI0Nyk7Zm9udC12YXJpYW50LW51bWVyaWM6bm9ybWFsO2Zv bnQtdmFyaWFudC1lYXN0LWFzaWFuOm5vcm1hbDt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt3 aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFw Ij4JPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6cmdiKDUxLDUxLDUxKTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigy NDcsMjQ3LDI0Nyk7Zm9udC12YXJpYW50LW51bWVyaWM6bm9ybWFsO2ZvbnQtdmFyaWFudC1l YXN0LWFzaWFuOm5vcm1hbDt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt3aGl0ZS1zcGFjZTpw cmUtd3JhcCI+PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj4JPC9zcGFuPjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6cmdiKDUxLDUxLDUxKTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNDcsMjQ3LDI0Nyk7 Zm9udC12YXJpYW50LW51bWVyaWM6bm9ybWFsO2ZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOm5v cm1hbDt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNw YW4gc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj4JPC9zcGFuPjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cmdiKDUx LDUxLDUxKTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNDcsMjQ3LDI0Nyk7Zm9udC12YXJpYW50 LW51bWVyaWM6bm9ybWFsO2ZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOm5vcm1hbDt2ZXJ0aWNh bC1hbGlnbjpiYXNlbGluZTt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+Ly8gcmVxdWVzdCBhbmQg cmVzcG9uc2UgKFNFQ0VWRU5UIC0mZ3Q7IGluY2x1ZGluZyBESUQgcG9zc2libHkpPC9zcGFu PjwvZm9udD48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjpyZ2IoMjQ3LDI0NywyNDcp O2NvbG9yOnJnYig1MSw1MSw1MSk7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Zm9udC1zaXplOngtc21hbGw7d2hpdGUtc3BhY2U6cHJlLXdyYXA7dGV4dC1pbmRlbnQ6 MzZwdCI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8L3NwYW4+PC9k aXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJsaW5l LWhlaWdodDoxLjI7bWFyZ2luLXRvcDowcHQ7bWFyZ2luLWJvdHRvbTowcHQiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpyZ2IoNTEs NTEsNTEpO2JhY2tncm91bmQtY29sb3I6cmdiKDI0NywyNDcsMjQ3KTtmb250LXZhcmlhbnQt bnVtZXJpYzpub3JtYWw7Zm9udC12YXJpYW50LWVhc3QtYXNpYW46bm9ybWFsO3ZlcnRpY2Fs LWFsaWduOmJhc2VsaW5lO3doaXRlLXNwYWNlOnByZS13cmFwIj48Zm9udCBzaXplPSIxIj7C oMKgwqAiYXNzZXJ0aW9ucyI6IFsgXSwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgICAgIC8vIHJl cXVlc3QgYW5kIHJlc3BvbnNlIChpZF90b2tlbiBvciBzYW1sdjIpPC9mb250Pjwvc3Bhbj48 L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9Imxp bmUtaGVpZ2h0OjEuMjttYXJnaW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOnJnYig1 MSw1MSw1MSk7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjQ3LDI0NywyNDcpO2ZvbnQtdmFyaWFu dC1udW1lcmljOm5vcm1hbDtmb250LXZhcmlhbnQtZWFzdC1hc2lhbjpub3JtYWw7dmVydGlj YWwtYWxpZ246YmFzZWxpbmU7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxmb250IHNpemU9IjEi Pn08L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPGRpdg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBzdHlsZT0ibGluZS1oZWlnaHQ6MS4yO21hcmdpbi10b3A6MHB0O21hcmdpbi1i b3R0b206MHB0Ij4oImhpbnRzIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBkbyBub3QgZXhpc3QgY3VycmVudGx5LCBidXQNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYXJlIHBhcnRpYWxseSBjb3ZlcmVkDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNlcGFyYXRlbHkg dmlhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICJyZXF1 ZXN0LnVzZXIiIC8gdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHJlbGV2YW5jZSBvZiAicHJpbmNpcGFsIiwNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgZGlzY3Vzc2VkIGluIHRoZSBzbGlkZSwgaXMgYQ0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBxdWVzdGlvbiBt YXJrIHRvbyAtIHdoaWNoIGlzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGEgZGlmZmVyZW50IGRpc2N1c3Npb24gb24NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgZW5kLXVzZXIgIT0gUk8pLjwvZGl2Pg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0ibGluZS1oZWlnaHQ6 MS4yO21hcmdpbi10b3A6MHB0O21hcmdpbi1ib3R0b206MHB0Ij48YnI+DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8L3NwYW4+PC9kaXY+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2 PjxiPjIuIEFuIGFsdGVybmF0ZSBwb3NzaWJpbGl0eQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGlzIHRvIHVzZSBTRUNFVkVOVCBvbmx5IGFzDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW5wdXQvaGludDwvYj48L2Rpdj4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+SW4gdGhhdCBjYXNl LCBESURzIHNob3VsZCBiZSBhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHBhcnQgb2YgYXNzZXJ0aW9ucyAod2hpY2ggaGF2ZSBhDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGRpZmZlcmVudCBtZWFuaW5nIGNvbXBhcmVkIHRvDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG9wdGlvbiAxKS48L2Rpdj4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8ZGl2PlRoZSBBUyBvbmx5IHJldHVybnMgYW4gbG9jYWwN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb3BhcXVlIHJlZmVyZW5j ZSBhc19yZWYgKHdoaWxlIGluDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIG9wdGlvbiAxLCBpdCB3YXMgb25seSBvbmUgb2YgbWFueQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBwb3NzaWJpbGl0aWVzKS4gSXRzIG9ubHkgam9iIGlz IHRvDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhlbHAgdGhlIGNs aWVudCBkaWZmZXJlbnRpYXRlIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICByZXNwb25zZSBzdWJqZWN0LiBUaGUgQVMgcG9saWN5DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIG1pZ2h0IGZ1cnRoZXIgZGVmaW5lIHRoZSBzY29w ZSBvZg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGF0IHJlZmVy ZW5jZSwgYXMgc3VnZ2VzdGVkIGluwqA8YQ0KaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2ll dGYtd2ctZ25hcC9nbmFwLWNvcmUtcHJvdG9jb2wvaXNzdWVzLzIxMCINCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZWw9Im5vcmVmZXJyZXIgbm9yZWZlcnJl cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5vcmVmZXJyZXIg bm9yZWZlcnJlcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5v cmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+aHR0cHM6Ly9naXRodWIuY29t L2lldGYtd2ctZ25hcC9nbmFwLWNvcmUtcHJvdG9jb2wvaXNzdWVzLzIxMDwvYT4sDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFsdGhvdWdoIEkgcGVyc29uYWxs ecKgdmlld2VkIHRoYXQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg YnkgZGVmYXVsdCBhc8KgKDIpICJhc19pZCIgYW4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgaWRlbnRpZmllciBsb2NhbGx5IHVuaXF1ZSB0byB0aGF0DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFTIGZvciBhbGwgdGhlIFJTcy48 L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+PGJyPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PlNFQ0VWRU5UUyBhcmUgc3RpbGwgdXNl ZnVsIGFzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFuIGlucHV0 LCB0aGF0J3Mgd2hhdCBJIHByZXNlbnRlZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBpbiByZXF1ZXN0LmhpbnRzLnNlbGYuc3ViX2lkcyAoYnV0DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGl0J3MgdGhlIHJlc3BvbnNpYmlsaXR5 wqBvZiB0aGUgQVMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdG8g bWF0Y2ggaXQgd2l0aCBpdHMgb3duIHJlZmVyZW5jZQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBzeXN0ZW0gLSBmcm9tIGluc3RhbmNlIGZyb20gdGhlDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsIHRvIEFTJ3MgbG9jYWwg cmVjb3JkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFhVVDJNRk0x WEJJS0pLU0RVOFEpLsKgTm90ZTogc2luY2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgdGhlIHNsaWRlcywgYSBuZXcNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1zZWNldmVudC1zdWJqZWN0LWlkZW50aWZpZXJz LTA3DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhhcyBiZWVuIHB1 Ymxpc2hlZC4gTm90YWJseSB0aGlzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGluY2x1ZGVzIGFuIG9wYXF1ZSBpZGVudGlmaWVyLA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB3aGljaCB0aGUgY2xpZW50IGNhbiB1c2UgdG8gcGFz cw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgYXNfcmVmIGhp bnQgdG8gdGhlIEFTLiBUaHVzIHdlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHdvdWxkbid0IG5lZWQgYW55IGZ1cnRoZXIgYWRkaXRpb24NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgdG8gU0VDRVZFTlQswqBhbHRob3VnaCBoaW50 cyB3b3VsZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBiZW5lZml0 IGZyb20gZnVydGhlciBhZGRpdGlvbnMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKGxpa2UgRElEcyBmb3IgaW5zdGFuY2UpLiBOb3RpY2UNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgYWxzbyB0aGF0IHN1YmplY3RfdHlwZXNfc3Vw cG9ydGVkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJlY29tZXMg bGVzcyBpbXBvcnRhbnQsIGJlY2F1c2UgaW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgdGhlIHdvcnN0IGNhc2Ugc2NlbmFyaW8sIGl0J3MNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgc2ltcGx5wqBhIGhpbnQgdGhhdCB3b3VsZG4n dCBiZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1bmRlcnN0b29k IGFuZCB0aGVyZWZvcmUgdGFrZW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgaW50byBhY2NvdW50IGJ5IHRoZSBBUy48L2Rpdj4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8ZGl2PlRoZSBhc3NlcnRpb25zIGFycmF5IGhhcyBhIG1vcmUNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgaW1wb3J0YW50IHJvbGUgdGhhbiBpbiBvcHRpb24g MQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAod2l0aCB0aGUgZXhw bGljaXQgYWltIG9mDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNl cGFyYXRpbmcgYmV0d2VlbiBjbGllbnQgaGludHMNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgYW5kIHZhbGlkYXRlZCBpbmZvIGFzc2VydGVkIGJ5IHRoZQ0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBUykuIEl0IHNlcnZlcyBhcyBh DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGdlbmVyaWMvZXh0ZW5k aWJsZSBtYXBwaW5nDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0 cnVjdHVyZSwgZS5nLiAidGhlIEFTIGFzc2VydHMNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgdGhhdCBvcGFxdWUgcmVmZXJlbmNlwqA8c3BhbiBzdHlsZT0iYmFj a2dyb3VuZC1jb2xvcjpyZ2IoMjQzLDI0MywyNDMpO2NvbG9yOnJnYigzNiw0MSw0Nik7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Zm9udC1zaXplOjlwdDt3aGl0ZS1z cGFjZTpwcmUtd3JhcCI+WFVUMk1GTTFYQklLSktTRFU4UTwvc3Bhbj7CoGlzDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1hdGNoaW5nIHdpdGggdGhlc2UgKG1v cmUgb3IgbGVzcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2ZXJp ZmlhYmxlKSBzdGF0ZW1lbnRzLiIgVGhlIG5hbWUNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgYXNzZXJ0aW9uIHRoZXJlZm9yZSBjb3JyZXNwb25kcyB0bw0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgcmVzcG9uc2liaWxpdHnC oG9mIHRoZSBBUyBpbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBk ZWxpdmVyaW5nIHRob3NlIHN0YXRlbWVudHMgKGNmDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHNob3VsZC9tdXN0LCBpc3N1ZSAjNDkpLiBTb21lIG9mDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZXNlIHN0YXRlbWVudHMgcmVs YXRlIHRvDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlkZW50aXR5 IG9yIGF1dGggZXZlbnRzIChleDogRElELA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBpZF90b2tlbiksIHNvbWUgbWlnaHQgZGlyZWN0bHkgYmUNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdXNlZnVsIGZvciBhdXRob3JpemF0aW9u IGRlY2lzaW9ucw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAobGlr ZSBaS1AgZXhhbXBsZSBpbiB0aGUgcGFyZW50YWwNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgY29udHJvbCBleGFtcGxlKS4gUG9zc2libHkgc29tZSBvZg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGVzZSB2YWxpZGF0ZWQgYXNz ZXJ0aW9ucyBjb3VsZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBi ZSByZXVzZWQgaW4gbmV4dCBpbnRlcmFjdGlvbnMuPC9kaXY+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPGRpdj5Bbm90aGVyIHF1ZXN0aW9uIHRoYXQgcG9wcGVkLXVwDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGlzIHRoZSBzY29wZSBvZiBzdWJfaWRzLiBTaG91 bGQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhleSBiZSBhYm91 dCB0aGUgc2FtZSB1c2VyPyAoSQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB0aGluayBzbykuIEluIHRoZSBjYXNlIG9mIHJlbW90ZQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBST3MgZXNwZWNpYWxseSwgaXQgbWlnaHQgYmUNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW1wb3J0YW50IHRoYXQgRElE IGJlIGNvbnNpZGVyZWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg YXMgYW4gYXNzZXJ0aW9uwqAoYWJvdXQgc29tZW9uZQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBlbHNlJ3MpIGFuZCBub3QgYXMgc3ViX2lkcywNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYmVjYXVzZSB0aGUgQVMgbmVlZHMgdG8g YmUgY2FyZWZ1bA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhYm91 dCB3aG8gdGhlIGNsaWVudCB3YW50cyB0bw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICByZWFjaCAoYXZvaWQgc3BhbSwgZXRjLikuIFRoaXMgaXMNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc2lzdGVudCB3aXRoIHRoZSByZXN0 IG9mDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRpc2N1c3Npb24g b24gd2hhdCB0byBkbyB3aGVuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGVuZC11c2VyICE9IFJPLCBhbHRob3VnaCB1c2luZw0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBESURDb21tIG1pZ2h0IHNlZW0gYSBiaXQgZWFybHkNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKHRoZSBwYWludCBpcyB2ZXJ5 IGZyZXNoKS7CoDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PGRpdj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+T3B0aW9uIDIgd2Fz IHN1bW1hcml6ZWQgYXM6wqA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PjxzcGFu DQppZD0ibV80MTU1Mjc0NzM3MTI4NDkxMzQ3Z21haWwtbV8tNzM1Njk2NDE3NjE2MTczMTA5 M21fLTQ2OTU5NjA0MzcxNzI2MTgxNzJtXy04NjE1MTkwOTIwNDQ0NjA0NjY1bV80ODA4MjA4 NDY3MzM0NjUxODIzbV81NTY0NjI2NTg3MTIxMTIzNDgwZ21haWwtZG9jcy1pbnRlcm5hbC1n dWlkLWNkODM1MDEyLTdmZmYtZjkyYi00NDQ0LTc1MTU0MGEyYzJmNyI+DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImxpbmUtaGVpZ2h0OjEuMjttYXJnaW4t dG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOnJnYig1MSw1MSw1MSk7YmFja2dyb3VuZC1j b2xvcjpyZ2IoMjQ3LDI0NywyNDcpO2ZvbnQtd2VpZ2h0OjcwMDtmb250LXZhcmlhbnQtbnVt ZXJpYzpub3JtYWw7Zm9udC12YXJpYW50LWVhc3QtYXNpYW46bm9ybWFsO3ZlcnRpY2FsLWFs aWduOmJhc2VsaW5lO3doaXRlLXNwYWNlOnByZS13cmFwIj48Zm9udCBzaXplPSIxIj4vLyAo c3VnZ2VzdGlvbiBvbmx5LCBub3QgYXMgYW4gZWRpdG9yKTwvZm9udD48L3NwYW4+PC9kaXY+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImxpbmUtaGVpZ2h0 OjEuMjttYXJnaW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOnJnYig1MSw1MSw1MSk7 YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjQ3LDI0NywyNDcpO2ZvbnQtdmFyaWFudC1udW1lcmlj Om5vcm1hbDtmb250LXZhcmlhbnQtZWFzdC1hc2lhbjpub3JtYWw7dmVydGljYWwtYWxpZ246 YmFzZWxpbmU7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxmb250IHNpemU9IjEiPiJzdWJqZWN0 IjogezwvZm9udD48L3NwYW4+PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPGRpdg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgc3R5bGU9ImxpbmUtaGVpZ2h0OjEuMjttYXJnaW4tdG9wOjBwdDttYXJnaW4tYm90 dG9tOjBwdCI+PGZvbnQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgc2l6ZT0iMSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOnJnYig1MSw1MSw1MSk7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjQ3 LDI0NywyNDcpO2ZvbnQtdmFyaWFudC1udW1lcmljOm5vcm1hbDtmb250LXZhcmlhbnQtZWFz dC1hc2lhbjpub3JtYWw7dmVydGljYWwtYWxpZ246YmFzZWxpbmU7d2hpdGUtc3BhY2U6cHJl LXdyYXAiPsKgwqDCoCJhc19yZWYiOiB7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cmdiKDUxLDUxLDUxKTtiYWNrZ3Jv dW5kLWNvbG9yOnJnYigyNDcsMjQ3LDI0Nyk7Zm9udC12YXJpYW50LW51bWVyaWM6bm9ybWFs O2ZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOm5vcm1hbDt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGlu ZTt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOnByZS13 cmFwIj4JPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6cmdiKDUxLDUxLDUxKTtiYWNrZ3JvdW5kLWNvbG9yOnJn YigyNDcsMjQ3LDI0Nyk7Zm9udC12YXJpYW50LW51bWVyaWM6bm9ybWFsO2ZvbnQtdmFyaWFu dC1lYXN0LWFzaWFuOm5vcm1hbDt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt3aGl0ZS1zcGFj ZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj4JPC9zcGFu Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6cmdiKDUxLDUxLDUxKTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNDcsMjQ3LDI0 Nyk7Zm9udC12YXJpYW50LW51bWVyaWM6bm9ybWFsO2ZvbnQtdmFyaWFudC1lYXN0LWFzaWFu Om5vcm1hbDt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+ PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj4JPC9zcGFuPjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cmdi KDUxLDUxLDUxKTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNDcsMjQ3LDI0Nyk7Zm9udC12YXJp YW50LW51bWVyaWM6bm9ybWFsO2ZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOm5vcm1hbDt2ZXJ0 aWNhbC1hbGlnbjpiYXNlbGluZTt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9 IndoaXRlLXNwYWNlOnByZS13cmFwIj4JPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cmdiKDUxLDUxLDUxKTti YWNrZ3JvdW5kLWNvbG9yOnJnYigyNDcsMjQ3LDI0Nyk7Zm9udC12YXJpYW50LW51bWVyaWM6 bm9ybWFsO2ZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOm5vcm1hbDt2ZXJ0aWNhbC1hbGlnbjpi YXNlbGluZTt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+Ly8gcmVzcG9uc2Ugb25seSAod291bGRu 4oCZdCByZXF1aXJlIFNFQ0VWRU5UKTwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdg0Kc3R5bGU9ImxpbmUtaGVpZ2h0 OjEuMjt0ZXh0LWluZGVudDozNnB0O21hcmdpbi10b3A6MHB0O21hcmdpbi1ib3R0b206MHB0 Ij48Zm9udA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBz aXplPSIxIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6cmdiKDUxLDUxLDUxKTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNDcsMjQ3LDI0 Nyk7Zm9udC12YXJpYW50LW51bWVyaWM6bm9ybWFsO2ZvbnQtdmFyaWFudC1lYXN0LWFzaWFu Om5vcm1hbDt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+ 4oCcYXPigJ06IOKAnDxhIGhyZWY9Imh0dHBzOi8vZXgxLmFzLmNvbS8iIHJlbD0ibm9yZWZl cnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIiB0YXJn ZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5odHRwczovL2V4MS5hcy5jb208 L2E+4oCdLDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6cmdiKDUxLDUxLDUxKTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNDcs MjQ3LDI0Nyk7Zm9udC12YXJpYW50LW51bWVyaWM6bm9ybWFsO2ZvbnQtdmFyaWFudC1lYXN0 LWFzaWFuOm5vcm1hbDt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt3aGl0ZS1zcGFjZTpwcmUt d3JhcCI+PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj4JPC9zcGFuPjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6cmdiKDUxLDUxLDUxKTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNDcsMjQ3LDI0Nyk7Zm9u dC12YXJpYW50LW51bWVyaWM6bm9ybWFsO2ZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOm5vcm1h bDt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4g c3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj4JPC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PC9k aXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdg0Kc3R5 bGU9ImxpbmUtaGVpZ2h0OjEuMjt0ZXh0LWluZGVudDozNnB0O21hcmdpbi10b3A6MHB0O21h cmdpbi1ib3R0b206MHB0Ij48Zm9udA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBzaXplPSIxIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cmdiKDUxLDUxLDUxKTtiYWNrZ3JvdW5kLWNvbG9y OnJnYigyNDcsMjQ3LDI0Nyk7Zm9udC12YXJpYW50LW51bWVyaWM6bm9ybWFsO2ZvbnQtdmFy aWFudC1lYXN0LWFzaWFuOm5vcm1hbDt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt3aGl0ZS1z cGFjZTpwcmUtd3JhcCI+4oCccmVm4oCdOiDigJw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOnJnYigzNiw0MSw0Nik7YmFj a2dyb3VuZC1jb2xvcjpyZ2IoMjQzLDI0MywyNDMpO2ZvbnQtdmFyaWFudC1udW1lcmljOm5v cm1hbDtmb250LXZhcmlhbnQtZWFzdC1hc2lhbjpub3JtYWw7dmVydGljYWwtYWxpZ246YmFz ZWxpbmU7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPlhVVDJNRk0xWEJJS0pLU0RVOFFNPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpyZ2IoNTEsNTEsNTEpO2JhY2tncm91bmQtY29sb3I6cmdiKDI0NywyNDcsMjQ3KTtmb250 LXZhcmlhbnQtbnVtZXJpYzpub3JtYWw7Zm9udC12YXJpYW50LWVhc3QtYXNpYW46bm9ybWFs O3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO3doaXRlLXNwYWNlOnByZS13cmFwIj7igJ3CoMKg wqA8L3NwYW4+PC9mb250PjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDxkaXYNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHN0eWxlPSJsaW5lLWhlaWdodDoxLjI7bWFyZ2luLXRvcDowcHQ7bWFyZ2luLWJvdHRv bTowcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpyZ2IoNTEsNTEsNTEpO2JhY2tncm91bmQtY29sb3I6cmdiKDI0NywyNDcsMjQ3 KTtmb250LXZhcmlhbnQtbnVtZXJpYzpub3JtYWw7Zm9udC12YXJpYW50LWVhc3QtYXNpYW46 bm9ybWFsO3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO3doaXRlLXNwYWNlOnByZS13cmFwIj48 Zm9udCBzaXplPSIxIj7CoMKgwqB9LMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgPC9mb250Pjwvc3Bhbj48L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8ZGl2DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBzdHlsZT0ibGluZS1oZWlnaHQ6MS4yO21hcmdpbi10b3A6MHB0O21hcmdpbi1i b3R0b206MHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6cmdiKDUxLDUxLDUxKTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNDcsMjQ3 LDI0Nyk7Zm9udC12YXJpYW50LW51bWVyaWM6bm9ybWFsO2ZvbnQtdmFyaWFudC1lYXN0LWFz aWFuOm5vcm1hbDt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt3aGl0ZS1zcGFjZTpwcmUtd3Jh cCI+PGZvbnQgc2l6ZT0iMSI+wqDCoMKgImFzc2VydGlvbnMiOiBbIF0sIMKgIMKgIMKgIMKg IMKgIMKgIMKgICAgICAvLyByZXF1ZXN0IGFuZCByZXNwb25zZSAoaWRfdG9rZW4vandrdGh1 bWIvRElEL1ZDL2V0Yy4gLSZndDsgd2hhdGV2ZXIgaW5mbyBjYW4gYmUgdmFsaWRhdGVkIGJ5 IHRoZSBBUyk8L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDxmb250IHNpemU9IjEiPjxicj4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8L2ZvbnQ+DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPGRpdg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgc3R5bGU9ImxpbmUtaGVpZ2h0OjEuMjttYXJnaW4tdG9wOjBwdDttYXJn aW4tYm90dG9tOjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOnJnYig1MSw1MSw1MSk7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjQ3 LDI0NywyNDcpO2ZvbnQtdmFyaWFudC1udW1lcmljOm5vcm1hbDtmb250LXZhcmlhbnQtZWFz dC1hc2lhbjpub3JtYWw7dmVydGljYWwtYWxpZ246YmFzZWxpbmU7d2hpdGUtc3BhY2U6cHJl LXdyYXAiPjxmb250IHNpemU9IjEiPsKgwqDCoCJoaW50cyI6IHsgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgICAgIC8vIHJlcXVlc3Qgb25seSAob3B0aW9uYWwpPC9mb250 Pjwvc3Bhbj48L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8ZGl2DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHls ZT0ibGluZS1oZWlnaHQ6MS4yO21hcmdpbi10b3A6MHB0O21hcmdpbi1ib3R0b206MHB0Ij48 Zm9udA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzaXpl PSIxIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6cmdiKDUxLDUxLDUxKTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNDcsMjQ3LDI0Nyk7 Zm9udC12YXJpYW50LW51bWVyaWM6bm9ybWFsO2ZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOm5v cm1hbDt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+wqDC oMKgwqDCoMKgInNlbGYiOiB7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cmdiKDUxLDUxLDUxKTtiYWNrZ3JvdW5kLWNv bG9yOnJnYigyNDcsMjQ3LDI0Nyk7Zm9udC12YXJpYW50LW51bWVyaWM6bm9ybWFsO2ZvbnQt dmFyaWFudC1lYXN0LWFzaWFuOm5vcm1hbDt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt3aGl0 ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj4J PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6cmdiKDUxLDUxLDUxKTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNDcs MjQ3LDI0Nyk7Zm9udC12YXJpYW50LW51bWVyaWM6bm9ybWFsO2ZvbnQtdmFyaWFudC1lYXN0 LWFzaWFuOm5vcm1hbDt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt3aGl0ZS1zcGFjZTpwcmUt d3JhcCI+PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj4JPC9zcGFuPiAgICAg ICAgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpyZ2IoNTEsNTEsNTEpO2JhY2tncm91bmQtY29sb3I6cmdiKDI0NywyNDcs MjQ3KTtmb250LXZhcmlhbnQtbnVtZXJpYzpub3JtYWw7Zm9udC12YXJpYW50LWVhc3QtYXNp YW46bm9ybWFsO3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO3doaXRlLXNwYWNlOnByZS13cmFw Ij4vLyByZXBsYWNlcyByZXF1ZXN0LnVzZXIgKHN1cHBvcnQgU0VDRVZFTlQgaGVyZSk8L3Nw YW4+PC9mb250PjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDxkaXYNCnN0eWxlPSJsaW5lLWhlaWdodDoxLjI7dGV4dC1pbmRlbnQ6MzZwdDttYXJn aW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdCI+PGZvbnQNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgc2l6ZT0iMSI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOnJnYig1MSw1MSw1MSk7YmFj a2dyb3VuZC1jb2xvcjpyZ2IoMjQ3LDI0NywyNDcpO2ZvbnQtdmFyaWFudC1udW1lcmljOm5v cm1hbDtmb250LXZhcmlhbnQtZWFzdC1hc2lhbjpub3JtYWw7dmVydGljYWwtYWxpZ246YmFz ZWxpbmU7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPsKgwqDCoOKAnHN1Yl9pZHPigJ06IHsgfSw8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOnJnYig1MSw1MSw1MSk7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjQ3LDI0NywyNDcp O2ZvbnQtdmFyaWFudC1udW1lcmljOm5vcm1hbDtmb250LXZhcmlhbnQtZWFzdC1hc2lhbjpu b3JtYWw7dmVydGljYWwtYWxpZ246YmFzZWxpbmU7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxz cGFuIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+CTwvc3Bhbj48L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOnJnYig1 MSw1MSw1MSk7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjQ3LDI0NywyNDcpO2ZvbnQtdmFyaWFu dC1udW1lcmljOm5vcm1hbDtmb250LXZhcmlhbnQtZWFzdC1hc2lhbjpub3JtYWw7dmVydGlj YWwtYWxpZ246YmFzZWxpbmU7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFuIHN0eWxlPSJ3 aGl0ZS1zcGFjZTpwcmUtd3JhcCI+CTwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOnJnYig1MSw1MSw1MSk7YmFj a2dyb3VuZC1jb2xvcjpyZ2IoMjQ3LDI0NywyNDcpO2ZvbnQtdmFyaWFudC1udW1lcmljOm5v cm1hbDtmb250LXZhcmlhbnQtZWFzdC1hc2lhbjpub3JtYWw7dmVydGljYWwtYWxpZ246YmFz ZWxpbmU7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPi8vIFNFQ0VWRU5UIChpbmNsdWRpbmcgb3Bh cXVlIGluIGRyYWZ0LTA3IC0gdGhhdCBjb3VsZCBjb250YWluIHRoZSByZWYpPC9zcGFuPjwv Zm9udD48L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 ZGl2DQpzdHlsZT0ibGluZS1oZWlnaHQ6MS4yO3RleHQtaW5kZW50OjM2cHQ7bWFyZ2luLXRv cDowcHQ7bWFyZ2luLWJvdHRvbTowcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpyZ2IoNTEsNTEsNTEpO2JhY2tncm91bmQtY29s b3I6cmdiKDI0NywyNDcsMjQ3KTtmb250LXZhcmlhbnQtbnVtZXJpYzpub3JtYWw7Zm9udC12 YXJpYW50LWVhc3QtYXNpYW46bm9ybWFsO3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO3doaXRl LXNwYWNlOnByZS13cmFwIj48Zm9udCBzaXplPSIxIj7CoMKgwqDigJxhc3NlcnRpb25z4oCd OiBbIF0gICAgICAgICAgICAvLyBzZWUgZXhhbXBsZXM6IFZDIG9uIERPQiBvciBaS1Agb24g YWdlICh3aWRlciBzY29wZSwgcG9zc2libHkgdGhyb3VnaCBleHRlbnNpb25zKSAgPC9mb250 Pjwvc3Bhbj48L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8ZGl2DQpzdHlsZT0ibGluZS1oZWlnaHQ6MS4yO3RleHQtaW5kZW50OjM2cHQ7bWFyZ2lu LXRvcDowcHQ7bWFyZ2luLWJvdHRvbTowcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpyZ2IoNTEsNTEsNTEpO2JhY2tncm91bmQt Y29sb3I6cmdiKDI0NywyNDcsMjQ3KTtmb250LXZhcmlhbnQtbnVtZXJpYzpub3JtYWw7Zm9u dC12YXJpYW50LWVhc3QtYXNpYW46bm9ybWFsO3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO3do aXRlLXNwYWNlOnByZS13cmFwIj48Zm9udCBzaXplPSIxIj59LMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoDwvZm9udD48L3NwYW4+PC9kaXY+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImxpbmUtaGVpZ2h0OjEuMjttYXJnaW4tdG9w OjBwdDttYXJnaW4tYm90dG9tOjBwdCI+PGZvbnQNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgc2l6ZT0iMSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOnJnYig1MSw1MSw1MSk7YmFja2dyb3Vu ZC1jb2xvcjpyZ2IoMjQ3LDI0NywyNDcpO2ZvbnQtdmFyaWFudC1udW1lcmljOm5vcm1hbDtm b250LXZhcmlhbnQtZWFzdC1hc2lhbjpub3JtYWw7dmVydGljYWwtYWxpZ246YmFzZWxpbmU7 d2hpdGUtc3BhY2U6cHJlLXdyYXAiPsKgwqDCoMKgwqDCoCJwcmluY2lwYWwiOiB7PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpyZ2IoNTEsNTEsNTEpO2JhY2tncm91bmQtY29sb3I6cmdiKDI0NywyNDcsMjQ3KTtmb250 LXZhcmlhbnQtbnVtZXJpYzpub3JtYWw7Zm9udC12YXJpYW50LWVhc3QtYXNpYW46bm9ybWFs O3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO3doaXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBz dHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXAiPgk8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpyZ2IoNTEsNTEs NTEpO2JhY2tncm91bmQtY29sb3I6cmdiKDI0NywyNDcsMjQ3KTtmb250LXZhcmlhbnQtbnVt ZXJpYzpub3JtYWw7Zm9udC12YXJpYW50LWVhc3QtYXNpYW46bm9ybWFsO3ZlcnRpY2FsLWFs aWduOmJhc2VsaW5lO3doaXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBzdHlsZT0id2hpdGUt c3BhY2U6cHJlLXdyYXAiPgk8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpyZ2IoNTEsNTEsNTEpO2JhY2tncm91 bmQtY29sb3I6cmdiKDI0NywyNDcsMjQ3KTtmb250LXZhcmlhbnQtbnVtZXJpYzpub3JtYWw7 Zm9udC12YXJpYW50LWVhc3QtYXNpYW46bm9ybWFsO3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5l O3doaXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdy YXAiPgk8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpyZ2IoNTEsNTEsNTEpO2JhY2tncm91bmQtY29sb3I6cmdi KDI0NywyNDcsMjQ3KTtmb250LXZhcmlhbnQtbnVtZXJpYzpub3JtYWw7Zm9udC12YXJpYW50 LWVhc3QtYXNpYW46bm9ybWFsO3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO3doaXRlLXNwYWNl OnByZS13cmFwIj4vLyBuZXcgcHJvcG9zYWwgcHJlc2VudGVkIGF0IElFVEYxMTAgKGp1c3Qg YW4gaWRlYSk8L3NwYW4+PC9mb250PjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDxkaXYNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHN0eWxlPSJsaW5lLWhlaWdodDoxLjI7bWFyZ2luLXRvcDowcHQ7bWFyZ2lu LWJvdHRvbTowcHQiPjxmb250DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHNpemU9IjEiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpyZ2IoNTEsNTEsNTEpO2JhY2tncm91bmQtY29sb3I6cmdi KDI0NywyNDcsMjQ3KTtmb250LXZhcmlhbnQtbnVtZXJpYzpub3JtYWw7Zm9udC12YXJpYW50 LWVhc3QtYXNpYW46bm9ybWFsO3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO3doaXRlLXNwYWNl OnByZS13cmFwIj48c3BhbiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXAiPgk8L3NwYW4+ PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpyZ2IoNTEsNTEsNTEpO2JhY2tncm91bmQtY29sb3I6cmdiKDI0NywyNDcsMjQ3 KTtmb250LXZhcmlhbnQtbnVtZXJpYzpub3JtYWw7Zm9udC12YXJpYW50LWVhc3QtYXNpYW46 bm9ybWFsO3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO3doaXRlLXNwYWNlOnByZS13cmFwIj4g wqAg4oCcYXV0b21hdGVk4oCdOiB0cnVlLDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cmdiKDUxLDUxLDUxKTtiYWNrZ3Jv dW5kLWNvbG9yOnJnYigyNDcsMjQ3LDI0Nyk7Zm9udC12YXJpYW50LW51bWVyaWM6bm9ybWFs O2ZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOm5vcm1hbDt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGlu ZTt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOnByZS13 cmFwIj4JPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6cmdiKDUxLDUxLDUxKTtiYWNrZ3JvdW5kLWNvbG9yOnJn YigyNDcsMjQ3LDI0Nyk7Zm9udC12YXJpYW50LW51bWVyaWM6bm9ybWFsO2ZvbnQtdmFyaWFu dC1lYXN0LWFzaWFuOm5vcm1hbDt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt3aGl0ZS1zcGFj ZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj4JPC9zcGFu Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6cmdiKDUxLDUxLDUxKTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNDcsMjQ3LDI0 Nyk7Zm9udC12YXJpYW50LW51bWVyaWM6bm9ybWFsO2ZvbnQtdmFyaWFudC1lYXN0LWFzaWFu Om5vcm1hbDt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+ Ly8gcnVsZSBlbmdpbmU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOnJnYig1MSw1MSw1MSk7YmFja2dyb3VuZC1jb2xvcjpy Z2IoMjQ3LDI0NywyNDcpO2ZvbnQtdmFyaWFudC1udW1lcmljOm5vcm1hbDtmb250LXZhcmlh bnQtZWFzdC1hc2lhbjpub3JtYWw7dmVydGljYWwtYWxpZ246YmFzZWxpbmU7d2hpdGUtc3Bh Y2U6cHJlLXdyYXAiPjxzcGFuIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+CTwvc3Bh bj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOnJnYig1MSw1MSw1MSk7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjQ3LDI0Nywy NDcpO2ZvbnQtdmFyaWFudC1udW1lcmljOm5vcm1hbDtmb250LXZhcmlhbnQtZWFzdC1hc2lh bjpub3JtYWw7dmVydGljYWwtYWxpZ246YmFzZWxpbmU7d2hpdGUtc3BhY2U6cHJlLXdyYXAi PjxzcGFuIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+CTwvc3Bhbj48L3NwYW4+PC9m b250PjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxk aXYNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJs aW5lLWhlaWdodDoxLjI7bWFyZ2luLXRvcDowcHQ7bWFyZ2luLWJvdHRvbTowcHQiPjxmb250 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNpemU9IjEi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpyZ2IoNTEsNTEsNTEpO2JhY2tncm91bmQtY29sb3I6cmdiKDI0NywyNDcsMjQ3KTtmb250 LXZhcmlhbnQtbnVtZXJpYzpub3JtYWw7Zm9udC12YXJpYW50LWVhc3QtYXNpYW46bm9ybWFs O3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO3doaXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBz dHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXAiPgk8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpyZ2IoNTEsNTEs NTEpO2JhY2tncm91bmQtY29sb3I6cmdiKDI0NywyNDcsMjQ3KTtmb250LXZhcmlhbnQtbnVt ZXJpYzpub3JtYWw7Zm9udC12YXJpYW50LWVhc3QtYXNpYW46bm9ybWFsO3ZlcnRpY2FsLWFs aWduOmJhc2VsaW5lO3doaXRlLXNwYWNlOnByZS13cmFwIj4gwqAg4oCcYXN5bmPigJ06IHsg fTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6cmdiKDUxLDUxLDUxKTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNDcsMjQ3LDI0 Nyk7Zm9udC12YXJpYW50LW51bWVyaWM6bm9ybWFsO2ZvbnQtdmFyaWFudC1lYXN0LWFzaWFu Om5vcm1hbDt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+ PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj4JPC9zcGFuPjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cmdi KDUxLDUxLDUxKTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNDcsMjQ3LDI0Nyk7Zm9udC12YXJp YW50LW51bWVyaWM6bm9ybWFsO2ZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOm5vcm1hbDt2ZXJ0 aWNhbC1hbGlnbjpiYXNlbGluZTt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9 IndoaXRlLXNwYWNlOnByZS13cmFwIj4JPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cmdiKDUxLDUxLDUxKTti YWNrZ3JvdW5kLWNvbG9yOnJnYigyNDcsMjQ3LDI0Nyk7Zm9udC12YXJpYW50LW51bWVyaWM6 bm9ybWFsO2ZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOm5vcm1hbDt2ZXJ0aWNhbC1hbGlnbjpi YXNlbGluZTt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNl OnByZS13cmFwIj4JPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cmdiKDUxLDUxLDUxKTtiYWNrZ3JvdW5kLWNv bG9yOnJnYigyNDcsMjQ3LDI0Nyk7Zm9udC12YXJpYW50LW51bWVyaWM6bm9ybWFsO2ZvbnQt dmFyaWFudC1lYXN0LWFzaWFuOm5vcm1hbDt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt3aGl0 ZS1zcGFjZTpwcmUtd3JhcCI+Ly8gcmVtb3RlIFJPczwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdg0Kc3R5bGU9Imxp bmUtaGVpZ2h0OjEuMjt0ZXh0LWluZGVudDozNnB0O21hcmdpbi10b3A6MHB0O21hcmdpbi1i b3R0b206MHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6cmdiKDUxLDUxLDUxKTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNDcsMjQ3 LDI0Nyk7Zm9udC12YXJpYW50LW51bWVyaWM6bm9ybWFsO2ZvbnQtdmFyaWFudC1lYXN0LWFz aWFuOm5vcm1hbDt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt3aGl0ZS1zcGFjZTpwcmUtd3Jh cCI+PGZvbnQgc2l6ZT0iMSI+fcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8L2ZvbnQ+ PC9zcGFuPjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDxkaXYNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxl PSJsaW5lLWhlaWdodDoxLjI7bWFyZ2luLXRvcDowcHQ7bWFyZ2luLWJvdHRvbTowcHQiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpy Z2IoNTEsNTEsNTEpO2JhY2tncm91bmQtY29sb3I6cmdiKDI0NywyNDcsMjQ3KTtmb250LXZh cmlhbnQtbnVtZXJpYzpub3JtYWw7Zm9udC12YXJpYW50LWVhc3QtYXNpYW46bm9ybWFsO3Zl cnRpY2FsLWFsaWduOmJhc2VsaW5lO3doaXRlLXNwYWNlOnByZS13cmFwIj48Zm9udCBzaXpl PSIxIj7CoMKgwqB9PC9mb250Pjwvc3Bhbj48L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8ZGl2DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBzdHlsZT0ibGluZS1oZWlnaHQ6MS4yO21hcmdpbi10b3A6MHB0O21h cmdpbi1ib3R0b206MHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6cmdiKDUxLDUxLDUxKTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigy NDcsMjQ3LDI0Nyk7Zm9udC12YXJpYW50LW51bWVyaWM6bm9ybWFsO2ZvbnQtdmFyaWFudC1l YXN0LWFzaWFuOm5vcm1hbDt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt3aGl0ZS1zcGFjZTpw cmUtd3JhcCI+PGZvbnQgc2l6ZT0iMSI+fTwvZm9udD48L3NwYW4+PC9kaXY+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvc3Bhbj48L2Rpdj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8ZGl2Pi0gQmVuZWZpdHM6IGFzX3JlZiBpcyBzZWxmDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN1cHBvcnRpbmcgKG5vIHN0cm9uZyBjb3Vw bGluZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3aXRoIFNFQ0VW RU5UKSwgYnV0IGNhbiBzdGlsbCB0YWtlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFNFQ0VWRU5UIGFzIGFuIGlucHV0IGhpbnQgZm9yIHRoZQ0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBUy4gSXQgYXZvaWRzIHRoZSByaXNrIG9m IG1ha2luZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhbiBvZmZp Y2lhbCBhc3NvY2lhdGlvbiBiZXR3ZWVuIGENCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgd2VhayBnbG9iYWwgaWRlbnRpZmllciAoZS5nLg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBlbWFpbCwgdXNlZCBlbHNld2hlcmUpIGFuZA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBob3BlZnVsbHkgc3Ryb25n ZXIgbG9jYWwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYXNzZXJ0 aW9ucy4gR05BUCB3b3VsZCBiZSBmdWxseQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBhZ25vc3RpYyB0byB3aGF0ZXZlciBpZGVudGl0eQ0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBzeXN0ZW0gaXMgdXNlZCwgb25seSBmYWNpbGl0 YXRpbmcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW50ZXJvcGVy YWJpbGl0eSB0aHJvdWdoDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGFzc2VydGlvbnMgKHNlY29uZCBvbmx5IGluDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGltcG9ydGFuY2XCoGNvbXBhcmVkIHRvIHRoZSBBUw0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvcGFxdWUgcmVmZXJlbmNlKS4gU29tZSBh c3NlcnRpb25zDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChwb3Nz aWJseSBleHRlbnNpb25zKSBjb3VsZCBhbHNvDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGJlIHVzZWZ1bCBmb3IgdGhlIEFTIGRlY2lzaW9uDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIChlLmcuIFZDIG9yIFpLUCkuPC9kaXY+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pi0gRG93bnNpZGVzOiBv cGFxdWVuZXNzIG9mDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFz X3JlZiBpcyBhIGZlYXR1cmUsIG5vdCBhIGJ1Zy4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgVGhlIG9wYXF1ZSByZWZlcmVuY2UgaXMgZnVsbHkNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWFuYWdlZCBieSB0aGUgQVMsIHRoZXJl Zm9yZSBub3QNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW5oZXJl bnRseSBwb3J0YWJsZSAoY2YNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgcG9ydGFiaWxpdHkgZGlzY3Vzc2lvbnMgaW4gT0lEQw0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBjdXJyZW50bHkpLiBUaGVyZSdzIG5vIGV4cGxpY2l0DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJpbmRpbmcgdG8gYW4gb2Zm aWNpYWwgaWRlbnRpdHksDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IG9ubHkgYSBjb250ZXh0dWFsIG1hcHBpbmcgdG8gQVMNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgdmFsaWRhdGVkIGFzc2VydGlvbnMuIEl0IG1ha2VzIGl0DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vcmUgZGlmZmljdWx0IHRv IG1hdGNoIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpZGVu dGlmaWVycyBmcm9tIG9uZSBBUyB0byBhbm90aGVyDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIG9yIHRvIGNvcnJlbGF0ZSB3aXRoIHRoZSBjbGllbnQNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdXNlciBEQiAoc3RpbGwgcG9zc2li bGUgdmlhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFzc2VydGlv bnMsIGlmIHRoZSBBUyBhbGxvd3MgaXQpLg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBBc3NlcnRpb25zIGFyZSBtdWNoIG1vcmUgZ2VuZXJpYw0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAocG9zc2libHkgdmlhIGV4dGVuc2lvbnMp LCBidXQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWlnaHQgcmVx dWlyZSBhIG1vcmUgYWR2YW5jZWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgbWVjaGFuaXNtwqB0byByZXF1ZXN0L3Jlc3BvbnNlIG9ubHkNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIG1vc3QgcmVsZXZhbnQgaW5mb3JtYXRp b24NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKHdoaWNoIG1ha2Vz IHRoZSBBUyBwb2xpY3kNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Y3JpdGljYWwgaGVyZSkuPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwv ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj5JIGhvcGUg dGhhdCBjbGFyaWZpZXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg dGhlwqByZWFzb25pbmcgZm9yIGJvdGggb3B0aW9ucy4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgQWdhaW4gSSdtIG5vdCBzYXlpbmcgb3B0aW9uIDIgaXMNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYmV0dGVyLCBqdXN0IHNheWlu ZyB0aGUgdHJhZGUtb2Zmcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBhcmUgZGlmZmVyZW50ICgrIGtub3dpbmcgdGhhdCB3ZQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBuZWVkIHRvIGtlZXAgaXQgc2ltcGxlKS48L2Rpdj4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+LSBvcHRpb24gMSBwdXRz IG1vcmUgaW4gc3ViX2lkcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBhbmQgbGVzcyBpbiBhc3NlcnRpb25zPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8ZGl2Pi0gb3B0aW9uIDIgcHV0cyBsZXNzIGluIHRoZQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZWZlcmVuY2UgYW5kIG1vcmUgaW4g YXNzZXJ0aW9uc8KgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8ZGl2PkFsbCBvZiB0aGlzIGlzIG9wZW4gdG8NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgZGlzY3Vzc2lvbi4gTW9yZSBnZW5lcmFsbHkNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgc3BlYWtpbmcsIG9uIGV2ZXJ5IHBhcnQgaW4g b3JhbmdlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFuZCBxdWVz dGlvbiBtYXJrICg/KSBJIHdvdWxkIGxvdmUNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgeW91ciBpZGVhcyBhbmQgY3JpdGljaXNtcy4gV2hhdCBJDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludGVuZGVkIGFzIGFuIGVkaXRvciBp cyBvbmx5IHRvDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhpZ2hs aWdodCB3aGVyZSB0aGUgV0cgaGFzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGltcG9ydGFudCBjaG9pY2VzIHRvIG1ha2UsIGJlZm9yZQ0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB3ZSBjYW4gbWFrZSB0aGUgcmVsYXRlZCBQUnMu PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj5BIGZ1cnRoZXIgc2lkZSBjb21tZW50 OiBJRVRGDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVBVCBSQVRT IHdhcyBzdWdnZXN0ZWQgZm9yDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGFzc2VydGlvbnMsIGJ1dCByZWxhdGVzIG1vcmUgdG8NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgdGhlIGNsaWVudCBhdHRlc3RhdGlvbnMuIEl0IHdhcw0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhZGRlZCBhcyBhIGNvbW1l bnQgaW7CoDxhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJl Zj0iaHR0cHM6Ly9naXRodWIuY29tL2lldGYtd2ctZ25hcC9nbmFwLWNvcmUtcHJvdG9jb2wv aXNzdWVzLzQ0Ig0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJl bD0ibm9yZWZlcnJlciBub3JlZmVycmVyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgbm9yZWZlcnJlciBub3JlZmVycmVyDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgbm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0 cnVlIj5odHRwczovL2dpdGh1Yi5jb20vaWV0Zi13Zy1nbmFwL2duYXAtY29yZS1wcm90b2Nv bC9pc3N1ZXMvNDQ8L2E+LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB3aGljaCBpcyBhIGRpc3RpbmN0IHRvcGljIHdlJ2xsDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHdvcmsgb24uPC9kaXY+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PGRpdj5GYWJpZW4gKGVkaXRvcidzIGhhdCBvZmYpPC9kaXY+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIDxicj4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUWEF1dGggbWFpbGluZyBsaXN0PGJy Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxhIGhyZWY9Im1haWx0bzpU WEF1dGhAaWV0Zi5vcmciDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBy ZWw9Im5vcmVmZXJyZXIgbm9yZWZlcnJlcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIiDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayINCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+VFhBdXRo QGlldGYub3JnPC9hPjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgiDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICByZWw9Im5vcmVmZXJyZXIgbm9yZWZlcnJlcg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbm9yZWZlcnJlciBub3JlZmVycmVyIG5v cmVmZXJyZXIiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9 Il9ibGFuayINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1u b3Qtc2VuZD0idHJ1ZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90 eGF1dGg8L2E+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAg ICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0K ICAgICAgICAgICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgICAg ICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAg IC0tIDxicj4NCiAgICAgICAgICAgICAgICAgIFRYQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQog ICAgICAgICAgICAgICAgICA8YSBocmVmPSJtYWlsdG86VFhBdXRoQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAgICAgICAgcmVsPSJub3JlZmVycmVyIiBtb3ot ZG8tbm90LXNlbmQ9InRydWUiPlRYQXV0aEBpZXRmLm9yZzwvYT48YnI+DQogICAgICAgICAg ICAgICAgICA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3R4YXV0aCINCiAgICAgICAgICAgICAgICAgICAgcmVsPSJub3JlZmVycmVyIG5vcmVmZXJy ZXIiIHRhcmdldD0iX2JsYW5rIg0KICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNl bmQ9InRydWUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRo PC9hPjxicj4NCiAgICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAg IDwvZGl2Pg0KICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgIDxwcmUgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LENvdXJpZXIsbW9ub3NwYWNl LGFyaWFsLHNhbnMtc2VyaWY7bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7d2hp dGUtc3BhY2U6cHJlLXdyYXA7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpO2Zv bnQtc2l6ZToxNHB4Ij5UaGlzIGNvbW11bmljYXRpb24sIGluY2x1ZGluZyBhbnkgYXR0YWNo bWVudHMsIGlzIGNvbmZpZGVudGlhbC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCwgeW91IHNob3VsZCBub3QgcmVhZCBpdCAtIHBsZWFzZSBjb250YWN0IG1lIGlt bWVkaWF0ZWx5LCBkZXN0cm95IGl0LCBhbmQgZG8gbm90IGNvcHkgb3IgdXNlIGFueSBwYXJ0 IG9mIHRoaXMgY29tbXVuaWNhdGlvbiBvciBkaXNjbG9zZSBhbnl0aGluZyBhYm91dCBpdC4g VGhhbmsgeW91LiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgY29tbXVuaWNhdGlvbiBkb2VzIG5v dCBkZXNpZ25hdGUgYW4gaW5mb3JtYXRpb24gc3lzdGVtIGZvciB0aGUgcHVycG9zZXMgb2Yg dGhlIEVsZWN0cm9uaWMgVHJhbnNhY3Rpb25zIEFjdCAyMDAyLjwvcHJlPg0KICAgICAgICAg ICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgIDwvZGl2Pg0KICAgICAgICA8L2Rpdj4NCiAg ICAgIDwvZGl2Pg0KICAgICAgPGJyPg0KICAgICAgPGZpZWxkc2V0IGNsYXNzPSJtaW1lQXR0 YWNobWVudEhlYWRlciI+PC9maWVsZHNldD4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgPHA+ PGJyPg0KICAgIDwvcD4NCiAgPC9ib2R5Pg0KPC9odG1sPg0K --------------53B8E44290D494B79CAA4081-- From nobody Thu Mar 11 10:56:49 2021 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 774793A0D75 for ; Thu, 11 Mar 2021 10:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, T_REMOTE_IMAGE=0.01, 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 HAMQ-pp4P51B for ; Thu, 11 Mar 2021 10:56:44 -0800 (PST) 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 0DCCA3A0D73 for ; Thu, 11 Mar 2021 10:56:44 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id k2so23081831ioh.5 for ; Thu, 11 Mar 2021 10:56:44 -0800 (PST) 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=1AmbNfg/9wRO4gCDnbeBwGSs/u4ERcICnqlVwF6fNrw=; b=uNJ0MdudFkAg5eBplzZyiq51gPmO49xVZuZcGhTXZElNT1YIa6PAxA7Mki9I81cBAE dIrSy99sqTC040CeRXxsDv3ghAb8luaMv6xtCXOd1TgUv2vWaalGRHFVFKza+Mqn9UVN P147RGnEyWw+IfDZenExwkJAFXdfkEyR+/rqBXIL5L52Be5XtNNc+S3jizmYo85q6zMa t5TWcqkLxylK92UnrBFIkjwWFPjUBOCpz6p6j/97wfugd8jxJ1MQ1aIVZ26FjrtmmFzM pcQwpBVVhtaXD0wR5u445D4/aq7JBlI5CfF/57zWm2dw2ViMd352OPHri7D4yfeDm3qo U+xQ== 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=1AmbNfg/9wRO4gCDnbeBwGSs/u4ERcICnqlVwF6fNrw=; b=R02fOJ8CVfTnVzdHJaSHPwQW3gf3IsRUKwOxL40awoanhlWXb5d9OaoU8IkQ9ARUlE TffGS9pXWVtRZhpje7cgwI75/EmpN/3BmFRJp6ow69E8sb+4oLc+8BMIcOWQ5glRPXbk R8GmDUZ3GtT/ZtSaWJx5PLx1LV6F5f0de21BOoXGxu5y393KUUyAADl35Jd+wtJhziQN TKWBroF6DGyWMDMnB1AkoLoqnJ0gro1hCwLcEAO5HjpEspjjl/qtv+DR2/oiYXZe0G5g +4pJFyXZJ0J87H935N8DZpLdNM/8DFnkioEIV+87Z7bTMBdwpk2ctRQoK0J67N38jPi5 8hZg== X-Gm-Message-State: AOAM531eDXMIy7IiZqZmWBJZF2qwqANRZNncRyx5SrkUb20pkusN9F/j wcs8Lj2tnmKxJGuQcqn225t1mSyenUJ4WMZTU6o= X-Google-Smtp-Source: ABdhPJzCrHwk97FMzYLYuYcHTijZYZMt7JaYl/0IVGFjNCmrR/eCqT8lpmhYgsupzjCsniazFow2LEvVcry1fHM034k= X-Received: by 2002:a05:6638:30d:: with SMTP id w13mr4905321jap.77.1615489002669; Thu, 11 Mar 2021 10:56:42 -0800 (PST) MIME-Version: 1.0 References: <67a11cda-a06a-4e03-0d99-05cf6ab14474@free.fr> In-Reply-To: <67a11cda-a06a-4e03-0d99-05cf6ab14474@free.fr> From: Fabien Imbault Date: Thu, 11 Mar 2021 19:56:31 +0100 Message-ID: To: Denis Cc: GNAP Mailing List , Justin Richer , Tobias Looker Content-Type: multipart/alternative; boundary="000000000000248a0705bd475874" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 18:56:49 -0000 --000000000000248a0705bd475874 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Denis, There's one big change in draft 07 : opaque identifiers. That's basically what we discussed in https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/51 Fabien On Thu, Mar 11, 2021 at 7:50 PM Denis wrote: > Hi Fabien, > > Thank you for launching the discussion. > > SECEVENT draft-07 does not really offer new possibilities over draft-06. > The major change is simply in the syntax naming. > > The response to your question is not limited to an exclusive choice > between option 1 and option 2. :-) > > The definition of a subject identifier in draft-07 is : > > *3. Subject Identifiers > * > > * A Subject Identifier is a JSON [RFC7159] object whose contents may be > used to identify a subject within some context. An Identifier Format > is a named definition of a set of information that may be used to > identify a subject, and the rules for encoding that information as a > Subject Identifier; they define the syntax and semantics of Subject > Identifiers.* > > With such a definition is it possible to request some *types *of subject > identifiers to be placed into an access token, > to place subjects identifiers (with their values) into an access token an= d > for a RS to compare these subjects identifiers > (with their values) against validation rules enacted by a RO acting as an > ADF (Access Decision Function) which also use > the same subjects identifiers (with their values). > > A DID is a persistent global unique identifier. > > In issue #210 ("sub_id" claims #210) I already proposed the following > examples for globally unique identifiers (gu_id) : > > (1) For a globally unique identifier: > > "sub_id": { > "format": "gu_id", > "gu_id": " email", > "email: "john@hughes.com" , > } > > or > > "sub_id": { > "format": "gu_id", > "gu_id": "ssn", > "ssn": { > "cn": "250" > "value": "160087404506527", > }, > } > > In order to address DIDs, I would simply add the following example: > > "sub_id": { > "format": "gu_id", > "gu_id": " did", > "did: "did:*DID:Method:DID Method Specific String*", > } > > "sub_ids" claims are much better when compared to "sub" claims. > > The definition of Subject Identifier in the draft-07 (section 3) is : > > A Subject Identifier is a JSON [RFC7159] object whose contents may be > used to identify a subject *within some context*. > > However, page 2 of the draft-07 states: > > As described in Section 1.2 of SET [RFC8417], subjects *related to* > * security events* may take a variety of forms, including but not > limited to a JWT [RFC7519] principal, an IP address, a URL, etc. > > RFC 8417 (Security Event Token (SET)) states in its abstract: > > Abstract > > This specification defines the *Security Event Token (SET) data* > * structure*. A SET describes statements of fact from the perspective > of an issuer about a subject. These statements of fact represent an > event that occurred directly to or about a security subject, for > example, a statement about the issuance or revocation of a token on > behalf of a subject. This specification is intended to enable > representing security- and identity-related events. A SET is a JSON > Web Token (JWT), which can be optionally signed and/or encrypted. > SETs can be distributed via protocols such as HTTP. > > There is a need to be able to use subject identifiers that will not > necessarily be used in > a Security Event Token (SET) data structure. > > > These Subject Identifiers might still be used in a Security Event Token > (SET) data structure, *but not necessarilly*. > > - When supporting RBAC (Role Based Access Control), it would be nice > to define "sub_ids" able to support roles. > - When supporting ABAC (Attribute Bases Access Control), it would be > nice to define "sub_ids" able to support > group memberships with two flavours of them : (a) hierarchical groups > and (b) functional groups; > > The current title of the draft is: "Subject Identifiers for Security Even= t > Tokens" . > More appropriate titles would be: > > Subject Identifiers for Security Event Tokens *a**nd other purposes* > > or simply > > Subject Identifiers > > The first sentence of the abstract should also be slightly modified. > > Denis > > > Hi Tobias, > > Option 2's pros and cons are the consequence of solely relying only on an > opaque identifier managed by the AS, independantly from external > identifiers. > > That's an additional level of indirection, not unlike how indexes are > usually managed in a database. But there's obviously the additional > complexity of making a just in time translation into a practical identifi= er > (like email for account recovery, as discussed by Justin). > > "Assertions" should be what the AS (possibly with the assistance of other > parties) can confidently say about the subject. > > Thanks for the great feedback, as well as Justin's. Since the slides were > written, SECEVENT draft-07 already offers new possibilities which is good > news. > > Fabien > > Le mer. 10 mars 2021 =C3=A0 22:02, Tobias Looker > a =C3=A9crit : > >> > Thanks for the feedback, although I'm not sure what you mean by too >> abstract. >> >> Apologies what I mean by that was I feel like Option 2 would expose too >> much complexity to clients that would be required to construct a request= to >> the AS. Option 1 IMO strikes a better balance by still offering the >> required flexibility but keeping things relatively simple. >> >> > Just a quick comment: an assertion in option 2 is not "the fact the >> identifier is resolvable to cryptographic material that *can *be used to >> validate cryptographic assertions". It is merely a statement by the AS t= hat >> "the subject corresponding to the reference has a DID" ("has" is the >> assertion here). >> >> Yes I understand to drill down on this more though couldn't the entire >> request made by the client to the AS also be considered to be an asserti= on? >> Therefore the "sub_ids" request element is an assertion by the client ab= out >> who it believes the subject to be identified as? If this is true then to= me >> the "assertions" request element is there for assertions that parties ot= her >> than the client are making about the subject (e.g an id_token). >> >> Thanks, >> [image: Mattr website] >> *Tobias Looker* >> Mattr >> +64 (0) 27 378 0461 >> tobias.looker@mattr.global >> [image: Mattr website] [image: Mattr on LinkedIn] >> [image: Mattr on Twitter] >> [image: Mattr on Github] >> >> This communication, including any attachments, is confidential. If you >> are not the intended recipient, you should not read it - please contact = me >> immediately, destroy it, and do not copy or use any part of this >> communication or disclose anything about it. Thank you. Please note that >> this communication does not designate an information system for the >> purposes of the Electronic Transactions Act 2002. >> >> >> On Thu, Mar 11, 2021 at 9:20 AM Fabien Imbault >> wrote: >> >>> Thanks Justin. >>> >>> It's good to clarify what we mean by assertion. I used a more mundane >>> meaning. >>> >>> I dislike email/phone as security disasters waiting to happen. I get >>> that they are practical. >>> >>> I think I have what I need to write the PRs based on sub_ids (based on >>> the current draft-07). >>> >>> Fabien >>> >>> Le mer. 10 mars 2021 =C3=A0 20:18, Justin Richer a = =C3=A9crit : >>> >>>> Hi Fabien, >>>> >>>> First, thanks for doing the heavy lift of writing this topic up. Of >>>> these options, I would strongly prefer option (1). The difference betw= een >>>> assertions and identifiers is that an assertion is a fully packaged se= t of >>>> attributes, one of which can be an identifier. They are, generally >>>> speaking, cryptographically protected bundles. They=E2=80=99re designe= d to carry a >>>> bunch of different information about a user and the authentication eve= nt in >>>> a form that=E2=80=99s independently verifiable and auditable. SAML ass= ertions (XML >>>> document) and ID Tokens (signed JWTs) are the most common ones we see >>>> today, but other formats exist and will keep being invented. >>>> >>>> An identifier is a different kind of creature. It is a single statemen= t >>>> that identifies the party in question in the context of the party doin= g the >>>> identification. It=E2=80=99s this full context that the receiver of th= e identifier >>>> needs to interpret it in. When using a federated identity protocol, ea= ch RP >>>> is going to have :some: kind of local user information store that they= =E2=80=99re >>>> going to tie into, some field in a database they=E2=80=99ll key off of= . It=E2=80=99s just >>>> never going to be the case that all RPs will be able to use server-pro= vided >>>> opaque identifiers for all cases. Account recovery and binding is one = such >>>> use case where a user-facing identifier like an email address makes a = LOT >>>> of sense, for one small example. This is an array in the request and >>>> response precisely because a user could be known by several different >>>> identifiers to a party, and an RP will have a better idea about what k= inds >>>> of things it wants to correlate against, and it=E2=80=99s up to the AS= to provide >>>> that mapping. I think that if we don=E2=80=99t define a way to describ= e the format, >>>> the =E2=80=9Cas_id=E2=80=9D field is going to get structure back-patch= ed onto it like is >>>> being proposed here: >>>> >>>> https://mattrglobal.github.io/oidc-portable-identities/ >>>> >>>> I=E2=80=99m personally not a fan of that approach as it mixes the data= layering >>>> too much, and you end up making guesses about whether a field is meani= ngful >>>> or a pointer. I think GNAP will be much better served by using a data >>>> structure for this from the start. DIDs should be another =E2=80=9Cfor= mat=E2=80=9D of the >>>> subject identifier. I don=E2=80=99t think GNAP should define this form= at, and I=E2=80=99ve >>>> dropped a note to the SECEVENT mailing list asking about adding DIDs t= o the >>>> subject identifiers draft before it gets published. DIDs are not >>>> assertions, even in the cases where they point to fully functional DID >>>> documents with user information in them. (And for what it=E2=80=99s wo= rth, I think >>>> the OIDC world should also use the SECEVENT draft inside ID Tokens to = solve >>>> the use case of the draft above). >>>> >>>> For the user !=3D RO cases, I think that potentially having a way to >>>> signal those two items separately in the request and response could be >>>> useful. Right now all the user/subject stuff is about identifying =E2= =80=9Cthe user >>>> that=E2=80=99s currently here at the client instance=E2=80=9D, in a va= riety of forms that >>>> the client instance and AS can negotiate. If the client or AS has some >>>> other notion about who the RO is and how that could be separate from t= he >>>> current user, we could provide a way to signal that like you=E2=80=99r= e proposing >>>> below. In my mental model, there are going to be a lot of use cases wh= ere >>>> the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the client at all, but= rather to the AS and is >>>> based on what the client=E2=80=99s asking for. So I could identify the= current user >>>> and ask for a specific medical record, and the AS realizes it has to g= o bug >>>> a particular doctor to approve things directly. This is instead of >>>> interacting with the current user and failing in an awkward way when t= he >>>> current user doesn=E2=80=99t have the rights to do things, but someone= else would. >>>> But we=E2=80=99d want the system to be able to detect if the current u= ser is the >>>> doctor, so we can just interact with them directly. Does that all trac= k? >>>> >>>> =E2=80=94 Justin >>>> >>>> On Mar 10, 2021, at 4:10 AM, Fabien Imbault >>>> wrote: >>>> >>>> Hello, >>>> >>>> Notice the question mark in the title. Not to be considered as an >>>> editor's comment. >>>> This thread intends to provide a detailed comment on the >>>> interesting feedback by Kristina: "I would catch up on the thread to >>>> understand why DIDs are thought to be treated as assertions". >>>> In the chat, I answered: "Happy to get the discussion on DIDs. >>>> Actually, could be either or, depending on what we intend to do." Let = me >>>> expand a bit on that, to make it understandable (didn't have the time >>>> during the meeting, unfortunately). >>>> >>>> This relates to the items described on slides 20 and 34, which I'll >>>> explain further. I'll highlight as transparently as possible what I th= ink >>>> would be the benefits and downsides of each. Both are probably viable >>>> options, but they correspond to different scopes and objectives. I'll = spend >>>> a bit more time on option 2, since it is a different approach compared= to >>>> the current draft. >>>> >>>> *1. The first possibility is to use SECEVENT throughout. * >>>> In that case, DIDs should be a part of sub_ids (in the core or in the >>>> extension registry, depending on what Annabelle's WG decides). More >>>> generally, the WG would have to decide which additional sub_ids it nee= ds >>>> (as per Yaron's comment). >>>> >>>> That's obviously the closest to what is described in draft-04. It >>>> allows a communication of subject information between the client and t= he >>>> AS, by using global identifiers (mail, phone, etc.), or using a local >>>> opaque reference - i.e. governed by the AS (that's probably what we >>>> would put in the examples, unless someone has a better idea - cf issue= s #16 >>>> and #42). >>>> >>>> Assertions relate for instance to the proof of presence of the RO. The >>>> current draft-04 therefore plans for id_tokens and saml2, maybe there = could >>>> be other needs later (extension registry). >>>> >>>> - Benefits: identifiers are a key component of GNAP, which makes >>>> integration easier. Possibly one could choose to use DIDs throughout. >>>> - Downsides: email/phone identifiers will probably be used throughout >>>> by most devs (since that's correlation information they have in their = user >>>> DB). Which means we should limit what assertions contain, to avoid doi= ng >>>> links between weak global identifiers and hopefully stronger assertion= s. >>>> That's not really a problem if it's limited to authentication events m= ostly >>>> (in that perspective, samlv2 could make sense in the core). An asserti= on is >>>> probably a single value then (not an array). >>>> >>>> Option 1 can be summarized as: >>>> >>>> "subject": { >>>> "sub_ids": { }, // request and response (SECEVENT -> including DID >>>> possibly) >>>> "assertions": [ ], // request and response (id_token >>>> or samlv2) >>>> } >>>> ("hints" do not exist currently, but are partially covered separately >>>> via "request.user" / the relevance of "principal", discussed in the sl= ide, >>>> is a question mark too - which is a different discussion on end-user != =3D RO). >>>> >>>> >>>> *2. An alternate possibility is to use SECEVENT only as input/hint* >>>> In that case, DIDs should be a part of assertions (which have a >>>> different meaning compared to option 1). >>>> >>>> The AS only returns an local opaque reference as_ref (while in option >>>> 1, it was only one of many possibilities). Its only job is to help the >>>> client differentiate the response subject. The AS policy might further >>>> define the scope of that reference, as suggested in >>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210, >>>> although I personally viewed that by default as (2) "as_id" an identif= ier >>>> locally unique to that AS for all the RSs. >>>> >>>> SECEVENTS are still useful as an input, that's what I presented in >>>> request.hints.self.sub_ids (but it's the responsibility of the AS to m= atch >>>> it with its own reference system - from instance from the email to AS'= s >>>> local record XUT2MFM1XBIKJKSDU8Q). Note: since the slides, a new >>>> draft-ietf-secevent-subject-identifiers-07 has been published. Notably= this >>>> includes an opaque identifier, which the client can use to pass the as= _ref >>>> hint to the AS. Thus we wouldn't need any further addition to >>>> SECEVENT, although hints would benefit from further additions (like DI= Ds >>>> for instance). Notice also that subject_types_supported becomes less >>>> important, because in the worst case scenario, it's simply a hint that >>>> wouldn't be understood and therefore taken into account by the AS. >>>> >>>> The assertions array has a more important role than in option 1 (with >>>> the explicit aim of separating between client hints and validated info >>>> asserted by the AS). It serves as a generic/extendible mapping structu= re, >>>> e.g. "the AS asserts that opaque reference XUT2MFM1XBIKJKSDU8Q is >>>> matching with these (more or less verifiable) statements." The name >>>> assertion therefore corresponds to the responsibility of the AS in >>>> delivering those statements (cf should/must, issue #49). Some of these >>>> statements relate to identity or auth events (ex: DID, id_token), some >>>> might directly be useful for authorization decisions (like ZKP example= in >>>> the parental control example). Possibly some of these validated assert= ions >>>> could be reused in next interactions. >>>> >>>> Another question that popped-up is the scope of sub_ids. Should they b= e >>>> about the same user? (I think so). In the case of remote ROs especiall= y, it >>>> might be important that DID be considered as an assertion (about someo= ne >>>> else's) and not as sub_ids, because the AS needs to be careful about w= ho >>>> the client wants to reach (avoid spam, etc.). This is consistent with = the >>>> rest of discussion on what to do when end-user !=3D RO, although using >>>> DIDComm might seem a bit early (the paint is very fresh). >>>> >>>> Option 2 was summarized as: >>>> >>>> // (suggestion only, not as an editor) >>>> "subject": { >>>> "as_ref": { // response only (wouldn=E2=80=99t require SECEVENT) >>>> =E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D, >>>> =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D >>>> }, >>>> "assertions": [ ], // request and response >>>> (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validated by th= e AS) >>>> >>>> "hints": { // request only (optional) >>>> "self": { // replaces request.user (support SECEVENT here) >>>> =E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque in dr= aft-07 - that >>>> could contain the ref) >>>> =E2=80=9Cassertions=E2=80=9D: [ ] // see examples: VC on DOB or ZKP= on age (wider >>>> scope, possibly through extensions) >>>> }, >>>> "principal": { // new proposal presented at IETF110 (just an >>>> idea) >>>> =E2=80=9Cautomated=E2=80=9D: true, // rule engine >>>> =E2=80=9Casync=E2=80=9D: { } // remote ROs >>>> } >>>> } >>>> } >>>> >>>> - Benefits: as_ref is self supporting (no strong coupling with >>>> SECEVENT), but can still take SECEVENT as an input hint for the AS. It >>>> avoids the risk of making an official association between a weak globa= l >>>> identifier (e.g. email, used elsewhere) and hopefully stronger local >>>> assertions. GNAP would be fully agnostic to whatever identity system i= s >>>> used, only facilitating interoperability through assertions (second on= ly in >>>> importance compared to the AS opaque reference). Some assertions (poss= ibly >>>> extensions) could also be useful for the AS decision (e.g. VC or ZKP). >>>> - Downsides: opaqueness of as_ref is a feature, not a bug. The opaque >>>> reference is fully managed by the AS, therefore not inherently portabl= e (cf >>>> portability discussions in OIDC currently). There's no explicit bindin= g to >>>> an official identity, only a contextual mapping to AS validated assert= ions. >>>> It makes it more difficult to match the identifiers from one AS to ano= ther >>>> or to correlate with the client user DB (still possible via assertions= , if >>>> the AS allows it). Assertions are much more generic (possibly via >>>> extensions), but might require a more advanced mechanism to >>>> request/response only the most relevant information (which makes the A= S >>>> policy critical here). >>>> >>>> I hope that clarifies the reasoning for both options. Again I'm not >>>> saying option 2 is better, just saying the trade-offs are different (+ >>>> knowing that we need to keep it simple). >>>> - option 1 puts more in sub_ids and less in assertions >>>> - option 2 puts less in the reference and more in assertions >>>> All of this is open to discussion. More generally speaking, on every >>>> part in orange and question mark (?) I would love your ideas and >>>> criticisms. What I intended as an editor is only to highlight where th= e WG >>>> has important choices to make, before we can make the related PRs. >>>> >>>> A further side comment: IETF EAT RATS was suggested for assertions, bu= t >>>> relates more to the client attestations. It was added as a comment in >>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, which is >>>> a distinct topic we'll work on. >>>> >>>> Fabien (editor's hat off) >>>> >>>> -- >>>> 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 >>> >> >> This communication, including any attachments, is confidential. If you a= re not the intended recipient, you should not read it - please contact me i= mmediately, destroy it, and do not copy or use any part of this communicati= on or disclose anything about it. Thank you. Please note that this communic= ation does not designate an information system for the purposes of the Elec= tronic Transactions Act 2002. >> >> > > --000000000000248a0705bd475874 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Denis,=C2=A0

There's one big cha= nge in draft 07 : opaque identifiers.
That's basically what w= e discussed in=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues= /51

Fabien

On Thu, Mar 11, 2021 at 7:50 P= M Denis <denis.ietf@free.fr>= ; wrote:
=20 =20 =20
Hi Fabien,

Thank you for launching the discussion.

SECEVENT draft-07 does not really offer new possibilities over draft-06. The major change is simply=C2=A0 in the syntax naming.

The response to your question is not limited to an exclusive choice between option 1 and option 2. :-)

The definition of a subject identifier in draft-07 is :

3.=C2=A0 Subject Identifiers=20

=C2=A0=C2=A0 A Subject Identifier is a JSON [RFC7159] =
object whose contents may be
=C2=A0=C2=A0 used to identify a subject within some context.=
=C2=A0 An Identifier Format
=C2=A0=C2=A0 is a named definition of a set of information that may =
be used to
=C2=A0=C2=A0 identify a subject, and the rules for encoding that inf=
ormation as a
=C2=A0=C2=A0 Subject Identifier; they define the syntax and semantic=
s of Subject=20
   Identifiers.
With such a definition is it possible to request some types of subject identifiers to be placed into an access token,
to place subjects identifiers (with their values) into an access token and for a RS to compare these subjects identifiers
(with their values) against validation rules enacted by a RO acting as an ADF (Access Decision Function) which also use
the same subjects identifiers (with their values).

A DID is a persistent global unique identifier.

In issue #210=C2=A0 ("sub_id" claims #210) I already proposed the following examples for = globally unique identifiers (gu_id) :
(1) Fo= r a globally unique identifier:

"sub_id": {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = "format": "gu_id",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = "gu_id": " email",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = "email: "john= @hughes.com",
=C2=A0=C2=A0=C2=A0=C2=A0 }

or

"sub_id": {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = "format": "gu_id",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = "gu_id": "ssn",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = "ssn": {
=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=C2=A0=C2=A0=C2=A0=C2= =A0 "cn": "250"
=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=C2=A0=C2=A0=C2=A0=C2= =A0 "value": "160087404506527", =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=C2=A0=C2=A0 },
=C2=A0=C2=A0=C2=A0=C2=A0 }
In order to address DIDs, I would simply add the following example:

"sub_id&= quot;: {
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 "format": "gu_id",
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 "gu_id": " did",
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 "did: "did:DID:Method:DID Method Specific String",=
=C2=A0=C2=A0=C2= =A0=C2=A0 }
"sub_ids" claims are much better when compared to "sub" claims.

The definition of Subject Identifier in the draft-07 (section 3) is :
=C2=A0=C2=A0 = A Subject Identifier is a JSON [RFC7159] object whose contents may be
=C2=A0=C2=A0 used to id= entify a subject within some context.=C2=A0
However, page 2 = of the draft-07 states:
=C2=A0=C2=A0 As desc= ribed in Section 1.2 of SET [RFC8417], subjects related to
=C2=A0=C2=A0 security events may take a variety of= forms, including but not
=C2=A0=C2=A0 limited to a JWT [RFC7519] principal, an IP addr= ess, a URL, etc.
<= span lang=3D"EN-US">RFC 8417 (Security Event Token (SET)) states in its abstract:
Abstract

=C2=A0=C2=A0 This specification defines the Security Event Token (SET) data<= i>
=C2=A0=C2=A0 structure.=C2=A0 A SET describes statements of fact from the perspective
=C2=A0=C2=A0 of an issuer about a subject.=C2=A0 These statements of fact represent an
=C2=A0=C2=A0 event that occurred directly to or about a security subject, for=
=C2=A0=C2=A0 example, a statement about the issuance or revocation of a token on=
=C2=A0=C2=A0 behalf of a subject.=C2=A0 This specification is intended to enable<= /span>
=C2=A0=C2=A0 representing security- and identity-related events.=C2=A0 A SET is a JSON
=C2=A0=C2=A0 Web Token (JWT), which can be optionally signed and/or encrypted.<= /span>
=C2=A0=C2=A0 SETs can be distributed via protocols such as HTTP.

There is a need to be able to= use subject identifiers that will not necessarily be used in<= span lang=3D"EN-US">
a Security Event Token (SET) data structure= <= span lang=3D"EN-US">.
<= span lang=3D"EN-US">
<= span lang=3D"EN-US">These <= span lang=3D"EN-US">Subject Identifiers might still be used in = <= span lang=3D"EN-US">a Security Event Token (SET) data structure, but not necessarilly<= /span>.
  • = When supporting RBAC (Role Based Access Control), it would be nice to define "sub_ids" able to support roles.
  • = When supporting ABAC (Attribute Bases Access Control), it would be nice to define <= /span>"sub_ids" able to support
    group memberships with two flavours of them : (a) hierarchical     <= span lang=3D"EN-US">groups and (b) functional <= /span><= span lang=3D"EN-US"><= span lang=3D"EN-US">groups; <= /span>=
The current title of the draft is: "Subject Identifiers for Security Event Tokens" .
More appropriate titles would be:
Subject Identifiers for Security Event Tokens and other purposes
or simply
Subject Identifiers
The first sentence of the abstract should also be slightly modified.

Denis


=20
Hi Tobias,

Option 2's pros and cons are the consequence = of solely relying only on an opaque identifier managed by the AS, independantly from external identifiers.=C2=A0

That's an additional level of indirection, no= t unlike how indexes are usually managed in a database. But there's obviously the additional complexity of making a just in time translation into a practical identifier (like email for account recovery, as discussed by Justin).=C2=A0

"Asse= rtions" should be what=C2=A0the AS (possibly with the assistance of other parties) can confidently say about the subject.=C2=A0

Thanks for the great feedback, as well as Justin's.=C2=A0Since = the slides were written, SECEVENT draft-07 already offers new possibilities which is good news.=C2=A0

Fabien

Le mer. 10 mars 2021 =C3= =A0 22:02, Tobias Looker <tobias.looker@mattr.global> a =C3=A9crit=C2=A0:
> Thanks for the feedback, although I'= ;m not sure what you mean by too abstract.

Apologies what I mean by that was I feel like Option 2 would expose too much complexity to clients that would be required to construct a request to the AS. Option 1 IMO strikes a better balance by still offering the required flexibility but keeping things relatively simple.

> Just a quick comment: an assertion in option 2 is not "the fact the identifier is resolvable to cryptographic material that=C2=A0can=C2=A0be used = to validate cryptographic assertions". It is merely a statement by the AS that "the subject corresponding = to the reference has a DID" ("has" is the ass= ertion here).=C2=A0

Yes I understand to drill down on this more though couldn't the entire request made by the client to the AS also be considered to be an assertion? Therefore the=C2=A0"sub_ids" request element is an assert= ion by the client about who it believes the subject to be identified as? If this is true then to me the "assertions" request element is there for asser= tions that parties other than the client are making about the subject (e.g an id_token).

Thanks,
3D"Mattr =C2=A0
Tobias Looker
Ma= ttr
+64 (0) 27 378 0461
tobias.looker@mattr.global
3D"Mattr 3D"Mattr 3D"Mattr

This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.


On Thu, Mar 11, 2021 at 9:20 AM Fabien Imbault <fabien.imbault@gmail.= com> wrote:
Thanks Justin.

It's good to clarify what we mean= by assertion. I used a more mundane meaning.=C2=A0

I dislike email/phone as security disasters waiting to happen. I get that they are practical.=C2=A0

I think I have what I need to write the PRs based on sub_ids (based on the current draft-07).=C2=A0

Fabien=C2=A0

Le mer. 10 mars 2021 =C3=A0 20:18, Justin Richer <jricher@mit.edu> a =C3=A9crit=C2=A0:
Hi Fabien,

First, thanks for doing the heavy lift of writing this topic up. Of these options, I would strongly prefer option (1). The difference between assertions and identifiers is that an assertion is a fully packaged set of attributes, one of which can be an identifier. They are, generally speaking, cryptographically protected bundles. They=E2=80=99re designed to carry a bu= nch of different information about a user and the authentication event in a form that=E2=80= =99s independently verifiable and auditable. SAML assertions (XML document) and ID Tokens (signed JWTs) are the most common ones we see today, but other formats exist and will keep being invented.=C2=A0

An identifier is a different kind of creature. It is a single statement that identifies the party in question in the context of the party doing the identification. It=E2=80=99s this full context = that the receiver of the identifier needs to interpret it in. When using a federated identity protocol, each RP is going to have :some: kind of local user information store that they=E2=80=99re going to tie into, some fi= eld in a database they=E2=80=99ll key off of. It=E2= =80=99s just never going to be the case that all RPs will be able to use server-provided opaque identifiers for all cases. Account recovery and binding is one such use case where a user-facing identifier like an email address makes a LOT of sense, for one small example. This is an array in the request and response precisely because a user could be known by several different identifiers to a party, and an RP will have a better idea about what kinds of things it wants to correlate against, and it=E2=80=99s up to the AS to provi= de that mapping. I think that if we don=E2=80=99t define a way to describe the format, the =E2=80=9Cas_id=E2=80=9D field is going to get s= tructure back-patched onto it like is being proposed here:


I=E2=80=99m personally not a fan of that app= roach as it mixes the data layering too much, and you end up making guesses about whether a field is meaningful or a pointer. I think GNAP will be much better served by using a data structure for this from the start. DIDs should be another =E2=80=9Cformat=E2=80=9D of t= he subject identifier. I don=E2=80=99t think GNAP should d= efine this format, and I=E2=80=99ve dropped a note to= the SECEVENT mailing list asking about adding DIDs to the subject identifiers draft before it gets published. DIDs are not assertions, even in the cases where they point to fully functional DID documents with user information in them. (And for what it=E2=80=99s worth, I think the OIDC world should also use the SECEVENT draft inside ID Tokens to solve the use case of the draft above).

For the user !=3D RO cases, I think that potentially having a way to signal those two items separately in the request and response could be useful. Right now all the user/subject stuff is about identifying =E2=80= =9Cthe user that=E2=80=99s currently here at the clien= t instance=E2=80=9D, in a variety of forms that t= he client instance and AS can negotiate. If the client or AS has some other notion about who the RO is and how that could be separate from the current user, we could provide a way to signal that like you=E2=80=99re proposin= g below. In my mental model, there are going to be a lot of use cases where the =E2=80=9CRO= =E2=80=9D isn=E2=80=99t known to the client at all, but r= ather to the AS and is based on what the client=E2=80= =99s asking for. So I could identify the current user and ask for a specific medical record, and the AS realizes it has to go bug a particular doctor to approve things directly. This is instead of interacting with the current user and failing in an awkward way when the current user doesn=E2=80= =99t have the rights to do things, but someone else would. But we=E2=80=99d want the system to= be able to detect if the current user is the doctor, so we can just interact with them directly. Does that all track?

=C2=A0=E2=80=94 Justin

On Mar 10, 2021, at 4:10 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hello,

Notice the question mark in the title. Not to be considered as an editor's comment.
This thread intends to provide a detailed comment on the interesting=C2=A0feedback by Kristina= : "I would catch up on the thread = to understand why DIDs are thought to be treated as assertions".
In the chat, I answered: "Hap= py to get the discussion on DIDs. Actually, could be either or, depending on what we intend to do." Let me expand a bit on that= , to make it understandable (didn't have the time during the meeting, unfortunately).

This relates to the items described on slides 20 and 34, which I'll explain further. I'= ;ll highlight as transparently as possible what I think would be the benefits and downsides of each. Both are probably viable options, but they correspond to different scopes and objectives. I'll spend a bit more time on option 2, since it is a different approach compared to the current draft.

1. The first possibility is to use SECEVENT throughout.=C2=A0
In that case, DIDs should be a part of sub_ids (in the core or in the extension registry, depending on what Annabelle's WG decides). More generally, the WG would have to decide which additional sub_ids it needs (as per Yaron's comment)= .

That's obviously the closest t= o what is described in draft-04. It allows a communication of subject information between the client and the AS, by using global identifiers (mail, phone, etc.), or using a local opaque reference=C2=A0- i.e. governed by the AS (that's probably what we would=C2=A0put in the examples, unles= s someone has a better idea - cf issues #16 and #42).=C2=A0

Assertions relate for instance to the proof of presence of the RO. The current draft-04 therefore plans for id_tokens and saml2, maybe there could be other needs later (extension registry).

- Benefits: identifiers are a key component of GNAP, which makes integration easier. Possibly one could choose to use DIDs throughout.
- Downsides: email/phone identifiers will probably be used throughout by most devs (since that's correlation information they=C2=A0have in their user DB). Whi= ch means we should limit what assertions contain, to avoid doing links between weak global identifiers and hopefully stronger assertions. That's not really a problem if it's limited to authentication events mostly (in that perspective, samlv2 could make sense in the core). An assertion is probably a single value then (not an array).=C2=A0 =C2= =A0

Option 1 can be summarized as:=C2=A0

"subject": {
=C2=A0=C2=A0=C2=A0"sub_ids": { }= , = // request and response (SECEVENT -> includ= ing DID possibly)=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=C2=A0=C2=A0=C2= =A0=C2=A0
=C2=A0=C2=A0=C2=A0"assertions": = [ ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request and re= sponse (id_token or samlv2)
}
("hints" do not exist currently, but are partially covered separately via "request.user" / the relevance of "principal&qu= ot;, discussed in the slide, is a question mark too - which is a different discussion on end-user !=3D RO).


2. An alternate possibility is to use SECEVENT only as input/hint
In that case, DIDs should be a part of assertions (which have a different meaning compared to option 1).

The AS only returns an local opaque reference as_ref (while in option 1, it was only one of many possibilities). Its only job is to help the client differentiate the response subject. The AS policy might further define the scope of that reference, as suggested in=C2=A0= https= ://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210, although I personally=C2=A0viewed tha= t by default as=C2=A0(2) "as_id&qu= ot; an identifier locally unique to that AS for all the RSs.

SECEVENTS are still useful as an input, that's what I presented in request.hints.self.sub_ids (but it's the responsibility=C2=A0of t= he AS to match it with its own reference system - from instance from the email to AS's local record XUT2MFM1XBIKJKSDU8Q).=C2=A0Note: sinc= e the slides, a new draft-ietf-secevent-subject-identifie= rs-07 has been published. Notably this includes an opaque identifier, which the client can use to pass the as_ref hint to the AS. Thus we wouldn't need any further additio= n to SECEVENT,=C2=A0although hints woul= d benefit from further additions (like DIDs for instance). Notice also that subject_types_supported becomes less important, because in the worst case scenario, it's simply=C2=A0a hint that wouldn't = be understood and therefore taken into account by the AS.

The assertions array has a more important role than in option 1 (with the explicit aim of separating between client hints and validated info asserted by the AS). It serves as a generic/extendible mapping structure, e.g. "the AS asserts that opaque reference=C2=A0XUT2MFM1XBIKJKSDU8Q= =C2=A0is matching with these (more or less verifiable) statements." The nam= e assertion therefore corresponds to the responsibility=C2=A0of the AS in delivering those statements (cf should/must, issue #49). Some of these statements relate to identity or auth events (ex: DID, id_token), some might directly be useful for authorization decisions (like ZKP example in the parental control example). Possibly some of these validated assertions could be reused in next interactions.

Another question that popped-up is the scope of sub_ids. Should they be about the same user? (I think so). In the case of remote ROs especially, it might be important that DID be considered as an assertion=C2=A0(about someone else's) and not as sub_ids, because the AS needs to be careful about who the client wants to reach (avoid spam, etc.). This is consistent with the rest of discussion on what to do when end-user !=3D RO, although using DIDComm might seem a bit early (the paint is very fresh).=C2=A0

Option 2 was summarized as:=C2=A0<= /div>

// (suggestion only, not as = an editor)
"subject": {
=C2=A0=C2=A0=C2=A0"as_ref": { // response = only (wouldn=E2=80=99t require SECEVENT)
=E2=80=9Cas=E2=80=9D: =E2= =80=9Chttps://ex1.as.com=E2=80=9D= , =
=E2=80=9Cref=E2=80=9D: =E2= =80=9CXU= T2MFM1XBIKJKSDU8QM=E2=80=9D=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=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"assertions": [ = ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request and resp= onse (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validated by= the AS)
=C2=A0=C2=A0=C2=A0"hints": { =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = // request only (optional)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"se= lf": { // replaces request.user (support SECEVENT here)
=C2=A0=C2=A0=C2=A0=E2=80= =9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque in draft-07 - that could cont= ain the ref)
=C2=A0=C2=A0=C2=A0=E2=80=9C= assertions=E2=80=9D: [ ] // see examples: VC on DOB or ZKP on ag= e (wider scope, possibly through extensions)
},=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=C2=A0=C2= =A0=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"pr= incipal": { // new proposal presented at IE= TF110 (just an idea)
=C2=A0= =E2=80=9Cautomated=E2=80=9D: true, // rule engine
=C2=A0= =E2=80=9Casync=E2=80=9D: { } // remote ROs
}=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<= /div>
=C2=A0=C2=A0=C2=A0}
}

- Benefits: as_ref is self supporting (no strong coupling with SECEVENT), but can still take SECEVENT as an input hint for the AS. It avoids the risk of making an official association between a weak global identifier (e.g. email, used elsewhere) and hopefully stronger local assertions. GNAP would be fully agnostic to whatever identity system is used, only facilitating interoperability through assertions (second only in importance=C2=A0compared to the AS opaque reference). Some assertions (possibly extensions) could also be useful for the AS decision (e.g. VC or ZKP).
- Downsides: opaqueness of as_ref is a feature, not a bug. The opaque reference is fully managed by the AS, therefore not inherently portable (cf portability discussions in OIDC currently). There's no explicit binding to an official identity, only a contextual mapping to AS validated assertions. It makes it more difficult to match the identifiers from one AS to another or to correlate with the client user DB (still possible via assertions, if the AS allows it). Assertions are much more generic (possibly via extensions), but might require a more advanced mechanism=C2=A0to request/response on= ly the most relevant information (which makes the AS policy critical here).

I hope that clarifies the=C2=A0reasoning for both options. Again I'm not saying option 2 is better, just saying the trade-offs are different (+ knowing that we need to keep it simple).
- option 1 puts more in sub_ids and less in assertions
- option 2 puts less in the reference and more in assertions=C2= =A0
All of this is open to discussion. More generally speaking, on every part in orange and question mark (?) I would love your ideas and criticisms. What I intended as an editor is only to highlight where the WG has important choices to make, before we can make the related PRs.

A further side comment: IETF EAT RATS was suggested for assertions, but relates more to the client attestations. It was added as a comment in=C2=A0https= ://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, which is a distinct topic we'll work on.

Fabien (editor's hat off)

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


--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailma= n/listinfo/txauth

This communication, in=
cluding any attachments, is confidential. If you are not the intended recip=
ient, you should not read it - please contact me immediately, destroy it, a=
nd do not copy or use any part of this communication or disclose anything a=
bout it. Thank you. Please note that this communication does not designate =
an information system for the purposes of the Electronic Transactions Act 2=
002.


--000000000000248a0705bd475874-- From nobody Thu Mar 11 11:58:40 2021 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 71E983A109F for ; Thu, 11 Mar 2021 11:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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 rCBJkqQ2I3Pd for ; Thu, 11 Mar 2021 11:58:35 -0800 (PST) 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 053853A109C for ; Thu, 11 Mar 2021 11:58:33 -0800 (PST) Received: from [192.168.1.22] (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 12BJwQ7v026721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Mar 2021 14:58:27 -0500 From: Justin Richer Message-Id: <7C3854AD-0EC1-4A21-A9F1-BE8004E5AA89@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_B4184C83-F7C4-4A7D-9DAE-DFD1FFE07C43" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 11 Mar 2021 14:58:26 -0500 In-Reply-To: <67a11cda-a06a-4e03-0d99-05cf6ab14474@free.fr> Cc: Fabien Imbault , GNAP Mailing List , Tobias Looker To: Denis References: <67a11cda-a06a-4e03-0d99-05cf6ab14474@free.fr> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 19:58:38 -0000 --Apple-Mail=_B4184C83-F7C4-4A7D-9DAE-DFD1FFE07C43 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Denis, Many of your comments here would be best addressed to the SECEVENT = working group as feedback on the subject identifiers draft. There is new = text in -07 that helps establish this as useful outside of SET/JWT, and = I would guess the author would be amenable to clarifying that further. =E2=80=94 Justin > On Mar 11, 2021, at 1:50 PM, Denis wrote: >=20 > Hi Fabien, >=20 > Thank you for launching the discussion.=20 >=20 > SECEVENT draft-07 does not really offer new possibilities over = draft-06. The major change is simply in the syntax naming. >=20 > The response to your question is not limited to an exclusive choice = between option 1 and option 2. :-) >=20 > The definition of a subject identifier in draft-07 is : >=20 > 3. Subject Identifiers=20 > A Subject Identifier is a JSON [RFC7159] object whose contents may = be > used to identify a subject within some context. An Identifier = Format > is a named definition of a set of information that may be used to > identify a subject, and the rules for encoding that information as = a > Subject Identifier; they define the syntax and semantics of Subject=20= > Identifiers. > With such a definition is it possible to request some types of subject = identifiers to be placed into an access token,=20 > to place subjects identifiers (with their values) into an access token = and for a RS to compare these subjects identifiers=20 > (with their values) against validation rules enacted by a RO acting as = an ADF (Access Decision Function) which also use > the same subjects identifiers (with their values). >=20 > A DID is a persistent global unique identifier.=20 >=20 > In issue #210 ("sub_id" claims #210) I already proposed the following = examples for globally unique identifiers (gu_id) : > (1) For a globally unique identifier: >=20 > "sub_id": { > "format": "gu_id", > "gu_id": " email", > "email: "john@hughes.com" , > } >=20 > or >=20 > "sub_id": { > "format": "gu_id", > "gu_id": "ssn", > "ssn": {=20 > "cn": "250" > "value": "160087404506527", > }, > } > In order to address DIDs, I would simply add the following example: >=20 > "sub_id": { > "format": "gu_id", > "gu_id": " did", > "did: "did:DID:Method:DID Method Specific String", > } > "sub_ids" claims are much better when compared to "sub" claims. >=20 > The definition of Subject Identifier in the draft-07 (section 3) is :=20= > A Subject Identifier is a JSON [RFC7159] object whose contents may = be > used to identify a subject within some context. =20 > However, page 2 of the draft-07 states: > As described in Section 1.2 of SET [RFC8417], subjects related to > security events may take a variety of forms, including but not > limited to a JWT [RFC7519] principal, an IP address, a URL, etc. > RFC 8417 (Security Event Token (SET)) states in its abstract: > Abstract >=20 > This specification defines the Security Event Token (SET) data > structure. A SET describes statements of fact from the perspective > of an issuer about a subject. These statements of fact represent = an > event that occurred directly to or about a security subject, for > example, a statement about the issuance or revocation of a token on > behalf of a subject. This specification is intended to enable > representing security- and identity-related events. A SET is a = JSON > Web Token (JWT), which can be optionally signed and/or encrypted. > SETs can be distributed via protocols such as HTTP. >=20 > There is a need to be able to use subject identifiers that will not = necessarily be used in > a Security Event Token (SET) data structure. >=20 > These Subject Identifiers might still be used in a Security Event = Token (SET) data structure, but not necessarilly. > When supporting RBAC (Role Based Access Control), it would be nice to = define "sub_ids" able to support roles. > When supporting ABAC (Attribute Bases Access Control), it would be = nice to define "sub_ids" able to support > group memberships with two flavours of them : (a) hierarchical groups = and (b) functional groups; > The current title of the draft is: "Subject Identifiers for Security = Event Tokens" . > More appropriate titles would be: > Subject Identifiers for Security Event Tokens and other purposes > or simply > Subject Identifiers > The first sentence of the abstract should also be slightly modified. >=20 > Denis >=20 >=20 >> Hi Tobias, >>=20 >> Option 2's pros and cons are the consequence of solely relying only = on an opaque identifier managed by the AS, independantly from external = identifiers.=20 >>=20 >> That's an additional level of indirection, not unlike how indexes are = usually managed in a database. But there's obviously the additional = complexity of making a just in time translation into a practical = identifier (like email for account recovery, as discussed by Justin).=20 >>=20 >> "Assertions" should be what the AS (possibly with the assistance of = other parties) can confidently say about the subject.=20 >>=20 >> Thanks for the great feedback, as well as Justin's. Since the slides = were written, SECEVENT draft-07 already offers new possibilities which = is good news.=20 >>=20 >> Fabien >>=20 >> Le mer. 10 mars 2021 =C3=A0 22:02, Tobias Looker = a = =C3=A9crit : >> > Thanks for the feedback, although I'm not sure what you mean by too = abstract. >>=20 >> Apologies what I mean by that was I feel like Option 2 would expose = too much complexity to clients that would be required to construct a = request to the AS. Option 1 IMO strikes a better balance by still = offering the required flexibility but keeping things relatively simple. >>=20 >> > Just a quick comment: an assertion in option 2 is not "the fact the = identifier is resolvable to cryptographic material that can be used to = validate cryptographic assertions". It is merely a statement by the AS = that "the subject corresponding to the reference has a DID" ("has" is = the assertion here).=20 >>=20 >> Yes I understand to drill down on this more though couldn't the = entire request made by the client to the AS also be considered to be an = assertion? Therefore the "sub_ids" request element is an assertion by = the client about who it believes the subject to be identified as? If = this is true then to me the "assertions" request element is there for = assertions that parties other than the client are making about the = subject (e.g an id_token). >>=20 >> Thanks, >> =09 >> Tobias Looker >> Mattr >> +64 (0) 27 378 0461 >> tobias.looker@mattr.global >> = = = >> This communication, including any attachments, is confidential. If = you are not the intended recipient, you should not read it - please = contact me immediately, destroy it, and do not copy or use any part of = this communication or disclose anything about it. Thank you. Please note = that this communication does not designate an information system for the = purposes of the Electronic Transactions Act 2002. >>=20 >>=20 >> On Thu, Mar 11, 2021 at 9:20 AM Fabien Imbault = > wrote: >> Thanks Justin. >>=20 >> It's good to clarify what we mean by assertion. I used a more mundane = meaning.=20 >>=20 >> I dislike email/phone as security disasters waiting to happen. I get = that they are practical.=20 >>=20 >> I think I have what I need to write the PRs based on sub_ids (based = on the current draft-07).=20 >>=20 >> Fabien=20 >>=20 >> Le mer. 10 mars 2021 =C3=A0 20:18, Justin Richer > a =C3=A9crit : >> Hi Fabien, >>=20 >> First, thanks for doing the heavy lift of writing this topic up. Of = these options, I would strongly prefer option (1). The difference = between assertions and identifiers is that an assertion is a fully = packaged set of attributes, one of which can be an identifier. They are, = generally speaking, cryptographically protected bundles. They=E2=80=99re = designed to carry a bunch of different information about a user and the = authentication event in a form that=E2=80=99s independently verifiable = and auditable. SAML assertions (XML document) and ID Tokens (signed = JWTs) are the most common ones we see today, but other formats exist and = will keep being invented.=20 >>=20 >> An identifier is a different kind of creature. It is a single = statement that identifies the party in question in the context of the = party doing the identification. It=E2=80=99s this full context that the = receiver of the identifier needs to interpret it in. When using a = federated identity protocol, each RP is going to have :some: kind of = local user information store that they=E2=80=99re going to tie into, = some field in a database they=E2=80=99ll key off of. It=E2=80=99s just = never going to be the case that all RPs will be able to use = server-provided opaque identifiers for all cases. Account recovery and = binding is one such use case where a user-facing identifier like an = email address makes a LOT of sense, for one small example. This is an = array in the request and response precisely because a user could be = known by several different identifiers to a party, and an RP will have a = better idea about what kinds of things it wants to correlate against, = and it=E2=80=99s up to the AS to provide that mapping. I think that if = we don=E2=80=99t define a way to describe the format, the =E2=80=9Cas_id=E2= =80=9D field is going to get structure back-patched onto it like is = being proposed here: >>=20 >> https://mattrglobal.github.io/oidc-portable-identities/ = >>=20 >> I=E2=80=99m personally not a fan of that approach as it mixes the = data layering too much, and you end up making guesses about whether a = field is meaningful or a pointer. I think GNAP will be much better = served by using a data structure for this from the start. DIDs should be = another =E2=80=9Cformat=E2=80=9D of the subject identifier. I don=E2=80=99= t think GNAP should define this format, and I=E2=80=99ve dropped a note = to the SECEVENT mailing list asking about adding DIDs to the subject = identifiers draft before it gets published. DIDs are not assertions, = even in the cases where they point to fully functional DID documents = with user information in them. (And for what it=E2=80=99s worth, I think = the OIDC world should also use the SECEVENT draft inside ID Tokens to = solve the use case of the draft above). >>=20 >> For the user !=3D RO cases, I think that potentially having a way to = signal those two items separately in the request and response could be = useful. Right now all the user/subject stuff is about identifying =E2=80=9C= the user that=E2=80=99s currently here at the client instance=E2=80=9D, = in a variety of forms that the client instance and AS can negotiate. If = the client or AS has some other notion about who the RO is and how that = could be separate from the current user, we could provide a way to = signal that like you=E2=80=99re proposing below. In my mental model, = there are going to be a lot of use cases where the =E2=80=9CRO=E2=80=9D = isn=E2=80=99t known to the client at all, but rather to the AS and is = based on what the client=E2=80=99s asking for. So I could identify the = current user and ask for a specific medical record, and the AS realizes = it has to go bug a particular doctor to approve things directly. This is = instead of interacting with the current user and failing in an awkward = way when the current user doesn=E2=80=99t have the rights to do things, = but someone else would. But we=E2=80=99d want the system to be able to = detect if the current user is the doctor, so we can just interact with = them directly. Does that all track? >>=20 >> =E2=80=94 Justin >>=20 >>> On Mar 10, 2021, at 4:10 AM, Fabien Imbault = > wrote: >>>=20 >>> Hello, >>>=20 >>> Notice the question mark in the title. Not to be considered as an = editor's comment. >>> This thread intends to provide a detailed comment on the interesting = feedback by Kristina: "I would catch up on the thread to understand why = DIDs are thought to be treated as assertions". >>> In the chat, I answered: "Happy to get the discussion on DIDs. = Actually, could be either or, depending on what we intend to do." Let me = expand a bit on that, to make it understandable (didn't have the time = during the meeting, unfortunately). >>>=20 >>> This relates to the items described on slides 20 and 34, which I'll = explain further. I'll highlight as transparently as possible what I = think would be the benefits and downsides of each. Both are probably = viable options, but they correspond to different scopes and objectives. = I'll spend a bit more time on option 2, since it is a different approach = compared to the current draft. >>>=20 >>> 1. The first possibility is to use SECEVENT throughout.=20 >>> In that case, DIDs should be a part of sub_ids (in the core or in = the extension registry, depending on what Annabelle's WG decides). More = generally, the WG would have to decide which additional sub_ids it needs = (as per Yaron's comment). >>>=20 >>> That's obviously the closest to what is described in draft-04. It = allows a communication of subject information between the client and the = AS, by using global identifiers (mail, phone, etc.), or using a local = opaque reference - i.e. governed by the AS (that's probably what we = would put in the examples, unless someone has a better idea - cf issues = #16 and #42).=20 >>>=20 >>> Assertions relate for instance to the proof of presence of the RO. = The current draft-04 therefore plans for id_tokens and saml2, maybe = there could be other needs later (extension registry). >>>=20 >>> - Benefits: identifiers are a key component of GNAP, which makes = integration easier. Possibly one could choose to use DIDs throughout. >>> - Downsides: email/phone identifiers will probably be used = throughout by most devs (since that's correlation information they have = in their user DB). Which means we should limit what assertions contain, = to avoid doing links between weak global identifiers and hopefully = stronger assertions. That's not really a problem if it's limited to = authentication events mostly (in that perspective, samlv2 could make = sense in the core). An assertion is probably a single value then (not an = array). =20 >>>=20 >>> Option 1 can be summarized as:=20 >>>=20 >>> "subject": { >>> "sub_ids": { }, // request and response = (SECEVENT -> including DID possibly) =20 >>> "assertions": [ ], // request and response = (id_token or samlv2) >>> } >>> ("hints" do not exist currently, but are partially covered = separately via "request.user" / the relevance of "principal", discussed = in the slide, is a question mark too - which is a different discussion = on end-user !=3D RO). >>>=20 >>>=20 >>> 2. An alternate possibility is to use SECEVENT only as input/hint >>> In that case, DIDs should be a part of assertions (which have a = different meaning compared to option 1). >>>=20 >>> The AS only returns an local opaque reference as_ref (while in = option 1, it was only one of many possibilities). Its only job is to = help the client differentiate the response subject. The AS policy might = further define the scope of that reference, as suggested in = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210 = , = although I personally viewed that by default as (2) "as_id" an = identifier locally unique to that AS for all the RSs. >>>=20 >>> SECEVENTS are still useful as an input, that's what I presented in = request.hints.self.sub_ids (but it's the responsibility of the AS to = match it with its own reference system - from instance from the email to = AS's local record XUT2MFM1XBIKJKSDU8Q). Note: since the slides, a new = draft-ietf-secevent-subject-identifiers-07 has been published. Notably = this includes an opaque identifier, which the client can use to pass the = as_ref hint to the AS. Thus we wouldn't need any further addition to = SECEVENT, although hints would benefit from further additions (like DIDs = for instance). Notice also that subject_types_supported becomes less = important, because in the worst case scenario, it's simply a hint that = wouldn't be understood and therefore taken into account by the AS. >>>=20 >>> The assertions array has a more important role than in option 1 = (with the explicit aim of separating between client hints and validated = info asserted by the AS). It serves as a generic/extendible mapping = structure, e.g. "the AS asserts that opaque reference = XUT2MFM1XBIKJKSDU8Q is matching with these (more or less verifiable) = statements." The name assertion therefore corresponds to the = responsibility of the AS in delivering those statements (cf should/must, = issue #49). Some of these statements relate to identity or auth events = (ex: DID, id_token), some might directly be useful for authorization = decisions (like ZKP example in the parental control example). Possibly = some of these validated assertions could be reused in next interactions. >>>=20 >>> Another question that popped-up is the scope of sub_ids. Should they = be about the same user? (I think so). In the case of remote ROs = especially, it might be important that DID be considered as an assertion = (about someone else's) and not as sub_ids, because the AS needs to be = careful about who the client wants to reach (avoid spam, etc.). This is = consistent with the rest of discussion on what to do when end-user !=3D = RO, although using DIDComm might seem a bit early (the paint is very = fresh).=20 >>>=20 >>> Option 2 was summarized as:=20 >>>=20 >>> // (suggestion only, not as an editor) >>> "subject": { >>> "as_ref": { // response only = (wouldn=E2=80=99t require SECEVENT) >>> =E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com = =E2=80=9D, =09 >>> =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D =20 >>> }, =20 >>> "assertions": [ ], // request and response = (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validated by the = AS) >>>=20 >>> "hints": { // request only (optional) >>> "self": { // replaces request.user = (support SECEVENT here) >>> =E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including = opaque in draft-07 - that could contain the ref) >>> =E2=80=9Cassertions=E2=80=9D: [ ] // see examples: VC = on DOB or ZKP on age (wider scope, possibly through extensions) =20 >>> }, =20 >>> "principal": { // new proposal = presented at IETF110 (just an idea) >>> =E2=80=9Cautomated=E2=80=9D: true, // rule engine =09= >>> =E2=80=9Casync=E2=80=9D: { } // remote ROs >>> } =20 >>> } >>> } >>>=20 >>> - Benefits: as_ref is self supporting (no strong coupling with = SECEVENT), but can still take SECEVENT as an input hint for the AS. It = avoids the risk of making an official association between a weak global = identifier (e.g. email, used elsewhere) and hopefully stronger local = assertions. GNAP would be fully agnostic to whatever identity system is = used, only facilitating interoperability through = assertions (second only in importance compared to the AS = opaque reference). Some assertions (possibly extensions) could also be = useful for the AS decision (e.g. VC or ZKP). >>> - Downsides: opaqueness of as_ref is a feature, not a bug. The = opaque reference is fully managed by the AS, therefore not inherently = portable (cf portability discussions in OIDC currently). There's no = explicit binding to an official identity, only a contextual mapping to = AS validated assertions. It makes it more difficult to match the = identifiers from one AS to another or to correlate with the client user = DB (still possible via assertions, if the AS allows it). Assertions are = much more generic (possibly via extensions), but might require a more = advanced mechanism to request/response only the most relevant = information (which makes the AS policy critical here). >>>=20 >>> I hope that clarifies the reasoning for both options. Again I'm not = saying option 2 is better, just saying the trade-offs are different (+ = knowing that we need to keep it simple). >>> - option 1 puts more in sub_ids and less in assertions >>> - option 2 puts less in the reference and more in assertions=20 >>> All of this is open to discussion. More generally speaking, on every = part in orange and question mark (?) I would love your ideas and = criticisms. What I intended as an editor is only to highlight where the = WG has important choices to make, before we can make the related PRs. >>>=20 >>> A further side comment: IETF EAT RATS was suggested for assertions, = but relates more to the client attestations. It was added as a comment = in https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44 = , which is = a distinct topic we'll work on. >>>=20 >>> Fabien (editor's hat off) >>>=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 = >>=20 >> This communication, including any attachments, is confidential. If = you are not the intended recipient, you should not read it - please = contact me immediately, destroy it, and do not copy or use any part of = this communication or disclose anything about it. Thank you. Please note = that this communication does not designate an information system for the = purposes of the Electronic Transactions Act 2002. >>=20 >>=20 >=20 --Apple-Mail=_B4184C83-F7C4-4A7D-9DAE-DFD1FFE07C43 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Denis,

Many= of your comments here would be best addressed to the SECEVENT working = group as feedback on the subject identifiers draft. There is new text in = -07 that helps establish this as useful outside of SET/JWT, and I would = guess the author would be amenable to clarifying that further.

 =E2=80=94 = Justin

On Mar 11, 2021, at 1:50 PM, Denis <denis.ietf@free.fr> = wrote:

=20
Hi Fabien,

Thank you for launching the discussion.

SECEVENT draft-07 does not really offer new possibilities over draft-06. The major change is simply  in the syntax naming.

The response to your question is = not limited to an exclusive choice between option 1 and option 2. :-)

The definition of a subject identifier in draft-07 is :

3.  Subject Identifiers=20

   A Subject Identifier is a JSON [RFC7159] =
object whose contents may be
   used to identify a subject within some context.  An Identifier =
Format
   is a named definition of a set of information that =
may be used to
   identify a subject, and the rules for encoding that =
information as a
   Subject Identifier; they define the syntax and =
semantics of Subject=20
   Identifiers.
With such a definition is it = possible to request some types of = subject identifiers to be placed into an access token,
to place subjects identifiers (with their values) into an access token and for a RS to compare these subjects identifiers
(with their values) against validation rules enacted by a RO acting as an ADF (Access Decision Function) which also use
the same subjects identifiers (with their values).

A DID is a persistent global unique identifier.

In issue #210  ("sub_id" = claims #210) I already proposed the following examples for globally unique = identifiers (gu_id) :
(1) For a globally unique = identifier:

"sub_id": {
       "format": "gu_id",
       "gu_id": " email",
       "email: "john@hughes.com",
     }

or

"sub_id": {
       "format": "gu_id",
       "gu_id": "ssn",
       "ssn": {
          &nb= sp;         "cn": "250"
          &nb= sp;         "value": "160087404506527",
          &nb= sp;       },
     }
In order to address DIDs, I would simply add the following example:

"sub_id": {
       "format": "gu_id",
       "gu_id": " did",
       "did: "did:DID:Method:DID Method Specific = String",
     }
"sub_ids" claims are much better when compared to "sub" claims.

The definition of Subject Identifier in = the draft-07 (section 3) is :
   A Subject Identifier is a JSON = [RFC7159] object whose contents may be
   used to identify a subject within some context. 
However, page 2 of the draft-07 states:
   As described in Section 1.2 of = SET [RFC8417], subjects related to
   security events may = take a variety of forms, including but not
   limited to a JWT [RFC7519] principal, an IP = address, a URL, etc.
RFC 8417 (Security Event Token (SET)) = states in its abstract:
Abstract

   This specification defines the Security Event Token (SET) = data
   = structure.  A SET describes statements of fact from the = perspective
   of an issuer about a = subject.  These statements of fact represent = an
   event that occurred directly to = or about a security subject, = for
   example, a statement about the issuance or revocation of a token = on
   behalf of a subject.  This specification is intended to = enable
   representing security- and identity-related events.  A SET is a = JSON
   Web Token (JWT), which can be optionally signed and/or = encrypted.
   SETs can be distributed via = protocols such as HTTP.
=

There is a need to be able to use subject identifiers that will not necessarily be used in
a Security Event Token (SET) data = structure.

=
These = Subject Identifiers might still be used in = <= /span>a Security Event Token (SET) data = structure, but = not = necessarilly.
=
  • When supporting RBAC (Role Based Access Control), it would be nice to define = "sub_ids" able to support = roles.
    • =
  • When supporting ABAC (Attribute Bases Access Control), = it would be nice to define = "sub_ids" able to support
    = group memberships with two flavours of them : (a) hierarchical =     groups and (b) functional = <= /span>groups; = <= /span>
The current title of the draft is: = "Subject Identifiers for Security Event Tokens" .
More appropriate titles would be:
Subject = Identifiers for Security Event Tokens and other = purposes
or simply
Subject = Identifiers
The first sentence of the abstract = should also be slightly modified.

Denis


=20
Hi Tobias,

Option 2's pros and cons are the = consequence of solely relying only on an opaque identifier managed by the AS, independantly from external identifiers. 

That's an additional level of = indirection, not unlike how indexes are usually managed in a database. But there's obviously the additional complexity of making a just in time translation into a practical identifier (like email for account recovery, as discussed by Justin). 

"Assertions" should be what the AS (possibly with the = assistance of other parties) can confidently say about the = subject. 

Thanks for the great feedback, as well as Justin's. Since = the slides were written, SECEVENT draft-07 already offers new possibilities which is good news. 

Fabien

Le mer. 10 mars 2021 = =C3=A0 22:02, Tobias Looker <tobias.looker@mattr.global&= gt; a =C3=A9crit :
> Thanks for the feedback, = although I'm not sure what you mean by too abstract.

Apologies what I mean by that was I feel = like Option 2 would expose too much complexity to clients that would be required to construct a request to the AS. Option 1 IMO strikes a better balance by still offering the required flexibility but keeping things relatively simple.

> Just a quick comment: an assertion = in option 2 is not "the fact the identifier is resolvable to cryptographic material that can be used to validate cryptographic assertions". It is merely a statement by the AS that "the subject corresponding to the reference has a DID" ("has" is the assertion here). 

Yes I understand to drill down on this = more though couldn't the entire request made by the client to the AS also be considered to be an assertion? Therefore the "sub_ids" request element is an assertion by = the client about who it believes the subject to be identified as? If this is true then to me the "assertions" request element is there for assertions that parties other than the client are making about the subject (e.g an id_token).

Thanks,
3D"Mattr  
Tobias Looker
Mattr
+64 (0) 27 378 0461
= tobias.looker@mattr.global
3D"Mattr 3D"Mattr 3D"Mattr 3D"Mattr

This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act = 2002.


On Thu, Mar 11, = 2021 at 9:20 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Thanks Justin.

It's good to clarify = what we mean by assertion. I used a more mundane = meaning. 

I dislike email/phone = as security disasters waiting to happen. I get that they are practical. 

I think I have what I = need to write the PRs based on sub_ids (based on the current draft-07). 

Fabien 

Le mer. 10 = mars 2021 =C3=A0 20:18, Justin Richer <jricher@mit.edu> a =C3=A9crit :
Hi Fabien,

First, thanks for doing the = heavy lift of writing this topic up. Of these options, I would strongly prefer option (1). The difference between assertions and identifiers is that an assertion is a fully packaged set of attributes, one of which can be an identifier. They are, generally speaking, cryptographically protected bundles. They=E2=80=99re designed to carry a = bunch of different information about a user and the authentication event in a form that=E2=80=99= s independently verifiable and auditable. SAML assertions (XML document) and ID Tokens (signed JWTs) are the most common ones we see today, but other formats exist and will keep being invented. 

An identifier is a different = kind of creature. It is a single statement that identifies the party in question in the context of the party doing the identification. It=E2=80=99s this full = context that the receiver of the identifier needs to interpret it in. When using a federated identity protocol, each RP is going to have :some: kind of local user information store that they=E2=80=99re going to tie into, some = field in a database they=E2=80=99ll key off of. = It=E2=80=99s just never going to be the case that all RPs will be able to use server-provided opaque identifiers for all cases. Account recovery and binding is one such use case where a user-facing identifier like an email address makes a LOT of sense, for one small example. This is an array in the request and response precisely because a user could be known by several different identifiers to a party, and an RP will have a better idea about what kinds of things it wants to correlate against, and it=E2=80=99s up to the AS to = provide that mapping. I think that if we don=E2=80=99t= define a way to describe the format, the =E2=80=9Cas_id=E2=80=9D field is going to = get structure back-patched onto it like is being proposed here:

https://mattrglobal.github.io/oidc-portable-identities/

I=E2=80=99m personally not a = fan of that approach as it mixes the data layering too much, and you end up making guesses about whether a field is meaningful or a pointer. I think GNAP will be much better served by using a data structure for this from the start. DIDs should be another =E2=80=9Cformat=E2=80=9D = of the subject identifier. I don=E2=80=99t think GNAP = should define this format, and I=E2=80=99ve dropped a note = to the SECEVENT mailing list asking about adding DIDs to the subject identifiers draft before it gets published. DIDs are not assertions, even in the cases where they point to fully functional DID documents with user information in them. (And for what it=E2=80=99= s worth, I think the OIDC world should also use the SECEVENT draft inside ID Tokens to solve the use case of the draft = above).

For the user !=3D RO cases, I = think that potentially having a way to signal those two items separately in the request and response could be useful. Right now all the user/subject stuff is about identifying = =E2=80=9Cthe user that=E2=80=99s currently here at the = client instance=E2=80=9D, in a variety of forms = that the client instance and AS can negotiate. If the client or AS has some other notion about who the RO is and how that could be separate from the current user, we could provide a way to signal that like you=E2=80=99re = proposing below. In my mental model, there are going to be a lot of use cases where the =E2=80=9CRO= =E2=80=9D isn=E2=80=99t known to the client at all, = but rather to the AS and is based on what the = client=E2=80=99s asking for. So I could identify the current user and ask for a specific medical record, and the AS realizes it has to go bug a particular doctor to approve things directly. This is instead of interacting with the current user and failing in an awkward way when the current user doesn=E2=80=99= t have the rights to do things, but someone else would. But we=E2=80=99d want the system = to be able to detect if the current user is the doctor, so we can just interact with them directly. Does that all track?

 =E2=80=94 Justin

On Mar 10, 2021, at 4:10 = AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hello,

Notice the question = mark in the title. Not to be considered as an editor's comment.
This thread intends = to provide a detailed comment on the interesting feedback by = Kristina: "I would catch up on the thread to understand why DIDs are thought to be treated as assertions".
In the chat, I = answered: "Happy to get the discussion on DIDs. Actually, could be either or, depending on what we intend to do." Let me expand a bit on that, to make it understandable (didn't have the time during the meeting, unfortunately).

This relates to the = items described on slides 20 and 34, which I'll explain further. I'll highlight as transparently as possible what I think would be the benefits and downsides of each. Both are probably viable options, but they correspond to different scopes and objectives. I'll spend a bit more time on option 2, since it is a different approach compared to the current = draft.

1. The = first possibility is to use SECEVENT = throughout. 
In that case, DIDs = should be a part of sub_ids (in the core or in the extension registry, depending on what Annabelle's WG decides). More generally, the WG would have to decide which additional sub_ids it needs (as per Yaron's = comment).

That's obviously the = closest to what is described in draft-04. It allows a communication of subject information between the client and the AS, by using global identifiers (mail, phone, etc.), or using a local opaque reference - i.e. governed by = the AS (that's probably what we would put in the examples, = unless someone has a better idea - cf issues #16 and #42). 

Assertions relate = for instance to the proof of presence of the RO. The current draft-04 therefore plans for id_tokens and saml2, maybe there could be other needs later (extension registry).

- Benefits: = identifiers are a key component of GNAP, which makes integration easier. Possibly one could choose to use DIDs throughout.
- Downsides: = email/phone identifiers will probably be used throughout by most devs (since that's correlation information they have in their user DB). = Which means we should limit what assertions contain, to avoid doing links between weak global identifiers and hopefully stronger assertions. That's not really a problem if it's limited to authentication events mostly (in that perspective, samlv2 could make sense in the core). An assertion is probably a single value then (not an array).  =  

Option 1 can be = summarized as: 

"subject": = {
   "sub_ids": { = }, // request and response (SECEVENT -> = including DID possibly)          &nb= sp;        
   "assertions": [ ],       =         // request and response (id_token or = samlv2)
}
("hints" do not exist currently, but are partially covered separately via "request.user" / the relevance of "principal", discussed in the slide, is a question mark too - which is a different discussion on end-user !=3D RO).


2. An = alternate possibility is to use SECEVENT only as input/hint
In that case, DIDs = should be a part of assertions (which have a different meaning compared to option 1).

The AS only returns = an local opaque reference as_ref (while in option 1, it was only one of many possibilities). Its only job is to help the client differentiate the response subject. The AS policy might further define the scope of that reference, as suggested = in https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210, although I personally viewed = that by default as (2) "as_id" an identifier locally unique to that AS for all the RSs.

SECEVENTS are still = useful as an input, that's what I presented in request.hints.self.sub_ids (but it's the responsibility of = the AS to match it with its own reference system - from instance from the email to AS's local record XUT2MFM1XBIKJKSDU8Q). Note: = since the slides, a new = draft-ietf-secevent-subject-identifiers-07 has been published. Notably this includes an opaque identifier, which the client can use to pass the as_ref hint to the AS. Thus we wouldn't need any further addition to SECEVENT, although hints = would benefit from further additions (like DIDs for instance). Notice also that subject_types_supported becomes less important, because in the worst case scenario, it's simply a hint that wouldn't = be understood and therefore taken into account by the AS.

The assertions array = has a more important role than in option 1 (with the explicit aim of separating between client hints and validated info asserted by the AS). It serves as a generic/extendible mapping structure, e.g. "the AS asserts that opaque reference XUT2MFM1XBIKJKSDU8Q is matching with these (more or less verifiable) statements." The name assertion therefore corresponds to the responsibility of the AS = in delivering those statements (cf should/must, issue #49). Some of these statements relate to identity or auth events (ex: DID, id_token), some might directly be useful for authorization decisions (like ZKP example in the parental control example). Possibly some of these validated assertions could be reused in next = interactions.

Another question = that popped-up is the scope of sub_ids. Should they be about the same user? (I think so). In the case of remote ROs especially, it might be important that DID be considered as an assertion (about = someone else's) and not as sub_ids, because the AS needs to be careful about who the client wants to reach (avoid spam, etc.). This is consistent with the rest of discussion on what to do when end-user !=3D RO, although using DIDComm might seem a bit early (the paint is very = fresh). 

Option 2 was = summarized as: 

// (suggestion only, not as an editor)
"subject": = {
   "as_ref": { = // response only (wouldn=E2=80=99t = require SECEVENT)
=E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D,
=E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D   <= /div>
   },       &= nbsp;           
   "assertions": [ ],       =         // request and response = (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validated by = the AS)
   "hints": {         =               // request only = (optional)
      "self": { // replaces request.user (support = SECEVENT here)
   =E2=80=9Csub_ids=E2=80=9D= : { }, // SECEVENT (including opaque in = draft-07 - that could contain the ref)
   =E2=80=9Cassertions=E2=80=9D: [ ] = // see examples: VC on DOB or ZKP on age (wider scope, possibly through = extensions)
},          &= nbsp;       
      "principal": = { // new proposal presented at IETF110 = (just an idea)
  =E2=80=9Cautomated=E2=80=9D: = true, // rule engine
  =E2=80=9Casync=E2=80=9D: { = } // remote ROs
}          &n= bsp;   
   }
}

- Benefits: as_ref = is self supporting (no strong coupling with SECEVENT), but can still take SECEVENT as an input hint for the AS. It avoids the risk of making an official association between a weak global identifier (e.g. email, used elsewhere) and hopefully stronger local assertions. GNAP would be fully agnostic to whatever identity system is used, only facilitating interoperability through assertions (second only in importance compared to the AS opaque reference). Some assertions (possibly extensions) could also be useful for the AS decision (e.g. VC or ZKP).
- Downsides: = opaqueness of as_ref is a feature, not a bug. The opaque reference is fully managed by the AS, therefore not inherently portable (cf portability discussions in OIDC currently). There's no explicit binding to an official identity, only a contextual mapping to AS validated assertions. It makes it more difficult to match the identifiers from one AS to another or to correlate with the client user DB (still possible via assertions, if the AS allows it). Assertions are much more generic (possibly via extensions), but might require a more advanced mechanism to request/response = only the most relevant information (which makes the AS policy critical here).

I hope that = clarifies the reasoning for both = options. Again I'm not saying option 2 is better, just saying the trade-offs are different (+ knowing that we need to keep it simple).
- option 1 puts more = in sub_ids and less in assertions
- option 2 puts less = in the reference and more in = assertions 
All of this is open = to discussion. More generally speaking, on every part in orange and question mark (?) I would love your ideas and criticisms. What I intended as an editor is only to highlight where the WG has important choices to make, before we can make the related PRs.

A further side = comment: IETF EAT RATS was suggested for assertions, but relates more to the client attestations. It was added as a comment in https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, which is a distinct topic we'll work on.

Fabien (editor's hat = off)

--
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
= 

This communication, including any attachments, is =
confidential. If you are not the intended recipient, you should not read =
it - please contact me immediately, destroy it, and do not copy or use =
any part of this communication or disclose anything about it. Thank you. =
Please note that this communication does not designate an information =
system for the purposes of the Electronic Transactions Act 2002.



= --Apple-Mail=_B4184C83-F7C4-4A7D-9DAE-DFD1FFE07C43-- From nobody Thu Mar 11 23:08:53 2021 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 826C33A0AB5 for ; Thu, 11 Mar 2021 23:08:51 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 U4E3jb-qnLj6 for ; Thu, 11 Mar 2021 23:08:48 -0800 (PST) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 81D5C3A0A9F for ; Thu, 11 Mar 2021 23:08:48 -0800 (PST) Received: by mail-il1-x12f.google.com with SMTP id d5so1690817iln.6 for ; Thu, 11 Mar 2021 23:08:48 -0800 (PST) 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=hpDT4ZVK5FZ4TVFUkDO+/xe2LIGt1Yss5fEsdTKAUh8=; b=Oiwvo+azjbK3edZNNegzFtl5xqVVQ+dWPFAWdNY1G1bNCrMfxRLgZI8do3/77Z/EeT hNa+ulk9Xzhd5dmlXQuD8kNUPyQzVwwZKL0ymISIrinHN5TOkWrS0S3KjLeWSPuiqGqR FjNqmyUZnCFKQjlJ/ZqhZLLnpLYgyjagWQM7jaefVjKEozafArNpcXMJEptVze8LwJyD U6nn26GBH2P3at2UNh5ypXC+1J/p4hrqblZGvAcfju+a94xX5ANST2siyKCmXFxPD3bl CnTxQDvqSnTU6XGM1wgouVeZqZbb2V7WyUj4YCtAPU44kINJR0k5IwkjHVQSLCkv/GfX ea9A== 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=hpDT4ZVK5FZ4TVFUkDO+/xe2LIGt1Yss5fEsdTKAUh8=; b=lV3C4r0LOW5bnmrHf2pZhOl2+Z9V5JvzfY+KqvnvPxCfIrwCp4t2wZKBmtZc6vOSkX mOCSMkaJ8k8OMeil7d25r297O9oRg1ciKLE4tGfXCSnq7d7kckNGNSBhsYD1T/fUoP7e LA/WIpEQgIKNt9BXjGuIG7Sg+0KsWBFPs67k41mdXxc5tCW8aJNLx58dH7M0f+l1NUTT WkxWzxfstV3U+GdteQnSCiQw0XrTRgHCsTbqmTRhMPCe7JuI+ygioUjqXeSFy1MJ4rsi vZVWc5YXKZuJ/aTiKQEq+Dk9kBGdADDTfmEr1hMkGNZYPhbnoY3I4TxOcrgEOuVBaIu7 oz7Q== X-Gm-Message-State: AOAM532aM9E3Gn5DN+lIztB2vzW3C5Rt3Cw9EmcNAzWCHeIBnBgUJAtY y6HSIiTvoIWDIzLI8PzhEb7pMM+NzXHhphC4tYreMFeldrMqTA== X-Google-Smtp-Source: ABdhPJy9tPSFlLKSLSGLdH2Jy/OMFA93xBCXq297u9k8BtWP+hvhzGyefXoY57KhY0qwo5b1OL/L6omLz1P/aBpNTts= X-Received: by 2002:a05:6e02:dc4:: with SMTP id l4mr1706799ilj.123.1615532926780; Thu, 11 Mar 2021 23:08:46 -0800 (PST) MIME-Version: 1.0 From: Fabien Imbault Date: Fri, 12 Mar 2021 08:08:36 +0100 Message-ID: To: GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000003948f305bd51928f" Archived-At: Subject: [GNAP] Next steps on subject identifiers X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2021 07:08:52 -0000 --0000000000003948f305bd51928f Content-Type: text/plain; charset="UTF-8" Hi everyone, Thanks a lot for your participation at IETF110 and on the mailing list. As agreed during the call, please find a summary and highlight of the next steps following the discussion item on "subject identifiers" (from an editorial standpoint this time, after taking into account the feedbacks): 1. fix open issues related to "subject identifiers". Every item with a question mark (?), in the slides, would love your input. In particular, some great questions during the meeting: - what goes into the identifier structure? (question about DIDs was further discussed in a dedicated thread) - what goes into the assertion(s) structure? - how do the identifiers and assertion(s) relate? - what do we handle in the core spec vs as an extension? New information: based on SECEVENT draft-07 published this week, we now have an internal opaque format to use. As per Yaron's suggestion, Justin has reached out to the SECEVENT WG to enquire about DID support. The next step is to make PRs (based on sub_ids draft-07), following the now usual process. See below for a recap of intended/proposed changes to fix outstanding issues, the detailed discussions will then be handled through issues and PRs on github. ------------------------------------------------------------------------------------------------------------------- Here's the list of suggested intended changes to come next (mostly normative clean up): - #16 #42 examples will be based on the sub_ids opaque format #16 #42 - #75 #120 scope of subject identifiers based on sub_id and validation by the AS (see #49) - #198 no major change on terminology but a light rewording for "subject information" (will become "statement asserted by an AS about a subject.") - #171 "ad-hoc portability" considered out of scope, sub_ids solve a big part of that - #51 is fixed by using the SECEVENT opaque format - #43 #50 assertion will correspond to an id_token authentication event, and samlv2 gives us a good reason to design the extension registry (a first step might just be to remove it from the core, due to XML security considerations / a dedicated issue related to samv2 extension is likely) - #49 "should/must validate client assertions" ultimately depends on #41, but "should" seems more realistic. As further guidance, we could move request.user into request.subject.hints to align with what has been done for interaction, to clarify the current wording "Subject identifiers are hints to the AS in determining the RO and MUST NOT be taken as declarative statements" - #178 is already with a PR in pending merge, no change to that Here's the list of issues that won't be addressed just yet (more input from WG needed): - #41 assertions as an array: it seems likely we'll need that but as long as we don't have anything else than id_token, this seems too early to change - #197 discussion on roles would remain open. Will keep the current wording for now. ------------------------------------------------------------------------------------------------------------------- 2. get preliminary feedback on the prospective issues, e.g. RO vs end-user. This is early stage and only for discussion right now. This is complementary to the "AS as a token factory" presentation by Justin. Wishing you all a nice day. The editors --0000000000003948f305bd51928f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

Thanks a lot for your = participation at IETF110 and on the mailing list. As agreed during the call= , please find a summary and highlight of the next steps following the discu= ssion item on "subject identifiers" (from an editorial standpoint= this time, after taking into account the feedbacks):

1. fix open is= sues related to "subject identifiers".

Every item with a q= uestion mark (?), in the slides, would love your input.
In particular, s= ome great questions during the meeting:
- what goes into the identifier = structure? (question about DIDs was further discussed in a dedicated thread= )
- what goes into the assertion(s) structure?
- how do the identifi= ers and assertion(s) relate?
- what do we handle in the core spec vs as = an extension?

New information: based on SECEVENT draft-07 published = this week, we now have an internal opaque format to use. As per Yaron's= suggestion, Justin has reached out to the SECEVENT WG to enquire about DID= support.

The next step is to make PRs (based on sub_ids draft-07),= following the now usual process.
See below for a recap of intended/pro= posed changes to fix outstanding issues, the detailed discussions will then= be handled through issues and PRs on github.
--------------------------= ---------------------------------------------------------------------------= --------------
Here's the list of suggested intended changes to come= next (mostly normative clean up):
- #16 #42 examples will be based on t= he sub_ids opaque format #16 #42
- #75 #120 scope of subject identifiers= based on sub_id and validation by the AS (see #49)
- #198 no major chan= ge on terminology but a light rewording for "subject information"= (will become "statement asserted by an AS about a subject.")
= - #171 "ad-hoc portability" considered out of scope, sub_ids solv= e a big part of that
- #51 is fixed by using the SECEVENT opaque format=
- #43 #50 assertion will correspond to an id_token authentication event= , and samlv2 gives us a good reason to design the extension registry (a fir= st step might just be to remove it from the core, due to XML security consi= derations / a dedicated issue related to samv2 extension is likely)
- #= 49 "should/must validate client assertions" ultimately depends on= #41, but "should" seems more realistic. As further guidance, we = could move request.user into request.subject.hints to align with what has b= een done for interaction, to clarify the current wording "Subject iden= tifiers are hints to the AS in determining the RO and MUST NOT be taken as = declarative statements"
- #178 is already with a PR in pending merg= e, no change to that

Here's the list of issues that won't be= addressed just yet (more input from WG needed):
- #41 assertions as an = array: it seems likely we'll need that but as long as we don't have= anything else than id_token, this seems too early to change
- #197 disc= ussion on roles would remain open. Will keep the current wording for now.-------------------------------------------------------------------------= ------------------------------------------

2. get preliminary feedba= ck on the prospective issues, e.g. RO vs end-user. This is early stage and = only for discussion right now. This is complementary to the "AS as a t= oken factory" presentation by Justin.

Wishing= you all a nice day.

The editors
--0000000000003948f305bd51928f-- From nobody Thu Mar 11 23:16:37 2021 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 533363A0C94 for ; Thu, 11 Mar 2021 23:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 gyowOO0p6Ec9 for ; Thu, 11 Mar 2021 23:16:32 -0800 (PST) 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 B6D363A0C81 for ; Thu, 11 Mar 2021 23:16:31 -0800 (PST) Received: by mail-il1-x12a.google.com with SMTP id e7so1687636ile.7 for ; Thu, 11 Mar 2021 23:16:31 -0800 (PST) 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=fBbsuEJrWRRAI241FlLX9jzTtQW+5m9+W83p+uPU9VA=; b=BbPNfFKRhmnFXhWLiNA9z4x0xjGzEyu2d8vWHeB0W/hfHd+BAAICXT1uGkcYhfUphy NukRhQlDC6PT20YsL7BF8Tq6QveGfwfNtlGslfNbO3UAmrymZTCttWoZEqQcaKwQxAru FzVH+zpKEoYKFih2OwOxXOZPo4EOHQ/tDenBQXbUq+gE2RqYpg9U09NQT5BP/nf9eMTc 299o8RQsdj4cF+ObNDSG5TJ7VeR3iXndON38UTJ0MyGwQfsi34OgEH07bVtL/JFe9us5 yxOG2GdwkxIH8pZaYO0DNxbbmwsA09Qp+NbOMBqdSWVdp3iKh7AVzGDpsei1muyx/V9z Y4CQ== 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=fBbsuEJrWRRAI241FlLX9jzTtQW+5m9+W83p+uPU9VA=; b=pBpm805qzzGAgHsFxlYI95v0L+yht5wW5QhbtJ1HcFe8G4K3z8smKahhtfJMm4R8Ht 1hq4IfvfVK8PcwW6n3GyndgfnQWckAiDfNqdyzqEIFd8IvpvPmKk/1vI3Y9pSejXBPEP 0tj7ehI2Vgyyzb92k4tmPuvFj7qq5mC1b/6fQ0FspJ/cGk9GWXSAyS79UQCR+ZPBSFcL OnKUAuhlrUVYOJteH3Ez9Sl+Ix1gXypHD2cjuiwj5qfCeclEprnurA5e5N2el7yIzzXF f/J9frfyTsfQUfHzgwZJCEWbUs/G4Z07l/UXU4qsQkP7blMTjhkTX9YEboMgwHoUGR5N ijkA== X-Gm-Message-State: AOAM533P8q4rnuIQrn8pZO3Z5lWYVGXZ1AVyePiIVadfbKaHDvdvPkS3 0x+EtPHzMvU0oCYvtZ8xxAscTcUTpUdisLL5Uho= X-Google-Smtp-Source: ABdhPJzN8X/17ZF5gvFKuEmkl5Ux4r7QB8UZrBekW+Vva0/oHXw9NJmR2qAvcb2dqVxVdr2U1uOUm+DBxde5rnaWhoQ= X-Received: by 2002:a05:6e02:1cac:: with SMTP id x12mr1933466ill.188.1615533390233; Thu, 11 Mar 2021 23:16:30 -0800 (PST) MIME-Version: 1.0 References: <67a11cda-a06a-4e03-0d99-05cf6ab14474@free.fr> <7C3854AD-0EC1-4A21-A9F1-BE8004E5AA89@mit.edu> In-Reply-To: <7C3854AD-0EC1-4A21-A9F1-BE8004E5AA89@mit.edu> From: Fabien Imbault Date: Fri, 12 Mar 2021 08:16:18 +0100 Message-ID: To: Justin Richer Cc: Denis , GNAP Mailing List , Tobias Looker Content-Type: multipart/alternative; boundary="000000000000d906eb05bd51ad8a" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2021 07:16:36 -0000 --000000000000d906eb05bd51ad8a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 for that. On Thu, Mar 11, 2021 at 8:58 PM Justin Richer wrote: > Denis, > > Many of your comments here would be best addressed to the SECEVENT workin= g > group as feedback on the subject identifiers draft. There is new text in > -07 that helps establish this as useful outside of SET/JWT, and I would > guess the author would be amenable to clarifying that further. > > =E2=80=94 Justin > > On Mar 11, 2021, at 1:50 PM, Denis wrote: > > Hi Fabien, > > Thank you for launching the discussion. > > SECEVENT draft-07 does not really offer new possibilities over draft-06. > The major change is simply in the syntax naming. > > The response to your question is not limited to an exclusive choice > between option 1 and option 2. :-) > > The definition of a subject identifier in draft-07 is : > > *3. Subject Identifiers > * > > * A Subject Identifier is a JSON [RFC7159] object whose contents may be > used to identify a subject within some context. An Identifier Format > is a named definition of a set of information that may be used to > identify a subject, and the rules for encoding that information as a > Subject Identifier; they define the syntax and semantics of Subject > Identifiers.* > > With such a definition is it possible to request some *types *of subject > identifiers to be placed into an access token, > to place subjects identifiers (with their values) into an access token an= d > for a RS to compare these subjects identifiers > (with their values) against validation rules enacted by a RO acting as an > ADF (Access Decision Function) which also use > the same subjects identifiers (with their values). > > A DID is a persistent global unique identifier. > > In issue #210 ("sub_id" claims #210) I already proposed the following > examples for globally unique identifiers (gu_id) : > > (1) For a globally unique identifier: > > "sub_id": { > "format": "gu_id", > "gu_id": " email", > "email: "john@hughes.com" , > } > > or > > "sub_id": { > "format": "gu_id", > "gu_id": "ssn", > "ssn": { > "cn": "250" > "value": "160087404506527", > }, > } > > In order to address DIDs, I would simply add the following example: > > "sub_id": { > "format": "gu_id", > "gu_id": " did", > "did: "did:*DID:Method:DID Method Specific String*", > } > > "sub_ids" claims are much better when compared to "sub" claims. > > The definition of Subject Identifier in the draft-07 (section 3) is : > > A Subject Identifier is a JSON [RFC7159] object whose contents may be > used to identify a subject *within some context*. > > However, page 2 of the draft-07 states: > > As described in Section 1.2 of SET [RFC8417], subjects *related to* > * security events* may take a variety of forms, including but not > limited to a JWT [RFC7519] principal, an IP address, a URL, etc. > > RFC 8417 (Security Event Token (SET)) states in its abstract: > > Abstract > > This specification defines the *Security Event Token (SET) data* > * structure*. A SET describes statements of fact from the perspective > of an issuer about a subject. These statements of fact represent an > event that occurred directly to or about a security subject, for > example, a statement about the issuance or revocation of a token on > behalf of a subject. This specification is intended to enable > representing security- and identity-related events. A SET is a JSON > Web Token (JWT), which can be optionally signed and/or encrypted. > SETs can be distributed via protocols such as HTTP. > > There is a need to be able to use subject identifiers that will not > necessarily be used in > a Security Event Token (SET) data structure. > > > These Subject Identifiers might still be used in a Security Event Token > (SET) data structure, *but not necessarilly*. > > - When supporting RBAC (Role Based Access Control), it would be nice > to define "sub_ids" able to support roles. > - When supporting ABAC (Attribute Bases Access Control), it would be > nice to define "sub_ids" able to support > group memberships with two flavours of them : (a) hierarchical groups > and (b) functional groups; > > The current title of the draft is: "Subject Identifiers for Security Even= t > Tokens" . > More appropriate titles would be: > > Subject Identifiers for Security Event Tokens *a**nd other purposes* > > or simply > > Subject Identifiers > > The first sentence of the abstract should also be slightly modified. > > Denis > > > Hi Tobias, > > Option 2's pros and cons are the consequence of solely relying only on an > opaque identifier managed by the AS, independantly from external > identifiers. > > That's an additional level of indirection, not unlike how indexes are > usually managed in a database. But there's obviously the additional > complexity of making a just in time translation into a practical identifi= er > (like email for account recovery, as discussed by Justin). > > "Assertions" should be what the AS (possibly with the assistance of other > parties) can confidently say about the subject. > > Thanks for the great feedback, as well as Justin's. Since the slides were > written, SECEVENT draft-07 already offers new possibilities which is good > news. > > Fabien > > Le mer. 10 mars 2021 =C3=A0 22:02, Tobias Looker > a =C3=A9crit : > >> > Thanks for the feedback, although I'm not sure what you mean by too >> abstract. >> >> Apologies what I mean by that was I feel like Option 2 would expose too >> much complexity to clients that would be required to construct a request= to >> the AS. Option 1 IMO strikes a better balance by still offering the >> required flexibility but keeping things relatively simple. >> >> > Just a quick comment: an assertion in option 2 is not "the fact the >> identifier is resolvable to cryptographic material that *can *be used to >> validate cryptographic assertions". It is merely a statement by the AS t= hat >> "the subject corresponding to the reference has a DID" ("has" is the >> assertion here). >> >> Yes I understand to drill down on this more though couldn't the entire >> request made by the client to the AS also be considered to be an asserti= on? >> Therefore the "sub_ids" request element is an assertion by the client ab= out >> who it believes the subject to be identified as? If this is true then to= me >> the "assertions" request element is there for assertions that parties ot= her >> than the client are making about the subject (e.g an id_token). >> >> Thanks, >> [image: Mattr website] >> *Tobias Looker* >> Mattr >> +64 (0) 27 378 0461 >> tobias.looker@mattr.global >> [image: Mattr website] [image: Mattr on LinkedIn= ] >> [image: Mattr on Twitter] >> [image: Mattr on Github] >> >> This communication, including any attachments, is confidential. If you >> are not the intended recipient, you should not read it - please contact = me >> immediately, destroy it, and do not copy or use any part of this >> communication or disclose anything about it. Thank you. Please note that >> this communication does not designate an information system for the >> purposes of the Electronic Transactions Act 2002. >> >> >> On Thu, Mar 11, 2021 at 9:20 AM Fabien Imbault >> wrote: >> >>> Thanks Justin. >>> >>> It's good to clarify what we mean by assertion. I used a more mundane >>> meaning. >>> >>> I dislike email/phone as security disasters waiting to happen. I get >>> that they are practical. >>> >>> I think I have what I need to write the PRs based on sub_ids (based on >>> the current draft-07). >>> >>> Fabien >>> >>> Le mer. 10 mars 2021 =C3=A0 20:18, Justin Richer a = =C3=A9crit : >>> >>>> Hi Fabien, >>>> >>>> First, thanks for doing the heavy lift of writing this topic up. Of >>>> these options, I would strongly prefer option (1). The difference betw= een >>>> assertions and identifiers is that an assertion is a fully packaged se= t of >>>> attributes, one of which can be an identifier. They are, generally >>>> speaking, cryptographically protected bundles. They=E2=80=99re designe= d to carry a >>>> bunch of different information about a user and the authentication eve= nt in >>>> a form that=E2=80=99s independently verifiable and auditable. SAML ass= ertions (XML >>>> document) and ID Tokens (signed JWTs) are the most common ones we see >>>> today, but other formats exist and will keep being invented. >>>> >>>> An identifier is a different kind of creature. It is a single statemen= t >>>> that identifies the party in question in the context of the party doin= g the >>>> identification. It=E2=80=99s this full context that the receiver of th= e identifier >>>> needs to interpret it in. When using a federated identity protocol, ea= ch RP >>>> is going to have :some: kind of local user information store that they= =E2=80=99re >>>> going to tie into, some field in a database they=E2=80=99ll key off of= . It=E2=80=99s just >>>> never going to be the case that all RPs will be able to use server-pro= vided >>>> opaque identifiers for all cases. Account recovery and binding is one = such >>>> use case where a user-facing identifier like an email address makes a = LOT >>>> of sense, for one small example. This is an array in the request and >>>> response precisely because a user could be known by several different >>>> identifiers to a party, and an RP will have a better idea about what k= inds >>>> of things it wants to correlate against, and it=E2=80=99s up to the AS= to provide >>>> that mapping. I think that if we don=E2=80=99t define a way to describ= e the format, >>>> the =E2=80=9Cas_id=E2=80=9D field is going to get structure back-patch= ed onto it like is >>>> being proposed here: >>>> >>>> https://mattrglobal.github.io/oidc-portable-identities/ >>>> >>>> I=E2=80=99m personally not a fan of that approach as it mixes the data= layering >>>> too much, and you end up making guesses about whether a field is meani= ngful >>>> or a pointer. I think GNAP will be much better served by using a data >>>> structure for this from the start. DIDs should be another =E2=80=9Cfor= mat=E2=80=9D of the >>>> subject identifier. I don=E2=80=99t think GNAP should define this form= at, and I=E2=80=99ve >>>> dropped a note to the SECEVENT mailing list asking about adding DIDs t= o the >>>> subject identifiers draft before it gets published. DIDs are not >>>> assertions, even in the cases where they point to fully functional DID >>>> documents with user information in them. (And for what it=E2=80=99s wo= rth, I think >>>> the OIDC world should also use the SECEVENT draft inside ID Tokens to = solve >>>> the use case of the draft above). >>>> >>>> For the user !=3D RO cases, I think that potentially having a way to >>>> signal those two items separately in the request and response could be >>>> useful. Right now all the user/subject stuff is about identifying =E2= =80=9Cthe user >>>> that=E2=80=99s currently here at the client instance=E2=80=9D, in a va= riety of forms that >>>> the client instance and AS can negotiate. If the client or AS has some >>>> other notion about who the RO is and how that could be separate from t= he >>>> current user, we could provide a way to signal that like you=E2=80=99r= e proposing >>>> below. In my mental model, there are going to be a lot of use cases wh= ere >>>> the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the client at all, but= rather to the AS and is >>>> based on what the client=E2=80=99s asking for. So I could identify the= current user >>>> and ask for a specific medical record, and the AS realizes it has to g= o bug >>>> a particular doctor to approve things directly. This is instead of >>>> interacting with the current user and failing in an awkward way when t= he >>>> current user doesn=E2=80=99t have the rights to do things, but someone= else would. >>>> But we=E2=80=99d want the system to be able to detect if the current u= ser is the >>>> doctor, so we can just interact with them directly. Does that all trac= k? >>>> >>>> =E2=80=94 Justin >>>> >>>> On Mar 10, 2021, at 4:10 AM, Fabien Imbault >>>> wrote: >>>> >>>> Hello, >>>> >>>> Notice the question mark in the title. Not to be considered as an >>>> editor's comment. >>>> This thread intends to provide a detailed comment on the >>>> interesting feedback by Kristina: "I would catch up on the thread to >>>> understand why DIDs are thought to be treated as assertions". >>>> In the chat, I answered: "Happy to get the discussion on DIDs. >>>> Actually, could be either or, depending on what we intend to do." Let = me >>>> expand a bit on that, to make it understandable (didn't have the time >>>> during the meeting, unfortunately). >>>> >>>> This relates to the items described on slides 20 and 34, which I'll >>>> explain further. I'll highlight as transparently as possible what I th= ink >>>> would be the benefits and downsides of each. Both are probably viable >>>> options, but they correspond to different scopes and objectives. I'll = spend >>>> a bit more time on option 2, since it is a different approach compared= to >>>> the current draft. >>>> >>>> *1. The first possibility is to use SECEVENT throughout. * >>>> In that case, DIDs should be a part of sub_ids (in the core or in the >>>> extension registry, depending on what Annabelle's WG decides). More >>>> generally, the WG would have to decide which additional sub_ids it nee= ds >>>> (as per Yaron's comment). >>>> >>>> That's obviously the closest to what is described in draft-04. It >>>> allows a communication of subject information between the client and t= he >>>> AS, by using global identifiers (mail, phone, etc.), or using a local >>>> opaque reference - i.e. governed by the AS (that's probably what we >>>> would put in the examples, unless someone has a better idea - cf issue= s #16 >>>> and #42). >>>> >>>> Assertions relate for instance to the proof of presence of the RO. The >>>> current draft-04 therefore plans for id_tokens and saml2, maybe there = could >>>> be other needs later (extension registry). >>>> >>>> - Benefits: identifiers are a key component of GNAP, which makes >>>> integration easier. Possibly one could choose to use DIDs throughout. >>>> - Downsides: email/phone identifiers will probably be used throughout >>>> by most devs (since that's correlation information they have in their = user >>>> DB). Which means we should limit what assertions contain, to avoid doi= ng >>>> links between weak global identifiers and hopefully stronger assertion= s. >>>> That's not really a problem if it's limited to authentication events m= ostly >>>> (in that perspective, samlv2 could make sense in the core). An asserti= on is >>>> probably a single value then (not an array). >>>> >>>> Option 1 can be summarized as: >>>> >>>> "subject": { >>>> "sub_ids": { }, // request and response (SECEVENT -> including DID >>>> possibly) >>>> "assertions": [ ], // request and response (id_token >>>> or samlv2) >>>> } >>>> ("hints" do not exist currently, but are partially covered separately >>>> via "request.user" / the relevance of "principal", discussed in the sl= ide, >>>> is a question mark too - which is a different discussion on end-user != =3D RO). >>>> >>>> >>>> *2. An alternate possibility is to use SECEVENT only as input/hint* >>>> In that case, DIDs should be a part of assertions (which have a >>>> different meaning compared to option 1). >>>> >>>> The AS only returns an local opaque reference as_ref (while in option >>>> 1, it was only one of many possibilities). Its only job is to help the >>>> client differentiate the response subject. The AS policy might further >>>> define the scope of that reference, as suggested in >>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210, >>>> although I personally viewed that by default as (2) "as_id" an identif= ier >>>> locally unique to that AS for all the RSs. >>>> >>>> SECEVENTS are still useful as an input, that's what I presented in >>>> request.hints.self.sub_ids (but it's the responsibility of the AS to m= atch >>>> it with its own reference system - from instance from the email to AS'= s >>>> local record XUT2MFM1XBIKJKSDU8Q). Note: since the slides, a new >>>> draft-ietf-secevent-subject-identifiers-07 has been published. Notably= this >>>> includes an opaque identifier, which the client can use to pass the as= _ref >>>> hint to the AS. Thus we wouldn't need any further addition to >>>> SECEVENT, although hints would benefit from further additions (like DI= Ds >>>> for instance). Notice also that subject_types_supported becomes less >>>> important, because in the worst case scenario, it's simply a hint that >>>> wouldn't be understood and therefore taken into account by the AS. >>>> >>>> The assertions array has a more important role than in option 1 (with >>>> the explicit aim of separating between client hints and validated info >>>> asserted by the AS). It serves as a generic/extendible mapping structu= re, >>>> e.g. "the AS asserts that opaque reference XUT2MFM1XBIKJKSDU8Q is >>>> matching with these (more or less verifiable) statements." The name >>>> assertion therefore corresponds to the responsibility of the AS in >>>> delivering those statements (cf should/must, issue #49). Some of these >>>> statements relate to identity or auth events (ex: DID, id_token), some >>>> might directly be useful for authorization decisions (like ZKP example= in >>>> the parental control example). Possibly some of these validated assert= ions >>>> could be reused in next interactions. >>>> >>>> Another question that popped-up is the scope of sub_ids. Should they b= e >>>> about the same user? (I think so). In the case of remote ROs especiall= y, it >>>> might be important that DID be considered as an assertion (about someo= ne >>>> else's) and not as sub_ids, because the AS needs to be careful about w= ho >>>> the client wants to reach (avoid spam, etc.). This is consistent with = the >>>> rest of discussion on what to do when end-user !=3D RO, although using >>>> DIDComm might seem a bit early (the paint is very fresh). >>>> >>>> Option 2 was summarized as: >>>> >>>> // (suggestion only, not as an editor) >>>> "subject": { >>>> "as_ref": { // response only (wouldn=E2=80=99t require SECEVENT) >>>> =E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D, >>>> =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D >>>> }, >>>> "assertions": [ ], // request and response >>>> (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validated by th= e AS) >>>> >>>> "hints": { // request only (optional) >>>> "self": { // replaces request.user (support SECEVENT here) >>>> =E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque in dr= aft-07 - that >>>> could contain the ref) >>>> =E2=80=9Cassertions=E2=80=9D: [ ] // see examples: VC on DOB or ZKP= on age (wider >>>> scope, possibly through extensions) >>>> }, >>>> "principal": { // new proposal presented at IETF110 (just an >>>> idea) >>>> =E2=80=9Cautomated=E2=80=9D: true, // rule engine >>>> =E2=80=9Casync=E2=80=9D: { } // remote ROs >>>> } >>>> } >>>> } >>>> >>>> - Benefits: as_ref is self supporting (no strong coupling with >>>> SECEVENT), but can still take SECEVENT as an input hint for the AS. It >>>> avoids the risk of making an official association between a weak globa= l >>>> identifier (e.g. email, used elsewhere) and hopefully stronger local >>>> assertions. GNAP would be fully agnostic to whatever identity system i= s >>>> used, only facilitating interoperability through assertions (second on= ly in >>>> importance compared to the AS opaque reference). Some assertions (poss= ibly >>>> extensions) could also be useful for the AS decision (e.g. VC or ZKP). >>>> - Downsides: opaqueness of as_ref is a feature, not a bug. The opaque >>>> reference is fully managed by the AS, therefore not inherently portabl= e (cf >>>> portability discussions in OIDC currently). There's no explicit bindin= g to >>>> an official identity, only a contextual mapping to AS validated assert= ions. >>>> It makes it more difficult to match the identifiers from one AS to ano= ther >>>> or to correlate with the client user DB (still possible via assertions= , if >>>> the AS allows it). Assertions are much more generic (possibly via >>>> extensions), but might require a more advanced mechanism to >>>> request/response only the most relevant information (which makes the A= S >>>> policy critical here). >>>> >>>> I hope that clarifies the reasoning for both options. Again I'm not >>>> saying option 2 is better, just saying the trade-offs are different (+ >>>> knowing that we need to keep it simple). >>>> - option 1 puts more in sub_ids and less in assertions >>>> - option 2 puts less in the reference and more in assertions >>>> All of this is open to discussion. More generally speaking, on every >>>> part in orange and question mark (?) I would love your ideas and >>>> criticisms. What I intended as an editor is only to highlight where th= e WG >>>> has important choices to make, before we can make the related PRs. >>>> >>>> A further side comment: IETF EAT RATS was suggested for assertions, bu= t >>>> relates more to the client attestations. It was added as a comment in >>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, which is >>>> a distinct topic we'll work on. >>>> >>>> Fabien (editor's hat off) >>>> >>>> -- >>>> 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 >>> >> >> This communication, including any attachments, is confidential. If you a= re not the intended recipient, you should not read it - please contact me i= mmediately, destroy it, and do not copy or use any part of this communicati= on or disclose anything about it. Thank you. Please note that this communic= ation does not designate an information system for the purposes of the Elec= tronic Transactions Act 2002. >> >> > > > --000000000000d906eb05bd51ad8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 for that.

On Thu, Mar 11, 2021 at 8= :58 PM Justin Richer <jricher@mit.edu= > wrote:
=
Denis,

Many of= your comments here would be best addressed to the SECEVENT working group a= s feedback on the subject identifiers draft. There is new text in -07 that = helps establish this as useful outside of SET/JWT, and I would guess the au= thor would be amenable to clarifying that further.

=C2=A0=E2=80=94 Justin

On Mar 1= 1, 2021, at 1:50 PM, Denis <denis.ietf@free.fr> wrote:

=20
Hi Fabien,

Thank you for launching the discussion.

SECEVENT draft-07 does not really offer new possibilities over draft-06. The major change is simply=C2=A0 in the syntax naming.

The response to your question is not limited to an exclusive choice between option 1 and option 2. :-)

The definition of a subject identifier in draft-07 is :

3.=C2=A0 Subject Identifiers=20

=C2=A0=C2=A0 A Subject Identifier is a JSON [RFC7159] =
object whose contents may be
=C2=A0=C2=A0 used to identify a subject within some context.=
=C2=A0 An Identifier Format
=C2=A0=C2=A0 is a named definition of a set of information that may =
be used to
=C2=A0=C2=A0 identify a subject, and the rules for encoding that inf=
ormation as a
=C2=A0=C2=A0 Subject Identifier; they define the syntax and semantic=
s of Subject=20
   Identifiers.
With such a definition is it possible to request some types of subject identifiers to be placed into an access token,
to place subjects identifiers (with their values) into an access token and for a RS to compare these subjects identifiers
(with their values) against validation rules enacted by a RO acting as an ADF (Access Decision Function) which also use
the same subjects identifiers (with their values).

A DID is a persistent global unique identifier.

In issue #210=C2=A0 ("sub_id" claims #210) I already proposed the following examples for = glob= ally unique identifiers (gu_id) :
(1) Fo= r a = globally unique identifier:

"sub_id": {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = "format": "gu_id",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = "gu_id": " email",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = "email: "john= @hughes.com",
=C2=A0=C2=A0=C2=A0=C2=A0 }

or

"sub_id": {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = "format": "gu_id",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = "gu_id": "ssn",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = "ssn": {
=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=C2=A0=C2=A0=C2=A0=C2= =A0 "cn": "250"
=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=C2=A0=C2=A0=C2=A0=C2= =A0 "value": "160087404506527", =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=C2=A0=C2=A0 },
=C2=A0=C2=A0=C2=A0=C2=A0 }
In order to address DIDs, I would simply add the following example:

"sub_id&= quot;: {
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 "format": "gu_id",
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 "gu_id": " did",
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 "did: "did:DID:Method:DID Method Specific String",=
=C2=A0=C2=A0=C2= =A0=C2=A0 }
"sub_ids" claims are much better when compared to "sub" claims.

The definition of Subject Identifier in the draft-07 (section 3) is :
=C2=A0=C2=A0 = A Subject Identifier is a JSON [RFC7159] object whose contents may be
=C2=A0=C2=A0 used to id= entify a subject within some context.=C2=A0
However, page 2 = of the draft-07 states:
=C2=A0=C2=A0 As desc= ribed in Section 1.2 of SET [RFC8417], subjects related to
=C2=A0=C2=A0 security events may take a variety of= forms, including but not
=C2=A0=C2=A0 limited to a JWT [RFC7519] principal, an IP addr= ess, a URL, etc.
<= span lang=3D"EN-US">RFC 8417 (Security Event Token (SET)) states in its abstract:
Abstract

=C2=A0=C2=A0 This specification defines the Security Event Token (SET) data<= i>
=C2=A0=C2=A0 structure.=C2=A0 A SET describes statements of fact from the perspective
=C2=A0=C2=A0 of an issuer about a subject.=C2=A0 These statements of fact represent an
=C2=A0=C2=A0 event that occurred directly to or about a security subject, for=
=C2=A0=C2=A0 example, a statement about the issuance or revocation of a token on=
=C2=A0=C2=A0 behalf of a subject.=C2=A0 This specification is intended to enable<= /span>
=C2=A0=C2=A0 representing security- and identity-related events.=C2=A0 A SET is a JSON
=C2=A0=C2=A0 Web Token (JWT), which can be optionally signed and/or encrypted.<= /span>
=C2=A0=C2=A0 SETs can be distributed via protocols such as HTTP.

There is a need to be able to= use subject identifiers that will not necessarily be used in<= span lang=3D"EN-US">
a Security Event Token (SET) data structure= <= span lang=3D"EN-US">.
<= span lang=3D"EN-US">
<= span lang=3D"EN-US">These <= span lang=3D"EN-US">Subject Identifiers might still be used in = <= span lang=3D"EN-US">a Security Event Token (SET) data structure, but not necessarilly<= /span>.
  • = When supporting RBAC (Role Based Access Control), it would be nice to define "sub_ids" able to support roles.
  • = When supporting ABAC (Attribute Bases Access Control), it would be nice to define <= /span>"sub_ids" able to support
    group memberships with two flavours of them : (a) hierarchical     <= span lang=3D"EN-US">groups and (b) functional <= /span><= span lang=3D"EN-US"><= span lang=3D"EN-US">groups; <= /span>=
The current title of the draft is: "Subject Identifiers for Security Event Tokens" .
More appropriate titles would be:
Subject Identifiers for Security Event Tokens and other purposes
or simply
Subject Identifiers
The first sentence of the abstract should also be slightly modified.

Denis


=20
Hi Tobias,

Option 2's pros and cons are the consequence = of solely relying only on an opaque identifier managed by the AS, independantly from external identifiers.=C2=A0

That's an additional level of indirection, no= t unlike how indexes are usually managed in a database. But there's obviously the additional complexity of making a just in time translation into a practical identifier (like email for account recovery, as discussed by Justin).=C2=A0

"Asse= rtions" should be what=C2=A0the AS (possibly with the assistance of other parties) can confidently say about the subject.=C2=A0

Thanks for the great feedback, as well as Justin's.=C2=A0Since = the slides were written, SECEVENT draft-07 already offers new possibilities which is good news.=C2=A0

Fabien

Le mer. 10 mars 2021 =C3= =A0 22:02, Tobias Looker <tobias.looker@mattr.global> a =C3=A9crit=C2=A0:
> Thanks for the feedback, although I'= ;m not sure what you mean by too abstract.

Apologies what I mean by that was I feel like Option 2 would expose too much complexity to clients that would be required to construct a request to the AS. Option 1 IMO strikes a better balance by still offering the required flexibility but keeping things relatively simple.

> Just a quick comment: an assertion in option 2 is not "the fact the identifier is resolvable to cryptographic material that=C2=A0can=C2=A0be used = to validate cryptographic assertions". It is merely a statement by the AS that "the subject corresponding = to the reference has a DID" ("has" is the ass= ertion here).=C2=A0

Yes I understand to drill down on this more though couldn't the entire request made by the client to the AS also be considered to be an assertion? Therefore the=C2=A0"sub_ids" request element is an assert= ion by the client about who it believes the subject to be identified as? If this is true then to me the "assertions" request element is there for asser= tions that parties other than the client are making about the subject (e.g an id_token).

Thanks,
3D"Mattr =C2=A0
Tobias Looker
Ma= ttr
+64 (0) 27 378 0461
tobias.looker@mattr.global
3D"Mattr 3D"Mattr 3D"Mattr

This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.


On Thu, Mar 11, 2021 at 9:20 AM Fabien Imbault <fabien.imbault@gmail.= com> wrote:
Thanks Justin.

It's good to clarify what we mean= by assertion. I used a more mundane meaning.=C2=A0

I dislike email/phone as security disasters waiting to happen. I get that they are practical.=C2=A0

I think I have what I need to write the PRs based on sub_ids (based on the current draft-07).=C2=A0

Fabien=C2=A0

Le mer. 10 mars 2021 =C3=A0 20:18, Justin Richer <jricher@mit.edu> a =C3=A9crit=C2=A0:
Hi Fabien,

First, thanks for doing the heavy lift of writing this topic up. Of these options, I would strongly prefer option (1). The difference between assertions and identifiers is that an assertion is a fully packaged set of attributes, one of which can be an identifier. They are, generally speaking, cryptographically protected bundles. They=E2=80=99re designed to carry a bu= nch of different information about a user and the authentication event in a form that=E2=80= =99s independently verifiable and auditable. SAML assertions (XML document) and ID Tokens (signed JWTs) are the most common ones we see today, but other formats exist and will keep being invented.=C2=A0

An identifier is a different kind of creature. It is a single statement that identifies the party in question in the context of the party doing the identification. It=E2=80=99s this full context = that the receiver of the identifier needs to interpret it in. When using a federated identity protocol, each RP is going to have :some: kind of local user information store that they=E2=80=99re going to tie into, some fi= eld in a database they=E2=80=99ll key off of. It=E2= =80=99s just never going to be the case that all RPs will be able to use server-provided opaque identifiers for all cases. Account recovery and binding is one such use case where a user-facing identifier like an email address makes a LOT of sense, for one small example. This is an array in the request and response precisely because a user could be known by several different identifiers to a party, and an RP will have a better idea about what kinds of things it wants to correlate against, and it=E2=80=99s up to the AS to provi= de that mapping. I think that if we don=E2=80=99t define a way to describe the format, the =E2=80=9Cas_id=E2=80=9D field is going to get s= tructure back-patched onto it like is being proposed here:


I=E2=80=99m personally not a fan of that app= roach as it mixes the data layering too much, and you end up making guesses about whether a field is meaningful or a pointer. I think GNAP will be much better served by using a data structure for this from the start. DIDs should be another =E2=80=9Cformat=E2=80=9D of t= he subject identifier. I don=E2=80=99t think GNAP should d= efine this format, and I=E2=80=99ve dropped a note to= the SECEVENT mailing list asking about adding DIDs to the subject identifiers draft before it gets published. DIDs are not assertions, even in the cases where they point to fully functional DID documents with user information in them. (And for what it=E2=80=99s worth, I think the OIDC world should also use the SECEVENT draft inside ID Tokens to solve the use case of the draft above).

For the user !=3D RO cases, I think that potentially having a way to signal those two items separately in the request and response could be useful. Right now all the user/subject stuff is about identifying =E2=80= =9Cthe user that=E2=80=99s currently here at the clien= t instance=E2=80=9D, in a variety of forms that t= he client instance and AS can negotiate. If the client or AS has some other notion about who the RO is and how that could be separate from the current user, we could provide a way to signal that like you=E2=80=99re proposin= g below. In my mental model, there are going to be a lot of use cases where the =E2=80=9CRO= =E2=80=9D isn=E2=80=99t known to the client at all, but r= ather to the AS and is based on what the client=E2=80= =99s asking for. So I could identify the current user and ask for a specific medical record, and the AS realizes it has to go bug a particular doctor to approve things directly. This is instead of interacting with the current user and failing in an awkward way when the current user doesn=E2=80= =99t have the rights to do things, but someone else would. But we=E2=80=99d want the system to= be able to detect if the current user is the doctor, so we can just interact with them directly. Does that all track?

=C2=A0=E2=80=94 Justin

On Mar 10, 2021, at 4:10 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hello,

Notice the question mark in the title. Not to be considered as an editor's comment.
This thread intends to provide a detailed comment on the interesting=C2=A0feedback by Kristina= : "I would catch up on the thread = to understand why DIDs are thought to be treated as assertions".
In the chat, I answered: "Hap= py to get the discussion on DIDs. Actually, could be either or, depending on what we intend to do." Let me expand a bit on that= , to make it understandable (didn't have the time during the meeting, unfortunately).

This relates to the items described on slides 20 and 34, which I'll explain further. I'= ;ll highlight as transparently as possible what I think would be the benefits and downsides of each. Both are probably viable options, but they correspond to different scopes and objectives. I'll spend a bit more time on option 2, since it is a different approach compared to the current draft.

1. The first possibility is to use SECEVENT throughout.=C2=A0
In that case, DIDs should be a part of sub_ids (in the core or in the extension registry, depending on what Annabelle's WG decides). More generally, the WG would have to decide which additional sub_ids it needs (as per Yaron's comment)= .

That's obviously the closest t= o what is described in draft-04. It allows a communication of subject information between the client and the AS, by using global identifiers (mail, phone, etc.), or using a local opaque reference=C2=A0- i.e. governed by the AS (that's probably what we would=C2=A0put in the examples, unles= s someone has a better idea - cf issues #16 and #42).=C2=A0

Assertions relate for instance to the proof of presence of the RO. The current draft-04 therefore plans for id_tokens and saml2, maybe there could be other needs later (extension registry).

- Benefits: identifiers are a key component of GNAP, which makes integration easier. Possibly one could choose to use DIDs throughout.
- Downsides: email/phone identifiers will probably be used throughout by most devs (since that's correlation information they=C2=A0have in their user DB). Whi= ch means we should limit what assertions contain, to avoid doing links between weak global identifiers and hopefully stronger assertions. That's not really a problem if it's limited to authentication events mostly (in that perspective, samlv2 could make sense in the core). An assertion is probably a single value then (not an array).=C2=A0 =C2= =A0

Option 1 can be summarized as:=C2=A0

"subject": {
=C2=A0=C2=A0=C2=A0"sub_ids": { }= , = // request and response (SECEVENT -> includ= ing DID possibly)=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=C2=A0=C2=A0=C2= =A0=C2=A0
=C2=A0=C2=A0=C2=A0"assertions": = [ ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request and re= sponse (id_token or samlv2)
}
("hints" do not exist currently, but are partially covered separately via "request.user" / the relevance of "principal&qu= ot;, discussed in the slide, is a question mark too - which is a different discussion on end-user !=3D RO).


2. An alternate possibility is to use SECEVENT only as input/hint
In that case, DIDs should be a part of assertions (which have a different meaning compared to option 1).

The AS only returns an local opaque reference as_ref (while in option 1, it was only one of many possibilities). Its only job is to help the client differentiate the response subject. The AS policy might further define the scope of that reference, as suggested in=C2=A0= https= ://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210, although I personally=C2=A0viewed tha= t by default as=C2=A0(2) "as_id&qu= ot; an identifier locally unique to that AS for all the RSs.

SECEVENTS are still useful as an input, that's what I presented in request.hints.self.sub_ids (but it's the responsibility=C2=A0of t= he AS to match it with its own reference system - from instance from the email to AS's local record XUT2MFM1XBIKJKSDU8Q).=C2=A0Note: sinc= e the slides, a new draft-ietf-secevent-subject-identifie= rs-07 has been published. Notably this includes an opaque identifier, which the client can use to pass the as_ref hint to the AS. Thus we wouldn't need any further additio= n to SECEVENT,=C2=A0although hints woul= d benefit from further additions (like DIDs for instance). Notice also that subject_types_supported becomes less important, because in the worst case scenario, it's simply=C2=A0a hint that wouldn't = be understood and therefore taken into account by the AS.

The assertions array has a more important role than in option 1 (with the explicit aim of separating between client hints and validated info asserted by the AS). It serves as a generic/extendible mapping structure, e.g. "the AS asserts that opaque reference=C2=A0XUT2MFM1XBIKJKSDU8Q= =C2=A0is matching with these (more or less verifiable) statements." The nam= e assertion therefore corresponds to the responsibility=C2=A0of the AS in delivering those statements (cf should/must, issue #49). Some of these statements relate to identity or auth events (ex: DID, id_token), some might directly be useful for authorization decisions (like ZKP example in the parental control example). Possibly some of these validated assertions could be reused in next interactions.

Another question that popped-up is the scope of sub_ids. Should they be about the same user? (I think so). In the case of remote ROs especially, it might be important that DID be considered as an assertion=C2=A0(about someone else's) and not as sub_ids, because the AS needs to be careful about who the client wants to reach (avoid spam, etc.). This is consistent with the rest of discussion on what to do when end-user !=3D RO, although using DIDComm might seem a bit early (the paint is very fresh).=C2=A0

Option 2 was summarized as:=C2=A0<= /div>

// (suggestion only, not as = an editor)
"subject": {
=C2=A0=C2=A0=C2=A0"as_ref": { // response = only (wouldn=E2=80=99t require SECEVENT)
=E2=80=9Cas=E2=80=9D: =E2= =80=9Chttps://ex1.as.com=E2=80=9D= , =
=E2=80=9Cref=E2=80=9D: =E2= =80=9CXU= T2MFM1XBIKJKSDU8QM=E2=80=9D=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=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"assertions": [ = ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request and resp= onse (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validated by= the AS)
=C2=A0=C2=A0=C2=A0"hints": { =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = // request only (optional)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"se= lf": { // replaces request.user (support SECEVENT here)
=C2=A0=C2=A0=C2=A0=E2=80= =9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque in draft-07 - that could cont= ain the ref)
=C2=A0=C2=A0=C2=A0=E2=80=9C= assertions=E2=80=9D: [ ] // see examples: VC on DOB or ZKP on ag= e (wider scope, possibly through extensions)
},=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=C2=A0=C2= =A0=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"pr= incipal": { // new proposal presented at IE= TF110 (just an idea)
=C2=A0= =E2=80=9Cautomated=E2=80=9D: true, // rule engine
=C2=A0= =E2=80=9Casync=E2=80=9D: { } // remote ROs
}=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<= /div>
=C2=A0=C2=A0=C2=A0}
}

- Benefits: as_ref is self supporting (no strong coupling with SECEVENT), but can still take SECEVENT as an input hint for the AS. It avoids the risk of making an official association between a weak global identifier (e.g. email, used elsewhere) and hopefully stronger local assertions. GNAP would be fully agnostic to whatever identity system is used, only facilitating interoperability through assertions (second only in importance=C2=A0compared to the AS opaque reference). Some assertions (possibly extensions) could also be useful for the AS decision (e.g. VC or ZKP).
- Downsides: opaqueness of as_ref is a feature, not a bug. The opaque reference is fully managed by the AS, therefore not inherently portable (cf portability discussions in OIDC currently). There's no explicit binding to an official identity, only a contextual mapping to AS validated assertions. It makes it more difficult to match the identifiers from one AS to another or to correlate with the client user DB (still possible via assertions, if the AS allows it). Assertions are much more generic (possibly via extensions), but might require a more advanced mechanism=C2=A0to request/response on= ly the most relevant information (which makes the AS policy critical here).

I hope that clarifies the=C2=A0reasoning for both options. Again I'm not saying option 2 is better, just saying the trade-offs are different (+ knowing that we need to keep it simple).
- option 1 puts more in sub_ids and less in assertions
- option 2 puts less in the reference and more in assertions=C2= =A0
All of this is open to discussion. More generally speaking, on every part in orange and question mark (?) I would love your ideas and criticisms. What I intended as an editor is only to highlight where the WG has important choices to make, before we can make the related PRs.

A further side comment: IETF EAT RATS was suggested for assertions, but relates more to the client attestations. It was added as a comment in=C2=A0https= ://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, which is a distinct topic we'll work on.

Fabien (editor's hat off)

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


--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailma= n/listinfo/txauth

This communication, in=
cluding any attachments, is confidential. If you are not the intended recip=
ient, you should not read it - please contact me immediately, destroy it, a=
nd do not copy or use any part of this communication or disclose anything a=
bout it. Thank you. Please note that this communication does not designate =
an information system for the purposes of the Electronic Transactions Act 2=
002.



--000000000000d906eb05bd51ad8a-- From nobody Fri Mar 12 09:07:48 2021 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 13F223A162D for ; Fri, 12 Mar 2021 09:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Zi3ClFmJgLmB for ; Fri, 12 Mar 2021 09:07:44 -0800 (PST) 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 6312A3A1609 for ; Fri, 12 Mar 2021 09:07:43 -0800 (PST) Received: from [192.168.1.22] (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 12CH7fJZ019788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 12 Mar 2021 12:07:42 -0500 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_5E4F3BC4-C90E-4696-9B1F-E10EE96CA2A6" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <205ACFE1-7D4C-4D7C-B394-4AD8A4D4D080@mit.edu> Date: Fri, 12 Mar 2021 12:07:41 -0500 To: GNAP Mailing List X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [GNAP] GNAP Architecture and the role of the AS X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2021 17:07:47 -0000 --Apple-Mail=_5E4F3BC4-C90E-4696-9B1F-E10EE96CA2A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As discussed at the IETF meeting, the editors proposed that one of our = next big topic areas was going to be the nature of the AS role within = the GNAP protocol, especially how it relates to the device-driven use = cases that have been brought up. Apologies in advance for the long post, = but there are a lot of parts to this discussion that I=E2=80=99m hoping = we can kick off here. My core proposal is that we see the AS as the component that has the = following properties: - receives delegation requests from the client instance for access to = an RS via access tokens, and for access to subject information returned = directly to the client instance - collects consent and authorization from the RO for the delegation - issues access tokens that its downstream RS=E2=80=99s can interpret = (and validate/accept) - issues subject information asserted by the AS=20 This framing of the parties is really important in making a consistent = understanding of how the protocol works, and a consistent understanding = is vital if we=E2=80=99re going to function as a working group in both = discussing the problem space and executing the solution space. For a = historical example, a naive approach to adding identity on top of a = protocol like OAuth 2 (or GNAP) is to declare that the resource server = is the thing the user is logging in to. This seems reasonable at first = (and some people tried doing this) but it violates all kinds of trust = boundaries and puts new expectations on the different parties that do = not make sense. It stops looking anything like OAuth very quickly and = turns into another protocol. If instead we say the user is logging in to = the client, things suddenly make a lot more sense and we can do a lot = more with it. (See this blog post from 2013 for one take on that = discussion: = https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/ = ) I think we=E2=80=99ve got a similar situation here when we start to talk = about the user bringing their own AS with them. I think this is a = reasonable-seeming assumption but it=E2=80=99s based on a false premise = that the RO has to log into the AS to approve the request, and the AS = has full control and view over everything in the network. While OAuth = doesn=E2=80=99t require this, it=E2=80=99s largely assumed that=E2=80=99s = how it works. After all, all of the early OAuth deployments worked = exactly this way: the user logs in and clicks the =E2=80=9COK=E2=80=9D = button. However, cloud deployments have shown us that it=E2=80=99s = perfectly reasonable for an OAuth AS to take in its consent and user = information from an external trusted source, and so this model is not = even accurate in OAuth. In short, I think we can do a better job here of defining things in = terms that both accept the reality we face and enable new ideas in ways = that make sense. It=E2=80=99s my stance that the user shouldn=E2=80=99t = need to bring the AS with them in order to have the kind of input and = control of the system that people are asking for. Instead, the AS should = be able to take inputs from things that the user controls in order for = the AS to do its job. People have discussed privacy concerns with the AS knowing =E2=80=9Ctoo = much=E2=80=9D, but in many of those discussions the knowledge is simply = pushed to the RS instead. What I=E2=80=99m observing here is really just = pushing portions of the AS role into the =E2=80=9CRS=E2=80=9D = deployment. This doesn=E2=80=99t make it less of an =E2=80=9CAS=E2=80=9D = role, it=E2=80=99s just being fulfilled closely to where the RS role is = fulfilled. As such, my proposal is really not that different in = practice, but the labels are different and better aligned with the = capabilities of the protocol.=20 We=E2=80=99ve previously talked about separating the user-facing = portions of the AS into another component, and I think now might be the = time to do that. This is a very flammable strawman proposal, but what if = we had the AS defined, as above, and the =E2=80=9Cconsent and = authorization=E2=80=9D gathering portion is augmented by another named = component. Here let=E2=80=99s call it an Interaction Component. This can = take several forms based on the kind of interaction mode in use: - Hosted at a URL the user is redirected to; it can then make the user = log in, consent, and whatever else they need to do - Hosted at a URL the user will load separately and enter in an access = code - An app on the user=E2=80=99s device that the user interacts with = directly and which sends information back to the AS - An app reachable by a messaging endpoint that the AS sends and = receives structured information from - The client itself that is given an indication as to what information = the AS needs in order to fulfill the request; this could be MFA = challenge/response, user credentials, signed claims, etc. It=E2=80=99s the AS=E2=80=99s job to accept any and all of these that it = supports and churn those into an access token.=20 The AS itself doesn=E2=80=99t ever need to have the user log in. The AS = doesn=E2=80=99t necessarily need to even know who the user is in any = way. The AS just needs to know from a trusted source that the request is = approved. =46rom a practical standpoint, I think this will have some small changes = in how we talk about the components and how we talk about the = interaction phase of the grant negotiation process. Everything I=E2=80=99m= laying out here is currently allowed by the spec, but I think we=E2=80=99= ve carried through the same assumptions from OAuth 2 about deployment = that are both inaccurate and confusing.=20 =E2=80=94 Justin= --Apple-Mail=_5E4F3BC4-C90E-4696-9B1F-E10EE96CA2A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 As = discussed at the IETF meeting, the editors proposed that one of our next = big topic areas was going to be the nature of the AS role within the = GNAP protocol, especially how it relates to the device-driven use cases = that have been brought up. Apologies in advance for the long post, but = there are a lot of parts to this discussion that I=E2=80=99m hoping we = can kick off here.

My = core proposal is that we see the AS as the component that has the = following properties:
 - receives delegation = requests from the client instance for access to an RS via access tokens, = and for access to subject information returned directly to the client = instance
 - collects consent and authorization = from the RO for the delegation
 - issues = access tokens that its downstream RS=E2=80=99s can interpret (and = validate/accept)
 - issues subject information = asserted by the AS 

This framing of the parties is really = important in making a consistent understanding of how the protocol = works, and a consistent understanding is vital if we=E2=80=99re going to = function as a working group in both discussing the problem space and = executing the solution space. For a historical example, a naive approach = to adding identity on top of a protocol like OAuth 2 (or GNAP) is to = declare that the resource server is the thing the user is logging in to. = This seems reasonable at first (and some people tried doing this) but it = violates all kinds of trust boundaries and puts new expectations on the = different parties that do not make sense. It stops looking anything like = OAuth very quickly and turns into another protocol. If instead we say = the user is logging in to the client, things suddenly make a lot more = sense and we can do a lot more with it. (See this blog post from 2013 = for one take on that discussion: https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sig= n-in-4/)

I = think we=E2=80=99ve got a similar situation here when we start to talk = about the user bringing their own AS with them. I think this is a = reasonable-seeming assumption but it=E2=80=99s based on a false premise = that the RO has to log into the AS to approve the request, and the AS = has full control and view over everything in the network. While OAuth = doesn=E2=80=99t require this, it=E2=80=99s largely assumed that=E2=80=99s = how it works. After all, all of the early OAuth deployments worked = exactly this way: the user logs in and clicks the =E2=80=9COK=E2=80=9D = button. However, cloud deployments have shown us that it=E2=80=99s = perfectly reasonable for an OAuth AS to take in its consent and user = information from an external trusted source, and so this model is not = even accurate in OAuth.

In short, I think we can do a better job here of defining = things in terms that both accept the reality we face and enable new = ideas in ways that make sense. It=E2=80=99s my stance that the user = shouldn=E2=80=99t need to bring the AS with them in order to have the = kind of input and control of the system that people are asking for. = Instead, the AS should be able to take inputs from things that the user = controls in order for the AS to do its job.

People have discussed privacy concerns = with the AS knowing =E2=80=9Ctoo much=E2=80=9D, but in many of those = discussions the knowledge is simply pushed to the RS instead. What I=E2=80= =99m observing here is really just pushing portions of the AS role into = the =E2=80=9CRS=E2=80=9D deployment. This doesn=E2=80=99t make it less = of an =E2=80=9CAS=E2=80=9D role, it=E2=80=99s just being fulfilled = closely to where the RS role is fulfilled. As such, my proposal is = really not that different in practice, but the labels are different and = better aligned with the capabilities of the = protocol. 

We=E2=80=99ve previously talked about separating the = user-facing portions of the AS into another component, and I think now = might be the time to do that. This is a very flammable strawman = proposal, but what if we had the AS defined, as above, and the = =E2=80=9Cconsent and authorization=E2=80=9D gathering portion is = augmented by another named component. Here let=E2=80=99s call it an = Interaction Component. This can take several forms based on the kind of = interaction mode in use:

 - Hosted at a URL the user is redirected to; it can = then make the user log in, consent, and whatever else they need to = do
 - Hosted at a URL the user will load = separately and enter in an access code
 - An = app on the user=E2=80=99s device that the user interacts with directly = and which sends information back to the AS
 - = An app reachable by a messaging endpoint that the AS sends and receives = structured information from
 - The client = itself that is given an indication as to what information the AS needs = in order to fulfill the request; this could be MFA challenge/response, = user credentials, signed claims, etc.

It=E2=80=99s the AS=E2=80=99s job to = accept any and all of these that it supports and churn those into an = access token. 

The AS itself doesn=E2=80=99t ever need to have the user log = in. The AS doesn=E2=80=99t necessarily need to even know who the user is = in any way. The AS just needs to know from a trusted source that the = request is approved.

=46rom a practical standpoint, I think this will have some = small changes in how we talk about the components and how we talk about = the interaction phase of the grant negotiation process. Everything I=E2=80= =99m laying out here is currently allowed by the spec, but I think = we=E2=80=99ve carried through the same assumptions from OAuth 2 about = deployment that are both inaccurate and confusing. 

 =E2=80=94 = Justin
= --Apple-Mail=_5E4F3BC4-C90E-4696-9B1F-E10EE96CA2A6-- From nobody Fri Mar 12 09:23:20 2021 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 8A1643A182C for ; Fri, 12 Mar 2021 09:23:12 -0800 (PST) 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 hLw2tvUpftEr for ; Fri, 12 Mar 2021 09:23:10 -0800 (PST) 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 DC6D93A182A for ; Fri, 12 Mar 2021 09:23:09 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id z13so26516285iox.8 for ; Fri, 12 Mar 2021 09:23:09 -0800 (PST) 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=2AzLnGV/3W0P+eXXc31QJu9lQok3JuXS8Ibdc5L/iO8=; b=LdhFnFCiu8h7KaR3mvNb9RHVzmlfkEFIpohCAfs7Zqq+9PZFPNoVflwcmxlNW872CM H1E/v5LnrrsJwgnUuTOsscAGMm19iMkqUxZISSZDwEcqxIVq8s/CJxPyH6HDLqBw6QDS 4YFVLPfi4+v/g6x7u6Ok7WhNLgtI1IheBg2OSgfBL8UOaBhnVibkxTtFnatCmfwGeVlY W5CnamXCVP13uFtIjZfhOuDaYUsy4oMGU7380S+iH9ugVXhg62rkgkzSl/zQz5pUJHOF 3WgWDQehOyx4eSN+IyfOT2Gg1XXSV4/dbZDO2DaYCDwUqEczMSXeiep02CbZP/V+TTeZ kjtg== 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=2AzLnGV/3W0P+eXXc31QJu9lQok3JuXS8Ibdc5L/iO8=; b=IM3Wg4DKVhWZXcTx0xJTJgdSRXcjB0cCuaxriknK4oCpTe34yEl5ytwa6ZcPu2/VAp JAi/668HGmnbTFfIJkGCerCMgljeeijImegaEMbpT8SZdfghtTb65y/9dK9FfKuGB0Z4 u3NrKf1KwcN+o1s5Gfx67sNEZR4E88KTK9dmZmqmCHM6/a7dokmfQhGgoz3bj3ip8Ut3 YSYSzXvvTz+KnQKZegvpWfIekRWfzd/vKYHRDU8vnGtuLj06qZZIETPKosopDh9kf8pg Wet2YoggkfKXX/0Xcaep2Pu5sAKXFY21W7DzaxcuNXiM9H4z/2j2AAzoMEJl7rebjeIs TL8w== X-Gm-Message-State: AOAM530JwNyxNeroMAqqeXwrvS1eJpvsjVVYiCXHyMuAspHIi70Yzbry Nr9gWEl06W41gJKuBroFi3Mv3OkbdkjK8m9qkAU= X-Google-Smtp-Source: ABdhPJw4uAttyobym7PyYcncfrBn+Z0IT5AIumtc8VKCb40LWGzOjdApPnAgUVv+YeRUzpR6poHpBZS10mJZyzW4yrQ= X-Received: by 2002:a02:c6b4:: with SMTP id o20mr302212jan.124.1615569787399; Fri, 12 Mar 2021 09:23:07 -0800 (PST) MIME-Version: 1.0 References: <205ACFE1-7D4C-4D7C-B394-4AD8A4D4D080@mit.edu> In-Reply-To: <205ACFE1-7D4C-4D7C-B394-4AD8A4D4D080@mit.edu> From: Fabien Imbault Date: Fri, 12 Mar 2021 18:22:56 +0100 Message-ID: To: Justin Richer Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000049c73a05bd5a2754" Archived-At: Subject: Re: [GNAP] GNAP Architecture and the role of the AS X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2021 17:23:19 -0000 --00000000000049c73a05bd5a2754 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Justin, Just a quick word to say I very much agree with both the observations and the framing. Fabien On Fri, Mar 12, 2021 at 6:07 PM Justin Richer wrote: > As discussed at the IETF meeting, the editors proposed that one of our > next big topic areas was going to be the nature of the AS role within the > GNAP protocol, especially how it relates to the device-driven use cases > that have been brought up. Apologies in advance for the long post, but > there are a lot of parts to this discussion that I=E2=80=99m hoping we ca= n kick off > here. > > My core proposal is that we see the AS as the component that has the > following properties: > - receives delegation requests from the client instance for access to an > RS via access tokens, and for access to subject information returned > directly to the client instance > - collects consent and authorization from the RO for the delegation > - issues access tokens that its downstream RS=E2=80=99s can interpret (a= nd > validate/accept) > - issues subject information asserted by the AS > > This framing of the parties is really important in making a consistent > understanding of how the protocol works, and a consistent understanding i= s > vital if we=E2=80=99re going to function as a working group in both discu= ssing the > problem space and executing the solution space. For a historical example,= a > naive approach to adding identity on top of a protocol like OAuth 2 (or > GNAP) is to declare that the resource server is the thing the user is > logging in to. This seems reasonable at first (and some people tried doin= g > this) but it violates all kinds of trust boundaries and puts new > expectations on the different parties that do not make sense. It stops > looking anything like OAuth very quickly and turns into another protocol. > If instead we say the user is logging in to the client, things suddenly > make a lot more sense and we can do a lot more with it. (See this blog po= st > from 2013 for one take on that discussion: > https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/) > > I think we=E2=80=99ve got a similar situation here when we start to talk = about the > user bringing their own AS with them. I think this is a reasonable-seemin= g > assumption but it=E2=80=99s based on a false premise that the RO has to l= og into > the AS to approve the request, and the AS has full control and view over > everything in the network. While OAuth doesn=E2=80=99t require this, it= =E2=80=99s largely > assumed that=E2=80=99s how it works. After all, all of the early OAuth de= ployments > worked exactly this way: the user logs in and clicks the =E2=80=9COK=E2= =80=9D button. > However, cloud deployments have shown us that it=E2=80=99s perfectly reas= onable for > an OAuth AS to take in its consent and user information from an external > trusted source, and so this model is not even accurate in OAuth. > > In short, I think we can do a better job here of defining things in terms > that both accept the reality we face and enable new ideas in ways that ma= ke > sense. It=E2=80=99s my stance that the user shouldn=E2=80=99t need to bri= ng the AS with > them in order to have the kind of input and control of the system that > people are asking for. Instead, the AS should be able to take inputs from > things that the user controls in order for the AS to do its job. > > People have discussed privacy concerns with the AS knowing =E2=80=9Ctoo m= uch=E2=80=9D, but > in many of those discussions the knowledge is simply pushed to the RS > instead. What I=E2=80=99m observing here is really just pushing portions = of the AS > role into the =E2=80=9CRS=E2=80=9D deployment. This doesn=E2=80=99t make = it less of an =E2=80=9CAS=E2=80=9D role, > it=E2=80=99s just being fulfilled closely to where the RS role is fulfill= ed. As > such, my proposal is really not that different in practice, but the label= s > are different and better aligned with the capabilities of the protocol. > > We=E2=80=99ve previously talked about separating the user-facing portions= of the > AS into another component, and I think now might be the time to do that. > This is a very flammable strawman proposal, but what if we had the AS > defined, as above, and the =E2=80=9Cconsent and authorization=E2=80=9D ga= thering portion is > augmented by another named component. Here let=E2=80=99s call it an Inter= action > Component. This can take several forms based on the kind of interaction > mode in use: > > - Hosted at a URL the user is redirected to; it can then make the user > log in, consent, and whatever else they need to do > - Hosted at a URL the user will load separately and enter in an access > code > - An app on the user=E2=80=99s device that the user interacts with direc= tly and > which sends information back to the AS > - An app reachable by a messaging endpoint that the AS sends and receive= s > structured information from > - The client itself that is given an indication as to what information > the AS needs in order to fulfill the request; this could be MFA > challenge/response, user credentials, signed claims, etc. > > It=E2=80=99s the AS=E2=80=99s job to accept any and all of these that it = supports and > churn those into an access token. > > The AS itself doesn=E2=80=99t ever need to have the user log in. The AS d= oesn=E2=80=99t > necessarily need to even know who the user is in any way. The AS just nee= ds > to know from a trusted source that the request is approved. > > From a practical standpoint, I think this will have some small changes in > how we talk about the components and how we talk about the interaction > phase of the grant negotiation process. Everything I=E2=80=99m laying out= here is > currently allowed by the spec, but I think we=E2=80=99ve carried through = the same > assumptions from OAuth 2 about deployment that are both inaccurate and > confusing. > > =E2=80=94 Justin > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000049c73a05bd5a2754 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Justin,=C2=A0

Just a quick word to s= ay I very much agree with both the observations and the framing.
=
Fabien

 --00000000000028f1c605bd66c629-- From nobody Sun Mar 14 00:36:10 2021 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 09B563A1F8B for ; Sun, 14 Mar 2021 00:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.819 X-Spam-Level: X-Spam-Status: No, score=-2.819 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=mnot.net header.b=tocDQ6Ix; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QCUpu6ZL 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 eisQNayye30k for ; Sun, 14 Mar 2021 00:36:02 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DDB63A1F8C for ; Sun, 14 Mar 2021 00:36:02 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 4B46F17CA for ; Sun, 14 Mar 2021 03:38:49 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 14 Mar 2021 03:38:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=nfuhkUJLPCG2Few1Cb2Cx1LVDXVP6QHipu2qf33XMHI=; b=tocDQ6Ix djTyX7OLtP8Km0A9RYl79K4BwZBkCEQA2RajOUunm+PoJA29lDpkv4JeR9QAcr2C 9RH3DNG2QfNhl/GthRUeQL1z/1b81nhe9l3wzqqGwQ755B1N+cyFo9ah9No8uso0 atz9LH0noJsU4b23T8cwusG1eR7Ly46z43NVCt3s/6+WK7qcXcmhkTfGJL1SzBSr 5hLdI8ysp2aK5hkqJFH+b5MCji5dCOJBrDFt4/AFfCngi8ZIMTdW627OGeaQVZ4z 3dvlPREhNOC4Uc1z5HZHHgDsof1gXrZP3+Wq0PGIutLlUMysh7cL95EW6Lcb/Rfd mxKcBm10rSAwxw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=nfuhkUJLPCG2Few1Cb2Cx1LVDXVP6 QHipu2qf33XMHI=; b=QCUpu6ZLeitYmZxu2tK1DSnqmMXXfCUkBpZLYv+ywdQxB 8sd1Mgg2aLARx5rrYSc3N3rjEqZg/xakVbK1NZCZEzN/r6wNIgYIpeanTicTJEqr ycIZDBP93F1m5/XrIuS1b2RUVAcj6iyVlRN4Lgdlj/tJHQDG6qNaiNDg0jqroP16 FLA3/5utuFmJEWDWSl7WO2z8W9HDIAzn3IB8/H0Rva7pokVVo39yugRs1Ip/OMkv IB5R4LlfDXay2tkkfPf8B4rF/q3yMPHA6E4bAx+S/6so/vhSZ0TGT0kBnWZiA0Ax Mupqkt2HF/B8Dg/KvwSFflasBZUQaOz1XwS3VJBqA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddvhedgkeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphepvdefrddutddurddugeehrd dujedunecuvehluhhsthgvrhfuihiivgepkeenucfrrghrrghmpehmrghilhhfrhhomhep ughopghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az207-156.internal.cloudapp.net (unknown [23.101.145.171]) by mail.messagingengine.com (Postfix) with ESMTPA id BE6AE240057 for ; Sun, 14 Mar 2021 03:38:48 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============2016520444077600778==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20210314073848.BE6AE240057@mailuser.nyi.internal> Date: Sun, 14 Mar 2021 03:38:48 -0400 (EDT) Archived-At: Subject: [GNAP] Weekly github digest (GNAP Weekly GitHub Activity Summary) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Mar 2021 08:36:04 -0000 --===============2016520444077600778== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * ietf-wg-gnap/core-protocol (+5/-0/=F0=9F=92=AC23) 5 issues created: - User choice and consent, and user notice (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/215=20 - Trust relationships (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/214=20 - Definition and roles of a Resource Owner (RO) (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/213=20 - Definition of a Resource Server (RS) (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/212=20 - "sub_id" claims (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210=20 7 issues received 23 new comments: - #215 User choice and consent, and user notice (5 by agropper, fimbault,= jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/215=20 - #214 Trust relationships (3 by agropper, fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/214=20 - #213 Definition and roles of a Resource Owner (RO) (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/213=20 - #212 Definition of a Resource Server (RS) (2 by fimbault, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/212=20 - #210 "sub_id" claims (2 by Denisthemalice, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210=20 - #145 Opaque / Non opaque access token (9 by Denisthemalice, agropper, f= imbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145=20 - #44 Client attestation and posture (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44=20 Pull requests ------------- * ietf-wg-gnap/core-protocol (+3/-0/=F0=9F=92=AC9) 3 pull requests submitted: - updated diagrams, included subject-only flow (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/211=20 - These examples of not sender-constrained tokens. Hence, the "bound" v= =E2=80=A6 (by adeinega) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/209=20 - Minor changes on the language in section "Presenting Access Tokens". (b= y adeinega) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/208=20 3 pull requests received 9 new comments: - #211 updated diagrams, included subject-only flow (3 by jricher, netlif= y) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/211=20 - #209 These are examples of not sender-constrained tokens. Hence, the "b= ound" v=E2=80=A6 (3 by adeinega, netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/209=20 - #208 Minor changes on the language in section "Presenting Access Tokens= ". (3 by adeinega, netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/208=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol --===============2016520444077600778== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (GNAP Weekly GitHub Activity Summary)

Sunday March 14, 2021

Events without label "editorial"

Issues

ietf-wg-gnap/core-protocol (+5/-0/=F0=9F=92=AC23)

5 issues created:

7 issues received 23 new comments:

Pull requests

ietf-wg-gnap/core-protocol (+3/-0/=F0=9F=92=AC9)

3 pull requests submitted:

3 pull requests received 9 new comments:

Repositories tracked by this digest:

--===============2016520444077600778==-- From nobody Mon Mar 15 02:24:16 2021 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 645213A0EFF for ; Mon, 15 Mar 2021 02:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.055 X-Spam-Level: X-Spam-Status: No, score=-1.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001, URI_WP_DIRINDEX=0.063] 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 atuY8W21H57A for ; Mon, 15 Mar 2021 02:24:10 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp08.smtpout.orange.fr [80.12.242.130]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 111953A0EFA for ; Mon, 15 Mar 2021 02:24:09 -0700 (PDT) Received: from [192.168.1.11] ([90.79.53.231]) by mwinf5d67 with ME id gZQ52400Y4zJUWJ03ZQ7mj; Mon, 15 Mar 2021 10:24:08 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Mon, 15 Mar 2021 10:24:08 +0100 X-ME-IP: 90.79.53.231 To: Justin Richer , GNAP Mailing List References: <205ACFE1-7D4C-4D7C-B394-4AD8A4D4D080@mit.edu> From: Denis Message-ID: <8cf9f884-5c17-bb5d-006d-c684d75be867@free.fr> Date: Mon, 15 Mar 2021 10:24:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <205ACFE1-7D4C-4D7C-B394-4AD8A4D4D080@mit.edu> Content-Type: multipart/alternative; boundary="------------B8FA32882240C88685B36891" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] GNAP Architecture and the role of the AS X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2021 09:24:14 -0000 This is a multi-part message in MIME format. --------------B8FA32882240C88685B36891 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Justin, My comments are between the lines. > As discussed at the IETF meeting, the editors proposed that one of our > next big topic areas was going to be the nature of the AS role within > the GNAP protocol, > especially how it relates to the device-driven use cases that have > been brought up. Apologies in advance for the long post, but there are > a lot of parts > to this discussion that I’m hoping we can kick off here. [Comment from Denis] The "device-driven use cases" are not addressed any further in this email. IMO, they are only possible if/when a secure element with some specific security properties is being used by the end-user and when the AS is able to verify that it is indeed used by the end-user. I am not disputing that this would be an interesting case but ,before going any further, we would have to modify the terms of our charter. > My core proposal is that we see the AS as the component that has the > following properties: > >  - receives delegation requests from the client instance for access to > an RS via access tokens, >    and for access to subject information returned directly to the > client instance > >  - collects consent and authorization from the RO for the delegation [Comment from Denis] The RO on the AS side is an optional component. >  - issues access tokens that its downstream RS’s can interpret (and > validate/accept) [Comment from Denis] This sentence must remain true whether or not the AS and the RS have established a prior relationship. When there is no prior relationship between an AS and a RS, the RS must be able to disclose to the Client, the access token format(s), as well as the crypto algorithms, it supports. In the same way, the AS must be able to disclose to the Client, the access token format(s), as well as the crypto algorithms, it supports. If there is no match, it is unnecessary to continue the exchanges. It is important to mention that the access token contains privileges, i.e. end-user attributes or/and rights. * When end-user attributes are contained into an access token, it is possible to implement on the RS side an ABAC or a RBAC or an IBAC. * When rights are contained into an access token, it is possible to implement on the RS side a capability model. A major difference between these two models is the point from which the access control rules are administered: * When end-user attributes are contained into an access token, the administration of the access control rules is only done by a Resource Owner sitting on the RS side. * When rights are contained into an access token, the administration of the access control rules is primally done by a Resource Owner sitting on the AS side but is also controlled by another by a Resource Owner sitting on the RS side which establishes the trust conditions. >  - issues subject information asserted by the AS [Comment from Denis] Still the same difficulty about the use of the term "subject" which remains unsolved, this sentence is ambiguous: is the "end-user" information placed into an access token ? > This framing of the parties is really important in making a consistent > understanding of how the protocol works, and a consistent > understanding is vital > if we’re going to function as a working group in both discussing the > problem space and executing the solution space. For a historical example, > a naive approach to adding identity on top of a protocol like OAuth 2 > (or GNAP) is to declare that the resource server is the thing the user > is logging in to. > This seems reasonable at first (and some people tried doing this) but > it violates all kinds of trust boundaries and puts new expectations on > the different parties > that do not make sense. It stops looking anything like OAuth very > quickly and turns into another protocol. If instead we say the user is > logging in to the client, > things suddenly make a lot more sense and we can do a lot more with > it. (See this blog post from 2013 for one take on that discussion: > https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/ > ) [Comment from Denis] This link does not work. After 10 minutes of search, here is the appropriate link: /https://www.cloudidentity.com/blog/?p=251/ to be able to access to this very looooong article (this will take you more than 30 minutes to read). [Comment from Denis] GNAP and OAuth 2.0 are both authorization frameworks, i.e. they are NOT authentication protocols. An authorization may be given to a "calling application", called the "client" in our draft. Before obtaining a response when calling an API, a Resource Server (RS) MAY mandate to authenticate the end-user. In such a case, if no authentication exchange has successfully taken place, it will return the error /401 Unauthorized/, which is the HTTP status code for authentication errors: it’s for authentication, not authorization. Receiving a 401 response is the server telling you, “you, as an end-user, aren’t authenticated–either not authenticated at all or authenticated incorrectly–but please re-authenticate and try again.” To help you out, it will always include a /WWW-Authenticate/ header that describes how to authenticate. The long post from 2013 contains one important sentence : " OAuth is interested in what takes place AFTER authentication," which means that an authentication MAY happen BEFORE OAuth takes place.This clearly means that an authentication exchange MAY exist. Unfortunately this is currently not mentioned in the draft, whereas it should be described in the draft. This raises an interesting question which has been left aside. What is the relationship (if any) between the end-user identifier used for an authentication exchange and a "sub-id" claim or a "sub" claim present inside an access token ? The long post from 2013 contains another important sentence : "keeping AS and RS under the same roof is baked in OAuth’s common usage, if not the spec itself." This is true. In GNAP, this assumption is no more valid as the ASs and the RSs are not necessarily any more "under the same roof". > I think we’ve got a similar situation here when we start to talk about > the user bringing their own AS with them. I think this is a > reasonable-seeming assumption > but it’s based on a false premise that the RO has to log into the AS > to approve the request, and the AS has full control and view over > everything in the network. > While OAuth doesn’t require this, it’s largely assumed that’s how it > works. After all, all of the early OAuth deployments worked exactly > this way: the user logs in > and clicks the “OK” button. However, cloud deployments have shown us > that it’s perfectly reasonable for an OAuth AS to take in its consent > and user information > from an external trusted source, and so this model is not even > accurate in OAuth. [Comment from Denis] It is more important to explain first how GNAP will work rather than stating what's wrong in OAuth. > In short, I think we can do a better job here of defining things in > terms that both accept the reality we face and enable new ideas in > ways that make sense. > It’s my stance that the user shouldn’t need to bring the AS with them > in order to have the kind of input and control of the system that > people are asking for. > Instead, the AS should be able to take inputs from things that the > user controls in order for the AS to do its job. [Comment from Denis] The writer surely understands what this means, but not me. > People have discussed privacy concerns with the AS knowing “too much”, > but in many of those discussions the knowledge is simply pushed to the > RS instead. [Comment from Denis] There is no argument to explain "how the knowledge is simply pushed to the RS instead". During the last IETF GNAP meeting, I presented some slides enumerating various privacy properties while comparing access control scheme based on ACLs versus access control schemes based on capabilities (i.e. rights): 1)*Unlinkeability between RS user accounts *: Two RSs should not be able to link their user accounts, by using the content of the access tokens they receive     from the same AS or from different ASs. 2) *AS-RS untraceability:* The AS is unable to know for which RS an issued access token is targeted. 3)*AS-Client Operation/Method hiding*: The AS is unable to know which Operation/Method will be performed by the client on which object of a RS. 4)*AS-Client access time invisibility : *The AS is unable to know exactly when an issued access token will be consumed by a RS. 5) *End-user confidence in the system*: The client can verify that the access token contains the requested / adequate privileges and,     if not, it can block the transmission of the access token to the RS. At the moment, the current draft does not list these privacy properties. If it would, it would indicate that the AS is able to know : * for which RS an issued access token is targeted, * which Operation/Method will be performed by the client on which object hosted by the RS, * exactly when an issued access token will be consumed by the RS (as soon as Token Introspection is supported), which means that *the AS would be able to act as a **Big Brother*. In addition if the access tokens are considered to be opaque to the clients, the end-user cannot have confidence that the AS discloses only the requested privileges and no more. *If these properties were advertised to the reader of the draft, which end-users would accept to use such a system which is opaque to the end-users and where the AS is able to act as Big Brother ?* There have been some arguments at the very beginning about the fact that the RO and the end-users were both able to have an account on the AS, because this was implicitly the case with OAuth. The charter states: Although the artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol where possible. This clearly means that GNAP is not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect. Originally, OAuth was invented to deal with the case where the same organization was managing the AS and a set of RSs. What was not explained is that an architecture /_using an AS_ /dealing with capabilities (i.e. rights) allows the AS to know/spy every action from the users on the RSs. There may be good business reasons to do so, but if privacy properties had been taken into consideration it would have been possible to provide the same services without using any AS. Since we don't need to achieve a backwards compatibility, I would say that it is still possible to use OAuth in the case where the RO = the end-user. It would also say that it would still be possible to define an architecture taking into consideration privacy requirements and to define an architecture with any AS to perform operations similar to OAuth. Such an architecture has been defined during the last century, more precisely in July 1988 under the standard ECMA-131 RDT (Referenced Data Transfer). This standard is still available at: /https://www.ecma-international.org/wp-content/uploads/ECMA-131_1st_edition_july_1988.pdf/ > What I’m observing here is really just pushing portions of the AS role > into the “RS” deployment. This doesn’t make it less of an “AS” role, > it’s just being fulfilled > closely to where the RS role is fulfilled. As such, my proposal is > really not that different in practice, but the labels are different > and better aligned with the capabilities > of the protocol. [Comment from Denis] Which proposal ? > We’ve previously talked about separating the user-facing portions of > the AS into another component, and I think now might be the time to do > that. > This is a very flammable strawman proposal, but what if we had the AS > defined, as above, and the “consent and authorization” gathering portion > is augmented by another named component. Here let’s call it an > Interaction Component. [Comment from Denis] First of all, using the privacy vocabulary, this is not “consent and authorization”, but it is "user notice", "user choice" and "user consent". Before making one or more choices, the end-user must be able to be informed about the reasons and /or the consequences of each choice. Then he must be able to make some choice(s) and finally he may indicate his consent for these choices. A key question is: At which moment such "user notice, choice and consent happens ? If an end-user has never contacted a RS before, this happens after a "discovery" flight and BEFORE contacting any AS. Since, there exist some situations where there is a single AS, some people may believe that these choices are the same whether they are made immediately after the first RS call or after the first AS call, and hence that that is is possible to use a same building block for both cases. Unfortunately this is not the case. As soon as a RS is trusting more than one AS, the user choice is first to select the AS(s) after being informed of which privileges are requested/needed by a RS to respond positively on a method performed on an object. Furthermore, as soon as an AS has not established a prior relationship with the RS, an AS is unable to present any choice to the end-user. So, /for the time being/, we should not presume that the functions can be factored and thus it is important to consider, /for the time being/, that *there is no such "Interaction Component"*. > This can take several forms based on the kind of interaction mode in use: > >  - Hosted at a URL the user is redirected to; it can then make the > user log in, consent, and whatever else they need to do >  - Hosted at a URL the user will load separately and enter in an > access code >  - An app on the user’s device that the user interacts with directly > and which sends information back to the AS >  - An app reachable by a messaging endpoint that the AS sends and > receives structured information from >  - The client itself that is given an indication as to what > information the AS needs in order to fulfill the request; this could > be MFA challenge/response, user credentials, signed claims, etc. > > It’s the AS’s job to accept any and all of these that it supports and > churn those into an access token. [Comment from Denis] No. It is not necessarily the AS's job. The AS job is to place into an access token the privileges that have been requested by the client. > The AS itself doesn’t ever need to have the user log in. The AS > doesn’t necessarily need to even know who the user is in any way. > The AS just needs to know from a trusted source that the request is > approved. [Comment from Denis] *No, no and no again for each of these three sentences*. It is rather strange to change the model and the (implicit) trust relationships at this time. I fear that we are following a moving target. When writing the first draft, *the cart has been placed before the horse*, which means that the components of the model, their relationships and their trust relationships have not been defined, and that the protocols have been designed without a clear model and without explaining their rational. > From a practical standpoint, I think this will have some small changes > in how we talk about the components and how we talk about the > interaction phase > of the grant negotiation process. Everything I’m laying out here is > currently allowed by the spec, but I think we’ve carried through the > same assumptions from OAuth 2 > about deployment that are both inaccurate and confusing. [Comment from Denis] The writer surely understands what this means, but not me. Which assumptions from OAuth 2 about deployment are both inaccurate and confusing ? Denis >  — Justin > --------------B8FA32882240C88685B36891 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Justin,

My comments are between the lines.

As discussed at the IETF meeting, the editors proposed that one of our next big topic areas was going to be the nature of the AS role within the GNAP protocol,
especially how it relates to the device-driven use cases that have been brought up. Apologies in advance for the long post, but there are a lot of parts
to this discussion that I’m hoping we can kick off here.

[Comment from Denis] The "device-driven use cases" are not addressed any further in this email. IMO, they are only possible if/when a secure element
with some specific security properties is being used by the end-user and when the AS is able to verify that it is indeed used by the end-user.
I am not disputing that this would be an interesting case but ,before going any further, we would have to modify the terms of our charter.

My core proposal is that we see the AS as the component that has the following properties:

 - receives delegation requests from the client instance for access to an RS via access tokens,
   and for access to subject information returned directly to the client instance

 - collects consent and authorization from the RO for the delegation
[Comment from Denis] The RO on the AS side is an optional component.
 - issues access tokens that its downstream RS’s can interpret (and validate/accept)

[Comment from Denis] This sentence must remain true whether or not the AS and the RS have established a prior relationship.
When there is no prior relationship between an AS and a RS, the RS must be able to disclose to the Client, the access token format(s),
as well as the crypto algorithms, it supports. In the same way, the AS must be able to disclose to the Client, the access token format(s),
as well as the crypto algorithms, it supports. If there is no match, it is unnecessary to continue the exchanges.

It is important to mention that the access token contains privileges, i.e. end-user attributes or/and rights.

  • When end-user attributes are contained into an access token, it is possible to implement on the RS side an ABAC or a RBAC or an IBAC.

  • When rights are contained into an access token, it is possible to implement on the RS side a capability model.

A major difference between these two models is the point from which the access control rules are administered:

  • When end-user attributes are contained into an access token, the administration of the access control rules is only done by a Resource Owner sitting on the RS side.
  • When rights are contained into an access token, the administration of the access control rules is primally done by a Resource Owner sitting on the AS side
    but is also controlled by another     by a Resource Owner sitting on the RS side which establishes the trust conditions.
 - issues subject information asserted by the AS

[Comment from Denis] Still the same difficulty about the use of the term "subject" which remains unsolved, this sentence is ambiguous:
is the "end-user" information placed into an access token ?

This framing of the parties is really important in making a consistent understanding of how the protocol works, and a consistent understanding is vital
if we’re going to function as a working group in both discussing the problem space and executing the solution space. For a historical example,
a naive approach to adding identity on top of a protocol like OAuth 2 (or GNAP) is to declare that the resource server is the thing the user is logging in to.
This seems reasonable at first (and some people tried doing this) but it violates all kinds of trust boundaries and puts new expectations on the different parties
that do not make sense. It stops looking anything like OAuth very quickly and turns into another protocol. If instead we say the user is logging in to the client,
things suddenly make a lot more sense and we can do a lot more with it. (See this blog post from 2013 for one take on that discussion:
https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/)

[Comment from Denis] This link does not work. After 10 minutes of search, here is the appropriate link: https://www.cloudidentity.com/blog/?p=251
to be able to access to this very looooong article (this will take you more than 30 minutes to read).

[Comment from Denis] GNAP and OAuth 2.0 are both authorization frameworks, i.e. they are NOT authentication protocols.  
An authorization may be given to a "calling application", called the "client" in our draft.

Before obtaining a response when calling an API, a Resource Server (RS) MAY mandate to authenticate the end-user.
In such a case, if no authentication exchange has successfully taken place, it will return the error 401 Unauthorized, which is the HTTP status code
for authentication errors: it’s for authentication, not authorization. Receiving a 401 response is the server telling you, “you, as an end-user,
aren’t authenticated–either not authenticated at all or authenticated incorrectly–but please re-authenticate and try again.”
To help you out, it will always include a WWW-Authenticate header that describes how to authenticate.

The long post from 2013 contains one important sentence : " OAuth is interested in what takes place AFTER authentication,"
which means that an authentication MAY happen BEFORE OAuth takes place.  This clearly means that an authentication exchange MAY exist.
Unfortunately this is currently not mentioned in the draft, whereas it should be described in the draft.

This raises an interesting question which has been left aside. What is the relationship (if any) between the end-user identifier used
for an authentication exchange and a "sub-id" claim or a "sub" claim present inside an access token ?

The long post from 2013 contains another important sentence :
"keeping AS and RS under the same roof is baked in OAuth’s common usage, if not the spec itself." This is true.

In GNAP, this assumption is no more valid as the ASs and the RSs are not necessarily any more "under the same roof".

I think we’ve got a similar situation here when we start to talk about the user bringing their own AS with them. I think this is a reasonable-seeming assumption
but it’s based on a false premise that the RO has to log into the AS to approve the request, and the AS has full control and view over everything in the network.
While OAuth doesn’t require this, it’s largely assumed that’s how it works. After all, all of the early OAuth deployments worked exactly this way: the user logs in
and clicks the “OK” button. However, cloud deployments have shown us that it’s perfectly reasonable for an OAuth AS to take in its consent and user information
from an external trusted source, and so this model is not even accurate in OAuth.

[Comment from Denis] It is more important to explain first how GNAP will work rather than stating what's wrong in OAuth.

In short, I think we can do a better job here of defining things in terms that both accept the reality we face and enable new ideas in ways that make sense.
It’s my stance that the user shouldn’t need to bring the AS with them in order to have the kind of input and control of the system that people are asking for.
Instead, the AS should be able to take inputs from things that the user controls in order for the AS to do its job.
[Comment from Denis] The writer surely understands what this means, but not me.
People have discussed privacy concerns with the AS knowing “too much”, but in many of those discussions the knowledge is simply pushed to the RS instead.

[Comment from Denis] There is no argument to explain "how the knowledge is simply pushed to the RS instead". During the last IETF GNAP meeting,
I presented some slides enumerating various privacy properties while comparing access control scheme based on ACLs versus access control schemes based
on capabilities (i.e. rights):

1) Unlinkeability between RS user accounts : Two RSs should not be able to link their user accounts, by using the content of the access tokens they receive
    from the same AS or from different ASs.

2) AS-RS untraceability: The AS is unable to know for which RS an issued access token is targeted.

3) AS-Client Operation/Method hiding: The AS is unable to know which Operation/Method will be performed by the client on which object of a RS.

4) AS-Client access time invisibility : The AS is unable to know exactly when an issued access token will be consumed by a RS.

5) End-user confidence in the system: The client can verify that the access token contains the requested / adequate privileges and,
    if not, it can block the transmission of the access token to the RS.

At the moment, the current draft does not list these privacy properties. If it would, it would indicate that the AS is able to know :

  • for which RS an issued access token is targeted,
  • which Operation/Method will be performed by the client on which object hosted by the RS,
  • exactly when an issued access token will be consumed by the RS (as soon as Token Introspection is supported),
which means that the AS would be able to act as a Big Brother.

In addition if the access tokens are considered to be opaque to the clients, the end-user cannot have confidence that the AS discloses only the requested privileges
and no more.

If these properties were advertised to the reader of the draft, which end-users would accept to use such a system which is opaque to the end-users
and where the AS is able to act as Big Brother ?

There have been some arguments at the very beginning about the fact that the RO and the end-users were both able to have an account on the AS,
because this was implicitly the case with OAuth.

The charter states:

Although the artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect,
the group will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol where possible.

This clearly means that GNAP is not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect.

Originally, OAuth was invented to deal with the case where the same organization was managing the AS and a set of RSs.

What was not explained is that an architecture using an AS dealing with capabilities (i.e. rights) allows the AS to know/spy every action from the users on the RSs.
There may be good business reasons to do so, but if privacy properties had been taken into consideration it would have been possible to provide the same services
without using any AS.

Since we don't need to achieve a backwards compatibility, I would say that it is still possible to use OAuth in the case where the RO = the end-user.

It would also say that it would still be possible to define an architecture taking into consideration privacy requirements and to define an architecture with any AS
to perform operations similar to OAuth. Such an architecture has been defined during the last century, more precisely in July 1988 under the standard ECMA-131
RDT (Referenced Data Transfer). This standard is still available at: https://www.ecma-international.org/wp-content/uploads/ECMA-131_1st_edition_july_1988.pdf

What I’m observing here is really just pushing portions of the AS role into the “RS” deployment. This doesn’t make it less of an “AS” role, it’s just being fulfilled
closely to where the RS role is fulfilled. As such, my proposal is really not that different in practice, but the labels are different and better aligned with the capabilities
of the protocol.

[Comment from Denis] Which proposal ?

We’ve previously talked about separating the user-facing portions of the AS into another component, and I think now might be the time to do that.
This is a very flammable strawman proposal, but what if we had the AS defined, as above, and the “consent and authorization” gathering portion
is augmented by another named component. Here let’s call it an Interaction Component.

[Comment from Denis] First of all, using the privacy vocabulary, this is not “consent and authorization”, but it is "user notice", "user choice" and "user consent".

Before making one or more choices, the end-user must be able to be informed about the reasons and /or the consequences of each choice.
Then he must be able to make some choice(s) and finally he may indicate his consent for these choices.

A key question is: At which moment such "user notice, choice and consent happens ? If an end-user has never contacted a RS before,
this happens after a "discovery" flight and BEFORE contacting any AS.

Since, there exist some situations where there is a single AS, some people may believe that these choices are the same whether they are made immediately
after the first RS call or after the first AS call, and hence that that is is possible to use a same building block for both cases. Unfortunately this is not the case.

As soon as a RS is trusting more than one AS, the user choice is first to select the AS(s) after being informed of which privileges are requested/needed
by a RS to respond positively on a method performed on an object.

Furthermore, as soon as an AS has not established a prior relationship with the RS, an AS is unable to present any choice to the end-user.

So, for the time being, we should not presume that the functions can be factored and thus it is important to consider, for the time being,
that there is no such "Interaction Component".

This can take several forms based on the kind of interaction mode in use:

 - Hosted at a URL the user is redirected to; it can then make the user log in, consent, and whatever else they need to do
 - Hosted at a URL the user will load separately and enter in an access code
 - An app on the user’s device that the user interacts with directly and which sends information back to the AS
 - An app reachable by a messaging endpoint that the AS sends and receives structured information from
 - The client itself that is given an indication as to what information the AS needs in order to fulfill the request; this could be MFA challenge/response, user credentials, signed claims, etc.

It’s the AS’s job to accept any and all of these that it supports and churn those into an access token.

[Comment from Denis] No. It is not necessarily the AS's job. The AS job is to place into an access token the privileges that have been requested by the client.

The AS itself doesn’t ever need to have the user log in. The AS doesn’t necessarily need to even know who the user is in any way.
The AS just needs to know from a trusted source that the request is approved.
[Comment from Denis] No, no and no again for each of these three sentences. It is rather strange to change the model and the (implicit) trust relationships at this time.
I fear that we are following a moving target.

When writing the first draft, the cart has been placed before the horse, which means that the components of the model, their relationships and their trust relationships
have not been defined, and that the protocols have been designed without a clear model and without explaining their rational.

From a practical standpoint, I think this will have some small changes in how we talk about the components and how we talk about the interaction phase
of the grant negotiation process. Everything I’m laying out here is currently allowed by the spec, but I think we’ve carried through the same assumptions from OAuth 2
about deployment that are both inaccurate and confusing.

[Comment from Denis] The writer surely understands what this means, but not me.
Which assumptions from OAuth 2 about deployment are both inaccurate and confusing ?

Denis

 — Justin


--------------B8FA32882240C88685B36891-- From nobody Mon Mar 15 03:29:51 2021 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 5FFAB3A0ABB for ; Mon, 15 Mar 2021 03:29:49 -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 AwyvnEbHbpUx for ; Mon, 15 Mar 2021 03:29:46 -0700 (PDT) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 D2EF23A0AB8 for ; Mon, 15 Mar 2021 03:29:45 -0700 (PDT) Received: by mail-il1-x12f.google.com with SMTP id p10so8827692ils.9 for ; Mon, 15 Mar 2021 03:29:45 -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=J5kdlBA+xxGW5V8dZld6R2gCzN5+0XV5hY5HTGENv5s=; b=lBxIVMNMnyxpzeml8inLoE6AgaykAGkbafhaFrr7OAL2frDNsksHAvmboPcX30vPIC oPDQmKqNTDg4C153XbYj4GwX7SOLhpctWXFoJZchdSO0rzaLLwAjfmD1bKbHAcMkuTk+ 9KWM3dY/Vb91hG9J7feIcgl4eEhQcTzK59vxjzw0uZ5PulQLl7v2wAcbQ4s1pS+p0xc0 CJhsX3z8kNSqpWSQQ3aFTPaZ7Saan+KSOJ3shS52bsDSU/rj+W3HU02x9DoFKv+UGVyf Ik4m2yoxK3P1Uf0DKnaFAoC0c3blCQwyXgHiM3roKHWBNUCVWQF0kvNwIFolQLm+OnAr HUcw== 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=J5kdlBA+xxGW5V8dZld6R2gCzN5+0XV5hY5HTGENv5s=; b=J/9dMFyl3ZBrcsUpCGVOmWJU2vfd/wJxS1f4MzUUXPKW8kn7AaYyiStPx9sTLlMFj0 NMw5Oc+vDMDM8AuaQYZ3c+E9UT/MxduvNfTRp9m/7i1Cm17TTDi+8EevwuuuoqifL++x HN3vNIDFJ+uacPaYhYA4OWO9n0tvZ0MBoCqtnDneRr6f5zxdgiQ7tF+xQB3ZCbfMEDzV UUGjpp7d611TzptxYBDhg7iURcBFnvZc6wywtEVltcfqvZHvMBc18lUZw+XnE/hFAlK5 A0HfeZp82jhlht9AOgmsOM7gSuyd6h7zhq8PDC+4JKqTfQBuey75XZVr9eVc2hMrKZo1 jv1w== X-Gm-Message-State: AOAM530XpiC2nV/BSFgYhwIdidUyycTraGupiaPZqRR/Y5sfXZQHjXzx /yWo8qWC8ld329/+wmMJ/H4Kc5U8GCL30xsKW64= X-Google-Smtp-Source: ABdhPJy9iy4U1eC0yv3fODg+R8plr2M7hyQJRJdLmIdZ9/QmSJ7CZJzOK0gsS8zzKHcoVQuFdz8jownhh1xBvpFLl7Q= X-Received: by 2002:a92:d84f:: with SMTP id h15mr11568153ilq.178.1615804183834; Mon, 15 Mar 2021 03:29:43 -0700 (PDT) MIME-Version: 1.0 References: <205ACFE1-7D4C-4D7C-B394-4AD8A4D4D080@mit.edu> In-Reply-To: From: Fabien Imbault Date: Mon, 15 Mar 2021 11:29:32 +0100 Message-ID: To: Adrian Gropper Cc: Justin Richer , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000006774ec05bd90baff" Archived-At: Subject: Re: [GNAP] GNAP Architecture and the role of the AS X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2021 10:29:49 -0000 --0000000000006774ec05bd90baff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Adrian, It's good to check what that means in real use cases indeed. My view: Items 1-2-3-7 : seems quite usual. Only in this example, the patient is the RO and generally delegates its decision to an automated policy engine (equivalent to seq 1.4.4). I believe item 4 (delegation, beyond the original token issuance) would be hard to do using JWT, at least in a generic way. Items 5 is probably beyond our scope, although Denis expressed the same requirement related to "solicits too much info" (based on non opaque tokens, which might not be the general assumption / I personally think token content should remain opaque to the client, but knowing the type of the token would be useful). Item 6 asks for a relationship between RS and RO, which I'm not sure we'd want to assume for the general case (although it could happen in some scenarii). Item 8 is fine in principle, but would require attention to make sure it's the case in practice. Depending on the sub_ids used (and even if opaque, as soon as dereferencing is allowed), correlation might be possible. Does that seem correct? Fabien On Fri, Mar 12, 2021 at 10:34 PM Adrian Gropper wrote: > Let=E2=80=99s try to map a real-world use-case into the names and roles w= e are > discussing. The use-case is documented as the API Task Force > Recommendations (2016) > https://www.healthit.gov/sites/default/files/facas/SingleSourceofTruth-AP= ITFRecommendations.pdf > and I=E2=80=99ve copied below the most relevant section. Bold highlight i= s in the > original. I=E2=80=99ve added bold italic because it may be important to o= ur > discussion. > > > > > - > > ONC should clarify that while API Providers may impose security > related restrictions on app access (e.g. rate limiting, encryption, an= d > expiration of access tokens), it is inappropriate for API providers to= set > limitations on what a patient authorized app can do with data downstre= am. > - > > Given the nature of patient access rights, the provider is not in a > legal position to prevent the registration of apps that would aggre= gate or > share data, for example (though the provider might certainly decide= to warn > the patient, or endeavor to educate and explain these issue to the = patient, > as part of the provider hosted app approval workflow). > - > > ONC should clarify that API providers are not obligated to protect > patients by identifying "suspicious" apps. API providers may suspend > API access to an app that has breached the API provider's terms of > service , or appears to have been compromised, or if the app poses a t= hreat > to the provider's own system. However, patients must be able to > override this suspension (except in the case where an app poses threat > to the provider's own system or violates allowable terms of service). > > > > > > The key requirements from a patient rights and privacy perspective are: > > > 1. > > To delegate a scope-limited access capability to anyone anywhere > without having to explain or justify that to the API Provider. > 2. > > To allow the patient to automate the issue of a scope-limited access > capability by delegating the authority to process API access requests = to > some agent. The API Provider has no say in who or where this agent is. > 3. > > The automation of the agent is based on policies provided by the > patient. The agent is able to process access requests from anyone and = is > responsible only to the patient. The agent responds to successful requ= ests > by issuing a filtered capability to the requesting party. > 4. > > To ensure that the requesting party can delegate the capability using > an institutional workflow system that they trust and the patient doesn= =E2=80=99t > know or care about. In many cases, the workflow system will pass the > capability to some other person, who we might call the end user. In ot= her > cases, the requesting party may forward the capability directly to ano= ther > person using, for example, an email. Either way, the client app used b= y the > end-user to access the API is of no concern to the patient or to the > patient=E2=80=99s agent. > 5. > > To ensure that the API Provider does not censor the client app that > presents the capability or solicits too much information about the cli= ent > app or the end-user of the client app. > 6. > > If the API Provider decides, for any reason, to be =E2=80=9Csuspicious= =E2=80=9D (as > above) of the access transaction based on the information it has, it s= hould > be possible for the API Provider to warn the patient and to accept an > override of the warning by the patient. This effectively means that th= e > end-user will provide as much information as they think will be necess= ary > in order to either avoid =E2=80=9Csuspicion=E2=80=9D or risk waiting f= or patient override. > 7. > > The policies by which the patient or the decides to grant a capability > to the requesting party are never shared outside of the patient-agent = trust > relationship. In other words, neither the patient nor the agent is ask= ed to > share or explain their reason for an access decision. > 8. > > Access requests to the agent are presumed confidential among the > patient, the agent, and whatever client the requesting party uses to > present an access request. The API Provider does not get to see the > requests and no entity in the GNAP authorization process, other than t= he > patient or the agent, gets to correlate across requests by different > requesting party clients. > > > Note that I am not saying all 8 requirements are in scope for GNAP but I > am asking for GNAP to allow for this level of privacy on the part of > self-sovereign patients using self-sovereign agents and the self-sovereig= n > licensed professionals they deal with. > > Adrian > > > On Fri, Mar 12, 2021 at 2:50 PM Fabien Imbault > wrote: > >> Hi Justin, >> >> Just a quick word to say I very much agree with both the observations an= d >> the framing. >> >> Fabien >> >> On Fri, Mar 12, 2021 at 6:07 PM Justin Richer wrote: >> >>> As discussed at the IETF meeting, the editors proposed that one of our >>> next big topic areas was going to be the nature of the AS role within t= he >>> GNAP protocol, especially how it relates to the device-driven use cases >>> that have been brought up. Apologies in advance for the long post, but >>> there are a lot of parts to this discussion that I=E2=80=99m hoping we = can kick off >>> here. >>> >>> My core proposal is that we see the AS as the component that has the >>> following properties: >>> - receives delegation requests from the client instance for access to >>> an RS via access tokens, and for access to subject information returned >>> directly to the client instance >>> - collects consent and authorization from the RO for the delegation >>> - issues access tokens that its downstream RS=E2=80=99s can interpret = (and >>> validate/accept) >>> - issues subject information asserted by the AS >>> >>> This framing of the parties is really important in making a consistent >>> understanding of how the protocol works, and a consistent understanding= is >>> vital if we=E2=80=99re going to function as a working group in both dis= cussing the >>> problem space and executing the solution space. For a historical exampl= e, a >>> naive approach to adding identity on top of a protocol like OAuth 2 (or >>> GNAP) is to declare that the resource server is the thing the user is >>> logging in to. This seems reasonable at first (and some people tried do= ing >>> this) but it violates all kinds of trust boundaries and puts new >>> expectations on the different parties that do not make sense. It stops >>> looking anything like OAuth very quickly and turns into another protoco= l. >>> If instead we say the user is logging in to the client, things suddenly >>> make a lot more sense and we can do a lot more with it. (See this blog = post >>> from 2013 for one take on that discussion: >>> https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/) >>> >>> I think we=E2=80=99ve got a similar situation here when we start to tal= k about >>> the user bringing their own AS with them. I think this is a >>> reasonable-seeming assumption but it=E2=80=99s based on a false premise= that the RO >>> has to log into the AS to approve the request, and the AS has full cont= rol >>> and view over everything in the network. While OAuth doesn=E2=80=99t re= quire this, >>> it=E2=80=99s largely assumed that=E2=80=99s how it works. After all, al= l of the early OAuth >>> deployments worked exactly this way: the user logs in and clicks the = =E2=80=9COK=E2=80=9D >>> button. However, cloud deployments have shown us that it=E2=80=99s perf= ectly >>> reasonable for an OAuth AS to take in its consent and user information = from >>> an external trusted source, and so this model is not even accurate in O= Auth. >>> >>> In short, I think we can do a better job here of defining things in >>> terms that both accept the reality we face and enable new ideas in ways >>> that make sense. It=E2=80=99s my stance that the user shouldn=E2=80=99t= need to bring the >>> AS with them in order to have the kind of input and control of the syst= em >>> that people are asking for. Instead, the AS should be able to take inpu= ts >>> from things that the user controls in order for the AS to do its job. >>> >>> People have discussed privacy concerns with the AS knowing =E2=80=9Ctoo= much=E2=80=9D, >>> but in many of those discussions the knowledge is simply pushed to the = RS >>> instead. What I=E2=80=99m observing here is really just pushing portion= s of the AS >>> role into the =E2=80=9CRS=E2=80=9D deployment. This doesn=E2=80=99t mak= e it less of an =E2=80=9CAS=E2=80=9D role, >>> it=E2=80=99s just being fulfilled closely to where the RS role is fulfi= lled. As >>> such, my proposal is really not that different in practice, but the lab= els >>> are different and better aligned with the capabilities of the protocol. >>> >>> We=E2=80=99ve previously talked about separating the user-facing portio= ns of the >>> AS into another component, and I think now might be the time to do that= . >>> This is a very flammable strawman proposal, but what if we had the AS >>> defined, as above, and the =E2=80=9Cconsent and authorization=E2=80=9D = gathering portion is >>> augmented by another named component. Here let=E2=80=99s call it an Int= eraction >>> Component. This can take several forms based on the kind of interaction >>> mode in use: >>> >>> - Hosted at a URL the user is redirected to; it can then make the user >>> log in, consent, and whatever else they need to do >>> - Hosted at a URL the user will load separately and enter in an access >>> code >>> - An app on the user=E2=80=99s device that the user interacts with dir= ectly and >>> which sends information back to the AS >>> - An app reachable by a messaging endpoint that the AS sends and >>> receives structured information from >>> - The client itself that is given an indication as to what information >>> the AS needs in order to fulfill the request; this could be MFA >>> challenge/response, user credentials, signed claims, etc. >>> >>> It=E2=80=99s the AS=E2=80=99s job to accept any and all of these that i= t supports and >>> churn those into an access token. >>> >>> The AS itself doesn=E2=80=99t ever need to have the user log in. The AS= doesn=E2=80=99t >>> necessarily need to even know who the user is in any way. The AS just n= eeds >>> to know from a trusted source that the request is approved. >>> >>> From a practical standpoint, I think this will have some small changes >>> in how we talk about the components and how we talk about the interacti= on >>> phase of the grant negotiation process. Everything I=E2=80=99m laying o= ut here is >>> currently allowed by the spec, but I think we=E2=80=99ve carried throug= h the same >>> assumptions from OAuth 2 about deployment that are both inaccurate and >>> confusing. >>> >>> =E2=80=94 Justin >>> -- >>> 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 >> > --0000000000006774ec05bd90baff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Adrian,=C2=A0

It's good to check= what that means in real use cases indeed.

My view:<= /div>
Items 1-2-3-7 : seems quite usual. Only in this example, the pati= ent is the RO and generally delegates its decision to an automated policy e= ngine (equivalent to seq 1.4.4).=C2=A0
I believe item 4 (delegati= on, beyond the original token issuance) would be hard to do using JWT, at l= east in a generic way.=C2=A0
Items 5 is probably beyond our scope= , although Denis expressed the same requirement related to "solicits t= oo much info" (based on non opaque tokens, which might not be the gene= ral assumption / I personally think token content should remain opaque to t= he client, but knowing the type of the token would be useful).=C2=A0
<= /div>
Item 6 asks for a relationship between RS and RO, which I'm n= ot sure we'd want to assume for the general case (although it could hap= pen in some scenarii).
Item 8 is fine in principle, but would req= uire attention to make sure it's the case in practice. Depending on the= sub_ids used (and even if opaque, as soon as dereferencing is allowed), co= rrelation might be possible.

Does that seem correc= t?
Fabien

On Fri, Mar 12, 2021 at 10:34 PM Adrian Gropper &l= t;agropper@healthurl.com> = wrote:

Let=E2=80=99s tr= y to map a real-world use-case into the names and roles we are discussing. = The use-case is documented as the API Task Force Recommendations (2016) https://www.healthit.gov/sites/default/files/fa= cas/SingleSourceofTruth-APITFRecommendations.pdf and I=E2=80=99ve copied b= elow the most relevant section. Bold highlight is in the original= . I=E2=80=99ve added bold italic because it may= be important to our discussion.=C2=A0


<quote>

  • ONC should clarify that while API Providers may impo= se security related restrictions on app access (e.g. rate limiting, encrypt= ion, and expiration of access tokens), it is inappropriate for API provider= s to set limitations on what a patient authorized app can do with data down= stream.

    • Given the = nature of patient access rights, the provider is not in a legal position to= prevent the registration of apps that would aggregate or share data, for e= xample (though the provider might certainly decide to warn the patient, or = endeavor to educate and explain these issue to the patient, as part of the = provider hosted app approval workflow).

  • ONC should clarify tha= t API providers are not obligated to protect patients by identifying "suspicious" apps. API= providers may suspend API access to an app that has breached the API provider's terms of service= , or appears to have been compromised, or if the app poses a threat to the= provider's own system. However, patients must be able to = override this suspension (except in the case where an app poses threat to the provider's own= system or violates allowable terms of service).


</quote>

The key requirements from a patient= rights and privacy perspective are:


  1. To delegate a scope-limited access capability to anyone = anywhere without having to explain or justify that to the API Provider.

  2. To allow the patient to automate the issue of a scope-limited acces= s capability by delegating the authority to process API access requests to = some agent. The API Provider has no say in who or where this agent is.

  3. The automation of the agent is based on policies provided by the pat= ient. The agent is able to process access requests from anyone and is respo= nsible only to the patient. The agent responds to successful requests by is= suing a filtered capability to the requesting party.

  4. To ensure t= hat the requesting party can delegate the capability using an institutional= workflow system that they trust and the patient doesn=E2=80=99t know or ca= re about. In many cases, the workflow system will pass the capability to so= me other person, who we might call the end user. In other cases, the reques= ting party may forward the capability directly to another person using, for= example, an email. Either way, the client app used by the end-user to acce= ss the API is of no concern to the patient or to the patient=E2=80=99s agen= t.=C2=A0

  5. To ensure that the API Provider does not censor the cli= ent app that presents the capability or solicits too much information about= the client app or the end-user of the client app.=C2=A0

    6. If the = API Provider decides, for any reason, to be =E2=80=9Csuspicious=E2=80=9D (a= s above) of the access transaction based on the information it has, it shou= ld be possible for the API Provider to warn the patient and to accept an ov= erride of the warning by the patient. This effectively means that the end-u= ser will provide as much information as they think will be necessary in ord= er to either avoid =E2=80=9Csuspicion=E2=80=9D or risk waiting for patient = override.

  6. The policies by which the patient or the decides to gr= ant a capability to the requesting party are never shared outside of the pa= tient-agent trust relationship. In other words, neither the patient nor the= agent is asked to share or explain their reason for an access decision.=C2= =A0

  7. Access requests to the agent are presumed confidential among= the patient, the agent, and whatever client the requesting party uses to p= resent an access request. The API Provider does not get to see the requests= and no entity in the GNAP authorization process, other than the patient or= the agent, gets to correlate across requests by different requesting party= clients.


Note that I am not saying all 8 requirements are in= scope for GNAP but I am asking for GNAP to allow for this level of privacy= on the part of self-sovereign patients using self-sovereign agents and the= self-sovereign licensed professionals they deal with.


Adrian


On Fri, Mar 12, 2021 at 2:50 P= M Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Justin,=C2=A0

=
Just a quick word to say I very much agree with both the observa= tions and the framing.

Fabien

On Fri, Mar 12,= 2021 at 6:07 PM Justin Richer <jricher@mit.edu> wrote:
As discussed at the IETF meeting, the edit= ors proposed that one of our next big topic areas was going to be the natur= e of the AS role within the GNAP protocol, especially how it relates to the= device-driven use cases that have been brought up. Apologies in advance fo= r the long post, but there are a lot of parts to this discussion that I=E2= =80=99m hoping we can kick off here.

My core proposal is= that we see the AS as the component that has the following properties:
=C2=A0- receives delegation requests from the client instance for ac= cess to an RS via access tokens, and for access to subject information retu= rned directly to the client instance
=C2=A0- collects consent and= authorization from the RO for the delegation
=C2=A0- issues acce= ss tokens that its downstream RS=E2=80=99s can interpret (and validate/acce= pt)
=C2=A0- issues subject information asserted by the AS=C2=A0

This framing of the parties is really important in ma= king a consistent understanding of how the protocol works, and a consistent= understanding is vital if we=E2=80=99re going to function as a working gro= up in both discussing the problem space and executing the solution space. F= or a historical example, a naive approach to adding identity on top of a pr= otocol like OAuth 2 (or GNAP) is to declare that the resource server is the= thing the user is logging in to. This seems reasonable at first (and some = people tried doing this) but it violates all kinds of trust boundaries and = puts new expectations on the different parties that do not make sense. It s= tops looking anything like OAuth very quickly and turns into another protoc= ol. If instead we say the user is logging in to the client, things suddenly= make a lot more sense and we can do a lot more with it. (See this blog pos= t from 2013 for one take on that discussion:=C2=A0https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/= )

I think we=E2=80=99ve got a similar situation he= re when we start to talk about the user bringing their own AS with them. I = think this is a reasonable-seeming assumption but it=E2=80=99s based on a f= alse premise that the RO has to log into the AS to approve the request, and= the AS has full control and view over everything in the network. While OAu= th doesn=E2=80=99t require this, it=E2=80=99s largely assumed that=E2=80=99= s how it works. After all, all of the early OAuth deployments worked exactl= y this way: the user logs in and clicks the =E2=80=9COK=E2=80=9D button. Ho= wever, cloud deployments have shown us that it=E2=80=99s perfectly reasonab= le for an OAuth AS to take in its consent and user information from an exte= rnal trusted source, and so this model is not even accurate in OAuth.
=

In short, I think we can do a better job here of defini= ng things in terms that both accept the reality we face and enable new idea= s in ways that make sense. It=E2=80=99s my stance that the user shouldn=E2= =80=99t need to bring the AS with them in order to have the kind of input a= nd control of the system that people are asking for. Instead, the AS should= be able to take inputs from things that the user controls in order for the= AS to do its job.

People have discussed privacy c= oncerns with the AS knowing =E2=80=9Ctoo much=E2=80=9D, but in many of thos= e discussions the knowledge is simply pushed to the RS instead. What I=E2= =80=99m observing here is really just pushing portions of the AS role into = the =E2=80=9CRS=E2=80=9D deployment. This doesn=E2=80=99t make it less of a= n =E2=80=9CAS=E2=80=9D role, it=E2=80=99s just being fulfilled closely to w= here the RS role is fulfilled. As such, my proposal is really not that diff= erent in practice, but the labels are different and better aligned with the= capabilities of the protocol.=C2=A0

We=E2= =80=99ve previously talked about separating the user-facing portions of the= AS into another component, and I think now might be the time to do that. T= his is a very flammable strawman proposal, but what if we had the AS define= d, as above, and the =E2=80=9Cconsent and authorization=E2=80=9D gathering = portion is augmented by another named component. Here let=E2=80=99s call it= an Interaction Component. This can take several forms based on the kind of= interaction mode in use:

=C2=A0- Hosted at a URL = the user is redirected to; it can then make the user log in, consent, and w= hatever else they need to do
=C2=A0- Hosted at a URL the user wil= l load separately and enter in an access code
=C2=A0- An app on t= he user=E2=80=99s device that the user interacts with directly and which se= nds information back to the AS
=C2=A0- An app reachable by a mess= aging endpoint that the AS sends and receives structured information from
=C2=A0- The client itself that is given an indication as to what i= nformation the AS needs in order to fulfill the request; this could be MFA = challenge/response, user credentials, signed claims, etc.

It=E2=80=99s the AS=E2=80=99s job to accept any and all of these th= at it supports and churn those into an access token.=C2=A0

The AS itself doesn=E2=80=99t ever need to have the user log in. T= he AS doesn=E2=80=99t necessarily need to even know who the user is in any = way. The AS just needs to know from a trusted source that the request is ap= proved.

From a practical standpoint, I think this = will have some small changes in how we talk about the components and how we= talk about the interaction phase of the grant negotiation process. Everyth= ing I=E2=80=99m laying out here is currently allowed by the spec, but I thi= nk we=E2=80=99ve carried through the same assumptions from OAuth 2 about de= ployment that are both inaccurate and confusing.=C2=A0

=
=C2=A0=E2=80=94 Justin
--
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
--0000000000006774ec05bd90baff-- From nobody Mon Mar 15 04:01:53 2021 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 85A763A0C55 for ; Mon, 15 Mar 2021 04:01:51 -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 DCRolBAca_9E for ; Mon, 15 Mar 2021 04:01:48 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 DF4DD3A0C4E for ; Mon, 15 Mar 2021 04:01:47 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id z13so32832166iox.8 for ; Mon, 15 Mar 2021 04:01:47 -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=JmMm3k/CtZT8gol0lYeTHv5nKuGae3tiykWgJ3wmN1A=; b=TQGv3SlZillLCAAdvKUDqNNJvPpbEbAHRiV7/Y22kjNJfxZXbH25pA+MdcQ+DXyKia pPifSjJkjTCseG9f3ZCHrrXlWaOqkxjXsdVbf+2LJUKwZp/NqFOlNDJYyPuhGXWa+SY6 Tdjpshr+jNog1HUNgmAbIqUmz+FgA+mZWU1ILbRR6C6DUNg80j39PtSd0Rcau4yOZdRJ d0I54MQBpY3zziTMvA99Ix4MTFUJuN0hnR1g0EMGL2nu8onbyd2IUARRKEyVb0ss2/en 9SRcxLgqzSUdNr7kiJxN+zl3YmzVjpoy0JZ3bxouorMLmzLDSNeWC7al+GWtEgWSsnYe s5hg== 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=JmMm3k/CtZT8gol0lYeTHv5nKuGae3tiykWgJ3wmN1A=; b=lDVVK5Z+9YZngsG/nD8xf0g67ZPCYl8UHKlefsy15ZAUW88w4fplDpGy2C9OkPyWze Hb24LU4q1rM8RvI80qdOvWpu44+Q+0vX6aLvRiw/ejBoo3MS+MojeItY8qT2csOuRcMk fqD3CbAGgXK8Uv6dxLvpTaDzOEW8jTT3G2+xnFfP2W/3liAUE94PNuPmtTg+IJ9PlCb5 lmon7p1DzAS3lXpf2TEWCjmvY9KtmIeDLt/C5udfNxN6IA6AoKbtIveWb8AvnvQGIqZQ 7h08azNx0YfkESThYERJnQrLPu817H5a+Z8JuP6AYCJtpXMk3ZQj/xw/a2jzbU/7RNwB gyjg== X-Gm-Message-State: AOAM530bCRgA71Ny6+/PvVRphmXNYGY+GOX3DpbcTcQ0whLSXBC2ZZhm kNlLbGVVv153aYhmGSDtxAzcJF/CGgErlEitpxM= X-Google-Smtp-Source: ABdhPJxRfYooavyQqqXcp754yt+XZntuOHi0JDebhXS6FbC2SUYN4IfaT2k69E/P1Yd/CmxblAaaU7k1X4LfdO3okgM= X-Received: by 2002:a05:6602:3314:: with SMTP id b20mr6907872ioz.78.1615806104940; Mon, 15 Mar 2021 04:01:44 -0700 (PDT) MIME-Version: 1.0 References: <205ACFE1-7D4C-4D7C-B394-4AD8A4D4D080@mit.edu> <8cf9f884-5c17-bb5d-006d-c684d75be867@free.fr> In-Reply-To: <8cf9f884-5c17-bb5d-006d-c684d75be867@free.fr> From: Fabien Imbault Date: Mon, 15 Mar 2021 12:01:33 +0100 Message-ID: To: Denis Cc: Justin Richer , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000e9327405bd912c1a" Archived-At: Subject: Re: [GNAP] GNAP Architecture and the role of the AS X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2021 11:01:52 -0000 --000000000000e9327405bd912c1a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Denis, I don't intend to comment on everything, just my 2 cents (personal view) in red. Cheers Fabien On Mon, Mar 15, 2021 at 10:24 AM Denis wrote: > Hi Justin, > > My comments are between the lines. > > As discussed at the IETF meeting, the editors proposed that one of our > next big topic areas was going to be the nature of the AS role within the > GNAP protocol, > especially how it relates to the device-driven use cases that have been > brought up. Apologies in advance for the long post, but there are a lot o= f > parts > to this discussion that I=E2=80=99m hoping we can kick off here. > > [Comment from Denis] The "device-driven use cases" are not addressed any > further in this email. IMO, they are only possible if/when a secure eleme= nt > with some specific security properties is being used by the end-user and > when the AS is able to verify that it is indeed used by the end-user. > I am not disputing that this would be an interesting case but ,before > going any further, we would have to modify the terms of our charter. > > My core proposal is that we see the AS as the component that has the > following properties: > > - receives delegation requests from the client instance for access to an > RS via access tokens, > and for access to subject information returned directly to the client > instance > > - collects consent and authorization from the RO for the delegation > > [Comment from Denis] The RO on the AS side is an optional component. > > - issues access tokens that its downstream RS=E2=80=99s can interpret (a= nd > validate/accept) > > [Comment from Denis] This sentence must remain true whether or not the AS > and the RS have established a prior relationship. > When there is no prior relationship between an AS and a RS, the RS must b= e > able to disclose to the Client, the access token format(s), > as well as the crypto algorithms, it supports. In the same way, the AS > must be able to disclose to the Client, the access token format(s), > as well as the crypto algorithms, it supports. If there is no match, it i= s > unnecessary to continue the exchanges. > > It is important to mention that the access token contains privileges, i.e= . > end-user attributes or/and rights. > > - When end-user attributes are contained into an access token, it is > possible to implement on the RS side an ABAC or a RBAC or an IBAC. > > [FIM] not currently covered by GNAP, this could be possible, cf https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/203 > > - When rights are contained into an access token, it is possible to > implement on the RS side a capability model. > > A major difference between these two models is the point from which the > access control rules are administered: > > - When end-user attributes are contained into an access token, the > administration of the access control rules is only done by a Resource = Owner > sitting on the RS side. > - When rights are contained into an access token, the administration > of the access control rules is primally done by a Resource Owner > sitting on the AS side > but is also controlled by another by a Resource Owner sitting on the > RS side which establishes the trust conditions. > > [FIM] yes, there are good reasons for both, GNAP I believe should be agnostic, only considering by default the case where the RO is on the AS side, but still allowing the case when the RO has an account on the RS side > - issues subject information asserted by the AS > > [Comment from Denis] Still the same difficulty about the use of the term > "subject" which remains unsolved, this sentence is ambiguous: > is the "end-user" information placed into an access token ? > [FIM] in the AS definition, we explain quite clearly that acces token and subject info are distinct. Justin has submitted a new PR 211 that even clarifies that further. > This framing of the parties is really important in making a consistent > understanding of how the protocol works, and a consistent understanding i= s > vital > if we=E2=80=99re going to function as a working group in both discussing = the > problem space and executing the solution space. For a historical example, > a naive approach to adding identity on top of a protocol like OAuth 2 (or > GNAP) is to declare that the resource server is the thing the user is > logging in to. > This seems reasonable at first (and some people tried doing this) but it > violates all kinds of trust boundaries and puts new expectations on the > different parties > that do not make sense. It stops looking anything like OAuth very quickly > and turns into another protocol. If instead we say the user is logging in > to the client, > things suddenly make a lot more sense and we can do a lot more with it. > (See this blog post from 2013 for one take on that discussion: > https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/) > > [Comment from Denis] This link does not work. After 10 minutes of search, > here is the appropriate link: *https://www.cloudidentity.com/blog/?p=3D25= 1 > * > to be able to access to this very looooong article (this will take you > more than 30 minutes to read). > > [Comment from Denis] GNAP and OAuth 2.0 are both authorization frameworks= , > i.e. they are NOT authentication protocols. > An authorization may be given to a "calling application", called the > "client" in our draft. > > Before obtaining a response when calling an API, a Resource Server (RS) > MAY mandate to authenticate the end-user. > In such a case, if no authentication exchange has successfully taken > place, it will return the error *401 Unauthorized*, which is the HTTP > status code > for authentication errors: it=E2=80=99s for authentication, not authoriza= tion. > Receiving a 401 response is the server telling you, =E2=80=9Cyou, as an e= nd-user, > aren=E2=80=99t authenticated=E2=80=93either not authenticated at all or a= uthenticated > incorrectly=E2=80=93but please re-authenticate and try again.=E2=80=9D > To help you out, it will always include a *WWW-Authenticate* header that > describes how to authenticate. > > The long post from 2013 contains one important sentence : " OAuth is > interested in what takes place AFTER authentication," > which means that an authentication MAY happen BEFORE OAuth takes place. = This > clearly means that an authentication exchange MAY exist. > Unfortunately this is currently not mentioned in the draft, whereas it > should be described in the draft. > [FIM] maybe it needs clarification, but the sequence diagrams do mention AuthN > This raises an interesting question which has been left aside. What is th= e > relationship (if any) between the end-user identifier used > for an authentication exchange and a "sub-id" claim or a "sub" claim > present inside an access token ? > > The long post from 2013 contains another important sentence : > "keeping AS and RS under the same roof is baked in OAuth=E2=80=99s common= usage, > if not the spec itself." This is true. > > In GNAP, this assumption is no more valid as the ASs and the RSs are not > necessarily any more "under the same roof". > [FIM] already the case in many OAuth2 deployments > I think we=E2=80=99ve got a similar situation here when we start to talk = about the > user bringing their own AS with them. I think this is a reasonable-seemin= g > assumption > but it=E2=80=99s based on a false premise that the RO has to log into the= AS to > approve the request, and the AS has full control and view over everything > in the network. > While OAuth doesn=E2=80=99t require this, it=E2=80=99s largely assumed th= at=E2=80=99s how it > works. After all, all of the early OAuth deployments worked exactly this > way: the user logs in > and clicks the =E2=80=9COK=E2=80=9D button. However, cloud deployments ha= ve shown us that > it=E2=80=99s perfectly reasonable for an OAuth AS to take in its consent = and user > information > from an external trusted source, and so this model is not even accurate i= n > OAuth. > > [Comment from Denis] It is more important to explain first how GNAP will > work rather than stating what's wrong in OAuth. > > In short, I think we can do a better job here of defining things in terms > that both accept the reality we face and enable new ideas in ways that ma= ke > sense. > It=E2=80=99s my stance that the user shouldn=E2=80=99t need to bring the = AS with them in > order to have the kind of input and control of the system that people are > asking for. > Instead, the AS should be able to take inputs from things that the user > controls in order for the AS to do its job. > > [Comment from Denis] The writer surely understands what this means, but > not me. > > People have discussed privacy concerns with the AS knowing =E2=80=9Ctoo m= uch=E2=80=9D, but > in many of those discussions the knowledge is simply pushed to the RS > instead. > > [Comment from Denis] There is no argument to explain "how the knowledge i= s > simply pushed to the RS instead". During the last IETF GNAP meeting, > I presented some slides enumerating various privacy properties while > comparing access control scheme based on ACLs versus access control schem= es > based > on capabilities (i.e. rights): > > 1)* Unlinkeability between RS user accounts *: Two RSs should not be able > to link their user accounts, by using the content of the access tokens th= ey > receive > from the same AS or from different ASs. > > 2) *AS-RS untraceability:* The AS is unable to know for which RS an > issued access token is targeted. > > 3)* AS-Client Operation/Method hiding*: The AS is unable to know which > Operation/Method will be performed by the client on which object of a RS. > > 4)* AS-Client access time invisibility : *The AS is unable to know > exactly when an issued access token will be consumed by a RS. > > 5) *End-user confidence in the system*: The client can verify that the > access token contains the requested / adequate privileges and, > if not, it can block the transmission of the access token to the RS. > > At the moment, the current draft does not list these privacy properties. > If it would, it would indicate that the AS is able to know : > > - for which RS an issued access token is targeted, > - which Operation/Method will be performed by the client on which > object hosted by the RS, > - exactly when an issued access token will be consumed by the RS (as > soon as Token Introspection is supported), > > [FIM] we planned a privacy consideration section (issue 133). which means that *the AS would be able to act as a **Big Brother*. > In addition if the access tokens are considered to be opaque to the > clients, the end-user cannot have confidence that the AS discloses only t= he > requested privileges > and no more. > > > *If these properties were advertised to the reader of the draft, which > end-users would accept to use such a system which is opaque to the > end-users and where the AS is able to act as Big Brother ?* > [FIM] that's a point of view, but one could think otherwise. The proposed alternative puts a lot of trust on the client, which might be a problem in practice. > There have been some arguments at the very beginning about the fact that > the RO and the end-users were both able to have an account on the AS, > because this was implicitly the case with OAuth. > > The charter states: > > Although the artifacts for this work are not intended or expected to be > backwards-compatible with OAuth 2.0 or OpenID Connect, > the group will attempt to simplify migrating from OAuth 2.0 and OpenID > Connect to the new protocol where possible. > > This clearly means that GNAP is not intended or expected to be > backwards-compatible with OAuth 2.0 or OpenID Connect. > > Originally, OAuth was invented to deal with the case where the same > organization was managing the AS and a set of RSs. > > What was not explained is that an architecture *using an AS *dealing with > capabilities (i.e. rights) allows the AS to know/spy every action from th= e > users on the RSs. > There may be good business reasons to do so, but if privacy properties ha= d > been taken into consideration it would have been possible to provide the > same services > without using any AS. > > Since we don't need to achieve a backwards compatibility, I would say tha= t > it is still possible to use OAuth in the case where the RO =3D the end-us= er. > [FIM] there are other major advances in GNAP when RO =3D end-user > > It would also say that it would still be possible to define an > architecture taking into consideration privacy requirements and to define > an architecture with any AS > to perform operations similar to OAuth. Such an architecture has been > defined during the last century, more precisely in July 1988 under the > standard ECMA-131 > RDT (Referenced Data Transfer). This standard is still available at: *htt= ps://www.ecma-international.org/wp-content/uploads/ECMA-131_1st_edition_jul= y_1988.pdf > * > > What I=E2=80=99m observing here is really just pushing portions of the AS= role > into the =E2=80=9CRS=E2=80=9D deployment. This doesn=E2=80=99t make it le= ss of an =E2=80=9CAS=E2=80=9D role, it=E2=80=99s > just being fulfilled > closely to where the RS role is fulfilled. As such, my proposal is really > not that different in practice, but the labels are different and better > aligned with the capabilities > of the protocol. > > [Comment from Denis] Which proposal ? > > We=E2=80=99ve previously talked about separating the user-facing portions= of the > AS into another component, and I think now might be the time to do that. > This is a very flammable strawman proposal, but what if we had the AS > defined, as above, and the =E2=80=9Cconsent and authorization=E2=80=9D ga= thering portion > is augmented by another named component. Here let=E2=80=99s call it an In= teraction > Component. > > [Comment from Denis] First of all, using the privacy vocabulary, this is > not =E2=80=9Cconsent and authorization=E2=80=9D, but it is "user notice",= "user choice" and > "user consent". > > Before making one or more choices, the end-user must be able to be > informed about the reasons and /or the consequences of each choice. > Then he must be able to make some choice(s) and finally he may indicate > his consent for these choices. > [FIM] possibly, but that is an assumption that could be discussed. I've written a short description of why I think the situation might be more complex than it seems https://fimbault.medium.com/consent-is-dead-long-live-consent-2d64a434cdf6 > > A key question is: At which moment such "user notice, choice and consent > happens ? If an end-user has never contacted a RS before, > this happens after a "discovery" flight and BEFORE contacting any AS. > > Since, there exist some situations where there is a single AS, some peopl= e > may believe that these choices are the same whether they are made > immediately > after the first RS call or after the first AS call, and hence that that i= s > is possible to use a same building block for both cases. Unfortunately th= is > is not the case. > > As soon as a RS is trusting more than one AS, the user choice is first to > select the AS(s) after being informed of which privileges are > requested/needed > by a RS to respond positively on a method performed on an object. > [FIM] an option preflight with the RS would enable this. Again issue 203. > Furthermore, as soon as an AS has not established a prior relationship > with the RS, an AS is unable to present any choice to the end-user. > > So, *for the time being*, we should not presume that the functions can be > factored and thus it is important to consider, *for the time being*, > that *there is no such "Interaction Component"*. > [FIM] At any one point in time, there is only one AS (cf discussion in https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/215, with comments from Justin, Adrian and myself). So I don't think we want to aggregate several requests to different ASs into one anyways. > This can take several forms based on the kind of interaction mode in use: > > - Hosted at a URL the user is redirected to; it can then make the user > log in, consent, and whatever else they need to do > - Hosted at a URL the user will load separately and enter in an access > code > - An app on the user=E2=80=99s device that the user interacts with direc= tly and > which sends information back to the AS > - An app reachable by a messaging endpoint that the AS sends and receive= s > structured information from > - The client itself that is given an indication as to what information > the AS needs in order to fulfill the request; this could be MFA > challenge/response, user credentials, signed claims, etc. > > It=E2=80=99s the AS=E2=80=99s job to accept any and all of these that it = supports and > churn those into an access token. > > [Comment from Denis] No. It is not necessarily the AS's job. The AS job i= s > to place into an access token the privileges that have been requested by > the client. > > The AS itself doesn=E2=80=99t ever need to have the user log in. The AS d= oesn=E2=80=99t > necessarily need to even know who the user is in any way. > The AS just needs to know from a trusted source that the request is > approved. > > [Comment from Denis] *No, no and no again for each of these three > sentences*. It is rather strange to change the model and the (implicit) > trust relationships at this time. > I fear that we are following a moving target. > > When writing the first draft, *the cart has been placed before the horse*= , > which means that the components of the model, their relationships and the= ir > trust relationships > have not been defined, and that the protocols have been designed without = a > clear model and without explaining their rational. > [FIM] I don't think that's the case, we're starting from what people use today (OAuth2 and OpenID), and change what seems necessary, instead of changing completely the model. My point of view is that a big part - probably not everything - of what you propose (which is interesting) can be achieved based on what GNAP proposes (+ some adjustments that could lead to PRs). > From a practical standpoint, I think this will have some small changes in > how we talk about the components and how we talk about the interaction > phase > of the grant negotiation process. Everything I=E2=80=99m laying out here = is > currently allowed by the spec, but I think we=E2=80=99ve carried through = the same > assumptions from OAuth 2 > about deployment that are both inaccurate and confusing. > > [Comment from Denis] The writer surely understands what this means, but > not me. > Which assumptions from OAuth 2 about deployment are both inaccurate and > confusing ? > > Denis > > =E2=80=94 Justin > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000e9327405bd912c1a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Denis,=C2=A0

I don&= #39;t intend to comment on everything, just my 2 cents (personal view) in r= ed.

Cheers
Fabien

On Mon, Mar 15, 2= 021 at 10:24 AM Denis <denis.ietf@= free.fr> wrote:
=20 =20 =20
Hi Justin,

My comments are between the lines.

=20 As discussed at the IETF meeting, the editors proposed that one of our next big topic areas was going to be the nature of the AS role within the GNAP protocol,
especially how it relates to the device-driven use cases that have been brought up. Apologies in advance for the long post, but there are a lot of parts
to this discussion that I=E2=80=99m hoping we can kick off here.

[Comment from Denis] The "device-driven use cases" are not addressed any further in this email. IMO, they are only possible if/when a secure element
with some specific security properties is being used by the end-user and when the AS is able to verify that it is indeed used by the end-user.
I am not disputing that this would be an interesting case but ,before going any further, we would have to modify the terms of our charter.

My core proposal is that we see the AS as the component that has the following properties:

=C2=A0- receives delegation requests from the client instance for access to an RS via access tokens,
=C2=A0=C2=A0 and for access to subject information returned directl= y to the client instance

=C2=A0- collects consent and authorization from the RO for the delegation
[Comment from Denis] The RO on the AS side is an optional component.
=C2=A0- issues access tokens that its downstream RS=E2=80=99s ca= n interpret (and validate/accept)

[Comment from Denis] This sentence must remain true whether or not the AS and the RS have established a prior relationship.
When there is no prior relationship between an AS and a RS, the RS must be able to disclose to the Client, the access token format(s),
as well as the crypto algorithms, it supports. In the same way, the AS must be able to disclose to the Client, the access token format(s),
as well as the crypto algorithms, it supports. If there is no match, it is unnecessary to continue the exchanges.

It is important to mention that the access token contains privileges, i.e. end-user attributes or/and rights.

  • When end-user attributes are contained into an access token, it is possible to implement on the RS side an ABAC or a RBAC or an IBAC.
[FIM] not currently covered by GNAP, this could be poss= ible, cf=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/203<= /a>=C2=A0
  • When rights are contained into an access token, it is possible to implement on the RS side a capability model.

A major difference between these two models is the point from which the access control rules are administered:

  • When end-user attributes are contained into an access token, the administration of the access control rules is only done by a Resource Owner sitting on the RS side.
  • When rights are contained into an access token, = the administration of the access control rules is primally done by a Resource Owner sitting on the AS side
    but is also controlled by another     by a Resource Owner sitting on the RS side which establishes the trust conditions.
This framing of the parties is really important in making a consistent understanding of how the protocol works, and a consistent understanding is vital
if we=E2=80=99re going to function as a working group in both discussing the problem space and executing the solution space. For a historical example,
a naive approach to adding identity on top of a protocol like OAuth 2 (or GNAP) is to declare that the resource server is the thing the user is logging in to.
This seems reasonable at first (and some people tried doing this) but it violates all kinds of trust boundaries and puts new expectations on the different parties
that do not make sense. It stops looking anything like OAuth very quickly and turns into another protocol. If instead we say the user is logging in to the client,
things suddenly make a lot more sense and we can do a lot more with it. (See this blog post from 2013 for one take on that discussion:
https://www.cloudidentity.com/blog/2013= /01/02/oauth-2-0-and-sign-in-4/)

[Comment from Denis] This link does not work. After 10 minutes of search, here is the appropriate link: https://www.cloudidentity.com/blog/?p=3D251
to be able to access to this very looooong article (this will take you more than 30 minutes to read).=

[Comment from Denis] GNAP and OAuth 2.0 are both authorization frameworks, i.e. they are NOT authentication protocols. =C2=A0
An authorization may be given to a "calling application"= ;, called the "client" in our draft.

Before obtaining a response when calling an API, a Resource Server (RS) MAY mandate to authenticate the end-user.
In such a case, if no authentication exchange has successfully taken place, it will return the error 401 Unauthorized, which is the HTTP status code
for authentication errors: it=E2=80=99s for authentication, not authorization. Receiving a 401 response is the server telling you, =E2=80=9Cyou, as an end-u= ser,
aren=E2=80=99t authenticated=E2=80=93either not authenticated at all or authenti= cated incorrectly=E2=80=93but please re-authenticate and try again.=E2=80=9D
To help you out, it will always include a WWW-Authenticate header that describes how to authenticate.

The long post from 2013 contains one important sentence : " OAuth is interested in what takes place AFTER authentication,"
which means that an authentication MAY happen BEFORE OAuth takes place.=C2=A0 This clearly means that an authentication exchange MAY exist.
Unfortunately this is currently not mentioned in the draft, whereas it should be described in the draft.


[FIM] maybe it needs clarification, but the sequence = diagrams do mention AuthN=C2=A0

This raises an interesting question which has been left aside. What is the relationship (if any) between the end-user identifier used
for an authentication exchange and a "sub-id" claim or = a "sub" claim present inside an access token ?

The long post from 2013 contains another important sentence :
"keeping AS and RS under the same roof is baked in OAuth=E2=80=99s common usage, if not the spec itself." This = is true.

In GNAP, this assumption is no more valid as the ASs and the RSs are not necessarily any more "under the same roof".


[FIM] already the case in many OAuth2 deployment= s=C2=A0
=20
I think we=E2=80=99ve got a similar situation here when we start to talk about the user bringing their own AS with them. I think this is a reasonable-seeming assumption
but it=E2=80=99s based on a false premise that the RO has to log = into the AS to approve the request, and the AS has full control and view over everything in the network.
While OAuth doesn=E2=80=99t require this, it=E2=80=99s largely as= sumed that=E2=80=99s how it works. After all, all of the early OAuth deployments worked exactly this way: the user logs in
and clicks the =E2=80=9COK=E2=80=9D button. However, cloud deploy= ments have shown us that it=E2=80=99s perfectly reasonable for an OAuth AS t= o take in its consent and user information
from an external trusted source, and so this model is not even accurate in OAuth.

[Comment from Denis] It is more important to explain first how GNAP will work rather than stating what's wrong in OAuth.

=20
In short, I think we can do a better job here of defining things in terms that both accept the reality we face and enable new ideas in ways that make sense.
It=E2=80=99s my stance that the user shouldn=E2=80=99t need to br= ing the AS with them in order to have the kind of input and control of the system that people are asking for.
Instead, the AS should be able to take inputs from things that the user controls in order for the AS to do its job.
[Comment from Denis] The writer surely understands what this means, but not me.
People have discussed privacy concerns with the AS knowing =E2=80=9Ctoo much=E2=80=9D, but in many of those discussi= ons the knowledge is simply pushed to the RS instead.

[Comment from Denis] There is no argument to explain "how the knowledge is simply pushed to the RS instead". During the last IETF GNAP meeting,
I presented some slides enumerating various privacy properties while comparing access control scheme based on ACLs versus access control schemes based
on capabilities (i.e. rights):

1) Unlinkeability between RS user accounts : Two RSs should not be able to link their user accounts, by using the content of the access tokens they receive
=C2=A0=C2=A0=C2=A0 from the same AS or from different ASs.

2) AS-RS untraceability: The AS is unable to know for which RS an issued access token is targeted.

3) AS-Client Operation/Method hiding: The AS is unable to know which Operation/Method will be performed by the client on which object of a RS.

4) AS-Client access time invisibility : The AS is unable to know exactly when an issued access token will be consumed by a RS.

5) End-user confidence in the system: The client can verify that the access token contains the requested / adequate privileges and,
=C2=A0=C2=A0=C2=A0 if not, it can block the transmission of the access token to the RS.

At the moment, the current draft does not list these privacy properties. If it would, it would indicate that the AS is able to know :

  • for which RS an issued access token is targeted,
  • which Operation/Method wil= l be performed by the client on which object hosted by the RS,
  • exactly when an issued access token will be consumed by the RS (as soon as Token Introspection is supported),
[FIM] we planned a privacy consideration section (issue 133).= =C2=A0

which means that t= he AS would be able to act as a Big Brother.

In addition if the access tokens are considered to be opaque to the clients, the end-user cannot have confidence that the AS discloses only the requested privileges
and no more.

If these properties were advertised to the reader of the draft, which end-users would accept to use such a system which is opaque to the end-users
and where the AS is able to act as Big Brother ?

[FIM] that's a point of view, but one could t= hink otherwise. The proposed alternative puts a lot of trust on the client,= which might be a problem in practice.=C2=A0

There have been some arguments at the very beginning about the fact that the RO and the end-users were both able to have an account on the AS,
because this was implicitly the case with OAuth.

The charter states:

Although the artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect,
the group will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol where possible.

This clearly means that GNAP is not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect.

Originally, OAuth was invented to deal with the case where the same organization was managing the AS and a set of RSs.

What was not explained is that an architecture using an AS dea= ling with capabilities (i.e. rights) allows the AS to know/spy every action from the users on the RSs.
There may be good business reasons to do so, but if privacy properties had been taken into consideration it would have been possible to provide the same services
without using any AS.

Since we don't need to achieve a backwards compatibility, I would say that it is still possible to use OAuth in the case where the RO =3D the end-user.

[FIM] there are other major advance= s in GNAP when RO =3D end-user=C2=A0


It would also say that it would still be possible to define an architecture taking into consideration privacy requirements and to define an architecture with any AS
to perform operations similar to OAuth. Such an architecture has been defined during the last century, more precisely in July 1988 under the standard ECMA-131
RDT (Referenced Data Transfer). This standard is still available at: https://www.ecma-international.org/wp-cont= ent/uploads/ECMA-131_1st_edition_july_1988.pdf

What I=E2=80=99m observing here is really just pushing portions of the AS role into the =E2=80=9CRS=E2=80=9D deployment.= This doesn=E2=80=99t make it less of an =E2=80=9CAS=E2=80=9D role, it=E2=80=99s just b= eing fulfilled
closely to where the RS role is fulfilled. As such, my proposal is really not that different in practice, but the labels are different and better aligned with the capabilities
of the protocol.

[Comment from Denis] Which proposal ?

=20
We=E2=80=99ve previously talked about separating the user-facing portions of the AS into another component, and I think now might be the time to do that.
This is a very flammable strawman proposal, but what if we had the AS defined, as above, and the =E2=80=9Cconsent and authorizatio= n=E2=80=9D gathering portion
is augmented by another named component. Here let=E2=80=99s call it= an Interaction Component.

[Comment from Denis] First of all, using the privacy vocabulary, this is not =E2=80=9Cconsent and authorization=E2=80= =9D, but it is "user notice", "user choice" and "user consent".

Before making one or more choices, the end-user must be able to be informed about the reasons and /or the consequences of each choice.
Then he must be able to make some choice(s) and finally he may indicate his consent for these choices.

[FIM] possibly, but that is an assumption that could be = discussed. I've written a short description of why I think the situatio= n might be more complex than it seems=C2=A0https://fimbault.med= ium.com/consent-is-dead-long-live-consent-2d64a434cdf6=C2=A0


A key question is: At which moment such "user notice, choice and consent happens ? If an end-user has never contacted a RS before,
this happens after a "discovery" flight and BEFORE cont= acting any AS.

Since, there exist some situations where there is a single AS, some people may believe that these choices are the same whether they are made immediately
after the first RS call or after the first AS call, and hence that that is is possible to use a same building block for both cases. Unfortunately this is not the case.

As soon as a RS is trusting more than one AS, the user choice is first to select the AS(s) after being informed of which privileges are requested/needed
by a RS to respond positively on a method performed on an object.

[FIM] an option pref= light with the RS would enable this. Again issue 203.
=20 =20

Furthermore, as soon as an AS has not established a prior relationship with the RS, an AS is unable to present any choice to the end-user.

So, for the time being, we should not presume that the functions can be factored and thus it is important to consider, for the time being,
that there is no such "Interaction Component".

[FIM] At any one point in = time, there is only one AS (cf discussion in=C2=A0https://github.com/ietf-wg= -gnap/gnap-core-protocol/issues/215, with comments from Justin, Adrian = and myself). So I don't think we want to aggregate several requests to = different ASs into=C2=A0one anyways.
=20
This can take several forms based on the kind of interaction mode in use:

=C2=A0- Hosted at a URL the user is redirected to; it can then make the user log in, consent, and whatever else they need to do
=C2=A0- Hosted at a URL the user will load separately and enter in an access code
=C2=A0- An app on the user=E2=80=99s device that the user interacts with directly and which sends information back to the AS
=C2=A0- An app reachable by a messaging endpoint that the AS sends and receives structured information from
=C2=A0- The client itself that is given an indication as to what information the AS needs in order to fulfill the request; this could be MFA challenge/response, user credentials, signed claims, etc.

It=E2=80=99s the AS=E2=80=99s job to accept any and all of these that it supports and churn those into an access token.

[Comment from Denis] No. It is not necessarily the AS's job. The AS job is to place into an access token the privileges that have been requested by the client.<= /p>

The AS itself doesn=E2=80=99t ever need to have the user log in. The AS doesn=E2=80=99t necessarily need to even know who the us= er is in any way.
The AS just needs to know from a trusted source that the request is approved.
[Comment from Denis] No= , no and no again for each of these three sentences. It is rather strange to change the model and the (implicit) trust relationships at this time.
I fear that we are following a moving target.

When writing the first draft, the cart has been placed before the horse, which means that the components of the model, their relationships and their trust relationships
have not been defined, and that the protocols have been designed without a clear model and without explaining their rational.

[FIM] I don't think that&#= 39;s the case, we're starting from what people use today (OAuth2 and Op= enID), and change what seems necessary, instead of changing completely=C2= =A0the model. My point of view is that a big part - probably not everything= - of what you propose (which is interesting) can be achieved based on what= GNAP proposes (+ some adjustments that could lead to PRs).=C2=A0
=20
From a practical standpoint, I think this will have some small changes in how we talk about the components and how we talk about the interaction phase
of the grant negotiation process. Everything I=E2=80=99m laying out= here is currently allowed by the spec, but I think we=E2=80=99ve carried through the same assumptions from OAuth 2
about deployment that are both inaccurate and confusing.

[Comment from Denis] The writer surely understands what this means, but not me.
Which assumptions from OAuth 2 about deployment are both inaccurate and confusing ?

Denis

=20
=C2=A0=E2=80=94 Justin


--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000e9327405bd912c1a-- From nobody Mon Mar 15 04:43:07 2021 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 8878F3A0DAD for ; Mon, 15 Mar 2021 04:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 KyTT5gvNGJax for ; Mon, 15 Mar 2021 04:43:02 -0700 (PDT) Received: from mail-ua1-f47.google.com (mail-ua1-f47.google.com [209.85.222.47]) (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 740663A0DA1 for ; Mon, 15 Mar 2021 04:43:02 -0700 (PDT) Received: by mail-ua1-f47.google.com with SMTP id x8so4077483ual.6 for ; Mon, 15 Mar 2021 04:43:02 -0700 (PDT) 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=cahlSxZoG+688WJ4y0bkk5Q13PskWV54fnqdKpHt3Qo=; b=lTKAgczr4JHY3FHil/kGwFucSexE4yQ5o5MivMDygm5vtY4GJJREoZChyiDm3aGU7S 4VqxOxQeEUUQV4bAofuneeXnJnnU+A/FouxvGNtSnhN2kf+VyZCdPbttQkl+36FTiK7v cAhslr+qSdCc3qksTbHfgmNbOZgoyJZTZjQy1VhLHDvkl4mB/rz2+dahs/ITXcE2CTw0 oe+NGSN6R2LEJQ39lzCFyaP0CdhqEknlXCGRTj1EAgt5S5y0lxFV5dS3DpqY/uF8bcoi z4Ow4itNO6mSBoW6IHAiPwqEqYDVtjzKO/ehrhM/ohazGmaoQBCJzRnwVkdFWjYE5H00 bS7g== X-Gm-Message-State: AOAM532g+fDSVwlte2ETE1VEQpl6ICOz6kZ02JjXCBhrlzJnJvPKoCBS O2LkkSKYF90zmQYKI77whIt8cVZS1Nxzv3leIXQ= X-Google-Smtp-Source: ABdhPJxg+2xqDBER1ILLsLZMo1zbhkMcHkv7/tyOA8pm7AtS6B18hGas4h+WTRfPk1/OmNZ5WVUcbJovOj2z78riNJY= X-Received: by 2002:a9f:258e:: with SMTP id 14mr4190279uaf.128.1615808581266; Mon, 15 Mar 2021 04:43:01 -0700 (PDT) MIME-Version: 1.0 References: <205ACFE1-7D4C-4D7C-B394-4AD8A4D4D080@mit.edu> In-Reply-To: From: Adrian Gropper Date: Mon, 15 Mar 2021 07:42:49 -0400 Message-ID: To: Fabien Imbault Cc: Justin Richer , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000082f29605bd91c090" Archived-At: Subject: Re: [GNAP] GNAP Architecture and the role of the AS X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2021 11:43:07 -0000 --00000000000082f29605bd91c090 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable inline... On Mon, Mar 15, 2021 at 6:29 AM Fabien Imbault wrote: > Hi Adrian, > > It's good to check what that means in real use cases indeed. > > My view: > Items 1-2-3-7 : seems quite usual. Only in this example, the patient is > the RO and generally delegates its decision to an automated policy engine > (equivalent to seq 1.4.4). > [AG] Yes. This ability to automate under consent is foundational to any large-scale information exchange or data brokerage use-case. I believe item 4 (delegation, beyond the original token issuance) would be > hard to do using JWT, at least in a generic way. > [AG] Whatever GNAP decides for token formats, at least one of them MUST support delegation otherwise, the RO is unable to hold a requester responsible. Put another way, a zero-trust architecture SHOULD hold an individual responsible. In an SSI model, it's the individual that controls their credentials and a non-repudiable signature and it's this individual that is present at the time the request is issued so that individual can use their wallet and be subject to non-repudiation. What happens afterward is the responsibility of this requester. [AG] The end-user framing we are currently working with has blurred this distinction between the entity trusted by the RO and the entity that operates the client at the RS. This, IMHO, needs to be fixed ASAP. lest we break compatibility with zero-trust architecture for no good reason. > Items 5 is probably beyond our scope, although Denis expressed the same > requirement related to "solicits too much info" (based on non opaque > tokens, which might not be the general assumption / I personally think > token content should remain opaque to the client, but knowing the type of > the token would be useful). > [AG] I'll take the "probably" for now. It's in everyone's interest for GNAP to build on data minimization as a principle. Nobody can keep the RS from asking for too much because, by definition, the RS holds all the cards. If an RS asks for too much then the request will pass the AS but fail at the RS. In cases where the RO has a choice of RS, the RS will lose business and that should keep them from asking too much. In cases where the RO is at the mercy of the RS, the only thing GNAP might be able to do is provide useful error messages to the various parties. In other words, GNAP needs to consider which errors and warnings are in scope. > Item 6 asks for a relationship between RS and RO, which I'm not sure we'd > want to assume for the general case (although it could happen in some > scenarii). > [AG] See my perspective on Item 5 just above. It's up to GNAP to decide which errors and warnings need to be handled in scope. Beyond that, RSs and ROs will have a relationship whether GNAP likes it or not. > Item 8 is fine in principle, but would require attention to make sure it'= s > the case in practice. Depending on the sub_ids used (and even if opaque, = as > soon as dereferencing is allowed), correlation might be possible. > [AG] In the SSI world we talk in terms of mediators as a separate entity that is trusted by the RO to limit correlation. GNAP should be agnostic to whether a mediator is involved. Ideally, GNAP would note that there are two separate correlation threats. Correlation by the requesters and correlation by the RSs. Note that I don't worry about correlation by the AS because, by design, I want my agent to know everything it can and to minimize what all other participants, except the RO and RO user agent know. [AG] A mediator allows the RO to use a pseudonym to their AS endpoint as long as the RO registers the pseudonym with the mediator first. Keeping the RS (and AS) from correlating separate end-users requires the end-user (and maybe the requester) to use a mediator themselves. I don't see any of this being a problem for GNAP but it might be helpful to have an informative mention of mediators in a privacy considerations section. Adrian > > Does that seem correct? > Fabien > > On Fri, Mar 12, 2021 at 10:34 PM Adrian Gropper > wrote: > >> Let=E2=80=99s try to map a real-world use-case into the names and roles = we are >> discussing. The use-case is documented as the API Task Force >> Recommendations (2016) >> https://www.healthit.gov/sites/default/files/facas/SingleSourceofTruth-A= PITFRecommendations.pdf >> and I=E2=80=99ve copied below the most relevant section. Bold highlight = is in >> the original. I=E2=80=99ve added bold italic because it may be important= to our >> discussion. >> >> >> >> >> - >> >> ONC should clarify that while API Providers may impose security >> related restrictions on app access (e.g. rate limiting, encryption, a= nd >> expiration of access tokens), it is inappropriate for API providers t= o set >> limitations on what a patient authorized app can do with data downstr= eam. >> - >> >> Given the nature of patient access rights, the provider is not in >> a legal position to prevent the registration of apps that would ag= gregate >> or share data, for example (though the provider might certainly de= cide to >> warn the patient, or endeavor to educate and explain these issue t= o the >> patient, as part of the provider hosted app approval workflow). >> - >> >> ONC should clarify that API providers are not obligated to protect >> patients by identifying "suspicious" apps. API providers may suspend >> API access to an app that has breached the API provider's terms of >> service , or appears to have been compromised, or if the app poses a = threat >> to the provider's own system. However, patients must be able to >> override this suspension (except in the case where an app poses >> threat to the provider's own system or violates allowable terms of se= rvice). >> >> >> >> >> >> The key requirements from a patient rights and privacy perspective are: >> >> >> 1. >> >> To delegate a scope-limited access capability to anyone anywhere >> without having to explain or justify that to the API Provider. >> 2. >> >> To allow the patient to automate the issue of a scope-limited access >> capability by delegating the authority to process API access requests= to >> some agent. The API Provider has no say in who or where this agent is= . >> 3. >> >> The automation of the agent is based on policies provided by the >> patient. The agent is able to process access requests from anyone and= is >> responsible only to the patient. The agent responds to successful req= uests >> by issuing a filtered capability to the requesting party. >> 4. >> >> To ensure that the requesting party can delegate the capability using >> an institutional workflow system that they trust and the patient does= n=E2=80=99t >> know or care about. In many cases, the workflow system will pass the >> capability to some other person, who we might call the end user. In o= ther >> cases, the requesting party may forward the capability directly to an= other >> person using, for example, an email. Either way, the client app used = by the >> end-user to access the API is of no concern to the patient or to the >> patient=E2=80=99s agent. >> 5. >> >> To ensure that the API Provider does not censor the client app that >> presents the capability or solicits too much information about the cl= ient >> app or the end-user of the client app. >> 6. >> >> If the API Provider decides, for any reason, to be =E2=80=9Csuspiciou= s=E2=80=9D (as >> above) of the access transaction based on the information it has, it = should >> be possible for the API Provider to warn the patient and to accept an >> override of the warning by the patient. This effectively means that t= he >> end-user will provide as much information as they think will be neces= sary >> in order to either avoid =E2=80=9Csuspicion=E2=80=9D or risk waiting = for patient override. >> 7. >> >> The policies by which the patient or the decides to grant a >> capability to the requesting party are never shared outside of the >> patient-agent trust relationship. In other words, neither the patient= nor >> the agent is asked to share or explain their reason for an access dec= ision. >> 8. >> >> Access requests to the agent are presumed confidential among the >> patient, the agent, and whatever client the requesting party uses to >> present an access request. The API Provider does not get to see the >> requests and no entity in the GNAP authorization process, other than = the >> patient or the agent, gets to correlate across requests by different >> requesting party clients. >> >> >> Note that I am not saying all 8 requirements are in scope for GNAP but I >> am asking for GNAP to allow for this level of privacy on the part of >> self-sovereign patients using self-sovereign agents and the self-soverei= gn >> licensed professionals they deal with. >> >> Adrian >> >> >> On Fri, Mar 12, 2021 at 2:50 PM Fabien Imbault >> wrote: >> >>> Hi Justin, >>> >>> Just a quick word to say I very much agree with both the observations >>> and the framing. >>> >>> Fabien >>> >>> On Fri, Mar 12, 2021 at 6:07 PM Justin Richer wrote: >>> >>>> As discussed at the IETF meeting, the editors proposed that one of our >>>> next big topic areas was going to be the nature of the AS role within = the >>>> GNAP protocol, especially how it relates to the device-driven use case= s >>>> that have been brought up. Apologies in advance for the long post, but >>>> there are a lot of parts to this discussion that I=E2=80=99m hoping we= can kick off >>>> here. >>>> >>>> My core proposal is that we see the AS as the component that has the >>>> following properties: >>>> - receives delegation requests from the client instance for access to >>>> an RS via access tokens, and for access to subject information returne= d >>>> directly to the client instance >>>> - collects consent and authorization from the RO for the delegation >>>> - issues access tokens that its downstream RS=E2=80=99s can interpret= (and >>>> validate/accept) >>>> - issues subject information asserted by the AS >>>> >>>> This framing of the parties is really important in making a consistent >>>> understanding of how the protocol works, and a consistent understandin= g is >>>> vital if we=E2=80=99re going to function as a working group in both di= scussing the >>>> problem space and executing the solution space. For a historical examp= le, a >>>> naive approach to adding identity on top of a protocol like OAuth 2 (o= r >>>> GNAP) is to declare that the resource server is the thing the user is >>>> logging in to. This seems reasonable at first (and some people tried d= oing >>>> this) but it violates all kinds of trust boundaries and puts new >>>> expectations on the different parties that do not make sense. It stops >>>> looking anything like OAuth very quickly and turns into another protoc= ol. >>>> If instead we say the user is logging in to the client, things suddenl= y >>>> make a lot more sense and we can do a lot more with it. (See this blog= post >>>> from 2013 for one take on that discussion: >>>> https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/= ) >>>> >>>> I think we=E2=80=99ve got a similar situation here when we start to ta= lk about >>>> the user bringing their own AS with them. I think this is a >>>> reasonable-seeming assumption but it=E2=80=99s based on a false premis= e that the RO >>>> has to log into the AS to approve the request, and the AS has full con= trol >>>> and view over everything in the network. While OAuth doesn=E2=80=99t r= equire this, >>>> it=E2=80=99s largely assumed that=E2=80=99s how it works. After all, a= ll of the early OAuth >>>> deployments worked exactly this way: the user logs in and clicks the = =E2=80=9COK=E2=80=9D >>>> button. However, cloud deployments have shown us that it=E2=80=99s per= fectly >>>> reasonable for an OAuth AS to take in its consent and user information= from >>>> an external trusted source, and so this model is not even accurate in = OAuth. >>>> >>>> In short, I think we can do a better job here of defining things in >>>> terms that both accept the reality we face and enable new ideas in way= s >>>> that make sense. It=E2=80=99s my stance that the user shouldn=E2=80=99= t need to bring the >>>> AS with them in order to have the kind of input and control of the sys= tem >>>> that people are asking for. Instead, the AS should be able to take inp= uts >>>> from things that the user controls in order for the AS to do its job. >>>> >>>> People have discussed privacy concerns with the AS knowing =E2=80=9Cto= o much=E2=80=9D, >>>> but in many of those discussions the knowledge is simply pushed to the= RS >>>> instead. What I=E2=80=99m observing here is really just pushing portio= ns of the AS >>>> role into the =E2=80=9CRS=E2=80=9D deployment. This doesn=E2=80=99t ma= ke it less of an =E2=80=9CAS=E2=80=9D role, >>>> it=E2=80=99s just being fulfilled closely to where the RS role is fulf= illed. As >>>> such, my proposal is really not that different in practice, but the la= bels >>>> are different and better aligned with the capabilities of the protocol= . >>>> >>>> We=E2=80=99ve previously talked about separating the user-facing porti= ons of >>>> the AS into another component, and I think now might be the time to do >>>> that. This is a very flammable strawman proposal, but what if we had t= he AS >>>> defined, as above, and the =E2=80=9Cconsent and authorization=E2=80=9D= gathering portion is >>>> augmented by another named component. Here let=E2=80=99s call it an In= teraction >>>> Component. This can take several forms based on the kind of interactio= n >>>> mode in use: >>>> >>>> - Hosted at a URL the user is redirected to; it can then make the use= r >>>> log in, consent, and whatever else they need to do >>>> - Hosted at a URL the user will load separately and enter in an acces= s >>>> code >>>> - An app on the user=E2=80=99s device that the user interacts with di= rectly >>>> and which sends information back to the AS >>>> - An app reachable by a messaging endpoint that the AS sends and >>>> receives structured information from >>>> - The client itself that is given an indication as to what informatio= n >>>> the AS needs in order to fulfill the request; this could be MFA >>>> challenge/response, user credentials, signed claims, etc. >>>> >>>> It=E2=80=99s the AS=E2=80=99s job to accept any and all of these that = it supports and >>>> churn those into an access token. >>>> >>>> The AS itself doesn=E2=80=99t ever need to have the user log in. The A= S doesn=E2=80=99t >>>> necessarily need to even know who the user is in any way. The AS just = needs >>>> to know from a trusted source that the request is approved. >>>> >>>> From a practical standpoint, I think this will have some small changes >>>> in how we talk about the components and how we talk about the interact= ion >>>> phase of the grant negotiation process. Everything I=E2=80=99m laying = out here is >>>> currently allowed by the spec, but I think we=E2=80=99ve carried throu= gh the same >>>> assumptions from OAuth 2 about deployment that are both inaccurate and >>>> confusing. >>>> >>>> =E2=80=94 Justin >>>> -- >>>> 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 >>> >> --00000000000082f29605bd91c090 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
inline...

On Mon, Mar 15, 2021 at 6:29 AM = Fabien Imbault <fabien.imbau= lt@gmail.com> wrote:
Hi A= drian,=C2=A0

It's good to check what that means in r= eal use cases indeed.

My view:
Items 1-2-3= -7 : seems quite usual. Only in this example, the patient is the RO and gen= erally delegates its decision to an automated policy engine (equivalent to = seq 1.4.4).=C2=A0
[AG] Yes.=C2=A0 This a= bility to automate under consent=C2=A0is foundational to any large-scale in= formation exchange=C2=A0or data brokerage use-case.

I believe item 4 (delegation, beyo= nd the original token issuance) would be hard to do using JWT, at least in = a generic way.=C2=A0
[AG] Whatever GNAP = decides for token formats, at least one of them MUST support delegation oth= erwise, the RO is unable to hold a requester=C2=A0responsible. Put another = way, a zero-trust architecture SHOULD hold an individual responsible. In an= SSI model, it's the individual that controls their credentials and a n= on-repudiable signature and it's this individual that is present at the= time the request is issued so that individual can use their wallet and be = subject to non-repudiation. What happens afterward is the responsibility of= this requester.=C2=A0

[AG] The end-user framing w= e are currently working with has blurred this distinction between the entit= y trusted by the RO and the entity that operates the client at the RS. This= , IMHO, needs to be fixed ASAP. lest we break compatibility with zero-trust= architecture for no good reason.
=C2=A0
=
Items 5 is probably beyond our scope, although D= enis expressed the same requirement related to "solicits too much info= " (based on non opaque tokens, which might not be the general assumpti= on / I personally think token content should remain opaque to the client, b= ut knowing the type of the token would be useful).=C2=A0
<= /blockquote>
[AG] I'll take the "probably" for now. It= 9;s in everyone's interest for GNAP to build on data minimization=C2=A0= as a principle. Nobody can keep the RS from asking for too much because, by= definition, the RS holds all the cards. If an RS asks for too much then th= e request will pass the AS but fail at the RS. In cases where the RO has a = choice of RS, the RS will lose business and that should keep them from aski= ng too much. In cases where the RO is at the mercy of the RS, the only thin= g GNAP might be able to do is provide useful error messages to the various = parties. In other words, GNAP needs to consider which errors and warnings a= re in scope.
=C2=A0
= Item 6 asks for a relationship between RS and RO, which I'm not sure we= 'd want to assume for the general case (although it could happen in som= e scenarii).
[AG] See my perspective on Item 5= just above. It's up to GNAP to decide which errors and warnings need t= o be handled in scope. Beyond that, RSs and ROs will have a relationship wh= ether GNAP likes it or not.
=C2=A0
Item 8 is fine in principle, but would require attention to m= ake sure it's the case in practice. Depending on the sub_ids used (and = even if opaque, as soon as dereferencing is allowed), correlation might be = possible.
[AG] In the SSI world we talk in ter= ms of mediators as a separate entity that is trusted by the RO to limit cor= relation. GNAP should be agnostic to whether a mediator is involved. Ideall= y, GNAP would note that there are two separate correlation threats. Correla= tion by the requesters and correlation by the RSs. Note that I don't wo= rry about correlation by the AS because, by design, I want my agent to know= everything it can and to minimize what all other participants, except the = RO and RO user agent know.

[AG] A mediator allows = the RO to use a pseudonym to their AS endpoint as long as the RO registers = the pseudonym with the mediator first. Keeping the RS (and AS) from correla= ting separate end-users requires the end-user (and maybe the requester) to = use a mediator themselves. I don't see any of this being a problem for = GNAP but it might be helpful to have an informative mention of mediators in= a privacy considerations section.

Adrian

Does that seem correct?<= /div>
Fabien

On Fri, Mar 12, 2021 at 10:34 PM Adrian Gropper <<= a href=3D"mailto:agropper@healthurl.com" target=3D"_blank">agropper@healthu= rl.com> wrote:

Let=E2= =80=99s try to map a real-world use-case into the names and roles we are di= scussing. The use-case is documented as the API Task Force Recommendations = (2016) https://www.healthit.gov/sites/default= /files/facas/SingleSourceofTruth-APITFRecommendations.pdf and I=E2=80=99ve= copied below the most relevant section. Bold highlight is in the= original. I=E2=80=99ve added bold italic becau= se it may be important to our discussion.=C2=A0


<quote>

  • ONC should clarify that while API Providers= may impose security related restrictions on app access (e.g. rate limiting= , encryption, and expiration of access tokens), it is inappropriate for API= providers to set limitations on what a patient authorized app can do with = data downstream.

    • G= iven the nature of patient access rights, the provider is not in a legal po= sition to prevent the registration of apps that would aggregate or share da= ta, for example (though the provider might certainly decide to warn the pat= ient, or endeavor to educate and explain these issue to the patient, as par= t of the provider hosted app approval workflow).

  • ONC should cl= arify that API providers are not obligated to protect patients by identifying "suspicious" = apps. API providers may suspend API access to an app that has breached the API provider's terms o= f service , or appears to have been compromised, or if the app poses a thre= at to the provider's own system. However, patients must be= able to override this suspension (except in the case where an app poses threat to the provider&= #39;s own system or violates allowable terms of service).


</quot= e>

The key requirements from= a patient rights and privacy perspective are:


  1. To delegate a scope-limited access capability = to anyone anywhere without having to explain or justify that to the API Pro= vider.

  2. To allow the patient to automate the issue of a scope-lim= ited access capability by delegating the authority to process API access re= quests to some agent. The API Provider has no say in who or where this agen= t is.

  3. The automation of the agent is based on policies provided = by the patient. The agent is able to process access requests from anyone an= d is responsible only to the patient. The agent responds to successful requ= ests by issuing a filtered capability to the requesting party.

  4. T= o ensure that the requesting party can delegate the capability using an ins= titutional workflow system that they trust and the patient doesn=E2=80=99t = know or care about. In many cases, the workflow system will pass the capabi= lity to some other person, who we might call the end user. In other cases, = the requesting party may forward the capability directly to another person = using, for example, an email. Either way, the client app used by the end-us= er to access the API is of no concern to the patient or to the patient=E2= =80=99s agent.=C2=A0

  5. To ensure that the API Provider does not ce= nsor the client app that presents the capability or solicits too much infor= mation about the client app or the end-user of the client app.=C2=A0=

  6. If the API Provider decides, for any reason, to be =E2=80=9Csuspicious= =E2=80=9D (as above) of the access transaction based on the information it = has, it should be possible for the API Provider to warn the patient and to = accept an override of the warning by the patient. This effectively means th= at the end-user will provide as much information as they think will be nece= ssary in order to either avoid =E2=80=9Csuspicion=E2=80=9D or risk waiting = for patient override.

  7. The policies by which the patient or the d= ecides to grant a capability to the requesting party are never shared outsi= de of the patient-agent trust relationship. In other words, neither the pat= ient nor the agent is asked to share or explain their reason for an access = decision.=C2=A0

  8. Access requests to the agent are presumed confid= ential among the patient, the agent, and whatever client the requesting par= ty uses to present an access request. The API Provider does not get to see = the requests and no entity in the GNAP authorization process, other than th= e patient or the agent, gets to correlate across requests by different requ= esting party clients.


Note that I am not saying all 8 require= ments are in scope for GNAP but I am asking for GNAP to allow for this leve= l of privacy on the part of self-sovereign patients using self-sovereign ag= ents and the self-sovereign licensed professionals they deal with.

Adri= an



On Fri, Mar 12, 20= 21 at 2:50 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Justin,=C2=A0

Just a quic= k word to say I very much agree with both the observations and the framing.=

Fabien

=
On Fri, Mar 12, 2021 at 6:07 PM Justi= n Richer <jricher@m= it.edu> wrote:
As discussed at the IE= TF meeting, the editors proposed that one of our next big topic areas was g= oing to be the nature of the AS role within the GNAP protocol, especially h= ow it relates to the device-driven use cases that have been brought up. Apo= logies in advance for the long post, but there are a lot of parts to this d= iscussion that I=E2=80=99m hoping we can kick off here.

= My core proposal is that we see the AS as the component that has the follow= ing properties:
=C2=A0- receives delegation requests from the cli= ent instance for access to an RS via access tokens, and for access to subje= ct information returned directly to the client instance
=C2=A0- c= ollects consent and authorization from the RO for the delegation
= =C2=A0- issues access tokens that its downstream RS=E2=80=99s can interpret= (and validate/accept)
=C2=A0- issues subject information asserte= d by the AS=C2=A0

This framing of the parties is rea= lly important in making a consistent understanding of how the protocol work= s, and a consistent understanding is vital if we=E2=80=99re going to functi= on as a working group in both discussing the problem space and executing th= e solution space. For a historical example, a naive approach to adding iden= tity on top of a protocol like OAuth 2 (or GNAP) is to declare that the res= ource server is the thing the user is logging in to. This seems reasonable = at first (and some people tried doing this) but it violates all kinds of tr= ust boundaries and puts new expectations on the different parties that do n= ot make sense. It stops looking anything like OAuth very quickly and turns = into another protocol. If instead we say the user is logging in to the clie= nt, things suddenly make a lot more sense and we can do a lot more with it.= (See this blog post from 2013 for one take on that discussion:=C2=A0https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0= -and-sign-in-4/)

I think we=E2=80=99ve got a s= imilar situation here when we start to talk about the user bringing their o= wn AS with them. I think this is a reasonable-seeming assumption but it=E2= =80=99s based on a false premise that the RO has to log into the AS to appr= ove the request, and the AS has full control and view over everything in th= e network. While OAuth doesn=E2=80=99t require this, it=E2=80=99s largely a= ssumed that=E2=80=99s how it works. After all, all of the early OAuth deplo= yments worked exactly this way: the user logs in and clicks the =E2=80=9COK= =E2=80=9D button. However, cloud deployments have shown us that it=E2=80=99= s perfectly reasonable for an OAuth AS to take in its consent and user info= rmation from an external trusted source, and so this model is not even accu= rate in OAuth.

In short, I think we can do a bette= r job here of defining things in terms that both accept the reality we face= and enable new ideas in ways that make sense. It=E2=80=99s my stance that = the user shouldn=E2=80=99t need to bring the AS with them in order to have = the kind of input and control of the system that people are asking for. Ins= tead, the AS should be able to take inputs from things that the user contro= ls in order for the AS to do its job.

People have = discussed privacy concerns with the AS knowing =E2=80=9Ctoo much=E2=80=9D, = but in many of those discussions the knowledge is simply pushed to the RS i= nstead. What I=E2=80=99m observing here is really just pushing portions of = the AS role into the =E2=80=9CRS=E2=80=9D deployment. This doesn=E2=80=99t = make it less of an =E2=80=9CAS=E2=80=9D role, it=E2=80=99s just being fulfi= lled closely to where the RS role is fulfilled. As such, my proposal is rea= lly not that different in practice, but the labels are different and better= aligned with the capabilities of the protocol.=C2=A0

<= /div>
We=E2=80=99ve previously talked about separating the user-facing = portions of the AS into another component, and I think now might be the tim= e to do that. This is a very flammable strawman proposal, but what if we ha= d the AS defined, as above, and the =E2=80=9Cconsent and authorization=E2= =80=9D gathering portion is augmented by another named component. Here let= =E2=80=99s call it an Interaction Component. This can take several forms ba= sed on the kind of interaction mode in use:

=C2=A0= - Hosted at a URL the user is redirected to; it can then make the user log = in, consent, and whatever else they need to do
=C2=A0- Hosted at = a URL the user will load separately and enter in an access code
= =C2=A0- An app on the user=E2=80=99s device that the user interacts with di= rectly and which sends information back to the AS
=C2=A0- An app = reachable by a messaging endpoint that the AS sends and receives structured= information from
=C2=A0- The client itself that is given an indi= cation as to what information the AS needs in order to fulfill the request;= this could be MFA challenge/response, user credentials, signed claims, etc= .

It=E2=80=99s the AS=E2=80=99s job to accept any = and all of these that it supports and churn those into an access token.=C2= =A0

The AS itself doesn=E2=80=99t ever need to hav= e the user log in. The AS doesn=E2=80=99t necessarily need to even know who= the user is in any way. The AS just needs to know from a trusted source th= at the request is approved.

From a practical stand= point, I think this will have some small changes in how we talk about the c= omponents and how we talk about the interaction phase of the grant negotiat= ion process. Everything I=E2=80=99m laying out here is currently allowed by= the spec, but I think we=E2=80=99ve carried through the same assumptions f= rom OAuth 2 about deployment that are both inaccurate and confusing.=C2=A0<= /div>

=C2=A0=E2=80=94 Justin
--
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
--00000000000082f29605bd91c090-- From nobody Mon Mar 15 04:56:38 2021 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 2A33C3A0E19 for ; Mon, 15 Mar 2021 04:56:36 -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 kjhz81QWA4jn for ; Mon, 15 Mar 2021 04:56:31 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 B95663A0E1C for ; Mon, 15 Mar 2021 04:56:31 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id 81so32981523iou.11 for ; Mon, 15 Mar 2021 04:56: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=hPqjuusix9RC7dTrjPSj3bCmVs/zI3JfB4Zyr+cmc8U=; b=f4RIg1ez9SSE9Q26vq3j4RGHQd0noukEkmx5N98937pQLHh676CZFxi9dpOnL69sTZ wIZ9uwev0uF9+XGiIuV0i5cAJr57+kabUmaZLwcveOiNIiQR0vuGq3hb9rbBpVKgpvrU DPL4LIgErVNXPwChD5CqUb83HbZvRUvrnZYNnnW4IA9QzC5KBE/72PNDLWKK0pTHVIuU 5PKqQhhEylAdDkcAo5p1EoDeAtp6Cj7vJxXMUDshMsswUo8ctunnY9apaIMXZd2hAVG3 cUHbHKQ82dMVJSe3BeXDK6Q1rlG9SxhYWGCZBB1nWL5DWvFSeEfuQq9TwymT5mqhcQ6I h6rA== 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=hPqjuusix9RC7dTrjPSj3bCmVs/zI3JfB4Zyr+cmc8U=; b=pxeAUozir5myEm7tlB8QaPodHmJYMcnTr59VumoVT6D5pdR51O3jobQYA9tP8T7StK 5LNiLMLz6Sl/JdE50JlSlRdpS48ynOF4vbvT3OE2ZNKNaQ1tC6SRZbAOGC/4Vlr1A6Fq hRcSJWbQ/zNBAEaSC6oboMl4tD1WfSQAllfqgpIPdcEHkuhLOpvzm1vf2kpjU1lqda2V Reg5dfR1GSOlfrFZhG2Fzv6ncNEgmwUbFxKEETMiAnWy0PLq2jq8KgKwbpwwdicE2pUe Mck2DxA9WPvhmLhfzdQ6rVWJKpKBPXMl1m79q/fU1I74kmAm22nWIfZQocd2OYfRzJG7 hQzw== X-Gm-Message-State: AOAM532A5rddvnBOj+I44Bzhw7caaTKjYvZU/OX9e07fp59YbND2Ym4w u2UchbQXkWg/geFaMNfbH9ngxhvXzMxkzwQgoS8= X-Google-Smtp-Source: ABdhPJzjB8jiGbMgk/OdeWXx4LGUrrBSZ8YUDKEAbU0xTF23lSR/jgTWwW5R4p8gNFEf9J0icJVc98PrsKXToy5ijBo= X-Received: by 2002:a02:ca13:: with SMTP id i19mr9244895jak.47.1615809389124; Mon, 15 Mar 2021 04:56:29 -0700 (PDT) MIME-Version: 1.0 References: <205ACFE1-7D4C-4D7C-B394-4AD8A4D4D080@mit.edu> In-Reply-To: From: Fabien Imbault Date: Mon, 15 Mar 2021 12:56:18 +0100 Message-ID: To: Adrian Gropper Cc: Justin Richer , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000a9de4d05bd91f0f2" Archived-At: Subject: Re: [GNAP] GNAP Architecture and the role of the AS X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2021 11:56:36 -0000 --000000000000a9de4d05bd91f0f2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Adrian. Useful comments, thanks. "The end-user framing we are currently working with has blurred this distinction between the entity trusted by the RO and the entity that operates the client at the RS. This, IMHO, needs to be fixed ASAP." What do you suggest? Thxs Fabien On Mon, Mar 15, 2021 at 12:43 PM Adrian Gropper wrote: > inline... > > On Mon, Mar 15, 2021 at 6:29 AM Fabien Imbault > wrote: > >> Hi Adrian, >> >> It's good to check what that means in real use cases indeed. >> >> My view: >> Items 1-2-3-7 : seems quite usual. Only in this example, the patient is >> the RO and generally delegates its decision to an automated policy engin= e >> (equivalent to seq 1.4.4). >> > [AG] Yes. This ability to automate under consent is foundational to any > large-scale information exchange or data brokerage use-case. > > I believe item 4 (delegation, beyond the original token issuance) would b= e >> hard to do using JWT, at least in a generic way. >> > [AG] Whatever GNAP decides for token formats, at least one of them MUST > support delegation otherwise, the RO is unable to hold a > requester responsible. Put another way, a zero-trust architecture SHOULD > hold an individual responsible. In an SSI model, it's the individual that > controls their credentials and a non-repudiable signature and it's this > individual that is present at the time the request is issued so that > individual can use their wallet and be subject to non-repudiation. What > happens afterward is the responsibility of this requester. > > [AG] The end-user framing we are currently working with has blurred this > distinction between the entity trusted by the RO and the entity that > operates the client at the RS. This, IMHO, needs to be fixed ASAP. lest w= e > break compatibility with zero-trust architecture for no good reason. > > >> Items 5 is probably beyond our scope, although Denis expressed the same >> requirement related to "solicits too much info" (based on non opaque >> tokens, which might not be the general assumption / I personally think >> token content should remain opaque to the client, but knowing the type o= f >> the token would be useful). >> > [AG] I'll take the "probably" for now. It's in everyone's interest for > GNAP to build on data minimization as a principle. Nobody can keep the RS > from asking for too much because, by definition, the RS holds all the > cards. If an RS asks for too much then the request will pass the AS but > fail at the RS. In cases where the RO has a choice of RS, the RS will los= e > business and that should keep them from asking too much. In cases where t= he > RO is at the mercy of the RS, the only thing GNAP might be able to do is > provide useful error messages to the various parties. In other words, GNA= P > needs to consider which errors and warnings are in scope. > > >> Item 6 asks for a relationship between RS and RO, which I'm not sure we'= d >> want to assume for the general case (although it could happen in some >> scenarii). >> > [AG] See my perspective on Item 5 just above. It's up to GNAP to decide > which errors and warnings need to be handled in scope. Beyond that, RSs a= nd > ROs will have a relationship whether GNAP likes it or not. > > >> Item 8 is fine in principle, but would require attention to make sure >> it's the case in practice. Depending on the sub_ids used (and even if >> opaque, as soon as dereferencing is allowed), correlation might be possi= ble. >> > [AG] In the SSI world we talk in terms of mediators as a separate entity > that is trusted by the RO to limit correlation. GNAP should be agnostic t= o > whether a mediator is involved. Ideally, GNAP would note that there are t= wo > separate correlation threats. Correlation by the requesters and correlati= on > by the RSs. Note that I don't worry about correlation by the AS because, = by > design, I want my agent to know everything it can and to minimize what al= l > other participants, except the RO and RO user agent know. > > [AG] A mediator allows the RO to use a pseudonym to their AS endpoint as > long as the RO registers the pseudonym with the mediator first. Keeping t= he > RS (and AS) from correlating separate end-users requires the end-user (an= d > maybe the requester) to use a mediator themselves. I don't see any of thi= s > being a problem for GNAP but it might be helpful to have an informative > mention of mediators in a privacy considerations section. > > Adrian > >> >> Does that seem correct? >> Fabien >> >> On Fri, Mar 12, 2021 at 10:34 PM Adrian Gropper >> wrote: >> >>> Let=E2=80=99s try to map a real-world use-case into the names and roles= we are >>> discussing. The use-case is documented as the API Task Force >>> Recommendations (2016) >>> https://www.healthit.gov/sites/default/files/facas/SingleSourceofTruth-= APITFRecommendations.pdf >>> and I=E2=80=99ve copied below the most relevant section. Bold highlight= is in >>> the original. I=E2=80=99ve added bold italic because it may be importan= t to our >>> discussion. >>> >>> >>> >>> >>> - >>> >>> ONC should clarify that while API Providers may impose security >>> related restrictions on app access (e.g. rate limiting, encryption, = and >>> expiration of access tokens), it is inappropriate for API providers = to set >>> limitations on what a patient authorized app can do with data downst= ream. >>> - >>> >>> Given the nature of patient access rights, the provider is not in >>> a legal position to prevent the registration of apps that would a= ggregate >>> or share data, for example (though the provider might certainly d= ecide to >>> warn the patient, or endeavor to educate and explain these issue = to the >>> patient, as part of the provider hosted app approval workflow). >>> - >>> >>> ONC should clarify that API providers are not obligated to protect >>> patients by identifying "suspicious" apps. API providers may suspend >>> API access to an app that has breached the API provider's terms of >>> service , or appears to have been compromised, or if the app poses a= threat >>> to the provider's own system. However, patients must be able to >>> override this suspension (except in the case where an app poses >>> threat to the provider's own system or violates allowable terms of s= ervice). >>> >>> >>> >>> >>> >>> The key requirements from a patient rights and privacy perspective are: >>> >>> >>> 1. >>> >>> To delegate a scope-limited access capability to anyone anywhere >>> without having to explain or justify that to the API Provider. >>> 2. >>> >>> To allow the patient to automate the issue of a scope-limited access >>> capability by delegating the authority to process API access request= s to >>> some agent. The API Provider has no say in who or where this agent i= s. >>> 3. >>> >>> The automation of the agent is based on policies provided by the >>> patient. The agent is able to process access requests from anyone an= d is >>> responsible only to the patient. The agent responds to successful re= quests >>> by issuing a filtered capability to the requesting party. >>> 4. >>> >>> To ensure that the requesting party can delegate the capability >>> using an institutional workflow system that they trust and the patie= nt >>> doesn=E2=80=99t know or care about. In many cases, the workflow syst= em will pass >>> the capability to some other person, who we might call the end user.= In >>> other cases, the requesting party may forward the capability directl= y to >>> another person using, for example, an email. Either way, the client = app >>> used by the end-user to access the API is of no concern to the patie= nt or >>> to the patient=E2=80=99s agent. >>> 5. >>> >>> To ensure that the API Provider does not censor the client app that >>> presents the capability or solicits too much information about the c= lient >>> app or the end-user of the client app. >>> 6. >>> >>> If the API Provider decides, for any reason, to be =E2=80=9Csuspicio= us=E2=80=9D (as >>> above) of the access transaction based on the information it has, it= should >>> be possible for the API Provider to warn the patient and to accept a= n >>> override of the warning by the patient. This effectively means that = the >>> end-user will provide as much information as they think will be nece= ssary >>> in order to either avoid =E2=80=9Csuspicion=E2=80=9D or risk waiting= for patient override. >>> 7. >>> >>> The policies by which the patient or the decides to grant a >>> capability to the requesting party are never shared outside of the >>> patient-agent trust relationship. In other words, neither the patien= t nor >>> the agent is asked to share or explain their reason for an access de= cision. >>> 8. >>> >>> Access requests to the agent are presumed confidential among the >>> patient, the agent, and whatever client the requesting party uses to >>> present an access request. The API Provider does not get to see the >>> requests and no entity in the GNAP authorization process, other than= the >>> patient or the agent, gets to correlate across requests by different >>> requesting party clients. >>> >>> >>> Note that I am not saying all 8 requirements are in scope for GNAP but = I >>> am asking for GNAP to allow for this level of privacy on the part of >>> self-sovereign patients using self-sovereign agents and the self-sovere= ign >>> licensed professionals they deal with. >>> >>> Adrian >>> >>> >>> On Fri, Mar 12, 2021 at 2:50 PM Fabien Imbault >>> wrote: >>> >>>> Hi Justin, >>>> >>>> Just a quick word to say I very much agree with both the observations >>>> and the framing. >>>> >>>> Fabien >>>> >>>> On Fri, Mar 12, 2021 at 6:07 PM Justin Richer wrote: >>>> >>>>> As discussed at the IETF meeting, the editors proposed that one of ou= r >>>>> next big topic areas was going to be the nature of the AS role within= the >>>>> GNAP protocol, especially how it relates to the device-driven use cas= es >>>>> that have been brought up. Apologies in advance for the long post, bu= t >>>>> there are a lot of parts to this discussion that I=E2=80=99m hoping w= e can kick off >>>>> here. >>>>> >>>>> My core proposal is that we see the AS as the component that has the >>>>> following properties: >>>>> - receives delegation requests from the client instance for access t= o >>>>> an RS via access tokens, and for access to subject information return= ed >>>>> directly to the client instance >>>>> - collects consent and authorization from the RO for the delegation >>>>> - issues access tokens that its downstream RS=E2=80=99s can interpre= t (and >>>>> validate/accept) >>>>> - issues subject information asserted by the AS >>>>> >>>>> This framing of the parties is really important in making a consisten= t >>>>> understanding of how the protocol works, and a consistent understandi= ng is >>>>> vital if we=E2=80=99re going to function as a working group in both d= iscussing the >>>>> problem space and executing the solution space. For a historical exam= ple, a >>>>> naive approach to adding identity on top of a protocol like OAuth 2 (= or >>>>> GNAP) is to declare that the resource server is the thing the user is >>>>> logging in to. This seems reasonable at first (and some people tried = doing >>>>> this) but it violates all kinds of trust boundaries and puts new >>>>> expectations on the different parties that do not make sense. It stop= s >>>>> looking anything like OAuth very quickly and turns into another proto= col. >>>>> If instead we say the user is logging in to the client, things sudden= ly >>>>> make a lot more sense and we can do a lot more with it. (See this blo= g post >>>>> from 2013 for one take on that discussion: >>>>> https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4= / >>>>> ) >>>>> >>>>> I think we=E2=80=99ve got a similar situation here when we start to t= alk about >>>>> the user bringing their own AS with them. I think this is a >>>>> reasonable-seeming assumption but it=E2=80=99s based on a false premi= se that the RO >>>>> has to log into the AS to approve the request, and the AS has full co= ntrol >>>>> and view over everything in the network. While OAuth doesn=E2=80=99t = require this, >>>>> it=E2=80=99s largely assumed that=E2=80=99s how it works. After all, = all of the early OAuth >>>>> deployments worked exactly this way: the user logs in and clicks the = =E2=80=9COK=E2=80=9D >>>>> button. However, cloud deployments have shown us that it=E2=80=99s pe= rfectly >>>>> reasonable for an OAuth AS to take in its consent and user informatio= n from >>>>> an external trusted source, and so this model is not even accurate in= OAuth. >>>>> >>>>> In short, I think we can do a better job here of defining things in >>>>> terms that both accept the reality we face and enable new ideas in wa= ys >>>>> that make sense. It=E2=80=99s my stance that the user shouldn=E2=80= =99t need to bring the >>>>> AS with them in order to have the kind of input and control of the sy= stem >>>>> that people are asking for. Instead, the AS should be able to take in= puts >>>>> from things that the user controls in order for the AS to do its job. >>>>> >>>>> People have discussed privacy concerns with the AS knowing =E2=80=9Ct= oo much=E2=80=9D, >>>>> but in many of those discussions the knowledge is simply pushed to th= e RS >>>>> instead. What I=E2=80=99m observing here is really just pushing porti= ons of the AS >>>>> role into the =E2=80=9CRS=E2=80=9D deployment. This doesn=E2=80=99t m= ake it less of an =E2=80=9CAS=E2=80=9D role, >>>>> it=E2=80=99s just being fulfilled closely to where the RS role is ful= filled. As >>>>> such, my proposal is really not that different in practice, but the l= abels >>>>> are different and better aligned with the capabilities of the protoco= l. >>>>> >>>>> We=E2=80=99ve previously talked about separating the user-facing port= ions of >>>>> the AS into another component, and I think now might be the time to d= o >>>>> that. This is a very flammable strawman proposal, but what if we had = the AS >>>>> defined, as above, and the =E2=80=9Cconsent and authorization=E2=80= =9D gathering portion is >>>>> augmented by another named component. Here let=E2=80=99s call it an I= nteraction >>>>> Component. This can take several forms based on the kind of interacti= on >>>>> mode in use: >>>>> >>>>> - Hosted at a URL the user is redirected to; it can then make the >>>>> user log in, consent, and whatever else they need to do >>>>> - Hosted at a URL the user will load separately and enter in an >>>>> access code >>>>> - An app on the user=E2=80=99s device that the user interacts with d= irectly >>>>> and which sends information back to the AS >>>>> - An app reachable by a messaging endpoint that the AS sends and >>>>> receives structured information from >>>>> - The client itself that is given an indication as to what >>>>> information the AS needs in order to fulfill the request; this could = be MFA >>>>> challenge/response, user credentials, signed claims, etc. >>>>> >>>>> It=E2=80=99s the AS=E2=80=99s job to accept any and all of these that= it supports and >>>>> churn those into an access token. >>>>> >>>>> The AS itself doesn=E2=80=99t ever need to have the user log in. The = AS >>>>> doesn=E2=80=99t necessarily need to even know who the user is in any = way. The AS >>>>> just needs to know from a trusted source that the request is approved= . >>>>> >>>>> From a practical standpoint, I think this will have some small change= s >>>>> in how we talk about the components and how we talk about the interac= tion >>>>> phase of the grant negotiation process. Everything I=E2=80=99m laying= out here is >>>>> currently allowed by the spec, but I think we=E2=80=99ve carried thro= ugh the same >>>>> assumptions from OAuth 2 about deployment that are both inaccurate an= d >>>>> confusing. >>>>> >>>>> =E2=80=94 Justin >>>>> -- >>>>> 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 >>>> >>> --000000000000a9de4d05bd91f0f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Adrian.=C2=A0

Useful comments, t= hanks.=C2=A0

"The end-user framing we are cur= rently working with has blurred this distinction between the entity trusted= by the RO and the entity that operates the client at the RS. This, IMHO, n= eeds to be fixed ASAP." What do you suggest?

= Thxs
Fabien





On Mon, Mar 15, 2021 at 12:43 PM Adrian Gropper <agropper@healthurl.com> wrote:
inline...

On Mon, Mar 15, 2021 at 6:29 AM Fabien Imbault <fabien.imbault@g= mail.com> wrote:
Hi Adrian,=C2=A0

It's good = to check what that means in real use cases indeed.

M= y view:
Items 1-2-3-7 : seems quite usual. Only in this example, = the patient is the RO and generally delegates its decision to an automated = policy engine (equivalent to seq 1.4.4).=C2=A0
[AG] Yes.=C2=A0 This ability to automate under consent=C2=A0is found= ational to any large-scale information exchange=C2=A0or data brokerage use-= case.

I believe item 4 (delegation, beyond the origin= al token issuance) would be hard to do using JWT, at least in a generic way= .=C2=A0
[AG] Whatever GNAP decides for t= oken formats, at least one of them MUST support delegation otherwise, the R= O is unable to hold a requester=C2=A0responsible. Put another way, a zero-t= rust architecture SHOULD hold an individual responsible. In an SSI model, i= t's the individual that controls their credentials and a non-repudiable= signature and it's this individual that is present at the time the req= uest is issued so that individual can use their wallet and be subject to no= n-repudiation. What happens afterward is the responsibility of this request= er.=C2=A0

[AG] The end-user framing we are current= ly working with has blurred this distinction between the entity trusted by = the RO and the entity that operates the client at the RS. This, IMHO, needs= to be fixed ASAP. lest we break compatibility with zero-trust architecture= for no good reason.
=C2=A0
Items 5 is probably beyond our= scope, although Denis expressed the same requirement related to "soli= cits too much info" (based on non opaque tokens, which might not be th= e general assumption / I personally think token content should remain opaqu= e to the client, but knowing the type of the token would be useful).=C2=A0<= /div>
[AG] I'll take the "probably&qu= ot; for now. It's in everyone's interest for GNAP to build on data = minimization=C2=A0as a principle. Nobody can keep the RS from asking for to= o much because, by definition, the RS holds all the cards. If an RS asks fo= r too much then the request will pass the AS but fail at the RS. In cases w= here the RO has a choice of RS, the RS will lose business and that should k= eep them from asking too much. In cases where the RO is at the mercy of the= RS, the only thing GNAP might be able to do is provide useful error messag= es to the various parties. In other words, GNAP needs to consider which err= ors and warnings are in scope.
=C2=A0
Item 6 asks for a relatio= nship between RS and RO, which I'm not sure we'd want to assume for= the general case (although it could happen in some scenarii).
<= /blockquote>
[AG] See my perspective on Item 5 just above. It's up = to GNAP to decide which errors and warnings need to be handled in scope. Be= yond that, RSs and ROs will have a relationship whether GNAP likes it or no= t.
=C2=A0
=
Item 8 is fine in principle, but would require attent= ion to make sure it's the case in practice. Depending on the sub_ids us= ed (and even if opaque, as soon as dereferencing is allowed), correlation m= ight be possible.
[AG] In the SSI world we tal= k in terms of mediators as a separate entity that is trusted by the RO to l= imit correlation. GNAP should be agnostic to whether a mediator is involved= . Ideally, GNAP would note that there are two separate correlation threats.= Correlation by the requesters and correlation by the RSs. Note that I don&= #39;t worry about correlation by the AS because, by design, I want my agent= to know everything it can and to minimize what all other participants, exc= ept the RO and RO user agent know.

[AG] A mediator= allows the RO to use a pseudonym to their AS endpoint as long as the RO re= gisters the pseudonym with the mediator first. Keeping the RS (and AS) from= correlating separate end-users requires the end-user (and maybe the reques= ter) to use a mediator themselves. I don't see any of this being a prob= lem for GNAP but it might be helpful to have an informative mention of medi= ators in a privacy considerations section.

Adrian<= /div>

Does that seem correct?
Fabien

On Fri, Mar = 12, 2021 at 10:34 PM Adrian Gropper <agropper@healthurl.com> wrote:

Let=E2=80=99s try to map a real-world use-case into the = names and roles we are discussing. The use-case is documented as the API Ta= sk Force Recommendations (2016) https://www.h= ealthit.gov/sites/default/files/facas/SingleSourceofTruth-APITFRecommendati= ons.pdf and I=E2=80=99ve copied below the most relevant section. Bold highlight is in the original. I=E2=80=99ve added bold italic because it may be important to our discussion.=C2=A0<= /span>

=

<quote><= /span>

  • ONC should clarif= y that while API Providers may impose security related restrictions on app = access (e.g. rate limiting, encryption, and expiration of access tokens), i= t is inappropriate for API providers to set limitations on what a patient a= uthorized app can do with data downstream.

    • Given the nature of patient access rights, the p= rovider is not in a legal position to prevent the registration of apps that= would aggregate or share data, for example (though the provider might cert= ainly decide to warn the patient, or endeavor to educate and explain these = issue to the patient, as part of the provider hosted app approval workflow)= .

  • ONC should clarify that API providers are not obligated to protect patients by identif= ying "suspicious" apps. API providers may suspend API access to an app that has breached th= e API provider's terms of service , or appears to have been compromised= , or if the app poses a threat to the provider's own system. However, <= /span>patients must be able to override this suspension (except in the case where an app p= oses threat to the provider's own system or violates allowable terms of= service).


</quote>

  • To delegate a scope= -limited access capability to anyone anywhere without having to explain or = justify that to the API Provider.

  • To allow the patient to automa= te the issue of a scope-limited access capability by delegating the authori= ty to process API access requests to some agent. The API Provider has no sa= y in who or where this agent is.

  • The automation of the agent is = based on policies provided by the patient. The agent is able to process acc= ess requests from anyone and is responsible only to the patient. The agent = responds to successful requests by issuing a filtered capability to the req= uesting party.

  • To ensure that the requesting party can delegate= the capability using an institutional workflow system that they trust and = the patient doesn=E2=80=99t know or care about. In many cases, the workflow= system will pass the capability to some other person, who we might call th= e end user. In other cases, the requesting party may forward the capability= directly to another person using, for example, an email. Either way, the c= lient app used by the end-user to access the API is of no concern to the pa= tient or to the patient=E2=80=99s agent.=C2=A0

  • To ensure that th= e API Provider does not censor the client app that presents the capability = or solicits too much information about the client app or the end-user of th= e client app.=C2=A0

  • If the API Provider decides, for any reason,= to be =E2=80=9Csuspicious=E2=80=9D (as above) of the access transaction ba= sed on the information it has, it should be possible for the API Provider t= o warn the patient and to accept an override of the warning by the patient.= This effectively means that the end-user will provide as much information = as they think will be necessary in order to either avoid =E2=80=9Csuspicion= =E2=80=9D or risk waiting for patient override.

  • The policies by = which the patient or the decides to grant a capability to the requesting pa= rty are never shared outside of the patient-agent trust relationship. In ot= her words, neither the patient nor the agent is asked to share or explain t= heir reason for an access decision.=C2=A0

  • Access requests to the= agent are presumed confidential among the patient, the agent, and whatever= client the requesting party uses to present an access request. The API Pro= vider does not get to see the requests and no entity in the GNAP authorizat= ion process, other than the patient or the agent, gets to correlate across = requests by different requesting party clients.


    • Note that I a= m not saying all 8 requirements are in scope for GNAP but I am asking for G= NAP to allow for this level of privacy on the part of self-sovereign patien= ts using self-sovereign agents and the self-sovereign licensed professional= s they deal with.


    Adrian



    On Fri, Mar 12, 2021 at 2:50 PM Fabien Imbault <fabien.imbault@gmail.com&= gt; wrote:
    Hi Justin,=C2=A0

    Just a quick word to say I = very much agree with both the observations and the framing.

    <= /div>
    Fabien

    On Fri, Mar 12, 2021 at 6:07 PM Justin Richer <jricher@mit.edu> w= rote:
    As di= scussed at the IETF meeting, the editors proposed that one of our next big = topic areas was going to be the nature of the AS role within the GNAP proto= col, especially how it relates to the device-driven use cases that have bee= n brought up. Apologies in advance for the long post, but there are a lot o= f parts to this discussion that I=E2=80=99m hoping we can kick off here.
    My core proposal is that we see the AS as the component th= at has the following properties:
    =C2=A0- receives delegation requ= ests from the client instance for access to an RS via access tokens, and fo= r access to subject information returned directly to the client instance
    =C2=A0- collects consent and authorization from the RO for the dele= gation
    =C2=A0- issues access tokens that its downstream RS=E2=80= =99s can interpret (and validate/accept)
    =C2=A0- issues subject i= nformation asserted by the AS=C2=A0

    This framing of = the parties is really important in making a consistent understanding of how= the protocol works, and a consistent understanding is vital if we=E2=80=99= re going to function as a working group in both discussing the problem spac= e and executing the solution space. For a historical example, a naive appro= ach to adding identity on top of a protocol like OAuth 2 (or GNAP) is to de= clare that the resource server is the thing the user is logging in to. This= seems reasonable at first (and some people tried doing this) but it violat= es all kinds of trust boundaries and puts new expectations on the different= parties that do not make sense. It stops looking anything like OAuth very = quickly and turns into another protocol. If instead we say the user is logg= ing in to the client, things suddenly make a lot more sense and we can do a= lot more with it. (See this blog post from 2013 for one take on that discu= ssion:=C2=A0https://www.cloudidentity.com/blog/20= 13/01/02/oauth-2-0-and-sign-in-4/)

    I think we= =E2=80=99ve got a similar situation here when we start to talk about the us= er bringing their own AS with them. I think this is a reasonable-seeming as= sumption but it=E2=80=99s based on a false premise that the RO has to log i= nto the AS to approve the request, and the AS has full control and view ove= r everything in the network. While OAuth doesn=E2=80=99t require this, it= =E2=80=99s largely assumed that=E2=80=99s how it works. After all, all of t= he early OAuth deployments worked exactly this way: the user logs in and cl= icks the =E2=80=9COK=E2=80=9D button. However, cloud deployments have shown= us that it=E2=80=99s perfectly reasonable for an OAuth AS to take in its c= onsent and user information from an external trusted source, and so this mo= del is not even accurate in OAuth.

    In short, I thi= nk we can do a better job here of defining things in terms that both accept= the reality we face and enable new ideas in ways that make sense. It=E2=80= =99s my stance that the user shouldn=E2=80=99t need to bring the AS with th= em in order to have the kind of input and control of the system that people= are asking for. Instead, the AS should be able to take inputs from things = that the user controls in order for the AS to do its job.

    People have discussed privacy concerns with the AS knowing =E2=80= =9Ctoo much=E2=80=9D, but in many of those discussions the knowledge is sim= ply pushed to the RS instead. What I=E2=80=99m observing here is really jus= t pushing portions of the AS role into the =E2=80=9CRS=E2=80=9D deployment.= This doesn=E2=80=99t make it less of an =E2=80=9CAS=E2=80=9D role, it=E2= =80=99s just being fulfilled closely to where the RS role is fulfilled. As = such, my proposal is really not that different in practice, but the labels = are different and better aligned with the capabilities of the protocol.=C2= =A0

    We=E2=80=99ve previously talked about se= parating the user-facing portions of the AS into another component, and I t= hink now might be the time to do that. This is a very flammable strawman pr= oposal, but what if we had the AS defined, as above, and the =E2=80=9Cconse= nt and authorization=E2=80=9D gathering portion is augmented by another nam= ed component. Here let=E2=80=99s call it an Interaction Component. This can= take several forms based on the kind of interaction mode in use:

    =C2=A0- Hosted at a URL the user is redirected to; it can t= hen make the user log in, consent, and whatever else they need to do
    <= div>=C2=A0- Hosted at a URL the user will load separately and enter in an a= ccess code
    =C2=A0- An app on the user=E2=80=99s device that the u= ser interacts with directly and which sends information back to the AS
    =C2=A0- An app reachable by a messaging endpoint that the AS sends an= d receives structured information from
    =C2=A0- The client itself = that is given an indication as to what information the AS needs in order to= fulfill the request; this could be MFA challenge/response, user credential= s, signed claims, etc.

    It=E2=80=99s the AS=E2=80= =99s job to accept any and all of these that it supports and churn those in= to an access token.=C2=A0

    The AS itself doesn=E2= =80=99t ever need to have the user log in. The AS doesn=E2=80=99t necessari= ly need to even know who the user is in any way. The AS just needs to know = from a trusted source that the request is approved.

    From a practical standpoint, I think this will have some small changes in= how we talk about the components and how we talk about the interaction pha= se of the grant negotiation process. Everything I=E2=80=99m laying out here= is currently allowed by the spec, but I think we=E2=80=99ve carried throug= h the same assumptions from OAuth 2 about deployment that are both inaccura= te and confusing.=C2=A0

    =C2=A0=E2=80=94 Justin
    --
    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
    --000000000000a9de4d05bd91f0f2-- From nobody Mon Mar 15 06:50:12 2021 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 6E1283A1220 for ; Mon, 15 Mar 2021 06:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 NrLwIhtkaMkH for ; Mon, 15 Mar 2021 06:50:07 -0700 (PDT) Received: from mail-vk1-f179.google.com (mail-vk1-f179.google.com [209.85.221.179]) (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 9D1CC3A1221 for ; Mon, 15 Mar 2021 06:50:07 -0700 (PDT) Received: by mail-vk1-f179.google.com with SMTP id o4so2836515vka.12 for ; Mon, 15 Mar 2021 06:50:07 -0700 (PDT) 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=YvDtt2cr4W94FO4JdHJu+d5q1k3HtIXkwtZ8UFkXoxI=; b=tyd0cmqXrtnpnUvhF/tCg1+JGMGFP/4deLyIu1EQ14B4F4ATTySInnKcz7i3dNPVSY oYrnrujjUxy1Uq8qSuMKIdW1X4canjHjF0zaB/Bx8nW7O4gwvod5Wxv4mC/m9s4QvXyH Q/DrGQ0oPojaNRYRMrj+MLEax6SdQdjBLiFeXnAbRbex1gFwWIFATTBfhXCS13VlYZP6 uycFqQXkcyYR5+VshLEQUoTUiVeGs3sEKvwt0g6E0pHYFcwaZ9L3hGAcKaZ9hCOfykTG JXZzNxdfWTDfSgOVsi7UGnIpwBeTPPYW80OqT1BKeiTn6jn/1mk22rquUDWfeelNIkxu gCng== X-Gm-Message-State: AOAM530HX5vYlg891skRzy9bBW9jZIkzS5PUsMlJo/jwLVcmALYln8jj 7vOIXbgpRe5ueyyFm9XdTngXmPywTMGbJVdLS4g= X-Google-Smtp-Source: ABdhPJzhnOrH4BaakbFTxy7sB+5+7/TM8ysJoVdnoTCylJqUS/po9fs1HdOO1L65sjGVXlp/+ccz17YiI76kFLOjvqw= X-Received: by 2002:a1f:914c:: with SMTP id t73mr3710704vkd.7.1615816206259; Mon, 15 Mar 2021 06:50:06 -0700 (PDT) MIME-Version: 1.0 References: <205ACFE1-7D4C-4D7C-B394-4AD8A4D4D080@mit.edu> In-Reply-To: From: Adrian Gropper Date: Mon, 15 Mar 2021 09:49:54 -0400 Message-ID: To: Fabien Imbault Cc: Justin Richer , GNAP Mailing List , Alan Karp , Mark Miller Content-Type: multipart/alternative; boundary="000000000000ff179805bd9386f9" Archived-At: Subject: Re: [GNAP] GNAP Architecture and the role of the AS X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2021 13:50:12 -0000 --000000000000ff179805bd9386f9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for asking, Fabien (and Justin). I never had a problem with RQ as the entity that brings claims, scope, and purpose to an AS (that is holding a capability and policies) and gets a token. I understand the attraction of dealing with end-user in cases where the end-user can be the RO but that changes the focus of attention and leads to a problem in the HIPAA use-case and other use-cases that try to priorotize human rights and zero-trust architecture https://docs.google.com/presentation/d/1ksKal62ZiApX09Nejm4RSqHzHJbgwpu_l2H= o64_ePKU/edit#slide=3Did.p . A bit philosophically but helpful as a privacy and community advocate, I have found it useful to analyze protocols in terms of power instead of trust and have learned a lot from that invited expert role in W3C SSI WGs as well as capabilities experts like Alan Karp and Mark Miller. Trust is often forced on the individual by powerful governing interests or just the fact that a sick person is in pain, anxious, overwhelmed, even scared. Presuming trust is not much different from coercion as an exercise of power. SSI data models have leveled the power playing field but GNA protocol is where the rubber meets the road in terms of human rights and security architecture. Adrian On Mon, Mar 15, 2021 at 7:56 AM Fabien Imbault wrote: > Thanks Adrian. > > Useful comments, thanks. > > "The end-user framing we are currently working with has blurred this > distinction between the entity trusted by the RO and the entity that > operates the client at the RS. This, IMHO, needs to be fixed ASAP." What = do > you suggest? > > Thxs > Fabien > > > > > > On Mon, Mar 15, 2021 at 12:43 PM Adrian Gropper > wrote: > >> inline... >> >> On Mon, Mar 15, 2021 at 6:29 AM Fabien Imbault >> wrote: >> >>> Hi Adrian, >>> >>> It's good to check what that means in real use cases indeed. >>> >>> My view: >>> Items 1-2-3-7 : seems quite usual. Only in this example, the patient is >>> the RO and generally delegates its decision to an automated policy engi= ne >>> (equivalent to seq 1.4.4). >>> >> [AG] Yes. This ability to automate under consent is foundational to any >> large-scale information exchange or data brokerage use-case. >> >> I believe item 4 (delegation, beyond the original token issuance) would >>> be hard to do using JWT, at least in a generic way. >>> >> [AG] Whatever GNAP decides for token formats, at least one of them MUST >> support delegation otherwise, the RO is unable to hold a >> requester responsible. Put another way, a zero-trust architecture SHOULD >> hold an individual responsible. In an SSI model, it's the individual tha= t >> controls their credentials and a non-repudiable signature and it's this >> individual that is present at the time the request is issued so that >> individual can use their wallet and be subject to non-repudiation. What >> happens afterward is the responsibility of this requester. >> >> [AG] The end-user framing we are currently working with has blurred this >> distinction between the entity trusted by the RO and the entity that >> operates the client at the RS. This, IMHO, needs to be fixed ASAP. lest = we >> break compatibility with zero-trust architecture for no good reason. >> >> >>> Items 5 is probably beyond our scope, although Denis expressed the same >>> requirement related to "solicits too much info" (based on non opaque >>> tokens, which might not be the general assumption / I personally think >>> token content should remain opaque to the client, but knowing the type = of >>> the token would be useful). >>> >> [AG] I'll take the "probably" for now. It's in everyone's interest for >> GNAP to build on data minimization as a principle. Nobody can keep the R= S >> from asking for too much because, by definition, the RS holds all the >> cards. If an RS asks for too much then the request will pass the AS but >> fail at the RS. In cases where the RO has a choice of RS, the RS will lo= se >> business and that should keep them from asking too much. In cases where = the >> RO is at the mercy of the RS, the only thing GNAP might be able to do is >> provide useful error messages to the various parties. In other words, GN= AP >> needs to consider which errors and warnings are in scope. >> >> >>> Item 6 asks for a relationship between RS and RO, which I'm not sure >>> we'd want to assume for the general case (although it could happen in s= ome >>> scenarii). >>> >> [AG] See my perspective on Item 5 just above. It's up to GNAP to decide >> which errors and warnings need to be handled in scope. Beyond that, RSs = and >> ROs will have a relationship whether GNAP likes it or not. >> >> >>> Item 8 is fine in principle, but would require attention to make sure >>> it's the case in practice. Depending on the sub_ids used (and even if >>> opaque, as soon as dereferencing is allowed), correlation might be poss= ible. >>> >> [AG] In the SSI world we talk in terms of mediators as a separate entity >> that is trusted by the RO to limit correlation. GNAP should be agnostic = to >> whether a mediator is involved. Ideally, GNAP would note that there are = two >> separate correlation threats. Correlation by the requesters and correlat= ion >> by the RSs. Note that I don't worry about correlation by the AS because,= by >> design, I want my agent to know everything it can and to minimize what a= ll >> other participants, except the RO and RO user agent know. >> >> [AG] A mediator allows the RO to use a pseudonym to their AS endpoint as >> long as the RO registers the pseudonym with the mediator first. Keeping = the >> RS (and AS) from correlating separate end-users requires the end-user (a= nd >> maybe the requester) to use a mediator themselves. I don't see any of th= is >> being a problem for GNAP but it might be helpful to have an informative >> mention of mediators in a privacy considerations section. >> >> Adrian >> >>> >>> Does that seem correct? >>> Fabien >>> >>> On Fri, Mar 12, 2021 at 10:34 PM Adrian Gropper >>> wrote: >>> >>>> Let=E2=80=99s try to map a real-world use-case into the names and role= s we are >>>> discussing. The use-case is documented as the API Task Force >>>> Recommendations (2016) >>>> https://www.healthit.gov/sites/default/files/facas/SingleSourceofTruth= -APITFRecommendations.pdf >>>> and I=E2=80=99ve copied below the most relevant section. Bold highligh= t is in >>>> the original. I=E2=80=99ve added bold italic because it may be importa= nt to >>>> our discussion. >>>> >>>> >>>> >>>> >>>> - >>>> >>>> ONC should clarify that while API Providers may impose security >>>> related restrictions on app access (e.g. rate limiting, encryption,= and >>>> expiration of access tokens), it is inappropriate for API providers= to set >>>> limitations on what a patient authorized app can do with data downs= tream. >>>> - >>>> >>>> Given the nature of patient access rights, the provider is not >>>> in a legal position to prevent the registration of apps that wou= ld >>>> aggregate or share data, for example (though the provider might = certainly >>>> decide to warn the patient, or endeavor to educate and explain t= hese issue >>>> to the patient, as part of the provider hosted app approval work= flow). >>>> - >>>> >>>> ONC should clarify that API providers are not obligated to protect >>>> patients by identifying "suspicious" apps. API providers may >>>> suspend API access to an app that has breached the API provider's >>>> terms of service , or appears to have been compromised, or if the a= pp poses >>>> a threat to the provider's own system. However, patients must be >>>> able to override this suspension (except in the case where an app >>>> poses threat to the provider's own system or violates allowable ter= ms of >>>> service). >>>> >>>> >>>> >>>> >>>> >>>> The key requirements from a patient rights and privacy perspective are= : >>>> >>>> >>>> 1. >>>> >>>> To delegate a scope-limited access capability to anyone anywhere >>>> without having to explain or justify that to the API Provider. >>>> 2. >>>> >>>> To allow the patient to automate the issue of a scope-limited >>>> access capability by delegating the authority to process API access >>>> requests to some agent. The API Provider has no say in who or where= this >>>> agent is. >>>> 3. >>>> >>>> The automation of the agent is based on policies provided by the >>>> patient. The agent is able to process access requests from anyone a= nd is >>>> responsible only to the patient. The agent responds to successful r= equests >>>> by issuing a filtered capability to the requesting party. >>>> 4. >>>> >>>> To ensure that the requesting party can delegate the capability >>>> using an institutional workflow system that they trust and the pati= ent >>>> doesn=E2=80=99t know or care about. In many cases, the workflow sys= tem will pass >>>> the capability to some other person, who we might call the end user= . In >>>> other cases, the requesting party may forward the capability direct= ly to >>>> another person using, for example, an email. Either way, the client= app >>>> used by the end-user to access the API is of no concern to the pati= ent or >>>> to the patient=E2=80=99s agent. >>>> 5. >>>> >>>> To ensure that the API Provider does not censor the client app that >>>> presents the capability or solicits too much information about the = client >>>> app or the end-user of the client app. >>>> 6. >>>> >>>> If the API Provider decides, for any reason, to be =E2=80=9Csuspici= ous=E2=80=9D (as >>>> above) of the access transaction based on the information it has, i= t should >>>> be possible for the API Provider to warn the patient and to accept = an >>>> override of the warning by the patient. This effectively means that= the >>>> end-user will provide as much information as they think will be nec= essary >>>> in order to either avoid =E2=80=9Csuspicion=E2=80=9D or risk waitin= g for patient override. >>>> 7. >>>> >>>> The policies by which the patient or the decides to grant a >>>> capability to the requesting party are never shared outside of the >>>> patient-agent trust relationship. In other words, neither the patie= nt nor >>>> the agent is asked to share or explain their reason for an access d= ecision. >>>> 8. >>>> >>>> Access requests to the agent are presumed confidential among the >>>> patient, the agent, and whatever client the requesting party uses t= o >>>> present an access request. The API Provider does not get to see the >>>> requests and no entity in the GNAP authorization process, other tha= n the >>>> patient or the agent, gets to correlate across requests by differen= t >>>> requesting party clients. >>>> >>>> >>>> Note that I am not saying all 8 requirements are in scope for GNAP but >>>> I am asking for GNAP to allow for this level of privacy on the part of >>>> self-sovereign patients using self-sovereign agents and the self-sover= eign >>>> licensed professionals they deal with. >>>> >>>> Adrian >>>> >>>> >>>> On Fri, Mar 12, 2021 at 2:50 PM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Hi Justin, >>>>> >>>>> Just a quick word to say I very much agree with both the observations >>>>> and the framing. >>>>> >>>>> Fabien >>>>> >>>>> On Fri, Mar 12, 2021 at 6:07 PM Justin Richer wrote= : >>>>> >>>>>> As discussed at the IETF meeting, the editors proposed that one of >>>>>> our next big topic areas was going to be the nature of the AS role w= ithin >>>>>> the GNAP protocol, especially how it relates to the device-driven us= e cases >>>>>> that have been brought up. Apologies in advance for the long post, b= ut >>>>>> there are a lot of parts to this discussion that I=E2=80=99m hoping = we can kick off >>>>>> here. >>>>>> >>>>>> My core proposal is that we see the AS as the component that has the >>>>>> following properties: >>>>>> - receives delegation requests from the client instance for access >>>>>> to an RS via access tokens, and for access to subject information re= turned >>>>>> directly to the client instance >>>>>> - collects consent and authorization from the RO for the delegation >>>>>> - issues access tokens that its downstream RS=E2=80=99s can interpr= et (and >>>>>> validate/accept) >>>>>> - issues subject information asserted by the AS >>>>>> >>>>>> This framing of the parties is really important in making a >>>>>> consistent understanding of how the protocol works, and a consistent >>>>>> understanding is vital if we=E2=80=99re going to function as a worki= ng group in >>>>>> both discussing the problem space and executing the solution space. = For a >>>>>> historical example, a naive approach to adding identity on top of a >>>>>> protocol like OAuth 2 (or GNAP) is to declare that the resource serv= er is >>>>>> the thing the user is logging in to. This seems reasonable at first = (and >>>>>> some people tried doing this) but it violates all kinds of trust bou= ndaries >>>>>> and puts new expectations on the different parties that do not make = sense. >>>>>> It stops looking anything like OAuth very quickly and turns into ano= ther >>>>>> protocol. If instead we say the user is logging in to the client, th= ings >>>>>> suddenly make a lot more sense and we can do a lot more with it. (Se= e this >>>>>> blog post from 2013 for one take on that discussion: >>>>>> https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-= 4/ >>>>>> ) >>>>>> >>>>>> I think we=E2=80=99ve got a similar situation here when we start to = talk >>>>>> about the user bringing their own AS with them. I think this is a >>>>>> reasonable-seeming assumption but it=E2=80=99s based on a false prem= ise that the RO >>>>>> has to log into the AS to approve the request, and the AS has full c= ontrol >>>>>> and view over everything in the network. While OAuth doesn=E2=80=99t= require this, >>>>>> it=E2=80=99s largely assumed that=E2=80=99s how it works. After all,= all of the early OAuth >>>>>> deployments worked exactly this way: the user logs in and clicks the= =E2=80=9COK=E2=80=9D >>>>>> button. However, cloud deployments have shown us that it=E2=80=99s p= erfectly >>>>>> reasonable for an OAuth AS to take in its consent and user informati= on from >>>>>> an external trusted source, and so this model is not even accurate i= n OAuth. >>>>>> >>>>>> In short, I think we can do a better job here of defining things in >>>>>> terms that both accept the reality we face and enable new ideas in w= ays >>>>>> that make sense. It=E2=80=99s my stance that the user shouldn=E2=80= =99t need to bring the >>>>>> AS with them in order to have the kind of input and control of the s= ystem >>>>>> that people are asking for. Instead, the AS should be able to take i= nputs >>>>>> from things that the user controls in order for the AS to do its job= . >>>>>> >>>>>> People have discussed privacy concerns with the AS knowing =E2=80=9C= too >>>>>> much=E2=80=9D, but in many of those discussions the knowledge is sim= ply pushed to >>>>>> the RS instead. What I=E2=80=99m observing here is really just pushi= ng portions of >>>>>> the AS role into the =E2=80=9CRS=E2=80=9D deployment. This doesn=E2= =80=99t make it less of an =E2=80=9CAS=E2=80=9D >>>>>> role, it=E2=80=99s just being fulfilled closely to where the RS role= is fulfilled. >>>>>> As such, my proposal is really not that different in practice, but t= he >>>>>> labels are different and better aligned with the capabilities of the >>>>>> protocol. >>>>>> >>>>>> We=E2=80=99ve previously talked about separating the user-facing por= tions of >>>>>> the AS into another component, and I think now might be the time to = do >>>>>> that. This is a very flammable strawman proposal, but what if we had= the AS >>>>>> defined, as above, and the =E2=80=9Cconsent and authorization=E2=80= =9D gathering portion is >>>>>> augmented by another named component. Here let=E2=80=99s call it an = Interaction >>>>>> Component. This can take several forms based on the kind of interact= ion >>>>>> mode in use: >>>>>> >>>>>> - Hosted at a URL the user is redirected to; it can then make the >>>>>> user log in, consent, and whatever else they need to do >>>>>> - Hosted at a URL the user will load separately and enter in an >>>>>> access code >>>>>> - An app on the user=E2=80=99s device that the user interacts with = directly >>>>>> and which sends information back to the AS >>>>>> - An app reachable by a messaging endpoint that the AS sends and >>>>>> receives structured information from >>>>>> - The client itself that is given an indication as to what >>>>>> information the AS needs in order to fulfill the request; this could= be MFA >>>>>> challenge/response, user credentials, signed claims, etc. >>>>>> >>>>>> It=E2=80=99s the AS=E2=80=99s job to accept any and all of these tha= t it supports and >>>>>> churn those into an access token. >>>>>> >>>>>> The AS itself doesn=E2=80=99t ever need to have the user log in. The= AS >>>>>> doesn=E2=80=99t necessarily need to even know who the user is in any= way. The AS >>>>>> just needs to know from a trusted source that the request is approve= d. >>>>>> >>>>>> From a practical standpoint, I think this will have some small >>>>>> changes in how we talk about the components and how we talk about th= e >>>>>> interaction phase of the grant negotiation process. Everything I=E2= =80=99m laying >>>>>> out here is currently allowed by the spec, but I think we=E2=80=99ve= carried >>>>>> through the same assumptions from OAuth 2 about deployment that are = both >>>>>> inaccurate and confusing. >>>>>> >>>>>> =E2=80=94 Justin >>>>>> -- >>>>>> 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 >>>>> >>>> --000000000000ff179805bd9386f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Thanks for asking, Fabien (and Justin).= =C2=A0

    I never had a probl= em with RQ as the entity that brings claims, scope, and purpose to an AS (t= hat is holding a capability and policies) and gets a token.=C2=A0

    <= /div>
    I understand=C2=A0the attraction of dealing with end-user in case= s where the end-user can be the RO but that changes the focus of attention = and leads to a problem in the HIPAA use-case and other use-cases that try t= o priorotize human rights and zero-trust architecture https://docs.google.com/presentation/d/1ksKal62ZiApX09Nej= m4RSqHzHJbgwpu_l2Ho64_ePKU/edit#slide=3Did.p .

    A bit philosophically but helpful=C2=A0as a privacy and community advocate= , I have found it useful to analyze protocols in terms of power instead of = trust and have learned a lot from that invited expert role in W3C SSI WGs a= s well as capabilities=C2=A0experts like Alan Karp and Mark Miller. Trust i= s often forced on the individual by powerful governing interests or just th= e fact that a sick person is in pain, anxious, overwhelmed, even scared. Pr= esuming trust is not much different from coercion as an exercise of power.= =C2=A0

    SSI data models have leveled the power play= ing field but GNA protocol is where the rubber meets the road in terms of h= uman rights and security architecture.

    Adrian



    <= div dir=3D"ltr" class=3D"gmail_attr">On Mon, Mar 15, 2021 at 7:56 AM Fabien= Imbault <fabien.imbault@gma= il.com> wrote:
    Thanks Adr= ian.=C2=A0

    Useful comments, thanks.=C2=A0

    =
    "The end-user framing we are currently working with has blu= rred this distinction between the entity trusted by the RO and the entity t= hat operates the client at the RS. This, IMHO, needs to be fixed ASAP."= ; What do you suggest?

    Thxs
    Fabien
    =





    On Mon, Mar 15,= 2021 at 12:43 PM Adrian Gropper <agropper@healthurl.com> wrote:
    inline...

    On Mon, Mar 15, 2021= at 6:29 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Adrian,=C2=A0

    It's good= to check what that means in real use cases indeed.

    = My view:
    Items 1-2-3-7 : seems quite usual. Only in this example,= the patient is the RO and generally delegates its decision to an automated= policy engine (equivalent to seq 1.4.4).=C2=A0
    [AG] Yes.=C2=A0 This ability to automate under consent=C2=A0is foun= dational to any large-scale information exchange=C2=A0or data brokerage use= -case.

    I be= lieve item 4 (delegation, beyond the original token issuance) would be hard= to do using JWT, at least in a generic way.=C2=A0
    [AG] Whatever GNAP decides for token formats, at least one of th= em MUST support delegation otherwise, the RO is unable to hold a requester= =C2=A0responsible. Put another way, a zero-trust architecture SHOULD hold a= n individual responsible. In an SSI model, it's the individual that con= trols their credentials and a non-repudiable signature and it's this in= dividual that is present at the time the request is issued so that individu= al can use their wallet and be subject to non-repudiation. What happens aft= erward is the responsibility of this requester.=C2=A0

    <= div>[AG] The end-user framing we are currently working with has blurred thi= s distinction between the entity trusted by the RO and the entity that oper= ates the client at the RS. This, IMHO, needs to be fixed ASAP. lest we brea= k compatibility with zero-trust architecture for no good reason.
    = =C2=A0
    Items 5 is probably= beyond our scope, although Denis expressed the same requirement related to= "solicits too much info" (based on non opaque tokens, which migh= t not be the general assumption / I personally think token content should r= emain opaque to the client, but knowing the type of the token would be usef= ul).=C2=A0
    [AG] I'll take the "= probably" for now. It's in everyone's interest for GNAP to bui= ld on data minimization=C2=A0as a principle. Nobody can keep the RS from as= king for too much because, by definition, the RS holds all the cards. If an= RS asks for too much then the request will pass the AS but fail at the RS.= In cases where the RO has a choice of RS, the RS will lose business and th= at should keep them from asking too much. In cases where the RO is at the m= ercy of the RS, the only thing GNAP might be able to do is provide useful e= rror messages to the various parties. In other words, GNAP needs to conside= r which errors and warnings are in scope.
    =C2=A0
    Item 6 asks for a relationship between RS and R= O, which I'm not sure we'd want to assume for the general case (alt= hough it could happen in some scenarii).
    [AG] = See my perspective on Item 5 just above. It's up to GNAP to decide whic= h errors and warnings need to be handled in scope. Beyond that, RSs and ROs= will have a relationship whether GNAP likes it or not.
    =C2=A0
    Item 8 is fine in principle, but = would require attention to make sure it's the case in practice. Dependi= ng on the sub_ids used (and even if opaque, as soon as dereferencing is all= owed), correlation might be possible.
    [AG] In = the SSI world we talk in terms of mediators as a separate entity that is tr= usted by the RO to limit correlation. GNAP should be agnostic to whether a = mediator is involved. Ideally, GNAP would note that there are two separate = correlation threats. Correlation by the requesters and correlation by the R= Ss. Note that I don't worry about correlation by the AS because, by des= ign, I want my agent to know everything it can and to minimize what all oth= er participants, except the RO and RO user agent know.

    =
    [AG] A mediator allows the RO to use a pseudonym to their AS endpoint = as long as the RO registers the pseudonym with the mediator first. Keeping = the RS (and AS) from correlating separate end-users requires the end-user (= and maybe the requester) to use a mediator themselves. I don't see any = of this being a problem for GNAP but it might be helpful to have an informa= tive mention of mediators in a privacy considerations section.
    Adrian

    <= div>Does that seem correct?
    Fabien

    On Fri, Mar 12, 2021 at 1= 0:34 PM Adrian Gropper <agropper@healthurl.com> wrote:

    = Let=E2=80=99s try to map a real-world use-case into the names and roles we = are discussing. The use-case is documented as the API Task Force Recommenda= tions (2016) https://www.healthit.gov/sites/d= efault/files/facas/SingleSourceofTruth-APITFRecommendations.pdf<= span style=3D"font-family:Arial;font-variant-ligatures:normal;font-variant-= east-asian:normal;vertical-align:baseline;white-space:pre-wrap"> and I=E2= =80=99ve copied below the most relevant section. Bold highlight i= s in the original. I=E2=80=99ve added bold i= talic

    <quote>

  • ONC should clarify that while API Pr= oviders may impose security related restrictions on app access (e.g. rate l= imiting, encryption, and expiration of access tokens), it is inappropriate = for API providers to set limitations on what a patient authorized app can d= o with data downstream.

    • Given the nature of patient access rights, the provider is not in a l= egal position to prevent the registration of apps that would aggregate or s= hare data, for example (though the provider might certainly decide to warn = the patient, or endeavor to educate and explain these issue to the patient,= as part of the provider hosted app approval workflow).

    • ONC sh= ould clarify that API providers are not obligated to protect patients by identifying "suspicious= " apps. API providers may suspend API access to an app that has breached the API provider's = terms of service , or appears to have been compromised, or if the app poses= a threat to the provider's own system. However, patients = must be able to override this suspension (except in the case where an app poses threat to the pr= ovider's own system or violates allowable terms of service).

      =

      =

    <= ;/quote>

    The key requirement= s from a patient rights and privacy perspective are:


    1. To delegate a scope-limited access capa= bility to anyone anywhere without having to explain or justify that to the = API Provider.

    2. To allow the patient to automate the issue of a = scope-limited access capability by delegating the authority to process API = access requests to some agent. The API Provider has no say in who or where = this agent is.

    3. The automation of the agent is based on policies= provided by the patient. The agent is able to process access requests from= anyone and is responsible only to the patient. The agent responds to succe= ssful requests by issuing a filtered capability to the requesting party.

    4. To ensure that the requesting party can delegate the capability us= ing an institutional workflow system that they trust and the patient doesn= =E2=80=99t know or care about. In many cases, the workflow system will pass= the capability to some other person, who we might call the end user. In ot= her cases, the requesting party may forward the capability directly to anot= her person using, for example, an email. Either way, the client app used by= the end-user to access the API is of no concern to the patient or to the p= atient=E2=80=99s agent.=C2=A0

    5. To ensure that the API Provider do= es not censor the client app that presents the capability or solicits too m= uch information about the client app or the end-user of the client app.=C2= =A0

    6. If the API Provider decides, for any reason, to be =E2=80=9C= suspicious=E2=80=9D (as above) of the access transaction based on the infor= mation it has, it should be possible for the API Provider to warn the patie= nt and to accept an override of the warning by the patient. This effectivel= y means that the end-user will provide as much information as they think wi= ll be necessary in order to either avoid =E2=80=9Csuspicion=E2=80=9D or ris= k waiting for patient override.

    7. The policies by which the patien= t or the decides to grant a capability to the requesting party are never sh= ared outside of the patient-agent trust relationship. In other words, neith= er the patient nor the agent is asked to share or explain their reason for = an access decision.=C2=A0

    8. Access requests to the agent are presu= med confidential among the patient, the agent, and whatever client the requ= esting party uses to present an access request. The API Provider does not g= et to see the requests and no entity in the GNAP authorization process, oth= er than the patient or the agent, gets to correlate across requests by diff= erent requesting party clients.


    Note that I am not saying all= 8 requirements are in scope for GNAP but I am asking for GNAP to allow for= this level of privacy on the part of self-sovereign patients using self-so= vereign agents and the self-sovereign licensed professionals they deal with= .


    Adrian


    On Fri, = Mar 12, 2021 at 2:50 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Justin,=C2=A0

    J= ust a quick word to say I very much agree with both the observations and th= e framing.

    Fabien

    On Fri, Mar 12, 2021 at 6:0= 7 PM Justin Richer <jricher@mit.edu> wrote:
    As discussed= at the IETF meeting, the editors proposed that one of our next big topic a= reas was going to be the nature of the AS role within the GNAP protocol, es= pecially how it relates to the device-driven use cases that have been broug= ht up. Apologies in advance for the long post, but there are a lot of parts= to this discussion that I=E2=80=99m hoping we can kick off here.

    <= /div>
    My core proposal is that we see the AS as the component that has = the following properties:
    =C2=A0- receives delegation requests fr= om the client instance for access to an RS via access tokens, and for acces= s to subject information returned directly to the client instance
    =C2=A0- collects consent and authorization from the RO for the delegation<= /div>
    =C2=A0- issues access tokens that its downstream RS=E2=80=99s can= interpret (and validate/accept)
    =C2=A0- issues subject informati= on asserted by the AS=C2=A0

    This framing of the part= ies is really important in making a consistent understanding of how the pro= tocol works, and a consistent understanding is vital if we=E2=80=99re going= to function as a working group in both discussing the problem space and ex= ecuting the solution space. For a historical example, a naive approach to a= dding identity on top of a protocol like OAuth 2 (or GNAP) is to declare th= at the resource server is the thing the user is logging in to. This seems r= easonable at first (and some people tried doing this) but it violates all k= inds of trust boundaries and puts new expectations on the different parties= that do not make sense. It stops looking anything like OAuth very quickly = and turns into another protocol. If instead we say the user is logging in t= o the client, things suddenly make a lot more sense and we can do a lot mor= e with it. (See this blog post from 2013 for one take on that discussion:= =C2=A0https://www.cloudidentity.com/blog/2013/01/= 02/oauth-2-0-and-sign-in-4/)

    I think we=E2=80= =99ve got a similar situation here when we start to talk about the user bri= nging their own AS with them. I think this is a reasonable-seeming assumpti= on but it=E2=80=99s based on a false premise that the RO has to log into th= e AS to approve the request, and the AS has full control and view over ever= ything in the network. While OAuth doesn=E2=80=99t require this, it=E2=80= =99s largely assumed that=E2=80=99s how it works. After all, all of the ear= ly OAuth deployments worked exactly this way: the user logs in and clicks t= he =E2=80=9COK=E2=80=9D button. However, cloud deployments have shown us th= at it=E2=80=99s perfectly reasonable for an OAuth AS to take in its consent= and user information from an external trusted source, and so this model is= not even accurate in OAuth.

    In short, I think we = can do a better job here of defining things in terms that both accept the r= eality we face and enable new ideas in ways that make sense. It=E2=80=99s m= y stance that the user shouldn=E2=80=99t need to bring the AS with them in = order to have the kind of input and control of the system that people are a= sking for. Instead, the AS should be able to take inputs from things that t= he user controls in order for the AS to do its job.

    People have discussed privacy concerns with the AS knowing =E2=80=9Ctoo m= uch=E2=80=9D, but in many of those discussions the knowledge is simply push= ed to the RS instead. What I=E2=80=99m observing here is really just pushin= g portions of the AS role into the =E2=80=9CRS=E2=80=9D deployment. This do= esn=E2=80=99t make it less of an =E2=80=9CAS=E2=80=9D role, it=E2=80=99s ju= st being fulfilled closely to where the RS role is fulfilled. As such, my p= roposal is really not that different in practice, but the labels are differ= ent and better aligned with the capabilities of the protocol.=C2=A0

    We=E2=80=99ve previously talked about separating th= e user-facing portions of the AS into another component, and I think now mi= ght be the time to do that. This is a very flammable strawman proposal, but= what if we had the AS defined, as above, and the =E2=80=9Cconsent and auth= orization=E2=80=9D gathering portion is augmented by another named componen= t. Here let=E2=80=99s call it an Interaction Component. This can take sever= al forms based on the kind of interaction mode in use:

    =
    =C2=A0- Hosted at a URL the user is redirected to; it can then make th= e user log in, consent, and whatever else they need to do
    =C2=A0-= Hosted at a URL the user will load separately and enter in an access code<= /div>
    =C2=A0- An app on the user=E2=80=99s device that the user interac= ts with directly and which sends information back to the AS
    =C2= =A0- An app reachable by a messaging endpoint that the AS sends and receive= s structured information from
    =C2=A0- The client itself that is g= iven an indication as to what information the AS needs in order to fulfill = the request; this could be MFA challenge/response, user credentials, signed= claims, etc.

    It=E2=80=99s the AS=E2=80=99s job to= accept any and all of these that it supports and churn those into an acces= s token.=C2=A0

    The AS itself doesn=E2=80=99t ever = need to have the user log in. The AS doesn=E2=80=99t necessarily need to ev= en know who the user is in any way. The AS just needs to know from a truste= d source that the request is approved.

    From a prac= tical standpoint, I think this will have some small changes in how we talk = about the components and how we talk about the interaction phase of the gra= nt negotiation process. Everything I=E2=80=99m laying out here is currently= allowed by the spec, but I think we=E2=80=99ve carried through the same as= sumptions from OAuth 2 about deployment that are both inaccurate and confus= ing.=C2=A0

    =C2=A0=E2=80=94 Justin
    -- 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
    --000000000000ff179805bd9386f9-- From nobody Mon Mar 15 07:13:14 2021 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 C49D13A1281 for ; Mon, 15 Mar 2021 07:13:12 -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 57iX-trZGaf7 for ; Mon, 15 Mar 2021 07:13:08 -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 AB41A3A127F for ; Mon, 15 Mar 2021 07:13:07 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id z13so33484329iox.8 for ; Mon, 15 Mar 2021 07:13: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=jYLyRUiDLGDL212hm5O57Jk83DBuRQEmoxx5Nxkdb00=; b=OtnpmqSj/uw0dEbX9/839ps/hXfkWfEHU1/uwepiCILdMsoKNjYjbzI08Ixc99QkPS GhtzCDSZcajOZYBvtLmiw3sbGP/MtYycdiZOXBzoIFcAEMIpMEU5oYDI3x2fxYYBhpHD Vq3pp2BRs8aAskJVJ/1R/IWMpojuMYi0AtiG0OO58hJ0bNMu9a3geO+RO92N84sJ//th 0Mm7STDoazqv0au6cII++FyXUZhLrtYaTxacyn/cGsRB64thrb4mqxXOrCPIQywj7IJy 7MVYzoNs2TCIYGW+oOXvuhGs4IvUwOhr2/odoD8HLGiHGvXfrBZPUbmteyi5syCC3zjI RBCA== 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=jYLyRUiDLGDL212hm5O57Jk83DBuRQEmoxx5Nxkdb00=; b=MKZj+gj2zdXDThIwPuFj0GqzakgwEWvuThu0Cu+RMyUYFqnD9QiPlnura0IlO4Gazq pz9fhAapr1Rp69RuV5xR0eESxPL46uPJt7HOg0Ww1edTbIbv+YVUnYtC+xzOW2lZJ7PY 5NvvsorOCm/3claMmrif7M5TFYSDIGKF+VwOu2g6LN7JbbTDIgUc/q/ykj1E+Hd+7zHo EfmoUdhJ3Cy0yUP0p8FQ42NrwHrk8yybwnS5G0130EgSyDrfwc5w2qp31Sz4neN9KnpU NJaKb6t0r0HEgb7PpuoU+V2busg1lOCW7cEQvTc9yHw6okzHt5rahACFUwOniihk/xdH 1o8Q== X-Gm-Message-State: AOAM5328j4Ir3b5vyGkJj6HCf8o6SLrQxo2y0cwtJaSGpUTPfxjmk51i W51X7wJwVoq/rp88wTCxW0nC1dWPc+S6+mz1dd4= X-Google-Smtp-Source: ABdhPJz0ruZ/ORXuxxoTktIgZd2cPgvakaSSfWLbhKqkkZOxU3JyNIqZOiWY0Tu8W4V1mZilFSBdsIBpvMesdOex2GM= X-Received: by 2002:a02:c6b4:: with SMTP id o20mr9698630jan.124.1615817586291; Mon, 15 Mar 2021 07:13:06 -0700 (PDT) MIME-Version: 1.0 References: <205ACFE1-7D4C-4D7C-B394-4AD8A4D4D080@mit.edu> In-Reply-To: From: Fabien Imbault Date: Mon, 15 Mar 2021 15:12:55 +0100 Message-ID: To: Adrian Gropper Cc: Justin Richer , GNAP Mailing List , Alan Karp , Mark Miller Content-Type: multipart/alternative; boundary="00000000000040b83805bd93d9f0" Archived-At: Subject: Re: [GNAP] GNAP Architecture and the role of the AS X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2021 14:13:13 -0000 --00000000000040b83805bd93d9f0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Adrian. I'm not very familiar with HIPAA (being based in Europe) but I don't see "end-user" as being in opposition with ZTA. To me (s)he's just the one using the client software, in such a way that the AS indeed needs to establish sufficient confidence in who that is to make him/her get access. (S)he could either be the RO or not. But it's true we never define its position of power to the RO. Not sure how we could include it. Fabien On Mon, Mar 15, 2021 at 2:50 PM Adrian Gropper wrote: > Thanks for asking, Fabien (and Justin). > > I never had a problem with RQ as the entity that brings claims, scope, an= d > purpose to an AS (that is holding a capability and policies) and gets a > token. > > I understand the attraction of dealing with end-user in cases where the > end-user can be the RO but that changes the focus of attention and leads = to > a problem in the HIPAA use-case and other use-cases that try to priorotiz= e > human rights and zero-trust architecture > https://docs.google.com/presentation/d/1ksKal62ZiApX09Nejm4RSqHzHJbgwpu_l= 2Ho64_ePKU/edit#slide=3Did.p > . > > A bit philosophically but helpful as a privacy and community advocate, I > have found it useful to analyze protocols in terms of power instead of > trust and have learned a lot from that invited expert role in W3C SSI WGs > as well as capabilities experts like Alan Karp and Mark Miller. Trust is > often forced on the individual by powerful governing interests or just th= e > fact that a sick person is in pain, anxious, overwhelmed, even scared. > Presuming trust is not much different from coercion as an exercise of > power. > > SSI data models have leveled the power playing field but GNA protocol is > where the rubber meets the road in terms of human rights and security > architecture. > > Adrian > > > > On Mon, Mar 15, 2021 at 7:56 AM Fabien Imbault > wrote: > >> Thanks Adrian. >> >> Useful comments, thanks. >> >> "The end-user framing we are currently working with has blurred this >> distinction between the entity trusted by the RO and the entity that >> operates the client at the RS. This, IMHO, needs to be fixed ASAP." What= do >> you suggest? >> >> Thxs >> Fabien >> >> >> >> >> >> On Mon, Mar 15, 2021 at 12:43 PM Adrian Gropper >> wrote: >> >>> inline... >>> >>> On Mon, Mar 15, 2021 at 6:29 AM Fabien Imbault >>> wrote: >>> >>>> Hi Adrian, >>>> >>>> It's good to check what that means in real use cases indeed. >>>> >>>> My view: >>>> Items 1-2-3-7 : seems quite usual. Only in this example, the patient i= s >>>> the RO and generally delegates its decision to an automated policy eng= ine >>>> (equivalent to seq 1.4.4). >>>> >>> [AG] Yes. This ability to automate under consent is foundational to an= y >>> large-scale information exchange or data brokerage use-case. >>> >>> I believe item 4 (delegation, beyond the original token issuance) would >>>> be hard to do using JWT, at least in a generic way. >>>> >>> [AG] Whatever GNAP decides for token formats, at least one of them MUST >>> support delegation otherwise, the RO is unable to hold a >>> requester responsible. Put another way, a zero-trust architecture SHOUL= D >>> hold an individual responsible. In an SSI model, it's the individual th= at >>> controls their credentials and a non-repudiable signature and it's this >>> individual that is present at the time the request is issued so that >>> individual can use their wallet and be subject to non-repudiation. What >>> happens afterward is the responsibility of this requester. >>> >>> [AG] The end-user framing we are currently working with has blurred thi= s >>> distinction between the entity trusted by the RO and the entity that >>> operates the client at the RS. This, IMHO, needs to be fixed ASAP. lest= we >>> break compatibility with zero-trust architecture for no good reason. >>> >>> >>>> Items 5 is probably beyond our scope, although Denis expressed the sam= e >>>> requirement related to "solicits too much info" (based on non opaque >>>> tokens, which might not be the general assumption / I personally think >>>> token content should remain opaque to the client, but knowing the type= of >>>> the token would be useful). >>>> >>> [AG] I'll take the "probably" for now. It's in everyone's interest for >>> GNAP to build on data minimization as a principle. Nobody can keep the = RS >>> from asking for too much because, by definition, the RS holds all the >>> cards. If an RS asks for too much then the request will pass the AS but >>> fail at the RS. In cases where the RO has a choice of RS, the RS will l= ose >>> business and that should keep them from asking too much. In cases where= the >>> RO is at the mercy of the RS, the only thing GNAP might be able to do i= s >>> provide useful error messages to the various parties. In other words, G= NAP >>> needs to consider which errors and warnings are in scope. >>> >>> >>>> Item 6 asks for a relationship between RS and RO, which I'm not sure >>>> we'd want to assume for the general case (although it could happen in = some >>>> scenarii). >>>> >>> [AG] See my perspective on Item 5 just above. It's up to GNAP to decide >>> which errors and warnings need to be handled in scope. Beyond that, RSs= and >>> ROs will have a relationship whether GNAP likes it or not. >>> >>> >>>> Item 8 is fine in principle, but would require attention to make sure >>>> it's the case in practice. Depending on the sub_ids used (and even if >>>> opaque, as soon as dereferencing is allowed), correlation might be pos= sible. >>>> >>> [AG] In the SSI world we talk in terms of mediators as a separate entit= y >>> that is trusted by the RO to limit correlation. GNAP should be agnostic= to >>> whether a mediator is involved. Ideally, GNAP would note that there are= two >>> separate correlation threats. Correlation by the requesters and correla= tion >>> by the RSs. Note that I don't worry about correlation by the AS because= , by >>> design, I want my agent to know everything it can and to minimize what = all >>> other participants, except the RO and RO user agent know. >>> >>> [AG] A mediator allows the RO to use a pseudonym to their AS endpoint a= s >>> long as the RO registers the pseudonym with the mediator first. Keeping= the >>> RS (and AS) from correlating separate end-users requires the end-user (= and >>> maybe the requester) to use a mediator themselves. I don't see any of t= his >>> being a problem for GNAP but it might be helpful to have an informative >>> mention of mediators in a privacy considerations section. >>> >>> Adrian >>> >>>> >>>> Does that seem correct? >>>> Fabien >>>> >>>> On Fri, Mar 12, 2021 at 10:34 PM Adrian Gropper >>>> wrote: >>>> >>>>> Let=E2=80=99s try to map a real-world use-case into the names and rol= es we are >>>>> discussing. The use-case is documented as the API Task Force >>>>> Recommendations (2016) >>>>> https://www.healthit.gov/sites/default/files/facas/SingleSourceofTrut= h-APITFRecommendations.pdf >>>>> and I=E2=80=99ve copied below the most relevant section. Bold highlig= ht is in >>>>> the original. I=E2=80=99ve added bold italic because it may be import= ant to >>>>> our discussion. >>>>> >>>>> >>>>> >>>>> >>>>> - >>>>> >>>>> ONC should clarify that while API Providers may impose security >>>>> related restrictions on app access (e.g. rate limiting, encryption= , and >>>>> expiration of access tokens), it is inappropriate for API provider= s to set >>>>> limitations on what a patient authorized app can do with data down= stream. >>>>> - >>>>> >>>>> Given the nature of patient access rights, the provider is not >>>>> in a legal position to prevent the registration of apps that wo= uld >>>>> aggregate or share data, for example (though the provider might= certainly >>>>> decide to warn the patient, or endeavor to educate and explain = these issue >>>>> to the patient, as part of the provider hosted app approval wor= kflow). >>>>> - >>>>> >>>>> ONC should clarify that API providers are not obligated to protect >>>>> patients by identifying "suspicious" apps. API providers may >>>>> suspend API access to an app that has breached the API provider's >>>>> terms of service , or appears to have been compromised, or if the = app poses >>>>> a threat to the provider's own system. However, patients must be >>>>> able to override this suspension (except in the case where an app >>>>> poses threat to the provider's own system or violates allowable te= rms of >>>>> service). >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The key requirements from a patient rights and privacy perspective ar= e: >>>>> >>>>> >>>>> 1. >>>>> >>>>> To delegate a scope-limited access capability to anyone anywhere >>>>> without having to explain or justify that to the API Provider. >>>>> 2. >>>>> >>>>> To allow the patient to automate the issue of a scope-limited >>>>> access capability by delegating the authority to process API acces= s >>>>> requests to some agent. The API Provider has no say in who or wher= e this >>>>> agent is. >>>>> 3. >>>>> >>>>> The automation of the agent is based on policies provided by the >>>>> patient. The agent is able to process access requests from anyone = and is >>>>> responsible only to the patient. The agent responds to successful = requests >>>>> by issuing a filtered capability to the requesting party. >>>>> 4. >>>>> >>>>> To ensure that the requesting party can delegate the capability >>>>> using an institutional workflow system that they trust and the pat= ient >>>>> doesn=E2=80=99t know or care about. In many cases, the workflow sy= stem will pass >>>>> the capability to some other person, who we might call the end use= r. In >>>>> other cases, the requesting party may forward the capability direc= tly to >>>>> another person using, for example, an email. Either way, the clien= t app >>>>> used by the end-user to access the API is of no concern to the pat= ient or >>>>> to the patient=E2=80=99s agent. >>>>> 5. >>>>> >>>>> To ensure that the API Provider does not censor the client app >>>>> that presents the capability or solicits too much information abou= t the >>>>> client app or the end-user of the client app. >>>>> 6. >>>>> >>>>> If the API Provider decides, for any reason, to be =E2=80=9Csuspic= ious=E2=80=9D >>>>> (as above) of the access transaction based on the information it h= as, it >>>>> should be possible for the API Provider to warn the patient and to= accept >>>>> an override of the warning by the patient. This effectively means = that the >>>>> end-user will provide as much information as they think will be ne= cessary >>>>> in order to either avoid =E2=80=9Csuspicion=E2=80=9D or risk waiti= ng for patient override. >>>>> 7. >>>>> >>>>> The policies by which the patient or the decides to grant a >>>>> capability to the requesting party are never shared outside of the >>>>> patient-agent trust relationship. In other words, neither the pati= ent nor >>>>> the agent is asked to share or explain their reason for an access = decision. >>>>> 8. >>>>> >>>>> Access requests to the agent are presumed confidential among the >>>>> patient, the agent, and whatever client the requesting party uses = to >>>>> present an access request. The API Provider does not get to see th= e >>>>> requests and no entity in the GNAP authorization process, other th= an the >>>>> patient or the agent, gets to correlate across requests by differe= nt >>>>> requesting party clients. >>>>> >>>>> >>>>> Note that I am not saying all 8 requirements are in scope for GNAP bu= t >>>>> I am asking for GNAP to allow for this level of privacy on the part o= f >>>>> self-sovereign patients using self-sovereign agents and the self-sove= reign >>>>> licensed professionals they deal with. >>>>> >>>>> Adrian >>>>> >>>>> >>>>> On Fri, Mar 12, 2021 at 2:50 PM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Hi Justin, >>>>>> >>>>>> Just a quick word to say I very much agree with both the observation= s >>>>>> and the framing. >>>>>> >>>>>> Fabien >>>>>> >>>>>> On Fri, Mar 12, 2021 at 6:07 PM Justin Richer >>>>>> wrote: >>>>>> >>>>>>> As discussed at the IETF meeting, the editors proposed that one of >>>>>>> our next big topic areas was going to be the nature of the AS role = within >>>>>>> the GNAP protocol, especially how it relates to the device-driven u= se cases >>>>>>> that have been brought up. Apologies in advance for the long post, = but >>>>>>> there are a lot of parts to this discussion that I=E2=80=99m hoping= we can kick off >>>>>>> here. >>>>>>> >>>>>>> My core proposal is that we see the AS as the component that has th= e >>>>>>> following properties: >>>>>>> - receives delegation requests from the client instance for access >>>>>>> to an RS via access tokens, and for access to subject information r= eturned >>>>>>> directly to the client instance >>>>>>> - collects consent and authorization from the RO for the delegatio= n >>>>>>> - issues access tokens that its downstream RS=E2=80=99s can interp= ret (and >>>>>>> validate/accept) >>>>>>> - issues subject information asserted by the AS >>>>>>> >>>>>>> This framing of the parties is really important in making a >>>>>>> consistent understanding of how the protocol works, and a consisten= t >>>>>>> understanding is vital if we=E2=80=99re going to function as a work= ing group in >>>>>>> both discussing the problem space and executing the solution space.= For a >>>>>>> historical example, a naive approach to adding identity on top of a >>>>>>> protocol like OAuth 2 (or GNAP) is to declare that the resource ser= ver is >>>>>>> the thing the user is logging in to. This seems reasonable at first= (and >>>>>>> some people tried doing this) but it violates all kinds of trust bo= undaries >>>>>>> and puts new expectations on the different parties that do not make= sense. >>>>>>> It stops looking anything like OAuth very quickly and turns into an= other >>>>>>> protocol. If instead we say the user is logging in to the client, t= hings >>>>>>> suddenly make a lot more sense and we can do a lot more with it. (S= ee this >>>>>>> blog post from 2013 for one take on that discussion: >>>>>>> https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in= -4/ >>>>>>> ) >>>>>>> >>>>>>> I think we=E2=80=99ve got a similar situation here when we start to= talk >>>>>>> about the user bringing their own AS with them. I think this is a >>>>>>> reasonable-seeming assumption but it=E2=80=99s based on a false pre= mise that the RO >>>>>>> has to log into the AS to approve the request, and the AS has full = control >>>>>>> and view over everything in the network. While OAuth doesn=E2=80=99= t require this, >>>>>>> it=E2=80=99s largely assumed that=E2=80=99s how it works. After all= , all of the early OAuth >>>>>>> deployments worked exactly this way: the user logs in and clicks th= e =E2=80=9COK=E2=80=9D >>>>>>> button. However, cloud deployments have shown us that it=E2=80=99s = perfectly >>>>>>> reasonable for an OAuth AS to take in its consent and user informat= ion from >>>>>>> an external trusted source, and so this model is not even accurate = in OAuth. >>>>>>> >>>>>>> In short, I think we can do a better job here of defining things in >>>>>>> terms that both accept the reality we face and enable new ideas in = ways >>>>>>> that make sense. It=E2=80=99s my stance that the user shouldn=E2=80= =99t need to bring the >>>>>>> AS with them in order to have the kind of input and control of the = system >>>>>>> that people are asking for. Instead, the AS should be able to take = inputs >>>>>>> from things that the user controls in order for the AS to do its jo= b. >>>>>>> >>>>>>> People have discussed privacy concerns with the AS knowing =E2=80= =9Ctoo >>>>>>> much=E2=80=9D, but in many of those discussions the knowledge is si= mply pushed to >>>>>>> the RS instead. What I=E2=80=99m observing here is really just push= ing portions of >>>>>>> the AS role into the =E2=80=9CRS=E2=80=9D deployment. This doesn=E2= =80=99t make it less of an =E2=80=9CAS=E2=80=9D >>>>>>> role, it=E2=80=99s just being fulfilled closely to where the RS rol= e is fulfilled. >>>>>>> As such, my proposal is really not that different in practice, but = the >>>>>>> labels are different and better aligned with the capabilities of th= e >>>>>>> protocol. >>>>>>> >>>>>>> We=E2=80=99ve previously talked about separating the user-facing po= rtions of >>>>>>> the AS into another component, and I think now might be the time to= do >>>>>>> that. This is a very flammable strawman proposal, but what if we ha= d the AS >>>>>>> defined, as above, and the =E2=80=9Cconsent and authorization=E2=80= =9D gathering portion is >>>>>>> augmented by another named component. Here let=E2=80=99s call it an= Interaction >>>>>>> Component. This can take several forms based on the kind of interac= tion >>>>>>> mode in use: >>>>>>> >>>>>>> - Hosted at a URL the user is redirected to; it can then make the >>>>>>> user log in, consent, and whatever else they need to do >>>>>>> - Hosted at a URL the user will load separately and enter in an >>>>>>> access code >>>>>>> - An app on the user=E2=80=99s device that the user interacts with= directly >>>>>>> and which sends information back to the AS >>>>>>> - An app reachable by a messaging endpoint that the AS sends and >>>>>>> receives structured information from >>>>>>> - The client itself that is given an indication as to what >>>>>>> information the AS needs in order to fulfill the request; this coul= d be MFA >>>>>>> challenge/response, user credentials, signed claims, etc. >>>>>>> >>>>>>> It=E2=80=99s the AS=E2=80=99s job to accept any and all of these th= at it supports >>>>>>> and churn those into an access token. >>>>>>> >>>>>>> The AS itself doesn=E2=80=99t ever need to have the user log in. Th= e AS >>>>>>> doesn=E2=80=99t necessarily need to even know who the user is in an= y way. The AS >>>>>>> just needs to know from a trusted source that the request is approv= ed. >>>>>>> >>>>>>> From a practical standpoint, I think this will have some small >>>>>>> changes in how we talk about the components and how we talk about t= he >>>>>>> interaction phase of the grant negotiation process. Everything I=E2= =80=99m laying >>>>>>> out here is currently allowed by the spec, but I think we=E2=80=99v= e carried >>>>>>> through the same assumptions from OAuth 2 about deployment that are= both >>>>>>> inaccurate and confusing. >>>>>>> >>>>>>> =E2=80=94 Justin >>>>>>> -- >>>>>>> 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 >>>>>> >>>>> --00000000000040b83805bd93d9f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Thanks Adrian.=C2=A0

    I= 'm not very familiar with HIPAA (being based in Europe) but I don't= see "end-user" as being in opposition with ZTA. To me (s)he'= s=C2=A0just the one using the client software, in such a way that the=C2=A0= AS indeed needs to establish sufficient confidence in who that is to make h= im/her get access. (S)he could either be the RO or not.=C2=A0
    But it's true we never define its position of power to the = RO. Not sure how we could include it.

    Fabien=C2=A0=


    On Mon, Mar 15, 2021 at 2:50 PM Adrian Gropper <agropper@healthurl.com> wrote= :
    Thanks for asking, Fabien (and Justin).=C2=A0

    I never had a problem with RQ as th= e entity that brings claims, scope, and purpose to an AS (that is holding a= capability and policies) and gets a token.=C2=A0

    I unde= rstand=C2=A0the attraction of dealing with end-user in cases where the end-= user can be the RO but that changes the focus of attention and leads to a p= roblem in the HIPAA use-case and other use-cases that try to priorotize hum= an rights and zero-trust architecture https://docs.google.com/presentation/d/1ksKal62ZiApX09N= ejm4RSqHzHJbgwpu_l2Ho64_ePKU/edit#slide=3Did.p .

    A bit philosophically but helpful=C2=A0as a privacy and community advoca= te, I have found it useful to analyze protocols in terms of power instead o= f trust and have learned a lot from that invited expert role in W3C SSI WGs= as well as capabilities=C2=A0experts like Alan Karp and Mark Miller. Trust= is often forced on the individual by powerful governing interests or just = the fact that a sick person is in pain, anxious, overwhelmed, even scared. = Presuming trust is not much different from coercion as an exercise of power= .=C2=A0

    SSI data models have leveled the power pla= ying field but GNA protocol is where the rubber meets the road in terms of = human rights and security architecture.

    Adrian



    =
    On Mon, Mar 15, 2021 at 7:56 AM Fabie= n Imbault <fabien.imbault@gmail.com> wrote:
    Thanks Adrian.=C2=A0

    Useful comments, thanks.=C2=A0

    "The en= d-user framing we are currently working with has blurred this distinction b= etween the entity trusted by the RO and the entity that operates the client= at the RS. This, IMHO, needs to be fixed ASAP." What do you suggest?<= /div>

    Thxs
    Fabien




    <= div dir=3D"ltr" class=3D"gmail_attr">On Mon, Mar 15, 2021 at 12:43 PM Adria= n Gropper <a= gropper@healthurl.com> wrote:
    inline...

    <= div class=3D"gmail_quote">
    On Mon, Mar= 15, 2021 at 6:29 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Adri= an,=C2=A0

    It's good to check what that means in real= use cases indeed.

    My view:
    Items 1-2-3-7 = : seems quite usual. Only in this example, the patient is the RO and genera= lly delegates its decision to an automated policy engine (equivalent to seq= 1.4.4).=C2=A0
    [AG] Yes.=C2=A0 This abil= ity to automate under consent=C2=A0is foundational to any large-scale infor= mation exchange=C2=A0or data brokerage use-case.

    I be= lieve item 4 (delegation, beyond the original token issuance) would be hard= to do using JWT, at least in a generic way.=C2=A0
    [AG] Whatever GNAP decides for token formats, at least one of th= em MUST support delegation otherwise, the RO is unable to hold a requester= =C2=A0responsible. Put another way, a zero-trust architecture SHOULD hold a= n individual responsible. In an SSI model, it's the individual that con= trols their credentials and a non-repudiable signature and it's this in= dividual that is present at the time the request is issued so that individu= al can use their wallet and be subject to non-repudiation. What happens aft= erward is the responsibility of this requester.=C2=A0

    <= div>[AG] The end-user framing we are currently working with has blurred thi= s distinction between the entity trusted by the RO and the entity that oper= ates the client at the RS. This, IMHO, needs to be fixed ASAP. lest we brea= k compatibility with zero-trust architecture for no good reason.
    = =C2=A0
    Items 5 is probably beyond our scope, although Denis expresse= d the same requirement related to "solicits too much info" (based= on non opaque tokens, which might not be the general assumption / I person= ally think token content should remain opaque to the client, but knowing th= e type of the token would be useful).=C2=A0
    <= div>[AG] I'll take the "probably" for now. It's in everyo= ne's interest for GNAP to build on data minimization=C2=A0as a principl= e. Nobody can keep the RS from asking for too much because, by definition, = the RS holds all the cards. If an RS asks for too much then the request wil= l pass the AS but fail at the RS. In cases where the RO has a choice of RS,= the RS will lose business and that should keep them from asking too much. = In cases where the RO is at the mercy of the RS, the only thing GNAP might = be able to do is provide useful error messages to the various parties. In o= ther words, GNAP needs to consider which errors and warnings are in scope.<= /div>
    =C2=A0
    Item 6 asks for a relationship between RS and RO, which = I'm not sure we'd want to assume for the general case (although it = could happen in some scenarii).
    [AG] See my pe= rspective on Item 5 just above. It's up to GNAP to decide which errors = and warnings need to be handled in scope. Beyond that, RSs and ROs will hav= e a relationship whether GNAP likes it or not.
    =C2=A0
    Item 8 is= fine in principle, but would require attention to make sure it's the c= ase in practice. Depending on the sub_ids used (and even if opaque, as soon= as dereferencing is allowed), correlation might be possible.
    [AG] In the SSI world we talk in terms of mediators as a se= parate entity that is trusted by the RO to limit correlation. GNAP should b= e agnostic to whether a mediator is involved. Ideally, GNAP would note that= there are two separate correlation threats. Correlation by the requesters = and correlation by the RSs. Note that I don't worry about correlation b= y the AS because, by design, I want my agent to know everything it can and = to minimize what all other participants, except the RO and RO user agent kn= ow.

    [AG] A mediator allows the RO to use a pseudon= ym to their AS endpoint as long as the RO registers the pseudonym with the = mediator first. Keeping the RS (and AS) from correlating separate end-users= requires the end-user (and maybe the requester) to use a mediator themselv= es. I don't see any of this being a problem for GNAP but it might be he= lpful to have an informative mention of mediators in a privacy consideratio= ns section.

    Adrian

    Does that seem= correct?
    Fabien

    On Fri, Mar 12, 2021 at 10:34 PM Adrian Gro= pper <agropp= er@healthurl.com> wrote:

    Let=E2=80=99s try to map a real-w= orld use-case into the names and roles we are discussing. The use-case is d= ocumented as the API Task Force Recommendations (2016) https://www.healthit.gov/sites/default/files/facas/SingleSourceof= Truth-APITFRecommendations.pdf and I=E2=80=99ve copied below the most rele= vant section. Bold highlight is in the original. I=E2=80=99ve add= ed bold italic because it may be important to o= ur discussion.=C2=A0


    <quote>

    • ONC should clarify that while API Providers may impose security related= restrictions on app access (e.g. rate limiting, encryption, and expiration= of access tokens), it is inappropriate for API providers to set limitation= s on what a patient authorized app can do with data downstream.

      <= /li>
      • <= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-variant-ligatures:normal;font-variant-east-asian:normal;= vertical-align:baseline;white-space:pre-wrap">Given the nature of patient a= ccess rights, the provider is not in a legal position to prevent the regist= ration of apps that would aggregate or share data, for example (though the = provider might certainly decide to warn the patient, or endeavor to educate= and explain these issue to the patient, as part of the provider hosted app= approval workflow).

    • ONC should clarify that API providers a= re no= t obligated to protec= t patients by identifying "suspicious" apps. API providers may suspend= API access to an app= that has breached the API provider's terms of service , or appears to = have been compromised, or if the app poses a threat to the provider's o= wn system. However, patients must be able to override this sus= pension (except in th= e case where an app poses threat to the provider's own system or violat= es allowable terms of service).


    </quote>

    The key requirements from a patient rights and priva= cy perspective are:


    1. To allow = the patient to automate the issue of a scope-limited access capability by d= elegating the authority to process API access requests to some agent. The A= PI Provider has no say in who or where this agent is.

    2. The automa= tion of the agent is based on policies provided by the patient. The agent i= s able to process access requests from anyone and is responsible only to th= e patient. The agent responds to successful requests by issuing a filtered = capability to the requesting party.

    3. =

      = To ensure that the requestin= g party can delegate the capability using an institutional workflow system = that they trust and the patient doesn=E2=80=99t know or care about. In many= cases, the workflow system will pass the capability to some other person, = who we might call the end user. In other cases, the requesting party may fo= rward the capability directly to another person using, for example, an emai= l. Either way, the client app used by the end-user to access the API is of = no concern to the patient or to the patient=E2=80=99s agent.=C2=A0

    4. To ensure that the API Provider does not censor the client app that pres= ents the capability or solicits too much information about the client app o= r the end-user of the client app.=C2=A0

    5. If the API Provider deci= des, for any reason, to be =E2=80=9Csuspicious=E2=80=9D (as above) of the a= ccess transaction based on the information it has, it should be possible fo= r the API Provider to warn the patient and to accept an override of the war= ning by the patient. This effectively means that the end-user will provide = as much information as they think will be necessary in order to either avoi= d =E2=80=9Csuspicion=E2=80=9D or risk waiting for patient override.<= /p>

    6. The policies by which the patient or the decides to grant a capability = to the requesting party are never shared outside of the patient-agent trust= relationship. In other words, neither the patient nor the agent is asked t= o share or explain their reason for an access decision.=C2=A0

    7. Ac= cess requests to the agent are presumed confidential among the patient, the= agent, and whatever client the requesting party uses to present an access = request. The API Provider does not get to see the requests and no entity in= the GNAP authorization process, other than the patient or the agent, gets = to correlate across requests by different requesting party clients.<= /p>


    Note that I am not saying all 8 requirements are in scope for GNAP b= ut I am asking for GNAP to allow for this level of privacy on the part of s= elf-sovereign patients using self-sovereign agents and the self-sovereign l= icensed professionals they deal with.


    Adrian



    On Fri, Mar 12, 2021 at 2:50 PM Fabien Imbaul= t <fabien.= imbault@gmail.com> wrote:
    Hi Justin,=C2=A0

    Just = a quick word to say I very much agree with both the observations and the fr= aming.

    Fabien

    On Fri, Mar 12, 2021 at 6:07 PM= Justin Richer <jri= cher@mit.edu> wrote:
    As discussed at the IETF meeting, the editors proposed tha= t one of our next big topic areas was going to be the nature of the AS role= within the GNAP protocol, especially how it relates to the device-driven u= se cases that have been brought up. Apologies in advance for the long post,= but there are a lot of parts to this discussion that I=E2=80=99m hoping we= can kick off here.

    My core proposal is that we see the = AS as the component that has the following properties:
    =C2=A0- re= ceives delegation requests from the client instance for access to an RS via= access tokens, and for access to subject information returned directly to = the client instance
    =C2=A0- collects consent and authorization fr= om the RO for the delegation
    =C2=A0- issues access tokens that it= s downstream RS=E2=80=99s can interpret (and validate/accept)
    =C2= =A0- issues subject information asserted by the AS=C2=A0

    =
    This framing of the parties is really important in making a consistent= understanding of how the protocol works, and a consistent understanding is= vital if we=E2=80=99re going to function as a working group in both discus= sing the problem space and executing the solution space. For a historical e= xample, a naive approach to adding identity on top of a protocol like OAuth= 2 (or GNAP) is to declare that the resource server is the thing the user i= s logging in to. This seems reasonable at first (and some people tried doin= g this) but it violates all kinds of trust boundaries and puts new expectat= ions on the different parties that do not make sense. It stops looking anyt= hing like OAuth very quickly and turns into another protocol. If instead we= say the user is logging in to the client, things suddenly make a lot more = sense and we can do a lot more with it. (See this blog post from 2013 for o= ne take on that discussion:=C2=A0https://www.clou= didentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/)

    <= /div>
    I think we=E2=80=99ve got a similar situation here when we start = to talk about the user bringing their own AS with them. I think this is a r= easonable-seeming assumption but it=E2=80=99s based on a false premise that= the RO has to log into the AS to approve the request, and the AS has full = control and view over everything in the network. While OAuth doesn=E2=80=99= t require this, it=E2=80=99s largely assumed that=E2=80=99s how it works. A= fter all, all of the early OAuth deployments worked exactly this way: the u= ser logs in and clicks the =E2=80=9COK=E2=80=9D button. However, cloud depl= oyments have shown us that it=E2=80=99s perfectly reasonable for an OAuth A= S to take in its consent and user information from an external trusted sour= ce, and so this model is not even accurate in OAuth.

    In short, I think we can do a better job here of defining things in term= s that both accept the reality we face and enable new ideas in ways that ma= ke sense. It=E2=80=99s my stance that the user shouldn=E2=80=99t need to br= ing the AS with them in order to have the kind of input and control of the = system that people are asking for. Instead, the AS should be able to take i= nputs from things that the user controls in order for the AS to do its job.=

    People have discussed privacy concerns with the A= S knowing =E2=80=9Ctoo much=E2=80=9D, but in many of those discussions the = knowledge is simply pushed to the RS instead. What I=E2=80=99m observing he= re is really just pushing portions of the AS role into the =E2=80=9CRS=E2= =80=9D deployment. This doesn=E2=80=99t make it less of an =E2=80=9CAS=E2= =80=9D role, it=E2=80=99s just being fulfilled closely to where the RS role= is fulfilled. As such, my proposal is really not that different in practic= e, but the labels are different and better aligned with the capabilities of= the protocol.=C2=A0

    We=E2=80=99ve previousl= y talked about separating the user-facing portions of the AS into another c= omponent, and I think now might be the time to do that. This is a very flam= mable strawman proposal, but what if we had the AS defined, as above, and t= he =E2=80=9Cconsent and authorization=E2=80=9D gathering portion is augment= ed by another named component. Here let=E2=80=99s call it an Interaction Co= mponent. This can take several forms based on the kind of interaction mode = in use:

    =C2=A0- Hosted at a URL the user is redire= cted to; it can then make the user log in, consent, and whatever else they = need to do
    =C2=A0- Hosted at a URL the user will load separately = and enter in an access code
    =C2=A0- An app on the user=E2=80=99s = device that the user interacts with directly and which sends information ba= ck to the AS
    =C2=A0- An app reachable by a messaging endpoint tha= t the AS sends and receives structured information from
    =C2=A0- T= he client itself that is given an indication as to what information the AS = needs in order to fulfill the request; this could be MFA challenge/response= , user credentials, signed claims, etc.

    It=E2=80= =99s the AS=E2=80=99s job to accept any and all of these that it supports a= nd churn those into an access token.=C2=A0

    The AS = itself doesn=E2=80=99t ever need to have the user log in. The AS doesn=E2= =80=99t necessarily need to even know who the user is in any way. The AS ju= st needs to know from a trusted source that the request is approved.
    <= div>
    From a practical standpoint, I think this will have some= small changes in how we talk about the components and how we talk about th= e interaction phase of the grant negotiation process. Everything I=E2=80=99= m laying out here is currently allowed by the spec, but I think we=E2=80=99= ve carried through the same assumptions from OAuth 2 about deployment that = are both inaccurate and confusing.=C2=A0

    =C2=A0=E2= =80=94 Justin
    --
    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
    --00000000000040b83805bd93d9f0-- From nobody Mon Mar 15 07:57:48 2021 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 8A2783A13C4 for ; Mon, 15 Mar 2021 07:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 U151UVO8jtqx for ; Mon, 15 Mar 2021 07:57:36 -0700 (PDT) Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com [209.85.217.47]) (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 C8DE93A1395 for ; Mon, 15 Mar 2021 07:57:35 -0700 (PDT) Received: by mail-vs1-f47.google.com with SMTP id m18so16509139vsa.1 for ; Mon, 15 Mar 2021 07:57:35 -0700 (PDT) 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=YeXLrk0zn8YjoA529Rmd6ESW0wajoVMer4WW4GC/zUM=; b=p6fwUCws2o24JxIdk0C1GYW5KufJ6i3D5/PYagyQB7pOB4v7hSeDt5ucD4gK6rrbBh kKFzehE3VNGqCYdtRm0fcc0knmD17TPtgBZ7IPBLdBXU1InkScfulqELUcxH6oBDJF3X dttCM+ec6U5u5+UMf4Ob2o5YiyKSefbgPy5jtLsiaXH3Nqlxm+5xbnpbWii2fYwcUbme Tpa5uelPStcPEZJkLtVqYuy4IzLu1a3X3ACb2UByAGWfSxtovkCMShY7uIbMUEBKDbAx u9G2uwgJco1A8BfN3glpQDsdLACJjtbiDYhtSYKQLKvCPeQbgr6Ddgz8jHsv7Lk1kmK4 0XJg== X-Gm-Message-State: AOAM530yiBr6X47Aw/CWOM46UJdusumU8ZnGL4zD3hUdAoWT94fu9+2c EVm59TwkHtn6Mvd84WdslD+aaQ0jQl8lgIv4fMU= X-Google-Smtp-Source: ABdhPJzw9dL5H4OhzVSNT1QeQRb8bkMYgJmM/2XkGnRwwd/kMpM2uMa5jt9UuVbdSdVPU7iMLcCqI8t3wiJ/3LnMc3k= X-Received: by 2002:a67:db84:: with SMTP id f4mr5430252vsk.20.1615820254521; Mon, 15 Mar 2021 07:57:34 -0700 (PDT) MIME-Version: 1.0 References: <205ACFE1-7D4C-4D7C-B394-4AD8A4D4D080@mit.edu> In-Reply-To: From: Adrian Gropper Date: Mon, 15 Mar 2021 10:57:22 -0400 Message-ID: To: Fabien Imbault Cc: Justin Richer , GNAP Mailing List , Alan Karp , Mark Miller Content-Type: multipart/alternative; boundary="0000000000004aaf3a05bd947860" Archived-At: Subject: Re: [GNAP] GNAP Architecture and the role of the AS X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2021 14:57:47 -0000 --0000000000004aaf3a05bd947860 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable No worries, GDPR is a lot like HIPAA. It's built around the separation of concerns between "controller" and "processor". Take that separation of concerns to mean the controller and processor have to be separate legal entities when designing GNAP. (OAuth obscures that distinction.) The controller receives requests and holds privacy policies but might never see the data itself in most cases. The processor has only security to worry about. If it can avoid making any identity decisions by using capabilities then it saves a lot of risk and cost. If the data being processed is encrypted, as in W3C Confidential Storage WG where I'm trying to insist on GNAP as the protocol, then the processor (a W3C / DIF Encrypted Data Vault) has even fewer legal responsibilities and lower compliance costs. I'm not against keeping the end-user actor as someone in control of their Self Sovereign Identity. The hard part is that SSI does not consider delegation. The policies are assumed to be in the end-user's head, not their wallet. That assumption is what GNAP now has to deal with because we've been delegated the delegation work. To consider power as part of our GNAP definitions language, we need to acknowledge the role of fiduciaires as accountable delegates and the audit protocols that keep them honest. Start by watching https://www.netflix.com/title/81350429 GNAP may be able to avoid introducing the role of notary before we're through but someone will need to introduce auditability of what the AS and RS do if they're fiduciary controllers and processors respectively. That's what's keeping me up at night. Adrian On Mon, Mar 15, 2021 at 10:13 AM Fabien Imbault wrote: > Thanks Adrian. > > I'm not very familiar with HIPAA (being based in Europe) but I don't see > "end-user" as being in opposition with ZTA. To me (s)he's just the one > using the client software, in such a way that the AS indeed needs to > establish sufficient confidence in who that is to make him/her get access= . > (S)he could either be the RO or not. > > But it's true we never define its position of power to the RO. Not sure > how we could include it. > > Fabien > > > On Mon, Mar 15, 2021 at 2:50 PM Adrian Gropper > wrote: > >> Thanks for asking, Fabien (and Justin). >> >> I never had a problem with RQ as the entity that brings claims, scope, >> and purpose to an AS (that is holding a capability and policies) and get= s a >> token. >> >> I understand the attraction of dealing with end-user in cases where the >> end-user can be the RO but that changes the focus of attention and leads= to >> a problem in the HIPAA use-case and other use-cases that try to prioroti= ze >> human rights and zero-trust architecture >> https://docs.google.com/presentation/d/1ksKal62ZiApX09Nejm4RSqHzHJbgwpu_= l2Ho64_ePKU/edit#slide=3Did.p >> . >> >> A bit philosophically but helpful as a privacy and community advocate, I >> have found it useful to analyze protocols in terms of power instead of >> trust and have learned a lot from that invited expert role in W3C SSI WG= s >> as well as capabilities experts like Alan Karp and Mark Miller. Trust is >> often forced on the individual by powerful governing interests or just t= he >> fact that a sick person is in pain, anxious, overwhelmed, even scared. >> Presuming trust is not much different from coercion as an exercise of >> power. >> >> SSI data models have leveled the power playing field but GNA protocol is >> where the rubber meets the road in terms of human rights and security >> architecture. >> >> Adrian >> >> >> >> On Mon, Mar 15, 2021 at 7:56 AM Fabien Imbault >> wrote: >> >>> Thanks Adrian. >>> >>> Useful comments, thanks. >>> >>> "The end-user framing we are currently working with has blurred this >>> distinction between the entity trusted by the RO and the entity that >>> operates the client at the RS. This, IMHO, needs to be fixed ASAP." Wha= t do >>> you suggest? >>> >>> Thxs >>> Fabien >>> >>> >>> >>> >>> >>> On Mon, Mar 15, 2021 at 12:43 PM Adrian Gropper >>> wrote: >>> >>>> inline... >>>> >>>> On Mon, Mar 15, 2021 at 6:29 AM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Hi Adrian, >>>>> >>>>> It's good to check what that means in real use cases indeed. >>>>> >>>>> My view: >>>>> Items 1-2-3-7 : seems quite usual. Only in this example, the patient >>>>> is the RO and generally delegates its decision to an automated policy >>>>> engine (equivalent to seq 1.4.4). >>>>> >>>> [AG] Yes. This ability to automate under consent is foundational to >>>> any large-scale information exchange or data brokerage use-case. >>>> >>>> I believe item 4 (delegation, beyond the original token issuance) woul= d >>>>> be hard to do using JWT, at least in a generic way. >>>>> >>>> [AG] Whatever GNAP decides for token formats, at least one of them MUS= T >>>> support delegation otherwise, the RO is unable to hold a >>>> requester responsible. Put another way, a zero-trust architecture SHOU= LD >>>> hold an individual responsible. In an SSI model, it's the individual t= hat >>>> controls their credentials and a non-repudiable signature and it's thi= s >>>> individual that is present at the time the request is issued so that >>>> individual can use their wallet and be subject to non-repudiation. Wha= t >>>> happens afterward is the responsibility of this requester. >>>> >>>> [AG] The end-user framing we are currently working with has blurred >>>> this distinction between the entity trusted by the RO and the entity t= hat >>>> operates the client at the RS. This, IMHO, needs to be fixed ASAP. les= t we >>>> break compatibility with zero-trust architecture for no good reason. >>>> >>>> >>>>> Items 5 is probably beyond our scope, although Denis expressed the >>>>> same requirement related to "solicits too much info" (based on non op= aque >>>>> tokens, which might not be the general assumption / I personally thin= k >>>>> token content should remain opaque to the client, but knowing the typ= e of >>>>> the token would be useful). >>>>> >>>> [AG] I'll take the "probably" for now. It's in everyone's interest for >>>> GNAP to build on data minimization as a principle. Nobody can keep the= RS >>>> from asking for too much because, by definition, the RS holds all the >>>> cards. If an RS asks for too much then the request will pass the AS bu= t >>>> fail at the RS. In cases where the RO has a choice of RS, the RS will = lose >>>> business and that should keep them from asking too much. In cases wher= e the >>>> RO is at the mercy of the RS, the only thing GNAP might be able to do = is >>>> provide useful error messages to the various parties. In other words, = GNAP >>>> needs to consider which errors and warnings are in scope. >>>> >>>> >>>>> Item 6 asks for a relationship between RS and RO, which I'm not sure >>>>> we'd want to assume for the general case (although it could happen in= some >>>>> scenarii). >>>>> >>>> [AG] See my perspective on Item 5 just above. It's up to GNAP to decid= e >>>> which errors and warnings need to be handled in scope. Beyond that, RS= s and >>>> ROs will have a relationship whether GNAP likes it or not. >>>> >>>> >>>>> Item 8 is fine in principle, but would require attention to make sure >>>>> it's the case in practice. Depending on the sub_ids used (and even if >>>>> opaque, as soon as dereferencing is allowed), correlation might be po= ssible. >>>>> >>>> [AG] In the SSI world we talk in terms of mediators as a separate >>>> entity that is trusted by the RO to limit correlation. GNAP should be >>>> agnostic to whether a mediator is involved. Ideally, GNAP would note t= hat >>>> there are two separate correlation threats. Correlation by the request= ers >>>> and correlation by the RSs. Note that I don't worry about correlation = by >>>> the AS because, by design, I want my agent to know everything it can a= nd to >>>> minimize what all other participants, except the RO and RO user agent = know. >>>> >>>> [AG] A mediator allows the RO to use a pseudonym to their AS endpoint >>>> as long as the RO registers the pseudonym with the mediator first. Kee= ping >>>> the RS (and AS) from correlating separate end-users requires the end-u= ser >>>> (and maybe the requester) to use a mediator themselves. I don't see an= y of >>>> this being a problem for GNAP but it might be helpful to have an >>>> informative mention of mediators in a privacy considerations section. >>>> >>>> Adrian >>>> >>>>> >>>>> Does that seem correct? >>>>> Fabien >>>>> >>>>> On Fri, Mar 12, 2021 at 10:34 PM Adrian Gropper < >>>>> agropper@healthurl.com> wrote: >>>>> >>>>>> Let=E2=80=99s try to map a real-world use-case into the names and ro= les we >>>>>> are discussing. The use-case is documented as the API Task Force >>>>>> Recommendations (2016) >>>>>> https://www.healthit.gov/sites/default/files/facas/SingleSourceofTru= th-APITFRecommendations.pdf >>>>>> and I=E2=80=99ve copied below the most relevant section. Bold highli= ght is >>>>>> in the original. I=E2=80=99ve added bold italic because it may be im= portant >>>>>> to our discussion. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> - >>>>>> >>>>>> ONC should clarify that while API Providers may impose security >>>>>> related restrictions on app access (e.g. rate limiting, encryptio= n, and >>>>>> expiration of access tokens), it is inappropriate for API provide= rs to set >>>>>> limitations on what a patient authorized app can do with data dow= nstream. >>>>>> - >>>>>> >>>>>> Given the nature of patient access rights, the provider is not >>>>>> in a legal position to prevent the registration of apps that w= ould >>>>>> aggregate or share data, for example (though the provider migh= t certainly >>>>>> decide to warn the patient, or endeavor to educate and explain= these issue >>>>>> to the patient, as part of the provider hosted app approval wo= rkflow). >>>>>> - >>>>>> >>>>>> ONC should clarify that API providers are not obligated to >>>>>> protect patients by identifying "suspicious" apps. API providers = may >>>>>> suspend API access to an app that has breached the API provider's >>>>>> terms of service , or appears to have been compromised, or if the= app poses >>>>>> a threat to the provider's own system. However, patients must be >>>>>> able to override this suspension (except in the case where an app >>>>>> poses threat to the provider's own system or violates allowable t= erms of >>>>>> service). >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The key requirements from a patient rights and privacy perspective >>>>>> are: >>>>>> >>>>>> >>>>>> 1. >>>>>> >>>>>> To delegate a scope-limited access capability to anyone anywhere >>>>>> without having to explain or justify that to the API Provider. >>>>>> 2. >>>>>> >>>>>> To allow the patient to automate the issue of a scope-limited >>>>>> access capability by delegating the authority to process API acce= ss >>>>>> requests to some agent. The API Provider has no say in who or whe= re this >>>>>> agent is. >>>>>> 3. >>>>>> >>>>>> The automation of the agent is based on policies provided by the >>>>>> patient. The agent is able to process access requests from anyone= and is >>>>>> responsible only to the patient. The agent responds to successful= requests >>>>>> by issuing a filtered capability to the requesting party. >>>>>> 4. >>>>>> >>>>>> To ensure that the requesting party can delegate the capability >>>>>> using an institutional workflow system that they trust and the pa= tient >>>>>> doesn=E2=80=99t know or care about. In many cases, the workflow s= ystem will pass >>>>>> the capability to some other person, who we might call the end us= er. In >>>>>> other cases, the requesting party may forward the capability dire= ctly to >>>>>> another person using, for example, an email. Either way, the clie= nt app >>>>>> used by the end-user to access the API is of no concern to the pa= tient or >>>>>> to the patient=E2=80=99s agent. >>>>>> 5. >>>>>> >>>>>> To ensure that the API Provider does not censor the client app >>>>>> that presents the capability or solicits too much information abo= ut the >>>>>> client app or the end-user of the client app. >>>>>> 6. >>>>>> >>>>>> If the API Provider decides, for any reason, to be =E2=80=9Csuspi= cious=E2=80=9D >>>>>> (as above) of the access transaction based on the information it = has, it >>>>>> should be possible for the API Provider to warn the patient and t= o accept >>>>>> an override of the warning by the patient. This effectively means= that the >>>>>> end-user will provide as much information as they think will be n= ecessary >>>>>> in order to either avoid =E2=80=9Csuspicion=E2=80=9D or risk wait= ing for patient override. >>>>>> 7. >>>>>> >>>>>> The policies by which the patient or the decides to grant a >>>>>> capability to the requesting party are never shared outside of th= e >>>>>> patient-agent trust relationship. In other words, neither the pat= ient nor >>>>>> the agent is asked to share or explain their reason for an access= decision. >>>>>> 8. >>>>>> >>>>>> Access requests to the agent are presumed confidential among the >>>>>> patient, the agent, and whatever client the requesting party uses= to >>>>>> present an access request. The API Provider does not get to see t= he >>>>>> requests and no entity in the GNAP authorization process, other t= han the >>>>>> patient or the agent, gets to correlate across requests by differ= ent >>>>>> requesting party clients. >>>>>> >>>>>> >>>>>> Note that I am not saying all 8 requirements are in scope for GNAP >>>>>> but I am asking for GNAP to allow for this level of privacy on the p= art of >>>>>> self-sovereign patients using self-sovereign agents and the self-sov= ereign >>>>>> licensed professionals they deal with. >>>>>> >>>>>> Adrian >>>>>> >>>>>> >>>>>> On Fri, Mar 12, 2021 at 2:50 PM Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>>> Hi Justin, >>>>>>> >>>>>>> Just a quick word to say I very much agree with both the >>>>>>> observations and the framing. >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> On Fri, Mar 12, 2021 at 6:07 PM Justin Richer >>>>>>> wrote: >>>>>>> >>>>>>>> As discussed at the IETF meeting, the editors proposed that one of >>>>>>>> our next big topic areas was going to be the nature of the AS role= within >>>>>>>> the GNAP protocol, especially how it relates to the device-driven = use cases >>>>>>>> that have been brought up. Apologies in advance for the long post,= but >>>>>>>> there are a lot of parts to this discussion that I=E2=80=99m hopin= g we can kick off >>>>>>>> here. >>>>>>>> >>>>>>>> My core proposal is that we see the AS as the component that has >>>>>>>> the following properties: >>>>>>>> - receives delegation requests from the client instance for acces= s >>>>>>>> to an RS via access tokens, and for access to subject information = returned >>>>>>>> directly to the client instance >>>>>>>> - collects consent and authorization from the RO for the delegati= on >>>>>>>> - issues access tokens that its downstream RS=E2=80=99s can inter= pret (and >>>>>>>> validate/accept) >>>>>>>> - issues subject information asserted by the AS >>>>>>>> >>>>>>>> This framing of the parties is really important in making a >>>>>>>> consistent understanding of how the protocol works, and a consiste= nt >>>>>>>> understanding is vital if we=E2=80=99re going to function as a wor= king group in >>>>>>>> both discussing the problem space and executing the solution space= . For a >>>>>>>> historical example, a naive approach to adding identity on top of = a >>>>>>>> protocol like OAuth 2 (or GNAP) is to declare that the resource se= rver is >>>>>>>> the thing the user is logging in to. This seems reasonable at firs= t (and >>>>>>>> some people tried doing this) but it violates all kinds of trust b= oundaries >>>>>>>> and puts new expectations on the different parties that do not mak= e sense. >>>>>>>> It stops looking anything like OAuth very quickly and turns into a= nother >>>>>>>> protocol. If instead we say the user is logging in to the client, = things >>>>>>>> suddenly make a lot more sense and we can do a lot more with it. (= See this >>>>>>>> blog post from 2013 for one take on that discussion: >>>>>>>> https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-i= n-4/ >>>>>>>> ) >>>>>>>> >>>>>>>> I think we=E2=80=99ve got a similar situation here when we start t= o talk >>>>>>>> about the user bringing their own AS with them. I think this is a >>>>>>>> reasonable-seeming assumption but it=E2=80=99s based on a false pr= emise that the RO >>>>>>>> has to log into the AS to approve the request, and the AS has full= control >>>>>>>> and view over everything in the network. While OAuth doesn=E2=80= =99t require this, >>>>>>>> it=E2=80=99s largely assumed that=E2=80=99s how it works. After al= l, all of the early OAuth >>>>>>>> deployments worked exactly this way: the user logs in and clicks t= he =E2=80=9COK=E2=80=9D >>>>>>>> button. However, cloud deployments have shown us that it=E2=80=99s= perfectly >>>>>>>> reasonable for an OAuth AS to take in its consent and user informa= tion from >>>>>>>> an external trusted source, and so this model is not even accurate= in OAuth. >>>>>>>> >>>>>>>> In short, I think we can do a better job here of defining things i= n >>>>>>>> terms that both accept the reality we face and enable new ideas in= ways >>>>>>>> that make sense. It=E2=80=99s my stance that the user shouldn=E2= =80=99t need to bring the >>>>>>>> AS with them in order to have the kind of input and control of the= system >>>>>>>> that people are asking for. Instead, the AS should be able to take= inputs >>>>>>>> from things that the user controls in order for the AS to do its j= ob. >>>>>>>> >>>>>>>> People have discussed privacy concerns with the AS knowing =E2=80= =9Ctoo >>>>>>>> much=E2=80=9D, but in many of those discussions the knowledge is s= imply pushed to >>>>>>>> the RS instead. What I=E2=80=99m observing here is really just pus= hing portions of >>>>>>>> the AS role into the =E2=80=9CRS=E2=80=9D deployment. This doesn= =E2=80=99t make it less of an =E2=80=9CAS=E2=80=9D >>>>>>>> role, it=E2=80=99s just being fulfilled closely to where the RS ro= le is fulfilled. >>>>>>>> As such, my proposal is really not that different in practice, but= the >>>>>>>> labels are different and better aligned with the capabilities of t= he >>>>>>>> protocol. >>>>>>>> >>>>>>>> We=E2=80=99ve previously talked about separating the user-facing p= ortions >>>>>>>> of the AS into another component, and I think now might be the tim= e to do >>>>>>>> that. This is a very flammable strawman proposal, but what if we h= ad the AS >>>>>>>> defined, as above, and the =E2=80=9Cconsent and authorization=E2= =80=9D gathering portion is >>>>>>>> augmented by another named component. Here let=E2=80=99s call it a= n Interaction >>>>>>>> Component. This can take several forms based on the kind of intera= ction >>>>>>>> mode in use: >>>>>>>> >>>>>>>> - Hosted at a URL the user is redirected to; it can then make the >>>>>>>> user log in, consent, and whatever else they need to do >>>>>>>> - Hosted at a URL the user will load separately and enter in an >>>>>>>> access code >>>>>>>> - An app on the user=E2=80=99s device that the user interacts wit= h >>>>>>>> directly and which sends information back to the AS >>>>>>>> - An app reachable by a messaging endpoint that the AS sends and >>>>>>>> receives structured information from >>>>>>>> - The client itself that is given an indication as to what >>>>>>>> information the AS needs in order to fulfill the request; this cou= ld be MFA >>>>>>>> challenge/response, user credentials, signed claims, etc. >>>>>>>> >>>>>>>> It=E2=80=99s the AS=E2=80=99s job to accept any and all of these t= hat it supports >>>>>>>> and churn those into an access token. >>>>>>>> >>>>>>>> The AS itself doesn=E2=80=99t ever need to have the user log in. T= he AS >>>>>>>> doesn=E2=80=99t necessarily need to even know who the user is in a= ny way. The AS >>>>>>>> just needs to know from a trusted source that the request is appro= ved. >>>>>>>> >>>>>>>> From a practical standpoint, I think this will have some small >>>>>>>> changes in how we talk about the components and how we talk about = the >>>>>>>> interaction phase of the grant negotiation process. Everything I= =E2=80=99m laying >>>>>>>> out here is currently allowed by the spec, but I think we=E2=80=99= ve carried >>>>>>>> through the same assumptions from OAuth 2 about deployment that ar= e both >>>>>>>> inaccurate and confusing. >>>>>>>> >>>>>>>> =E2=80=94 Justin >>>>>>>> -- >>>>>>>> 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 >>>>>>> >>>>>> --0000000000004aaf3a05bd947860 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    No worries, GDPR is a lot like HIPAA. It&= #39;s built around the separation of concerns between "controller"= ; and "processor". Take that separation of concerns to mean the c= ontroller and processor have to be separate=C2=A0legal entities when design= ing GNAP. (OAuth obscures that distinction.) The controller receives reques= ts and holds privacy policies but might never see the data itself in most c= ases. The processor has only security to worry about. If it can avoid makin= g any identity decisions by using capabilities then it saves a lot of risk = and cost. If the data being processed is encrypted, as in W3C Confidential= =C2=A0Storage WG where I'm trying to insist on GNAP as the protocol, th= en the processor (a W3C / DIF Encrypted Data Vault) has even fewer legal re= sponsibilities and lower compliance costs.

    I'm not a= gainst keeping the end-user actor as someone in control=C2=A0of their Self = Sovereign Identity. The hard part is that SSI does not consider delegation.= The policies are assumed to be in the end-user's head, not their walle= t. That assumption is what GNAP now has to deal with because we've been= delegated the delegation work.

    To consider power = as part of our GNAP definitions language, we need to acknowledge the role o= f fiduciaires as accountable delegates and the audit protocols that keep th= em honest. Start by watching=C2=A0https://www.netflix.com/title/81350429

    GNAP may be able to avoid introducing the role of notary before we'r= e through but someone will need to introduce auditability of what the AS an= d RS do if they're fiduciary controllers and processors respectively. T= hat's what's keeping me up at night.

    Adria= n

    On Mon, Mar 15, 2021 at 10:13 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks Adrian.= =C2=A0

    I'm not very familiar with HIPAA (being based= in Europe) but I don't see "end-user" as being in opposition= with ZTA. To me (s)he's=C2=A0just the one using the client software, i= n such a way that the=C2=A0AS indeed needs to establish sufficient confiden= ce in who that is to make him/her get access. (S)he could either be the RO = or not.=C2=A0

    But it's true we never define it= s position of power to the RO. Not sure how we could include it.
    =
    Fabien=C2=A0


    On Mon, Mar 15, 2021 at 2:5= 0 PM Adrian Gropper <agropper@healthurl.com> wrote:
    =
    Thanks for asking, Fabien (and Justin).= =C2=A0

    I never had a probl= em with RQ as the entity that brings claims, scope, and purpose to an AS (t= hat is holding a capability and policies) and gets a token.=C2=A0

    <= /div>
    I understand=C2=A0the attraction of dealing with end-user in case= s where the end-user can be the RO but that changes the focus of attention = and leads to a problem in the HIPAA use-case and other use-cases that try t= o priorotize human rights and zero-trust architecture https://docs.google.com/presentation/d/= 1ksKal62ZiApX09Nejm4RSqHzHJbgwpu_l2Ho64_ePKU/edit#slide=3Did.p .
    <= div>
    A bit philosophically but helpful=C2=A0as a privacy and = community advocate, I have found it useful to analyze protocols in terms of= power instead of trust and have learned a lot from that invited expert rol= e in W3C SSI WGs as well as capabilities=C2=A0experts like Alan Karp and Ma= rk Miller. Trust is often forced on the individual by powerful governing in= terests or just the fact that a sick person is in pain, anxious, overwhelme= d, even scared. Presuming trust is not much different from coercion as an e= xercise of power.=C2=A0

    SSI data models have level= ed the power playing field but GNA protocol is where the rubber meets the r= oad in terms of human rights and security architecture.

    Adrian



    On Mon, Mar 15, 2021= at 7:56 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks Adrian.=C2=A0

    Useful co= mments, thanks.=C2=A0

    "The end-user framing w= e are currently working with has blurred this distinction between the entit= y trusted by the RO and the entity that operates the client at the RS. This= , IMHO, needs to be fixed ASAP." What do you suggest?

    Thxs
    Fabien



    =


    On Mon, Mar 15, 2021 at 12:43 PM Adrian Gropper <agropper@healthur= l.com> wrote:
    inline...

    On Mon, Mar 15, 2021 at 6:29 AM Fabien Imbault <fabien.imbault@gmail= .com> wrote:
    Hi Adrian,= =C2=A0

    It's good to check what that means in real us= e cases indeed.

    My view:
    Items 1-2-3-7 : s= eems quite usual. Only in this example, the patient is the RO and generally= delegates its decision to an automated policy engine (equivalent to seq 1.= 4.4).=C2=A0
    [AG] Yes.=C2=A0 This ability= to automate under consent=C2=A0is foundational to any large-scale informat= ion exchange=C2=A0or data brokerage use-case.

    I believe item 4 (delegation, beyond the= original token issuance) would be hard to do using JWT, at least in a gene= ric way.=C2=A0
    [AG] Whatever GNAP decide= s for token formats, at least one of them MUST support delegation otherwise= , the RO is unable to hold a requester=C2=A0responsible. Put another way, a= zero-trust architecture SHOULD hold an individual responsible. In an SSI m= odel, it's the individual that controls their credentials and a non-rep= udiable signature and it's this individual that is present at the time = the request is issued so that individual can use their wallet and be subjec= t to non-repudiation. What happens afterward is the responsibility of this = requester.=C2=A0

    [AG] The end-user framing we are = currently working with has blurred this distinction between the entity trus= ted by the RO and the entity that operates the client at the RS. This, IMHO= , needs to be fixed ASAP. lest we break compatibility with zero-trust archi= tecture for no good reason.
    =C2=A0
    Items 5 is probably beyond our scope, although Denis exp= ressed the same requirement related to "solicits too much info" (= based on non opaque tokens, which might not be the general assumption / I p= ersonally think token content should remain opaque to the client, but knowi= ng the type of the token would be useful).=C2=A0
    [AG] I'll take the "probably" for now. It's in e= veryone's interest for GNAP to build on data minimization=C2=A0as a pri= nciple. Nobody can keep the RS from asking for too much because, by definit= ion, the RS holds all the cards. If an RS asks for too much then the reques= t will pass the AS but fail at the RS. In cases where the RO has a choice o= f RS, the RS will lose business and that should keep them from asking too m= uch. In cases where the RO is at the mercy of the RS, the only thing GNAP m= ight be able to do is provide useful error messages to the various parties.= In other words, GNAP needs to consider which errors and warnings are in sc= ope.
    =C2=A0
    Item 6 as= ks for a relationship between RS and RO, which I'm not sure we'd wa= nt to assume for the general case (although it could happen in some scenari= i).
    [AG] See my perspective on Item 5 just abo= ve. It's up to GNAP to decide which errors and warnings need to be hand= led in scope. Beyond that, RSs and ROs will have a relationship whether GNA= P likes it or not.
    =C2=A0
    =
    Item 8 is fine in principle, but would require attention to make sure = it's the case in practice. Depending on the sub_ids used (and even if o= paque, as soon as dereferencing is allowed), correlation might be possible.=
    [AG] In the SSI world we talk in terms of med= iators as a separate entity that is trusted by the RO to limit correlation.= GNAP should be agnostic to whether a mediator is involved. Ideally, GNAP w= ould note that there are two separate correlation threats. Correlation by t= he requesters and correlation by the RSs. Note that I don't worry about= correlation by the AS because, by design, I want my agent to know everythi= ng it can and to minimize what all other participants, except the RO and RO= user agent know.

    [AG] A mediator allows the RO to= use a pseudonym to their AS endpoint as long as the RO registers the pseud= onym with the mediator first. Keeping the RS (and AS) from correlating sepa= rate end-users requires the end-user (and maybe the requester) to use a med= iator themselves. I don't see any of this being a problem for GNAP but = it might be helpful to have an informative mention of mediators in a privac= y considerations section.

    Adrian

    Does that seem correct?
    Fabien

    On Fri, Mar 12, 2021 at 10:34 PM Adrian Gropper <agropper@healthurl.com> wrote:

    Let=E2=80=99s try to map a real-world use-case into the na= mes and roles we are discussing. The use-case is documented as the API Task= Force Recommendations (2016) https://www.hea= lthit.gov/sites/default/files/facas/SingleSourceofTruth-APITFRecommendation= s.pdf and I=E2=80=99ve copied below the most relevant section. highlight is in the original. I=E2=80=99ve added bold italic because it may be important to our discussion.=C2=A0


    =

    <= font face=3D"Arial"><quote>

    • ONC should clarify th= at while API Providers may impose security related restrictions on app acce= ss (e.g. rate limiting, encryption, and expiration of access tokens), it is= inappropriate for API providers to set limitations on what a patient autho= rized app can do with data downstream.

      • Given the nature of patient access rights, the provide= r is not in a legal position to prevent the registration of apps that would= aggregate or share data, for example (though the provider might certainly = decide to warn the patient, or endeavor to educate and explain these issue = to the patient, as part of the provider hosted app approval workflow).

    • ONC should clarify that API providers are not obligated to protect patients by identifying &= quot;suspicious" apps. API providers may suspend API access to an app that has breached the API = provider's terms of service , or appears to have been compromised, or i= f the app poses a threat to the provider's own system. However, = patients must be able to override this suspension (except in the case where an app poses= threat to the provider's own system or violates allowable terms of ser= vice).


      =

    </quote>

    Th= e key requirements from a patient rights and privacy perspective are:


    1. To delegate a scope-lim= ited access capability to anyone anywhere without having to explain or just= ify that to the API Provider.

    2. To allow the patient to automate t= he issue of a scope-limited access capability by delegating the authority t= o process API access requests to some agent. The API Provider has no say in= who or where this agent is.

    3. The automation of the agent is bas= ed on policies provided by the patient. The agent is able to process access= requests from anyone and is responsible only to the patient. The agent res= ponds to successful requests by issuing a filtered capability to the reques= ting party.

    4. To ensure that the requesting party can delegate the= capability using an institutional workflow system that they trust and the = patient doesn=E2=80=99t know or care about. In many cases, the workflow sys= tem will pass the capability to some other person, who we might call the en= d user. In other cases, the requesting party may forward the capability dir= ectly to another person using, for example, an email. Either way, the clien= t app used by the end-user to access the API is of no concern to the patien= t or to the patient=E2=80=99s agent.=C2=A0

    5. To ensure that the AP= I Provider does not censor the client app that presents the capability or s= olicits too much information about the client app or the end-user of the cl= ient app.=C2=A0

    6. If the API Provider decides, for any reason, to = be =E2=80=9Csuspicious=E2=80=9D (as above) of the access transaction based = on the information it has, it should be possible for the API Provider to wa= rn the patient and to accept an override of the warning by the patient. Thi= s effectively means that the end-user will provide as much information as t= hey think will be necessary in order to either avoid =E2=80=9Csuspicion=E2= =80=9D or risk waiting for patient override.

    7. The policies by whi= ch the patient or the decides to grant a capability to the requesting party= are never shared outside of the patient-agent trust relationship. In other= words, neither the patient nor the agent is asked to share or explain thei= r reason for an access decision.=C2=A0

    8. Access requests to the ag= ent are presumed confidential among the patient, the agent, and whatever cl= ient the requesting party uses to present an access request. The API Provid= er does not get to see the requests and no entity in the GNAP authorization= process, other than the patient or the agent, gets to correlate across req= uests by different requesting party clients.


    Note that I am n= ot saying all 8 requirements are in scope for GNAP but I am asking for GNAP= to allow for this level of privacy on the part of self-sovereign patients = using self-sovereign agents and the self-sovereign licensed professionals t= hey deal with.


    Adrian


    <= /div>

    On Fri, Mar 12, 2021 at 2:50 PM Fabien Imbault <fabien.imbault@gmail.com>= wrote:
    Hi Justin,=C2=A0
    Just a quick word to say I very much agree with both the observ= ations and the framing.

    Fabien

    On Fri, Mar 12= , 2021 at 6:07 PM Justin Richer <jricher@mit.edu> wrote:
    As discussed at the IETF meeting, the editors proposed that one of our nex= t big topic areas was going to be the nature of the AS role within the GNAP= protocol, especially how it relates to the device-driven use cases that ha= ve been brought up. Apologies in advance for the long post, but there are a= lot of parts to this discussion that I=E2=80=99m hoping we can kick off he= re.

    My core proposal is that we see the AS as the compon= ent that has the following properties:
    =C2=A0- receives delegatio= n requests from the client instance for access to an RS via access tokens, = and for access to subject information returned directly to the client insta= nce
    =C2=A0- collects consent and authorization from the RO for th= e delegation
    =C2=A0- issues access tokens that its downstream RS= =E2=80=99s can interpret (and validate/accept)
    =C2=A0- issues sub= ject information asserted by the AS=C2=A0

    This frami= ng of the parties is really important in making a consistent understanding = of how the protocol works, and a consistent understanding is vital if we=E2= =80=99re going to function as a working group in both discussing the proble= m space and executing the solution space. For a historical example, a naive= approach to adding identity on top of a protocol like OAuth 2 (or GNAP) is= to declare that the resource server is the thing the user is logging in to= . This seems reasonable at first (and some people tried doing this) but it = violates all kinds of trust boundaries and puts new expectations on the dif= ferent parties that do not make sense. It stops looking anything like OAuth= very quickly and turns into another protocol. If instead we say the user i= s logging in to the client, things suddenly make a lot more sense and we ca= n do a lot more with it. (See this blog post from 2013 for one take on that= discussion:=C2=A0https://www.cloudidentity.com/b= log/2013/01/02/oauth-2-0-and-sign-in-4/)

    I thi= nk we=E2=80=99ve got a similar situation here when we start to talk about t= he user bringing their own AS with them. I think this is a reasonable-seemi= ng assumption but it=E2=80=99s based on a false premise that the RO has to = log into the AS to approve the request, and the AS has full control and vie= w over everything in the network. While OAuth doesn=E2=80=99t require this,= it=E2=80=99s largely assumed that=E2=80=99s how it works. After all, all o= f the early OAuth deployments worked exactly this way: the user logs in and= clicks the =E2=80=9COK=E2=80=9D button. However, cloud deployments have sh= own us that it=E2=80=99s perfectly reasonable for an OAuth AS to take in it= s consent and user information from an external trusted source, and so this= model is not even accurate in OAuth.

    In short, I = think we can do a better job here of defining things in terms that both acc= ept the reality we face and enable new ideas in ways that make sense. It=E2= =80=99s my stance that the user shouldn=E2=80=99t need to bring the AS with= them in order to have the kind of input and control of the system that peo= ple are asking for. Instead, the AS should be able to take inputs from thin= gs that the user controls in order for the AS to do its job.

    =
    People have discussed privacy concerns with the AS knowing =E2= =80=9Ctoo much=E2=80=9D, but in many of those discussions the knowledge is = simply pushed to the RS instead. What I=E2=80=99m observing here is really = just pushing portions of the AS role into the =E2=80=9CRS=E2=80=9D deployme= nt. This doesn=E2=80=99t make it less of an =E2=80=9CAS=E2=80=9D role, it= =E2=80=99s just being fulfilled closely to where the RS role is fulfilled. = As such, my proposal is really not that different in practice, but the labe= ls are different and better aligned with the capabilities of the protocol.= =C2=A0

    We=E2=80=99ve previously talked about= separating the user-facing portions of the AS into another component, and = I think now might be the time to do that. This is a very flammable strawman= proposal, but what if we had the AS defined, as above, and the =E2=80=9Cco= nsent and authorization=E2=80=9D gathering portion is augmented by another = named component. Here let=E2=80=99s call it an Interaction Component. This = can take several forms based on the kind of interaction mode in use:
    <= div>
    =C2=A0- Hosted at a URL the user is redirected to; it ca= n then make the user log in, consent, and whatever else they need to do
    =C2=A0- Hosted at a URL the user will load separately and enter in a= n access code
    =C2=A0- An app on the user=E2=80=99s device that th= e user interacts with directly and which sends information back to the AS
    =C2=A0- An app reachable by a messaging endpoint that the AS sends= and receives structured information from
    =C2=A0- The client itse= lf that is given an indication as to what information the AS needs in order= to fulfill the request; this could be MFA challenge/response, user credent= ials, signed claims, etc.

    It=E2=80=99s the AS=E2= =80=99s job to accept any and all of these that it supports and churn those= into an access token.=C2=A0

    The AS itself doesn= =E2=80=99t ever need to have the user log in. The AS doesn=E2=80=99t necess= arily need to even know who the user is in any way. The AS just needs to kn= ow from a trusted source that the request is approved.

    =
    From a practical standpoint, I think this will have some small changes= in how we talk about the components and how we talk about the interaction = phase of the grant negotiation process. Everything I=E2=80=99m laying out h= ere is currently allowed by the spec, but I think we=E2=80=99ve carried thr= ough the same assumptions from OAuth 2 about deployment that are both inacc= urate and confusing.=C2=A0

    =C2=A0=E2=80=94 Justin<= /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
    --0000000000004aaf3a05bd947860-- From nobody Mon Mar 15 08:03:10 2021 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 423833A1380 for ; Mon, 15 Mar 2021 08:03:08 -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 TNpudn3Nwq4n for ; Mon, 15 Mar 2021 08:03:03 -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 AA6843A137F for ; Mon, 15 Mar 2021 08:03:03 -0700 (PDT) Received: by mail-il1-x130.google.com with SMTP id c10so9620718ilo.8 for ; Mon, 15 Mar 2021 08:03:03 -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=KzUx0oGpwHlgOoK4yAicwdUG0AMA4CSA/+UTAxNi4G8=; b=W52OHMw+BL789U8TO+c75iOXcIMKJFQq8WXeuMnOUWxRjanjY9C1epUW9WRGhUbKZJ EGZwU31nvawLYAUy2WSQZ4ksGQyuYiHxZAeSuw5XiUUc8Ofal0DA7FysWbxGhW77ybQE KdyfhHD18QXXaxtVZPweN/vUC+r3hvE8PRsOfw3X+riDksb21j0WK/L5TmVYLOhpjUmI cQpF78dxVasqWw71F7PDgaKf/CtlBAt2uVmHhu1JEGoZNN4gl3rMZE8MISQXuanGrz8L SB3HlEXeCClQIuTBwepKOgFolEqbpTOXu9tf0fI4k1yAfzhgkByRYz0o/hu17Nbq9x4D 07Fw== 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=KzUx0oGpwHlgOoK4yAicwdUG0AMA4CSA/+UTAxNi4G8=; b=SYDaTSku6zt7oBDr06m4FIoFjEK6JOecufYFdXXFBEZRLKmLnpk1WtZ5w0ljpGsrpk 9qZN3Ah8sZv4E48Tg190v+y6crOsl9jYtNY14yTnmyBCYq70m+Fkthtc+AOuT3Tqxai2 q8Aqc6cq60VS3ijEfqeYys6CMMrIC/iKDg6zFGbkuDX58Jw9hGRWQda+bRj9UmgoD+r0 IziIghBUVV/I714yPfvbg4r9AR25DMOKNCbmaufenoisDeDZdfGldF1KUUJM0D6Leren gkJc6JAfR63NTniGqjoJ4cHUORWBKvCOujbD1sERvJ/tewLnS/lDUvc2CwHp47uA64Os hnJQ== X-Gm-Message-State: AOAM531nx7HsVy79Jkf4ZTwwRaRIaQdL1DQmusNZGl9ZGnG6TdRe45mK eP0de59tJ+DJoBJ9mo8WBds4NZy9EBqoOsjMgpw= X-Google-Smtp-Source: ABdhPJzlAR0veBNz9VwWCZ+C4T6JbzZZ8dJ/yp+paFW0/ztak+lqceW5g76p8J9D2hDVwwquMo1apeqEgRqteTFYdPM= X-Received: by 2002:a92:c6d0:: with SMTP id v16mr11304264ilm.289.1615820580701; Mon, 15 Mar 2021 08:03:00 -0700 (PDT) MIME-Version: 1.0 References: <205ACFE1-7D4C-4D7C-B394-4AD8A4D4D080@mit.edu> In-Reply-To: From: Fabien Imbault Date: Mon, 15 Mar 2021 16:02:49 +0100 Message-ID: To: Adrian Gropper Cc: Justin Richer , GNAP Mailing List , Alan Karp , Mark Miller Content-Type: multipart/alternative; boundary="000000000000bbcaa205bd948b83" Archived-At: Subject: Re: [GNAP] GNAP Architecture and the role of the AS X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2021 15:03:08 -0000 --000000000000bbcaa205bd948b83 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, a good movie to watch ;-) - they deserved their Golden Globe. Auditability is certainly of major importance, I agree we should open an issue on that topic. Fabien On Mon, Mar 15, 2021 at 3:57 PM Adrian Gropper wrote: > No worries, GDPR is a lot like HIPAA. It's built around the separation of > concerns between "controller" and "processor". Take that separation of > concerns to mean the controller and processor have to be separate legal > entities when designing GNAP. (OAuth obscures that distinction.) The > controller receives requests and holds privacy policies but might never s= ee > the data itself in most cases. The processor has only security to worry > about. If it can avoid making any identity decisions by using capabilitie= s > then it saves a lot of risk and cost. If the data being processed is > encrypted, as in W3C Confidential Storage WG where I'm trying to insist o= n > GNAP as the protocol, then the processor (a W3C / DIF Encrypted Data Vaul= t) > has even fewer legal responsibilities and lower compliance costs. > > I'm not against keeping the end-user actor as someone in control of their > Self Sovereign Identity. The hard part is that SSI does not consider > delegation. The policies are assumed to be in the end-user's head, not > their wallet. That assumption is what GNAP now has to deal with because > we've been delegated the delegation work. > > To consider power as part of our GNAP definitions language, we need to > acknowledge the role of fiduciaires as accountable delegates and the audi= t > protocols that keep them honest. Start by watching > https://www.netflix.com/title/81350429 > > GNAP may be able to avoid introducing the role of notary before we're > through but someone will need to introduce auditability of what the AS an= d > RS do if they're fiduciary controllers and processors respectively. That'= s > what's keeping me up at night. > > Adrian > > On Mon, Mar 15, 2021 at 10:13 AM Fabien Imbault > wrote: > >> Thanks Adrian. >> >> I'm not very familiar with HIPAA (being based in Europe) but I don't see >> "end-user" as being in opposition with ZTA. To me (s)he's just the one >> using the client software, in such a way that the AS indeed needs to >> establish sufficient confidence in who that is to make him/her get acces= s. >> (S)he could either be the RO or not. >> >> But it's true we never define its position of power to the RO. Not sure >> how we could include it. >> >> Fabien >> >> >> On Mon, Mar 15, 2021 at 2:50 PM Adrian Gropper >> wrote: >> >>> Thanks for asking, Fabien (and Justin). >>> >>> I never had a problem with RQ as the entity that brings claims, scope, >>> and purpose to an AS (that is holding a capability and policies) and ge= ts a >>> token. >>> >>> I understand the attraction of dealing with end-user in cases where the >>> end-user can be the RO but that changes the focus of attention and lead= s to >>> a problem in the HIPAA use-case and other use-cases that try to priorot= ize >>> human rights and zero-trust architecture >>> https://docs.google.com/presentation/d/1ksKal62ZiApX09Nejm4RSqHzHJbgwpu= _l2Ho64_ePKU/edit#slide=3Did.p >>> . >>> >>> A bit philosophically but helpful as a privacy and community advocate, = I >>> have found it useful to analyze protocols in terms of power instead of >>> trust and have learned a lot from that invited expert role in W3C SSI W= Gs >>> as well as capabilities experts like Alan Karp and Mark Miller. Trust i= s >>> often forced on the individual by powerful governing interests or just = the >>> fact that a sick person is in pain, anxious, overwhelmed, even scared. >>> Presuming trust is not much different from coercion as an exercise of >>> power. >>> >>> SSI data models have leveled the power playing field but GNA protocol i= s >>> where the rubber meets the road in terms of human rights and security >>> architecture. >>> >>> Adrian >>> >>> >>> >>> On Mon, Mar 15, 2021 at 7:56 AM Fabien Imbault >>> wrote: >>> >>>> Thanks Adrian. >>>> >>>> Useful comments, thanks. >>>> >>>> "The end-user framing we are currently working with has blurred this >>>> distinction between the entity trusted by the RO and the entity that >>>> operates the client at the RS. This, IMHO, needs to be fixed ASAP." Wh= at do >>>> you suggest? >>>> >>>> Thxs >>>> Fabien >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Mar 15, 2021 at 12:43 PM Adrian Gropper >>>> wrote: >>>> >>>>> inline... >>>>> >>>>> On Mon, Mar 15, 2021 at 6:29 AM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Hi Adrian, >>>>>> >>>>>> It's good to check what that means in real use cases indeed. >>>>>> >>>>>> My view: >>>>>> Items 1-2-3-7 : seems quite usual. Only in this example, the patient >>>>>> is the RO and generally delegates its decision to an automated polic= y >>>>>> engine (equivalent to seq 1.4.4). >>>>>> >>>>> [AG] Yes. This ability to automate under consent is foundational to >>>>> any large-scale information exchange or data brokerage use-case. >>>>> >>>>> I believe item 4 (delegation, beyond the original token issuance) >>>>>> would be hard to do using JWT, at least in a generic way. >>>>>> >>>>> [AG] Whatever GNAP decides for token formats, at least one of them >>>>> MUST support delegation otherwise, the RO is unable to hold a >>>>> requester responsible. Put another way, a zero-trust architecture SHO= ULD >>>>> hold an individual responsible. In an SSI model, it's the individual = that >>>>> controls their credentials and a non-repudiable signature and it's th= is >>>>> individual that is present at the time the request is issued so that >>>>> individual can use their wallet and be subject to non-repudiation. Wh= at >>>>> happens afterward is the responsibility of this requester. >>>>> >>>>> [AG] The end-user framing we are currently working with has blurred >>>>> this distinction between the entity trusted by the RO and the entity = that >>>>> operates the client at the RS. This, IMHO, needs to be fixed ASAP. le= st we >>>>> break compatibility with zero-trust architecture for no good reason. >>>>> >>>>> >>>>>> Items 5 is probably beyond our scope, although Denis expressed the >>>>>> same requirement related to "solicits too much info" (based on non o= paque >>>>>> tokens, which might not be the general assumption / I personally thi= nk >>>>>> token content should remain opaque to the client, but knowing the ty= pe of >>>>>> the token would be useful). >>>>>> >>>>> [AG] I'll take the "probably" for now. It's in everyone's interest fo= r >>>>> GNAP to build on data minimization as a principle. Nobody can keep th= e RS >>>>> from asking for too much because, by definition, the RS holds all the >>>>> cards. If an RS asks for too much then the request will pass the AS b= ut >>>>> fail at the RS. In cases where the RO has a choice of RS, the RS will= lose >>>>> business and that should keep them from asking too much. In cases whe= re the >>>>> RO is at the mercy of the RS, the only thing GNAP might be able to do= is >>>>> provide useful error messages to the various parties. In other words,= GNAP >>>>> needs to consider which errors and warnings are in scope. >>>>> >>>>> >>>>>> Item 6 asks for a relationship between RS and RO, which I'm not sure >>>>>> we'd want to assume for the general case (although it could happen i= n some >>>>>> scenarii). >>>>>> >>>>> [AG] See my perspective on Item 5 just above. It's up to GNAP to >>>>> decide which errors and warnings need to be handled in scope. Beyond = that, >>>>> RSs and ROs will have a relationship whether GNAP likes it or not. >>>>> >>>>> >>>>>> Item 8 is fine in principle, but would require attention to make sur= e >>>>>> it's the case in practice. Depending on the sub_ids used (and even i= f >>>>>> opaque, as soon as dereferencing is allowed), correlation might be p= ossible. >>>>>> >>>>> [AG] In the SSI world we talk in terms of mediators as a separate >>>>> entity that is trusted by the RO to limit correlation. GNAP should be >>>>> agnostic to whether a mediator is involved. Ideally, GNAP would note = that >>>>> there are two separate correlation threats. Correlation by the reques= ters >>>>> and correlation by the RSs. Note that I don't worry about correlation= by >>>>> the AS because, by design, I want my agent to know everything it can = and to >>>>> minimize what all other participants, except the RO and RO user agent= know. >>>>> >>>>> [AG] A mediator allows the RO to use a pseudonym to their AS endpoint >>>>> as long as the RO registers the pseudonym with the mediator first. Ke= eping >>>>> the RS (and AS) from correlating separate end-users requires the end-= user >>>>> (and maybe the requester) to use a mediator themselves. I don't see a= ny of >>>>> this being a problem for GNAP but it might be helpful to have an >>>>> informative mention of mediators in a privacy considerations section. >>>>> >>>>> Adrian >>>>> >>>>>> >>>>>> Does that seem correct? >>>>>> Fabien >>>>>> >>>>>> On Fri, Mar 12, 2021 at 10:34 PM Adrian Gropper < >>>>>> agropper@healthurl.com> wrote: >>>>>> >>>>>>> Let=E2=80=99s try to map a real-world use-case into the names and r= oles we >>>>>>> are discussing. The use-case is documented as the API Task Force >>>>>>> Recommendations (2016) >>>>>>> https://www.healthit.gov/sites/default/files/facas/SingleSourceofTr= uth-APITFRecommendations.pdf >>>>>>> and I=E2=80=99ve copied below the most relevant section. Bold highl= ight is >>>>>>> in the original. I=E2=80=99ve added bold italic because it may be i= mportant >>>>>>> to our discussion. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> - >>>>>>> >>>>>>> ONC should clarify that while API Providers may impose security >>>>>>> related restrictions on app access (e.g. rate limiting, encrypti= on, and >>>>>>> expiration of access tokens), it is inappropriate for API provid= ers to set >>>>>>> limitations on what a patient authorized app can do with data do= wnstream. >>>>>>> - >>>>>>> >>>>>>> Given the nature of patient access rights, the provider is >>>>>>> not in a legal position to prevent the registration of apps t= hat would >>>>>>> aggregate or share data, for example (though the provider mig= ht certainly >>>>>>> decide to warn the patient, or endeavor to educate and explai= n these issue >>>>>>> to the patient, as part of the provider hosted app approval w= orkflow). >>>>>>> - >>>>>>> >>>>>>> ONC should clarify that API providers are not obligated to >>>>>>> protect patients by identifying "suspicious" apps. API providers= may >>>>>>> suspend API access to an app that has breached the API >>>>>>> provider's terms of service , or appears to have been compromise= d, or if >>>>>>> the app poses a threat to the provider's own system. However, pa= tients >>>>>>> must be able to override this suspension (except in the case >>>>>>> where an app poses threat to the provider's own system or violat= es >>>>>>> allowable terms of service). >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The key requirements from a patient rights and privacy perspective >>>>>>> are: >>>>>>> >>>>>>> >>>>>>> 1. >>>>>>> >>>>>>> To delegate a scope-limited access capability to anyone anywhere >>>>>>> without having to explain or justify that to the API Provider. >>>>>>> 2. >>>>>>> >>>>>>> To allow the patient to automate the issue of a scope-limited >>>>>>> access capability by delegating the authority to process API acc= ess >>>>>>> requests to some agent. The API Provider has no say in who or wh= ere this >>>>>>> agent is. >>>>>>> 3. >>>>>>> >>>>>>> The automation of the agent is based on policies provided by the >>>>>>> patient. The agent is able to process access requests from anyon= e and is >>>>>>> responsible only to the patient. The agent responds to successfu= l requests >>>>>>> by issuing a filtered capability to the requesting party. >>>>>>> 4. >>>>>>> >>>>>>> To ensure that the requesting party can delegate the capability >>>>>>> using an institutional workflow system that they trust and the p= atient >>>>>>> doesn=E2=80=99t know or care about. In many cases, the workflow = system will pass >>>>>>> the capability to some other person, who we might call the end u= ser. In >>>>>>> other cases, the requesting party may forward the capability dir= ectly to >>>>>>> another person using, for example, an email. Either way, the cli= ent app >>>>>>> used by the end-user to access the API is of no concern to the p= atient or >>>>>>> to the patient=E2=80=99s agent. >>>>>>> 5. >>>>>>> >>>>>>> To ensure that the API Provider does not censor the client app >>>>>>> that presents the capability or solicits too much information ab= out the >>>>>>> client app or the end-user of the client app. >>>>>>> 6. >>>>>>> >>>>>>> If the API Provider decides, for any reason, to be =E2=80=9Csusp= icious=E2=80=9D >>>>>>> (as above) of the access transaction based on the information it= has, it >>>>>>> should be possible for the API Provider to warn the patient and = to accept >>>>>>> an override of the warning by the patient. This effectively mean= s that the >>>>>>> end-user will provide as much information as they think will be = necessary >>>>>>> in order to either avoid =E2=80=9Csuspicion=E2=80=9D or risk wai= ting for patient override. >>>>>>> 7. >>>>>>> >>>>>>> The policies by which the patient or the decides to grant a >>>>>>> capability to the requesting party are never shared outside of t= he >>>>>>> patient-agent trust relationship. In other words, neither the pa= tient nor >>>>>>> the agent is asked to share or explain their reason for an acces= s decision. >>>>>>> 8. >>>>>>> >>>>>>> Access requests to the agent are presumed confidential among the >>>>>>> patient, the agent, and whatever client the requesting party use= s to >>>>>>> present an access request. The API Provider does not get to see = the >>>>>>> requests and no entity in the GNAP authorization process, other = than the >>>>>>> patient or the agent, gets to correlate across requests by diffe= rent >>>>>>> requesting party clients. >>>>>>> >>>>>>> >>>>>>> Note that I am not saying all 8 requirements are in scope for GNAP >>>>>>> but I am asking for GNAP to allow for this level of privacy on the = part of >>>>>>> self-sovereign patients using self-sovereign agents and the self-so= vereign >>>>>>> licensed professionals they deal with. >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>> >>>>>>> On Fri, Mar 12, 2021 at 2:50 PM Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>> >>>>>>>> Hi Justin, >>>>>>>> >>>>>>>> Just a quick word to say I very much agree with both the >>>>>>>> observations and the framing. >>>>>>>> >>>>>>>> Fabien >>>>>>>> >>>>>>>> On Fri, Mar 12, 2021 at 6:07 PM Justin Richer >>>>>>>> wrote: >>>>>>>> >>>>>>>>> As discussed at the IETF meeting, the editors proposed that one o= f >>>>>>>>> our next big topic areas was going to be the nature of the AS rol= e within >>>>>>>>> the GNAP protocol, especially how it relates to the device-driven= use cases >>>>>>>>> that have been brought up. Apologies in advance for the long post= , but >>>>>>>>> there are a lot of parts to this discussion that I=E2=80=99m hopi= ng we can kick off >>>>>>>>> here. >>>>>>>>> >>>>>>>>> My core proposal is that we see the AS as the component that has >>>>>>>>> the following properties: >>>>>>>>> - receives delegation requests from the client instance for >>>>>>>>> access to an RS via access tokens, and for access to subject info= rmation >>>>>>>>> returned directly to the client instance >>>>>>>>> - collects consent and authorization from the RO for the >>>>>>>>> delegation >>>>>>>>> - issues access tokens that its downstream RS=E2=80=99s can inte= rpret >>>>>>>>> (and validate/accept) >>>>>>>>> - issues subject information asserted by the AS >>>>>>>>> >>>>>>>>> This framing of the parties is really important in making a >>>>>>>>> consistent understanding of how the protocol works, and a consist= ent >>>>>>>>> understanding is vital if we=E2=80=99re going to function as a wo= rking group in >>>>>>>>> both discussing the problem space and executing the solution spac= e. For a >>>>>>>>> historical example, a naive approach to adding identity on top of= a >>>>>>>>> protocol like OAuth 2 (or GNAP) is to declare that the resource s= erver is >>>>>>>>> the thing the user is logging in to. This seems reasonable at fir= st (and >>>>>>>>> some people tried doing this) but it violates all kinds of trust = boundaries >>>>>>>>> and puts new expectations on the different parties that do not ma= ke sense. >>>>>>>>> It stops looking anything like OAuth very quickly and turns into = another >>>>>>>>> protocol. If instead we say the user is logging in to the client,= things >>>>>>>>> suddenly make a lot more sense and we can do a lot more with it. = (See this >>>>>>>>> blog post from 2013 for one take on that discussion: >>>>>>>>> https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-= in-4/ >>>>>>>>> ) >>>>>>>>> >>>>>>>>> I think we=E2=80=99ve got a similar situation here when we start = to talk >>>>>>>>> about the user bringing their own AS with them. I think this is a >>>>>>>>> reasonable-seeming assumption but it=E2=80=99s based on a false p= remise that the RO >>>>>>>>> has to log into the AS to approve the request, and the AS has ful= l control >>>>>>>>> and view over everything in the network. While OAuth doesn=E2=80= =99t require this, >>>>>>>>> it=E2=80=99s largely assumed that=E2=80=99s how it works. After a= ll, all of the early OAuth >>>>>>>>> deployments worked exactly this way: the user logs in and clicks = the =E2=80=9COK=E2=80=9D >>>>>>>>> button. However, cloud deployments have shown us that it=E2=80=99= s perfectly >>>>>>>>> reasonable for an OAuth AS to take in its consent and user inform= ation from >>>>>>>>> an external trusted source, and so this model is not even accurat= e in OAuth. >>>>>>>>> >>>>>>>>> In short, I think we can do a better job here of defining things >>>>>>>>> in terms that both accept the reality we face and enable new idea= s in ways >>>>>>>>> that make sense. It=E2=80=99s my stance that the user shouldn=E2= =80=99t need to bring the >>>>>>>>> AS with them in order to have the kind of input and control of th= e system >>>>>>>>> that people are asking for. Instead, the AS should be able to tak= e inputs >>>>>>>>> from things that the user controls in order for the AS to do its = job. >>>>>>>>> >>>>>>>>> People have discussed privacy concerns with the AS knowing =E2=80= =9Ctoo >>>>>>>>> much=E2=80=9D, but in many of those discussions the knowledge is = simply pushed to >>>>>>>>> the RS instead. What I=E2=80=99m observing here is really just pu= shing portions of >>>>>>>>> the AS role into the =E2=80=9CRS=E2=80=9D deployment. This doesn= =E2=80=99t make it less of an =E2=80=9CAS=E2=80=9D >>>>>>>>> role, it=E2=80=99s just being fulfilled closely to where the RS r= ole is fulfilled. >>>>>>>>> As such, my proposal is really not that different in practice, bu= t the >>>>>>>>> labels are different and better aligned with the capabilities of = the >>>>>>>>> protocol. >>>>>>>>> >>>>>>>>> We=E2=80=99ve previously talked about separating the user-facing = portions >>>>>>>>> of the AS into another component, and I think now might be the ti= me to do >>>>>>>>> that. This is a very flammable strawman proposal, but what if we = had the AS >>>>>>>>> defined, as above, and the =E2=80=9Cconsent and authorization=E2= =80=9D gathering portion is >>>>>>>>> augmented by another named component. Here let=E2=80=99s call it = an Interaction >>>>>>>>> Component. This can take several forms based on the kind of inter= action >>>>>>>>> mode in use: >>>>>>>>> >>>>>>>>> - Hosted at a URL the user is redirected to; it can then make th= e >>>>>>>>> user log in, consent, and whatever else they need to do >>>>>>>>> - Hosted at a URL the user will load separately and enter in an >>>>>>>>> access code >>>>>>>>> - An app on the user=E2=80=99s device that the user interacts wi= th >>>>>>>>> directly and which sends information back to the AS >>>>>>>>> - An app reachable by a messaging endpoint that the AS sends and >>>>>>>>> receives structured information from >>>>>>>>> - The client itself that is given an indication as to what >>>>>>>>> information the AS needs in order to fulfill the request; this co= uld be MFA >>>>>>>>> challenge/response, user credentials, signed claims, etc. >>>>>>>>> >>>>>>>>> It=E2=80=99s the AS=E2=80=99s job to accept any and all of these = that it supports >>>>>>>>> and churn those into an access token. >>>>>>>>> >>>>>>>>> The AS itself doesn=E2=80=99t ever need to have the user log in. = The AS >>>>>>>>> doesn=E2=80=99t necessarily need to even know who the user is in = any way. The AS >>>>>>>>> just needs to know from a trusted source that the request is appr= oved. >>>>>>>>> >>>>>>>>> From a practical standpoint, I think this will have some small >>>>>>>>> changes in how we talk about the components and how we talk about= the >>>>>>>>> interaction phase of the grant negotiation process. Everything I= =E2=80=99m laying >>>>>>>>> out here is currently allowed by the spec, but I think we=E2=80= =99ve carried >>>>>>>>> through the same assumptions from OAuth 2 about deployment that a= re both >>>>>>>>> inaccurate and confusing. >>>>>>>>> >>>>>>>>> =E2=80=94 Justin >>>>>>>>> -- >>>>>>>>> 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 >>>>>>>> >>>>>>> --000000000000bbcaa205bd948b83 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Yes, a good movie to watch ;-) - they deserved their Golde= n Globe.=C2=A0
    Auditability is certainly of major importance, I agree w= e should open an issue on that topic.=C2=A0

    Fabien
    =

    On Mon, Mar 15, 2021 at 3:57 PM Adrian Gropper <agropper@healthurl.com> wrote:
    No worries, GDPR is a lot like HIPAA. It's built around the separa= tion of concerns between "controller" and "processor". = Take that separation of concerns to mean the controller and processor have = to be separate=C2=A0legal entities when designing GNAP. (OAuth obscures tha= t distinction.) The controller receives requests and holds privacy policies= but might never see the data itself in most cases. The processor has only = security to worry about. If it can avoid making any identity decisions by u= sing capabilities then it saves a lot of risk and cost. If the data being p= rocessed is encrypted, as in W3C Confidential=C2=A0Storage WG where I'm= trying to insist on GNAP as the protocol, then the processor (a W3C / DIF = Encrypted Data Vault) has even fewer legal responsibilities and lower compl= iance costs.

    I'm not against keeping the end-user ac= tor as someone in control=C2=A0of their Self Sovereign Identity. The hard p= art is that SSI does not consider delegation. The policies are assumed to b= e in the end-user's head, not their wallet. That assumption is what GNA= P now has to deal with because we've been delegated the delegation work= .

    To consider power as part of our GNAP definition= s language, we need to acknowledge the role of fiduciaires as accountable d= elegates and the audit protocols that keep them honest. Start by watching= =C2=A0= https://www.netflix.com/title/81350429

    GNAP ma= y be able to avoid introducing the role of notary before we're through = but someone will need to introduce auditability of what the AS and RS do if= they're fiduciary controllers and processors respectively. That's = what's keeping me up at night.

    Adrian

    On Mon, Mar 15, 2021 at 10:13 AM Fabien Imbault <fabien.imbault@gmail.com> = wrote:
    Thanks Adrian.=C2=A0

    I'm n= ot very familiar with HIPAA (being based in Europe) but I don't see &qu= ot;end-user" as being in opposition with ZTA. To me (s)he's=C2=A0j= ust the one using the client software, in such a way that the=C2=A0AS indee= d needs to establish sufficient confidence in who that is to make him/her g= et access. (S)he could either be the RO or not.=C2=A0

    <= div>But it's true we never define its position of power to the RO. Not = sure how we could include it.

    Fabien=C2=A0


    On Mon, Mar 15, 2021 at 2:50 PM Adrian Gropper <agropper@healthurl.com= > wrote:
    Thanks for asking, Fabien (and Justin).=C2=A0=

    I never had a problem wit= h RQ as the entity that brings claims, scope, and purpose to an AS (that is= holding a capability and policies) and gets a token.=C2=A0

    <= div>I understand=C2=A0the attraction of dealing with end-user in cases wher= e the end-user can be the RO but that changes the focus of attention and le= ads to a problem in the HIPAA use-case and other use-cases that try to prio= rotize human rights and zero-trust architecture https://docs.google.com/presentation/d/1ksKal= 62ZiApX09Nejm4RSqHzHJbgwpu_l2Ho64_ePKU/edit#slide=3Did.p .
    A bit philosophically but helpful=C2=A0as a privacy and commun= ity advocate, I have found it useful to analyze protocols in terms of power= instead of trust and have learned a lot from that invited expert role in W= 3C SSI WGs as well as capabilities=C2=A0experts like Alan Karp and Mark Mil= ler. Trust is often forced on the individual by powerful governing interest= s or just the fact that a sick person is in pain, anxious, overwhelmed, eve= n scared. Presuming trust is not much different from coercion as an exercis= e of power.=C2=A0

    SSI data models have leveled the= power playing field but GNA protocol is where the rubber meets the road in= terms of human rights and security architecture.

    = Adrian



    On Mon, Mar 15, 2021 at 7:5= 6 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks Adrian.=C2=A0
    Useful comments, thanks.=C2=A0

    &= quot;The end-user framing we are currently working with has blurred this di= stinction between the entity trusted by the RO and the entity that operates= the client at the RS. This, IMHO, needs to be fixed ASAP." What do yo= u suggest?

    Thxs
    Fabien





    On Mon, Mar 15, 2021 at 12:= 43 PM Adrian Gropper <agropper@healthurl.com> wrote:
    inline.= ..

    On Mon, Mar 15, 2021 at 6:29 AM Fabien Imbault <fabien.imbault@gmail.com> wr= ote:
    Hi Adrian,=C2=A0

    It's good to check what that = means in real use cases indeed.

    My view:
    I= tems 1-2-3-7 : seems quite usual. Only in this example, the patient is the = RO and generally delegates its decision to an automated policy engine (equi= valent to seq 1.4.4).=C2=A0
    [AG] Yes.=C2= =A0 This ability to automate under consent=C2=A0is foundational to any larg= e-scale information exchange=C2=A0or data brokerage use-case.
    <= div>
    I believe item 4 (delegation, beyond the original token issuance) = would be hard to do using JWT, at least in a generic way.=C2=A0
    =
    [AG] Whatever GNAP decides for token formats, at le= ast one of them MUST support delegation otherwise, the RO is unable to hold= a requester=C2=A0responsible. Put another way, a zero-trust architecture S= HOULD hold an individual responsible. In an SSI model, it's the individ= ual that controls their credentials and a non-repudiable signature and it&#= 39;s this individual that is present at the time the request is issued so t= hat individual can use their wallet and be subject to non-repudiation. What= happens afterward is the responsibility of this requester.=C2=A0

    [AG] The end-user framing we are currently working with has= blurred this distinction between the entity trusted by the RO and the enti= ty that operates the client at the RS. This, IMHO, needs to be fixed ASAP. = lest we break compatibility with zero-trust architecture for no good reason= .
    =C2=A0
    <= div dir=3D"ltr">
    Items 5 is probably beyond our scope, although De= nis expressed the same requirement related to "solicits too much info&= quot; (based on non opaque tokens, which might not be the general assumptio= n / I personally think token content should remain opaque to the client, bu= t knowing the type of the token would be useful).=C2=A0
    [AG] I'll take the "probably" for now. It'= ;s in everyone's interest for GNAP to build on data minimization=C2=A0a= s a principle. Nobody can keep the RS from asking for too much because, by = definition, the RS holds all the cards. If an RS asks for too much then the= request will pass the AS but fail at the RS. In cases where the RO has a c= hoice of RS, the RS will lose business and that should keep them from askin= g too much. In cases where the RO is at the mercy of the RS, the only thing= GNAP might be able to do is provide useful error messages to the various p= arties. In other words, GNAP needs to consider which errors and warnings ar= e in scope.
    =C2=A0
    Item 6 asks for a relationship between RS = and RO, which I'm not sure we'd want to assume for the general case= (although it could happen in some scenarii).
    = [AG] See my perspective on Item 5 just above. It's up to GNAP to decide= which errors and warnings need to be handled in scope. Beyond that, RSs an= d ROs will have a relationship whether GNAP likes it or not.
    =C2= =A0
    Item 8 is fine in principle, but would require attention to make sure= it's the case in practice. Depending on the sub_ids used (and even if = opaque, as soon as dereferencing is allowed), correlation might be possible= .
    [AG] In the SSI world we talk in terms of me= diators as a separate entity that is trusted by the RO to limit correlation= . GNAP should be agnostic to whether a mediator is involved. Ideally, GNAP = would note that there are two separate correlation threats. Correlation by = the requesters and correlation by the RSs. Note that I don't worry abou= t correlation by the AS because, by design, I want my agent to know everyth= ing it can and to minimize what all other participants, except the RO and R= O user agent know.

    [AG] A mediator allows the RO t= o use a pseudonym to their AS endpoint as long as the RO registers the pseu= donym with the mediator first. Keeping the RS (and AS) from correlating sep= arate end-users requires the end-user (and maybe the requester) to use a me= diator themselves. I don't see any of this being a problem for GNAP but= it might be helpful to have an informative mention of mediators in a priva= cy considerations section.

    Adrian

    Does that seem correct?
    Fabien

    On Fri, Mar 12, 2021 at 10:3= 4 PM Adrian Gropper <agropper@healthurl.com> wrote:

    Let=E2=80=99s try to map a real-worl= d use-case into the names and roles we are discussing. The use-case is docu= mented as the API Task Force Recommendations (2016) https://www.healthit.gov/sites/default/files/facas/SingleSourceofTru= th-APITFRecommendations.pdf and I=E2=80=99ve copied below the most relevan= t section. Bold highlight is in the original. I=E2=80=99ve added = bold italic because it may be important to our = discussion.=C2=A0


    <quote>

    • ONC should clarify that while API Providers may impose security related re= strictions on app access (e.g. rate limiting, encryption, and expiration of= access tokens), it is inappropriate for API providers to set limitations o= n what a patient authorized app can do with data downstream.

      • Given the nature of patient acce= ss rights, the provider is not in a legal position to prevent the registrat= ion of apps that would aggregate or share data, for example (though the pro= vider might certainly decide to warn the patient, or endeavor to educate an= d explain these issue to the patient, as part of the provider hosted app ap= proval workflow).

    • ONC should clarify that API providers are not obl= igated to protect pat= ients by identifying "suspicious" apps. API providers may suspend API = access to an app that= has breached the API provider's terms of service , or appears to have = been compromised, or if the app poses a threat to the provider's own sy= stem. However, patients must be able to override this suspensi= on (except in the cas= e where an app poses threat to the provider's own system or violates al= lowable terms of service).


    </quote>

    The key requirements from a patient rights and privacy pe= rspective are:


    1. To = delegate a scope-limited access capability to anyone anywhere without havin= g to explain or justify that to the API Provider.

    2. To allow the p= atient to automate the issue of a scope-limited access capability by delega= ting the authority to process API access requests to some agent. The API Pr= ovider has no say in who or where this agent is.

    3. The automation = of the agent is based on policies provided by the patient. The agent is abl= e to process access requests from anyone and is responsible only to the pat= ient. The agent responds to successful requests by issuing a filtered capab= ility to the requesting party.

    4. To ensure that the requesting par= ty can delegate the capability using an institutional workflow system that = they trust and the patient doesn=E2=80=99t know or care about. In many case= s, the workflow system will pass the capability to some other person, who w= e might call the end user. In other cases, the requesting party may forward= the capability directly to another person using, for example, an email. Ei= ther way, the client app used by the end-user to access the API is of no co= ncern to the patient or to the patient=E2=80=99s agent.=C2=A0

    5. To= ensure that the API Provider does not censor the client app that presents = the capability or solicits too much information about the client app or the= end-user of the client app.=C2=A0

    6. <= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-variant-ligatures:normal;font-variant-east-asian:normal;= vertical-align:baseline;white-space:pre-wrap">If the API Provider decides, = for any reason, to be =E2=80=9Csuspicious=E2=80=9D (as above) of the access= transaction based on the information it has, it should be possible for the= API Provider to warn the patient and to accept an override of the warning = by the patient. This effectively means that the end-user will provide as mu= ch information as they think will be necessary in order to either avoid =E2= =80=9Csuspicion=E2=80=9D or risk waiting for patient override.

    7. T= he policies by which the patient or the decides to grant a capability to th= e requesting party are never shared outside of the patient-agent trust rela= tionship. In other words, neither the patient nor the agent is asked to sha= re or explain their reason for an access decision.=C2=A0

      8. Access = requests to the agent are presumed confidential among the patient, the agen= t, and whatever client the requesting party uses to present an access reque= st. The API Provider does not get to see the requests and no entity in the = GNAP authorization process, other than the patient or the agent, gets to co= rrelate across requests by different requesting party clients.


    Adrian



    On Fri, Mar 12, 2021 at 2:50 PM Fabien Imbault <<= a href=3D"mailto:fabien.imbault@gmail.com" target=3D"_blank">fabien.imbault= @gmail.com> wrote:
    Hi Justin,=C2=A0

    Just a quic= k word to say I very much agree with both the observations and the framing.=

    Fabien

    =
    On Fri, Mar 12, 2021 at 6:07 PM Justi= n Richer <jricher@m= it.edu> wrote:
    As discussed at the IETF meeting, the editors proposed that one = of our next big topic areas was going to be the nature of the AS role withi= n the GNAP protocol, especially how it relates to the device-driven use cas= es that have been brought up. Apologies in advance for the long post, but t= here are a lot of parts to this discussion that I=E2=80=99m hoping we can k= ick off here.

    My core proposal is that we see the AS as = the component that has the following properties:
    =C2=A0- receives= delegation requests from the client instance for access to an RS via acces= s tokens, and for access to subject information returned directly to the cl= ient instance
    =C2=A0- collects consent and authorization from the= RO for the delegation
    =C2=A0- issues access tokens that its down= stream RS=E2=80=99s can interpret (and validate/accept)
    =C2=A0- i= ssues subject information asserted by the AS=C2=A0

    T= his framing of the parties is really important in making a consistent under= standing of how the protocol works, and a consistent understanding is vital= if we=E2=80=99re going to function as a working group in both discussing t= he problem space and executing the solution space. For a historical example= , a naive approach to adding identity on top of a protocol like OAuth 2 (or= GNAP) is to declare that the resource server is the thing the user is logg= ing in to. This seems reasonable at first (and some people tried doing this= ) but it violates all kinds of trust boundaries and puts new expectations o= n the different parties that do not make sense. It stops looking anything l= ike OAuth very quickly and turns into another protocol. If instead we say t= he user is logging in to the client, things suddenly make a lot more sense = and we can do a lot more with it. (See this blog post from 2013 for one tak= e on that discussion:=C2=A0https://www.cloudident= ity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/)

    <= div>I think we=E2=80=99ve got a similar situation here when we start to tal= k about the user bringing their own AS with them. I think this is a reasona= ble-seeming assumption but it=E2=80=99s based on a false premise that the R= O has to log into the AS to approve the request, and the AS has full contro= l and view over everything in the network. While OAuth doesn=E2=80=99t requ= ire this, it=E2=80=99s largely assumed that=E2=80=99s how it works. After a= ll, all of the early OAuth deployments worked exactly this way: the user lo= gs in and clicks the =E2=80=9COK=E2=80=9D button. However, cloud deployment= s have shown us that it=E2=80=99s perfectly reasonable for an OAuth AS to t= ake in its consent and user information from an external trusted source, an= d so this model is not even accurate in OAuth.

    In = short, I think we can do a better job here of defining things in terms that= both accept the reality we face and enable new ideas in ways that make sen= se. It=E2=80=99s my stance that the user shouldn=E2=80=99t need to bring th= e AS with them in order to have the kind of input and control of the system= that people are asking for. Instead, the AS should be able to take inputs = from things that the user controls in order for the AS to do its job.
    =

    People have discussed privacy concerns with the AS know= ing =E2=80=9Ctoo much=E2=80=9D, but in many of those discussions the knowle= dge is simply pushed to the RS instead. What I=E2=80=99m observing here is = really just pushing portions of the AS role into the =E2=80=9CRS=E2=80=9D d= eployment. This doesn=E2=80=99t make it less of an =E2=80=9CAS=E2=80=9D rol= e, it=E2=80=99s just being fulfilled closely to where the RS role is fulfil= led. As such, my proposal is really not that different in practice, but the= labels are different and better aligned with the capabilities of the proto= col.=C2=A0

    We=E2=80=99ve previously talked a= bout separating the user-facing portions of the AS into another component, = and I think now might be the time to do that. This is a very flammable stra= wman proposal, but what if we had the AS defined, as above, and the =E2=80= =9Cconsent and authorization=E2=80=9D gathering portion is augmented by ano= ther named component. Here let=E2=80=99s call it an Interaction Component. = This can take several forms based on the kind of interaction mode in use:

    =C2=A0- Hosted at a URL the user is redirected to; = it can then make the user log in, consent, and whatever else they need to d= o
    =C2=A0- Hosted at a URL the user will load separately and enter= in an access code
    =C2=A0- An app on the user=E2=80=99s device th= at the user interacts with directly and which sends information back to the= AS
    =C2=A0- An app reachable by a messaging endpoint that the AS = sends and receives structured information from
    =C2=A0- The client= itself that is given an indication as to what information the AS needs in = order to fulfill the request; this could be MFA challenge/response, user cr= edentials, signed claims, etc.

    It=E2=80=99s the AS= =E2=80=99s job to accept any and all of these that it supports and churn th= ose into an access token.=C2=A0

    The AS itself does= n=E2=80=99t ever need to have the user log in. The AS doesn=E2=80=99t neces= sarily need to even know who the user is in any way. The AS just needs to k= now from a trusted source that the request is approved.

    From a practical standpoint, I think this will have some small change= s in how we talk about the components and how we talk about the interaction= phase of the grant negotiation process. Everything I=E2=80=99m laying out = here is currently allowed by the spec, but I think we=E2=80=99ve carried th= rough the same assumptions from OAuth 2 about deployment that are both inac= curate and confusing.=C2=A0

    =C2=A0=E2=80=94 Justin=
    --
    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
    --000000000000bbcaa205bd948b83-- From nobody Mon Mar 15 12:42:19 2021 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 A45C63A0A73 for ; Mon, 15 Mar 2021 12:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 YX3bxWfapPfj for ; Mon, 15 Mar 2021 12:42:13 -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 4B4593A0A6F for ; Mon, 15 Mar 2021 12:42:13 -0700 (PDT) Received: from [192.168.1.22] (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 12FJg76w010700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 15 Mar 2021 15:42:08 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9B14AFD8-620B-455F-906E-2CD33AB14DEE" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 15 Mar 2021 15:42:07 -0400 In-Reply-To: Cc: Fabien Imbault , GNAP Mailing List To: Adrian Gropper References: <205ACFE1-7D4C-4D7C-B394-4AD8A4D4D080@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] GNAP Architecture and the role of the AS X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2021 19:42:18 -0000 --Apple-Mail=_9B14AFD8-620B-455F-906E-2CD33AB14DEE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Adrian, thanks so much for writing up this use case. I=E2=80=99ve = included some thoughts below into how different aspects of GNAP might = map to these requirements. I don=E2=80=99t think mapping any human = system to any technology is clean and dry, but for what it=E2=80=99s = worth I do see a lot of alignment. > On Mar 12, 2021, at 4:34 PM, Adrian Gropper = wrote: >=20 > Let=E2=80=99s try to map a real-world use-case into the names and = roles we are discussing. The use-case is documented as the API Task = Force Recommendations (2016) = https://www.healthit.gov/sites/default/files/facas/SingleSourceofTruth-API= TFRecommendations.pdf = and I=E2=80=99ve copied below the most relevant = section. Bold highlight is in the original. I=E2=80=99ve added bold = italic because it may be important to our discussion.=20 >=20 > > ONC should clarify that while API Providers may impose security = related restrictions on app access (e.g. rate limiting, encryption, and = expiration of access tokens), it is inappropriate for API providers to = set limitations on what a patient authorized app can do with data = downstream. > Given the nature of patient access rights, the provider is not in a = legal position to prevent the registration of apps that would aggregate = or share data, for example (though the provider might certainly decide = to warn the patient, or endeavor to educate and explain these issue to = the patient, as part of the provider hosted app approval workflow). > ONC should clarify that API providers are not obligated to protect = patients by identifying "suspicious" apps. API providers may suspend API = access to an app that has breached the API provider's terms of service , = or appears to have been compromised, or if the app poses a threat to the = provider's own system. However, patients must be able to override this = suspension (except in the case where an app poses threat to the = provider's own system or violates allowable terms of service). >=20 > >=20 > The key requirements from a patient rights and privacy perspective = are: >=20 > To delegate a scope-limited access capability to anyone anywhere = without having to explain or justify that to the API Provider. This will always be susceptible to the level of granularity that the API = Provider allows the API to be accessed in.=20 Standard APIs (which would result in standard =E2=80=9Ctype=E2=80=9D = values in the =E2=80=9Caccess=E2=80=9D request array) can help with this = by defining sufficient levels of detail. But ultimately, the user could = never ask for a scope that the API Provider isn=E2=80=99t willing to = express. > To allow the patient to automate the issue of a scope-limited access = capability by delegating the authority to process API access requests to = some agent. The API Provider has no say in who or where this agent is. This is where I think this discussion really should go. On the surface, = this seems to lead to the =E2=80=9Cbring your own AS=E2=80=9D model. I = am contending that it=E2=80=99s more powerful to have an AS (still under = the API Provider=E2=80=99s control) that allows the user to provide = additional inputs during the protocol process. As an industry, we can = standardize and innovate a lot of those inputs, but ultimately GNAP = should be able to just connect those endpoints to each other (in my = opinion). One of the common inputs is going to remain =E2=80=9Cget = someone to log in at this webpage at the AS and click a button=E2=80=9D, = but I=E2=80=99m convinced there will be others. > The automation of the agent is based on policies provided by the = patient. The agent is able to process access requests from anyone and is = responsible only to the patient. The agent responds to successful = requests by issuing a filtered capability to the requesting party. In this case, shouldn=E2=80=99t it be that the agent is separated from = the AS? Since the patient is going to have data protected by different = API Provders, to me it stands to reason that they=E2=80=99d want the = same agent acting for them on different systems. Each of those systems = would still have its own AS, but the AS would be facilitated by the = user=E2=80=99s input. Now this is NOT saying that the user would have their own AS to delegate = something to the downstream AS. Or even saying that the user would have = some kind of XACML policy server. I=E2=80=99m not sure exactly how the = bits on the wire would work but a strawman would look something like: User -> Client: go access my medical data Client -> RS: hey I want to access this medical data RS -> Client: sure go talk to this AS Client -> Agent: I need to make a request for data, how can I get the AS = in touch with you? Agent -> Client: tell them to use [some kind of magic] Client -> AS: hey I want to access this medical data; I can get the user = to interact with you or I can put you in touch with their policy agent AS -> Client: OK I=E2=80=99ll talk to the policy agent AS -> Agent: I have a request for data, I need you to prove that you = have the right to release this data Agent -> User: It looks like Client is asking for stuff at RS through = AS, that cool? Agent -> AS: OK, here you go [more magic] AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99s good for = accessing that AS Client -> RS: hey, I want to access this medical data and here=E2=80=99s = an access token for it > To ensure that the requesting party can delegate the capability using = an institutional workflow system that they trust and the patient = doesn=E2=80=99t know or care about. In many cases, the workflow system = will pass the capability to some other person, who we might call the end = user. In other cases, the requesting party may forward the capability = directly to another person using, for example, an email. Either way, the = client app used by the end-user to access the API is of no concern to = the patient or to the patient=E2=80=99s agent.=20 To facilitate this, the =E2=80=9Cagent=E2=80=9D above can be augmented = with other capabilities based on what=E2=80=99s being asked for. Adding = a line to the flow above: User -> Client: go access my medical data Client -> RS: hey I want to access this medical data RS -> Client: sure go talk to this AS Client -> Agent: I need to make a request for data, how can I get the AS = in touch with you? Agent -> Client: tell them to use [some kind of magic] Client -> AS: hey I want to access this medical data; I can get the user = to interact with you or I can put you in touch with their policy agent AS -> Client: OK I=E2=80=99ll talk to the policy agent AS -> Agent: I have a request for data, I need you to prove that you = have the right to release this data Agent -> User: It looks like Client is asking for stuff at RS through = AS, that cool? Agent -> AS: OK, here you go [more magic] AS -> RO: It looks like someone's asking for an RS you have the approval = for, that cool? AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99s good for = accessing that AS Client -> RS: hey, I want to access this medical data and here=E2=80=99s = an access token for it In other words, when the AS gets the request, it can and should take in = inputs from multiple different dimensions in order to make the = authorization decision and encode that into the access token. > To ensure that the API Provider does not censor the client app that = presents the capability or solicits too much information about the = client app or the end-user of the client app.=20 This is one of the reasons that the AS-based model is really important = in GNAP =E2=80=94 the API Provider's RS only needs to know =E2=80=9Cis = this token good for what=E2=80=99s being asked=E2=80=9D.=20 > If the API Provider decides, for any reason, to be =E2=80=9Csuspicious=E2= =80=9D (as above) of the access transaction based on the information it = has, it should be possible for the API Provider to warn the patient and = to accept an override of the warning by the patient. This effectively = means that the end-user will provide as much information as they think = will be necessary in order to either avoid =E2=80=9Csuspicion=E2=80=9D = or risk waiting for patient override. If the AS can reach out to the patient through notice and consent, they = can be brought into the process in an interactive way above. This = assumes the AS has a way of connecting that, but we should assume the AS = can provide this kind of notice and consent to parties that aren=E2=80=99t= directly involved in the protocol flow in the same way the end user is. > The policies by which the patient or the decides to grant a capability = to the requesting party are never shared outside of the patient-agent = trust relationship. In other words, neither the patient nor the agent is = asked to share or explain their reason for an access decision.=20 In the above pattern, the AS and agent would need a way to communicate = this with each other. I think the details of this are outside the scope = of GNAP but it could take the form of a query/response fulfillment = language. VC=E2=80=99s address part of this, but I think there will need = to be other aspects brought to bear here. I think you could have a = privacy-preserving protocol that would layer into GNAP here, but I = don=E2=80=99t know for sure what that would look like. > Access requests to the agent are presumed confidential among the = patient, the agent, and whatever client the requesting party uses to = present an access request. The API Provider does not get to see the = requests and no entity in the GNAP authorization process, other than the = patient or the agent, gets to correlate across requests by different = requesting party clients. This would be a different kind of model, where the client would act as = some kind of proxy in the process. Something more like: User -> Client: go access my medical data Client -> RS: hey I want to access this medical data RS -> Client: sure go talk to this AS Client -> Agent: I need to make a request for data, how can I get the AS = in touch with you? Agent -> Client: tell them to use [some kind of magic] Client -> AS: hey I want to access this medical data; I can get the user = to interact with you or I can forward your request details to the policy = agent AS -> Client: OK go talk to the policy agent, ask for these kinds of = things Client -> Agent: I have a request for data, at this AS, I need you to = prove that you have the right to release this data Agent -> User: It looks like Client is asking for stuff at RS through = AS, that cool? Agent -> Client: OK, here you go [more magic] Client -> AS: Here=E2=80=99s the result of that policy thing you asked = for [more magic] AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99s good for = accessing that AS Client -> RS: hey, I want to access this medical data and here=E2=80=99s = an access token for it >=20 > Note that I am not saying all 8 requirements are in scope for GNAP but = I am asking for GNAP to allow for this level of privacy on the part of = self-sovereign patients using self-sovereign agents and the = self-sovereign licensed professionals they deal with. For me the important part is that GNAP allow these kinds of trust = connections. Even if GNAP isn=E2=80=99t solving every piece of this = equation, it can at least clearly state =E2=80=9Cthere=E2=80=99s a = function here that needs to / is able to solve this thing=E2=80=9D and = build the important parts around it. - Justin >=20 > Adrian >=20 >=20 > On Fri, Mar 12, 2021 at 2:50 PM Fabien Imbault = > wrote: > Hi Justin,=20 >=20 > Just a quick word to say I very much agree with both the observations = and the framing. >=20 > Fabien >=20 > On Fri, Mar 12, 2021 at 6:07 PM Justin Richer > wrote: > As discussed at the IETF meeting, the editors proposed that one of our = next big topic areas was going to be the nature of the AS role within = the GNAP protocol, especially how it relates to the device-driven use = cases that have been brought up. Apologies in advance for the long post, = but there are a lot of parts to this discussion that I=E2=80=99m hoping = we can kick off here. >=20 > My core proposal is that we see the AS as the component that has the = following properties: > - receives delegation requests from the client instance for access to = an RS via access tokens, and for access to subject information returned = directly to the client instance > - collects consent and authorization from the RO for the delegation > - issues access tokens that its downstream RS=E2=80=99s can interpret = (and validate/accept) > - issues subject information asserted by the AS=20 >=20 > This framing of the parties is really important in making a consistent = understanding of how the protocol works, and a consistent understanding = is vital if we=E2=80=99re going to function as a working group in both = discussing the problem space and executing the solution space. For a = historical example, a naive approach to adding identity on top of a = protocol like OAuth 2 (or GNAP) is to declare that the resource server = is the thing the user is logging in to. This seems reasonable at first = (and some people tried doing this) but it violates all kinds of trust = boundaries and puts new expectations on the different parties that do = not make sense. It stops looking anything like OAuth very quickly and = turns into another protocol. If instead we say the user is logging in to = the client, things suddenly make a lot more sense and we can do a lot = more with it. (See this blog post from 2013 for one take on that = discussion: = https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/ = ) >=20 > I think we=E2=80=99ve got a similar situation here when we start to = talk about the user bringing their own AS with them. I think this is a = reasonable-seeming assumption but it=E2=80=99s based on a false premise = that the RO has to log into the AS to approve the request, and the AS = has full control and view over everything in the network. While OAuth = doesn=E2=80=99t require this, it=E2=80=99s largely assumed that=E2=80=99s = how it works. After all, all of the early OAuth deployments worked = exactly this way: the user logs in and clicks the =E2=80=9COK=E2=80=9D = button. However, cloud deployments have shown us that it=E2=80=99s = perfectly reasonable for an OAuth AS to take in its consent and user = information from an external trusted source, and so this model is not = even accurate in OAuth. >=20 > In short, I think we can do a better job here of defining things in = terms that both accept the reality we face and enable new ideas in ways = that make sense. It=E2=80=99s my stance that the user shouldn=E2=80=99t = need to bring the AS with them in order to have the kind of input and = control of the system that people are asking for. Instead, the AS should = be able to take inputs from things that the user controls in order for = the AS to do its job. >=20 > People have discussed privacy concerns with the AS knowing =E2=80=9Ctoo = much=E2=80=9D, but in many of those discussions the knowledge is simply = pushed to the RS instead. What I=E2=80=99m observing here is really just = pushing portions of the AS role into the =E2=80=9CRS=E2=80=9D = deployment. This doesn=E2=80=99t make it less of an =E2=80=9CAS=E2=80=9D = role, it=E2=80=99s just being fulfilled closely to where the RS role is = fulfilled. As such, my proposal is really not that different in = practice, but the labels are different and better aligned with the = capabilities of the protocol.=20 >=20 > We=E2=80=99ve previously talked about separating the user-facing = portions of the AS into another component, and I think now might be the = time to do that. This is a very flammable strawman proposal, but what if = we had the AS defined, as above, and the =E2=80=9Cconsent and = authorization=E2=80=9D gathering portion is augmented by another named = component. Here let=E2=80=99s call it an Interaction Component. This can = take several forms based on the kind of interaction mode in use: >=20 > - Hosted at a URL the user is redirected to; it can then make the = user log in, consent, and whatever else they need to do > - Hosted at a URL the user will load separately and enter in an = access code > - An app on the user=E2=80=99s device that the user interacts with = directly and which sends information back to the AS > - An app reachable by a messaging endpoint that the AS sends and = receives structured information from > - The client itself that is given an indication as to what = information the AS needs in order to fulfill the request; this could be = MFA challenge/response, user credentials, signed claims, etc. >=20 > It=E2=80=99s the AS=E2=80=99s job to accept any and all of these that = it supports and churn those into an access token.=20 >=20 > The AS itself doesn=E2=80=99t ever need to have the user log in. The = AS doesn=E2=80=99t necessarily need to even know who the user is in any = way. The AS just needs to know from a trusted source that the request is = approved. >=20 > =46rom a practical standpoint, I think this will have some small = changes in how we talk about the components and how we talk about the = interaction phase of the grant negotiation process. Everything I=E2=80=99m= laying out here is currently allowed by the spec, but I think we=E2=80=99= ve carried through the same assumptions from OAuth 2 about deployment = that are both inaccurate and confusing.=20 >=20 > =E2=80=94 Justin > --=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=_9B14AFD8-620B-455F-906E-2CD33AB14DEE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Adrian, thanks so much for writing up this use case. I=E2=80=99ve = included some thoughts below into how different aspects of GNAP might = map to these requirements. I don=E2=80=99t think mapping any human = system to any technology is clean and dry, but for what it=E2=80=99s = worth I do see a lot of alignment.

    On Mar = 12, 2021, at 4:34 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    Let=E2=80=99s try to map a real-world use-case into the names = and roles we are discussing. The use-case is documented as the API Task = Force Recommendations (2016) https://www.healthit.gov/sites/default/files/facas/SingleSource= ofTruth-APITFRecommendations.pdf = and I=E2=80=99ve copied below the most relevant section. Bold = highlight is in the original. I=E2=80=99ve added bold italic = because it may be important to our discussion. 
    <quote>

    • ONC should clarify = that while API Providers may impose security related restrictions on app = access (e.g. rate limiting, encryption, and expiration of access = tokens), it is inappropriate for API providers to set limitations on = what a patient authorized app can do with data = downstream.

      • Given the nature of = patient access rights, the provider is not in a legal position to = prevent the registration of apps that would aggregate or share data, for = example (though the provider might certainly decide to warn the patient, = or endeavor to educate and explain these issue to the patient, as part = of the provider hosted app approval workflow).
    • ONC should clarify = that API providers are not = obligated to protect = patients by identifying "suspicious" apps. API providers may = suspend API access to an app that has = breached the API provider's terms of service , or appears to have been = compromised, or if the app poses a threat to the provider's own system. = However, patients must be able to override this = suspension (except in the = case where an app poses threat to the provider's own system or violates = allowable terms of service).

    </quote>

    The= key requirements from a patient rights and privacy perspective = are:

    1. To delegate a = scope-limited access capability to anyone anywhere without having to = explain or justify that to the API = Provider.

    This will always be susceptible to the level = of granularity that the API Provider allows the API to be accessed = in. 

    Standard APIs (which would = result in standard =E2=80=9Ctype=E2=80=9D values in the =E2=80=9Caccess=E2= =80=9D request array) can help with this by defining sufficient levels = of detail. But ultimately, the user could never ask for a scope that the = API Provider isn=E2=80=99t willing to express.

    1. To allow the = patient to automate the issue of a scope-limited access capability by = delegating the authority to process API access requests to some agent. = The API Provider has no say in who or where this agent = is.

    This is where I think this discussion really = should go. On the surface, this seems to lead to the =E2=80=9Cbring your = own AS=E2=80=9D model. I am contending that it=E2=80=99s more powerful = to have an AS (still under the API Provider=E2=80=99s control) that = allows the user to provide additional inputs during the protocol = process. As an industry, we can standardize and innovate a lot of those = inputs, but ultimately GNAP should be able to just connect those = endpoints to each other (in my opinion). One of the common inputs is = going to remain =E2=80=9Cget someone to log in at this webpage at the AS = and click a button=E2=80=9D, but I=E2=80=99m convinced there will be = others.

    1. The automation of = the agent is based on policies provided by the patient. The agent is = able to process access requests from anyone and is responsible only to = the patient. The agent responds to successful requests by issuing a = filtered capability to the requesting = party.
    In this case, shouldn=E2=80=99t it be that the = agent is separated from the AS? Since the patient is going to have data = protected by different API Provders, to me it stands to reason that = they=E2=80=99d want the same agent acting for them on different systems. = Each of those systems would still have its own AS, but the AS would be = facilitated by the user=E2=80=99s input.

    Now this is NOT saying that the user would have = their own AS to delegate something to the downstream AS. Or even saying = that the user would have some kind of XACML policy server. I=E2=80=99m = not sure exactly how the bits on the wire would work but a strawman = would look something like:


    3D"https://www.websequencediagrams.com/?png=3Dmsc978356221"

    User -> Client: = go access my medical data
    Client -> RS: hey I want to = access this medical data
    RS -> Client: sure go talk to this = AS
    Client -> Agent: I need to make a request for data, how = can I get the AS in touch with you?
    Agent -> Client: tell = them to use [some kind of magic]
    Client -> AS: hey I want = to access this medical data; I can get the user to interact with you or = I can put you in touch with their policy agent
    AS -> = Client: OK I=E2=80=99ll talk to the policy agent
    AS -> = Agent: I have a request for data, I need you to prove that you have the = right to release this data
    Agent -> User: It looks like = Client is asking for stuff at RS through AS, that cool?
    Agent = -> AS: OK, here you go [more magic]
    AS -> Client: ok, = here=E2=80=99s an access token that=E2=80=99s good for accessing that = AS
    Client -> RS: hey, I want to access this medical data = and here=E2=80=99s an access token for it


    1. To ensure that the = requesting party can delegate the capability using an institutional = workflow system that they trust and the patient doesn=E2=80=99t know or = care about. In many cases, the workflow system will pass the capability = to some other person, who we might call the end user. In other cases, = the requesting party may forward the capability directly to another = person using, for example, an email. Either way, the client app used by = the end-user to access the API is of no concern to the patient or to the = patient=E2=80=99s = agent. 
    <= div>
    To facilitate this, the =E2=80=9Cagent=E2=80= =9D above can be augmented with other capabilities based on what=E2=80=99s= being asked for. Adding a line to the flow above:

    User -> Client: go access my medical = data
    Client -> RS: hey I want to access this medical = data
    RS -> Client: sure go talk to this AS
    Client = -> Agent: I need to make a request for data, how can I get the AS in = touch with you?
    Agent -> Client: tell them to use [some = kind of magic]
    Client -> AS: hey I want to access this = medical data; I can get the user to interact with you or I can put you = in touch with their policy agent
    AS -> Client: OK I=E2=80=99l= l talk to the policy agent
    AS -> Agent: I have a request = for data, I need you to prove that you have the right to release this = data
    Agent -> User: It looks like Client is asking for = stuff at RS through AS, that cool?
    Agent -> AS: OK, here = you go [more magic]
    AS -> RO: It looks like = someone's asking for an RS you have the approval for, that = cool?
    AS -> Client: ok, here=E2=80=99s an access token = that=E2=80=99s good for accessing that AS
    Client -> RS: = hey, I want to access this medical data and here=E2=80=99s an access = token for it

    In = other words, when the AS gets the request, it can and should take in = inputs from multiple different dimensions in order to make the = authorization decision and encode that into the access = token.

    1. To ensure that the = API Provider does not censor the client app that presents the capability = or solicits too much information about the client app or the end-user of = the client = app. 

    This is one of the reasons that the AS-based = model is really important in GNAP =E2=80=94 the API Provider's RS only = needs to know =E2=80=9Cis this token good for what=E2=80=99s being = asked=E2=80=9D. 

    1. If the API Provider = decides, for any reason, to be =E2=80=9Csuspicious=E2=80=9D (as above) = of the access transaction based on the information it has, it should be = possible for the API Provider to warn the patient and to accept an = override of the warning by the patient. This effectively means that the = end-user will provide as much information as they think will be = necessary in order to either avoid =E2=80=9Csuspicion=E2=80=9D or risk = waiting for patient = override.

    If the AS can reach out to the patient = through notice and consent, they can be brought into the process in an = interactive way above. This assumes the AS has a way of connecting that, = but we should assume the AS can provide this kind of notice and consent = to parties that aren=E2=80=99t directly involved in the protocol flow in = the same way the end user is.

    1. The policies by = which the patient or the decides to grant a capability to the requesting = party are never shared outside of the patient-agent trust relationship. = In other words, neither the patient nor the agent is asked to share or = explain their reason for an access = decision. 

    In the above pattern, the AS and agent = would need a way to communicate this with each other. I think the = details of this are outside the scope of GNAP but it could take the form = of a query/response fulfillment language. VC=E2=80=99s address part of = this, but I think there will need to be other aspects brought to bear = here. I think you could have a privacy-preserving protocol that would = layer into GNAP here, but I don=E2=80=99t know for sure what that would = look like.

    1. Access requests to = the agent are presumed confidential among the patient, the agent, and = whatever client the requesting party uses to present an access request. = The API Provider does not get to see the requests and no entity in the = GNAP authorization process, other than the patient or the agent, gets to = correlate across requests by different requesting party = clients.
    =
    This would be a different kind of model, where = the client would act as some kind of proxy in the process. Something = more like:

    3D"https://www.websequencediagrams.com/?png=3Dmsc685845457"

    User -> Client: = go access my medical data
    Client -> RS: hey I want to = access this medical data
    RS -> Client: sure go talk to this = AS
    Client -> Agent: I need to make a request for data, how = can I get the AS in touch with you?
    Agent -> Client: tell = them to use [some kind of magic]
    Client -> AS: hey I want = to access this medical data; I can get the user to interact with you or = I can forward your request details to the policy agent
    AS = -> Client: OK go talk to the policy agent, ask for these kinds of = things
    Client -> Agent: I have a request for data, at this = AS, I need you to prove that you have the right to release this = data
    Agent -> User: It looks like Client is asking for = stuff at RS through AS, that cool?
    Agent -> Client: OK, = here you go [more magic]
    Client -> AS: Here=E2=80=99s the = result of that policy thing you asked for [more magic]
    AS = -> Client: ok, here=E2=80=99s an access token that=E2=80=99s good for = accessing that AS
    Client -> RS: hey, I want to access this = medical data and here=E2=80=99s an access token for it



    Note that I am not saying all 8 requirements are in scope for = GNAP but I am asking for GNAP to allow for this level of privacy on the = part of self-sovereign patients using self-sovereign agents and the = self-sovereign licensed professionals they deal = with.

    For me the important part is that GNAP allow these = kinds of trust connections. Even if GNAP isn=E2=80=99t solving every = piece of this equation, it can at least clearly state =E2=80=9Cthere=E2=80= =99s a function here that needs to / is able to solve this thing=E2=80=9D = and build the important parts around it.


     - Justin


    Adrian


    On Fri, Mar 12, 2021 at 2:50 PM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Hi = Justin, 

    Just a = quick word to say I very much agree with both the observations and the = framing.

    Fabien

    On Fri, Mar = 12, 2021 at 6:07 PM Justin Richer <jricher@mit.edu> wrote:
    As discussed at the IETF = meeting, the editors proposed that one of our next big topic areas was = going to be the nature of the AS role within the GNAP protocol, = especially how it relates to the device-driven use cases that have been = brought up. Apologies in advance for the long post, but there are a lot = of parts to this discussion that I=E2=80=99m hoping we can kick off = here.

    My core = proposal is that we see the AS as the component that has the following = properties:
     - receives delegation requests = from the client instance for access to an RS via access tokens, and for = access to subject information returned directly to the client = instance
     - collects consent and authorization = from the RO for the delegation
     - issues = access tokens that its downstream RS=E2=80=99s can interpret (and = validate/accept)
     - issues subject information = asserted by the AS 

    This framing of the parties is really = important in making a consistent understanding of how the protocol = works, and a consistent understanding is vital if we=E2=80=99re going to = function as a working group in both discussing the problem space and = executing the solution space. For a historical example, a naive approach = to adding identity on top of a protocol like OAuth 2 (or GNAP) is to = declare that the resource server is the thing the user is logging in to. = This seems reasonable at first (and some people tried doing this) but it = violates all kinds of trust boundaries and puts new expectations on the = different parties that do not make sense. It stops looking anything like = OAuth very quickly and turns into another protocol. If instead we say = the user is logging in to the client, things suddenly make a lot more = sense and we can do a lot more with it. (See this blog post from 2013 = for one take on that discussion: https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sig= n-in-4/)

    I = think we=E2=80=99ve got a similar situation here when we start to talk = about the user bringing their own AS with them. I think this is a = reasonable-seeming assumption but it=E2=80=99s based on a false premise = that the RO has to log into the AS to approve the request, and the AS = has full control and view over everything in the network. While OAuth = doesn=E2=80=99t require this, it=E2=80=99s largely assumed that=E2=80=99s = how it works. After all, all of the early OAuth deployments worked = exactly this way: the user logs in and clicks the =E2=80=9COK=E2=80=9D = button. However, cloud deployments have shown us that it=E2=80=99s = perfectly reasonable for an OAuth AS to take in its consent and user = information from an external trusted source, and so this model is not = even accurate in OAuth.

    In short, I think we can do a better job here of defining = things in terms that both accept the reality we face and enable new = ideas in ways that make sense. It=E2=80=99s my stance that the user = shouldn=E2=80=99t need to bring the AS with them in order to have the = kind of input and control of the system that people are asking for. = Instead, the AS should be able to take inputs from things that the user = controls in order for the AS to do its job.

    People have discussed privacy concerns = with the AS knowing =E2=80=9Ctoo much=E2=80=9D, but in many of those = discussions the knowledge is simply pushed to the RS instead. What I=E2=80= =99m observing here is really just pushing portions of the AS role into = the =E2=80=9CRS=E2=80=9D deployment. This doesn=E2=80=99t make it less = of an =E2=80=9CAS=E2=80=9D role, it=E2=80=99s just being fulfilled = closely to where the RS role is fulfilled. As such, my proposal is = really not that different in practice, but the labels are different and = better aligned with the capabilities of the = protocol. 

    We=E2=80=99ve previously talked about separating the = user-facing portions of the AS into another component, and I think now = might be the time to do that. This is a very flammable strawman = proposal, but what if we had the AS defined, as above, and the = =E2=80=9Cconsent and authorization=E2=80=9D gathering portion is = augmented by another named component. Here let=E2=80=99s call it an = Interaction Component. This can take several forms based on the kind of = interaction mode in use:

     - Hosted at a URL the user is redirected to; it can = then make the user log in, consent, and whatever else they need to = do
     - Hosted at a URL the user will load = separately and enter in an access code
     - An = app on the user=E2=80=99s device that the user interacts with directly = and which sends information back to the AS
     - = An app reachable by a messaging endpoint that the AS sends and receives = structured information from
     - The client = itself that is given an indication as to what information the AS needs = in order to fulfill the request; this could be MFA challenge/response, = user credentials, signed claims, etc.

    It=E2=80=99s the AS=E2=80=99s job to = accept any and all of these that it supports and churn those into an = access token. 

    The AS itself doesn=E2=80=99t ever need to have the user log = in. The AS doesn=E2=80=99t necessarily need to even know who the user is = in any way. The AS just needs to know from a trusted source that the = request is approved.

    =46rom a practical standpoint, I think this will have some = small changes in how we talk about the components and how we talk about = the interaction phase of the grant negotiation process. Everything I=E2=80= =99m laying out here is currently allowed by the spec, but I think = we=E2=80=99ve carried through the same assumptions from OAuth 2 about = deployment that are both inaccurate and confusing. 

     =E2=80=94 = Justin
    --
    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=_9B14AFD8-620B-455F-906E-2CD33AB14DEE-- From nobody Mon Mar 15 18:45:50 2021 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 918B73A16C2 for ; Mon, 15 Mar 2021 18:45:47 -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 LpRJT2wOY9li for ; Mon, 15 Mar 2021 18:45:44 -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 0ED923A16A9 for ; Mon, 15 Mar 2021 18:45:42 -0700 (PDT) Received: by mail-il1-x131.google.com with SMTP id h18so11264433ils.2 for ; Mon, 15 Mar 2021 18:45:41 -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=0q/EqEbGPoP0RHDXewipQU//YuCbvllKSy3uw4WCRqM=; b=g3EoAn0vK0PuecR0aHRPE4GeQHE+EOXYQit2DzaKKZ8XyK7o9vglyuxiXPavwKgwl6 tT0jOM6TZl7KMy3i6tMwhR4LDkYlj/IA0cwYE/9ciCx4dXy46EtsBXT8CH+uAiaHdk3a Z3sBb/4pxJl1N+nONKBH+E38U1CwWNXK11LmWOJVIV8t/sIZdjsXX/zwaTIvhxTG95yI DribF4plGCP3/bzxiJgbMWE+k7xtc89dkZAnCeDKCm0vn9bl1oOztwbqPircrsZEXhaL aV3hUPbsWmQ4g+n7fR+qZ/aF6c0YXFAbW2ctgbuVjCvz9J0K+aRkzy0TaFK0rEDcrPjB 8a6w== 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=0q/EqEbGPoP0RHDXewipQU//YuCbvllKSy3uw4WCRqM=; b=koJySgt7/nPEV6tI9DF5A4OlSBK+gdxl3fszJR1ZBsTeOuh9p2SHmA/zLCkUkTTddi Y0wlr945rG/CewTVxUHkDuJWDtmrAm3HnmGIkwcxyOMJU7i+03pPWg6sPXYzkmAROOxq vSzWLZDZiKC97Gxja7KcLZ0QVkUqn6+XDUMFNGDParH0FCC5TDvDLsbcTTkCzYMQQo+r W4PKAb1AVHdN/HpsHb4ivlKT3T1xhW8Pt4mm6oeNcD9sWwVbP0TfuuiwjkVw9CVuVTOR N9UztJOblZ/xZkgZLM0r74s93JV1bUFnza2N8GktOIsNNy0+u0YhnzD3gfZpbfV3PvQV OHug== X-Gm-Message-State: AOAM533Ix6hk6qJAZHOrDbcXu11IItUbhDkEU9z3b9pj+EQTCCPeXz0j tD9xHUySkYfZo0Rabz+a2iiyY/vyfjGGY3TSKWQ= X-Google-Smtp-Source: ABdhPJw4JuW06+WRivHAlRa11R4zgj/frwrm4liffovNpS/GYnelCOrKM22tgYkBkX3g9KK+KHW914TTB2e6a70GSTs= X-Received: by 2002:a92:c6d0:: with SMTP id v16mr1756488ilm.289.1615859141249; Mon, 15 Mar 2021 18:45:41 -0700 (PDT) MIME-Version: 1.0 References: <205ACFE1-7D4C-4D7C-B394-4AD8A4D4D080@mit.edu> In-Reply-To: From: Fabien Imbault Date: Tue, 16 Mar 2021 02:45:29 +0100 Message-ID: To: Justin Richer Cc: Adrian Gropper , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000001f0e2505bd9d86d2" Archived-At: Subject: Re: [GNAP] GNAP Architecture and the role of the AS X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 01:45:48 -0000 --0000000000001f0e2505bd9d86d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Justin A few questions : - we're covering the use case "get my medical data", how does that change if that's someone else's data? - what happens if the agent can't guarantee availability? Fabien Le lun. 15 mars 2021 =C3=A0 20:42, Justin Richer a =C3=A9= crit : > Hi Adrian, thanks so much for writing up this use case. I=E2=80=99ve incl= uded some > thoughts below into how different aspects of GNAP might map to these > requirements. I don=E2=80=99t think mapping any human system to any techn= ology is > clean and dry, but for what it=E2=80=99s worth I do see a lot of alignmen= t. > > On Mar 12, 2021, at 4:34 PM, Adrian Gropper > wrote: > > Let=E2=80=99s try to map a real-world use-case into the names and roles w= e are > discussing. The use-case is documented as the API Task Force > Recommendations (2016) > https://www.healthit.gov/sites/default/files/facas/SingleSourceofTruth-AP= ITFRecommendations.pdf > and I=E2=80=99ve copied below the most relevant section. Bold highlight i= s in the > original. I=E2=80=99ve added bold italic because it may be important to o= ur > discussion. > > > > - > > ONC should clarify that while API Providers may impose security > related restrictions on app access (e.g. rate limiting, encryption, an= d > expiration of access tokens), it is inappropriate for API providers to= set > limitations on what a patient authorized app can do with data downstre= am. > - Given the nature of patient access rights, the provider is not in a > legal position to prevent the registration of apps that would aggre= gate or > share data, for example (though the provider might certainly decide= to warn > the patient, or endeavor to educate and explain these issue to the = patient, > as part of the provider hosted app approval workflow). > - ONC should clarify that API providers are not obligated to > protect patients by identifying "suspicious" apps. API providers may > suspend API access to an app that has breached the API provider's > terms of service , or appears to have been compromised, or if the app = poses > a threat to the provider's own system. However, patients must be able > to override this suspension (except in the case where an app poses > threat to the provider's own system or violates allowable terms of ser= vice). > > > > > The key requirements from a patient rights and privacy perspective are: > > > 1. To delegate a scope-limited access capability to anyone anywhere > without having to explain or justify that to the API Provider. > > > This will always be susceptible to the level of granularity that the API > Provider allows the API to be accessed in. > > Standard APIs (which would result in standard =E2=80=9Ctype=E2=80=9D valu= es in the > =E2=80=9Caccess=E2=80=9D request array) can help with this by defining su= fficient levels of > detail. But ultimately, the user could never ask for a scope that the API > Provider isn=E2=80=99t willing to express. > > > 1. To allow the patient to automate the issue of a scope-limited > access capability by delegating the authority to process API access > requests to some agent. The API Provider has no say in who or where th= is > agent is. > > > This is where I think this discussion really should go. On the surface, > this seems to lead to the =E2=80=9Cbring your own AS=E2=80=9D model. I am= contending that > it=E2=80=99s more powerful to have an AS (still under the API Provider=E2= =80=99s control) > that allows the user to provide additional inputs during the protocol > process. As an industry, we can standardize and innovate a lot of those > inputs, but ultimately GNAP should be able to just connect those endpoint= s > to each other (in my opinion). One of the common inputs is going to remai= n > =E2=80=9Cget someone to log in at this webpage at the AS and click a butt= on=E2=80=9D, but > I=E2=80=99m convinced there will be others. > > > 1. The automation of the agent is based on policies provided by the > patient. The agent is able to process access requests from anyone and = is > responsible only to the patient. The agent responds to successful requ= ests > by issuing a filtered capability to the requesting party. > > > In this case, shouldn=E2=80=99t it be that the agent is separated from th= e AS? > Since the patient is going to have data protected by different API > Provders, to me it stands to reason that they=E2=80=99d want the same age= nt acting > for them on different systems. Each of those systems would still have its > own AS, but the AS would be facilitated by the user=E2=80=99s input. > > Now this is NOT saying that the user would have their own AS to delegate > something to the downstream AS. Or even saying that the user would have > some kind of XACML policy server. I=E2=80=99m not sure exactly how the bi= ts on the > wire would work but a strawman would look something like: > > > [image: https://www.websequencediagrams.com/?png=3Dmsc978356221] > > User -> Client: go access my medical data > Client -> RS: hey I want to access this medical data > RS -> Client: sure go talk to this AS > Client -> Agent: I need to make a request for data, how can I get the AS > in touch with you? > Agent -> Client: tell them to use [some kind of magic] > Client -> AS: hey I want to access this medical data; I can get the user > to interact with you or I can put you in touch with their policy agent > AS -> Client: OK I=E2=80=99ll talk to the policy agent > AS -> Agent: I have a request for data, I need you to prove that you have > the right to release this data > Agent -> User: It looks like Client is asking for stuff at RS through AS, > that cool? > Agent -> AS: OK, here you go [more magic] > AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99s good for = accessing that AS > Client -> RS: hey, I want to access this medical data and here=E2=80=99s = an access > token for it > > > > 1. To ensure that the requesting party can delegate the capability > using an institutional workflow system that they trust and the patient > doesn=E2=80=99t know or care about. In many cases, the workflow system= will pass > the capability to some other person, who we might call the end user. I= n > other cases, the requesting party may forward the capability directly = to > another person using, for example, an email. Either way, the client ap= p > used by the end-user to access the API is of no concern to the patient= or > to the patient=E2=80=99s agent. > > > To facilitate this, the =E2=80=9Cagent=E2=80=9D above can be augmented wi= th other > capabilities based on what=E2=80=99s being asked for. Adding a line to th= e flow > above: > > User -> Client: go access my medical data > Client -> RS: hey I want to access this medical data > RS -> Client: sure go talk to this AS > Client -> Agent: I need to make a request for data, how can I get the AS > in touch with you? > Agent -> Client: tell them to use [some kind of magic] > Client -> AS: hey I want to access this medical data; I can get the user > to interact with you or I can put you in touch with their policy agent > AS -> Client: OK I=E2=80=99ll talk to the policy agent > AS -> Agent: I have a request for data, I need you to prove that you have > the right to release this data > Agent -> User: It looks like Client is asking for stuff at RS through AS, > that cool? > Agent -> AS: OK, here you go [more magic] > *AS -> RO: It looks like someone's asking for an RS you have the approval > for, that cool?* > AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99s good for = accessing that AS > Client -> RS: hey, I want to access this medical data and here=E2=80=99s = an access > token for it > > In other words, when the AS gets the request, it can and should take in > inputs from multiple different dimensions in order to make the > authorization decision and encode that into the access token. > > > 1. To ensure that the API Provider does not censor the client app that > presents the capability or solicits too much information about the cli= ent > app or the end-user of the client app. > > > This is one of the reasons that the AS-based model is really important in > GNAP =E2=80=94 the API Provider's RS only needs to know =E2=80=9Cis this = token good for > what=E2=80=99s being asked=E2=80=9D. > > > 1. If the API Provider decides, for any reason, to be =E2=80=9Csuspici= ous=E2=80=9D (as > above) of the access transaction based on the information it has, it s= hould > be possible for the API Provider to warn the patient and to accept an > override of the warning by the patient. This effectively means that th= e > end-user will provide as much information as they think will be necess= ary > in order to either avoid =E2=80=9Csuspicion=E2=80=9D or risk waiting f= or patient override. > > > If the AS can reach out to the patient through notice and consent, they > can be brought into the process in an interactive way above. This assumes > the AS has a way of connecting that, but we should assume the AS can > provide this kind of notice and consent to parties that aren=E2=80=99t di= rectly > involved in the protocol flow in the same way the end user is. > > > 1. The policies by which the patient or the decides to grant a > capability to the requesting party are never shared outside of the > patient-agent trust relationship. In other words, neither the patient = nor > the agent is asked to share or explain their reason for an access deci= sion. > > > In the above pattern, the AS and agent would need a way to communicate > this with each other. I think the details of this are outside the scope o= f > GNAP but it could take the form of a query/response fulfillment language. > VC=E2=80=99s address part of this, but I think there will need to be othe= r aspects > brought to bear here. I think you could have a privacy-preserving protoco= l > that would layer into GNAP here, but I don=E2=80=99t know for sure what t= hat would > look like. > > > 1. Access requests to the agent are presumed confidential among the > patient, the agent, and whatever client the requesting party uses to > present an access request. The API Provider does not get to see the > requests and no entity in the GNAP authorization process, other than t= he > patient or the agent, gets to correlate across requests by different > requesting party clients. > > > This would be a different kind of model, where the client would act as > some kind of proxy in the process. Something more like: > > [image: https://www.websequencediagrams.com/?png=3Dmsc685845457] > > User -> Client: go access my medical data > Client -> RS: hey I want to access this medical data > RS -> Client: sure go talk to this AS > Client -> Agent: I need to make a request for data, how can I get the AS > in touch with you? > Agent -> Client: tell them to use [some kind of magic] > Client -> AS: hey I want to access this medical data; I can get the user > to interact with you or I can forward your request details to the policy > agent > AS -> Client: OK go talk to the policy agent, ask for these kinds of thin= gs > Client -> Agent: I have a request for data, at this AS, I need you to > prove that you have the right to release this data > Agent -> User: It looks like Client is asking for stuff at RS through AS, > that cool? > Agent -> Client: OK, here you go [more magic] > Client -> AS: Here=E2=80=99s the result of that policy thing you asked fo= r [more > magic] > AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99s good for = accessing that AS > Client -> RS: hey, I want to access this medical data and here=E2=80=99s = an access > token for it > > > > Note that I am not saying all 8 requirements are in scope for GNAP but I > am asking for GNAP to allow for this level of privacy on the part of > self-sovereign patients using self-sovereign agents and the self-sovereig= n > licensed professionals they deal with. > > > For me the important part is that GNAP allow these kinds of trust > connections. Even if GNAP isn=E2=80=99t solving every piece of this equat= ion, it > can at least clearly state =E2=80=9Cthere=E2=80=99s a function here that = needs to / is able > to solve this thing=E2=80=9D and build the important parts around it. > > > - Justin > > > Adrian > > > On Fri, Mar 12, 2021 at 2:50 PM Fabien Imbault > wrote: > >> Hi Justin, >> >> Just a quick word to say I very much agree with both the observations an= d >> the framing. >> >> Fabien >> >> On Fri, Mar 12, 2021 at 6:07 PM Justin Richer wrote: >> >>> As discussed at the IETF meeting, the editors proposed that one of our >>> next big topic areas was going to be the nature of the AS role within t= he >>> GNAP protocol, especially how it relates to the device-driven use cases >>> that have been brought up. Apologies in advance for the long post, but >>> there are a lot of parts to this discussion that I=E2=80=99m hoping we = can kick off >>> here. >>> >>> My core proposal is that we see the AS as the component that has the >>> following properties: >>> - receives delegation requests from the client instance for access to >>> an RS via access tokens, and for access to subject information returned >>> directly to the client instance >>> - collects consent and authorization from the RO for the delegation >>> - issues access tokens that its downstream RS=E2=80=99s can interpret = (and >>> validate/accept) >>> - issues subject information asserted by the AS >>> >>> This framing of the parties is really important in making a consistent >>> understanding of how the protocol works, and a consistent understanding= is >>> vital if we=E2=80=99re going to function as a working group in both dis= cussing the >>> problem space and executing the solution space. For a historical exampl= e, a >>> naive approach to adding identity on top of a protocol like OAuth 2 (or >>> GNAP) is to declare that the resource server is the thing the user is >>> logging in to. This seems reasonable at first (and some people tried do= ing >>> this) but it violates all kinds of trust boundaries and puts new >>> expectations on the different parties that do not make sense. It stops >>> looking anything like OAuth very quickly and turns into another protoco= l. >>> If instead we say the user is logging in to the client, things suddenly >>> make a lot more sense and we can do a lot more with it. (See this blog = post >>> from 2013 for one take on that discussion: >>> https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/) >>> >>> I think we=E2=80=99ve got a similar situation here when we start to tal= k about >>> the user bringing their own AS with them. I think this is a >>> reasonable-seeming assumption but it=E2=80=99s based on a false premise= that the RO >>> has to log into the AS to approve the request, and the AS has full cont= rol >>> and view over everything in the network. While OAuth doesn=E2=80=99t re= quire this, >>> it=E2=80=99s largely assumed that=E2=80=99s how it works. After all, al= l of the early OAuth >>> deployments worked exactly this way: the user logs in and clicks the = =E2=80=9COK=E2=80=9D >>> button. However, cloud deployments have shown us that it=E2=80=99s perf= ectly >>> reasonable for an OAuth AS to take in its consent and user information = from >>> an external trusted source, and so this model is not even accurate in O= Auth. >>> >>> In short, I think we can do a better job here of defining things in >>> terms that both accept the reality we face and enable new ideas in ways >>> that make sense. It=E2=80=99s my stance that the user shouldn=E2=80=99t= need to bring the >>> AS with them in order to have the kind of input and control of the syst= em >>> that people are asking for. Instead, the AS should be able to take inpu= ts >>> from things that the user controls in order for the AS to do its job. >>> >>> People have discussed privacy concerns with the AS knowing =E2=80=9Ctoo= much=E2=80=9D, >>> but in many of those discussions the knowledge is simply pushed to the = RS >>> instead. What I=E2=80=99m observing here is really just pushing portion= s of the AS >>> role into the =E2=80=9CRS=E2=80=9D deployment. This doesn=E2=80=99t mak= e it less of an =E2=80=9CAS=E2=80=9D role, >>> it=E2=80=99s just being fulfilled closely to where the RS role is fulfi= lled. As >>> such, my proposal is really not that different in practice, but the lab= els >>> are different and better aligned with the capabilities of the protocol. >>> >>> We=E2=80=99ve previously talked about separating the user-facing portio= ns of the >>> AS into another component, and I think now might be the time to do that= . >>> This is a very flammable strawman proposal, but what if we had the AS >>> defined, as above, and the =E2=80=9Cconsent and authorization=E2=80=9D = gathering portion is >>> augmented by another named component. Here let=E2=80=99s call it an Int= eraction >>> Component. This can take several forms based on the kind of interaction >>> mode in use: >>> >>> - Hosted at a URL the user is redirected to; it can then make the user >>> log in, consent, and whatever else they need to do >>> - Hosted at a URL the user will load separately and enter in an access >>> code >>> - An app on the user=E2=80=99s device that the user interacts with dir= ectly and >>> which sends information back to the AS >>> - An app reachable by a messaging endpoint that the AS sends and >>> receives structured information from >>> - The client itself that is given an indication as to what information >>> the AS needs in order to fulfill the request; this could be MFA >>> challenge/response, user credentials, signed claims, etc. >>> >>> It=E2=80=99s the AS=E2=80=99s job to accept any and all of these that i= t supports and >>> churn those into an access token. >>> >>> The AS itself doesn=E2=80=99t ever need to have the user log in. The AS= doesn=E2=80=99t >>> necessarily need to even know who the user is in any way. The AS just n= eeds >>> to know from a trusted source that the request is approved. >>> >>> From a practical standpoint, I think this will have some small changes >>> in how we talk about the components and how we talk about the interacti= on >>> phase of the grant negotiation process. Everything I=E2=80=99m laying o= ut here is >>> currently allowed by the spec, but I think we=E2=80=99ve carried throug= h the same >>> assumptions from OAuth 2 about deployment that are both inaccurate and >>> confusing. >>> >>> =E2=80=94 Justin >>> -- >>> 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 >> > > --0000000000001f0e2505bd9d86d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Justin

    A few questions :
    - we're covering the use ca= se "get my medical data", how does that change if that's some= one else's data?=C2=A0
    - what happens if the age= nt can't guarantee availability?=C2=A0

    Fabien=C2=A0


    Le lun. 15 mars 2021 =C3=A0 20:42, Justi= n Richer <jricher@mit.edu> a = =C3=A9crit=C2=A0:
    Hi Adrian, thanks so much f= or writing up this use case. I=E2=80=99ve included some thoughts below into= how different aspects of GNAP might map to these requirements. I don=E2=80= =99t think mapping any human system to any technology is clean and dry, but= for what it=E2=80=99s worth I do see a lot of alignment.

    On Mar 12, 2021, at 4:34 PM, Adrian Gropper <<= a href=3D"mailto:agropper@healthurl.com" target=3D"_blank" rel=3D"noreferre= r">agropper@healthurl.com> wrote:

    Let=E2=80=99s try to map a real-world use-case into the names and roles = we are discussing. The use-case is documented as the API Task Force Recomme= ndations (2016) https://www.healthit.gov/sites/default/files/facas/SingleSo= urceofTruth-APITFRecommendations.pdf and I=E2=80=99ve copied below the mos= t relevant section. Bold highlight is in the original. I=E2=80=99= ve added bold italic because it may be importan= t to our discussion.=C2=A0

    <quote>

    • ONC should clarify that while API Providers may impose security rel= ated restrictions on app access (e.g. rate limiting, encryption, and expira= tion of access tokens), it is inappropriate for API providers to set limita= tions on what a patient authorized app can do with data downstream.<= /p>

      • Given the nature of patient access = rights, the provider is not in a legal position to prevent the registration= of apps that would aggregate or share data, for example (though the provid= er might certainly decide to warn the patient, or endeavor to educate and e= xplain these issue to the patient, as part of the provider hosted app appro= val workflow).
    • ONC should clarify that API providers are not obligated to protect patients by id= entifying "suspicious" apps. API providers may suspend API access to an app that has breach= ed the API provider's terms of service , or appears to have been compro= mised, or if the app poses a threat to the provider's own system. Howev= er, patients must be able to override this suspension (except in the case where an = app poses threat to the provider's own system or violates allowable ter= ms of service).

    </quote>

    The key requirements from a patient = rights and privacy perspective are:

    1. To delegate a scope-limited access capability to anyone anywhere = without having to explain or justify that to the API Provider.
      =

    This wi= ll always be susceptible to the level of granularity that the API Provider = allows the API to be accessed in.=C2=A0

    Standard A= PIs (which would result in standard =E2=80=9Ctype=E2=80=9D values in the = =E2=80=9Caccess=E2=80=9D request array) can help with this by defining suff= icient levels of detail. But ultimately, the user could never ask for a sco= pe that the API Provider isn=E2=80=99t willing to express.

    1. To allow the patient to automate the issue of a scope= -limited access capability by delegating the authority to process API acces= s requests to some agent. The API Provider has no say in who or where this = agent is.
    =
    This is where I think this discussion really should go. On t= he surface, this seems to lead to the =E2=80=9Cbring your own AS=E2=80=9D m= odel. I am contending that it=E2=80=99s more powerful to have an AS (still = under the API Provider=E2=80=99s control) that allows the user to provide a= dditional inputs during the protocol process. As an industry, we can standa= rdize and innovate a lot of those inputs, but ultimately GNAP should be abl= e to just connect those endpoints to each other (in my opinion). One of the= common inputs is going to remain =E2=80=9Cget someone to log in at this we= bpage at the AS and click a button=E2=80=9D, but I=E2=80=99m convinced ther= e will be others.

    =
    1. The automation of t= he agent is based on policies provided by the patient. The agent is able to= process access requests from anyone and is responsible only to the patient= . The agent responds to successful requests by issuing a filtered capabilit= y to the requesting party.
    <= /blockquote>

    In this case, shouldn=E2=80=99t it be that = the agent is separated from the AS? Since the patient is going to have data= protected by different API Provders, to me it stands to reason that they= =E2=80=99d want the same agent acting for them on different systems. Each o= f those systems would still have its own AS, but the AS would be facilitate= d by the user=E2=80=99s input.

    Now this is NOT say= ing that the user would have their own AS to delegate something to the down= stream AS. Or even saying that the user would have some kind of XACML polic= y server. I=E2=80=99m not sure exactly how the bits on the wire would work = but a strawman would look something like:


    3D"https://www.websequencediagrams.com/?png=3Dmsc978356221"

    User -> Client: go access my medical data
    Client -> RS: hey I want to access this medical data
    RS ->= Client: sure go talk to this AS
    Client -> Agent: I need to ma= ke a request for data, how can I get the AS in touch with you?
    Ag= ent -> Client: tell them to use [some kind of magic]
    Client -&= gt; AS: hey I want to access this medical data; I can get the user to inter= act with you or I can put you in touch with their policy agent
    AS= -> Client: OK I=E2=80=99ll talk to the policy agent
    AS -> = Agent: I have a request for data, I need you to prove that you have the rig= ht to release this data
    Agent -> User: It looks like Client is= asking for stuff at RS through AS, that cool?
    Agent -> AS: OK= , here you go [more magic]
    AS -> Client: ok, here=E2=80=99s an= access token that=E2=80=99s good for accessing that AS
    Client -&= gt; RS: hey, I want to access this medical data and here=E2=80=99s an acces= s token for it


    1. To ensure that the requesting party can delegate the capability u= sing an institutional workflow system that they trust and the patient doesn= =E2=80=99t know or care about. In many cases, the workflow system will pass= the capability to some other person, who we might call the end user. In ot= her cases, the requesting party may forward the capability directly to anot= her person using, for example, an email. Either way, the client app used by= the end-user to access the API is of no concern to the patient or to the p= atient=E2=80=99s agent.=C2=A0

    To facilitate this, the =E2=80=9Cagent= =E2=80=9D above can be augmented with other capabilities based on what=E2= =80=99s being asked for. Adding a line to the flow above:

    User -> Client: go access my medical data
    Client = -> RS: hey I want to access this medical data
    RS -> Client:= sure go talk to this AS
    Client -> Agent: I need to make a req= uest for data, how can I get the AS in touch with you?
    Agent ->= ; Client: tell them to use [some kind of magic]
    Client -> AS: = hey I want to access this medical data; I can get the user to interact with= you or I can put you in touch with their policy agent
    AS -> C= lient: OK I=E2=80=99ll talk to the policy agent
    AS -> Agent: I= have a request for data, I need you to prove that you have the right to re= lease this data
    Agent -> User: It looks like Client is asking = for stuff at RS through AS, that cool?
    Agent -> AS: OK, here y= ou go [more magic]
    AS -> RO: It looks like someone's as= king for an RS you have the approval for, that cool?
    AS ->= Client: ok, here=E2=80=99s an access token that=E2=80=99s good for accessi= ng that AS
    Client -> RS: hey, I want to access this medical da= ta and here=E2=80=99s an access token for it

    In ot= her words, when the AS gets the request, it can and should take in inputs f= rom multiple different dimensions in order to make the authorization decisi= on and encode that into the access token.

    1. To ensure that the API Provider does not censor the client app= that presents the capability or solicits too much information about the cl= ient app or the end-user of the client app.=C2=A0

    This is one of the r= easons that the AS-based model is really important in GNAP =E2=80=94 the AP= I Provider's RS only needs to know =E2=80=9Cis this token good for what= =E2=80=99s being asked=E2=80=9D.=C2=A0

    <= div>
      1. <= span style=3D"font-variant-ligatures:normal;font-variant-east-asian:normal;= vertical-align:baseline;white-space:pre-wrap">The policies by which the pat= ient or the decides to grant a capability to the requesting party are never= shared outside of the patient-agent trust relationship. In other words, ne= ither the patient nor the agent is asked to share or explain their reason f= or an access decision.=C2=A0

    In the above pattern, the AS and agent wo= uld need a way to communicate this with each other. I think the details of = this are outside the scope of GNAP but it could take the form of a query/re= sponse fulfillment language. VC=E2=80=99s address part of this, but I think= there will need to be other aspects brought to bear here. I think you coul= d have a privacy-preserving protocol that would layer into GNAP here, but I= don=E2=80=99t know for sure what that would look like.

    1. Access requests to the agent are presumed confidential a= mong the patient, the agent, and whatever client the requesting party uses = to present an access request. The API Provider does not get to see the requ= ests and no entity in the GNAP authorization process, other than the patien= t or the agent, gets to correlate across requests by different requesting p= arty clients.
    <= div>
    This would be a different kind of model, where the clien= t would act as some kind of proxy in the process. Something more like:

    3D"https://www.websequencediagrams.com/?png=3Dmsc68584=

    User -> Client: go access my medica= l data
    Client -> RS: hey I want to access this medical data
    RS -> Client: sure go talk to this AS
    Client -> Age= nt: I need to make a request for data, how can I get the AS in touch with y= ou?
    Agent -> Client: tell them to use [some kind of magic]
    Client -> AS: hey I want to access this medical data; I can get t= he user to interact with you or I can forward your request details to the p= olicy agent
    AS -> Client: OK go talk to the policy agent, ask = for these kinds of things
    Client -> Agent: I have a request fo= r data, at this AS, I need you to prove that you have the right to release = this data
    Agent -> User: It looks like Client is asking for st= uff at RS through AS, that cool?
    Agent -> Client: OK, here you= go [more magic]
    Client -> AS: Here=E2=80=99s the result of th= at policy thing you asked for [more magic]
    AS -> Client: ok, h= ere=E2=80=99s an access token that=E2=80=99s good for accessing that AS
    Client -> RS: hey, I want to access this medical data and here=E2= =80=99s an access token for it



    Note that I am not saying all 8 requirements a= re in scope for GNAP but I am asking for GNAP to allow for this level of pr= ivacy on the part of self-sovereign patients using self-sovereign agents an= d the self-sovereign licensed professionals they deal with.

    For me the important= part is that GNAP allow these kinds of trust connections. Even if GNAP isn= =E2=80=99t solving every piece of this equation, it can at least clearly st= ate =E2=80=9Cthere=E2=80=99s a function here that needs to / is able to sol= ve this thing=E2=80=9D and build the important parts around it.
    <= br>

    =C2=A0- Justin


    Adrian


    On Fri, Mar 12, 20= 21 at 2:50 PM Fabien Imbault <fabien.imbault@gmail.com> wro= te:
    Hi Justin,=C2=A0

    Just a quick word to say I very much agree with both the observatio= ns and the framing.

    Fabien

    On Fri, Mar 12, 20= 21 at 6:07 PM Justin Richer <jricher@mit.edu> wrote:
    As discussed at the IETF meeting, the editors proposed th= at one of our next big topic areas was going to be the nature of the AS rol= e within the GNAP protocol, especially how it relates to the device-driven = use cases that have been brought up. Apologies in advance for the long post= , but there are a lot of parts to this discussion that I=E2=80=99m hoping w= e can kick off here.

    My core proposal is that we see the= AS as the component that has the following properties:
    =C2=A0- r= eceives delegation requests from the client instance for access to an RS vi= a access tokens, and for access to subject information returned directly to= the client instance
    =C2=A0- collects consent and authorization f= rom the RO for the delegation
    =C2=A0- issues access tokens that i= ts downstream RS=E2=80=99s can interpret (and validate/accept)
    = =C2=A0- issues subject information asserted by the AS=C2=A0

    This framing of the parties is really important in making a consist= ent understanding of how the protocol works, and a consistent understanding= is vital if we=E2=80=99re going to function as a working group in both dis= cussing the problem space and executing the solution space. For a historica= l example, a naive approach to adding identity on top of a protocol like OA= uth 2 (or GNAP) is to declare that the resource server is the thing the use= r is logging in to. This seems reasonable at first (and some people tried d= oing this) but it violates all kinds of trust boundaries and puts new expec= tations on the different parties that do not make sense. It stops looking a= nything like OAuth very quickly and turns into another protocol. If instead= we say the user is logging in to the client, things suddenly make a lot mo= re sense and we can do a lot more with it. (See this blog post from 2013 fo= r one take on that discussion:=C2=A0https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4= /)

    I think we=E2=80=99ve got a similar situati= on here when we start to talk about the user bringing their own AS with the= m. I think this is a reasonable-seeming assumption but it=E2=80=99s based o= n a false premise that the RO has to log into the AS to approve the request= , and the AS has full control and view over everything in the network. Whil= e OAuth doesn=E2=80=99t require this, it=E2=80=99s largely assumed that=E2= =80=99s how it works. After all, all of the early OAuth deployments worked = exactly this way: the user logs in and clicks the =E2=80=9COK=E2=80=9D butt= on. However, cloud deployments have shown us that it=E2=80=99s perfectly re= asonable for an OAuth AS to take in its consent and user information from a= n external trusted source, and so this model is not even accurate in OAuth.=

    In short, I think we can do a better job here of = defining things in terms that both accept the reality we face and enable ne= w ideas in ways that make sense. It=E2=80=99s my stance that the user shoul= dn=E2=80=99t need to bring the AS with them in order to have the kind of in= put and control of the system that people are asking for. Instead, the AS s= hould be able to take inputs from things that the user controls in order fo= r the AS to do its job.

    People have discussed priv= acy concerns with the AS knowing =E2=80=9Ctoo much=E2=80=9D, but in many of= those discussions the knowledge is simply pushed to the RS instead. What I= =E2=80=99m observing here is really just pushing portions of the AS role in= to the =E2=80=9CRS=E2=80=9D deployment. This doesn=E2=80=99t make it less o= f an =E2=80=9CAS=E2=80=9D role, it=E2=80=99s just being fulfilled closely t= o where the RS role is fulfilled. As such, my proposal is really not that d= ifferent in practice, but the labels are different and better aligned with = the capabilities of the protocol.=C2=A0

    We= =E2=80=99ve previously talked about separating the user-facing portions of = the AS into another component, and I think now might be the time to do that= . This is a very flammable strawman proposal, but what if we had the AS def= ined, as above, and the =E2=80=9Cconsent and authorization=E2=80=9D gatheri= ng portion is augmented by another named component. Here let=E2=80=99s call= it an Interaction Component. This can take several forms based on the kind= of interaction mode in use:

    =C2=A0- Hosted at a U= RL the user is redirected to; it can then make the user log in, consent, an= d whatever else they need to do
    =C2=A0- Hosted at a URL the user = will load separately and enter in an access code
    =C2=A0- An app o= n the user=E2=80=99s device that the user interacts with directly and which= sends information back to the AS
    =C2=A0- An app reachable by a m= essaging endpoint that the AS sends and receives structured information fro= m
    =C2=A0- The client itself that is given an indication as to wha= t information the AS needs in order to fulfill the request; this could be M= FA challenge/response, user credentials, signed claims, etc.

    =
    It=E2=80=99s the AS=E2=80=99s job to accept any and all of these= that it supports and churn those into an access token.=C2=A0
    The AS itself doesn=E2=80=99t ever need to have the user log in= . The AS doesn=E2=80=99t necessarily need to even know who the user is in a= ny way. The AS just needs to know from a trusted source that the request is= approved.

    From a practical standpoint, I think th= is will have some small changes in how we talk about the components and how= we talk about the interaction phase of the grant negotiation process. Ever= ything I=E2=80=99m laying out here is currently allowed by the spec, but I = think we=E2=80=99ve carried through the same assumptions from OAuth 2 about= deployment that are both inaccurate and confusing.=C2=A0

    =C2=A0=E2=80=94 Justin
    --
    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>

    --0000000000001f0e2505bd9d86d2-- From nobody Mon Mar 15 19:12:41 2021 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 450743A176F for ; Mon, 15 Mar 2021 19:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 o4XWc81TPbrk for ; Mon, 15 Mar 2021 19:12:35 -0700 (PDT) Received: from mail-vk1-f175.google.com (mail-vk1-f175.google.com [209.85.221.175]) (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 328D73A1767 for ; Mon, 15 Mar 2021 19:12:34 -0700 (PDT) Received: by mail-vk1-f175.google.com with SMTP id 11so3275678vkx.6 for ; Mon, 15 Mar 2021 19:12:34 -0700 (PDT) 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=yUORlb0U+34GdEuzEO/qOCNZI8P4hkO7u9qKujqA6FM=; b=T2sEWXzDEuR8haTg3GJzsgo6bZACTtqcSEdYOLM2HjoRRuoN0V+wsWTlEJYkITl7I4 zX2aGK+7R7ArYFlzhgHQtPTjk1oabdVirvtvnkYvIrk58ArhX0M49DX/jnLFvP6p+zeg NfPFlbUqNgmU8vNl6Quo5MJ+Sdgg52qkHtHS5Xx9GoxyVcwOuDol4s4rFhVvZTgtWCog TAEX7yIiiVR8s9xp2R/99eADrIzUIRs21ZYtDPUnDQo8AGYbYAtI8N8yjIE9ipKEBnNx FtwEj3Wx8ZGiSUWvTPgejUcOdzoI9mcV/krRRQqlgxPnpduATMKGfS98F9n5b41r+wi5 PlMQ== X-Gm-Message-State: AOAM533gOka/3GaH+X8ZUDHA/0tTWv4UNyFQUsH4i6ki5XHMkPCQakRG /Xe2+7jEaHqjhspX/7GPfmf1/LXXQF8kw7v37nw= X-Google-Smtp-Source: ABdhPJwHUftf+212z9B5BBskgFDXUjjHdoDp6m+g/bZVjDs+Cw+J5Vw2gUPaM9/recj407/2kxBbbcnzZpTMWt73y9E= X-Received: by 2002:a1f:9895:: with SMTP id a143mr15231269vke.20.1615860753602; Mon, 15 Mar 2021 19:12:33 -0700 (PDT) MIME-Version: 1.0 References: <205ACFE1-7D4C-4D7C-B394-4AD8A4D4D080@mit.edu> In-Reply-To: From: Adrian Gropper Date: Mon, 15 Mar 2021 22:12:21 -0400 Message-ID: To: Fabien Imbault Cc: Justin Richer , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000399d1d05bd9de69d" Archived-At: Subject: Re: [GNAP] GNAP Architecture and the role of the AS X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 02:12:39 -0000 --000000000000399d1d05bd9de69d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Justin, I have exactly the same two questions as Fabien and also, I On Mon, Mar 15, 2021 at 9:45 PM Fabien Imbault wrote: > Hi Justin > > A few questions : > - we're covering the use case "get my medical data", how does that change > if that's someone else's data? > - what happens if the agent can't guarantee availability? > > Fabien > > > Le lun. 15 mars 2021 =C3=A0 20:42, Justin Richer a =C3= =A9crit : > >> Hi Adrian, thanks so much for writing up this use case. I=E2=80=99ve inc= luded >> some thoughts below into how different aspects of GNAP might map to thes= e >> requirements. I don=E2=80=99t think mapping any human system to any tech= nology is >> clean and dry, but for what it=E2=80=99s worth I do see a lot of alignme= nt. >> >> On Mar 12, 2021, at 4:34 PM, Adrian Gropper >> wrote: >> >> Let=E2=80=99s try to map a real-world use-case into the names and roles = we are >> discussing. The use-case is documented as the API Task Force >> Recommendations (2016) >> https://www.healthit.gov/sites/default/files/facas/SingleSourceofTruth-A= PITFRecommendations.pdf >> and I=E2=80=99ve copied below the most relevant section. Bold highlight = is in >> the original. I=E2=80=99ve added bold italic because it may be important= to our >> discussion. >> >> >> >> - >> >> ONC should clarify that while API Providers may impose security >> related restrictions on app access (e.g. rate limiting, encryption, a= nd >> expiration of access tokens), it is inappropriate for API providers t= o set >> limitations on what a patient authorized app can do with data downstr= eam. >> - Given the nature of patient access rights, the provider is not in a >> legal position to prevent the registration of apps that would aggr= egate or >> share data, for example (though the provider might certainly decid= e to warn >> the patient, or endeavor to educate and explain these issue to the= patient, >> as part of the provider hosted app approval workflow). >> - ONC should clarify that API providers are not obligated to >> protect patients by identifying "suspicious" apps. API providers may >> suspend API access to an app that has breached the API provider's >> terms of service , or appears to have been compromised, or if the app= poses >> a threat to the provider's own system. However, patients must be able >> to override this suspension (except in the case where an app poses >> threat to the provider's own system or violates allowable terms of se= rvice). >> >> >> >> >> The key requirements from a patient rights and privacy perspective are: >> >> >> 1. To delegate a scope-limited access capability to anyone anywhere >> without having to explain or justify that to the API Provider. >> >> >> This will always be susceptible to the level of granularity that the API >> Provider allows the API to be accessed in. >> >> Standard APIs (which would result in standard =E2=80=9Ctype=E2=80=9D val= ues in the >> =E2=80=9Caccess=E2=80=9D request array) can help with this by defining s= ufficient levels of >> detail. But ultimately, the user could never ask for a scope that the AP= I >> Provider isn=E2=80=99t willing to express. >> >> >> 1. To allow the patient to automate the issue of a scope-limited >> access capability by delegating the authority to process API access >> requests to some agent. The API Provider has no say in who or where t= his >> agent is. >> >> >> This is where I think this discussion really should go. On the surface, >> this seems to lead to the =E2=80=9Cbring your own AS=E2=80=9D model. I a= m contending that >> it=E2=80=99s more powerful to have an AS (still under the API Provider= =E2=80=99s control) >> that allows the user to provide additional inputs during the protocol >> process. As an industry, we can standardize and innovate a lot of those >> inputs, but ultimately GNAP should be able to just connect those endpoin= ts >> to each other (in my opinion). One of the common inputs is going to rema= in >> =E2=80=9Cget someone to log in at this webpage at the AS and click a but= ton=E2=80=9D, but >> I=E2=80=99m convinced there will be others. >> >> >> 1. The automation of the agent is based on policies provided by the >> patient. The agent is able to process access requests from anyone and= is >> responsible only to the patient. The agent responds to successful req= uests >> by issuing a filtered capability to the requesting party. >> >> >> In this case, shouldn=E2=80=99t it be that the agent is separated from t= he AS? >> Since the patient is going to have data protected by different API >> Provders, to me it stands to reason that they=E2=80=99d want the same ag= ent acting >> for them on different systems. Each of those systems would still have it= s >> own AS, but the AS would be facilitated by the user=E2=80=99s input. >> >> Now this is NOT saying that the user would have their own AS to delegate >> something to the downstream AS. Or even saying that the user would have >> some kind of XACML policy server. I=E2=80=99m not sure exactly how the b= its on the >> wire would work but a strawman would look something like: >> >> >> [image: https://www.websequencediagrams.com/?png=3Dmsc978356221] >> >> User -> Client: go access my medical data >> Client -> RS: hey I want to access this medical data >> RS -> Client: sure go talk to this AS >> Client -> Agent: I need to make a request for data, how can I get the AS >> in touch with you? >> Agent -> Client: tell them to use [some kind of magic] >> Client -> AS: hey I want to access this medical data; I can get the user >> to interact with you or I can put you in touch with their policy agent >> AS -> Client: OK I=E2=80=99ll talk to the policy agent >> AS -> Agent: I have a request for data, I need you to prove that you hav= e >> the right to release this data >> Agent -> User: It looks like Client is asking for stuff at RS through AS= , >> that cool? >> Agent -> AS: OK, here you go [more magic] >> AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99s good for= accessing that AS >> Client -> RS: hey, I want to access this medical data and here=E2=80=99s= an >> access token for it >> >> >> >> 1. To ensure that the requesting party can delegate the capability >> using an institutional workflow system that they trust and the patien= t >> doesn=E2=80=99t know or care about. In many cases, the workflow syste= m will pass >> the capability to some other person, who we might call the end user. = In >> other cases, the requesting party may forward the capability directly= to >> another person using, for example, an email. Either way, the client a= pp >> used by the end-user to access the API is of no concern to the patien= t or >> to the patient=E2=80=99s agent. >> >> >> To facilitate this, the =E2=80=9Cagent=E2=80=9D above can be augmented w= ith other >> capabilities based on what=E2=80=99s being asked for. Adding a line to t= he flow >> above: >> >> User -> Client: go access my medical data >> Client -> RS: hey I want to access this medical data >> RS -> Client: sure go talk to this AS >> Client -> Agent: I need to make a request for data, how can I get the AS >> in touch with you? >> Agent -> Client: tell them to use [some kind of magic] >> Client -> AS: hey I want to access this medical data; I can get the user >> to interact with you or I can put you in touch with their policy agent >> AS -> Client: OK I=E2=80=99ll talk to the policy agent >> AS -> Agent: I have a request for data, I need you to prove that you hav= e >> the right to release this data >> Agent -> User: It looks like Client is asking for stuff at RS through AS= , >> that cool? >> Agent -> AS: OK, here you go [more magic] >> *AS -> RO: It looks like someone's asking for an RS you have the approva= l >> for, that cool?* >> AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99s good for= accessing that AS >> Client -> RS: hey, I want to access this medical data and here=E2=80=99s= an >> access token for it >> >> In other words, when the AS gets the request, it can and should take in >> inputs from multiple different dimensions in order to make the >> authorization decision and encode that into the access token. >> >> >> 1. To ensure that the API Provider does not censor the client app >> that presents the capability or solicits too much information about t= he >> client app or the end-user of the client app. >> >> >> This is one of the reasons that the AS-based model is really important i= n >> GNAP =E2=80=94 the API Provider's RS only needs to know =E2=80=9Cis this= token good for >> what=E2=80=99s being asked=E2=80=9D. >> >> >> 1. If the API Provider decides, for any reason, to be =E2=80=9Csuspic= ious=E2=80=9D >> (as above) of the access transaction based on the information it has,= it >> should be possible for the API Provider to warn the patient and to ac= cept >> an override of the warning by the patient. This effectively means tha= t the >> end-user will provide as much information as they think will be neces= sary >> in order to either avoid =E2=80=9Csuspicion=E2=80=9D or risk waiting = for patient override. >> >> >> If the AS can reach out to the patient through notice and consent, they >> can be brought into the process in an interactive way above. This assume= s >> the AS has a way of connecting that, but we should assume the AS can >> provide this kind of notice and consent to parties that aren=E2=80=99t d= irectly >> involved in the protocol flow in the same way the end user is. >> >> >> 1. The policies by which the patient or the decides to grant a >> capability to the requesting party are never shared outside of the >> patient-agent trust relationship. In other words, neither the patient= nor >> the agent is asked to share or explain their reason for an access dec= ision. >> >> >> In the above pattern, the AS and agent would need a way to communicate >> this with each other. I think the details of this are outside the scope = of >> GNAP but it could take the form of a query/response fulfillment language= . >> VC=E2=80=99s address part of this, but I think there will need to be oth= er aspects >> brought to bear here. I think you could have a privacy-preserving protoc= ol >> that would layer into GNAP here, but I don=E2=80=99t know for sure what = that would >> look like. >> >> >> 1. Access requests to the agent are presumed confidential among the >> patient, the agent, and whatever client the requesting party uses to >> present an access request. The API Provider does not get to see the >> requests and no entity in the GNAP authorization process, other than = the >> patient or the agent, gets to correlate across requests by different >> requesting party clients. >> >> >> This would be a different kind of model, where the client would act as >> some kind of proxy in the process. Something more like: >> >> [image: https://www.websequencediagrams.com/?png=3Dmsc685845457] >> >> User -> Client: go access my medical data >> Client -> RS: hey I want to access this medical data >> RS -> Client: sure go talk to this AS >> Client -> Agent: I need to make a request for data, how can I get the AS >> in touch with you? >> Agent -> Client: tell them to use [some kind of magic] >> Client -> AS: hey I want to access this medical data; I can get the user >> to interact with you or I can forward your request details to the policy >> agent >> AS -> Client: OK go talk to the policy agent, ask for these kinds of >> things >> Client -> Agent: I have a request for data, at this AS, I need you to >> prove that you have the right to release this data >> Agent -> User: It looks like Client is asking for stuff at RS through AS= , >> that cool? >> Agent -> Client: OK, here you go [more magic] >> Client -> AS: Here=E2=80=99s the result of that policy thing you asked f= or [more >> magic] >> AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99s good for= accessing that AS >> Client -> RS: hey, I want to access this medical data and here=E2=80=99s= an >> access token for it >> >> >> >> Note that I am not saying all 8 requirements are in scope for GNAP but I >> am asking for GNAP to allow for this level of privacy on the part of >> self-sovereign patients using self-sovereign agents and the self-soverei= gn >> licensed professionals they deal with. >> >> >> For me the important part is that GNAP allow these kinds of trust >> connections. Even if GNAP isn=E2=80=99t solving every piece of this equa= tion, it >> can at least clearly state =E2=80=9Cthere=E2=80=99s a function here that= needs to / is able >> to solve this thing=E2=80=9D and build the important parts around it. >> >> >> - Justin >> >> >> Adrian >> >> >> On Fri, Mar 12, 2021 at 2:50 PM Fabien Imbault >> wrote: >> >>> Hi Justin, >>> >>> Just a quick word to say I very much agree with both the observations >>> and the framing. >>> >>> Fabien >>> >>> On Fri, Mar 12, 2021 at 6:07 PM Justin Richer wrote: >>> >>>> As discussed at the IETF meeting, the editors proposed that one of our >>>> next big topic areas was going to be the nature of the AS role within = the >>>> GNAP protocol, especially how it relates to the device-driven use case= s >>>> that have been brought up. Apologies in advance for the long post, but >>>> there are a lot of parts to this discussion that I=E2=80=99m hoping we= can kick off >>>> here. >>>> >>>> My core proposal is that we see the AS as the component that has the >>>> following properties: >>>> - receives delegation requests from the client instance for access to >>>> an RS via access tokens, and for access to subject information returne= d >>>> directly to the client instance >>>> - collects consent and authorization from the RO for the delegation >>>> - issues access tokens that its downstream RS=E2=80=99s can interpret= (and >>>> validate/accept) >>>> - issues subject information asserted by the AS >>>> >>>> This framing of the parties is really important in making a consistent >>>> understanding of how the protocol works, and a consistent understandin= g is >>>> vital if we=E2=80=99re going to function as a working group in both di= scussing the >>>> problem space and executing the solution space. For a historical examp= le, a >>>> naive approach to adding identity on top of a protocol like OAuth 2 (o= r >>>> GNAP) is to declare that the resource server is the thing the user is >>>> logging in to. This seems reasonable at first (and some people tried d= oing >>>> this) but it violates all kinds of trust boundaries and puts new >>>> expectations on the different parties that do not make sense. It stops >>>> looking anything like OAuth very quickly and turns into another protoc= ol. >>>> If instead we say the user is logging in to the client, things suddenl= y >>>> make a lot more sense and we can do a lot more with it. (See this blog= post >>>> from 2013 for one take on that discussion: >>>> https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/= ) >>>> >>>> I think we=E2=80=99ve got a similar situation here when we start to ta= lk about >>>> the user bringing their own AS with them. I think this is a >>>> reasonable-seeming assumption but it=E2=80=99s based on a false premis= e that the RO >>>> has to log into the AS to approve the request, and the AS has full con= trol >>>> and view over everything in the network. While OAuth doesn=E2=80=99t r= equire this, >>>> it=E2=80=99s largely assumed that=E2=80=99s how it works. After all, a= ll of the early OAuth >>>> deployments worked exactly this way: the user logs in and clicks the = =E2=80=9COK=E2=80=9D >>>> button. However, cloud deployments have shown us that it=E2=80=99s per= fectly >>>> reasonable for an OAuth AS to take in its consent and user information= from >>>> an external trusted source, and so this model is not even accurate in = OAuth. >>>> >>>> In short, I think we can do a better job here of defining things in >>>> terms that both accept the reality we face and enable new ideas in way= s >>>> that make sense. It=E2=80=99s my stance that the user shouldn=E2=80=99= t need to bring the >>>> AS with them in order to have the kind of input and control of the sys= tem >>>> that people are asking for. Instead, the AS should be able to take inp= uts >>>> from things that the user controls in order for the AS to do its job. >>>> >>>> People have discussed privacy concerns with the AS knowing =E2=80=9Cto= o much=E2=80=9D, >>>> but in many of those discussions the knowledge is simply pushed to the= RS >>>> instead. What I=E2=80=99m observing here is really just pushing portio= ns of the AS >>>> role into the =E2=80=9CRS=E2=80=9D deployment. This doesn=E2=80=99t ma= ke it less of an =E2=80=9CAS=E2=80=9D role, >>>> it=E2=80=99s just being fulfilled closely to where the RS role is fulf= illed. As >>>> such, my proposal is really not that different in practice, but the la= bels >>>> are different and better aligned with the capabilities of the protocol= . >>>> >>>> We=E2=80=99ve previously talked about separating the user-facing porti= ons of >>>> the AS into another component, and I think now might be the time to do >>>> that. This is a very flammable strawman proposal, but what if we had t= he AS >>>> defined, as above, and the =E2=80=9Cconsent and authorization=E2=80=9D= gathering portion is >>>> augmented by another named component. Here let=E2=80=99s call it an In= teraction >>>> Component. This can take several forms based on the kind of interactio= n >>>> mode in use: >>>> >>>> - Hosted at a URL the user is redirected to; it can then make the use= r >>>> log in, consent, and whatever else they need to do >>>> - Hosted at a URL the user will load separately and enter in an acces= s >>>> code >>>> - An app on the user=E2=80=99s device that the user interacts with di= rectly >>>> and which sends information back to the AS >>>> - An app reachable by a messaging endpoint that the AS sends and >>>> receives structured information from >>>> - The client itself that is given an indication as to what informatio= n >>>> the AS needs in order to fulfill the request; this could be MFA >>>> challenge/response, user credentials, signed claims, etc. >>>> >>>> It=E2=80=99s the AS=E2=80=99s job to accept any and all of these that = it supports and >>>> churn those into an access token. >>>> >>>> The AS itself doesn=E2=80=99t ever need to have the user log in. The A= S doesn=E2=80=99t >>>> necessarily need to even know who the user is in any way. The AS just = needs >>>> to know from a trusted source that the request is approved. >>>> >>>> From a practical standpoint, I think this will have some small changes >>>> in how we talk about the components and how we talk about the interact= ion >>>> phase of the grant negotiation process. Everything I=E2=80=99m laying = out here is >>>> currently allowed by the spec, but I think we=E2=80=99ve carried throu= gh the same >>>> assumptions from OAuth 2 about deployment that are both inaccurate and >>>> confusing. >>>> >>>> =E2=80=94 Justin >>>> -- >>>> 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 > --000000000000399d1d05bd9de69d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Justin,

    I have exactly the same two = questions as Fabien and also, I=C2=A0

    On Mon, Mar 15, 2021 at 9:45 PM = Fabien Imbault <fabien.imbau= lt@gmail.com> wrote:
    Hi Justin

    A few questions :<= /div>
    - we're covering the use case "get my medic= al data", how does that change if that's someone else's data?= =C2=A0
    - what happens if the agent can't guarant= ee availability?=C2=A0

    F= abien=C2=A0


    Le lun. 15 mars 2021 =C3=A0 20:42, Justin Richer <jricher@mit.edu> a = =C3=A9crit=C2=A0:
    Hi Adrian, thanks so much for writing up = this use case. I=E2=80=99ve included some thoughts below into how different= aspects of GNAP might map to these requirements. I don=E2=80=99t think map= ping any human system to any technology is clean and dry, but for what it= =E2=80=99s worth I do see a lot of alignment.

    On Mar 12, 2021, at 4:34 PM, Adrian Gropper <agropper= @healthurl.com> wrote:

    Let=E2=80=99s try to map a real-world use-case into the= names and roles we are discussing. The use-case is documented as the API T= ask Force Recommendations (2016) https://www.healthit.gov/sites/default/fil= es/facas/SingleSourceofTruth-APITFRecommendations.pdf and I=E2=80=99ve cop= ied below the most relevant section. Bold highlight is in the ori= ginal. I=E2=80=99ve added bold italic= because i= t may be important to our discussion.=C2=A0

    <quote>

    • ONC should clarify that while API Providers may im= pose security related restrictions on app access (e.g. rate limiting, encry= ption, and expiration of access tokens), it is inappropriate for API provid= ers to set limitations on what a patient authorized app can do with data do= wnstream.

        • Given the nature o= f patient access rights, the provider is not in a legal position to prevent= the registration of apps that would aggregate or share data, for example (= though the provider might certainly decide to warn the patient, or endeavor= to educate and explain these issue to the patient, as part of the provider= hosted app approval workflow).
    • =
      ONC should clarify that API providers = are n= ot obligated to prote= ct patients by identifying "suspicious" apps. API providers may suspen= d API access to an ap= p that has breached the API provider's terms of service , or appears to= have been compromised, or if the app poses a threat to the provider's = own system. However, patients must be able to override this su= spension (except in t= he case where an app poses threat to the provider's own system or viola= tes allowable terms of service).

    </quote>
    The key requirement= s from a patient rights and privacy perspective are:

    1. To delegate a scope-limited access capability to= anyone anywhere without having to explain or justify that to the API Provi= der.

    <= /div>
    This will always be susceptible to the level of granularity that = the API Provider allows the API to be accessed in.=C2=A0

    Standard APIs (which would result in standard =E2=80=9Ctype=E2=80=9D= values in the =E2=80=9Caccess=E2=80=9D request array) can help with this b= y defining sufficient levels of detail. But ultimately, the user could neve= r ask for a scope that the API Provider isn=E2=80=99t willing to express.
    1. =
      To allow the patient to automate the i= ssue of a scope-limited access capability by delegating the authority to pr= ocess API access requests to some agent. The API Provider has no say in who= or where this agent is.

    This is where I think this discussion really = should go. On the surface, this seems to lead to the =E2=80=9Cbring your ow= n AS=E2=80=9D model. I am contending that it=E2=80=99s more powerful to hav= e an AS (still under the API Provider=E2=80=99s control) that allows the us= er to provide additional inputs during the protocol process. As an industry= , we can standardize and innovate a lot of those inputs, but ultimately GNA= P should be able to just connect those endpoints to each other (in my opini= on). One of the common inputs is going to remain =E2=80=9Cget someone to lo= g in at this webpage at the AS and click a button=E2=80=9D, but I=E2=80=99m= convinced there will be others.

    1. The = automation of the agent is based on policies provided by the patient. The a= gent is able to process access requests from anyone and is responsible only= to the patient. The agent responds to successful requests by issuing a fil= tered capability to the requesting party.

    In this case, shouldn=E2=80= =99t it be that the agent is separated from the AS? Since the patient is go= ing to have data protected by different API Provders, to me it stands to re= ason that they=E2=80=99d want the same agent acting for them on different s= ystems. Each of those systems would still have its own AS, but the AS would= be facilitated by the user=E2=80=99s input.

    Now t= his is NOT saying that the user would have their own AS to delegate somethi= ng to the downstream AS. Or even saying that the user would have some kind = of XACML policy server. I=E2=80=99m not sure exactly how the bits on the wi= re would work but a strawman would look something like:


    3D"https://www.websequencediagrams.com/?png=3Dmsc97835=

    User -> Client: go access my medica= l data
    Client -> RS: hey I want to access this medical data
    RS -> Client: sure go talk to this AS
    Client -> Age= nt: I need to make a request for data, how can I get the AS in touch with y= ou?
    Agent -> Client: tell them to use [some kind of magic]
    Client -> AS: hey I want to access this medical data; I can get t= he user to interact with you or I can put you in touch with their policy ag= ent
    AS -> Client: OK I=E2=80=99ll talk to the policy agent
    AS -> Agent: I have a request for data, I need you to prove that = you have the right to release this data
    Agent -> User: It look= s like Client is asking for stuff at RS through AS, that cool?
    Ag= ent -> AS: OK, here you go [more magic]
    AS -> Client: ok, h= ere=E2=80=99s an access token that=E2=80=99s good for accessing that AS
    Client -> RS: hey, I want to access this medical data and here=E2= =80=99s an access token for it


    1. To ensure that the requesting party can delegate= the capability using an institutional workflow system that they trust and = the patient doesn=E2=80=99t know or care about. In many cases, the workflow= system will pass the capability to some other person, who we might call th= e end user. In other cases, the requesting party may forward the capability= directly to another person using, for example, an email. Either way, the c= lient app used by the end-user to access the API is of no concern to the pa= tient or to the patient=E2=80=99s agent.=C2=A0

    To facilitate this, the= =E2=80=9Cagent=E2=80=9D above can be augmented with other capabilities bas= ed on what=E2=80=99s being asked for. Adding a line to the flow above:

    User -> Client: go access my medical data
    Client -> RS: hey I want to access this medical data
    RS = -> Client: sure go talk to this AS
    Client -> Agent: I need = to make a request for data, how can I get the AS in touch with you?
    Agent -> Client: tell them to use [some kind of magic]
    Clie= nt -> AS: hey I want to access this medical data; I can get the user to = interact with you or I can put you in touch with their policy agent
    AS -> Client: OK I=E2=80=99ll talk to the policy agent
    AS -= > Agent: I have a request for data, I need you to prove that you have th= e right to release this data
    Agent -> User: It looks like Clie= nt is asking for stuff at RS through AS, that cool?
    Agent -> A= S: OK, here you go [more magic]
    AS -> RO: It looks like som= eone's asking for an RS you have the approval for, that cool?
    =
    AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99s goo= d for accessing that AS
    Client -> RS: hey, I want to access th= is medical data and here=E2=80=99s an access token for it

    In other words, when the AS gets the request, it can and should tak= e in inputs from multiple different dimensions in order to make the authori= zation decision and encode that into the access token.

    1. To ensure that the API Provider does not censor the= client app that presents the capability or solicits too much information a= bout the client app or the end-user of the client app.=C2=A0

    This is o= ne of the reasons that the AS-based model is really important in GNAP =E2= =80=94 the API Provider's RS only needs to know =E2=80=9Cis this token = good for what=E2=80=99s being asked=E2=80=9D.=C2=A0

    1. If the API Provider decides, for any reason, to be =E2=80=9C= suspicious=E2=80=9D (as above) of the access transaction based on the infor= mation it has, it should be possible for the API Provider to warn the patie= nt and to accept an override of the warning by the patient. This effectivel= y means that the end-user will provide as much information as they think wi= ll be necessary in order to either avoid =E2=80=9Csuspicion=E2=80=9D or ris= k waiting for patient override.

    If the AS can reach out to the patient= through notice and consent, they can be brought into the process in an int= eractive way above. This assumes the AS has a way of connecting that, but w= e should assume the AS can provide this kind of notice and consent to parti= es that aren=E2=80=99t directly involved in the protocol flow in the same w= ay the end user is.

      The policies by w= hich the patient or the decides to grant a capability to the requesting par= ty are never shared outside of the patient-agent trust relationship. In oth= er words, neither the patient nor the agent is asked to share or explain th= eir reason for an access decision.=C2=A0

    In the above pattern, the AS = and agent would need a way to communicate this with each other. I think the= details of this are outside the scope of GNAP but it could take the form o= f a query/response fulfillment language. VC=E2=80=99s address part of this,= but I think there will need to be other aspects brought to bear here. I th= ink you could have a privacy-preserving protocol that would layer into GNAP= here, but I don=E2=80=99t know for sure what that would look like.
    1. Access requests to the agent are presumed co= nfidential among the patient, the agent, and whatever client the requesting= party uses to present an access request. The API Provider does not get to = see the requests and no entity in the GNAP authorization process, other tha= n the patient or the agent, gets to correlate across requests by different = requesting party clients.

    This would be a different kind of model, whe= re the client would act as some kind of proxy in the process. Something mor= e like:

    3D"https://www.websequencediagrams.com/?png=

    User -> Client: go acces= s my medical data
    Client -> RS: hey I want to access this medi= cal data
    RS -> Client: sure go talk to this AS
    Clien= t -> Agent: I need to make a request for data, how can I get the AS in t= ouch with you?
    Agent -> Client: tell them to use [some kind of= magic]
    Client -> AS: hey I want to access this medical data; = I can get the user to interact with you or I can forward your request detai= ls to the policy agent
    AS -> Client: OK go talk to the policy = agent, ask for these kinds of things
    Client -> Agent: I have a= request for data, at this AS, I need you to prove that you have the right = to release this data
    Agent -> User: It looks like Client is as= king for stuff at RS through AS, that cool?
    Agent -> Client: O= K, here you go [more magic]
    Client -> AS: Here=E2=80=99s the r= esult of that policy thing you asked for [more magic]
    AS -> Cl= ient: ok, here=E2=80=99s an access token that=E2=80=99s good for accessing = that AS
    Client -> RS: hey, I want to access this medical data = and here=E2=80=99s an access token for it



    Note that I am not saying all 8 req= uirements are in scope for GNAP but I am asking for GNAP to allow for this = level of privacy on the part of self-sovereign patients using self-sovereig= n agents and the self-sovereign licensed professionals they deal with.

    For me th= e important part is that GNAP allow these kinds of trust connections. Even = if GNAP isn=E2=80=99t solving every piece of this equation, it can at least= clearly state =E2=80=9Cthere=E2=80=99s a function here that needs to / is = able to solve this thing=E2=80=9D and build the important parts around it.<= /div>


    =C2=A0- Justin


    Adrian

    <= br>
    On Fri,= Mar 12, 2021 at 2:50 PM Fabien Imbault <fabien.imbault@gmail.com<= /a>> wrote:

    <= br>
    On Fri,= Mar 12, 2021 at 6:07 PM Justin Richer <jricher@mit.edu> wrote:
    <= /div>
    As discussed at the IETF meeting, the editors pr= oposed that one of our next big topic areas was going to be the nature of t= he AS role within the GNAP protocol, especially how it relates to the devic= e-driven use cases that have been brought up. Apologies in advance for the = long post, but there are a lot of parts to this discussion that I=E2=80=99m= hoping we can kick off here.

    My core proposal is that w= e see the AS as the component that has the following properties:
    = =C2=A0- receives delegation requests from the client instance for access to= an RS via access tokens, and for access to subject information returned di= rectly to the client instance
    =C2=A0- collects consent and author= ization from the RO for the delegation
    =C2=A0- issues access toke= ns that its downstream RS=E2=80=99s can interpret (and validate/accept)
    =C2=A0- issues subject information asserted by the AS=C2=A0
    =
    This framing of the parties is really important in making a = consistent understanding of how the protocol works, and a consistent unders= tanding is vital if we=E2=80=99re going to function as a working group in b= oth discussing the problem space and executing the solution space. For a hi= storical example, a naive approach to adding identity on top of a protocol = like OAuth 2 (or GNAP) is to declare that the resource server is the thing = the user is logging in to. This seems reasonable at first (and some people = tried doing this) but it violates all kinds of trust boundaries and puts ne= w expectations on the different parties that do not make sense. It stops lo= oking anything like OAuth very quickly and turns into another protocol. If = instead we say the user is logging in to the client, things suddenly make a= lot more sense and we can do a lot more with it. (See this blog post from = 2013 for one take on that discussion:=C2=A0https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-si= gn-in-4/)

    I think we=E2=80=99ve got a similar = situation here when we start to talk about the user bringing their own AS w= ith them. I think this is a reasonable-seeming assumption but it=E2=80=99s = based on a false premise that the RO has to log into the AS to approve the = request, and the AS has full control and view over everything in the networ= k. While OAuth doesn=E2=80=99t require this, it=E2=80=99s largely assumed t= hat=E2=80=99s how it works. After all, all of the early OAuth deployments w= orked exactly this way: the user logs in and clicks the =E2=80=9COK=E2=80= =9D button. However, cloud deployments have shown us that it=E2=80=99s perf= ectly reasonable for an OAuth AS to take in its consent and user informatio= n from an external trusted source, and so this model is not even accurate i= n OAuth.

    In short, I think we can do a better job = here of defining things in terms that both accept the reality we face and e= nable new ideas in ways that make sense. It=E2=80=99s my stance that the us= er shouldn=E2=80=99t need to bring the AS with them in order to have the ki= nd of input and control of the system that people are asking for. Instead, = the AS should be able to take inputs from things that the user controls in = order for the AS to do its job.

    People have discus= sed privacy concerns with the AS knowing =E2=80=9Ctoo much=E2=80=9D, but in= many of those discussions the knowledge is simply pushed to the RS instead= . What I=E2=80=99m observing here is really just pushing portions of the AS= role into the =E2=80=9CRS=E2=80=9D deployment. This doesn=E2=80=99t make i= t less of an =E2=80=9CAS=E2=80=9D role, it=E2=80=99s just being fulfilled c= losely to where the RS role is fulfilled. As such, my proposal is really no= t that different in practice, but the labels are different and better align= ed with the capabilities of the protocol.=C2=A0

    <= div>We=E2=80=99ve previously talked about separating the user-facing portio= ns of the AS into another component, and I think now might be the time to d= o that. This is a very flammable strawman proposal, but what if we had the = AS defined, as above, and the =E2=80=9Cconsent and authorization=E2=80=9D g= athering portion is augmented by another named component. Here let=E2=80=99= s call it an Interaction Component. This can take several forms based on th= e kind of interaction mode in use:

    =C2=A0- Hosted = at a URL the user is redirected to; it can then make the user log in, conse= nt, and whatever else they need to do
    =C2=A0- Hosted at a URL the= user will load separately and enter in an access code
    =C2=A0- An= app on the user=E2=80=99s device that the user interacts with directly and= which sends information back to the AS
    =C2=A0- An app reachable = by a messaging endpoint that the AS sends and receives structured informati= on from
    =C2=A0- The client itself that is given an indication as = to what information the AS needs in order to fulfill the request; this coul= d be MFA challenge/response, user credentials, signed claims, etc.

    It=E2=80=99s the AS=E2=80=99s job to accept any and all of= these that it supports and churn those into an access token.=C2=A0

    The AS itself doesn=E2=80=99t ever need to have the user = log in. The AS doesn=E2=80=99t necessarily need to even know who the user i= s in any way. The AS just needs to know from a trusted source that the requ= est is approved.

    From a practical standpoint, I th= ink this will have some small changes in how we talk about the components a= nd how we talk about the interaction phase of the grant negotiation process= . Everything I=E2=80=99m laying out here is currently allowed by the spec, = but I think we=E2=80=99ve carried through the same assumptions from OAuth 2= about deployment that are both inaccurate and confusing.=C2=A0
    <= br>
    =C2=A0=E2=80=94 Justin
    --
    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
    --000000000000399d1d05bd9de69d-- From nobody Mon Mar 15 19:17:12 2021 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 1D96B3A1798 for ; Mon, 15 Mar 2021 19:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 7Vm_Qh7UQp-5 for ; Mon, 15 Mar 2021 19:17:06 -0700 (PDT) Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com [209.85.217.47]) (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 9D5CA3A1793 for ; Mon, 15 Mar 2021 19:17:06 -0700 (PDT) Received: by mail-vs1-f47.google.com with SMTP id e21so15420162vsh.5 for ; Mon, 15 Mar 2021 19:17:06 -0700 (PDT) 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=bh0LWU2DA9qKLelvYH96T0bhOzTCfi/bNn36JwFcbPg=; b=bllh/PiMY3x9F7RaidaC2O0dEy87OH5groGUtTYzpGq+fzmYgwXXIfC6sqEvLKY3I6 szmnyuGJFFrP3cYIvH101AO5YEbxzukZ+AB61K4eYfvWSig9ONKwVMSkfxv3tyHCEflG w9l8069qV7Ffgg9BdI4Ss0bf588PcfJe4sqb7cmpV4Gh+U2I/yxwFdG5PRDFTg2MIUHv w7DmrcMZ5+LZcT6qcG60a0kzw1neTgZmE4su5qoByRcgd9Vqrtlo5HSgqd8wP7x+uu9r 7YXLDFHT8M9XzeRuqKPQDufY0aS3orW6BQFH7pGz/WG3O8HGnhn713ZUrFdxp9twjz+2 pWgg== X-Gm-Message-State: AOAM5315p5yHyZOJ/21Gucc72V3QC+EyraP1fXDK1D8JACp1jPv43f4W l4NMWnH5L5JpMLswnpkds8+5RDrlS30xr615rss= X-Google-Smtp-Source: ABdhPJw1BnVYgb2zxEFw6FR69WP8VB4c1ChnGCbWqtXNcj1sW8cNc4TyixRs7HFQHuRTZpXhRutZGtNeNkzl/eYEuNk= X-Received: by 2002:a67:db84:: with SMTP id f4mr7183237vsk.20.1615861025521; Mon, 15 Mar 2021 19:17:05 -0700 (PDT) MIME-Version: 1.0 References: <205ACFE1-7D4C-4D7C-B394-4AD8A4D4D080@mit.edu> In-Reply-To: From: Adrian Gropper Date: Mon, 15 Mar 2021 22:16:52 -0400 Message-ID: To: Fabien Imbault Cc: Justin Richer , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000006ec29c05bd9df6f4" Archived-At: Subject: Re: [GNAP] GNAP Architecture and the role of the AS X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 02:17:11 -0000 --0000000000006ec29c05bd9df6f4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Justin, I have exactly the same two questions as Fabien and also, I worry about the handwaving in the answer to 7. Your flow for 8 doesn't make sense to me because I assume the client is on the RO's mobile device and unavailable for most interactions. The whole point of having the Agent is to keep the RO Client out of the picture when the requesting party shows up with their Client. Adrian On Mon, Mar 15, 2021 at 10:12 PM Adrian Gropper wrote: > Hi Justin, > > I have exactly the same two questions as Fabien and also, I > > On Mon, Mar 15, 2021 at 9:45 PM Fabien Imbault > wrote: > >> Hi Justin >> >> A few questions : >> - we're covering the use case "get my medical data", how does that chang= e >> if that's someone else's data? >> - what happens if the agent can't guarantee availability? >> >> Fabien >> >> >> Le lun. 15 mars 2021 =C3=A0 20:42, Justin Richer a =C3= =A9crit : >> >>> Hi Adrian, thanks so much for writing up this use case. I=E2=80=99ve in= cluded >>> some thoughts below into how different aspects of GNAP might map to the= se >>> requirements. I don=E2=80=99t think mapping any human system to any tec= hnology is >>> clean and dry, but for what it=E2=80=99s worth I do see a lot of alignm= ent. >>> >>> On Mar 12, 2021, at 4:34 PM, Adrian Gropper >>> wrote: >>> >>> Let=E2=80=99s try to map a real-world use-case into the names and roles= we are >>> discussing. The use-case is documented as the API Task Force >>> Recommendations (2016) >>> https://www.healthit.gov/sites/default/files/facas/SingleSourceofTruth-= APITFRecommendations.pdf >>> and I=E2=80=99ve copied below the most relevant section. Bold highlight= is in >>> the original. I=E2=80=99ve added bold italic because it may be importan= t to our >>> discussion. >>> >>> >>> >>> - >>> >>> ONC should clarify that while API Providers may impose security >>> related restrictions on app access (e.g. rate limiting, encryption, = and >>> expiration of access tokens), it is inappropriate for API providers = to set >>> limitations on what a patient authorized app can do with data downst= ream. >>> - Given the nature of patient access rights, the provider is not in >>> a legal position to prevent the registration of apps that would a= ggregate >>> or share data, for example (though the provider might certainly d= ecide to >>> warn the patient, or endeavor to educate and explain these issue = to the >>> patient, as part of the provider hosted app approval workflow). >>> - ONC should clarify that API providers are not obligated to >>> protect patients by identifying "suspicious" apps. API providers may >>> suspend API access to an app that has breached the API provider's >>> terms of service , or appears to have been compromised, or if the ap= p poses >>> a threat to the provider's own system. However, patients must be >>> able to override this suspension (except in the case where an app >>> poses threat to the provider's own system or violates allowable term= s of >>> service). >>> >>> >>> >>> >>> The key requirements from a patient rights and privacy perspective are: >>> >>> >>> 1. To delegate a scope-limited access capability to anyone anywhere >>> without having to explain or justify that to the API Provider. >>> >>> >>> This will always be susceptible to the level of granularity that the AP= I >>> Provider allows the API to be accessed in. >>> >>> Standard APIs (which would result in standard =E2=80=9Ctype=E2=80=9D va= lues in the >>> =E2=80=9Caccess=E2=80=9D request array) can help with this by defining = sufficient levels of >>> detail. But ultimately, the user could never ask for a scope that the A= PI >>> Provider isn=E2=80=99t willing to express. >>> >>> >>> 1. To allow the patient to automate the issue of a scope-limited >>> access capability by delegating the authority to process API access >>> requests to some agent. The API Provider has no say in who or where = this >>> agent is. >>> >>> >>> This is where I think this discussion really should go. On the surface, >>> this seems to lead to the =E2=80=9Cbring your own AS=E2=80=9D model. I = am contending that >>> it=E2=80=99s more powerful to have an AS (still under the API Provider= =E2=80=99s control) >>> that allows the user to provide additional inputs during the protocol >>> process. As an industry, we can standardize and innovate a lot of those >>> inputs, but ultimately GNAP should be able to just connect those endpoi= nts >>> to each other (in my opinion). One of the common inputs is going to rem= ain >>> =E2=80=9Cget someone to log in at this webpage at the AS and click a bu= tton=E2=80=9D, but >>> I=E2=80=99m convinced there will be others. >>> >>> >>> 1. The automation of the agent is based on policies provided by the >>> patient. The agent is able to process access requests from anyone an= d is >>> responsible only to the patient. The agent responds to successful re= quests >>> by issuing a filtered capability to the requesting party. >>> >>> >>> In this case, shouldn=E2=80=99t it be that the agent is separated from = the AS? >>> Since the patient is going to have data protected by different API >>> Provders, to me it stands to reason that they=E2=80=99d want the same a= gent acting >>> for them on different systems. Each of those systems would still have i= ts >>> own AS, but the AS would be facilitated by the user=E2=80=99s input. >>> >>> Now this is NOT saying that the user would have their own AS to delegat= e >>> something to the downstream AS. Or even saying that the user would have >>> some kind of XACML policy server. I=E2=80=99m not sure exactly how the = bits on the >>> wire would work but a strawman would look something like: >>> >>> >>> [image: https://www.websequencediagrams.com/?png=3Dmsc978356221] >>> >>> User -> Client: go access my medical data >>> Client -> RS: hey I want to access this medical data >>> RS -> Client: sure go talk to this AS >>> Client -> Agent: I need to make a request for data, how can I get the A= S >>> in touch with you? >>> Agent -> Client: tell them to use [some kind of magic] >>> Client -> AS: hey I want to access this medical data; I can get the use= r >>> to interact with you or I can put you in touch with their policy agent >>> AS -> Client: OK I=E2=80=99ll talk to the policy agent >>> AS -> Agent: I have a request for data, I need you to prove that you >>> have the right to release this data >>> Agent -> User: It looks like Client is asking for stuff at RS through >>> AS, that cool? >>> Agent -> AS: OK, here you go [more magic] >>> AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99s good fo= r accessing that >>> AS >>> Client -> RS: hey, I want to access this medical data and here=E2=80=99= s an >>> access token for it >>> >>> >>> >>> 1. To ensure that the requesting party can delegate the capability >>> using an institutional workflow system that they trust and the patie= nt >>> doesn=E2=80=99t know or care about. In many cases, the workflow syst= em will pass >>> the capability to some other person, who we might call the end user.= In >>> other cases, the requesting party may forward the capability directl= y to >>> another person using, for example, an email. Either way, the client = app >>> used by the end-user to access the API is of no concern to the patie= nt or >>> to the patient=E2=80=99s agent. >>> >>> >>> To facilitate this, the =E2=80=9Cagent=E2=80=9D above can be augmented = with other >>> capabilities based on what=E2=80=99s being asked for. Adding a line to = the flow >>> above: >>> >>> User -> Client: go access my medical data >>> Client -> RS: hey I want to access this medical data >>> RS -> Client: sure go talk to this AS >>> Client -> Agent: I need to make a request for data, how can I get the A= S >>> in touch with you? >>> Agent -> Client: tell them to use [some kind of magic] >>> Client -> AS: hey I want to access this medical data; I can get the use= r >>> to interact with you or I can put you in touch with their policy agent >>> AS -> Client: OK I=E2=80=99ll talk to the policy agent >>> AS -> Agent: I have a request for data, I need you to prove that you >>> have the right to release this data >>> Agent -> User: It looks like Client is asking for stuff at RS through >>> AS, that cool? >>> Agent -> AS: OK, here you go [more magic] >>> *AS -> RO: It looks like someone's asking for an RS you have the >>> approval for, that cool?* >>> AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99s good fo= r accessing that >>> AS >>> Client -> RS: hey, I want to access this medical data and here=E2=80=99= s an >>> access token for it >>> >>> In other words, when the AS gets the request, it can and should take in >>> inputs from multiple different dimensions in order to make the >>> authorization decision and encode that into the access token. >>> >>> >>> 1. To ensure that the API Provider does not censor the client app >>> that presents the capability or solicits too much information about = the >>> client app or the end-user of the client app. >>> >>> >>> This is one of the reasons that the AS-based model is really important >>> in GNAP =E2=80=94 the API Provider's RS only needs to know =E2=80=9Cis = this token good for >>> what=E2=80=99s being asked=E2=80=9D. >>> >>> >>> 1. If the API Provider decides, for any reason, to be =E2=80=9Csuspi= cious=E2=80=9D >>> (as above) of the access transaction based on the information it has= , it >>> should be possible for the API Provider to warn the patient and to a= ccept >>> an override of the warning by the patient. This effectively means th= at the >>> end-user will provide as much information as they think will be nece= ssary >>> in order to either avoid =E2=80=9Csuspicion=E2=80=9D or risk waiting= for patient override. >>> >>> >>> If the AS can reach out to the patient through notice and consent, they >>> can be brought into the process in an interactive way above. This assum= es >>> the AS has a way of connecting that, but we should assume the AS can >>> provide this kind of notice and consent to parties that aren=E2=80=99t = directly >>> involved in the protocol flow in the same way the end user is. >>> >>> >>> 1. The policies by which the patient or the decides to grant a >>> capability to the requesting party are never shared outside of the >>> patient-agent trust relationship. In other words, neither the patien= t nor >>> the agent is asked to share or explain their reason for an access de= cision. >>> >>> >>> In the above pattern, the AS and agent would need a way to communicate >>> this with each other. I think the details of this are outside the scope= of >>> GNAP but it could take the form of a query/response fulfillment languag= e. >>> VC=E2=80=99s address part of this, but I think there will need to be ot= her aspects >>> brought to bear here. I think you could have a privacy-preserving proto= col >>> that would layer into GNAP here, but I don=E2=80=99t know for sure what= that would >>> look like. >>> >>> >>> 1. Access requests to the agent are presumed confidential among the >>> patient, the agent, and whatever client the requesting party uses to >>> present an access request. The API Provider does not get to see the >>> requests and no entity in the GNAP authorization process, other than= the >>> patient or the agent, gets to correlate across requests by different >>> requesting party clients. >>> >>> >>> This would be a different kind of model, where the client would act as >>> some kind of proxy in the process. Something more like: >>> >>> [image: https://www.websequencediagrams.com/?png=3Dmsc685845457] >>> >>> User -> Client: go access my medical data >>> Client -> RS: hey I want to access this medical data >>> RS -> Client: sure go talk to this AS >>> Client -> Agent: I need to make a request for data, how can I get the A= S >>> in touch with you? >>> Agent -> Client: tell them to use [some kind of magic] >>> Client -> AS: hey I want to access this medical data; I can get the use= r >>> to interact with you or I can forward your request details to the polic= y >>> agent >>> AS -> Client: OK go talk to the policy agent, ask for these kinds of >>> things >>> Client -> Agent: I have a request for data, at this AS, I need you to >>> prove that you have the right to release this data >>> Agent -> User: It looks like Client is asking for stuff at RS through >>> AS, that cool? >>> Agent -> Client: OK, here you go [more magic] >>> Client -> AS: Here=E2=80=99s the result of that policy thing you asked = for [more >>> magic] >>> AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99s good fo= r accessing that >>> AS >>> Client -> RS: hey, I want to access this medical data and here=E2=80=99= s an >>> access token for it >>> >>> >>> >>> Note that I am not saying all 8 requirements are in scope for GNAP but = I >>> am asking for GNAP to allow for this level of privacy on the part of >>> self-sovereign patients using self-sovereign agents and the self-sovere= ign >>> licensed professionals they deal with. >>> >>> >>> For me the important part is that GNAP allow these kinds of trust >>> connections. Even if GNAP isn=E2=80=99t solving every piece of this equ= ation, it >>> can at least clearly state =E2=80=9Cthere=E2=80=99s a function here tha= t needs to / is able >>> to solve this thing=E2=80=9D and build the important parts around it. >>> >>> >>> - Justin >>> >>> >>> Adrian >>> >>> >>> On Fri, Mar 12, 2021 at 2:50 PM Fabien Imbault >>> wrote: >>> >>>> Hi Justin, >>>> >>>> Just a quick word to say I very much agree with both the observations >>>> and the framing. >>>> >>>> Fabien >>>> >>>> On Fri, Mar 12, 2021 at 6:07 PM Justin Richer wrote: >>>> >>>>> As discussed at the IETF meeting, the editors proposed that one of ou= r >>>>> next big topic areas was going to be the nature of the AS role within= the >>>>> GNAP protocol, especially how it relates to the device-driven use cas= es >>>>> that have been brought up. Apologies in advance for the long post, bu= t >>>>> there are a lot of parts to this discussion that I=E2=80=99m hoping w= e can kick off >>>>> here. >>>>> >>>>> My core proposal is that we see the AS as the component that has the >>>>> following properties: >>>>> - receives delegation requests from the client instance for access t= o >>>>> an RS via access tokens, and for access to subject information return= ed >>>>> directly to the client instance >>>>> - collects consent and authorization from the RO for the delegation >>>>> - issues access tokens that its downstream RS=E2=80=99s can interpre= t (and >>>>> validate/accept) >>>>> - issues subject information asserted by the AS >>>>> >>>>> This framing of the parties is really important in making a consisten= t >>>>> understanding of how the protocol works, and a consistent understandi= ng is >>>>> vital if we=E2=80=99re going to function as a working group in both d= iscussing the >>>>> problem space and executing the solution space. For a historical exam= ple, a >>>>> naive approach to adding identity on top of a protocol like OAuth 2 (= or >>>>> GNAP) is to declare that the resource server is the thing the user is >>>>> logging in to. This seems reasonable at first (and some people tried = doing >>>>> this) but it violates all kinds of trust boundaries and puts new >>>>> expectations on the different parties that do not make sense. It stop= s >>>>> looking anything like OAuth very quickly and turns into another proto= col. >>>>> If instead we say the user is logging in to the client, things sudden= ly >>>>> make a lot more sense and we can do a lot more with it. (See this blo= g post >>>>> from 2013 for one take on that discussion: >>>>> https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4= / >>>>> ) >>>>> >>>>> I think we=E2=80=99ve got a similar situation here when we start to t= alk about >>>>> the user bringing their own AS with them. I think this is a >>>>> reasonable-seeming assumption but it=E2=80=99s based on a false premi= se that the RO >>>>> has to log into the AS to approve the request, and the AS has full co= ntrol >>>>> and view over everything in the network. While OAuth doesn=E2=80=99t = require this, >>>>> it=E2=80=99s largely assumed that=E2=80=99s how it works. After all, = all of the early OAuth >>>>> deployments worked exactly this way: the user logs in and clicks the = =E2=80=9COK=E2=80=9D >>>>> button. However, cloud deployments have shown us that it=E2=80=99s pe= rfectly >>>>> reasonable for an OAuth AS to take in its consent and user informatio= n from >>>>> an external trusted source, and so this model is not even accurate in= OAuth. >>>>> >>>>> In short, I think we can do a better job here of defining things in >>>>> terms that both accept the reality we face and enable new ideas in wa= ys >>>>> that make sense. It=E2=80=99s my stance that the user shouldn=E2=80= =99t need to bring the >>>>> AS with them in order to have the kind of input and control of the sy= stem >>>>> that people are asking for. Instead, the AS should be able to take in= puts >>>>> from things that the user controls in order for the AS to do its job. >>>>> >>>>> People have discussed privacy concerns with the AS knowing =E2=80=9Ct= oo much=E2=80=9D, >>>>> but in many of those discussions the knowledge is simply pushed to th= e RS >>>>> instead. What I=E2=80=99m observing here is really just pushing porti= ons of the AS >>>>> role into the =E2=80=9CRS=E2=80=9D deployment. This doesn=E2=80=99t m= ake it less of an =E2=80=9CAS=E2=80=9D role, >>>>> it=E2=80=99s just being fulfilled closely to where the RS role is ful= filled. As >>>>> such, my proposal is really not that different in practice, but the l= abels >>>>> are different and better aligned with the capabilities of the protoco= l. >>>>> >>>>> We=E2=80=99ve previously talked about separating the user-facing port= ions of >>>>> the AS into another component, and I think now might be the time to d= o >>>>> that. This is a very flammable strawman proposal, but what if we had = the AS >>>>> defined, as above, and the =E2=80=9Cconsent and authorization=E2=80= =9D gathering portion is >>>>> augmented by another named component. Here let=E2=80=99s call it an I= nteraction >>>>> Component. This can take several forms based on the kind of interacti= on >>>>> mode in use: >>>>> >>>>> - Hosted at a URL the user is redirected to; it can then make the >>>>> user log in, consent, and whatever else they need to do >>>>> - Hosted at a URL the user will load separately and enter in an >>>>> access code >>>>> - An app on the user=E2=80=99s device that the user interacts with d= irectly >>>>> and which sends information back to the AS >>>>> - An app reachable by a messaging endpoint that the AS sends and >>>>> receives structured information from >>>>> - The client itself that is given an indication as to what >>>>> information the AS needs in order to fulfill the request; this could = be MFA >>>>> challenge/response, user credentials, signed claims, etc. >>>>> >>>>> It=E2=80=99s the AS=E2=80=99s job to accept any and all of these that= it supports and >>>>> churn those into an access token. >>>>> >>>>> The AS itself doesn=E2=80=99t ever need to have the user log in. The = AS >>>>> doesn=E2=80=99t necessarily need to even know who the user is in any = way. The AS >>>>> just needs to know from a trusted source that the request is approved= . >>>>> >>>>> From a practical standpoint, I think this will have some small change= s >>>>> in how we talk about the components and how we talk about the interac= tion >>>>> phase of the grant negotiation process. Everything I=E2=80=99m laying= out here is >>>>> currently allowed by the spec, but I think we=E2=80=99ve carried thro= ugh the same >>>>> assumptions from OAuth 2 about deployment that are both inaccurate an= d >>>>> confusing. >>>>> >>>>> =E2=80=94 Justin >>>>> -- >>>>> 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 >> > --0000000000006ec29c05bd9df6f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Justin,

    I have exac= tly the same two questions as Fabien and also, I worry about the handwaving= =C2=A0in the answer=C2=A0to 7.

    Your flow for 8 doe= sn't make sense to me because I assume the client is on the RO's mo= bile device and unavailable for most interactions. The whole point of havin= g the Agent is to keep the RO Client out of the picture when the requesting= party shows up with their Client.

    Adrian

    On Mon, Mar 15, 2021 at 10:12 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Hi Justin,

    I have exactly th= e same two questions as Fabien and also, I=C2=A0

    On Mon, Mar 15, 2021= at 9:45 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Justin

    A few questions :
    - we're covering t= he use case "get my medical data", how does that change if that&#= 39;s someone else's data?=C2=A0
    - what happens i= f the agent can't guarantee availability?=C2=A0
    =
    Fabien=C2=A0


    Le lun. 15 mars 2021 =C3=A0 20:= 42, Justin Richer <= jricher@mit.edu> a =C3=A9crit=C2=A0:
    Hi Adrian, than= ks so much for writing up this use case. I=E2=80=99ve included some thought= s below into how different aspects of GNAP might map to these requirements.= I don=E2=80=99t think mapping any human system to any technology is clean = and dry, but for what it=E2=80=99s worth I do see a lot of alignment.

    On Mar 12, 2021, at 4:34 PM, Adrian G= ropper <agropper@healthurl.com> wrote:

    Let=E2= =80=99s try to map a real-world use-case into the names and roles we are di= scussing. The use-case is documented as the API Task Force Recommendations = (2016) https://www.healthit.gov/sites/default/files/facas/SingleSourceofTru= th-APITFRecommendations.pdf and I=E2=80=99ve copied below the most relevan= t section. Bold highlight is in the original. I=E2=80=99ve added = bold italic because it may be important to our = discussion.=C2=A0

    = <quote>

    • O= NC should clarify that while API Providers may impose security related rest= rictions on app access (e.g. rate limiting, encryption, and expiration of a= ccess tokens), it is inappropriate for API providers to set limitations on = what a patient authorized app can do with data downstream.

      • <= ul style=3D"margin-top:0px;margin-bottom:0px">
    • Given the nature of patient access rights, t= he provider is not in a legal position to prevent the registration of apps = that would aggregate or share data, for example (though the provider might = certainly decide to warn the patient, or endeavor to educate and explain th= ese issue to the patient, as part of the provider hosted app approval workf= low).
  • ONC should clarify that API providers are not obligated to protect patients by identifying= "suspicious" apps. API providers may suspend API access to an app that has breached the AP= I provider's terms of service , or appears to have been compromised, or= if the app poses a threat to the provider's own system. However, patients must be able to override this suspension (except in the case where an app poses= threat to the provider's own system or violates allowable terms of ser= vice).

    </quote>

    • The key requirements from a patient rights an= d privacy perspective are:

    1. To delegate a scope-limited access capability to anyone anywhere without h= aving to explain or justify that to the API Provider.

    This will always= be susceptible to the level of granularity that the API Provider allows th= e API to be accessed in.=C2=A0

    Standard APIs (whic= h would result in standard =E2=80=9Ctype=E2=80=9D values in the =E2=80=9Cac= cess=E2=80=9D request array) can help with this by defining sufficient leve= ls of detail. But ultimately, the user could never ask for a scope that the= API Provider isn=E2=80=99t willing to express.

    1. To allow the patient to automate the issue of a scope-limited = access capability by delegating the authority to process API access request= s to some agent. The API Provider has no say in who or where this agent is.=

    This is where I think this discussion really should go. On the surfac= e, this seems to lead to the =E2=80=9Cbring your own AS=E2=80=9D model. I a= m contending that it=E2=80=99s more powerful to have an AS (still under the= API Provider=E2=80=99s control) that allows the user to provide additional= inputs during the protocol process. As an industry, we can standardize and= innovate a lot of those inputs, but ultimately GNAP should be able to just= connect those endpoints to each other (in my opinion). One of the common i= nputs is going to remain =E2=80=9Cget someone to log in at this webpage at = the AS and click a button=E2=80=9D, but I=E2=80=99m convinced there will be= others.

    1. = The automation of the agent = is based on policies provided by the patient. The agent is able to process = access requests from anyone and is responsible only to the patient. The age= nt responds to successful requests by issuing a filtered capability to the = requesting party.

    In this case, shouldn=E2=80=99t it be that the agent= is separated from the AS? Since the patient is going to have data protecte= d by different API Provders, to me it stands to reason that they=E2=80=99d = want the same agent acting for them on different systems. Each of those sys= tems would still have its own AS, but the AS would be facilitated by the us= er=E2=80=99s input.

    Now this is NOT saying that th= e user would have their own AS to delegate something to the downstream AS. = Or even saying that the user would have some kind of XACML policy server. I= =E2=80=99m not sure exactly how the bits on the wire would work but a straw= man would look something like:



    =
    User -> Client: go access my medical data
    Client -&g= t; RS: hey I want to access this medical data
    RS -> Client: su= re go talk to this AS
    Client -> Agent: I need to make a reques= t for data, how can I get the AS in touch with you?
    Agent -> C= lient: tell them to use [some kind of magic]
    Client -> AS: hey= I want to access this medical data; I can get the user to interact with yo= u or I can put you in touch with their policy agent
    AS -> Clie= nt: OK I=E2=80=99ll talk to the policy agent
    AS -> Agent: I ha= ve a request for data, I need you to prove that you have the right to relea= se this data
    Agent -> User: It looks like Client is asking for= stuff at RS through AS, that cool?
    Agent -> AS: OK, here you = go [more magic]
    AS -> Client: ok, here=E2=80=99s an access tok= en that=E2=80=99s good for accessing that AS
    Client -> RS: hey= , I want to access this medical data and here=E2=80=99s an access token for= it


    1. T= o ensure that the requesting party can delegate the capability using an ins= titutional workflow system that they trust and the patient doesn=E2=80=99t = know or care about. In many cases, the workflow system will pass the capabi= lity to some other person, who we might call the end user. In other cases, = the requesting party may forward the capability directly to another person = using, for example, an email. Either way, the client app used by the end-us= er to access the API is of no concern to the patient or to the patient=E2= =80=99s agent.=C2=A0

    To facilitate this, the =E2=80=9Cagent=E2=80=9D a= bove can be augmented with other capabilities based on what=E2=80=99s being= asked for. Adding a line to the flow above:

    = User -> Client: go access my medical data
    Client -> RS: hey= I want to access this medical data
    RS -> Client: sure go talk= to this AS
    Client -> Agent: I need to make a request for data= , how can I get the AS in touch with you?
    Agent -> Client: tel= l them to use [some kind of magic]
    Client -> AS: hey I want to= access this medical data; I can get the user to interact with you or I can= put you in touch with their policy agent
    AS -> Client: OK I= =E2=80=99ll talk to the policy agent
    AS -> Agent: I have a req= uest for data, I need you to prove that you have the right to release this = data
    Agent -> User: It looks like Client is asking for stuff a= t RS through AS, that cool?
    Agent -> AS: OK, here you go [more= magic]
    AS -> RO: It looks like someone's asking for an= RS you have the approval for, that cool?
    AS -> Client: ok= , here=E2=80=99s an access token that=E2=80=99s good for accessing that AS<= /div>
    Client -> RS: hey, I want to access this medical data and here= =E2=80=99s an access token for it

    In other words, = when the AS gets the request, it can and should take in inputs from multipl= e different dimensions in order to make the authorization decision and enco= de that into the access token.

    1. = To ensure that the API Provider does not censor the client app that present= s the capability or solicits too much information about the client app or t= he end-user of the client app.=C2=A0

    This is one of the reasons that t= he AS-based model is really important in GNAP =E2=80=94 the API Provider= 9;s RS only needs to know =E2=80=9Cis this token good for what=E2=80=99s be= ing asked=E2=80=9D.=C2=A0

    1. If the API= Provider decides, for any reason, to be =E2=80=9Csuspicious=E2=80=9D (as a= bove) of the access transaction based on the information it has, it should = be possible for the API Provider to warn the patient and to accept an overr= ide of the warning by the patient. This effectively means that the end-user= will provide as much information as they think will be necessary in order = to either avoid =E2=80=9Csuspicion=E2=80=9D or risk waiting for patient ove= rride.
    If the AS can reach out to the patient through notice and conse= nt, they can be brought into the process in an interactive way above. This = assumes the AS has a way of connecting that, but we should assume the AS ca= n provide this kind of notice and consent to parties that aren=E2=80=99t di= rectly involved in the protocol flow in the same way the end user is.
    =
    1. The policies by which the patient or the d= ecides to grant a capability to the requesting party are never shared outsi= de of the patient-agent trust relationship. In other words, neither the pat= ient nor the agent is asked to share or explain their reason for an access = decision.=C2=A0

    In the above pattern, the AS and agent would need a wa= y to communicate this with each other. I think the details of this are outs= ide the scope of GNAP but it could take the form of a query/response fulfil= lment language. VC=E2=80=99s address part of this, but I think there will n= eed to be other aspects brought to bear here. I think you could have a priv= acy-preserving protocol that would layer into GNAP here, but I don=E2=80=99= t know for sure what that would look like.

    1. Access requests to the agent are presumed confidential among the pati= ent, the agent, and whatever client the requesting party uses to present an= access request. The API Provider does not get to see the requests and no e= ntity in the GNAP authorization process, other than the patient or the agen= t, gets to correlate across requests by different requesting party clients.=

    This would be a different kind of model, where the client would act a= s some kind of proxy in the process. Something more like:

    3D"https://www.websequencediagrams.com/?png=3Dmsc685845457"

    User -> Client: go access my medical data
    Client -> RS: hey I want to access this medical data
    RS ->= ; Client: sure go talk to this AS
    Client -> Agent: I need to m= ake a request for data, how can I get the AS in touch with you?
    A= gent -> Client: tell them to use [some kind of magic]
    Client -= > AS: hey I want to access this medical data; I can get the user to inte= ract with you or I can forward your request details to the policy agent
    AS -> Client: OK go talk to the policy agent, ask for these kinds= of things
    Client -> Agent: I have a request for data, at this= AS, I need you to prove that you have the right to release this data
    =
    Agent -> User: It looks like Client is asking for stuff at RS throu= gh AS, that cool?
    Agent -> Client: OK, here you go [more magic= ]
    Client -> AS: Here=E2=80=99s the result of that policy thing= you asked for [more magic]
    AS -> Client: ok, here=E2=80=99s a= n access token that=E2=80=99s good for accessing that AS
    Client -= > RS: hey, I want to access this medical data and here=E2=80=99s an acce= ss token for it



    Note that I am not saying all 8 requirements are in scope for= GNAP but I am asking for GNAP to allow for this level of privacy on the pa= rt of self-sovereign patients using self-sovereign agents and the self-sove= reign licensed professionals they deal with.

    For me the important part is that G= NAP allow these kinds of trust connections. Even if GNAP isn=E2=80=99t solv= ing every piece of this equation, it can at least clearly state =E2=80=9Cth= ere=E2=80=99s a function here that needs to / is able to solve this thing= =E2=80=9D and build the important parts around it.


    =C2=A0- Justin


    Adrian


    On Fri, Mar 12, 2021 at 2:50 PM= Fabien Imbault <fabien.imbault@gmail.com> wrote:
    =
    Hi Justin,=C2=A0

    Just = a quick word to say I very much agree with both the observations and the fr= aming.

    Fabien

    On Fri, Mar 12, 2021 at 6:07 PM= Justin Richer <jricher@mit.edu> wrote:
    =
    As discussed at the IETF meeting, the editors proposed that one of our= next big topic areas was going to be the nature of the AS role within the = GNAP protocol, especially how it relates to the device-driven use cases tha= t have been brought up. Apologies in advance for the long post, but there a= re a lot of parts to this discussion that I=E2=80=99m hoping we can kick of= f here.

    My core proposal is that we see the AS as the co= mponent that has the following properties:
    =C2=A0- receives deleg= ation requests from the client instance for access to an RS via access toke= ns, and for access to subject information returned directly to the client i= nstance
    =C2=A0- collects consent and authorization from the RO fo= r the delegation
    =C2=A0- issues access tokens that its downstream= RS=E2=80=99s can interpret (and validate/accept)
    =C2=A0- issues = subject information asserted by the AS=C2=A0

    This fr= aming of the parties is really important in making a consistent understandi= ng of how the protocol works, and a consistent understanding is vital if we= =E2=80=99re going to function as a working group in both discussing the pro= blem space and executing the solution space. For a historical example, a na= ive approach to adding identity on top of a protocol like OAuth 2 (or GNAP)= is to declare that the resource server is the thing the user is logging in= to. This seems reasonable at first (and some people tried doing this) but = it violates all kinds of trust boundaries and puts new expectations on the = different parties that do not make sense. It stops looking anything like OA= uth very quickly and turns into another protocol. If instead we say the use= r is logging in to the client, things suddenly make a lot more sense and we= can do a lot more with it. (See this blog post from 2013 for one take on t= hat discussion:=C2=A0https://w= ww.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/)

    I think we=E2=80=99ve got a similar situation here when we= start to talk about the user bringing their own AS with them. I think this= is a reasonable-seeming assumption but it=E2=80=99s based on a false premi= se that the RO has to log into the AS to approve the request, and the AS ha= s full control and view over everything in the network. While OAuth doesn= =E2=80=99t require this, it=E2=80=99s largely assumed that=E2=80=99s how it= works. After all, all of the early OAuth deployments worked exactly this w= ay: the user logs in and clicks the =E2=80=9COK=E2=80=9D button. However, c= loud deployments have shown us that it=E2=80=99s perfectly reasonable for a= n OAuth AS to take in its consent and user information from an external tru= sted source, and so this model is not even accurate in OAuth.
    In short, I think we can do a better job here of defining thing= s in terms that both accept the reality we face and enable new ideas in way= s that make sense. It=E2=80=99s my stance that the user shouldn=E2=80=99t n= eed to bring the AS with them in order to have the kind of input and contro= l of the system that people are asking for. Instead, the AS should be able = to take inputs from things that the user controls in order for the AS to do= its job.

    People have discussed privacy concerns w= ith the AS knowing =E2=80=9Ctoo much=E2=80=9D, but in many of those discuss= ions the knowledge is simply pushed to the RS instead. What I=E2=80=99m obs= erving here is really just pushing portions of the AS role into the =E2=80= =9CRS=E2=80=9D deployment. This doesn=E2=80=99t make it less of an =E2=80= =9CAS=E2=80=9D role, it=E2=80=99s just being fulfilled closely to where the= RS role is fulfilled. As such, my proposal is really not that different in= practice, but the labels are different and better aligned with the capabil= ities of the protocol.=C2=A0

    We=E2=80=99ve p= reviously talked about separating the user-facing portions of the AS into a= nother component, and I think now might be the time to do that. This is a v= ery flammable strawman proposal, but what if we had the AS defined, as abov= e, and the =E2=80=9Cconsent and authorization=E2=80=9D gathering portion is= augmented by another named component. Here let=E2=80=99s call it an Intera= ction Component. This can take several forms based on the kind of interacti= on mode in use:

    =C2=A0- Hosted at a URL the user i= s redirected to; it can then make the user log in, consent, and whatever el= se they need to do
    =C2=A0- Hosted at a URL the user will load sep= arately and enter in an access code
    =C2=A0- An app on the user=E2= =80=99s device that the user interacts with directly and which sends inform= ation back to the AS
    =C2=A0- An app reachable by a messaging endp= oint that the AS sends and receives structured information from
    = =C2=A0- The client itself that is given an indication as to what informatio= n the AS needs in order to fulfill the request; this could be MFA challenge= /response, user credentials, signed claims, etc.

    I= t=E2=80=99s the AS=E2=80=99s job to accept any and all of these that it sup= ports and churn those into an access token.=C2=A0

    = The AS itself doesn=E2=80=99t ever need to have the user log in. The AS doe= sn=E2=80=99t necessarily need to even know who the user is in any way. The = AS just needs to know from a trusted source that the request is approved.

    From a practical standpoint, I think this will have= some small changes in how we talk about the components and how we talk abo= ut the interaction phase of the grant negotiation process. Everything I=E2= =80=99m laying out here is currently allowed by the spec, but I think we=E2= =80=99ve carried through the same assumptions from OAuth 2 about deployment= that are both inaccurate and confusing.=C2=A0

    =C2= =A0=E2=80=94 Justin
    --
    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
    --0000000000006ec29c05bd9df6f4-- From nobody Tue Mar 16 05:14:42 2021 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 D8A833A08BB for ; Tue, 16 Mar 2021 05:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 KjrvTxnnPK8j for ; Tue, 16 Mar 2021 05:14:35 -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 7ECD13A08B0 for ; Tue, 16 Mar 2021 05:14:35 -0700 (PDT) Received: from [192.168.1.22] (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 12GCET4T016643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 16 Mar 2021 08:14:30 -0400 From: Justin Richer Message-Id: <4AD539F3-31BE-4162-BE2B-69D5AE22B48E@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_F5400E46-B178-4793-B0BD-979422D9C086" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Tue, 16 Mar 2021 08:14:29 -0400 In-Reply-To: Cc: Fabien Imbault , GNAP Mailing List To: Adrian Gropper References: <205ACFE1-7D4C-4D7C-B394-4AD8A4D4D080@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] GNAP Architecture and the role of the AS X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 12:14:41 -0000 --Apple-Mail=_F5400E46-B178-4793-B0BD-979422D9C086 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 15, 2021, at 10:16 PM, Adrian Gropper = wrote: >=20 > Hi Justin, >=20 > I have exactly the same two questions as Fabien and also, I worry = about the handwaving in the answer to 7. The handwaving is actually important. I don=E2=80=99t think that=E2=80=99s= something that GNAP will solve in a universal way. We can have hooks in = the core protocol that say =E2=80=9Cand now go do This Other Thing to = talk to an agent=E2=80=9D, but I don=E2=80=99t think we=E2=80=99re = really the best ones to decide what that is or what it looks like for = everyone.=20 This could be DIDComm, it could be CHAPI, it could be some proprietary = app connection with push notifications, it could be writing/reading from = a shared encryption storage fabric =E2=80=94 all that=E2=80=99s = important here is that GNAP has a place in the protocol where these = various things can fit.=20 OAuth chose HTTP Redirects as The Way to get users involved in the = process, but GNAP is taking a very different stance in trying to get = away from that limiting assumption. I don=E2=80=99t think it would serve = us to just make a different limiting assumption about how users (and = their decisions) get involved. To answer the questions; > - we're covering the use case "get my medical data", how does that = change if that's someone else's data?=20 It=E2=80=99s the same process as the second flow. The RO is the patient = or doctor or someone who can approve things. The AS doesn=E2=80=99t get = everything that it needs to from the agent introduced by the client, so = it needs to access another agent. > - what happens if the agent can't guarantee availability?=20 Then the AS doesn=E2=80=99t get what it needs in order to fulfill the = request and it denies the request. Whether that=E2=80=99s a timeout or = some other error, and whether that comes back to the client with a = =E2=80=9Ctry again=E2=80=9D or with a =E2=80=9Ctough luck, go away=E2=80=9D= , I think that=E2=80=99s all up for debate, and parts of that we=E2=80=99l= l need answers for. But ultimately, it=E2=80=99s the same kind of thing = that happens in OAuth if the user doesn=E2=80=99t consent, or the user = can=E2=80=99t log in, or the =E2=80=9Cwrong=E2=80=9D user logs in for = what=E2=80=99s being asked for =E2=80=94 the AS isn=E2=80=99t satisfied = with the approval so the delegation request fails. > Your flow for 8 doesn't make sense to me because I assume the client = is on the RO's mobile device and unavailable for most interactions. The = whole point of having the Agent is to keep the RO Client out of the = picture when the requesting party shows up with their Client. The RO doesn=E2=80=99t have a client in any of the flows below. The RO = might have an agent, they might have an app that notifies them to go log = into a webpage asynchronously, they might get an email with a link to = click back at the AS. None of that is facilitated through the RO=E2=80=99s= client because the RO doesn=E2=80=99t have a =E2=80=9Cclient=E2=80=9D = in this model. The client is by definition the software in front of the = =E2=80=9Cuser=E2=80=9D, the requesting party.=20 And it=E2=80=99s important in the design that the client doesn=E2=80=99t = need to know about any of that. It can identify the resource, possibly = identify the RO, and it can tell the AS =E2=80=9Cthis is how I can talk = to the person sitting in front of me right now=E2=80=9D =E2=80=94 for = whatever definition of =E2=80=9Ctalk to=E2=80=9D makes sense for the = client app. What it can=E2=80=99t reliably do is say =E2=80=9Cthis is = how I can get in touch with an RO that I=E2=80=99m not talking to=E2=80=9D= , and certainly not communicate with another client, another AS, or = other part of the GNAP protocol.=20 - Justin >=20 > Adrian >=20 > On Mon, Mar 15, 2021 at 10:12 PM Adrian Gropper = > wrote: > Hi Justin, >=20 > I have exactly the same two questions as Fabien and also, I=20 >=20 > On Mon, Mar 15, 2021 at 9:45 PM Fabien Imbault = > wrote: > Hi Justin >=20 > A few questions : > - we're covering the use case "get my medical data", how does that = change if that's someone else's data?=20 > - what happens if the agent can't guarantee availability?=20 >=20 > Fabien=20 >=20 >=20 > Le lun. 15 mars 2021 =C3=A0 20:42, Justin Richer > a =C3=A9crit : > Hi Adrian, thanks so much for writing up this use case. I=E2=80=99ve = included some thoughts below into how different aspects of GNAP might = map to these requirements. I don=E2=80=99t think mapping any human = system to any technology is clean and dry, but for what it=E2=80=99s = worth I do see a lot of alignment. >=20 >> On Mar 12, 2021, at 4:34 PM, Adrian Gropper > wrote: >>=20 >> Let=E2=80=99s try to map a real-world use-case into the names and = roles we are discussing. The use-case is documented as the API Task = Force Recommendations (2016) = https://www.healthit.gov/sites/default/files/facas/SingleSourceofTruth-API= TFRecommendations.pdf = and I=E2=80=99ve copied below the most relevant = section. Bold highlight is in the original. I=E2=80=99ve added bold = italic because it may be important to our discussion.=20 >>=20 >> >> ONC should clarify that while API Providers may impose security = related restrictions on app access (e.g. rate limiting, encryption, and = expiration of access tokens), it is inappropriate for API providers to = set limitations on what a patient authorized app can do with data = downstream. >> Given the nature of patient access rights, the provider is not in a = legal position to prevent the registration of apps that would aggregate = or share data, for example (though the provider might certainly decide = to warn the patient, or endeavor to educate and explain these issue to = the patient, as part of the provider hosted app approval workflow). >> ONC should clarify that API providers are not obligated to protect = patients by identifying "suspicious" apps. API providers may suspend API = access to an app that has breached the API provider's terms of service , = or appears to have been compromised, or if the app poses a threat to the = provider's own system. However, patients must be able to override this = suspension (except in the case where an app poses threat to the = provider's own system or violates allowable terms of service). >>=20 >> >>=20 >> The key requirements from a patient rights and privacy perspective = are: >>=20 >> To delegate a scope-limited access capability to anyone anywhere = without having to explain or justify that to the API Provider. >=20 > This will always be susceptible to the level of granularity that the = API Provider allows the API to be accessed in.=20 >=20 > Standard APIs (which would result in standard =E2=80=9Ctype=E2=80=9D = values in the =E2=80=9Caccess=E2=80=9D request array) can help with this = by defining sufficient levels of detail. But ultimately, the user could = never ask for a scope that the API Provider isn=E2=80=99t willing to = express. >=20 >> To allow the patient to automate the issue of a scope-limited access = capability by delegating the authority to process API access requests to = some agent. The API Provider has no say in who or where this agent is. >=20 > This is where I think this discussion really should go. On the = surface, this seems to lead to the =E2=80=9Cbring your own AS=E2=80=9D = model. I am contending that it=E2=80=99s more powerful to have an AS = (still under the API Provider=E2=80=99s control) that allows the user to = provide additional inputs during the protocol process. As an industry, = we can standardize and innovate a lot of those inputs, but ultimately = GNAP should be able to just connect those endpoints to each other (in my = opinion). One of the common inputs is going to remain =E2=80=9Cget = someone to log in at this webpage at the AS and click a button=E2=80=9D, = but I=E2=80=99m convinced there will be others. >=20 >> The automation of the agent is based on policies provided by the = patient. The agent is able to process access requests from anyone and is = responsible only to the patient. The agent responds to successful = requests by issuing a filtered capability to the requesting party. >=20 > In this case, shouldn=E2=80=99t it be that the agent is separated from = the AS? Since the patient is going to have data protected by different = API Provders, to me it stands to reason that they=E2=80=99d want the = same agent acting for them on different systems. Each of those systems = would still have its own AS, but the AS would be facilitated by the = user=E2=80=99s input. >=20 > Now this is NOT saying that the user would have their own AS to = delegate something to the downstream AS. Or even saying that the user = would have some kind of XACML policy server. I=E2=80=99m not sure = exactly how the bits on the wire would work but a strawman would look = something like: >=20 >=20 >=20 >=20 > User -> Client: go access my medical data > Client -> RS: hey I want to access this medical data > RS -> Client: sure go talk to this AS > Client -> Agent: I need to make a request for data, how can I get the = AS in touch with you? > Agent -> Client: tell them to use [some kind of magic] > Client -> AS: hey I want to access this medical data; I can get the = user to interact with you or I can put you in touch with their policy = agent > AS -> Client: OK I=E2=80=99ll talk to the policy agent > AS -> Agent: I have a request for data, I need you to prove that you = have the right to release this data > Agent -> User: It looks like Client is asking for stuff at RS through = AS, that cool? > Agent -> AS: OK, here you go [more magic] > AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99s good = for accessing that AS > Client -> RS: hey, I want to access this medical data and here=E2=80=99s= an access token for it >=20 >=20 >> To ensure that the requesting party can delegate the capability using = an institutional workflow system that they trust and the patient = doesn=E2=80=99t know or care about. In many cases, the workflow system = will pass the capability to some other person, who we might call the end = user. In other cases, the requesting party may forward the capability = directly to another person using, for example, an email. Either way, the = client app used by the end-user to access the API is of no concern to = the patient or to the patient=E2=80=99s agent.=20 >=20 > To facilitate this, the =E2=80=9Cagent=E2=80=9D above can be augmented = with other capabilities based on what=E2=80=99s being asked for. Adding = a line to the flow above: >=20 > User -> Client: go access my medical data > Client -> RS: hey I want to access this medical data > RS -> Client: sure go talk to this AS > Client -> Agent: I need to make a request for data, how can I get the = AS in touch with you? > Agent -> Client: tell them to use [some kind of magic] > Client -> AS: hey I want to access this medical data; I can get the = user to interact with you or I can put you in touch with their policy = agent > AS -> Client: OK I=E2=80=99ll talk to the policy agent > AS -> Agent: I have a request for data, I need you to prove that you = have the right to release this data > Agent -> User: It looks like Client is asking for stuff at RS through = AS, that cool? > Agent -> AS: OK, here you go [more magic] > AS -> RO: It looks like someone's asking for an RS you have the = approval for, that cool? > AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99s good = for accessing that AS > Client -> RS: hey, I want to access this medical data and here=E2=80=99s= an access token for it >=20 > In other words, when the AS gets the request, it can and should take = in inputs from multiple different dimensions in order to make the = authorization decision and encode that into the access token. >=20 >> To ensure that the API Provider does not censor the client app that = presents the capability or solicits too much information about the = client app or the end-user of the client app.=20 >=20 > This is one of the reasons that the AS-based model is really important = in GNAP =E2=80=94 the API Provider's RS only needs to know =E2=80=9Cis = this token good for what=E2=80=99s being asked=E2=80=9D.=20 >=20 >> If the API Provider decides, for any reason, to be =E2=80=9Csuspicious=E2= =80=9D (as above) of the access transaction based on the information it = has, it should be possible for the API Provider to warn the patient and = to accept an override of the warning by the patient. This effectively = means that the end-user will provide as much information as they think = will be necessary in order to either avoid =E2=80=9Csuspicion=E2=80=9D = or risk waiting for patient override. >=20 > If the AS can reach out to the patient through notice and consent, = they can be brought into the process in an interactive way above. This = assumes the AS has a way of connecting that, but we should assume the AS = can provide this kind of notice and consent to parties that aren=E2=80=99t= directly involved in the protocol flow in the same way the end user is. >=20 >> The policies by which the patient or the decides to grant a = capability to the requesting party are never shared outside of the = patient-agent trust relationship. In other words, neither the patient = nor the agent is asked to share or explain their reason for an access = decision.=20 >=20 > In the above pattern, the AS and agent would need a way to communicate = this with each other. I think the details of this are outside the scope = of GNAP but it could take the form of a query/response fulfillment = language. VC=E2=80=99s address part of this, but I think there will need = to be other aspects brought to bear here. I think you could have a = privacy-preserving protocol that would layer into GNAP here, but I = don=E2=80=99t know for sure what that would look like. >=20 >> Access requests to the agent are presumed confidential among the = patient, the agent, and whatever client the requesting party uses to = present an access request. The API Provider does not get to see the = requests and no entity in the GNAP authorization process, other than the = patient or the agent, gets to correlate across requests by different = requesting party clients. >=20 > This would be a different kind of model, where the client would act as = some kind of proxy in the process. Something more like: >=20 >=20 >=20 > User -> Client: go access my medical data > Client -> RS: hey I want to access this medical data > RS -> Client: sure go talk to this AS > Client -> Agent: I need to make a request for data, how can I get the = AS in touch with you? > Agent -> Client: tell them to use [some kind of magic] > Client -> AS: hey I want to access this medical data; I can get the = user to interact with you or I can forward your request details to the = policy agent > AS -> Client: OK go talk to the policy agent, ask for these kinds of = things > Client -> Agent: I have a request for data, at this AS, I need you to = prove that you have the right to release this data > Agent -> User: It looks like Client is asking for stuff at RS through = AS, that cool? > Agent -> Client: OK, here you go [more magic] > Client -> AS: Here=E2=80=99s the result of that policy thing you asked = for [more magic] > AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99s good = for accessing that AS > Client -> RS: hey, I want to access this medical data and here=E2=80=99s= an access token for it >=20 >=20 >>=20 >> Note that I am not saying all 8 requirements are in scope for GNAP = but I am asking for GNAP to allow for this level of privacy on the part = of self-sovereign patients using self-sovereign agents and the = self-sovereign licensed professionals they deal with. >=20 > For me the important part is that GNAP allow these kinds of trust = connections. Even if GNAP isn=E2=80=99t solving every piece of this = equation, it can at least clearly state =E2=80=9Cthere=E2=80=99s a = function here that needs to / is able to solve this thing=E2=80=9D and = build the important parts around it. >=20 >=20 > - Justin >=20 >>=20 >> Adrian >>=20 >>=20 >> On Fri, Mar 12, 2021 at 2:50 PM Fabien Imbault = > wrote: >> Hi Justin,=20 >>=20 >> Just a quick word to say I very much agree with both the observations = and the framing. >>=20 >> Fabien >>=20 >> On Fri, Mar 12, 2021 at 6:07 PM Justin Richer > wrote: >> As discussed at the IETF meeting, the editors proposed that one of = our next big topic areas was going to be the nature of the AS role = within the GNAP protocol, especially how it relates to the device-driven = use cases that have been brought up. Apologies in advance for the long = post, but there are a lot of parts to this discussion that I=E2=80=99m = hoping we can kick off here. >>=20 >> My core proposal is that we see the AS as the component that has the = following properties: >> - receives delegation requests from the client instance for access = to an RS via access tokens, and for access to subject information = returned directly to the client instance >> - collects consent and authorization from the RO for the delegation >> - issues access tokens that its downstream RS=E2=80=99s can = interpret (and validate/accept) >> - issues subject information asserted by the AS=20 >>=20 >> This framing of the parties is really important in making a = consistent understanding of how the protocol works, and a consistent = understanding is vital if we=E2=80=99re going to function as a working = group in both discussing the problem space and executing the solution = space. For a historical example, a naive approach to adding identity on = top of a protocol like OAuth 2 (or GNAP) is to declare that the resource = server is the thing the user is logging in to. This seems reasonable at = first (and some people tried doing this) but it violates all kinds of = trust boundaries and puts new expectations on the different parties that = do not make sense. It stops looking anything like OAuth very quickly and = turns into another protocol. If instead we say the user is logging in to = the client, things suddenly make a lot more sense and we can do a lot = more with it. (See this blog post from 2013 for one take on that = discussion: = https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/ = ) >>=20 >> I think we=E2=80=99ve got a similar situation here when we start to = talk about the user bringing their own AS with them. I think this is a = reasonable-seeming assumption but it=E2=80=99s based on a false premise = that the RO has to log into the AS to approve the request, and the AS = has full control and view over everything in the network. While OAuth = doesn=E2=80=99t require this, it=E2=80=99s largely assumed that=E2=80=99s = how it works. After all, all of the early OAuth deployments worked = exactly this way: the user logs in and clicks the =E2=80=9COK=E2=80=9D = button. However, cloud deployments have shown us that it=E2=80=99s = perfectly reasonable for an OAuth AS to take in its consent and user = information from an external trusted source, and so this model is not = even accurate in OAuth. >>=20 >> In short, I think we can do a better job here of defining things in = terms that both accept the reality we face and enable new ideas in ways = that make sense. It=E2=80=99s my stance that the user shouldn=E2=80=99t = need to bring the AS with them in order to have the kind of input and = control of the system that people are asking for. Instead, the AS should = be able to take inputs from things that the user controls in order for = the AS to do its job. >>=20 >> People have discussed privacy concerns with the AS knowing =E2=80=9Ctoo= much=E2=80=9D, but in many of those discussions the knowledge is simply = pushed to the RS instead. What I=E2=80=99m observing here is really just = pushing portions of the AS role into the =E2=80=9CRS=E2=80=9D = deployment. This doesn=E2=80=99t make it less of an =E2=80=9CAS=E2=80=9D = role, it=E2=80=99s just being fulfilled closely to where the RS role is = fulfilled. As such, my proposal is really not that different in = practice, but the labels are different and better aligned with the = capabilities of the protocol.=20 >>=20 >> We=E2=80=99ve previously talked about separating the user-facing = portions of the AS into another component, and I think now might be the = time to do that. This is a very flammable strawman proposal, but what if = we had the AS defined, as above, and the =E2=80=9Cconsent and = authorization=E2=80=9D gathering portion is augmented by another named = component. Here let=E2=80=99s call it an Interaction Component. This can = take several forms based on the kind of interaction mode in use: >>=20 >> - Hosted at a URL the user is redirected to; it can then make the = user log in, consent, and whatever else they need to do >> - Hosted at a URL the user will load separately and enter in an = access code >> - An app on the user=E2=80=99s device that the user interacts with = directly and which sends information back to the AS >> - An app reachable by a messaging endpoint that the AS sends and = receives structured information from >> - The client itself that is given an indication as to what = information the AS needs in order to fulfill the request; this could be = MFA challenge/response, user credentials, signed claims, etc. >>=20 >> It=E2=80=99s the AS=E2=80=99s job to accept any and all of these that = it supports and churn those into an access token.=20 >>=20 >> The AS itself doesn=E2=80=99t ever need to have the user log in. The = AS doesn=E2=80=99t necessarily need to even know who the user is in any = way. The AS just needs to know from a trusted source that the request is = approved. >>=20 >> =46rom a practical standpoint, I think this will have some small = changes in how we talk about the components and how we talk about the = interaction phase of the grant negotiation process. Everything I=E2=80=99m= laying out here is currently allowed by the spec, but I think we=E2=80=99= ve carried through the same assumptions from OAuth 2 about deployment = that are both inaccurate and confusing.=20 >>=20 >> =E2=80=94 Justin >> --=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 = >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_F5400E46-B178-4793-B0BD-979422D9C086 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    On = Mar 15, 2021, at 10:16 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    Hi = Justin,

    I have = exactly the same two questions as Fabien and also, I worry about the = handwaving in the answer to = 7.

    The = handwaving is actually important. I don=E2=80=99t think that=E2=80=99s = something that GNAP will solve in a universal way. We can have hooks in = the core protocol that say =E2=80=9Cand now go do This Other Thing to = talk to an agent=E2=80=9D, but I don=E2=80=99t think we=E2=80=99re = really the best ones to decide what that is or what it looks like for = everyone. 

    This could be = DIDComm, it could be CHAPI, it could be some proprietary app connection = with push notifications, it could be writing/reading from a shared = encryption storage fabric =E2=80=94 all that=E2=80=99s important here is = that GNAP has a place in the protocol where these various things can = fit. 

    OAuth chose HTTP = Redirects as The Way to get users involved in the process, but GNAP is = taking a very different stance in trying to get away from that limiting = assumption. I don=E2=80=99t think it would serve us to just make a = different limiting assumption about how users (and their decisions) get = involved.

    To answer the = questions;

    - = we're covering the use case "get my medical data", how does that change = if that's someone else's = data? 

    It=E2=80=99s the same process as = the second flow. The RO is the patient or doctor or someone who can = approve things. The AS doesn=E2=80=99t get everything that it needs to = from the agent introduced by the client, so it needs to access another = agent.

    - = what happens if the agent can't guarantee = availability? 

    Then the AS doesn=E2=80=99t get = what it needs in order to fulfill the request and it denies the request. = Whether that=E2=80=99s a timeout or some other error, and whether that = comes back to the client with a =E2=80=9Ctry again=E2=80=9D or with a = =E2=80=9Ctough luck, go away=E2=80=9D, I think that=E2=80=99s all up for = debate, and parts of that we=E2=80=99ll need answers for. But = ultimately, it=E2=80=99s the same kind of thing that happens in OAuth if = the user doesn=E2=80=99t consent, or the user can=E2=80=99t log in, or = the =E2=80=9Cwrong=E2=80=9D user logs in for what=E2=80=99s being asked = for =E2=80=94 the AS isn=E2=80=99t satisfied with the approval so the = delegation request fails.

    Your flow for 8 doesn't make = sense to me because I assume the client is on the RO's mobile device and = unavailable for most interactions. The whole point of having the Agent = is to keep the RO Client out of the picture when the requesting party = shows up with their Client.

    The RO doesn=E2=80=99t have a client in any of the = flows below. The RO might have an agent, they might have an app that = notifies them to go log into a webpage asynchronously, they might get an = email with a link to click back at the AS. None of that is facilitated = through the RO=E2=80=99s client because the RO doesn=E2=80=99t have a = =E2=80=9Cclient=E2=80=9D in this model. The client is by definition the = software in front of the =E2=80=9Cuser=E2=80=9D, the requesting = party. 

    And it=E2=80=99s = important in the design that the client doesn=E2=80=99t need to know = about any of that. It can identify the resource, possibly identify the = RO, and it can tell the AS =E2=80=9Cthis is how I can talk to the person = sitting in front of me right now=E2=80=9D =E2=80=94 for whatever = definition of =E2=80=9Ctalk to=E2=80=9D makes sense for the client app. = What it can=E2=80=99t reliably do is say =E2=80=9Cthis is how I can get = in touch with an RO that I=E2=80=99m not talking to=E2=80=9D, and = certainly not communicate with another client, another AS, or other part = of the GNAP protocol. 

     - = Justin


    Adrian

    On Mon, Mar = 15, 2021 at 10:12 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Hi = Justin,

    I have = exactly the same two questions as Fabien and also, = I 

    On Mon, Mar 15, 2021 at 9:45 PM Fabien = Imbault <fabien.imbault@gmail.com> wrote:
    Hi Justin

    A few questions :
    - we're covering the use case "get my medical data", how does = that change if that's someone else's data? 
    - what happens if the agent can't guarantee = availability? 

    Fabien 


    Le lun. 15 mars 2021 =C3=A0 20:42, Justin Richer = <jricher@mit.edu> a =C3=A9crit :
    Hi = Adrian, thanks so much for writing up this use case. I=E2=80=99ve = included some thoughts below into how different aspects of GNAP might = map to these requirements. I don=E2=80=99t think mapping any human = system to any technology is clean and dry, but for what it=E2=80=99s = worth I do see a lot of alignment.

    On Mar = 12, 2021, at 4:34 PM, Adrian Gropper <agropper@healthurl.com> = wrote:

    Let=E2=80=99s try to map a real-world use-case into the names = and roles we are discussing. The use-case is documented as the API Task = Force Recommendations (2016) https://www.healthit.gov/sites/default/files/facas/SingleSource= ofTruth-APITFRecommendations.pdf = and I=E2=80=99ve copied below the most relevant section. Bold = highlight is in the original. I=E2=80=99ve added bold italic = because it may be important to our discussion. 
    <quote>

    • ONC should clarify = that while API Providers may impose security related restrictions on app = access (e.g. rate limiting, encryption, and expiration of access = tokens), it is inappropriate for API providers to set limitations on = what a patient authorized app can do with data = downstream.

      • Given the nature of = patient access rights, the provider is not in a legal position to = prevent the registration of apps that would aggregate or share data, for = example (though the provider might certainly decide to warn the patient, = or endeavor to educate and explain these issue to the patient, as part = of the provider hosted app approval workflow).
    • ONC should clarify = that API providers are not = obligated to protect = patients by identifying "suspicious" apps. API providers may = suspend API access to an app that has = breached the API provider's terms of service , or appears to have been = compromised, or if the app poses a threat to the provider's own system. = However, patients must be able to override this = suspension (except in the = case where an app poses threat to the provider's own system or violates = allowable terms of service).

    </quote>

    The= key requirements from a patient rights and privacy perspective = are:

    1. To delegate a = scope-limited access capability to anyone anywhere without having to = explain or justify that to the API = Provider.

    This will always be = susceptible to the level of granularity that the API Provider allows the = API to be accessed in. 

    Standard APIs (which would result in = standard =E2=80=9Ctype=E2=80=9D values in the =E2=80=9Caccess=E2=80=9D = request array) can help with this by defining sufficient levels of = detail. But ultimately, the user could never ask for a scope that the = API Provider isn=E2=80=99t willing to express.

    1. To allow the = patient to automate the issue of a scope-limited access capability by = delegating the authority to process API access requests to some agent. = The API Provider has no say in who or where this agent = is.

    This is where I think = this discussion really should go. On the surface, this seems to lead to = the =E2=80=9Cbring your own AS=E2=80=9D model. I am contending that = it=E2=80=99s more powerful to have an AS (still under the API = Provider=E2=80=99s control) that allows the user to provide additional = inputs during the protocol process. As an industry, we can standardize = and innovate a lot of those inputs, but ultimately GNAP should be able = to just connect those endpoints to each other (in my opinion). One of = the common inputs is going to remain =E2=80=9Cget someone to log in at = this webpage at the AS and click a button=E2=80=9D, but I=E2=80=99m = convinced there will be others.

    1. The automation of = the agent is based on policies provided by the patient. The agent is = able to process access requests from anyone and is responsible only to = the patient. The agent responds to successful requests by issuing a = filtered capability to the requesting = party.

    In this case, = shouldn=E2=80=99t it be that the agent is separated from the AS? Since = the patient is going to have data protected by different API Provders, = to me it stands to reason that they=E2=80=99d want the same agent acting = for them on different systems. Each of those systems would still have = its own AS, but the AS would be facilitated by the user=E2=80=99s = input.

    Now = this is NOT saying that the user would have their own AS to delegate = something to the downstream AS. Or even saying that the user would have = some kind of XACML policy server. I=E2=80=99m not sure exactly how the = bits on the wire would work but a strawman would look something = like:


    3D"https://www.websequencediagrams.com/?png=3Dmsc978356221"

    User -> Client: go access my medical data
    Client -> RS: hey I want to access this medical = data
    RS -> Client: sure go talk to this = AS
    Client -> Agent: I need to make a request for = data, how can I get the AS in touch with you?
    Agent = -> Client: tell them to use [some kind of magic]
    Client -> AS: hey I want to access this medical data; I = can get the user to interact with you or I can put you in touch with = their policy agent
    AS -> Client: OK I=E2=80=99ll = talk to the policy agent
    AS -> Agent: I have a = request for data, I need you to prove that you have the right to release = this data
    Agent -> User: It looks like Client is = asking for stuff at RS through AS, that cool?
    Agent = -> AS: OK, here you go [more magic]
    AS -> = Client: ok, here=E2=80=99s an access token that=E2=80=99s good for = accessing that AS
    Client -> RS: hey, I want to = access this medical data and here=E2=80=99s an access token for = it


    1. To ensure that the = requesting party can delegate the capability using an institutional = workflow system that they trust and the patient doesn=E2=80=99t know or = care about. In many cases, the workflow system will pass the capability = to some other person, who we might call the end user. In other cases, = the requesting party may forward the capability directly to another = person using, for example, an email. Either way, the client app used by = the end-user to access the API is of no concern to the patient or to the = patient=E2=80=99s = agent. 
    <= div class=3D"">
    To facilitate this, = the =E2=80=9Cagent=E2=80=9D above can be augmented with other = capabilities based on what=E2=80=99s being asked for. Adding a line to = the flow above:

    User -> Client: go access my medical = data
    Client -> RS: hey I want to access this = medical data
    RS -> Client: sure go talk to this = AS
    Client -> Agent: I need to make a request for = data, how can I get the AS in touch with you?
    Agent = -> Client: tell them to use [some kind of magic]
    Client -> AS: hey I want to access this medical data; I = can get the user to interact with you or I can put you in touch with = their policy agent
    AS -> Client: OK I=E2=80=99ll = talk to the policy agent
    AS -> Agent: I have a = request for data, I need you to prove that you have the right to release = this data
    Agent -> User: It looks like Client is = asking for stuff at RS through AS, that cool?
    Agent = -> AS: OK, here you go [more magic]
    AS -> RO: It looks like someone's asking for an RS you = have the approval for, that cool?
    AS -> = Client: ok, here=E2=80=99s an access token that=E2=80=99s good for = accessing that AS
    Client -> RS: hey, I want to = access this medical data and here=E2=80=99s an access token for = it

    In other = words, when the AS gets the request, it can and should take in inputs = from multiple different dimensions in order to make the authorization = decision and encode that into the access token.

    1. To ensure that the = API Provider does not censor the client app that presents the capability = or solicits too much information about the client app or the end-user of = the client = app. 

    This is one of the = reasons that the AS-based model is really important in GNAP =E2=80=94 = the API Provider's RS only needs to know =E2=80=9Cis this token good for = what=E2=80=99s being asked=E2=80=9D. 

    1. If the API Provider = decides, for any reason, to be =E2=80=9Csuspicious=E2=80=9D (as above) = of the access transaction based on the information it has, it should be = possible for the API Provider to warn the patient and to accept an = override of the warning by the patient. This effectively means that the = end-user will provide as much information as they think will be = necessary in order to either avoid =E2=80=9Csuspicion=E2=80=9D or risk = waiting for patient = override.

    If the AS can reach out = to the patient through notice and consent, they can be brought into the = process in an interactive way above. This assumes the AS has a way of = connecting that, but we should assume the AS can provide this kind of = notice and consent to parties that aren=E2=80=99t directly involved in = the protocol flow in the same way the end user is.

    1. The policies by = which the patient or the decides to grant a capability to the requesting = party are never shared outside of the patient-agent trust relationship. = In other words, neither the patient nor the agent is asked to share or = explain their reason for an access = decision. 

    In the above = pattern, the AS and agent would need a way to communicate this with each = other. I think the details of this are outside the scope of GNAP but it = could take the form of a query/response fulfillment language. VC=E2=80=99s= address part of this, but I think there will need to be other aspects = brought to bear here. I think you could have a privacy-preserving = protocol that would layer into GNAP here, but I don=E2=80=99t know for = sure what that would look like.

    1. Access requests to = the agent are presumed confidential among the patient, the agent, and = whatever client the requesting party uses to present an access request. = The API Provider does not get to see the requests and no entity in the = GNAP authorization process, other than the patient or the agent, gets to = correlate across requests by different requesting party = clients.

    This would be a = different kind of model, where the client would act as some kind of = proxy in the process. Something more like:

    3D"https://www.websequencediagrams.com/?png=3Dmsc685845457"

    User -> Client: go access my medical data
    Client -> RS: hey I want to access this medical = data
    RS -> Client: sure go talk to this = AS
    Client -> Agent: I need to make a request for = data, how can I get the AS in touch with you?
    Agent = -> Client: tell them to use [some kind of magic]
    Client -> AS: hey I want to access this medical data; I = can get the user to interact with you or I can forward your request = details to the policy agent
    AS -> Client: OK go = talk to the policy agent, ask for these kinds of things
    Client -> Agent: I have a request for data, at this AS, I = need you to prove that you have the right to release this data
    Agent -> User: It looks like Client is asking for stuff at = RS through AS, that cool?
    Agent -> Client: OK, = here you go [more magic]
    Client -> AS: Here=E2=80=99= s the result of that policy thing you asked for [more magic]
    AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99= s good for accessing that AS
    Client -> RS: hey, = I want to access this medical data and here=E2=80=99s an access token = for it



    Note that I am not saying all 8 requirements are in scope for = GNAP but I am asking for GNAP to allow for this level of privacy on the = part of self-sovereign patients using self-sovereign agents and the = self-sovereign licensed professionals they deal = with.

    For me the important = part is that GNAP allow these kinds of trust connections. Even if GNAP = isn=E2=80=99t solving every piece of this equation, it can at least = clearly state =E2=80=9Cthere=E2=80=99s a function here that needs to / = is able to solve this thing=E2=80=9D and build the important parts = around it.


     - Justin


    Adrian


    On Fri, Mar 12, 2021 at 2:50 PM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Hi = Justin, 

    Just a = quick word to say I very much agree with both the observations and the = framing.

    Fabien

    On Fri, Mar = 12, 2021 at 6:07 PM Justin Richer <jricher@mit.edu> = wrote:
    As discussed at the IETF = meeting, the editors proposed that one of our next big topic areas was = going to be the nature of the AS role within the GNAP protocol, = especially how it relates to the device-driven use cases that have been = brought up. Apologies in advance for the long post, but there are a lot = of parts to this discussion that I=E2=80=99m hoping we can kick off = here.

    My core = proposal is that we see the AS as the component that has the following = properties:
     - receives delegation requests = from the client instance for access to an RS via access tokens, and for = access to subject information returned directly to the client = instance
     - collects consent and authorization = from the RO for the delegation
     - issues = access tokens that its downstream RS=E2=80=99s can interpret (and = validate/accept)
     - issues subject information = asserted by the AS 

    This framing of the parties is really = important in making a consistent understanding of how the protocol = works, and a consistent understanding is vital if we=E2=80=99re going to = function as a working group in both discussing the problem space and = executing the solution space. For a historical example, a naive approach = to adding identity on top of a protocol like OAuth 2 (or GNAP) is to = declare that the resource server is the thing the user is logging in to. = This seems reasonable at first (and some people tried doing this) but it = violates all kinds of trust boundaries and puts new expectations on the = different parties that do not make sense. It stops looking anything like = OAuth very quickly and turns into another protocol. If instead we say = the user is logging in to the client, things suddenly make a lot more = sense and we can do a lot more with it. (See this blog post from 2013 = for one take on that discussion: https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sig= n-in-4/)

    I = think we=E2=80=99ve got a similar situation here when we start to talk = about the user bringing their own AS with them. I think this is a = reasonable-seeming assumption but it=E2=80=99s based on a false premise = that the RO has to log into the AS to approve the request, and the AS = has full control and view over everything in the network. While OAuth = doesn=E2=80=99t require this, it=E2=80=99s largely assumed that=E2=80=99s = how it works. After all, all of the early OAuth deployments worked = exactly this way: the user logs in and clicks the =E2=80=9COK=E2=80=9D = button. However, cloud deployments have shown us that it=E2=80=99s = perfectly reasonable for an OAuth AS to take in its consent and user = information from an external trusted source, and so this model is not = even accurate in OAuth.

    In short, I think we can do a better job here of defining = things in terms that both accept the reality we face and enable new = ideas in ways that make sense. It=E2=80=99s my stance that the user = shouldn=E2=80=99t need to bring the AS with them in order to have the = kind of input and control of the system that people are asking for. = Instead, the AS should be able to take inputs from things that the user = controls in order for the AS to do its job.

    People have discussed privacy concerns = with the AS knowing =E2=80=9Ctoo much=E2=80=9D, but in many of those = discussions the knowledge is simply pushed to the RS instead. What I=E2=80= =99m observing here is really just pushing portions of the AS role into = the =E2=80=9CRS=E2=80=9D deployment. This doesn=E2=80=99t make it less = of an =E2=80=9CAS=E2=80=9D role, it=E2=80=99s just being fulfilled = closely to where the RS role is fulfilled. As such, my proposal is = really not that different in practice, but the labels are different and = better aligned with the capabilities of the = protocol. 

    We=E2=80=99ve previously talked about separating the = user-facing portions of the AS into another component, and I think now = might be the time to do that. This is a very flammable strawman = proposal, but what if we had the AS defined, as above, and the = =E2=80=9Cconsent and authorization=E2=80=9D gathering portion is = augmented by another named component. Here let=E2=80=99s call it an = Interaction Component. This can take several forms based on the kind of = interaction mode in use:

     - Hosted at a URL the user is redirected to; it can = then make the user log in, consent, and whatever else they need to = do
     - Hosted at a URL the user will load = separately and enter in an access code
     - An = app on the user=E2=80=99s device that the user interacts with directly = and which sends information back to the AS
     - = An app reachable by a messaging endpoint that the AS sends and receives = structured information from
     - The client = itself that is given an indication as to what information the AS needs = in order to fulfill the request; this could be MFA challenge/response, = user credentials, signed claims, etc.

    It=E2=80=99s the AS=E2=80=99s job to = accept any and all of these that it supports and churn those into an = access token. 

    The AS itself doesn=E2=80=99t ever need to have the user log = in. The AS doesn=E2=80=99t necessarily need to even know who the user is = in any way. The AS just needs to know from a trusted source that the = request is approved.

    =46rom a practical standpoint, I think this will have some = small changes in how we talk about the components and how we talk about = the interaction phase of the grant negotiation process. Everything I=E2=80= =99m laying out here is currently allowed by the spec, but I think = we=E2=80=99ve carried through the same assumptions from OAuth 2 about = deployment that are both inaccurate and confusing. 

     =E2=80=94 = Justin
    --
    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
    =
    = --Apple-Mail=_F5400E46-B178-4793-B0BD-979422D9C086-- From nobody Tue Mar 16 06:20:01 2021 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 5D0773A0D6A for ; Tue, 16 Mar 2021 06:20:00 -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 Tic5hOlklhdc for ; Tue, 16 Mar 2021 06:19:55 -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 7E8673A0D69 for ; Tue, 16 Mar 2021 06:19:55 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id f20so37035944ioo.10 for ; Tue, 16 Mar 2021 06:19: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=+MpOL5gkNzVHfx3prvkruP/VoRt/kQG2mPYq2EFduPI=; b=g5p9LkBbCbj6pmLSXV0mE5UQkd2hDSZChsVvsU54s32AZgk5umRKx5crP6k+3kW6S0 j9dCPnQlW5QEh9MNwJy7FSZpCEunH1sarKZM5ma9z1NuXywtOJxwVoj5hLVBKWVz2yge HirODnGivlceChMAXgQG6ia6ax2K+IlYxVOCw5NnbEPI4hTCSvZbcd/QizKzEuVVM2oN R0Q9GbxPmkJeq5VxSl+ktkfCiP5tALZPiiIlhATgsUlioJR3JyKdHihpwnfVy5TnHqvu AtrVcUYEs+9P7CaI+bswPOcfK6Zg5oFnJRPik0+J1hQzwvXorWUmO/jNlc4WfhepDxcO UbTA== 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=+MpOL5gkNzVHfx3prvkruP/VoRt/kQG2mPYq2EFduPI=; b=tDMei8hQUpLa7edJ6DRcfKa/+Ubgl6Qofzrfd59ryU4ibX2u/fS5KG8GsKfAByAI4A UQ1zZ/PRFzk/PLKRfD+PbfpexJuRtiebw6wurPtP7fg2cRgLTItwKeHAk/Oe1kNM41Tl gz+iUHMTj3LFQNKQU2VCsQSOrc9IeWmO+NSrD+BSagLmNX08qW9APUNcVwzpbbZtnVUU IVTAQ8Qmgp2/CbueuTlByD6r0Kj0cZbAyBnHCRg40J3kozQ2aPSNC+75mDoCJb2RRqlu P2yxcTgDn0l3NpHneC16lpewi+4nnjTXEcNABvp7tbNthzTIzZ7Dxej0ymsm8kb5yb36 e6gQ== X-Gm-Message-State: AOAM531i8NrrOLNOukXSXBgwTRBjEEZQrkVQ1X7tzsNMiebifACTf2tc 1AOVClFc+JcAWF7mTADCheiVZATfCkEckIl7QUw= X-Google-Smtp-Source: ABdhPJwSpibU8CUx6C1glio4pGK9PSYnbBZmYfuONMzpDsMrOM9+k9tmjf3KNFDtu9rzO8n01bFWHM7LeHZVNpq+3OM= X-Received: by 2002:a5d:8c8f:: with SMTP id g15mr3236705ion.162.1615900792793; Tue, 16 Mar 2021 06:19:52 -0700 (PDT) MIME-Version: 1.0 References: <205ACFE1-7D4C-4D7C-B394-4AD8A4D4D080@mit.edu> <4AD539F3-31BE-4162-BE2B-69D5AE22B48E@mit.edu> In-Reply-To: <4AD539F3-31BE-4162-BE2B-69D5AE22B48E@mit.edu> From: Fabien Imbault Date: Tue, 16 Mar 2021 14:19:41 +0100 Message-ID: To: Justin Richer Cc: Adrian Gropper , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000bf2afc05bda7380d" Archived-At: Subject: Re: [GNAP] GNAP Architecture and the role of the AS X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 13:20:00 -0000 --000000000000bf2afc05bda7380d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Justin, My comments in red [FIM]. Cheers Fabien On Tue, Mar 16, 2021 at 1:14 PM Justin Richer wrote: > On Mar 15, 2021, at 10:16 PM, Adrian Gropper > wrote: > > Hi Justin, > > I have exactly the same two questions as Fabien and also, I worry about > the handwaving in the answer to 7. > > > The handwaving is actually important. I don=E2=80=99t think that=E2=80=99= s something that > GNAP will solve in a universal way. We can have hooks in the core protoco= l > that say =E2=80=9Cand now go do This Other Thing to talk to an agent=E2= =80=9D, but I don=E2=80=99t > think we=E2=80=99re really the best ones to decide what that is or what i= t looks > like for everyone. > > This could be DIDComm, it could be CHAPI, it could be some proprietary ap= p > connection with push notifications, it could be writing/reading from a > shared encryption storage fabric =E2=80=94 all that=E2=80=99s important h= ere is that GNAP > has a place in the protocol where these various things can fit. > > OAuth chose HTTP Redirects as The Way to get users involved in the > process, but GNAP is taking a very different stance in trying to get away > from that limiting assumption. I don=E2=80=99t think it would serve us to= just make > a different limiting assumption about how users (and their decisions) get > involved. > [FIM] We shouldn't be looking for an universal carrier, I agree, but people will need practical ways to implement that. I think there's a fine line between avoiding limiting assumptions and GNAP remaining too conceptual. At least we should know where to put the extension points. > > To answer the questions; > > - we're covering the use case "get my medical data", how does that change >>> if that's someone else's data? >>> >> > It=E2=80=99s the same process as the second flow. The RO is the patient o= r doctor > or someone who can approve things. The AS doesn=E2=80=99t get everything = that it > needs to from the agent introduced by the client, so it needs to access > another agent. > > - what happens if the agent can't guarantee availability? >>> >> > Then the AS doesn=E2=80=99t get what it needs in order to fulfill the req= uest and > it denies the request. Whether that=E2=80=99s a timeout or some other err= or, and > whether that comes back to the client with a =E2=80=9Ctry again=E2=80=9D = or with a =E2=80=9Ctough > luck, go away=E2=80=9D, I think that=E2=80=99s all up for debate, and par= ts of that we=E2=80=99ll > need answers for. But ultimately, it=E2=80=99s the same kind of thing tha= t happens > in OAuth if the user doesn=E2=80=99t consent, or the user can=E2=80=99t l= og in, or the > =E2=80=9Cwrong=E2=80=9D user logs in for what=E2=80=99s being asked for = =E2=80=94 the AS isn=E2=80=99t satisfied > with the approval so the delegation request fails. > [FIM] seems realistic when user =3D RO, the end-user can make itself available if the service is really important to him. "Tough luck" at first failure is fine then. But I believe that becomes impractical when a remote RO is involved (at least if it's supposed to be a human: if we don't deal with unavailability, async sequence 1.4.3 should be removed). > Your flow for 8 doesn't make sense to me because I assume the client is o= n > the RO's mobile device and unavailable for most interactions. The whole > point of having the Agent is to keep the RO Client out of the picture whe= n > the requesting party shows up with their Client. > > > The RO doesn=E2=80=99t have a client in any of the flows below. The RO mi= ght have > an agent, they might have an app that notifies them to go log into a > webpage asynchronously, they might get an email with a link to click back > at the AS. None of that is facilitated through the RO=E2=80=99s client be= cause the > RO doesn=E2=80=99t have a =E2=80=9Cclient=E2=80=9D in this model. The cli= ent is by definition the > software in front of the =E2=80=9Cuser=E2=80=9D, the requesting party. > [FIM] yes indeed > > And it=E2=80=99s important in the design that the client doesn=E2=80=99t = need to know > about any of that. It can identify the resource, possibly identify the RO= , > and it can tell the AS =E2=80=9Cthis is how I can talk to the person sitt= ing in > front of me right now=E2=80=9D =E2=80=94 for whatever definition of =E2= =80=9Ctalk to=E2=80=9D makes sense > for the client app. What it can=E2=80=99t reliably do is say =E2=80=9Cthi= s is how I can get > in touch with an RO that I=E2=80=99m not talking to=E2=80=9D, and certain= ly not communicate > with another client, another AS, or other part of the GNAP protocol. > [FIM] Not entirely clear where we draw the line. I imagine "person sitting in front of me right now" is not to be taken literally? (could be my doctor, even if he's not in the same room). Clearly there's no way a client can ever guarantee a reliable communication with something else, I agree. At the very best it's a hint (and possibly a bad one). > > - Justin > > > Adrian > > On Mon, Mar 15, 2021 at 10:12 PM Adrian Gropper > wrote: > >> Hi Justin, >> >> I have exactly the same two questions as Fabien and also, I >> >> On Mon, Mar 15, 2021 at 9:45 PM Fabien Imbault >> wrote: >> >>> Hi Justin >>> >>> A few questions : >>> - we're covering the use case "get my medical data", how does that >>> change if that's someone else's data? >>> - what happens if the agent can't guarantee availability? >>> >>> Fabien >>> >>> >>> Le lun. 15 mars 2021 =C3=A0 20:42, Justin Richer a = =C3=A9crit : >>> >>>> Hi Adrian, thanks so much for writing up this use case. I=E2=80=99ve i= ncluded >>>> some thoughts below into how different aspects of GNAP might map to th= ese >>>> requirements. I don=E2=80=99t think mapping any human system to any te= chnology is >>>> clean and dry, but for what it=E2=80=99s worth I do see a lot of align= ment. >>>> >>>> On Mar 12, 2021, at 4:34 PM, Adrian Gropper >>>> wrote: >>>> >>>> Let=E2=80=99s try to map a real-world use-case into the names and role= s we are >>>> discussing. The use-case is documented as the API Task Force >>>> Recommendations (2016) >>>> https://www.healthit.gov/sites/default/files/facas/SingleSourceofTruth= -APITFRecommendations.pdf >>>> and I=E2=80=99ve copied below the most relevant section. Bold highligh= t is in >>>> the original. I=E2=80=99ve added bold italic because it may be importa= nt to >>>> our discussion. >>>> >>>> >>>> >>>> - >>>> >>>> ONC should clarify that while API Providers may impose security >>>> related restrictions on app access (e.g. rate limiting, encryption,= and >>>> expiration of access tokens), it is inappropriate for API providers= to set >>>> limitations on what a patient authorized app can do with data downs= tream. >>>> - Given the nature of patient access rights, the provider is not in >>>> a legal position to prevent the registration of apps that would = aggregate >>>> or share data, for example (though the provider might certainly = decide to >>>> warn the patient, or endeavor to educate and explain these issue= to the >>>> patient, as part of the provider hosted app approval workflow). >>>> - ONC should clarify that API providers are not obligated to >>>> protect patients by identifying "suspicious" apps. API providers ma= y >>>> suspend API access to an app that has breached the API provider's >>>> terms of service , or appears to have been compromised, or if the a= pp poses >>>> a threat to the provider's own system. However, patients must be >>>> able to override this suspension (except in the case where an app >>>> poses threat to the provider's own system or violates allowable ter= ms of >>>> service). >>>> >>>> >>>> >>>> >>>> The key requirements from a patient rights and privacy perspective are= : >>>> >>>> >>>> 1. To delegate a scope-limited access capability to anyone anywhere >>>> without having to explain or justify that to the API Provider. >>>> >>>> >>>> This will always be susceptible to the level of granularity that the >>>> API Provider allows the API to be accessed in. >>>> >>>> Standard APIs (which would result in standard =E2=80=9Ctype=E2=80=9D v= alues in the >>>> =E2=80=9Caccess=E2=80=9D request array) can help with this by defining= sufficient levels of >>>> detail. But ultimately, the user could never ask for a scope that the = API >>>> Provider isn=E2=80=99t willing to express. >>>> >>>> >>>> 1. To allow the patient to automate the issue of a scope-limited >>>> access capability by delegating the authority to process API access >>>> requests to some agent. The API Provider has no say in who or where= this >>>> agent is. >>>> >>>> >>>> This is where I think this discussion really should go. On the surface= , >>>> this seems to lead to the =E2=80=9Cbring your own AS=E2=80=9D model. I= am contending that >>>> it=E2=80=99s more powerful to have an AS (still under the API Provider= =E2=80=99s control) >>>> that allows the user to provide additional inputs during the protocol >>>> process. As an industry, we can standardize and innovate a lot of thos= e >>>> inputs, but ultimately GNAP should be able to just connect those endpo= ints >>>> to each other (in my opinion). One of the common inputs is going to re= main >>>> =E2=80=9Cget someone to log in at this webpage at the AS and click a b= utton=E2=80=9D, but >>>> I=E2=80=99m convinced there will be others. >>>> >>>> >>>> 1. The automation of the agent is based on policies provided by the >>>> patient. The agent is able to process access requests from anyone a= nd is >>>> responsible only to the patient. The agent responds to successful r= equests >>>> by issuing a filtered capability to the requesting party. >>>> >>>> >>>> In this case, shouldn=E2=80=99t it be that the agent is separated from= the AS? >>>> Since the patient is going to have data protected by different API >>>> Provders, to me it stands to reason that they=E2=80=99d want the same = agent acting >>>> for them on different systems. Each of those systems would still have = its >>>> own AS, but the AS would be facilitated by the user=E2=80=99s input. >>>> >>>> Now this is NOT saying that the user would have their own AS to >>>> delegate something to the downstream AS. Or even saying that the user = would >>>> have some kind of XACML policy server. I=E2=80=99m not sure exactly ho= w the bits on >>>> the wire would work but a strawman would look something like: >>>> >>>> >>>> [image: https://www.websequencediagrams.com/?png=3Dmsc978356221] >>>> >>>> User -> Client: go access my medical data >>>> Client -> RS: hey I want to access this medical data >>>> RS -> Client: sure go talk to this AS >>>> Client -> Agent: I need to make a request for data, how can I get the >>>> AS in touch with you? >>>> Agent -> Client: tell them to use [some kind of magic] >>>> Client -> AS: hey I want to access this medical data; I can get the >>>> user to interact with you or I can put you in touch with their policy = agent >>>> AS -> Client: OK I=E2=80=99ll talk to the policy agent >>>> AS -> Agent: I have a request for data, I need you to prove that you >>>> have the right to release this data >>>> Agent -> User: It looks like Client is asking for stuff at RS through >>>> AS, that cool? >>>> Agent -> AS: OK, here you go [more magic] >>>> AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99s good f= or accessing that >>>> AS >>>> Client -> RS: hey, I want to access this medical data and here=E2=80= =99s an >>>> access token for it >>>> >>>> >>>> >>>> 1. To ensure that the requesting party can delegate the capability >>>> using an institutional workflow system that they trust and the pati= ent >>>> doesn=E2=80=99t know or care about. In many cases, the workflow sys= tem will pass >>>> the capability to some other person, who we might call the end user= . In >>>> other cases, the requesting party may forward the capability direct= ly to >>>> another person using, for example, an email. Either way, the client= app >>>> used by the end-user to access the API is of no concern to the pati= ent or >>>> to the patient=E2=80=99s agent. >>>> >>>> >>>> To facilitate this, the =E2=80=9Cagent=E2=80=9D above can be augmented= with other >>>> capabilities based on what=E2=80=99s being asked for. Adding a line to= the flow >>>> above: >>>> >>>> User -> Client: go access my medical data >>>> Client -> RS: hey I want to access this medical data >>>> RS -> Client: sure go talk to this AS >>>> Client -> Agent: I need to make a request for data, how can I get the >>>> AS in touch with you? >>>> Agent -> Client: tell them to use [some kind of magic] >>>> Client -> AS: hey I want to access this medical data; I can get the >>>> user to interact with you or I can put you in touch with their policy = agent >>>> AS -> Client: OK I=E2=80=99ll talk to the policy agent >>>> AS -> Agent: I have a request for data, I need you to prove that you >>>> have the right to release this data >>>> Agent -> User: It looks like Client is asking for stuff at RS through >>>> AS, that cool? >>>> Agent -> AS: OK, here you go [more magic] >>>> *AS -> RO: It looks like someone's asking for an RS you have the >>>> approval for, that cool?* >>>> AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99s good f= or accessing that >>>> AS >>>> Client -> RS: hey, I want to access this medical data and here=E2=80= =99s an >>>> access token for it >>>> >>>> In other words, when the AS gets the request, it can and should take i= n >>>> inputs from multiple different dimensions in order to make the >>>> authorization decision and encode that into the access token. >>>> >>>> >>>> 1. To ensure that the API Provider does not censor the client app >>>> that presents the capability or solicits too much information about= the >>>> client app or the end-user of the client app. >>>> >>>> >>>> This is one of the reasons that the AS-based model is really important >>>> in GNAP =E2=80=94 the API Provider's RS only needs to know =E2=80=9Cis= this token good for >>>> what=E2=80=99s being asked=E2=80=9D. >>>> >>>> >>>> 1. If the API Provider decides, for any reason, to be =E2=80=9Csusp= icious=E2=80=9D >>>> (as above) of the access transaction based on the information it ha= s, it >>>> should be possible for the API Provider to warn the patient and to = accept >>>> an override of the warning by the patient. This effectively means t= hat the >>>> end-user will provide as much information as they think will be nec= essary >>>> in order to either avoid =E2=80=9Csuspicion=E2=80=9D or risk waitin= g for patient override. >>>> >>>> >>>> If the AS can reach out to the patient through notice and consent, the= y >>>> can be brought into the process in an interactive way above. This assu= mes >>>> the AS has a way of connecting that, but we should assume the AS can >>>> provide this kind of notice and consent to parties that aren=E2=80=99t= directly >>>> involved in the protocol flow in the same way the end user is. >>>> >>>> >>>> 1. The policies by which the patient or the decides to grant a >>>> capability to the requesting party are never shared outside of the >>>> patient-agent trust relationship. In other words, neither the patie= nt nor >>>> the agent is asked to share or explain their reason for an access d= ecision. >>>> >>>> >>>> In the above pattern, the AS and agent would need a way to communicate >>>> this with each other. I think the details of this are outside the scop= e of >>>> GNAP but it could take the form of a query/response fulfillment langua= ge. >>>> VC=E2=80=99s address part of this, but I think there will need to be o= ther aspects >>>> brought to bear here. I think you could have a privacy-preserving prot= ocol >>>> that would layer into GNAP here, but I don=E2=80=99t know for sure wha= t that would >>>> look like. >>>> >>>> >>>> 1. Access requests to the agent are presumed confidential among the >>>> patient, the agent, and whatever client the requesting party uses t= o >>>> present an access request. The API Provider does not get to see the >>>> requests and no entity in the GNAP authorization process, other tha= n the >>>> patient or the agent, gets to correlate across requests by differen= t >>>> requesting party clients. >>>> >>>> >>>> This would be a different kind of model, where the client would act as >>>> some kind of proxy in the process. Something more like: >>>> >>>> [image: https://www.websequencediagrams.com/?png=3Dmsc685845457] >>>> >>>> User -> Client: go access my medical data >>>> Client -> RS: hey I want to access this medical data >>>> RS -> Client: sure go talk to this AS >>>> Client -> Agent: I need to make a request for data, how can I get the >>>> AS in touch with you? >>>> Agent -> Client: tell them to use [some kind of magic] >>>> Client -> AS: hey I want to access this medical data; I can get the >>>> user to interact with you or I can forward your request details to the >>>> policy agent >>>> AS -> Client: OK go talk to the policy agent, ask for these kinds of >>>> things >>>> Client -> Agent: I have a request for data, at this AS, I need you to >>>> prove that you have the right to release this data >>>> Agent -> User: It looks like Client is asking for stuff at RS through >>>> AS, that cool? >>>> Agent -> Client: OK, here you go [more magic] >>>> Client -> AS: Here=E2=80=99s the result of that policy thing you asked= for >>>> [more magic] >>>> AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99s good f= or accessing that >>>> AS >>>> Client -> RS: hey, I want to access this medical data and here=E2=80= =99s an >>>> access token for it >>>> >>>> >>>> >>>> Note that I am not saying all 8 requirements are in scope for GNAP but >>>> I am asking for GNAP to allow for this level of privacy on the part of >>>> self-sovereign patients using self-sovereign agents and the self-sover= eign >>>> licensed professionals they deal with. >>>> >>>> >>>> For me the important part is that GNAP allow these kinds of trust >>>> connections. Even if GNAP isn=E2=80=99t solving every piece of this eq= uation, it >>>> can at least clearly state =E2=80=9Cthere=E2=80=99s a function here th= at needs to / is able >>>> to solve this thing=E2=80=9D and build the important parts around it. >>>> >>>> >>>> - Justin >>>> >>>> >>>> Adrian >>>> >>>> >>>> On Fri, Mar 12, 2021 at 2:50 PM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Hi Justin, >>>>> >>>>> Just a quick word to say I very much agree with both the observations >>>>> and the framing. >>>>> >>>>> Fabien >>>>> >>>>> On Fri, Mar 12, 2021 at 6:07 PM Justin Richer wrote= : >>>>> >>>>>> As discussed at the IETF meeting, the editors proposed that one of >>>>>> our next big topic areas was going to be the nature of the AS role w= ithin >>>>>> the GNAP protocol, especially how it relates to the device-driven us= e cases >>>>>> that have been brought up. Apologies in advance for the long post, b= ut >>>>>> there are a lot of parts to this discussion that I=E2=80=99m hoping = we can kick off >>>>>> here. >>>>>> >>>>>> My core proposal is that we see the AS as the component that has the >>>>>> following properties: >>>>>> - receives delegation requests from the client instance for access >>>>>> to an RS via access tokens, and for access to subject information re= turned >>>>>> directly to the client instance >>>>>> - collects consent and authorization from the RO for the delegation >>>>>> - issues access tokens that its downstream RS=E2=80=99s can interpr= et (and >>>>>> validate/accept) >>>>>> - issues subject information asserted by the AS >>>>>> >>>>>> This framing of the parties is really important in making a >>>>>> consistent understanding of how the protocol works, and a consistent >>>>>> understanding is vital if we=E2=80=99re going to function as a worki= ng group in >>>>>> both discussing the problem space and executing the solution space. = For a >>>>>> historical example, a naive approach to adding identity on top of a >>>>>> protocol like OAuth 2 (or GNAP) is to declare that the resource serv= er is >>>>>> the thing the user is logging in to. This seems reasonable at first = (and >>>>>> some people tried doing this) but it violates all kinds of trust bou= ndaries >>>>>> and puts new expectations on the different parties that do not make = sense. >>>>>> It stops looking anything like OAuth very quickly and turns into ano= ther >>>>>> protocol. If instead we say the user is logging in to the client, th= ings >>>>>> suddenly make a lot more sense and we can do a lot more with it. (Se= e this >>>>>> blog post from 2013 for one take on that discussion: >>>>>> https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-= 4/ >>>>>> ) >>>>>> >>>>>> I think we=E2=80=99ve got a similar situation here when we start to = talk >>>>>> about the user bringing their own AS with them. I think this is a >>>>>> reasonable-seeming assumption but it=E2=80=99s based on a false prem= ise that the RO >>>>>> has to log into the AS to approve the request, and the AS has full c= ontrol >>>>>> and view over everything in the network. While OAuth doesn=E2=80=99t= require this, >>>>>> it=E2=80=99s largely assumed that=E2=80=99s how it works. After all,= all of the early OAuth >>>>>> deployments worked exactly this way: the user logs in and clicks the= =E2=80=9COK=E2=80=9D >>>>>> button. However, cloud deployments have shown us that it=E2=80=99s p= erfectly >>>>>> reasonable for an OAuth AS to take in its consent and user informati= on from >>>>>> an external trusted source, and so this model is not even accurate i= n OAuth. >>>>>> >>>>>> In short, I think we can do a better job here of defining things in >>>>>> terms that both accept the reality we face and enable new ideas in w= ays >>>>>> that make sense. It=E2=80=99s my stance that the user shouldn=E2=80= =99t need to bring the >>>>>> AS with them in order to have the kind of input and control of the s= ystem >>>>>> that people are asking for. Instead, the AS should be able to take i= nputs >>>>>> from things that the user controls in order for the AS to do its job= . >>>>>> >>>>>> People have discussed privacy concerns with the AS knowing =E2=80=9C= too >>>>>> much=E2=80=9D, but in many of those discussions the knowledge is sim= ply pushed to >>>>>> the RS instead. What I=E2=80=99m observing here is really just pushi= ng portions of >>>>>> the AS role into the =E2=80=9CRS=E2=80=9D deployment. This doesn=E2= =80=99t make it less of an =E2=80=9CAS=E2=80=9D >>>>>> role, it=E2=80=99s just being fulfilled closely to where the RS role= is fulfilled. >>>>>> As such, my proposal is really not that different in practice, but t= he >>>>>> labels are different and better aligned with the capabilities of the >>>>>> protocol. >>>>>> >>>>>> We=E2=80=99ve previously talked about separating the user-facing por= tions of >>>>>> the AS into another component, and I think now might be the time to = do >>>>>> that. This is a very flammable strawman proposal, but what if we had= the AS >>>>>> defined, as above, and the =E2=80=9Cconsent and authorization=E2=80= =9D gathering portion is >>>>>> augmented by another named component. Here let=E2=80=99s call it an = Interaction >>>>>> Component. This can take several forms based on the kind of interact= ion >>>>>> mode in use: >>>>>> >>>>>> - Hosted at a URL the user is redirected to; it can then make the >>>>>> user log in, consent, and whatever else they need to do >>>>>> - Hosted at a URL the user will load separately and enter in an >>>>>> access code >>>>>> - An app on the user=E2=80=99s device that the user interacts with = directly >>>>>> and which sends information back to the AS >>>>>> - An app reachable by a messaging endpoint that the AS sends and >>>>>> receives structured information from >>>>>> - The client itself that is given an indication as to what >>>>>> information the AS needs in order to fulfill the request; this could= be MFA >>>>>> challenge/response, user credentials, signed claims, etc. >>>>>> >>>>>> It=E2=80=99s the AS=E2=80=99s job to accept any and all of these tha= t it supports and >>>>>> churn those into an access token. >>>>>> >>>>>> The AS itself doesn=E2=80=99t ever need to have the user log in. The= AS >>>>>> doesn=E2=80=99t necessarily need to even know who the user is in any= way. The AS >>>>>> just needs to know from a trusted source that the request is approve= d. >>>>>> >>>>>> From a practical standpoint, I think this will have some small >>>>>> changes in how we talk about the components and how we talk about th= e >>>>>> interaction phase of the grant negotiation process. Everything I=E2= =80=99m laying >>>>>> out here is currently allowed by the spec, but I think we=E2=80=99ve= carried >>>>>> through the same assumptions from OAuth 2 about deployment that are = both >>>>>> inaccurate and confusing. >>>>>> >>>>>> =E2=80=94 Justin >>>>>> -- >>>>>> 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 >>> >> > --000000000000bf2afc05bda7380d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Justin,

    My comments in re= d [FIM].

    Cheers
    Fabien

    On Tue, Mar 16, 20= 21 at 1:14 PM Justin Richer <jricher@= mit.edu> wrote:
    On Mar 15, 2021, at 10:16 PM, Adrian Gropper <agropper@healthurl.com> = wrote:

    Hi Justin,

    <= /div>
    I have exactly the same two questions as Fabien and also, I worry= about the handwaving=C2=A0in the answer=C2=A0to 7.
    =

    The handwaving is actually important. I don=E2= =80=99t think that=E2=80=99s something that GNAP will solve in a universal = way. We can have hooks in the core protocol that say =E2=80=9Cand now go do= This Other Thing to talk to an agent=E2=80=9D, but I don=E2=80=99t think w= e=E2=80=99re really the best ones to decide what that is or what it looks l= ike for everyone.=C2=A0

    This could be DIDComm, it = could be CHAPI, it could be some proprietary app connection with push notif= ications, it could be writing/reading from a shared encryption storage fabr= ic =E2=80=94 all that=E2=80=99s important here is that GNAP has a place in = the protocol where these various things can fit.=C2=A0

    =
    OAuth chose HTTP Redirects as The Way to get users involved in the pro= cess, but GNAP is taking a very different stance in trying to get away from= that limiting assumption. I don=E2=80=99t think it would serve us to just = make a different limiting assumption about how users (and their decisions) = get involved.

    [FIM] We shouldn't be looking for an universal carrier, I = agree, but people will need practical ways to implement that. I think there= 's a fine line between avoiding limiting assumptions and GNAP remaining= too conceptual. At least we should know where to put the extension points.=

    To answer the ques= tions;

    - we're covering the use case "get my me= dical data", how does that change if that's someone else's dat= a?=C2=A0

    It=E2=80=99s the same process as the second flow. The= RO is the patient or doctor or someone who can approve things. The AS does= n=E2=80=99t get everything that it needs to from the agent introduced by th= e client, so it needs to access another agent.

    - what happens if the agent = can't guarantee availability?=C2=A0

    Then the AS doesn=E2=80=99t= get what it needs in order to fulfill the request and it denies the reques= t. Whether that=E2=80=99s a timeout or some other error, and whether that c= omes back to the client with a =E2=80=9Ctry again=E2=80=9D or with a =E2=80= =9Ctough luck, go away=E2=80=9D, I think that=E2=80=99s all up for debate, = and parts of that we=E2=80=99ll need answers for. But ultimately, it=E2=80= =99s the same kind of thing that happens in OAuth if the user doesn=E2=80= =99t consent, or the user can=E2=80=99t log in, or the =E2=80=9Cwrong=E2=80= =9D user logs in for what=E2=80=99s being asked for =E2=80=94 the AS isn=E2= =80=99t satisfied with the approval so the delegation request fails.
    <= /div>
    =C2=A0
    [FIM]=C2=A0 seems realistic when user =3D RO, the end-user can make itself= available if the service is really important to him. "Tough luck"= ; at first failure is fine then.=C2=A0
    But I believe that becomes impractical when=C2=A0a remote RO is involved (at least if it's supposed= to be a human: if we don't deal with=C2=A0unavailability, async sequen= ce 1.4.3 should be removed).=C2=A0
    Your flow f= or 8 doesn't make sense to me because I assume the client is on the RO&= #39;s mobile device and unavailable for most interactions. The whole point = of having the Agent is to keep the RO Client out of the picture when the re= questing party shows up with their Client.

    The RO doesn=E2=80=99t have a client in any of the = flows below. The RO might have an agent, they might have an app that notifi= es them to go log into a webpage asynchronously, they might get an email wi= th a link to click back at the AS. None of that is facilitated through the = RO=E2=80=99s client because the RO doesn=E2=80=99t have a =E2=80=9Cclient= =E2=80=9D in this model. The client is by definition the software in front = of the =E2=80=9Cuser=E2=80=9D, the requesting party.=C2=A0
    [FIM] yes indeed=C2=A0

    And it=E2=80=99s important in = the design that the client doesn=E2=80=99t need to know about any of that. = It can identify the resource, possibly identify the RO, and it can tell the= AS =E2=80=9Cthis is how I can talk to the person sitting in front of me ri= ght now=E2=80=9D =E2=80=94 for whatever definition of =E2=80=9Ctalk to=E2= =80=9D makes sense for the client app. What it can=E2=80=99t reliably do is= say =E2=80=9Cthis is how I can get in touch with an RO that I=E2=80=99m no= t talking to=E2=80=9D, and certainly not communicate with another client, a= nother AS, or other part of the GNAP protocol.=C2=A0

    [FIM] Not entirely clea= r where we draw the line. I imagine "person sitting in front of me rig= ht now" is not to be taken literally? (could be my doctor, even if he&= #39;s not in the same room).
    Clear= ly there's no way a client can ever guarantee a reliable communication = with something else,=C2=A0I agree. At the very best it's a hint (and po= ssibly a bad one).

    = =C2=A0- Justin


    Adrian

    On Mon, Mar 15, 2021 at= 10:12 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Hi Justin,

    I have exactly the same two questions as Fabien and also, I=C2=A0

    On Mon, Mar 15, 2021 at 9:45 PM Fabien Imbault <fabien.imbault@gmail.com> = wrote:
    Hi Justin

    A few= questions :
    - we're covering the use case "= ;get my medical data", how does that change if that's someone else= 's data?=C2=A0
    - what happens if the agent can&#= 39;t guarantee availability?=C2=A0

    Fabien=C2=A0


    Le lun. 15 mars 2021 =C3=A0 20:42, Justin Richer= <jricher@mit.edu> a =C3=A9crit=C2=A0:
    Hi Adrian, thanks so m= uch for writing up this use case. I=E2=80=99ve included some thoughts below= into how different aspects of GNAP might map to these requirements. I don= =E2=80=99t think mapping any human system to any technology is clean and dr= y, but for what it=E2=80=99s worth I do see a lot of alignment.

    Let=E2=80=99s try to map a real-world use-case into the name= s and roles we are discussing. The use-case is documented as the API Task F= orce Recommendations (2016) https://www.healthit.gov/sites/default/files/facas/SingleSourceofTruth= -APITFRecommendations.pdf and I=E2=80=99ve copied below the most relevant = section. Bold highlight is in the original. I=E2=80=99ve added bold italic because it may be important to our di= scussion.=C2=A0

    &l= t;quote>

    • ONC= should clarify that while API Providers may impose security related restri= ctions on app access (e.g. rate limiting, encryption, and expiration of acc= ess tokens), it is inappropriate for API providers to set limitations on wh= at a patient authorized app can do with data downstream.

    • Given the nature of patient access rights, the= provider is not in a legal position to prevent the registration of apps th= at would aggregate or share data, for example (though the provider might ce= rtainly decide to warn the patient, or endeavor to educate and explain thes= e issue to the patient, as part of the provider hosted app approval workflo= w).
  • ONC should clarify that API providers are not obligated to protect patients by identifying &= quot;suspicious" apps. API providers may suspend API access to an app that has breached the API = provider's terms of service , or appears to have been compromised, or i= f the app poses a threat to the provider's own system. However, = patients must be able to override this suspension (except in the case where an app poses= threat to the provider's own system or violates allowable terms of ser= vice).

    </quote>

    • The key requirements from a patient rights an= d privacy perspective are:

    1. To delegate a scope-limited access capability to anyone anywhere without h= aving to explain or justify that to the API Provider.

    This will always= be susceptible to the level of granularity that the API Provider allows th= e API to be accessed in.=C2=A0

    Standard APIs (whic= h would result in standard =E2=80=9Ctype=E2=80=9D values in the =E2=80=9Cac= cess=E2=80=9D request array) can help with this by defining sufficient leve= ls of detail. But ultimately, the user could never ask for a scope that the= API Provider isn=E2=80=99t willing to express.

    1. To allow the patient to automate the issue of a scope-limited = access capability by delegating the authority to process API access request= s to some agent. The API Provider has no say in who or where this agent is.=

    This is where I think this discussion really should go. On the surfac= e, this seems to lead to the =E2=80=9Cbring your own AS=E2=80=9D model. I a= m contending that it=E2=80=99s more powerful to have an AS (still under the= API Provider=E2=80=99s control) that allows the user to provide additional= inputs during the protocol process. As an industry, we can standardize and= innovate a lot of those inputs, but ultimately GNAP should be able to just= connect those endpoints to each other (in my opinion). One of the common i= nputs is going to remain =E2=80=9Cget someone to log in at this webpage at = the AS and click a button=E2=80=9D, but I=E2=80=99m convinced there will be= others.

    1. = The automation of the agent = is based on policies provided by the patient. The agent is able to process = access requests from anyone and is responsible only to the patient. The age= nt responds to successful requests by issuing a filtered capability to the = requesting party.

    In this case, shouldn=E2=80=99t it be that the agent= is separated from the AS? Since the patient is going to have data protecte= d by different API Provders, to me it stands to reason that they=E2=80=99d = want the same agent acting for them on different systems. Each of those sys= tems would still have its own AS, but the AS would be facilitated by the us= er=E2=80=99s input.

    Now this is NOT saying that th= e user would have their own AS to delegate something to the downstream AS. = Or even saying that the user would have some kind of XACML policy server. I= =E2=80=99m not sure exactly how the bits on the wire would work but a straw= man would look something like:



    =
    User -> Client: go access my medical data
    Client -&g= t; RS: hey I want to access this medical data
    RS -> Client: su= re go talk to this AS
    Client -> Agent: I need to make a reques= t for data, how can I get the AS in touch with you?
    Agent -> C= lient: tell them to use [some kind of magic]
    Client -> AS: hey= I want to access this medical data; I can get the user to interact with yo= u or I can put you in touch with their policy agent
    AS -> Clie= nt: OK I=E2=80=99ll talk to the policy agent
    AS -> Agent: I ha= ve a request for data, I need you to prove that you have the right to relea= se this data
    Agent -> User: It looks like Client is asking for= stuff at RS through AS, that cool?
    Agent -> AS: OK, here you = go [more magic]
    AS -> Client: ok, here=E2=80=99s an access tok= en that=E2=80=99s good for accessing that AS
    Client -> RS: hey= , I want to access this medical data and here=E2=80=99s an access token for= it


    1. T= o ensure that the requesting party can delegate the capability using an ins= titutional workflow system that they trust and the patient doesn=E2=80=99t = know or care about. In many cases, the workflow system will pass the capabi= lity to some other person, who we might call the end user. In other cases, = the requesting party may forward the capability directly to another person = using, for example, an email. Either way, the client app used by the end-us= er to access the API is of no concern to the patient or to the patient=E2= =80=99s agent.=C2=A0

    To facilitate this, the =E2=80=9Cagent=E2=80=9D a= bove can be augmented with other capabilities based on what=E2=80=99s being= asked for. Adding a line to the flow above:

    = User -> Client: go access my medical data
    Client -> RS: hey= I want to access this medical data
    RS -> Client: sure go talk= to this AS
    Client -> Agent: I need to make a request for data= , how can I get the AS in touch with you?
    Agent -> Client: tel= l them to use [some kind of magic]
    Client -> AS: hey I want to= access this medical data; I can get the user to interact with you or I can= put you in touch with their policy agent
    AS -> Client: OK I= =E2=80=99ll talk to the policy agent
    AS -> Agent: I have a req= uest for data, I need you to prove that you have the right to release this = data
    Agent -> User: It looks like Client is asking for stuff a= t RS through AS, that cool?
    Agent -> AS: OK, here you go [more= magic]
    AS -> RO: It looks like someone's asking for an= RS you have the approval for, that cool?
    AS -> Client: ok= , here=E2=80=99s an access token that=E2=80=99s good for accessing that AS<= /div>
    Client -> RS: hey, I want to access this medical data and here= =E2=80=99s an access token for it

    In other words, = when the AS gets the request, it can and should take in inputs from multipl= e different dimensions in order to make the authorization decision and enco= de that into the access token.

    1. = To ensure that the API Provider does not censor the client app that present= s the capability or solicits too much information about the client app or t= he end-user of the client app.=C2=A0

    This is one of the reasons that t= he AS-based model is really important in GNAP =E2=80=94 the API Provider= 9;s RS only needs to know =E2=80=9Cis this token good for what=E2=80=99s be= ing asked=E2=80=9D.=C2=A0

    1. If the API= Provider decides, for any reason, to be =E2=80=9Csuspicious=E2=80=9D (as a= bove) of the access transaction based on the information it has, it should = be possible for the API Provider to warn the patient and to accept an overr= ide of the warning by the patient. This effectively means that the end-user= will provide as much information as they think will be necessary in order = to either avoid =E2=80=9Csuspicion=E2=80=9D or risk waiting for patient ove= rride.
    If the AS can reach out to the patient through notice and conse= nt, they can be brought into the process in an interactive way above. This = assumes the AS has a way of connecting that, but we should assume the AS ca= n provide this kind of notice and consent to parties that aren=E2=80=99t di= rectly involved in the protocol flow in the same way the end user is.
    =
    1. The policies by which the patient or the d= ecides to grant a capability to the requesting party are never shared outsi= de of the patient-agent trust relationship. In other words, neither the pat= ient nor the agent is asked to share or explain their reason for an access = decision.=C2=A0

    In the above pattern, the AS and agent would need a wa= y to communicate this with each other. I think the details of this are outs= ide the scope of GNAP but it could take the form of a query/response fulfil= lment language. VC=E2=80=99s address part of this, but I think there will n= eed to be other aspects brought to bear here. I think you could have a priv= acy-preserving protocol that would layer into GNAP here, but I don=E2=80=99= t know for sure what that would look like.

    1. Access requests to the agent are presumed confidential among the pati= ent, the agent, and whatever client the requesting party uses to present an= access request. The API Provider does not get to see the requests and no e= ntity in the GNAP authorization process, other than the patient or the agen= t, gets to correlate across requests by different requesting party clients.=

    This would be a different kind of model, where the client would act a= s some kind of proxy in the process. Something more like:

    3D"https://www.websequencediagrams.com/?png=3Dmsc685845457"

    User -> Client: go access my medical data
    Client -> RS: hey I want to access this medical data
    RS ->= ; Client: sure go talk to this AS
    Client -> Agent: I need to m= ake a request for data, how can I get the AS in touch with you?
    A= gent -> Client: tell them to use [some kind of magic]
    Client -= > AS: hey I want to access this medical data; I can get the user to inte= ract with you or I can forward your request details to the policy agent
    AS -> Client: OK go talk to the policy agent, ask for these kinds= of things
    Client -> Agent: I have a request for data, at this= AS, I need you to prove that you have the right to release this data
    =
    Agent -> User: It looks like Client is asking for stuff at RS throu= gh AS, that cool?
    Agent -> Client: OK, here you go [more magic= ]
    Client -> AS: Here=E2=80=99s the result of that policy thing= you asked for [more magic]
    AS -> Client: ok, here=E2=80=99s a= n access token that=E2=80=99s good for accessing that AS
    Client -= > RS: hey, I want to access this medical data and here=E2=80=99s an acce= ss token for it



    Note that I am not saying all 8 requirements are in scope for= GNAP but I am asking for GNAP to allow for this level of privacy on the pa= rt of self-sovereign patients using self-sovereign agents and the self-sove= reign licensed professionals they deal with.

    For me the important part is that G= NAP allow these kinds of trust connections. Even if GNAP isn=E2=80=99t solv= ing every piece of this equation, it can at least clearly state =E2=80=9Cth= ere=E2=80=99s a function here that needs to / is able to solve this thing= =E2=80=9D and build the important parts around it.


    =C2=A0- Justin


    Adrian


    On Fri, Mar 12, 2021 at 2:50 PM= Fabien Imbault <fabien.imbault@gmail.com> wrote:
    =
    Hi Justi= n,=C2=A0

    Just a quick word to say I very much agree with= both the observations and the framing.

    Fabien

    On Fri, Mar 12, 2021 at 6:07 PM Justin Richer <jricher@mit.edu> wr= ote:
    As dis= cussed at the IETF meeting, the editors proposed that one of our next big t= opic areas was going to be the nature of the AS role within the GNAP protoc= ol, especially how it relates to the device-driven use cases that have been= brought up. Apologies in advance for the long post, but there are a lot of= parts to this discussion that I=E2=80=99m hoping we can kick off here.
    My core proposal is that we see the AS as the component tha= t has the following properties:
    =C2=A0- receives delegation reque= sts from the client instance for access to an RS via access tokens, and for= access to subject information returned directly to the client instance
    =C2=A0- collects consent and authorization from the RO for the deleg= ation
    =C2=A0- issues access tokens that its downstream RS=E2=80= =99s can interpret (and validate/accept)
    =C2=A0- issues subject i= nformation asserted by the AS=C2=A0

    This framing of = the parties is really important in making a consistent understanding of how= the protocol works, and a consistent understanding is vital if we=E2=80=99= re going to function as a working group in both discussing the problem spac= e and executing the solution space. For a historical example, a naive appro= ach to adding identity on top of a protocol like OAuth 2 (or GNAP) is to de= clare that the resource server is the thing the user is logging in to. This= seems reasonable at first (and some people tried doing this) but it violat= es all kinds of trust boundaries and puts new expectations on the different= parties that do not make sense. It stops looking anything like OAuth very = quickly and turns into another protocol. If instead we say the user is logg= ing in to the client, things suddenly make a lot more sense and we can do a= lot more with it. (See this blog post from 2013 for one take on that discu= ssion:=C2=A0https://www.cloudi= dentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/)

    I think we=E2=80=99ve got a similar situation here when we start to= talk about the user bringing their own AS with them. I think this is a rea= sonable-seeming assumption but it=E2=80=99s based on a false premise that t= he RO has to log into the AS to approve the request, and the AS has full co= ntrol and view over everything in the network. While OAuth doesn=E2=80=99t = require this, it=E2=80=99s largely assumed that=E2=80=99s how it works. Aft= er all, all of the early OAuth deployments worked exactly this way: the use= r logs in and clicks the =E2=80=9COK=E2=80=9D button. However, cloud deploy= ments have shown us that it=E2=80=99s perfectly reasonable for an OAuth AS = to take in its consent and user information from an external trusted source= , and so this model is not even accurate in OAuth.

    In short, I think we can do a better job here of defining things in terms = that both accept the reality we face and enable new ideas in ways that make= sense. It=E2=80=99s my stance that the user shouldn=E2=80=99t need to brin= g the AS with them in order to have the kind of input and control of the sy= stem that people are asking for. Instead, the AS should be able to take inp= uts from things that the user controls in order for the AS to do its job.

    People have discussed privacy concerns with the AS = knowing =E2=80=9Ctoo much=E2=80=9D, but in many of those discussions the kn= owledge is simply pushed to the RS instead. What I=E2=80=99m observing here= is really just pushing portions of the AS role into the =E2=80=9CRS=E2=80= =9D deployment. This doesn=E2=80=99t make it less of an =E2=80=9CAS=E2=80= =9D role, it=E2=80=99s just being fulfilled closely to where the RS role is= fulfilled. As such, my proposal is really not that different in practice, = but the labels are different and better aligned with the capabilities of th= e protocol.=C2=A0

    We=E2=80=99ve previously t= alked about separating the user-facing portions of the AS into another comp= onent, and I think now might be the time to do that. This is a very flammab= le strawman proposal, but what if we had the AS defined, as above, and the = =E2=80=9Cconsent and authorization=E2=80=9D gathering portion is augmented = by another named component. Here let=E2=80=99s call it an Interaction Compo= nent. This can take several forms based on the kind of interaction mode in = use:

    =C2=A0- Hosted at a URL the user is redirecte= d to; it can then make the user log in, consent, and whatever else they nee= d to do
    =C2=A0- Hosted at a URL the user will load separately and= enter in an access code
    =C2=A0- An app on the user=E2=80=99s dev= ice that the user interacts with directly and which sends information back = to the AS
    =C2=A0- An app reachable by a messaging endpoint that t= he AS sends and receives structured information from
    =C2=A0- The = client itself that is given an indication as to what information the AS nee= ds in order to fulfill the request; this could be MFA challenge/response, u= ser credentials, signed claims, etc.

    It=E2=80=99s = the AS=E2=80=99s job to accept any and all of these that it supports and ch= urn those into an access token.=C2=A0

    The AS itsel= f doesn=E2=80=99t ever need to have the user log in. The AS doesn=E2=80=99t= necessarily need to even know who the user is in any way. The AS just need= s to know from a trusted source that the request is approved.
    From a practical standpoint, I think this will have some small = changes in how we talk about the components and how we talk about the inter= action phase of the grant negotiation process. Everything I=E2=80=99m layin= g out here is currently allowed by the spec, but I think we=E2=80=99ve carr= ied through the same assumptions from OAuth 2 about deployment that are bot= h inaccurate and confusing.=C2=A0

    =C2=A0=E2=80=94 = Justin
    --
    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

    --000000000000bf2afc05bda7380d-- From nobody Tue Mar 16 07:11:44 2021 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 45C8B3A0EE8 for ; Tue, 16 Mar 2021 07:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.218 X-Spam-Level: X-Spam-Status: No, score=-4.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 MGr0pUQMdDBU for ; Tue, 16 Mar 2021 07:11:36 -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 3F4303A0EDB for ; Tue, 16 Mar 2021 07:11:35 -0700 (PDT) Received: from [192.168.1.22] (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 12GEBTHs001394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 16 Mar 2021 10:11:29 -0400 From: Justin Richer Message-Id: <6B51886D-35F6-443C-B9B6-4C8F22EE11CF@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_2CFE92F0-4730-4D61-9BBA-8798EF1F7A0A" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Tue, 16 Mar 2021 10:11:29 -0400 In-Reply-To: Cc: Adrian Gropper , GNAP Mailing List To: Fabien Imbault References: <205ACFE1-7D4C-4D7C-B394-4AD8A4D4D080@mit.edu> <4AD539F3-31BE-4162-BE2B-69D5AE22B48E@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] GNAP Architecture and the role of the AS X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 14:11:42 -0000 --Apple-Mail=_2CFE92F0-4730-4D61-9BBA-8798EF1F7A0A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Responses inline.. > On Mar 16, 2021, at 9:19 AM, Fabien Imbault = wrote: >=20 > Hi Justin, >=20 > My comments in red [FIM]. >=20 > Cheers > Fabien >=20 > On Tue, Mar 16, 2021 at 1:14 PM Justin Richer > wrote: >> On Mar 15, 2021, at 10:16 PM, Adrian Gropper > wrote: >>=20 >> Hi Justin, >>=20 >> I have exactly the same two questions as Fabien and also, I worry = about the handwaving in the answer to 7. >=20 > The handwaving is actually important. I don=E2=80=99t think that=E2=80=99= s something that GNAP will solve in a universal way. We can have hooks = in the core protocol that say =E2=80=9Cand now go do This Other Thing to = talk to an agent=E2=80=9D, but I don=E2=80=99t think we=E2=80=99re = really the best ones to decide what that is or what it looks like for = everyone.=20 >=20 > This could be DIDComm, it could be CHAPI, it could be some proprietary = app connection with push notifications, it could be writing/reading from = a shared encryption storage fabric =E2=80=94 all that=E2=80=99s = important here is that GNAP has a place in the protocol where these = various things can fit.=20 >=20 > OAuth chose HTTP Redirects as The Way to get users involved in the = process, but GNAP is taking a very different stance in trying to get = away from that limiting assumption. I don=E2=80=99t think it would serve = us to just make a different limiting assumption about how users (and = their decisions) get involved. >=20 > [FIM] We shouldn't be looking for an universal carrier, I agree, but = people will need practical ways to implement that. I think there's a = fine line between avoiding limiting assumptions and GNAP remaining too = conceptual. At least we should know where to put the extension points. I agree that we need to have the extension points in the right place. In = order to do that, we need to know what we=E2=80=99re extending, which = was the impetus for starting this conversation. It=E2=80=99s debatable = how much further we want to go beyond that in GNAP itself, especially = since there are a lot of other protocols out there designed to fit this = niche well (see examples above).=20 One step we definitely can help with is providing a cohesive model for = describing both people and access rights, and being clear about the = overall process. >=20 > To answer the questions; >=20 >> - we're covering the use case "get my medical data", how does that = change if that's someone else's data?=20 >=20 > It=E2=80=99s the same process as the second flow. The RO is the = patient or doctor or someone who can approve things. The AS doesn=E2=80=99= t get everything that it needs to from the agent introduced by the = client, so it needs to access another agent. >=20 >> - what happens if the agent can't guarantee availability?=20 >=20 > Then the AS doesn=E2=80=99t get what it needs in order to fulfill the = request and it denies the request. Whether that=E2=80=99s a timeout or = some other error, and whether that comes back to the client with a = =E2=80=9Ctry again=E2=80=9D or with a =E2=80=9Ctough luck, go away=E2=80=9D= , I think that=E2=80=99s all up for debate, and parts of that we=E2=80=99l= l need answers for. But ultimately, it=E2=80=99s the same kind of thing = that happens in OAuth if the user doesn=E2=80=99t consent, or the user = can=E2=80=99t log in, or the =E2=80=9Cwrong=E2=80=9D user logs in for = what=E2=80=99s being asked for =E2=80=94 the AS isn=E2=80=99t satisfied = with the approval so the delegation request fails. > =20 > [FIM] seems realistic when user =3D RO, the end-user can make itself = available if the service is really important to him. "Tough luck" at = first failure is fine then.=20 > But I believe that becomes impractical when a remote RO is involved = (at least if it's supposed to be a human: if we don't deal with = unavailability, async sequence 1.4.3 should be removed).=20 Then, what is the AS to do if it tries the methods necessary to reach = the RO, but those methods fail? Or if there are multiple RO=E2=80=99s = who could approve and multiple come back?=20 I agree that these are situations the AS is going to have to deal with, = but I also believe that the details of what gets us into these = situations is outside of GNAP itself. Perhaps think of it this way: - The AS needs to gather authorization and consent. - The client can direct interaction with the end user. - The end user might be able to provide that authorization and consent. - The client doesn=E2=80=99t know if the end user is the RO, but it can = provide the AS with hints as to who the end user is and means to = interact with them for the AS. - The AS knows who the RO is and might have ways to interact with them = (and their decisions) outside of the interface with the client. So in other words, the consent-gathering process that the AS goes = through can be both client-mediated and non-client-mediated. The = client-mediated portions are very much in scope of GNAP and they fall = into the space of user =3D=3D RO very easily. The non-client-mediated = interactions are outside the scope of GNAP =E2=80=94 or at least outside = the core protocol, since the core protocol is all about the client = instance getting a token (and/or subject info). I think we can expand the discussion in the draft of how the AS goes = through this consent gathering process but shouldn=E2=80=99t try to = define one specific way of it happening. That way we can define good = behavior around asynchronous methods, timeouts, and multi-user = protocols, but without having to define, say, a wire-based policy = language to carry those decisions. It=E2=80=99s definitely a fine line! >> Your flow for 8 doesn't make sense to me because I assume the client = is on the RO's mobile device and unavailable for most interactions. The = whole point of having the Agent is to keep the RO Client out of the = picture when the requesting party shows up with their Client. >=20 > The RO doesn=E2=80=99t have a client in any of the flows below. The RO = might have an agent, they might have an app that notifies them to go log = into a webpage asynchronously, they might get an email with a link to = click back at the AS. None of that is facilitated through the RO=E2=80=99s= client because the RO doesn=E2=80=99t have a =E2=80=9Cclient=E2=80=9D = in this model. The client is by definition the software in front of the = =E2=80=9Cuser=E2=80=9D, the requesting party.=20 > [FIM] yes indeed=20 >=20 > And it=E2=80=99s important in the design that the client doesn=E2=80=99t= need to know about any of that. It can identify the resource, possibly = identify the RO, and it can tell the AS =E2=80=9Cthis is how I can talk = to the person sitting in front of me right now=E2=80=9D =E2=80=94 for = whatever definition of =E2=80=9Ctalk to=E2=80=9D makes sense for the = client app. What it can=E2=80=99t reliably do is say =E2=80=9Cthis is = how I can get in touch with an RO that I=E2=80=99m not talking to=E2=80=9D= , and certainly not communicate with another client, another AS, or = other part of the GNAP protocol.=20 >=20 > [FIM] Not entirely clear where we draw the line. I imagine "person = sitting in front of me right now" is not to be taken literally? (could = be my doctor, even if he's not in the same room). > Clearly there's no way a client can ever guarantee a reliable = communication with something else, I agree. At the very best it's a hint = (and possibly a bad one). If the doctor isn=E2=80=99t using the client application, then the = doctor=E2=80=99s not the =E2=80=9Cuser=E2=80=9D in protocol terms. If = the AS has some other way to get the doctor involved, it should be able = to do that, but the client can=E2=80=99t really do anything about it. - Justin >=20 > - Justin >=20 >>=20 >> Adrian >>=20 >> On Mon, Mar 15, 2021 at 10:12 PM Adrian Gropper = > wrote: >> Hi Justin, >>=20 >> I have exactly the same two questions as Fabien and also, I=20 >>=20 >> On Mon, Mar 15, 2021 at 9:45 PM Fabien Imbault = > wrote: >> Hi Justin >>=20 >> A few questions : >> - we're covering the use case "get my medical data", how does that = change if that's someone else's data?=20 >> - what happens if the agent can't guarantee availability?=20 >>=20 >> Fabien=20 >>=20 >>=20 >> Le lun. 15 mars 2021 =C3=A0 20:42, Justin Richer > a =C3=A9crit : >> Hi Adrian, thanks so much for writing up this use case. I=E2=80=99ve = included some thoughts below into how different aspects of GNAP might = map to these requirements. I don=E2=80=99t think mapping any human = system to any technology is clean and dry, but for what it=E2=80=99s = worth I do see a lot of alignment. >>=20 >>> On Mar 12, 2021, at 4:34 PM, Adrian Gropper > wrote: >>>=20 >>> Let=E2=80=99s try to map a real-world use-case into the names and = roles we are discussing. The use-case is documented as the API Task = Force Recommendations (2016) = https://www.healthit.gov/sites/default/files/facas/SingleSourceofTruth-API= TFRecommendations.pdf = and I=E2=80=99ve copied below the most relevant = section. Bold highlight is in the original. I=E2=80=99ve added bold = italic because it may be important to our discussion.=20 >>>=20 >>> >>> ONC should clarify that while API Providers may impose security = related restrictions on app access (e.g. rate limiting, encryption, and = expiration of access tokens), it is inappropriate for API providers to = set limitations on what a patient authorized app can do with data = downstream. >>> Given the nature of patient access rights, the provider is not in a = legal position to prevent the registration of apps that would aggregate = or share data, for example (though the provider might certainly decide = to warn the patient, or endeavor to educate and explain these issue to = the patient, as part of the provider hosted app approval workflow). >>> ONC should clarify that API providers are not obligated to protect = patients by identifying "suspicious" apps. API providers may suspend API = access to an app that has breached the API provider's terms of service , = or appears to have been compromised, or if the app poses a threat to the = provider's own system. However, patients must be able to override this = suspension (except in the case where an app poses threat to the = provider's own system or violates allowable terms of service). >>>=20 >>> >>>=20 >>> The key requirements from a patient rights and privacy perspective = are: >>>=20 >>> To delegate a scope-limited access capability to anyone anywhere = without having to explain or justify that to the API Provider. >>=20 >> This will always be susceptible to the level of granularity that the = API Provider allows the API to be accessed in.=20 >>=20 >> Standard APIs (which would result in standard =E2=80=9Ctype=E2=80=9D = values in the =E2=80=9Caccess=E2=80=9D request array) can help with this = by defining sufficient levels of detail. But ultimately, the user could = never ask for a scope that the API Provider isn=E2=80=99t willing to = express. >>=20 >>> To allow the patient to automate the issue of a scope-limited access = capability by delegating the authority to process API access requests to = some agent. The API Provider has no say in who or where this agent is. >>=20 >> This is where I think this discussion really should go. On the = surface, this seems to lead to the =E2=80=9Cbring your own AS=E2=80=9D = model. I am contending that it=E2=80=99s more powerful to have an AS = (still under the API Provider=E2=80=99s control) that allows the user to = provide additional inputs during the protocol process. As an industry, = we can standardize and innovate a lot of those inputs, but ultimately = GNAP should be able to just connect those endpoints to each other (in my = opinion). One of the common inputs is going to remain =E2=80=9Cget = someone to log in at this webpage at the AS and click a button=E2=80=9D, = but I=E2=80=99m convinced there will be others. >>=20 >>> The automation of the agent is based on policies provided by the = patient. The agent is able to process access requests from anyone and is = responsible only to the patient. The agent responds to successful = requests by issuing a filtered capability to the requesting party. >>=20 >> In this case, shouldn=E2=80=99t it be that the agent is separated = from the AS? Since the patient is going to have data protected by = different API Provders, to me it stands to reason that they=E2=80=99d = want the same agent acting for them on different systems. Each of those = systems would still have its own AS, but the AS would be facilitated by = the user=E2=80=99s input. >>=20 >> Now this is NOT saying that the user would have their own AS to = delegate something to the downstream AS. Or even saying that the user = would have some kind of XACML policy server. I=E2=80=99m not sure = exactly how the bits on the wire would work but a strawman would look = something like: >>=20 >>=20 >>=20 >>=20 >> User -> Client: go access my medical data >> Client -> RS: hey I want to access this medical data >> RS -> Client: sure go talk to this AS >> Client -> Agent: I need to make a request for data, how can I get the = AS in touch with you? >> Agent -> Client: tell them to use [some kind of magic] >> Client -> AS: hey I want to access this medical data; I can get the = user to interact with you or I can put you in touch with their policy = agent >> AS -> Client: OK I=E2=80=99ll talk to the policy agent >> AS -> Agent: I have a request for data, I need you to prove that you = have the right to release this data >> Agent -> User: It looks like Client is asking for stuff at RS through = AS, that cool? >> Agent -> AS: OK, here you go [more magic] >> AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99s good = for accessing that AS >> Client -> RS: hey, I want to access this medical data and here=E2=80=99= s an access token for it >>=20 >>=20 >>> To ensure that the requesting party can delegate the capability = using an institutional workflow system that they trust and the patient = doesn=E2=80=99t know or care about. In many cases, the workflow system = will pass the capability to some other person, who we might call the end = user. In other cases, the requesting party may forward the capability = directly to another person using, for example, an email. Either way, the = client app used by the end-user to access the API is of no concern to = the patient or to the patient=E2=80=99s agent.=20 >>=20 >> To facilitate this, the =E2=80=9Cagent=E2=80=9D above can be = augmented with other capabilities based on what=E2=80=99s being asked = for. Adding a line to the flow above: >>=20 >> User -> Client: go access my medical data >> Client -> RS: hey I want to access this medical data >> RS -> Client: sure go talk to this AS >> Client -> Agent: I need to make a request for data, how can I get the = AS in touch with you? >> Agent -> Client: tell them to use [some kind of magic] >> Client -> AS: hey I want to access this medical data; I can get the = user to interact with you or I can put you in touch with their policy = agent >> AS -> Client: OK I=E2=80=99ll talk to the policy agent >> AS -> Agent: I have a request for data, I need you to prove that you = have the right to release this data >> Agent -> User: It looks like Client is asking for stuff at RS through = AS, that cool? >> Agent -> AS: OK, here you go [more magic] >> AS -> RO: It looks like someone's asking for an RS you have the = approval for, that cool? >> AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99s good = for accessing that AS >> Client -> RS: hey, I want to access this medical data and here=E2=80=99= s an access token for it >>=20 >> In other words, when the AS gets the request, it can and should take = in inputs from multiple different dimensions in order to make the = authorization decision and encode that into the access token. >>=20 >>> To ensure that the API Provider does not censor the client app that = presents the capability or solicits too much information about the = client app or the end-user of the client app.=20 >>=20 >> This is one of the reasons that the AS-based model is really = important in GNAP =E2=80=94 the API Provider's RS only needs to know = =E2=80=9Cis this token good for what=E2=80=99s being asked=E2=80=9D.=20 >>=20 >>> If the API Provider decides, for any reason, to be =E2=80=9Csuspicious= =E2=80=9D (as above) of the access transaction based on the information = it has, it should be possible for the API Provider to warn the patient = and to accept an override of the warning by the patient. This = effectively means that the end-user will provide as much information as = they think will be necessary in order to either avoid =E2=80=9Csuspicion=E2= =80=9D or risk waiting for patient override. >>=20 >> If the AS can reach out to the patient through notice and consent, = they can be brought into the process in an interactive way above. This = assumes the AS has a way of connecting that, but we should assume the AS = can provide this kind of notice and consent to parties that aren=E2=80=99t= directly involved in the protocol flow in the same way the end user is. >>=20 >>> The policies by which the patient or the decides to grant a = capability to the requesting party are never shared outside of the = patient-agent trust relationship. In other words, neither the patient = nor the agent is asked to share or explain their reason for an access = decision.=20 >>=20 >> In the above pattern, the AS and agent would need a way to = communicate this with each other. I think the details of this are = outside the scope of GNAP but it could take the form of a query/response = fulfillment language. VC=E2=80=99s address part of this, but I think = there will need to be other aspects brought to bear here. I think you = could have a privacy-preserving protocol that would layer into GNAP = here, but I don=E2=80=99t know for sure what that would look like. >>=20 >>> Access requests to the agent are presumed confidential among the = patient, the agent, and whatever client the requesting party uses to = present an access request. The API Provider does not get to see the = requests and no entity in the GNAP authorization process, other than the = patient or the agent, gets to correlate across requests by different = requesting party clients. >>=20 >> This would be a different kind of model, where the client would act = as some kind of proxy in the process. Something more like: >>=20 >>=20 >>=20 >> User -> Client: go access my medical data >> Client -> RS: hey I want to access this medical data >> RS -> Client: sure go talk to this AS >> Client -> Agent: I need to make a request for data, how can I get the = AS in touch with you? >> Agent -> Client: tell them to use [some kind of magic] >> Client -> AS: hey I want to access this medical data; I can get the = user to interact with you or I can forward your request details to the = policy agent >> AS -> Client: OK go talk to the policy agent, ask for these kinds of = things >> Client -> Agent: I have a request for data, at this AS, I need you to = prove that you have the right to release this data >> Agent -> User: It looks like Client is asking for stuff at RS through = AS, that cool? >> Agent -> Client: OK, here you go [more magic] >> Client -> AS: Here=E2=80=99s the result of that policy thing you = asked for [more magic] >> AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99s good = for accessing that AS >> Client -> RS: hey, I want to access this medical data and here=E2=80=99= s an access token for it >>=20 >>=20 >>>=20 >>> Note that I am not saying all 8 requirements are in scope for GNAP = but I am asking for GNAP to allow for this level of privacy on the part = of self-sovereign patients using self-sovereign agents and the = self-sovereign licensed professionals they deal with. >>=20 >> For me the important part is that GNAP allow these kinds of trust = connections. Even if GNAP isn=E2=80=99t solving every piece of this = equation, it can at least clearly state =E2=80=9Cthere=E2=80=99s a = function here that needs to / is able to solve this thing=E2=80=9D and = build the important parts around it. >>=20 >>=20 >> - Justin >>=20 >>>=20 >>> Adrian >>>=20 >>>=20 >>> On Fri, Mar 12, 2021 at 2:50 PM Fabien Imbault = > wrote: >>> Hi Justin,=20 >>>=20 >>> Just a quick word to say I very much agree with both the = observations and the framing. >>>=20 >>> Fabien >>>=20 >>> On Fri, Mar 12, 2021 at 6:07 PM Justin Richer > wrote: >>> As discussed at the IETF meeting, the editors proposed that one of = our next big topic areas was going to be the nature of the AS role = within the GNAP protocol, especially how it relates to the device-driven = use cases that have been brought up. Apologies in advance for the long = post, but there are a lot of parts to this discussion that I=E2=80=99m = hoping we can kick off here. >>>=20 >>> My core proposal is that we see the AS as the component that has the = following properties: >>> - receives delegation requests from the client instance for access = to an RS via access tokens, and for access to subject information = returned directly to the client instance >>> - collects consent and authorization from the RO for the delegation >>> - issues access tokens that its downstream RS=E2=80=99s can = interpret (and validate/accept) >>> - issues subject information asserted by the AS=20 >>>=20 >>> This framing of the parties is really important in making a = consistent understanding of how the protocol works, and a consistent = understanding is vital if we=E2=80=99re going to function as a working = group in both discussing the problem space and executing the solution = space. For a historical example, a naive approach to adding identity on = top of a protocol like OAuth 2 (or GNAP) is to declare that the resource = server is the thing the user is logging in to. This seems reasonable at = first (and some people tried doing this) but it violates all kinds of = trust boundaries and puts new expectations on the different parties that = do not make sense. It stops looking anything like OAuth very quickly and = turns into another protocol. If instead we say the user is logging in to = the client, things suddenly make a lot more sense and we can do a lot = more with it. (See this blog post from 2013 for one take on that = discussion: = https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/ = ) >>>=20 >>> I think we=E2=80=99ve got a similar situation here when we start to = talk about the user bringing their own AS with them. I think this is a = reasonable-seeming assumption but it=E2=80=99s based on a false premise = that the RO has to log into the AS to approve the request, and the AS = has full control and view over everything in the network. While OAuth = doesn=E2=80=99t require this, it=E2=80=99s largely assumed that=E2=80=99s = how it works. After all, all of the early OAuth deployments worked = exactly this way: the user logs in and clicks the =E2=80=9COK=E2=80=9D = button. However, cloud deployments have shown us that it=E2=80=99s = perfectly reasonable for an OAuth AS to take in its consent and user = information from an external trusted source, and so this model is not = even accurate in OAuth. >>>=20 >>> In short, I think we can do a better job here of defining things in = terms that both accept the reality we face and enable new ideas in ways = that make sense. It=E2=80=99s my stance that the user shouldn=E2=80=99t = need to bring the AS with them in order to have the kind of input and = control of the system that people are asking for. Instead, the AS should = be able to take inputs from things that the user controls in order for = the AS to do its job. >>>=20 >>> People have discussed privacy concerns with the AS knowing =E2=80=9Cto= o much=E2=80=9D, but in many of those discussions the knowledge is = simply pushed to the RS instead. What I=E2=80=99m observing here is = really just pushing portions of the AS role into the =E2=80=9CRS=E2=80=9D = deployment. This doesn=E2=80=99t make it less of an =E2=80=9CAS=E2=80=9D = role, it=E2=80=99s just being fulfilled closely to where the RS role is = fulfilled. As such, my proposal is really not that different in = practice, but the labels are different and better aligned with the = capabilities of the protocol.=20 >>>=20 >>> We=E2=80=99ve previously talked about separating the user-facing = portions of the AS into another component, and I think now might be the = time to do that. This is a very flammable strawman proposal, but what if = we had the AS defined, as above, and the =E2=80=9Cconsent and = authorization=E2=80=9D gathering portion is augmented by another named = component. Here let=E2=80=99s call it an Interaction Component. This can = take several forms based on the kind of interaction mode in use: >>>=20 >>> - Hosted at a URL the user is redirected to; it can then make the = user log in, consent, and whatever else they need to do >>> - Hosted at a URL the user will load separately and enter in an = access code >>> - An app on the user=E2=80=99s device that the user interacts with = directly and which sends information back to the AS >>> - An app reachable by a messaging endpoint that the AS sends and = receives structured information from >>> - The client itself that is given an indication as to what = information the AS needs in order to fulfill the request; this could be = MFA challenge/response, user credentials, signed claims, etc. >>>=20 >>> It=E2=80=99s the AS=E2=80=99s job to accept any and all of these = that it supports and churn those into an access token.=20 >>>=20 >>> The AS itself doesn=E2=80=99t ever need to have the user log in. The = AS doesn=E2=80=99t necessarily need to even know who the user is in any = way. The AS just needs to know from a trusted source that the request is = approved. >>>=20 >>> =46rom a practical standpoint, I think this will have some small = changes in how we talk about the components and how we talk about the = interaction phase of the grant negotiation process. Everything I=E2=80=99m= laying out here is currently allowed by the spec, but I think we=E2=80=99= ve carried through the same assumptions from OAuth 2 about deployment = that are both inaccurate and confusing.=20 >>>=20 >>> =E2=80=94 Justin >>> --=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 = >>=20 >> --=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 = --Apple-Mail=_2CFE92F0-4730-4D61-9BBA-8798EF1F7A0A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Responses inline..

    On Mar = 16, 2021, at 9:19 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    Hi Justin,

    My comments in red [FIM].

    Cheers
    Fabien

    On Tue, Mar 16, 2021 at 1:14 PM Justin = Richer <jricher@mit.edu> wrote:
    On Mar 15, 2021, at 10:16 PM, Adrian Gropper = <agropper@healthurl.com> wrote:

    Hi = Justin,

    I have = exactly the same two questions as Fabien and also, I worry about the = handwaving in the answer to = 7.

    The handwaving is actually important. I don=E2=80=99t = think that=E2=80=99s something that GNAP will solve in a universal way. = We can have hooks in the core protocol that say =E2=80=9Cand now go do = This Other Thing to talk to an agent=E2=80=9D, but I don=E2=80=99t think = we=E2=80=99re really the best ones to decide what that is or what it = looks like for everyone. 

    This could be DIDComm, it could be = CHAPI, it could be some proprietary app connection with push = notifications, it could be writing/reading from a shared encryption = storage fabric =E2=80=94 all that=E2=80=99s important here is that GNAP = has a place in the protocol where these various things can = fit. 

    OAuth= chose HTTP Redirects as The Way to get users involved in the process, = but GNAP is taking a very different stance in trying to get away from = that limiting assumption. I don=E2=80=99t think it would serve us to = just make a different limiting assumption about how users (and their = decisions) get involved.

    [FIM] We shouldn't be looking for an universal carrier, I = agree, but people will need practical ways to implement that. I think = there's a fine line between avoiding limiting assumptions and GNAP = remaining too conceptual. At least we should know where to put the = extension points.

    I agree that we need to have the extension points = in the right place. In order to do that, we need to know what we=E2=80=99r= e extending, which was the impetus for starting this conversation. = It=E2=80=99s debatable how much further we want to go beyond that in = GNAP itself, especially since there are a lot of other protocols out = there designed to fit this niche well (see examples = above). 

    One step we definitely = can help with is providing a cohesive model for describing both people = and access rights, and being clear about the overall process.


    To answer the questions;

    - = we're covering the use case "get my medical data", how does that change = if that's someone else's = data? 

    It=E2=80=99s = the same process as the second flow. The RO is the patient or doctor or = someone who can approve things. The AS doesn=E2=80=99t get everything = that it needs to from the agent introduced by the client, so it needs to = access another = agent.

    - = what happens if the agent can't guarantee = availability? 

    Then the AS doesn=E2=80= =99t get what it needs in order to fulfill the request and it denies the = request. Whether that=E2=80=99s a timeout or some other error, and = whether that comes back to the client with a =E2=80=9Ctry again=E2=80=9D = or with a =E2=80=9Ctough luck, go away=E2=80=9D, I think that=E2=80=99s = all up for debate, and parts of that we=E2=80=99ll need answers for. But = ultimately, it=E2=80=99s the same kind of thing that happens in OAuth if = the user doesn=E2=80=99t consent, or the user can=E2=80=99t log in, or = the =E2=80=9Cwrong=E2=80=9D user logs in for what=E2=80=99s being asked = for =E2=80=94 the AS isn=E2=80=99t satisfied with the approval so the = delegation request fails.
     
    [FIM]  seems realistic when user =3D RO, the end-user = can make itself available if the service is really important to him. = "Tough luck" at first failure is fine then. 
    But I believe that becomes = impractical when a remote RO is involved (at least if it's supposed to = be a human: if we don't deal with unavailability, async sequence = 1.4.3 should be = removed). 

    Then, what is the AS to do if it tries the methods = necessary to reach the RO, but those methods fail? Or if there are = multiple RO=E2=80=99s who could approve and multiple come = back? 

    I agree that these are = situations the AS is going to have to deal with, but I also believe that = the details of what gets us into these situations is outside of GNAP = itself. Perhaps think of it this way:

     - The AS needs to gather authorization and = consent.
     - The client can direct interaction with the end = user.
     - The end user might be able to provide that = authorization and consent.
     - The client doesn=E2=80=99t = know if the end user is the RO, but it can provide the AS with hints as = to who the end user is and means to interact with them for the = AS.
     - The AS knows who the RO is and might have ways to = interact with them (and their decisions) outside of the interface with = the client.

    So in other words, the = consent-gathering process that the AS goes through can be both = client-mediated and non-client-mediated. The client-mediated portions = are very much in scope of GNAP and they fall into the space of user =3D=3D= RO very easily. The non-client-mediated interactions are outside the = scope of GNAP =E2=80=94 or at least outside the core protocol, since the = core protocol is all about the client instance getting a token (and/or = subject info).

    I think we can expand = the discussion in the draft of how the AS goes through this consent = gathering process but shouldn=E2=80=99t try to define one specific way = of it happening. That way we can define good behavior around = asynchronous methods, timeouts, and multi-user protocols, but without = having to define, say, a wire-based policy language to carry those = decisions. It=E2=80=99s definitely a fine line!

    Your flow for 8 doesn't make sense to me = because I assume the client is on the RO's mobile device and unavailable = for most interactions. The whole point of having the Agent is to keep = the RO Client out of the picture when the requesting party shows up with = their Client.

    The RO doesn=E2=80=99t have a client in = any of the flows below. The RO might have an agent, they might have an = app that notifies them to go log into a webpage asynchronously, they = might get an email with a link to click back at the AS. None of that is = facilitated through the RO=E2=80=99s client because the RO doesn=E2=80=99t= have a =E2=80=9Cclient=E2=80=9D in this model. The client is by = definition the software in front of the =E2=80=9Cuser=E2=80=9D, the = requesting party. 
    [FIM] yes = indeed 

    And it=E2=80=99s important in the design that the client = doesn=E2=80=99t need to know about any of that. It can identify the = resource, possibly identify the RO, and it can tell the AS =E2=80=9Cthis = is how I can talk to the person sitting in front of me right now=E2=80=9D = =E2=80=94 for whatever definition of =E2=80=9Ctalk to=E2=80=9D makes = sense for the client app. What it can=E2=80=99t reliably do is say = =E2=80=9Cthis is how I can get in touch with an RO that I=E2=80=99m not = talking to=E2=80=9D, and certainly not communicate with another client, = another AS, or other part of the GNAP = protocol. 

    [FIM] = Not entirely clear where we draw the line. I imagine "person sitting in = front of me right now" is not to be taken literally? (could be my = doctor, even if he's not in the same room).
    Clearly there's no way a = client can ever guarantee a reliable communication with something = else, I agree. At the very best it's a hint (and possibly a bad = one).

    If the doctor isn=E2=80=99t using the client = application, then the doctor=E2=80=99s not the =E2=80=9Cuser=E2=80=9D in = protocol terms. If the AS has some other way to get the doctor involved, = it should be able to do that, but the client can=E2=80=99t really do = anything about it.

     - = Justin


     - Justin


    Adrian

    On Mon, Mar 15, 2021 at 10:12 PM Adrian Gropper = <agropper@healthurl.com> wrote:
    Hi Justin,

    I have exactly the same two questions as Fabien and also, = I 

    On Mon, Mar 15, 2021 at 9:45 PM Fabien = Imbault <fabien.imbault@gmail.com> wrote:
    Hi Justin

    A few = questions :
    - we're covering the use = case "get my medical data", how does that change if that's someone = else's data? 
    - what happens if = the agent can't guarantee availability? 

    Fabien 


    Le lun. 15 = mars 2021 =C3=A0 20:42, Justin Richer <jricher@mit.edu> a =C3=A9crit :
    Hi Adrian, thanks so = much for writing up this use case. I=E2=80=99ve included some thoughts = below into how different aspects of GNAP might map to these = requirements. I don=E2=80=99t think mapping any human system to any = technology is clean and dry, but for what it=E2=80=99s worth I do see a = lot of alignment.

    On Mar 12, 2021, at 4:34 PM, = Adrian Gropper <agropper@healthurl.com> wrote:

    Let=E2=80=99s try to map a real-world use-case = into the names and roles we are discussing. The use-case is documented = as the API Task Force Recommendations (2016) https://www.healthit.gov/sites/default/files/facas/SingleSource= ofTruth-APITFRecommendations.pdf and I=E2=80=99= ve copied below the most relevant section. Bold highlight = is in the original. I=E2=80=99ve added bold italic because it may be important to our = discussion. 

    <quote>

    • ONC should clarify that while API Providers may = impose security related restrictions on app access (e.g. rate limiting, = encryption, and expiration of access tokens), it is inappropriate for = API providers to set limitations on what a patient authorized app can do = with data downstream.

      • Given the nature of patient access = rights, the provider is not in a legal position to prevent the = registration of apps that would aggregate or share data, for example = (though the provider might certainly decide to warn the patient, or = endeavor to educate and explain these issue to the patient, as part of = the provider hosted app approval workflow).
    • ONC should clarify that API providers are = not obligated to = protect patients by identifying "suspicious" apps. API providers = may suspend API access to = an app that has breached the API provider's terms of service , or = appears to have been compromised, or if the app poses a threat to the = provider's own system. However, patients must be able to override this = suspension (except in the case where an app poses threat to = the provider's own system or violates allowable terms of = service).

    </quote>

    The key requirements from a patient rights and = privacy perspective are:

    1. To delegate a scope-limited access capability to = anyone anywhere without having to explain or justify that to the API = Provider.

    This will always be = susceptible to the level of granularity that the API Provider allows the = API to be accessed in. 

    Standard APIs (which would result in = standard =E2=80=9Ctype=E2=80=9D values in the =E2=80=9Caccess=E2=80=9D = request array) can help with this by defining sufficient levels of = detail. But ultimately, the user could never ask for a scope that the = API Provider isn=E2=80=99t willing to express.

    1. To allow the patient to automate the issue of a = scope-limited access capability by delegating the authority to process = API access requests to some agent. The API Provider has no say in who or = where this agent = is.

    This is where I think = this discussion really should go. On the surface, this seems to lead to = the =E2=80=9Cbring your own AS=E2=80=9D model. I am contending that = it=E2=80=99s more powerful to have an AS (still under the API = Provider=E2=80=99s control) that allows the user to provide additional = inputs during the protocol process. As an industry, we can standardize = and innovate a lot of those inputs, but ultimately GNAP should be able = to just connect those endpoints to each other (in my opinion). One of = the common inputs is going to remain =E2=80=9Cget someone to log in at = this webpage at the AS and click a button=E2=80=9D, but I=E2=80=99m = convinced there will be others.

    1. The automation of the agent is based = on policies provided by the patient. The agent is able to process access = requests from anyone and is responsible only to the patient. The agent = responds to successful requests by issuing a filtered capability to the = requesting = party.

    In this case, = shouldn=E2=80=99t it be that the agent is separated from the AS? Since = the patient is going to have data protected by different API Provders, = to me it stands to reason that they=E2=80=99d want the same agent acting = for them on different systems. Each of those systems would still have = its own AS, but the AS would be facilitated by the user=E2=80=99s = input.

    Now = this is NOT saying that the user would have their own AS to delegate = something to the downstream AS. Or even saying that the user would have = some kind of XACML policy server. I=E2=80=99m not sure exactly how the = bits on the wire would work but a strawman would look something = like:


    3D"https://www.websequencediagrams.com/?png=3Dmsc978356221"

    User -> Client: go access my medical data
    Client -> RS: hey I want to access this medical = data
    RS -> Client: sure go talk to this = AS
    Client -> Agent: I need to make a request for = data, how can I get the AS in touch with you?
    Agent = -> Client: tell them to use [some kind of magic]
    Client -> AS: hey I want to access this medical data; I = can get the user to interact with you or I can put you in touch with = their policy agent
    AS -> Client: OK I=E2=80=99ll = talk to the policy agent
    AS -> Agent: I have a = request for data, I need you to prove that you have the right to release = this data
    Agent -> User: It looks like Client is = asking for stuff at RS through AS, that cool?
    Agent = -> AS: OK, here you go [more magic]
    AS -> = Client: ok, here=E2=80=99s an access token that=E2=80=99s good for = accessing that AS
    Client -> RS: hey, I want to = access this medical data and here=E2=80=99s an access token for = it


    1. To ensure that the requesting party = can delegate the capability using an institutional workflow system that = they trust and the patient doesn=E2=80=99t know or care about. In many = cases, the workflow system will pass the capability to some other = person, who we might call the end user. In other cases, the requesting = party may forward the capability directly to another person using, for = example, an email. Either way, the client app used by the end-user to = access the API is of no concern to the patient or to the patient=E2=80=99s= = agent. 
    <= div class=3D"">
    To facilitate this, = the =E2=80=9Cagent=E2=80=9D above can be augmented with other = capabilities based on what=E2=80=99s being asked for. Adding a line to = the flow above:

    User -> Client: go access my medical = data
    Client -> RS: hey I want to access this = medical data
    RS -> Client: sure go talk to this = AS
    Client -> Agent: I need to make a request for = data, how can I get the AS in touch with you?
    Agent = -> Client: tell them to use [some kind of magic]
    Client -> AS: hey I want to access this medical data; I = can get the user to interact with you or I can put you in touch with = their policy agent
    AS -> Client: OK I=E2=80=99ll = talk to the policy agent
    AS -> Agent: I have a = request for data, I need you to prove that you have the right to release = this data
    Agent -> User: It looks like Client is = asking for stuff at RS through AS, that cool?
    Agent = -> AS: OK, here you go [more magic]
    AS -> RO: It looks like someone's asking for an RS you = have the approval for, that cool?
    AS -> = Client: ok, here=E2=80=99s an access token that=E2=80=99s good for = accessing that AS
    Client -> RS: hey, I want to = access this medical data and here=E2=80=99s an access token for = it

    In other = words, when the AS gets the request, it can and should take in inputs = from multiple different dimensions in order to make the authorization = decision and encode that into the access token.

    1. To ensure that the API Provider does not censor = the client app that presents the capability or solicits too much = information about the client app or the end-user of the client = app. 

    This is one of the = reasons that the AS-based model is really important in GNAP =E2=80=94 = the API Provider's RS only needs to know =E2=80=9Cis this token good for = what=E2=80=99s being asked=E2=80=9D. 

    1. If the API Provider decides, for any = reason, to be =E2=80=9Csuspicious=E2=80=9D (as above) of the access = transaction based on the information it has, it should be possible for = the API Provider to warn the patient and to accept an override of the = warning by the patient. This effectively means that the end-user will = provide as much information as they think will be necessary in order to = either avoid =E2=80=9Csuspicion=E2=80=9D or risk waiting for patient = override.

    If the AS can reach out = to the patient through notice and consent, they can be brought into the = process in an interactive way above. This assumes the AS has a way of = connecting that, but we should assume the AS can provide this kind of = notice and consent to parties that aren=E2=80=99t directly involved in = the protocol flow in the same way the end user is.

    1. The policies by which the patient or the decides = to grant a capability to the requesting party are never shared outside = of the patient-agent trust relationship. In other words, neither the = patient nor the agent is asked to share or explain their reason for an = access = decision. 

    In the above = pattern, the AS and agent would need a way to communicate this with each = other. I think the details of this are outside the scope of GNAP but it = could take the form of a query/response fulfillment language. VC=E2=80=99s= address part of this, but I think there will need to be other aspects = brought to bear here. I think you could have a privacy-preserving = protocol that would layer into GNAP here, but I don=E2=80=99t know for = sure what that would look like.

    1. Access requests to the agent are = presumed confidential among the patient, the agent, and whatever client = the requesting party uses to present an access request. The API Provider = does not get to see the requests and no entity in the GNAP authorization = process, other than the patient or the agent, gets to correlate across = requests by different requesting party = clients.

    This would be a = different kind of model, where the client would act as some kind of = proxy in the process. Something more like:

    3D"https://www.websequencediagrams.com/?png=3Dmsc685845457"

    User -> Client: go access my medical data
    Client -> RS: hey I want to access this medical = data
    RS -> Client: sure go talk to this = AS
    Client -> Agent: I need to make a request for = data, how can I get the AS in touch with you?
    Agent = -> Client: tell them to use [some kind of magic]
    Client -> AS: hey I want to access this medical data; I = can get the user to interact with you or I can forward your request = details to the policy agent
    AS -> Client: OK go = talk to the policy agent, ask for these kinds of things
    Client -> Agent: I have a request for data, at this AS, I = need you to prove that you have the right to release this data
    Agent -> User: It looks like Client is asking for stuff at = RS through AS, that cool?
    Agent -> Client: OK, = here you go [more magic]
    Client -> AS: Here=E2=80=99= s the result of that policy thing you asked for [more magic]
    AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99= s good for accessing that AS
    Client -> RS: hey, = I want to access this medical data and here=E2=80=99s an access token = for it



    Note that I = am not saying all 8 requirements are in scope for GNAP but I am asking = for GNAP to allow for this level of privacy on the part of = self-sovereign patients using self-sovereign agents and the = self-sovereign licensed professionals they deal = with.

    For me the important = part is that GNAP allow these kinds of trust connections. Even if GNAP = isn=E2=80=99t solving every piece of this equation, it can at least = clearly state =E2=80=9Cthere=E2=80=99s a function here that needs to / = is able to solve this thing=E2=80=9D and build the important parts = around it.


     - Justin


    Adrian


    On Fri, Mar 12, 2021 at 2:50 PM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Hi Justin, 

    Just a quick word to say I very much = agree with both the observations and the framing.
    Fabien

    On Fri, Mar = 12, 2021 at 6:07 PM Justin Richer <jricher@mit.edu> = wrote:
    As discussed at the IETF meeting, = the editors proposed that one of our next big topic areas was going to = be the nature of the AS role within the GNAP protocol, especially how it = relates to the device-driven use cases that have been brought up. = Apologies in advance for the long post, but there are a lot of parts to = this discussion that I=E2=80=99m hoping we can kick off here.

    My core proposal is that = we see the AS as the component that has the following = properties:
     - receives delegation requests = from the client instance for access to an RS via access tokens, and for = access to subject information returned directly to the client = instance
     - collects consent and authorization = from the RO for the delegation
     - issues = access tokens that its downstream RS=E2=80=99s can interpret (and = validate/accept)
     - issues subject information = asserted by the AS 

    This framing of the parties is really = important in making a consistent understanding of how the protocol = works, and a consistent understanding is vital if we=E2=80=99re going to = function as a working group in both discussing the problem space and = executing the solution space. For a historical example, a naive approach = to adding identity on top of a protocol like OAuth 2 (or GNAP) is to = declare that the resource server is the thing the user is logging in to. = This seems reasonable at first (and some people tried doing this) but it = violates all kinds of trust boundaries and puts new expectations on the = different parties that do not make sense. It stops looking anything like = OAuth very quickly and turns into another protocol. If instead we say = the user is logging in to the client, things suddenly make a lot more = sense and we can do a lot more with it. (See this blog post from 2013 = for one take on that discussion: https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sig= n-in-4/)

    I = think we=E2=80=99ve got a similar situation here when we start to talk = about the user bringing their own AS with them. I think this is a = reasonable-seeming assumption but it=E2=80=99s based on a false premise = that the RO has to log into the AS to approve the request, and the AS = has full control and view over everything in the network. While OAuth = doesn=E2=80=99t require this, it=E2=80=99s largely assumed that=E2=80=99s = how it works. After all, all of the early OAuth deployments worked = exactly this way: the user logs in and clicks the =E2=80=9COK=E2=80=9D = button. However, cloud deployments have shown us that it=E2=80=99s = perfectly reasonable for an OAuth AS to take in its consent and user = information from an external trusted source, and so this model is not = even accurate in OAuth.

    In short, I think we can do a better job here of defining = things in terms that both accept the reality we face and enable new = ideas in ways that make sense. It=E2=80=99s my stance that the user = shouldn=E2=80=99t need to bring the AS with them in order to have the = kind of input and control of the system that people are asking for. = Instead, the AS should be able to take inputs from things that the user = controls in order for the AS to do its job.

    People have discussed privacy concerns = with the AS knowing =E2=80=9Ctoo much=E2=80=9D, but in many of those = discussions the knowledge is simply pushed to the RS instead. What I=E2=80= =99m observing here is really just pushing portions of the AS role into = the =E2=80=9CRS=E2=80=9D deployment. This doesn=E2=80=99t make it less = of an =E2=80=9CAS=E2=80=9D role, it=E2=80=99s just being fulfilled = closely to where the RS role is fulfilled. As such, my proposal is = really not that different in practice, but the labels are different and = better aligned with the capabilities of the = protocol. 

    We=E2=80=99ve previously talked about separating the = user-facing portions of the AS into another component, and I think now = might be the time to do that. This is a very flammable strawman = proposal, but what if we had the AS defined, as above, and the = =E2=80=9Cconsent and authorization=E2=80=9D gathering portion is = augmented by another named component. Here let=E2=80=99s call it an = Interaction Component. This can take several forms based on the kind of = interaction mode in use:

     - Hosted at a URL the user is redirected to; it can = then make the user log in, consent, and whatever else they need to = do
     - Hosted at a URL the user will load = separately and enter in an access code
     - An = app on the user=E2=80=99s device that the user interacts with directly = and which sends information back to the AS
     - = An app reachable by a messaging endpoint that the AS sends and receives = structured information from
     - The client = itself that is given an indication as to what information the AS needs = in order to fulfill the request; this could be MFA challenge/response, = user credentials, signed claims, etc.

    It=E2=80=99s the AS=E2=80=99s job to = accept any and all of these that it supports and churn those into an = access token. 

    The AS itself doesn=E2=80=99t ever need to have the user log = in. The AS doesn=E2=80=99t necessarily need to even know who the user is = in any way. The AS just needs to know from a trusted source that the = request is approved.

    =46rom a practical standpoint, I think this will have some = small changes in how we talk about the components and how we talk about = the interaction phase of the grant negotiation process. Everything I=E2=80= =99m laying out here is currently allowed by the spec, but I think = we=E2=80=99ve carried through the same assumptions from OAuth 2 about = deployment that are both inaccurate and confusing. 

     =E2=80=94 = Justin
    -- 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
    =
    -- TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    = --Apple-Mail=_2CFE92F0-4730-4D61-9BBA-8798EF1F7A0A-- From nobody Tue Mar 16 08:00:19 2021 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 C58DF3A10F7 for ; Tue, 16 Mar 2021 08:00:16 -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 9vk3se8P35C0 for ; Tue, 16 Mar 2021 08:00:10 -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 DCA713A115C for ; Tue, 16 Mar 2021 08:00:08 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id y20so19140186iot.4 for ; Tue, 16 Mar 2021 08:00: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=9g47ZjD2PldrAQT83pxZzBLxQA0DVXwG0GEOId40Y9E=; b=X/UrEXDcd9RjvZBi3r6cBbzZryNVuVg0/2ROLYGnw85Kjb8Zl1rPbj4/sxQpeV0XNp w5a9H6hPJSSh0XVNJ9cg0ksws3TroRr9Dfm6TSC4jP7/kjx9NmX1pTInTOLqxqOQVrsp 1zMYSj4E5lz0Rq2XAheW73SpMClGkHE2/oNT3YLNkZ2iKd3B9Ccy0klynP5C8X3uj/iM +V9lMkouwk3ggpDwA7SXCz31VydStcfNrUo23XFyTgPoVurST92fIN8Vdoen1/d2dIOL agD4xMOkI/niC4x3xIz3oBN8D0WinazzkD0QpH02kDOZABYAkWQi1lEKyQwqYtbb0sTo ZYPw== 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=9g47ZjD2PldrAQT83pxZzBLxQA0DVXwG0GEOId40Y9E=; b=SNt1hzaEK7Lx4I55avZ19IYhUlL2fRZXzWcbUvi+SuiwVOZUzVwGLjTUQ/qHHIhXdX RXLAT4KdweqedRwZIkpUxJyx9mw4uuybY6BX8UiCwi36RNzZcM6IrKDU6q0RRxc9feza FR94VS1VV61A/zBISi6Z1aSigKIZLPTv4YeP6CBuZaKRL31ECyffpUze4UyZuZkwF9me uYRVDnFR4wzx92dLTfKFVJVxN6gkk26dl+NRiYA45mcNp5K4ijuBK5S5pYdYApJFqjIL aiGr+W8ffAn7Ls4l/OMLJyyzyR5biAqjw4Zf0Np4wnxqlB0FxZfVUo7LGk4QtkEyqdMo 556A== X-Gm-Message-State: AOAM530/eg9QZRXIo/GzHe8Ra8Oz0mnX5VEtSrl2PVuVO9zoNFBd6vb1 xXFTQz91fjV9FMLiRwQNo51bdGVT6Jw/V1mwxRw= X-Google-Smtp-Source: ABdhPJygYxRAz0YxevdGT1BeFT1J/2TaFBqtadjhlh5lSwoyZUwHnTLjTJrA4dmGQCgp7xtmwNfl564obL+IfaxkvTI= X-Received: by 2002:a6b:5818:: with SMTP id m24mr3569669iob.144.1615906806851; Tue, 16 Mar 2021 08:00:06 -0700 (PDT) MIME-Version: 1.0 References: <205ACFE1-7D4C-4D7C-B394-4AD8A4D4D080@mit.edu> <4AD539F3-31BE-4162-BE2B-69D5AE22B48E@mit.edu> <6B51886D-35F6-443C-B9B6-4C8F22EE11CF@mit.edu> In-Reply-To: <6B51886D-35F6-443C-B9B6-4C8F22EE11CF@mit.edu> From: Fabien Imbault Date: Tue, 16 Mar 2021 15:59:55 +0100 Message-ID: To: Justin Richer Cc: Adrian Gropper , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000366db805bda89fb4" Archived-At: Subject: Re: [GNAP] GNAP Architecture and the role of the AS X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 15:00:17 -0000 --000000000000366db805bda89fb4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Same, thanks for the clarification. On Tue, Mar 16, 2021 at 3:11 PM Justin Richer wrote: > Responses inline.. > > On Mar 16, 2021, at 9:19 AM, Fabien Imbault > wrote: > > Hi Justin, > > My comments in red [FIM]. > > Cheers > Fabien > > On Tue, Mar 16, 2021 at 1:14 PM Justin Richer wrote: > >> On Mar 15, 2021, at 10:16 PM, Adrian Gropper >> wrote: >> >> Hi Justin, >> >> I have exactly the same two questions as Fabien and also, I worry about >> the handwaving in the answer to 7. >> >> >> The handwaving is actually important. I don=E2=80=99t think that=E2=80= =99s something that >> GNAP will solve in a universal way. We can have hooks in the core protoc= ol >> that say =E2=80=9Cand now go do This Other Thing to talk to an agent=E2= =80=9D, but I don=E2=80=99t >> think we=E2=80=99re really the best ones to decide what that is or what = it looks >> like for everyone. >> >> This could be DIDComm, it could be CHAPI, it could be some proprietary >> app connection with push notifications, it could be writing/reading from= a >> shared encryption storage fabric =E2=80=94 all that=E2=80=99s important = here is that GNAP >> has a place in the protocol where these various things can fit. >> >> OAuth chose HTTP Redirects as The Way to get users involved in the >> process, but GNAP is taking a very different stance in trying to get awa= y >> from that limiting assumption. I don=E2=80=99t think it would serve us t= o just make >> a different limiting assumption about how users (and their decisions) ge= t >> involved. >> > > [FIM] We shouldn't be looking for an universal carrier, I agree, but > people will need practical ways to implement that. I think there's a fine > line between avoiding limiting assumptions and GNAP remaining too > conceptual. At least we should know where to put the extension points. > > > I agree that we need to have the extension points in the right place. In > order to do that, we need to know what we=E2=80=99re extending, which was= the > impetus for starting this conversation. It=E2=80=99s debatable how much f= urther we > want to go beyond that in GNAP itself, especially since there are a lot o= f > other protocols out there designed to fit this niche well (see examples > above). > > One step we definitely can help with is providing a cohesive model for > describing both people and access rights, and being clear about the overa= ll > process. > [FIM2] clearer to me, thanks. > >> To answer the questions; >> >> - we're covering the use case "get my medical data", how does that chang= e >>>> if that's someone else's data? >>>> >>> >> It=E2=80=99s the same process as the second flow. The RO is the patient = or doctor >> or someone who can approve things. The AS doesn=E2=80=99t get everything= that it >> needs to from the agent introduced by the client, so it needs to access >> another agent. >> > >> - what happens if the agent can't guarantee availability? >>>> >>> >> Then the AS doesn=E2=80=99t get what it needs in order to fulfill the re= quest and >> it denies the request. Whether that=E2=80=99s a timeout or some other er= ror, and >> whether that comes back to the client with a =E2=80=9Ctry again=E2=80=9D= or with a =E2=80=9Ctough >> luck, go away=E2=80=9D, I think that=E2=80=99s all up for debate, and pa= rts of that we=E2=80=99ll >> need answers for. But ultimately, it=E2=80=99s the same kind of thing th= at happens >> in OAuth if the user doesn=E2=80=99t consent, or the user can=E2=80=99t = log in, or the >> =E2=80=9Cwrong=E2=80=9D user logs in for what=E2=80=99s being asked for = =E2=80=94 the AS isn=E2=80=99t satisfied >> with the approval so the delegation request fails. >> > > [FIM] seems realistic when user =3D RO, the end-user can make itself > available if the service is really important to him. "Tough luck" at firs= t > failure is fine then. > But I believe that becomes impractical when a remote RO is involved (at > least if it's supposed to be a human: if we don't deal with unavailabilit= y, > async sequence 1.4.3 should be removed). > > > Then, what is the AS to do if it tries the methods necessary to reach the > RO, but those methods fail? Or if there are multiple RO=E2=80=99s who cou= ld approve > and multiple come back? > [FIM2] yes, that's some of the cases (and open questions) I put forward in the presentation, trying to identify what would have to be dealt with. It would be fine to decide all interactions need to be synchronous requests/responses in the core. > > I agree that these are situations the AS is going to have to deal with, > but I also believe that the details of what gets us into these situations > is outside of GNAP itself. Perhaps think of it this way: > > - The AS needs to gather authorization and consent. > - The client can direct interaction with the end user. > - The end user might be able to provide that authorization and consent. > - The client doesn=E2=80=99t know if the end user is the RO, but it can = provide > the AS with hints as to who the end user is and means to interact with th= em > for the AS. > - The AS knows who the RO is and might have ways to interact with them > (and their decisions) outside of the interface with the client. > > So in other words, the consent-gathering process that the AS goes through > can be both client-mediated and non-client-mediated. The client-mediated > portions are very much in scope of GNAP and they fall into the space of > user =3D=3D RO very easily. The non-client-mediated interactions are outs= ide > the scope of GNAP =E2=80=94 or at least outside the core protocol, since = the core > protocol is all about the client instance getting a token (and/or subject > info). > [FIM2] that could be a viable way to refine the scope of the core. As long as it's clear what we do, it's fine to me. > > I think we can expand the discussion in the draft of how the AS goes > through this consent gathering process but shouldn=E2=80=99t try to defin= e one > specific way of it happening. That way we can define good behavior around > asynchronous methods, timeouts, and multi-user protocols, but without > having to define, say, a wire-based policy language to carry those > decisions. It=E2=80=99s definitely a fine line! > [FIM2] yes, for sure DIDComm was in my view just one example of a possible extended interact method (among many possible already today and more in the future). In practice, none of those non-client-mediated interactions need to be in the core. However, they would probably require that GNAP defines how one should react to such async or message based patterns, above the underlying protocol foundation, to provide "elegant, synchronous request-response interactions." (as said in 1.3.1 of DIDComm). Defining good async behaviour without minimal syntax is possible with coloring schemes, but they have their drawbacks too (forces you to always think in colors, even for basic sync cases, and so I'm not convinced that would be a win). > > Your flow for 8 doesn't make sense to me because I assume the client is o= n >> the RO's mobile device and unavailable for most interactions. The whole >> point of having the Agent is to keep the RO Client out of the picture wh= en >> the requesting party shows up with their Client. >> >> >> The RO doesn=E2=80=99t have a client in any of the flows below. The RO m= ight have >> an agent, they might have an app that notifies them to go log into a >> webpage asynchronously, they might get an email with a link to click bac= k >> at the AS. None of that is facilitated through the RO=E2=80=99s client b= ecause the >> RO doesn=E2=80=99t have a =E2=80=9Cclient=E2=80=9D in this model. The cl= ient is by definition the >> software in front of the =E2=80=9Cuser=E2=80=9D, the requesting party. >> > [FIM] yes indeed > >> >> And it=E2=80=99s important in the design that the client doesn=E2=80=99t= need to know >> about any of that. It can identify the resource, possibly identify the R= O, >> and it can tell the AS =E2=80=9Cthis is how I can talk to the person sit= ting in >> front of me right now=E2=80=9D =E2=80=94 for whatever definition of =E2= =80=9Ctalk to=E2=80=9D makes sense >> for the client app. What it can=E2=80=99t reliably do is say =E2=80=9Cth= is is how I can get >> in touch with an RO that I=E2=80=99m not talking to=E2=80=9D, and certai= nly not communicate >> with another client, another AS, or other part of the GNAP protocol. >> > > [FIM] Not entirely clear where we draw the line. I imagine "person sittin= g > in front of me right now" is not to be taken literally? (could be my > doctor, even if he's not in the same room). > Clearly there's no way a client can ever guarantee a reliable > communication with something else, I agree. At the very best it's a hint > (and possibly a bad one). > > > If the doctor isn=E2=80=99t using the client application, then the doctor= =E2=80=99s not > the =E2=80=9Cuser=E2=80=9D in protocol terms. If the AS has some other wa= y to get the > doctor involved, it should be able to do that, but the client can=E2=80= =99t really > do anything about it. > > - Justin > > >> - Justin >> >> >> Adrian >> >> On Mon, Mar 15, 2021 at 10:12 PM Adrian Gropper >> wrote: >> >>> Hi Justin, >>> >>> I have exactly the same two questions as Fabien and also, I >>> >>> On Mon, Mar 15, 2021 at 9:45 PM Fabien Imbault >>> wrote: >>> >>>> Hi Justin >>>> >>>> A few questions : >>>> - we're covering the use case "get my medical data", how does that >>>> change if that's someone else's data? >>>> - what happens if the agent can't guarantee availability? >>>> >>>> Fabien >>>> >>>> >>>> Le lun. 15 mars 2021 =C3=A0 20:42, Justin Richer a = =C3=A9crit : >>>> >>>>> Hi Adrian, thanks so much for writing up this use case. I=E2=80=99ve = included >>>>> some thoughts below into how different aspects of GNAP might map to t= hese >>>>> requirements. I don=E2=80=99t think mapping any human system to any t= echnology is >>>>> clean and dry, but for what it=E2=80=99s worth I do see a lot of alig= nment. >>>>> >>>>> On Mar 12, 2021, at 4:34 PM, Adrian Gropper >>>>> wrote: >>>>> >>>>> Let=E2=80=99s try to map a real-world use-case into the names and rol= es we are >>>>> discussing. The use-case is documented as the API Task Force >>>>> Recommendations (2016) >>>>> https://www.healthit.gov/sites/default/files/facas/SingleSourceofTrut= h-APITFRecommendations.pdf >>>>> and I=E2=80=99ve copied below the most relevant section. Bold highlig= ht is in >>>>> the original. I=E2=80=99ve added bold italic because it may be import= ant to >>>>> our discussion. >>>>> >>>>> >>>>> >>>>> - >>>>> >>>>> ONC should clarify that while API Providers may impose security >>>>> related restrictions on app access (e.g. rate limiting, encryption= , and >>>>> expiration of access tokens), it is inappropriate for API provider= s to set >>>>> limitations on what a patient authorized app can do with data down= stream. >>>>> - Given the nature of patient access rights, the provider is not >>>>> in a legal position to prevent the registration of apps that wo= uld >>>>> aggregate or share data, for example (though the provider might= certainly >>>>> decide to warn the patient, or endeavor to educate and explain = these issue >>>>> to the patient, as part of the provider hosted app approval wor= kflow). >>>>> - ONC should clarify that API providers are not obligated to >>>>> protect patients by identifying "suspicious" apps. API providers m= ay >>>>> suspend API access to an app that has breached the API provider's >>>>> terms of service , or appears to have been compromised, or if the = app poses >>>>> a threat to the provider's own system. However, patients must be >>>>> able to override this suspension (except in the case where an app >>>>> poses threat to the provider's own system or violates allowable te= rms of >>>>> service). >>>>> >>>>> >>>>> >>>>> >>>>> The key requirements from a patient rights and privacy perspective ar= e: >>>>> >>>>> >>>>> 1. To delegate a scope-limited access capability to anyone >>>>> anywhere without having to explain or justify that to the API Prov= ider. >>>>> >>>>> >>>>> This will always be susceptible to the level of granularity that the >>>>> API Provider allows the API to be accessed in. >>>>> >>>>> Standard APIs (which would result in standard =E2=80=9Ctype=E2=80=9D = values in the >>>>> =E2=80=9Caccess=E2=80=9D request array) can help with this by definin= g sufficient levels of >>>>> detail. But ultimately, the user could never ask for a scope that the= API >>>>> Provider isn=E2=80=99t willing to express. >>>>> >>>>> >>>>> 1. To allow the patient to automate the issue of a scope-limited >>>>> access capability by delegating the authority to process API acces= s >>>>> requests to some agent. The API Provider has no say in who or wher= e this >>>>> agent is. >>>>> >>>>> >>>>> This is where I think this discussion really should go. On the >>>>> surface, this seems to lead to the =E2=80=9Cbring your own AS=E2=80= =9D model. I am >>>>> contending that it=E2=80=99s more powerful to have an AS (still under= the API >>>>> Provider=E2=80=99s control) that allows the user to provide additiona= l inputs >>>>> during the protocol process. As an industry, we can standardize and >>>>> innovate a lot of those inputs, but ultimately GNAP should be able to= just >>>>> connect those endpoints to each other (in my opinion). One of the com= mon >>>>> inputs is going to remain =E2=80=9Cget someone to log in at this webp= age at the AS >>>>> and click a button=E2=80=9D, but I=E2=80=99m convinced there will be = others. >>>>> >>>>> >>>>> 1. The automation of the agent is based on policies provided by >>>>> the patient. The agent is able to process access requests from any= one and >>>>> is responsible only to the patient. The agent responds to successf= ul >>>>> requests by issuing a filtered capability to the requesting party. >>>>> >>>>> >>>>> In this case, shouldn=E2=80=99t it be that the agent is separated fro= m the AS? >>>>> Since the patient is going to have data protected by different API >>>>> Provders, to me it stands to reason that they=E2=80=99d want the same= agent acting >>>>> for them on different systems. Each of those systems would still have= its >>>>> own AS, but the AS would be facilitated by the user=E2=80=99s input. >>>>> >>>>> Now this is NOT saying that the user would have their own AS to >>>>> delegate something to the downstream AS. Or even saying that the user= would >>>>> have some kind of XACML policy server. I=E2=80=99m not sure exactly h= ow the bits on >>>>> the wire would work but a strawman would look something like: >>>>> >>>>> >>>>> [image: https://www.websequencediagrams.com/?png=3Dmsc978356221] >>>>> >>>>> User -> Client: go access my medical data >>>>> Client -> RS: hey I want to access this medical data >>>>> RS -> Client: sure go talk to this AS >>>>> Client -> Agent: I need to make a request for data, how can I get the >>>>> AS in touch with you? >>>>> Agent -> Client: tell them to use [some kind of magic] >>>>> Client -> AS: hey I want to access this medical data; I can get the >>>>> user to interact with you or I can put you in touch with their policy= agent >>>>> AS -> Client: OK I=E2=80=99ll talk to the policy agent >>>>> AS -> Agent: I have a request for data, I need you to prove that you >>>>> have the right to release this data >>>>> Agent -> User: It looks like Client is asking for stuff at RS through >>>>> AS, that cool? >>>>> Agent -> AS: OK, here you go [more magic] >>>>> AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99s good = for accessing >>>>> that AS >>>>> Client -> RS: hey, I want to access this medical data and here=E2=80= =99s an >>>>> access token for it >>>>> >>>>> >>>>> >>>>> 1. To ensure that the requesting party can delegate the capability >>>>> using an institutional workflow system that they trust and the pat= ient >>>>> doesn=E2=80=99t know or care about. In many cases, the workflow sy= stem will pass >>>>> the capability to some other person, who we might call the end use= r. In >>>>> other cases, the requesting party may forward the capability direc= tly to >>>>> another person using, for example, an email. Either way, the clien= t app >>>>> used by the end-user to access the API is of no concern to the pat= ient or >>>>> to the patient=E2=80=99s agent. >>>>> >>>>> >>>>> To facilitate this, the =E2=80=9Cagent=E2=80=9D above can be augmente= d with other >>>>> capabilities based on what=E2=80=99s being asked for. Adding a line t= o the flow >>>>> above: >>>>> >>>>> User -> Client: go access my medical data >>>>> Client -> RS: hey I want to access this medical data >>>>> RS -> Client: sure go talk to this AS >>>>> Client -> Agent: I need to make a request for data, how can I get the >>>>> AS in touch with you? >>>>> Agent -> Client: tell them to use [some kind of magic] >>>>> Client -> AS: hey I want to access this medical data; I can get the >>>>> user to interact with you or I can put you in touch with their policy= agent >>>>> AS -> Client: OK I=E2=80=99ll talk to the policy agent >>>>> AS -> Agent: I have a request for data, I need you to prove that you >>>>> have the right to release this data >>>>> Agent -> User: It looks like Client is asking for stuff at RS through >>>>> AS, that cool? >>>>> Agent -> AS: OK, here you go [more magic] >>>>> *AS -> RO: It looks like someone's asking for an RS you have the >>>>> approval for, that cool?* >>>>> AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99s good = for accessing >>>>> that AS >>>>> Client -> RS: hey, I want to access this medical data and here=E2=80= =99s an >>>>> access token for it >>>>> >>>>> In other words, when the AS gets the request, it can and should take >>>>> in inputs from multiple different dimensions in order to make the >>>>> authorization decision and encode that into the access token. >>>>> >>>>> >>>>> 1. To ensure that the API Provider does not censor the client app >>>>> that presents the capability or solicits too much information abou= t the >>>>> client app or the end-user of the client app. >>>>> >>>>> >>>>> This is one of the reasons that the AS-based model is really importan= t >>>>> in GNAP =E2=80=94 the API Provider's RS only needs to know =E2=80=9Ci= s this token good for >>>>> what=E2=80=99s being asked=E2=80=9D. >>>>> >>>>> >>>>> 1. If the API Provider decides, for any reason, to be =E2=80=9Csus= picious=E2=80=9D >>>>> (as above) of the access transaction based on the information it h= as, it >>>>> should be possible for the API Provider to warn the patient and to= accept >>>>> an override of the warning by the patient. This effectively means = that the >>>>> end-user will provide as much information as they think will be ne= cessary >>>>> in order to either avoid =E2=80=9Csuspicion=E2=80=9D or risk waiti= ng for patient override. >>>>> >>>>> >>>>> If the AS can reach out to the patient through notice and consent, >>>>> they can be brought into the process in an interactive way above. Thi= s >>>>> assumes the AS has a way of connecting that, but we should assume the= AS >>>>> can provide this kind of notice and consent to parties that aren=E2= =80=99t directly >>>>> involved in the protocol flow in the same way the end user is. >>>>> >>>>> >>>>> 1. The policies by which the patient or the decides to grant a >>>>> capability to the requesting party are never shared outside of the >>>>> patient-agent trust relationship. In other words, neither the pati= ent nor >>>>> the agent is asked to share or explain their reason for an access = decision. >>>>> >>>>> >>>>> In the above pattern, the AS and agent would need a way to communicat= e >>>>> this with each other. I think the details of this are outside the sco= pe of >>>>> GNAP but it could take the form of a query/response fulfillment langu= age. >>>>> VC=E2=80=99s address part of this, but I think there will need to be = other aspects >>>>> brought to bear here. I think you could have a privacy-preserving pro= tocol >>>>> that would layer into GNAP here, but I don=E2=80=99t know for sure wh= at that would >>>>> look like. >>>>> >>>>> >>>>> 1. Access requests to the agent are presumed confidential among >>>>> the patient, the agent, and whatever client the requesting party u= ses to >>>>> present an access request. The API Provider does not get to see th= e >>>>> requests and no entity in the GNAP authorization process, other th= an the >>>>> patient or the agent, gets to correlate across requests by differe= nt >>>>> requesting party clients. >>>>> >>>>> >>>>> This would be a different kind of model, where the client would act a= s >>>>> some kind of proxy in the process. Something more like: >>>>> >>>>> [image: https://www.websequencediagrams.com/?png=3Dmsc685845457] >>>>> >>>>> User -> Client: go access my medical data >>>>> Client -> RS: hey I want to access this medical data >>>>> RS -> Client: sure go talk to this AS >>>>> Client -> Agent: I need to make a request for data, how can I get the >>>>> AS in touch with you? >>>>> Agent -> Client: tell them to use [some kind of magic] >>>>> Client -> AS: hey I want to access this medical data; I can get the >>>>> user to interact with you or I can forward your request details to th= e >>>>> policy agent >>>>> AS -> Client: OK go talk to the policy agent, ask for these kinds of >>>>> things >>>>> Client -> Agent: I have a request for data, at this AS, I need you to >>>>> prove that you have the right to release this data >>>>> Agent -> User: It looks like Client is asking for stuff at RS through >>>>> AS, that cool? >>>>> Agent -> Client: OK, here you go [more magic] >>>>> Client -> AS: Here=E2=80=99s the result of that policy thing you aske= d for >>>>> [more magic] >>>>> AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99s good = for accessing >>>>> that AS >>>>> Client -> RS: hey, I want to access this medical data and here=E2=80= =99s an >>>>> access token for it >>>>> >>>>> >>>>> >>>>> Note that I am not saying all 8 requirements are in scope for GNAP bu= t >>>>> I am asking for GNAP to allow for this level of privacy on the part o= f >>>>> self-sovereign patients using self-sovereign agents and the self-sove= reign >>>>> licensed professionals they deal with. >>>>> >>>>> >>>>> For me the important part is that GNAP allow these kinds of trust >>>>> connections. Even if GNAP isn=E2=80=99t solving every piece of this e= quation, it >>>>> can at least clearly state =E2=80=9Cthere=E2=80=99s a function here t= hat needs to / is able >>>>> to solve this thing=E2=80=9D and build the important parts around it. >>>>> >>>>> >>>>> - Justin >>>>> >>>>> >>>>> Adrian >>>>> >>>>> >>>>> On Fri, Mar 12, 2021 at 2:50 PM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Hi Justin, >>>>>> >>>>>> Just a quick word to say I very much agree with both the observation= s >>>>>> and the framing. >>>>>> >>>>>> Fabien >>>>>> >>>>>> On Fri, Mar 12, 2021 at 6:07 PM Justin Richer >>>>>> wrote: >>>>>> >>>>>>> As discussed at the IETF meeting, the editors proposed that one of >>>>>>> our next big topic areas was going to be the nature of the AS role = within >>>>>>> the GNAP protocol, especially how it relates to the device-driven u= se cases >>>>>>> that have been brought up. Apologies in advance for the long post, = but >>>>>>> there are a lot of parts to this discussion that I=E2=80=99m hoping= we can kick off >>>>>>> here. >>>>>>> >>>>>>> My core proposal is that we see the AS as the component that has th= e >>>>>>> following properties: >>>>>>> - receives delegation requests from the client instance for access >>>>>>> to an RS via access tokens, and for access to subject information r= eturned >>>>>>> directly to the client instance >>>>>>> - collects consent and authorization from the RO for the delegatio= n >>>>>>> - issues access tokens that its downstream RS=E2=80=99s can interp= ret (and >>>>>>> validate/accept) >>>>>>> - issues subject information asserted by the AS >>>>>>> >>>>>>> This framing of the parties is really important in making a >>>>>>> consistent understanding of how the protocol works, and a consisten= t >>>>>>> understanding is vital if we=E2=80=99re going to function as a work= ing group in >>>>>>> both discussing the problem space and executing the solution space.= For a >>>>>>> historical example, a naive approach to adding identity on top of a >>>>>>> protocol like OAuth 2 (or GNAP) is to declare that the resource ser= ver is >>>>>>> the thing the user is logging in to. This seems reasonable at first= (and >>>>>>> some people tried doing this) but it violates all kinds of trust bo= undaries >>>>>>> and puts new expectations on the different parties that do not make= sense. >>>>>>> It stops looking anything like OAuth very quickly and turns into an= other >>>>>>> protocol. If instead we say the user is logging in to the client, t= hings >>>>>>> suddenly make a lot more sense and we can do a lot more with it. (S= ee this >>>>>>> blog post from 2013 for one take on that discussion: >>>>>>> https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in= -4/ >>>>>>> ) >>>>>>> >>>>>>> I think we=E2=80=99ve got a similar situation here when we start to= talk >>>>>>> about the user bringing their own AS with them. I think this is a >>>>>>> reasonable-seeming assumption but it=E2=80=99s based on a false pre= mise that the RO >>>>>>> has to log into the AS to approve the request, and the AS has full = control >>>>>>> and view over everything in the network. While OAuth doesn=E2=80=99= t require this, >>>>>>> it=E2=80=99s largely assumed that=E2=80=99s how it works. After all= , all of the early OAuth >>>>>>> deployments worked exactly this way: the user logs in and clicks th= e =E2=80=9COK=E2=80=9D >>>>>>> button. However, cloud deployments have shown us that it=E2=80=99s = perfectly >>>>>>> reasonable for an OAuth AS to take in its consent and user informat= ion from >>>>>>> an external trusted source, and so this model is not even accurate = in OAuth. >>>>>>> >>>>>>> In short, I think we can do a better job here of defining things in >>>>>>> terms that both accept the reality we face and enable new ideas in = ways >>>>>>> that make sense. It=E2=80=99s my stance that the user shouldn=E2=80= =99t need to bring the >>>>>>> AS with them in order to have the kind of input and control of the = system >>>>>>> that people are asking for. Instead, the AS should be able to take = inputs >>>>>>> from things that the user controls in order for the AS to do its jo= b. >>>>>>> >>>>>>> People have discussed privacy concerns with the AS knowing =E2=80= =9Ctoo >>>>>>> much=E2=80=9D, but in many of those discussions the knowledge is si= mply pushed to >>>>>>> the RS instead. What I=E2=80=99m observing here is really just push= ing portions of >>>>>>> the AS role into the =E2=80=9CRS=E2=80=9D deployment. This doesn=E2= =80=99t make it less of an =E2=80=9CAS=E2=80=9D >>>>>>> role, it=E2=80=99s just being fulfilled closely to where the RS rol= e is fulfilled. >>>>>>> As such, my proposal is really not that different in practice, but = the >>>>>>> labels are different and better aligned with the capabilities of th= e >>>>>>> protocol. >>>>>>> >>>>>>> We=E2=80=99ve previously talked about separating the user-facing po= rtions of >>>>>>> the AS into another component, and I think now might be the time to= do >>>>>>> that. This is a very flammable strawman proposal, but what if we ha= d the AS >>>>>>> defined, as above, and the =E2=80=9Cconsent and authorization=E2=80= =9D gathering portion is >>>>>>> augmented by another named component. Here let=E2=80=99s call it an= Interaction >>>>>>> Component. This can take several forms based on the kind of interac= tion >>>>>>> mode in use: >>>>>>> >>>>>>> - Hosted at a URL the user is redirected to; it can then make the >>>>>>> user log in, consent, and whatever else they need to do >>>>>>> - Hosted at a URL the user will load separately and enter in an >>>>>>> access code >>>>>>> - An app on the user=E2=80=99s device that the user interacts with= directly >>>>>>> and which sends information back to the AS >>>>>>> - An app reachable by a messaging endpoint that the AS sends and >>>>>>> receives structured information from >>>>>>> - The client itself that is given an indication as to what >>>>>>> information the AS needs in order to fulfill the request; this coul= d be MFA >>>>>>> challenge/response, user credentials, signed claims, etc. >>>>>>> >>>>>>> It=E2=80=99s the AS=E2=80=99s job to accept any and all of these th= at it supports >>>>>>> and churn those into an access token. >>>>>>> >>>>>>> The AS itself doesn=E2=80=99t ever need to have the user log in. Th= e AS >>>>>>> doesn=E2=80=99t necessarily need to even know who the user is in an= y way. The AS >>>>>>> just needs to know from a trusted source that the request is approv= ed. >>>>>>> >>>>>>> From a practical standpoint, I think this will have some small >>>>>>> changes in how we talk about the components and how we talk about t= he >>>>>>> interaction phase of the grant negotiation process. Everything I=E2= =80=99m laying >>>>>>> out here is currently allowed by the spec, but I think we=E2=80=99v= e carried >>>>>>> through the same assumptions from OAuth 2 about deployment that are= both >>>>>>> inaccurate and confusing. >>>>>>> >>>>>>> =E2=80=94 Justin >>>>>>> -- >>>>>>> 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 >>>> >>> >> -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --000000000000366db805bda89fb4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Same, thanks for the clarification.

    On Tue, Mar 16, 20= 21 at 3:11 PM Justin Richer <jricher@= mit.edu> wrote:
    Responses inline..

    On Mar 16, 2021, at 9:19 AM, Fabien Imb= ault <fabi= en.imbault@gmail.com> wrote:

    Hi Justin,

    My comments in red [FIM].<= /div>

    Cheers
    Fabien

    On Tue, Mar 16, 2021 at 1:1= 4 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 15, 2021, a= t 10:16 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    Hi Justin,

    I have exactly the= same two questions as Fabien and also, I worry about the handwaving=C2=A0i= n the answer=C2=A0to 7.

    = The handwaving is actually important. I don=E2=80=99t think that=E2=80=99s = something that GNAP will solve in a universal way. We can have hooks in the= core protocol that say =E2=80=9Cand now go do This Other Thing to talk to = an agent=E2=80=9D, but I don=E2=80=99t think we=E2=80=99re really the best = ones to decide what that is or what it looks like for everyone.=C2=A0
    =

    This could be DIDComm, it could be CHAPI, it could be s= ome proprietary app connection with push notifications, it could be writing= /reading from a shared encryption storage fabric =E2=80=94 all that=E2=80= =99s important here is that GNAP has a place in the protocol where these va= rious things can fit.=C2=A0

    OAuth chose HTTP Redir= ects as The Way to get users involved in the process, but GNAP is taking a = very different stance in trying to get away from that limiting assumption. = I don=E2=80=99t think it would serve us to just make a different limiting a= ssumption about how users (and their decisions) get involved.

    [FIM] We shouldn= 't be looking for an universal carrier, I agree, but people will need p= ractical ways to implement that. I think there's a fine line between av= oiding limiting assumptions and GNAP remaining too conceptual. At least we = should know where to put the extension points.

    I agree that we need to have the extensi= on points in the right place. In order to do that, we need to know what we= =E2=80=99re extending, which was the impetus for starting this conversation= . It=E2=80=99s debatable how much further we want to go beyond that in GNAP= itself, especially since there are a lot of other protocols out there desi= gned to fit this niche well (see examples above).=C2=A0

    One step we definitely can help with is providing a cohesive model fo= r describing both people and access rights, and being clear about the overa= ll process.

    [FIM2] clearer to me, thanks.=C2=A0
    <= div>

    To answer the questions;

    -= we're covering the use case "get my medical data", how does = that change if that's someone else's data?=C2=A0
    <= /blockquote>

    It=E2= =80=99s the same process as the second flow. The RO is the patient or docto= r or someone who can approve things. The AS doesn=E2=80=99t get everything = that it needs to from the agent introduced by the client, so it needs to ac= cess another agent.

    - what happens if = the agent can't guarantee availability?=C2=A0

    Then the AS doesn= =E2=80=99t get what it needs in order to fulfill the request and it denies = the request. Whether that=E2=80=99s a timeout or some other error, and whet= her that comes back to the client with a =E2=80=9Ctry again=E2=80=9D or wit= h a =E2=80=9Ctough luck, go away=E2=80=9D, I think that=E2=80=99s all up fo= r debate, and parts of that we=E2=80=99ll need answers for. But ultimately,= it=E2=80=99s the same kind of thing that happens in OAuth if the user does= n=E2=80=99t consent, or the user can=E2=80=99t log in, or the =E2=80=9Cwron= g=E2=80=9D user logs in for what=E2=80=99s being asked for =E2=80=94 the AS= isn=E2=80=99t satisfied with the approval so the delegation request fails.=
    =C2=A0
    [FIM]=C2=A0 seems realistic when user =3D RO, the end-user can make= itself available if the service is really important to him. "Tough lu= ck" at first failure is fine then.=C2=A0
    But I believe that becomes impractical when=C2=A0a remote RO is involved (at least if it's= supposed to be a human: if we don't deal with=C2=A0unavailability, asy= nc sequence 1.4.3 should be removed).=C2=A0
    <= /blockquote>

    Then, what is the AS to do if it tries the = methods necessary to reach the RO, but those methods fail? Or if there are = multiple RO=E2=80=99s who could approve and multiple come back?=C2=A0
    =
    [FIM2] yes, that'= s some of the cases (and open questions) I put forward in the presentation,= trying to identify what would have to=C2=A0be dealt with.=C2=A0
    It would be fine to decide all interactions = need to be synchronous requests/responses in the core.=C2=A0

    I agree that these are situations t= he AS is going to have to deal with, but I also believe that the details of= what gets us into these situations is outside of GNAP itself. Perhaps thin= k of it this way:

    =C2=A0- The AS needs to gather a= uthorization and consent.
    =C2=A0- The client can direct interaction wi= th the end user.
    =C2=A0- The end user might be able to provide that aut= horization and consent.
    =C2=A0- The client doesn=E2=80=99t know i= f the end user is the RO, but it can provide the AS with hints as to who th= e end user is and means to interact with them for the AS.
    =C2=A0-= The AS knows who the RO is and might have ways to interact with them (and = their decisions) outside of the interface with the client.

    So in other words, the consent-gathering process that the AS goes = through can be both client-mediated and non-client-mediated. The client-med= iated portions are very much in scope of GNAP and they fall into the space = of user =3D=3D RO very easily. The non-client-mediated interactions are out= side the scope of GNAP =E2=80=94 or at least outside the core protocol, sin= ce the core protocol is all about the client instance getting a token (and/= or subject info).
    [FIM2] that could be a viable way to refine the scope of the core. As lon= g as it's clear what we do, it's fine to me.=C2=A0

    I think we can expand the discussion = in the draft of how the AS goes through this consent gathering process but = shouldn=E2=80=99t try to define one specific way of it happening. That way = we can define good behavior around asynchronous methods, timeouts, and mult= i-user protocols, but without having to define, say, a wire-based policy la= nguage to carry those decisions. It=E2=80=99s definitely a fine line!
    =
    [FIM2] yes, for sure = DIDComm was in my view just one example of a possible extended interact met= hod (among many possible already today and more in the future).=C2=A0
    In practice, none of those non-client-m= ediated interactions need to be in the core.=C2=A0However, they would probably require that GNAP defines how= one should react to such async or message based patterns, above the underl= ying protocol foundation, to provide "elegant, synchronous request-response interactions." (as sai= d in 1.3.1 of DIDComm). Defining good async behaviour without minimal synta= x is possible with coloring schemes, but they have their drawbacks too (for= ces you to always think in colors, even for basic sync cases, and so I'= m not convinced that would be a win).=C2=A0=C2=A0

    Your flow for 8 doesn't make sense to me because I = assume the client is on the RO's mobile device and unavailable for most= interactions. The whole point of having the Agent is to keep the RO Client= out of the picture when the requesting party shows up with their Client.

    The RO doesn=E2=80= =99t have a client in any of the flows below. The RO might have an agent, t= hey might have an app that notifies them to go log into a webpage asynchron= ously, they might get an email with a link to click back at the AS. None of= that is facilitated through the RO=E2=80=99s client because the RO doesn= =E2=80=99t have a =E2=80=9Cclient=E2=80=9D in this model. The client is by = definition the software in front of the =E2=80=9Cuser=E2=80=9D, the request= ing party.=C2=A0
    [FIM] yes indeed=C2=A0

    And it=E2=80=99s important in the = design that the client doesn=E2=80=99t need to know about any of that. It c= an identify the resource, possibly identify the RO, and it can tell the AS = =E2=80=9Cthis is how I can talk to the person sitting in front of me right = now=E2=80=9D =E2=80=94 for whatever definition of =E2=80=9Ctalk to=E2=80=9D= makes sense for the client app. What it can=E2=80=99t reliably do is say = =E2=80=9Cthis is how I can get in touch with an RO that I=E2=80=99m not tal= king to=E2=80=9D, and certainly not communicate with another client, anothe= r AS, or other part of the GNAP protocol.=C2=A0

    [FIM] Not entirely clear whe= re we draw the line. I imagine "person sitting in front of me right no= w" is not to be taken literally? (could be my doctor, even if he's= not in the same room).
    Clearly th= ere's no way a client can ever guarantee a reliable communication with = something else,=C2=A0I agree. At the very best it's a hint (and possibl= y a bad one).

    If the doctor isn=E2=80=99t using the client application, then the doctor= =E2=80=99s not the =E2=80=9Cuser=E2=80=9D in protocol terms. If the AS has = some other way to get the doctor involved, it should be able to do that, bu= t the client can=E2=80=99t really do anything about it.

    =C2=A0- Justin


    =C2=A0- Justin

    =

    <= /div>
    Adrian

    On Mon, Mar 15, 2021 at 10:12 PM Adrian Gropp= er <agropper= @healthurl.com> wrote:
    Hi Justin,

    I have exactly= the same two questions as Fabien and also, I=C2=A0

    On Mon, Mar 15, 20= 21 at 9:45 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Justi= n

    A few questions :
    - we're covering the use case "get my medical data&qu= ot;, how does that change if that's someone else's data?=C2=A0
    - what happens if the agent can't guarantee availabi= lity?=C2=A0

    Fabien=C2=A0=


    Le lun. 15 mars 2021 =C3=A0 20:42, Justin Richer <jricher@mit.edu> a =C3=A9crit=C2= =A0:
    Hi Adr= ian, thanks so much for writing up this use case. I=E2=80=99ve included som= e thoughts below into how different aspects of GNAP might map to these requ= irements. I don=E2=80=99t think mapping any human system to any technology = is clean and dry, but for what it=E2=80=99s worth I do see a lot of alignme= nt.

    On Mar 12, 2021, at 4:34 PM,= Adrian Gropper <agropper@healthurl.com> wrote:

    Let=E2=80=99s try= to map a real-world use-case into the names and roles we are discussing. T= he use-case is documented as the API Task Force Recommendations (2016) https://www.healthit.gov/sites= /default/files/facas/SingleSourceofTruth-APITFRecommendations.pdf and I=E2= =80=99ve copied below the most relevant section. Bold highlight i= s in the original. I=E2=80=99ve added bold i= talic
    </quote>
    =

    The k= ey requirements from a patient rights and privacy perspective are:
    1. To delegate a scope-limited access= capability to anyone anywhere without having to explain or justify that to= the API Provider.

    This will always be susceptible to the level of gra= nularity that the API Provider allows the API to be accessed in.=C2=A0

    Standard APIs (which would result in standard =E2=80= =9Ctype=E2=80=9D values in the =E2=80=9Caccess=E2=80=9D request array) can = help with this by defining sufficient levels of detail. But ultimately, the= user could never ask for a scope that the API Provider isn=E2=80=99t willi= ng to express.

    1. To allow the patient = to automate the issue of a scope-limited access capability by delegating th= e authority to process API access requests to some agent. The API Provider = has no say in who or where this agent is.

    This is where I think this d= iscussion really should go. On the surface, this seems to lead to the =E2= =80=9Cbring your own AS=E2=80=9D model. I am contending that it=E2=80=99s m= ore powerful to have an AS (still under the API Provider=E2=80=99s control)= that allows the user to provide additional inputs during the protocol proc= ess. As an industry, we can standardize and innovate a lot of those inputs,= but ultimately GNAP should be able to just connect those endpoints to each= other (in my opinion). One of the common inputs is going to remain =E2=80= =9Cget someone to log in at this webpage at the AS and click a button=E2=80= =9D, but I=E2=80=99m convinced there will be others.

    1. The automation of the agent is based on policies provided b= y the patient. The agent is able to process access requests from anyone and= is responsible only to the patient. The agent responds to successful reque= sts by issuing a filtered capability to the requesting party.
      <= /li>

    In this = case, shouldn=E2=80=99t it be that the agent is separated from the AS? Sinc= e the patient is going to have data protected by different API Provders, to= me it stands to reason that they=E2=80=99d want the same agent acting for = them on different systems. Each of those systems would still have its own A= S, but the AS would be facilitated by the user=E2=80=99s input.
    <= br>
    Now this is NOT saying that the user would have their own AS = to delegate something to the downstream AS. Or even saying that the user wo= uld have some kind of XACML policy server. I=E2=80=99m not sure exactly how= the bits on the wire would work but a strawman would look something like:<= /div>


    3D"https://www.websequencediagrams.co=

    User -> Client: go= access my medical data
    Client -> RS: hey I want to access thi= s medical data
    RS -> Client: sure go talk to this AS
    Client -> Agent: I need to make a request for data, how can I get the A= S in touch with you?
    Agent -> Client: tell them to use [some k= ind of magic]
    Client -> AS: hey I want to access this medical = data; I can get the user to interact with you or I can put you in touch wit= h their policy agent
    AS -> Client: OK I=E2=80=99ll talk to the= policy agent
    AS -> Agent: I have a request for data, I need y= ou to prove that you have the right to release this data
    Agent -&= gt; User: It looks like Client is asking for stuff at RS through AS, that c= ool?
    Agent -> AS: OK, here you go [more magic]
    AS -&= gt; Client: ok, here=E2=80=99s an access token that=E2=80=99s good for acce= ssing that AS
    Client -> RS: hey, I want to access this medical= data and here=E2=80=99s an access token for it

  • To ensure that the requesting pa= rty can delegate the capability using an institutional workflow system that= they trust and the patient doesn=E2=80=99t know or care about. In many cas= es, the workflow system will pass the capability to some other person, who = we might call the end user. In other cases, the requesting party may forwar= d the capability directly to another person using, for example, an email. E= ither way, the client app used by the end-user to access the API is of no c= oncern to the patient or to the patient=E2=80=99s agent.=C2=A0
    =

    • To faci= litate this, the =E2=80=9Cagent=E2=80=9D above can be augmented with other = capabilities based on what=E2=80=99s being asked for. Adding a line to the = flow above:

    User -> Client: go access my m= edical data
    Client -> RS: hey I want to access this medical da= ta
    RS -> Client: sure go talk to this AS
    Client ->= ; Agent: I need to make a request for data, how can I get the AS in touch w= ith you?
    Agent -> Client: tell them to use [some kind of magic= ]
    Client -> AS: hey I want to access this medical data; I can = get the user to interact with you or I can put you in touch with their poli= cy agent
    AS -> Client: OK I=E2=80=99ll talk to the policy agen= t
    AS -> Agent: I have a request for data, I need you to prove = that you have the right to release this data
    Agent -> User: It= looks like Client is asking for stuff at RS through AS, that cool?
    Agent -> AS: OK, here you go [more magic]
    AS -> RO: I= t looks like someone's asking for an RS you have the approval for, that= cool?
    AS -> Client: ok, here=E2=80=99s an access token th= at=E2=80=99s good for accessing that AS
    Client -> RS: hey, I w= ant to access this medical data and here=E2=80=99s an access token for it

    In other words, when the AS gets the request, it ca= n and should take in inputs from multiple different dimensions in order to = make the authorization decision and encode that into the access token.

    1. To ensure that the API Provider doe= s not censor the client app that presents the capability or solicits too mu= ch information about the client app or the end-user of the client app.=C2= =A0

    This is one of the reasons that the AS-based model is really impor= tant in GNAP =E2=80=94 the API Provider's RS only needs to know =E2=80= =9Cis this token good for what=E2=80=99s being asked=E2=80=9D.=C2=A0
    <= br>
    1. If the API Provider decides, for any reason= , to be =E2=80=9Csuspicious=E2=80=9D (as above) of the access transaction b= ased on the information it has, it should be possible for the API Provider = to warn the patient and to accept an override of the warning by the patient= . This effectively means that the end-user will provide as much information= as they think will be necessary in order to either avoid =E2=80=9Csuspicio= n=E2=80=9D or risk waiting for patient override.

    If the AS can reach o= ut to the patient through notice and consent, they can be brought into the = process in an interactive way above. This assumes the AS has a way of conne= cting that, but we should assume the AS can provide this kind of notice and= consent to parties that aren=E2=80=99t directly involved in the protocol f= low in the same way the end user is.

    1. = The policies by which the patient or the decides to grant a capability to t= he requesting party are never shared outside of the patient-agent trust rel= ationship. In other words, neither the patient nor the agent is asked to sh= are or explain their reason for an access decision.=C2=A0
      2. =


    1. Access requests to the agen= t are presumed confidential among the patient, the agent, and whatever clie= nt the requesting party uses to present an access request. The API Provider= does not get to see the requests and no entity in the GNAP authorization p= rocess, other than the patient or the agent, gets to correlate across reque= sts by different requesting party clients.

    This would be a different k= ind of model, where the client would act as some kind of proxy in the proce= ss. Something more like:

    3D"https://www.websequenced=

    User -> = Client: go access my medical data
    Client -> RS: hey I want to = access this medical data
    RS -> Client: sure go talk to this AS=
    Client -> Agent: I need to make a request for data, how can I= get the AS in touch with you?
    Agent -> Client: tell them to u= se [some kind of magic]
    Client -> AS: hey I want to access thi= s medical data; I can get the user to interact with you or I can forward yo= ur request details to the policy agent
    AS -> Client: OK go tal= k to the policy agent, ask for these kinds of things
    Client ->= Agent: I have a request for data, at this AS, I need you to prove that you= have the right to release this data
    Agent -> User: It looks l= ike Client is asking for stuff at RS through AS, that cool?
    Agent= -> Client: OK, here you go [more magic]
    Client -> AS: Here= =E2=80=99s the result of that policy thing you asked for [more magic]
    =
    AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99s goo= d for accessing that AS
    Client -> RS: hey, I want to access th= is medical data and here=E2=80=99s an access token for it


    Note that I am not = saying all 8 requirements are in scope for GNAP but I am asking for GNAP to= allow for this level of privacy on the part of self-sovereign patients usi= ng self-sovereign agents and the self-sovereign licensed professionals they= deal with.

    For me the important part is that GNAP allow these kinds of trust co= nnections. Even if GNAP isn=E2=80=99t solving every piece of this equation,= it can at least clearly state =E2=80=9Cthere=E2=80=99s a function here tha= t needs to / is able to solve this thing=E2=80=9D and build the important p= arts around it.


    =C2=A0- Justin


    Adrian
    <= br>

    On Fri, Mar 12, 2021 at 2:50 PM Fabien Imbault <fabien.im= bault@gmail.com> wrote:
    Hi Justin,=C2=A0

    Just a = quick word to say I very much agree with both the observations and the fram= ing.

    Fabien

    On Fri, Mar 12, 2021 at 6:07 PM J= ustin Richer <jricher@mit.edu> wrote:
    As discussed at the IETF meeting, the edi= tors proposed that one of our next big topic areas was going to be the natu= re of the AS role within the GNAP protocol, especially how it relates to th= e device-driven use cases that have been brought up. Apologies in advance f= or the long post, but there are a lot of parts to this discussion that I=E2= =80=99m hoping we can kick off here.

    My core proposal is= that we see the AS as the component that has the following properties:
    =C2=A0- receives delegation requests from the client instance for ac= cess to an RS via access tokens, and for access to subject information retu= rned directly to the client instance
    =C2=A0- collects consent and= authorization from the RO for the delegation
    =C2=A0- issues acce= ss tokens that its downstream RS=E2=80=99s can interpret (and validate/acce= pt)
    =C2=A0- issues subject information asserted by the AS=C2=A0

    This framing of the parties is really important in ma= king a consistent understanding of how the protocol works, and a consistent= understanding is vital if we=E2=80=99re going to function as a working gro= up in both discussing the problem space and executing the solution space. F= or a historical example, a naive approach to adding identity on top of a pr= otocol like OAuth 2 (or GNAP) is to declare that the resource server is the= thing the user is logging in to. This seems reasonable at first (and some = people tried doing this) but it violates all kinds of trust boundaries and = puts new expectations on the different parties that do not make sense. It s= tops looking anything like OAuth very quickly and turns into another protoc= ol. If instead we say the user is logging in to the client, things suddenly= make a lot more sense and we can do a lot more with it. (See this blog pos= t from 2013 for one take on that discussion:=C2=A0https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0= -and-sign-in-4/)

    I think we=E2=80=99ve got a s= imilar situation here when we start to talk about the user bringing their o= wn AS with them. I think this is a reasonable-seeming assumption but it=E2= =80=99s based on a false premise that the RO has to log into the AS to appr= ove the request, and the AS has full control and view over everything in th= e network. While OAuth doesn=E2=80=99t require this, it=E2=80=99s largely a= ssumed that=E2=80=99s how it works. After all, all of the early OAuth deplo= yments worked exactly this way: the user logs in and clicks the =E2=80=9COK= =E2=80=9D button. However, cloud deployments have shown us that it=E2=80=99= s perfectly reasonable for an OAuth AS to take in its consent and user info= rmation from an external trusted source, and so this model is not even accu= rate in OAuth.

    In short, I think we can do a bette= r job here of defining things in terms that both accept the reality we face= and enable new ideas in ways that make sense. It=E2=80=99s my stance that = the user shouldn=E2=80=99t need to bring the AS with them in order to have = the kind of input and control of the system that people are asking for. Ins= tead, the AS should be able to take inputs from things that the user contro= ls in order for the AS to do its job.

    People have = discussed privacy concerns with the AS knowing =E2=80=9Ctoo much=E2=80=9D, = but in many of those discussions the knowledge is simply pushed to the RS i= nstead. What I=E2=80=99m observing here is really just pushing portions of = the AS role into the =E2=80=9CRS=E2=80=9D deployment. This doesn=E2=80=99t = make it less of an =E2=80=9CAS=E2=80=9D role, it=E2=80=99s just being fulfi= lled closely to where the RS role is fulfilled. As such, my proposal is rea= lly not that different in practice, but the labels are different and better= aligned with the capabilities of the protocol.=C2=A0

    <= /div>
    We=E2=80=99ve previously talked about separating the user-facing = portions of the AS into another component, and I think now might be the tim= e to do that. This is a very flammable strawman proposal, but what if we ha= d the AS defined, as above, and the =E2=80=9Cconsent and authorization=E2= =80=9D gathering portion is augmented by another named component. Here let= =E2=80=99s call it an Interaction Component. This can take several forms ba= sed on the kind of interaction mode in use:

    =C2=A0= - Hosted at a URL the user is redirected to; it can then make the user log = in, consent, and whatever else they need to do
    =C2=A0- Hosted at = a URL the user will load separately and enter in an access code
    = =C2=A0- An app on the user=E2=80=99s device that the user interacts with di= rectly and which sends information back to the AS
    =C2=A0- An app = reachable by a messaging endpoint that the AS sends and receives structured= information from
    =C2=A0- The client itself that is given an indi= cation as to what information the AS needs in order to fulfill the request;= this could be MFA challenge/response, user credentials, signed claims, etc= .

    It=E2=80=99s the AS=E2=80=99s job to accept any = and all of these that it supports and churn those into an access token.=C2= =A0

    The AS itself doesn=E2=80=99t ever need to hav= e the user log in. The AS doesn=E2=80=99t necessarily need to even know who= the user is in any way. The AS just needs to know from a trusted source th= at the request is approved.

    From a practical stand= point, I think this will have some small changes in how we talk about the c= omponents and how we talk about the interaction phase of the grant negotiat= ion process. Everything I=E2=80=99m laying out here is currently allowed by= the spec, but I think we=E2=80=99ve carried through the same assumptions f= rom OAuth 2 about deployment that are both inaccurate and confusing.=C2=A0<= /div>

    =C2=A0=E2=80=94 Justin
    --=C2=A0
    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<= br>

    --=C2=A0
    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/m= ailman/listinfo/txauth

    <= /div> --000000000000366db805bda89fb4-- From nobody Tue Mar 16 08:04:31 2021 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 7E3BF3A10E6 for ; Tue, 16 Mar 2021 08:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 7TutSHxGOZH3 for ; Tue, 16 Mar 2021 08:04:23 -0700 (PDT) Received: from mail-vk1-f173.google.com (mail-vk1-f173.google.com [209.85.221.173]) (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 0B4073A10FF for ; Tue, 16 Mar 2021 08:04:20 -0700 (PDT) Received: by mail-vk1-f173.google.com with SMTP id s136so2358020vks.4 for ; Tue, 16 Mar 2021 08:04:19 -0700 (PDT) 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=pRyCD9fj/Umw4A74o3xXEGfPj9h8VavstjB2TQtSzJQ=; b=V7/ynxVtTZbluirgsWzzmGr9Oqk/Y0Fxqq/bpumT8PZsiW5jCOcbT+2io4Dc80a+3R x9wRaQy+lL8//hCgomzVXpjNLftcM8l8tNqu80Ix56vyHFcQz8VCeEIXrYYHC3UVQLO3 8V39V6I4Vte6SJ0V7X66WTEvaOAd2wFrFanqJX6FbeTohBO01BCvWDhOMOMz6ArejsAL UCoF2ZWhrItMkp+4ld8bgfrq0/VGPhhymnB2QwNlNnJzh5Upp81//fw+MczqvbO/rz2g WSg3tVxjkVPLnlyGKEShpZtFyBqq7xImnbAiQ/oXgwWF5OaJbQDRS3kO6KOWDjmrlcye cEpQ== X-Gm-Message-State: AOAM532Z+4wPCD8DIjvE6qkKPSTPH/LprPtqIQl4pOc1Z0TCkdcNK31m reeC1UmROlHsEW15DglI3LHf9epf2dwZC3Y6KUM= X-Google-Smtp-Source: ABdhPJyVw9Pz1HcjcBqyUY+bd1msjymbHvo+RTvop8xztRBulWaTR+rUONm/xUZYXIGnwM0iNjfAsS5sAFaWU7HLjuM= X-Received: by 2002:a05:6122:889:: with SMTP id 9mr4310650vkf.10.1615907058677; Tue, 16 Mar 2021 08:04:18 -0700 (PDT) MIME-Version: 1.0 References: <205ACFE1-7D4C-4D7C-B394-4AD8A4D4D080@mit.edu> <4AD539F3-31BE-4162-BE2B-69D5AE22B48E@mit.edu> <6B51886D-35F6-443C-B9B6-4C8F22EE11CF@mit.edu> In-Reply-To: From: Adrian Gropper Date: Tue, 16 Mar 2021 11:04:06 -0400 Message-ID: To: Fabien Imbault Cc: Justin Richer , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000038fb0405bda8ae18" Archived-At: Subject: Re: [GNAP] GNAP Architecture and the role of the AS X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 15:04:30 -0000 --00000000000038fb0405bda8ae18 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I share the goal of finding the appropriate extension points but I'm having a hard time following the conversation because we're not talking about the specific use case. Let me try and recap: - The doctor is live and using a client application to place a request to an AS that pertains to a particular RO as the subject. - The RO has delegated authorization to an on-line agent and the RO themselves may be offline. - Any of the various actors in the GNAP protocol may raise warnings or exceptions and could try to reach the RO if provided with appropriate hints. The actual mechanisms for contacting the RO are likely out of scope for GNAP but we do need to consider the extension points and hints for some or all actors we do identify in the GNAP spec. - Given the above, Justin is proposing that the AS and the agent are separate actors, both online, and need to interact in order to turn the doctor's request into an authorization token. - This interaction between the AS and the agent is clearly at the heart of GNAP and how we explain GNAP to others. - If the RO's policies are in one actor (the agent) and the request is presented to another actor (the AS) then GNAP becomes a protocol for how an agent interacts with an AS. - The capability to be turned into an authorization token originates with the RS-RO relationship. It could have been given to the RO, the agent, or the AS initially. Some of these might be out of scope for GNAP and others need to be specified. - The capability to issue an authorization needs is the third essential component of GNAP along with policies (at the agent) and a request receipt endpoint (of the AS). - The RO has a privacy interest in getting the request in a way that the AS does not benefit from. GNAP must not force the agent to share request information with anyone that is not a principal to the transaction. Those principals are the RO, their agent, and the RS. Adrian On Tue, Mar 16, 2021 at 11:00 AM Fabien Imbault wrote: > Same, thanks for the clarification. > > On Tue, Mar 16, 2021 at 3:11 PM Justin Richer wrote: > >> Responses inline.. >> >> On Mar 16, 2021, at 9:19 AM, Fabien Imbault >> wrote: >> >> Hi Justin, >> >> My comments in red [FIM]. >> >> Cheers >> Fabien >> >> On Tue, Mar 16, 2021 at 1:14 PM Justin Richer wrote: >> >>> On Mar 15, 2021, at 10:16 PM, Adrian Gropper >>> wrote: >>> >>> Hi Justin, >>> >>> I have exactly the same two questions as Fabien and also, I worry about >>> the handwaving in the answer to 7. >>> >>> >>> The handwaving is actually important. I don=E2=80=99t think that=E2=80= =99s something >>> that GNAP will solve in a universal way. We can have hooks in the core >>> protocol that say =E2=80=9Cand now go do This Other Thing to talk to an= agent=E2=80=9D, but >>> I don=E2=80=99t think we=E2=80=99re really the best ones to decide what= that is or what it >>> looks like for everyone. >>> >>> This could be DIDComm, it could be CHAPI, it could be some proprietary >>> app connection with push notifications, it could be writing/reading fro= m a >>> shared encryption storage fabric =E2=80=94 all that=E2=80=99s important= here is that GNAP >>> has a place in the protocol where these various things can fit. >>> >>> OAuth chose HTTP Redirects as The Way to get users involved in the >>> process, but GNAP is taking a very different stance in trying to get aw= ay >>> from that limiting assumption. I don=E2=80=99t think it would serve us = to just make >>> a different limiting assumption about how users (and their decisions) g= et >>> involved. >>> >> >> [FIM] We shouldn't be looking for an universal carrier, I agree, but >> people will need practical ways to implement that. I think there's a fin= e >> line between avoiding limiting assumptions and GNAP remaining too >> conceptual. At least we should know where to put the extension points. >> >> >> I agree that we need to have the extension points in the right place. In >> order to do that, we need to know what we=E2=80=99re extending, which wa= s the >> impetus for starting this conversation. It=E2=80=99s debatable how much = further we >> want to go beyond that in GNAP itself, especially since there are a lot = of >> other protocols out there designed to fit this niche well (see examples >> above). >> >> One step we definitely can help with is providing a cohesive model for >> describing both people and access rights, and being clear about the over= all >> process. >> > > [FIM2] clearer to me, thanks. > >> >>> To answer the questions; >>> >>> - we're covering the use case "get my medical data", how does that >>>>> change if that's someone else's data? >>>>> >>>> >>> It=E2=80=99s the same process as the second flow. The RO is the patient= or >>> doctor or someone who can approve things. The AS doesn=E2=80=99t get ev= erything >>> that it needs to from the agent introduced by the client, so it needs t= o >>> access another agent. >>> >> >>> - what happens if the agent can't guarantee availability? >>>>> >>>> >>> Then the AS doesn=E2=80=99t get what it needs in order to fulfill the r= equest >>> and it denies the request. Whether that=E2=80=99s a timeout or some oth= er error, >>> and whether that comes back to the client with a =E2=80=9Ctry again=E2= =80=9D or with a >>> =E2=80=9Ctough luck, go away=E2=80=9D, I think that=E2=80=99s all up fo= r debate, and parts of that >>> we=E2=80=99ll need answers for. But ultimately, it=E2=80=99s the same k= ind of thing that >>> happens in OAuth if the user doesn=E2=80=99t consent, or the user can= =E2=80=99t log in, or >>> the =E2=80=9Cwrong=E2=80=9D user logs in for what=E2=80=99s being asked= for =E2=80=94 the AS isn=E2=80=99t >>> satisfied with the approval so the delegation request fails. >>> >> >> [FIM] seems realistic when user =3D RO, the end-user can make itself >> available if the service is really important to him. "Tough luck" at fir= st >> failure is fine then. >> But I believe that becomes impractical when a remote RO is involved (at >> least if it's supposed to be a human: if we don't deal with unavailabili= ty, >> async sequence 1.4.3 should be removed). >> >> >> Then, what is the AS to do if it tries the methods necessary to reach th= e >> RO, but those methods fail? Or if there are multiple RO=E2=80=99s who co= uld approve >> and multiple come back? >> > [FIM2] yes, that's some of the cases (and open questions) I put forward i= n > the presentation, trying to identify what would have to be dealt with. > It would be fine to decide all interactions need to be synchronous > requests/responses in the core. > >> >> I agree that these are situations the AS is going to have to deal with, >> but I also believe that the details of what gets us into these situation= s >> is outside of GNAP itself. Perhaps think of it this way: >> >> - The AS needs to gather authorization and consent. >> - The client can direct interaction with the end user. >> - The end user might be able to provide that authorization and consent. >> - The client doesn=E2=80=99t know if the end user is the RO, but it can= provide >> the AS with hints as to who the end user is and means to interact with t= hem >> for the AS. >> - The AS knows who the RO is and might have ways to interact with them >> (and their decisions) outside of the interface with the client. >> >> So in other words, the consent-gathering process that the AS goes throug= h >> can be both client-mediated and non-client-mediated. The client-mediated >> portions are very much in scope of GNAP and they fall into the space of >> user =3D=3D RO very easily. The non-client-mediated interactions are out= side >> the scope of GNAP =E2=80=94 or at least outside the core protocol, since= the core >> protocol is all about the client instance getting a token (and/or subjec= t >> info). >> > [FIM2] that could be a viable way to refine the scope of the core. As lon= g > as it's clear what we do, it's fine to me. > >> >> I think we can expand the discussion in the draft of how the AS goes >> through this consent gathering process but shouldn=E2=80=99t try to defi= ne one >> specific way of it happening. That way we can define good behavior aroun= d >> asynchronous methods, timeouts, and multi-user protocols, but without >> having to define, say, a wire-based policy language to carry those >> decisions. It=E2=80=99s definitely a fine line! >> > [FIM2] yes, for sure DIDComm was in my view just one example of a possibl= e > extended interact method (among many possible already today and more in t= he > future). > In practice, none of those non-client-mediated interactions need to be in > the core. However, they would probably require that GNAP defines how one > should react to such async or message based patterns, above the underlyin= g > protocol foundation, to provide "elegant, synchronous request-response > interactions." (as said in 1.3.1 of DIDComm). Defining good async behavio= ur > without minimal syntax is possible with coloring schemes, but they have > their drawbacks too (forces you to always think in colors, even for basic > sync cases, and so I'm not convinced that would be a win). > >> >> Your flow for 8 doesn't make sense to me because I assume the client is >>> on the RO's mobile device and unavailable for most interactions. The wh= ole >>> point of having the Agent is to keep the RO Client out of the picture w= hen >>> the requesting party shows up with their Client. >>> >>> >>> The RO doesn=E2=80=99t have a client in any of the flows below. The RO = might >>> have an agent, they might have an app that notifies them to go log into= a >>> webpage asynchronously, they might get an email with a link to click ba= ck >>> at the AS. None of that is facilitated through the RO=E2=80=99s client = because the >>> RO doesn=E2=80=99t have a =E2=80=9Cclient=E2=80=9D in this model. The c= lient is by definition the >>> software in front of the =E2=80=9Cuser=E2=80=9D, the requesting party. >>> >> [FIM] yes indeed >> >>> >>> And it=E2=80=99s important in the design that the client doesn=E2=80=99= t need to know >>> about any of that. It can identify the resource, possibly identify the = RO, >>> and it can tell the AS =E2=80=9Cthis is how I can talk to the person si= tting in >>> front of me right now=E2=80=9D =E2=80=94 for whatever definition of =E2= =80=9Ctalk to=E2=80=9D makes sense >>> for the client app. What it can=E2=80=99t reliably do is say =E2=80=9Ct= his is how I can get >>> in touch with an RO that I=E2=80=99m not talking to=E2=80=9D, and certa= inly not communicate >>> with another client, another AS, or other part of the GNAP protocol. >>> >> >> [FIM] Not entirely clear where we draw the line. I imagine "person >> sitting in front of me right now" is not to be taken literally? (could b= e >> my doctor, even if he's not in the same room). >> Clearly there's no way a client can ever guarantee a reliable >> communication with something else, I agree. At the very best it's a hint >> (and possibly a bad one). >> >> >> If the doctor isn=E2=80=99t using the client application, then the docto= r=E2=80=99s not >> the =E2=80=9Cuser=E2=80=9D in protocol terms. If the AS has some other w= ay to get the >> doctor involved, it should be able to do that, but the client can=E2=80= =99t really >> do anything about it. >> >> - Justin >> >> >>> - Justin >>> >>> >>> Adrian >>> >>> On Mon, Mar 15, 2021 at 10:12 PM Adrian Gropper >>> wrote: >>> >>>> Hi Justin, >>>> >>>> I have exactly the same two questions as Fabien and also, I >>>> >>>> On Mon, Mar 15, 2021 at 9:45 PM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Hi Justin >>>>> >>>>> A few questions : >>>>> - we're covering the use case "get my medical data", how does that >>>>> change if that's someone else's data? >>>>> - what happens if the agent can't guarantee availability? >>>>> >>>>> Fabien >>>>> >>>>> >>>>> Le lun. 15 mars 2021 =C3=A0 20:42, Justin Richer a >>>>> =C3=A9crit : >>>>> >>>>>> Hi Adrian, thanks so much for writing up this use case. I=E2=80=99ve= included >>>>>> some thoughts below into how different aspects of GNAP might map to = these >>>>>> requirements. I don=E2=80=99t think mapping any human system to any = technology is >>>>>> clean and dry, but for what it=E2=80=99s worth I do see a lot of ali= gnment. >>>>>> >>>>>> On Mar 12, 2021, at 4:34 PM, Adrian Gropper >>>>>> wrote: >>>>>> >>>>>> Let=E2=80=99s try to map a real-world use-case into the names and ro= les we >>>>>> are discussing. The use-case is documented as the API Task Force >>>>>> Recommendations (2016) >>>>>> https://www.healthit.gov/sites/default/files/facas/SingleSourceofTru= th-APITFRecommendations.pdf >>>>>> and I=E2=80=99ve copied below the most relevant section. Bold highli= ght is >>>>>> in the original. I=E2=80=99ve added bold italic because it may be im= portant >>>>>> to our discussion. >>>>>> >>>>>> >>>>>> >>>>>> - >>>>>> >>>>>> ONC should clarify that while API Providers may impose security >>>>>> related restrictions on app access (e.g. rate limiting, encryptio= n, and >>>>>> expiration of access tokens), it is inappropriate for API provide= rs to set >>>>>> limitations on what a patient authorized app can do with data dow= nstream. >>>>>> - Given the nature of patient access rights, the provider is not >>>>>> in a legal position to prevent the registration of apps that w= ould >>>>>> aggregate or share data, for example (though the provider migh= t certainly >>>>>> decide to warn the patient, or endeavor to educate and explain= these issue >>>>>> to the patient, as part of the provider hosted app approval wo= rkflow). >>>>>> - ONC should clarify that API providers are not obligated to >>>>>> protect patients by identifying "suspicious" apps. API providers = may >>>>>> suspend API access to an app that has breached the API provider's >>>>>> terms of service , or appears to have been compromised, or if the= app poses >>>>>> a threat to the provider's own system. However, patients must be >>>>>> able to override this suspension (except in the case where an app >>>>>> poses threat to the provider's own system or violates allowable t= erms of >>>>>> service). >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The key requirements from a patient rights and privacy perspective >>>>>> are: >>>>>> >>>>>> >>>>>> 1. To delegate a scope-limited access capability to anyone >>>>>> anywhere without having to explain or justify that to the API Pro= vider. >>>>>> >>>>>> >>>>>> This will always be susceptible to the level of granularity that the >>>>>> API Provider allows the API to be accessed in. >>>>>> >>>>>> Standard APIs (which would result in standard =E2=80=9Ctype=E2=80=9D= values in the >>>>>> =E2=80=9Caccess=E2=80=9D request array) can help with this by defini= ng sufficient levels of >>>>>> detail. But ultimately, the user could never ask for a scope that th= e API >>>>>> Provider isn=E2=80=99t willing to express. >>>>>> >>>>>> >>>>>> 1. To allow the patient to automate the issue of a scope-limited >>>>>> access capability by delegating the authority to process API acce= ss >>>>>> requests to some agent. The API Provider has no say in who or whe= re this >>>>>> agent is. >>>>>> >>>>>> >>>>>> This is where I think this discussion really should go. On the >>>>>> surface, this seems to lead to the =E2=80=9Cbring your own AS=E2=80= =9D model. I am >>>>>> contending that it=E2=80=99s more powerful to have an AS (still unde= r the API >>>>>> Provider=E2=80=99s control) that allows the user to provide addition= al inputs >>>>>> during the protocol process. As an industry, we can standardize and >>>>>> innovate a lot of those inputs, but ultimately GNAP should be able t= o just >>>>>> connect those endpoints to each other (in my opinion). One of the co= mmon >>>>>> inputs is going to remain =E2=80=9Cget someone to log in at this web= page at the AS >>>>>> and click a button=E2=80=9D, but I=E2=80=99m convinced there will be= others. >>>>>> >>>>>> >>>>>> 1. The automation of the agent is based on policies provided by >>>>>> the patient. The agent is able to process access requests from an= yone and >>>>>> is responsible only to the patient. The agent responds to success= ful >>>>>> requests by issuing a filtered capability to the requesting party= . >>>>>> >>>>>> >>>>>> In this case, shouldn=E2=80=99t it be that the agent is separated fr= om the >>>>>> AS? Since the patient is going to have data protected by different A= PI >>>>>> Provders, to me it stands to reason that they=E2=80=99d want the sam= e agent acting >>>>>> for them on different systems. Each of those systems would still hav= e its >>>>>> own AS, but the AS would be facilitated by the user=E2=80=99s input. >>>>>> >>>>>> Now this is NOT saying that the user would have their own AS to >>>>>> delegate something to the downstream AS. Or even saying that the use= r would >>>>>> have some kind of XACML policy server. I=E2=80=99m not sure exactly = how the bits on >>>>>> the wire would work but a strawman would look something like: >>>>>> >>>>>> >>>>>> [image: https://www.websequencediagrams.com/?png=3Dmsc978356221] >>>>>> >>>>>> User -> Client: go access my medical data >>>>>> Client -> RS: hey I want to access this medical data >>>>>> RS -> Client: sure go talk to this AS >>>>>> Client -> Agent: I need to make a request for data, how can I get th= e >>>>>> AS in touch with you? >>>>>> Agent -> Client: tell them to use [some kind of magic] >>>>>> Client -> AS: hey I want to access this medical data; I can get the >>>>>> user to interact with you or I can put you in touch with their polic= y agent >>>>>> AS -> Client: OK I=E2=80=99ll talk to the policy agent >>>>>> AS -> Agent: I have a request for data, I need you to prove that you >>>>>> have the right to release this data >>>>>> Agent -> User: It looks like Client is asking for stuff at RS throug= h >>>>>> AS, that cool? >>>>>> Agent -> AS: OK, here you go [more magic] >>>>>> AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99s good= for accessing >>>>>> that AS >>>>>> Client -> RS: hey, I want to access this medical data and here=E2=80= =99s an >>>>>> access token for it >>>>>> >>>>>> >>>>>> >>>>>> 1. To ensure that the requesting party can delegate the >>>>>> capability using an institutional workflow system that they trust= and the >>>>>> patient doesn=E2=80=99t know or care about. In many cases, the wo= rkflow system will >>>>>> pass the capability to some other person, who we might call the e= nd user. >>>>>> In other cases, the requesting party may forward the capability d= irectly to >>>>>> another person using, for example, an email. Either way, the clie= nt app >>>>>> used by the end-user to access the API is of no concern to the pa= tient or >>>>>> to the patient=E2=80=99s agent. >>>>>> >>>>>> >>>>>> To facilitate this, the =E2=80=9Cagent=E2=80=9D above can be augment= ed with other >>>>>> capabilities based on what=E2=80=99s being asked for. Adding a line = to the flow >>>>>> above: >>>>>> >>>>>> User -> Client: go access my medical data >>>>>> Client -> RS: hey I want to access this medical data >>>>>> RS -> Client: sure go talk to this AS >>>>>> Client -> Agent: I need to make a request for data, how can I get th= e >>>>>> AS in touch with you? >>>>>> Agent -> Client: tell them to use [some kind of magic] >>>>>> Client -> AS: hey I want to access this medical data; I can get the >>>>>> user to interact with you or I can put you in touch with their polic= y agent >>>>>> AS -> Client: OK I=E2=80=99ll talk to the policy agent >>>>>> AS -> Agent: I have a request for data, I need you to prove that you >>>>>> have the right to release this data >>>>>> Agent -> User: It looks like Client is asking for stuff at RS throug= h >>>>>> AS, that cool? >>>>>> Agent -> AS: OK, here you go [more magic] >>>>>> *AS -> RO: It looks like someone's asking for an RS you have the >>>>>> approval for, that cool?* >>>>>> AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99s good= for accessing >>>>>> that AS >>>>>> Client -> RS: hey, I want to access this medical data and here=E2=80= =99s an >>>>>> access token for it >>>>>> >>>>>> In other words, when the AS gets the request, it can and should take >>>>>> in inputs from multiple different dimensions in order to make the >>>>>> authorization decision and encode that into the access token. >>>>>> >>>>>> >>>>>> 1. To ensure that the API Provider does not censor the client app >>>>>> that presents the capability or solicits too much information abo= ut the >>>>>> client app or the end-user of the client app. >>>>>> >>>>>> >>>>>> This is one of the reasons that the AS-based model is really >>>>>> important in GNAP =E2=80=94 the API Provider's RS only needs to know= =E2=80=9Cis this token >>>>>> good for what=E2=80=99s being asked=E2=80=9D. >>>>>> >>>>>> >>>>>> 1. If the API Provider decides, for any reason, to be >>>>>> =E2=80=9Csuspicious=E2=80=9D (as above) of the access transaction= based on the information >>>>>> it has, it should be possible for the API Provider to warn the pa= tient and >>>>>> to accept an override of the warning by the patient. This effecti= vely means >>>>>> that the end-user will provide as much information as they think = will be >>>>>> necessary in order to either avoid =E2=80=9Csuspicion=E2=80=9D or= risk waiting for patient >>>>>> override. >>>>>> >>>>>> >>>>>> If the AS can reach out to the patient through notice and consent, >>>>>> they can be brought into the process in an interactive way above. Th= is >>>>>> assumes the AS has a way of connecting that, but we should assume th= e AS >>>>>> can provide this kind of notice and consent to parties that aren=E2= =80=99t directly >>>>>> involved in the protocol flow in the same way the end user is. >>>>>> >>>>>> >>>>>> 1. The policies by which the patient or the decides to grant a >>>>>> capability to the requesting party are never shared outside of th= e >>>>>> patient-agent trust relationship. In other words, neither the pat= ient nor >>>>>> the agent is asked to share or explain their reason for an access= decision. >>>>>> >>>>>> >>>>>> In the above pattern, the AS and agent would need a way to >>>>>> communicate this with each other. I think the details of this are ou= tside >>>>>> the scope of GNAP but it could take the form of a query/response >>>>>> fulfillment language. VC=E2=80=99s address part of this, but I think= there will >>>>>> need to be other aspects brought to bear here. I think you could hav= e a >>>>>> privacy-preserving protocol that would layer into GNAP here, but I d= on=E2=80=99t >>>>>> know for sure what that would look like. >>>>>> >>>>>> >>>>>> 1. Access requests to the agent are presumed confidential among >>>>>> the patient, the agent, and whatever client the requesting party = uses to >>>>>> present an access request. The API Provider does not get to see t= he >>>>>> requests and no entity in the GNAP authorization process, other t= han the >>>>>> patient or the agent, gets to correlate across requests by differ= ent >>>>>> requesting party clients. >>>>>> >>>>>> >>>>>> This would be a different kind of model, where the client would act >>>>>> as some kind of proxy in the process. Something more like: >>>>>> >>>>>> [image: https://www.websequencediagrams.com/?png=3Dmsc685845457] >>>>>> >>>>>> User -> Client: go access my medical data >>>>>> Client -> RS: hey I want to access this medical data >>>>>> RS -> Client: sure go talk to this AS >>>>>> Client -> Agent: I need to make a request for data, how can I get th= e >>>>>> AS in touch with you? >>>>>> Agent -> Client: tell them to use [some kind of magic] >>>>>> Client -> AS: hey I want to access this medical data; I can get the >>>>>> user to interact with you or I can forward your request details to t= he >>>>>> policy agent >>>>>> AS -> Client: OK go talk to the policy agent, ask for these kinds of >>>>>> things >>>>>> Client -> Agent: I have a request for data, at this AS, I need you t= o >>>>>> prove that you have the right to release this data >>>>>> Agent -> User: It looks like Client is asking for stuff at RS throug= h >>>>>> AS, that cool? >>>>>> Agent -> Client: OK, here you go [more magic] >>>>>> Client -> AS: Here=E2=80=99s the result of that policy thing you ask= ed for >>>>>> [more magic] >>>>>> AS -> Client: ok, here=E2=80=99s an access token that=E2=80=99s good= for accessing >>>>>> that AS >>>>>> Client -> RS: hey, I want to access this medical data and here=E2=80= =99s an >>>>>> access token for it >>>>>> >>>>>> >>>>>> >>>>>> Note that I am not saying all 8 requirements are in scope for GNAP >>>>>> but I am asking for GNAP to allow for this level of privacy on the p= art of >>>>>> self-sovereign patients using self-sovereign agents and the self-sov= ereign >>>>>> licensed professionals they deal with. >>>>>> >>>>>> >>>>>> For me the important part is that GNAP allow these kinds of trust >>>>>> connections. Even if GNAP isn=E2=80=99t solving every piece of this = equation, it >>>>>> can at least clearly state =E2=80=9Cthere=E2=80=99s a function here = that needs to / is able >>>>>> to solve this thing=E2=80=9D and build the important parts around it= . >>>>>> >>>>>> >>>>>> - Justin >>>>>> >>>>>> >>>>>> Adrian >>>>>> >>>>>> >>>>>> On Fri, Mar 12, 2021 at 2:50 PM Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>>> Hi Justin, >>>>>>> >>>>>>> Just a quick word to say I very much agree with both the >>>>>>> observations and the framing. >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> On Fri, Mar 12, 2021 at 6:07 PM Justin Richer >>>>>>> wrote: >>>>>>> >>>>>>>> As discussed at the IETF meeting, the editors proposed that one of >>>>>>>> our next big topic areas was going to be the nature of the AS role= within >>>>>>>> the GNAP protocol, especially how it relates to the device-driven = use cases >>>>>>>> that have been brought up. Apologies in advance for the long post,= but >>>>>>>> there are a lot of parts to this discussion that I=E2=80=99m hopin= g we can kick off >>>>>>>> here. >>>>>>>> >>>>>>>> My core proposal is that we see the AS as the component that has >>>>>>>> the following properties: >>>>>>>> - receives delegation requests from the client instance for acces= s >>>>>>>> to an RS via access tokens, and for access to subject information = returned >>>>>>>> directly to the client instance >>>>>>>> - collects consent and authorization from the RO for the delegati= on >>>>>>>> - issues access tokens that its downstream RS=E2=80=99s can inter= pret (and >>>>>>>> validate/accept) >>>>>>>> - issues subject information asserted by the AS >>>>>>>> >>>>>>>> This framing of the parties is really important in making a >>>>>>>> consistent understanding of how the protocol works, and a consiste= nt >>>>>>>> understanding is vital if we=E2=80=99re going to function as a wor= king group in >>>>>>>> both discussing the problem space and executing the solution space= . For a >>>>>>>> historical example, a naive approach to adding identity on top of = a >>>>>>>> protocol like OAuth 2 (or GNAP) is to declare that the resource se= rver is >>>>>>>> the thing the user is logging in to. This seems reasonable at firs= t (and >>>>>>>> some people tried doing this) but it violates all kinds of trust b= oundaries >>>>>>>> and puts new expectations on the different parties that do not mak= e sense. >>>>>>>> It stops looking anything like OAuth very quickly and turns into a= nother >>>>>>>> protocol. If instead we say the user is logging in to the client, = things >>>>>>>> suddenly make a lot more sense and we can do a lot more with it. (= See this >>>>>>>> blog post from 2013 for one take on that discussion: >>>>>>>> https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-i= n-4/ >>>>>>>> ) >>>>>>>> >>>>>>>> I think we=E2=80=99ve got a similar situation here when we start t= o talk >>>>>>>> about the user bringing their own AS with them. I think this is a >>>>>>>> reasonable-seeming assumption but it=E2=80=99s based on a false pr= emise that the RO >>>>>>>> has to log into the AS to approve the request, and the AS has full= control >>>>>>>> and view over everything in the network. While OAuth doesn=E2=80= =99t require this, >>>>>>>> it=E2=80=99s largely assumed that=E2=80=99s how it works. After al= l, all of the early OAuth >>>>>>>> deployments worked exactly this way: the user logs in and clicks t= he =E2=80=9COK=E2=80=9D >>>>>>>> button. However, cloud deployments have shown us that it=E2=80=99s= perfectly >>>>>>>> reasonable for an OAuth AS to take in its consent and user informa= tion from >>>>>>>> an external trusted source, and so this model is not even accurate= in OAuth. >>>>>>>> >>>>>>>> In short, I think we can do a better job here of defining things i= n >>>>>>>> terms that both accept the reality we face and enable new ideas in= ways >>>>>>>> that make sense. It=E2=80=99s my stance that the user shouldn=E2= =80=99t need to bring the >>>>>>>> AS with them in order to have the kind of input and control of the= system >>>>>>>> that people are asking for. Instead, the AS should be able to take= inputs >>>>>>>> from things that the user controls in order for the AS to do its j= ob. >>>>>>>> >>>>>>>> People have discussed privacy concerns with the AS knowing =E2=80= =9Ctoo >>>>>>>> much=E2=80=9D, but in many of those discussions the knowledge is s= imply pushed to >>>>>>>> the RS instead. What I=E2=80=99m observing here is really just pus= hing portions of >>>>>>>> the AS role into the =E2=80=9CRS=E2=80=9D deployment. This doesn= =E2=80=99t make it less of an =E2=80=9CAS=E2=80=9D >>>>>>>> role, it=E2=80=99s just being fulfilled closely to where the RS ro= le is fulfilled. >>>>>>>> As such, my proposal is really not that different in practice, but= the >>>>>>>> labels are different and better aligned with the capabilities of t= he >>>>>>>> protocol. >>>>>>>> >>>>>>>> We=E2=80=99ve previously talked about separating the user-facing p= ortions >>>>>>>> of the AS into another component, and I think now might be the tim= e to do >>>>>>>> that. This is a very flammable strawman proposal, but what if we h= ad the AS >>>>>>>> defined, as above, and the =E2=80=9Cconsent and authorization=E2= =80=9D gathering portion is >>>>>>>> augmented by another named component. Here let=E2=80=99s call it a= n Interaction >>>>>>>> Component. This can take several forms based on the kind of intera= ction >>>>>>>> mode in use: >>>>>>>> >>>>>>>> - Hosted at a URL the user is redirected to; it can then make the >>>>>>>> user log in, consent, and whatever else they need to do >>>>>>>> - Hosted at a URL the user will load separately and enter in an >>>>>>>> access code >>>>>>>> - An app on the user=E2=80=99s device that the user interacts wit= h >>>>>>>> directly and which sends information back to the AS >>>>>>>> - An app reachable by a messaging endpoint that the AS sends and >>>>>>>> receives structured information from >>>>>>>> - The client itself that is given an indication as to what >>>>>>>> information the AS needs in order to fulfill the request; this cou= ld be MFA >>>>>>>> challenge/response, user credentials, signed claims, etc. >>>>>>>> >>>>>>>> It=E2=80=99s the AS=E2=80=99s job to accept any and all of these t= hat it supports >>>>>>>> and churn those into an access token. >>>>>>>> >>>>>>>> The AS itself doesn=E2=80=99t ever need to have the user log in. T= he AS >>>>>>>> doesn=E2=80=99t necessarily need to even know who the user is in a= ny way. The AS >>>>>>>> just needs to know from a trusted source that the request is appro= ved. >>>>>>>> >>>>>>>> From a practical standpoint, I think this will have some small >>>>>>>> changes in how we talk about the components and how we talk about = the >>>>>>>> interaction phase of the grant negotiation process. Everything I= =E2=80=99m laying >>>>>>>> out here is currently allowed by the spec, but I think we=E2=80=99= ve carried >>>>>>>> through the same assumptions from OAuth 2 about deployment that ar= e both >>>>>>>> inaccurate and confusing. >>>>>>>> >>>>>>>> =E2=80=94 Justin >>>>>>>> -- >>>>>>>> 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 >>>>> >>>> >>> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> --00000000000038fb0405bda8ae18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I share the=C2=A0goal of finding the= =C2=A0appropriate extension points but I'm having a hard time following= the conversation because we're not talking about the specific use case= .=C2=A0

    Let me try and recap:
    - The doctor is live and using a cli= ent application to place a request to an AS that pertains to a particular R= O=C2=A0as=C2=A0the subject.=C2=A0
    - The RO has delegated authoriz= ation to an on-line agent and the RO themselves may be offline.
    =
    - Any of the various actors in the GNAP pro= tocol may raise warnings or exceptions and could try to reach the RO if=C2= =A0provided with appropriate hints. The actual mechanisms for contacting=C2= =A0the RO are likely out of scope for GNAP but we do need to consider the e= xtension points and hints for some or all actors we do identify in the GNAP= spec.
    - Given the above, Justin is pr= oposing that the AS and the agent are separate actors, both online, and nee= d to interact in order to turn the doctor's request into an authorizati= on token.
    - This interaction between t= he AS and the agent is clearly at the heart of GNAP and how we explain GNAP= to others.=C2=A0
    - If the RO's po= licies are in one actor (the agent) and the request is presented to another= actor (the AS) then GNAP becomes a protocol for how an agent interacts wit= h an AS.
    - The capability to be turned= into an authorization token originates with the RS-RO relationship. It cou= ld have been given to the RO, the agent, or the AS initially. Some of these= might be out of scope for GNAP and others need to be specified.
    - The capability to issue an authorization needs= is the third essential component of GNAP along with policies (at the agent= ) and a request receipt endpoint (of the AS).
    - The RO has a privacy interest in getting the request in a way tha= t the AS does not benefit from.=C2=A0
    =
    GNAP must not force the agent to = share request information with anyone that is not a principal to the transa= ction. Those principals are the RO, their agent, and the RS.

    Adrian

    On Tue, Mar 16, 2021 at 11:00 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Same, thanks for the clarificatio= n.

    On Tue, Mar 16, 2021 at 3:11 PM Justin Richer <jricher@mit.edu> wrote:
    Responses inline..

    <= div>On Mar 16, 2021, at 9:19 AM, Fabien Imbault <fabien.imbault@gmail.com> wro= te:

    Hi Justin,

    My comments in red [FIM].

    Cheers<= /div>
    Fabien

    On Tue, Mar 16, 2021 at 1:14 PM Justin Richer <jricher@mit.edu> wrote= :
    On Mar= 15, 2021, at 10:16 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    =
    Hi Justin,

    I have= exactly the same two questions as Fabien and also, I worry about the handw= aving=C2=A0in the answer=C2=A0to 7.

    The handwaving is actually important. I don=E2=80=99t think tha= t=E2=80=99s something that GNAP will solve in a universal way. We can have = hooks in the core protocol that say =E2=80=9Cand now go do This Other Thing= to talk to an agent=E2=80=9D, but I don=E2=80=99t think we=E2=80=99re real= ly the best ones to decide what that is or what it looks like for everyone.= =C2=A0

    This could be DIDComm, it could be CHAPI, i= t could be some proprietary app connection with push notifications, it coul= d be writing/reading from a shared encryption storage fabric =E2=80=94 all = that=E2=80=99s important here is that GNAP has a place in the protocol wher= e these various things can fit.=C2=A0

    OAuth chose = HTTP Redirects as The Way to get users involved in the process, but GNAP is= taking a very different stance in trying to get away from that limiting as= sumption. I don=E2=80=99t think it would serve us to just make a different = limiting assumption about how users (and their decisions) get involved.
    =

    [FIM] = We shouldn't be looking for an universal carrier, I agree, but people w= ill need practical ways to implement that. I think there's a fine line = between avoiding limiting assumptions and GNAP remaining too conceptual. At= least we should know where to put the extension points.
    =

    I agree that we need to have t= he extension points in the right place. In order to do that, we need to kno= w what we=E2=80=99re extending, which was the impetus for starting this con= versation. It=E2=80=99s debatable how much further we want to go beyond tha= t in GNAP itself, especially since there are a lot of other protocols out t= here designed to fit this niche well (see examples above).=C2=A0
    =
    One step we definitely can help with is providing a cohesive= model for describing both people and access rights, and being clear about = the overall process.

    [FIM2] clearer to me, thanks.=C2=A0

    <= /div>
    To answer the questions;

    - we're= covering the use case "get my medical data", how does that chang= e if that's someone else's data?=C2=A0

    It=E2=80=99s th= e same process as the second flow. The RO is the patient or doctor or someo= ne who can approve things. The AS doesn=E2=80=99t get everything that it ne= eds to from the agent introduced by the client, so it needs to access anoth= er agent.
    <= div>

    =
    - what happens if the agent can't guarantee avai= lability?=C2=A0

    Then the AS doesn=E2=80=99t get what it needs in or= der to fulfill the request and it denies the request. Whether that=E2=80=99= s a timeout or some other error, and whether that comes back to the client = with a =E2=80=9Ctry again=E2=80=9D or with a =E2=80=9Ctough luck, go away= =E2=80=9D, I think that=E2=80=99s all up for debate, and parts of that we= =E2=80=99ll need answers for. But ultimately, it=E2=80=99s the same kind of= thing that happens in OAuth if the user doesn=E2=80=99t consent, or the us= er can=E2=80=99t log in, or the =E2=80=9Cwrong=E2=80=9D user logs in for wh= at=E2=80=99s being asked for =E2=80=94 the AS isn=E2=80=99t satisfied with = the approval so the delegation request fails.
    =C2=A0
    [FIM]=C2=A0 seems real= istic when user =3D RO, the end-user can make itself available if the servi= ce is really important to him. "Tough luck" at first failure is f= ine then.=C2=A0
    But I believe that= becomes impractical when=C2=A0a = remote RO is involved (at least if it's supposed to be a human: if we d= on't deal with=C2=A0unavailability, async sequence 1.4.3 should be remo= ved).=C2=A0

    = Then, what is the AS to do if it tries the methods necessary to reach the R= O, but those methods fail? Or if there are multiple RO=E2=80=99s who could = approve and multiple come back?=C2=A0
    [FIM2] yes, that's some of the cases (and open qu= estions) I put forward in the presentation, trying to identify what would h= ave to=C2=A0be dealt with.=C2=A0
    I= t would be fine to decide all interactions need to be synchronous requests/= responses in the core.=C2=A0
    I agree that these are situations the AS is going to have to d= eal with, but I also believe that the details of what gets us into these si= tuations is outside of GNAP itself. Perhaps think of it this way:

    =C2=A0- The AS needs to gather authorization and consent.=C2=A0- The client can direct interaction with the end user.
    =C2=A0= - The end user might be able to provide that authorization and consent.
    =C2=A0- The client doesn=E2=80=99t know if the end user is the RO, b= ut it can provide the AS with hints as to who the end user is and means to = interact with them for the AS.
    =C2=A0- The AS knows who the RO is= and might have ways to interact with them (and their decisions) outside of= the interface with the client.

    So in other words,= the consent-gathering process that the AS goes through can be both client-= mediated and non-client-mediated. The client-mediated portions are very muc= h in scope of GNAP and they fall into the space of user =3D=3D RO very easi= ly. The non-client-mediated interactions are outside the scope of GNAP =E2= =80=94 or at least outside the core protocol, since the core protocol is al= l about the client instance getting a token (and/or subject info).
    [FIM2] that could be a v= iable way to refine the scope of the core. As long as it's clear what w= e do, it's fine to me.=C2=A0

    I think we can expand the discussion in the draft of how t= he AS goes through this consent gathering process but shouldn=E2=80=99t try= to define one specific way of it happening. That way we can define good be= havior around asynchronous methods, timeouts, and multi-user protocols, but= without having to define, say, a wire-based policy language to carry those= decisions. It=E2=80=99s definitely a fine line!
    [FIM2] yes, for sure DIDComm was in my vie= w just one example of a possible extended interact method (among many possi= ble already today and more in the future).=C2=A0
    In practice, none of those non-client-mediated interactions = need to be in the core.=C2=A0Howe= ver, they would probably require that GNAP defines how one should react to = such async or message based patterns, above the underlying protocol foundat= ion, to provide "elegant, sy= nchronous request-response interactions." (as said in 1.3.1 of DIDComm= ). Defining good async behaviour without minimal syntax is possible with co= loring schemes, but they have their drawbacks too (forces you to always thi= nk in colors, even for basic sync cases, and so I'm not convinced that = would be a win).=C2=A0=C2=A0
    Your flow for 8 doesn't m= ake sense to me because I assume the client is on the RO's mobile devic= e and unavailable for most interactions. The whole point of having the Agen= t is to keep the RO Client out of the picture when the requesting party sho= ws up with their Client.

    The RO doesn=E2=80=99t have a client in any of the flows below. The R= O might have an agent, they might have an app that notifies them to go log = into a webpage asynchronously, they might get an email with a link to click= back at the AS. None of that is facilitated through the RO=E2=80=99s clien= t because the RO doesn=E2=80=99t have a =E2=80=9Cclient=E2=80=9D in this mo= del. The client is by definition the software in front of the =E2=80=9Cuser= =E2=80=9D, the requesting party.=C2=A0
    <= font color=3D"#ff0000">[FIM] yes indeed=C2=A0
    =

    And it=E2=80=99s important in the design that= the client doesn=E2=80=99t need to know about any of that. It can identify= the resource, possibly identify the RO, and it can tell the AS =E2=80=9Cth= is is how I can talk to the person sitting in front of me right now=E2=80= =9D =E2=80=94 for whatever definition of =E2=80=9Ctalk to=E2=80=9D makes se= nse for the client app. What it can=E2=80=99t reliably do is say =E2=80=9Ct= his is how I can get in touch with an RO that I=E2=80=99m not talking to=E2= =80=9D, and certainly not communicate with another client, another AS, or o= ther part of the GNAP protocol.=C2=A0
    [FIM] Not entirely clear where we draw= the line. I imagine "person sitting in front of me right now" is= not to be taken literally? (could be my doctor, even if he's not in th= e same room).
    Clearly there's = no way a client can ever guarantee a reliable communication with something = else,=C2=A0I agree. At the very best it's a hint (and possibly a bad on= e).

    If the d= octor isn=E2=80=99t using the client application, then the doctor=E2=80=99s= not the =E2=80=9Cuser=E2=80=9D in protocol terms. If the AS has some other= way to get the doctor involved, it should be able to do that, but the clie= nt can=E2=80=99t really do anything about it.

    =C2= =A0- Justin


    <= /div>
    =C2=A0- Justin


    Adrian

    <= div class=3D"gmail_quote">
    On Mon, Mar= 15, 2021 at 10:12 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Hi Justin,

    I have exactl= y the same two questions as Fabien and also, I=C2=A0

    On Mon, Mar 15, 2= 021 at 9:45 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Justin

    A few questions :
    - we're coverin= g the use case "get my medical data", how does that change if tha= t's someone else's data?=C2=A0
    - what happen= s if the agent can't guarantee availability?=C2=A0

    Fabien=C2=A0


    Le lun. 15 mars 2021 =C3=A0 = 20:42, Justin Richer <jricher@mit.edu> a =C3=A9crit=C2=A0:
    =
    Hi Adrian, thanks so much for writing up this use case. I=E2=80=99ve i= ncluded some thoughts below into how different aspects of GNAP might map to= these requirements. I don=E2=80=99t think mapping any human system to any = technology is clean and dry, but for what it=E2=80=99s worth I do see a lot= of alignment.

    On Mar 12, 2021, = at 4:34 PM, Adrian Gropper <agropper@healthurl.com> wrote:
    Let=E2=80=99s try to map a real-world use-case into th= e names and roles we are discussing. The use-case is documented as the API = Task Force Recommendations (2016) https://www.healthit.gov/sites/default/files/facas/SingleSourceofTr= uth-APITFRecommendations.pdf and I=E2=80=99ve copied below the most releva= nt section. Bold highlight is in the original. I=E2=80=99ve added= bold italic because it may be important to our= discussion.=C2=A0

    <quote>

    • = ONC should clarify that while API Providers may impose security related res= trictions on app access (e.g. rate limiting, encryption, and expiration of = access tokens), it is inappropriate for API providers to set limitations on= what a patient authorized app can do with data downstream.

      • =
      • Given the nature of patient access rights, = the provider is not in a legal position to prevent the registration of apps= that would aggregate or share data, for example (though the provider might= certainly decide to warn the patient, or endeavor to educate and explain t= hese issue to the patient, as part of the provider hosted app approval work= flow).
    • ONC should clarify that API providers are not obligated to protect patients by identifyin= g "suspicious" apps. API providers may suspend API access to an app that has breached the A= PI provider's terms of service , or appears to have been compromised, o= r if the app poses a threat to the provider's own system. However, patients must be able to override this suspension (except in the case where an app pose= s threat to the provider's own system or violates allowable terms of se= rvice).

      <= /li>
    </quote>

    The key requirements from a patient rights a= nd privacy perspective are:

      1. To allow the patient to automate the issue of a scope-limited = access capability by delegating the authority to process API access request= s to some agent. The API Provider has no say in who or where this agent is.=

    This is where I think this discussion really should go. On the surfac= e, this seems to lead to the =E2=80=9Cbring your own AS=E2=80=9D model. I a= m contending that it=E2=80=99s more powerful to have an AS (still under the= API Provider=E2=80=99s control) that allows the user to provide additional= inputs during the protocol process. As an industry, we can standardize and= innovate a lot of those inputs, but ultimately GNAP should be able to just= connect those endpoints to each other (in my opinion). One of the common i= nputs is going to remain =E2=80=9Cget someone to log in at this webpage at = the AS and click a button=E2=80=9D, but I=E2=80=99m convinced there will be= others.

    1. = The automation of the agent = is based on policies provided by the patient. The agent is able to process = access requests from anyone and is responsible only to the patient. The age= nt responds to successful requests by issuing a filtered capability to the = requesting party.

    In this case, shouldn=E2=80=99t it be that the agent= is separated from the AS? Since the patient is going to have data protecte= d by different API Provders, to me it stands to reason that they=E2=80=99d = want the same agent acting for them on different systems. Each of those sys= tems would still have its own AS, but the AS would be facilitated by the us= er=E2=80=99s input.

    Now this is NOT saying that th= e user would have their own AS to delegate something to the downstream AS. = Or even saying that the user would have some kind of XACML policy server. I= =E2=80=99m not sure exactly how the bits on the wire would work but a straw= man would look something like:



    =
    User -> Client: go access my medical data
    Client -&g= t; RS: hey I want to access this medical data
    RS -> Client: su= re go talk to this AS
    Client -> Agent: I need to make a reques= t for data, how can I get the AS in touch with you?
    Agent -> C= lient: tell them to use [some kind of magic]
    Client -> AS: hey= I want to access this medical data; I can get the user to interact with yo= u or I can put you in touch with their policy agent
    AS -> Clie= nt: OK I=E2=80=99ll talk to the policy agent
    AS -> Agent: I ha= ve a request for data, I need you to prove that you have the right to relea= se this data
    Agent -> User: It looks like Client is asking for= stuff at RS through AS, that cool?
    Agent -> AS: OK, here you = go [more magic]
    AS -> Client: ok, here=E2=80=99s an access tok= en that=E2=80=99s good for accessing that AS
    Client -> RS: hey= , I want to access this medical data and here=E2=80=99s an access token for= it


    1. T= o ensure that the requesting party can delegate the capability using an ins= titutional workflow system that they trust and the patient doesn=E2=80=99t = know or care about. In many cases, the workflow system will pass the capabi= lity to some other person, who we might call the end user. In other cases, = the requesting party may forward the capability directly to another person = using, for example, an email. Either way, the client app used by the end-us= er to access the API is of no concern to the patient or to the patient=E2= =80=99s agent.=C2=A0

    To facilitate this, the =E2=80=9Cagent=E2=80=9D a= bove can be augmented with other capabilities based on what=E2=80=99s being= asked for. Adding a line to the flow above:

    = User -> Client: go access my medical data
    Client -> RS: hey= I want to access this medical data
    RS -> Client: sure go talk= to this AS
    Client -> Agent: I need to make a request for data= , how can I get the AS in touch with you?
    Agent -> Client: tel= l them to use [some kind of magic]
    Client -> AS: hey I want to= access this medical data; I can get the user to interact with you or I can= put you in touch with their policy agent
    AS -> Client: OK I= =E2=80=99ll talk to the policy agent
    AS -> Agent: I have a req= uest for data, I need you to prove that you have the right to release this = data
    Agent -> User: It looks like Client is asking for stuff a= t RS through AS, that cool?
    Agent -> AS: OK, here you go [more= magic]
    AS -> RO: It looks like someone's asking for an= RS you have the approval for, that cool?
    AS -> Client: ok= , here=E2=80=99s an access token that=E2=80=99s good for accessing that AS<= /div>
    Client -> RS: hey, I want to access this medical data and here= =E2=80=99s an access token for it

    In other words, = when the AS gets the request, it can and should take in inputs from multipl= e different dimensions in order to make the authorization decision and enco= de that into the access token.

    1. = To ensure that the API Provider does not censor the client app that present= s the capability or solicits too much information about the client app or t= he end-user of the client app.=C2=A0

    This is one of the reasons that t= he AS-based model is really important in GNAP =E2=80=94 the API Provider= 9;s RS only needs to know =E2=80=9Cis this token good for what=E2=80=99s be= ing asked=E2=80=9D.=C2=A0

    1. If the API= Provider decides, for any reason, to be =E2=80=9Csuspicious=E2=80=9D (as a= bove) of the access transaction based on the information it has, it should = be possible for the API Provider to warn the patient and to accept an overr= ide of the warning by the patient. This effectively means that the end-user= will provide as much information as they think will be necessary in order = to either avoid =E2=80=9Csuspicion=E2=80=9D or risk waiting for patient ove= rride.
    If the AS can reach out to the patient through notice and conse= nt, they can be brought into the process in an interactive way above. This = assumes the AS has a way of connecting that, but we should assume the AS ca= n provide this kind of notice and consent to parties that aren=E2=80=99t di= rectly involved in the protocol flow in the same way the end user is.
    =
    1. The policies by which the patient or the d= ecides to grant a capability to the requesting party are never shared outsi= de of the patient-agent trust relationship. In other words, neither the pat= ient nor the agent is asked to share or explain their reason for an access = decision.=C2=A0

    In the above pattern, the AS and agent would need a wa= y to communicate this with each other. I think the details of this are outs= ide the scope of GNAP but it could take the form of a query/response fulfil= lment language. VC=E2=80=99s address part of this, but I think there will n= eed to be other aspects brought to bear here. I think you could have a priv= acy-preserving protocol that would layer into GNAP here, but I don=E2=80=99= t know for sure what that would look like.

    1. Access requests to the agent are presumed confidential among the pati= ent, the agent, and whatever client the requesting party uses to present an= access request. The API Provider does not get to see the requests and no e= ntity in the GNAP authorization process, other than the patient or the agen= t, gets to correlate across requests by different requesting party clients.=

    This would be a different kind of model, where the client would act a= s some kind of proxy in the process. Something more like:

    3D"https://www.websequencediagrams.com/?png=3Dmsc685845457"

    User -> Client: go access my medical data
    Client -> RS: hey I want to access this medical data
    RS ->= ; Client: sure go talk to this AS
    Client -> Agent: I need to m= ake a request for data, how can I get the AS in touch with you?
    A= gent -> Client: tell them to use [some kind of magic]
    Client -= > AS: hey I want to access this medical data; I can get the user to inte= ract with you or I can forward your request details to the policy agent
    AS -> Client: OK go talk to the policy agent, ask for these kinds= of things
    Client -> Agent: I have a request for data, at this= AS, I need you to prove that you have the right to release this data
    =
    Agent -> User: It looks like Client is asking for stuff at RS throu= gh AS, that cool?
    Agent -> Client: OK, here you go [more magic= ]
    Client -> AS: Here=E2=80=99s the result of that policy thing= you asked for [more magic]
    AS -> Client: ok, here=E2=80=99s a= n access token that=E2=80=99s good for accessing that AS
    Client -= > RS: hey, I want to access this medical data and here=E2=80=99s an acce= ss token for it



    Note that I am not saying all 8 requirements are in scope for= GNAP but I am asking for GNAP to allow for this level of privacy on the pa= rt of self-sovereign patients using self-sovereign agents and the self-sove= reign licensed professionals they deal with.

    For me the important part is that G= NAP allow these kinds of trust connections. Even if GNAP isn=E2=80=99t solv= ing every piece of this equation, it can at least clearly state =E2=80=9Cth= ere=E2=80=99s a function here that needs to / is able to solve this thing= =E2=80=9D and build the important parts around it.


    =C2=A0- Justin


    Adrian


    On Fri, Mar 12, 2021 at 2:50 PM= Fabien Imbault <fabien.imbault@gmail.com> wrote:
    =
    Hi Justin,=C2=A0

    Just = a quick word to say I very much agree with both the observations and the fr= aming.

    Fabien

    On Fri, Mar 12, 2021 at 6:07 PM= Justin Richer <jricher@mit.edu> wrote:
    =
    As discussed at the IETF meeting, the editors proposed that one of our= next big topic areas was going to be the nature of the AS role within the = GNAP protocol, especially how it relates to the device-driven use cases tha= t have been brought up. Apologies in advance for the long post, but there a= re a lot of parts to this discussion that I=E2=80=99m hoping we can kick of= f here.

    My core proposal is that we see the AS as the co= mponent that has the following properties:
    =C2=A0- receives deleg= ation requests from the client instance for access to an RS via access toke= ns, and for access to subject information returned directly to the client i= nstance
    =C2=A0- collects consent and authorization from the RO fo= r the delegation
    =C2=A0- issues access tokens that its downstream= RS=E2=80=99s can interpret (and validate/accept)
    =C2=A0- issues = subject information asserted by the AS=C2=A0

    This fr= aming of the parties is really important in making a consistent understandi= ng of how the protocol works, and a consistent understanding is vital if we= =E2=80=99re going to function as a working group in both discussing the pro= blem space and executing the solution space. For a historical example, a na= ive approach to adding identity on top of a protocol like OAuth 2 (or GNAP)= is to declare that the resource server is the thing the user is logging in= to. This seems reasonable at first (and some people tried doing this) but = it violates all kinds of trust boundaries and puts new expectations on the = different parties that do not make sense. It stops looking anything like OA= uth very quickly and turns into another protocol. If instead we say the use= r is logging in to the client, things suddenly make a lot more sense and we= can do a lot more with it. (See this blog post from 2013 for one take on t= hat discussion:=C2=A0https://w= ww.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/)

    I think we=E2=80=99ve got a similar situation here when we= start to talk about the user bringing their own AS with them. I think this= is a reasonable-seeming assumption but it=E2=80=99s based on a false premi= se that the RO has to log into the AS to approve the request, and the AS ha= s full control and view over everything in the network. While OAuth doesn= =E2=80=99t require this, it=E2=80=99s largely assumed that=E2=80=99s how it= works. After all, all of the early OAuth deployments worked exactly this w= ay: the user logs in and clicks the =E2=80=9COK=E2=80=9D button. However, c= loud deployments have shown us that it=E2=80=99s perfectly reasonable for a= n OAuth AS to take in its consent and user information from an external tru= sted source, and so this model is not even accurate in OAuth.
    In short, I think we can do a better job here of defining thing= s in terms that both accept the reality we face and enable new ideas in way= s that make sense. It=E2=80=99s my stance that the user shouldn=E2=80=99t n= eed to bring the AS with them in order to have the kind of input and contro= l of the system that people are asking for. Instead, the AS should be able = to take inputs from things that the user controls in order for the AS to do= its job.

    People have discussed privacy concerns w= ith the AS knowing =E2=80=9Ctoo much=E2=80=9D, but in many of those discuss= ions the knowledge is simply pushed to the RS instead. What I=E2=80=99m obs= erving here is really just pushing portions of the AS role into the =E2=80= =9CRS=E2=80=9D deployment. This doesn=E2=80=99t make it less of an =E2=80= =9CAS=E2=80=9D role, it=E2=80=99s just being fulfilled closely to where the= RS role is fulfilled. As such, my proposal is really not that different in= practice, but the labels are different and better aligned with the capabil= ities of the protocol.=C2=A0

    We=E2=80=99ve p= reviously talked about separating the user-facing portions of the AS into a= nother component, and I think now might be the time to do that. This is a v= ery flammable strawman proposal, but what if we had the AS defined, as abov= e, and the =E2=80=9Cconsent and authorization=E2=80=9D gathering portion is= augmented by another named component. Here let=E2=80=99s call it an Intera= ction Component. This can take several forms based on the kind of interacti= on mode in use:

    =C2=A0- Hosted at a URL the user i= s redirected to; it can then make the user log in, consent, and whatever el= se they need to do
    =C2=A0- Hosted at a URL the user will load sep= arately and enter in an access code
    =C2=A0- An app on the user=E2= =80=99s device that the user interacts with directly and which sends inform= ation back to the AS
    =C2=A0- An app reachable by a messaging endp= oint that the AS sends and receives structured information from
    = =C2=A0- The client itself that is given an indication as to what informatio= n the AS needs in order to fulfill the request; this could be MFA challenge= /response, user credentials, signed claims, etc.

    I= t=E2=80=99s the AS=E2=80=99s job to accept any and all of these that it sup= ports and churn those into an access token.=C2=A0

    = The AS itself doesn=E2=80=99t ever need to have the user log in. The AS doe= sn=E2=80=99t necessarily need to even know who the user is in any way. The = AS just needs to know from a trusted source that the request is approved.

    From a practical standpoint, I think this will have= some small changes in how we talk about the components and how we talk abo= ut the interaction phase of the grant negotiation process. Everything I=E2= =80=99m laying out here is currently allowed by the spec, but I think we=E2= =80=99ve carried through the same assumptions from OAuth 2 about deployment= that are both inaccurate and confusing.=C2=A0

    =C2= =A0=E2=80=94 Justin
    --=C2=A0
    TXAuth mailing list=
    TXAuth@ietf.org
    https://www.ietf.org/= mailman/listinfo/txauth
    --=C2=A0
    = TXAuth mailing list
    TXAuth@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/txauth
    =

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

    --=C2=A0
    = TXAuth mailing list<= br style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-var= iant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;= text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;tex= t-decoration:none">TXAuth@i= etf.org
    https://www.ietf.org/mailman/listinfo/txauth<= /div>
    --00000000000038fb0405bda8ae18-- From nobody Tue Mar 16 17:01:27 2021 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 5A4CB3A13DE for ; Tue, 16 Mar 2021 17:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 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, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mattr-global.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 2OZuksW2-n07 for ; Tue, 16 Mar 2021 17:01:21 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 362FD3A13E7 for ; Tue, 16 Mar 2021 17:01:21 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id a9so37160209qkn.13 for ; Tue, 16 Mar 2021 17:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattr-global.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1DtqJ3cn3SnrwghBYDLw2nENn9+J/gkv1CxyIEGwuFM=; b=QtFAQ1Il0lsO7AhS6POpH06DhFLUqVI4VemgYkMdBHXn2v9AX8qm8xRVBGAYjnyN2x oR4Fhlw3J/d+5+SeXEP52pVlaFhr2Bx96j+qk/K/ZUyitY9iUmb0924Hd6I6U9c4Sc4Z iXhwFkpbRcdejhTesyh2aY4ZBmvctEGrlF67hppABAD5V84+2KC5F7UWdE0XYRb/9+57 vBIqT5qhOq0yNpKFA2jS0wVXmoqMdbDp2wclQIRqDUzp8vSn+ZNZM6/CvAcngCCke+DG 7pAIJ6dBdVVXS+WpyRggjOc/bBwg9SLKpCVssqZD8IKGguyLgd1+AwPePUbC71boG0wI i79w== 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=1DtqJ3cn3SnrwghBYDLw2nENn9+J/gkv1CxyIEGwuFM=; b=GZGjSekDeVnIdRM0EWTJTfv9KV24xSWufkwxbd7ff1tmJSuaeALHFCzlgsBio6cxQb QFrZTNKHUlN47aepft/JP9IGPao5vRa13ZU42884IO3ZK7ZLYol8bJ897bo/ScbOdQmy g/fS0icGpNXzUKI+rZELsxhzJuhUD1t+Ne+KmDkpPuVISY+wB6ij/lOEuBHtkVqZ13Iv omQ0E53zi5G7TbYWhk3GXXFemOAk60fO7mOesw0OXehLxJl8YVK9MqibsJPpjulvmMI7 M424FXlFnMgvVq3hhJPfCHhr21ROI5B3T1EK5znfy2W/qY4irS1+HzDXlgmD8niu8zJe PEGQ== X-Gm-Message-State: AOAM5320lpJ/uNDWkjlEWMfpipha5zL0iICYxVE6wUOt8awItNW/hYFh Oz7ZVlOs/sPCHtJxN05W93UOdjLMMDtq8mU7bbZ8ugJqiXynCEzNr6eaIsJ9nSvrMPdIjcelGRr 5oUa8411mnR0X2nnfFw== X-Google-Smtp-Source: ABdhPJyUpAs35lhvw0L4ZRRLRj/lDqqvTJKHmIXTTOKvPVkYcc6WTFPnLcaoemJBpElg6Ln+g6PPYXT9jarTJcz7MKE= X-Received: by 2002:a37:604:: with SMTP id 4mr1771053qkg.346.1615939280108; Tue, 16 Mar 2021 17:01:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tobias Looker Date: Wed, 17 Mar 2021 13:01:09 +1300 Message-ID: To: Fabien Imbault Cc: Justin Richer , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000c50e0405bdb02e48" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 00:01:26 -0000 --000000000000c50e0405bdb02e48 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, This is probably out of scope for the current conversation but has any thought been had on how the client instance could communicate additional options around what subject identifier types it supports for cases where the client instance will perhaps be required to conduct additional processing on the artifacts returned by the AS? As an example if the AS chose to identify the subject (End-User) using a DID and wanted to include an additional cryptographic assertion that showed it controls keys appropriately associated to the DID, then the client may have wanted to communicate some information up front in their request to ensure they can perform this additional processing, such as the signature suites it supports and in the context of DIDs potentially which DID methods it is capable of resolving? Thanks, [image: Mattr website] *Tobias Looker* Mattr +64 (0) 27 378 0461 tobias.looker@mattr.global [image: Mattr website] [image: Mattr on LinkedIn] [image: Mattr on Twitter] [image: Mattr on Github] This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002. On Sat, Mar 13, 2021 at 9:26 PM Fabien Imbault wrote: > Hi Justin, > > A last word on end-user! =3DRO (again just as food for thought). > > As soon as hints.automated is set to true, it takes priority over async, > which means it's the same model as the one you describe : the AS has > precedence over any other remote contact. > > So that confirms the global view that the AS is the one with the > authority, and that it might know more than the client. > > Cheers > Fabien > > Le jeu. 11 mars 2021 =C3=A0 11:44, Fabien Imbault a > =C3=A9crit : > >> Hi Justin, >> >> I think that's interesting: >> "For the user !=3D RO cases, I think that potentially having a way to >> signal those two items separately in the request and response could be >> useful. Right now all the user/subject stuff is about identifying =E2=80= =9Cthe user >> that=E2=80=99s currently here at the client instance=E2=80=9D, in a vari= ety of forms that >> the client instance and AS can negotiate. If the client or AS has some >> other notion about who the RO is and how that could be separate from the >> current user, we could provide a way to signal that like you=E2=80=99re = proposing >> below. In my mental model, there are going to be a lot of use cases wher= e >> the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the client at all, but r= ather to the AS and is >> based on what the client=E2=80=99s asking for. So I could identify the c= urrent user >> and ask for a specific medical record, and the AS realizes it has to go = bug >> a particular doctor to approve things directly. This is instead of >> interacting with the current user and failing in an awkward way when the >> current user doesn=E2=80=99t have the rights to do things, but someone e= lse would. >> But we=E2=80=99d want the system to be able to detect if the current use= r is the >> doctor, so we can just interact with them directly. Does that all track?= " >> >> I agree with the general idea. In the end, that's the AS's responsibilit= y >> (and also a big part of its value as a policy engine). >> >> Even in the cases - as I suggested - where the client would be able to >> signal what it knows (or thinks it knows) about the subject, the AS stil= l >> needs to validate what it can. The client could be an attacker lying to = the >> AS. Or there could be an unintended bug. >> >> The client still seems like a straightforward source to gather >> optional/declarative hints. Which is what request.user is already doing = in >> spirit. In many cases, the AS should go a step further. Validate >> cryptographic statements from a more reputable issuer, whatever helps. >> >> Contacts might be one of the possibilities. I'm not suggesting >> interact/fail scenarii at all, which I see as anti-ergonomic (composabil= ity >> with timeouts and fallback is the answer to that). The failure I was >> considering is only for async calls explicitly requested by the client >> (which is considered in sequence 1.4.3, and not coming from me), there's >> obviously no way to ensure a remote RO would actually respond when the >> client expects it. If that sequence is considered, realistic failure mod= es >> should be anticipated and dealt with internally (just like any distribut= ed >> program would do), is all I'm saying. And so from the outside, there's n= o >> interact/fail. >> That's the same as in real life: when booking a business trip, an >> employee could either follow the generic rule (2nd class train ticket) o= r >> reach out to his manager, explaining that it's a long trip and that 1st >> class would be better. The employee knows the manager might not instantl= y >> respond, and knows that the absence of an answer means he'll have to go = for >> the 2nd class. >> >> There will be cases when the client doesn't know the RO. I'm not sure if >> that's a majority of cases, but it will definitely happen. It could happ= en >> when you interact with an organization or a team and have no idea who's >> responsible or what delegations are in place (some of those cases have b= een >> described by Adrian for instance). >> There could also be cases where the ownership could be distributed (an >> example was provided when considering remote ROs). Again in real life, i= t's >> not unusual for a decision to fallback on a deputy when the main decisio= n >> maker is unavailable. Or there could be an open governance even, but may= be >> that's one step too far. >> >> Of course, if the AS has internal knowledge or other ways to get the >> information it should use it. Remains to be seen how we can specify that >> (cf issue #49 on should/must). The example with doctor/patient is fine i= f >> hardcoded, but it becomes a problem when we fail to understand the real >> relationships in environments of various sensitive nature. How the AS >> identifies that a specific record requires approval from Doctor Bob migh= t >> be context dependent (sometimes it could be a nurse, a team of doctors, >> another medical organization, etc.). Maybe you could have various levels= of >> authorizations (extreme example: military style classifications), so tha= t >> it might even be impossible to tell who can be contacted. >> >> That's also why I was suggesting assertions could go beyond >> authentication events, and include cryptographic assertions for >> authorization purposes. Maybe we can even imagine a risk based approach,= as >> in some cases we won't know for sure. >> >> The difficulty will be to be sufficiently generic but simple enough. >> Maybe we can rule out some cases. Maybe remote async contacts are out of >> scope, because we only want instantaneous authorizations. Most of those >> cases are way beyond what OAuth2 does. I don't know. But what's certain = is >> that the WG should decide what support for cases where end-user !=3D RO = it >> intends to provide. My discussion was just a very small Chesterston's Fe= nce >> contribution, even if that seems to have surprised. >> >> Fabien >> >> >> On Wed, Mar 10, 2021 at 8:18 PM Justin Richer wrote: >> >>> Hi Fabien, >>> >>> First, thanks for doing the heavy lift of writing this topic up. Of >>> these options, I would strongly prefer option (1). The difference betwe= en >>> assertions and identifiers is that an assertion is a fully packaged set= of >>> attributes, one of which can be an identifier. They are, generally >>> speaking, cryptographically protected bundles. They=E2=80=99re designed= to carry a >>> bunch of different information about a user and the authentication even= t in >>> a form that=E2=80=99s independently verifiable and auditable. SAML asse= rtions (XML >>> document) and ID Tokens (signed JWTs) are the most common ones we see >>> today, but other formats exist and will keep being invented. >>> >>> An identifier is a different kind of creature. It is a single statement >>> that identifies the party in question in the context of the party doing= the >>> identification. It=E2=80=99s this full context that the receiver of the= identifier >>> needs to interpret it in. When using a federated identity protocol, eac= h RP >>> is going to have :some: kind of local user information store that they= =E2=80=99re >>> going to tie into, some field in a database they=E2=80=99ll key off of.= It=E2=80=99s just >>> never going to be the case that all RPs will be able to use server-prov= ided >>> opaque identifiers for all cases. Account recovery and binding is one s= uch >>> use case where a user-facing identifier like an email address makes a L= OT >>> of sense, for one small example. This is an array in the request and >>> response precisely because a user could be known by several different >>> identifiers to a party, and an RP will have a better idea about what ki= nds >>> of things it wants to correlate against, and it=E2=80=99s up to the AS = to provide >>> that mapping. I think that if we don=E2=80=99t define a way to describe= the format, >>> the =E2=80=9Cas_id=E2=80=9D field is going to get structure back-patche= d onto it like is >>> being proposed here: >>> >>> https://mattrglobal.github.io/oidc-portable-identities/ >>> >>> I=E2=80=99m personally not a fan of that approach as it mixes the data = layering >>> too much, and you end up making guesses about whether a field is meanin= gful >>> or a pointer. I think GNAP will be much better served by using a data >>> structure for this from the start. DIDs should be another =E2=80=9Cform= at=E2=80=9D of the >>> subject identifier. I don=E2=80=99t think GNAP should define this forma= t, and I=E2=80=99ve >>> dropped a note to the SECEVENT mailing list asking about adding DIDs to= the >>> subject identifiers draft before it gets published. DIDs are not >>> assertions, even in the cases where they point to fully functional DID >>> documents with user information in them. (And for what it=E2=80=99s wor= th, I think >>> the OIDC world should also use the SECEVENT draft inside ID Tokens to s= olve >>> the use case of the draft above). >>> >>> For the user !=3D RO cases, I think that potentially having a way to >>> signal those two items separately in the request and response could be >>> useful. Right now all the user/subject stuff is about identifying =E2= =80=9Cthe user >>> that=E2=80=99s currently here at the client instance=E2=80=9D, in a var= iety of forms that >>> the client instance and AS can negotiate. If the client or AS has some >>> other notion about who the RO is and how that could be separate from th= e >>> current user, we could provide a way to signal that like you=E2=80=99re= proposing >>> below. In my mental model, there are going to be a lot of use cases whe= re >>> the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the client at all, but = rather to the AS and is >>> based on what the client=E2=80=99s asking for. So I could identify the = current user >>> and ask for a specific medical record, and the AS realizes it has to go= bug >>> a particular doctor to approve things directly. This is instead of >>> interacting with the current user and failing in an awkward way when th= e >>> current user doesn=E2=80=99t have the rights to do things, but someone = else would. >>> But we=E2=80=99d want the system to be able to detect if the current us= er is the >>> doctor, so we can just interact with them directly. Does that all track= ? >>> >>> =E2=80=94 Justin >>> >>> On Mar 10, 2021, at 4:10 AM, Fabien Imbault >>> wrote: >>> >>> Hello, >>> >>> Notice the question mark in the title. Not to be considered as an >>> editor's comment. >>> This thread intends to provide a detailed comment on the >>> interesting feedback by Kristina: "I would catch up on the thread to >>> understand why DIDs are thought to be treated as assertions". >>> In the chat, I answered: "Happy to get the discussion on DIDs. Actually= , >>> could be either or, depending on what we intend to do." Let me expand a= bit >>> on that, to make it understandable (didn't have the time during the >>> meeting, unfortunately). >>> >>> This relates to the items described on slides 20 and 34, which I'll >>> explain further. I'll highlight as transparently as possible what I thi= nk >>> would be the benefits and downsides of each. Both are probably viable >>> options, but they correspond to different scopes and objectives. I'll s= pend >>> a bit more time on option 2, since it is a different approach compared = to >>> the current draft. >>> >>> *1. The first possibility is to use SECEVENT throughout. * >>> In that case, DIDs should be a part of sub_ids (in the core or in the >>> extension registry, depending on what Annabelle's WG decides). More >>> generally, the WG would have to decide which additional sub_ids it need= s >>> (as per Yaron's comment). >>> >>> That's obviously the closest to what is described in draft-04. It allow= s >>> a communication of subject information between the client and the AS, b= y >>> using global identifiers (mail, phone, etc.), or using a local opaque >>> reference - i.e. governed by the AS (that's probably what we would put = in >>> the examples, unless someone has a better idea - cf issues #16 and #42)= . >>> >>> Assertions relate for instance to the proof of presence of the RO. The >>> current draft-04 therefore plans for id_tokens and saml2, maybe there c= ould >>> be other needs later (extension registry). >>> >>> - Benefits: identifiers are a key component of GNAP, which makes >>> integration easier. Possibly one could choose to use DIDs throughout. >>> - Downsides: email/phone identifiers will probably be used throughout b= y >>> most devs (since that's correlation information they have in their user >>> DB). Which means we should limit what assertions contain, to avoid doin= g >>> links between weak global identifiers and hopefully stronger assertions= . >>> That's not really a problem if it's limited to authentication events mo= stly >>> (in that perspective, samlv2 could make sense in the core). An assertio= n is >>> probably a single value then (not an array). >>> >>> Option 1 can be summarized as: >>> >>> "subject": { >>> "sub_ids": { }, // request and response (SECEVENT -> including DID >>> possibly) >>> "assertions": [ ], // request and response (id_token o= r >>> samlv2) >>> } >>> ("hints" do not exist currently, but are partially covered separately >>> via "request.user" / the relevance of "principal", discussed in the sli= de, >>> is a question mark too - which is a different discussion on end-user != =3D RO). >>> >>> >>> *2. An alternate possibility is to use SECEVENT only as input/hint* >>> In that case, DIDs should be a part of assertions (which have a >>> different meaning compared to option 1). >>> >>> The AS only returns an local opaque reference as_ref (while in option 1= , >>> it was only one of many possibilities). Its only job is to help the cli= ent >>> differentiate the response subject. The AS policy might further define = the >>> scope of that reference, as suggested in >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210, although >>> I personally viewed that by default as (2) "as_id" an identifier locall= y >>> unique to that AS for all the RSs. >>> >>> SECEVENTS are still useful as an input, that's what I presented in >>> request.hints.self.sub_ids (but it's the responsibility of the AS to ma= tch >>> it with its own reference system - from instance from the email to AS's >>> local record XUT2MFM1XBIKJKSDU8Q). Note: since the slides, a new >>> draft-ietf-secevent-subject-identifiers-07 has been published. Notably = this >>> includes an opaque identifier, which the client can use to pass the as_= ref >>> hint to the AS. Thus we wouldn't need any further addition to >>> SECEVENT, although hints would benefit from further additions (like DID= s >>> for instance). Notice also that subject_types_supported becomes less >>> important, because in the worst case scenario, it's simply a hint that >>> wouldn't be understood and therefore taken into account by the AS. >>> >>> The assertions array has a more important role than in option 1 (with >>> the explicit aim of separating between client hints and validated info >>> asserted by the AS). It serves as a generic/extendible mapping structur= e, >>> e.g. "the AS asserts that opaque reference XUT2MFM1XBIKJKSDU8Q is >>> matching with these (more or less verifiable) statements." The name >>> assertion therefore corresponds to the responsibility of the AS in >>> delivering those statements (cf should/must, issue #49). Some of these >>> statements relate to identity or auth events (ex: DID, id_token), some >>> might directly be useful for authorization decisions (like ZKP example = in >>> the parental control example). Possibly some of these validated asserti= ons >>> could be reused in next interactions. >>> >>> Another question that popped-up is the scope of sub_ids. Should they be >>> about the same user? (I think so). In the case of remote ROs especially= , it >>> might be important that DID be considered as an assertion (about someon= e >>> else's) and not as sub_ids, because the AS needs to be careful about wh= o >>> the client wants to reach (avoid spam, etc.). This is consistent with t= he >>> rest of discussion on what to do when end-user !=3D RO, although using >>> DIDComm might seem a bit early (the paint is very fresh). >>> >>> Option 2 was summarized as: >>> >>> // (suggestion only, not as an editor) >>> "subject": { >>> "as_ref": { // response only (wouldn=E2=80=99t require SECEVENT) >>> =E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D, >>> =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D >>> }, >>> "assertions": [ ], // request and response >>> (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validated by the= AS) >>> >>> "hints": { // request only (optional) >>> "self": { // replaces request.user (support SECEVENT here) >>> =E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque in dra= ft-07 - that >>> could contain the ref) >>> =E2=80=9Cassertions=E2=80=9D: [ ] // see examples: VC on DOB or ZKP = on age (wider >>> scope, possibly through extensions) >>> }, >>> "principal": { // new proposal presented at IETF110 (just an idea= ) >>> =E2=80=9Cautomated=E2=80=9D: true, // rule engine >>> =E2=80=9Casync=E2=80=9D: { } // remote ROs >>> } >>> } >>> } >>> >>> - Benefits: as_ref is self supporting (no strong coupling with >>> SECEVENT), but can still take SECEVENT as an input hint for the AS. It >>> avoids the risk of making an official association between a weak global >>> identifier (e.g. email, used elsewhere) and hopefully stronger local >>> assertions. GNAP would be fully agnostic to whatever identity system is >>> used, only facilitating interoperability through assertions (second onl= y in >>> importance compared to the AS opaque reference). Some assertions (possi= bly >>> extensions) could also be useful for the AS decision (e.g. VC or ZKP). >>> - Downsides: opaqueness of as_ref is a feature, not a bug. The opaque >>> reference is fully managed by the AS, therefore not inherently portable= (cf >>> portability discussions in OIDC currently). There's no explicit binding= to >>> an official identity, only a contextual mapping to AS validated asserti= ons. >>> It makes it more difficult to match the identifiers from one AS to anot= her >>> or to correlate with the client user DB (still possible via assertions,= if >>> the AS allows it). Assertions are much more generic (possibly via >>> extensions), but might require a more advanced mechanism to >>> request/response only the most relevant information (which makes the AS >>> policy critical here). >>> >>> I hope that clarifies the reasoning for both options. Again I'm not >>> saying option 2 is better, just saying the trade-offs are different (+ >>> knowing that we need to keep it simple). >>> - option 1 puts more in sub_ids and less in assertions >>> - option 2 puts less in the reference and more in assertions >>> All of this is open to discussion. More generally speaking, on every >>> part in orange and question mark (?) I would love your ideas and >>> criticisms. What I intended as an editor is only to highlight where the= WG >>> has important choices to make, before we can make the related PRs. >>> >>> A further side comment: IETF EAT RATS was suggested for assertions, but >>> relates more to the client attestations. It was added as a comment in >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, which is >>> a distinct topic we'll work on. >>> >>> Fabien (editor's hat off) >>> >>> -- >>> 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 This communication, including any attachments, is confidential. If you are= =20 not the intended recipient, you should not read it - please contact me=20 immediately, destroy it, and do not copy or use any part of this=20 communication or disclose anything about it. Thank you. Please note that=20 this communication does not designate an information system for the=20 purposes of the Electronic Transactions Act 2002. --000000000000c50e0405bdb02e48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi,

    This is probably out of scope for t= he current conversation but has any thought been had on how the client inst= ance could communicate additional options around what subject identifier ty= pes it supports for cases where the client instance will perhaps be require= d to conduct additional processing on the artifacts returned by the AS? As = an example if the AS chose to identify the subject (End-User) using a DID a= nd wanted to include an additional cryptographic assertion that showed it c= ontrols keys appropriately associated to the DID, then the client may have = wanted to communicate some information up front in their request to ensure = they can perform this additional processing, such as the signature suites i= t supports and in the context of DIDs potentially which DID methods it is c= apable of resolving?

    Thanks,
    Mattr
    3D"Mattr=C2=A0
    Tobias Looker
    +64 (0) 27 378 04= 61
    tobias.looker@mattr.global
    3D"Mattr3D"Mattr3D"Mattr

    This commu= nication, including any attachments, is confidential. If you are not the in= tended recipient, you should not read it - please contact me immediately, d= estroy it, and do not copy or use any part of this communication or disclos= e anything about it. Thank you. Please note that this communication does no= t designate an information system for the purposes of the Electronic Transa= ctions Act 2002.


    On Sat, Mar 13, 202= 1 at 9:26 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Justin,=C2=A0

    A last word on end-user! =3DRO (ag= ain just as food for thought).=C2=A0

    As soon as hints.automated is set to true, it takes priority o= ver async, which means it's the same model as the one you describe : th= e AS has precedence over any other remote contact.=C2=A0

    So that confirms the global view that the = AS is the one with the authority, and that it might know more than the clie= nt.=C2=A0

    Cheers
    Fabien=C2=A0

    Le jeu. 11 mars = 2021 =C3=A0 11:44, Fabien Imbault <fabien.imbault@gmail.com> a =C3=A9crit=C2= =A0:
    Hi Justin,

    I think that's interesting:
    "For the user !=3D RO cases, I think that potentially having a= way to signal those two items separately in the request and response could= be useful. Right now all the user/subject stuff is about identifying =E2= =80=9Cthe user that=E2=80=99s currently here at the client instance=E2=80= =9D, in a variety of forms that the client instance and AS can negotiate. I= f the client or AS has some other notion about who the RO is and how that c= ould be separate from the current user, we could provide a way to signal th= at like you=E2=80=99re proposing below. In my mental model, there are going= to be a lot of use cases where the =E2=80=9CRO=E2=80=9D isn=E2=80=99t know= n to the client at all, but rather to the AS and is based on what the clien= t=E2=80=99s asking for. So I could identify the current user and ask for a = specific medical record, and the AS realizes it has to go bug a particular = doctor to approve things directly. This is instead of interacting with the = current user and failing in an awkward way when the current user doesn=E2= =80=99t have the rights to do things, but someone else would. But we=E2=80= =99d want the system to be able to detect if the current user is the doctor= , so we can just interact with them directly. Does that all track?"

    I agree with the general idea. In the end, that'= s the AS's responsibility (and also a big part of its value as a policy= engine). =C2=A0

    Even in the cases - as I suggeste= d - where the client would be able to signal what it knows (or thinks it kn= ows) about the subject, the AS still needs to validate what it can. The cli= ent could be an attacker lying to the AS. Or there could be an unintended b= ug.=C2=A0

    The=C2=A0client still seems like a strai= ghtforward source to gather optional/declarative hints. Which is what reque= st.user is already doing in spirit. In many cases, the AS should go a step = further. Validate cryptographic statements from a more reputable issuer, wh= atever helps.

    Contacts might be one of the possibi= lities. I'm not suggesting interact/fail scenarii at all, which I see a= s anti-ergonomic (composability with timeouts and fallback is the answer to= that). The failure I was considering is only for async calls explicitly re= quested by the client (which is considered in sequence 1.4.3, and not comin= g from me), there's obviously no way to ensure a remote RO would actual= ly respond when the client expects it. If that sequence is considered, real= istic failure modes should be anticipated and dealt with internally (just l= ike any distributed program would do), is all I'm saying. And so from t= he outside, there's no interact/fail.=C2=A0=C2=A0
    That's = the same as in real life: when booking a business trip, an employee could e= ither follow the generic rule (2nd class train ticket) or reach out to his = manager, explaining that it's a long trip and that 1st class would be b= etter. The employee knows the manager might not instantly respond, and know= s that the absence of an answer means he'll have to go for the 2nd clas= s.=C2=A0

    There will be cases when the=C2=A0cli= ent doesn't know the=C2=A0RO. I'm not sure if that's a majority= of cases, but it will definitely happen. It could happen when you interact= with an organization or a team and have no idea who's responsible or w= hat delegations are in place (some of those cases have been described by Ad= rian for instance).=C2=A0
    There could also be cases where the own= ership could be distributed (an example was provided when considering remot= e ROs). Again in real life, it's not unusual for a decision to fallback= on a deputy when the main decision maker is unavailable. Or there could be= an open governance even, but maybe that's one step too far.
    =
    Of course, if the AS has internal knowledge or other ways to= get the information it should use it. Remains to be seen how we can specif= y that (cf issue #49 on should/must). The example with doctor/patient is fi= ne if hardcoded, but it becomes a problem when we fail to understand the re= al relationships in environments of various sensitive nature. How the AS id= entifies that a specific record requires approval from Doctor Bob might be = context dependent (sometimes it could be a nurse, a team of doctors, anothe= r medical organization, etc.). Maybe you could have various levels of autho= rizations (extreme example: military style classifications), so that it mig= ht even be impossible to tell who can be contacted.=C2=A0

    That's also why I was suggesting assertions could go beyond aut= hentication events, and include cryptographic assertions for authorization = purposes. Maybe we can even imagine a risk based approach, as in some cases= we won't know for sure.=C2=A0

    The difficulty = will be to be sufficiently generic but simple enough. Maybe we can rule out= some cases. Maybe remote async contacts are out of scope,=C2=A0because we = only want instantaneous authorizations. Most of those cases are way beyond = what OAuth2 does. I don't know. But what's certain is that the WG s= hould decide what support for cases where end-user !=3D RO it intends to pr= ovide. My discussion was just a very small Chesterston's Fence contribu= tion, even if that seems to have surprised.

    Fabien=


    On Wed, Mar 10, 2= 021 at 8:18 PM Justin Richer <jricher@mit.edu> wrote:
    Hi Fabien,

    =
    First, thanks for doing the heavy lift of writing this topic up. Of th= ese options, I would strongly prefer option (1). The difference between ass= ertions and identifiers is that an assertion is a fully packaged set of att= ributes, one of which can be an identifier. They are, generally speaking, c= ryptographically protected bundles. They=E2=80=99re designed to carry a bun= ch of different information about a user and the authentication event in a = form that=E2=80=99s independently verifiable and auditable. SAML assertions= (XML document) and ID Tokens (signed JWTs) are the most common ones we see= today, but other formats exist and will keep being invented.=C2=A0

    An identifier is a different kind of creature. It is a si= ngle statement that identifies the party in question in the context of the = party doing the identification. It=E2=80=99s this full context that the rec= eiver of the identifier needs to interpret it in. When using a federated id= entity protocol, each RP is going to have :some: kind of local user informa= tion store that they=E2=80=99re going to tie into, some field in a database= they=E2=80=99ll key off of. It=E2=80=99s just never going to be the case t= hat all RPs will be able to use server-provided opaque identifiers for all = cases. Account recovery and binding is one such use case where a user-facin= g identifier like an email address makes a LOT of sense, for one small exam= ple. This is an array in the request and response precisely because a user = could be known by several different identifiers to a party, and an RP will = have a better idea about what kinds of things it wants to correlate against= , and it=E2=80=99s up to the AS to provide that mapping. I think that if we= don=E2=80=99t define a way to describe the format, the =E2=80=9Cas_id=E2= =80=9D field is going to get structure back-patched onto it like is being p= roposed here:


    <= div>I=E2=80=99m personally not a fan of that approach as it mixes the data = layering too much, and you end up making guesses about whether a field is m= eaningful or a pointer. I think GNAP will be much better served by using a = data structure for this from the start. DIDs should be another =E2=80=9Cfor= mat=E2=80=9D of the subject identifier. I don=E2=80=99t think GNAP should d= efine this format, and I=E2=80=99ve dropped a note to the SECEVENT mailing = list asking about adding DIDs to the subject identifiers draft before it ge= ts published. DIDs are not assertions, even in the cases where they point t= o fully functional DID documents with user information in them. (And for wh= at it=E2=80=99s worth, I think the OIDC world should also use the SECEVENT = draft inside ID Tokens to solve the use case of the draft above).

    For the user !=3D RO cases, I think that potentially having= a way to signal those two items separately in the request and response cou= ld be useful. Right now all the user/subject stuff is about identifying =E2= =80=9Cthe user that=E2=80=99s currently here at the client instance=E2=80= =9D, in a variety of forms that the client instance and AS can negotiate. I= f the client or AS has some other notion about who the RO is and how that c= ould be separate from the current user, we could provide a way to signal th= at like you=E2=80=99re proposing below. In my mental model, there are going= to be a lot of use cases where the =E2=80=9CRO=E2=80=9D isn=E2=80=99t know= n to the client at all, but rather to the AS and is based on what the clien= t=E2=80=99s asking for. So I could identify the current user and ask for a = specific medical record, and the AS realizes it has to go bug a particular = doctor to approve things directly. This is instead of interacting with the = current user and failing in an awkward way when the current user doesn=E2= =80=99t have the rights to do things, but someone else would. But we=E2=80= =99d want the system to be able to detect if the current user is the doctor= , so we can just interact with them directly. Does that all track?

    =C2=A0=E2=80=94 Justin

    On Mar 10, 2021, at 4:10 AM, Fabien Imbault <fabien= .imbault@gmail.com> wrote:

    Hello,
    Notice the question mark in the title. Not to be considered= as an editor's comment.
    This thread intends to provide a det= ailed comment on the interesting=C2=A0feedback by Kristina: "I would c= atch up on the thread to understand why DIDs are thought to be treated as a= ssertions".
    In the chat, I answered: "Happy to get the = discussion on DIDs. Actually, could be either or, depending on what we inte= nd to do." Let me expand a bit on that, to make it understandable (did= n't have the time during the meeting, unfortunately).

    This relates to the items described on slides 20 and 34, which I= 9;ll explain further. I'll highlight as transparently as possible what = I think would be the benefits and downsides of each. Both are probably viab= le options, but they correspond to different scopes and objectives. I'l= l spend a bit more time on option 2, since it is a different approach compa= red to the current draft.

    1. The first possibility is to use SEC= EVENT throughout.=C2=A0
    In that case, DIDs should be a part o= f sub_ids (in the core or in the extension registry, depending on what Anna= belle's WG decides). More generally, the WG would have to decide which = additional sub_ids it needs (as per Yaron's comment).

    That's obviously the closest to what is described in draft-04. = It allows a communication of subject information between the client and the= AS, by using global identifiers (mail, phone, etc.), or using a local opaq= ue reference=C2=A0- i.e. governed by the AS (that's probably what we wo= uld=C2=A0put in the examples, unless someone has a better idea - cf issues = #16 and #42).=C2=A0

    Assertions relate for instance= to the proof of presence of the RO. The current draft-04 therefore plans f= or id_tokens and saml2, maybe there could be other needs later (extension r= egistry).

    - Benefits: identifiers are a key compon= ent of GNAP, which makes integration easier. Possibly one could choose to u= se DIDs throughout.
    - Downsides: email/phone identifiers will pro= bably be used throughout by most devs (since that's correlation informa= tion they=C2=A0have in their user DB). Which means we should limit what ass= ertions contain, to avoid doing links between weak global identifiers and h= opefully stronger assertions. That's not really a problem if it's l= imited to authentication events mostly (in that perspective, samlv2 could m= ake sense in the core). An assertion is probably a single value then (not a= n array).=C2=A0 =C2=A0

    Option 1 can be summar= ized as:=C2=A0

    "subject": {
    =C2=A0=C2=A0= =C2=A0"sub_ids": { }, = <= span style=3D"font-family:"Courier New";color:rgb(51,51,51);backg= round-color:rgb(247,247,247);font-variant-numeric:normal;font-variant-east-= asian:normal;vertical-align:baseline;white-space:pre-wrap">// request and r= esponse (SECEVENT -> including DID possibly)    = =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=C2=A0=C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0"assertio= ns": [ ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // requ= est and response (id_token or samlv2)
    }
    ("hints"= ; do not exist currently, but are partially covered separately via "re= quest.user" / the relevance of "principal", discussed in the= slide, is a question mark too - which is a different discussion on end-use= r !=3D RO).


    2. An alternate p= ossibility is to use SECEVENT only as input/hint
    In that case= , DIDs should be a part of assertions (which have a different meaning compa= red to option 1).

    The AS only returns an local opa= que reference as_ref (while in option 1, it was only one of many possibilit= ies). Its only job is to help the client differentiate the response subject= . The AS policy might further define the scope of that reference, as sugges= ted in=C2=A0https://github.com/ietf-wg-= gnap/gnap-core-protocol/issues/210, although I personally=C2=A0viewed t= hat by default as=C2=A0(2) "as_id" an identifier locally unique t= o that AS for all the RSs.

    SECEVENTS are still use= ful as an input, that's what I presented in request.hints.self.sub_ids = (but it's the responsibility=C2=A0of the AS to match it with its own re= ference system - from instance from the email to AS's local record XUT2= MFM1XBIKJKSDU8Q).=C2=A0Note: since the slides, a new draft-ietf-secevent-su= bject-identifiers-07 has been published. Notably this includes an opaque id= entifier, which the client can use to pass the as_ref hint to the AS. Thus = we wouldn't need any further addition to SECEVENT,=C2=A0although hints = would benefit from further additions (like DIDs for instance). Notice also = that subject_types_supported becomes less important, because in the worst c= ase scenario, it's simply=C2=A0a hint that wouldn't be understood a= nd therefore taken into account by the AS.

    The ass= ertions array has a more important role than in option 1 (with the explicit= aim of separating between client hints and validated info asserted by the = AS). It serves as a generic/extendible mapping structure, e.g. "the AS= asserts that opaque reference=C2=A0XUT2MFM1XBIKJKSDU8Q=C2=A0is matching with= these (more or less verifiable) statements." The name assertion there= fore corresponds to the responsibility=C2=A0of the AS in delivering those s= tatements (cf should/must, issue #49). Some of these statements relate to i= dentity or auth events (ex: DID, id_token), some might directly be useful f= or authorization decisions (like ZKP example in the parental control exampl= e). Possibly some of these validated assertions could be reused in next int= eractions.

    Another question that popped-up is the = scope of sub_ids. Should they be about the same user? (I think so). In the = case of remote ROs especially, it might be important that DID be considered= as an assertion=C2=A0(about someone else's) and not as sub_ids, becaus= e the AS needs to be careful about who the client wants to reach (avoid spa= m, etc.). This is consistent with the rest of discussion on what to do when= end-user !=3D RO, although using DIDComm might seem a bit early (the paint= is very fresh).=C2=A0

    Option 2 was summarized as:= =C2=A0

    // (suggestion only, not as an editor= )
    "subject": {
    =C2=A0=C2=A0=C2=A0"as_ref= ": { = = // response only (wouldn=E2=80=99t require SECEVENT)
    =E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D, =
    =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D=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=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"assertions": [ ], =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request and response (id_token/jwkth= umb/DID/VC/etc. -> whatever info can be validated by the AS)

    =C2=A0=C2=A0=C2=A0"hints": { =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /= / request only (optional)
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0&qu= ot;self": { // replaces request.user (support SECEVENT here)
    =C2=A0=C2=A0=C2=A0=E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (inclu= ding opaque in draft-07 - that could contain the ref)
    =C2=A0=C2=A0=C2=A0=E2=80=9Cassertions=E2=80=9D: [ ] // se= e examples: VC on DOB or ZKP on age (wider scope, possibly through extensio= ns)
    },=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=C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"principal": { // new proposal presented at IETF110 (just an idea)
    =C2=A0 =E2=80=9Cautomated=E2=80= =9D: true, // rule engine
    =C2=A0 =E2= =80=9Casync=E2=80=9D: { } // remote ROs
    }=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=C2=A0=C2=A0}<= /div>
    }

    - Benefits: as_ref is sel= f supporting (no strong coupling with SECEVENT), but can still take SECEVEN= T as an input hint for the AS. It avoids the risk of making an official ass= ociation between a weak global identifier (e.g. email, used elsewhere) and = hopefully stronger local assertions. GNAP would be fully agnostic to whatev= er identity system is used, only facilitating interoperability through asse= rtions (second only in importance=C2=A0compared to the AS opaque reference)= . Some assertions (possibly extensions) could also be useful for the AS dec= ision (e.g. VC or ZKP).
    - Downsides: opaqueness of as_ref is a fe= ature, not a bug. The opaque reference is fully managed by the AS, therefor= e not inherently portable (cf portability discussions in OIDC currently). T= here's no explicit binding to an official identity, only a contextual m= apping to AS validated assertions. It makes it more difficult to match the = identifiers from one AS to another or to correlate with the client user DB = (still possible via assertions, if the AS allows it). Assertions are much m= ore generic (possibly via extensions), but might require a more advanced me= chanism=C2=A0to request/response only the most relevant information (which = makes the AS policy critical here).

    I hope that cl= arifies the=C2=A0reasoning for both options. Again I'm not saying optio= n 2 is better, just saying the trade-offs are different (+ knowing that we = need to keep it simple).
    - option 1 puts more in sub_ids and less= in assertions
    - option 2 puts less in the reference and more in = assertions=C2=A0
    All of this is open to discussion. More generall= y speaking, on every part in orange and question mark (?) I would love your= ideas and criticisms. What I intended as an editor is only to highlight wh= ere the WG has important choices to make, before we can make the related PR= s.

    A further side comment: IETF EAT RATS was sugge= sted for assertions, but relates more to the client attestations. It was ad= ded as a comment in=C2=A0https://github.= com/ietf-wg-gnap/gnap-core-protocol/issues/44, which is a distinct topi= c we'll work on.

    Fabien (editor's hat off)=

    --
    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

    This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.
    --000000000000c50e0405bdb02e48-- From nobody Tue Mar 16 18:59:55 2021 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 0E0C33A16F6 for ; Tue, 16 Mar 2021 18:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 K7xoVwxNlhIN for ; Tue, 16 Mar 2021 18:59:48 -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 4430F3A16F1 for ; Tue, 16 Mar 2021 18:59:48 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id e7so14564477ile.7 for ; Tue, 16 Mar 2021 18:59:48 -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=xk3hW4/wJszGX9MWp4T2/8tco6388Xu5Ud6z8eaE0Y0=; b=BFN+1OcqTBu+gdgxuzh70SOTSy8pQmEUpym4gKPsfRdhA71mMecVV0vzR2PVIhoe/a HuZ5g9XopkQXX5HxRZYIrYjTSDej+m3BfwXpOU6s1r2VgITkNoJh7sGT6OJE59ZKGxfD EzZBbCyJ+PEltB14Smu/0mmaTVcJmDLqikcGB0Y/e++C1E+V/SeKR1gVqh8muEpfPMgN yuUNTGmAlErt0d1oxWHFJniRUMqzGlnkdMt56zZcyM4p8wmY/QYZDjJIMvKjj8daYpFB +5KFX6PAVK4z3L6VhkFXYxPstKxg0Ho1J4+KvVwOIqqLiRi+b0hyI4xSJ7QEO87hRA8s Cm5w== 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=xk3hW4/wJszGX9MWp4T2/8tco6388Xu5Ud6z8eaE0Y0=; b=ERMywp/dY7NNyc4Q3hxjHALWObf6wj91uhZ15Us4KytcNd9gR9cjO0gOTq7Os11siA rdOMQCqsnWSGdVp4WZbMreiVaLYby2Q1jFrGyY2VUiYAIl2yWsJo7yBLv4fJ9rcRSrEJ myGTwev7/r5X3DhyFIf9UwdbIxzTgq0id+fR2avOhk0ybgfg4ItPIFs+2wxR8yopbYd2 v14xhoFLHeOjNhW1qJwDrdXNta4mQgiUvV19JNl8o2TQ5yCpDpenTNElgi6V4n8jc0Za KhgvVd/WvDs0iTht0U2vy+9rTlWBODrlWUINBV8xFSj0rF/wUoEDSu/JrGJ1y1z8blPL oFtQ== X-Gm-Message-State: AOAM533sIEgpgc+5gHjF6ne12k9dcbjQnCNbuphA6ht02yMTtE6FKvql ozy2Hhybjj5+qVy8aRg7P6bpFrnDR1FgUbk/7qU= X-Google-Smtp-Source: ABdhPJzo8eV1vRMi3PTR/Llg7xwFw+VRvQCMN2JPcWs/S9D84HrdEiEUEHb3gus0SjEe3xDWa2J8YqKE/B4inkmLmvA= X-Received: by 2002:a92:c6d0:: with SMTP id v16mr5485633ilm.289.1615946385440; Tue, 16 Mar 2021 18:59:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Wed, 17 Mar 2021 02:59:32 +0100 Message-ID: To: Tobias Looker Cc: Justin Richer , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000047c62905bdb1d6c0" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 01:59:53 -0000 --00000000000047c62905bdb1d6c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tobias, Not yet (none of the current sub_ids require additional parameters) but if DIDs do get added to subject identifiers, then it's certainly something we would have to support. There's already a very basic version of that, but only to chose the main type (now called "format" in latest draft 07 of SECEVENT), with subject_types_supported in the discovery. Thanks for the heads up, it's worth creating an issue or putting a note in some existing issue to not forget looking into that. Cheers Fabien Le mer. 17 mars 2021 =C3=A0 01:01, Tobias Looker a =C3=A9crit : > Hi, > > This is probably out of scope for the current conversation but has any > thought been had on how the client instance could communicate additional > options around what subject identifier types it supports for cases where > the client instance will perhaps be required to conduct additional > processing on the artifacts returned by the AS? As an example if the AS > chose to identify the subject (End-User) using a DID and wanted to includ= e > an additional cryptographic assertion that showed it controls keys > appropriately associated to the DID, then the client may have wanted to > communicate some information up front in their request to ensure they can > perform this additional processing, such as the signature suites it > supports and in the context of DIDs potentially which DID methods it is > capable of resolving? > > Thanks, > [image: Mattr website] > *Tobias Looker* > Mattr > +64 (0) 27 378 0461 > tobias.looker@mattr.global > [image: Mattr website] [image: Mattr on LinkedIn] > [image: Mattr on Twitter] > [image: Mattr on Github] > > This communication, including any attachments, is confidential. If you ar= e > not the intended recipient, you should not read it - please contact me > immediately, destroy it, and do not copy or use any part of this > communication or disclose anything about it. Thank you. Please note that > this communication does not designate an information system for the > purposes of the Electronic Transactions Act 2002. > > > On Sat, Mar 13, 2021 at 9:26 PM Fabien Imbault > wrote: > >> Hi Justin, >> >> A last word on end-user! =3DRO (again just as food for thought). >> >> As soon as hints.automated is set to true, it takes priority over async, >> which means it's the same model as the one you describe : the AS has >> precedence over any other remote contact. >> >> So that confirms the global view that the AS is the one with the >> authority, and that it might know more than the client. >> >> Cheers >> Fabien >> >> Le jeu. 11 mars 2021 =C3=A0 11:44, Fabien Imbault >> a =C3=A9crit : >> >>> Hi Justin, >>> >>> I think that's interesting: >>> "For the user !=3D RO cases, I think that potentially having a way to >>> signal those two items separately in the request and response could be >>> useful. Right now all the user/subject stuff is about identifying =E2= =80=9Cthe user >>> that=E2=80=99s currently here at the client instance=E2=80=9D, in a var= iety of forms that >>> the client instance and AS can negotiate. If the client or AS has some >>> other notion about who the RO is and how that could be separate from th= e >>> current user, we could provide a way to signal that like you=E2=80=99re= proposing >>> below. In my mental model, there are going to be a lot of use cases whe= re >>> the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the client at all, but = rather to the AS and is >>> based on what the client=E2=80=99s asking for. So I could identify the = current user >>> and ask for a specific medical record, and the AS realizes it has to go= bug >>> a particular doctor to approve things directly. This is instead of >>> interacting with the current user and failing in an awkward way when th= e >>> current user doesn=E2=80=99t have the rights to do things, but someone = else would. >>> But we=E2=80=99d want the system to be able to detect if the current us= er is the >>> doctor, so we can just interact with them directly. Does that all track= ?" >>> >>> I agree with the general idea. In the end, that's the AS's >>> responsibility (and also a big part of its value as a policy engine). >>> >>> Even in the cases - as I suggested - where the client would be able to >>> signal what it knows (or thinks it knows) about the subject, the AS sti= ll >>> needs to validate what it can. The client could be an attacker lying to= the >>> AS. Or there could be an unintended bug. >>> >>> The client still seems like a straightforward source to gather >>> optional/declarative hints. Which is what request.user is already doing= in >>> spirit. In many cases, the AS should go a step further. Validate >>> cryptographic statements from a more reputable issuer, whatever helps. >>> >>> Contacts might be one of the possibilities. I'm not suggesting >>> interact/fail scenarii at all, which I see as anti-ergonomic (composabi= lity >>> with timeouts and fallback is the answer to that). The failure I was >>> considering is only for async calls explicitly requested by the client >>> (which is considered in sequence 1.4.3, and not coming from me), there'= s >>> obviously no way to ensure a remote RO would actually respond when the >>> client expects it. If that sequence is considered, realistic failure mo= des >>> should be anticipated and dealt with internally (just like any distribu= ted >>> program would do), is all I'm saying. And so from the outside, there's = no >>> interact/fail. >>> That's the same as in real life: when booking a business trip, an >>> employee could either follow the generic rule (2nd class train ticket) = or >>> reach out to his manager, explaining that it's a long trip and that 1st >>> class would be better. The employee knows the manager might not instant= ly >>> respond, and knows that the absence of an answer means he'll have to go= for >>> the 2nd class. >>> >>> There will be cases when the client doesn't know the RO. I'm not sure i= f >>> that's a majority of cases, but it will definitely happen. It could hap= pen >>> when you interact with an organization or a team and have no idea who's >>> responsible or what delegations are in place (some of those cases have = been >>> described by Adrian for instance). >>> There could also be cases where the ownership could be distributed (an >>> example was provided when considering remote ROs). Again in real life, = it's >>> not unusual for a decision to fallback on a deputy when the main decisi= on >>> maker is unavailable. Or there could be an open governance even, but ma= ybe >>> that's one step too far. >>> >>> Of course, if the AS has internal knowledge or other ways to get the >>> information it should use it. Remains to be seen how we can specify tha= t >>> (cf issue #49 on should/must). The example with doctor/patient is fine = if >>> hardcoded, but it becomes a problem when we fail to understand the real >>> relationships in environments of various sensitive nature. How the AS >>> identifies that a specific record requires approval from Doctor Bob mig= ht >>> be context dependent (sometimes it could be a nurse, a team of doctors, >>> another medical organization, etc.). Maybe you could have various level= s of >>> authorizations (extreme example: military style classifications), so th= at >>> it might even be impossible to tell who can be contacted. >>> >>> That's also why I was suggesting assertions could go beyond >>> authentication events, and include cryptographic assertions for >>> authorization purposes. Maybe we can even imagine a risk based approach= , as >>> in some cases we won't know for sure. >>> >>> The difficulty will be to be sufficiently generic but simple enough. >>> Maybe we can rule out some cases. Maybe remote async contacts are out o= f >>> scope, because we only want instantaneous authorizations. Most of those >>> cases are way beyond what OAuth2 does. I don't know. But what's certain= is >>> that the WG should decide what support for cases where end-user !=3D RO= it >>> intends to provide. My discussion was just a very small Chesterston's F= ence >>> contribution, even if that seems to have surprised. >>> >>> Fabien >>> >>> >>> On Wed, Mar 10, 2021 at 8:18 PM Justin Richer wrote: >>> >>>> Hi Fabien, >>>> >>>> First, thanks for doing the heavy lift of writing this topic up. Of >>>> these options, I would strongly prefer option (1). The difference betw= een >>>> assertions and identifiers is that an assertion is a fully packaged se= t of >>>> attributes, one of which can be an identifier. They are, generally >>>> speaking, cryptographically protected bundles. They=E2=80=99re designe= d to carry a >>>> bunch of different information about a user and the authentication eve= nt in >>>> a form that=E2=80=99s independently verifiable and auditable. SAML ass= ertions (XML >>>> document) and ID Tokens (signed JWTs) are the most common ones we see >>>> today, but other formats exist and will keep being invented. >>>> >>>> An identifier is a different kind of creature. It is a single statemen= t >>>> that identifies the party in question in the context of the party doin= g the >>>> identification. It=E2=80=99s this full context that the receiver of th= e identifier >>>> needs to interpret it in. When using a federated identity protocol, ea= ch RP >>>> is going to have :some: kind of local user information store that they= =E2=80=99re >>>> going to tie into, some field in a database they=E2=80=99ll key off of= . It=E2=80=99s just >>>> never going to be the case that all RPs will be able to use server-pro= vided >>>> opaque identifiers for all cases. Account recovery and binding is one = such >>>> use case where a user-facing identifier like an email address makes a = LOT >>>> of sense, for one small example. This is an array in the request and >>>> response precisely because a user could be known by several different >>>> identifiers to a party, and an RP will have a better idea about what k= inds >>>> of things it wants to correlate against, and it=E2=80=99s up to the AS= to provide >>>> that mapping. I think that if we don=E2=80=99t define a way to describ= e the format, >>>> the =E2=80=9Cas_id=E2=80=9D field is going to get structure back-patch= ed onto it like is >>>> being proposed here: >>>> >>>> https://mattrglobal.github.io/oidc-portable-identities/ >>>> >>>> I=E2=80=99m personally not a fan of that approach as it mixes the data= layering >>>> too much, and you end up making guesses about whether a field is meani= ngful >>>> or a pointer. I think GNAP will be much better served by using a data >>>> structure for this from the start. DIDs should be another =E2=80=9Cfor= mat=E2=80=9D of the >>>> subject identifier. I don=E2=80=99t think GNAP should define this form= at, and I=E2=80=99ve >>>> dropped a note to the SECEVENT mailing list asking about adding DIDs t= o the >>>> subject identifiers draft before it gets published. DIDs are not >>>> assertions, even in the cases where they point to fully functional DID >>>> documents with user information in them. (And for what it=E2=80=99s wo= rth, I think >>>> the OIDC world should also use the SECEVENT draft inside ID Tokens to = solve >>>> the use case of the draft above). >>>> >>>> For the user !=3D RO cases, I think that potentially having a way to >>>> signal those two items separately in the request and response could be >>>> useful. Right now all the user/subject stuff is about identifying =E2= =80=9Cthe user >>>> that=E2=80=99s currently here at the client instance=E2=80=9D, in a va= riety of forms that >>>> the client instance and AS can negotiate. If the client or AS has some >>>> other notion about who the RO is and how that could be separate from t= he >>>> current user, we could provide a way to signal that like you=E2=80=99r= e proposing >>>> below. In my mental model, there are going to be a lot of use cases wh= ere >>>> the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the client at all, but= rather to the AS and is >>>> based on what the client=E2=80=99s asking for. So I could identify the= current user >>>> and ask for a specific medical record, and the AS realizes it has to g= o bug >>>> a particular doctor to approve things directly. This is instead of >>>> interacting with the current user and failing in an awkward way when t= he >>>> current user doesn=E2=80=99t have the rights to do things, but someone= else would. >>>> But we=E2=80=99d want the system to be able to detect if the current u= ser is the >>>> doctor, so we can just interact with them directly. Does that all trac= k? >>>> >>>> =E2=80=94 Justin >>>> >>>> On Mar 10, 2021, at 4:10 AM, Fabien Imbault >>>> wrote: >>>> >>>> Hello, >>>> >>>> Notice the question mark in the title. Not to be considered as an >>>> editor's comment. >>>> This thread intends to provide a detailed comment on the >>>> interesting feedback by Kristina: "I would catch up on the thread to >>>> understand why DIDs are thought to be treated as assertions". >>>> In the chat, I answered: "Happy to get the discussion on DIDs. >>>> Actually, could be either or, depending on what we intend to do." Let = me >>>> expand a bit on that, to make it understandable (didn't have the time >>>> during the meeting, unfortunately). >>>> >>>> This relates to the items described on slides 20 and 34, which I'll >>>> explain further. I'll highlight as transparently as possible what I th= ink >>>> would be the benefits and downsides of each. Both are probably viable >>>> options, but they correspond to different scopes and objectives. I'll = spend >>>> a bit more time on option 2, since it is a different approach compared= to >>>> the current draft. >>>> >>>> *1. The first possibility is to use SECEVENT throughout. * >>>> In that case, DIDs should be a part of sub_ids (in the core or in the >>>> extension registry, depending on what Annabelle's WG decides). More >>>> generally, the WG would have to decide which additional sub_ids it nee= ds >>>> (as per Yaron's comment). >>>> >>>> That's obviously the closest to what is described in draft-04. It >>>> allows a communication of subject information between the client and t= he >>>> AS, by using global identifiers (mail, phone, etc.), or using a local >>>> opaque reference - i.e. governed by the AS (that's probably what we >>>> would put in the examples, unless someone has a better idea - cf issue= s #16 >>>> and #42). >>>> >>>> Assertions relate for instance to the proof of presence of the RO. The >>>> current draft-04 therefore plans for id_tokens and saml2, maybe there = could >>>> be other needs later (extension registry). >>>> >>>> - Benefits: identifiers are a key component of GNAP, which makes >>>> integration easier. Possibly one could choose to use DIDs throughout. >>>> - Downsides: email/phone identifiers will probably be used throughout >>>> by most devs (since that's correlation information they have in their = user >>>> DB). Which means we should limit what assertions contain, to avoid doi= ng >>>> links between weak global identifiers and hopefully stronger assertion= s. >>>> That's not really a problem if it's limited to authentication events m= ostly >>>> (in that perspective, samlv2 could make sense in the core). An asserti= on is >>>> probably a single value then (not an array). >>>> >>>> Option 1 can be summarized as: >>>> >>>> "subject": { >>>> "sub_ids": { }, // request and response (SECEVENT -> including DID >>>> possibly) >>>> "assertions": [ ], // request and response (id_token >>>> or samlv2) >>>> } >>>> ("hints" do not exist currently, but are partially covered separately >>>> via "request.user" / the relevance of "principal", discussed in the sl= ide, >>>> is a question mark too - which is a different discussion on end-user != =3D RO). >>>> >>>> >>>> *2. An alternate possibility is to use SECEVENT only as input/hint* >>>> In that case, DIDs should be a part of assertions (which have a >>>> different meaning compared to option 1). >>>> >>>> The AS only returns an local opaque reference as_ref (while in option >>>> 1, it was only one of many possibilities). Its only job is to help the >>>> client differentiate the response subject. The AS policy might further >>>> define the scope of that reference, as suggested in >>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210, >>>> although I personally viewed that by default as (2) "as_id" an identif= ier >>>> locally unique to that AS for all the RSs. >>>> >>>> SECEVENTS are still useful as an input, that's what I presented in >>>> request.hints.self.sub_ids (but it's the responsibility of the AS to m= atch >>>> it with its own reference system - from instance from the email to AS'= s >>>> local record XUT2MFM1XBIKJKSDU8Q). Note: since the slides, a new >>>> draft-ietf-secevent-subject-identifiers-07 has been published. Notably= this >>>> includes an opaque identifier, which the client can use to pass the as= _ref >>>> hint to the AS. Thus we wouldn't need any further addition to >>>> SECEVENT, although hints would benefit from further additions (like DI= Ds >>>> for instance). Notice also that subject_types_supported becomes less >>>> important, because in the worst case scenario, it's simply a hint that >>>> wouldn't be understood and therefore taken into account by the AS. >>>> >>>> The assertions array has a more important role than in option 1 (with >>>> the explicit aim of separating between client hints and validated info >>>> asserted by the AS). It serves as a generic/extendible mapping structu= re, >>>> e.g. "the AS asserts that opaque reference XUT2MFM1XBIKJKSDU8Q is >>>> matching with these (more or less verifiable) statements." The name >>>> assertion therefore corresponds to the responsibility of the AS in >>>> delivering those statements (cf should/must, issue #49). Some of these >>>> statements relate to identity or auth events (ex: DID, id_token), some >>>> might directly be useful for authorization decisions (like ZKP example= in >>>> the parental control example). Possibly some of these validated assert= ions >>>> could be reused in next interactions. >>>> >>>> Another question that popped-up is the scope of sub_ids. Should they b= e >>>> about the same user? (I think so). In the case of remote ROs especiall= y, it >>>> might be important that DID be considered as an assertion (about someo= ne >>>> else's) and not as sub_ids, because the AS needs to be careful about w= ho >>>> the client wants to reach (avoid spam, etc.). This is consistent with = the >>>> rest of discussion on what to do when end-user !=3D RO, although using >>>> DIDComm might seem a bit early (the paint is very fresh). >>>> >>>> Option 2 was summarized as: >>>> >>>> // (suggestion only, not as an editor) >>>> "subject": { >>>> "as_ref": { // response only (wouldn=E2=80=99t require SECEVENT) >>>> =E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D, >>>> =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D >>>> }, >>>> "assertions": [ ], // request and response >>>> (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validated by th= e AS) >>>> >>>> "hints": { // request only (optional) >>>> "self": { // replaces request.user (support SECEVENT here) >>>> =E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque in dr= aft-07 - that >>>> could contain the ref) >>>> =E2=80=9Cassertions=E2=80=9D: [ ] // see examples: VC on DOB or ZKP= on age (wider >>>> scope, possibly through extensions) >>>> }, >>>> "principal": { // new proposal presented at IETF110 (just an >>>> idea) >>>> =E2=80=9Cautomated=E2=80=9D: true, // rule engine >>>> =E2=80=9Casync=E2=80=9D: { } // remote ROs >>>> } >>>> } >>>> } >>>> >>>> - Benefits: as_ref is self supporting (no strong coupling with >>>> SECEVENT), but can still take SECEVENT as an input hint for the AS. It >>>> avoids the risk of making an official association between a weak globa= l >>>> identifier (e.g. email, used elsewhere) and hopefully stronger local >>>> assertions. GNAP would be fully agnostic to whatever identity system i= s >>>> used, only facilitating interoperability through assertions (second on= ly in >>>> importance compared to the AS opaque reference). Some assertions (poss= ibly >>>> extensions) could also be useful for the AS decision (e.g. VC or ZKP). >>>> - Downsides: opaqueness of as_ref is a feature, not a bug. The opaque >>>> reference is fully managed by the AS, therefore not inherently portabl= e (cf >>>> portability discussions in OIDC currently). There's no explicit bindin= g to >>>> an official identity, only a contextual mapping to AS validated assert= ions. >>>> It makes it more difficult to match the identifiers from one AS to ano= ther >>>> or to correlate with the client user DB (still possible via assertions= , if >>>> the AS allows it). Assertions are much more generic (possibly via >>>> extensions), but might require a more advanced mechanism to >>>> request/response only the most relevant information (which makes the A= S >>>> policy critical here). >>>> >>>> I hope that clarifies the reasoning for both options. Again I'm not >>>> saying option 2 is better, just saying the trade-offs are different (+ >>>> knowing that we need to keep it simple). >>>> - option 1 puts more in sub_ids and less in assertions >>>> - option 2 puts less in the reference and more in assertions >>>> All of this is open to discussion. More generally speaking, on every >>>> part in orange and question mark (?) I would love your ideas and >>>> criticisms. What I intended as an editor is only to highlight where th= e WG >>>> has important choices to make, before we can make the related PRs. >>>> >>>> A further side comment: IETF EAT RATS was suggested for assertions, bu= t >>>> relates more to the client attestations. It was added as a comment in >>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, which is >>>> a distinct topic we'll work on. >>>> >>>> Fabien (editor's hat off) >>>> >>>> -- >>>> 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 >> > > This communication, including any attachments, is confidential. If you ar= e not the intended recipient, you should not read it - please contact me im= mediately, destroy it, and do not copy or use any part of this communicatio= n or disclose anything about it. Thank you. Please note that this communica= tion does not designate an information system for the purposes of the Elect= ronic Transactions Act 2002. > > --00000000000047c62905bdb1d6c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Tobias,

    N= ot yet (none of the current sub_ids require additional parameters) but if D= IDs do get added to subject identifiers, then it's certainly something = we would have to support.=C2=A0

    There's already a very basic version of that, but only to cho= se the main type (now called "format" in latest draft 07 of SECEV= ENT), with subject_types_supported in the discovery.=C2=A0

    Thanks for the heads up, it's worth = creating an issue or putting a note in some existing issue to not forget lo= oking into that.=C2=A0

    C= heers
    Fabien


    Le mer. 17 mars 2021 = =C3=A0 01:01, Tobias Looker <tobias.looker@mattr.global> a =C3=A9crit= =C2=A0:
    Hi,
    This is probably out of scope for the current conversation but= has any thought been had on how the client instance could communicate addi= tional options around what subject identifier types it supports for cases w= here the client instance will perhaps be required to conduct additional pro= cessing on the artifacts returned by the AS? As an example if the AS chose = to identify the subject (End-User) using a DID and wanted to include an add= itional cryptographic assertion that showed it controls keys appropriately = associated to the DID, then the client may have wanted to communicate some = information up front in their request to ensure they can perform this addit= ional processing, such as the signature suites it supports and in the conte= xt of DIDs potentially which DID methods it is capable of resolving?

    Thanks,
    =3D"Mattr<= /td>=C2=A0<= /tr>
    Tobias Looker
    Mat= tr
    +64 (0) 27 378 0461
    tobias.looker@mattr.global
    <= /tr>
    3D"Mattr3D"Mattr= 3D"Mattr= 3D"Mattr
    This communication, inclu= ding any attachments, is confidential. If you are not the intended recipien= t, you should not read it - please contact me immediately, destroy it, and = do not copy or use any part of this communication or disclose anything abou= t it. Thank you. Please note that this communication does not designate an = information system for the purposes of the Electronic Transactions Act 2002= .


    On Sat, Mar 13, 2021 at 9:26 PM Fa= bien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Ju= stin,=C2=A0

    A last word = on end-user! =3DRO (again just as food for thought).=C2=A0

    As soon as hints.automated is set to tru= e, it takes priority over async, which means it's the same model as the= one you describe : the AS has precedence over any other remote contact.=C2= =A0

    So that confirms the= global view that the AS is the one with the authority, and that it might k= now more than the client.=C2=A0

    Cheers
    Fabien=C2=A0

    Le jeu. 11 mars 2021 =C3=A0 11:44, Fabien Imbault <fabien.= imbault@gmail.com> a =C3=A9crit=C2=A0:
    Hi Justin,

    I think that's interesting:
    "For the user !=3D RO= cases, I think that potentially having a way to signal those two items sep= arately in the request and response could be useful. Right now all the user= /subject stuff is about identifying =E2=80=9Cthe user that=E2=80=99s curren= tly here at the client instance=E2=80=9D, in a variety of forms that the cl= ient instance and AS can negotiate. If the client or AS has some other noti= on about who the RO is and how that could be separate from the current user= , we could provide a way to signal that like you=E2=80=99re proposing below= . In my mental model, there are going to be a lot of use cases where the = =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the client at all, but rather t= o the AS and is based on what the client=E2=80=99s asking for. So I could i= dentify the current user and ask for a specific medical record, and the AS = realizes it has to go bug a particular doctor to approve things directly. T= his is instead of interacting with the current user and failing in an awkwa= rd way when the current user doesn=E2=80=99t have the rights to do things, = but someone else would. But we=E2=80=99d want the system to be able to dete= ct if the current user is the doctor, so we can just interact with them dir= ectly. Does that all track?"

    I agree with the= general idea. In the end, that's the AS's responsibility (and also= a big part of its value as a policy engine). =C2=A0

    Even in the cases - as I suggested - where the client would be able to s= ignal what it knows (or thinks it knows) about the subject, the AS still ne= eds to validate what it can. The client could be an attacker lying to the A= S. Or there could be an unintended bug.=C2=A0

    The= =C2=A0client still seems like a straightforward source to gather optional/d= eclarative hints. Which is what request.user is already doing in spirit. In= many cases, the AS should go a step further. Validate cryptographic statem= ents from a more reputable issuer, whatever helps.

    Contacts might be one of the possibilities. I'm not suggesting interac= t/fail scenarii at all, which I see as anti-ergonomic (composability with t= imeouts and fallback is the answer to that). The failure I was considering = is only for async calls explicitly requested by the client (which is consid= ered in sequence 1.4.3, and not coming from me), there's obviously no w= ay to ensure a remote RO would actually respond when the client expects it.= If that sequence is considered, realistic failure modes should be anticipa= ted and dealt with internally (just like any distributed program would do),= is all I'm saying. And so from the outside, there's no interact/fa= il.=C2=A0=C2=A0
    That's the same as in real life: when booking= a business trip, an employee could either follow the generic rule (2nd cla= ss train ticket) or reach out to his manager, explaining that it's a lo= ng trip and that 1st class would be better. The employee knows the manager = might not instantly respond, and knows that the absence of an answer means = he'll have to go for the 2nd class.=C2=A0

    = There will be cases when the=C2=A0client doesn't know the=C2=A0RO. I= 9;m not sure if that's a majority of cases, but it will definitely happ= en. It could happen when you interact with an organization or a team and ha= ve no idea who's responsible or what delegations are in place (some of = those cases have been described by Adrian for instance).=C2=A0
    Th= ere could also be cases where the ownership could be distributed (an exampl= e was provided when considering remote ROs). Again in real life, it's n= ot unusual for a decision to fallback on a deputy when the main decision ma= ker is unavailable. Or there could be an open governance even, but maybe th= at's one step too far.

    Of course, if the AS ha= s internal knowledge or other ways to get the information it should use it.= Remains to be seen how we can specify that (cf issue #49 on should/must). = The example with doctor/patient is fine if hardcoded, but it becomes a prob= lem when we fail to understand the real relationships in environments of va= rious sensitive nature. How the AS identifies that a specific record requir= es approval from Doctor Bob might be context dependent (sometimes it could = be a nurse, a team of doctors, another medical organization, etc.). Maybe y= ou could have various levels of authorizations (extreme example: military s= tyle classifications), so that it might even be impossible to tell who can = be contacted.=C2=A0

    That's also why I was sugg= esting assertions could go beyond authentication events, and include crypto= graphic assertions for authorization purposes. Maybe we can even imagine a = risk based approach, as in some cases we won't know for sure.=C2=A0

    The difficulty will be to be sufficiently generic but= simple enough. Maybe we can rule out some cases. Maybe remote async contac= ts are out of scope,=C2=A0because we only want instantaneous authorizations= . Most of those cases are way beyond what OAuth2 does. I don't know. Bu= t what's certain is that the WG should decide what support for cases wh= ere end-user !=3D RO it intends to provide. My discussion was just a very s= mall Chesterston's Fence contribution, even if that seems to have surpr= ised.

    Fabien

    On Wed, Mar 10, 2021 at 8:18 PM Justin Richer <jricher@mit.edu> wrote:
    Hi Fabien,

    First, thanks for doin= g the heavy lift of writing this topic up. Of these options, I would strong= ly prefer option (1). The difference between assertions and identifiers is = that an assertion is a fully packaged set of attributes, one of which can b= e an identifier. They are, generally speaking, cryptographically protected = bundles. They=E2=80=99re designed to carry a bunch of different information= about a user and the authentication event in a form that=E2=80=99s indepen= dently verifiable and auditable. SAML assertions (XML document) and ID Toke= ns (signed JWTs) are the most common ones we see today, but other formats e= xist and will keep being invented.=C2=A0

    An identi= fier is a different kind of creature. It is a single statement that identif= ies the party in question in the context of the party doing the identificat= ion. It=E2=80=99s this full context that the receiver of the identifier nee= ds to interpret it in. When using a federated identity protocol, each RP is= going to have :some: kind of local user information store that they=E2=80= =99re going to tie into, some field in a database they=E2=80=99ll key off o= f. It=E2=80=99s just never going to be the case that all RPs will be able t= o use server-provided opaque identifiers for all cases. Account recovery an= d binding is one such use case where a user-facing identifier like an email= address makes a LOT of sense, for one small example. This is an array in t= he request and response precisely because a user could be known by several = different identifiers to a party, and an RP will have a better idea about w= hat kinds of things it wants to correlate against, and it=E2=80=99s up to t= he AS to provide that mapping. I think that if we don=E2=80=99t define a wa= y to describe the format, the =E2=80=9Cas_id=E2=80=9D field is going to get= structure back-patched onto it like is being proposed here:

    =

    I=E2=80=99m p= ersonally not a fan of that approach as it mixes the data layering too much= , and you end up making guesses about whether a field is meaningful or a po= inter. I think GNAP will be much better served by using a data structure fo= r this from the start. DIDs should be another =E2=80=9Cformat=E2=80=9D of t= he subject identifier. I don=E2=80=99t think GNAP should define this format= , and I=E2=80=99ve dropped a note to the SECEVENT mailing list asking about= adding DIDs to the subject identifiers draft before it gets published. DID= s are not assertions, even in the cases where they point to fully functiona= l DID documents with user information in them. (And for what it=E2=80=99s w= orth, I think the OIDC world should also use the SECEVENT draft inside ID T= okens to solve the use case of the draft above).

    F= or the user !=3D RO cases, I think that potentially having a way to signal = those two items separately in the request and response could be useful. Rig= ht now all the user/subject stuff is about identifying =E2=80=9Cthe user th= at=E2=80=99s currently here at the client instance=E2=80=9D, in a variety o= f forms that the client instance and AS can negotiate. If the client or AS = has some other notion about who the RO is and how that could be separate fr= om the current user, we could provide a way to signal that like you=E2=80= =99re proposing below. In my mental model, there are going to be a lot of u= se cases where the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the client a= t all, but rather to the AS and is based on what the client=E2=80=99s askin= g for. So I could identify the current user and ask for a specific medical = record, and the AS realizes it has to go bug a particular doctor to approve= things directly. This is instead of interacting with the current user and = failing in an awkward way when the current user doesn=E2=80=99t have the ri= ghts to do things, but someone else would. But we=E2=80=99d want the system= to be able to detect if the current user is the doctor, so we can just int= eract with them directly. Does that all track?

    =C2= =A0=E2=80=94 Justin

    On Ma= r 10, 2021, at 4:10 AM, Fabien Imbault <fabien.imbault@= gmail.com> wrote:

    Hello,

    Notice the question mark in the title. Not to be considered as an ed= itor's comment.
    This thread intends to provide a detailed com= ment on the interesting=C2=A0feedback by Kristina: "I would catch up o= n the thread to understand why DIDs are thought to be treated as assertions= ".
    In the chat, I answered: "Happy to get the discussio= n on DIDs. Actually, could be either or, depending on what we intend to do.= " Let me expand a bit on that, to make it understandable (didn't h= ave the time during the meeting, unfortunately).

    T= his relates to the items described on slides 20 and 34, which I'll expl= ain further. I'll highlight as transparently as possible what I think w= ould be the benefits and downsides of each. Both are probably viable option= s, but they correspond to different scopes and objectives. I'll spend a= bit more time on option 2, since it is a different approach compared to th= e current draft.

    1. The first possibility is to use SECEVENT thr= oughout.=C2=A0
    In that case, DIDs should be a part of sub_ids= (in the core or in the extension registry, depending on what Annabelle'= ;s WG decides). More generally, the WG would have to decide which additiona= l sub_ids it needs (as per Yaron's comment).

    T= hat's obviously the closest to what is described in draft-04. It allows= a communication of subject information between the client and the AS, by u= sing global identifiers (mail, phone, etc.), or using a local opaque refere= nce=C2=A0- i.e. governed by the AS (that's probably what we would=C2=A0= put in the examples, unless someone has a better idea - cf issues #16 and #= 42).=C2=A0

    Assertions relate for instance to the p= roof of presence of the RO. The current draft-04 therefore plans for id_tok= ens and saml2, maybe there could be other needs later (extension registry).=

    - Benefits: identifiers are a key component of GN= AP, which makes integration easier. Possibly one could choose to use DIDs t= hroughout.
    - Downsides: email/phone identifiers will probably be = used throughout by most devs (since that's correlation information they= =C2=A0have in their user DB). Which means we should limit what assertions c= ontain, to avoid doing links between weak global identifiers and hopefully = stronger assertions. That's not really a problem if it's limited to= authentication events mostly (in that perspective, samlv2 could make sense= in the core). An assertion is probably a single value then (not an array).= =C2=A0 =C2=A0

    Option 1 can be summarized as:= =C2=A0

    "subject": {
    <= font size=3D"1">=C2=A0=C2=A0=C2=A0"sub_ids": { }, <= /span> // = request and response (SECEVENT -> including DID possibly)<= span style=3D"background-color:rgb(247,247,247);color:rgb(51,51,51);font-fa= mily:"Courier New";font-size:x-small;white-space:pre-wrap;text-in= dent:36pt">=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=C2=A0=C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0&= quot;assertions": [ ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 // request and response (id_token or samlv2)
    }
    (&= quot;hints" do not exist currently, but are partially covered separate= ly via "request.user" / the relevance of "principal", d= iscussed in the slide, is a question mark too - which is a different discus= sion on end-user !=3D RO).


    2.= An alternate possibility is to use SECEVENT only as input/hint
    In that case, DIDs should be a part of assertions (which have a differen= t meaning compared to option 1).

    The AS only retur= ns an local opaque reference as_ref (while in option 1, it was only one of = many possibilities). Its only job is to help the client differentiate the r= esponse subject. The AS policy might further define the scope of that refer= ence, as suggested in=C2=A0h= ttps://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210, although = I personally=C2=A0viewed that by default as=C2=A0(2) "as_id" an i= dentifier locally unique to that AS for all the RSs.

    SECEVENTS are still useful as an input, that's what I presented in r= equest.hints.self.sub_ids (but it's the responsibility=C2=A0of the AS t= o match it with its own reference system - from instance from the email to = AS's local record XUT2MFM1XBIKJKSDU8Q).=C2=A0Note: since the slides, a = new draft-ietf-secevent-subject-identifiers-07 has been published. Notably = this includes an opaque identifier, which the client can use to pass the as= _ref hint to the AS. Thus we wouldn't need any further addition to SECE= VENT,=C2=A0although hints would benefit from further additions (like DIDs f= or instance). Notice also that subject_types_supported becomes less importa= nt, because in the worst case scenario, it's simply=C2=A0a hint that wo= uldn't be understood and therefore taken into account by the AS.
    <= div>
    The assertions array has a more important role than in o= ption 1 (with the explicit aim of separating between client hints and valid= ated info asserted by the AS). It serves as a generic/extendible mapping st= ructure, e.g. "the AS asserts that opaque reference=C2=A0XUT2MFM1XBIKJKSDU8Q<= /span>=C2=A0is matching with these (more or less verifiable) statements.&qu= ot; The name assertion therefore corresponds to the responsibility=C2=A0of = the AS in delivering those statements (cf should/must, issue #49). Some of = these statements relate to identity or auth events (ex: DID, id_token), som= e might directly be useful for authorization decisions (like ZKP example in= the parental control example). Possibly some of these validated assertions= could be reused in next interactions.

    Another que= stion that popped-up is the scope of sub_ids. Should they be about the same= user? (I think so). In the case of remote ROs especially, it might be impo= rtant that DID be considered as an assertion=C2=A0(about someone else's= ) and not as sub_ids, because the AS needs to be careful about who the clie= nt wants to reach (avoid spam, etc.). This is consistent with the rest of d= iscussion on what to do when end-user !=3D RO, although using DIDComm might= seem a bit early (the paint is very fresh).=C2=A0

    Option 2 was summarized as:=C2=A0

    // (suggestion only, not as an editor)
    "subject&= quot;: {
    =C2=A0=C2=A0=C2=A0"as_ref": { // response only (wouldn= =E2=80=99t require SECEVENT)
    =E2=80=9Cas=E2=80= =9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D,
    =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D=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=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"assertions": [ ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 // request and response (id_token/jwkthumb/DID/VC/= etc. -> whatever info can be validated by the AS)

    <= font size=3D"1">=C2=A0=C2=A0=C2=A0"hints": { =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request onl= y (optional)
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"self"= : { // replaces request.user (support SECEVENT here)
    =C2=A0=C2=A0=C2=A0=E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque i= n draft-07 - that could contain the ref)
    =C2=A0= =C2=A0=C2=A0=E2=80=9Cassertions=E2=80=9D: [ ] // see examples: V= C on DOB or ZKP on age (wider scope, possibly through extensions) <= /span>
    },=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=C2=A0=C2=A0=C2=A0
    =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"principal": { // new proposal presented at IETF110 (just an idea)
    =C2=A0 =E2=80=9Cautomated=E2=80=9D: true, // rule eng= ine
    =C2=A0 =E2=80=9Casync=E2= =80=9D: { } // remote ROs
    }=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=C2=A0=C2=A0}
    }<= /div>

    - Benefits: as_ref is self supporting= (no strong coupling with SECEVENT), but can still take SECEVENT as an inpu= t hint for the AS. It avoids the risk of making an official association bet= ween a weak global identifier (e.g. email, used elsewhere) and hopefully st= ronger local assertions. GNAP would be fully agnostic to whatever identity = system is used, only facilitating interoperability through assertions (seco= nd only in importance=C2=A0compared to the AS opaque reference). Some asser= tions (possibly extensions) could also be useful for the AS decision (e.g. = VC or ZKP).
    - Downsides: opaqueness of as_ref is a feature, not a= bug. The opaque reference is fully managed by the AS, therefore not inhere= ntly portable (cf portability discussions in OIDC currently). There's n= o explicit binding to an official identity, only a contextual mapping to AS= validated assertions. It makes it more difficult to match the identifiers = from one AS to another or to correlate with the client user DB (still possi= ble via assertions, if the AS allows it). Assertions are much more generic = (possibly via extensions), but might require a more advanced mechanism=C2= =A0to request/response only the most relevant information (which makes the = AS policy critical here).

    I hope that clarifies th= e=C2=A0reasoning for both options. Again I'm not saying option 2 is bet= ter, just saying the trade-offs are different (+ knowing that we need to ke= ep it simple).
    - option 1 puts more in sub_ids and less in assert= ions
    - option 2 puts less in the reference and more in assertions= =C2=A0
    All of this is open to discussion. More generally speaking= , on every part in orange and question mark (?) I would love your ideas and= criticisms. What I intended as an editor is only to highlight where the WG= has important choices to make, before we can make the related PRs.

    A further side comment: IETF EAT RATS was suggested for a= ssertions, but relates more to the client attestations. It was added as a c= omment in=C2=A0https://github= .com/ietf-wg-gnap/gnap-core-protocol/issues/44, which is a distinct top= ic we'll work on.

    Fabien (editor's hat off= )

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

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

    This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.
    --00000000000047c62905bdb1d6c0-- From nobody Tue Mar 16 19:10:55 2021 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 F2F353A172B for ; Tue, 16 Mar 2021 19:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 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 nqp_98GqZ380 for ; Tue, 16 Mar 2021 19:10:49 -0700 (PDT) Received: from mail-vs1-f43.google.com (mail-vs1-f43.google.com [209.85.217.43]) (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 00CA13A172A for ; Tue, 16 Mar 2021 19:10:48 -0700 (PDT) Received: by mail-vs1-f43.google.com with SMTP id v123so225601vsv.9 for ; Tue, 16 Mar 2021 19:10:48 -0700 (PDT) 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=Me3QRgaM29+H1WVJas7aihqILonCJ07J/iO6vzm7DMg=; b=WjuKXp9KA8aSnFkuJ33ujizhG+V+Q2jCC8LNh1wdSTE3/RZP6VJC1w1uwvOVlPM2kJ Dr25HD/xGmFcPZyyIoT6PnsMIj3+Xw/efFN+MeaPZyHTZ7GfSHiPCJQcZZFn1/ZzqGVo SEQckRtXoomlGtx7e+Q6/SPbn6kAGcuS26JFIiyjOOP74I7oxiqy66wyo2758o3YS1Un yuwPuYLmy09zfKRTVyBHiqfzIgPExQS0R2NWRlay5NvYnAX4JayKu6tSwPh0wkmKvTvu mXjvt1THzNRiEYfm0iHDhP09HeMHrwBXIhSh9fYHlAxUNHLlcr13uWuB3AGkVwVadgRK GMlg== X-Gm-Message-State: AOAM530ZdAGZRHiBZ1Eze5Lhmyg8ixlfUv8nc+Gqjkwfvig/RNY+ci0P rBXtOtb8U3+nCaGsbwN+qyVnjazglHqkWcatvB0= X-Google-Smtp-Source: ABdhPJzrvy+ykK8IC8XUICAbPCBUHs437GSd1RCAT4hU36FKeE7iOJTVTQMo1DWOS1T9SOpe4UjYR8quga49Svsv+s0= X-Received: by 2002:a05:6102:222f:: with SMTP id d15mr1932062vsb.1.1615947047804; Tue, 16 Mar 2021 19:10:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Adrian Gropper Date: Tue, 16 Mar 2021 22:10:36 -0400 Message-ID: To: Fabien Imbault Cc: Tobias Looker , GNAP Mailing List , Justin Richer Content-Type: multipart/alternative; boundary="000000000000c2a41705bdb1fdbd" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 02:10:53 -0000 --000000000000c2a41705bdb1fdbd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm late to this conversation and confused by Tobias' use of End-User (his caps) and subject. Are we talking about a DID for the subject, the end-user, or both? To be clear, in my mind, the subject is in control of policies and capabilities at the GNAP AS. The end-user is in control of a client or user agent and a request to the AS. The end-user and client may or may not have any prior relationship with the AS. Adrian On Tue, Mar 16, 2021 at 10:00 PM Fabien Imbault wrote: > Hi Tobias, > > Not yet (none of the current sub_ids require additional parameters) but i= f > DIDs do get added to subject identifiers, then it's certainly something w= e > would have to support. > > There's already a very basic version of that, but only to chose the main > type (now called "format" in latest draft 07 of SECEVENT), with > subject_types_supported in the discovery. > > Thanks for the heads up, it's worth creating an issue or putting a note i= n > some existing issue to not forget looking into that. > > Cheers > Fabien > > > Le mer. 17 mars 2021 =C3=A0 01:01, Tobias Looker > a =C3=A9crit : > >> Hi, >> >> This is probably out of scope for the current conversation but has any >> thought been had on how the client instance could communicate additional >> options around what subject identifier types it supports for cases where >> the client instance will perhaps be required to conduct additional >> processing on the artifacts returned by the AS? As an example if the AS >> chose to identify the subject (End-User) using a DID and wanted to inclu= de >> an additional cryptographic assertion that showed it controls keys >> appropriately associated to the DID, then the client may have wanted to >> communicate some information up front in their request to ensure they ca= n >> perform this additional processing, such as the signature suites it >> supports and in the context of DIDs potentially which DID methods it is >> capable of resolving? >> >> Thanks, >> [image: Mattr website] >> *Tobias Looker* >> Mattr >> +64 (0) 27 378 0461 >> tobias.looker@mattr.global >> [image: Mattr website] [image: Mattr on LinkedIn] >> [image: Mattr on Twitter] >> [image: Mattr on Github] >> >> This communication, including any attachments, is confidential. If you >> are not the intended recipient, you should not read it - please contact = me >> immediately, destroy it, and do not copy or use any part of this >> communication or disclose anything about it. Thank you. Please note that >> this communication does not designate an information system for the >> purposes of the Electronic Transactions Act 2002. >> >> >> On Sat, Mar 13, 2021 at 9:26 PM Fabien Imbault >> wrote: >> >>> Hi Justin, >>> >>> A last word on end-user! =3DRO (again just as food for thought). >>> >>> As soon as hints.automated is set to true, it takes priority over async= , >>> which means it's the same model as the one you describe : the AS has >>> precedence over any other remote contact. >>> >>> So that confirms the global view that the AS is the one with the >>> authority, and that it might know more than the client. >>> >>> Cheers >>> Fabien >>> >>> Le jeu. 11 mars 2021 =C3=A0 11:44, Fabien Imbault >>> a =C3=A9crit : >>> >>>> Hi Justin, >>>> >>>> I think that's interesting: >>>> "For the user !=3D RO cases, I think that potentially having a way to >>>> signal those two items separately in the request and response could be >>>> useful. Right now all the user/subject stuff is about identifying =E2= =80=9Cthe user >>>> that=E2=80=99s currently here at the client instance=E2=80=9D, in a va= riety of forms that >>>> the client instance and AS can negotiate. If the client or AS has some >>>> other notion about who the RO is and how that could be separate from t= he >>>> current user, we could provide a way to signal that like you=E2=80=99r= e proposing >>>> below. In my mental model, there are going to be a lot of use cases wh= ere >>>> the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the client at all, but= rather to the AS and is >>>> based on what the client=E2=80=99s asking for. So I could identify the= current user >>>> and ask for a specific medical record, and the AS realizes it has to g= o bug >>>> a particular doctor to approve things directly. This is instead of >>>> interacting with the current user and failing in an awkward way when t= he >>>> current user doesn=E2=80=99t have the rights to do things, but someone= else would. >>>> But we=E2=80=99d want the system to be able to detect if the current u= ser is the >>>> doctor, so we can just interact with them directly. Does that all trac= k?" >>>> >>>> I agree with the general idea. In the end, that's the AS's >>>> responsibility (and also a big part of its value as a policy engine). >>>> >>>> Even in the cases - as I suggested - where the client would be able to >>>> signal what it knows (or thinks it knows) about the subject, the AS st= ill >>>> needs to validate what it can. The client could be an attacker lying t= o the >>>> AS. Or there could be an unintended bug. >>>> >>>> The client still seems like a straightforward source to gather >>>> optional/declarative hints. Which is what request.user is already doin= g in >>>> spirit. In many cases, the AS should go a step further. Validate >>>> cryptographic statements from a more reputable issuer, whatever helps. >>>> >>>> Contacts might be one of the possibilities. I'm not suggesting >>>> interact/fail scenarii at all, which I see as anti-ergonomic (composab= ility >>>> with timeouts and fallback is the answer to that). The failure I was >>>> considering is only for async calls explicitly requested by the client >>>> (which is considered in sequence 1.4.3, and not coming from me), there= 's >>>> obviously no way to ensure a remote RO would actually respond when the >>>> client expects it. If that sequence is considered, realistic failure m= odes >>>> should be anticipated and dealt with internally (just like any distrib= uted >>>> program would do), is all I'm saying. And so from the outside, there's= no >>>> interact/fail. >>>> That's the same as in real life: when booking a business trip, an >>>> employee could either follow the generic rule (2nd class train ticket)= or >>>> reach out to his manager, explaining that it's a long trip and that 1s= t >>>> class would be better. The employee knows the manager might not instan= tly >>>> respond, and knows that the absence of an answer means he'll have to g= o for >>>> the 2nd class. >>>> >>>> There will be cases when the client doesn't know the RO. I'm not sure >>>> if that's a majority of cases, but it will definitely happen. It could >>>> happen when you interact with an organization or a team and have no id= ea >>>> who's responsible or what delegations are in place (some of those case= s >>>> have been described by Adrian for instance). >>>> There could also be cases where the ownership could be distributed (an >>>> example was provided when considering remote ROs). Again in real life,= it's >>>> not unusual for a decision to fallback on a deputy when the main decis= ion >>>> maker is unavailable. Or there could be an open governance even, but m= aybe >>>> that's one step too far. >>>> >>>> Of course, if the AS has internal knowledge or other ways to get the >>>> information it should use it. Remains to be seen how we can specify th= at >>>> (cf issue #49 on should/must). The example with doctor/patient is fine= if >>>> hardcoded, but it becomes a problem when we fail to understand the rea= l >>>> relationships in environments of various sensitive nature. How the AS >>>> identifies that a specific record requires approval from Doctor Bob mi= ght >>>> be context dependent (sometimes it could be a nurse, a team of doctors= , >>>> another medical organization, etc.). Maybe you could have various leve= ls of >>>> authorizations (extreme example: military style classifications), so t= hat >>>> it might even be impossible to tell who can be contacted. >>>> >>>> That's also why I was suggesting assertions could go beyond >>>> authentication events, and include cryptographic assertions for >>>> authorization purposes. Maybe we can even imagine a risk based approac= h, as >>>> in some cases we won't know for sure. >>>> >>>> The difficulty will be to be sufficiently generic but simple enough. >>>> Maybe we can rule out some cases. Maybe remote async contacts are out = of >>>> scope, because we only want instantaneous authorizations. Most of thos= e >>>> cases are way beyond what OAuth2 does. I don't know. But what's certai= n is >>>> that the WG should decide what support for cases where end-user !=3D R= O it >>>> intends to provide. My discussion was just a very small Chesterston's = Fence >>>> contribution, even if that seems to have surprised. >>>> >>>> Fabien >>>> >>>> >>>> On Wed, Mar 10, 2021 at 8:18 PM Justin Richer wrote: >>>> >>>>> Hi Fabien, >>>>> >>>>> First, thanks for doing the heavy lift of writing this topic up. Of >>>>> these options, I would strongly prefer option (1). The difference bet= ween >>>>> assertions and identifiers is that an assertion is a fully packaged s= et of >>>>> attributes, one of which can be an identifier. They are, generally >>>>> speaking, cryptographically protected bundles. They=E2=80=99re design= ed to carry a >>>>> bunch of different information about a user and the authentication ev= ent in >>>>> a form that=E2=80=99s independently verifiable and auditable. SAML as= sertions (XML >>>>> document) and ID Tokens (signed JWTs) are the most common ones we see >>>>> today, but other formats exist and will keep being invented. >>>>> >>>>> An identifier is a different kind of creature. It is a single >>>>> statement that identifies the party in question in the context of the= party >>>>> doing the identification. It=E2=80=99s this full context that the rec= eiver of the >>>>> identifier needs to interpret it in. When using a federated identity >>>>> protocol, each RP is going to have :some: kind of local user informat= ion >>>>> store that they=E2=80=99re going to tie into, some field in a databas= e they=E2=80=99ll key >>>>> off of. It=E2=80=99s just never going to be the case that all RPs wil= l be able to >>>>> use server-provided opaque identifiers for all cases. Account recover= y and >>>>> binding is one such use case where a user-facing identifier like an e= mail >>>>> address makes a LOT of sense, for one small example. This is an array= in >>>>> the request and response precisely because a user could be known by s= everal >>>>> different identifiers to a party, and an RP will have a better idea a= bout >>>>> what kinds of things it wants to correlate against, and it=E2=80=99s = up to the AS >>>>> to provide that mapping. I think that if we don=E2=80=99t define a wa= y to describe >>>>> the format, the =E2=80=9Cas_id=E2=80=9D field is going to get structu= re back-patched onto >>>>> it like is being proposed here: >>>>> >>>>> https://mattrglobal.github.io/oidc-portable-identities/ >>>>> >>>>> I=E2=80=99m personally not a fan of that approach as it mixes the dat= a >>>>> layering too much, and you end up making guesses about whether a fiel= d is >>>>> meaningful or a pointer. I think GNAP will be much better served by u= sing a >>>>> data structure for this from the start. DIDs should be another =E2=80= =9Cformat=E2=80=9D of >>>>> the subject identifier. I don=E2=80=99t think GNAP should define this= format, and >>>>> I=E2=80=99ve dropped a note to the SECEVENT mailing list asking about= adding DIDs >>>>> to the subject identifiers draft before it gets published. DIDs are n= ot >>>>> assertions, even in the cases where they point to fully functional DI= D >>>>> documents with user information in them. (And for what it=E2=80=99s w= orth, I think >>>>> the OIDC world should also use the SECEVENT draft inside ID Tokens to= solve >>>>> the use case of the draft above). >>>>> >>>>> For the user !=3D RO cases, I think that potentially having a way to >>>>> signal those two items separately in the request and response could b= e >>>>> useful. Right now all the user/subject stuff is about identifying =E2= =80=9Cthe user >>>>> that=E2=80=99s currently here at the client instance=E2=80=9D, in a v= ariety of forms that >>>>> the client instance and AS can negotiate. If the client or AS has som= e >>>>> other notion about who the RO is and how that could be separate from = the >>>>> current user, we could provide a way to signal that like you=E2=80=99= re proposing >>>>> below. In my mental model, there are going to be a lot of use cases w= here >>>>> the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the client at all, bu= t rather to the AS and is >>>>> based on what the client=E2=80=99s asking for. So I could identify th= e current user >>>>> and ask for a specific medical record, and the AS realizes it has to = go bug >>>>> a particular doctor to approve things directly. This is instead of >>>>> interacting with the current user and failing in an awkward way when = the >>>>> current user doesn=E2=80=99t have the rights to do things, but someon= e else would. >>>>> But we=E2=80=99d want the system to be able to detect if the current = user is the >>>>> doctor, so we can just interact with them directly. Does that all tra= ck? >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Mar 10, 2021, at 4:10 AM, Fabien Imbault >>>>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> Notice the question mark in the title. Not to be considered as an >>>>> editor's comment. >>>>> This thread intends to provide a detailed comment on the >>>>> interesting feedback by Kristina: "I would catch up on the thread to >>>>> understand why DIDs are thought to be treated as assertions". >>>>> In the chat, I answered: "Happy to get the discussion on DIDs. >>>>> Actually, could be either or, depending on what we intend to do." Let= me >>>>> expand a bit on that, to make it understandable (didn't have the time >>>>> during the meeting, unfortunately). >>>>> >>>>> This relates to the items described on slides 20 and 34, which I'll >>>>> explain further. I'll highlight as transparently as possible what I t= hink >>>>> would be the benefits and downsides of each. Both are probably viable >>>>> options, but they correspond to different scopes and objectives. I'll= spend >>>>> a bit more time on option 2, since it is a different approach compare= d to >>>>> the current draft. >>>>> >>>>> *1. The first possibility is to use SECEVENT throughout. * >>>>> In that case, DIDs should be a part of sub_ids (in the core or in the >>>>> extension registry, depending on what Annabelle's WG decides). More >>>>> generally, the WG would have to decide which additional sub_ids it ne= eds >>>>> (as per Yaron's comment). >>>>> >>>>> That's obviously the closest to what is described in draft-04. It >>>>> allows a communication of subject information between the client and = the >>>>> AS, by using global identifiers (mail, phone, etc.), or using a local >>>>> opaque reference - i.e. governed by the AS (that's probably what we >>>>> would put in the examples, unless someone has a better idea - cf issu= es #16 >>>>> and #42). >>>>> >>>>> Assertions relate for instance to the proof of presence of the RO. Th= e >>>>> current draft-04 therefore plans for id_tokens and saml2, maybe there= could >>>>> be other needs later (extension registry). >>>>> >>>>> - Benefits: identifiers are a key component of GNAP, which makes >>>>> integration easier. Possibly one could choose to use DIDs throughout. >>>>> - Downsides: email/phone identifiers will probably be used throughout >>>>> by most devs (since that's correlation information they have in their= user >>>>> DB). Which means we should limit what assertions contain, to avoid do= ing >>>>> links between weak global identifiers and hopefully stronger assertio= ns. >>>>> That's not really a problem if it's limited to authentication events = mostly >>>>> (in that perspective, samlv2 could make sense in the core). An assert= ion is >>>>> probably a single value then (not an array). >>>>> >>>>> Option 1 can be summarized as: >>>>> >>>>> "subject": { >>>>> "sub_ids": { }, // request and response (SECEVENT -> including DID >>>>> possibly) >>>>> "assertions": [ ], // request and response (id_token >>>>> or samlv2) >>>>> } >>>>> ("hints" do not exist currently, but are partially covered separately >>>>> via "request.user" / the relevance of "principal", discussed in the s= lide, >>>>> is a question mark too - which is a different discussion on end-user = !=3D RO). >>>>> >>>>> >>>>> *2. An alternate possibility is to use SECEVENT only as input/hint* >>>>> In that case, DIDs should be a part of assertions (which have a >>>>> different meaning compared to option 1). >>>>> >>>>> The AS only returns an local opaque reference as_ref (while in option >>>>> 1, it was only one of many possibilities). Its only job is to help th= e >>>>> client differentiate the response subject. The AS policy might furthe= r >>>>> define the scope of that reference, as suggested in >>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210, >>>>> although I personally viewed that by default as (2) "as_id" an identi= fier >>>>> locally unique to that AS for all the RSs. >>>>> >>>>> SECEVENTS are still useful as an input, that's what I presented in >>>>> request.hints.self.sub_ids (but it's the responsibility of the AS to = match >>>>> it with its own reference system - from instance from the email to AS= 's >>>>> local record XUT2MFM1XBIKJKSDU8Q). Note: since the slides, a new >>>>> draft-ietf-secevent-subject-identifiers-07 has been published. Notabl= y this >>>>> includes an opaque identifier, which the client can use to pass the a= s_ref >>>>> hint to the AS. Thus we wouldn't need any further addition to >>>>> SECEVENT, although hints would benefit from further additions (like D= IDs >>>>> for instance). Notice also that subject_types_supported becomes less >>>>> important, because in the worst case scenario, it's simply a hint tha= t >>>>> wouldn't be understood and therefore taken into account by the AS. >>>>> >>>>> The assertions array has a more important role than in option 1 (with >>>>> the explicit aim of separating between client hints and validated inf= o >>>>> asserted by the AS). It serves as a generic/extendible mapping struct= ure, >>>>> e.g. "the AS asserts that opaque reference XUT2MFM1XBIKJKSDU8Q is >>>>> matching with these (more or less verifiable) statements." The name >>>>> assertion therefore corresponds to the responsibility of the AS in >>>>> delivering those statements (cf should/must, issue #49). Some of thes= e >>>>> statements relate to identity or auth events (ex: DID, id_token), som= e >>>>> might directly be useful for authorization decisions (like ZKP exampl= e in >>>>> the parental control example). Possibly some of these validated asser= tions >>>>> could be reused in next interactions. >>>>> >>>>> Another question that popped-up is the scope of sub_ids. Should they >>>>> be about the same user? (I think so). In the case of remote ROs espec= ially, >>>>> it might be important that DID be considered as an assertion (about s= omeone >>>>> else's) and not as sub_ids, because the AS needs to be careful about = who >>>>> the client wants to reach (avoid spam, etc.). This is consistent with= the >>>>> rest of discussion on what to do when end-user !=3D RO, although usin= g >>>>> DIDComm might seem a bit early (the paint is very fresh). >>>>> >>>>> Option 2 was summarized as: >>>>> >>>>> // (suggestion only, not as an editor) >>>>> "subject": { >>>>> "as_ref": { // response only (wouldn=E2=80=99t require SECEVENT) >>>>> =E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D, >>>>> =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D >>>>> }, >>>>> "assertions": [ ], // request and response >>>>> (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validated by t= he AS) >>>>> >>>>> "hints": { // request only (optional) >>>>> "self": { // replaces request.user (support SECEVENT here) >>>>> =E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque in d= raft-07 - that >>>>> could contain the ref) >>>>> =E2=80=9Cassertions=E2=80=9D: [ ] // see examples: VC on DOB or ZK= P on age (wider >>>>> scope, possibly through extensions) >>>>> }, >>>>> "principal": { // new proposal presented at IETF110 (just an >>>>> idea) >>>>> =E2=80=9Cautomated=E2=80=9D: true, // rule engine >>>>> =E2=80=9Casync=E2=80=9D: { } // remote ROs >>>>> } >>>>> } >>>>> } >>>>> >>>>> - Benefits: as_ref is self supporting (no strong coupling with >>>>> SECEVENT), but can still take SECEVENT as an input hint for the AS. I= t >>>>> avoids the risk of making an official association between a weak glob= al >>>>> identifier (e.g. email, used elsewhere) and hopefully stronger local >>>>> assertions. GNAP would be fully agnostic to whatever identity system = is >>>>> used, only facilitating interoperability through assertions (second o= nly in >>>>> importance compared to the AS opaque reference). Some assertions (pos= sibly >>>>> extensions) could also be useful for the AS decision (e.g. VC or ZKP)= . >>>>> - Downsides: opaqueness of as_ref is a feature, not a bug. The opaque >>>>> reference is fully managed by the AS, therefore not inherently portab= le (cf >>>>> portability discussions in OIDC currently). There's no explicit bindi= ng to >>>>> an official identity, only a contextual mapping to AS validated asser= tions. >>>>> It makes it more difficult to match the identifiers from one AS to an= other >>>>> or to correlate with the client user DB (still possible via assertion= s, if >>>>> the AS allows it). Assertions are much more generic (possibly via >>>>> extensions), but might require a more advanced mechanism to >>>>> request/response only the most relevant information (which makes the = AS >>>>> policy critical here). >>>>> >>>>> I hope that clarifies the reasoning for both options. Again I'm not >>>>> saying option 2 is better, just saying the trade-offs are different (= + >>>>> knowing that we need to keep it simple). >>>>> - option 1 puts more in sub_ids and less in assertions >>>>> - option 2 puts less in the reference and more in assertions >>>>> All of this is open to discussion. More generally speaking, on every >>>>> part in orange and question mark (?) I would love your ideas and >>>>> criticisms. What I intended as an editor is only to highlight where t= he WG >>>>> has important choices to make, before we can make the related PRs. >>>>> >>>>> A further side comment: IETF EAT RATS was suggested for assertions, >>>>> but relates more to the client attestations. It was added as a commen= t in >>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, which >>>>> is a distinct topic we'll work on. >>>>> >>>>> Fabien (editor's hat off) >>>>> >>>>> -- >>>>> 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 >>> >> >> This communication, including any attachments, is confidential. If you a= re not the intended recipient, you should not read it - please contact me i= mmediately, destroy it, and do not copy or use any part of this communicati= on or disclose anything about it. Thank you. Please note that this communic= ation does not designate an information system for the purposes of the Elec= tronic Transactions Act 2002. >> >> -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000c2a41705bdb1fdbd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I'm late to this conversation and confused by Tobias&#= 39; use of End-User (his caps)=C2=A0and subject. Are we talking about a DID= for the subject, the end-user, or both?

    To be clear, in= my mind, the subject is in control=C2=A0of policies and capabilities at th= e GNAP AS. The end-user is in control=C2=A0of a client or user agent and a = request to the AS. The end-user and client may or may not have any prior re= lationship with the AS.

    Adrian

    On Tue, Mar 16= , 2021 at 10:00 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    =
    Hi Tobias,

    N= ot yet (none of the current sub_ids require additional parameters) but if D= IDs do get added to subject identifiers, then it's certainly something = we would have to support.=C2=A0

    There's already a very basic version of that, but only to cho= se the main type (now called "format" in latest draft 07 of SECEV= ENT), with subject_types_supported in the discovery.=C2=A0

    Thanks for the heads up, it's worth = creating an issue or putting a note in some existing issue to not forget lo= oking into that.=C2=A0

    C= heers
    Fabien


    Le mer. 17 mars 2021 = =C3=A0 01:01, Tobias Looker <tobias.looker@mattr.global> a =C3=A9crit= =C2=A0:
    Hi,

    T= his is probably out of scope for the current conversation but has any thoug= ht been had on how the client instance could communicate additional options= around what subject identifier types it supports for cases where the clien= t instance will perhaps be required to conduct additional processing on the= artifacts returned by the AS? As an example if the AS chose to identify th= e subject (End-User) using a DID and wanted to include an additional crypto= graphic assertion that showed it controls keys appropriately associated to = the DID, then the client may have wanted to communicate some information up= front in their request to ensure they can perform this additional processi= ng, such as the signature suites it supports and in the context of DIDs pot= entially which DID methods it is capable of resolving?

    Thanks,
    <= table width=3D"auto" cellpadding=3D"0" cellspacing=3D"0" border=3D"0" style= =3D"color:rgb(0,0,0);font-family:Times;font-size:medium;border:0px">= 3D"Mattr=C2=A0= =
    Tobias= Looker
    Mattr
    +64 (0) 27 378 0461
    tobias.looker@mattr.global
    3D"Mattr3D"Mattr3D"Mattr

    This communication, including any attachments, is = confidential. If you are not the intended recipient, you should not read it= - please contact me immediately, destroy it, and do not copy or use any pa= rt of this communication or disclose anything about it. Thank you. Please n= ote that this communication does not designate an information system for th= e purposes of the Electronic Transactions Act 2002.
    =


    On Sat, Mar 13, 2021 at 9:26 PM Fabien Imbault <f= abien.imbault@gmail.com> wrote:
    Hi Justin,=C2=A0

    A last word on end-user! =3DRO (again just as food for thought).= =C2=A0

    As soon as hints.= automated is set to true, it takes priority over async, which means it'= s the same model as the one you describe : the AS has precedence over any o= ther remote contact.=C2=A0

    So that confirms the global view that the AS is the one with the authori= ty, and that it might know more than the client.=C2=A0

    Cheers
    Fabien=C2=A0

    Le jeu. 11 mars 2021 =C3=A0 11:44, Fabien Imb= ault <fabien.imbault@gmail.com> a =C3=A9crit=C2=A0:
    Hi Justin,

    I think t= hat's interesting:
    "For the user !=3D RO cases, I t= hink that potentially having a way to signal those two items separately in = the request and response could be useful. Right now all the user/subject st= uff is about identifying =E2=80=9Cthe user that=E2=80=99s currently here at= the client instance=E2=80=9D, in a variety of forms that the client instan= ce and AS can negotiate. If the client or AS has some other notion about wh= o the RO is and how that could be separate from the current user, we could = provide a way to signal that like you=E2=80=99re proposing below. In my men= tal model, there are going to be a lot of use cases where the =E2=80=9CRO= =E2=80=9D isn=E2=80=99t known to the client at all, but rather to the AS an= d is based on what the client=E2=80=99s asking for. So I could identify the= current user and ask for a specific medical record, and the AS realizes it= has to go bug a particular doctor to approve things directly. This is inst= ead of interacting with the current user and failing in an awkward way when= the current user doesn=E2=80=99t have the rights to do things, but someone= else would. But we=E2=80=99d want the system to be able to detect if the c= urrent user is the doctor, so we can just interact with them directly. Does= that all track?"

    I agree with the general id= ea. In the end, that's the AS's responsibility (and also a big part= of its value as a policy engine). =C2=A0

    Even in = the cases - as I suggested - where the client would be able to signal what = it knows (or thinks it knows) about the subject, the AS still needs to vali= date what it can. The client could be an attacker lying to the AS. Or there= could be an unintended bug.=C2=A0

    The=C2=A0client= still seems like a straightforward source to gather optional/declarative h= ints. Which is what request.user is already doing in spirit. In many cases,= the AS should go a step further. Validate cryptographic statements from a = more reputable issuer, whatever helps.

    Contacts mi= ght be one of the possibilities. I'm not suggesting interact/fail scena= rii at all, which I see as anti-ergonomic (composability with timeouts and = fallback is the answer to that). The failure I was considering is only for = async calls explicitly requested by the client (which is considered in sequ= ence 1.4.3, and not coming from me), there's obviously no way to ensure= a remote RO would actually respond when the client expects it. If that seq= uence is considered, realistic failure modes should be anticipated and deal= t with internally (just like any distributed program would do), is all I= 9;m saying. And so from the outside, there's no interact/fail.=C2=A0=C2= =A0
    That's the same as in real life: when booking a business = trip, an employee could either follow the generic rule (2nd class train tic= ket) or reach out to his manager, explaining that it's a long trip and = that 1st class would be better. The employee knows the manager might not in= stantly respond, and knows that the absence of an answer means he'll ha= ve to go for the 2nd class.=C2=A0

    There will b= e cases when the=C2=A0client doesn't know the=C2=A0RO. I'm not sure= if that's a majority of cases, but it will definitely happen. It could= happen when you interact with an organization or a team and have no idea w= ho's responsible or what delegations are in place (some of those cases = have been described by Adrian for instance).=C2=A0
    There could al= so be cases where the ownership could be distributed (an example was provid= ed when considering remote ROs). Again in real life, it's not unusual f= or a decision to fallback on a deputy when the main decision maker is unava= ilable. Or there could be an open governance even, but maybe that's one= step too far.

    Of course, if the AS has internal k= nowledge or other ways to get the information it should use it. Remains to = be seen how we can specify that (cf issue #49 on should/must). The example = with doctor/patient is fine if hardcoded, but it becomes a problem when we = fail to understand the real relationships in environments of various sensit= ive nature. How the AS identifies that a specific record requires approval = from Doctor Bob might be context dependent (sometimes it could be a nurse, = a team of doctors, another medical organization, etc.). Maybe you could hav= e various levels of authorizations (extreme example: military style classif= ications), so that it might even be impossible to tell who can be contacted= .=C2=A0

    That's also why I was suggesting asser= tions could go beyond authentication events, and include cryptographic asse= rtions for authorization purposes. Maybe we can even imagine a risk based a= pproach, as in some cases we won't know for sure.=C2=A0

    <= /div>
    The difficulty will be to be sufficiently generic but simple enou= gh. Maybe we can rule out some cases. Maybe remote async contacts are out o= f scope,=C2=A0because we only want instantaneous authorizations. Most of th= ose cases are way beyond what OAuth2 does. I don't know. But what's= certain is that the WG should decide what support for cases where end-user= !=3D RO it intends to provide. My discussion was just a very small Chester= ston's Fence contribution, even if that seems to have surprised.
    <= div>
    Fabien


    On Wed, Mar 10, 2021 at 8:18 PM Justin Richer <jricher@m= it.edu> wrote:
    Hi Fabien,

    First, thanks for doing the heavy lift of writing this topic up. Of= these options, I would strongly prefer option (1). The difference between = assertions and identifiers is that an assertion is a fully packaged set of = attributes, one of which can be an identifier. They are, generally speaking= , cryptographically protected bundles. They=E2=80=99re designed to carry a = bunch of different information about a user and the authentication event in= a form that=E2=80=99s independently verifiable and auditable. SAML asserti= ons (XML document) and ID Tokens (signed JWTs) are the most common ones we = see today, but other formats exist and will keep being invented.=C2=A0

    An identifier is a different kind of creature. It is a= single statement that identifies the party in question in the context of t= he party doing the identification. It=E2=80=99s this full context that the = receiver of the identifier needs to interpret it in. When using a federated= identity protocol, each RP is going to have :some: kind of local user info= rmation store that they=E2=80=99re going to tie into, some field in a datab= ase they=E2=80=99ll key off of. It=E2=80=99s just never going to be the cas= e that all RPs will be able to use server-provided opaque identifiers for a= ll cases. Account recovery and binding is one such use case where a user-fa= cing identifier like an email address makes a LOT of sense, for one small e= xample. This is an array in the request and response precisely because a us= er could be known by several different identifiers to a party, and an RP wi= ll have a better idea about what kinds of things it wants to correlate agai= nst, and it=E2=80=99s up to the AS to provide that mapping. I think that if= we don=E2=80=99t define a way to describe the format, the =E2=80=9Cas_id= =E2=80=9D field is going to get structure back-patched onto it like is bein= g proposed here:


    I=E2=80=99m personally not a fan of that approach as it m= ixes the data layering too much, and you end up making guesses about whethe= r a field is meaningful or a pointer. I think GNAP will be much better serv= ed by using a data structure for this from the start. DIDs should be anothe= r =E2=80=9Cformat=E2=80=9D of the subject identifier. I don=E2=80=99t think= GNAP should define this format, and I=E2=80=99ve dropped a note to the SEC= EVENT mailing list asking about adding DIDs to the subject identifiers draf= t before it gets published. DIDs are not assertions, even in the cases wher= e they point to fully functional DID documents with user information in the= m. (And for what it=E2=80=99s worth, I think the OIDC world should also use= the SECEVENT draft inside ID Tokens to solve the use case of the draft abo= ve).

    For the user !=3D RO cases, I think that pote= ntially having a way to signal those two items separately in the request an= d response could be useful. Right now all the user/subject stuff is about i= dentifying =E2=80=9Cthe user that=E2=80=99s currently here at the client in= stance=E2=80=9D, in a variety of forms that the client instance and AS can = negotiate. If the client or AS has some other notion about who the RO is an= d how that could be separate from the current user, we could provide a way = to signal that like you=E2=80=99re proposing below. In my mental model, the= re are going to be a lot of use cases where the =E2=80=9CRO=E2=80=9D isn=E2= =80=99t known to the client at all, but rather to the AS and is based on wh= at the client=E2=80=99s asking for. So I could identify the current user an= d ask for a specific medical record, and the AS realizes it has to go bug a= particular doctor to approve things directly. This is instead of interacti= ng with the current user and failing in an awkward way when the current use= r doesn=E2=80=99t have the rights to do things, but someone else would. But= we=E2=80=99d want the system to be able to detect if the current user is t= he doctor, so we can just interact with them directly. Does that all track?=

    =C2=A0=E2=80=94 Justin

    On Mar 10, 2021, at 4:10 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    Hello,

    Notice the question mark in the title. = Not to be considered as an editor's comment.
    This thread inte= nds to provide a detailed comment on the interesting=C2=A0feedback by Krist= ina: "I would catch up on the thread to understand why DIDs are though= t to be treated as assertions".
    In the chat, I answered: &qu= ot;Happy to get the discussion on DIDs. Actually, could be either or, depen= ding on what we intend to do." Let me expand a bit on that, to make it= understandable (didn't have the time during the meeting, unfortunately= ).

    This relates to the items described on slides 2= 0 and 34, which I'll explain further. I'll highlight as transparent= ly as possible what I think would be the benefits and downsides of each. Bo= th are probably viable options, but they correspond to different scopes and= objectives. I'll spend a bit more time on option 2, since it is a diff= erent approach compared to the current draft.

    1. The first possi= bility is to use SECEVENT throughout.=C2=A0
    In that case, DID= s should be a part of sub_ids (in the core or in the extension registry, de= pending on what Annabelle's WG decides). More generally, the WG would h= ave to decide which additional sub_ids it needs (as per Yaron's comment= ).

    That's obviously the closest to what is des= cribed in draft-04. It allows a communication of subject information betwee= n the client and the AS, by using global identifiers (mail, phone, etc.), o= r using a local opaque reference=C2=A0- i.e. governed by the AS (that's= probably what we would=C2=A0put in the examples, unless someone has a bett= er idea - cf issues #16 and #42).=C2=A0

    Assertions= relate for instance to the proof of presence of the RO. The current draft-= 04 therefore plans for id_tokens and saml2, maybe there could be other need= s later (extension registry).

    - Benefits: identifi= ers are a key component of GNAP, which makes integration easier. Possibly o= ne could choose to use DIDs throughout.
    - Downsides: email/phone = identifiers will probably be used throughout by most devs (since that's= correlation information they=C2=A0have in their user DB). Which means we s= hould limit what assertions contain, to avoid doing links between weak glob= al identifiers and hopefully stronger assertions. That's not really a p= roblem if it's limited to authentication events mostly (in that perspec= tive, samlv2 could make sense in the core). An assertion is probably a sing= le value then (not an array).=C2=A0 =C2=A0

    Op= tion 1 can be summarized as:=C2=A0

    "subject": {
    =C2=A0=C2=A0=C2=A0= "sub_ids": { }, // request and respons= e (SECEVENT -> including DID possibly)=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=C2=A0=C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0"assertions&quo= t;: [ ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request an= d response (id_token or samlv2)
    }
    ("hints" do= not exist currently, but are partially covered separately via "reques= t.user" / the relevance of "principal", discussed in the sli= de, is a question mark too - which is a different discussion on end-user != =3D RO).


    2. An alternate poss= ibility is to use SECEVENT only as input/hint
    In that case, D= IDs should be a part of assertions (which have a different meaning compared= to option 1).

    The AS only returns an local opaque= reference as_ref (while in option 1, it was only one of many possibilities= ). Its only job is to help the client differentiate the response subject. T= he AS policy might further define the scope of that reference, as suggested= in=C2=A0https://github.com/= ietf-wg-gnap/gnap-core-protocol/issues/210, although I personally=C2=A0= viewed that by default as=C2=A0(2) "as_id" an identifier locally = unique to that AS for all the RSs.

    SECEVENTS are s= till useful as an input, that's what I presented in request.hints.self.= sub_ids (but it's the responsibility=C2=A0of the AS to match it with it= s own reference system - from instance from the email to AS's local rec= ord XUT2MFM1XBIKJKSDU8Q).=C2=A0Note: since the slides, a new draft-ietf-sec= event-subject-identifiers-07 has been published. Notably this includes an o= paque identifier, which the client can use to pass the as_ref hint to the A= S. Thus we wouldn't need any further addition to SECEVENT,=C2=A0althoug= h hints would benefit from further additions (like DIDs for instance). Noti= ce also that subject_types_supported becomes less important, because in the= worst case scenario, it's simply=C2=A0a hint that wouldn't be unde= rstood and therefore taken into account by the AS.

    The assertions array has a more important role than in option 1 (with the = explicit aim of separating between client hints and validated info asserted= by the AS). It serves as a generic/extendible mapping structure, e.g. &quo= t;the AS asserts that opaque reference=C2=A0XUT2MFM1XBIKJKSDU8Q=C2=A0is match= ing with these (more or less verifiable) statements." The name asserti= on therefore corresponds to the responsibility=C2=A0of the AS in delivering= those statements (cf should/must, issue #49). Some of these statements rel= ate to identity or auth events (ex: DID, id_token), some might directly be = useful for authorization decisions (like ZKP example in the parental contro= l example). Possibly some of these validated assertions could be reused in = next interactions.

    Another question that popped-up= is the scope of sub_ids. Should they be about the same user? (I think so).= In the case of remote ROs especially, it might be important that DID be co= nsidered as an assertion=C2=A0(about someone else's) and not as sub_ids= , because the AS needs to be careful about who the client wants to reach (a= void spam, etc.). This is consistent with the rest of discussion on what to= do when end-user !=3D RO, although using DIDComm might seem a bit early (t= he paint is very fresh).=C2=A0

    Option 2 was summar= ized as:=C2=A0

    // (suggestion only, not as an editor)
    "= subject": {
    =C2=A0=C2=A0=C2=A0"as_ref": { <= span style=3D"font-family:"Courier New";color:rgb(51,51,51);backg= round-color:rgb(247,247,247);font-variant-numeric:normal;font-variant-east-= asian:normal;vertical-align:baseline;white-space:pre-wrap"> // response only (= wouldn=E2=80=99t require SECEVENT)
    =E2=80=9Cas= =E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D,
    =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D=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=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"assertions": [ ], =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request and response (id_token/jwkthumb/= DID/VC/etc. -> whatever info can be validated by the AS)
    =C2=A0=C2=A0=C2=A0"hints": { =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // requ= est only (optional)
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"sel= f": { // replaces request.user (support SECEVENT here)
    =C2=A0=C2=A0=C2=A0=E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including o= paque in draft-07 - that could contain the ref)
    = =C2=A0=C2=A0=C2=A0=E2=80=9Cassertions=E2=80=9D: [ ] // see examp= les: VC on DOB or ZKP on age (wider scope, possibly through extensions)
    },=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=C2=A0=C2=A0=C2=A0
    = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"principal": { // new proposal presented at IETF110 (just an idea)
    = =C2=A0 =E2=80=9Cautomated=E2=80=9D: t= rue, // ru= le engine =
    =C2=A0 =E2=80=9Cas= ync=E2=80=9D: { } // remote ROs
    }=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=C2=A0=C2=A0}
    }

    - Benefits: as_ref is self support= ing (no strong coupling with SECEVENT), but can still take SECEVENT as an i= nput hint for the AS. It avoids the risk of making an official association = between a weak global identifier (e.g. email, used elsewhere) and hopefully= stronger local assertions. GNAP would be fully agnostic to whatever identi= ty system is used, only facilitating interoperability through assertions (s= econd only in importance=C2=A0compared to the AS opaque reference). Some as= sertions (possibly extensions) could also be useful for the AS decision (e.= g. VC or ZKP).
    - Downsides: opaqueness of as_ref is a feature, no= t a bug. The opaque reference is fully managed by the AS, therefore not inh= erently portable (cf portability discussions in OIDC currently). There'= s no explicit binding to an official identity, only a contextual mapping to= AS validated assertions. It makes it more difficult to match the identifie= rs from one AS to another or to correlate with the client user DB (still po= ssible via assertions, if the AS allows it). Assertions are much more gener= ic (possibly via extensions), but might require a more advanced mechanism= =C2=A0to request/response only the most relevant information (which makes t= he AS policy critical here).

    I hope that clarifies= the=C2=A0reasoning for both options. Again I'm not saying option 2 is = better, just saying the trade-offs are different (+ knowing that we need to= keep it simple).
    - option 1 puts more in sub_ids and less in ass= ertions
    - option 2 puts less in the reference and more in asserti= ons=C2=A0
    All of this is open to discussion. More generally speak= ing, on every part in orange and question mark (?) I would love your ideas = and criticisms. What I intended as an editor is only to highlight where the= WG has important choices to make, before we can make the related PRs.

    A further side comment: IETF EAT RATS was suggested fo= r assertions, but relates more to the client attestations. It was added as = a comment in=C2=A0https://git= hub.com/ietf-wg-gnap/gnap-core-protocol/issues/44, which is a distinct = topic we'll work on.

    Fabien (editor's hat = off)

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

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

    This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.
    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --000000000000c2a41705bdb1fdbd-- From nobody Tue Mar 16 19:35:14 2021 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 E0E043A179A for ; Tue, 16 Mar 2021 19:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 PQuCNYse-Kov for ; Tue, 16 Mar 2021 19:35:07 -0700 (PDT) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0: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 0B5D43A1799 for ; Tue, 16 Mar 2021 19:35:06 -0700 (PDT) Received: by mail-il1-x12e.google.com with SMTP id t6so93244ilp.11 for ; Tue, 16 Mar 2021 19:35: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=GEGq8u3wmRgYVjzUEVjNVyjkent6/K3c5j5YxDuCylU=; b=YculYAVsFIWlJzsYSIvNiOLrvdKty3BnPa8szw0LPYCasPaLT5EfFXApgLFYXbihpV wSkcqhJ0fkaZIE4pJneG7p9/33YkEahKbEPVUr2rMy8z3D8VLIARvdMi1KjVvbcYDolq /A7IQnhJUO1qrWySMFOzvbiHQ+p8ehFLyjpkGlqRPwQT199xBC0zf8tFh7qEAmoXw70n brFybuQ1TdOn3/KzSeDPNHh0uM+YV++GXB/lb4EV698KpuJN6tyshVtobllxWKO8UPaC fcH42tDMYoTNNeTlOS9mcgp5CkZVWcFB7G0VdhFCT5aPd45Pp7MjjgjF6MM6MVA71hcS oXUg== 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=GEGq8u3wmRgYVjzUEVjNVyjkent6/K3c5j5YxDuCylU=; b=hNKc/absEM3DA0stJKdirjDcfdH3Wyr61dSeCJCGY/2fnlu4ZI1QwGQgWfqFt6L7xx s6FaB6od1TZ+JBF/lkGDDkJzCSBcp7WCYZQjszVlrGILDfzWunY4sNDqooiOCK4FkbEZ ljW5o3s+uZduUxEup3C8qvEISxOHcvpnvgZ4zGboZyG0YyuN+4elgtCo2fi1+vRfMm1b SLs5aZp/CuFRIcNWuFecdfvYRQ3/8qHb7VIOoFdnwTtKPhCRgkD7KrHGG7culHafTPV6 kPgTuVyYv83sNdsxokMq4B3JLkC0xyNezLGL12u17wJzYf5UHA5T2A/ob4nCyYu1mntH VDlg== X-Gm-Message-State: AOAM530sE7AlX/E3V56Nv+WwDTDD5fVVHaYOsCfnVHlSIDEHJxzMfCTg xQnosY2C6YOUaD1YaDt03DD4aMRwkEdEb3CuSfM= X-Google-Smtp-Source: ABdhPJw/f7I0DuHlIqR5VbTrzqNDqapQhOe21eyVachGHklpwZERAC+mssZ3tUJA2vKqB2YD/qwxhoVDEY0Iur+vVqE= X-Received: by 2002:a92:d84f:: with SMTP id h15mr6226185ilq.178.1615948505278; Tue, 16 Mar 2021 19:35:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Wed, 17 Mar 2021 03:34:50 +0100 Message-ID: To: Adrian Gropper Cc: Tobias Looker , GNAP Mailing List , Justin Richer Content-Type: multipart/alternative; boundary="000000000000a1efac05bdb254f3" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 02:35:12 -0000 --000000000000a1efac05bdb254f3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Adrian, As the name suggests, it's an identifier for the subject (and so, hypothetically, a DID to identify the subject). The text indeed concerns the subject as the RO, as it is known to the AS. But it's easy to make shortcuts, because often we end-up dealing with is user =3D end-user =3D RO =3D subject. Fabien Le mer. 17 mars 2021 =C3=A0 03:10, Adrian Gropper = a =C3=A9crit : > I'm late to this conversation and confused by Tobias' use of End-User (hi= s > caps) and subject. Are we talking about a DID for the subject, the > end-user, or both? > > To be clear, in my mind, the subject is in control of policies and > capabilities at the GNAP AS. The end-user is in control of a client or us= er > agent and a request to the AS. The end-user and client may or may not hav= e > any prior relationship with the AS. > > Adrian > > On Tue, Mar 16, 2021 at 10:00 PM Fabien Imbault > wrote: > >> Hi Tobias, >> >> Not yet (none of the current sub_ids require additional parameters) but >> if DIDs do get added to subject identifiers, then it's certainly somethi= ng >> we would have to support. >> >> There's already a very basic version of that, but only to chose the main >> type (now called "format" in latest draft 07 of SECEVENT), with >> subject_types_supported in the discovery. >> >> Thanks for the heads up, it's worth creating an issue or putting a note >> in some existing issue to not forget looking into that. >> >> Cheers >> Fabien >> >> >> Le mer. 17 mars 2021 =C3=A0 01:01, Tobias Looker >> a =C3=A9crit : >> >>> Hi, >>> >>> This is probably out of scope for the current conversation but has any >>> thought been had on how the client instance could communicate additiona= l >>> options around what subject identifier types it supports for cases wher= e >>> the client instance will perhaps be required to conduct additional >>> processing on the artifacts returned by the AS? As an example if the AS >>> chose to identify the subject (End-User) using a DID and wanted to incl= ude >>> an additional cryptographic assertion that showed it controls keys >>> appropriately associated to the DID, then the client may have wanted to >>> communicate some information up front in their request to ensure they c= an >>> perform this additional processing, such as the signature suites it >>> supports and in the context of DIDs potentially which DID methods it is >>> capable of resolving? >>> >>> Thanks, >>> [image: Mattr website] >>> *Tobias Looker* >>> Mattr >>> +64 (0) 27 378 0461 >>> tobias.looker@mattr.global >>> [image: Mattr website] [image: Mattr on LinkedIn= ] >>> [image: Mattr on Twitter= ] >>> [image: Mattr on Github] >>> >>> This communication, including any attachments, is confidential. If you >>> are not the intended recipient, you should not read it - please contact= me >>> immediately, destroy it, and do not copy or use any part of this >>> communication or disclose anything about it. Thank you. Please note tha= t >>> this communication does not designate an information system for the >>> purposes of the Electronic Transactions Act 2002. >>> >>> >>> On Sat, Mar 13, 2021 at 9:26 PM Fabien Imbault >>> wrote: >>> >>>> Hi Justin, >>>> >>>> A last word on end-user! =3DRO (again just as food for thought). >>>> >>>> As soon as hints.automated is set to true, it takes priority over >>>> async, which means it's the same model as the one you describe : the A= S has >>>> precedence over any other remote contact. >>>> >>>> So that confirms the global view that the AS is the one with the >>>> authority, and that it might know more than the client. >>>> >>>> Cheers >>>> Fabien >>>> >>>> Le jeu. 11 mars 2021 =C3=A0 11:44, Fabien Imbault >>>> a =C3=A9crit : >>>> >>>>> Hi Justin, >>>>> >>>>> I think that's interesting: >>>>> "For the user !=3D RO cases, I think that potentially having a way to >>>>> signal those two items separately in the request and response could b= e >>>>> useful. Right now all the user/subject stuff is about identifying =E2= =80=9Cthe user >>>>> that=E2=80=99s currently here at the client instance=E2=80=9D, in a v= ariety of forms that >>>>> the client instance and AS can negotiate. If the client or AS has som= e >>>>> other notion about who the RO is and how that could be separate from = the >>>>> current user, we could provide a way to signal that like you=E2=80=99= re proposing >>>>> below. In my mental model, there are going to be a lot of use cases w= here >>>>> the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the client at all, bu= t rather to the AS and is >>>>> based on what the client=E2=80=99s asking for. So I could identify th= e current user >>>>> and ask for a specific medical record, and the AS realizes it has to = go bug >>>>> a particular doctor to approve things directly. This is instead of >>>>> interacting with the current user and failing in an awkward way when = the >>>>> current user doesn=E2=80=99t have the rights to do things, but someon= e else would. >>>>> But we=E2=80=99d want the system to be able to detect if the current = user is the >>>>> doctor, so we can just interact with them directly. Does that all tra= ck?" >>>>> >>>>> I agree with the general idea. In the end, that's the AS's >>>>> responsibility (and also a big part of its value as a policy engine). >>>>> >>>>> Even in the cases - as I suggested - where the client would be able t= o >>>>> signal what it knows (or thinks it knows) about the subject, the AS s= till >>>>> needs to validate what it can. The client could be an attacker lying = to the >>>>> AS. Or there could be an unintended bug. >>>>> >>>>> The client still seems like a straightforward source to gather >>>>> optional/declarative hints. Which is what request.user is already doi= ng in >>>>> spirit. In many cases, the AS should go a step further. Validate >>>>> cryptographic statements from a more reputable issuer, whatever helps= . >>>>> >>>>> Contacts might be one of the possibilities. I'm not suggesting >>>>> interact/fail scenarii at all, which I see as anti-ergonomic (composa= bility >>>>> with timeouts and fallback is the answer to that). The failure I was >>>>> considering is only for async calls explicitly requested by the clien= t >>>>> (which is considered in sequence 1.4.3, and not coming from me), ther= e's >>>>> obviously no way to ensure a remote RO would actually respond when th= e >>>>> client expects it. If that sequence is considered, realistic failure = modes >>>>> should be anticipated and dealt with internally (just like any distri= buted >>>>> program would do), is all I'm saying. And so from the outside, there'= s no >>>>> interact/fail. >>>>> That's the same as in real life: when booking a business trip, an >>>>> employee could either follow the generic rule (2nd class train ticket= ) or >>>>> reach out to his manager, explaining that it's a long trip and that 1= st >>>>> class would be better. The employee knows the manager might not insta= ntly >>>>> respond, and knows that the absence of an answer means he'll have to = go for >>>>> the 2nd class. >>>>> >>>>> There will be cases when the client doesn't know the RO. I'm not sure >>>>> if that's a majority of cases, but it will definitely happen. It coul= d >>>>> happen when you interact with an organization or a team and have no i= dea >>>>> who's responsible or what delegations are in place (some of those cas= es >>>>> have been described by Adrian for instance). >>>>> There could also be cases where the ownership could be distributed (a= n >>>>> example was provided when considering remote ROs). Again in real life= , it's >>>>> not unusual for a decision to fallback on a deputy when the main deci= sion >>>>> maker is unavailable. Or there could be an open governance even, but = maybe >>>>> that's one step too far. >>>>> >>>>> Of course, if the AS has internal knowledge or other ways to get the >>>>> information it should use it. Remains to be seen how we can specify t= hat >>>>> (cf issue #49 on should/must). The example with doctor/patient is fin= e if >>>>> hardcoded, but it becomes a problem when we fail to understand the re= al >>>>> relationships in environments of various sensitive nature. How the AS >>>>> identifies that a specific record requires approval from Doctor Bob m= ight >>>>> be context dependent (sometimes it could be a nurse, a team of doctor= s, >>>>> another medical organization, etc.). Maybe you could have various lev= els of >>>>> authorizations (extreme example: military style classifications), so = that >>>>> it might even be impossible to tell who can be contacted. >>>>> >>>>> That's also why I was suggesting assertions could go beyond >>>>> authentication events, and include cryptographic assertions for >>>>> authorization purposes. Maybe we can even imagine a risk based approa= ch, as >>>>> in some cases we won't know for sure. >>>>> >>>>> The difficulty will be to be sufficiently generic but simple enough. >>>>> Maybe we can rule out some cases. Maybe remote async contacts are out= of >>>>> scope, because we only want instantaneous authorizations. Most of tho= se >>>>> cases are way beyond what OAuth2 does. I don't know. But what's certa= in is >>>>> that the WG should decide what support for cases where end-user !=3D = RO it >>>>> intends to provide. My discussion was just a very small Chesterston's= Fence >>>>> contribution, even if that seems to have surprised. >>>>> >>>>> Fabien >>>>> >>>>> >>>>> On Wed, Mar 10, 2021 at 8:18 PM Justin Richer wrote= : >>>>> >>>>>> Hi Fabien, >>>>>> >>>>>> First, thanks for doing the heavy lift of writing this topic up. Of >>>>>> these options, I would strongly prefer option (1). The difference be= tween >>>>>> assertions and identifiers is that an assertion is a fully packaged = set of >>>>>> attributes, one of which can be an identifier. They are, generally >>>>>> speaking, cryptographically protected bundles. They=E2=80=99re desig= ned to carry a >>>>>> bunch of different information about a user and the authentication e= vent in >>>>>> a form that=E2=80=99s independently verifiable and auditable. SAML a= ssertions (XML >>>>>> document) and ID Tokens (signed JWTs) are the most common ones we se= e >>>>>> today, but other formats exist and will keep being invented. >>>>>> >>>>>> An identifier is a different kind of creature. It is a single >>>>>> statement that identifies the party in question in the context of th= e party >>>>>> doing the identification. It=E2=80=99s this full context that the re= ceiver of the >>>>>> identifier needs to interpret it in. When using a federated identity >>>>>> protocol, each RP is going to have :some: kind of local user informa= tion >>>>>> store that they=E2=80=99re going to tie into, some field in a databa= se they=E2=80=99ll key >>>>>> off of. It=E2=80=99s just never going to be the case that all RPs wi= ll be able to >>>>>> use server-provided opaque identifiers for all cases. Account recove= ry and >>>>>> binding is one such use case where a user-facing identifier like an = email >>>>>> address makes a LOT of sense, for one small example. This is an arra= y in >>>>>> the request and response precisely because a user could be known by = several >>>>>> different identifiers to a party, and an RP will have a better idea = about >>>>>> what kinds of things it wants to correlate against, and it=E2=80=99s= up to the AS >>>>>> to provide that mapping. I think that if we don=E2=80=99t define a w= ay to describe >>>>>> the format, the =E2=80=9Cas_id=E2=80=9D field is going to get struct= ure back-patched onto >>>>>> it like is being proposed here: >>>>>> >>>>>> https://mattrglobal.github.io/oidc-portable-identities/ >>>>>> >>>>>> I=E2=80=99m personally not a fan of that approach as it mixes the da= ta >>>>>> layering too much, and you end up making guesses about whether a fie= ld is >>>>>> meaningful or a pointer. I think GNAP will be much better served by = using a >>>>>> data structure for this from the start. DIDs should be another =E2= =80=9Cformat=E2=80=9D of >>>>>> the subject identifier. I don=E2=80=99t think GNAP should define thi= s format, and >>>>>> I=E2=80=99ve dropped a note to the SECEVENT mailing list asking abou= t adding DIDs >>>>>> to the subject identifiers draft before it gets published. DIDs are = not >>>>>> assertions, even in the cases where they point to fully functional D= ID >>>>>> documents with user information in them. (And for what it=E2=80=99s = worth, I think >>>>>> the OIDC world should also use the SECEVENT draft inside ID Tokens t= o solve >>>>>> the use case of the draft above). >>>>>> >>>>>> For the user !=3D RO cases, I think that potentially having a way to >>>>>> signal those two items separately in the request and response could = be >>>>>> useful. Right now all the user/subject stuff is about identifying = =E2=80=9Cthe user >>>>>> that=E2=80=99s currently here at the client instance=E2=80=9D, in a = variety of forms that >>>>>> the client instance and AS can negotiate. If the client or AS has so= me >>>>>> other notion about who the RO is and how that could be separate from= the >>>>>> current user, we could provide a way to signal that like you=E2=80= =99re proposing >>>>>> below. In my mental model, there are going to be a lot of use cases = where >>>>>> the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the client at all, b= ut rather to the AS and is >>>>>> based on what the client=E2=80=99s asking for. So I could identify t= he current user >>>>>> and ask for a specific medical record, and the AS realizes it has to= go bug >>>>>> a particular doctor to approve things directly. This is instead of >>>>>> interacting with the current user and failing in an awkward way when= the >>>>>> current user doesn=E2=80=99t have the rights to do things, but someo= ne else would. >>>>>> But we=E2=80=99d want the system to be able to detect if the current= user is the >>>>>> doctor, so we can just interact with them directly. Does that all tr= ack? >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> On Mar 10, 2021, at 4:10 AM, Fabien Imbault >>>>>> wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Notice the question mark in the title. Not to be considered as an >>>>>> editor's comment. >>>>>> This thread intends to provide a detailed comment on the >>>>>> interesting feedback by Kristina: "I would catch up on the thread to >>>>>> understand why DIDs are thought to be treated as assertions". >>>>>> In the chat, I answered: "Happy to get the discussion on DIDs. >>>>>> Actually, could be either or, depending on what we intend to do." Le= t me >>>>>> expand a bit on that, to make it understandable (didn't have the tim= e >>>>>> during the meeting, unfortunately). >>>>>> >>>>>> This relates to the items described on slides 20 and 34, which I'll >>>>>> explain further. I'll highlight as transparently as possible what I = think >>>>>> would be the benefits and downsides of each. Both are probably viabl= e >>>>>> options, but they correspond to different scopes and objectives. I'l= l spend >>>>>> a bit more time on option 2, since it is a different approach compar= ed to >>>>>> the current draft. >>>>>> >>>>>> *1. The first possibility is to use SECEVENT throughout. * >>>>>> In that case, DIDs should be a part of sub_ids (in the core or in th= e >>>>>> extension registry, depending on what Annabelle's WG decides). More >>>>>> generally, the WG would have to decide which additional sub_ids it n= eeds >>>>>> (as per Yaron's comment). >>>>>> >>>>>> That's obviously the closest to what is described in draft-04. It >>>>>> allows a communication of subject information between the client and= the >>>>>> AS, by using global identifiers (mail, phone, etc.), or using a loca= l >>>>>> opaque reference - i.e. governed by the AS (that's probably what we >>>>>> would put in the examples, unless someone has a better idea - cf iss= ues #16 >>>>>> and #42). >>>>>> >>>>>> Assertions relate for instance to the proof of presence of the RO. >>>>>> The current draft-04 therefore plans for id_tokens and saml2, maybe = there >>>>>> could be other needs later (extension registry). >>>>>> >>>>>> - Benefits: identifiers are a key component of GNAP, which makes >>>>>> integration easier. Possibly one could choose to use DIDs throughout= . >>>>>> - Downsides: email/phone identifiers will probably be used throughou= t >>>>>> by most devs (since that's correlation information they have in thei= r user >>>>>> DB). Which means we should limit what assertions contain, to avoid d= oing >>>>>> links between weak global identifiers and hopefully stronger asserti= ons. >>>>>> That's not really a problem if it's limited to authentication events= mostly >>>>>> (in that perspective, samlv2 could make sense in the core). An asser= tion is >>>>>> probably a single value then (not an array). >>>>>> >>>>>> Option 1 can be summarized as: >>>>>> >>>>>> "subject": { >>>>>> "sub_ids": { }, // request and response (SECEVENT -> including >>>>>> DID possibly) >>>>>> "assertions": [ ], // request and response (id_toke= n >>>>>> or samlv2) >>>>>> } >>>>>> ("hints" do not exist currently, but are partially covered separatel= y >>>>>> via "request.user" / the relevance of "principal", discussed in the = slide, >>>>>> is a question mark too - which is a different discussion on end-user= !=3D RO). >>>>>> >>>>>> >>>>>> *2. An alternate possibility is to use SECEVENT only as input/hint* >>>>>> In that case, DIDs should be a part of assertions (which have a >>>>>> different meaning compared to option 1). >>>>>> >>>>>> The AS only returns an local opaque reference as_ref (while in optio= n >>>>>> 1, it was only one of many possibilities). Its only job is to help t= he >>>>>> client differentiate the response subject. The AS policy might furth= er >>>>>> define the scope of that reference, as suggested in >>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210, >>>>>> although I personally viewed that by default as (2) "as_id" an ident= ifier >>>>>> locally unique to that AS for all the RSs. >>>>>> >>>>>> SECEVENTS are still useful as an input, that's what I presented in >>>>>> request.hints.self.sub_ids (but it's the responsibility of the AS to= match >>>>>> it with its own reference system - from instance from the email to A= S's >>>>>> local record XUT2MFM1XBIKJKSDU8Q). Note: since the slides, a new >>>>>> draft-ietf-secevent-subject-identifiers-07 has been published. Notab= ly this >>>>>> includes an opaque identifier, which the client can use to pass the = as_ref >>>>>> hint to the AS. Thus we wouldn't need any further addition to >>>>>> SECEVENT, although hints would benefit from further additions (like = DIDs >>>>>> for instance). Notice also that subject_types_supported becomes less >>>>>> important, because in the worst case scenario, it's simply a hint th= at >>>>>> wouldn't be understood and therefore taken into account by the AS. >>>>>> >>>>>> The assertions array has a more important role than in option 1 (wit= h >>>>>> the explicit aim of separating between client hints and validated in= fo >>>>>> asserted by the AS). It serves as a generic/extendible mapping struc= ture, >>>>>> e.g. "the AS asserts that opaque reference XUT2MFM1XBIKJKSDU8Q is >>>>>> matching with these (more or less verifiable) statements." The name >>>>>> assertion therefore corresponds to the responsibility of the AS in >>>>>> delivering those statements (cf should/must, issue #49). Some of the= se >>>>>> statements relate to identity or auth events (ex: DID, id_token), so= me >>>>>> might directly be useful for authorization decisions (like ZKP examp= le in >>>>>> the parental control example). Possibly some of these validated asse= rtions >>>>>> could be reused in next interactions. >>>>>> >>>>>> Another question that popped-up is the scope of sub_ids. Should they >>>>>> be about the same user? (I think so). In the case of remote ROs espe= cially, >>>>>> it might be important that DID be considered as an assertion (about = someone >>>>>> else's) and not as sub_ids, because the AS needs to be careful about= who >>>>>> the client wants to reach (avoid spam, etc.). This is consistent wit= h the >>>>>> rest of discussion on what to do when end-user !=3D RO, although usi= ng >>>>>> DIDComm might seem a bit early (the paint is very fresh). >>>>>> >>>>>> Option 2 was summarized as: >>>>>> >>>>>> // (suggestion only, not as an editor) >>>>>> "subject": { >>>>>> "as_ref": { // response only (wouldn=E2=80=99t require SECEVENT) >>>>>> =E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D, >>>>>> =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D >>>>>> }, >>>>>> "assertions": [ ], // request and response >>>>>> (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validated by = the AS) >>>>>> >>>>>> "hints": { // request only (optional) >>>>>> "self": { // replaces request.user (support SECEVENT here) >>>>>> =E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque in = draft-07 - that >>>>>> could contain the ref) >>>>>> =E2=80=9Cassertions=E2=80=9D: [ ] // see examples: VC on DOB or Z= KP on age (wider >>>>>> scope, possibly through extensions) >>>>>> }, >>>>>> "principal": { // new proposal presented at IETF110 (just an >>>>>> idea) >>>>>> =E2=80=9Cautomated=E2=80=9D: true, // rule engine >>>>>> =E2=80=9Casync=E2=80=9D: { } // remote ROs >>>>>> } >>>>>> } >>>>>> } >>>>>> >>>>>> - Benefits: as_ref is self supporting (no strong coupling with >>>>>> SECEVENT), but can still take SECEVENT as an input hint for the AS. = It >>>>>> avoids the risk of making an official association between a weak glo= bal >>>>>> identifier (e.g. email, used elsewhere) and hopefully stronger local >>>>>> assertions. GNAP would be fully agnostic to whatever identity system= is >>>>>> used, only facilitating interoperability through assertions (second = only in >>>>>> importance compared to the AS opaque reference). Some assertions (po= ssibly >>>>>> extensions) could also be useful for the AS decision (e.g. VC or ZKP= ). >>>>>> - Downsides: opaqueness of as_ref is a feature, not a bug. The opaqu= e >>>>>> reference is fully managed by the AS, therefore not inherently porta= ble (cf >>>>>> portability discussions in OIDC currently). There's no explicit bind= ing to >>>>>> an official identity, only a contextual mapping to AS validated asse= rtions. >>>>>> It makes it more difficult to match the identifiers from one AS to a= nother >>>>>> or to correlate with the client user DB (still possible via assertio= ns, if >>>>>> the AS allows it). Assertions are much more generic (possibly via >>>>>> extensions), but might require a more advanced mechanism to >>>>>> request/response only the most relevant information (which makes the= AS >>>>>> policy critical here). >>>>>> >>>>>> I hope that clarifies the reasoning for both options. Again I'm not >>>>>> saying option 2 is better, just saying the trade-offs are different = (+ >>>>>> knowing that we need to keep it simple). >>>>>> - option 1 puts more in sub_ids and less in assertions >>>>>> - option 2 puts less in the reference and more in assertions >>>>>> All of this is open to discussion. More generally speaking, on every >>>>>> part in orange and question mark (?) I would love your ideas and >>>>>> criticisms. What I intended as an editor is only to highlight where = the WG >>>>>> has important choices to make, before we can make the related PRs. >>>>>> >>>>>> A further side comment: IETF EAT RATS was suggested for assertions, >>>>>> but relates more to the client attestations. It was added as a comme= nt in >>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, which >>>>>> is a distinct topic we'll work on. >>>>>> >>>>>> Fabien (editor's hat off) >>>>>> >>>>>> -- >>>>>> 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 >>>> >>> >>> This communication, including any attachments, is confidential. If you = are not the intended recipient, you should not read it - please contact me = immediately, destroy it, and do not copy or use any part of this communicat= ion or disclose anything about it. Thank you. Please note that this communi= cation does not designate an information system for the purposes of the Ele= ctronic Transactions Act 2002. >>> >>> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --000000000000a1efac05bdb254f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Adrian,

    A= s the name suggests, it's an identifier for the subject (and so, hypoth= etically, a DID to identify the subject). The text indeed concerns the subj= ect as the RO, as it is known to the AS.=C2=A0

    <= /div>
    But it's easy to make shortcuts, because often w= e end-up dealing with is user =3D end-user =3D RO =3D subject.=C2=A0
    <= div dir=3D"auto">
    Fabien=C2=A0

    Le me= r. 17 mars 2021 =C3=A0 03:10, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    I'm late to this conve= rsation and confused by Tobias' use of End-User (his caps)=C2=A0and sub= ject. Are we talking about a DID for the subject, the end-user, or both?
    To be clear, in my mind, the subject is in control=C2=A0of= policies and capabilities at the GNAP AS. The end-user is in control=C2=A0= of a client or user agent and a request to the AS. The end-user and client = may or may not have any prior relationship with the AS.

    = Adrian

    On Tue, Mar 16, 2021 at 10:00 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Tobias,

    Not yet (= none of the current sub_ids require additional parameters) but if DIDs do g= et added to subject identifiers, then it's certainly something we would= have to support.=C2=A0

    = There's already a very basic version of that, but only to chose the mai= n type (now called "format" in latest draft 07 of SECEVENT), with= subject_types_supported in the discovery.=C2=A0
    Thanks for the heads up, it's worth creating a= n issue or putting a note in some existing issue to not forget looking into= that.=C2=A0

    Cheers
    Fabien


    Le mer. 17 mars 2021 =C3=A0 01:01= , Tobias Looker <tobias.looker@mattr.global> a =C3=A9crit=C2=A0:
    <= /div>
    Hi,

    This is proba= bly out of scope for the current conversation but has any thought been had = on how the client instance could communicate additional options around what= subject identifier types it supports for cases where the client instance w= ill perhaps be required to conduct additional processing on the artifacts r= eturned by the AS? As an example if the AS chose to identify the subject (E= nd-User) using a DID and wanted to include an additional cryptographic asse= rtion that showed it controls keys appropriately associated to the DID, the= n the client may have wanted to communicate some information up front in th= eir request to ensure they can perform this additional processing, such as = the signature suites it supports and in the context of DIDs potentially whi= ch DID methods it is capable of resolving?

    Thanks,

    This communication, = including any attachments, is confidential. If you are not the intended rec= ipient, you should not read it - please contact me immediately, destroy it,= and do not copy or use any part of this communication or disclose anything= about it. Thank you. Please note that this communication does not designat= e an information system for the purposes of the Electronic Transactions Act= 2002.


    On Sat, Mar 13, 2021 at 9:26 = PM Fabien Imbault <fabien.imbault@gmail.com> wro= te:
    Hi Justin,=C2=A0
    =

    A last word on end-user! =3DR= O (again just as food for thought).=C2=A0

    =
    As soon as hints.automated is set to true, it takes prior= ity over async, which means it's the same model as the one you describe= : the AS has precedence over any other remote contact.=C2=A0

    So that confirms the global view that= the AS is the one with the authority, and that it might know more than the= client.=C2=A0

    Cheers
    Fabien=C2=A0

    Le jeu. 11 = mars 2021 =C3=A0 11:44, Fabien Imbault <fabien.imbault@= gmail.com> a =C3=A9crit=C2=A0:
    Hi Justin,

    I think that's interesting:
    "For the user !=3D RO cases, I think that potentially having a= way to signal those two items separately in the request and response could= be useful. Right now all the user/subject stuff is about identifying =E2= =80=9Cthe user that=E2=80=99s currently here at the client instance=E2=80= =9D, in a variety of forms that the client instance and AS can negotiate. I= f the client or AS has some other notion about who the RO is and how that c= ould be separate from the current user, we could provide a way to signal th= at like you=E2=80=99re proposing below. In my mental model, there are going= to be a lot of use cases where the =E2=80=9CRO=E2=80=9D isn=E2=80=99t know= n to the client at all, but rather to the AS and is based on what the clien= t=E2=80=99s asking for. So I could identify the current user and ask for a = specific medical record, and the AS realizes it has to go bug a particular = doctor to approve things directly. This is instead of interacting with the = current user and failing in an awkward way when the current user doesn=E2= =80=99t have the rights to do things, but someone else would. But we=E2=80= =99d want the system to be able to detect if the current user is the doctor= , so we can just interact with them directly. Does that all track?"

    I agree with the general idea. In the end, that'= s the AS's responsibility (and also a big part of its value as a policy= engine). =C2=A0

    Even in the cases - as I suggeste= d - where the client would be able to signal what it knows (or thinks it kn= ows) about the subject, the AS still needs to validate what it can. The cli= ent could be an attacker lying to the AS. Or there could be an unintended b= ug.=C2=A0

    The=C2=A0client still seems like a strai= ghtforward source to gather optional/declarative hints. Which is what reque= st.user is already doing in spirit. In many cases, the AS should go a step = further. Validate cryptographic statements from a more reputable issuer, wh= atever helps.

    Contacts might be one of the possibi= lities. I'm not suggesting interact/fail scenarii at all, which I see a= s anti-ergonomic (composability with timeouts and fallback is the answer to= that). The failure I was considering is only for async calls explicitly re= quested by the client (which is considered in sequence 1.4.3, and not comin= g from me), there's obviously no way to ensure a remote RO would actual= ly respond when the client expects it. If that sequence is considered, real= istic failure modes should be anticipated and dealt with internally (just l= ike any distributed program would do), is all I'm saying. And so from t= he outside, there's no interact/fail.=C2=A0=C2=A0
    That's = the same as in real life: when booking a business trip, an employee could e= ither follow the generic rule (2nd class train ticket) or reach out to his = manager, explaining that it's a long trip and that 1st class would be b= etter. The employee knows the manager might not instantly respond, and know= s that the absence of an answer means he'll have to go for the 2nd clas= s.=C2=A0

    There will be cases when the=C2=A0cli= ent doesn't know the=C2=A0RO. I'm not sure if that's a majority= of cases, but it will definitely happen. It could happen when you interact= with an organization or a team and have no idea who's responsible or w= hat delegations are in place (some of those cases have been described by Ad= rian for instance).=C2=A0
    There could also be cases where the own= ership could be distributed (an example was provided when considering remot= e ROs). Again in real life, it's not unusual for a decision to fallback= on a deputy when the main decision maker is unavailable. Or there could be= an open governance even, but maybe that's one step too far.
    =
    Of course, if the AS has internal knowledge or other ways to= get the information it should use it. Remains to be seen how we can specif= y that (cf issue #49 on should/must). The example with doctor/patient is fi= ne if hardcoded, but it becomes a problem when we fail to understand the re= al relationships in environments of various sensitive nature. How the AS id= entifies that a specific record requires approval from Doctor Bob might be = context dependent (sometimes it could be a nurse, a team of doctors, anothe= r medical organization, etc.). Maybe you could have various levels of autho= rizations (extreme example: military style classifications), so that it mig= ht even be impossible to tell who can be contacted.=C2=A0

    That's also why I was suggesting assertions could go beyond aut= hentication events, and include cryptographic assertions for authorization = purposes. Maybe we can even imagine a risk based approach, as in some cases= we won't know for sure.=C2=A0

    The difficulty = will be to be sufficiently generic but simple enough. Maybe we can rule out= some cases. Maybe remote async contacts are out of scope,=C2=A0because we = only want instantaneous authorizations. Most of those cases are way beyond = what OAuth2 does. I don't know. But what's certain is that the WG s= hould decide what support for cases where end-user !=3D RO it intends to pr= ovide. My discussion was just a very small Chesterston's Fence contribu= tion, even if that seems to have surprised.

    Fabien=


    On Wed, Mar 10, 2= 021 at 8:18 PM Justin Richer <jricher@mit.edu>= wrote:
    Hi Fabien,

    First,= thanks for doing the heavy lift of writing this topic up. Of these options= , I would strongly prefer option (1). The difference between assertions and= identifiers is that an assertion is a fully packaged set of attributes, on= e of which can be an identifier. They are, generally speaking, cryptographi= cally protected bundles. They=E2=80=99re designed to carry a bunch of diffe= rent information about a user and the authentication event in a form that= =E2=80=99s independently verifiable and auditable. SAML assertions (XML doc= ument) and ID Tokens (signed JWTs) are the most common ones we see today, b= ut other formats exist and will keep being invented.=C2=A0

    An identifier is a different kind of creature. It is a single stat= ement that identifies the party in question in the context of the party doi= ng the identification. It=E2=80=99s this full context that the receiver of = the identifier needs to interpret it in. When using a federated identity pr= otocol, each RP is going to have :some: kind of local user information stor= e that they=E2=80=99re going to tie into, some field in a database they=E2= =80=99ll key off of. It=E2=80=99s just never going to be the case that all = RPs will be able to use server-provided opaque identifiers for all cases. A= ccount recovery and binding is one such use case where a user-facing identi= fier like an email address makes a LOT of sense, for one small example. Thi= s is an array in the request and response precisely because a user could be= known by several different identifiers to a party, and an RP will have a b= etter idea about what kinds of things it wants to correlate against, and it= =E2=80=99s up to the AS to provide that mapping. I think that if we don=E2= =80=99t define a way to describe the format, the =E2=80=9Cas_id=E2=80=9D fi= eld is going to get structure back-patched onto it like is being proposed h= ere:


    I=E2=80=99m personally not a fan of that approach as it mi= xes the data layering too much, and you end up making guesses about whether= a field is meaningful or a pointer. I think GNAP will be much better serve= d by using a data structure for this from the start. DIDs should be another= =E2=80=9Cformat=E2=80=9D of the subject identifier. I don=E2=80=99t think = GNAP should define this format, and I=E2=80=99ve dropped a note to the SECE= VENT mailing list asking about adding DIDs to the subject identifiers draft= before it gets published. DIDs are not assertions, even in the cases where= they point to fully functional DID documents with user information in them= . (And for what it=E2=80=99s worth, I think the OIDC world should also use = the SECEVENT draft inside ID Tokens to solve the use case of the draft abov= e).

    For the user !=3D RO cases, I think that poten= tially having a way to signal those two items separately in the request and= response could be useful. Right now all the user/subject stuff is about id= entifying =E2=80=9Cthe user that=E2=80=99s currently here at the client ins= tance=E2=80=9D, in a variety of forms that the client instance and AS can n= egotiate. If the client or AS has some other notion about who the RO is and= how that could be separate from the current user, we could provide a way t= o signal that like you=E2=80=99re proposing below. In my mental model, ther= e are going to be a lot of use cases where the =E2=80=9CRO=E2=80=9D isn=E2= =80=99t known to the client at all, but rather to the AS and is based on wh= at the client=E2=80=99s asking for. So I could identify the current user an= d ask for a specific medical record, and the AS realizes it has to go bug a= particular doctor to approve things directly. This is instead of interacti= ng with the current user and failing in an awkward way when the current use= r doesn=E2=80=99t have the rights to do things, but someone else would. But= we=E2=80=99d want the system to be able to detect if the current user is t= he doctor, so we can just interact with them directly. Does that all track?=

    =C2=A0=E2=80=94 Justin

    On Mar 10, 2021, at 4:10 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    <= div>
    Hello,

    Notice the question mark in = the title. Not to be considered as an editor's comment.
    This = thread intends to provide a detailed comment on the interesting=C2=A0feedba= ck by Kristina: "I would catch up on the thread to understand why DIDs= are thought to be treated as assertions".
    In the chat, I an= swered: "Happy to get the discussion on DIDs. Actually, could be eithe= r or, depending on what we intend to do." Let me expand a bit on that,= to make it understandable (didn't have the time during the meeting, un= fortunately).

    This relates to the items described = on slides 20 and 34, which I'll explain further. I'll highlight as = transparently as possible what I think would be the benefits and downsides = of each. Both are probably viable options, but they correspond to different= scopes and objectives. I'll spend a bit more time on option 2, since i= t is a different approach compared to the current draft.

    1. The = first possibility is to use SECEVENT throughout.=C2=A0
    In tha= t case, DIDs should be a part of sub_ids (in the core or in the extension r= egistry, depending on what Annabelle's WG decides). More generally, the= WG would have to decide which additional sub_ids it needs (as per Yaron= 9;s comment).

    That's obviously the closest to = what is described in draft-04. It allows a communication of subject informa= tion between the client and the AS, by using global identifiers (mail, phon= e, etc.), or using a local opaque reference=C2=A0- i.e. governed by the AS = (that's probably what we would=C2=A0put in the examples, unless someone= has a better idea - cf issues #16 and #42).=C2=A0

    Assertions relate for instance to the proof of presence of the RO. The cur= rent draft-04 therefore plans for id_tokens and saml2, maybe there could be= other needs later (extension registry).

    - Benefit= s: identifiers are a key component of GNAP, which makes integration easier.= Possibly one could choose to use DIDs throughout.
    - Downsides: e= mail/phone identifiers will probably be used throughout by most devs (since= that's correlation information they=C2=A0have in their user DB). Which= means we should limit what assertions contain, to avoid doing links betwee= n weak global identifiers and hopefully stronger assertions. That's not= really a problem if it's limited to authentication events mostly (in t= hat perspective, samlv2 could make sense in the core). An assertion is prob= ably a single value then (not an array).=C2=A0 =C2=A0

    <= div>
    Option 1 can be summarized as:=C2=A0

    "subject"= : {
    =C2=A0=C2=A0=C2=A0"sub_ids": { }, // request and response (SECEVENT -> including DID possibly)<= /span>=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=C2=A0=C2=A0=C2=A0=C2=A0
    =C2= =A0=C2=A0=C2=A0"assertions": [ ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 // request and response (id_token or samlv2)
    = }
    ("hints" do not exist currently, but are partially co= vered separately via "request.user" / the relevance of "prin= cipal", discussed in the slide, is a question mark too - which is a di= fferent discussion on end-user !=3D RO).


    2. An alternate possibility is to use SECEVENT only as input/hi= nt
    In that case, DIDs should be a part of assertions (which h= ave a different meaning compared to option 1).

    The= AS only returns an local opaque reference as_ref (while in option 1, it wa= s only one of many possibilities). Its only job is to help the client diffe= rentiate the response subject. The AS policy might further define the scope= of that reference, as suggested in=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/= issues/210, although I personally=C2=A0viewed that by default as=C2=A0(= 2) "as_id" an identifier locally unique to that AS for all the RS= s.

    SECEVENTS are still useful as an input, that= 9;s what I presented in request.hints.self.sub_ids (but it's the respon= sibility=C2=A0of the AS to match it with its own reference system - from in= stance from the email to AS's local record XUT2MFM1XBIKJKSDU8Q).=C2=A0N= ote: since the slides, a new draft-ietf-secevent-subject-identifiers-07 has= been published. Notably this includes an opaque identifier, which the clie= nt can use to pass the as_ref hint to the AS. Thus we wouldn't need any= further addition to SECEVENT,=C2=A0although hints would benefit from furth= er additions (like DIDs for instance). Notice also that subject_types_suppo= rted becomes less important, because in the worst case scenario, it's s= imply=C2=A0a hint that wouldn't be understood and therefore taken into = account by the AS.

    The assertions array has a more= important role than in option 1 (with the explicit aim of separating betwe= en client hints and validated info asserted by the AS). It serves as a gene= ric/extendible mapping structure, e.g. "the AS asserts that opaque ref= erence=C2=A0XUT2MFM1XBIKJKSDU8Q=C2=A0is matching with these (more or less ver= ifiable) statements." The name assertion therefore corresponds to the = responsibility=C2=A0of the AS in delivering those statements (cf should/mus= t, issue #49). Some of these statements relate to identity or auth events (= ex: DID, id_token), some might directly be useful for authorization decisio= ns (like ZKP example in the parental control example). Possibly some of the= se validated assertions could be reused in next interactions.
    Another question that popped-up is the scope of sub_ids. Should= they be about the same user? (I think so). In the case of remote ROs espec= ially, it might be important that DID be considered as an assertion=C2=A0(a= bout someone else's) and not as sub_ids, because the AS needs to be car= eful about who the client wants to reach (avoid spam, etc.). This is consis= tent with the rest of discussion on what to do when end-user !=3D RO, altho= ugh using DIDComm might seem a bit early (the paint is very fresh).=C2=A0

    Option 2 was summarized as:=C2=A0

    // (suggestion only, not as an editor)
    "subject&quo= t;: {
    =C2=A0=C2=A0=C2=A0"as_ref": { // response only (wouldn= =E2=80=99t require SECEVENT)
    =E2=80=9Cas=E2=80= =9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D, =
    =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D=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=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"assertions": [ ], =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request and response (id_token/jwkth= umb/DID/VC/etc. -> whatever info can be validated by the AS)

    =C2=A0=C2=A0=C2=A0"hints": { =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /= / request only (optional)
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0&qu= ot;self": { // replaces request.user (support SECEVENT here)
    =C2=A0=C2=A0=C2=A0=E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (inclu= ding opaque in draft-07 - that could contain the ref)
    =C2=A0=C2=A0=C2=A0=E2=80=9Cassertions=E2=80=9D: [ ] // se= e examples: VC on DOB or ZKP on age (wider scope, possibly through extensio= ns)
    },=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=C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"principal": { // new proposal presented at IETF110 (just an idea)
    =C2=A0 =E2=80=9Cautomated=E2=80= =9D: true, // rule engine
    =C2=A0 =E2= =80=9Casync=E2=80=9D: { } // remote ROs
    }=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=C2=A0=C2=A0}<= /div>
    }

    - Benefits: as_ref is sel= f supporting (no strong coupling with SECEVENT), but can still take SECEVEN= T as an input hint for the AS. It avoids the risk of making an official ass= ociation between a weak global identifier (e.g. email, used elsewhere) and = hopefully stronger local assertions. GNAP would be fully agnostic to whatev= er identity system is used, only facilitating interoperability through asse= rtions (second only in importance=C2=A0compared to the AS opaque reference)= . Some assertions (possibly extensions) could also be useful for the AS dec= ision (e.g. VC or ZKP).
    - Downsides: opaqueness of as_ref is a fe= ature, not a bug. The opaque reference is fully managed by the AS, therefor= e not inherently portable (cf portability discussions in OIDC currently). T= here's no explicit binding to an official identity, only a contextual m= apping to AS validated assertions. It makes it more difficult to match the = identifiers from one AS to another or to correlate with the client user DB = (still possible via assertions, if the AS allows it). Assertions are much m= ore generic (possibly via extensions), but might require a more advanced me= chanism=C2=A0to request/response only the most relevant information (which = makes the AS policy critical here).

    I hope that cl= arifies the=C2=A0reasoning for both options. Again I'm not saying optio= n 2 is better, just saying the trade-offs are different (+ knowing that we = need to keep it simple).
    - option 1 puts more in sub_ids and less= in assertions
    - option 2 puts less in the reference and more in = assertions=C2=A0
    All of this is open to discussion. More generall= y speaking, on every part in orange and question mark (?) I would love your= ideas and criticisms. What I intended as an editor is only to highlight wh= ere the WG has important choices to make, before we can make the related PR= s.

    A further side comment: IETF EAT RATS was sugge= sted for assertions, but relates more to the client attestations. It was ad= ded as a comment in=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, wh= ich is a distinct topic we'll work on.

    Fabien = (editor's hat off)

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

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

    This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.
    --
    TXAuth mailing list
    TXA= uth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= /a>
    --000000000000a1efac05bdb254f3-- From nobody Tue Mar 16 19:51:49 2021 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 7756C3A17F7 for ; Tue, 16 Mar 2021 19:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 8SVVObmMOSOa for ; Tue, 16 Mar 2021 19:51:42 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 A8F3A3A17F6 for ; Tue, 16 Mar 2021 19:51:42 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id k2so39517680ioh.5 for ; Tue, 16 Mar 2021 19:51:42 -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=utGpHHQUF+cJFkmRAZXsVoz6u2gAkHd5GyceVvZAtdk=; b=P3RxKzqkfSX63UQyvi6Od4O55kSPOYM0EFIXUxlNITiKVRRrU0g8Qw1Tp+y/TSeBpW emY7PzikBX+uHplphRqjexoEQ9XRbR31NRXMNtU12lJhICaHGJMWtVtClKHeIr0QLaJb bpV5pr3MbD8nkzs4gHn5wa55RjtMMJltt9M1FX+qIyZF6/I0DWcAAThOWHxtonnGAQR4 /I4fDX1KyGkpeM2C6H2JzRWiDTW98/YeDaj84UcpgyjOytm+2jWF0+em4NKoi44sM9Kx 7vtIFw8kEsFwxL6VdtHrJH7OogdAzSy81XHmk26/QGIRSKOyl9n9fQn1sj3MAEjINLDb 2TOQ== 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=utGpHHQUF+cJFkmRAZXsVoz6u2gAkHd5GyceVvZAtdk=; b=uDBeHf1gS5DmLPEHEGRUGZo6abK8ZJNRIRsbIXCtzdret9c4urmdMGhlys47VtJVtw AnPLW+429Q2fgl3d9TW7tIPat5825DN+NUXaFv8MrnrPC0gLWhSRMSCtfFwB5cg/qyhN sUC4I+SMAUKZB1FXELuyjpyGDw0quJ5a3LkEMT9U3V87IIQiqGckbJU18xDYuNEWRRbF KCPIWPLBcNFbif4AnYxNANT7rk3FkUwnUCSfctKN6fVGXJW8xezEm/1kqcXi83sFUxSi h96vDIo7x3C8ouvmK4YAAFV6rbSs2jEU/PznDZa18xdFwGhUwmy5QHdZMuQ72d4o3kzm 5EOQ== X-Gm-Message-State: AOAM530sUwRtslfWcBM+Q/QXb8Pd3W4+OjVkirA7/ryHkkvKo55cx1mD nF3dZehyaxPB/3BbMsGSSd+Gcs8SxZD+51afnE4= X-Google-Smtp-Source: ABdhPJwFGREwVWEuONPy03xHMcYnVN4qrqyERGvudcwrNIUHgDB9MzTMJP2UtJcomeykNR2igQVDbYitpJi1ZNvPlfs= X-Received: by 2002:a05:6602:228f:: with SMTP id d15mr5161496iod.141.1615949500626; Tue, 16 Mar 2021 19:51:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Wed, 17 Mar 2021 03:51:27 +0100 Message-ID: To: Adrian Gropper Cc: Tobias Looker , GNAP Mailing List , Justin Richer Content-Type: multipart/alternative; boundary="000000000000f5b8da05bdb28ffc" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 02:51:48 -0000 --000000000000f5b8da05bdb28ffc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Note also that there's issue 197 that discussed that very question. https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/197 Le mer. 17 mars 2021 =C3=A0 03:34, Fabien Imbault a =C3=A9crit : > Hi Adrian, > > As the name suggests, it's an identifier for the subject (and so, > hypothetically, a DID to identify the subject). The text indeed concerns > the subject as the RO, as it is known to the AS. > > But it's easy to make shortcuts, because often we end-up dealing with is > user =3D end-user =3D RO =3D subject. > > Fabien > > Le mer. 17 mars 2021 =C3=A0 03:10, Adrian Gropper a > =C3=A9crit : > >> I'm late to this conversation and confused by Tobias' use of End-User >> (his caps) and subject. Are we talking about a DID for the subject, the >> end-user, or both? >> >> To be clear, in my mind, the subject is in control of policies and >> capabilities at the GNAP AS. The end-user is in control of a client or u= ser >> agent and a request to the AS. The end-user and client may or may not ha= ve >> any prior relationship with the AS. >> >> Adrian >> >> On Tue, Mar 16, 2021 at 10:00 PM Fabien Imbault >> wrote: >> >>> Hi Tobias, >>> >>> Not yet (none of the current sub_ids require additional parameters) but >>> if DIDs do get added to subject identifiers, then it's certainly someth= ing >>> we would have to support. >>> >>> There's already a very basic version of that, but only to chose the mai= n >>> type (now called "format" in latest draft 07 of SECEVENT), with >>> subject_types_supported in the discovery. >>> >>> Thanks for the heads up, it's worth creating an issue or putting a note >>> in some existing issue to not forget looking into that. >>> >>> Cheers >>> Fabien >>> >>> >>> Le mer. 17 mars 2021 =C3=A0 01:01, Tobias Looker >>> a =C3=A9crit : >>> >>>> Hi, >>>> >>>> This is probably out of scope for the current conversation but has any >>>> thought been had on how the client instance could communicate addition= al >>>> options around what subject identifier types it supports for cases whe= re >>>> the client instance will perhaps be required to conduct additional >>>> processing on the artifacts returned by the AS? As an example if the A= S >>>> chose to identify the subject (End-User) using a DID and wanted to inc= lude >>>> an additional cryptographic assertion that showed it controls keys >>>> appropriately associated to the DID, then the client may have wanted t= o >>>> communicate some information up front in their request to ensure they = can >>>> perform this additional processing, such as the signature suites it >>>> supports and in the context of DIDs potentially which DID methods it i= s >>>> capable of resolving? >>>> >>>> Thanks, >>>> [image: Mattr website] >>>> *Tobias Looker* >>>> Mattr >>>> +64 (0) 27 378 0461 >>>> tobias.looker@mattr.global >>>> [image: Mattr website] [image: Mattr on >>>> LinkedIn] [image: Mattr >>>> on Twitter] [image: Mattr on Github] >>>> >>>> This communication, including any attachments, is confidential. If you >>>> are not the intended recipient, you should not read it - please contac= t me >>>> immediately, destroy it, and do not copy or use any part of this >>>> communication or disclose anything about it. Thank you. Please note th= at >>>> this communication does not designate an information system for the >>>> purposes of the Electronic Transactions Act 2002. >>>> >>>> >>>> On Sat, Mar 13, 2021 at 9:26 PM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Hi Justin, >>>>> >>>>> A last word on end-user! =3DRO (again just as food for thought). >>>>> >>>>> As soon as hints.automated is set to true, it takes priority over >>>>> async, which means it's the same model as the one you describe : the = AS has >>>>> precedence over any other remote contact. >>>>> >>>>> So that confirms the global view that the AS is the one with the >>>>> authority, and that it might know more than the client. >>>>> >>>>> Cheers >>>>> Fabien >>>>> >>>>> Le jeu. 11 mars 2021 =C3=A0 11:44, Fabien Imbault >>>>> a =C3=A9crit : >>>>> >>>>>> Hi Justin, >>>>>> >>>>>> I think that's interesting: >>>>>> "For the user !=3D RO cases, I think that potentially having a way t= o >>>>>> signal those two items separately in the request and response could = be >>>>>> useful. Right now all the user/subject stuff is about identifying = =E2=80=9Cthe user >>>>>> that=E2=80=99s currently here at the client instance=E2=80=9D, in a = variety of forms that >>>>>> the client instance and AS can negotiate. If the client or AS has so= me >>>>>> other notion about who the RO is and how that could be separate from= the >>>>>> current user, we could provide a way to signal that like you=E2=80= =99re proposing >>>>>> below. In my mental model, there are going to be a lot of use cases = where >>>>>> the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the client at all, b= ut rather to the AS and is >>>>>> based on what the client=E2=80=99s asking for. So I could identify t= he current user >>>>>> and ask for a specific medical record, and the AS realizes it has to= go bug >>>>>> a particular doctor to approve things directly. This is instead of >>>>>> interacting with the current user and failing in an awkward way when= the >>>>>> current user doesn=E2=80=99t have the rights to do things, but someo= ne else would. >>>>>> But we=E2=80=99d want the system to be able to detect if the current= user is the >>>>>> doctor, so we can just interact with them directly. Does that all tr= ack?" >>>>>> >>>>>> I agree with the general idea. In the end, that's the AS's >>>>>> responsibility (and also a big part of its value as a policy engine)= . >>>>>> >>>>>> Even in the cases - as I suggested - where the client would be able >>>>>> to signal what it knows (or thinks it knows) about the subject, the = AS >>>>>> still needs to validate what it can. The client could be an attacker= lying >>>>>> to the AS. Or there could be an unintended bug. >>>>>> >>>>>> The client still seems like a straightforward source to gather >>>>>> optional/declarative hints. Which is what request.user is already do= ing in >>>>>> spirit. In many cases, the AS should go a step further. Validate >>>>>> cryptographic statements from a more reputable issuer, whatever help= s. >>>>>> >>>>>> Contacts might be one of the possibilities. I'm not suggesting >>>>>> interact/fail scenarii at all, which I see as anti-ergonomic (compos= ability >>>>>> with timeouts and fallback is the answer to that). The failure I was >>>>>> considering is only for async calls explicitly requested by the clie= nt >>>>>> (which is considered in sequence 1.4.3, and not coming from me), the= re's >>>>>> obviously no way to ensure a remote RO would actually respond when t= he >>>>>> client expects it. If that sequence is considered, realistic failure= modes >>>>>> should be anticipated and dealt with internally (just like any distr= ibuted >>>>>> program would do), is all I'm saying. And so from the outside, there= 's no >>>>>> interact/fail. >>>>>> That's the same as in real life: when booking a business trip, an >>>>>> employee could either follow the generic rule (2nd class train ticke= t) or >>>>>> reach out to his manager, explaining that it's a long trip and that = 1st >>>>>> class would be better. The employee knows the manager might not inst= antly >>>>>> respond, and knows that the absence of an answer means he'll have to= go for >>>>>> the 2nd class. >>>>>> >>>>>> There will be cases when the client doesn't know the RO. I'm not sur= e >>>>>> if that's a majority of cases, but it will definitely happen. It cou= ld >>>>>> happen when you interact with an organization or a team and have no = idea >>>>>> who's responsible or what delegations are in place (some of those ca= ses >>>>>> have been described by Adrian for instance). >>>>>> There could also be cases where the ownership could be distributed >>>>>> (an example was provided when considering remote ROs). Again in real= life, >>>>>> it's not unusual for a decision to fallback on a deputy when the mai= n >>>>>> decision maker is unavailable. Or there could be an open governance = even, >>>>>> but maybe that's one step too far. >>>>>> >>>>>> Of course, if the AS has internal knowledge or other ways to get the >>>>>> information it should use it. Remains to be seen how we can specify = that >>>>>> (cf issue #49 on should/must). The example with doctor/patient is fi= ne if >>>>>> hardcoded, but it becomes a problem when we fail to understand the r= eal >>>>>> relationships in environments of various sensitive nature. How the A= S >>>>>> identifies that a specific record requires approval from Doctor Bob = might >>>>>> be context dependent (sometimes it could be a nurse, a team of docto= rs, >>>>>> another medical organization, etc.). Maybe you could have various le= vels of >>>>>> authorizations (extreme example: military style classifications), so= that >>>>>> it might even be impossible to tell who can be contacted. >>>>>> >>>>>> That's also why I was suggesting assertions could go beyond >>>>>> authentication events, and include cryptographic assertions for >>>>>> authorization purposes. Maybe we can even imagine a risk based appro= ach, as >>>>>> in some cases we won't know for sure. >>>>>> >>>>>> The difficulty will be to be sufficiently generic but simple enough. >>>>>> Maybe we can rule out some cases. Maybe remote async contacts are ou= t of >>>>>> scope, because we only want instantaneous authorizations. Most of th= ose >>>>>> cases are way beyond what OAuth2 does. I don't know. But what's cert= ain is >>>>>> that the WG should decide what support for cases where end-user !=3D= RO it >>>>>> intends to provide. My discussion was just a very small Chesterston'= s Fence >>>>>> contribution, even if that seems to have surprised. >>>>>> >>>>>> Fabien >>>>>> >>>>>> >>>>>> On Wed, Mar 10, 2021 at 8:18 PM Justin Richer >>>>>> wrote: >>>>>> >>>>>>> Hi Fabien, >>>>>>> >>>>>>> First, thanks for doing the heavy lift of writing this topic up. Of >>>>>>> these options, I would strongly prefer option (1). The difference b= etween >>>>>>> assertions and identifiers is that an assertion is a fully packaged= set of >>>>>>> attributes, one of which can be an identifier. They are, generally >>>>>>> speaking, cryptographically protected bundles. They=E2=80=99re desi= gned to carry a >>>>>>> bunch of different information about a user and the authentication = event in >>>>>>> a form that=E2=80=99s independently verifiable and auditable. SAML = assertions (XML >>>>>>> document) and ID Tokens (signed JWTs) are the most common ones we s= ee >>>>>>> today, but other formats exist and will keep being invented. >>>>>>> >>>>>>> An identifier is a different kind of creature. It is a single >>>>>>> statement that identifies the party in question in the context of t= he party >>>>>>> doing the identification. It=E2=80=99s this full context that the r= eceiver of the >>>>>>> identifier needs to interpret it in. When using a federated identit= y >>>>>>> protocol, each RP is going to have :some: kind of local user inform= ation >>>>>>> store that they=E2=80=99re going to tie into, some field in a datab= ase they=E2=80=99ll key >>>>>>> off of. It=E2=80=99s just never going to be the case that all RPs w= ill be able to >>>>>>> use server-provided opaque identifiers for all cases. Account recov= ery and >>>>>>> binding is one such use case where a user-facing identifier like an= email >>>>>>> address makes a LOT of sense, for one small example. This is an arr= ay in >>>>>>> the request and response precisely because a user could be known by= several >>>>>>> different identifiers to a party, and an RP will have a better idea= about >>>>>>> what kinds of things it wants to correlate against, and it=E2=80=99= s up to the AS >>>>>>> to provide that mapping. I think that if we don=E2=80=99t define a = way to describe >>>>>>> the format, the =E2=80=9Cas_id=E2=80=9D field is going to get struc= ture back-patched onto >>>>>>> it like is being proposed here: >>>>>>> >>>>>>> https://mattrglobal.github.io/oidc-portable-identities/ >>>>>>> >>>>>>> I=E2=80=99m personally not a fan of that approach as it mixes the d= ata >>>>>>> layering too much, and you end up making guesses about whether a fi= eld is >>>>>>> meaningful or a pointer. I think GNAP will be much better served by= using a >>>>>>> data structure for this from the start. DIDs should be another =E2= =80=9Cformat=E2=80=9D of >>>>>>> the subject identifier. I don=E2=80=99t think GNAP should define th= is format, and >>>>>>> I=E2=80=99ve dropped a note to the SECEVENT mailing list asking abo= ut adding DIDs >>>>>>> to the subject identifiers draft before it gets published. DIDs are= not >>>>>>> assertions, even in the cases where they point to fully functional = DID >>>>>>> documents with user information in them. (And for what it=E2=80=99s= worth, I think >>>>>>> the OIDC world should also use the SECEVENT draft inside ID Tokens = to solve >>>>>>> the use case of the draft above). >>>>>>> >>>>>>> For the user !=3D RO cases, I think that potentially having a way t= o >>>>>>> signal those two items separately in the request and response could= be >>>>>>> useful. Right now all the user/subject stuff is about identifying = =E2=80=9Cthe user >>>>>>> that=E2=80=99s currently here at the client instance=E2=80=9D, in a= variety of forms that >>>>>>> the client instance and AS can negotiate. If the client or AS has s= ome >>>>>>> other notion about who the RO is and how that could be separate fro= m the >>>>>>> current user, we could provide a way to signal that like you=E2=80= =99re proposing >>>>>>> below. In my mental model, there are going to be a lot of use cases= where >>>>>>> the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the client at all, = but rather to the AS and is >>>>>>> based on what the client=E2=80=99s asking for. So I could identify = the current user >>>>>>> and ask for a specific medical record, and the AS realizes it has t= o go bug >>>>>>> a particular doctor to approve things directly. This is instead of >>>>>>> interacting with the current user and failing in an awkward way whe= n the >>>>>>> current user doesn=E2=80=99t have the rights to do things, but some= one else would. >>>>>>> But we=E2=80=99d want the system to be able to detect if the curren= t user is the >>>>>>> doctor, so we can just interact with them directly. Does that all t= rack? >>>>>>> >>>>>>> =E2=80=94 Justin >>>>>>> >>>>>>> On Mar 10, 2021, at 4:10 AM, Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Notice the question mark in the title. Not to be considered as an >>>>>>> editor's comment. >>>>>>> This thread intends to provide a detailed comment on the >>>>>>> interesting feedback by Kristina: "I would catch up on the thread t= o >>>>>>> understand why DIDs are thought to be treated as assertions". >>>>>>> In the chat, I answered: "Happy to get the discussion on DIDs. >>>>>>> Actually, could be either or, depending on what we intend to do." L= et me >>>>>>> expand a bit on that, to make it understandable (didn't have the ti= me >>>>>>> during the meeting, unfortunately). >>>>>>> >>>>>>> This relates to the items described on slides 20 and 34, which I'll >>>>>>> explain further. I'll highlight as transparently as possible what I= think >>>>>>> would be the benefits and downsides of each. Both are probably viab= le >>>>>>> options, but they correspond to different scopes and objectives. I'= ll spend >>>>>>> a bit more time on option 2, since it is a different approach compa= red to >>>>>>> the current draft. >>>>>>> >>>>>>> *1. The first possibility is to use SECEVENT throughout. * >>>>>>> In that case, DIDs should be a part of sub_ids (in the core or in >>>>>>> the extension registry, depending on what Annabelle's WG decides). = More >>>>>>> generally, the WG would have to decide which additional sub_ids it = needs >>>>>>> (as per Yaron's comment). >>>>>>> >>>>>>> That's obviously the closest to what is described in draft-04. It >>>>>>> allows a communication of subject information between the client an= d the >>>>>>> AS, by using global identifiers (mail, phone, etc.), or using a loc= al >>>>>>> opaque reference - i.e. governed by the AS (that's probably what we >>>>>>> would put in the examples, unless someone has a better idea - cf is= sues #16 >>>>>>> and #42). >>>>>>> >>>>>>> Assertions relate for instance to the proof of presence of the RO. >>>>>>> The current draft-04 therefore plans for id_tokens and saml2, maybe= there >>>>>>> could be other needs later (extension registry). >>>>>>> >>>>>>> - Benefits: identifiers are a key component of GNAP, which makes >>>>>>> integration easier. Possibly one could choose to use DIDs throughou= t. >>>>>>> - Downsides: email/phone identifiers will probably be used >>>>>>> throughout by most devs (since that's correlation information they = have in >>>>>>> their user DB). Which means we should limit what assertions contain= , to >>>>>>> avoid doing links between weak global identifiers and hopefully str= onger >>>>>>> assertions. That's not really a problem if it's limited to authenti= cation >>>>>>> events mostly (in that perspective, samlv2 could make sense in the = core). >>>>>>> An assertion is probably a single value then (not an array). >>>>>>> >>>>>>> Option 1 can be summarized as: >>>>>>> >>>>>>> "subject": { >>>>>>> "sub_ids": { }, // request and response (SECEVENT -> including >>>>>>> DID possibly) >>>>>>> "assertions": [ ], // request and response >>>>>>> (id_token or samlv2) >>>>>>> } >>>>>>> ("hints" do not exist currently, but are partially covered >>>>>>> separately via "request.user" / the relevance of "principal", discu= ssed in >>>>>>> the slide, is a question mark too - which is a different discussion= on >>>>>>> end-user !=3D RO). >>>>>>> >>>>>>> >>>>>>> *2. An alternate possibility is to use SECEVENT only as input/hint* >>>>>>> In that case, DIDs should be a part of assertions (which have a >>>>>>> different meaning compared to option 1). >>>>>>> >>>>>>> The AS only returns an local opaque reference as_ref (while in >>>>>>> option 1, it was only one of many possibilities). Its only job is t= o help >>>>>>> the client differentiate the response subject. The AS policy might = further >>>>>>> define the scope of that reference, as suggested in >>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210, >>>>>>> although I personally viewed that by default as (2) "as_id" an iden= tifier >>>>>>> locally unique to that AS for all the RSs. >>>>>>> >>>>>>> SECEVENTS are still useful as an input, that's what I presented in >>>>>>> request.hints.self.sub_ids (but it's the responsibility of the AS t= o match >>>>>>> it with its own reference system - from instance from the email to = AS's >>>>>>> local record XUT2MFM1XBIKJKSDU8Q). Note: since the slides, a new >>>>>>> draft-ietf-secevent-subject-identifiers-07 has been published. Nota= bly this >>>>>>> includes an opaque identifier, which the client can use to pass the= as_ref >>>>>>> hint to the AS. Thus we wouldn't need any further addition to >>>>>>> SECEVENT, although hints would benefit from further additions (like= DIDs >>>>>>> for instance). Notice also that subject_types_supported becomes les= s >>>>>>> important, because in the worst case scenario, it's simply a hint t= hat >>>>>>> wouldn't be understood and therefore taken into account by the AS. >>>>>>> >>>>>>> The assertions array has a more important role than in option 1 >>>>>>> (with the explicit aim of separating between client hints and valid= ated >>>>>>> info asserted by the AS). It serves as a generic/extendible mapping >>>>>>> structure, e.g. "the AS asserts that opaque reference >>>>>>> XUT2MFM1XBIKJKSDU8Q is matching with these (more or less >>>>>>> verifiable) statements." The name assertion therefore corresponds t= o the >>>>>>> responsibility of the AS in delivering those statements (cf should/= must, >>>>>>> issue #49). Some of these statements relate to identity or auth eve= nts (ex: >>>>>>> DID, id_token), some might directly be useful for authorization dec= isions >>>>>>> (like ZKP example in the parental control example). Possibly some o= f these >>>>>>> validated assertions could be reused in next interactions. >>>>>>> >>>>>>> Another question that popped-up is the scope of sub_ids. Should the= y >>>>>>> be about the same user? (I think so). In the case of remote ROs esp= ecially, >>>>>>> it might be important that DID be considered as an assertion (about= someone >>>>>>> else's) and not as sub_ids, because the AS needs to be careful abou= t who >>>>>>> the client wants to reach (avoid spam, etc.). This is consistent wi= th the >>>>>>> rest of discussion on what to do when end-user !=3D RO, although us= ing >>>>>>> DIDComm might seem a bit early (the paint is very fresh). >>>>>>> >>>>>>> Option 2 was summarized as: >>>>>>> >>>>>>> // (suggestion only, not as an editor) >>>>>>> "subject": { >>>>>>> "as_ref": { // response only (wouldn=E2=80=99t require SECEVENT) >>>>>>> =E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D, >>>>>>> =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D >>>>>>> }, >>>>>>> "assertions": [ ], // request and response >>>>>>> (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validated by= the AS) >>>>>>> >>>>>>> "hints": { // request only (optional) >>>>>>> "self": { // replaces request.user (support SECEVENT here) >>>>>>> =E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque in= draft-07 - that >>>>>>> could contain the ref) >>>>>>> =E2=80=9Cassertions=E2=80=9D: [ ] // see examples: VC on DOB or = ZKP on age (wider >>>>>>> scope, possibly through extensions) >>>>>>> }, >>>>>>> "principal": { // new proposal presented at IETF110 (just an >>>>>>> idea) >>>>>>> =E2=80=9Cautomated=E2=80=9D: true, // rule engine >>>>>>> =E2=80=9Casync=E2=80=9D: { } // remote ROs >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> - Benefits: as_ref is self supporting (no strong coupling with >>>>>>> SECEVENT), but can still take SECEVENT as an input hint for the AS.= It >>>>>>> avoids the risk of making an official association between a weak gl= obal >>>>>>> identifier (e.g. email, used elsewhere) and hopefully stronger loca= l >>>>>>> assertions. GNAP would be fully agnostic to whatever identity syste= m is >>>>>>> used, only facilitating interoperability through assertions (second= only in >>>>>>> importance compared to the AS opaque reference). Some assertions (p= ossibly >>>>>>> extensions) could also be useful for the AS decision (e.g. VC or ZK= P). >>>>>>> - Downsides: opaqueness of as_ref is a feature, not a bug. The >>>>>>> opaque reference is fully managed by the AS, therefore not inherent= ly >>>>>>> portable (cf portability discussions in OIDC currently). There's no >>>>>>> explicit binding to an official identity, only a contextual mapping= to AS >>>>>>> validated assertions. It makes it more difficult to match the ident= ifiers >>>>>>> from one AS to another or to correlate with the client user DB (sti= ll >>>>>>> possible via assertions, if the AS allows it). Assertions are much = more >>>>>>> generic (possibly via extensions), but might require a more advance= d >>>>>>> mechanism to request/response only the most relevant information (w= hich >>>>>>> makes the AS policy critical here). >>>>>>> >>>>>>> I hope that clarifies the reasoning for both options. Again I'm not >>>>>>> saying option 2 is better, just saying the trade-offs are different= (+ >>>>>>> knowing that we need to keep it simple). >>>>>>> - option 1 puts more in sub_ids and less in assertions >>>>>>> - option 2 puts less in the reference and more in assertions >>>>>>> All of this is open to discussion. More generally speaking, on ever= y >>>>>>> part in orange and question mark (?) I would love your ideas and >>>>>>> criticisms. What I intended as an editor is only to highlight where= the WG >>>>>>> has important choices to make, before we can make the related PRs. >>>>>>> >>>>>>> A further side comment: IETF EAT RATS was suggested for assertions, >>>>>>> but relates more to the client attestations. It was added as a comm= ent in >>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, which >>>>>>> is a distinct topic we'll work on. >>>>>>> >>>>>>> Fabien (editor's hat off) >>>>>>> >>>>>>> -- >>>>>>> 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 >>>>> >>>> >>>> This communication, including any attachments, is confidential. If you= are not the intended recipient, you should not read it - please contact me= immediately, destroy it, and do not copy or use any part of this communica= tion or disclose anything about it. Thank you. Please note that this commun= ication does not designate an information system for the purposes of the El= ectronic Transactions Act 2002. >>>> >>>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> --000000000000f5b8da05bdb28ffc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Note also that there's issue 197 that discussed = that very question.=C2=A0

    Le mer= . 17 mars 2021 =C3=A0 03:34, Fabien Imbault <fabien.imbault@gmail.com> a =C3=A9crit=C2=A0:
    Hi Adrian,

    =
    As the name suggests, it's an identifier for the subj= ect (and so, hypothetically, a DID to identify the subject). The text indee= d concerns the subject as the RO, as it is known to the AS.=C2=A0

    But it's easy to make shortcu= ts, because often we end-up dealing with is user =3D end-user =3D RO =3D su= bject.=C2=A0

    Fabien=C2= =A0

    Le mer. 17 mars 2021 =C3=A0 03:10, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit= =C2=A0:
    I'm la= te to this conversation and confused by Tobias' use of End-User (his ca= ps)=C2=A0and subject. Are we talking about a DID for the subject, the end-u= ser, or both?

    To be clear, in my mind, the subject is in= control=C2=A0of policies and capabilities at the GNAP AS. The end-user is = in control=C2=A0of a client or user agent and a request to the AS. The end-= user and client may or may not have any prior relationship with the AS.
    Adrian

    On Tue, Mar 16, 2021 at 10:00 PM Fabien I= mbault <fabien.imbault= @gmail.com> wrote:
    Hi T= obias,

    Not yet (none of the cu= rrent sub_ids require additional parameters) but if DIDs do get added to su= bject identifiers, then it's certainly something we would have to suppo= rt.=C2=A0

    There's al= ready a very basic version of that, but only to chose the main type (now ca= lled "format" in latest draft 07 of SECEVENT), with subject_types= _supported in the discovery.=C2=A0

    Thanks for the heads up, it's worth creating an issue or put= ting a note in some existing issue to not forget looking into that.=C2=A0

    Cheers
    Fabien


    Le mer. 17 mars 2021 =C3=A0 01:01, Tobias Loo= ker <tobias.looker@mattr.global> a =C3=A9crit=C2=A0:
    Hi,

    This is probably out of s= cope for the current conversation but has any thought been had on how the c= lient instance could communicate additional options around what subject ide= ntifier types it supports for cases where the client instance will perhaps = be required to conduct additional processing on the artifacts returned by t= he AS? As an example if the AS chose to identify the subject (End-User) usi= ng a DID and wanted to include an additional cryptographic assertion that s= howed it controls keys appropriately associated to the DID, then the client= may have wanted to communicate some information up front in their request = to ensure they can perform this additional processing, such as the signatur= e suites it supports and in the context of DIDs potentially which DID metho= ds it is capable of resolving?

    Thanks,
    3D"Mattr=C2=A0=
    Tobias= Looker
    Mattr
    +64 (0) 27 378 0461
    tobias.looker@matt= r.global
    3D=3D"Mattr3D"Mattr3D"Matt=<= /td>
    =
    3D"Mattr=C2=A0
    Tobias Looker
    Mattr
    +64 (0) 27 378 0461
    tobias.looker@matt= r.global
    3D"Mattr3D"Mattr3D"Mattr3D"Mattr

    This communication, including any attachments, is confidential. If yo= u are not the intended recipient, you should not read it - please contact m= e immediately, destroy it, and do not copy or use any part of this communic= ation or disclose anything about it. Thank you. Please note that this commu= nication does not designate an information system for the purposes of the E= lectronic Transactions Act 2002.


    On = Sat, Mar 13, 2021 at 9:26 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Justin,=C2=A0

    A last word on end-user! =3DRO (ag= ain just as food for thought).=C2=A0

    As soon as hints.automated is set to true, it takes priority o= ver async, which means it's the same model as the one you describe : th= e AS has precedence over any other remote contact.=C2=A0

    So that confirms the global view that the = AS is the one with the authority, and that it might know more than the clie= nt.=C2=A0

    Cheers
    Fabien=C2=A0

    Le jeu. 11 mars = 2021 =C3=A0 11:44, Fabien Imbault <fabien.imbault@gmail.com> a =C3=A9crit=C2=A0= :
    Hi Justin,

    = I think that's interesting:
    "For the user !=3D RO c= ases, I think that potentially having a way to signal those two items separ= ately in the request and response could be useful. Right now all the user/s= ubject stuff is about identifying =E2=80=9Cthe user that=E2=80=99s currentl= y here at the client instance=E2=80=9D, in a variety of forms that the clie= nt instance and AS can negotiate. If the client or AS has some other notion= about who the RO is and how that could be separate from the current user, = we could provide a way to signal that like you=E2=80=99re proposing below. = In my mental model, there are going to be a lot of use cases where the =E2= =80=9CRO=E2=80=9D isn=E2=80=99t known to the client at all, but rather to t= he AS and is based on what the client=E2=80=99s asking for. So I could iden= tify the current user and ask for a specific medical record, and the AS rea= lizes it has to go bug a particular doctor to approve things directly. This= is instead of interacting with the current user and failing in an awkward = way when the current user doesn=E2=80=99t have the rights to do things, but= someone else would. But we=E2=80=99d want the system to be able to detect = if the current user is the doctor, so we can just interact with them direct= ly. Does that all track?"

    I agree with the ge= neral idea. In the end, that's the AS's responsibility (and also a = big part of its value as a policy engine). =C2=A0

    = Even in the cases - as I suggested - where the client would be able to sign= al what it knows (or thinks it knows) about the subject, the AS still needs= to validate what it can. The client could be an attacker lying to the AS. = Or there could be an unintended bug.=C2=A0

    The=C2= =A0client still seems like a straightforward source to gather optional/decl= arative hints. Which is what request.user is already doing in spirit. In ma= ny cases, the AS should go a step further. Validate cryptographic statement= s from a more reputable issuer, whatever helps.

    Co= ntacts might be one of the possibilities. I'm not suggesting interact/f= ail scenarii at all, which I see as anti-ergonomic (composability with time= outs and fallback is the answer to that). The failure I was considering is = only for async calls explicitly requested by the client (which is considere= d in sequence 1.4.3, and not coming from me), there's obviously no way = to ensure a remote RO would actually respond when the client expects it. If= that sequence is considered, realistic failure modes should be anticipated= and dealt with internally (just like any distributed program would do), is= all I'm saying. And so from the outside, there's no interact/fail.= =C2=A0=C2=A0
    That's the same as in real life: when booking a = business trip, an employee could either follow the generic rule (2nd class = train ticket) or reach out to his manager, explaining that it's a long = trip and that 1st class would be better. The employee knows the manager mig= ht not instantly respond, and knows that the absence of an answer means he&= #39;ll have to go for the 2nd class.=C2=A0

    The= re will be cases when the=C2=A0client doesn't know the=C2=A0RO. I'm= not sure if that's a majority of cases, but it will definitely happen.= It could happen when you interact with an organization or a team and have = no idea who's responsible or what delegations are in place (some of tho= se cases have been described by Adrian for instance).=C2=A0
    There= could also be cases where the ownership could be distributed (an example w= as provided when considering remote ROs). Again in real life, it's not = unusual for a decision to fallback on a deputy when the main decision maker= is unavailable. Or there could be an open governance even, but maybe that&= #39;s one step too far.

    Of course, if the AS has i= nternal knowledge or other ways to get the information it should use it. Re= mains to be seen how we can specify that (cf issue #49 on should/must). The= example with doctor/patient is fine if hardcoded, but it becomes a problem= when we fail to understand the real relationships in environments of vario= us sensitive nature. How the AS identifies that a specific record requires = approval from Doctor Bob might be context dependent (sometimes it could be = a nurse, a team of doctors, another medical organization, etc.). Maybe you = could have various levels of authorizations (extreme example: military styl= e classifications), so that it might even be impossible to tell who can be = contacted.=C2=A0

    That's also why I was suggest= ing assertions could go beyond authentication events, and include cryptogra= phic assertions for authorization purposes. Maybe we can even imagine a ris= k based approach, as in some cases we won't know for sure.=C2=A0
    <= div>
    The difficulty will be to be sufficiently generic but si= mple enough. Maybe we can rule out some cases. Maybe remote async contacts = are out of scope,=C2=A0because we only want instantaneous authorizations. M= ost of those cases are way beyond what OAuth2 does. I don't know. But w= hat's certain is that the WG should decide what support for cases where= end-user !=3D RO it intends to provide. My discussion was just a very smal= l Chesterston's Fence contribution, even if that seems to have surprise= d.

    Fabien


    On Wed, Mar 10, 2021 at 8:18 PM Justin Richer <jricher@mit.edu= > wrote:
    Hi Fabien,

    Fi= rst, thanks for doing the heavy lift of writing this topic up. Of these opt= ions, I would strongly prefer option (1). The difference between assertions= and identifiers is that an assertion is a fully packaged set of attributes= , one of which can be an identifier. They are, generally speaking, cryptogr= aphically protected bundles. They=E2=80=99re designed to carry a bunch of d= ifferent information about a user and the authentication event in a form th= at=E2=80=99s independently verifiable and auditable. SAML assertions (XML d= ocument) and ID Tokens (signed JWTs) are the most common ones we see today,= but other formats exist and will keep being invented.=C2=A0

    =
    An identifier is a different kind of creature. It is a single st= atement that identifies the party in question in the context of the party d= oing the identification. It=E2=80=99s this full context that the receiver o= f the identifier needs to interpret it in. When using a federated identity = protocol, each RP is going to have :some: kind of local user information st= ore that they=E2=80=99re going to tie into, some field in a database they= =E2=80=99ll key off of. It=E2=80=99s just never going to be the case that a= ll RPs will be able to use server-provided opaque identifiers for all cases= . Account recovery and binding is one such use case where a user-facing ide= ntifier like an email address makes a LOT of sense, for one small example. = This is an array in the request and response precisely because a user could= be known by several different identifiers to a party, and an RP will have = a better idea about what kinds of things it wants to correlate against, and= it=E2=80=99s up to the AS to provide that mapping. I think that if we don= =E2=80=99t define a way to describe the format, the =E2=80=9Cas_id=E2=80=9D= field is going to get structure back-patched onto it like is being propose= d here:


    I=E2=80=99m= personally not a fan of that approach as it mixes the data layering too mu= ch, and you end up making guesses about whether a field is meaningful or a = pointer. I think GNAP will be much better served by using a data structure = for this from the start. DIDs should be another =E2=80=9Cformat=E2=80=9D of= the subject identifier. I don=E2=80=99t think GNAP should define this form= at, and I=E2=80=99ve dropped a note to the SECEVENT mailing list asking abo= ut adding DIDs to the subject identifiers draft before it gets published. D= IDs are not assertions, even in the cases where they point to fully functio= nal DID documents with user information in them. (And for what it=E2=80=99s= worth, I think the OIDC world should also use the SECEVENT draft inside ID= Tokens to solve the use case of the draft above).

    For the user !=3D RO cases, I think that potentially having a way to signa= l those two items separately in the request and response could be useful. R= ight now all the user/subject stuff is about identifying =E2=80=9Cthe user = that=E2=80=99s currently here at the client instance=E2=80=9D, in a variety= of forms that the client instance and AS can negotiate. If the client or A= S has some other notion about who the RO is and how that could be separate = from the current user, we could provide a way to signal that like you=E2=80= =99re proposing below. In my mental model, there are going to be a lot of u= se cases where the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the client a= t all, but rather to the AS and is based on what the client=E2=80=99s askin= g for. So I could identify the current user and ask for a specific medical = record, and the AS realizes it has to go bug a particular doctor to approve= things directly. This is instead of interacting with the current user and = failing in an awkward way when the current user doesn=E2=80=99t have the ri= ghts to do things, but someone else would. But we=E2=80=99d want the system= to be able to detect if the current user is the doctor, so we can just int= eract with them directly. Does that all track?

    =C2= =A0=E2=80=94 Justin

    On Ma= r 10, 2021, at 4:10 AM, Fabien Imbault <fabien.imbault@gmail.com> wr= ote:

    Hello,

    Notice the qu= estion mark in the title. Not to be considered as an editor's comment.<= /div>
    This thread intends to provide a detailed comment on the interest= ing=C2=A0feedback by Kristina: "I would catch up on the thread to unde= rstand why DIDs are thought to be treated as assertions".
    In= the chat, I answered: "Happy to get the discussion on DIDs. Actually,= could be either or, depending on what we intend to do." Let me expand= a bit on that, to make it understandable (didn't have the time during = the meeting, unfortunately).

    This relates to the i= tems described on slides 20 and 34, which I'll explain further. I'l= l highlight as transparently as possible what I think would be the benefits= and downsides of each. Both are probably viable options, but they correspo= nd to different scopes and objectives. I'll spend a bit more time on op= tion 2, since it is a different approach compared to the current draft.

    =
    1. The first possibility is to use SECEVENT throughout.=C2=A0
    In that case, DIDs should be a part of sub_ids (in the core or in = the extension registry, depending on what Annabelle's WG decides). More= generally, the WG would have to decide which additional sub_ids it needs (= as per Yaron's comment).

    That's obviously = the closest to what is described in draft-04. It allows a communication of = subject information between the client and the AS, by using global identifi= ers (mail, phone, etc.), or using a local opaque reference=C2=A0- i.e. gove= rned by the AS (that's probably what we would=C2=A0put in the examples,= unless someone has a better idea - cf issues #16 and #42).=C2=A0

    Assertions relate for instance to the proof of presence of = the RO. The current draft-04 therefore plans for id_tokens and saml2, maybe= there could be other needs later (extension registry).

    - Benefits: identifiers are a key component of GNAP, which makes inte= gration easier. Possibly one could choose to use DIDs throughout.
    - Downsides: email/phone identifiers will probably be used throughout by m= ost devs (since that's correlation information they=C2=A0have in their = user DB). Which means we should limit what assertions contain, to avoid doi= ng links between weak global identifiers and hopefully stronger assertions.= That's not really a problem if it's limited to authentication even= ts mostly (in that perspective, samlv2 could make sense in the core). An as= sertion is probably a single value then (not an array).=C2=A0 =C2=A0
    <= div>
    Option 1 can be summarized as:=C2=A0

    =
    "subject": {
    =C2=A0=C2=A0=C2=A0"sub_ids&qu= ot;: { }, = = // request and response (SECEVENT ->= ; including DID possibly)=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=C2=A0=C2= =A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0"assertions": [ ], =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request and response (id_t= oken or samlv2)
    }
    ("hints" do not exist current= ly, but are partially covered separately via "request.user" / the= relevance of "principal", discussed in the slide, is a question = mark too - which is a different discussion on end-user !=3D RO).


    2. An alternate possibility is to use S= ECEVENT only as input/hint
    In that case, DIDs should be a par= t of assertions (which have a different meaning compared to option 1).

    The AS only returns an local opaque reference as_ref (= while in option 1, it was only one of many possibilities). Its only job is = to help the client differentiate the response subject. The AS policy might = further define the scope of that reference, as suggested in=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/= 210, although I personally=C2=A0viewed that by default as=C2=A0(2) &quo= t;as_id" an identifier locally unique to that AS for all the RSs.

    SECEVENTS are still useful as an input, that's wha= t I presented in request.hints.self.sub_ids (but it's the responsibilit= y=C2=A0of the AS to match it with its own reference system - from instance = from the email to AS's local record XUT2MFM1XBIKJKSDU8Q).=C2=A0Note: si= nce the slides, a new draft-ietf-secevent-subject-identifiers-07 has been p= ublished. Notably this includes an opaque identifier, which the client can = use to pass the as_ref hint to the AS. Thus we wouldn't need any furthe= r addition to SECEVENT,=C2=A0although hints would benefit from further addi= tions (like DIDs for instance). Notice also that subject_types_supported be= comes less important, because in the worst case scenario, it's simply= =C2=A0a hint that wouldn't be understood and therefore taken into accou= nt by the AS.

    The assertions array has a more impo= rtant role than in option 1 (with the explicit aim of separating between cl= ient hints and validated info asserted by the AS). It serves as a generic/e= xtendible mapping structure, e.g. "the AS asserts that opaque referenc= e=C2=A0XU= T2MFM1XBIKJKSDU8Q=C2=A0is matching with these (more or less verifiab= le) statements." The name assertion therefore corresponds to the respo= nsibility=C2=A0of the AS in delivering those statements (cf should/must, is= sue #49). Some of these statements relate to identity or auth events (ex: D= ID, id_token), some might directly be useful for authorization decisions (l= ike ZKP example in the parental control example). Possibly some of these va= lidated assertions could be reused in next interactions.

    Another question that popped-up is the scope of sub_ids. Should they= be about the same user? (I think so). In the case of remote ROs especially= , it might be important that DID be considered as an assertion=C2=A0(about = someone else's) and not as sub_ids, because the AS needs to be careful = about who the client wants to reach (avoid spam, etc.). This is consistent = with the rest of discussion on what to do when end-user !=3D RO, although u= sing DIDComm might seem a bit early (the paint is very fresh).=C2=A0
    <= div>
    Option 2 was summarized as:=C2=A0

    <= font size=3D"1">// (suggestion only, not as an editor)
    <= div style=3D"line-height:1.2;margin-top:0pt;margin-bottom:0pt">"sub= ject": {
    =C2=A0=C2=A0=C2=A0"as_ref": { // response only (wou= ldn=E2=80=99t require SECEVENT)
    <= span style=3D"font-family:"Courier New";color:rgb(51,51,51);backg= round-color:rgb(247,247,247);font-variant-numeric:normal;font-variant-east-= asian:normal;vertical-align:baseline;white-space:pre-wrap">=E2=80=9Cas=E2= =80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D,
    =E2=80=9Cref= =E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D=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=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"assertions": [ ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 // request and response (id_token/jwkthumb/DID/VC/etc. -> wha= tever info can be validated by the AS)
    =
    = =C2=A0=C2=A0=C2=A0"hints": { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request only (optional)
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"self": { // replaces= request.user (support SECEVENT here)
    =C2=A0= =C2=A0=C2=A0=E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque in draft-07= - that could contain the ref)
    =C2=A0=C2=A0=C2= =A0=E2=80=9Cassertions=E2=80=9D: [ ] // see examples: VC on DOB = or ZKP on age (wider scope, possibly through extensions)
    },=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=C2=A0=C2=A0=C2=A0
    <= span style=3D"font-family:"Courier New";color:rgb(51,51,51);backg= round-color:rgb(247,247,247);font-variant-numeric:normal;font-variant-east-= asian:normal;vertical-align:baseline;white-space:pre-wrap">=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0"principal": { = <= span style=3D"white-space:pre-wrap"> <= /span>//= new proposal presented at IETF110 (just an idea)
    = =C2=A0 =E2=80=9Cautomated=E2=80=9D: true, // rule engine =
    =C2=A0 =E2=80=9Casync=E2=80=9D: {= } // remote ROs
    }= =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=C2=A0=C2=A0}
    }

    - Benefits: as_ref is self supporting (no stro= ng coupling with SECEVENT), but can still take SECEVENT as an input hint fo= r the AS. It avoids the risk of making an official association between a we= ak global identifier (e.g. email, used elsewhere) and hopefully stronger lo= cal assertions. GNAP would be fully agnostic to whatever identity system is= used, only facilitating interoperability through assertions (second only i= n importance=C2=A0compared to the AS opaque reference). Some assertions (po= ssibly extensions) could also be useful for the AS decision (e.g. VC or ZKP= ).
    - Downsides: opaqueness of as_ref is a feature, not a bug. The= opaque reference is fully managed by the AS, therefore not inherently port= able (cf portability discussions in OIDC currently). There's no explici= t binding to an official identity, only a contextual mapping to AS validate= d assertions. It makes it more difficult to match the identifiers from one = AS to another or to correlate with the client user DB (still possible via a= ssertions, if the AS allows it). Assertions are much more generic (possibly= via extensions), but might require a more advanced mechanism=C2=A0to reque= st/response only the most relevant information (which makes the AS policy c= ritical here).

    I hope that clarifies the=C2=A0reas= oning for both options. Again I'm not saying option 2 is better, just s= aying the trade-offs are different (+ knowing that we need to keep it simpl= e).
    - option 1 puts more in sub_ids and less in assertions
    <= div>- option 2 puts less in the reference and more in assertions=C2=A0
    All of this is open to discussion. More generally speaking, on every = part in orange and question mark (?) I would love your ideas and criticisms= . What I intended as an editor is only to highlight where the WG has import= ant choices to make, before we can make the related PRs.

    A further side comment: IETF EAT RATS was suggested for assertions, = but relates more to the client attestations. It was added as a comment in= =C2=A0https://github.com/ietf-wg-gnap/gnap-core-p= rotocol/issues/44, which is a distinct topic we'll work on.

    Fabien (editor's hat off)

    --
    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

    This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.
    --
    TXAuth mailing list
    TXAuth@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/txauth
    --000000000000f5b8da05bdb28ffc-- From nobody Tue Mar 16 20:05:00 2021 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 0336C3A1839 for ; Tue, 16 Mar 2021 20:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 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 RPkOHDwiG1OU for ; Tue, 16 Mar 2021 20:04:54 -0700 (PDT) Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) (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 EBCCF3A1838 for ; Tue, 16 Mar 2021 20:04:53 -0700 (PDT) Received: by mail-vs1-f52.google.com with SMTP id m18so298485vsa.1 for ; Tue, 16 Mar 2021 20:04:53 -0700 (PDT) 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=0agLOFybByfdHYc5DZm79dwnQGnq5ILEusMB/dcjg2E=; b=GR+njhlDP1mZ17A/UfmGYZM9xLtve6oHXzskdG94EZSK53rt46AG+Zwn+KGcKxS6Cb PMZzmVH3sIxJxLsjoahaNeIGgZW+7Kx3HhOJUpAoO7MyDmf1geKC1el+zuNBejY9lvfP QMyYHXYsYcnwuPbH3vM9Q/6Xn0wPbJUXTJ42hlpmWq9UFKc/18lnjMWk1ySe3HqbozL0 B9FimRfp8E0JkKVjG0Qyts8vv76TX67htprB6Q7CUxeA/h1sA5OOHykdUuAqCwnAzyWu OMCzYhdk64gPCAPcPKmKtVbYcJLO+qnT2UfsMkIXcaDLQI254SUqqKj8MR6gx1hSQlsA gq4w== X-Gm-Message-State: AOAM532+bphu3nIOMcHaRT4PLgpHJ5/cuFYiuSQ6RpG47ja3O0ToUsOR vgd8ssjkJcPGQ3qexHIgbt2yRbZSUjFeJSBpAn3x+Yo9Rf914Q== X-Google-Smtp-Source: ABdhPJwsgaKqjg32WuIwawNnQJ5beMC9yWgpkDyB6GX0dfS6QZQwdW0MUyQh1c5Jnl/yh3zowz9UXdgZCJ3ZCmZWYGU= X-Received: by 2002:a05:6102:222f:: with SMTP id d15mr1986995vsb.1.1615950292713; Tue, 16 Mar 2021 20:04:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Adrian Gropper Date: Tue, 16 Mar 2021 23:04:40 -0400 Message-ID: To: Fabien Imbault Cc: Tobias Looker , GNAP Mailing List , Justin Richer Content-Type: multipart/alternative; boundary="0000000000002c075f05bdb2bfcf" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 03:04:59 -0000 --0000000000002c075f05bdb2bfcf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, Fabien. We need to be verrry careful about the shortcuts once we add user and end-user to our spec. RO =3D subject (of the resource secured by a RS) is clear and independent of any AS or clients. DIDs can be helpful for the RO-RS relationship for authentication, encryption, and service endpoints. Authentication can facilitate pseudonymity by default. Encryption, for example, can allow mediated communications for privacy enhancement. When we bring the request of an end-user into the picture, the DID can apply to someone other than the RO / subject. The DID can secure claims that had nothing to do with the RO-RS (as you point out in #197). Also, in many cases, the subject DID known to the requesting party might be different from the DID associated with the RO at the RS. This promotes privacy through DIDs as same-domain identifiers but has to be dealt with at the policy decision point where capabilities are filtered. Another source of potential confusion comes from the way we use client. DIDs are generally not associated with a client except to the extent the client is a user-agent such as a mobile wallet or an online policy and capabilities agent. My suggestion is that we arrive at a set of consistent names soon and present them early in the spec - in what is now Section 1.2 - and avoid using any shortcuts in the rest of the spec. I would also suggest we provide examples of the use of DIDs relative to the names we define in 1.2. Adrian On Tue, Mar 16, 2021 at 10:51 PM Fabien Imbault wrote: > Note also that there's issue 197 that discussed that very question. > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/197 > > Le mer. 17 mars 2021 =C3=A0 03:34, Fabien Imbault a > =C3=A9crit : > >> Hi Adrian, >> >> As the name suggests, it's an identifier for the subject (and so, >> hypothetically, a DID to identify the subject). The text indeed concerns >> the subject as the RO, as it is known to the AS. >> >> But it's easy to make shortcuts, because often we end-up dealing with is >> user =3D end-user =3D RO =3D subject. >> >> Fabien >> >> Le mer. 17 mars 2021 =C3=A0 03:10, Adrian Gropper a >> =C3=A9crit : >> >>> I'm late to this conversation and confused by Tobias' use of End-User >>> (his caps) and subject. Are we talking about a DID for the subject, the >>> end-user, or both? >>> >>> To be clear, in my mind, the subject is in control of policies and >>> capabilities at the GNAP AS. The end-user is in control of a client or = user >>> agent and a request to the AS. The end-user and client may or may not h= ave >>> any prior relationship with the AS. >>> >>> Adrian >>> >>> On Tue, Mar 16, 2021 at 10:00 PM Fabien Imbault < >>> fabien.imbault@gmail.com> wrote: >>> >>>> Hi Tobias, >>>> >>>> Not yet (none of the current sub_ids require additional parameters) bu= t >>>> if DIDs do get added to subject identifiers, then it's certainly somet= hing >>>> we would have to support. >>>> >>>> There's already a very basic version of that, but only to chose the >>>> main type (now called "format" in latest draft 07 of SECEVENT), with >>>> subject_types_supported in the discovery. >>>> >>>> Thanks for the heads up, it's worth creating an issue or putting a not= e >>>> in some existing issue to not forget looking into that. >>>> >>>> Cheers >>>> Fabien >>>> >>>> >>>> Le mer. 17 mars 2021 =C3=A0 01:01, Tobias Looker >>>> a =C3=A9crit : >>>> >>>>> Hi, >>>>> >>>>> This is probably out of scope for the current conversation but has an= y >>>>> thought been had on how the client instance could communicate additio= nal >>>>> options around what subject identifier types it supports for cases wh= ere >>>>> the client instance will perhaps be required to conduct additional >>>>> processing on the artifacts returned by the AS? As an example if the = AS >>>>> chose to identify the subject (End-User) using a DID and wanted to in= clude >>>>> an additional cryptographic assertion that showed it controls keys >>>>> appropriately associated to the DID, then the client may have wanted = to >>>>> communicate some information up front in their request to ensure they= can >>>>> perform this additional processing, such as the signature suites it >>>>> supports and in the context of DIDs potentially which DID methods it = is >>>>> capable of resolving? >>>>> >>>>> Thanks, >>>>> [image: Mattr website] >>>>> *Tobias Looker* >>>>> Mattr >>>>> +64 (0) 27 378 0461 >>>>> tobias.looker@mattr.global >>>>> [image: Mattr website] [image: Mattr on >>>>> LinkedIn] [image: >>>>> Mattr on Twitter] [image: Mattr on >>>>> Github] >>>>> This communication, including any attachments, is confidential. If yo= u >>>>> are not the intended recipient, you should not read it - please conta= ct me >>>>> immediately, destroy it, and do not copy or use any part of this >>>>> communication or disclose anything about it. Thank you. Please note t= hat >>>>> this communication does not designate an information system for the >>>>> purposes of the Electronic Transactions Act 2002. >>>>> >>>>> >>>>> On Sat, Mar 13, 2021 at 9:26 PM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Hi Justin, >>>>>> >>>>>> A last word on end-user! =3DRO (again just as food for thought). >>>>>> >>>>>> As soon as hints.automated is set to true, it takes priority over >>>>>> async, which means it's the same model as the one you describe : the= AS has >>>>>> precedence over any other remote contact. >>>>>> >>>>>> So that confirms the global view that the AS is the one with the >>>>>> authority, and that it might know more than the client. >>>>>> >>>>>> Cheers >>>>>> Fabien >>>>>> >>>>>> Le jeu. 11 mars 2021 =C3=A0 11:44, Fabien Imbault < >>>>>> fabien.imbault@gmail.com> a =C3=A9crit : >>>>>> >>>>>>> Hi Justin, >>>>>>> >>>>>>> I think that's interesting: >>>>>>> "For the user !=3D RO cases, I think that potentially having a way = to >>>>>>> signal those two items separately in the request and response could= be >>>>>>> useful. Right now all the user/subject stuff is about identifying = =E2=80=9Cthe user >>>>>>> that=E2=80=99s currently here at the client instance=E2=80=9D, in a= variety of forms that >>>>>>> the client instance and AS can negotiate. If the client or AS has s= ome >>>>>>> other notion about who the RO is and how that could be separate fro= m the >>>>>>> current user, we could provide a way to signal that like you=E2=80= =99re proposing >>>>>>> below. In my mental model, there are going to be a lot of use cases= where >>>>>>> the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the client at all, = but rather to the AS and is >>>>>>> based on what the client=E2=80=99s asking for. So I could identify = the current user >>>>>>> and ask for a specific medical record, and the AS realizes it has t= o go bug >>>>>>> a particular doctor to approve things directly. This is instead of >>>>>>> interacting with the current user and failing in an awkward way whe= n the >>>>>>> current user doesn=E2=80=99t have the rights to do things, but some= one else would. >>>>>>> But we=E2=80=99d want the system to be able to detect if the curren= t user is the >>>>>>> doctor, so we can just interact with them directly. Does that all t= rack?" >>>>>>> >>>>>>> I agree with the general idea. In the end, that's the AS's >>>>>>> responsibility (and also a big part of its value as a policy engine= ). >>>>>>> >>>>>>> Even in the cases - as I suggested - where the client would be able >>>>>>> to signal what it knows (or thinks it knows) about the subject, the= AS >>>>>>> still needs to validate what it can. The client could be an attacke= r lying >>>>>>> to the AS. Or there could be an unintended bug. >>>>>>> >>>>>>> The client still seems like a straightforward source to gather >>>>>>> optional/declarative hints. Which is what request.user is already d= oing in >>>>>>> spirit. In many cases, the AS should go a step further. Validate >>>>>>> cryptographic statements from a more reputable issuer, whatever hel= ps. >>>>>>> >>>>>>> Contacts might be one of the possibilities. I'm not suggesting >>>>>>> interact/fail scenarii at all, which I see as anti-ergonomic (compo= sability >>>>>>> with timeouts and fallback is the answer to that). The failure I wa= s >>>>>>> considering is only for async calls explicitly requested by the cli= ent >>>>>>> (which is considered in sequence 1.4.3, and not coming from me), th= ere's >>>>>>> obviously no way to ensure a remote RO would actually respond when = the >>>>>>> client expects it. If that sequence is considered, realistic failur= e modes >>>>>>> should be anticipated and dealt with internally (just like any dist= ributed >>>>>>> program would do), is all I'm saying. And so from the outside, ther= e's no >>>>>>> interact/fail. >>>>>>> That's the same as in real life: when booking a business trip, an >>>>>>> employee could either follow the generic rule (2nd class train tick= et) or >>>>>>> reach out to his manager, explaining that it's a long trip and that= 1st >>>>>>> class would be better. The employee knows the manager might not ins= tantly >>>>>>> respond, and knows that the absence of an answer means he'll have t= o go for >>>>>>> the 2nd class. >>>>>>> >>>>>>> There will be cases when the client doesn't know the RO. I'm not >>>>>>> sure if that's a majority of cases, but it will definitely happen. = It could >>>>>>> happen when you interact with an organization or a team and have no= idea >>>>>>> who's responsible or what delegations are in place (some of those c= ases >>>>>>> have been described by Adrian for instance). >>>>>>> There could also be cases where the ownership could be distributed >>>>>>> (an example was provided when considering remote ROs). Again in rea= l life, >>>>>>> it's not unusual for a decision to fallback on a deputy when the ma= in >>>>>>> decision maker is unavailable. Or there could be an open governance= even, >>>>>>> but maybe that's one step too far. >>>>>>> >>>>>>> Of course, if the AS has internal knowledge or other ways to get th= e >>>>>>> information it should use it. Remains to be seen how we can specify= that >>>>>>> (cf issue #49 on should/must). The example with doctor/patient is f= ine if >>>>>>> hardcoded, but it becomes a problem when we fail to understand the = real >>>>>>> relationships in environments of various sensitive nature. How the = AS >>>>>>> identifies that a specific record requires approval from Doctor Bob= might >>>>>>> be context dependent (sometimes it could be a nurse, a team of doct= ors, >>>>>>> another medical organization, etc.). Maybe you could have various l= evels of >>>>>>> authorizations (extreme example: military style classifications), s= o that >>>>>>> it might even be impossible to tell who can be contacted. >>>>>>> >>>>>>> That's also why I was suggesting assertions could go beyond >>>>>>> authentication events, and include cryptographic assertions for >>>>>>> authorization purposes. Maybe we can even imagine a risk based appr= oach, as >>>>>>> in some cases we won't know for sure. >>>>>>> >>>>>>> The difficulty will be to be sufficiently generic but simple enough= . >>>>>>> Maybe we can rule out some cases. Maybe remote async contacts are o= ut of >>>>>>> scope, because we only want instantaneous authorizations. Most of t= hose >>>>>>> cases are way beyond what OAuth2 does. I don't know. But what's cer= tain is >>>>>>> that the WG should decide what support for cases where end-user != =3D RO it >>>>>>> intends to provide. My discussion was just a very small Chesterston= 's Fence >>>>>>> contribution, even if that seems to have surprised. >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 10, 2021 at 8:18 PM Justin Richer >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Fabien, >>>>>>>> >>>>>>>> First, thanks for doing the heavy lift of writing this topic up. O= f >>>>>>>> these options, I would strongly prefer option (1). The difference = between >>>>>>>> assertions and identifiers is that an assertion is a fully package= d set of >>>>>>>> attributes, one of which can be an identifier. They are, generally >>>>>>>> speaking, cryptographically protected bundles. They=E2=80=99re des= igned to carry a >>>>>>>> bunch of different information about a user and the authentication= event in >>>>>>>> a form that=E2=80=99s independently verifiable and auditable. SAML= assertions (XML >>>>>>>> document) and ID Tokens (signed JWTs) are the most common ones we = see >>>>>>>> today, but other formats exist and will keep being invented. >>>>>>>> >>>>>>>> An identifier is a different kind of creature. It is a single >>>>>>>> statement that identifies the party in question in the context of = the party >>>>>>>> doing the identification. It=E2=80=99s this full context that the = receiver of the >>>>>>>> identifier needs to interpret it in. When using a federated identi= ty >>>>>>>> protocol, each RP is going to have :some: kind of local user infor= mation >>>>>>>> store that they=E2=80=99re going to tie into, some field in a data= base they=E2=80=99ll key >>>>>>>> off of. It=E2=80=99s just never going to be the case that all RPs = will be able to >>>>>>>> use server-provided opaque identifiers for all cases. Account reco= very and >>>>>>>> binding is one such use case where a user-facing identifier like a= n email >>>>>>>> address makes a LOT of sense, for one small example. This is an ar= ray in >>>>>>>> the request and response precisely because a user could be known b= y several >>>>>>>> different identifiers to a party, and an RP will have a better ide= a about >>>>>>>> what kinds of things it wants to correlate against, and it=E2=80= =99s up to the AS >>>>>>>> to provide that mapping. I think that if we don=E2=80=99t define a= way to describe >>>>>>>> the format, the =E2=80=9Cas_id=E2=80=9D field is going to get stru= cture back-patched onto >>>>>>>> it like is being proposed here: >>>>>>>> >>>>>>>> https://mattrglobal.github.io/oidc-portable-identities/ >>>>>>>> >>>>>>>> I=E2=80=99m personally not a fan of that approach as it mixes the = data >>>>>>>> layering too much, and you end up making guesses about whether a f= ield is >>>>>>>> meaningful or a pointer. I think GNAP will be much better served b= y using a >>>>>>>> data structure for this from the start. DIDs should be another =E2= =80=9Cformat=E2=80=9D of >>>>>>>> the subject identifier. I don=E2=80=99t think GNAP should define t= his format, and >>>>>>>> I=E2=80=99ve dropped a note to the SECEVENT mailing list asking ab= out adding DIDs >>>>>>>> to the subject identifiers draft before it gets published. DIDs ar= e not >>>>>>>> assertions, even in the cases where they point to fully functional= DID >>>>>>>> documents with user information in them. (And for what it=E2=80=99= s worth, I think >>>>>>>> the OIDC world should also use the SECEVENT draft inside ID Tokens= to solve >>>>>>>> the use case of the draft above). >>>>>>>> >>>>>>>> For the user !=3D RO cases, I think that potentially having a way = to >>>>>>>> signal those two items separately in the request and response coul= d be >>>>>>>> useful. Right now all the user/subject stuff is about identifying = =E2=80=9Cthe user >>>>>>>> that=E2=80=99s currently here at the client instance=E2=80=9D, in = a variety of forms that >>>>>>>> the client instance and AS can negotiate. If the client or AS has = some >>>>>>>> other notion about who the RO is and how that could be separate fr= om the >>>>>>>> current user, we could provide a way to signal that like you=E2=80= =99re proposing >>>>>>>> below. In my mental model, there are going to be a lot of use case= s where >>>>>>>> the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the client at all,= but rather to the AS and is >>>>>>>> based on what the client=E2=80=99s asking for. So I could identify= the current user >>>>>>>> and ask for a specific medical record, and the AS realizes it has = to go bug >>>>>>>> a particular doctor to approve things directly. This is instead of >>>>>>>> interacting with the current user and failing in an awkward way wh= en the >>>>>>>> current user doesn=E2=80=99t have the rights to do things, but som= eone else would. >>>>>>>> But we=E2=80=99d want the system to be able to detect if the curre= nt user is the >>>>>>>> doctor, so we can just interact with them directly. Does that all = track? >>>>>>>> >>>>>>>> =E2=80=94 Justin >>>>>>>> >>>>>>>> On Mar 10, 2021, at 4:10 AM, Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Notice the question mark in the title. Not to be considered as an >>>>>>>> editor's comment. >>>>>>>> This thread intends to provide a detailed comment on the >>>>>>>> interesting feedback by Kristina: "I would catch up on the thread = to >>>>>>>> understand why DIDs are thought to be treated as assertions". >>>>>>>> In the chat, I answered: "Happy to get the discussion on DIDs. >>>>>>>> Actually, could be either or, depending on what we intend to do." = Let me >>>>>>>> expand a bit on that, to make it understandable (didn't have the t= ime >>>>>>>> during the meeting, unfortunately). >>>>>>>> >>>>>>>> This relates to the items described on slides 20 and 34, which I'l= l >>>>>>>> explain further. I'll highlight as transparently as possible what = I think >>>>>>>> would be the benefits and downsides of each. Both are probably via= ble >>>>>>>> options, but they correspond to different scopes and objectives. I= 'll spend >>>>>>>> a bit more time on option 2, since it is a different approach comp= ared to >>>>>>>> the current draft. >>>>>>>> >>>>>>>> *1. The first possibility is to use SECEVENT throughout. * >>>>>>>> In that case, DIDs should be a part of sub_ids (in the core or in >>>>>>>> the extension registry, depending on what Annabelle's WG decides).= More >>>>>>>> generally, the WG would have to decide which additional sub_ids it= needs >>>>>>>> (as per Yaron's comment). >>>>>>>> >>>>>>>> That's obviously the closest to what is described in draft-04. It >>>>>>>> allows a communication of subject information between the client a= nd the >>>>>>>> AS, by using global identifiers (mail, phone, etc.), or using a lo= cal >>>>>>>> opaque reference - i.e. governed by the AS (that's probably what w= e >>>>>>>> would put in the examples, unless someone has a better idea - cf i= ssues #16 >>>>>>>> and #42). >>>>>>>> >>>>>>>> Assertions relate for instance to the proof of presence of the RO. >>>>>>>> The current draft-04 therefore plans for id_tokens and saml2, mayb= e there >>>>>>>> could be other needs later (extension registry). >>>>>>>> >>>>>>>> - Benefits: identifiers are a key component of GNAP, which makes >>>>>>>> integration easier. Possibly one could choose to use DIDs througho= ut. >>>>>>>> - Downsides: email/phone identifiers will probably be used >>>>>>>> throughout by most devs (since that's correlation information they= have in >>>>>>>> their user DB). Which means we should limit what assertions contai= n, to >>>>>>>> avoid doing links between weak global identifiers and hopefully st= ronger >>>>>>>> assertions. That's not really a problem if it's limited to authent= ication >>>>>>>> events mostly (in that perspective, samlv2 could make sense in the= core). >>>>>>>> An assertion is probably a single value then (not an array). >>>>>>>> >>>>>>>> Option 1 can be summarized as: >>>>>>>> >>>>>>>> "subject": { >>>>>>>> "sub_ids": { }, // request and response (SECEVENT -> including >>>>>>>> DID possibly) >>>>>>>> "assertions": [ ], // request and response >>>>>>>> (id_token or samlv2) >>>>>>>> } >>>>>>>> ("hints" do not exist currently, but are partially covered >>>>>>>> separately via "request.user" / the relevance of "principal", disc= ussed in >>>>>>>> the slide, is a question mark too - which is a different discussio= n on >>>>>>>> end-user !=3D RO). >>>>>>>> >>>>>>>> >>>>>>>> *2. An alternate possibility is to use SECEVENT only as input/hint= * >>>>>>>> In that case, DIDs should be a part of assertions (which have a >>>>>>>> different meaning compared to option 1). >>>>>>>> >>>>>>>> The AS only returns an local opaque reference as_ref (while in >>>>>>>> option 1, it was only one of many possibilities). Its only job is = to help >>>>>>>> the client differentiate the response subject. The AS policy might= further >>>>>>>> define the scope of that reference, as suggested in >>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210, >>>>>>>> although I personally viewed that by default as (2) "as_id" an ide= ntifier >>>>>>>> locally unique to that AS for all the RSs. >>>>>>>> >>>>>>>> SECEVENTS are still useful as an input, that's what I presented in >>>>>>>> request.hints.self.sub_ids (but it's the responsibility of the AS = to match >>>>>>>> it with its own reference system - from instance from the email to= AS's >>>>>>>> local record XUT2MFM1XBIKJKSDU8Q). Note: since the slides, a new >>>>>>>> draft-ietf-secevent-subject-identifiers-07 has been published. Not= ably this >>>>>>>> includes an opaque identifier, which the client can use to pass th= e as_ref >>>>>>>> hint to the AS. Thus we wouldn't need any further addition to >>>>>>>> SECEVENT, although hints would benefit from further additions (lik= e DIDs >>>>>>>> for instance). Notice also that subject_types_supported becomes le= ss >>>>>>>> important, because in the worst case scenario, it's simply a hint = that >>>>>>>> wouldn't be understood and therefore taken into account by the AS. >>>>>>>> >>>>>>>> The assertions array has a more important role than in option 1 >>>>>>>> (with the explicit aim of separating between client hints and vali= dated >>>>>>>> info asserted by the AS). It serves as a generic/extendible mappin= g >>>>>>>> structure, e.g. "the AS asserts that opaque reference >>>>>>>> XUT2MFM1XBIKJKSDU8Q is matching with these (more or less >>>>>>>> verifiable) statements." The name assertion therefore corresponds = to the >>>>>>>> responsibility of the AS in delivering those statements (cf should= /must, >>>>>>>> issue #49). Some of these statements relate to identity or auth ev= ents (ex: >>>>>>>> DID, id_token), some might directly be useful for authorization de= cisions >>>>>>>> (like ZKP example in the parental control example). Possibly some = of these >>>>>>>> validated assertions could be reused in next interactions. >>>>>>>> >>>>>>>> Another question that popped-up is the scope of sub_ids. Should >>>>>>>> they be about the same user? (I think so). In the case of remote R= Os >>>>>>>> especially, it might be important that DID be considered as an >>>>>>>> assertion (about someone else's) and not as sub_ids, because the A= S needs >>>>>>>> to be careful about who the client wants to reach (avoid spam, etc= .). This >>>>>>>> is consistent with the rest of discussion on what to do when end-u= ser !=3D >>>>>>>> RO, although using DIDComm might seem a bit early (the paint is ve= ry >>>>>>>> fresh). >>>>>>>> >>>>>>>> Option 2 was summarized as: >>>>>>>> >>>>>>>> // (suggestion only, not as an editor) >>>>>>>> "subject": { >>>>>>>> "as_ref": { // response only (wouldn=E2=80=99t require SECEVENT= ) >>>>>>>> =E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D, >>>>>>>> =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D >>>>>>>> }, >>>>>>>> "assertions": [ ], // request and response >>>>>>>> (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validated b= y the AS) >>>>>>>> >>>>>>>> "hints": { // request only (optional) >>>>>>>> "self": { // replaces request.user (support SECEVENT here) >>>>>>>> =E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque i= n draft-07 - >>>>>>>> that could contain the ref) >>>>>>>> =E2=80=9Cassertions=E2=80=9D: [ ] // see examples: VC on DOB or= ZKP on age >>>>>>>> (wider scope, possibly through extensions) >>>>>>>> }, >>>>>>>> "principal": { // new proposal presented at IETF110 (just an >>>>>>>> idea) >>>>>>>> =E2=80=9Cautomated=E2=80=9D: true, // rule engine >>>>>>>> =E2=80=9Casync=E2=80=9D: { } // remote ROs >>>>>>>> } >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> - Benefits: as_ref is self supporting (no strong coupling with >>>>>>>> SECEVENT), but can still take SECEVENT as an input hint for the AS= . It >>>>>>>> avoids the risk of making an official association between a weak g= lobal >>>>>>>> identifier (e.g. email, used elsewhere) and hopefully stronger loc= al >>>>>>>> assertions. GNAP would be fully agnostic to whatever identity syst= em is >>>>>>>> used, only facilitating interoperability through assertions (secon= d only in >>>>>>>> importance compared to the AS opaque reference). Some assertions (= possibly >>>>>>>> extensions) could also be useful for the AS decision (e.g. VC or Z= KP). >>>>>>>> - Downsides: opaqueness of as_ref is a feature, not a bug. The >>>>>>>> opaque reference is fully managed by the AS, therefore not inheren= tly >>>>>>>> portable (cf portability discussions in OIDC currently). There's n= o >>>>>>>> explicit binding to an official identity, only a contextual mappin= g to AS >>>>>>>> validated assertions. It makes it more difficult to match the iden= tifiers >>>>>>>> from one AS to another or to correlate with the client user DB (st= ill >>>>>>>> possible via assertions, if the AS allows it). Assertions are much= more >>>>>>>> generic (possibly via extensions), but might require a more advanc= ed >>>>>>>> mechanism to request/response only the most relevant information (= which >>>>>>>> makes the AS policy critical here). >>>>>>>> >>>>>>>> I hope that clarifies the reasoning for both options. Again I'm no= t >>>>>>>> saying option 2 is better, just saying the trade-offs are differen= t (+ >>>>>>>> knowing that we need to keep it simple). >>>>>>>> - option 1 puts more in sub_ids and less in assertions >>>>>>>> - option 2 puts less in the reference and more in assertions >>>>>>>> All of this is open to discussion. More generally speaking, on >>>>>>>> every part in orange and question mark (?) I would love your ideas= and >>>>>>>> criticisms. What I intended as an editor is only to highlight wher= e the WG >>>>>>>> has important choices to make, before we can make the related PRs. >>>>>>>> >>>>>>>> A further side comment: IETF EAT RATS was suggested for assertions= , >>>>>>>> but relates more to the client attestations. It was added as a com= ment in >>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, >>>>>>>> which is a distinct topic we'll work on. >>>>>>>> >>>>>>>> Fabien (editor's hat off) >>>>>>>> >>>>>>>> -- >>>>>>>> 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 >>>>>> >>>>> >>>>> This communication, including any attachments, is confidential. If yo= u are not the intended recipient, you should not read it - please contact m= e immediately, destroy it, and do not copy or use any part of this communic= ation or disclose anything about it. Thank you. Please note that this commu= nication does not designate an information system for the purposes of the E= lectronic Transactions Act 2002. >>>>> >>>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> --0000000000002c075f05bdb2bfcf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Thanks, Fabien.

    We need to be verrry c= areful about the shortcuts once we add user and end-user to our spec. RO = =3D subject (of the resource secured by a RS) is clear and independent of a= ny AS or clients. DIDs can be helpful for the RO-RS relationship for authen= tication, encryption, and service endpoints. Authentication can facilitate = pseudonymity by default. Encryption, for example, can allow mediated commun= ications for privacy=C2=A0enhancement.=C2=A0

    When we bring the request = of an end-user into the picture, the DID can apply to someone other than th= e RO / subject. The DID can secure claims that had nothing to do with the= =C2=A0RO-RS (as you point out in #197). Also, in many cases, the subject DI= D known to the requesting party might be different from the DID associated = with the RO at the RS. This promotes privacy through DIDs as same-domain id= entifiers but has to be dealt with at the policy decision point where capab= ilities are filtered.=C2=A0

    =
    Another source of potential confusion comes= from the way we use client. DIDs are generally not associated with a clien= t except to the extent the client is a user-agent such as a mobile wallet o= r an online policy and capabilities agent.

    My suggestion is that we arr= ive at a set of consistent names soon and present them early in the spec - = in what is now Section 1.2 - and avoid using any shortcuts in the rest of t= he spec. I would also suggest we provide examples of the use of DIDs relati= ve to the names we define in 1.2.=C2=A0

    Adrian

    On Tue, Mar 1= 6, 2021 at 10:51 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    =
    Note also that there's issue 197 that discussed = that very question.=C2=A0

    Le mer. 17 mars 2021 =C3=A0 03:34, Fabien Imbault <fabien.imbault@gmail.com> a =C3=A9crit=C2=A0:
    Hi Adrian,

    =
    As the name suggests, it's an identifier for th= e subject (and so, hypothetically, a DID to identify the subject). The text= indeed concerns the subject as the RO, as it is known to the AS.=C2=A0

    But it's easy to make s= hortcuts, because often we end-up dealing with is user =3D end-user =3D RO = =3D subject.=C2=A0

    Fabie= n=C2=A0

    Le mer. 17 mars 2021 =C3=A0 03:10, Adrian Gropper <<= a href=3D"mailto:agropper@healthurl.com" rel=3D"noreferrer noreferrer noref= errer noreferrer" target=3D"_blank">agropper@healthurl.com> a =C3=A9= crit=C2=A0:
    I'm late to this= conversation and confused by Tobias' use of End-User (his caps)=C2=A0a= nd subject. Are we talking about a DID for the subject, the end-user, or bo= th?

    To be clear, in my mind, the subject is in control= =C2=A0of policies and capabilities at the GNAP AS. The end-user is in contr= ol=C2=A0of a client or user agent and a request to the AS. The end-user and= client may or may not have any prior relationship with the AS.

    Adrian

    On Tue, Mar 16, 2021 at 10:00 PM Fabien Imbault &= lt;fabien.imbault@gmail.c= om> wrote:
    Hi Tobias,
    Not yet (none of the current sub= _ids require additional parameters) but if DIDs do get added to subject ide= ntifiers, then it's certainly something we would have to support.=C2=A0=

    There's already a v= ery basic version of that, but only to chose the main type (now called &quo= t;format" in latest draft 07 of SECEVENT), with subject_types_supporte= d in the discovery.=C2=A0

    Thanks for the heads up, it's worth creating an issue or putting a no= te in some existing issue to not forget looking into that.=C2=A0

    Cheers
    Fabi= en


    Le mer. 17 mars 2021 =C3=A0 01:01, Tobias Looker <tob= ias.looker@mattr.global> a =C3=A9crit=C2=A0:
    =
    Hi,

    This is probably out of scope for t= he current conversation but has any thought been had on how the client inst= ance could communicate additional options around what subject identifier ty= pes it supports for cases where the client instance will perhaps be require= d to conduct additional processing on the artifacts returned by the AS? As = an example if the AS chose to identify the subject (End-User) using a DID a= nd wanted to include an additional cryptographic assertion that showed it c= ontrols keys appropriately associated to the DID, then the client may have = wanted to communicate some information up front in their request to ensure = they can perform this additional processing, such as the signature suites i= t supports and in the context of DIDs potentially which DID methods it is c= apable of resolving?

    Thanks,
    3D"Mattr=C2= =A0
    Tobias Looker
    Mattr
    +64 (0) 27 378 0461
    tobias.looker@mattr.g= lobal
    3D"Mattr
    3D"Mattr3D"Mattr3D"Mattr
    =

    This communication, including any attachments= , is confidential. If you are not the intended recipient, you should not re= ad it - please contact me immediately, destroy it, and do not copy or use a= ny part of this communication or disclose anything about it. Thank you. Ple= ase note that this communication does not designate an information system f= or the purposes of the Electronic Transactions Act 2002.
    <= /div>


    On Sat, Mar 13, 2021 at 9:26 PM Fabien Imbault <fabien.imbault@gm= ail.com> wrote:
    Hi = Justin,=C2=A0

    A last wor= d on end-user! =3DRO (again just as food for thought).=C2=A0

    As soon as hints.automated is set to = true, it takes priority over async, which means it's the same model as = the one you describe : the AS has precedence over any other remote contact.= =C2=A0

    So that confirms = the global view that the AS is the one with the authority, and that it migh= t know more than the client.=C2=A0

    Cheers
    Fabien=C2=A0

    Le jeu. 11 mars 2021 =C3=A0 11:44, Fabien Imbault <fabien.imbault@gmail.com> a =C3=A9crit=C2=A0:
    Hi Ju= stin,

    I think that's interesting:
    &qu= ot;For the user !=3D RO cases, I think that potentially having a way to sig= nal those two items separately in the request and response could be useful.= Right now all the user/subject stuff is about identifying =E2=80=9Cthe use= r that=E2=80=99s currently here at the client instance=E2=80=9D, in a varie= ty of forms that the client instance and AS can negotiate. If the client or= AS has some other notion about who the RO is and how that could be separat= e from the current user, we could provide a way to signal that like you=E2= =80=99re proposing below. In my mental model, there are going to be a lot o= f use cases where the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the clien= t at all, but rather to the AS and is based on what the client=E2=80=99s as= king for. So I could identify the current user and ask for a specific medic= al record, and the AS realizes it has to go bug a particular doctor to appr= ove things directly. This is instead of interacting with the current user a= nd failing in an awkward way when the current user doesn=E2=80=99t have the= rights to do things, but someone else would. But we=E2=80=99d want the sys= tem to be able to detect if the current user is the doctor, so we can just = interact with them directly. Does that all track?"

    I agree with the general idea. In the end, that's the AS's re= sponsibility (and also a big part of its value as a policy engine). =C2=A0<= /div>

    Even in the cases - as I suggested - where the cli= ent would be able to signal what it knows (or thinks it knows) about the su= bject, the AS still needs to validate what it can. The client could be an a= ttacker lying to the AS. Or there could be an unintended bug.=C2=A0

    The=C2=A0client still seems like a straightforward source= to gather optional/declarative hints. Which is what request.user is alread= y doing in spirit. In many cases, the AS should go a step further. Validate= cryptographic statements from a more reputable issuer, whatever helps.

    Contacts might be one of the possibilities. I'm n= ot suggesting interact/fail scenarii at all, which I see as anti-ergonomic = (composability with timeouts and fallback is the answer to that). The failu= re I was considering is only for async calls explicitly requested by the cl= ient (which is considered in sequence 1.4.3, and not coming from me), there= 's obviously no way to ensure a remote RO would actually respond when t= he client expects it. If that sequence is considered, realistic failure mod= es should be anticipated and dealt with internally (just like any distribut= ed program would do), is all I'm saying. And so from the outside, there= 's no interact/fail.=C2=A0=C2=A0
    That's the same as in re= al life: when booking a business trip, an employee could either follow the = generic rule (2nd class train ticket) or reach out to his manager, explaini= ng that it's a long trip and that 1st class would be better. The employ= ee knows the manager might not instantly respond, and knows that the absenc= e of an answer means he'll have to go for the 2nd class.=C2=A0

    There will be cases when the=C2=A0client doesn't k= now the=C2=A0RO. I'm not sure if that's a majority of cases, but it= will definitely happen. It could happen when you interact with an organiza= tion or a team and have no idea who's responsible or what delegations a= re in place (some of those cases have been described by Adrian for instance= ).=C2=A0
    There could also be cases where the ownership could be d= istributed (an example was provided when considering remote ROs). Again in = real life, it's not unusual for a decision to fallback on a deputy when= the main decision maker is unavailable. Or there could be an open governan= ce even, but maybe that's one step too far.

    Of= course, if the AS has internal knowledge or other ways to get the informat= ion it should use it. Remains to be seen how we can specify that (cf issue = #49 on should/must). The example with doctor/patient is fine if hardcoded, = but it becomes a problem when we fail to understand the real relationships = in environments of various sensitive nature. How the AS identifies that a s= pecific record requires approval from Doctor Bob might be context dependent= (sometimes it could be a nurse, a team of doctors, another medical organiz= ation, etc.). Maybe you could have various levels of authorizations (extrem= e example: military style classifications), so that it might even be imposs= ible to tell who can be contacted.=C2=A0

    That'= s also why I was suggesting assertions could go beyond authentication event= s, and include cryptographic assertions for authorization purposes. Maybe w= e can even imagine a risk based approach, as in some cases we won't kno= w for sure.=C2=A0

    The difficulty will be to be suf= ficiently generic but simple enough. Maybe we can rule out some cases. Mayb= e remote async contacts are out of scope,=C2=A0because we only want instant= aneous authorizations. Most of those cases are way beyond what OAuth2 does.= I don't know. But what's certain is that the WG should decide what= support for cases where end-user !=3D RO it intends to provide. My discuss= ion was just a very small Chesterston's Fence contribution, even if tha= t seems to have surprised.

    Fabien


    On Wed, Mar 10, 2021 at 8:18 PM Ju= stin Richer <jricher@mit.edu> wrote:
    Hi Fabien= ,

    First, thanks for doing the heavy lift of writing this= topic up. Of these options, I would strongly prefer option (1). The differ= ence between assertions and identifiers is that an assertion is a fully pac= kaged set of attributes, one of which can be an identifier. They are, gener= ally speaking, cryptographically protected bundles. They=E2=80=99re designe= d to carry a bunch of different information about a user and the authentica= tion event in a form that=E2=80=99s independently verifiable and auditable.= SAML assertions (XML document) and ID Tokens (signed JWTs) are the most co= mmon ones we see today, but other formats exist and will keep being invente= d.=C2=A0

    An identifier is a different kind of crea= ture. It is a single statement that identifies the party in question in the= context of the party doing the identification. It=E2=80=99s this full cont= ext that the receiver of the identifier needs to interpret it in. When usin= g a federated identity protocol, each RP is going to have :some: kind of lo= cal user information store that they=E2=80=99re going to tie into, some fie= ld in a database they=E2=80=99ll key off of. It=E2=80=99s just never going = to be the case that all RPs will be able to use server-provided opaque iden= tifiers for all cases. Account recovery and binding is one such use case wh= ere a user-facing identifier like an email address makes a LOT of sense, fo= r one small example. This is an array in the request and response precisely= because a user could be known by several different identifiers to a party,= and an RP will have a better idea about what kinds of things it wants to c= orrelate against, and it=E2=80=99s up to the AS to provide that mapping. I = think that if we don=E2=80=99t define a way to describe the format, the =E2= =80=9Cas_id=E2=80=9D field is going to get structure back-patched onto it l= ike is being proposed here:


    I=E2=80=99m personally not a fan of that approach as it mixes the = data layering too much, and you end up making guesses about whether a field= is meaningful or a pointer. I think GNAP will be much better served by usi= ng a data structure for this from the start. DIDs should be another =E2=80= =9Cformat=E2=80=9D of the subject identifier. I don=E2=80=99t think GNAP sh= ould define this format, and I=E2=80=99ve dropped a note to the SECEVENT ma= iling list asking about adding DIDs to the subject identifiers draft before= it gets published. DIDs are not assertions, even in the cases where they p= oint to fully functional DID documents with user information in them. (And = for what it=E2=80=99s worth, I think the OIDC world should also use the SEC= EVENT draft inside ID Tokens to solve the use case of the draft above).

    For the user !=3D RO cases, I think that potentially = having a way to signal those two items separately in the request and respon= se could be useful. Right now all the user/subject stuff is about identifyi= ng =E2=80=9Cthe user that=E2=80=99s currently here at the client instance= =E2=80=9D, in a variety of forms that the client instance and AS can negoti= ate. If the client or AS has some other notion about who the RO is and how = that could be separate from the current user, we could provide a way to sig= nal that like you=E2=80=99re proposing below. In my mental model, there are= going to be a lot of use cases where the =E2=80=9CRO=E2=80=9D isn=E2=80=99= t known to the client at all, but rather to the AS and is based on what the= client=E2=80=99s asking for. So I could identify the current user and ask = for a specific medical record, and the AS realizes it has to go bug a parti= cular doctor to approve things directly. This is instead of interacting wit= h the current user and failing in an awkward way when the current user does= n=E2=80=99t have the rights to do things, but someone else would. But we=E2= =80=99d want the system to be able to detect if the current user is the doc= tor, so we can just interact with them directly. Does that all track?
    =

    =C2=A0=E2=80=94 Justin

    On Mar 10, 2021, at 4:10 AM, Fabien Imbault <fabien.imb= ault@gmail.com> wrote:

    Hello,
    Notice the question mark in the title. Not to be considered as = an editor's comment.
    This thread intends to provide a detaile= d comment on the interesting=C2=A0feedback by Kristina: "I would catch= up on the thread to understand why DIDs are thought to be treated as asser= tions".
    In the chat, I answered: "Happy to get the disc= ussion on DIDs. Actually, could be either or, depending on what we intend t= o do." Let me expand a bit on that, to make it understandable (didn= 9;t have the time during the meeting, unfortunately).

    <= div>This relates to the items described on slides 20 and 34, which I'll= explain further. I'll highlight as transparently as possible what I th= ink would be the benefits and downsides of each. Both are probably viable o= ptions, but they correspond to different scopes and objectives. I'll sp= end a bit more time on option 2, since it is a different approach compared = to the current draft.

    1. The first possibility is to use SECEVEN= T throughout.=C2=A0
    In that case, DIDs should be a part of su= b_ids (in the core or in the extension registry, depending on what Annabell= e's WG decides). More generally, the WG would have to decide which addi= tional sub_ids it needs (as per Yaron's comment).

    <= div>That's obviously the closest to what is described in draft-04. It a= llows a communication of subject information between the client and the AS,= by using global identifiers (mail, phone, etc.), or using a local opaque r= eference=C2=A0- i.e. governed by the AS (that's probably what we would= =C2=A0put in the examples, unless someone has a better idea - cf issues #16= and #42).=C2=A0

    Assertions relate for instance to= the proof of presence of the RO. The current draft-04 therefore plans for = id_tokens and saml2, maybe there could be other needs later (extension regi= stry).

    - Benefits: identifiers are a key component= of GNAP, which makes integration easier. Possibly one could choose to use = DIDs throughout.
    - Downsides: email/phone identifiers will probab= ly be used throughout by most devs (since that's correlation informatio= n they=C2=A0have in their user DB). Which means we should limit what assert= ions contain, to avoid doing links between weak global identifiers and hope= fully stronger assertions. That's not really a problem if it's limi= ted to authentication events mostly (in that perspective, samlv2 could make= sense in the core). An assertion is probably a single value then (not an a= rray).=C2=A0 =C2=A0

    Option 1 can be summarize= d as:=C2=A0

    "subject= ": {
    =C2=A0=C2=A0=C2=A0"sub_ids": { }, // request and response (SECEVENT -> including DID possi= bly)=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=C2=A0=C2=A0=C2=A0=C2=A0
    = =C2=A0=C2=A0=C2=A0"assertions": [ ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 // request and response (id_token or samlv2)
    }
    ("hints" do not exist currently, but are partial= ly covered separately via "request.user" / the relevance of "= ;principal", discussed in the slide, is a question mark too - which is= a different discussion on end-user !=3D RO).

    <= br>
    2. An alternate possibility is to use SECEVENT only as inp= ut/hint
    In that case, DIDs should be a part of assertions (wh= ich have a different meaning compared to option 1).

    The AS only returns an local opaque reference as_ref (while in option 1, = it was only one of many possibilities). Its only job is to help the client = differentiate the response subject. The AS policy might further define the = scope of that reference, as suggested in=C2=A0ht= tps://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210, although I= personally=C2=A0viewed that by default as=C2=A0(2) "as_id" an id= entifier locally unique to that AS for all the RSs.

    SECEVENTS are still useful as an input, that's what I presented in re= quest.hints.self.sub_ids (but it's the responsibility=C2=A0of the AS to= match it with its own reference system - from instance from the email to A= S's local record XUT2MFM1XBIKJKSDU8Q).=C2=A0Note: since the slides, a n= ew draft-ietf-secevent-subject-identifiers-07 has been published. Notably t= his includes an opaque identifier, which the client can use to pass the as_= ref hint to the AS. Thus we wouldn't need any further addition to SECEV= ENT,=C2=A0although hints would benefit from further additions (like DIDs fo= r instance). Notice also that subject_types_supported becomes less importan= t, because in the worst case scenario, it's simply=C2=A0a hint that wou= ldn't be understood and therefore taken into account by the AS.

    The assertions array has a more important role than in op= tion 1 (with the explicit aim of separating between client hints and valida= ted info asserted by the AS). It serves as a generic/extendible mapping str= ucture, e.g. "the AS asserts that opaque reference=C2=A0XUT2MFM1XBIKJKSDU8Q=C2=A0is matching with these (more or less verifiable) statements."= The name assertion therefore corresponds to the responsibility=C2=A0of the= AS in delivering those statements (cf should/must, issue #49). Some of the= se statements relate to identity or auth events (ex: DID, id_token), some m= ight directly be useful for authorization decisions (like ZKP example in th= e parental control example). Possibly some of these validated assertions co= uld be reused in next interactions.

    Another questi= on that popped-up is the scope of sub_ids. Should they be about the same us= er? (I think so). In the case of remote ROs especially, it might be importa= nt that DID be considered as an assertion=C2=A0(about someone else's) a= nd not as sub_ids, because the AS needs to be careful about who the client = wants to reach (avoid spam, etc.). This is consistent with the rest of disc= ussion on what to do when end-user !=3D RO, although using DIDComm might se= em a bit early (the paint is very fresh).=C2=A0

    Op= tion 2 was summarized as:=C2=A0

    // (suggestion only, not as an editor)=
    &qu= ot;subject": {
    =C2=A0=C2=A0=C2=A0"as_ref": { // response = only (wouldn=E2=80=99t require SECEVENT)
    =E2=80= =9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D, <= /span>
    = =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D=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= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<= /div>
    =C2= =A0=C2=A0=C2=A0"assertions": [ ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 // request and response (id_token/jwkthumb/DID/VC/etc= . -> whatever info can be validated by the AS)

    =C2=A0=C2=A0=C2=A0"hints": { =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request only= (optional)
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"self":= { =C2=A0=C2=A0=C2=A0=E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque in= draft-07 - that could contain the ref)
    =C2=A0= =C2=A0=C2=A0=E2=80=9Cassertions=E2=80=9D: [ ] // see examples: V= C on DOB or ZKP on age (wider scope, possibly through extensions) <= /span>
    },=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=C2=A0=C2=A0=C2=A0
    =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"principal": { // new proposal presented at IETF110 (just an idea)
    =C2=A0 =E2=80=9Cautomated=E2=80=9D: true, // rule eng= ine
    =C2=A0 =E2=80=9Casync=E2= =80=9D: { } // remote ROs
    }=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=C2=A0=C2=A0}
    }<= /div>

    - Benefits: as_ref is self supporting= (no strong coupling with SECEVENT), but can still take SECEVENT as an inpu= t hint for the AS. It avoids the risk of making an official association bet= ween a weak global identifier (e.g. email, used elsewhere) and hopefully st= ronger local assertions. GNAP would be fully agnostic to whatever identity = system is used, only facilitating interoperability through assertions (seco= nd only in importance=C2=A0compared to the AS opaque reference). Some asser= tions (possibly extensions) could also be useful for the AS decision (e.g. = VC or ZKP).
    - Downsides: opaqueness of as_ref is a feature, not a= bug. The opaque reference is fully managed by the AS, therefore not inhere= ntly portable (cf portability discussions in OIDC currently). There's n= o explicit binding to an official identity, only a contextual mapping to AS= validated assertions. It makes it more difficult to match the identifiers = from one AS to another or to correlate with the client user DB (still possi= ble via assertions, if the AS allows it). Assertions are much more generic = (possibly via extensions), but might require a more advanced mechanism=C2= =A0to request/response only the most relevant information (which makes the = AS policy critical here).

    I hope that clarifies th= e=C2=A0reasoning for both options. Again I'm not saying option 2 is bet= ter, just saying the trade-offs are different (+ knowing that we need to ke= ep it simple).
    - option 1 puts more in sub_ids and less in assert= ions
    - option 2 puts less in the reference and more in assertions= =C2=A0
    All of this is open to discussion. More generally speaking= , on every part in orange and question mark (?) I would love your ideas and= criticisms. What I intended as an editor is only to highlight where the WG= has important choices to make, before we can make the related PRs.

    A further side comment: IETF EAT RATS was suggested for a= ssertions, but relates more to the client attestations. It was added as a c= omment in=C2=A0https://github.com/ietf-wg-gnap/gn= ap-core-protocol/issues/44, which is a distinct topic we'll work on= .

    Fabien (editor's hat off)

    --
    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

    This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.
    --
    TXAuth mailing list
    TXAuth@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/txauth
    --0000000000002c075f05bdb2bfcf-- From nobody Tue Mar 16 20:42:44 2021 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 C2E483A190F for ; Tue, 16 Mar 2021 20:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, T_REMOTE_IMAGE=0.01, 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 Ex-wk53AUSmt for ; Tue, 16 Mar 2021 20:42:37 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 4DBC23A190C for ; Tue, 16 Mar 2021 20:42:37 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id m7so20510969iow.7 for ; Tue, 16 Mar 2021 20:42:37 -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=ircOfTOWW1tXKnec5IQiRWZowjm+z7fu5SqGyhfN/BY=; b=VL9I9wW5LMurNJ+l70fQ5o6paRYkgCUAvh6wU1gl+tSdwp70rCehcfiTx44uuQR8mk uJ6v+80qcdEaNb2yy7w147VyVuEF0FRWXzhHRV0eaZ9fK/LOAlZeC91MqUbOCEjjTZaB 9HNKe0OJII5ArMXSm6eS4zyWLdXMZJ84/NAPXZaL2tSW0deauLr2Iv3yfVGeE1+UtUkt RkVaYUKOwuXy/GWg2CDvemlcW8Ze7Blv23yIK/7SSrYJ4N9d9oQ5f6JeZgwgVG7+a7oM 5aULtI/6tKD+/fHK6qLeVNW86SYZ+58rimjPtZR8G65nfrgWzjE8EOVoz0Rrd9F2Wgm/ d88g== 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=ircOfTOWW1tXKnec5IQiRWZowjm+z7fu5SqGyhfN/BY=; b=duud9PitU6DTHbTN37/Wos4QlEbTe++NLIt6QHbta4xD6FqO8FQcVFX3g8QpIRDvEk AzSNpNmfXMMKlB+OZV1i/3tEXklhQJoCIBv/qHdddwVyC8/AogR7wSa6LA12uP/495X5 ugzgaUkVsJ3rXHyQmvRRaFhGLxvPG/admuqRfpfZ7uHR+EkTFxym/2ULiFM69I4eCeye OHIaBbR9+Tr1VpkvgO+qeq7RabYcWEJ27RV0NdvzxZPctWtH0n5dP+egArTuDVjmg3IM AedUaLDTCzMhQJxwx98SGI5UvrRS6odJM/lig3IftWRUrc1/fZ6jC09iffFUpsOhdB1Y Icyg== X-Gm-Message-State: AOAM5326tMsR9V5cb5i6v4QuPa1botyt9OanKdMoKr6tvDYJtKkHzTJF FyvgVw/YTNyix62e0xIpOGtD/8I4+j9GOOy90hQ= X-Google-Smtp-Source: ABdhPJyT0gPV3lSG4n+RdELl2Zss0oBch8YXGQ6D0eYD9/rZCtjtsZNNAfRQox/9uR5cB4PiXL0jkQUzuMHBm2iaCGw= X-Received: by 2002:a05:6602:228f:: with SMTP id d15mr5255390iod.141.1615952555880; Tue, 16 Mar 2021 20:42:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Wed, 17 Mar 2021 04:42:22 +0100 Message-ID: To: Adrian Gropper Cc: Tobias Looker , GNAP Mailing List , Justin Richer Content-Type: multipart/alternative; boundary="00000000000011357805bdb34685" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 03:42:43 -0000 --00000000000011357805bdb34685 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Noted. I agree with that goal. Back to identifiers, even if we'd use DIDs, the scope is restricted to the subject. Fabien Le mer. 17 mars 2021 =C3=A0 04:04, Adrian Gropper = a =C3=A9crit : > Thanks, Fabien. > > We need to be verrry careful about the shortcuts once we add user and > end-user to our spec. RO =3D subject (of the resource secured by a RS) is > clear and independent of any AS or clients. DIDs can be helpful for the > RO-RS relationship for authentication, encryption, and service endpoints. > Authentication can facilitate pseudonymity by default. Encryption, for > example, can allow mediated communications for privacy enhancement. > > When we bring the request of an end-user into the picture, the DID can > apply to someone other than the RO / subject. The DID can secure claims > that had nothing to do with the RO-RS (as you point out in #197). Also, i= n > many cases, the subject DID known to the requesting party might be > different from the DID associated with the RO at the RS. This promotes > privacy through DIDs as same-domain identifiers but has to be dealt with = at > the policy decision point where capabilities are filtered. > > Another source of potential confusion comes from the way we use client. > DIDs are generally not associated with a client except to the extent the > client is a user-agent such as a mobile wallet or an online policy and > capabilities agent. > > My suggestion is that we arrive at a set of consistent names soon and > present them early in the spec - in what is now Section 1.2 - and avoid > using any shortcuts in the rest of the spec. I would also suggest we > provide examples of the use of DIDs relative to the names we define in 1.= 2. > > Adrian > > On Tue, Mar 16, 2021 at 10:51 PM Fabien Imbault > wrote: > >> Note also that there's issue 197 that discussed that very question. >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/197 >> >> Le mer. 17 mars 2021 =C3=A0 03:34, Fabien Imbault >> a =C3=A9crit : >> >>> Hi Adrian, >>> >>> As the name suggests, it's an identifier for the subject (and so, >>> hypothetically, a DID to identify the subject). The text indeed concern= s >>> the subject as the RO, as it is known to the AS. >>> >>> But it's easy to make shortcuts, because often we end-up dealing with i= s >>> user =3D end-user =3D RO =3D subject. >>> >>> Fabien >>> >>> Le mer. 17 mars 2021 =C3=A0 03:10, Adrian Gropper a >>> =C3=A9crit : >>> >>>> I'm late to this conversation and confused by Tobias' use of End-User >>>> (his caps) and subject. Are we talking about a DID for the subject, th= e >>>> end-user, or both? >>>> >>>> To be clear, in my mind, the subject is in control of policies and >>>> capabilities at the GNAP AS. The end-user is in control of a client or= user >>>> agent and a request to the AS. The end-user and client may or may not = have >>>> any prior relationship with the AS. >>>> >>>> Adrian >>>> >>>> On Tue, Mar 16, 2021 at 10:00 PM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Hi Tobias, >>>>> >>>>> Not yet (none of the current sub_ids require additional parameters) >>>>> but if DIDs do get added to subject identifiers, then it's certainly >>>>> something we would have to support. >>>>> >>>>> There's already a very basic version of that, but only to chose the >>>>> main type (now called "format" in latest draft 07 of SECEVENT), with >>>>> subject_types_supported in the discovery. >>>>> >>>>> Thanks for the heads up, it's worth creating an issue or putting a >>>>> note in some existing issue to not forget looking into that. >>>>> >>>>> Cheers >>>>> Fabien >>>>> >>>>> >>>>> Le mer. 17 mars 2021 =C3=A0 01:01, Tobias Looker >>>>> a =C3=A9crit : >>>>> >>>>>> Hi, >>>>>> >>>>>> This is probably out of scope for the current conversation but has >>>>>> any thought been had on how the client instance could communicate >>>>>> additional options around what subject identifier types it supports = for >>>>>> cases where the client instance will perhaps be required to conduct >>>>>> additional processing on the artifacts returned by the AS? As an exa= mple if >>>>>> the AS chose to identify the subject (End-User) using a DID and want= ed to >>>>>> include an additional cryptographic assertion that showed it control= s keys >>>>>> appropriately associated to the DID, then the client may have wanted= to >>>>>> communicate some information up front in their request to ensure the= y can >>>>>> perform this additional processing, such as the signature suites it >>>>>> supports and in the context of DIDs potentially which DID methods it= is >>>>>> capable of resolving? >>>>>> >>>>>> Thanks, >>>>>> [image: Mattr website] >>>>>> *Tobias Looker* >>>>>> Mattr >>>>>> +64 (0) 27 378 0461 >>>>>> tobias.looker@mattr.global >>>>>> [image: Mattr website] [image: Mattr on >>>>>> LinkedIn] [image: >>>>>> Mattr on Twitter] [image: Mattr on >>>>>> Github] >>>>>> This communication, including any attachments, is confidential. If >>>>>> you are not the intended recipient, you should not read it - please = contact >>>>>> me immediately, destroy it, and do not copy or use any part of this >>>>>> communication or disclose anything about it. Thank you. Please note = that >>>>>> this communication does not designate an information system for the >>>>>> purposes of the Electronic Transactions Act 2002. >>>>>> >>>>>> >>>>>> On Sat, Mar 13, 2021 at 9:26 PM Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>>> Hi Justin, >>>>>>> >>>>>>> A last word on end-user! =3DRO (again just as food for thought). >>>>>>> >>>>>>> As soon as hints.automated is set to true, it takes priority over >>>>>>> async, which means it's the same model as the one you describe : th= e AS has >>>>>>> precedence over any other remote contact. >>>>>>> >>>>>>> So that confirms the global view that the AS is the one with the >>>>>>> authority, and that it might know more than the client. >>>>>>> >>>>>>> Cheers >>>>>>> Fabien >>>>>>> >>>>>>> Le jeu. 11 mars 2021 =C3=A0 11:44, Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> a =C3=A9crit : >>>>>>> >>>>>>>> Hi Justin, >>>>>>>> >>>>>>>> I think that's interesting: >>>>>>>> "For the user !=3D RO cases, I think that potentially having a way= to >>>>>>>> signal those two items separately in the request and response coul= d be >>>>>>>> useful. Right now all the user/subject stuff is about identifying = =E2=80=9Cthe user >>>>>>>> that=E2=80=99s currently here at the client instance=E2=80=9D, in = a variety of forms that >>>>>>>> the client instance and AS can negotiate. If the client or AS has = some >>>>>>>> other notion about who the RO is and how that could be separate fr= om the >>>>>>>> current user, we could provide a way to signal that like you=E2=80= =99re proposing >>>>>>>> below. In my mental model, there are going to be a lot of use case= s where >>>>>>>> the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the client at all,= but rather to the AS and is >>>>>>>> based on what the client=E2=80=99s asking for. So I could identify= the current user >>>>>>>> and ask for a specific medical record, and the AS realizes it has = to go bug >>>>>>>> a particular doctor to approve things directly. This is instead of >>>>>>>> interacting with the current user and failing in an awkward way wh= en the >>>>>>>> current user doesn=E2=80=99t have the rights to do things, but som= eone else would. >>>>>>>> But we=E2=80=99d want the system to be able to detect if the curre= nt user is the >>>>>>>> doctor, so we can just interact with them directly. Does that all = track?" >>>>>>>> >>>>>>>> I agree with the general idea. In the end, that's the AS's >>>>>>>> responsibility (and also a big part of its value as a policy engin= e). >>>>>>>> >>>>>>>> Even in the cases - as I suggested - where the client would be abl= e >>>>>>>> to signal what it knows (or thinks it knows) about the subject, th= e AS >>>>>>>> still needs to validate what it can. The client could be an attack= er lying >>>>>>>> to the AS. Or there could be an unintended bug. >>>>>>>> >>>>>>>> The client still seems like a straightforward source to gather >>>>>>>> optional/declarative hints. Which is what request.user is already = doing in >>>>>>>> spirit. In many cases, the AS should go a step further. Validate >>>>>>>> cryptographic statements from a more reputable issuer, whatever he= lps. >>>>>>>> >>>>>>>> Contacts might be one of the possibilities. I'm not suggesting >>>>>>>> interact/fail scenarii at all, which I see as anti-ergonomic (comp= osability >>>>>>>> with timeouts and fallback is the answer to that). The failure I w= as >>>>>>>> considering is only for async calls explicitly requested by the cl= ient >>>>>>>> (which is considered in sequence 1.4.3, and not coming from me), t= here's >>>>>>>> obviously no way to ensure a remote RO would actually respond when= the >>>>>>>> client expects it. If that sequence is considered, realistic failu= re modes >>>>>>>> should be anticipated and dealt with internally (just like any dis= tributed >>>>>>>> program would do), is all I'm saying. And so from the outside, the= re's no >>>>>>>> interact/fail. >>>>>>>> That's the same as in real life: when booking a business trip, an >>>>>>>> employee could either follow the generic rule (2nd class train tic= ket) or >>>>>>>> reach out to his manager, explaining that it's a long trip and tha= t 1st >>>>>>>> class would be better. The employee knows the manager might not in= stantly >>>>>>>> respond, and knows that the absence of an answer means he'll have = to go for >>>>>>>> the 2nd class. >>>>>>>> >>>>>>>> There will be cases when the client doesn't know the RO. I'm not >>>>>>>> sure if that's a majority of cases, but it will definitely happen.= It could >>>>>>>> happen when you interact with an organization or a team and have n= o idea >>>>>>>> who's responsible or what delegations are in place (some of those = cases >>>>>>>> have been described by Adrian for instance). >>>>>>>> There could also be cases where the ownership could be distributed >>>>>>>> (an example was provided when considering remote ROs). Again in re= al life, >>>>>>>> it's not unusual for a decision to fallback on a deputy when the m= ain >>>>>>>> decision maker is unavailable. Or there could be an open governanc= e even, >>>>>>>> but maybe that's one step too far. >>>>>>>> >>>>>>>> Of course, if the AS has internal knowledge or other ways to get >>>>>>>> the information it should use it. Remains to be seen how we can sp= ecify >>>>>>>> that (cf issue #49 on should/must). The example with doctor/patien= t is fine >>>>>>>> if hardcoded, but it becomes a problem when we fail to understand = the real >>>>>>>> relationships in environments of various sensitive nature. How the= AS >>>>>>>> identifies that a specific record requires approval from Doctor Bo= b might >>>>>>>> be context dependent (sometimes it could be a nurse, a team of doc= tors, >>>>>>>> another medical organization, etc.). Maybe you could have various = levels of >>>>>>>> authorizations (extreme example: military style classifications), = so that >>>>>>>> it might even be impossible to tell who can be contacted. >>>>>>>> >>>>>>>> That's also why I was suggesting assertions could go beyond >>>>>>>> authentication events, and include cryptographic assertions for >>>>>>>> authorization purposes. Maybe we can even imagine a risk based app= roach, as >>>>>>>> in some cases we won't know for sure. >>>>>>>> >>>>>>>> The difficulty will be to be sufficiently generic but simple >>>>>>>> enough. Maybe we can rule out some cases. Maybe remote async conta= cts are >>>>>>>> out of scope, because we only want instantaneous authorizations. M= ost of >>>>>>>> those cases are way beyond what OAuth2 does. I don't know. But wha= t's >>>>>>>> certain is that the WG should decide what support for cases where = end-user >>>>>>>> !=3D RO it intends to provide. My discussion was just a very small >>>>>>>> Chesterston's Fence contribution, even if that seems to have surpr= ised. >>>>>>>> >>>>>>>> Fabien >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Mar 10, 2021 at 8:18 PM Justin Richer >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Fabien, >>>>>>>>> >>>>>>>>> First, thanks for doing the heavy lift of writing this topic up. >>>>>>>>> Of these options, I would strongly prefer option (1). The differe= nce >>>>>>>>> between assertions and identifiers is that an assertion is a full= y packaged >>>>>>>>> set of attributes, one of which can be an identifier. They are, g= enerally >>>>>>>>> speaking, cryptographically protected bundles. They=E2=80=99re de= signed to carry a >>>>>>>>> bunch of different information about a user and the authenticatio= n event in >>>>>>>>> a form that=E2=80=99s independently verifiable and auditable. SAM= L assertions (XML >>>>>>>>> document) and ID Tokens (signed JWTs) are the most common ones we= see >>>>>>>>> today, but other formats exist and will keep being invented. >>>>>>>>> >>>>>>>>> An identifier is a different kind of creature. It is a single >>>>>>>>> statement that identifies the party in question in the context of= the party >>>>>>>>> doing the identification. It=E2=80=99s this full context that the= receiver of the >>>>>>>>> identifier needs to interpret it in. When using a federated ident= ity >>>>>>>>> protocol, each RP is going to have :some: kind of local user info= rmation >>>>>>>>> store that they=E2=80=99re going to tie into, some field in a dat= abase they=E2=80=99ll key >>>>>>>>> off of. It=E2=80=99s just never going to be the case that all RPs= will be able to >>>>>>>>> use server-provided opaque identifiers for all cases. Account rec= overy and >>>>>>>>> binding is one such use case where a user-facing identifier like = an email >>>>>>>>> address makes a LOT of sense, for one small example. This is an a= rray in >>>>>>>>> the request and response precisely because a user could be known = by several >>>>>>>>> different identifiers to a party, and an RP will have a better id= ea about >>>>>>>>> what kinds of things it wants to correlate against, and it=E2=80= =99s up to the AS >>>>>>>>> to provide that mapping. I think that if we don=E2=80=99t define = a way to describe >>>>>>>>> the format, the =E2=80=9Cas_id=E2=80=9D field is going to get str= ucture back-patched onto >>>>>>>>> it like is being proposed here: >>>>>>>>> >>>>>>>>> https://mattrglobal.github.io/oidc-portable-identities/ >>>>>>>>> >>>>>>>>> I=E2=80=99m personally not a fan of that approach as it mixes the= data >>>>>>>>> layering too much, and you end up making guesses about whether a = field is >>>>>>>>> meaningful or a pointer. I think GNAP will be much better served = by using a >>>>>>>>> data structure for this from the start. DIDs should be another = =E2=80=9Cformat=E2=80=9D of >>>>>>>>> the subject identifier. I don=E2=80=99t think GNAP should define = this format, and >>>>>>>>> I=E2=80=99ve dropped a note to the SECEVENT mailing list asking a= bout adding DIDs >>>>>>>>> to the subject identifiers draft before it gets published. DIDs a= re not >>>>>>>>> assertions, even in the cases where they point to fully functiona= l DID >>>>>>>>> documents with user information in them. (And for what it=E2=80= =99s worth, I think >>>>>>>>> the OIDC world should also use the SECEVENT draft inside ID Token= s to solve >>>>>>>>> the use case of the draft above). >>>>>>>>> >>>>>>>>> For the user !=3D RO cases, I think that potentially having a way= to >>>>>>>>> signal those two items separately in the request and response cou= ld be >>>>>>>>> useful. Right now all the user/subject stuff is about identifying= =E2=80=9Cthe user >>>>>>>>> that=E2=80=99s currently here at the client instance=E2=80=9D, in= a variety of forms that >>>>>>>>> the client instance and AS can negotiate. If the client or AS has= some >>>>>>>>> other notion about who the RO is and how that could be separate f= rom the >>>>>>>>> current user, we could provide a way to signal that like you=E2= =80=99re proposing >>>>>>>>> below. In my mental model, there are going to be a lot of use cas= es where >>>>>>>>> the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the client at all= , but rather to the AS and is >>>>>>>>> based on what the client=E2=80=99s asking for. So I could identif= y the current user >>>>>>>>> and ask for a specific medical record, and the AS realizes it has= to go bug >>>>>>>>> a particular doctor to approve things directly. This is instead o= f >>>>>>>>> interacting with the current user and failing in an awkward way w= hen the >>>>>>>>> current user doesn=E2=80=99t have the rights to do things, but so= meone else would. >>>>>>>>> But we=E2=80=99d want the system to be able to detect if the curr= ent user is the >>>>>>>>> doctor, so we can just interact with them directly. Does that all= track? >>>>>>>>> >>>>>>>>> =E2=80=94 Justin >>>>>>>>> >>>>>>>>> On Mar 10, 2021, at 4:10 AM, Fabien Imbault < >>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Notice the question mark in the title. Not to be considered as an >>>>>>>>> editor's comment. >>>>>>>>> This thread intends to provide a detailed comment on the >>>>>>>>> interesting feedback by Kristina: "I would catch up on the thread= to >>>>>>>>> understand why DIDs are thought to be treated as assertions". >>>>>>>>> In the chat, I answered: "Happy to get the discussion on DIDs. >>>>>>>>> Actually, could be either or, depending on what we intend to do."= Let me >>>>>>>>> expand a bit on that, to make it understandable (didn't have the = time >>>>>>>>> during the meeting, unfortunately). >>>>>>>>> >>>>>>>>> This relates to the items described on slides 20 and 34, which >>>>>>>>> I'll explain further. I'll highlight as transparently as possible= what I >>>>>>>>> think would be the benefits and downsides of each. Both are proba= bly viable >>>>>>>>> options, but they correspond to different scopes and objectives. = I'll spend >>>>>>>>> a bit more time on option 2, since it is a different approach com= pared to >>>>>>>>> the current draft. >>>>>>>>> >>>>>>>>> *1. The first possibility is to use SECEVENT throughout. * >>>>>>>>> In that case, DIDs should be a part of sub_ids (in the core or in >>>>>>>>> the extension registry, depending on what Annabelle's WG decides)= . More >>>>>>>>> generally, the WG would have to decide which additional sub_ids i= t needs >>>>>>>>> (as per Yaron's comment). >>>>>>>>> >>>>>>>>> That's obviously the closest to what is described in draft-04. It >>>>>>>>> allows a communication of subject information between the client = and the >>>>>>>>> AS, by using global identifiers (mail, phone, etc.), or using a l= ocal >>>>>>>>> opaque reference - i.e. governed by the AS (that's probably what = we >>>>>>>>> would put in the examples, unless someone has a better idea - cf = issues #16 >>>>>>>>> and #42). >>>>>>>>> >>>>>>>>> Assertions relate for instance to the proof of presence of the RO= . >>>>>>>>> The current draft-04 therefore plans for id_tokens and saml2, may= be there >>>>>>>>> could be other needs later (extension registry). >>>>>>>>> >>>>>>>>> - Benefits: identifiers are a key component of GNAP, which makes >>>>>>>>> integration easier. Possibly one could choose to use DIDs through= out. >>>>>>>>> - Downsides: email/phone identifiers will probably be used >>>>>>>>> throughout by most devs (since that's correlation information the= y have in >>>>>>>>> their user DB). Which means we should limit what assertions conta= in, to >>>>>>>>> avoid doing links between weak global identifiers and hopefully s= tronger >>>>>>>>> assertions. That's not really a problem if it's limited to authen= tication >>>>>>>>> events mostly (in that perspective, samlv2 could make sense in th= e core). >>>>>>>>> An assertion is probably a single value then (not an array). >>>>>>>>> >>>>>>>>> Option 1 can be summarized as: >>>>>>>>> >>>>>>>>> "subject": { >>>>>>>>> "sub_ids": { }, // request and response (SECEVENT -> including >>>>>>>>> DID possibly) >>>>>>>>> "assertions": [ ], // request and response >>>>>>>>> (id_token or samlv2) >>>>>>>>> } >>>>>>>>> ("hints" do not exist currently, but are partially covered >>>>>>>>> separately via "request.user" / the relevance of "principal", dis= cussed in >>>>>>>>> the slide, is a question mark too - which is a different discussi= on on >>>>>>>>> end-user !=3D RO). >>>>>>>>> >>>>>>>>> >>>>>>>>> *2. An alternate possibility is to use SECEVENT only as input/hin= t* >>>>>>>>> In that case, DIDs should be a part of assertions (which have a >>>>>>>>> different meaning compared to option 1). >>>>>>>>> >>>>>>>>> The AS only returns an local opaque reference as_ref (while in >>>>>>>>> option 1, it was only one of many possibilities). Its only job is= to help >>>>>>>>> the client differentiate the response subject. The AS policy migh= t further >>>>>>>>> define the scope of that reference, as suggested in >>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210, >>>>>>>>> although I personally viewed that by default as (2) "as_id" an id= entifier >>>>>>>>> locally unique to that AS for all the RSs. >>>>>>>>> >>>>>>>>> SECEVENTS are still useful as an input, that's what I presented i= n >>>>>>>>> request.hints.self.sub_ids (but it's the responsibility of the AS= to match >>>>>>>>> it with its own reference system - from instance from the email t= o AS's >>>>>>>>> local record XUT2MFM1XBIKJKSDU8Q). Note: since the slides, a new >>>>>>>>> draft-ietf-secevent-subject-identifiers-07 has been published. No= tably this >>>>>>>>> includes an opaque identifier, which the client can use to pass t= he as_ref >>>>>>>>> hint to the AS. Thus we wouldn't need any further addition to >>>>>>>>> SECEVENT, although hints would benefit from further additions (li= ke DIDs >>>>>>>>> for instance). Notice also that subject_types_supported becomes l= ess >>>>>>>>> important, because in the worst case scenario, it's simply a hint= that >>>>>>>>> wouldn't be understood and therefore taken into account by the AS= . >>>>>>>>> >>>>>>>>> The assertions array has a more important role than in option 1 >>>>>>>>> (with the explicit aim of separating between client hints and val= idated >>>>>>>>> info asserted by the AS). It serves as a generic/extendible mappi= ng >>>>>>>>> structure, e.g. "the AS asserts that opaque reference >>>>>>>>> XUT2MFM1XBIKJKSDU8Q is matching with these (more or less >>>>>>>>> verifiable) statements." The name assertion therefore corresponds= to the >>>>>>>>> responsibility of the AS in delivering those statements (cf shoul= d/must, >>>>>>>>> issue #49). Some of these statements relate to identity or auth e= vents (ex: >>>>>>>>> DID, id_token), some might directly be useful for authorization d= ecisions >>>>>>>>> (like ZKP example in the parental control example). Possibly some= of these >>>>>>>>> validated assertions could be reused in next interactions. >>>>>>>>> >>>>>>>>> Another question that popped-up is the scope of sub_ids. Should >>>>>>>>> they be about the same user? (I think so). In the case of remote = ROs >>>>>>>>> especially, it might be important that DID be considered as an >>>>>>>>> assertion (about someone else's) and not as sub_ids, because the = AS needs >>>>>>>>> to be careful about who the client wants to reach (avoid spam, et= c.). This >>>>>>>>> is consistent with the rest of discussion on what to do when end-= user !=3D >>>>>>>>> RO, although using DIDComm might seem a bit early (the paint is v= ery >>>>>>>>> fresh). >>>>>>>>> >>>>>>>>> Option 2 was summarized as: >>>>>>>>> >>>>>>>>> // (suggestion only, not as an editor) >>>>>>>>> "subject": { >>>>>>>>> "as_ref": { // response only (wouldn=E2=80=99t require SECEVEN= T) >>>>>>>>> =E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D, >>>>>>>>> =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D >>>>>>>>> }, >>>>>>>>> "assertions": [ ], // request and response >>>>>>>>> (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validated = by the AS) >>>>>>>>> >>>>>>>>> "hints": { // request only (optional) >>>>>>>>> "self": { // replaces request.user (support SECEVENT here) >>>>>>>>> =E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque = in draft-07 - >>>>>>>>> that could contain the ref) >>>>>>>>> =E2=80=9Cassertions=E2=80=9D: [ ] // see examples: VC on DOB o= r ZKP on age >>>>>>>>> (wider scope, possibly through extensions) >>>>>>>>> }, >>>>>>>>> "principal": { // new proposal presented at IETF110 (just >>>>>>>>> an idea) >>>>>>>>> =E2=80=9Cautomated=E2=80=9D: true, // rule engine >>>>>>>>> =E2=80=9Casync=E2=80=9D: { } // remote ROs >>>>>>>>> } >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> - Benefits: as_ref is self supporting (no strong coupling with >>>>>>>>> SECEVENT), but can still take SECEVENT as an input hint for the A= S. It >>>>>>>>> avoids the risk of making an official association between a weak = global >>>>>>>>> identifier (e.g. email, used elsewhere) and hopefully stronger lo= cal >>>>>>>>> assertions. GNAP would be fully agnostic to whatever identity sys= tem is >>>>>>>>> used, only facilitating interoperability through assertions (seco= nd only in >>>>>>>>> importance compared to the AS opaque reference). Some assertions = (possibly >>>>>>>>> extensions) could also be useful for the AS decision (e.g. VC or = ZKP). >>>>>>>>> - Downsides: opaqueness of as_ref is a feature, not a bug. The >>>>>>>>> opaque reference is fully managed by the AS, therefore not inhere= ntly >>>>>>>>> portable (cf portability discussions in OIDC currently). There's = no >>>>>>>>> explicit binding to an official identity, only a contextual mappi= ng to AS >>>>>>>>> validated assertions. It makes it more difficult to match the ide= ntifiers >>>>>>>>> from one AS to another or to correlate with the client user DB (s= till >>>>>>>>> possible via assertions, if the AS allows it). Assertions are muc= h more >>>>>>>>> generic (possibly via extensions), but might require a more advan= ced >>>>>>>>> mechanism to request/response only the most relevant information = (which >>>>>>>>> makes the AS policy critical here). >>>>>>>>> >>>>>>>>> I hope that clarifies the reasoning for both options. Again I'm >>>>>>>>> not saying option 2 is better, just saying the trade-offs are dif= ferent (+ >>>>>>>>> knowing that we need to keep it simple). >>>>>>>>> - option 1 puts more in sub_ids and less in assertions >>>>>>>>> - option 2 puts less in the reference and more in assertions >>>>>>>>> All of this is open to discussion. More generally speaking, on >>>>>>>>> every part in orange and question mark (?) I would love your idea= s and >>>>>>>>> criticisms. What I intended as an editor is only to highlight whe= re the WG >>>>>>>>> has important choices to make, before we can make the related PRs= . >>>>>>>>> >>>>>>>>> A further side comment: IETF EAT RATS was suggested for >>>>>>>>> assertions, but relates more to the client attestations. It was a= dded as a >>>>>>>>> comment in >>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, >>>>>>>>> which is a distinct topic we'll work on. >>>>>>>>> >>>>>>>>> Fabien (editor's hat off) >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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 >>>>>>> >>>>>> >>>>>> This communication, including any attachments, is confidential. If y= ou are not the intended recipient, you should not read it - please contact = me immediately, destroy it, and do not copy or use any part of this communi= cation or disclose anything about it. Thank you. Please note that this comm= unication does not designate an information system for the purposes of the = Electronic Transactions Act 2002. >>>>>> >>>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> --00000000000011357805bdb34685 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Noted. I agree with that goal.

    =
    Back to identifiers, even if we'd use DIDs, the= scope is restricted to the subject.=C2=A0=C2=A0
    Fabien


    Le mer. 17 mars 2021 =C3=A0 04:04, Adria= n Gropper <agropper@healthurl.= com> a =C3=A9crit=C2=A0:
    Thanks, Fabien.

    We need to be verrry car= eful about the shortcuts once we add user and end-user to our spec. RO =3D = subject (of the resource secured by a RS) is clear and independent of any A= S or clients. DIDs can be helpful for the RO-RS relationship for authentica= tion, encryption, and service endpoints. Authentication can facilitate pseu= donymity by default. Encryption, for example, can allow mediated communicat= ions for privacy=C2=A0enhancement.=C2=A0

    When we bring the request of a= n end-user into the picture, the DID can apply to someone other than the RO= / subject. The DID can secure claims that had nothing to do with the=C2=A0= RO-RS (as you point out in #197). Also, in many cases, the subject DID know= n to the requesting party might be different from the DID associated with t= he RO at the RS. This promotes privacy through DIDs as same-domain identifi= ers but has to be dealt with at the policy decision point where capabilitie= s are filtered.=C2=A0

    Another source of potential confusion comes from = the way we use client. DIDs are generally not associated with a client exce= pt to the extent the client is a user-agent such as a mobile wallet or an o= nline policy and capabilities agent.
    <= br>
    My suggestion is that we arrive at= a set of consistent names soon and present them early in the spec - in wha= t is now Section 1.2 - and avoid using any shortcuts in the rest of the spe= c. I would also suggest we provide examples of the use of DIDs relative to = the names we define in 1.2.=C2=A0

    =
    Adrian

    On Tue, Mar 16, 202= 1 at 10:51 PM Fabien Imbault <fabien.imbault@gmail.com> wro= te:
    Note also that there&#= 39;s issue 197 that discussed that very question.=C2=A0

    Le mer. 17 mar= s 2021 =C3=A0 03:34, Fabien Imbault <fabien.imbault@gmail.com> a =C3=A9crit=C2=A0:
    Hi Adrian,

    As the name suggests, it's an identifier for the subject (and so= , hypothetically, a DID to identify the subject). The text indeed concerns = the subject as the RO, as it is known to the AS.=C2=A0

    But it's easy to make shortcuts, because= often we end-up dealing with is user =3D end-user =3D RO =3D subject.=C2= =A0

    Fabien=C2=A0
    Le mer. 17 mars 2021 =C3=A0 03:10, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit= =C2=A0:
    I'm late to this con= versation and confused by Tobias' use of End-User (his caps)=C2=A0and s= ubject. Are we talking about a DID for the subject, the end-user, or both?<= div>
    To be clear, in my mind, the subject is in control=C2=A0= of policies and capabilities at the GNAP AS. The end-user is in control=C2= =A0of a client or user agent and a request to the AS. The end-user and clie= nt may or may not have any prior relationship with the AS.

    Adrian

    On Tue, Mar 16, 2021 at 10:00 PM Fabien Imbault <fabien.imbault@g= mail.com> wrote:
    Hi Tobi= as,

    Not yet (none of the curre= nt sub_ids require additional parameters) but if DIDs do get added to subje= ct identifiers, then it's certainly something we would have to support.= =C2=A0

    There's alrea= dy a very basic version of that, but only to chose the main type (now calle= d "format" in latest draft 07 of SECEVENT), with subject_types_su= pported in the discovery.=C2=A0

    Thanks for the heads up, it's worth creating an issue or putt= ing a note in some existing issue to not forget looking into that.=C2=A0

    Cheers
    Fabien


    Le mer. 17 mars 2021 =C3=A0 01:01, Tobias Looker= <tobias.looker@mattr.global> a =C3=A9crit=C2=A0:
    Hi,

    This is probably out of scop= e for the current conversation but has any thought been had on how the clie= nt instance could communicate additional options around what subject identi= fier types it supports for cases where the client instance will perhaps be = required to conduct additional processing on the artifacts returned by the = AS? As an example if the AS chose to identify the subject (End-User) using = a DID and wanted to include an additional cryptographic assertion that show= ed it controls keys appropriately associated to the DID, then the client ma= y have wanted to communicate some information up front in their request to = ensure they can perform this additional processing, such as the signature s= uites it supports and in the context of DIDs potentially which DID methods = it is capable of resolving?

    Thanks,
    =
    =C2=A0=
    Tobias Looker
    Mattr
    +64 (0) 27 378 0461
    t= obias.looker@mattr.global
    3D"=3D"Mattr3D"Mattr3D"Mattr

    This c= ommunication, including any attachments, is confidential. If you are not th= e intended recipient, you should not read it - please contact me immediatel= y, destroy it, and do not copy or use any part of this communication or dis= close anything about it. Thank you. Please note that this communication doe= s not designate an information system for the purposes of the Electronic Tr= ansactions Act 2002.


    On Sat, Mar 13,= 2021 at 9:26 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Justin,=C2=A0

    A last word on end-user! =3DRO (aga= in just as food for thought).=C2=A0

    As soon as hints.automated is set to true, it takes priority ov= er async, which means it's the same model as the one you describe : the= AS has precedence over any other remote contact.=C2=A0

    So that confirms the global view that the A= S is the one with the authority, and that it might know more than the clien= t.=C2=A0

    Cheers
    Fabien=C2=A0

    Le jeu. 11 mars 2= 021 =C3=A0 11:44, Fabien Imbault <fabien.imbault@gmail.com> a =C3=A9= crit=C2=A0:
    Hi Justin,

    <= /div>
    I think that's interesting:
    "For the user= !=3D RO cases, I think that potentially having a way to signal those two i= tems separately in the request and response could be useful. Right now all = the user/subject stuff is about identifying =E2=80=9Cthe user that=E2=80=99= s currently here at the client instance=E2=80=9D, in a variety of forms tha= t the client instance and AS can negotiate. If the client or AS has some ot= her notion about who the RO is and how that could be separate from the curr= ent user, we could provide a way to signal that like you=E2=80=99re proposi= ng below. In my mental model, there are going to be a lot of use cases wher= e the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the client at all, but ra= ther to the AS and is based on what the client=E2=80=99s asking for. So I c= ould identify the current user and ask for a specific medical record, and t= he AS realizes it has to go bug a particular doctor to approve things direc= tly. This is instead of interacting with the current user and failing in an= awkward way when the current user doesn=E2=80=99t have the rights to do th= ings, but someone else would. But we=E2=80=99d want the system to be able t= o detect if the current user is the doctor, so we can just interact with th= em directly. Does that all track?"

    I agree wi= th the general idea. In the end, that's the AS's responsibility (an= d also a big part of its value as a policy engine). =C2=A0

    Even in the cases - as I suggested - where the client would be abl= e to signal what it knows (or thinks it knows) about the subject, the AS st= ill needs to validate what it can. The client could be an attacker lying to= the AS. Or there could be an unintended bug.=C2=A0

    The=C2=A0client still seems like a straightforward source to gather optio= nal/declarative hints. Which is what request.user is already doing in spiri= t. In many cases, the AS should go a step further. Validate cryptographic s= tatements from a more reputable issuer, whatever helps.

    Contacts might be one of the possibilities. I'm not suggesting in= teract/fail scenarii at all, which I see as anti-ergonomic (composability w= ith timeouts and fallback is the answer to that). The failure I was conside= ring is only for async calls explicitly requested by the client (which is c= onsidered in sequence 1.4.3, and not coming from me), there's obviously= no way to ensure a remote RO would actually respond when the client expect= s it. If that sequence is considered, realistic failure modes should be ant= icipated and dealt with internally (just like any distributed program would= do), is all I'm saying. And so from the outside, there's no intera= ct/fail.=C2=A0=C2=A0
    That's the same as in real life: when bo= oking a business trip, an employee could either follow the generic rule (2n= d class train ticket) or reach out to his manager, explaining that it's= a long trip and that 1st class would be better. The employee knows the man= ager might not instantly respond, and knows that the absence of an answer m= eans he'll have to go for the 2nd class.=C2=A0

    =
    There will be cases when the=C2=A0client doesn't know the=C2=A0RO.= I'm not sure if that's a majority of cases, but it will definitely= happen. It could happen when you interact with an organization or a team a= nd have no idea who's responsible or what delegations are in place (som= e of those cases have been described by Adrian for instance).=C2=A0
    There could also be cases where the ownership could be distributed (an e= xample was provided when considering remote ROs). Again in real life, it= 9;s not unusual for a decision to fallback on a deputy when the main decisi= on maker is unavailable. Or there could be an open governance even, but may= be that's one step too far.

    Of course, if the = AS has internal knowledge or other ways to get the information it should us= e it. Remains to be seen how we can specify that (cf issue #49 on should/mu= st). The example with doctor/patient is fine if hardcoded, but it becomes a= problem when we fail to understand the real relationships in environments = of various sensitive nature. How the AS identifies that a specific record r= equires approval from Doctor Bob might be context dependent (sometimes it c= ould be a nurse, a team of doctors, another medical organization, etc.). Ma= ybe you could have various levels of authorizations (extreme example: milit= ary style classifications), so that it might even be impossible to tell who= can be contacted.=C2=A0

    That's also why I was= suggesting assertions could go beyond authentication events, and include c= ryptographic assertions for authorization purposes. Maybe we can even imagi= ne a risk based approach, as in some cases we won't know for sure.=C2= =A0

    The difficulty will be to be sufficiently gene= ric but simple enough. Maybe we can rule out some cases. Maybe remote async= contacts are out of scope,=C2=A0because we only want instantaneous authori= zations. Most of those cases are way beyond what OAuth2 does. I don't k= now. But what's certain is that the WG should decide what support for c= ases where end-user !=3D RO it intends to provide. My discussion was just a= very small Chesterston's Fence contribution, even if that seems to hav= e surprised.

    Fabien
    <= div>

    On Wed, Mar 10, 2021 at 8:18 PM Justin Richer &l= t;jricher@mit.edu> wrote:
    Hi Fabien,
    First, thanks for doing the heavy lift of writing this to= pic up. Of these options, I would strongly prefer option (1). The differenc= e between assertions and identifiers is that an assertion is a fully packag= ed set of attributes, one of which can be an identifier. They are, generall= y speaking, cryptographically protected bundles. They=E2=80=99re designed t= o carry a bunch of different information about a user and the authenticatio= n event in a form that=E2=80=99s independently verifiable and auditable. SA= ML assertions (XML document) and ID Tokens (signed JWTs) are the most commo= n ones we see today, but other formats exist and will keep being invented.= =C2=A0

    An identifier is a different kind of creatu= re. It is a single statement that identifies the party in question in the c= ontext of the party doing the identification. It=E2=80=99s this full contex= t that the receiver of the identifier needs to interpret it in. When using = a federated identity protocol, each RP is going to have :some: kind of loca= l user information store that they=E2=80=99re going to tie into, some field= in a database they=E2=80=99ll key off of. It=E2=80=99s just never going to= be the case that all RPs will be able to use server-provided opaque identi= fiers for all cases. Account recovery and binding is one such use case wher= e a user-facing identifier like an email address makes a LOT of sense, for = one small example. This is an array in the request and response precisely b= ecause a user could be known by several different identifiers to a party, a= nd an RP will have a better idea about what kinds of things it wants to cor= relate against, and it=E2=80=99s up to the AS to provide that mapping. I th= ink that if we don=E2=80=99t define a way to describe the format, the =E2= =80=9Cas_id=E2=80=9D field is going to get structure back-patched onto it l= ike is being proposed here:

    https://mattrglobal.github.io/oidc-portable-identities/

    I=E2=80=99m personally not a fan of that approach as = it mixes the data layering too much, and you end up making guesses about wh= ether a field is meaningful or a pointer. I think GNAP will be much better = served by using a data structure for this from the start. DIDs should be an= other =E2=80=9Cformat=E2=80=9D of the subject identifier. I don=E2=80=99t t= hink GNAP should define this format, and I=E2=80=99ve dropped a note to the= SECEVENT mailing list asking about adding DIDs to the subject identifiers = draft before it gets published. DIDs are not assertions, even in the cases = where they point to fully functional DID documents with user information in= them. (And for what it=E2=80=99s worth, I think the OIDC world should also= use the SECEVENT draft inside ID Tokens to solve the use case of the draft= above).

    For the user !=3D RO cases, I think that = potentially having a way to signal those two items separately in the reques= t and response could be useful. Right now all the user/subject stuff is abo= ut identifying =E2=80=9Cthe user that=E2=80=99s currently here at the clien= t instance=E2=80=9D, in a variety of forms that the client instance and AS = can negotiate. If the client or AS has some other notion about who the RO i= s and how that could be separate from the current user, we could provide a = way to signal that like you=E2=80=99re proposing below. In my mental model,= there are going to be a lot of use cases where the =E2=80=9CRO=E2=80=9D is= n=E2=80=99t known to the client at all, but rather to the AS and is based o= n what the client=E2=80=99s asking for. So I could identify the current use= r and ask for a specific medical record, and the AS realizes it has to go b= ug a particular doctor to approve things directly. This is instead of inter= acting with the current user and failing in an awkward way when the current= user doesn=E2=80=99t have the rights to do things, but someone else would.= But we=E2=80=99d want the system to be able to detect if the current user = is the doctor, so we can just interact with them directly. Does that all tr= ack?

    =C2=A0=E2=80=94 Justin

    On Mar 10, 2021, at 4:10 AM, Fabien Imbault <= ;fabien.imbault@gmail.com> wrote:

    Hello,

    Notice the question mark in the title. Not t= o be considered as an editor's comment.
    This thread intends t= o provide a detailed comment on the interesting=C2=A0feedback by Kristina: = "I would catch up on the thread to understand why DIDs are thought to = be treated as assertions".
    In the chat, I answered: "Ha= ppy to get the discussion on DIDs. Actually, could be either or, depending = on what we intend to do." Let me expand a bit on that, to make it unde= rstandable (didn't have the time during the meeting, unfortunately).

    This relates to the items described on slides 20 and= 34, which I'll explain further. I'll highlight as transparently as= possible what I think would be the benefits and downsides of each. Both ar= e probably viable options, but they correspond to different scopes and obje= ctives. I'll spend a bit more time on option 2, since it is a different= approach compared to the current draft.

    1. The first possibilit= y is to use SECEVENT throughout.=C2=A0
    In that case, DIDs sho= uld be a part of sub_ids (in the core or in the extension registry, dependi= ng on what Annabelle's WG decides). More generally, the WG would have t= o decide which additional sub_ids it needs (as per Yaron's comment).

    That's obviously the closest to what is describe= d in draft-04. It allows a communication of subject information between the= client and the AS, by using global identifiers (mail, phone, etc.), or usi= ng a local opaque reference=C2=A0- i.e. governed by the AS (that's prob= ably what we would=C2=A0put in the examples, unless someone has a better id= ea - cf issues #16 and #42).=C2=A0

    Assertions rela= te for instance to the proof of presence of the RO. The current draft-04 th= erefore plans for id_tokens and saml2, maybe there could be other needs lat= er (extension registry).

    - Benefits: identifiers a= re a key component of GNAP, which makes integration easier. Possibly one co= uld choose to use DIDs throughout.
    - Downsides: email/phone ident= ifiers will probably be used throughout by most devs (since that's corr= elation information they=C2=A0have in their user DB). Which means we should= limit what assertions contain, to avoid doing links between weak global id= entifiers and hopefully stronger assertions. That's not really a proble= m if it's limited to authentication events mostly (in that perspective,= samlv2 could make sense in the core). An assertion is probably a single va= lue then (not an array).=C2=A0 =C2=A0

    Option = 1 can be summarized as:=C2=A0

    "subject": {
    <= span style=3D"font-family:"Courier New";color:rgb(51,51,51);backg= round-color:rgb(247,247,247);font-variant-numeric:normal;font-variant-east-= asian:normal;vertical-align:baseline;white-space:pre-wrap">=C2=A0=C2=A0=C2= =A0"sub_ids": { }, // request and resp= onse (SECEVENT -> including DID possibly)=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=C2=A0=C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0"assertions&= quot;: [ ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request= and response (id_token or samlv2)
    }
    ("hints" d= o not exist currently, but are partially covered separately via "reque= st.user" / the relevance of "principal", discussed in the sl= ide, is a question mark too - which is a different discussion on end-user != =3D RO).


    2. An alternate poss= ibility is to use SECEVENT only as input/hint
    In that case, D= IDs should be a part of assertions (which have a different meaning compared= to option 1).

    The AS only returns an local opaque= reference as_ref (while in option 1, it was only one of many possibilities= ). Its only job is to help the client differentiate the response subject. T= he AS policy might further define the scope of that reference, as suggested= in=C2=A0https://github.com/ietf-wg-g= nap/gnap-core-protocol/issues/210, although I personally=C2=A0viewed th= at by default as=C2=A0(2) "as_id" an identifier locally unique to= that AS for all the RSs.

    SECEVENTS are still usef= ul as an input, that's what I presented in request.hints.self.sub_ids (= but it's the responsibility=C2=A0of the AS to match it with its own ref= erence system - from instance from the email to AS's local record XUT2M= FM1XBIKJKSDU8Q).=C2=A0Note: since the slides, a new draft-ietf-secevent-sub= ject-identifiers-07 has been published. Notably this includes an opaque ide= ntifier, which the client can use to pass the as_ref hint to the AS. Thus w= e wouldn't need any further addition to SECEVENT,=C2=A0although hints w= ould benefit from further additions (like DIDs for instance). Notice also t= hat subject_types_supported becomes less important, because in the worst ca= se scenario, it's simply=C2=A0a hint that wouldn't be understood an= d therefore taken into account by the AS.

    The asse= rtions array has a more important role than in option 1 (with the explicit = aim of separating between client hints and validated info asserted by the A= S). It serves as a generic/extendible mapping structure, e.g. "the AS = asserts that opaque reference=C2=A0XUT2MFM1XBIKJKSDU8Q=C2=A0is matching with = these (more or less verifiable) statements." The name assertion theref= ore corresponds to the responsibility=C2=A0of the AS in delivering those st= atements (cf should/must, issue #49). Some of these statements relate to id= entity or auth events (ex: DID, id_token), some might directly be useful fo= r authorization decisions (like ZKP example in the parental control example= ). Possibly some of these validated assertions could be reused in next inte= ractions.

    Another question that popped-up is the s= cope of sub_ids. Should they be about the same user? (I think so). In the c= ase of remote ROs especially, it might be important that DID be considered = as an assertion=C2=A0(about someone else's) and not as sub_ids, because= the AS needs to be careful about who the client wants to reach (avoid spam= , etc.). This is consistent with the rest of discussion on what to do when = end-user !=3D RO, although using DIDComm might seem a bit early (the paint = is very fresh).=C2=A0

    Option 2 was summarized as:= =C2=A0

    // (suggestion only, not as an editor)
    "s= ubject": {
    =C2=A0=C2=A0=C2=A0"as_ref": { // response only (w= ouldn=E2=80=99t require SECEVENT)
    =E2=80=9Cas=E2= =80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D, = <= span style=3D"white-space:pre-wrap">
    = =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D=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= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<= /div>
    =C2= =A0=C2=A0=C2=A0"assertions": [ ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 // request and response (id_token/jwkthumb/DID/VC/etc= . -> whatever info can be validated by the AS)

    =C2=A0=C2=A0=C2=A0"hints": { =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request only= (optional)
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"self":= { =C2=A0=C2=A0=C2=A0=E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque in= draft-07 - that could contain the ref)
    =C2=A0= =C2=A0=C2=A0=E2=80=9Cassertions=E2=80=9D: [ ] // see examples: V= C on DOB or ZKP on age (wider scope, possibly through extensions) <= /span>
    },=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=C2=A0=C2=A0=C2=A0
    =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"principal": { // new proposal presented at IETF110 (just an idea)
    =C2=A0 =E2=80=9Cautomated=E2=80=9D: true, // rule eng= ine
    =C2=A0 =E2=80=9Casync=E2= =80=9D: { } // remote ROs
    }=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=C2=A0=C2=A0}
    }<= /div>

    - Benefits: as_ref is self supporting= (no strong coupling with SECEVENT), but can still take SECEVENT as an inpu= t hint for the AS. It avoids the risk of making an official association bet= ween a weak global identifier (e.g. email, used elsewhere) and hopefully st= ronger local assertions. GNAP would be fully agnostic to whatever identity = system is used, only facilitating interoperability through assertions (seco= nd only in importance=C2=A0compared to the AS opaque reference). Some asser= tions (possibly extensions) could also be useful for the AS decision (e.g. = VC or ZKP).
    - Downsides: opaqueness of as_ref is a feature, not a= bug. The opaque reference is fully managed by the AS, therefore not inhere= ntly portable (cf portability discussions in OIDC currently). There's n= o explicit binding to an official identity, only a contextual mapping to AS= validated assertions. It makes it more difficult to match the identifiers = from one AS to another or to correlate with the client user DB (still possi= ble via assertions, if the AS allows it). Assertions are much more generic = (possibly via extensions), but might require a more advanced mechanism=C2= =A0to request/response only the most relevant information (which makes the = AS policy critical here).

    I hope that clarifies th= e=C2=A0reasoning for both options. Again I'm not saying option 2 is bet= ter, just saying the trade-offs are different (+ knowing that we need to ke= ep it simple).
    - option 1 puts more in sub_ids and less in assert= ions
    - option 2 puts less in the reference and more in assertions= =C2=A0
    All of this is open to discussion. More generally speaking= , on every part in orange and question mark (?) I would love your ideas and= criticisms. What I intended as an editor is only to highlight where the WG= has important choices to make, before we can make the related PRs.

    A further side comment: IETF EAT RATS was suggested for a= ssertions, but relates more to the client attestations. It was added as a c= omment in=C2=A0https://github.com/ietf= -wg-gnap/gnap-core-protocol/issues/44, which is a distinct topic we'= ;ll work on.

    Fabien (editor's hat off)

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

    This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    --00000000000011357805bdb34685-- From nobody Tue Mar 16 21:30:26 2021 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 B025B3A1A01 for ; Tue, 16 Mar 2021 21:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 jnxn-gn1l2Sl for ; Tue, 16 Mar 2021 21:30:23 -0700 (PDT) Received: from mail-vk1-f174.google.com (mail-vk1-f174.google.com [209.85.221.174]) (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 293433A1A00 for ; Tue, 16 Mar 2021 21:30:23 -0700 (PDT) Received: by mail-vk1-f174.google.com with SMTP id o85so195305vko.8 for ; Tue, 16 Mar 2021 21:30:23 -0700 (PDT) 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=c/1979L/ja7xUmxWtwK5OzHmcV0QZsvnGU/siZrzXEU=; b=IiweVOQgulIDcGkRhdHcqfzh37WdEt0A5iVSIXXKZ2h2p4gK04pnVaDRmDl3MSRktY Bw/9p005LysdLyBap3aFUezzHF1LBjPdxovLi2tlj1tzwKRtT1YDXMTOXrEmYaLgwA/J Z7lgrL7WHcb44hTJlZxSPgwk/aXr2Nl99TfqKR7ICmzTxlsF6DdKAP4b8/QCmBQ/pSD7 CPGUt+bNEEEtC3qpHY2rqBTJoHgRuDkOXqktToZyps99hEHgdy4e5ZdEgDVMuxMdTHd7 Equkl4qTG08x3TiRa9uafD76+VHUqYYigpEZ0hJtK1RLMecJQDmVqJl9ai38WQRu2nmR /BRw== X-Gm-Message-State: AOAM533D25i3pg8yKxfzjoylUxyGdQSEdS9KaDTLVKAvNKpVeIAdBjek 3QljtRsRtxyILRjTZkyxlAtlKEEiUbKOJOeN1Dg3mR+B828= X-Google-Smtp-Source: ABdhPJzMJaoS4V1rTAytni40asDQzYBSR5oK0EBTEhl9HTFnEsgWQ0xl7ygp3Phl2U48tv56DlhMtLhAVveJG9zDcv4= X-Received: by 2002:a1f:fcc5:: with SMTP id a188mr1800238vki.4.1615955421835; Tue, 16 Mar 2021 21:30:21 -0700 (PDT) MIME-Version: 1.0 From: Adrian Gropper Date: Wed, 17 Mar 2021 00:30:10 -0400 Message-ID: To: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000e4352e05bdb3f03f" Archived-At: Subject: [GNAP] GNAP from a human-centered perspective X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 04:30:25 -0000 --000000000000e4352e05bdb3f03f Content-Type: text/plain; charset="UTF-8" I truly appreciate the diligence of our editors and contributors. Without intruding on the technical discussions, I hope this thread can be an opportunity for us to step out of our comfort zone and look around. As a human data subject, I am cognizant and in control of only two kinds of actors, user agents and services. The user agents are almost exclusively a handful of web browsers, email clients, and apps duplicated and sometimes synchronizing across two to four phones and computers. The services (that I expect have visibility into my persona) are in a dozen categories from banking and ISPs that I expect to be acting as fiduciaries to platforms, social networks and other data brokers with their own agenda. At this altitude, GNAP, DIDs, and ASs are as invisible as MAC addresses and routers. Our success, from a human-centered perspective, will come indirectly as a result of the GNAP Authorization Server. The user agents and service providers I see (and sometimes choose) will support GNAP along with OAuth and FIDO and Apple Sign-In as protocols. The common thing about these protocols is that they coexist and overlap in incomprehensible ways made even more obscure by DIDs, VCs, and self-issued identity providers (SIOP). As we get to DIDcomm, even I get lost. My suggestion or proposal to our group is that we respect the human perspective by doing our best to make the concept of an authorization server relevant even if it remains hidden from view behind protocols like GNAP and OAuth and data models like DID and VC. In doing this we would recognize that a human's agent would likely support GNAP AS as well as incumbent attribute management protocols. As a human, I just want my online agent to work across as many user-agents and services as possible. As with life partners or spouses, having more than one intelligent semi-autonomous agent is not typically a benefit. My concrete suggestion is that GNAP define the AS as the entity or actor that brings together the subject's policies, the capabilities granted by services, and requests and serves up authorizations to the requesting party. Adrian --000000000000e4352e05bdb3f03f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I truly appreciate the diligence of our editors and contri= butors.

    Without intruding on the technical discussions, = I hope this thread can be an opportunity for us to step out of our comfort = zone and look around.

    As a human data subject, I a= m cognizant=C2=A0and in control of only two kinds of actors, user agents an= d services. The user agents are almost exclusively a handful of=C2=A0web br= owsers, email clients, and apps duplicated and sometimes synchronizing acro= ss two to four phones and computers. The services (that I expect have visib= ility into my persona) are in a dozen categories from banking and ISPs that= I expect to be acting as fiduciaries to platforms, social networks and oth= er data brokers with their=C2=A0own agenda. At this altitude, GNAP, DIDs, a= nd ASs are as invisible as MAC addresses and routers.

    <= div>Our success, from a human-centered perspective, will come indirectly as= a result of the GNAP Authorization Server. The user agents and service pro= viders I see (and sometimes choose) will support GNAP along with OAuth and = FIDO and Apple Sign-In as protocols. The common thing about these protocols= is that they coexist and overlap in incomprehensible ways made even more o= bscure by DIDs, VCs, and self-issued identity providers (SIOP). As we get t= o DIDcomm, even I get lost.

    My suggestion or propo= sal to our group is that we respect the human perspective by doing our best= to make the concept of an authorization server relevant even if it remains= hidden from view behind protocols like GNAP and OAuth and data models like= DID and VC. In doing this we would recognize that a human's agent woul= d likely support GNAP AS as well as incumbent attribute management protocol= s. As a human, I just want my online agent to work across as many user-agen= ts and services as possible. As with life partners or spouses, having more = than one intelligent semi-autonomous agent is not typically a benefit.

    My concrete suggestion is that GNAP define the AS as t= he entity or actor that brings together the subject's policies, the cap= abilities granted by services, and requests and serves up authorizations to= the requesting party.

    Adrian

    =
    =C2=A0=C2=A0

    =C2=A0
    --000000000000e4352e05bdb3f03f-- From nobody Tue Mar 16 21:48:10 2021 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 66F133A1A57 for ; Tue, 16 Mar 2021 21:48:09 -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 UZP5SU6J3F9I for ; Tue, 16 Mar 2021 21:48:07 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 D5A9B3A1A55 for ; Tue, 16 Mar 2021 21:48:07 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id y20so21326341iot.4 for ; Tue, 16 Mar 2021 21:48: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=QmP37BJJlHckdd6ZanxeqjdLelKUgezL1qPvg8IRbbA=; b=IB7rOceJM4AECx1yk6kgzb540mjpzd0nkkQ4iozUY3aS3c82UrY4UaZjaK/YMHheCK Qd1deyOnndooNJnt+UCoP+h/eOV6vAeCnd092aqeOwWSY8+kPOHt6dBXzI6ZgrIFtBUT HH7tL8UkU7Sqav3x0mKJ84e60j1dLEo7+XFY9N291wwMxl/Qw17QtEXbDjbjX4WWreKI gdj79jaF8N3Y8OHR+FbI7HLgEt5AzfaZbjdl8UWVL2OLgsOZn0m58ZO38E9D27ImZ5el wdfURvvq+KqOexyvCpWHu8VqY3DOqtF8PmcFKvWzrkW9/xgwq4or0cguGTZBluHnnBHe X1Tw== 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=QmP37BJJlHckdd6ZanxeqjdLelKUgezL1qPvg8IRbbA=; b=RXZiAX1/mj3JwLHtX2gsQVSaMGS7sVtaz9L9YAjmjg4dib0XjuNyg6CVFi9QS9YqDb 3dKJYYpIcjJFakREgBwCIKY+ZzBR8u06Gmj6G+c54EC52JQ/uu6kWID6XlSF86YinxUK A7/s1KSYNWSPCz7MjoYwuJdyKF18435Kty81h4JrcLWfn34V/401eYn3YrksIokf0T/G iBJpc553iCSiPUMTjhatRpyE75S0UDtgWuxpHx54ggCPnJ7XZmz268mijIS8g4GOQ0ET w1ZfSLeh7EcSADZeZg67BukyhjaTw56LabNkKXLSijzLamA65Kft7JM4cEbo0R4eWFqu qlOQ== X-Gm-Message-State: AOAM530haruwkdGL24rU4jO9PxKZiqhYcVJm8s9bWy1/t5/65AavA45E 0E9nVEn9jy89GbRM7PbHHEethbYBn1OIOTN+yi0= X-Google-Smtp-Source: ABdhPJy7i+GZcP7uR97qbOqY/D/TnDW/c+WapEjGm2T3AhwG5FQ43xRWV6pv9fniWY44Vu7QV1k/gvMVTuwm4eQQ+YE= X-Received: by 2002:a02:a606:: with SMTP id c6mr1560668jam.108.1615956486159; Tue, 16 Mar 2021 21:48:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Wed, 17 Mar 2021 05:47:52 +0100 Message-ID: To: Adrian Gropper Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000005482df05bdb430c0" Archived-At: Subject: Re: [GNAP] GNAP from a human-centered perspective X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 04:48:09 -0000 --0000000000005482df05bdb430c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Not sure about partners and spouses, but I concur with the rest :-)) Le mer. 17 mars 2021 =C3=A0 05:30, Adrian Gropper = a =C3=A9crit : > I truly appreciate the diligence of our editors and contributors. > > Without intruding on the technical discussions, I hope this thread can be > an opportunity for us to step out of our comfort zone and look around. > > As a human data subject, I am cognizant and in control of only two kinds > of actors, user agents and services. The user agents are almost exclusive= ly > a handful of web browsers, email clients, and apps duplicated and sometim= es > synchronizing across two to four phones and computers. The services (that= I > expect have visibility into my persona) are in a dozen categories from > banking and ISPs that I expect to be acting as fiduciaries to platforms, > social networks and other data brokers with their own agenda. At this > altitude, GNAP, DIDs, and ASs are as invisible as MAC addresses and route= rs. > > Our success, from a human-centered perspective, will come indirectly as a > result of the GNAP Authorization Server. The user agents and service > providers I see (and sometimes choose) will support GNAP along with OAuth > and FIDO and Apple Sign-In as protocols. The common thing about these > protocols is that they coexist and overlap in incomprehensible ways made > even more obscure by DIDs, VCs, and self-issued identity providers (SIOP)= . > As we get to DIDcomm, even I get lost. > > My suggestion or proposal to our group is that we respect the human > perspective by doing our best to make the concept of an authorization > server relevant even if it remains hidden from view behind protocols like > GNAP and OAuth and data models like DID and VC. In doing this we would > recognize that a human's agent would likely support GNAP AS as well as > incumbent attribute management protocols. As a human, I just want my onli= ne > agent to work across as many user-agents and services as possible. As wit= h > life partners or spouses, having more than one intelligent semi-autonomou= s > agent is not typically a benefit. > > My concrete suggestion is that GNAP define the AS as the entity or actor > that brings together the subject's policies, the capabilities granted by > services, and requests and serves up authorizations to the requesting par= ty. > > Adrian > > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000005482df05bdb430c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Not sure about partners and spouses, but I concur with th= e rest :-))=C2=A0

    Le mer. 17 mars 2021 =C3=A0 05:30, Adrian Gropper <agropper@healthurl.com> a =C3= =A9crit=C2=A0:
    I t= ruly appreciate the diligence of our editors and contributors.

    Without intruding on the technical discussions, I hope this thread c= an be an opportunity for us to step out of our comfort zone and look around= .

    As a human data subject, I am cognizant=C2=A0and= in control of only two kinds of actors, user agents and services. The user= agents are almost exclusively a handful of=C2=A0web browsers, email client= s, and apps duplicated and sometimes synchronizing across two to four phone= s and computers. The services (that I expect have visibility into my person= a) are in a dozen categories from banking and ISPs that I expect to be acti= ng as fiduciaries to platforms, social networks and other data brokers with= their=C2=A0own agenda. At this altitude, GNAP, DIDs, and ASs are as invisi= ble as MAC addresses and routers.

    Our success, fro= m a human-centered perspective, will come indirectly as a result of the GNA= P Authorization Server. The user agents and service providers I see (and so= metimes choose) will support GNAP along with OAuth and FIDO and Apple Sign-= In as protocols. The common thing about these protocols is that they coexis= t and overlap in incomprehensible ways made even more obscure by DIDs, VCs,= and self-issued identity providers (SIOP). As we get to DIDcomm, even I ge= t lost.

    My suggestion or proposal to our group is = that we respect the human perspective by doing our best to make the concept= of an authorization server relevant even if it remains hidden from view be= hind protocols like GNAP and OAuth and data models like DID and VC. In doin= g this we would recognize that a human's agent would likely support GNA= P AS as well as incumbent attribute management protocols. As a human, I jus= t want my online agent to work across as many user-agents and services as p= ossible. As with life partners or spouses, having more than one intelligent= semi-autonomous agent is not typically a benefit.

    My concrete suggestion is that GNAP define the AS as the entity or actor t= hat brings together the subject's policies, the capabilities granted by= services, and requests and serves up authorizations to the requesting part= y.

    Adrian

    =C2=A0=C2=A0

    =C2=A0
    --
    TXAuth mailing list
    TXA= uth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= /a>
    --0000000000005482df05bdb430c0-- From nobody Tue Mar 16 21:48:28 2021 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 5639A3A1A58 for ; Tue, 16 Mar 2021 21:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 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 dlsIqgTrA5Nk for ; Tue, 16 Mar 2021 21:48:21 -0700 (PDT) Received: from mail-vs1-f46.google.com (mail-vs1-f46.google.com [209.85.217.46]) (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 06EDE3A1A60 for ; Tue, 16 Mar 2021 21:48:21 -0700 (PDT) Received: by mail-vs1-f46.google.com with SMTP id q1so374140vsq.6 for ; Tue, 16 Mar 2021 21:48:20 -0700 (PDT) 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=fglancvOtM8dPNnsweIRUH2rKbwM6TjY8mGIgiYTSEc=; b=N0+hA19pAkjZQPGh/e7xzVCgxRfbae+MO1DaqjAQ/EITKgAAnSFUuNrov5vmOOtexP 6EHIRrL7RIH2x5X4mnVYmTV90dB3q5CmzGZEBtlyTPFvqxJbzMZRoLVAbZmLhMT1kPsA mgwEXmAcFTyiz5iwB9slkkoMO4GRhvOF6qG7p989gtI+R5wUwzdy8p26cQ26J5HAw4xd XLkoX2Ul3zjA4/CrthqKbW8kgDCB+M8ZW8aq7D39RQCSHGif0F29vwIcs0I54kflt4gQ l6gtYED1z8LaTiPYJF80mtdHfNekF0B4E36LjOAP3UNeTfVOv6/pSyUZZql1POGQvh/6 zIOA== X-Gm-Message-State: AOAM531WqivO1Wlk4Asdr55Psmhnkh9CwIp96nkWg6MTeIDg/MVhgz0D VHC/muyKyM5MyUH+9snwFakY1Vv4mcYKiOnz3LU= X-Google-Smtp-Source: ABdhPJx9qV4YxZPCQ13EqGlOJZnXXHcakyVM1or/Fp/ZDmFKUkDwGHStPb8RhsJoYzwjqUjA34IZBTqGFfOj51Rujq0= X-Received: by 2002:a05:6102:222f:: with SMTP id d15mr2091326vsb.1.1615956499436; Tue, 16 Mar 2021 21:48:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Adrian Gropper Date: Wed, 17 Mar 2021 00:48:07 -0400 Message-ID: To: Fabien Imbault Cc: GNAP Mailing List , Justin Richer , Tobias Looker Content-Type: multipart/alternative; boundary="0000000000001f16e705bdb43133" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 04:48:26 -0000 --0000000000001f16e705bdb43133 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What do you mean the scope is restricted to the subject? DIDs are valuable for all end-users and things like did:web can help interop with RSs. A client might not have a DID but it could have a VC as a certificate of authenticity linked to some audit mechanism. Adrian On Tue, Mar 16, 2021 at 11:42 PM Fabien Imbault wrote: > Noted. I agree with that goal. > > Back to identifiers, even if we'd use DIDs, the scope is restricted to th= e > subject. > > Fabien > > > Le mer. 17 mars 2021 =C3=A0 04:04, Adrian Gropper a > =C3=A9crit : > >> Thanks, Fabien. >> >> We need to be verrry careful about the shortcuts once we add user and >> end-user to our spec. RO =3D subject (of the resource secured by a RS) i= s >> clear and independent of any AS or clients. DIDs can be helpful for the >> RO-RS relationship for authentication, encryption, and service endpoints= . >> Authentication can facilitate pseudonymity by default. Encryption, for >> example, can allow mediated communications for privacy enhancement. >> >> When we bring the request of an end-user into the picture, the DID can >> apply to someone other than the RO / subject. The DID can secure claims >> that had nothing to do with the RO-RS (as you point out in #197). Also, = in >> many cases, the subject DID known to the requesting party might be >> different from the DID associated with the RO at the RS. This promotes >> privacy through DIDs as same-domain identifiers but has to be dealt with= at >> the policy decision point where capabilities are filtered. >> >> Another source of potential confusion comes from the way we use client. >> DIDs are generally not associated with a client except to the extent the >> client is a user-agent such as a mobile wallet or an online policy and >> capabilities agent. >> >> My suggestion is that we arrive at a set of consistent names soon and >> present them early in the spec - in what is now Section 1.2 - and avoid >> using any shortcuts in the rest of the spec. I would also suggest we >> provide examples of the use of DIDs relative to the names we define in 1= .2. >> >> Adrian >> >> On Tue, Mar 16, 2021 at 10:51 PM Fabien Imbault >> wrote: >> >>> Note also that there's issue 197 that discussed that very question. >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/197 >>> >>> Le mer. 17 mars 2021 =C3=A0 03:34, Fabien Imbault >>> a =C3=A9crit : >>> >>>> Hi Adrian, >>>> >>>> As the name suggests, it's an identifier for the subject (and so, >>>> hypothetically, a DID to identify the subject). The text indeed concer= ns >>>> the subject as the RO, as it is known to the AS. >>>> >>>> But it's easy to make shortcuts, because often we end-up dealing with >>>> is user =3D end-user =3D RO =3D subject. >>>> >>>> Fabien >>>> >>>> Le mer. 17 mars 2021 =C3=A0 03:10, Adrian Gropper >>>> a =C3=A9crit : >>>> >>>>> I'm late to this conversation and confused by Tobias' use of End-User >>>>> (his caps) and subject. Are we talking about a DID for the subject, t= he >>>>> end-user, or both? >>>>> >>>>> To be clear, in my mind, the subject is in control of policies and >>>>> capabilities at the GNAP AS. The end-user is in control of a client o= r user >>>>> agent and a request to the AS. The end-user and client may or may not= have >>>>> any prior relationship with the AS. >>>>> >>>>> Adrian >>>>> >>>>> On Tue, Mar 16, 2021 at 10:00 PM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Hi Tobias, >>>>>> >>>>>> Not yet (none of the current sub_ids require additional parameters) >>>>>> but if DIDs do get added to subject identifiers, then it's certainly >>>>>> something we would have to support. >>>>>> >>>>>> There's already a very basic version of that, but only to chose the >>>>>> main type (now called "format" in latest draft 07 of SECEVENT), with >>>>>> subject_types_supported in the discovery. >>>>>> >>>>>> Thanks for the heads up, it's worth creating an issue or putting a >>>>>> note in some existing issue to not forget looking into that. >>>>>> >>>>>> Cheers >>>>>> Fabien >>>>>> >>>>>> >>>>>> Le mer. 17 mars 2021 =C3=A0 01:01, Tobias Looker >>>>>> a =C3=A9crit : >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> This is probably out of scope for the current conversation but has >>>>>>> any thought been had on how the client instance could communicate >>>>>>> additional options around what subject identifier types it supports= for >>>>>>> cases where the client instance will perhaps be required to conduct >>>>>>> additional processing on the artifacts returned by the AS? As an ex= ample if >>>>>>> the AS chose to identify the subject (End-User) using a DID and wan= ted to >>>>>>> include an additional cryptographic assertion that showed it contro= ls keys >>>>>>> appropriately associated to the DID, then the client may have wante= d to >>>>>>> communicate some information up front in their request to ensure th= ey can >>>>>>> perform this additional processing, such as the signature suites it >>>>>>> supports and in the context of DIDs potentially which DID methods i= t is >>>>>>> capable of resolving? >>>>>>> >>>>>>> Thanks, >>>>>>> [image: Mattr website] >>>>>>> *Tobias Looker* >>>>>>> Mattr >>>>>>> +64 (0) 27 378 0461 >>>>>>> tobias.looker@mattr.global >>>>>>> [image: Mattr website] [image: Mattr on >>>>>>> LinkedIn] [image: >>>>>>> Mattr on Twitter] [image: Mattr >>>>>>> on Github] >>>>>>> This communication, including any attachments, is confidential. If >>>>>>> you are not the intended recipient, you should not read it - please= contact >>>>>>> me immediately, destroy it, and do not copy or use any part of this >>>>>>> communication or disclose anything about it. Thank you. Please note= that >>>>>>> this communication does not designate an information system for the >>>>>>> purposes of the Electronic Transactions Act 2002. >>>>>>> >>>>>>> >>>>>>> On Sat, Mar 13, 2021 at 9:26 PM Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>> >>>>>>>> Hi Justin, >>>>>>>> >>>>>>>> A last word on end-user! =3DRO (again just as food for thought). >>>>>>>> >>>>>>>> As soon as hints.automated is set to true, it takes priority over >>>>>>>> async, which means it's the same model as the one you describe : t= he AS has >>>>>>>> precedence over any other remote contact. >>>>>>>> >>>>>>>> So that confirms the global view that the AS is the one with the >>>>>>>> authority, and that it might know more than the client. >>>>>>>> >>>>>>>> Cheers >>>>>>>> Fabien >>>>>>>> >>>>>>>> Le jeu. 11 mars 2021 =C3=A0 11:44, Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com> a =C3=A9crit : >>>>>>>> >>>>>>>>> Hi Justin, >>>>>>>>> >>>>>>>>> I think that's interesting: >>>>>>>>> "For the user !=3D RO cases, I think that potentially having a wa= y >>>>>>>>> to signal those two items separately in the request and response = could be >>>>>>>>> useful. Right now all the user/subject stuff is about identifying= =E2=80=9Cthe user >>>>>>>>> that=E2=80=99s currently here at the client instance=E2=80=9D, in= a variety of forms that >>>>>>>>> the client instance and AS can negotiate. If the client or AS has= some >>>>>>>>> other notion about who the RO is and how that could be separate f= rom the >>>>>>>>> current user, we could provide a way to signal that like you=E2= =80=99re proposing >>>>>>>>> below. In my mental model, there are going to be a lot of use cas= es where >>>>>>>>> the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the client at all= , but rather to the AS and is >>>>>>>>> based on what the client=E2=80=99s asking for. So I could identif= y the current user >>>>>>>>> and ask for a specific medical record, and the AS realizes it has= to go bug >>>>>>>>> a particular doctor to approve things directly. This is instead o= f >>>>>>>>> interacting with the current user and failing in an awkward way w= hen the >>>>>>>>> current user doesn=E2=80=99t have the rights to do things, but so= meone else would. >>>>>>>>> But we=E2=80=99d want the system to be able to detect if the curr= ent user is the >>>>>>>>> doctor, so we can just interact with them directly. Does that all= track?" >>>>>>>>> >>>>>>>>> I agree with the general idea. In the end, that's the AS's >>>>>>>>> responsibility (and also a big part of its value as a policy engi= ne). >>>>>>>>> >>>>>>>>> Even in the cases - as I suggested - where the client would be >>>>>>>>> able to signal what it knows (or thinks it knows) about the subje= ct, the AS >>>>>>>>> still needs to validate what it can. The client could be an attac= ker lying >>>>>>>>> to the AS. Or there could be an unintended bug. >>>>>>>>> >>>>>>>>> The client still seems like a straightforward source to gather >>>>>>>>> optional/declarative hints. Which is what request.user is already= doing in >>>>>>>>> spirit. In many cases, the AS should go a step further. Validate >>>>>>>>> cryptographic statements from a more reputable issuer, whatever h= elps. >>>>>>>>> >>>>>>>>> Contacts might be one of the possibilities. I'm not suggesting >>>>>>>>> interact/fail scenarii at all, which I see as anti-ergonomic (com= posability >>>>>>>>> with timeouts and fallback is the answer to that). The failure I = was >>>>>>>>> considering is only for async calls explicitly requested by the c= lient >>>>>>>>> (which is considered in sequence 1.4.3, and not coming from me), = there's >>>>>>>>> obviously no way to ensure a remote RO would actually respond whe= n the >>>>>>>>> client expects it. If that sequence is considered, realistic fail= ure modes >>>>>>>>> should be anticipated and dealt with internally (just like any di= stributed >>>>>>>>> program would do), is all I'm saying. And so from the outside, th= ere's no >>>>>>>>> interact/fail. >>>>>>>>> That's the same as in real life: when booking a business trip, an >>>>>>>>> employee could either follow the generic rule (2nd class train ti= cket) or >>>>>>>>> reach out to his manager, explaining that it's a long trip and th= at 1st >>>>>>>>> class would be better. The employee knows the manager might not i= nstantly >>>>>>>>> respond, and knows that the absence of an answer means he'll have= to go for >>>>>>>>> the 2nd class. >>>>>>>>> >>>>>>>>> There will be cases when the client doesn't know the RO. I'm not >>>>>>>>> sure if that's a majority of cases, but it will definitely happen= . It could >>>>>>>>> happen when you interact with an organization or a team and have = no idea >>>>>>>>> who's responsible or what delegations are in place (some of those= cases >>>>>>>>> have been described by Adrian for instance). >>>>>>>>> There could also be cases where the ownership could be distribute= d >>>>>>>>> (an example was provided when considering remote ROs). Again in r= eal life, >>>>>>>>> it's not unusual for a decision to fallback on a deputy when the = main >>>>>>>>> decision maker is unavailable. Or there could be an open governan= ce even, >>>>>>>>> but maybe that's one step too far. >>>>>>>>> >>>>>>>>> Of course, if the AS has internal knowledge or other ways to get >>>>>>>>> the information it should use it. Remains to be seen how we can s= pecify >>>>>>>>> that (cf issue #49 on should/must). The example with doctor/patie= nt is fine >>>>>>>>> if hardcoded, but it becomes a problem when we fail to understand= the real >>>>>>>>> relationships in environments of various sensitive nature. How th= e AS >>>>>>>>> identifies that a specific record requires approval from Doctor B= ob might >>>>>>>>> be context dependent (sometimes it could be a nurse, a team of do= ctors, >>>>>>>>> another medical organization, etc.). Maybe you could have various= levels of >>>>>>>>> authorizations (extreme example: military style classifications),= so that >>>>>>>>> it might even be impossible to tell who can be contacted. >>>>>>>>> >>>>>>>>> That's also why I was suggesting assertions could go beyond >>>>>>>>> authentication events, and include cryptographic assertions for >>>>>>>>> authorization purposes. Maybe we can even imagine a risk based ap= proach, as >>>>>>>>> in some cases we won't know for sure. >>>>>>>>> >>>>>>>>> The difficulty will be to be sufficiently generic but simple >>>>>>>>> enough. Maybe we can rule out some cases. Maybe remote async cont= acts are >>>>>>>>> out of scope, because we only want instantaneous authorizations. = Most of >>>>>>>>> those cases are way beyond what OAuth2 does. I don't know. But wh= at's >>>>>>>>> certain is that the WG should decide what support for cases where= end-user >>>>>>>>> !=3D RO it intends to provide. My discussion was just a very smal= l >>>>>>>>> Chesterston's Fence contribution, even if that seems to have surp= rised. >>>>>>>>> >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Mar 10, 2021 at 8:18 PM Justin Richer >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi Fabien, >>>>>>>>>> >>>>>>>>>> First, thanks for doing the heavy lift of writing this topic up. >>>>>>>>>> Of these options, I would strongly prefer option (1). The differ= ence >>>>>>>>>> between assertions and identifiers is that an assertion is a ful= ly packaged >>>>>>>>>> set of attributes, one of which can be an identifier. They are, = generally >>>>>>>>>> speaking, cryptographically protected bundles. They=E2=80=99re d= esigned to carry a >>>>>>>>>> bunch of different information about a user and the authenticati= on event in >>>>>>>>>> a form that=E2=80=99s independently verifiable and auditable. SA= ML assertions (XML >>>>>>>>>> document) and ID Tokens (signed JWTs) are the most common ones w= e see >>>>>>>>>> today, but other formats exist and will keep being invented. >>>>>>>>>> >>>>>>>>>> An identifier is a different kind of creature. It is a single >>>>>>>>>> statement that identifies the party in question in the context o= f the party >>>>>>>>>> doing the identification. It=E2=80=99s this full context that th= e receiver of the >>>>>>>>>> identifier needs to interpret it in. When using a federated iden= tity >>>>>>>>>> protocol, each RP is going to have :some: kind of local user inf= ormation >>>>>>>>>> store that they=E2=80=99re going to tie into, some field in a da= tabase they=E2=80=99ll key >>>>>>>>>> off of. It=E2=80=99s just never going to be the case that all RP= s will be able to >>>>>>>>>> use server-provided opaque identifiers for all cases. Account re= covery and >>>>>>>>>> binding is one such use case where a user-facing identifier like= an email >>>>>>>>>> address makes a LOT of sense, for one small example. This is an = array in >>>>>>>>>> the request and response precisely because a user could be known= by several >>>>>>>>>> different identifiers to a party, and an RP will have a better i= dea about >>>>>>>>>> what kinds of things it wants to correlate against, and it=E2=80= =99s up to the AS >>>>>>>>>> to provide that mapping. I think that if we don=E2=80=99t define= a way to describe >>>>>>>>>> the format, the =E2=80=9Cas_id=E2=80=9D field is going to get st= ructure back-patched onto >>>>>>>>>> it like is being proposed here: >>>>>>>>>> >>>>>>>>>> https://mattrglobal.github.io/oidc-portable-identities/ >>>>>>>>>> >>>>>>>>>> I=E2=80=99m personally not a fan of that approach as it mixes th= e data >>>>>>>>>> layering too much, and you end up making guesses about whether a= field is >>>>>>>>>> meaningful or a pointer. I think GNAP will be much better served= by using a >>>>>>>>>> data structure for this from the start. DIDs should be another = =E2=80=9Cformat=E2=80=9D of >>>>>>>>>> the subject identifier. I don=E2=80=99t think GNAP should define= this format, and >>>>>>>>>> I=E2=80=99ve dropped a note to the SECEVENT mailing list asking = about adding DIDs >>>>>>>>>> to the subject identifiers draft before it gets published. DIDs = are not >>>>>>>>>> assertions, even in the cases where they point to fully function= al DID >>>>>>>>>> documents with user information in them. (And for what it=E2=80= =99s worth, I think >>>>>>>>>> the OIDC world should also use the SECEVENT draft inside ID Toke= ns to solve >>>>>>>>>> the use case of the draft above). >>>>>>>>>> >>>>>>>>>> For the user !=3D RO cases, I think that potentially having a wa= y >>>>>>>>>> to signal those two items separately in the request and response= could be >>>>>>>>>> useful. Right now all the user/subject stuff is about identifyin= g =E2=80=9Cthe user >>>>>>>>>> that=E2=80=99s currently here at the client instance=E2=80=9D, i= n a variety of forms that >>>>>>>>>> the client instance and AS can negotiate. If the client or AS ha= s some >>>>>>>>>> other notion about who the RO is and how that could be separate = from the >>>>>>>>>> current user, we could provide a way to signal that like you=E2= =80=99re proposing >>>>>>>>>> below. In my mental model, there are going to be a lot of use ca= ses where >>>>>>>>>> the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the client at al= l, but rather to the AS and is >>>>>>>>>> based on what the client=E2=80=99s asking for. So I could identi= fy the current user >>>>>>>>>> and ask for a specific medical record, and the AS realizes it ha= s to go bug >>>>>>>>>> a particular doctor to approve things directly. This is instead = of >>>>>>>>>> interacting with the current user and failing in an awkward way = when the >>>>>>>>>> current user doesn=E2=80=99t have the rights to do things, but s= omeone else would. >>>>>>>>>> But we=E2=80=99d want the system to be able to detect if the cur= rent user is the >>>>>>>>>> doctor, so we can just interact with them directly. Does that al= l track? >>>>>>>>>> >>>>>>>>>> =E2=80=94 Justin >>>>>>>>>> >>>>>>>>>> On Mar 10, 2021, at 4:10 AM, Fabien Imbault < >>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Notice the question mark in the title. Not to be considered as a= n >>>>>>>>>> editor's comment. >>>>>>>>>> This thread intends to provide a detailed comment on the >>>>>>>>>> interesting feedback by Kristina: "I would catch up on the threa= d to >>>>>>>>>> understand why DIDs are thought to be treated as assertions". >>>>>>>>>> In the chat, I answered: "Happy to get the discussion on DIDs. >>>>>>>>>> Actually, could be either or, depending on what we intend to do.= " Let me >>>>>>>>>> expand a bit on that, to make it understandable (didn't have the= time >>>>>>>>>> during the meeting, unfortunately). >>>>>>>>>> >>>>>>>>>> This relates to the items described on slides 20 and 34, which >>>>>>>>>> I'll explain further. I'll highlight as transparently as possibl= e what I >>>>>>>>>> think would be the benefits and downsides of each. Both are prob= ably viable >>>>>>>>>> options, but they correspond to different scopes and objectives.= I'll spend >>>>>>>>>> a bit more time on option 2, since it is a different approach co= mpared to >>>>>>>>>> the current draft. >>>>>>>>>> >>>>>>>>>> *1. The first possibility is to use SECEVENT throughout. * >>>>>>>>>> In that case, DIDs should be a part of sub_ids (in the core or i= n >>>>>>>>>> the extension registry, depending on what Annabelle's WG decides= ). More >>>>>>>>>> generally, the WG would have to decide which additional sub_ids = it needs >>>>>>>>>> (as per Yaron's comment). >>>>>>>>>> >>>>>>>>>> That's obviously the closest to what is described in draft-04. I= t >>>>>>>>>> allows a communication of subject information between the client= and the >>>>>>>>>> AS, by using global identifiers (mail, phone, etc.), or using a = local >>>>>>>>>> opaque reference - i.e. governed by the AS (that's probably what= we >>>>>>>>>> would put in the examples, unless someone has a better idea - cf= issues #16 >>>>>>>>>> and #42). >>>>>>>>>> >>>>>>>>>> Assertions relate for instance to the proof of presence of the >>>>>>>>>> RO. The current draft-04 therefore plans for id_tokens and saml2= , maybe >>>>>>>>>> there could be other needs later (extension registry). >>>>>>>>>> >>>>>>>>>> - Benefits: identifiers are a key component of GNAP, which makes >>>>>>>>>> integration easier. Possibly one could choose to use DIDs throug= hout. >>>>>>>>>> - Downsides: email/phone identifiers will probably be used >>>>>>>>>> throughout by most devs (since that's correlation information th= ey have in >>>>>>>>>> their user DB). Which means we should limit what assertions cont= ain, to >>>>>>>>>> avoid doing links between weak global identifiers and hopefully = stronger >>>>>>>>>> assertions. That's not really a problem if it's limited to authe= ntication >>>>>>>>>> events mostly (in that perspective, samlv2 could make sense in t= he core). >>>>>>>>>> An assertion is probably a single value then (not an array). >>>>>>>>>> >>>>>>>>>> Option 1 can be summarized as: >>>>>>>>>> >>>>>>>>>> "subject": { >>>>>>>>>> "sub_ids": { }, // request and response (SECEVENT -> >>>>>>>>>> including DID possibly) >>>>>>>>>> "assertions": [ ], // request and response >>>>>>>>>> (id_token or samlv2) >>>>>>>>>> } >>>>>>>>>> ("hints" do not exist currently, but are partially covered >>>>>>>>>> separately via "request.user" / the relevance of "principal", di= scussed in >>>>>>>>>> the slide, is a question mark too - which is a different discuss= ion on >>>>>>>>>> end-user !=3D RO). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *2. An alternate possibility is to use SECEVENT only as >>>>>>>>>> input/hint* >>>>>>>>>> In that case, DIDs should be a part of assertions (which have a >>>>>>>>>> different meaning compared to option 1). >>>>>>>>>> >>>>>>>>>> The AS only returns an local opaque reference as_ref (while in >>>>>>>>>> option 1, it was only one of many possibilities). Its only job i= s to help >>>>>>>>>> the client differentiate the response subject. The AS policy mig= ht further >>>>>>>>>> define the scope of that reference, as suggested in >>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210, >>>>>>>>>> although I personally viewed that by default as (2) "as_id" an i= dentifier >>>>>>>>>> locally unique to that AS for all the RSs. >>>>>>>>>> >>>>>>>>>> SECEVENTS are still useful as an input, that's what I presented >>>>>>>>>> in request.hints.self.sub_ids (but it's the responsibility of th= e AS to >>>>>>>>>> match it with its own reference system - from instance from the = email to >>>>>>>>>> AS's local record XUT2MFM1XBIKJKSDU8Q). Note: since the slides, = a new >>>>>>>>>> draft-ietf-secevent-subject-identifiers-07 has been published. N= otably this >>>>>>>>>> includes an opaque identifier, which the client can use to pass = the as_ref >>>>>>>>>> hint to the AS. Thus we wouldn't need any further addition to >>>>>>>>>> SECEVENT, although hints would benefit from further additions (l= ike DIDs >>>>>>>>>> for instance). Notice also that subject_types_supported becomes = less >>>>>>>>>> important, because in the worst case scenario, it's simply a hin= t that >>>>>>>>>> wouldn't be understood and therefore taken into account by the A= S. >>>>>>>>>> >>>>>>>>>> The assertions array has a more important role than in option 1 >>>>>>>>>> (with the explicit aim of separating between client hints and va= lidated >>>>>>>>>> info asserted by the AS). It serves as a generic/extendible mapp= ing >>>>>>>>>> structure, e.g. "the AS asserts that opaque reference >>>>>>>>>> XUT2MFM1XBIKJKSDU8Q is matching with these (more or less >>>>>>>>>> verifiable) statements." The name assertion therefore correspond= s to the >>>>>>>>>> responsibility of the AS in delivering those statements (cf shou= ld/must, >>>>>>>>>> issue #49). Some of these statements relate to identity or auth = events (ex: >>>>>>>>>> DID, id_token), some might directly be useful for authorization = decisions >>>>>>>>>> (like ZKP example in the parental control example). Possibly som= e of these >>>>>>>>>> validated assertions could be reused in next interactions. >>>>>>>>>> >>>>>>>>>> Another question that popped-up is the scope of sub_ids. Should >>>>>>>>>> they be about the same user? (I think so). In the case of remote= ROs >>>>>>>>>> especially, it might be important that DID be considered as an >>>>>>>>>> assertion (about someone else's) and not as sub_ids, because the= AS needs >>>>>>>>>> to be careful about who the client wants to reach (avoid spam, e= tc.). This >>>>>>>>>> is consistent with the rest of discussion on what to do when end= -user !=3D >>>>>>>>>> RO, although using DIDComm might seem a bit early (the paint is = very >>>>>>>>>> fresh). >>>>>>>>>> >>>>>>>>>> Option 2 was summarized as: >>>>>>>>>> >>>>>>>>>> // (suggestion only, not as an editor) >>>>>>>>>> "subject": { >>>>>>>>>> "as_ref": { // response only (wouldn=E2=80=99t require SECEVE= NT) >>>>>>>>>> =E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D, >>>>>>>>>> =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D >>>>>>>>>> }, >>>>>>>>>> "assertions": [ ], // request and response >>>>>>>>>> (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validated= by the AS) >>>>>>>>>> >>>>>>>>>> "hints": { // request only (optional) >>>>>>>>>> "self": { // replaces request.user (support SECEVENT here) >>>>>>>>>> =E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque= in draft-07 - >>>>>>>>>> that could contain the ref) >>>>>>>>>> =E2=80=9Cassertions=E2=80=9D: [ ] // see examples: VC on DOB = or ZKP on age >>>>>>>>>> (wider scope, possibly through extensions) >>>>>>>>>> }, >>>>>>>>>> "principal": { // new proposal presented at IETF110 (just >>>>>>>>>> an idea) >>>>>>>>>> =E2=80=9Cautomated=E2=80=9D: true, // rule engine >>>>>>>>>> =E2=80=9Casync=E2=80=9D: { } // remote ROs >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> - Benefits: as_ref is self supporting (no strong coupling with >>>>>>>>>> SECEVENT), but can still take SECEVENT as an input hint for the = AS. It >>>>>>>>>> avoids the risk of making an official association between a weak= global >>>>>>>>>> identifier (e.g. email, used elsewhere) and hopefully stronger l= ocal >>>>>>>>>> assertions. GNAP would be fully agnostic to whatever identity sy= stem is >>>>>>>>>> used, only facilitating interoperability through assertions (sec= ond only in >>>>>>>>>> importance compared to the AS opaque reference). Some assertions= (possibly >>>>>>>>>> extensions) could also be useful for the AS decision (e.g. VC or= ZKP). >>>>>>>>>> - Downsides: opaqueness of as_ref is a feature, not a bug. The >>>>>>>>>> opaque reference is fully managed by the AS, therefore not inher= ently >>>>>>>>>> portable (cf portability discussions in OIDC currently). There's= no >>>>>>>>>> explicit binding to an official identity, only a contextual mapp= ing to AS >>>>>>>>>> validated assertions. It makes it more difficult to match the id= entifiers >>>>>>>>>> from one AS to another or to correlate with the client user DB (= still >>>>>>>>>> possible via assertions, if the AS allows it). Assertions are mu= ch more >>>>>>>>>> generic (possibly via extensions), but might require a more adva= nced >>>>>>>>>> mechanism to request/response only the most relevant information= (which >>>>>>>>>> makes the AS policy critical here). >>>>>>>>>> >>>>>>>>>> I hope that clarifies the reasoning for both options. Again I'm >>>>>>>>>> not saying option 2 is better, just saying the trade-offs are di= fferent (+ >>>>>>>>>> knowing that we need to keep it simple). >>>>>>>>>> - option 1 puts more in sub_ids and less in assertions >>>>>>>>>> - option 2 puts less in the reference and more in assertions >>>>>>>>>> All of this is open to discussion. More generally speaking, on >>>>>>>>>> every part in orange and question mark (?) I would love your ide= as and >>>>>>>>>> criticisms. What I intended as an editor is only to highlight wh= ere the WG >>>>>>>>>> has important choices to make, before we can make the related PR= s. >>>>>>>>>> >>>>>>>>>> A further side comment: IETF EAT RATS was suggested for >>>>>>>>>> assertions, but relates more to the client attestations. It was = added as a >>>>>>>>>> comment in >>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, >>>>>>>>>> which is a distinct topic we'll work on. >>>>>>>>>> >>>>>>>>>> Fabien (editor's hat off) >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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 >>>>>>>> >>>>>>> >>>>>>> This communication, including any attachments, is confidential. If = you are not the intended recipient, you should not read it - please contact= me immediately, destroy it, and do not copy or use any part of this commun= ication or disclose anything about it. Thank you. Please note that this com= munication does not designate an information system for the purposes of the= Electronic Transactions Act 2002. >>>>>>> >>>>>>> -- >>>>>> 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 > --0000000000001f16e705bdb43133 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    What do you mean the scope is restricted to the subject? D= IDs are valuable for all end-users and things like did:web can help interop= with RSs. A client might not have a DID but it could have a VC as a certif= icate of authenticity linked to some audit mechanism.

    Ad= rian

    On Tue, Mar 16, 2021 at 11:42 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    <= /div>
    Noted. I agree with that goal.=

    Back to identifiers, even if = we'd use DIDs, the scope is restricted to the subject.=C2=A0=C2=A0

    Fabien


    Le mer. 17 mars 20= 21 =C3=A0 04:04, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    =
    Thanks, Fabien.

    We need to be verrry careful about the shortcuts once we add user and end-= user to our spec. RO =3D subject (of the resource secured by a RS) is clear= and independent of any AS or clients. DIDs can be helpful for the RO-RS re= lationship for authentication, encryption, and service endpoints. Authentic= ation can facilitate pseudonymity by default. Encryption, for example, can = allow mediated communications for privacy=C2=A0enhancement.=C2=A0

    When = we bring the request of an end-user into the picture, the DID can apply to = someone other than the RO / subject. The DID can secure claims that had not= hing to do with the=C2=A0RO-RS (as you point out in #197). Also, in many ca= ses, the subject DID known to the requesting party might be different from = the DID associated with the RO at the RS. This promotes privacy through DID= s as same-domain identifiers but has to be dealt with at the policy decisio= n point where capabilities are filtered.=C2=A0

    Another source of potent= ial confusion comes from the way we use client. DIDs are generally not asso= ciated with a client except to the extent the client is a user-agent such a= s a mobile wallet or an online policy and capabilities agent.

    My sugges= tion is that we arrive at a set of consistent names soon and present them e= arly in the spec - in what is now Section 1.2 - and avoid using any shortcu= ts in the rest of the spec. I would also suggest we provide examples of the= use of DIDs relative to the names we define in 1.2.=C2=A0

    Adrian

    On Tue, Mar 16, 2021 at 10:51 PM Fabien Imbault <fabien.imb= ault@gmail.com> wrote:
    <= div>Note also that there's issue 197 that discussed that very question.= =C2=A0

    Le mer. 17 mars 2021 =C3=A0 03:34, Fabien Imbault <fabien.imbault@gmail.com> a =C3=A9cr= it=C2=A0:
    Hi Adrian,

    As the name suggests, it's an identi= fier for the subject (and so, hypothetically, a DID to identify the subject= ). The text indeed concerns the subject as the RO, as it is known to the AS= .=C2=A0

    But it's eas= y to make shortcuts, because often we end-up dealing with is user =3D end-u= ser =3D RO =3D subject.=C2=A0

    Fabien=C2=A0

    Le mer. 17 mars 2021 =C3=A0 03:10, Adrian Gr= opper <agropper@healthur= l.com> a =C3=A9crit=C2=A0:
    I'm late to this conversation and confused by Tobias' use of End-= User (his caps)=C2=A0and subject. Are we talking about a DID for the subjec= t, the end-user, or both?

    To be clear, in my mind, the s= ubject is in control=C2=A0of policies and capabilities at the GNAP AS. The = end-user is in control=C2=A0of a client or user agent and a request to the = AS. The end-user and client may or may not have any prior relationship with= the AS.

    Adrian

    On Tue, Mar 16, 2021 at 10:00= PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    =
    Hi Tobias,

    N= ot yet (none of the current sub_ids require additional parameters) but if D= IDs do get added to subject identifiers, then it's certainly something = we would have to support.=C2=A0

    There's already a very basic version of that, but only to cho= se the main type (now called "format" in latest draft 07 of SECEV= ENT), with subject_types_supported in the discovery.=C2=A0

    Thanks for the heads up, it's worth = creating an issue or putting a note in some existing issue to not forget lo= oking into that.=C2=A0

    C= heers
    Fabien


    Le mer. 17 mars 2021 = =C3=A0 01:01, Tobias Looker <tobias.looker@mattr.global> a =C3=A9crit= =C2=A0:
    Hi,

    T= his is probably out of scope for the current conversation but has any thoug= ht been had on how the client instance could communicate additional options= around what subject identifier types it supports for cases where the clien= t instance will perhaps be required to conduct additional processing on the= artifacts returned by the AS? As an example if the AS chose to identify th= e subject (End-User) using a DID and wanted to include an additional crypto= graphic assertion that showed it controls keys appropriately associated to = the DID, then the client may have wanted to communicate some information up= front in their request to ensure they can perform this additional processi= ng, such as the signature suites it supports and in the context of DIDs pot= entially which DID methods it is capable of resolving?

    Thanks,
    <= table width=3D"auto" cellpadding=3D"0" cellspacing=3D"0" border=3D"0" style= =3D"color:rgb(0,0,0);font-family:Times;font-size:medium;border:0px">
    3D"Mattr=C2=A0
    Tobias Looker=
    Mattr
    +64 (0) 27 378 0461
    tobias.looker@mattr.global
    <= td width=3D"40">
    3D"Mattr3D"Mattr3D"Mattr
    =
    This communication, in= cluding any attachments, is confidential. If you are not the intended recip= ient, you should not read it - please contact me immediately, destroy it, a= nd do not copy or use any part of this communication or disclose anything a= bout it. Thank you. Please note that this communication does not designate = an information system for the purposes of the Electronic Transactions Act 2= 002.


    On Sat, Mar 13, 2021 at 9:26 PM= Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Justin,=C2=A0

    =
    A last word on end-user! =3DRO (again just as food = for thought).=C2=A0

    As s= oon as hints.automated is set to true, it takes priority over async, which = means it's the same model as the one you describe : the AS has preceden= ce over any other remote contact.=C2=A0

    So that confirms the global view that the AS is the one wit= h the authority, and that it might know more than the client.=C2=A0

    Cheers
    F= abien=C2=A0

    Le jeu. 11 mars 2021 =C3=A0 11:44= , Fabien Imbault <fabien.imbault@gmail.com> a =C3=A9crit=C2=A0:
    <= /div>
    Hi Justin,

    I thin= k that's interesting:
    "For the user !=3D RO cases, = I think that potentially having a way to signal those two items separately = in the request and response could be useful. Right now all the user/subject= stuff is about identifying =E2=80=9Cthe user that=E2=80=99s currently here= at the client instance=E2=80=9D, in a variety of forms that the client ins= tance and AS can negotiate. If the client or AS has some other notion about= who the RO is and how that could be separate from the current user, we cou= ld provide a way to signal that like you=E2=80=99re proposing below. In my = mental model, there are going to be a lot of use cases where the =E2=80=9CR= O=E2=80=9D isn=E2=80=99t known to the client at all, but rather to the AS a= nd is based on what the client=E2=80=99s asking for. So I could identify th= e current user and ask for a specific medical record, and the AS realizes i= t has to go bug a particular doctor to approve things directly. This is ins= tead of interacting with the current user and failing in an awkward way whe= n the current user doesn=E2=80=99t have the rights to do things, but someon= e else would. But we=E2=80=99d want the system to be able to detect if the = current user is the doctor, so we can just interact with them directly. Doe= s that all track?"

    I agree with the general i= dea. In the end, that's the AS's responsibility (and also a big par= t of its value as a policy engine). =C2=A0

    Even in= the cases - as I suggested - where the client would be able to signal what= it knows (or thinks it knows) about the subject, the AS still needs to val= idate what it can. The client could be an attacker lying to the AS. Or ther= e could be an unintended bug.=C2=A0

    The=C2=A0clien= t still seems like a straightforward source to gather optional/declarative = hints. Which is what request.user is already doing in spirit. In many cases= , the AS should go a step further. Validate cryptographic statements from a= more reputable issuer, whatever helps.

    Contacts m= ight be one of the possibilities. I'm not suggesting interact/fail scen= arii at all, which I see as anti-ergonomic (composability with timeouts and= fallback is the answer to that). The failure I was considering is only for= async calls explicitly requested by the client (which is considered in seq= uence 1.4.3, and not coming from me), there's obviously no way to ensur= e a remote RO would actually respond when the client expects it. If that se= quence is considered, realistic failure modes should be anticipated and dea= lt with internally (just like any distributed program would do), is all I&#= 39;m saying. And so from the outside, there's no interact/fail.=C2=A0= =C2=A0
    That's the same as in real life: when booking a busine= ss trip, an employee could either follow the generic rule (2nd class train = ticket) or reach out to his manager, explaining that it's a long trip a= nd that 1st class would be better. The employee knows the manager might not= instantly respond, and knows that the absence of an answer means he'll= have to go for the 2nd class.=C2=A0

    There wil= l be cases when the=C2=A0client doesn't know the=C2=A0RO. I'm not s= ure if that's a majority of cases, but it will definitely happen. It co= uld happen when you interact with an organization or a team and have no ide= a who's responsible or what delegations are in place (some of those cas= es have been described by Adrian for instance).=C2=A0
    There could= also be cases where the ownership could be distributed (an example was pro= vided when considering remote ROs). Again in real life, it's not unusua= l for a decision to fallback on a deputy when the main decision maker is un= available. Or there could be an open governance even, but maybe that's = one step too far.

    Of course, if the AS has interna= l knowledge or other ways to get the information it should use it. Remains = to be seen how we can specify that (cf issue #49 on should/must). The examp= le with doctor/patient is fine if hardcoded, but it becomes a problem when = we fail to understand the real relationships in environments of various sen= sitive nature. How the AS identifies that a specific record requires approv= al from Doctor Bob might be context dependent (sometimes it could be a nurs= e, a team of doctors, another medical organization, etc.). Maybe you could = have various levels of authorizations (extreme example: military style clas= sifications), so that it might even be impossible to tell who can be contac= ted.=C2=A0

    That's also why I was suggesting as= sertions could go beyond authentication events, and include cryptographic a= ssertions for authorization purposes. Maybe we can even imagine a risk base= d approach, as in some cases we won't know for sure.=C2=A0
    The difficulty will be to be sufficiently generic but simple e= nough. Maybe we can rule out some cases. Maybe remote async contacts are ou= t of scope,=C2=A0because we only want instantaneous authorizations. Most of= those cases are way beyond what OAuth2 does. I don't know. But what= 9;s certain is that the WG should decide what support for cases where end-u= ser !=3D RO it intends to provide. My discussion was just a very small Ches= terston's Fence contribution, even if that seems to have surprised.

    Fabien


    On Wed, Mar 10, 2021 at 8:18 PM Justin Richer <jricher@mit.edu= > wrote:
    Hi Fabien,

    First, thanks for doing the heavy lift of writing this topic up. Of these= options, I would strongly prefer option (1). The difference between assert= ions and identifiers is that an assertion is a fully packaged set of attrib= utes, one of which can be an identifier. They are, generally speaking, cryp= tographically protected bundles. They=E2=80=99re designed to carry a bunch = of different information about a user and the authentication event in a for= m that=E2=80=99s independently verifiable and auditable. SAML assertions (X= ML document) and ID Tokens (signed JWTs) are the most common ones we see to= day, but other formats exist and will keep being invented.=C2=A0
    =
    An identifier is a different kind of creature. It is a singl= e statement that identifies the party in question in the context of the par= ty doing the identification. It=E2=80=99s this full context that the receiv= er of the identifier needs to interpret it in. When using a federated ident= ity protocol, each RP is going to have :some: kind of local user informatio= n store that they=E2=80=99re going to tie into, some field in a database th= ey=E2=80=99ll key off of. It=E2=80=99s just never going to be the case that= all RPs will be able to use server-provided opaque identifiers for all cas= es. Account recovery and binding is one such use case where a user-facing i= dentifier like an email address makes a LOT of sense, for one small example= . This is an array in the request and response precisely because a user cou= ld be known by several different identifiers to a party, and an RP will hav= e a better idea about what kinds of things it wants to correlate against, a= nd it=E2=80=99s up to the AS to provide that mapping. I think that if we do= n=E2=80=99t define a way to describe the format, the =E2=80=9Cas_id=E2=80= =9D field is going to get structure back-patched onto it like is being prop= osed here:


    I=E2=80=99m personally not a fan of that approach as it mixes the data l= ayering too much, and you end up making guesses about whether a field is me= aningful or a pointer. I think GNAP will be much better served by using a d= ata structure for this from the start. DIDs should be another =E2=80=9Cform= at=E2=80=9D of the subject identifier. I don=E2=80=99t think GNAP should de= fine this format, and I=E2=80=99ve dropped a note to the SECEVENT mailing l= ist asking about adding DIDs to the subject identifiers draft before it get= s published. DIDs are not assertions, even in the cases where they point to= fully functional DID documents with user information in them. (And for wha= t it=E2=80=99s worth, I think the OIDC world should also use the SECEVENT d= raft inside ID Tokens to solve the use case of the draft above).
    =
    For the user !=3D RO cases, I think that potentially having = a way to signal those two items separately in the request and response coul= d be useful. Right now all the user/subject stuff is about identifying =E2= =80=9Cthe user that=E2=80=99s currently here at the client instance=E2=80= =9D, in a variety of forms that the client instance and AS can negotiate. I= f the client or AS has some other notion about who the RO is and how that c= ould be separate from the current user, we could provide a way to signal th= at like you=E2=80=99re proposing below. In my mental model, there are going= to be a lot of use cases where the =E2=80=9CRO=E2=80=9D isn=E2=80=99t know= n to the client at all, but rather to the AS and is based on what the clien= t=E2=80=99s asking for. So I could identify the current user and ask for a = specific medical record, and the AS realizes it has to go bug a particular = doctor to approve things directly. This is instead of interacting with the = current user and failing in an awkward way when the current user doesn=E2= =80=99t have the rights to do things, but someone else would. But we=E2=80= =99d want the system to be able to detect if the current user is the doctor= , so we can just interact with them directly. Does that all track?

    =C2=A0=E2=80=94 Justin

    On Mar 10, 2021, at 4:10 AM, Fabien Imbault <fabi= en.imbault@gmail.com> wrote:

    Hello,
    Notice the question mark in the title. Not to be consider= ed as an editor's comment.
    This thread intends to provide a d= etailed comment on the interesting=C2=A0feedback by Kristina: "I would= catch up on the thread to understand why DIDs are thought to be treated as= assertions".
    In the chat, I answered: "Happy to get th= e discussion on DIDs. Actually, could be either or, depending on what we in= tend to do." Let me expand a bit on that, to make it understandable (d= idn't have the time during the meeting, unfortunately).

    <= /div>
    This relates to the items described on slides 20 and 34, which I&= #39;ll explain further. I'll highlight as transparently as possible wha= t I think would be the benefits and downsides of each. Both are probably vi= able options, but they correspond to different scopes and objectives. I'= ;ll spend a bit more time on option 2, since it is a different approach com= pared to the current draft.

    1. The first possibility is to use S= ECEVENT throughout.=C2=A0
    In that case, DIDs should be a part= of sub_ids (in the core or in the extension registry, depending on what An= nabelle's WG decides). More generally, the WG would have to decide whic= h additional sub_ids it needs (as per Yaron's comment).

    <= /div>
    That's obviously the closest to what is described in draft-04= . It allows a communication of subject information between the client and t= he AS, by using global identifiers (mail, phone, etc.), or using a local op= aque reference=C2=A0- i.e. governed by the AS (that's probably what we = would=C2=A0put in the examples, unless someone has a better idea - cf issue= s #16 and #42).=C2=A0

    Assertions relate for instan= ce to the proof of presence of the RO. The current draft-04 therefore plans= for id_tokens and saml2, maybe there could be other needs later (extension= registry).

    - Benefits: identifiers are a key comp= onent of GNAP, which makes integration easier. Possibly one could choose to= use DIDs throughout.
    - Downsides: email/phone identifiers will p= robably be used throughout by most devs (since that's correlation infor= mation they=C2=A0have in their user DB). Which means we should limit what a= ssertions contain, to avoid doing links between weak global identifiers and= hopefully stronger assertions. That's not really a problem if it's= limited to authentication events mostly (in that perspective, samlv2 could= make sense in the core). An assertion is probably a single value then (not= an array).=C2=A0 =C2=A0

    Option 1 can be summ= arized as:=C2=A0

    "subject": {
    = =C2=A0=C2=A0=C2=A0"sub_ids": { }, // r= equest and response (SECEVENT -> including DID possibly)=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=C2=A0=C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0&= quot;assertions": [ ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 // request and response (id_token or samlv2)
    }
    (&= quot;hints" do not exist currently, but are partially covered separate= ly via "request.user" / the relevance of "principal", d= iscussed in the slide, is a question mark too - which is a different discus= sion on end-user !=3D RO).


    2.= An alternate possibility is to use SECEVENT only as input/hint
    In that case, DIDs should be a part of assertions (which have a differen= t meaning compared to option 1).

    The AS only retur= ns an local opaque reference as_ref (while in option 1, it was only one of = many possibilities). Its only job is to help the client differentiate the r= esponse subject. The AS policy might further define the scope of that refer= ence, as suggested in=C2=A0https://gi= thub.com/ietf-wg-gnap/gnap-core-protocol/issues/210, although I persona= lly=C2=A0viewed that by default as=C2=A0(2) "as_id" an identifier= locally unique to that AS for all the RSs.

    SECEVE= NTS are still useful as an input, that's what I presented in request.hi= nts.self.sub_ids (but it's the responsibility=C2=A0of the AS to match i= t with its own reference system - from instance from the email to AS's = local record XUT2MFM1XBIKJKSDU8Q).=C2=A0Note: since the slides, a new draft= -ietf-secevent-subject-identifiers-07 has been published. Notably this incl= udes an opaque identifier, which the client can use to pass the as_ref hint= to the AS. Thus we wouldn't need any further addition to SECEVENT,=C2= =A0although hints would benefit from further additions (like DIDs for insta= nce). Notice also that subject_types_supported becomes less important, beca= use in the worst case scenario, it's simply=C2=A0a hint that wouldn'= ;t be understood and therefore taken into account by the AS.

    =
    The assertions array has a more important role than in option 1 = (with the explicit aim of separating between client hints and validated inf= o asserted by the AS). It serves as a generic/extendible mapping structure,= e.g. "the AS asserts that opaque reference=C2=A0XUT2MFM1XBIKJKSDU8Q=C2= =A0is matching with these (more or less verifiable) statements." The n= ame assertion therefore corresponds to the responsibility=C2=A0of the AS in= delivering those statements (cf should/must, issue #49). Some of these sta= tements relate to identity or auth events (ex: DID, id_token), some might d= irectly be useful for authorization decisions (like ZKP example in the pare= ntal control example). Possibly some of these validated assertions could be= reused in next interactions.

    Another question tha= t popped-up is the scope of sub_ids. Should they be about the same user? (I= think so). In the case of remote ROs especially, it might be important tha= t DID be considered as an assertion=C2=A0(about someone else's) and not= as sub_ids, because the AS needs to be careful about who the client wants = to reach (avoid spam, etc.). This is consistent with the rest of discussion= on what to do when end-user !=3D RO, although using DIDComm might seem a b= it early (the paint is very fresh).=C2=A0

    Option 2= was summarized as:=C2=A0

    // (sugges= tion only, not as an editor)
    "subject": {=
    =C2= =A0=C2=A0=C2=A0"as_ref": { <= /span> // response only (wouldn=E2=80=99t require SECEV= ENT)
    =E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.c= om=E2=80=9D,
    =E2=80=9Cref=E2=80=9D: =E2=80=9C= XUT2MFM1= XBIKJKSDU8QM=E2=80=9D=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=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"assertions&qu= ot;: [ ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request a= nd response (id_token/jwkthumb/DID/VC/etc. -> whatever info can be valid= ated by the AS)

    =C2=A0=C2=A0=C2=A0&= quot;hints": { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 // request only (optional)
    =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0"self": { <= /span> // replaces request.user (suppor= t SECEVENT here)
    =C2=A0=C2=A0=C2=A0=E2=80=9Csub_= ids=E2=80=9D: { }, // SECEVENT (including opaque in draft-07 - that could contain t= he ref)
    =C2=A0=C2=A0=C2=A0=E2=80=9Cassertions=E2= =80=9D: [ ] // see examples: VC on DOB or ZKP on age (wider scop= e, possibly through extensions)
    },=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=C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"p= rincipal": { // new proposal presented at I= ETF110 (just an idea)
    =C2= =A0 =E2=80=9Cautomated=E2=80=9D: true, = // rule engine
    =C2=A0 =E2=80=9Casync=E2=80=9D: { } // remote ROs
    }=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= =C2=A0=C2=A0}
    }

    - Benefits: as_ref is self supporting (no strong coupling with SECEVENT)= , but can still take SECEVENT as an input hint for the AS. It avoids the ri= sk of making an official association between a weak global identifier (e.g.= email, used elsewhere) and hopefully stronger local assertions. GNAP would= be fully agnostic to whatever identity system is used, only facilitating i= nteroperability through assertions (second only in importance=C2=A0compared= to the AS opaque reference). Some assertions (possibly extensions) could a= lso be useful for the AS decision (e.g. VC or ZKP).
    - Downsides: = opaqueness of as_ref is a feature, not a bug. The opaque reference is fully= managed by the AS, therefore not inherently portable (cf portability discu= ssions in OIDC currently). There's no explicit binding to an official i= dentity, only a contextual mapping to AS validated assertions. It makes it = more difficult to match the identifiers from one AS to another or to correl= ate with the client user DB (still possible via assertions, if the AS allow= s it). Assertions are much more generic (possibly via extensions), but migh= t require a more advanced mechanism=C2=A0to request/response only the most = relevant information (which makes the AS policy critical here).
    <= br>
    I hope that clarifies the=C2=A0reasoning for both options. Ag= ain I'm not saying option 2 is better, just saying the trade-offs are d= ifferent (+ knowing that we need to keep it simple).
    - option 1 p= uts more in sub_ids and less in assertions
    - option 2 puts less i= n the reference and more in assertions=C2=A0
    All of this is open = to discussion. More generally speaking, on every part in orange and questio= n mark (?) I would love your ideas and criticisms. What I intended as an ed= itor is only to highlight where the WG has important choices to make, befor= e we can make the related PRs.

    A further side comm= ent: IETF EAT RATS was suggested for assertions, but relates more to the cl= ient attestations. It was added as a comment in=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44= , which is a distinct topic we'll work on.

    Fabien (editor's hat off)

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

    This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.
    --
    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
    --0000000000001f16e705bdb43133-- From nobody Tue Mar 16 22:20:56 2021 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 244323A1AE5 for ; Tue, 16 Mar 2021 22:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, T_REMOTE_IMAGE=0.01, 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 OuV4xtd6ZFT2 for ; Tue, 16 Mar 2021 22:20:50 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 D822F3A1AE7 for ; Tue, 16 Mar 2021 22:20:49 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id g27so39740792iox.2 for ; Tue, 16 Mar 2021 22:20: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=u/JxhJpUWOClPUJmZKf6tbRfk/2q0UnHqsqTMkqH2HI=; b=XpaULEjpqA62ODAKwZ3xPOrxhcdul+I31hLadPRd8deGmxagwOVdMWPYAhRCGEy/Np 5On6OrZFgaptK51XpkU5lJkP2HN2M1sEH0EfHR95YWKxo5CuBWZqyBWIPH4ghUOWG/H3 x5I936T6nYjpFQhkvbl7GfSdCfn/HTyLUbWkpvN+Ifg/aXtm78ZShwkuP3/du7xu2Gsw rEtLLxfkbzSCw33LcIormOS/OP8FL4cv8kKCOzHhW4jWmRtKZFsUye3P6HIseInwFE02 VyG6kHGOAP5NXp+DefOXLTlkTbxPJWHsYqMuJyBv6rJFO+uJoFMlnTedDbCWmVhojFMR sL0w== 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=u/JxhJpUWOClPUJmZKf6tbRfk/2q0UnHqsqTMkqH2HI=; b=NpCD11rzNGKc/OYCb4LcbApM8GLYQ3T4d5AQX+A1n6kxMjuHYmGzrrcJ3rImGF94tn 1aSBdVRX5eWuyQ8UkH8Owl8Ygueckhpmpyy8rkmp2a77x89IOhw2psLfpdhQekhTeR/1 j1CilR8yKCsOL9HgN4IFeFLkKM3WIXnLL221fR8XD7BbdFxeXbOeaZLsbIqhT4u+/7R5 GK48pZh9mYmDOiRXDrgCGWPpOLB7kUVPaW6h7FoVcMfiyQOapFnAp5jrKH0VXNAb/vti BNAYG6km9eYMlljb4E2XY74sfEpUSRyvrMDPHxBSlqmHjod2ffkwtNd1qd9J0RmtVnzO r7Yg== X-Gm-Message-State: AOAM5326ciWvwSide+St/8kTU7wNfow6+BLvSn9siopmDV7pS0BfAx1S Dry0gmsSFwBOhshUPRVUEGZFl0gomZjjNyAmDiw= X-Google-Smtp-Source: ABdhPJxO1ppT/ajbvSeWlW+LcM4zxOVvpFT3RSIjNwxFaOhoTl/IETN0DwdsQmBr4SPgiZUEzUkzVqZEk7Et4ExwG/g= X-Received: by 2002:a02:94cb:: with SMTP id x69mr1655973jah.8.1615958447200; Tue, 16 Mar 2021 22:20:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Wed, 17 Mar 2021 06:20:33 +0100 Message-ID: To: Adrian Gropper Cc: GNAP Mailing List , Justin Richer , Tobias Looker Content-Type: multipart/alternative; boundary="000000000000379fc905bdb4a532" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 05:20:55 -0000 --000000000000379fc905bdb4a532 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Currently I mostly see DID as alternative subject identifier (again hypothetically since not currently included in SECEVENT). You're right that DIDs could serve other purposes too. Denis has also asked an interesting question on whether sub_ids might be used within the access tokens (issue #210). I do see some value in supporting VCs for assertions. In my early attempts to map that, it seems to be applicable to the client instance (like the client posture, or even a VP for the display) or to the end-user (request.user). We need to keep in mind that a big part of that discussion also depends on what the SECEVENT WG decides. Fabien Le mer. 17 mars 2021 =C3=A0 05:48, Adrian Gropper = a =C3=A9crit : > What do you mean the scope is restricted to the subject? DIDs are valuabl= e > for all end-users and things like did:web can help interop with RSs. A > client might not have a DID but it could have a VC as a certificate of > authenticity linked to some audit mechanism. > > Adrian > > On Tue, Mar 16, 2021 at 11:42 PM Fabien Imbault > wrote: > >> Noted. I agree with that goal. >> >> Back to identifiers, even if we'd use DIDs, the scope is restricted to >> the subject. >> >> Fabien >> >> >> Le mer. 17 mars 2021 =C3=A0 04:04, Adrian Gropper a >> =C3=A9crit : >> >>> Thanks, Fabien. >>> >>> We need to be verrry careful about the shortcuts once we add user and >>> end-user to our spec. RO =3D subject (of the resource secured by a RS) = is >>> clear and independent of any AS or clients. DIDs can be helpful for the >>> RO-RS relationship for authentication, encryption, and service endpoint= s. >>> Authentication can facilitate pseudonymity by default. Encryption, for >>> example, can allow mediated communications for privacy enhancement. >>> >>> When we bring the request of an end-user into the picture, the DID can >>> apply to someone other than the RO / subject. The DID can secure claims >>> that had nothing to do with the RO-RS (as you point out in #197). Also,= in >>> many cases, the subject DID known to the requesting party might be >>> different from the DID associated with the RO at the RS. This promotes >>> privacy through DIDs as same-domain identifiers but has to be dealt wit= h at >>> the policy decision point where capabilities are filtered. >>> >>> Another source of potential confusion comes from the way we use client. >>> DIDs are generally not associated with a client except to the extent th= e >>> client is a user-agent such as a mobile wallet or an online policy and >>> capabilities agent. >>> >>> My suggestion is that we arrive at a set of consistent names soon and >>> present them early in the spec - in what is now Section 1.2 - and avoid >>> using any shortcuts in the rest of the spec. I would also suggest we >>> provide examples of the use of DIDs relative to the names we define in = 1.2. >>> >>> Adrian >>> >>> On Tue, Mar 16, 2021 at 10:51 PM Fabien Imbault < >>> fabien.imbault@gmail.com> wrote: >>> >>>> Note also that there's issue 197 that discussed that very question. >>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/197 >>>> >>>> Le mer. 17 mars 2021 =C3=A0 03:34, Fabien Imbault >>>> a =C3=A9crit : >>>> >>>>> Hi Adrian, >>>>> >>>>> As the name suggests, it's an identifier for the subject (and so, >>>>> hypothetically, a DID to identify the subject). The text indeed conce= rns >>>>> the subject as the RO, as it is known to the AS. >>>>> >>>>> But it's easy to make shortcuts, because often we end-up dealing with >>>>> is user =3D end-user =3D RO =3D subject. >>>>> >>>>> Fabien >>>>> >>>>> Le mer. 17 mars 2021 =C3=A0 03:10, Adrian Gropper >>>>> a =C3=A9crit : >>>>> >>>>>> I'm late to this conversation and confused by Tobias' use of End-Use= r >>>>>> (his caps) and subject. Are we talking about a DID for the subject, = the >>>>>> end-user, or both? >>>>>> >>>>>> To be clear, in my mind, the subject is in control of policies and >>>>>> capabilities at the GNAP AS. The end-user is in control of a client = or user >>>>>> agent and a request to the AS. The end-user and client may or may no= t have >>>>>> any prior relationship with the AS. >>>>>> >>>>>> Adrian >>>>>> >>>>>> On Tue, Mar 16, 2021 at 10:00 PM Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>>> Hi Tobias, >>>>>>> >>>>>>> Not yet (none of the current sub_ids require additional parameters) >>>>>>> but if DIDs do get added to subject identifiers, then it's certainl= y >>>>>>> something we would have to support. >>>>>>> >>>>>>> There's already a very basic version of that, but only to chose the >>>>>>> main type (now called "format" in latest draft 07 of SECEVENT), wit= h >>>>>>> subject_types_supported in the discovery. >>>>>>> >>>>>>> Thanks for the heads up, it's worth creating an issue or putting a >>>>>>> note in some existing issue to not forget looking into that. >>>>>>> >>>>>>> Cheers >>>>>>> Fabien >>>>>>> >>>>>>> >>>>>>> Le mer. 17 mars 2021 =C3=A0 01:01, Tobias Looker >>>>>>> a =C3=A9crit : >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> This is probably out of scope for the current conversation but has >>>>>>>> any thought been had on how the client instance could communicate >>>>>>>> additional options around what subject identifier types it support= s for >>>>>>>> cases where the client instance will perhaps be required to conduc= t >>>>>>>> additional processing on the artifacts returned by the AS? As an e= xample if >>>>>>>> the AS chose to identify the subject (End-User) using a DID and wa= nted to >>>>>>>> include an additional cryptographic assertion that showed it contr= ols keys >>>>>>>> appropriately associated to the DID, then the client may have want= ed to >>>>>>>> communicate some information up front in their request to ensure t= hey can >>>>>>>> perform this additional processing, such as the signature suites i= t >>>>>>>> supports and in the context of DIDs potentially which DID methods = it is >>>>>>>> capable of resolving? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> [image: Mattr website] >>>>>>>> *Tobias Looker* >>>>>>>> Mattr >>>>>>>> +64 (0) 27 378 0461 >>>>>>>> tobias.looker@mattr.global >>>>>>>> [image: Mattr website] [image: Mattr on >>>>>>>> LinkedIn] [image: >>>>>>>> Mattr on Twitter] [image: Mattr >>>>>>>> on Github] >>>>>>>> This communication, including any attachments, is confidential. If >>>>>>>> you are not the intended recipient, you should not read it - pleas= e contact >>>>>>>> me immediately, destroy it, and do not copy or use any part of thi= s >>>>>>>> communication or disclose anything about it. Thank you. Please not= e that >>>>>>>> this communication does not designate an information system for th= e >>>>>>>> purposes of the Electronic Transactions Act 2002. >>>>>>>> >>>>>>>> >>>>>>>> On Sat, Mar 13, 2021 at 9:26 PM Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi Justin, >>>>>>>>> >>>>>>>>> A last word on end-user! =3DRO (again just as food for thought). >>>>>>>>> >>>>>>>>> As soon as hints.automated is set to true, it takes priority over >>>>>>>>> async, which means it's the same model as the one you describe : = the AS has >>>>>>>>> precedence over any other remote contact. >>>>>>>>> >>>>>>>>> So that confirms the global view that the AS is the one with the >>>>>>>>> authority, and that it might know more than the client. >>>>>>>>> >>>>>>>>> Cheers >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> Le jeu. 11 mars 2021 =C3=A0 11:44, Fabien Imbault < >>>>>>>>> fabien.imbault@gmail.com> a =C3=A9crit : >>>>>>>>> >>>>>>>>>> Hi Justin, >>>>>>>>>> >>>>>>>>>> I think that's interesting: >>>>>>>>>> "For the user !=3D RO cases, I think that potentially having a w= ay >>>>>>>>>> to signal those two items separately in the request and response= could be >>>>>>>>>> useful. Right now all the user/subject stuff is about identifyin= g =E2=80=9Cthe user >>>>>>>>>> that=E2=80=99s currently here at the client instance=E2=80=9D, i= n a variety of forms that >>>>>>>>>> the client instance and AS can negotiate. If the client or AS ha= s some >>>>>>>>>> other notion about who the RO is and how that could be separate = from the >>>>>>>>>> current user, we could provide a way to signal that like you=E2= =80=99re proposing >>>>>>>>>> below. In my mental model, there are going to be a lot of use ca= ses where >>>>>>>>>> the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the client at al= l, but rather to the AS and is >>>>>>>>>> based on what the client=E2=80=99s asking for. So I could identi= fy the current user >>>>>>>>>> and ask for a specific medical record, and the AS realizes it ha= s to go bug >>>>>>>>>> a particular doctor to approve things directly. This is instead = of >>>>>>>>>> interacting with the current user and failing in an awkward way = when the >>>>>>>>>> current user doesn=E2=80=99t have the rights to do things, but s= omeone else would. >>>>>>>>>> But we=E2=80=99d want the system to be able to detect if the cur= rent user is the >>>>>>>>>> doctor, so we can just interact with them directly. Does that al= l track?" >>>>>>>>>> >>>>>>>>>> I agree with the general idea. In the end, that's the AS's >>>>>>>>>> responsibility (and also a big part of its value as a policy eng= ine). >>>>>>>>>> >>>>>>>>>> Even in the cases - as I suggested - where the client would be >>>>>>>>>> able to signal what it knows (or thinks it knows) about the subj= ect, the AS >>>>>>>>>> still needs to validate what it can. The client could be an atta= cker lying >>>>>>>>>> to the AS. Or there could be an unintended bug. >>>>>>>>>> >>>>>>>>>> The client still seems like a straightforward source to gather >>>>>>>>>> optional/declarative hints. Which is what request.user is alread= y doing in >>>>>>>>>> spirit. In many cases, the AS should go a step further. Validate >>>>>>>>>> cryptographic statements from a more reputable issuer, whatever = helps. >>>>>>>>>> >>>>>>>>>> Contacts might be one of the possibilities. I'm not suggesting >>>>>>>>>> interact/fail scenarii at all, which I see as anti-ergonomic (co= mposability >>>>>>>>>> with timeouts and fallback is the answer to that). The failure I= was >>>>>>>>>> considering is only for async calls explicitly requested by the = client >>>>>>>>>> (which is considered in sequence 1.4.3, and not coming from me),= there's >>>>>>>>>> obviously no way to ensure a remote RO would actually respond wh= en the >>>>>>>>>> client expects it. If that sequence is considered, realistic fai= lure modes >>>>>>>>>> should be anticipated and dealt with internally (just like any d= istributed >>>>>>>>>> program would do), is all I'm saying. And so from the outside, t= here's no >>>>>>>>>> interact/fail. >>>>>>>>>> That's the same as in real life: when booking a business trip, a= n >>>>>>>>>> employee could either follow the generic rule (2nd class train t= icket) or >>>>>>>>>> reach out to his manager, explaining that it's a long trip and t= hat 1st >>>>>>>>>> class would be better. The employee knows the manager might not = instantly >>>>>>>>>> respond, and knows that the absence of an answer means he'll hav= e to go for >>>>>>>>>> the 2nd class. >>>>>>>>>> >>>>>>>>>> There will be cases when the client doesn't know the RO. I'm not >>>>>>>>>> sure if that's a majority of cases, but it will definitely happe= n. It could >>>>>>>>>> happen when you interact with an organization or a team and have= no idea >>>>>>>>>> who's responsible or what delegations are in place (some of thos= e cases >>>>>>>>>> have been described by Adrian for instance). >>>>>>>>>> There could also be cases where the ownership could be >>>>>>>>>> distributed (an example was provided when considering remote ROs= ). Again in >>>>>>>>>> real life, it's not unusual for a decision to fallback on a depu= ty when the >>>>>>>>>> main decision maker is unavailable. Or there could be an open go= vernance >>>>>>>>>> even, but maybe that's one step too far. >>>>>>>>>> >>>>>>>>>> Of course, if the AS has internal knowledge or other ways to get >>>>>>>>>> the information it should use it. Remains to be seen how we can = specify >>>>>>>>>> that (cf issue #49 on should/must). The example with doctor/pati= ent is fine >>>>>>>>>> if hardcoded, but it becomes a problem when we fail to understan= d the real >>>>>>>>>> relationships in environments of various sensitive nature. How t= he AS >>>>>>>>>> identifies that a specific record requires approval from Doctor = Bob might >>>>>>>>>> be context dependent (sometimes it could be a nurse, a team of d= octors, >>>>>>>>>> another medical organization, etc.). Maybe you could have variou= s levels of >>>>>>>>>> authorizations (extreme example: military style classifications)= , so that >>>>>>>>>> it might even be impossible to tell who can be contacted. >>>>>>>>>> >>>>>>>>>> That's also why I was suggesting assertions could go beyond >>>>>>>>>> authentication events, and include cryptographic assertions for >>>>>>>>>> authorization purposes. Maybe we can even imagine a risk based a= pproach, as >>>>>>>>>> in some cases we won't know for sure. >>>>>>>>>> >>>>>>>>>> The difficulty will be to be sufficiently generic but simple >>>>>>>>>> enough. Maybe we can rule out some cases. Maybe remote async con= tacts are >>>>>>>>>> out of scope, because we only want instantaneous authorizations.= Most of >>>>>>>>>> those cases are way beyond what OAuth2 does. I don't know. But w= hat's >>>>>>>>>> certain is that the WG should decide what support for cases wher= e end-user >>>>>>>>>> !=3D RO it intends to provide. My discussion was just a very sma= ll >>>>>>>>>> Chesterston's Fence contribution, even if that seems to have sur= prised. >>>>>>>>>> >>>>>>>>>> Fabien >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Mar 10, 2021 at 8:18 PM Justin Richer >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Fabien, >>>>>>>>>>> >>>>>>>>>>> First, thanks for doing the heavy lift of writing this topic up= . >>>>>>>>>>> Of these options, I would strongly prefer option (1). The diffe= rence >>>>>>>>>>> between assertions and identifiers is that an assertion is a fu= lly packaged >>>>>>>>>>> set of attributes, one of which can be an identifier. They are,= generally >>>>>>>>>>> speaking, cryptographically protected bundles. They=E2=80=99re = designed to carry a >>>>>>>>>>> bunch of different information about a user and the authenticat= ion event in >>>>>>>>>>> a form that=E2=80=99s independently verifiable and auditable. S= AML assertions (XML >>>>>>>>>>> document) and ID Tokens (signed JWTs) are the most common ones = we see >>>>>>>>>>> today, but other formats exist and will keep being invented. >>>>>>>>>>> >>>>>>>>>>> An identifier is a different kind of creature. It is a single >>>>>>>>>>> statement that identifies the party in question in the context = of the party >>>>>>>>>>> doing the identification. It=E2=80=99s this full context that t= he receiver of the >>>>>>>>>>> identifier needs to interpret it in. When using a federated ide= ntity >>>>>>>>>>> protocol, each RP is going to have :some: kind of local user in= formation >>>>>>>>>>> store that they=E2=80=99re going to tie into, some field in a d= atabase they=E2=80=99ll key >>>>>>>>>>> off of. It=E2=80=99s just never going to be the case that all R= Ps will be able to >>>>>>>>>>> use server-provided opaque identifiers for all cases. Account r= ecovery and >>>>>>>>>>> binding is one such use case where a user-facing identifier lik= e an email >>>>>>>>>>> address makes a LOT of sense, for one small example. This is an= array in >>>>>>>>>>> the request and response precisely because a user could be know= n by several >>>>>>>>>>> different identifiers to a party, and an RP will have a better = idea about >>>>>>>>>>> what kinds of things it wants to correlate against, and it=E2= =80=99s up to the AS >>>>>>>>>>> to provide that mapping. I think that if we don=E2=80=99t defin= e a way to describe >>>>>>>>>>> the format, the =E2=80=9Cas_id=E2=80=9D field is going to get s= tructure back-patched onto >>>>>>>>>>> it like is being proposed here: >>>>>>>>>>> >>>>>>>>>>> https://mattrglobal.github.io/oidc-portable-identities/ >>>>>>>>>>> >>>>>>>>>>> I=E2=80=99m personally not a fan of that approach as it mixes t= he data >>>>>>>>>>> layering too much, and you end up making guesses about whether = a field is >>>>>>>>>>> meaningful or a pointer. I think GNAP will be much better serve= d by using a >>>>>>>>>>> data structure for this from the start. DIDs should be another = =E2=80=9Cformat=E2=80=9D of >>>>>>>>>>> the subject identifier. I don=E2=80=99t think GNAP should defin= e this format, and >>>>>>>>>>> I=E2=80=99ve dropped a note to the SECEVENT mailing list asking= about adding DIDs >>>>>>>>>>> to the subject identifiers draft before it gets published. DIDs= are not >>>>>>>>>>> assertions, even in the cases where they point to fully functio= nal DID >>>>>>>>>>> documents with user information in them. (And for what it=E2=80= =99s worth, I think >>>>>>>>>>> the OIDC world should also use the SECEVENT draft inside ID Tok= ens to solve >>>>>>>>>>> the use case of the draft above). >>>>>>>>>>> >>>>>>>>>>> For the user !=3D RO cases, I think that potentially having a w= ay >>>>>>>>>>> to signal those two items separately in the request and respons= e could be >>>>>>>>>>> useful. Right now all the user/subject stuff is about identifyi= ng =E2=80=9Cthe user >>>>>>>>>>> that=E2=80=99s currently here at the client instance=E2=80=9D, = in a variety of forms that >>>>>>>>>>> the client instance and AS can negotiate. If the client or AS h= as some >>>>>>>>>>> other notion about who the RO is and how that could be separate= from the >>>>>>>>>>> current user, we could provide a way to signal that like you=E2= =80=99re proposing >>>>>>>>>>> below. In my mental model, there are going to be a lot of use c= ases where >>>>>>>>>>> the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the client at a= ll, but rather to the AS and is >>>>>>>>>>> based on what the client=E2=80=99s asking for. So I could ident= ify the current user >>>>>>>>>>> and ask for a specific medical record, and the AS realizes it h= as to go bug >>>>>>>>>>> a particular doctor to approve things directly. This is instead= of >>>>>>>>>>> interacting with the current user and failing in an awkward way= when the >>>>>>>>>>> current user doesn=E2=80=99t have the rights to do things, but = someone else would. >>>>>>>>>>> But we=E2=80=99d want the system to be able to detect if the cu= rrent user is the >>>>>>>>>>> doctor, so we can just interact with them directly. Does that a= ll track? >>>>>>>>>>> >>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>> >>>>>>>>>>> On Mar 10, 2021, at 4:10 AM, Fabien Imbault < >>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Notice the question mark in the title. Not to be considered as >>>>>>>>>>> an editor's comment. >>>>>>>>>>> This thread intends to provide a detailed comment on the >>>>>>>>>>> interesting feedback by Kristina: "I would catch up on the thre= ad to >>>>>>>>>>> understand why DIDs are thought to be treated as assertions". >>>>>>>>>>> In the chat, I answered: "Happy to get the discussion on DIDs. >>>>>>>>>>> Actually, could be either or, depending on what we intend to do= ." Let me >>>>>>>>>>> expand a bit on that, to make it understandable (didn't have th= e time >>>>>>>>>>> during the meeting, unfortunately). >>>>>>>>>>> >>>>>>>>>>> This relates to the items described on slides 20 and 34, which >>>>>>>>>>> I'll explain further. I'll highlight as transparently as possib= le what I >>>>>>>>>>> think would be the benefits and downsides of each. Both are pro= bably viable >>>>>>>>>>> options, but they correspond to different scopes and objectives= . I'll spend >>>>>>>>>>> a bit more time on option 2, since it is a different approach c= ompared to >>>>>>>>>>> the current draft. >>>>>>>>>>> >>>>>>>>>>> *1. The first possibility is to use SECEVENT throughout. * >>>>>>>>>>> In that case, DIDs should be a part of sub_ids (in the core or >>>>>>>>>>> in the extension registry, depending on what Annabelle's WG dec= ides). More >>>>>>>>>>> generally, the WG would have to decide which additional sub_ids= it needs >>>>>>>>>>> (as per Yaron's comment). >>>>>>>>>>> >>>>>>>>>>> That's obviously the closest to what is described in draft-04. >>>>>>>>>>> It allows a communication of subject information between the cl= ient and the >>>>>>>>>>> AS, by using global identifiers (mail, phone, etc.), or using a= local >>>>>>>>>>> opaque reference - i.e. governed by the AS (that's probably wha= t we >>>>>>>>>>> would put in the examples, unless someone has a better idea - c= f issues #16 >>>>>>>>>>> and #42). >>>>>>>>>>> >>>>>>>>>>> Assertions relate for instance to the proof of presence of the >>>>>>>>>>> RO. The current draft-04 therefore plans for id_tokens and saml= 2, maybe >>>>>>>>>>> there could be other needs later (extension registry). >>>>>>>>>>> >>>>>>>>>>> - Benefits: identifiers are a key component of GNAP, which make= s >>>>>>>>>>> integration easier. Possibly one could choose to use DIDs throu= ghout. >>>>>>>>>>> - Downsides: email/phone identifiers will probably be used >>>>>>>>>>> throughout by most devs (since that's correlation information t= hey have in >>>>>>>>>>> their user DB). Which means we should limit what assertions con= tain, to >>>>>>>>>>> avoid doing links between weak global identifiers and hopefully= stronger >>>>>>>>>>> assertions. That's not really a problem if it's limited to auth= entication >>>>>>>>>>> events mostly (in that perspective, samlv2 could make sense in = the core). >>>>>>>>>>> An assertion is probably a single value then (not an array). >>>>>>>>>>> >>>>>>>>>>> Option 1 can be summarized as: >>>>>>>>>>> >>>>>>>>>>> "subject": { >>>>>>>>>>> "sub_ids": { }, // request and response (SECEVENT -> >>>>>>>>>>> including DID possibly) >>>>>>>>>>> "assertions": [ ], // request and response >>>>>>>>>>> (id_token or samlv2) >>>>>>>>>>> } >>>>>>>>>>> ("hints" do not exist currently, but are partially covered >>>>>>>>>>> separately via "request.user" / the relevance of "principal", d= iscussed in >>>>>>>>>>> the slide, is a question mark too - which is a different discus= sion on >>>>>>>>>>> end-user !=3D RO). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *2. An alternate possibility is to use SECEVENT only as >>>>>>>>>>> input/hint* >>>>>>>>>>> In that case, DIDs should be a part of assertions (which have a >>>>>>>>>>> different meaning compared to option 1). >>>>>>>>>>> >>>>>>>>>>> The AS only returns an local opaque reference as_ref (while in >>>>>>>>>>> option 1, it was only one of many possibilities). Its only job = is to help >>>>>>>>>>> the client differentiate the response subject. The AS policy mi= ght further >>>>>>>>>>> define the scope of that reference, as suggested in >>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210, >>>>>>>>>>> although I personally viewed that by default as (2) "as_id" an = identifier >>>>>>>>>>> locally unique to that AS for all the RSs. >>>>>>>>>>> >>>>>>>>>>> SECEVENTS are still useful as an input, that's what I presented >>>>>>>>>>> in request.hints.self.sub_ids (but it's the responsibility of t= he AS to >>>>>>>>>>> match it with its own reference system - from instance from the= email to >>>>>>>>>>> AS's local record XUT2MFM1XBIKJKSDU8Q). Note: since the slides,= a new >>>>>>>>>>> draft-ietf-secevent-subject-identifiers-07 has been published. = Notably this >>>>>>>>>>> includes an opaque identifier, which the client can use to pass= the as_ref >>>>>>>>>>> hint to the AS. Thus we wouldn't need any further addition to >>>>>>>>>>> SECEVENT, although hints would benefit from further additions (= like DIDs >>>>>>>>>>> for instance). Notice also that subject_types_supported becomes= less >>>>>>>>>>> important, because in the worst case scenario, it's simply a hi= nt that >>>>>>>>>>> wouldn't be understood and therefore taken into account by the = AS. >>>>>>>>>>> >>>>>>>>>>> The assertions array has a more important role than in option 1 >>>>>>>>>>> (with the explicit aim of separating between client hints and v= alidated >>>>>>>>>>> info asserted by the AS). It serves as a generic/extendible map= ping >>>>>>>>>>> structure, e.g. "the AS asserts that opaque reference >>>>>>>>>>> XUT2MFM1XBIKJKSDU8Q is matching with these (more or less >>>>>>>>>>> verifiable) statements." The name assertion therefore correspon= ds to the >>>>>>>>>>> responsibility of the AS in delivering those statements (cf sho= uld/must, >>>>>>>>>>> issue #49). Some of these statements relate to identity or auth= events (ex: >>>>>>>>>>> DID, id_token), some might directly be useful for authorization= decisions >>>>>>>>>>> (like ZKP example in the parental control example). Possibly so= me of these >>>>>>>>>>> validated assertions could be reused in next interactions. >>>>>>>>>>> >>>>>>>>>>> Another question that popped-up is the scope of sub_ids. Should >>>>>>>>>>> they be about the same user? (I think so). In the case of remot= e ROs >>>>>>>>>>> especially, it might be important that DID be considered as an >>>>>>>>>>> assertion (about someone else's) and not as sub_ids, because th= e AS needs >>>>>>>>>>> to be careful about who the client wants to reach (avoid spam, = etc.). This >>>>>>>>>>> is consistent with the rest of discussion on what to do when en= d-user !=3D >>>>>>>>>>> RO, although using DIDComm might seem a bit early (the paint is= very >>>>>>>>>>> fresh). >>>>>>>>>>> >>>>>>>>>>> Option 2 was summarized as: >>>>>>>>>>> >>>>>>>>>>> // (suggestion only, not as an editor) >>>>>>>>>>> "subject": { >>>>>>>>>>> "as_ref": { // response only (wouldn=E2=80=99t require SECEV= ENT) >>>>>>>>>>> =E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D, >>>>>>>>>>> =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D >>>>>>>>>>> }, >>>>>>>>>>> "assertions": [ ], // request and response >>>>>>>>>>> (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validate= d by the AS) >>>>>>>>>>> >>>>>>>>>>> "hints": { // request only (optional) >>>>>>>>>>> "self": { // replaces request.user (support SECEVENT here= ) >>>>>>>>>>> =E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaqu= e in draft-07 - >>>>>>>>>>> that could contain the ref) >>>>>>>>>>> =E2=80=9Cassertions=E2=80=9D: [ ] // see examples: VC on DOB= or ZKP on age >>>>>>>>>>> (wider scope, possibly through extensions) >>>>>>>>>>> }, >>>>>>>>>>> "principal": { // new proposal presented at IETF110 (just >>>>>>>>>>> an idea) >>>>>>>>>>> =E2=80=9Cautomated=E2=80=9D: true, // rule engine >>>>>>>>>>> =E2=80=9Casync=E2=80=9D: { } // remote ROs >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> - Benefits: as_ref is self supporting (no strong coupling with >>>>>>>>>>> SECEVENT), but can still take SECEVENT as an input hint for the= AS. It >>>>>>>>>>> avoids the risk of making an official association between a wea= k global >>>>>>>>>>> identifier (e.g. email, used elsewhere) and hopefully stronger = local >>>>>>>>>>> assertions. GNAP would be fully agnostic to whatever identity s= ystem is >>>>>>>>>>> used, only facilitating interoperability through assertions (se= cond only in >>>>>>>>>>> importance compared to the AS opaque reference). Some assertion= s (possibly >>>>>>>>>>> extensions) could also be useful for the AS decision (e.g. VC o= r ZKP). >>>>>>>>>>> - Downsides: opaqueness of as_ref is a feature, not a bug. The >>>>>>>>>>> opaque reference is fully managed by the AS, therefore not inhe= rently >>>>>>>>>>> portable (cf portability discussions in OIDC currently). There'= s no >>>>>>>>>>> explicit binding to an official identity, only a contextual map= ping to AS >>>>>>>>>>> validated assertions. It makes it more difficult to match the i= dentifiers >>>>>>>>>>> from one AS to another or to correlate with the client user DB = (still >>>>>>>>>>> possible via assertions, if the AS allows it). Assertions are m= uch more >>>>>>>>>>> generic (possibly via extensions), but might require a more adv= anced >>>>>>>>>>> mechanism to request/response only the most relevant informatio= n (which >>>>>>>>>>> makes the AS policy critical here). >>>>>>>>>>> >>>>>>>>>>> I hope that clarifies the reasoning for both options. Again I'm >>>>>>>>>>> not saying option 2 is better, just saying the trade-offs are d= ifferent (+ >>>>>>>>>>> knowing that we need to keep it simple). >>>>>>>>>>> - option 1 puts more in sub_ids and less in assertions >>>>>>>>>>> - option 2 puts less in the reference and more in assertions >>>>>>>>>>> All of this is open to discussion. More generally speaking, on >>>>>>>>>>> every part in orange and question mark (?) I would love your id= eas and >>>>>>>>>>> criticisms. What I intended as an editor is only to highlight w= here the WG >>>>>>>>>>> has important choices to make, before we can make the related P= Rs. >>>>>>>>>>> >>>>>>>>>>> A further side comment: IETF EAT RATS was suggested for >>>>>>>>>>> assertions, but relates more to the client attestations. It was= added as a >>>>>>>>>>> comment in >>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, >>>>>>>>>>> which is a distinct topic we'll work on. >>>>>>>>>>> >>>>>>>>>>> Fabien (editor's hat off) >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> 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 >>>>>>>>> >>>>>>>> >>>>>>>> This communication, including any attachments, is confidential. If= you are not the intended recipient, you should not read it - please contac= t me immediately, destroy it, and do not copy or use any part of this commu= nication or disclose anything about it. Thank you. Please note that this co= mmunication does not designate an information system for the purposes of th= e Electronic Transactions Act 2002. >>>>>>>> >>>>>>>> -- >>>>>>> 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 >> > --000000000000379fc905bdb4a532 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Currently I mostly see DID as alternative subject id= entifier (again hypothetically since not currently included in SECEVENT).

    You're right that DID= s could serve other purposes too.=C2=A0Denis has also asked an interesting question on whether sub_ids might be= used within the access tokens (issue #210).=C2=A0

    I do see some value in supporting VCs for= assertions. In my early attempts to map that, it seems to be applicable to= the client instance (like the client posture, or even a VP for the display= ) or to the end-user (request.user).=C2=A0

    We need to keep in mind that a big part of that discussi= on also depends on what the SECEVENT WG decides.=C2=A0

    Fabien=C2=A0

    L= e mer. 17 mars 2021 =C3=A0 05:48, Adrian Gropper <agropper@healthurl= .com> a =C3=A9crit=C2=A0:
    What do you mean the scope is restricted to the subject? DID= s are valuable for all end-users and things like did:web can help interop w= ith RSs. A client might not have a DID but it could have a VC as a certific= ate of authenticity linked to some audit mechanism.

    Adri= an

    On Tue, Mar 16, 2021 at 11:42 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Noted. I agree with that goal.

    <= div dir=3D"auto">Back to identifiers, even if we'd use DIDs, the scope = is restricted to the subject.=C2=A0=C2=A0

    =
    Fabien


    Le mer. 17 mars 2021 =C3=A0 04:04, Adrian Gro= pper <agropper@healthurl.com> a =C3=A9crit=C2=A0:<= br>
    Thanks, Fabien.

    We need to be verrry careful about the shortcuts once we add user and e= nd-user to our spec. RO =3D subject (of the resource secured by a RS) is cl= ear and independent of any AS or clients. DIDs can be helpful for the RO-RS= relationship for authentication, encryption, and service endpoints. Authen= tication can facilitate pseudonymity by default. Encryption, for example, c= an allow mediated communications for privacy=C2=A0enhancement.=C2=A0
    <= div style=3D"color:rgb(0,0,0)">
    Wh= en we bring the request of an end-user into the picture, the DID can apply = to someone other than the RO / subject. The DID can secure claims that had = nothing to do with the=C2=A0RO-RS (as you point out in #197). Also, in many= cases, the subject DID known to the requesting party might be different fr= om the DID associated with the RO at the RS. This promotes privacy through = DIDs as same-domain identifiers but has to be dealt with at the policy deci= sion point where capabilities are filtered.=C2=A0

    Another source of pot= ential confusion comes from the way we use client. DIDs are generally not a= ssociated with a client except to the extent the client is a user-agent suc= h as a mobile wallet or an online policy and capabilities agent.

    My sug= gestion is that we arrive at a set of consistent names soon and present the= m early in the spec - in what is now Section 1.2 - and avoid using any shor= tcuts in the rest of the spec. I would also suggest we provide examples of = the use of DIDs relative to the names we define in 1.2.=C2=A0

    Adrian

    On Tue, Mar 16, 2021 at 10:51 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Note also that there's issue 197 that discu= ssed that very question.=C2=A0

    Le mer. 17 mars 2= 021 =C3=A0 03:34, Fabien Imbault <fabien.imbault@gmail.com> a =C3=A9crit=C2=A0:=
    Hi Adrian,
    As the name suggests, it's an identifier for = the subject (and so, hypothetically, a DID to identify the subject). The te= xt indeed concerns the subject as the RO, as it is known to the AS.=C2=A0

    But it's easy to make= shortcuts, because often we end-up dealing with is user =3D end-user =3D R= O =3D subject.=C2=A0

    Fab= ien=C2=A0

    Le mer. 17 mars 2021 =C3=A0 03:10, Adrian Gropper <= ;agro= pper@healthurl.com> a =C3=A9crit=C2=A0:
    =
    I'm late to this conversation and confused by Tobias&#= 39; use of End-User (his caps)=C2=A0and subject. Are we talking about a DID= for the subject, the end-user, or both?

    To be clear, in= my mind, the subject is in control=C2=A0of policies and capabilities at th= e GNAP AS. The end-user is in control=C2=A0of a client or user agent and a = request to the AS. The end-user and client may or may not have any prior re= lationship with the AS.

    Adrian

    On Tue, Mar 16= , 2021 at 10:00 PM Fabien Imbault <fabien.imbault@gmail.com&= gt; wrote:
    Hi Tobias,

    Not yet (none of the current sub_ids = require additional parameters) but if DIDs do get added to subject identifi= ers, then it's certainly something we would have to support.=C2=A0

    There's already a very b= asic version of that, but only to chose the main type (now called "for= mat" in latest draft 07 of SECEVENT), with subject_types_supported in = the discovery.=C2=A0

    Tha= nks for the heads up, it's worth creating an issue or putting a note in= some existing issue to not forget looking into that.=C2=A0

    Cheers
    Fabien<= /div>

    Le mer. 17 mars 2021 =C3=A0 01:01, Tobias Looker <tobias= .looker@mattr.global> a =C3=A9crit=C2=A0:
    Hi,

    This is probably out of scope for the c= urrent conversation but has any thought been had on how the client instance= could communicate additional options around what subject identifier types = it supports for cases where the client instance will perhaps be required to= conduct additional processing on the artifacts returned by the AS? As an e= xample if the AS chose to identify the subject (End-User) using a DID and w= anted to include an additional cryptographic assertion that showed it contr= ols keys appropriately associated to the DID, then the client may have want= ed to communicate some information up front in their request to ensure they= can perform this additional processing, such as the signature suites it su= pports and in the context of DIDs potentially which DID methods it is capab= le of resolving?
    Thanks,
    <= td width=3D"125" valign=3D"top">=3D"Mattr<= /td>
    =C2=A0<= /tr>
    Tobias Looker
    Mat= tr
    +64 (0) 27 378 0461
    tobias.looker@mattr.global
    3D"Mattr3D"Mattr3D"Mattr3D"Mattr

    This communication, including a= ny attachments, is confidential. If you are not the intended recipient, you= should not read it - please contact me immediately, destroy it, and do not= copy or use any part of this communication or disclose anything about it. = Thank you. Please note that this communication does not designate an inform= ation system for the purposes of the Electronic Transactions Act 2002.


    On Sat, Mar 13, 2021 at 9:26 PM Fabien I= mbault <fabien.imbault@gmail.com> wrote:
    Hi Justin,=C2=A0

    A last word on end-user! =3DRO (again= just as food for thought).=C2=A0

    As soon as hints.automated is set to true, it takes priority over= async, which means it's the same model as the one you describe : the A= S has precedence over any other remote contact.=C2=A0

    So that confirms the global view that the AS = is the one with the authority, and that it might know more than the client.= =C2=A0

    Cheers
    Fabien=C2=A0

    Le jeu. 11 mars 202= 1 =C3=A0 11:44, Fabien Imbault <fabien.imbault@gmail.= com> a =C3=A9crit=C2=A0:
    = Hi Justin,

    I think that's interesting:
    "For the user !=3D RO cases, I think that potentially having a way t= o signal those two items separately in the request and response could be us= eful. Right now all the user/subject stuff is about identifying =E2=80=9Cth= e user that=E2=80=99s currently here at the client instance=E2=80=9D, in a = variety of forms that the client instance and AS can negotiate. If the clie= nt or AS has some other notion about who the RO is and how that could be se= parate from the current user, we could provide a way to signal that like yo= u=E2=80=99re proposing below. In my mental model, there are going to be a l= ot of use cases where the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the c= lient at all, but rather to the AS and is based on what the client=E2=80=99= s asking for. So I could identify the current user and ask for a specific m= edical record, and the AS realizes it has to go bug a particular doctor to = approve things directly. This is instead of interacting with the current us= er and failing in an awkward way when the current user doesn=E2=80=99t have= the rights to do things, but someone else would. But we=E2=80=99d want the= system to be able to detect if the current user is the doctor, so we can j= ust interact with them directly. Does that all track?"

    <= /div>
    I agree with the general idea. In the end, that's the AS'= s responsibility (and also a big part of its value as a policy engine). =C2= =A0

    Even in the cases - as I suggested - where the= client would be able to signal what it knows (or thinks it knows) about th= e subject, the AS still needs to validate what it can. The client could be = an attacker lying to the AS. Or there could be an unintended bug.=C2=A0

    The=C2=A0client still seems like a straightforward so= urce to gather optional/declarative hints. Which is what request.user is al= ready doing in spirit. In many cases, the AS should go a step further. Vali= date cryptographic statements from a more reputable issuer, whatever helps.=

    Contacts might be one of the possibilities. I'= ;m not suggesting interact/fail scenarii at all, which I see as anti-ergono= mic (composability with timeouts and fallback is the answer to that). The f= ailure I was considering is only for async calls explicitly requested by th= e client (which is considered in sequence 1.4.3, and not coming from me), t= here's obviously no way to ensure a remote RO would actually respond wh= en the client expects it. If that sequence is considered, realistic failure= modes should be anticipated and dealt with internally (just like any distr= ibuted program would do), is all I'm saying. And so from the outside, t= here's no interact/fail.=C2=A0=C2=A0
    That's the same as i= n real life: when booking a business trip, an employee could either follow = the generic rule (2nd class train ticket) or reach out to his manager, expl= aining that it's a long trip and that 1st class would be better. The em= ployee knows the manager might not instantly respond, and knows that the ab= sence of an answer means he'll have to go for the 2nd class.=C2=A0
    <= /div>

    There will be cases when the=C2=A0client doesn'= ;t know the=C2=A0RO. I'm not sure if that's a majority of cases, bu= t it will definitely happen. It could happen when you interact with an orga= nization or a team and have no idea who's responsible or what delegatio= ns are in place (some of those cases have been described by Adrian for inst= ance).=C2=A0
    There could also be cases where the ownership could = be distributed (an example was provided when considering remote ROs). Again= in real life, it's not unusual for a decision to fallback on a deputy = when the main decision maker is unavailable. Or there could be an open gove= rnance even, but maybe that's one step too far.

    Of course, if the AS has internal knowledge or other ways to get the info= rmation it should use it. Remains to be seen how we can specify that (cf is= sue #49 on should/must). The example with doctor/patient is fine if hardcod= ed, but it becomes a problem when we fail to understand the real relationsh= ips in environments of various sensitive nature. How the AS identifies that= a specific record requires approval from Doctor Bob might be context depen= dent (sometimes it could be a nurse, a team of doctors, another medical org= anization, etc.). Maybe you could have various levels of authorizations (ex= treme example: military style classifications), so that it might even be im= possible to tell who can be contacted.=C2=A0

    That&= #39;s also why I was suggesting assertions could go beyond authentication e= vents, and include cryptographic assertions for authorization purposes. May= be we can even imagine a risk based approach, as in some cases we won't= know for sure.=C2=A0

    The difficulty will be to be= sufficiently generic but simple enough. Maybe we can rule out some cases. = Maybe remote async contacts are out of scope,=C2=A0because we only want ins= tantaneous authorizations. Most of those cases are way beyond what OAuth2 d= oes. I don't know. But what's certain is that the WG should decide = what support for cases where end-user !=3D RO it intends to provide. My dis= cussion was just a very small Chesterston's Fence contribution, even if= that seems to have surprised.

    Fabien


    On Wed, Mar 10, 2021 at 8:18 P= M Justin Richer <jricher@mit.edu> wrote:
    =
    Hi Fabien,

    First, thanks for= doing the heavy lift of writing this topic up. Of these options, I would s= trongly prefer option (1). The difference between assertions and identifier= s is that an assertion is a fully packaged set of attributes, one of which = can be an identifier. They are, generally speaking, cryptographically prote= cted bundles. They=E2=80=99re designed to carry a bunch of different inform= ation about a user and the authentication event in a form that=E2=80=99s in= dependently verifiable and auditable. SAML assertions (XML document) and ID= Tokens (signed JWTs) are the most common ones we see today, but other form= ats exist and will keep being invented.=C2=A0

    An i= dentifier is a different kind of creature. It is a single statement that id= entifies the party in question in the context of the party doing the identi= fication. It=E2=80=99s this full context that the receiver of the identifie= r needs to interpret it in. When using a federated identity protocol, each = RP is going to have :some: kind of local user information store that they= =E2=80=99re going to tie into, some field in a database they=E2=80=99ll key= off of. It=E2=80=99s just never going to be the case that all RPs will be = able to use server-provided opaque identifiers for all cases. Account recov= ery and binding is one such use case where a user-facing identifier like an= email address makes a LOT of sense, for one small example. This is an arra= y in the request and response precisely because a user could be known by se= veral different identifiers to a party, and an RP will have a better idea a= bout what kinds of things it wants to correlate against, and it=E2=80=99s u= p to the AS to provide that mapping. I think that if we don=E2=80=99t defin= e a way to describe the format, the =E2=80=9Cas_id=E2=80=9D field is going = to get structure back-patched onto it like is being proposed here:


    I=E2=80=99m personally not a fan of that approach as it mixes the dat= a layering too much, and you end up making guesses about whether a field is= meaningful or a pointer. I think GNAP will be much better served by using = a data structure for this from the start. DIDs should be another =E2=80=9Cf= ormat=E2=80=9D of the subject identifier. I don=E2=80=99t think GNAP should= define this format, and I=E2=80=99ve dropped a note to the SECEVENT mailin= g list asking about adding DIDs to the subject identifiers draft before it = gets published. DIDs are not assertions, even in the cases where they point= to fully functional DID documents with user information in them. (And for = what it=E2=80=99s worth, I think the OIDC world should also use the SECEVEN= T draft inside ID Tokens to solve the use case of the draft above).

    For the user !=3D RO cases, I think that potentially havi= ng a way to signal those two items separately in the request and response c= ould be useful. Right now all the user/subject stuff is about identifying = =E2=80=9Cthe user that=E2=80=99s currently here at the client instance=E2= =80=9D, in a variety of forms that the client instance and AS can negotiate= . If the client or AS has some other notion about who the RO is and how tha= t could be separate from the current user, we could provide a way to signal= that like you=E2=80=99re proposing below. In my mental model, there are go= ing to be a lot of use cases where the =E2=80=9CRO=E2=80=9D isn=E2=80=99t k= nown to the client at all, but rather to the AS and is based on what the cl= ient=E2=80=99s asking for. So I could identify the current user and ask for= a specific medical record, and the AS realizes it has to go bug a particul= ar doctor to approve things directly. This is instead of interacting with t= he current user and failing in an awkward way when the current user doesn= =E2=80=99t have the rights to do things, but someone else would. But we=E2= =80=99d want the system to be able to detect if the current user is the doc= tor, so we can just interact with them directly. Does that all track?
    =

    =C2=A0=E2=80=94 Justin

    On Mar 10, 2021, at 4:10 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    Hello,

    Notice the question mark in th= e title. Not to be considered as an editor's comment.
    This th= read intends to provide a detailed comment on the interesting=C2=A0feedback= by Kristina: "I would catch up on the thread to understand why DIDs a= re thought to be treated as assertions".
    In the chat, I answ= ered: "Happy to get the discussion on DIDs. Actually, could be either = or, depending on what we intend to do." Let me expand a bit on that, t= o make it understandable (didn't have the time during the meeting, unfo= rtunately).

    This relates to the items described on= slides 20 and 34, which I'll explain further. I'll highlight as tr= ansparently as possible what I think would be the benefits and downsides of= each. Both are probably viable options, but they correspond to different s= copes and objectives. I'll spend a bit more time on option 2, since it = is a different approach compared to the current draft.

    1. The fi= rst possibility is to use SECEVENT throughout.=C2=A0
    In that = case, DIDs should be a part of sub_ids (in the core or in the extension reg= istry, depending on what Annabelle's WG decides). More generally, the W= G would have to decide which additional sub_ids it needs (as per Yaron'= s comment).

    That's obviously the closest to wh= at is described in draft-04. It allows a communication of subject informati= on between the client and the AS, by using global identifiers (mail, phone,= etc.), or using a local opaque reference=C2=A0- i.e. governed by the AS (t= hat's probably what we would=C2=A0put in the examples, unless someone h= as a better idea - cf issues #16 and #42).=C2=A0

    A= ssertions relate for instance to the proof of presence of the RO. The curre= nt draft-04 therefore plans for id_tokens and saml2, maybe there could be o= ther needs later (extension registry).

    - Benefits:= identifiers are a key component of GNAP, which makes integration easier. P= ossibly one could choose to use DIDs throughout.
    - Downsides: ema= il/phone identifiers will probably be used throughout by most devs (since t= hat's correlation information they=C2=A0have in their user DB). Which m= eans we should limit what assertions contain, to avoid doing links between = weak global identifiers and hopefully stronger assertions. That's not r= eally a problem if it's limited to authentication events mostly (in tha= t perspective, samlv2 could make sense in the core). An assertion is probab= ly a single value then (not an array).=C2=A0 =C2=A0

    Option 1 can be summarized as:=C2=A0

    "subject": {
    =C2=A0= =C2=A0=C2=A0"sub_ids": { }, <= /span> // request= and response (SECEVENT -> including DID possibly)=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=C2=A0=C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0"as= sertions": [ ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /= / request and response (id_token or samlv2)
    }
    ("hi= nts" do not exist currently, but are partially covered separately via = "request.user" / the relevance of "principal", discusse= d in the slide, is a question mark too - which is a different discussion on= end-user !=3D RO).


    2. An alt= ernate possibility is to use SECEVENT only as input/hint
    In t= hat case, DIDs should be a part of assertions (which have a different meani= ng compared to option 1).

    The AS only returns an l= ocal opaque reference as_ref (while in option 1, it was only one of many po= ssibilities). Its only job is to help the client differentiate the response= subject. The AS policy might further define the scope of that reference, a= s suggested in=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210, alt= hough I personally=C2=A0viewed that by default as=C2=A0(2) "as_id"= ; an identifier locally unique to that AS for all the RSs.

    SECEVENTS are still useful as an input, that's what I presente= d in request.hints.self.sub_ids (but it's the responsibility=C2=A0of th= e AS to match it with its own reference system - from instance from the ema= il to AS's local record XUT2MFM1XBIKJKSDU8Q).=C2=A0Note: since the slid= es, a new draft-ietf-secevent-subject-identifiers-07 has been published. No= tably this includes an opaque identifier, which the client can use to pass = the as_ref hint to the AS. Thus we wouldn't need any further addition t= o SECEVENT,=C2=A0although hints would benefit from further additions (like = DIDs for instance). Notice also that subject_types_supported becomes less i= mportant, because in the worst case scenario, it's simply=C2=A0a hint t= hat wouldn't be understood and therefore taken into account by the AS.<= /div>

    The assertions array has a more important role tha= n in option 1 (with the explicit aim of separating between client hints and= validated info asserted by the AS). It serves as a generic/extendible mapp= ing structure, e.g. "the AS asserts that opaque reference=C2=A0XUT2MFM1XBIKJKSD= U8Q=C2=A0is matching with these (more or less verifiable) statements= ." The name assertion therefore corresponds to the responsibility=C2= =A0of the AS in delivering those statements (cf should/must, issue #49). So= me of these statements relate to identity or auth events (ex: DID, id_token= ), some might directly be useful for authorization decisions (like ZKP exam= ple in the parental control example). Possibly some of these validated asse= rtions could be reused in next interactions.

    Anoth= er question that popped-up is the scope of sub_ids. Should they be about th= e same user? (I think so). In the case of remote ROs especially, it might b= e important that DID be considered as an assertion=C2=A0(about someone else= 's) and not as sub_ids, because the AS needs to be careful about who th= e client wants to reach (avoid spam, etc.). This is consistent with the res= t of discussion on what to do when end-user !=3D RO, although using DIDComm= might seem a bit early (the paint is very fresh).=C2=A0

    Option 2 was summarized as:=C2=A0

    // (suggestion only, not as= an editor)
    "subject": {
    =C2=A0=C2=A0=C2=A0&= quot;as_ref": { // response only (wouldn=E2=80=99t require SECEVENT)
    =E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex= 1.as.com=E2=80=9D,
    =E2=80=9Cref=E2=80=9D: =E2= =80=9CXU= T2MFM1XBIKJKSDU8QM=E2=80=9D=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=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"asserti= ons": [ ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // req= uest and response (id_token/jwkthumb/DID/VC/etc. -> whatever info can be= validated by the AS)

    =C2=A0=C2=A0=C2= =A0"hints": { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request only (optional)
    =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"self": { // replaces request.user (= support SECEVENT here)
    =C2=A0=C2=A0=C2=A0=E2=80= =9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque in draft-07 - that could cont= ain the ref)
    =C2=A0=C2=A0=C2=A0=E2=80=9Cassertio= ns=E2=80=9D: [ ] // see examples: VC on DOB or ZKP on age (wider= scope, possibly through extensions)
    },=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=C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0&= quot;principal": { // new proposal presente= d at IETF110 (just an idea)
    = = =C2=A0 =E2=80=9Cautomated=E2=80=9D: true, // rule engine
    =C2=A0 =E2=80=9Casync=E2=80=9D: { } // remote ROs
    }=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=C2=A0=C2=A0}
    }

    - Benefits: as_ref is self supporting (no strong coupling with SEC= EVENT), but can still take SECEVENT as an input hint for the AS. It avoids = the risk of making an official association between a weak global identifier= (e.g. email, used elsewhere) and hopefully stronger local assertions. GNAP= would be fully agnostic to whatever identity system is used, only facilita= ting interoperability through assertions (second only in importance=C2=A0co= mpared to the AS opaque reference). Some assertions (possibly extensions) c= ould also be useful for the AS decision (e.g. VC or ZKP).
    - Downs= ides: opaqueness of as_ref is a feature, not a bug. The opaque reference is= fully managed by the AS, therefore not inherently portable (cf portability= discussions in OIDC currently). There's no explicit binding to an offi= cial identity, only a contextual mapping to AS validated assertions. It mak= es it more difficult to match the identifiers from one AS to another or to = correlate with the client user DB (still possible via assertions, if the AS= allows it). Assertions are much more generic (possibly via extensions), bu= t might require a more advanced mechanism=C2=A0to request/response only the= most relevant information (which makes the AS policy critical here).
    =

    I hope that clarifies the=C2=A0reasoning for both optio= ns. Again I'm not saying option 2 is better, just saying the trade-offs= are different (+ knowing that we need to keep it simple).
    - opti= on 1 puts more in sub_ids and less in assertions
    - option 2 puts = less in the reference and more in assertions=C2=A0
    All of this is= open to discussion. More generally speaking, on every part in orange and q= uestion mark (?) I would love your ideas and criticisms. What I intended as= an editor is only to highlight where the WG has important choices to make,= before we can make the related PRs.

    A further sid= e comment: IETF EAT RATS was suggested for assertions, but relates more to = the client attestations. It was added as a comment in=C2=A0https://github.com/ietf-wg-gnap/= gnap-core-protocol/issues/44, which is a distinct topic we'll work = on.

    Fabien (editor's hat off)

    --
    TXAuth mailing list
    TXAuth@ietf.org
    <= a href=3D"https://www.ietf.org/mailman/listinfo/txauth" rel=3D"noreferrer n= oreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer= noreferrer noreferrer" target=3D"_blank">https://www.ietf.org/mailman/list= info/txauth

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/lis= tinfo/txauth

    This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.
    --
    TXAuth mailing list
    T= XAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txaut= h
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listi= nfo/txauth
    --000000000000379fc905bdb4a532-- From nobody Wed Mar 17 07:55:33 2021 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 C2F993A0EEE for ; Wed, 17 Mar 2021 07:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 DZDnR3CmBRwc for ; Wed, 17 Mar 2021 07:55: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 3CDE53A0EEC for ; Wed, 17 Mar 2021 07:55:21 -0700 (PDT) Received: from [192.168.1.22] (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 12HEtEsh002349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 17 Mar 2021 10:55:19 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Justin Richer In-Reply-To: Date: Wed, 17 Mar 2021 10:55:14 -0400 Cc: GNAP Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Adrian Gropper X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] GNAP from a human-centered perspective X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 14:55:28 -0000 I think this is a fairly reasonable way to look at things, but the = sticking point for me is the implication of how the AS =E2=80=9Cbrings = together=E2=80=9D the items. It could be read to mean that the = end-user=E2=80=99s policies all live on the AS. If the end-user needs to = own or control the AS in order for this to work, I don=E2=80=99t think = that pattern has any legs in reality as it requires an RS to accept = access tokens from an unknown source. This means the RS then needs to = understand a LOT more about the access token than it would otherwise be = able to.=20 Instead, I would encourage us to think of =E2=80=9Cbrings together=E2=80=9D= in the sense that the AS can take as input a number of different = things, including things that the user controls and things the RO = controls. This is where I think we can draw the line around the AS in a = way that will let it function in this human-facing world. Because you=E2=80=99re absolutely right that the end user shouldn=E2=80=99= t know or care if what they carry is an =E2=80=9CAS=E2=80=9D in the GNAP = sense or not. =46rom their perspective, they need to present something = to a service to get something done. In the OAuth world this is =E2=80=9Clo= g in to our web server=E2=80=9D. In the GNAP world we can have this = include a wider variety of things they can present to the AS, including = VCs and DIDs and a bunch of other things.=20 =E2=80=94 Justin > On Mar 17, 2021, at 12:30 AM, Adrian Gropper = wrote: >=20 > I truly appreciate the diligence of our editors and contributors. >=20 > Without intruding on the technical discussions, I hope this thread can = be an opportunity for us to step out of our comfort zone and look = around. >=20 > As a human data subject, I am cognizant and in control of only two = kinds of actors, user agents and services. The user agents are almost = exclusively a handful of web browsers, email clients, and apps = duplicated and sometimes synchronizing across two to four phones and = computers. The services (that I expect have visibility into my persona) = are in a dozen categories from banking and ISPs that I expect to be = acting as fiduciaries to platforms, social networks and other data = brokers with their own agenda. At this altitude, GNAP, DIDs, and ASs are = as invisible as MAC addresses and routers. >=20 > Our success, from a human-centered perspective, will come indirectly = as a result of the GNAP Authorization Server. The user agents and = service providers I see (and sometimes choose) will support GNAP along = with OAuth and FIDO and Apple Sign-In as protocols. The common thing = about these protocols is that they coexist and overlap in = incomprehensible ways made even more obscure by DIDs, VCs, and = self-issued identity providers (SIOP). As we get to DIDcomm, even I get = lost. >=20 > My suggestion or proposal to our group is that we respect the human = perspective by doing our best to make the concept of an authorization = server relevant even if it remains hidden from view behind protocols = like GNAP and OAuth and data models like DID and VC. In doing this we = would recognize that a human's agent would likely support GNAP AS as = well as incumbent attribute management protocols. As a human, I just = want my online agent to work across as many user-agents and services as = possible. As with life partners or spouses, having more than one = intelligent semi-autonomous agent is not typically a benefit. >=20 > My concrete suggestion is that GNAP define the AS as the entity or = actor that brings together the subject's policies, the capabilities = granted by services, and requests and serves up authorizations to the = requesting party. >=20 > Adrian >=20 > =20 >=20 > =20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth From nobody Wed Mar 17 09:21:47 2021 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 DD00F3A0651 for ; Wed, 17 Mar 2021 09:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 t5d4p-NoB77m for ; Wed, 17 Mar 2021 09:21:42 -0700 (PDT) Received: from mail-vk1-f172.google.com (mail-vk1-f172.google.com [209.85.221.172]) (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 EB9B73A0645 for ; Wed, 17 Mar 2021 09:21:41 -0700 (PDT) Received: by mail-vk1-f172.google.com with SMTP id o4so595046vka.12 for ; Wed, 17 Mar 2021 09:21:41 -0700 (PDT) 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=FGh9KkzZyIs629U3wtT41zYL1EEvjpWLnObv+scVNBM=; b=oSxZMQ9narFjOj0RpWkQcY8lx9KiVwKKvqcWMWB8r+I7NjzMuGbHEF+Iz+aHFObEp2 VM4zlz2Tr6Dbgyijcz/qCYKYP49lpvsisryPGHj6ah0pHHobjCWhxqrhMqeqNMNye1Gy /swdjlNxj00+Letm+3GLzEpD5A/Kd17ezD8K+wTSgwO31R7otm1ptTFLnfHFqbSPnW81 xgaPSlCj+RzUTfDFbioal6E9DkoB5rPZRKe6iusaxYlRJ/gr0YRqPTfSiaAskSyQEofo sQWE+li4mFj4BoZsobTwTzY8Icwgo/I5hMh1Wbxj2poSvbIUBA0L9WDWez5n1I15LbX0 ZJwA== X-Gm-Message-State: AOAM531d+yhhSKXCdkpQBYFfCdvA/bBCS0Xz7PaerYFRgT9wvGvqV1SK Gv8YgB+GoI5vYMeEFs8BQ6kK1cSnVtoDtF1YfUk= X-Google-Smtp-Source: ABdhPJxzwpozAu16umtVe97itSSvRYGnjyyPoE+r21JExl/B5h8Q18Nd+zu4OH7fCcbt+ejyuVHvfJTiQTP7V2obddQ= X-Received: by 2002:a1f:fcc5:: with SMTP id a188mr3785413vki.4.1615998100655; Wed, 17 Mar 2021 09:21:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Adrian Gropper Date: Wed, 17 Mar 2021 12:21:28 -0400 Message-ID: To: Justin Richer Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000bf513305bdbde0ac" Archived-At: Subject: Re: [GNAP] GNAP from a human-centered perspective X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 16:21:46 -0000 --000000000000bf513305bdbde0ac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think Justin and I are starting from the same assumption that "the RS holds all the cards" but then reaching different conclusions about the GNAP AS. The RS can decide what scopes to honor, can ignore tokens, can choose their jurisdiction and policies, and can often deny service to subjects on a whim. Giving the RS any additional power or coerced trust (e.g. shrink-wrap licenses) over the subject should be avoided by design. One thing the RS controls is the ability to issue a capability to the subject at some point prior to there being any GNAP AS involved. The subject can keep this capability in their client (e.g. a wallet) or can send that capability to a GNAP AS that they choose. Instead of issuing a capability, the RS can also choose to accept a user-controlled AS. They can do that, for example, by storing a (DID) service endpoint to a GNAP AS. The RS could force the subject (as controller) to choose from a list of certified ASs or they could ask the AS to present a certificate from a trusted issuer. This last RS-controlled option is seen in US HIPAA law but it has provisions for the data subject to insist on acceptance of a subject-issued certificate as part of the protocol. The UDAP group is active in profiling the format of these certificates to be used on top of OAuth. Finally, GNAP should not presume that the AS is either carried by a subject or online. A subject can have the option to choose an unreliable or part-time AS. Adrian On Wed, Mar 17, 2021 at 10:55 AM Justin Richer wrote: > I think this is a fairly reasonable way to look at things, but the > sticking point for me is the implication of how the AS =E2=80=9Cbrings to= gether=E2=80=9D > the items. It could be read to mean that the end-user=E2=80=99s policies = all live > on the AS. If the end-user needs to own or control the AS in order for th= is > to work, I don=E2=80=99t think that pattern has any legs in reality as it= requires > an RS to accept access tokens from an unknown source. This means the RS > then needs to understand a LOT more about the access token than it would > otherwise be able to. > > Instead, I would encourage us to think of =E2=80=9Cbrings together=E2=80= =9D in the sense > that the AS can take as input a number of different things, including > things that the user controls and things the RO controls. This is where I > think we can draw the line around the AS in a way that will let it functi= on > in this human-facing world. > > Because you=E2=80=99re absolutely right that the end user shouldn=E2=80= =99t know or care > if what they carry is an =E2=80=9CAS=E2=80=9D in the GNAP sense or not. F= rom their > perspective, they need to present something to a service to get something > done. In the OAuth world this is =E2=80=9Clog in to our web server=E2=80= =9D. In the GNAP > world we can have this include a wider variety of things they can present > to the AS, including VCs and DIDs and a bunch of other things. > > =E2=80=94 Justin > > > On Mar 17, 2021, at 12:30 AM, Adrian Gropper > wrote: > > > > I truly appreciate the diligence of our editors and contributors. > > > > Without intruding on the technical discussions, I hope this thread can > be an opportunity for us to step out of our comfort zone and look around. > > > > As a human data subject, I am cognizant and in control of only two kind= s > of actors, user agents and services. The user agents are almost exclusive= ly > a handful of web browsers, email clients, and apps duplicated and sometim= es > synchronizing across two to four phones and computers. The services (that= I > expect have visibility into my persona) are in a dozen categories from > banking and ISPs that I expect to be acting as fiduciaries to platforms, > social networks and other data brokers with their own agenda. At this > altitude, GNAP, DIDs, and ASs are as invisible as MAC addresses and route= rs. > > > > Our success, from a human-centered perspective, will come indirectly as > a result of the GNAP Authorization Server. The user agents and service > providers I see (and sometimes choose) will support GNAP along with OAuth > and FIDO and Apple Sign-In as protocols. The common thing about these > protocols is that they coexist and overlap in incomprehensible ways made > even more obscure by DIDs, VCs, and self-issued identity providers (SIOP)= . > As we get to DIDcomm, even I get lost. > > > > My suggestion or proposal to our group is that we respect the human > perspective by doing our best to make the concept of an authorization > server relevant even if it remains hidden from view behind protocols like > GNAP and OAuth and data models like DID and VC. In doing this we would > recognize that a human's agent would likely support GNAP AS as well as > incumbent attribute management protocols. As a human, I just want my onli= ne > agent to work across as many user-agents and services as possible. As wit= h > life partners or spouses, having more than one intelligent semi-autonomou= s > agent is not typically a benefit. > > > > My concrete suggestion is that GNAP define the AS as the entity or acto= r > that brings together the subject's policies, the capabilities granted by > services, and requests and serves up authorizations to the requesting par= ty. > > > > Adrian > > > > > > > > > > -- > > TXAuth mailing list > > TXAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth > > --000000000000bf513305bdbde0ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I think Justin and I are starting from the same assumption= that "the RS holds all the cards" but then reaching different co= nclusions about the GNAP AS.=C2=A0

    The RS can decide wha= t scopes to honor, can ignore tokens, can choose their jurisdiction and pol= icies, and can often deny service to subjects on a whim. Giving the RS any = additional power or coerced trust (e.g. shrink-wrap licenses) over the subj= ect should be avoided by design.

    One thing the RS = controls is the ability=C2=A0to issue a capability to the subject at some p= oint prior to there being any GNAP AS involved. The subject can keep this c= apability in their client (e.g. a wallet) or can send that capability to a = GNAP AS that they choose.=C2=A0

    Instead of issuing= a capability, the RS can also choose to accept a user-controlled AS. They = can do that, for=C2=A0example, by storing a (DID) service endpoint to a GNA= P AS. The RS could force the subject (as controller) to choose from a list = of certified ASs or they could ask the AS to present a certificate from a t= rusted issuer. This last RS-controlled option is seen in US HIPAA law but i= t has provisions for the data subject to insist on acceptance of a subject-= issued certificate as part of the protocol. The UDAP group is active in pro= filing the format of these certificates to be used on top of OAuth.

    Finally, GNAP should not presume that the AS is either ca= rried by a subject or online. A subject can have the option to choose an un= reliable or part-time AS.

    Adrian=C2=A0
    <= br>






    On Wed, Mar 17, 2021 at 10:55 AM Justin Richer <jricher@mit.edu> wrote:
    I think this is a fairly reasonable way to look at things, but the sticki= ng point for me is the implication of how the AS =E2=80=9Cbrings together= =E2=80=9D the items. It could be read to mean that the end-user=E2=80=99s p= olicies all live on the AS. If the end-user needs to own or control the AS = in order for this to work, I don=E2=80=99t think that pattern has any legs = in reality as it requires an RS to accept access tokens from an unknown sou= rce. This means the RS then needs to understand a LOT more about the access= token than it would otherwise be able to.

    Instead, I would encourage us to think of =E2=80=9Cbrings together=E2=80=9D= in the sense that the AS can take as input a number of different things, i= ncluding things that the user controls and things the RO controls. This is = where I think we can draw the line around the AS in a way that will let it = function in this human-facing world.

    Because you=E2=80=99re absolutely right that the end user shouldn=E2=80=99t= know or care if what they carry is an =E2=80=9CAS=E2=80=9D in the GNAP sen= se or not. From their perspective, they need to present something to a serv= ice to get something done. In the OAuth world this is =E2=80=9Clog in to ou= r web server=E2=80=9D. In the GNAP world we can have this include a wider v= ariety of things they can present to the AS, including VCs and DIDs and a b= unch of other things.

    =C2=A0=E2=80=94 Justin

    > On Mar 17, 2021, at 12:30 AM, Adrian Gropper <agropper@healthurl.com> wrote= :
    >
    > I truly appreciate the diligence of our editors and contributors.
    >
    > Without intruding on the technical discussions, I hope this thread can= be an opportunity for us to step out of our comfort zone and look around.<= br> >
    > As a human data subject, I am cognizant and in control of only two kin= ds of actors, user agents and services. The user agents are almost exclusiv= ely a handful of web browsers, email clients, and apps duplicated and somet= imes synchronizing across two to four phones and computers. The services (t= hat I expect have visibility into my persona) are in a dozen categories fro= m banking and ISPs that I expect to be acting as fiduciaries to platforms, = social networks and other data brokers with their own agenda. At this altit= ude, GNAP, DIDs, and ASs are as invisible as MAC addresses and routers.
    >
    > Our success, from a human-centered perspective, will come indirectly a= s a result of the GNAP Authorization Server. The user agents and service pr= oviders I see (and sometimes choose) will support GNAP along with OAuth and= FIDO and Apple Sign-In as protocols. The common thing about these protocol= s is that they coexist and overlap in incomprehensible ways made even more = obscure by DIDs, VCs, and self-issued identity providers (SIOP). As we get = to DIDcomm, even I get lost.
    >
    > My suggestion or proposal to our group is that we respect the human pe= rspective by doing our best to make the concept of an authorization server = relevant even if it remains hidden from view behind protocols like GNAP and= OAuth and data models like DID and VC. In doing this we would recognize th= at a human's agent would likely support GNAP AS as well as incumbent at= tribute management protocols. As a human, I just want my online agent to wo= rk across as many user-agents and services as possible. As with life partne= rs or spouses, having more than one intelligent semi-autonomous agent is no= t typically a benefit.
    >
    > My concrete suggestion is that GNAP define the AS as the entity or act= or that brings together the subject's policies, the capabilities grante= d by services, and requests and serves up authorizations to the requesting = party.
    >
    > Adrian
    >
    >=C2=A0 =C2=A0
    >
    >=C2=A0
    > --
    > TXAuth mailing list
    > TXAuth@ietf.org
    >     https://www.ietf.org/mailman/listinfo/txauth
    --000000000000bf513305bdbde0ac-- From nobody Wed Mar 17 10:03:59 2021 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 A2A5B3A0B3F for ; Wed, 17 Mar 2021 10:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 1Y-iTxSEEC6B for ; Wed, 17 Mar 2021 10:03:54 -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 A66AE3A0B3A for ; Wed, 17 Mar 2021 10:03:54 -0700 (PDT) Received: from [192.168.1.22] (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 12HH3mh0030711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 17 Mar 2021 13:03:50 -0400 From: Justin Richer Message-Id: <614551CF-E544-4376-9576-E2956454D67D@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_D2514236-E698-4495-ABD5-F9D82CEC7E0B" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 17 Mar 2021 13:03:48 -0400 In-Reply-To: Cc: GNAP Mailing List To: Adrian Gropper References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] GNAP from a human-centered perspective X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 17:03:58 -0000 --Apple-Mail=_D2514236-E698-4495-ABD5-F9D82CEC7E0B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 17, 2021, at 12:21 PM, Adrian Gropper = wrote: >=20 > I think Justin and I are starting from the same assumption that "the = RS holds all the cards" but then reaching different conclusions about = the GNAP AS.=20 >=20 > The RS can decide what scopes to honor, can ignore tokens, can choose = their jurisdiction and policies, and can often deny service to subjects = on a whim. Giving the RS any additional power or coerced trust (e.g. = shrink-wrap licenses) over the subject should be avoided by design. >=20 > One thing the RS controls is the ability to issue a capability to the = subject at some point prior to there being any GNAP AS involved. The = subject can keep this capability in their client (e.g. a wallet) or can = send that capability to a GNAP AS that they choose.=20 I don=E2=80=99t believe this is in scope for GNAP. The abstraction layer = offered by the protocol is such that the only communication between the = client instance and RS is via an access token issued by an AS. This AS = is reachable by the client and trusted by the RS.=20 Fundamentally, what you are describing is function of the AS, at least = as far as the GNAP protocol itself is concerned. Remember, this isn=E2=80=99= t about deployment, it=E2=80=99s about the roles and responsibilities of = the different items involved. >=20 > Instead of issuing a capability, the RS can also choose to accept a = user-controlled AS. They can do that, for example, by storing a (DID) = service endpoint to a GNAP AS. The RS could force the subject (as = controller) to choose from a list of certified ASs or they could ask the = AS to present a certificate from a trusted issuer. This last = RS-controlled option is seen in US HIPAA law but it has provisions for = the data subject to insist on acceptance of a subject-issued certificate = as part of the protocol. The UDAP group is active in profiling the = format of these certificates to be used on top of OAuth. I think that all of these things are functions of the AS, not the RS. = With many AS deployments in OAuth today, the user can present themselves = to the AS using a choice of federated logins. So in GNAP the user=E2=80=99= s agent can present a certificate from a trusted issuer. This is not = something an AS presents to an RS, it=E2=80=99s something that a = different component presents to the AS. The result of this is an access token that the RS will accept. The AS = and RS are in the same trust boundary, the crossing of that boundary = happens inbound to the AS. This is fundamentally the change in language = that I have been trying to push here. While the RS could accept an = arbitrary AS, I think it=E2=80=99s both more useful and more realistic = for the AS to accept a variety of proofs, claims, certifications, etc = from the RO and/or user at runtime in order to make its token. >=20 > Finally, GNAP should not presume that the AS is either carried by a = subject or online. A subject can have the option to choose an unreliable = or part-time AS. >=20 I disagree with this statement. GNAP is a protocol and is based on HTTP. = =46rom a technical level, we have to assume that it is reachable by the = client instance at the start of the process. But if we stop trying to = put the AS into a place where it doesn=E2=80=99t function well, we can = start to talk about the unreliable and part-time = authorization-and-consent component (agent, wallet, whatever) that can = feed into the AS when available. This leads to a much more robust = protocol structure. =E2=80=94 Justin > Adrian=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Wed, Mar 17, 2021 at 10:55 AM Justin Richer > wrote: > I think this is a fairly reasonable way to look at things, but the = sticking point for me is the implication of how the AS =E2=80=9Cbrings = together=E2=80=9D the items. It could be read to mean that the = end-user=E2=80=99s policies all live on the AS. If the end-user needs to = own or control the AS in order for this to work, I don=E2=80=99t think = that pattern has any legs in reality as it requires an RS to accept = access tokens from an unknown source. This means the RS then needs to = understand a LOT more about the access token than it would otherwise be = able to.=20 >=20 > Instead, I would encourage us to think of =E2=80=9Cbrings together=E2=80= =9D in the sense that the AS can take as input a number of different = things, including things that the user controls and things the RO = controls. This is where I think we can draw the line around the AS in a = way that will let it function in this human-facing world. >=20 > Because you=E2=80=99re absolutely right that the end user shouldn=E2=80=99= t know or care if what they carry is an =E2=80=9CAS=E2=80=9D in the GNAP = sense or not. =46rom their perspective, they need to present something = to a service to get something done. In the OAuth world this is =E2=80=9Clo= g in to our web server=E2=80=9D. In the GNAP world we can have this = include a wider variety of things they can present to the AS, including = VCs and DIDs and a bunch of other things.=20 >=20 > =E2=80=94 Justin >=20 > > On Mar 17, 2021, at 12:30 AM, Adrian Gropper > wrote: > >=20 > > I truly appreciate the diligence of our editors and contributors. > >=20 > > Without intruding on the technical discussions, I hope this thread = can be an opportunity for us to step out of our comfort zone and look = around. > >=20 > > As a human data subject, I am cognizant and in control of only two = kinds of actors, user agents and services. The user agents are almost = exclusively a handful of web browsers, email clients, and apps = duplicated and sometimes synchronizing across two to four phones and = computers. The services (that I expect have visibility into my persona) = are in a dozen categories from banking and ISPs that I expect to be = acting as fiduciaries to platforms, social networks and other data = brokers with their own agenda. At this altitude, GNAP, DIDs, and ASs are = as invisible as MAC addresses and routers. > >=20 > > Our success, from a human-centered perspective, will come indirectly = as a result of the GNAP Authorization Server. The user agents and = service providers I see (and sometimes choose) will support GNAP along = with OAuth and FIDO and Apple Sign-In as protocols. The common thing = about these protocols is that they coexist and overlap in = incomprehensible ways made even more obscure by DIDs, VCs, and = self-issued identity providers (SIOP). As we get to DIDcomm, even I get = lost. > >=20 > > My suggestion or proposal to our group is that we respect the human = perspective by doing our best to make the concept of an authorization = server relevant even if it remains hidden from view behind protocols = like GNAP and OAuth and data models like DID and VC. In doing this we = would recognize that a human's agent would likely support GNAP AS as = well as incumbent attribute management protocols. As a human, I just = want my online agent to work across as many user-agents and services as = possible. As with life partners or spouses, having more than one = intelligent semi-autonomous agent is not typically a benefit. > >=20 > > My concrete suggestion is that GNAP define the AS as the entity or = actor that brings together the subject's policies, the capabilities = granted by services, and requests and serves up authorizations to the = requesting party. > >=20 > > Adrian > >=20 > > =20 > >=20 > > =20 > > --=20 > > TXAuth mailing list > > TXAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth = >=20 --Apple-Mail=_D2514236-E698-4495-ABD5-F9D82CEC7E0B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

    On Mar 17, 2021, at 12:21 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I think Justin and I are starting = from the same assumption that "the RS holds all the cards" but then = reaching different conclusions about the GNAP AS. 
    The RS can decide what scopes to = honor, can ignore tokens, can choose their jurisdiction and policies, = and can often deny service to subjects on a whim. Giving the RS any = additional power or coerced trust (e.g. shrink-wrap licenses) over the = subject should be avoided by design.

    One thing the RS controls is the = ability to issue a capability to the subject at some point prior to = there being any GNAP AS involved. The subject can keep this capability = in their client (e.g. a wallet) or can send that capability to a GNAP AS = that they choose. 

    I don=E2=80=99t believe this is in scope for GNAP. = The abstraction layer offered by the protocol is such that the only = communication between the client instance and RS is via an access token = issued by an AS. This AS is reachable by the client and trusted by the = RS. 

    Fundamentally, what you = are describing is function of the AS, at least as far as the GNAP = protocol itself is concerned. Remember, this isn=E2=80=99t about = deployment, it=E2=80=99s about the roles and responsibilities of the = different items involved.

    Instead of issuing a capability, the = RS can also choose to accept a user-controlled AS. They can do that, = for example, by storing a (DID) service endpoint to a GNAP AS. The = RS could force the subject (as controller) to choose from a list of = certified ASs or they could ask the AS to present a certificate from a = trusted issuer. This last RS-controlled option is seen in US HIPAA law = but it has provisions for the data subject to insist on acceptance of a = subject-issued certificate as part of the protocol. The UDAP group is = active in profiling the format of these certificates to be used on top = of OAuth.

    I = think that all of these things are functions of the AS, not the RS. With = many AS deployments in OAuth today, the user can present themselves to = the AS using a choice of federated logins. So in GNAP the user=E2=80=99s = agent can present a certificate from a trusted issuer. This is not = something an AS presents to an RS, it=E2=80=99s something that a = different component presents to the AS.

    The result of this is an access token that the RS = will accept. The AS and RS are in the same trust boundary, the crossing = of that boundary happens inbound to the AS. This is fundamentally the = change in language that I have been trying to push here. While the RS = could accept an arbitrary AS, I think it=E2=80=99s both more useful and = more realistic for the AS to accept a variety of proofs, claims, = certifications, etc from the RO and/or user at runtime in order to make = its token.


    Finally, GNAP should not presume that = the AS is either carried by a subject or online. A subject can have the = option to choose an unreliable or part-time AS.


    I= disagree with this statement. GNAP is a protocol and is based on HTTP. = =46rom a technical level, we have to assume that it is reachable by the = client instance at the start of the process. But if we stop trying to = put the AS into a place where it doesn=E2=80=99t function well, we can = start to talk about the unreliable and part-time = authorization-and-consent component (agent, wallet, whatever) that can = feed into the AS when available. This leads to a much more robust = protocol structure.

     =E2=80=94 = Justin

    Adrian 







    On Wed, Mar = 17, 2021 at 10:55 AM Justin Richer <jricher@mit.edu> wrote:
    I think this is a fairly reasonable way = to look at things, but the sticking point for me is the implication of = how the AS =E2=80=9Cbrings together=E2=80=9D the items. It could be read = to mean that the end-user=E2=80=99s policies all live on the AS. If the = end-user needs to own or control the AS in order for this to work, I = don=E2=80=99t think that pattern has any legs in reality as it requires = an RS to accept access tokens from an unknown source. This means the RS = then needs to understand a LOT more about the access token than it would = otherwise be able to.

    Instead, I would encourage us to think of =E2=80=9Cbrings together=E2=80=9D= in the sense that the AS can take as input a number of different = things, including things that the user controls and things the RO = controls. This is where I think we can draw the line around the AS in a = way that will let it function in this human-facing world.

    Because you=E2=80=99re absolutely right that the end user shouldn=E2=80=99= t know or care if what they carry is an =E2=80=9CAS=E2=80=9D in the GNAP = sense or not. =46rom their perspective, they need to present something = to a service to get something done. In the OAuth world this is =E2=80=9Clo= g in to our web server=E2=80=9D. In the GNAP world we can have this = include a wider variety of things they can present to the AS, including = VCs and DIDs and a bunch of other things.

     =E2=80=94 Justin

    > On Mar 17, 2021, at 12:30 AM, Adrian Gropper <agropper@healthurl.com> wrote:
    >
    > I truly appreciate the diligence of our editors and = contributors.
    >
    > Without intruding on the technical discussions, I hope this thread = can be an opportunity for us to step out of our comfort zone and look = around.
    >
    > As a human data subject, I am cognizant and in control of only two = kinds of actors, user agents and services. The user agents are almost = exclusively a handful of web browsers, email clients, and apps = duplicated and sometimes synchronizing across two to four phones and = computers. The services (that I expect have visibility into my persona) = are in a dozen categories from banking and ISPs that I expect to be = acting as fiduciaries to platforms, social networks and other data = brokers with their own agenda. At this altitude, GNAP, DIDs, and ASs are = as invisible as MAC addresses and routers.
    >
    > Our success, from a human-centered perspective, will come = indirectly as a result of the GNAP Authorization Server. The user agents = and service providers I see (and sometimes choose) will support GNAP = along with OAuth and FIDO and Apple Sign-In as protocols. The common = thing about these protocols is that they coexist and overlap in = incomprehensible ways made even more obscure by DIDs, VCs, and = self-issued identity providers (SIOP). As we get to DIDcomm, even I get = lost.
    >
    > My suggestion or proposal to our group is that we respect the human = perspective by doing our best to make the concept of an authorization = server relevant even if it remains hidden from view behind protocols = like GNAP and OAuth and data models like DID and VC. In doing this we = would recognize that a human's agent would likely support GNAP AS as = well as incumbent attribute management protocols. As a human, I just = want my online agent to work across as many user-agents and services as = possible. As with life partners or spouses, having more than one = intelligent semi-autonomous agent is not typically a benefit.
    >
    > My concrete suggestion is that GNAP define the AS as the entity or = actor that brings together the subject's policies, the capabilities = granted by services, and requests and serves up authorizations to the = requesting party.
    >
    > Adrian
    >
    >   
    >
    > 
    > --
    > TXAuth mailing list
    > TXAuth@ietf.org
    > https://www.ietf.org/mailman/listinfo/txauth
    =

    = --Apple-Mail=_D2514236-E698-4495-ABD5-F9D82CEC7E0B-- From nobody Wed Mar 17 10:51:27 2021 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 9F4B33A0E03 for ; Wed, 17 Mar 2021 10:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 L9t3f0b1Fucp for ; Wed, 17 Mar 2021 10:51:23 -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 AC70E3A0E02 for ; Wed, 17 Mar 2021 10:51:21 -0700 (PDT) Received: from [192.168.1.22] (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 12HHpJsP016357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 17 Mar 2021 13:51:20 -0400 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_0C547AB4-DDEA-4609-A22B-84CA88C5699C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <22D6F32C-621C-4B9E-8AE9-69F7D7810080@mit.edu> Date: Wed, 17 Mar 2021 13:51:19 -0400 To: GNAP Mailing List X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [GNAP] Editors Update X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 17:51:26 -0000 --Apple-Mail=_0C547AB4-DDEA-4609-A22B-84CA88C5699C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This week, the editors have marked the following pull requests as = Pending Merge: #207: Mnr editorial changes for jws and jwsd https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/207 = #208: Minor changes on the language in section "Presenting Access = Tokens=E2=80=9D https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/208 = #209: These are examples of not sender-constrained tokens. Hence, the = "bound" v=E2=80=A6 https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/209 = #211: updated diagrams, included subject-only flow https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/211 = The discussion on several of these has brought to light some other gaps, = which have been filed as issues and are being tracked and worked on by = the editors. In addition, the following issues and pull requests have been marked = Pending Close, with reasons cited in the issue tracker: #145: Opaque / Non opaque access token https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145 = #206: HTTP status codes and responses https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/206 = Unless there is consensus to do otherwise, these items will be acted = upon as described next Wednesday, March 25.=20 =E2=80=94 Justin, Aaron, and Fabien --Apple-Mail=_0C547AB4-DDEA-4609-A22B-84CA88C5699C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This = week, the editors have marked the following pull requests as Pending = Merge:

    #207: Mnr = editorial changes for jws and jwsd
    https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/207=

    #208: Minor changes on the language in section = "Presenting Access Tokens=E2=80=9D
    https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/208=

    #209: These are examples of not sender-constrained = tokens. Hence, the "bound" v=E2=80=A6
    https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/209=

    #211: updated diagrams, included subject-only = flow
    https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/211=


    The discussion on several of these has = brought to light some other gaps, which have been filed as issues and = are being tracked and worked on by the editors.


    In = addition, the following issues and pull requests have been marked = Pending Close, with reasons cited in the issue tracker:

    #145: Opaque / Non = opaque access token
    https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145

    #206: HTTP status codes and responses
    https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/206=

    Unless there = is consensus to do otherwise, these items will be acted upon as = described next Wednesday, March 25. 

     =E2=80=94 Justin, Aaron, and = Fabien

    = --Apple-Mail=_0C547AB4-DDEA-4609-A22B-84CA88C5699C-- From nobody Wed Mar 17 13:24:05 2021 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 003113A1347 for ; Wed, 17 Mar 2021 13:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 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, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mattr-global.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 fL75WZK49s7w for ; Wed, 17 Mar 2021 13:23:57 -0700 (PDT) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (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 9423A3A1343 for ; Wed, 17 Mar 2021 13:23:57 -0700 (PDT) Received: by mail-qv1-xf34.google.com with SMTP id d10so2053251qve.7 for ; Wed, 17 Mar 2021 13:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattr-global.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=thLIbaonKGyJPJQzclFzVzWYeYtC+LbtMH5jW/TwzNU=; b=UISkYNjO/xmin1FmtMmdi5E59P508qQkppaBA9DqBWfMG0Tl1WGg+j7o+xCK6lzPtw DlU22OtdytOipON88Wy1lBZV9O0l3O1VvY/o8S+lv0nzDCtxJTa9emeVu/Zhh66oQsAm 4cADRPoY19mVfUH86XhcLQBpJTvcwVZ6ztJ/yTumCOkWsVlyz37DlKkr11ZLGmiTDRL0 EbiEdrXp4zZfY7zz2st1t+ysSX2zNKmW/dHHLf30ljzQnGOoX0aolgN356yAYyHlzIdc fvoz4Gv4IttgvO/8vsuKL+ffkZKaV7DAT7R5mC9M3V9Y/POk9ydvPNFB+EQE93SdFHFi 8Edg== 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=thLIbaonKGyJPJQzclFzVzWYeYtC+LbtMH5jW/TwzNU=; b=MLashjTEZWSxweE+b2Y60ILFI7ecay+K9nyaD3M5zhLgK2Jr08L/e3A9TUCtBKDmek Tr5J4gnA4xtqEuDorJlwqs9LrXc82bapUDP3qBx0CJgmasDu1pJa8XKd0P2QA7R2I77Y ekWI++Ye0Bnl8AZBEHJ0Z0OFS9+U1COUwZU+czSr3Z70AgNNUQynLE3hipWZzUjILQrm Bk274K7EPuJyJepj9WFfXxBooTrWkIUCCfn5yni/CwpqZUPuoRYZTODQp85idtxG9Llk M5HBNDfdzZihoCgrFqQqj7iXUCPjtAhcAtIunODRDONGjX6OaKUV2BPEkyVKuoTUMQG2 8E1w== X-Gm-Message-State: AOAM530YHJTgRnmm977npyOXZ0Rbx5/AWE76F+sK9uQVtnDI1of9XfET aKoz5yWpjYH7KNV7DqLlq5+LQF9qjhFf660medylE/sEwmLqwJqiahh4RfOJY2Hb/Zdk6+UAwF2 Lv8QaisuTzFSd9jy/gQ== X-Google-Smtp-Source: ABdhPJxYtmE7o4WlYvEikL8py5xJLpia8BcwXsVWOvRMPVsXpR5gwuiOJ/dsWe4mOJuOvB12CPzhCdNS4hn8V+uB29g= X-Received: by 2002:ad4:4b6c:: with SMTP id m12mr926426qvx.21.1616012636336; Wed, 17 Mar 2021 13:23:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tobias Looker Date: Thu, 18 Mar 2021 09:23:45 +1300 Message-ID: To: Fabien Imbault Cc: Adrian Gropper , GNAP Mailing List , Justin Richer Content-Type: multipart/alternative; boundary="00000000000024611805bdc143db" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 20:24:04 -0000 --00000000000024611805bdc143db Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Currently I mostly see DID as alternative subject identifier (again hypothetically since not currently included in SECEVENT). +1 I think DIDs are an interesting option to allow the subject identifier to belong to a domain that is not controlled by the AS unlocking the possibility of the End-User being able to have their identity portable between AS's (hence the name portable identities being used of recent). > A client might not have a DID but it could have a VC as a certificate of authenticity linked to some audit mechanism. To me a VC would come under the assertions umbrella (that is to say a VC could be one type of valid assertion). The client may possess or been presented with a VC that it could include in its request to the AS as a way to identify the subject and perhaps prove authentication and authorization. Thanks, [image: Mattr website] *Tobias Looker* Mattr +64 (0) 27 378 0461 tobias.looker@mattr.global [image: Mattr website] [image: Mattr on LinkedIn] [image: Mattr on Twitter] [image: Mattr on Github] This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002. On Wed, Mar 17, 2021 at 6:20 PM Fabien Imbault wrote: > Currently I mostly see DID as alternative subject identifier (again > hypothetically since not currently included in SECEVENT). > > You're right that DIDs could serve other purposes too. Denis has also > asked an interesting question on whether sub_ids might be used within the > access tokens (issue #210). > > I do see some value in supporting VCs for assertions. In my early attempt= s > to map that, it seems to be applicable to the client instance (like the > client posture, or even a VP for the display) or to the end-user > (request.user). > > We need to keep in mind that a big part of that discussion also depends o= n > what the SECEVENT WG decides. > > Fabien > > Le mer. 17 mars 2021 =C3=A0 05:48, Adrian Gropper a > =C3=A9crit : > >> What do you mean the scope is restricted to the subject? DIDs are >> valuable for all end-users and things like did:web can help interop with >> RSs. A client might not have a DID but it could have a VC as a certifica= te >> of authenticity linked to some audit mechanism. >> >> Adrian >> >> On Tue, Mar 16, 2021 at 11:42 PM Fabien Imbault >> wrote: >> >>> Noted. I agree with that goal. >>> >>> Back to identifiers, even if we'd use DIDs, the scope is restricted to >>> the subject. >>> >>> Fabien >>> >>> >>> Le mer. 17 mars 2021 =C3=A0 04:04, Adrian Gropper a >>> =C3=A9crit : >>> >>>> Thanks, Fabien. >>>> >>>> We need to be verrry careful about the shortcuts once we add user and >>>> end-user to our spec. RO =3D subject (of the resource secured by a RS)= is >>>> clear and independent of any AS or clients. DIDs can be helpful for th= e >>>> RO-RS relationship for authentication, encryption, and service endpoin= ts. >>>> Authentication can facilitate pseudonymity by default. Encryption, for >>>> example, can allow mediated communications for privacy enhancement. >>>> >>>> When we bring the request of an end-user into the picture, the DID can >>>> apply to someone other than the RO / subject. The DID can secure claim= s >>>> that had nothing to do with the RO-RS (as you point out in #197). Also= , in >>>> many cases, the subject DID known to the requesting party might be >>>> different from the DID associated with the RO at the RS. This promotes >>>> privacy through DIDs as same-domain identifiers but has to be dealt wi= th at >>>> the policy decision point where capabilities are filtered. >>>> >>>> Another source of potential confusion comes from the way we use client= . >>>> DIDs are generally not associated with a client except to the extent t= he >>>> client is a user-agent such as a mobile wallet or an online policy and >>>> capabilities agent. >>>> >>>> My suggestion is that we arrive at a set of consistent names soon and >>>> present them early in the spec - in what is now Section 1.2 - and avoi= d >>>> using any shortcuts in the rest of the spec. I would also suggest we >>>> provide examples of the use of DIDs relative to the names we define in= 1.2. >>>> >>>> Adrian >>>> >>>> On Tue, Mar 16, 2021 at 10:51 PM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Note also that there's issue 197 that discussed that very question. >>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/197 >>>>> >>>>> Le mer. 17 mars 2021 =C3=A0 03:34, Fabien Imbault >>>>> a =C3=A9crit : >>>>> >>>>>> Hi Adrian, >>>>>> >>>>>> As the name suggests, it's an identifier for the subject (and so, >>>>>> hypothetically, a DID to identify the subject). The text indeed conc= erns >>>>>> the subject as the RO, as it is known to the AS. >>>>>> >>>>>> But it's easy to make shortcuts, because often we end-up dealing wit= h >>>>>> is user =3D end-user =3D RO =3D subject. >>>>>> >>>>>> Fabien >>>>>> >>>>>> Le mer. 17 mars 2021 =C3=A0 03:10, Adrian Gropper >>>>>> a =C3=A9crit : >>>>>> >>>>>>> I'm late to this conversation and confused by Tobias' use of >>>>>>> End-User (his caps) and subject. Are we talking about a DID for the >>>>>>> subject, the end-user, or both? >>>>>>> >>>>>>> To be clear, in my mind, the subject is in control of policies and >>>>>>> capabilities at the GNAP AS. The end-user is in control of a client= or user >>>>>>> agent and a request to the AS. The end-user and client may or may n= ot have >>>>>>> any prior relationship with the AS. >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>> On Tue, Mar 16, 2021 at 10:00 PM Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>> >>>>>>>> Hi Tobias, >>>>>>>> >>>>>>>> Not yet (none of the current sub_ids require additional parameters= ) >>>>>>>> but if DIDs do get added to subject identifiers, then it's certain= ly >>>>>>>> something we would have to support. >>>>>>>> >>>>>>>> There's already a very basic version of that, but only to chose th= e >>>>>>>> main type (now called "format" in latest draft 07 of SECEVENT), wi= th >>>>>>>> subject_types_supported in the discovery. >>>>>>>> >>>>>>>> Thanks for the heads up, it's worth creating an issue or putting a >>>>>>>> note in some existing issue to not forget looking into that. >>>>>>>> >>>>>>>> Cheers >>>>>>>> Fabien >>>>>>>> >>>>>>>> >>>>>>>> Le mer. 17 mars 2021 =C3=A0 01:01, Tobias Looker >>>>>>>> a =C3=A9crit : >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> This is probably out of scope for the current conversation but ha= s >>>>>>>>> any thought been had on how the client instance could communicate >>>>>>>>> additional options around what subject identifier types it suppor= ts for >>>>>>>>> cases where the client instance will perhaps be required to condu= ct >>>>>>>>> additional processing on the artifacts returned by the AS? As an = example if >>>>>>>>> the AS chose to identify the subject (End-User) using a DID and w= anted to >>>>>>>>> include an additional cryptographic assertion that showed it cont= rols keys >>>>>>>>> appropriately associated to the DID, then the client may have wan= ted to >>>>>>>>> communicate some information up front in their request to ensure = they can >>>>>>>>> perform this additional processing, such as the signature suites = it >>>>>>>>> supports and in the context of DIDs potentially which DID methods= it is >>>>>>>>> capable of resolving? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> [image: Mattr website] >>>>>>>>> *Tobias Looker* >>>>>>>>> Mattr >>>>>>>>> +64 (0) 27 378 0461 >>>>>>>>> tobias.looker@mattr.global >>>>>>>>> [image: Mattr website] [image: Mattr on >>>>>>>>> LinkedIn] [image: >>>>>>>>> Mattr on Twitter] [image: Mattr >>>>>>>>> on Github] >>>>>>>>> This communication, including any attachments, is confidential. I= f >>>>>>>>> you are not the intended recipient, you should not read it - plea= se contact >>>>>>>>> me immediately, destroy it, and do not copy or use any part of th= is >>>>>>>>> communication or disclose anything about it. Thank you. Please no= te that >>>>>>>>> this communication does not designate an information system for t= he >>>>>>>>> purposes of the Electronic Transactions Act 2002. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sat, Mar 13, 2021 at 9:26 PM Fabien Imbault < >>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hi Justin, >>>>>>>>>> >>>>>>>>>> A last word on end-user! =3DRO (again just as food for thought). >>>>>>>>>> >>>>>>>>>> As soon as hints.automated is set to true, it takes priority ove= r >>>>>>>>>> async, which means it's the same model as the one you describe := the AS has >>>>>>>>>> precedence over any other remote contact. >>>>>>>>>> >>>>>>>>>> So that confirms the global view that the AS is the one with the >>>>>>>>>> authority, and that it might know more than the client. >>>>>>>>>> >>>>>>>>>> Cheers >>>>>>>>>> Fabien >>>>>>>>>> >>>>>>>>>> Le jeu. 11 mars 2021 =C3=A0 11:44, Fabien Imbault < >>>>>>>>>> fabien.imbault@gmail.com> a =C3=A9crit : >>>>>>>>>> >>>>>>>>>>> Hi Justin, >>>>>>>>>>> >>>>>>>>>>> I think that's interesting: >>>>>>>>>>> "For the user !=3D RO cases, I think that potentially having a = way >>>>>>>>>>> to signal those two items separately in the request and respons= e could be >>>>>>>>>>> useful. Right now all the user/subject stuff is about identifyi= ng =E2=80=9Cthe user >>>>>>>>>>> that=E2=80=99s currently here at the client instance=E2=80=9D, = in a variety of forms that >>>>>>>>>>> the client instance and AS can negotiate. If the client or AS h= as some >>>>>>>>>>> other notion about who the RO is and how that could be separate= from the >>>>>>>>>>> current user, we could provide a way to signal that like you=E2= =80=99re proposing >>>>>>>>>>> below. In my mental model, there are going to be a lot of use c= ases where >>>>>>>>>>> the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the client at a= ll, but rather to the AS and is >>>>>>>>>>> based on what the client=E2=80=99s asking for. So I could ident= ify the current user >>>>>>>>>>> and ask for a specific medical record, and the AS realizes it h= as to go bug >>>>>>>>>>> a particular doctor to approve things directly. This is instead= of >>>>>>>>>>> interacting with the current user and failing in an awkward way= when the >>>>>>>>>>> current user doesn=E2=80=99t have the rights to do things, but = someone else would. >>>>>>>>>>> But we=E2=80=99d want the system to be able to detect if the cu= rrent user is the >>>>>>>>>>> doctor, so we can just interact with them directly. Does that a= ll track?" >>>>>>>>>>> >>>>>>>>>>> I agree with the general idea. In the end, that's the AS's >>>>>>>>>>> responsibility (and also a big part of its value as a policy en= gine). >>>>>>>>>>> >>>>>>>>>>> Even in the cases - as I suggested - where the client would be >>>>>>>>>>> able to signal what it knows (or thinks it knows) about the sub= ject, the AS >>>>>>>>>>> still needs to validate what it can. The client could be an att= acker lying >>>>>>>>>>> to the AS. Or there could be an unintended bug. >>>>>>>>>>> >>>>>>>>>>> The client still seems like a straightforward source to gather >>>>>>>>>>> optional/declarative hints. Which is what request.user is alrea= dy doing in >>>>>>>>>>> spirit. In many cases, the AS should go a step further. Validat= e >>>>>>>>>>> cryptographic statements from a more reputable issuer, whatever= helps. >>>>>>>>>>> >>>>>>>>>>> Contacts might be one of the possibilities. I'm not suggesting >>>>>>>>>>> interact/fail scenarii at all, which I see as anti-ergonomic (c= omposability >>>>>>>>>>> with timeouts and fallback is the answer to that). The failure = I was >>>>>>>>>>> considering is only for async calls explicitly requested by the= client >>>>>>>>>>> (which is considered in sequence 1.4.3, and not coming from me)= , there's >>>>>>>>>>> obviously no way to ensure a remote RO would actually respond w= hen the >>>>>>>>>>> client expects it. If that sequence is considered, realistic fa= ilure modes >>>>>>>>>>> should be anticipated and dealt with internally (just like any = distributed >>>>>>>>>>> program would do), is all I'm saying. And so from the outside, = there's no >>>>>>>>>>> interact/fail. >>>>>>>>>>> That's the same as in real life: when booking a business trip, >>>>>>>>>>> an employee could either follow the generic rule (2nd class tra= in ticket) >>>>>>>>>>> or reach out to his manager, explaining that it's a long trip a= nd that 1st >>>>>>>>>>> class would be better. The employee knows the manager might not= instantly >>>>>>>>>>> respond, and knows that the absence of an answer means he'll ha= ve to go for >>>>>>>>>>> the 2nd class. >>>>>>>>>>> >>>>>>>>>>> There will be cases when the client doesn't know the RO. I'm no= t >>>>>>>>>>> sure if that's a majority of cases, but it will definitely happ= en. It could >>>>>>>>>>> happen when you interact with an organization or a team and hav= e no idea >>>>>>>>>>> who's responsible or what delegations are in place (some of tho= se cases >>>>>>>>>>> have been described by Adrian for instance). >>>>>>>>>>> There could also be cases where the ownership could be >>>>>>>>>>> distributed (an example was provided when considering remote RO= s). Again in >>>>>>>>>>> real life, it's not unusual for a decision to fallback on a dep= uty when the >>>>>>>>>>> main decision maker is unavailable. Or there could be an open g= overnance >>>>>>>>>>> even, but maybe that's one step too far. >>>>>>>>>>> >>>>>>>>>>> Of course, if the AS has internal knowledge or other ways to ge= t >>>>>>>>>>> the information it should use it. Remains to be seen how we can= specify >>>>>>>>>>> that (cf issue #49 on should/must). The example with doctor/pat= ient is fine >>>>>>>>>>> if hardcoded, but it becomes a problem when we fail to understa= nd the real >>>>>>>>>>> relationships in environments of various sensitive nature. How = the AS >>>>>>>>>>> identifies that a specific record requires approval from Doctor= Bob might >>>>>>>>>>> be context dependent (sometimes it could be a nurse, a team of = doctors, >>>>>>>>>>> another medical organization, etc.). Maybe you could have vario= us levels of >>>>>>>>>>> authorizations (extreme example: military style classifications= ), so that >>>>>>>>>>> it might even be impossible to tell who can be contacted. >>>>>>>>>>> >>>>>>>>>>> That's also why I was suggesting assertions could go beyond >>>>>>>>>>> authentication events, and include cryptographic assertions for >>>>>>>>>>> authorization purposes. Maybe we can even imagine a risk based = approach, as >>>>>>>>>>> in some cases we won't know for sure. >>>>>>>>>>> >>>>>>>>>>> The difficulty will be to be sufficiently generic but simple >>>>>>>>>>> enough. Maybe we can rule out some cases. Maybe remote async co= ntacts are >>>>>>>>>>> out of scope, because we only want instantaneous authorizations= . Most of >>>>>>>>>>> those cases are way beyond what OAuth2 does. I don't know. But = what's >>>>>>>>>>> certain is that the WG should decide what support for cases whe= re end-user >>>>>>>>>>> !=3D RO it intends to provide. My discussion was just a very sm= all >>>>>>>>>>> Chesterston's Fence contribution, even if that seems to have su= rprised. >>>>>>>>>>> >>>>>>>>>>> Fabien >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Mar 10, 2021 at 8:18 PM Justin Richer >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Fabien, >>>>>>>>>>>> >>>>>>>>>>>> First, thanks for doing the heavy lift of writing this topic >>>>>>>>>>>> up. Of these options, I would strongly prefer option (1). The = difference >>>>>>>>>>>> between assertions and identifiers is that an assertion is a f= ully packaged >>>>>>>>>>>> set of attributes, one of which can be an identifier. They are= , generally >>>>>>>>>>>> speaking, cryptographically protected bundles. They=E2=80=99re= designed to carry a >>>>>>>>>>>> bunch of different information about a user and the authentica= tion event in >>>>>>>>>>>> a form that=E2=80=99s independently verifiable and auditable. = SAML assertions (XML >>>>>>>>>>>> document) and ID Tokens (signed JWTs) are the most common ones= we see >>>>>>>>>>>> today, but other formats exist and will keep being invented. >>>>>>>>>>>> >>>>>>>>>>>> An identifier is a different kind of creature. It is a single >>>>>>>>>>>> statement that identifies the party in question in the context= of the party >>>>>>>>>>>> doing the identification. It=E2=80=99s this full context that = the receiver of the >>>>>>>>>>>> identifier needs to interpret it in. When using a federated id= entity >>>>>>>>>>>> protocol, each RP is going to have :some: kind of local user i= nformation >>>>>>>>>>>> store that they=E2=80=99re going to tie into, some field in a = database they=E2=80=99ll key >>>>>>>>>>>> off of. It=E2=80=99s just never going to be the case that all = RPs will be able to >>>>>>>>>>>> use server-provided opaque identifiers for all cases. Account = recovery and >>>>>>>>>>>> binding is one such use case where a user-facing identifier li= ke an email >>>>>>>>>>>> address makes a LOT of sense, for one small example. This is a= n array in >>>>>>>>>>>> the request and response precisely because a user could be kno= wn by several >>>>>>>>>>>> different identifiers to a party, and an RP will have a better= idea about >>>>>>>>>>>> what kinds of things it wants to correlate against, and it=E2= =80=99s up to the AS >>>>>>>>>>>> to provide that mapping. I think that if we don=E2=80=99t defi= ne a way to describe >>>>>>>>>>>> the format, the =E2=80=9Cas_id=E2=80=9D field is going to get = structure back-patched onto >>>>>>>>>>>> it like is being proposed here: >>>>>>>>>>>> >>>>>>>>>>>> https://mattrglobal.github.io/oidc-portable-identities/ >>>>>>>>>>>> >>>>>>>>>>>> I=E2=80=99m personally not a fan of that approach as it mixes = the data >>>>>>>>>>>> layering too much, and you end up making guesses about whether= a field is >>>>>>>>>>>> meaningful or a pointer. I think GNAP will be much better serv= ed by using a >>>>>>>>>>>> data structure for this from the start. DIDs should be another= =E2=80=9Cformat=E2=80=9D of >>>>>>>>>>>> the subject identifier. I don=E2=80=99t think GNAP should defi= ne this format, and >>>>>>>>>>>> I=E2=80=99ve dropped a note to the SECEVENT mailing list askin= g about adding DIDs >>>>>>>>>>>> to the subject identifiers draft before it gets published. DID= s are not >>>>>>>>>>>> assertions, even in the cases where they point to fully functi= onal DID >>>>>>>>>>>> documents with user information in them. (And for what it=E2= =80=99s worth, I think >>>>>>>>>>>> the OIDC world should also use the SECEVENT draft inside ID To= kens to solve >>>>>>>>>>>> the use case of the draft above). >>>>>>>>>>>> >>>>>>>>>>>> For the user !=3D RO cases, I think that potentially having a = way >>>>>>>>>>>> to signal those two items separately in the request and respon= se could be >>>>>>>>>>>> useful. Right now all the user/subject stuff is about identify= ing =E2=80=9Cthe user >>>>>>>>>>>> that=E2=80=99s currently here at the client instance=E2=80=9D,= in a variety of forms that >>>>>>>>>>>> the client instance and AS can negotiate. If the client or AS = has some >>>>>>>>>>>> other notion about who the RO is and how that could be separat= e from the >>>>>>>>>>>> current user, we could provide a way to signal that like you= =E2=80=99re proposing >>>>>>>>>>>> below. In my mental model, there are going to be a lot of use = cases where >>>>>>>>>>>> the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the client at = all, but rather to the AS and is >>>>>>>>>>>> based on what the client=E2=80=99s asking for. So I could iden= tify the current user >>>>>>>>>>>> and ask for a specific medical record, and the AS realizes it = has to go bug >>>>>>>>>>>> a particular doctor to approve things directly. This is instea= d of >>>>>>>>>>>> interacting with the current user and failing in an awkward wa= y when the >>>>>>>>>>>> current user doesn=E2=80=99t have the rights to do things, but= someone else would. >>>>>>>>>>>> But we=E2=80=99d want the system to be able to detect if the c= urrent user is the >>>>>>>>>>>> doctor, so we can just interact with them directly. Does that = all track? >>>>>>>>>>>> >>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>> >>>>>>>>>>>> On Mar 10, 2021, at 4:10 AM, Fabien Imbault < >>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> Notice the question mark in the title. Not to be considered as >>>>>>>>>>>> an editor's comment. >>>>>>>>>>>> This thread intends to provide a detailed comment on the >>>>>>>>>>>> interesting feedback by Kristina: "I would catch up on the thr= ead to >>>>>>>>>>>> understand why DIDs are thought to be treated as assertions". >>>>>>>>>>>> In the chat, I answered: "Happy to get the discussion on DIDs. >>>>>>>>>>>> Actually, could be either or, depending on what we intend to d= o." Let me >>>>>>>>>>>> expand a bit on that, to make it understandable (didn't have t= he time >>>>>>>>>>>> during the meeting, unfortunately). >>>>>>>>>>>> >>>>>>>>>>>> This relates to the items described on slides 20 and 34, which >>>>>>>>>>>> I'll explain further. I'll highlight as transparently as possi= ble what I >>>>>>>>>>>> think would be the benefits and downsides of each. Both are pr= obably viable >>>>>>>>>>>> options, but they correspond to different scopes and objective= s. I'll spend >>>>>>>>>>>> a bit more time on option 2, since it is a different approach = compared to >>>>>>>>>>>> the current draft. >>>>>>>>>>>> >>>>>>>>>>>> *1. The first possibility is to use SECEVENT throughout. * >>>>>>>>>>>> In that case, DIDs should be a part of sub_ids (in the core or >>>>>>>>>>>> in the extension registry, depending on what Annabelle's WG de= cides). More >>>>>>>>>>>> generally, the WG would have to decide which additional sub_id= s it needs >>>>>>>>>>>> (as per Yaron's comment). >>>>>>>>>>>> >>>>>>>>>>>> That's obviously the closest to what is described in draft-04. >>>>>>>>>>>> It allows a communication of subject information between the c= lient and the >>>>>>>>>>>> AS, by using global identifiers (mail, phone, etc.), or using = a local >>>>>>>>>>>> opaque reference - i.e. governed by the AS (that's probably wh= at we >>>>>>>>>>>> would put in the examples, unless someone has a better idea - = cf issues #16 >>>>>>>>>>>> and #42). >>>>>>>>>>>> >>>>>>>>>>>> Assertions relate for instance to the proof of presence of the >>>>>>>>>>>> RO. The current draft-04 therefore plans for id_tokens and sam= l2, maybe >>>>>>>>>>>> there could be other needs later (extension registry). >>>>>>>>>>>> >>>>>>>>>>>> - Benefits: identifiers are a key component of GNAP, which >>>>>>>>>>>> makes integration easier. Possibly one could choose to use DID= s throughout. >>>>>>>>>>>> - Downsides: email/phone identifiers will probably be used >>>>>>>>>>>> throughout by most devs (since that's correlation information = they have in >>>>>>>>>>>> their user DB). Which means we should limit what assertions co= ntain, to >>>>>>>>>>>> avoid doing links between weak global identifiers and hopefull= y stronger >>>>>>>>>>>> assertions. That's not really a problem if it's limited to aut= hentication >>>>>>>>>>>> events mostly (in that perspective, samlv2 could make sense in= the core). >>>>>>>>>>>> An assertion is probably a single value then (not an array). >>>>>>>>>>>> >>>>>>>>>>>> Option 1 can be summarized as: >>>>>>>>>>>> >>>>>>>>>>>> "subject": { >>>>>>>>>>>> "sub_ids": { }, // request and response (SECEVENT -> >>>>>>>>>>>> including DID possibly) >>>>>>>>>>>> "assertions": [ ], // request and response >>>>>>>>>>>> (id_token or samlv2) >>>>>>>>>>>> } >>>>>>>>>>>> ("hints" do not exist currently, but are partially covered >>>>>>>>>>>> separately via "request.user" / the relevance of "principal", = discussed in >>>>>>>>>>>> the slide, is a question mark too - which is a different discu= ssion on >>>>>>>>>>>> end-user !=3D RO). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *2. An alternate possibility is to use SECEVENT only as >>>>>>>>>>>> input/hint* >>>>>>>>>>>> In that case, DIDs should be a part of assertions (which have = a >>>>>>>>>>>> different meaning compared to option 1). >>>>>>>>>>>> >>>>>>>>>>>> The AS only returns an local opaque reference as_ref (while in >>>>>>>>>>>> option 1, it was only one of many possibilities). Its only job= is to help >>>>>>>>>>>> the client differentiate the response subject. The AS policy m= ight further >>>>>>>>>>>> define the scope of that reference, as suggested in >>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210, >>>>>>>>>>>> although I personally viewed that by default as (2) "as_id" an= identifier >>>>>>>>>>>> locally unique to that AS for all the RSs. >>>>>>>>>>>> >>>>>>>>>>>> SECEVENTS are still useful as an input, that's what I presente= d >>>>>>>>>>>> in request.hints.self.sub_ids (but it's the responsibility of = the AS to >>>>>>>>>>>> match it with its own reference system - from instance from th= e email to >>>>>>>>>>>> AS's local record XUT2MFM1XBIKJKSDU8Q). Note: since the slides= , a new >>>>>>>>>>>> draft-ietf-secevent-subject-identifiers-07 has been published.= Notably this >>>>>>>>>>>> includes an opaque identifier, which the client can use to pas= s the as_ref >>>>>>>>>>>> hint to the AS. Thus we wouldn't need any further addition to >>>>>>>>>>>> SECEVENT, although hints would benefit from further additions = (like DIDs >>>>>>>>>>>> for instance). Notice also that subject_types_supported become= s less >>>>>>>>>>>> important, because in the worst case scenario, it's simply a h= int that >>>>>>>>>>>> wouldn't be understood and therefore taken into account by the= AS. >>>>>>>>>>>> >>>>>>>>>>>> The assertions array has a more important role than in option = 1 >>>>>>>>>>>> (with the explicit aim of separating between client hints and = validated >>>>>>>>>>>> info asserted by the AS). It serves as a generic/extendible ma= pping >>>>>>>>>>>> structure, e.g. "the AS asserts that opaque reference >>>>>>>>>>>> XUT2MFM1XBIKJKSDU8Q is matching with these (more or less >>>>>>>>>>>> verifiable) statements." The name assertion therefore correspo= nds to the >>>>>>>>>>>> responsibility of the AS in delivering those statements (cf sh= ould/must, >>>>>>>>>>>> issue #49). Some of these statements relate to identity or aut= h events (ex: >>>>>>>>>>>> DID, id_token), some might directly be useful for authorizatio= n decisions >>>>>>>>>>>> (like ZKP example in the parental control example). Possibly s= ome of these >>>>>>>>>>>> validated assertions could be reused in next interactions. >>>>>>>>>>>> >>>>>>>>>>>> Another question that popped-up is the scope of sub_ids. Shoul= d >>>>>>>>>>>> they be about the same user? (I think so). In the case of remo= te ROs >>>>>>>>>>>> especially, it might be important that DID be considered as an >>>>>>>>>>>> assertion (about someone else's) and not as sub_ids, because t= he AS needs >>>>>>>>>>>> to be careful about who the client wants to reach (avoid spam,= etc.). This >>>>>>>>>>>> is consistent with the rest of discussion on what to do when e= nd-user !=3D >>>>>>>>>>>> RO, although using DIDComm might seem a bit early (the paint i= s very >>>>>>>>>>>> fresh). >>>>>>>>>>>> >>>>>>>>>>>> Option 2 was summarized as: >>>>>>>>>>>> >>>>>>>>>>>> // (suggestion only, not as an editor) >>>>>>>>>>>> "subject": { >>>>>>>>>>>> "as_ref": { // response only (wouldn=E2=80=99t require SECE= VENT) >>>>>>>>>>>> =E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D, >>>>>>>>>>>> =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D >>>>>>>>>>>> }, >>>>>>>>>>>> "assertions": [ ], // request and response >>>>>>>>>>>> (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validat= ed by the AS) >>>>>>>>>>>> >>>>>>>>>>>> "hints": { // request only (optional) >>>>>>>>>>>> "self": { // replaces request.user (support SECEVENT >>>>>>>>>>>> here) >>>>>>>>>>>> =E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaq= ue in draft-07 - >>>>>>>>>>>> that could contain the ref) >>>>>>>>>>>> =E2=80=9Cassertions=E2=80=9D: [ ] // see examples: VC on DO= B or ZKP on age >>>>>>>>>>>> (wider scope, possibly through extensions) >>>>>>>>>>>> }, >>>>>>>>>>>> "principal": { // new proposal presented at IETF110 >>>>>>>>>>>> (just an idea) >>>>>>>>>>>> =E2=80=9Cautomated=E2=80=9D: true, // rule engine >>>>>>>>>>>> =E2=80=9Casync=E2=80=9D: { } // remote ROs >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> - Benefits: as_ref is self supporting (no strong coupling with >>>>>>>>>>>> SECEVENT), but can still take SECEVENT as an input hint for th= e AS. It >>>>>>>>>>>> avoids the risk of making an official association between a we= ak global >>>>>>>>>>>> identifier (e.g. email, used elsewhere) and hopefully stronger= local >>>>>>>>>>>> assertions. GNAP would be fully agnostic to whatever identity = system is >>>>>>>>>>>> used, only facilitating interoperability through assertions (s= econd only in >>>>>>>>>>>> importance compared to the AS opaque reference). Some assertio= ns (possibly >>>>>>>>>>>> extensions) could also be useful for the AS decision (e.g. VC = or ZKP). >>>>>>>>>>>> - Downsides: opaqueness of as_ref is a feature, not a bug. The >>>>>>>>>>>> opaque reference is fully managed by the AS, therefore not inh= erently >>>>>>>>>>>> portable (cf portability discussions in OIDC currently). There= 's no >>>>>>>>>>>> explicit binding to an official identity, only a contextual ma= pping to AS >>>>>>>>>>>> validated assertions. It makes it more difficult to match the = identifiers >>>>>>>>>>>> from one AS to another or to correlate with the client user DB= (still >>>>>>>>>>>> possible via assertions, if the AS allows it). Assertions are = much more >>>>>>>>>>>> generic (possibly via extensions), but might require a more ad= vanced >>>>>>>>>>>> mechanism to request/response only the most relevant informati= on (which >>>>>>>>>>>> makes the AS policy critical here). >>>>>>>>>>>> >>>>>>>>>>>> I hope that clarifies the reasoning for both options. Again I'= m >>>>>>>>>>>> not saying option 2 is better, just saying the trade-offs are = different (+ >>>>>>>>>>>> knowing that we need to keep it simple). >>>>>>>>>>>> - option 1 puts more in sub_ids and less in assertions >>>>>>>>>>>> - option 2 puts less in the reference and more in assertions >>>>>>>>>>>> All of this is open to discussion. More generally speaking, on >>>>>>>>>>>> every part in orange and question mark (?) I would love your i= deas and >>>>>>>>>>>> criticisms. What I intended as an editor is only to highlight = where the WG >>>>>>>>>>>> has important choices to make, before we can make the related = PRs. >>>>>>>>>>>> >>>>>>>>>>>> A further side comment: IETF EAT RATS was suggested for >>>>>>>>>>>> assertions, but relates more to the client attestations. It wa= s added as a >>>>>>>>>>>> comment in >>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, >>>>>>>>>>>> which is a distinct topic we'll work on. >>>>>>>>>>>> >>>>>>>>>>>> Fabien (editor's hat off) >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>> >>>>>>>>> This communication, including any attachments, is confidential. I= f you are not the intended recipient, you should not read it - please conta= ct me immediately, destroy it, and do not copy or use any part of this comm= unication or disclose anything about it. Thank you. Please note that this c= ommunication does not designate an information system for the purposes of t= he Electronic Transactions Act 2002. >>>>>>>>> >>>>>>>>> -- >>>>>>>> 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 This communication, including any attachments, is confidential. If you are= =20 not the intended recipient, you should not read it - please contact me=20 immediately, destroy it, and do not copy or use any part of this=20 communication or disclose anything about it. Thank you. Please note that=20 this communication does not designate an information system for the=20 purposes of the Electronic Transactions Act 2002. --00000000000024611805bdc143db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    > Currently I mostly see DID as alternative subject ide= ntifier (again hypothetically since not currently included in SECEVENT).
    +1 I think DIDs are an interesting option to allow the sub= ject identifier to belong to a domain that is not controlled by the AS unlo= cking the possibility of the End-User being able to have their identity por= table between AS's (hence the name portable identities=C2=A0being used = of recent).

    > A client might not have a DID but= it could have a VC as a certificate of authenticity linked to some audit m= echanism.

    To me a VC would come under the assertio= ns umbrella (that is to say a VC could be one type of valid assertion). The= client may possess or been presented with a VC that it could include in it= s request to the AS as a way to identify the subject and perhaps prove auth= entication and authorization.

    Thanks,
    3D"Mattr=C2=A0
    Tobias Loo= ker
    Mattr
    +64 (0) 27 378 0461
    tobias.looker@mattr.global
    <= table cellpadding=3D"0" cellspacing=3D"0" border=3D"0" style=3D"border:0px"= >
    3D"Mattr3D"Mattr3D"Mattr3D"Mattr=

    This communication, i= ncluding any attachments, is confidential. If you are not the intended reci= pient, you should not read it - please contact me immediately, destroy it, = and do not copy or use any part of this communication or disclose anything = about it. Thank you. Please note that this communication does not designate= an information system for the purposes of the Electronic Transactions Act = 2002.


    On Wed, Mar 17, 2021 at 6:20 P= M Fabien Imbault <fabien.imb= ault@gmail.com> wrote:
    Currently I mostly see DID as alternat= ive subject identifier (again hypothetically since not currently included i= n SECEVENT).

    You're = right that DIDs could serve other purposes too.=C2=A0Denis has also asked an interesting question on whether su= b_ids might be used within the access tokens (issue #210).=C2=A0

    I do see some value in supp= orting VCs for assertions. In my early attempts to map that, it seems to be= applicable to the client instance (like the client posture, or even a VP f= or the display) or to the end-user (request.user).=C2=A0

    We need to keep in mind that a big part of= that discussion also depends on what the SECEVENT WG decides.=C2=A0
    <= div dir=3D"auto">
    Fabien=C2=A0

    Le mer. 17 mars 2021 =C3=A0 05:48, Adrian Gropper <agr= opper@healthurl.com> a =C3=A9crit=C2=A0:
    What do you mean the scop= e is restricted to the subject? DIDs are valuable for all end-users and thi= ngs like did:web can help interop with RSs. A client might not have a DID b= ut it could have a VC as a certificate of authenticity linked to some audit= mechanism.

    Adrian

    On Tue, Mar 16, 2021 at 11:42 PM= Fabien Imbault <fabien.imbault@gmail.com> wrote= :
    Noted. I agree with that goal.

    Back to identifiers, even if we'd use DIDs, the scope is rest= ricted to the subject.=C2=A0=C2=A0

    Fabien


    Le mer. 17 mars 2021 =C3=A0 04:04, Adrian Gropper <= agropper@healthurl.com> a =C3=A9crit=C2=A0:
    =
    = Thanks, Fabien.

    We need to be verrry careful about the shortcut= s once we add user and end-user to our spec. RO =3D subject (of the resourc= e secured by a RS) is clear and independent of any AS or clients. DIDs can = be helpful for the RO-RS relationship for authentication, encryption, and s= ervice endpoints. Authentication can facilitate pseudonymity by default. En= cryption, for example, can allow mediated communications for privacy=C2=A0e= nhancement.=C2=A0

    When we bring the request of an end-user into the pic= ture, the DID can apply to someone other than the RO / subject. The DID can= secure claims that had nothing to do with the=C2=A0RO-RS (as you point out= in #197). Also, in many cases, the subject DID known to the requesting par= ty might be different from the DID associated with the RO at the RS. This p= romotes privacy through DIDs as same-domain identifiers but has to be dealt= with at the policy decision point where capabilities are filtered.=C2=A0

    Another source of potential confusion comes from the way we use client. = DIDs are generally not associated with a client except to the extent the cl= ient is a user-agent such as a mobile wallet or an online policy and capabi= lities agent.

    My suggestion is that we arrive at a set of consistent na= mes soon and present them early in the spec - in what is now Section 1.2 - = and avoid using any shortcuts in the rest of the spec. I would also suggest= we provide examples of the use of DIDs relative to the names we define in = 1.2.=C2=A0

    Adrian

    On Tue, Mar 16, 2021 at 10:51 PM Fabien Im= bault <fabien.imbault@gmail.com> wrot= e:
    Note also that there's issue 197 that discussed that very que= stion.=C2=A0

    Le mer. 17 mars 2021 =C3=A0 03:34, = Fabien Imbault <fabien.imbault@gmail.com> a =C3=A9crit=C2=A0:
    Hi Adrian,

    As the name suggests, it's an = identifier for the subject (and so, hypothetically, a DID to identify the s= ubject). The text indeed concerns the subject as the RO, as it is known to = the AS.=C2=A0

    But it'= ;s easy to make shortcuts, because often we end-up dealing with is user =3D= end-user =3D RO =3D subject.=C2=A0

    Fabien=C2=A0

    <= div dir=3D"ltr" class=3D"gmail_attr">Le mer. 17 mars 2021 =C3=A0 03:10, Adr= ian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    I'm lat= e to this conversation and confused by Tobias' use of End-User (his cap= s)=C2=A0and subject. Are we talking about a DID for the subject, the end-us= er, or both?

    To be clear, in my mind, the subject is in = control=C2=A0of policies and capabilities at the GNAP AS. The end-user is i= n control=C2=A0of a client or user agent and a request to the AS. The end-u= ser and client may or may not have any prior relationship with the AS.
    =
    Adrian

    On Tue, Mar 16, 2021 at 10:00 PM Fabien Im= bault <fabien.imbault@gmail.com> wrote:
    Hi Tobias,

    Not yet (none of the current sub_i= ds require additional parameters) but if DIDs do get added to subject ident= ifiers, then it's certainly something we would have to support.=C2=A0

    There's already a ver= y basic version of that, but only to chose the main type (now called "= format" in latest draft 07 of SECEVENT), with subject_types_supported = in the discovery.=C2=A0

    = Thanks for the heads up, it's worth creating an issue or putting a note= in some existing issue to not forget looking into that.=C2=A0

    Cheers
    Fabien=


    Le mer. 17 mars 2021 =C3=A0 01:01, Tobias Looker <tobia= s.looker@mattr.global> a =C3=A9crit=C2=A0:
    Hi,

    This = is probably out of scope for the current conversation but has any thought b= een had on how the client instance could communicate additional options aro= und what subject identifier types it supports for cases where the client in= stance will perhaps be required to conduct additional processing on the art= ifacts returned by the AS? As an example if the AS chose to identify the su= bject (End-User) using a DID and wanted to include an additional cryptograp= hic assertion that showed it controls keys appropriately associated to the = DID, then the client may have wanted to communicate some information up fro= nt in their request to ensure they can perform this additional processing, = such as the signature suites it supports and in the context of DIDs potenti= ally which DID methods it is capable of resolving?

    Thanks,
    3D"Mattr=C2=A0<= table cellpadding=3D"0" cellspacing=3D"0" border=3D"0" style=3D"border:0px"= >Tobias Looker
    Mattr+64 (0) 27 378= 0461
    tob= ias.looker@mattr.global<= td style=3D"font-size:12px;padding-top:12px">3D"Mattr
    3D"Mattr3D"Mattr3D"Mattr
    =
    This communication, including any attachments= , is confidential. If you are not the intended recipient, you should not re= ad it - please contact me immediately, destroy it, and do not copy or use a= ny part of this communication or disclose anything about it. Thank you. Ple= ase note that this communication does not designate an information system f= or the purposes of the Electronic Transactions Act 2002.
    <= /div>


    On Sat, Mar 13, 2021 at 9:26 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Justin,= =C2=A0

    A last word on en= d-user! =3DRO (again just as food for thought).=C2=A0

    As soon as hints.automated is set to true, it= takes priority over async, which means it's the same model as the one = you describe : the AS has precedence over any other remote contact.=C2=A0

    So that confirms the glob= al view that the AS is the one with the authority, and that it might know m= ore than the client.=C2=A0

    Cheers
    Fabien=C2=A0

    Le jeu. 11 mars 2021 =C3=A0 11:44, Fabien Imbault <f= abien.imbault@gmail.com> a =C3=A9crit=C2=A0:
    Hi Justin,

    I think that's interesting:
    "For the user != =3D RO cases, I think that potentially having a way to signal those two ite= ms separately in the request and response could be useful. Right now all th= e user/subject stuff is about identifying =E2=80=9Cthe user that=E2=80=99s = currently here at the client instance=E2=80=9D, in a variety of forms that = the client instance and AS can negotiate. If the client or AS has some othe= r notion about who the RO is and how that could be separate from the curren= t user, we could provide a way to signal that like you=E2=80=99re proposing= below. In my mental model, there are going to be a lot of use cases where = the =E2=80=9CRO=E2=80=9D isn=E2=80=99t known to the client at all, but rath= er to the AS and is based on what the client=E2=80=99s asking for. So I cou= ld identify the current user and ask for a specific medical record, and the= AS realizes it has to go bug a particular doctor to approve things directl= y. This is instead of interacting with the current user and failing in an a= wkward way when the current user doesn=E2=80=99t have the rights to do thin= gs, but someone else would. But we=E2=80=99d want the system to be able to = detect if the current user is the doctor, so we can just interact with them= directly. Does that all track?"

    I agree with= the general idea. In the end, that's the AS's responsibility (and = also a big part of its value as a policy engine). =C2=A0

    Even in the cases - as I suggested - where the client would be able = to signal what it knows (or thinks it knows) about the subject, the AS stil= l needs to validate what it can. The client could be an attacker lying to t= he AS. Or there could be an unintended bug.=C2=A0

    = The=C2=A0client still seems like a straightforward source to gather optiona= l/declarative hints. Which is what request.user is already doing in spirit.= In many cases, the AS should go a step further. Validate cryptographic sta= tements from a more reputable issuer, whatever helps.

    <= div>Contacts might be one of the possibilities. I'm not suggesting inte= ract/fail scenarii at all, which I see as anti-ergonomic (composability wit= h timeouts and fallback is the answer to that). The failure I was consideri= ng is only for async calls explicitly requested by the client (which is con= sidered in sequence 1.4.3, and not coming from me), there's obviously n= o way to ensure a remote RO would actually respond when the client expects = it. If that sequence is considered, realistic failure modes should be antic= ipated and dealt with internally (just like any distributed program would d= o), is all I'm saying. And so from the outside, there's no interact= /fail.=C2=A0=C2=A0
    That's the same as in real life: when book= ing a business trip, an employee could either follow the generic rule (2nd = class train ticket) or reach out to his manager, explaining that it's a= long trip and that 1st class would be better. The employee knows the manag= er might not instantly respond, and knows that the absence of an answer mea= ns he'll have to go for the 2nd class.=C2=A0

    There will be cases when the=C2=A0client doesn't know the=C2=A0RO. I= 'm not sure if that's a majority of cases, but it will definitely h= appen. It could happen when you interact with an organization or a team and= have no idea who's responsible or what delegations are in place (some = of those cases have been described by Adrian for instance).=C2=A0
    There could also be cases where the ownership could be distributed (an exa= mple was provided when considering remote ROs). Again in real life, it'= s not unusual for a decision to fallback on a deputy when the main decision= maker is unavailable. Or there could be an open governance even, but maybe= that's one step too far.

    Of course, if the AS= has internal knowledge or other ways to get the information it should use = it. Remains to be seen how we can specify that (cf issue #49 on should/must= ). The example with doctor/patient is fine if hardcoded, but it becomes a p= roblem when we fail to understand the real relationships in environments of= various sensitive nature. How the AS identifies that a specific record req= uires approval from Doctor Bob might be context dependent (sometimes it cou= ld be a nurse, a team of doctors, another medical organization, etc.). Mayb= e you could have various levels of authorizations (extreme example: militar= y style classifications), so that it might even be impossible to tell who c= an be contacted.=C2=A0

    That's also why I was s= uggesting assertions could go beyond authentication events, and include cry= ptographic assertions for authorization purposes. Maybe we can even imagine= a risk based approach, as in some cases we won't know for sure.=C2=A0<= /div>

    The difficulty will be to be sufficiently generic = but simple enough. Maybe we can rule out some cases. Maybe remote async con= tacts are out of scope,=C2=A0because we only want instantaneous authorizati= ons. Most of those cases are way beyond what OAuth2 does. I don't know.= But what's certain is that the WG should decide what support for cases= where end-user !=3D RO it intends to provide. My discussion was just a ver= y small Chesterston's Fence contribution, even if that seems to have su= rprised.

    Fabien
    =

    On Wed, Mar 10, 2021 at 8:18 PM Justin Richer <jricher@mit.edu> wrote:
    Hi Fabien,

    First,= thanks for doing the heavy lift of writing this topic up. Of these options= , I would strongly prefer option (1). The difference between assertions and= identifiers is that an assertion is a fully packaged set of attributes, on= e of which can be an identifier. They are, generally speaking, cryptographi= cally protected bundles. They=E2=80=99re designed to carry a bunch of diffe= rent information about a user and the authentication event in a form that= =E2=80=99s independently verifiable and auditable. SAML assertions (XML doc= ument) and ID Tokens (signed JWTs) are the most common ones we see today, b= ut other formats exist and will keep being invented.=C2=A0

    An identifier is a different kind of creature. It is a single stat= ement that identifies the party in question in the context of the party doi= ng the identification. It=E2=80=99s this full context that the receiver of = the identifier needs to interpret it in. When using a federated identity pr= otocol, each RP is going to have :some: kind of local user information stor= e that they=E2=80=99re going to tie into, some field in a database they=E2= =80=99ll key off of. It=E2=80=99s just never going to be the case that all = RPs will be able to use server-provided opaque identifiers for all cases. A= ccount recovery and binding is one such use case where a user-facing identi= fier like an email address makes a LOT of sense, for one small example. Thi= s is an array in the request and response precisely because a user could be= known by several different identifiers to a party, and an RP will have a b= etter idea about what kinds of things it wants to correlate against, and it= =E2=80=99s up to the AS to provide that mapping. I think that if we don=E2= =80=99t define a way to describe the format, the =E2=80=9Cas_id=E2=80=9D fi= eld is going to get structure back-patched onto it like is being proposed h= ere:

    <= div>
    I=E2=80=99m personally not a fan of that approach as it = mixes the data layering too much, and you end up making guesses about wheth= er a field is meaningful or a pointer. I think GNAP will be much better ser= ved by using a data structure for this from the start. DIDs should be anoth= er =E2=80=9Cformat=E2=80=9D of the subject identifier. I don=E2=80=99t thin= k GNAP should define this format, and I=E2=80=99ve dropped a note to the SE= CEVENT mailing list asking about adding DIDs to the subject identifiers dra= ft before it gets published. DIDs are not assertions, even in the cases whe= re they point to fully functional DID documents with user information in th= em. (And for what it=E2=80=99s worth, I think the OIDC world should also us= e the SECEVENT draft inside ID Tokens to solve the use case of the draft ab= ove).

    For the user !=3D RO cases, I think that pot= entially having a way to signal those two items separately in the request a= nd response could be useful. Right now all the user/subject stuff is about = identifying =E2=80=9Cthe user that=E2=80=99s currently here at the client i= nstance=E2=80=9D, in a variety of forms that the client instance and AS can= negotiate. If the client or AS has some other notion about who the RO is a= nd how that could be separate from the current user, we could provide a way= to signal that like you=E2=80=99re proposing below. In my mental model, th= ere are going to be a lot of use cases where the =E2=80=9CRO=E2=80=9D isn= =E2=80=99t known to the client at all, but rather to the AS and is based on= what the client=E2=80=99s asking for. So I could identify the current user= and ask for a specific medical record, and the AS realizes it has to go bu= g a particular doctor to approve things directly. This is instead of intera= cting with the current user and failing in an awkward way when the current = user doesn=E2=80=99t have the rights to do things, but someone else would. = But we=E2=80=99d want the system to be able to detect if the current user i= s the doctor, so we can just interact with them directly. Does that all tra= ck?

    =C2=A0=E2=80=94 Justin

    On Mar 10, 2021, at 4:10 AM, Fabien Imbault <= fabien.imbault@gmail.com> wrote:
    =
    Hello,

    Notice the question mar= k in the title. Not to be considered as an editor's comment.
    = This thread intends to provide a detailed comment on the interesting=C2=A0f= eedback by Kristina: "I would catch up on the thread to understand why= DIDs are thought to be treated as assertions".
    In the chat,= I answered: "Happy to get the discussion on DIDs. Actually, could be = either or, depending on what we intend to do." Let me expand a bit on = that, to make it understandable (didn't have the time during the meetin= g, unfortunately).

    This relates to the items descr= ibed on slides 20 and 34, which I'll explain further. I'll highligh= t as transparently as possible what I think would be the benefits and downs= ides of each. Both are probably viable options, but they correspond to diff= erent scopes and objectives. I'll spend a bit more time on option 2, si= nce it is a different approach compared to the current draft.

    1.= The first possibility is to use SECEVENT throughout.=C2=A0
    I= n that case, DIDs should be a part of sub_ids (in the core or in the extens= ion registry, depending on what Annabelle's WG decides). More generally= , the WG would have to decide which additional sub_ids it needs (as per Yar= on's comment).

    That's obviously the closes= t to what is described in draft-04. It allows a communication of subject in= formation between the client and the AS, by using global identifiers (mail,= phone, etc.), or using a local opaque reference=C2=A0- i.e. governed by th= e AS (that's probably what we would=C2=A0put in the examples, unless so= meone has a better idea - cf issues #16 and #42).=C2=A0

    Assertions relate for instance to the proof of presence of the RO. Th= e current draft-04 therefore plans for id_tokens and saml2, maybe there cou= ld be other needs later (extension registry).

    - Be= nefits: identifiers are a key component of GNAP, which makes integration ea= sier. Possibly one could choose to use DIDs throughout.
    - Downsid= es: email/phone identifiers will probably be used throughout by most devs (= since that's correlation information they=C2=A0have in their user DB). = Which means we should limit what assertions contain, to avoid doing links b= etween weak global identifiers and hopefully stronger assertions. That'= s not really a problem if it's limited to authentication events mostly = (in that perspective, samlv2 could make sense in the core). An assertion is= probably a single value then (not an array).=C2=A0 =C2=A0

    Option 1 can be summarized as:=C2=A0

    "= subject": {
    =C2=A0=C2=A0=C2=A0"sub_ids": { }, // request and response (SECEVENT -> including= DID possibly)=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=C2=A0=C2=A0=C2=A0= =C2=A0
    =C2=A0=C2=A0=C2=A0"assertions": [ ], =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request and response (id_token or sa= mlv2)
    <= font size=3D"1">}
    ("hints" do not exist currently, but ar= e partially covered separately via "request.user" / the relevance= of "principal", discussed in the slide, is a question mark too -= which is a different discussion on end-user !=3D RO).


    2. An alternate possibility is to use SECEVENT on= ly as input/hint
    In that case, DIDs should be a part of asser= tions (which have a different meaning compared to option 1).

    =
    The AS only returns an local opaque reference as_ref (while in o= ption 1, it was only one of many possibilities). Its only job is to help th= e client differentiate the response subject. The AS policy might further de= fine the scope of that reference, as suggested in=C2=A0https://github.com/ietf-wg-gnap/gna= p-core-protocol/issues/210, although I personally=C2=A0viewed that by d= efault as=C2=A0(2) "as_id" an identifier locally unique to that A= S for all the RSs.

    SECEVENTS are still useful as a= n input, that's what I presented in request.hints.self.sub_ids (but it&= #39;s the responsibility=C2=A0of the AS to match it with its own reference = system - from instance from the email to AS's local record XUT2MFM1XBIK= JKSDU8Q).=C2=A0Note: since the slides, a new draft-ietf-secevent-subject-id= entifiers-07 has been published. Notably this includes an opaque identifier= , which the client can use to pass the as_ref hint to the AS. Thus we would= n't need any further addition to SECEVENT,=C2=A0although hints would be= nefit from further additions (like DIDs for instance). Notice also that sub= ject_types_supported becomes less important, because in the worst case scen= ario, it's simply=C2=A0a hint that wouldn't be understood and there= fore taken into account by the AS.

    The assertions = array has a more important role than in option 1 (with the explicit aim of = separating between client hints and validated info asserted by the AS). It = serves as a generic/extendible mapping structure, e.g. "the AS asserts= that opaque reference=C2=A0XUT2MFM1XBIKJKSDU8Q=C2=A0is matching with these (= more or less verifiable) statements." The name assertion therefore cor= responds to the responsibility=C2=A0of the AS in delivering those statement= s (cf should/must, issue #49). Some of these statements relate to identity = or auth events (ex: DID, id_token), some might directly be useful for autho= rization decisions (like ZKP example in the parental control example). Poss= ibly some of these validated assertions could be reused in next interaction= s.

    Another question that popped-up is the scope of= sub_ids. Should they be about the same user? (I think so). In the case of = remote ROs especially, it might be important that DID be considered as an a= ssertion=C2=A0(about someone else's) and not as sub_ids, because the AS= needs to be careful about who the client wants to reach (avoid spam, etc.)= . This is consistent with the rest of discussion on what to do when end-use= r !=3D RO, although using DIDComm might seem a bit early (the paint is very= fresh).=C2=A0

    Option 2 was summarized as:=C2=A0

    // (suggestion only, not as an editor)
    "subject": {
    =C2=A0=C2=A0=C2=A0"as_ref"= ;: { // re= sponse only (wouldn=E2=80=99t require SECEVENT)
    = =E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2= =80=9D,<= span style=3D"white-space:pre-wrap"> <= /span>
    =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU= 8QM=E2= =80=9D=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=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"assertions": [= ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request and res= ponse (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validated b= y the AS)

    =C2=A0=C2=A0=C2=A0"hin= ts": { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 // request only (optional)
    =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0"self": { = // replaces request.user (support SECE= VENT here)
    =C2=A0=C2=A0=C2=A0=E2=80=9Csub_ids=E2= =80=9D: { }, // SECEVENT (including opaque in draft-07 - that could contain the ref)<= /span>
    =C2=A0=C2=A0=C2=A0=E2=80=9Cassertions=E2=80=9D: = [ ] // see examples: VC on DOB or ZKP on age (wider scope, possi= bly through extensions)
    },=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=C2= =A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"princip= al": { // new proposal presented at IETF110= (just an idea)
    =C2=A0 =E2= =80=9Cautomated=E2=80=9D: true, = // rule engine
    =C2=A0 =E2=80=9Casync=E2=80=9D: { } <= /span> // = remote ROs
    }=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=C2=A0=C2= =A0}
    }

    - Bene= fits: as_ref is self supporting (no strong coupling with SECEVENT), but can= still take SECEVENT as an input hint for the AS. It avoids the risk of mak= ing an official association between a weak global identifier (e.g. email, u= sed elsewhere) and hopefully stronger local assertions. GNAP would be fully= agnostic to whatever identity system is used, only facilitating interopera= bility through assertions (second only in importance=C2=A0compared to the A= S opaque reference). Some assertions (possibly extensions) could also be us= eful for the AS decision (e.g. VC or ZKP).
    - Downsides: opaquenes= s of as_ref is a feature, not a bug. The opaque reference is fully managed = by the AS, therefore not inherently portable (cf portability discussions in= OIDC currently). There's no explicit binding to an official identity, = only a contextual mapping to AS validated assertions. It makes it more diff= icult to match the identifiers from one AS to another or to correlate with = the client user DB (still possible via assertions, if the AS allows it). As= sertions are much more generic (possibly via extensions), but might require= a more advanced mechanism=C2=A0to request/response only the most relevant = information (which makes the AS policy critical here).

    =
    I hope that clarifies the=C2=A0reasoning for both options. Again I'= ;m not saying option 2 is better, just saying the trade-offs are different = (+ knowing that we need to keep it simple).
    - option 1 puts more = in sub_ids and less in assertions
    - option 2 puts less in the ref= erence and more in assertions=C2=A0
    All of this is open to discus= sion. More generally speaking, on every part in orange and question mark (?= ) I would love your ideas and criticisms. What I intended as an editor is o= nly to highlight where the WG has important choices to make, before we can = make the related PRs.

    A further side comment: IETF= EAT RATS was suggested for assertions, but relates more to the client atte= stations. It was added as a comment in=C2=A0https://github.com/ietf-wg-gnap/gnap-core-proto= col/issues/44, which is a distinct topic we'll work on.
    <= br>
    Fabien (editor's hat off)

    --
    TXAuth mailing list
    TXAuth@ietf.org
    <= a href=3D"https://www.ietf.org/mailman/listinfo/txauth" rel=3D"noreferrer n= oreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer= noreferrer noreferrer" target=3D"_blank">https://www.ietf.org/mailman/list= info/txauth

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/lis= tinfo/txauth

    This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.
    --
    TXAuth mailing list
    T= XAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txaut= h
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listi= nfo/txauth

    This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.
    --00000000000024611805bdc143db-- From nobody Wed Mar 17 13:42:40 2021 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 2F9953A13BB for ; Wed, 17 Mar 2021 13:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 MMEbdwBlS5It for ; Wed, 17 Mar 2021 13:42:36 -0700 (PDT) Received: from mail-ua1-f47.google.com (mail-ua1-f47.google.com [209.85.222.47]) (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 930FF3A13BC for ; Wed, 17 Mar 2021 13:42:36 -0700 (PDT) Received: by mail-ua1-f47.google.com with SMTP id 97so1193432uav.7 for ; Wed, 17 Mar 2021 13:42:36 -0700 (PDT) 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=TL4ZyEjKUaD1ZS6qaxNW2sCP2bReNxcfu28sXbm2xzI=; b=az0N9F6o6ZR8nrPecaa/mePkAZdMpjgrDyQrpfAUpMkSBM2u32bKukTukmPmN2QJF6 wohwMpRkEAii+nYkEJmEpkQuo4mBOpILl/1Jc7O+mYapT8vXxAQnguS2fLOM7yRUVSVR KIMujk/bSNP2qU37G5rJQSA/7FoCQPcS3u59n57MDx2jsFRALgC23NWDaFIFZ9Y6xGmY 6aJ7hiGiM7tEt9uT005Yu6RxhML+nBEgn15SyWVaYlXA5kR25vp8kNKVO6Od4UfHgH5w MmxfgFcXuJ2ehNcO3HlNVZGOkgeDeLex2eBU8cjSWGCgX+g8dhWoSIpVhkDzwjR2Vkly CDBw== X-Gm-Message-State: AOAM5322+qyz5EdMP7I1G4HOu+OcYC53j7+EoXzi7E9xWkz1VFnKQA0i tnGH5HOpbTWUOo6OtK7pMUnC9NWQ+0xgjG+UpwI= X-Google-Smtp-Source: ABdhPJzfeUUFwA6zgjgkFSowi8YYtsyZ3jkok2m7bfP5RTtMg/ld9UIjVs4YLefhi7jRPTtZPViJPkQkRntEpxCqKAc= X-Received: by 2002:ab0:7115:: with SMTP id x21mr583960uan.39.1616013755240; Wed, 17 Mar 2021 13:42:35 -0700 (PDT) MIME-Version: 1.0 References: <614551CF-E544-4376-9576-E2956454D67D@mit.edu> In-Reply-To: <614551CF-E544-4376-9576-E2956454D67D@mit.edu> From: Adrian Gropper Date: Wed, 17 Mar 2021 16:42:23 -0400 Message-ID: To: Justin Richer Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000d556fc05bdc18556" Archived-At: Subject: Re: [GNAP] GNAP from a human-centered perspective X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 20:42:39 -0000 --000000000000d556fc05bdc18556 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Justin, I just reviewed our charter and I see no clear mandate for an AS-first or RS-first presumption. >From my human-centered, subject-empowering perspective, I want to make sure that I am not forced into an RS-first authorization model. This means that I want control over discovery of an RS that has a relationship with me. If I don't trust the RS, and I can't choose an alternative, I will use a pseudonym or lie about my identity before interacting with that RS. If an RS does not allow me to control my AS, then they are forcing me to send requesting parties to an actor that I do not want to share request data and metadata with. I will then control or hire my own AS and make that discoverable to requesting parties I care about. My AS will determine which clients get information about the existence of an RS that does not respect my choice of AS. If I can, (remember that the RS holds all the cards) I will move my information to another RS that respects my AS choice as soon as possible and then I will have the power to decide whether to make that RS discoverable, or not. SImply put, I care about where requests are presented and I want GNAP to call that the AS. How the client gets to the AS, through out-of band discovery or by visiting an RS-first (UMA-style), may not be that relevant to the core protocol. Adrian On Wed, Mar 17, 2021 at 1:03 PM Justin Richer wrote: > > > On Mar 17, 2021, at 12:21 PM, Adrian Gropper > wrote: > > I think Justin and I are starting from the same assumption that "the RS > holds all the cards" but then reaching different conclusions about the GN= AP > AS. > > The RS can decide what scopes to honor, can ignore tokens, can choose > their jurisdiction and policies, and can often deny service to subjects o= n > a whim. Giving the RS any additional power or coerced trust (e.g. > shrink-wrap licenses) over the subject should be avoided by design. > > One thing the RS controls is the ability to issue a capability to the > subject at some point prior to there being any GNAP AS involved. The > subject can keep this capability in their client (e.g. a wallet) or can > send that capability to a GNAP AS that they choose. > > > I don=E2=80=99t believe this is in scope for GNAP. The abstraction layer = offered > by the protocol is such that the only communication between the client > instance and RS is via an access token issued by an AS. This AS is > reachable by the client and trusted by the RS. > > Fundamentally, what you are describing is function of the AS, at least as > far as the GNAP protocol itself is concerned. Remember, this isn=E2=80=99= t about > deployment, it=E2=80=99s about the roles and responsibilities of the diff= erent > items involved. > > > Instead of issuing a capability, the RS can also choose to accept a > user-controlled AS. They can do that, for example, by storing a (DID) > service endpoint to a GNAP AS. The RS could force the subject (as > controller) to choose from a list of certified ASs or they could ask the = AS > to present a certificate from a trusted issuer. This last RS-controlled > option is seen in US HIPAA law but it has provisions for the data subject > to insist on acceptance of a subject-issued certificate as part of the > protocol. The UDAP group is active in profiling the format of these > certificates to be used on top of OAuth. > > > I think that all of these things are functions of the AS, not the RS. Wit= h > many AS deployments in OAuth today, the user can present themselves to th= e > AS using a choice of federated logins. So in GNAP the user=E2=80=99s agen= t can > present a certificate from a trusted issuer. This is not something an AS > presents to an RS, it=E2=80=99s something that a different component pres= ents to > the AS. > > The result of this is an access token that the RS will accept. The AS and > RS are in the same trust boundary, the crossing of that boundary happens > inbound to the AS. This is fundamentally the change in language that I ha= ve > been trying to push here. While the RS could accept an arbitrary AS, I > think it=E2=80=99s both more useful and more realistic for the AS to acce= pt a > variety of proofs, claims, certifications, etc from the RO and/or user at > runtime in order to make its token. > > > Finally, GNAP should not presume that the AS is either carried by a > subject or online. A subject can have the option to choose an unreliable = or > part-time AS. > > > I disagree with this statement. GNAP is a protocol and is based on HTTP. > From a technical level, we have to assume that it is reachable by the > client instance at the start of the process. But if we stop trying to put > the AS into a place where it doesn=E2=80=99t function well, we can start = to talk > about the unreliable and part-time authorization-and-consent component > (agent, wallet, whatever) that can feed into the AS when available. This > leads to a much more robust protocol structure. > > =E2=80=94 Justin > > Adrian > > > > > > > > On Wed, Mar 17, 2021 at 10:55 AM Justin Richer wrote: > >> I think this is a fairly reasonable way to look at things, but the >> sticking point for me is the implication of how the AS =E2=80=9Cbrings t= ogether=E2=80=9D >> the items. It could be read to mean that the end-user=E2=80=99s policies= all live >> on the AS. If the end-user needs to own or control the AS in order for t= his >> to work, I don=E2=80=99t think that pattern has any legs in reality as i= t requires >> an RS to accept access tokens from an unknown source. This means the RS >> then needs to understand a LOT more about the access token than it would >> otherwise be able to. >> >> Instead, I would encourage us to think of =E2=80=9Cbrings together=E2=80= =9D in the sense >> that the AS can take as input a number of different things, including >> things that the user controls and things the RO controls. This is where = I >> think we can draw the line around the AS in a way that will let it funct= ion >> in this human-facing world. >> >> Because you=E2=80=99re absolutely right that the end user shouldn=E2=80= =99t know or care >> if what they carry is an =E2=80=9CAS=E2=80=9D in the GNAP sense or not. = >From their >> perspective, they need to present something to a service to get somethin= g >> done. In the OAuth world this is =E2=80=9Clog in to our web server=E2=80= =9D. In the GNAP >> world we can have this include a wider variety of things they can presen= t >> to the AS, including VCs and DIDs and a bunch of other things. >> >> =E2=80=94 Justin >> >> > On Mar 17, 2021, at 12:30 AM, Adrian Gropper >> wrote: >> > >> > I truly appreciate the diligence of our editors and contributors. >> > >> > Without intruding on the technical discussions, I hope this thread can >> be an opportunity for us to step out of our comfort zone and look around= . >> > >> > As a human data subject, I am cognizant and in control of only two >> kinds of actors, user agents and services. The user agents are almost >> exclusively a handful of web browsers, email clients, and apps duplicate= d >> and sometimes synchronizing across two to four phones and computers. The >> services (that I expect have visibility into my persona) are in a dozen >> categories from banking and ISPs that I expect to be acting as fiduciari= es >> to platforms, social networks and other data brokers with their own agen= da. >> At this altitude, GNAP, DIDs, and ASs are as invisible as MAC addresses = and >> routers. >> > >> > Our success, from a human-centered perspective, will come indirectly a= s >> a result of the GNAP Authorization Server. The user agents and service >> providers I see (and sometimes choose) will support GNAP along with OAut= h >> and FIDO and Apple Sign-In as protocols. The common thing about these >> protocols is that they coexist and overlap in incomprehensible ways made >> even more obscure by DIDs, VCs, and self-issued identity providers (SIOP= ). >> As we get to DIDcomm, even I get lost. >> > >> > My suggestion or proposal to our group is that we respect the human >> perspective by doing our best to make the concept of an authorization >> server relevant even if it remains hidden from view behind protocols lik= e >> GNAP and OAuth and data models like DID and VC. In doing this we would >> recognize that a human's agent would likely support GNAP AS as well as >> incumbent attribute management protocols. As a human, I just want my onl= ine >> agent to work across as many user-agents and services as possible. As wi= th >> life partners or spouses, having more than one intelligent semi-autonomo= us >> agent is not typically a benefit. >> > >> > My concrete suggestion is that GNAP define the AS as the entity or >> actor that brings together the subject's policies, the capabilities gran= ted >> by services, and requests and serves up authorizations to the requesting >> party. >> > >> > Adrian >> > >> > >> > >> > >> > -- >> > TXAuth mailing list >> > TXAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/txauth >> >> > --000000000000d556fc05bdc18556 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Justin,

    I just reviewed our charter = and I see no clear mandate for an AS-first or RS-first presumption.=C2=A0

    From my human-centered, subject-empowering perspect= ive, I want to make sure that I am not forced into an RS-first authorizatio= n model. This means that I want control over discovery of an RS that has a = relationship with me. If I don't trust the RS, and I can't choose a= n alternative, I will use a pseudonym or lie about my identity before inter= acting with that RS.

    If an RS does not allow me to= control my AS, then they are forcing me to send requesting parties to an a= ctor that I do not want to share request data and metadata with. I will the= n control or hire my own AS and make that discoverable to requesting partie= s I care about. My AS will determine which clients get information about th= e existence of an RS that does not respect my choice of AS. If I can, (reme= mber that the RS holds all the cards) I will move my information to another= RS that respects my AS choice as soon as possible and then I will have the= power to decide whether to make that RS discoverable, or not.
    SImply put, I care about where requests are presented and I wa= nt GNAP to call that the AS. How the client gets to the AS, through out-of = band discovery or by visiting an RS-first (UMA-style), may not be that rele= vant to the core protocol.=C2=A0

    Adrian

    On We= d, Mar 17, 2021 at 1:03 PM Justin Richer <jricher@mit.edu> wrote:


    On Mar 17, 2021, at 12:21 PM, Adrian Gropper <agropper@healthurl.c= om> wrote:

    I think Justin and I are s= tarting from the same assumption that "the RS holds all the cards"= ; but then reaching different conclusions about the GNAP AS.=C2=A0

    =
    The RS can decide what scopes to honor, can ignore tokens, can c= hoose their jurisdiction and policies, and can often deny service to subjec= ts on a whim. Giving the RS any additional power or coerced trust (e.g. shr= ink-wrap licenses) over the subject should be avoided by design.
    =
    One thing the RS controls is the ability=C2=A0to issue a cap= ability to the subject at some point prior to there being any GNAP AS invol= ved. The subject can keep this capability in their client (e.g. a wallet) o= r can send that capability to a GNAP AS that they choose.=C2=A0
    =

    I don=E2=80=99t believe this is in s= cope for GNAP. The abstraction layer offered by the protocol is such that t= he only communication between the client instance and RS is via an access t= oken issued by an AS. This AS is reachable by the client and trusted by the= RS.=C2=A0

    Fundamentally, what you are describing = is function of the AS, at least as far as the GNAP protocol itself is conce= rned. Remember, this isn=E2=80=99t about deployment, it=E2=80=99s about the= roles and responsibilities of the different items involved.


    Instead of i= ssuing a capability, the RS can also choose to accept a user-controlled AS.= They can do that, for=C2=A0example, by storing a (DID) service endpoint to= a GNAP AS. The RS could force the subject (as controller) to choose from a= list of certified ASs or they could ask the AS to present a certificate fr= om a trusted issuer. This last RS-controlled option is seen in US HIPAA law= but it has provisions for the data subject to insist on acceptance of a su= bject-issued certificate as part of the protocol. The UDAP group is active = in profiling the format of these certificates to be used on top of OAuth.

    I think that all of these = things are functions of the AS, not the RS. With many AS deployments in OAu= th today, the user can present themselves to the AS using a choice of feder= ated logins. So in GNAP the user=E2=80=99s agent can present a certificate = from a trusted issuer. This is not something an AS presents to an RS, it=E2= =80=99s something that a different component presents to the AS.
    =
    The result of this is an access token that the RS will accep= t. The AS and RS are in the same trust boundary, the crossing of that bound= ary happens inbound to the AS. This is fundamentally the change in language= that I have been trying to push here. While the RS could accept an arbitra= ry AS, I think it=E2=80=99s both more useful and more realistic for the AS = to accept a variety of proofs, claims, certifications, etc from the RO and/= or user at runtime in order to make its token.


    Finally, GNAP should not p= resume that the AS is either carried by a subject or online. A subject can = have the option to choose an unreliable or part-time AS.


    I disagree with this stateme= nt. GNAP is a protocol and is based on HTTP. From a technical level, we hav= e to assume that it is reachable by the client instance at the start of the= process. But if we stop trying to put the AS into a place where it doesn= =E2=80=99t function well, we can start to talk about the unreliable and par= t-time authorization-and-consent component (agent, wallet, whatever) that c= an feed into the AS when available. This leads to a much more robust protoc= ol structure.

    =C2=A0=E2=80=94 Justin

    Adrian=C2=A0






    On Wed, Mar 17, 2021 at 10:55 AM Justin Richer <jricher@mit.edu> wrote:
    I think this is a fairly reasonable way to look at things= , but the sticking point for me is the implication of how the AS =E2=80=9Cb= rings together=E2=80=9D the items. It could be read to mean that the end-us= er=E2=80=99s policies all live on the AS. If the end-user needs to own or c= ontrol the AS in order for this to work, I don=E2=80=99t think that pattern= has any legs in reality as it requires an RS to accept access tokens from = an unknown source. This means the RS then needs to understand a LOT more ab= out the access token than it would otherwise be able to.

    Instead, I would encourage us to think of =E2=80=9Cbrings together=E2=80=9D= in the sense that the AS can take as input a number of different things, i= ncluding things that the user controls and things the RO controls. This is = where I think we can draw the line around the AS in a way that will let it = function in this human-facing world.

    Because you=E2=80=99re absolutely right that the end user shouldn=E2=80=99t= know or care if what they carry is an =E2=80=9CAS=E2=80=9D in the GNAP sen= se or not. From their perspective, they need to present something to a serv= ice to get something done. In the OAuth world this is =E2=80=9Clog in to ou= r web server=E2=80=9D. In the GNAP world we can have this include a wider v= ariety of things they can present to the AS, including VCs and DIDs and a b= unch of other things.

    =C2=A0=E2=80=94 Justin

    > On Mar 17, 2021, at 12:30 AM, Adrian Gropper <agropper@healthurl.com> wrote= :
    >
    > I truly appreciate the diligence of our editors and contributors.
    >
    > Without intruding on the technical discussions, I hope this thread can= be an opportunity for us to step out of our comfort zone and look around.<= br> >
    > As a human data subject, I am cognizant and in control of only two kin= ds of actors, user agents and services. The user agents are almost exclusiv= ely a handful of web browsers, email clients, and apps duplicated and somet= imes synchronizing across two to four phones and computers. The services (t= hat I expect have visibility into my persona) are in a dozen categories fro= m banking and ISPs that I expect to be acting as fiduciaries to platforms, = social networks and other data brokers with their own agenda. At this altit= ude, GNAP, DIDs, and ASs are as invisible as MAC addresses and routers.
    >
    > Our success, from a human-centered perspective, will come indirectly a= s a result of the GNAP Authorization Server. The user agents and service pr= oviders I see (and sometimes choose) will support GNAP along with OAuth and= FIDO and Apple Sign-In as protocols. The common thing about these protocol= s is that they coexist and overlap in incomprehensible ways made even more = obscure by DIDs, VCs, and self-issued identity providers (SIOP). As we get = to DIDcomm, even I get lost.
    >
    > My suggestion or proposal to our group is that we respect the human pe= rspective by doing our best to make the concept of an authorization server = relevant even if it remains hidden from view behind protocols like GNAP and= OAuth and data models like DID and VC. In doing this we would recognize th= at a human's agent would likely support GNAP AS as well as incumbent at= tribute management protocols. As a human, I just want my online agent to wo= rk across as many user-agents and services as possible. As with life partne= rs or spouses, having more than one intelligent semi-autonomous agent is no= t typically a benefit.
    >
    > My concrete suggestion is that GNAP define the AS as the entity or act= or that brings together the subject's policies, the capabilities grante= d by services, and requests and serves up authorizations to the requesting = party.
    >
    > Adrian
    >
    >=C2=A0 =C2=A0
    >
    >=C2=A0
    > --
    > TXAuth mailing list
    > TXAuth@ietf.org
    >     https://www.ietf.org/mailman/listinfo/txauth

    --000000000000d556fc05bdc18556-- From nobody Wed Mar 17 13:55:46 2021 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 DBCD33A1491 for ; Wed, 17 Mar 2021 13:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 Wl6uFZiv-rbr for ; Wed, 17 Mar 2021 13:55:43 -0700 (PDT) Received: from mail-vs1-f46.google.com (mail-vs1-f46.google.com [209.85.217.46]) (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 829493A1490 for ; Wed, 17 Mar 2021 13:55:43 -0700 (PDT) Received: by mail-vs1-f46.google.com with SMTP id 124so365488vsg.12 for ; Wed, 17 Mar 2021 13:55:43 -0700 (PDT) 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=nRKkyyJhhIsuLoH86LYrbLGMO++iLQzRpK+Ds+zjRg0=; b=Up0ILKyJXt8XdAoPrb2xKoCnWP70+yfvLKLXeUaofIfd2kdUf1uBgJ0YkvkFqMBYAU XUNCNfMzVZJwW9pafNRDmY2Jfkfw3cVYwgW45nFXHPKcXy9vosVYztYRRaetZU3mBvSF I9wXcbYK5bHlvFYLUmJu2FNqPAwyD9BmanGtA88Mq8g2RUUbDftWzKO/7KXANu9ExpYv 1Z9QdxkBohmaUlcSMRrYM2Cw+kZK+BH4el1AmgeN9kxxqAoAdQ1YviFBBE8TVO5k/SRO uLoWQS/LiJp6HyxS7MWQTv1zNSqex1J6gCLyl7GHlOyYXWEfZusXKci1LvASLskHkbrY rAuw== X-Gm-Message-State: AOAM531VnYIu2VG9fxxA7AKWeUNIguzdLCYJJq+2bPOf3jPEP2U5RzYa Z3SsbEBMfBZE6UCFsNZM6yf9873lDhKCamtqvtY= X-Google-Smtp-Source: ABdhPJxFjhhzLJSPwCMYxTJ5DHVUqMgsA2jV2ZjNhDTHW4CgXo6LciENUMp1rAVKQHLfpn/DVZRZe8etsA3uIRNoXR4= X-Received: by 2002:a05:6102:24a:: with SMTP id a10mr4723069vsq.39.1616014542298; Wed, 17 Mar 2021 13:55:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Adrian Gropper Date: Wed, 17 Mar 2021 16:55:31 -0400 Message-ID: To: Tobias Looker Cc: Fabien Imbault , GNAP Mailing List , Justin Richer Content-Type: multipart/alternative; boundary="000000000000bee15005bdc1b406" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 20:55:45 -0000 --000000000000bee15005bdc1b406 Content-Type: text/plain; charset="UTF-8" On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker wrote: > > > A client might not have a DID but it could have a VC as a certificate of > authenticity linked to some audit mechanism. > > To me a VC would come under the assertions umbrella (that is to say a VC > could be one type of valid assertion). The client may possess or been > presented with a VC that it could include in its request to the AS as a way > to identify the subject and perhaps prove authentication and authorization. > I do not assume that the client that interacts with the AS to make a request and receive a token is the same as the client that will present the token to the RS. In the US HIPAA use-case, for example, the root of trust is a contract between the patient-subject and the doctor-requesting party but the doctor workflow is expected to delegate the token to some other end-user that may be using a totally different client such as an EHR. Adrian --000000000000bee15005bdc1b406 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Wed, Mar 17, 2021 at 4:23 PM Tobias Lo= oker <tobias.looker@mattr.global> wrote:
    <snip>
    > = A client might not have a DID but it could have a VC as a certificate of au= thenticity linked to some audit mechanism.

    To me a= VC would come under the assertions umbrella (that is to say a VC could be = one type of valid assertion). The client may possess or been presented with= a VC that it could include in its request to the AS as a way to identify t= he subject and perhaps prove authentication and authorization.
    <= /blockquote>

    I do not assume that the client that intera= cts with the AS to make a request and receive a token is the same as the cl= ient that will present the token to the RS. In the US HIPAA use-case, for e= xample, the root of trust is a contract between the patient-subject and the= doctor-requesting party but the doctor workflow is expected to delegate th= e token to some other end-user that may be using a totally different client= such as an EHR.

    Adrian

    =
    --000000000000bee15005bdc1b406-- From nobody Wed Mar 17 14:29:30 2021 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 F2F553A1572 for ; Wed, 17 Mar 2021 14:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Su7n-QsYBDYz for ; Wed, 17 Mar 2021 14:29:27 -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 1BB933A156D for ; Wed, 17 Mar 2021 14:29:26 -0700 (PDT) Received: from [192.168.1.22] (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 12HLTLTt028071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 17 Mar 2021 17:29:21 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_75862123-7B9D-42E9-94B6-79F3BBDF9034" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 17 Mar 2021 17:29:21 -0400 In-Reply-To: Cc: Tobias Looker , Fabien Imbault , GNAP Mailing List To: Adrian Gropper References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 21:29:29 -0000 --Apple-Mail=_75862123-7B9D-42E9-94B6-79F3BBDF9034 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 17, 2021, at 4:55 PM, Adrian Gropper = wrote: >=20 > On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker = wrote: > > > A client might not have a DID but it could have a VC as a = certificate of authenticity linked to some audit mechanism. >=20 > To me a VC would come under the assertions umbrella (that is to say a = VC could be one type of valid assertion). The client may possess or been = presented with a VC that it could include in its request to the AS as a = way to identify the subject and perhaps prove authentication and = authorization. >=20 > I do not assume that the client that interacts with the AS to make a = request and receive a token is the same as the client that will present = the token to the RS. In the US HIPAA use-case, for example, the root of = trust is a contract between the patient-subject and the = doctor-requesting party but the doctor workflow is expected to delegate = the token to some other end-user that may be using a totally different = client such as an EHR. >=20 If the client that gets the token is not same as the client that uses = the token, that is a violation of core security principles as it allows = for (and really designs for) impersonation by client software. I would = have no reason to trust client software that would hand its credentials = over to another piece of software, and in fact I shouldn=E2=80=99t trust = it.=20 I think you may be conflating several different kinds of parties under = the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80=99s = entirely possible that one client might call an RS that in turn acts as = a client for something else down stream. But each of those hops is = different from the last. =E2=80=94 Justin --Apple-Mail=_75862123-7B9D-42E9-94B6-79F3BBDF9034 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Mar 17, 2021, at 4:55 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    On = Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <tobias.looker@mattr.global> wrote:
    <snip>
    > A client might not = have a DID but it could have a VC as a certificate of authenticity = linked to some audit mechanism.

    To me a VC would come under the = assertions umbrella (that is to say a VC could be one type of valid = assertion). The client may possess or been presented with a VC that it = could include in its request to the AS as a way to identify the subject = and perhaps prove authentication and = authorization.

    I do not assume that the client that = interacts with the AS to make a request and receive a token is the same = as the client that will present the token to the RS. In the US HIPAA = use-case, for example, the root of trust is a contract between the = patient-subject and the doctor-requesting party but the doctor workflow = is expected to delegate the token to some other end-user that may be = using a totally different client such as an EHR.


    If the client that gets the token is not same as = the client that uses the token, that is a violation of core security = principles as it allows for (and really designs for) impersonation by = client software. I would have no reason to trust client software that = would hand its credentials over to another piece of software, and in = fact I shouldn=E2=80=99t trust it. 

    I think you may be conflating several different = kinds of parties under the =E2=80=9Cclient=E2=80=9D umbrella here, = though. It=E2=80=99s entirely possible that one client might call an RS = that in turn acts as a client for something else down stream. But each = of those hops is different from the last.

     =E2=80=94 Justin

    = --Apple-Mail=_75862123-7B9D-42E9-94B6-79F3BBDF9034-- From nobody Wed Mar 17 16:19:00 2021 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 456C43A17AC for ; Wed, 17 Mar 2021 16:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 IASn8LFBQsGX for ; Wed, 17 Mar 2021 16:18:57 -0700 (PDT) Received: from mail-vs1-f46.google.com (mail-vs1-f46.google.com [209.85.217.46]) (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 720553A17AA for ; Wed, 17 Mar 2021 16:18:57 -0700 (PDT) Received: by mail-vs1-f46.google.com with SMTP id e13so539210vsl.5 for ; Wed, 17 Mar 2021 16:18:57 -0700 (PDT) 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=9mVNrvr8Sz78cmWJRBkK7+qPvzSk0Iaq4zMW96o1m50=; b=Osv3ilC65zP3ZFQ3EpTWdL+PnG/D11mmchL7kRsUbgaLifSv/Oq1X+tX8sdhkgA0ur 2SQpf3ti2VEg1ZpvyCgjhJgvka3jICqoz8zTXt20pQOnEAoJ5GyImi1Z8ePw29r8HhLX Cw4HbxZy8cl51G5soxyQ8ImLwkHNI3Bv1oa8rKSppksd2boMvU9VyNlX943rscqUnA42 kvT6EJ9dVW4NuhV+DGIuAS63rARQ8WcdDbrhA5JXZ63nieT+kj2yRo1olVS7WgfumoPQ YoRNnfmDSWgHUgMJbivBKIB9+fbGEW1DFWK9qqXOBMzUoNd/Q17JOJ03DE9iOoIr2Lo0 CYQQ== X-Gm-Message-State: AOAM531zle6lbg0u9cOV+IcTXjH5oCB1p59dvh3NZdJusE4DPx3uZNxi Td6ow0/XIXjDbIS+QsmmaVOMl9lLBeB5uNOwSjw= X-Google-Smtp-Source: ABdhPJw+7GywzOuZ4JeyhipRxrP+Ggttx7lZM2XX9ChDbZT7kMRxxbUbRux9KTOCBZoXOjsc4zquS7b8r5ZIBlyuQ44= X-Received: by 2002:a05:6102:24a:: with SMTP id a10mr4990449vsq.39.1616023136334; Wed, 17 Mar 2021 16:18:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Adrian Gropper Date: Wed, 17 Mar 2021 19:18:44 -0400 Message-ID: To: Justin Richer Cc: Tobias Looker , Fabien Imbault , GNAP Mailing List , Alan Karp , Mark Miller Content-Type: multipart/alternative; boundary="000000000000fd775705bdc3b44b" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 23:18:59 -0000 --000000000000fd775705bdc3b44b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm sure you're right. Our vague terminology around client and end-user leads to my confusion. If GNAP is primarily about delegation then, of course, we should avoid any incentives to impersonate or we're wasting our time. This is partly why I'm trying to study up on capabilities and asking for expert advice from folks like Alan Karp and Mark Miller (cc'd) As best I can understand it, the RS has only two choices, it can: - store an attribute of the RO a [DID, email address, GNAP AS URL], or - hand the RO a capability as a sort-of promise and avoid making any entries in an ACL or equivalent. When a token comes back to the RS, it will either be: - validated according to something associated with the stored RO attribute, or - signed by the RS itself. Either way, trust in the client seems moot. Adrian On Wed, Mar 17, 2021 at 5:29 PM Justin Richer wrote: > On Mar 17, 2021, at 4:55 PM, Adrian Gropper > wrote: > > > On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker > wrote: > >> >> > A client might not have a DID but it could have a VC as a certificate >> of authenticity linked to some audit mechanism. >> >> To me a VC would come under the assertions umbrella (that is to say a VC >> could be one type of valid assertion). The client may possess or been >> presented with a VC that it could include in its request to the AS as a = way >> to identify the subject and perhaps prove authentication and authorizati= on. >> > > I do not assume that the client that interacts with the AS to make a > request and receive a token is the same as the client that will present t= he > token to the RS. In the US HIPAA use-case, for example, the root of trust > is a contract between the patient-subject and the doctor-requesting party > but the doctor workflow is expected to delegate the token to some other > end-user that may be using a totally different client such as an EHR. > > > If the client that gets the token is not same as the client that uses the > token, that is a violation of core security principles as it allows for > (and really designs for) impersonation by client software. I would have n= o > reason to trust client software that would hand its credentials over to > another piece of software, and in fact I shouldn=E2=80=99t trust it. > > I think you may be conflating several different kinds of parties under th= e > =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80=99s entirely pos= sible that one client > might call an RS that in turn acts as a client for something else down > stream. But each of those hops is different from the last. > > =E2=80=94 Justin > > --000000000000fd775705bdc3b44b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I'm sure you're right. Our vague terminology=C2=A0= around client=C2=A0and=C2=A0end-user leads to my confusion. If GNAP is prim= arily about delegation=C2=A0then, of course, we should=C2=A0avoid any incen= tives to impersonate or we're wasting our time. This is partly why I= 9;m trying to study up on capabilities and asking for expert advice from fo= lks like Alan Karp and Mark Miller (cc'd)

    As best I = can understand it, the RS has only two choices, it can:
    • s= tore an attribute of the RO a [DID, email address, GNAP AS URL], or
      • hand the RO a capability as a sort-of promise and avoid making any entries= in an ACL or equivalent.
    When a token comes back to the RS, = it will either be:
    • validated according to something assoc= iated with the stored RO attribute, or
    • signed by the RS itself.=
    Either way, trust in the client seems moot.

    Adrian



    On Wed, Mar = 17, 2021 at 5:29 PM Justin Richer <jr= icher@mit.edu> wrote:
    On Mar 17, 2021, at 4:55 PM, A= drian Gropper <agropper@healthurl.com> wrote:
    =
    On Wed, Mar 17, 2021 at 4:23 PM = Tobias Looker <tobias.looker@mattr.global> wrote:
    <snip>
    >= ; A client might not have a DID but it could have a VC as a certificate of = authenticity linked to some audit mechanism.

    To me= a VC would come under the assertions umbrella (that is to say a VC could b= e one type of valid assertion). The client may possess or been presented wi= th a VC that it could include in its request to the AS as a way to identify= the subject and perhaps prove authentication and authorization.

    I do not assume that the client that inte= racts with the AS to make a request and receive a token is the same as the = client that will present the token to the RS. In the US HIPAA use-case, for= example, the root of trust is a contract between the patient-subject and t= he doctor-requesting party but the doctor workflow is expected to delegate = the token to some other end-user that may be using a totally different clie= nt such as an EHR.


    <= /div>
    If the client that gets the token is not same as the client that = uses the token, that is a violation of core security principles as it allow= s for (and really designs for) impersonation by client software. I would ha= ve no reason to trust client software that would hand its credentials over = to another piece of software, and in fact I shouldn=E2=80=99t trust it.=C2= =A0

    I think you may be conflating several differen= t kinds of parties under the =E2=80=9Cclient=E2=80=9D umbrella here, though= . It=E2=80=99s entirely possible that one client might call an RS that in t= urn acts as a client for something else down stream. But each of those hops= is different from the last.

    =C2=A0=E2=80=94 Justi= n

    --000000000000fd775705bdc3b44b-- From nobody Wed Mar 17 16:36:41 2021 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 511983A1302 for ; Wed, 17 Mar 2021 16:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 zPkK-PNPpBhD for ; Wed, 17 Mar 2021 16:36:37 -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 ED40D3A17E4 for ; Wed, 17 Mar 2021 16:36:35 -0700 (PDT) Received: from [192.168.1.22] (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 12HNaV63031983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 17 Mar 2021 19:36:31 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F5F49108-7A3D-49D1-BA14-7A53D55FFD33" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 17 Mar 2021 19:36:31 -0400 In-Reply-To: Cc: Tobias Looker , Fabien Imbault , GNAP Mailing List , Alan Karp , Mark Miller To: Adrian Gropper References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 23:36:39 -0000 --Apple-Mail=_F5F49108-7A3D-49D1-BA14-7A53D55FFD33 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I still think the RS doesn=E2=80=99t do these things, the AS does. The = AS is the component of the =E2=80=9CAPI Provider=E2=80=99 (in your use = case model) that handles the authorizations. The RS just fulfills them. = They are part of the same trust boundary. =E2=80=94 Justin > On Mar 17, 2021, at 7:18 PM, Adrian Gropper = wrote: >=20 > I'm sure you're right. Our vague terminology around client and = end-user leads to my confusion. If GNAP is primarily about delegation = then, of course, we should avoid any incentives to impersonate or we're = wasting our time. This is partly why I'm trying to study up on = capabilities and asking for expert advice from folks like Alan Karp and = Mark Miller (cc'd) >=20 > As best I can understand it, the RS has only two choices, it can: > store an attribute of the RO a [DID, email address, GNAP AS URL], or > hand the RO a capability as a sort-of promise and avoid making any = entries in an ACL or equivalent. > When a token comes back to the RS, it will either be: > validated according to something associated with the stored RO = attribute, or > signed by the RS itself. > Either way, trust in the client seems moot. >=20 > Adrian >=20 >=20 >=20 > On Wed, Mar 17, 2021 at 5:29 PM Justin Richer > wrote: > On Mar 17, 2021, at 4:55 PM, Adrian Gropper > wrote: >>=20 >> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker = > wrote: >> >> > A client might not have a DID but it could have a VC as a = certificate of authenticity linked to some audit mechanism. >>=20 >> To me a VC would come under the assertions umbrella (that is to say a = VC could be one type of valid assertion). The client may possess or been = presented with a VC that it could include in its request to the AS as a = way to identify the subject and perhaps prove authentication and = authorization. >>=20 >> I do not assume that the client that interacts with the AS to make a = request and receive a token is the same as the client that will present = the token to the RS. In the US HIPAA use-case, for example, the root of = trust is a contract between the patient-subject and the = doctor-requesting party but the doctor workflow is expected to delegate = the token to some other end-user that may be using a totally different = client such as an EHR. >>=20 >=20 > If the client that gets the token is not same as the client that uses = the token, that is a violation of core security principles as it allows = for (and really designs for) impersonation by client software. I would = have no reason to trust client software that would hand its credentials = over to another piece of software, and in fact I shouldn=E2=80=99t trust = it.=20 >=20 > I think you may be conflating several different kinds of parties under = the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80=99s = entirely possible that one client might call an RS that in turn acts as = a client for something else down stream. But each of those hops is = different from the last. >=20 > =E2=80=94 Justin >=20 --Apple-Mail=_F5F49108-7A3D-49D1-BA14-7A53D55FFD33 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = still think the RS doesn=E2=80=99t do these things, the AS does. The AS = is the component of the =E2=80=9CAPI Provider=E2=80=99 (in your use case = model) that handles the authorizations. The RS just fulfills them. They = are part of the same trust boundary.

     =E2=80=94 Justin

    On Mar 17, 2021, at 7:18 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I'm sure you're right. Our vague = terminology around client and end-user leads to my = confusion. If GNAP is primarily about delegation then, of course, = we should avoid any incentives to impersonate or we're wasting our = time. This is partly why I'm trying to study up on capabilities and = asking for expert advice from folks like Alan Karp and Mark Miller = (cc'd)

    As best I can = understand it, the RS has only two choices, it can:
    • store an attribute of the RO a = [DID, email address, GNAP AS URL], or
    • hand the RO a = capability as a sort-of promise and avoid making any entries in an ACL = or equivalent.
    When a token comes back to the = RS, it will either be:
    • validated according to something associated with the stored = RO attribute, or
    • signed by the RS = itself.
    Either way, trust in the client seems = moot.

    Adrian



    On Wed, Mar = 17, 2021 at 5:29 PM Justin Richer <jricher@mit.edu> wrote:
    On = Mar 17, 2021, at 4:55 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    On = Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <tobias.looker@mattr.global> wrote:
    <snip>
    > A client might not = have a DID but it could have a VC as a certificate of authenticity = linked to some audit mechanism.

    To me a VC would come under the = assertions umbrella (that is to say a VC could be one type of valid = assertion). The client may possess or been presented with a VC that it = could include in its request to the AS as a way to identify the subject = and perhaps prove authentication and = authorization.

    I do not assume that the client that = interacts with the AS to make a request and receive a token is the same = as the client that will present the token to the RS. In the US HIPAA = use-case, for example, the root of trust is a contract between the = patient-subject and the doctor-requesting party but the doctor workflow = is expected to delegate the token to some other end-user that may be = using a totally different client such as an EHR.


    If the client that gets the token is not same as the client = that uses the token, that is a violation of core security principles as = it allows for (and really designs for) impersonation by client software. = I would have no reason to trust client software that would hand its = credentials over to another piece of software, and in fact I shouldn=E2=80= =99t trust it. 

    I think you may be conflating several different kinds of = parties under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80= =99s entirely possible that one client might call an RS that in turn = acts as a client for something else down stream. But each of those hops = is different from the last.

     =E2=80=94 Justin


    = --Apple-Mail=_F5F49108-7A3D-49D1-BA14-7A53D55FFD33-- From nobody Wed Mar 17 16:56:49 2021 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 868DD3A1852 for ; Wed, 17 Mar 2021 16:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 SCaKyfCemcZ7 for ; Wed, 17 Mar 2021 16:56:46 -0700 (PDT) Received: from mail-vs1-f51.google.com (mail-vs1-f51.google.com [209.85.217.51]) (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 97AA53A182C for ; Wed, 17 Mar 2021 16:56:46 -0700 (PDT) Received: by mail-vs1-f51.google.com with SMTP id h25so571480vso.2 for ; Wed, 17 Mar 2021 16:56:46 -0700 (PDT) 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=bwdwg3udDEC+Bcv5cLdULhR3Vi/EAyq2MVyUnni+TuI=; b=HWcBDCqpPJG78t1peIC/LntwwpnCrOqGvuq/H+ztB4n3ug3tzs3l8ztHBnCGI+I4Im AScD74hvCt4jM6U5nDe1Y7zAi0layAhgXgKRALT0fJz96BgFFsH/kmJXOMe7eSGNbDmh 4MTBBQcz2KbfI0I4R+eWdX1wGcMHJ3SV+AWso8vFrfd81u71g6/I+wx7G71WFHJpo3vY QEZ366VNQ0fz31GygKeOFc4s4SSN7LxIeLZoQvX2xciSYDz/JIf65CMbr+Lc8JUhFmtV E6J6seoMUp64/1ERGo/4Tc9ppB8cPI9NmFBp5D7zzbg+5s9nc3Mbj70hnJeEe7AWHQre AGHw== X-Gm-Message-State: AOAM533E2W0DFpHT6SHNAtxf1IfaodysFjaXyE4+278HDw/ZXyq2zvRb aN7Cjt6aE/+DVtBcAz/ze/blSqJsohyTOLijHt7xt1Qude8= X-Google-Smtp-Source: ABdhPJxfrditZHJLEmtc7VFOFhAa84AuzoqHFcKKoBM7wVeR6O5GpMvcuYX7wz0q3D4L1Gmkl6Oc92rx+cnY16xz69w= X-Received: by 2002:a05:6102:222f:: with SMTP id d15mr5234271vsb.1.1616025405549; Wed, 17 Mar 2021 16:56:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Adrian Gropper Date: Wed, 17 Mar 2021 19:56:33 -0400 Message-ID: To: Justin Richer Cc: Tobias Looker , Fabien Imbault , GNAP Mailing List , Alan Karp , Mark Miller Content-Type: multipart/alternative; boundary="0000000000003ef10a05bdc43ca1" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 23:56:49 -0000 --0000000000003ef10a05bdc43ca1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That's the vagueness we're talking about. For me, the RS holds all the cards and can choose whether to hold them or pass them to some other actor. "Same trust boundary" just reinforces that mental model for me, it's a technicality that splits one actor into two pieces. If the RS does this it should be completely invisible to GNAP and I would call the whole thing RS anyway. The reason I advocate for GNAP in the SSI workgroups is exactly because SSI does not depend on "trust boundary" - which to me is another name for "federation". So, on the protocols side, I propose, in both the SSI and GNAP groups, that the AS be defined as the actor that has policies, requests, and capabilities in order to emit tokens. If there's a reason to treat this actor as a trust boundary around an RO + the user-agent or the RO + an AS, then I'm happy to state that explicitly. Adrian On Wed, Mar 17, 2021 at 7:36 PM Justin Richer wrote: > I still think the RS doesn=E2=80=99t do these things, the AS does. The AS= is the > component of the =E2=80=9CAPI Provider=E2=80=99 (in your use case model) = that handles the > authorizations. The RS just fulfills them. They are part of the same trus= t > boundary. > > =E2=80=94 Justin > > On Mar 17, 2021, at 7:18 PM, Adrian Gropper > wrote: > > I'm sure you're right. Our vague terminology around client and end-user > leads to my confusion. If GNAP is primarily about delegation then, of > course, we should avoid any incentives to impersonate or we're wasting ou= r > time. This is partly why I'm trying to study up on capabilities and askin= g > for expert advice from folks like Alan Karp and Mark Miller (cc'd) > > As best I can understand it, the RS has only two choices, it can: > > - store an attribute of the RO a [DID, email address, GNAP AS URL], or > - hand the RO a capability as a sort-of promise and avoid making any > entries in an ACL or equivalent. > > When a token comes back to the RS, it will either be: > > - validated according to something associated with the stored RO > attribute, or > - signed by the RS itself. > > Either way, trust in the client seems moot. > > Adrian > > > > On Wed, Mar 17, 2021 at 5:29 PM Justin Richer wrote: > >> On Mar 17, 2021, at 4:55 PM, Adrian Gropper >> wrote: >> >> >> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker >> wrote: >> >>> >>> > A client might not have a DID but it could have a VC as a certificate >>> of authenticity linked to some audit mechanism. >>> >>> To me a VC would come under the assertions umbrella (that is to say a V= C >>> could be one type of valid assertion). The client may possess or been >>> presented with a VC that it could include in its request to the AS as a= way >>> to identify the subject and perhaps prove authentication and authorizat= ion. >>> >> >> I do not assume that the client that interacts with the AS to make a >> request and receive a token is the same as the client that will present = the >> token to the RS. In the US HIPAA use-case, for example, the root of trus= t >> is a contract between the patient-subject and the doctor-requesting part= y >> but the doctor workflow is expected to delegate the token to some other >> end-user that may be using a totally different client such as an EHR. >> >> >> If the client that gets the token is not same as the client that uses th= e >> token, that is a violation of core security principles as it allows for >> (and really designs for) impersonation by client software. I would have = no >> reason to trust client software that would hand its credentials over to >> another piece of software, and in fact I shouldn=E2=80=99t trust it. >> >> I think you may be conflating several different kinds of parties under >> the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80=99s entirel= y possible that one client >> might call an RS that in turn acts as a client for something else down >> stream. But each of those hops is different from the last. >> >> =E2=80=94 Justin >> >> > --0000000000003ef10a05bdc43ca1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    That's the vagueness we're talking about. For me, = the RS holds all the cards and can choose whether to hold them or pass them= to some other actor. "Same trust boundary" just reinforces that = mental model for me, it's a technicality that splits one actor into two= pieces. If the RS does this it should be completely invisible to GNAP and = I would call the whole thing RS anyway.=C2=A0

    The reason= I advocate for GNAP in the SSI workgroups is exactly because SSI does not = depend on "trust boundary" - which to me is another name for &quo= t;federation".

    So, on the protocols side, I p= ropose, in both the SSI and GNAP groups, that the AS be defined as the acto= r that has policies, requests, and capabilities=C2=A0in order to emit token= s. If there's a reason to treat this actor as a trust boundary around a= n RO + the user-agent or the RO + an AS, then I'm happy to state that e= xplicitly.

    Adrian

    On Wed, Mar 17, 2021 at 7:3= 6 PM Justin Richer <jricher@mit.edu> wrote:
    I still think the RS doesn=E2=80=99t do these= things, the AS does. The AS is the component of the =E2=80=9CAPI Provider= =E2=80=99 (in your use case model) that handles the authorizations. The RS = just fulfills them. They are part of the same trust boundary.

    =C2=A0=E2=80=94 Justin

    I'm sure you're right. Our vague terminolog= y=C2=A0around client=C2=A0and=C2=A0end-user leads to my confusion. If GNAP = is primarily about delegation=C2=A0then, of course, we should=C2=A0avoid an= y incentives to impersonate or we're wasting our time. This is partly w= hy I'm trying to study up on capabilities and asking for expert advice = from folks like Alan Karp and Mark Miller (cc'd)

    As = best I can understand it, the RS has only two choices, it can:
  • store an attribute of the RO a [DID, email address, GNAP AS URL], or<= /li>
  • hand the RO a capability as a sort-of promise and avoid making any = entries in an ACL or equivalent.
    • When a token comes back to t= he RS, it will either be:
    • validated according to somethin= g associated with the stored RO attribute, or
    • signed by the RS = itself.
    Either way, trust in the client seems moot.

    Adrian



    On We= d, Mar 17, 2021 at 5:29 PM Justin Richer <jricher@mit.edu> wrote:
    On Ma= r 17, 2021, at 4:55 PM, Adrian Gropper <agropper@healthurl.com> wrote:
    <= blockquote type=3D"cite">
    On Wed,= Mar 17, 2021 at 4:23 PM Tobias Looker <tobias.looker@mattr.global> wrote:
    = <snip>
    > A client might not have a DID but it could have= a VC as a certificate of authenticity linked to some audit mechanism.

    To me a VC would come under the assertions umbrella (t= hat is to say a VC could be one type of valid assertion). The client may po= ssess or been presented with a VC that it could include in its request to t= he AS as a way to identify the subject and perhaps prove authentication and= authorization.

    I do not assume= that the client that interacts with the AS to make a request and receive a= token is the same as the client that will present the token to the RS. In = the US HIPAA use-case, for example, the root of trust is a contract between= the patient-subject and the doctor-requesting party but the doctor workflo= w is expected to delegate the token to some other end-user that may be usin= g a totally different client such as an EHR.


    If the client that gets the token is no= t same as the client that uses the token, that is a violation of core secur= ity principles as it allows for (and really designs for) impersonation by c= lient software. I would have no reason to trust client software that would = hand its credentials over to another piece of software, and in fact I shoul= dn=E2=80=99t trust it.=C2=A0

    I think you may be co= nflating several different kinds of parties under the =E2=80=9Cclient=E2=80= =9D umbrella here, though. It=E2=80=99s entirely possible that one client m= ight call an RS that in turn acts as a client for something else down strea= m. But each of those hops is different from the last.

    <= div>=C2=A0=E2=80=94 Justin


    --0000000000003ef10a05bdc43ca1-- From nobody Wed Mar 17 19:20:09 2021 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 6950D3A1BB7 for ; Wed, 17 Mar 2021 19:20:08 -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 q2qMyuTmr4J6 for ; Wed, 17 Mar 2021 19:20:06 -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 AC64A3A1BB6 for ; Wed, 17 Mar 2021 19:20:06 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id n21so697964ioa.7 for ; Wed, 17 Mar 2021 19:20: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=8zseAnM35XJj0Ej21HmH0Xy2ybV/G9HDkpobHYHX2hA=; b=FfNPoTaUma0E/PVIsvCLuXbnH92JeAKJY/YqGhiMWutT+LDy2kKV9EatXdos7goOin PnY4EzMBOXKcc6tE9K/1zjhyXrYNBJSEoMComFhk7nUEYTQIox+vDy/GSaiYo+Wfuvjl i17XvmEpy999EfeWSZ4cLXYLKz3KwNsucXyOHqzB4IgkJmdIAbCHDyTHy9/TCcUwS/SC +h584Bjq1o7d5FAdW2viOIagZ3xMU2rZA2zDycLxk7q54HaOI7Qqyr54le/gRHnI4T8m zrnxTLPAcGKCrrQ96FwRSX6G7uyRv6FzgvQmZAscGa54n1lYlJ8FbMV5gu7NE988ViEN Wk6A== 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=8zseAnM35XJj0Ej21HmH0Xy2ybV/G9HDkpobHYHX2hA=; b=hqMajs0QHjxONunEcaPwDvaSOipxpjRt3pM3W48l7N1uJXL7R+6FrH4OH1t/8mTMYM gZKdEB8aPyYzI3m0HRs5wLHuu0Kekc7xzxWGEUCJOae8TMNMwVmDKc1p9VP9csGaVhmI 1zCBRhteY0R1U2SpAUonkc5s17UpR+Nvuz+TbdSBiDbGbn18aqBlRSmWazIJ6qNehBEr yb/sTQ0EQn80aJancDkKwF9sKau3fh4GyaQdT3NiDZW04H4gAcnWIMzCo0hzG5cYKw2i HGESLXAuQ0tP441VhH15vwRp8LNVYWtRE8H3zjc+SGubPse8GpZE34DCKlcqh0SNgeJU jSOg== X-Gm-Message-State: AOAM530nHbLXCe545qyVe3g6COTDa1fv9O3862GHuH37wl8JKGrYDOdp e7ZxEmIpVFodZpvo3x5CX1339ny1y/zcAPJ/o7Q= X-Google-Smtp-Source: ABdhPJyWnIn20NJ0glcWVunub8I1IW8pGP5v1F99mXG5OjvkEyjQc2s7m4BgKtezj1njb7qfkKt0AFgYMPA5IyVL2b4= X-Received: by 2002:a02:c6b4:: with SMTP id o20mr5286072jan.124.1616034004034; Wed, 17 Mar 2021 19:20:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Thu, 18 Mar 2021 03:19:50 +0100 Message-ID: To: Adrian Gropper Cc: Justin Richer , Tobias Looker , GNAP Mailing List , Alan Karp , Mark Miller Content-Type: multipart/alternative; boundary="000000000000c1699105bdc63c98" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 02:20:08 -0000 --000000000000c1699105bdc63c98 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Adrian I'm still confused why you're saying the terminology is vague. I get the "power" neutrality is not to your liking, but RQ / user agent is no better in my view. Can you elaborate? Fabien Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper = a =C3=A9crit : > I'm sure you're right. Our vague terminology around client and end-user > leads to my confusion. If GNAP is primarily about delegation then, of > course, we should avoid any incentives to impersonate or we're wasting ou= r > time. This is partly why I'm trying to study up on capabilities and askin= g > for expert advice from folks like Alan Karp and Mark Miller (cc'd) > > As best I can understand it, the RS has only two choices, it can: > > - store an attribute of the RO a [DID, email address, GNAP AS URL], or > - hand the RO a capability as a sort-of promise and avoid making any > entries in an ACL or equivalent. > > When a token comes back to the RS, it will either be: > > - validated according to something associated with the stored RO > attribute, or > - signed by the RS itself. > > Either way, trust in the client seems moot. > > Adrian > > > > On Wed, Mar 17, 2021 at 5:29 PM Justin Richer wrote: > >> On Mar 17, 2021, at 4:55 PM, Adrian Gropper >> wrote: >> >> >> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker >> wrote: >> >>> >>> > A client might not have a DID but it could have a VC as a certificate >>> of authenticity linked to some audit mechanism. >>> >>> To me a VC would come under the assertions umbrella (that is to say a V= C >>> could be one type of valid assertion). The client may possess or been >>> presented with a VC that it could include in its request to the AS as a= way >>> to identify the subject and perhaps prove authentication and authorizat= ion. >>> >> >> I do not assume that the client that interacts with the AS to make a >> request and receive a token is the same as the client that will present = the >> token to the RS. In the US HIPAA use-case, for example, the root of trus= t >> is a contract between the patient-subject and the doctor-requesting part= y >> but the doctor workflow is expected to delegate the token to some other >> end-user that may be using a totally different client such as an EHR. >> >> >> If the client that gets the token is not same as the client that uses th= e >> token, that is a violation of core security principles as it allows for >> (and really designs for) impersonation by client software. I would have = no >> reason to trust client software that would hand its credentials over to >> another piece of software, and in fact I shouldn=E2=80=99t trust it. >> >> I think you may be conflating several different kinds of parties under >> the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80=99s entirel= y possible that one client >> might call an RS that in turn acts as a client for something else down >> stream. But each of those hops is different from the last. >> >> =E2=80=94 Justin >> >> --000000000000c1699105bdc63c98 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Adrian

    I&= #39;m still confused why you're saying the terminology is vague.=C2=A0<= /div>
    I get the "power" neutrality is not to you= r liking, but RQ / user agent is no better in my view.=C2=A0

    Can you elaborate?=C2=A0

    Fabien=C2=A0

    Le jeu. 18 mars 20= 21 =C3=A0 00:18, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    I'm sure you're right. Our vagu= e terminology=C2=A0around client=C2=A0and=C2=A0end-user leads to my confusi= on. If GNAP is primarily about delegation=C2=A0then, of course, we should= =C2=A0avoid any incentives to impersonate or we're wasting our time. Th= is is partly why I'm trying to study up on capabilities and asking for = expert advice from folks like Alan Karp and Mark Miller (cc'd)

    =
    As best I can understand it, the RS has only two choices, it can= :
    • store an attribute of the RO a [DID, email address, GNA= P AS URL], or
    • hand the RO a capability as a sort-of promise and avo= id making any entries in an ACL or equivalent.
    When a token c= omes back to the RS, it will either be:
    • validated accordi= ng to something associated with the stored RO attribute, or
    • sig= ned by the RS itself.
    Either way, trust in the client seems m= oot.

    Adrian



    On Wed, Mar 17, 2021 at 5:29 PM Justin Richer <jricher@mit.edu= > wrote:
    On Mar 17, 2021, at 4:55 PM, Adrian Gropper <= ;agropper@healthurl.com> wrote:

    On Wed, Mar 17, 2021 at 4:23 P= M Tobias Looker <tobias.looker@mattr.global> wrote:
    <s= nip>
    > A client might not have a DID but it could have a VC= as a certificate of authenticity linked to some audit mechanism.

    To me a VC would come under the assertions umbrella (that i= s to say a VC could be one type of valid assertion). The client may possess= or been presented with a VC that it could include in its request to the AS= as a way to identify the subject and perhaps prove authentication and auth= orization.

    I do not assume that= the client that interacts with the AS to make a request and receive a toke= n is the same as the client that will present the token to the RS. In the U= S HIPAA use-case, for example, the root of trust is a contract between the = patient-subject and the doctor-requesting party but the doctor workflow is = expected to delegate the token to some other end-user that may be using a t= otally different client such as an EHR.


    If the client that gets the token is not sam= e as the client that uses the token, that is a violation of core security p= rinciples as it allows for (and really designs for) impersonation by client= software. I would have no reason to trust client software that would hand = its credentials over to another piece of software, and in fact I shouldn=E2= =80=99t trust it.=C2=A0

    I think you may be conflat= ing several different kinds of parties under the =E2=80=9Cclient=E2=80=9D u= mbrella here, though. It=E2=80=99s entirely possible that one client might = call an RS that in turn acts as a client for something else down stream. Bu= t each of those hops is different from the last.

    = =C2=A0=E2=80=94 Justin

    --000000000000c1699105bdc63c98-- From nobody Wed Mar 17 20:29:59 2021 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 2BE6F3A1D76 for ; Wed, 17 Mar 2021 20:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 GNs_7JCgGYdn for ; Wed, 17 Mar 2021 20:29:55 -0700 (PDT) Received: from mail-vs1-f51.google.com (mail-vs1-f51.google.com [209.85.217.51]) (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 5C5B53A1D5C for ; Wed, 17 Mar 2021 20:29:55 -0700 (PDT) Received: by mail-vs1-f51.google.com with SMTP id k14so779142vsb.6 for ; Wed, 17 Mar 2021 20:29:55 -0700 (PDT) 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=iRnWdDo2dGGXpcnXioQ3WXyKK6SbUlFY0ax3CHUVdv0=; b=Z7mWVqJ4tOAPZwvX9BV1BDNkgHV5xFYvxWBk/OwKXXIfYOayN9jJgwM5U9t8IGU3pB PhSP4572DnVecIu9dlSCFQPDj5FjMeJjMXi7s0g9NvK2j+f+j5hw3F9wo/z2oINQD65S K4na7RWbGCohwd6VuVoBUCdpBR1jKQSmQWJv85dZAWmZA8lZqtxwEXp8NAZH1SiqBiqD keICy2PvoTFYD7ldbSJb4slmYwMxhuW7qsFZapFQSKDJYLB1KCj7MDljSETEL3rXXSfn 2xSdSBeA6wlkv2EODFVcJpLkPa8SisqmsRgwI2OikLL8Ybjn6XaXkSmCpjBTlqvnIv2r dy5w== X-Gm-Message-State: AOAM533OjnK08RWot9IEHb9Vbc6x+pHT0bbtPGJBBLAdCZbFxOuS+dZ3 P4Mzbts3yKk81sF8bMK6WILlLxAbdTa0ogfde1w= X-Google-Smtp-Source: ABdhPJxPMs06/u4df2WCTa6tBSfQnfua6KUFMl5oX7pda0TSuingTpJaRlyMJb8oina6MkI0T6MquKYUEpuRnuown78= X-Received: by 2002:a67:db84:: with SMTP id f4mr5558546vsk.20.1616038194354; Wed, 17 Mar 2021 20:29:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Adrian Gropper Date: Wed, 17 Mar 2021 23:29:42 -0400 Message-ID: To: Fabien Imbault Cc: Justin Richer , Tobias Looker , GNAP Mailing List , Alan Karp , Mark Miller Content-Type: multipart/alternative; boundary="000000000000849d1605bdc736e7" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 03:29:57 -0000 --000000000000849d1605bdc736e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable At various points in the lifecycle of the protected resource the client at the resource server (RS) might be: - The RO (subject) user agent trading payment for a service promise - The RO user agent using the promise to access the protected resource - A delegate of the RO user agent using a different client What's vague is where the GNAP AS enters the picture as described above. How would you describe it? Adrian On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault wrote: > Hi Adrian > > I'm still confused why you're saying the terminology is vague. > I get the "power" neutrality is not to your liking, but RQ / user agent i= s > no better in my view. > > Can you elaborate? > > Fabien > > Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper a > =C3=A9crit : > >> I'm sure you're right. Our vague terminology around client and end-user >> leads to my confusion. If GNAP is primarily about delegation then, of >> course, we should avoid any incentives to impersonate or we're wasting o= ur >> time. This is partly why I'm trying to study up on capabilities and aski= ng >> for expert advice from folks like Alan Karp and Mark Miller (cc'd) >> >> As best I can understand it, the RS has only two choices, it can: >> >> - store an attribute of the RO a [DID, email address, GNAP AS URL], o= r >> - hand the RO a capability as a sort-of promise and avoid making any >> entries in an ACL or equivalent. >> >> When a token comes back to the RS, it will either be: >> >> - validated according to something associated with the stored RO >> attribute, or >> - signed by the RS itself. >> >> Either way, trust in the client seems moot. >> >> Adrian >> >> >> >> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer wrote: >> >>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper >>> wrote: >>> >>> >>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker < >>> tobias.looker@mattr.global> wrote: >>> >>>> >>>> > A client might not have a DID but it could have a VC as a certificat= e >>>> of authenticity linked to some audit mechanism. >>>> >>>> To me a VC would come under the assertions umbrella (that is to say a >>>> VC could be one type of valid assertion). The client may possess or be= en >>>> presented with a VC that it could include in its request to the AS as = a way >>>> to identify the subject and perhaps prove authentication and authoriza= tion. >>>> >>> >>> I do not assume that the client that interacts with the AS to make a >>> request and receive a token is the same as the client that will present= the >>> token to the RS. In the US HIPAA use-case, for example, the root of tru= st >>> is a contract between the patient-subject and the doctor-requesting par= ty >>> but the doctor workflow is expected to delegate the token to some other >>> end-user that may be using a totally different client such as an EHR. >>> >>> >>> If the client that gets the token is not same as the client that uses >>> the token, that is a violation of core security principles as it allows= for >>> (and really designs for) impersonation by client software. I would have= no >>> reason to trust client software that would hand its credentials over to >>> another piece of software, and in fact I shouldn=E2=80=99t trust it. >>> >>> I think you may be conflating several different kinds of parties under >>> the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80=99s entire= ly possible that one client >>> might call an RS that in turn acts as a client for something else down >>> stream. But each of those hops is different from the last. >>> >>> =E2=80=94 Justin >>> >>> --000000000000849d1605bdc736e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    At various points in the lifecycle=C2=A0of the protected r= esource the client at the resource server (RS) might be:
    • The RO= (subject) user agent trading payment for a service promise
    • The RO = user agent using the promise to access the protected resource
    • A del= egate of the RO user agent using a different client
    What'= s vague is where the GNAP AS enters the picture as described above. How wou= ld you describe it?

    Adrian


    On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Adrian

    I'm still confused why you're saying the terminology i= s vague.=C2=A0
    I get the "power" neutralit= y is not to your liking, but RQ / user agent is no better in my view.=C2=A0=

    Can you elaborate?=C2= =A0

    Fabien=C2=A0

    Le= jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper <agropper@healthurl.com> a =C3= =A9crit=C2=A0:
    I'm sure you&= #39;re right. Our vague terminology=C2=A0around client=C2=A0and=C2=A0end-us= er leads to my confusion. If GNAP is primarily about delegation=C2=A0then, = of course, we should=C2=A0avoid any incentives to impersonate or we're = wasting our time. This is partly why I'm trying to study up on capabili= ties and asking for expert advice from folks like Alan Karp and Mark Miller= (cc'd)

    As best I can understand it, the RS has only= two choices, it can:
    • store an attribute of the RO a [DID= , email address, GNAP AS URL], or
    • hand the RO a capability as a sor= t-of promise and avoid making any entries in an ACL or equivalent.
      • When a token comes back to the RS, it will either be:
        <= li>validated according to something associated with the stored RO attribute= , or
      • signed by the RS itself.
      Either way, trust i= n the client seems moot.

      Adrian


    On Wed, Mar 17, 2021 at 5:29 PM Justin Richer= <jricher@mit.edu> wrote:
    On Mar 17, 2021, at 4:55 P= M, Adrian Gropper <agropper@healthurl.com> wrote:

    On Wed, M= ar 17, 2021 at 4:23 PM Tobias Looker <tobias.looker@mattr.global= > wrote:
    <snip>
    > A client might not have a DID b= ut it could have a VC as a certificate of authenticity linked to some audit= mechanism.

    To me a VC would come under the assert= ions umbrella (that is to say a VC could be one type of valid assertion). T= he client may possess or been presented with a VC that it could include in = its request to the AS as a way to identify the subject and perhaps prove au= thentication and authorization.

    I do not assume that the client that interacts with the AS to make a reque= st and receive a token is the same as the client that will present the toke= n to the RS. In the US HIPAA use-case, for example, the root of trust is a = contract between the patient-subject and the doctor-requesting party but th= e doctor workflow is expected to delegate the token to some other end-user = that may be using a totally different client such as an EHR.

    =

    If the client that gets= the token is not same as the client that uses the token, that is a violati= on of core security principles as it allows for (and really designs for) im= personation by client software. I would have no reason to trust client soft= ware that would hand its credentials over to another piece of software, and= in fact I shouldn=E2=80=99t trust it.=C2=A0

    I thi= nk you may be conflating several different kinds of parties under the =E2= =80=9Cclient=E2=80=9D umbrella here, though. It=E2=80=99s entirely possible= that one client might call an RS that in turn acts as a client for somethi= ng else down stream. But each of those hops is different from the last.

    =C2=A0=E2=80=94 Justin

    --000000000000849d1605bdc736e7-- From nobody Wed Mar 17 20:43:25 2021 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 D4D4C3A1ECF for ; Wed, 17 Mar 2021 20:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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, T_SPF_TEMPERROR=0.01, 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 7nMNN3ZE-D2m for ; Wed, 17 Mar 2021 20:43:18 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 0A2143A1ECE for ; Wed, 17 Mar 2021 20:43:18 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id z9so3574012ilb.4 for ; Wed, 17 Mar 2021 20:43:17 -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=KYfOR6JKb6UMHQSemsXZiANVzLILDudAC/Bbs7OSYfE=; b=NPGPoNZ90mAMkjY9OUAC3jqUpIdi3OIa8XwNDmDplwpBMU9lDV0atlo3GAhjifKT/P LQLrSQ8AXiE9Mgb92tB7lwjU3fxO87MzGs9LjzpWNiZfRq/AmHXX87PqkTRApZr+4Ihv nDzJNyqF6WptXXZCVs7Tbj8tuC7BR00UqzughA6yI0hNNOdm5r2qYkvgNmkH0C2Typ9n 9CrtyfbiB4OMBLx18uFQZ4dkSYBc1lvRS29tlRJmM+q9UpneNovJcs7n7yrETIsZnJRF V95Q82FQoXHGi4lJCqrAPCKPX69ltMziHgHpVPzp7NLBr+lxZb4OIt8aDlw74HWSmyVF jEew== 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=KYfOR6JKb6UMHQSemsXZiANVzLILDudAC/Bbs7OSYfE=; b=PKlJGpYgYu7zaYfkNHDgOQClxCZTNOZSAijyM+7CrKCYAift5h2GBqVO4ZBc7cZP+g 2vhXMH6CLRy35VfLm63h2ykpYElgAk9n8/nrtho3CQM9q+cvY/mEuB9clXgMLqpcaGGJ Nfn3RRUKk5HhA+gRhAASizJfP8My/TbnV6DRy2qHEBrfjtim/3QIU8ExaPl9eYpKKdHO fGLPT5om2Hn3y8o+W0EufOj4/ytdEOwXy/NJtjDg2Atk+xgEA0hp7bsG3B5zxVTiuOwN ar1N5OokeyGCXn1Gn16/vMZFQxQLFEKaxjcqIw5g3YdlVK79qq4d3RWaGuImPdxXoSVl 2SZQ== X-Gm-Message-State: AOAM533fgWb9/X2Sn5134G6EhWzJBZWEkBQO3niUl44eqbSScYzoMAGp wDEvUOTwrRIv74nTzg5NXAmypZSngkBcE856bsA= X-Google-Smtp-Source: ABdhPJwXlHeCjEOw9G7DelijeGf2iRYeQ7oy9rWBltAKj84aAtbPOL4W58CvpsSvn6S8UjsAda56f/AfIlUTUXuxED0= X-Received: by 2002:a92:1a11:: with SMTP id a17mr10496959ila.188.1616038996449; Wed, 17 Mar 2021 20:43:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Thu, 18 Mar 2021 04:43:03 +0100 Message-ID: To: Adrian Gropper Cc: Justin Richer , Tobias Looker , GNAP Mailing List , Alan Karp , Mark Miller Content-Type: multipart/alternative; boundary="000000000000539d5205bdc766c2" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 03:43:23 -0000 --000000000000539d5205bdc766c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for that. Trying to reframe it: GNAP is defined as a delegation protocol so the main intent is related to a delegate of the RO (i.e. the end user) that wishes to access the RO's protected resources, through the client. Fabien Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper = a =C3=A9crit : > At various points in the lifecycle of the protected resource the client a= t > the resource server (RS) might be: > > - The RO (subject) user agent trading payment for a service promise > - The RO user agent using the promise to access the protected resource > - A delegate of the RO user agent using a different client > > What's vague is where the GNAP AS enters the picture as described above. > How would you describe it? > > Adrian > > > On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault > wrote: > >> Hi Adrian >> >> I'm still confused why you're saying the terminology is vague. >> I get the "power" neutrality is not to your liking, but RQ / user agent >> is no better in my view. >> >> Can you elaborate? >> >> Fabien >> >> Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper a >> =C3=A9crit : >> >>> I'm sure you're right. Our vague terminology around client and end-user >>> leads to my confusion. If GNAP is primarily about delegation then, of >>> course, we should avoid any incentives to impersonate or we're wasting = our >>> time. This is partly why I'm trying to study up on capabilities and ask= ing >>> for expert advice from folks like Alan Karp and Mark Miller (cc'd) >>> >>> As best I can understand it, the RS has only two choices, it can: >>> >>> - store an attribute of the RO a [DID, email address, GNAP AS URL], >>> or >>> - hand the RO a capability as a sort-of promise and avoid making any >>> entries in an ACL or equivalent. >>> >>> When a token comes back to the RS, it will either be: >>> >>> - validated according to something associated with the stored RO >>> attribute, or >>> - signed by the RS itself. >>> >>> Either way, trust in the client seems moot. >>> >>> Adrian >>> >>> >>> >>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer wrote: >>> >>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper >>>> wrote: >>>> >>>> >>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker < >>>> tobias.looker@mattr.global> wrote: >>>> >>>>> >>>>> > A client might not have a DID but it could have a VC as a >>>>> certificate of authenticity linked to some audit mechanism. >>>>> >>>>> To me a VC would come under the assertions umbrella (that is to say a >>>>> VC could be one type of valid assertion). The client may possess or b= een >>>>> presented with a VC that it could include in its request to the AS as= a way >>>>> to identify the subject and perhaps prove authentication and authoriz= ation. >>>>> >>>> >>>> I do not assume that the client that interacts with the AS to make a >>>> request and receive a token is the same as the client that will presen= t the >>>> token to the RS. In the US HIPAA use-case, for example, the root of tr= ust >>>> is a contract between the patient-subject and the doctor-requesting pa= rty >>>> but the doctor workflow is expected to delegate the token to some othe= r >>>> end-user that may be using a totally different client such as an EHR. >>>> >>>> >>>> If the client that gets the token is not same as the client that uses >>>> the token, that is a violation of core security principles as it allow= s for >>>> (and really designs for) impersonation by client software. I would hav= e no >>>> reason to trust client software that would hand its credentials over t= o >>>> another piece of software, and in fact I shouldn=E2=80=99t trust it. >>>> >>>> I think you may be conflating several different kinds of parties under >>>> the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80=99s entir= ely possible that one client >>>> might call an RS that in turn acts as a client for something else down >>>> stream. But each of those hops is different from the last. >>>> >>>> =E2=80=94 Justin >>>> >>>> --000000000000539d5205bdc766c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Thanks for that.=C2=A0

    Trying to reframe it:
    GNAP is = defined as a delegation protocol so the main intent is related to a delegat= e of the RO (i.e. the end user) that wishes to access the RO's protecte= d resources, through the client.=C2=A0

    Fabien=C2= =A0

    Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper <agropper@healthurl.com> a =C3= =A9crit=C2=A0:
    At = various points in the lifecycle=C2=A0of the protected resource the client a= t the resource server (RS) might be:
    • The RO (subject) user agen= t trading payment for a service promise
    • The RO user agent using the= promise to access the protected resource
    • A delegate of the RO user= agent using a different client
    What's vague is where the= GNAP AS enters the picture as described above. How would you describe it?<= /div>

    Adrian


    On Wed, Mar 17, 2= 021 at 10:20 PM Fabien Imbault <fabien.imbault@gmail.com> w= rote:
    Hi Adrian

    I'm still confused why you're saying = the terminology is vague.=C2=A0
    I get the "powe= r" neutrality is not to your liking, but RQ / user agent is no better = in my view.=C2=A0

    Can yo= u elaborate?=C2=A0

    Fabie= n=C2=A0

    Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper <agr= opper@healthurl.com> a =C3=A9crit=C2=A0:
    =
    I'm sure you're right. Our vague terminology=C2=A0= around client=C2=A0and=C2=A0end-user leads to my confusion. If GNAP is prim= arily about delegation=C2=A0then, of course, we should=C2=A0avoid any incen= tives to impersonate or we're wasting our time. This is partly why I= 9;m trying to study up on capabilities and asking for expert advice from fo= lks like Alan Karp and Mark Miller (cc'd)

    As best I = can understand it, the RS has only two choices, it can:
    • s= tore an attribute of the RO a [DID, email address, GNAP AS URL], or
      • hand the RO a capability as a sort-of promise and avoid making any entries= in an ACL or equivalent.
    When a token comes back to the RS, = it will either be:
    • validated according to something assoc= iated with the stored RO attribute, or
    • signed by the RS itself.=
    Either way, trust in the client seems moot.

    Adrian



    On Wed, Mar = 17, 2021 at 5:29 PM Justin Richer <jricher@mit.edu> wrote= :
    On Mar 17, 2021, at 4:55 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    On Wed, Mar 17, 2021 at 4:2= 3 PM Tobias Looker <tobias.looker@mattr.global>= ; wrote:
    <snip>
    > A client might not have a DID but it c= ould have a VC as a certificate of authenticity linked to some audit mechan= ism.

    To me a VC would come under the assertions um= brella (that is to say a VC could be one type of valid assertion). The clie= nt may possess or been presented with a VC that it could include in its req= uest to the AS as a way to identify the subject and perhaps prove authentic= ation and authorization.

    I do n= ot assume that the client that interacts with the AS to make a request and = receive a token is the same as the client that will present the token to th= e RS. In the US HIPAA use-case, for example, the root of trust is a contrac= t between the patient-subject and the doctor-requesting party but the docto= r workflow is expected to delegate the token to some other end-user that ma= y be using a totally different client such as an EHR.

    <= /div>

    If the client that gets the to= ken is not same as the client that uses the token, that is a violation of c= ore security principles as it allows for (and really designs for) impersona= tion by client software. I would have no reason to trust client software th= at would hand its credentials over to another piece of software, and in fac= t I shouldn=E2=80=99t trust it.=C2=A0

    I think you = may be conflating several different kinds of parties under the =E2=80=9Ccli= ent=E2=80=9D umbrella here, though. It=E2=80=99s entirely possible that one= client might call an RS that in turn acts as a client for something else d= own stream. But each of those hops is different from the last.
    =C2=A0=E2=80=94 Justin

    --000000000000539d5205bdc766c2-- From nobody Wed Mar 17 20:54:19 2021 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 A4FE83A1F1A for ; Wed, 17 Mar 2021 20:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 cQ-SQGNlPMgo for ; Wed, 17 Mar 2021 20:54:14 -0700 (PDT) Received: from mail-ua1-f42.google.com (mail-ua1-f42.google.com [209.85.222.42]) (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 8C4A63A1F19 for ; Wed, 17 Mar 2021 20:54:14 -0700 (PDT) Received: by mail-ua1-f42.google.com with SMTP id x8so1489482ual.6 for ; Wed, 17 Mar 2021 20:54:14 -0700 (PDT) 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=aMfJC96rl3trHAJU8Tp8BlILki37jmpAUrEVp61zcNE=; b=tFOE8ntKs1QdDZnXxuRutvWkM8HfAggXYC18TKqOjVY1sVAqmG+AYmh6MzZq8ppfwS asjtvm4c2I7/1T4RcRjpvKPOqbKJtJH94+PR4R9jzjBC+8Y8A7o4haAOkZOsVxGRcRas koNlVcjRn9v27OTfId65cln1ZwmI78Z4yx8nX10DtNdgRzgxwFn7oLyKYAnN0USDXdlM bNg2AwbKbHOlpREOLsoKuFNvBgKkIl9IrUXM/HZCPa65iRJWCrS3jipjcTq3mAq7SFsP f3OJJWF4GeOWkoZFBapT6M37bR0t5Tg3RRZYejM4DPa4slaxTgB3uw+aS+vcTSpbKNTJ T+Yw== X-Gm-Message-State: AOAM530iI4xaQVhVR/GLMKX4JOmh78+S7g63WS539N0jtMQlykwu+NrV 5MYU5XcBXwa1EdwY0XlnFcrzPI9tri0HjmevqCs= X-Google-Smtp-Source: ABdhPJwgp+KJDQzXa67iN1B6t6HD5ZvCWHEhTSWkkkyK7kM4S8u8cJ9hlL6I2rUEYRaooQ/yR8ixFm5duMC2ExMCpOg= X-Received: by 2002:a9f:280a:: with SMTP id c10mr1308265uac.7.1616039653502; Wed, 17 Mar 2021 20:54:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Adrian Gropper Date: Wed, 17 Mar 2021 23:54:02 -0400 Message-ID: To: Fabien Imbault Cc: Justin Richer , Tobias Looker , GNAP Mailing List , Alan Karp , Mark Miller Content-Type: multipart/alternative; boundary="0000000000007d785c05bdc78d1c" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 03:54:17 -0000 --0000000000007d785c05bdc78d1c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sure! Is there an AS involved in the delegation? How and where in the lifecycle of the protected resource? Also your use of "the client" seems to imply that either there is only one client or the client doesn't matter. Which is it? Adrian On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault wrote: > Thanks for that. > > Trying to reframe it: > GNAP is defined as a delegation protocol so the main intent is related to > a delegate of the RO (i.e. the end user) that wishes to access the RO's > protected resources, through the client. > > Fabien > > Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper a > =C3=A9crit : > >> At various points in the lifecycle of the protected resource the client >> at the resource server (RS) might be: >> >> - The RO (subject) user agent trading payment for a service promise >> - The RO user agent using the promise to access the protected resourc= e >> - A delegate of the RO user agent using a different client >> >> What's vague is where the GNAP AS enters the picture as described above. >> How would you describe it? >> >> Adrian >> >> >> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault >> wrote: >> >>> Hi Adrian >>> >>> I'm still confused why you're saying the terminology is vague. >>> I get the "power" neutrality is not to your liking, but RQ / user agent >>> is no better in my view. >>> >>> Can you elaborate? >>> >>> Fabien >>> >>> Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper a >>> =C3=A9crit : >>> >>>> I'm sure you're right. Our vague terminology around client and end-use= r >>>> leads to my confusion. If GNAP is primarily about delegation then, of >>>> course, we should avoid any incentives to impersonate or we're wasting= our >>>> time. This is partly why I'm trying to study up on capabilities and as= king >>>> for expert advice from folks like Alan Karp and Mark Miller (cc'd) >>>> >>>> As best I can understand it, the RS has only two choices, it can: >>>> >>>> - store an attribute of the RO a [DID, email address, GNAP AS URL], >>>> or >>>> - hand the RO a capability as a sort-of promise and avoid making >>>> any entries in an ACL or equivalent. >>>> >>>> When a token comes back to the RS, it will either be: >>>> >>>> - validated according to something associated with the stored RO >>>> attribute, or >>>> - signed by the RS itself. >>>> >>>> Either way, trust in the client seems moot. >>>> >>>> Adrian >>>> >>>> >>>> >>>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer wrote: >>>> >>>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper >>>>> wrote: >>>>> >>>>> >>>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker < >>>>> tobias.looker@mattr.global> wrote: >>>>> >>>>>> >>>>>> > A client might not have a DID but it could have a VC as a >>>>>> certificate of authenticity linked to some audit mechanism. >>>>>> >>>>>> To me a VC would come under the assertions umbrella (that is to say = a >>>>>> VC could be one type of valid assertion). The client may possess or = been >>>>>> presented with a VC that it could include in its request to the AS a= s a way >>>>>> to identify the subject and perhaps prove authentication and authori= zation. >>>>>> >>>>> >>>>> I do not assume that the client that interacts with the AS to make a >>>>> request and receive a token is the same as the client that will prese= nt the >>>>> token to the RS. In the US HIPAA use-case, for example, the root of t= rust >>>>> is a contract between the patient-subject and the doctor-requesting p= arty >>>>> but the doctor workflow is expected to delegate the token to some oth= er >>>>> end-user that may be using a totally different client such as an EHR. >>>>> >>>>> >>>>> If the client that gets the token is not same as the client that uses >>>>> the token, that is a violation of core security principles as it allo= ws for >>>>> (and really designs for) impersonation by client software. I would ha= ve no >>>>> reason to trust client software that would hand its credentials over = to >>>>> another piece of software, and in fact I shouldn=E2=80=99t trust it. >>>>> >>>>> I think you may be conflating several different kinds of parties unde= r >>>>> the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80=99s enti= rely possible that one client >>>>> might call an RS that in turn acts as a client for something else dow= n >>>>> stream. But each of those hops is different from the last. >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> --0000000000007d785c05bdc78d1c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Sure!=C2=A0

    Is there an AS involved in = the delegation? How and where in the lifecycle=C2=A0of the protected resour= ce?=C2=A0

    Also your use of "the client" seems = to imply that either there is only one client or the client doesn't mat= ter. Which is it?

    Adrian

    On Wed, Mar 17= , 2021 at 11:43 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    =
    Thanks for that.=C2=A0

    Trying to reframe it:
    GNAP is = defined as a delegation protocol so the main intent is related to a delegat= e of the RO (i.e. the end user) that wishes to access the RO's protecte= d resources, through the client.=C2=A0

    Fabien=C2= =A0

    Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper <agropper@healthurl.c= om> a =C3=A9crit=C2=A0:
    A= t various points in the lifecycle=C2=A0of the protected resource the client= at the resource server (RS) might be:
    • The RO (subject) user ag= ent trading payment for a service promise
    • The RO user agent using t= he promise to access the protected resource
    • A delegate of the RO us= er agent using a different client
    What's vague is where t= he GNAP AS enters the picture as described above. How would you describe it= ?

    Adrian


    On Wed, Mar 17,= 2021 at 10:20 PM Fabien Imbault <fabien.imbault@gmail.com>= wrote:
    Hi Adrian

    I'm still confused why you're sayin= g the terminology is vague.=C2=A0
    I get the "po= wer" neutrality is not to your liking, but RQ / user agent is no bette= r in my view.=C2=A0

    Can = you elaborate?=C2=A0

    Fab= ien=C2=A0

    Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper <a= gropper@healthurl.com> a =C3=A9crit=C2=A0:
    I'm sure you're right. Our vague terminology=C2= =A0around client=C2=A0and=C2=A0end-user leads to my confusion. If GNAP is p= rimarily about delegation=C2=A0then, of course, we should=C2=A0avoid any in= centives to impersonate or we're wasting our time. This is partly why I= 'm trying to study up on capabilities and asking for expert advice from= folks like Alan Karp and Mark Miller (cc'd)

    As best= I can understand it, the RS has only two choices, it can:
      store an attribute of the RO a [DID, email address, GNAP AS URL], or=
    • hand the RO a capability as a sort-of promise and avoid making any entr= ies in an ACL or equivalent.
    When a token comes back to the R= S, it will either be:
    • validated according to something as= sociated with the stored RO attribute, or
    • signed by the RS itse= lf.
    Either way, trust in the client seems moot.
    Adrian


    On Wed, M= ar 17, 2021 at 5:29 PM Justin Richer <jricher@mit.edu> wr= ote:
    On Mar 17, 2021, at 4:55 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    On Wed, Mar 17, 2021 at 4:= 23 PM Tobias Looker <tobias.looker@mattr.global= > wrote:
    <snip>
    > A client might not have a DID but= it could have a VC as a certificate of authenticity linked to some audit m= echanism.

    To me a VC would come under the assertio= ns umbrella (that is to say a VC could be one type of valid assertion). The= client may possess or been presented with a VC that it could include in it= s request to the AS as a way to identify the subject and perhaps prove auth= entication and authorization.

    I= do not assume that the client that interacts with the AS to make a request= and receive a token is the same as the client that will present the token = to the RS. In the US HIPAA use-case, for example, the root of trust is a co= ntract between the patient-subject and the doctor-requesting party but the = doctor workflow is expected to delegate the token to some other end-user th= at may be using a totally different client such as an EHR.


    If the client that gets t= he token is not same as the client that uses the token, that is a violation= of core security principles as it allows for (and really designs for) impe= rsonation by client software. I would have no reason to trust client softwa= re that would hand its credentials over to another piece of software, and i= n fact I shouldn=E2=80=99t trust it.=C2=A0

    I think= you may be conflating several different kinds of parties under the =E2=80= =9Cclient=E2=80=9D umbrella here, though. It=E2=80=99s entirely possible th= at one client might call an RS that in turn acts as a client for something = else down stream. But each of those hops is different from the last.
    <= div>
    =C2=A0=E2=80=94 Justin

    --0000000000007d785c05bdc78d1c-- From nobody Wed Mar 17 21:07:48 2021 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 DB7E83A1F55 for ; Wed, 17 Mar 2021 21:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 S1UIrkP927sr for ; Wed, 17 Mar 2021 21:07:45 -0700 (PDT) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 0A4373A1F53 for ; Wed, 17 Mar 2021 21:07:45 -0700 (PDT) Received: by mail-il1-x12f.google.com with SMTP id 19so3627913ilj.2 for ; Wed, 17 Mar 2021 21:07: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=fR62Wqqh7Cylnk6/kmyXxwspESKrPb47ejWKHcQjtts=; b=POaOMt8gvV6NhrU10GTBEM21Wm5LBS3gHisSjFcgjiW8J/m8PX9jbUvCSTeTEqVEB1 1aXG/JHw0SS/w7TD0HQu235QBIdDIlv+HxnUO0LpEvuk18CcDDjIA2XG19zWqZJqEvie I30LG9P7GJ3C7IbrQ6iBm3PL1QoWTYOIjL93BQ191WleSsVHKlZNLqQnDDaoWQykTNqq 2xnMFDpLpOp4IF9mr3S/ArJ5flF9fbOcrhHHrRzWwvZ/OCHoIqGHvV7oY0UWYFj7lne6 oIA7ETBbl3wlXBTimQNnZ90QpKkd4/qv+ZL7H+WyegVwP8epTu4RowkujAwhn05dURDK JZZA== 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=fR62Wqqh7Cylnk6/kmyXxwspESKrPb47ejWKHcQjtts=; b=SoBwAdkJ6MZKe5H/SLQ2+qzq5Qjl7hL5+Mx2XLWpnMvfWTaMgVBQebRuiGOyrFT8TQ rPG+8LBsGqc9TJKveOIQiTkGPrpWDE6sz3Ltz0c6uijfPrIS3RRd33r0dxUyOLCKb4ow bY/JCRw34Wk3OqFNl67ZJbigbHt6hC0A4gqF1McpqOfiyIYaZPSXazb9sS0WKDBv+uNA eIXHv4mCuQXs66N0PS4J+ZBPDE36KPK+ioCLqMgBWDSGrgZBRaXfvTVLViLa6Yrxg8xA XNt10f7ucJvP+QL8XgkGIutpBf7SutfrdYtRoxCzxrwxpz2FSSbbehClNa/cKEBbrO68 ABYw== X-Gm-Message-State: AOAM531bYJFSS8j1nrdJMspaoScY+1O1YfrlgNvRH26jyeNwGl49Odfx HJDeIDAXplfeXSpmmHCGmuKbciMxg9PDGGaO2P4= X-Google-Smtp-Source: ABdhPJwJLrPl0H99Jejb8tX6YpyCabl/+A90KjmsTrflD+Ub08KtAtdTY6rwSiOt+rwFaYZrKLKzt7Ya71yeLW1A7ZE= X-Received: by 2002:a92:d84f:: with SMTP id h15mr10353347ilq.178.1616040463103; Wed, 17 Mar 2021 21:07:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Thu, 18 Mar 2021 05:07:30 +0100 Message-ID: To: Adrian Gropper Cc: Justin Richer , Tobias Looker , GNAP Mailing List , Alan Karp , Mark Miller Content-Type: multipart/alternative; boundary="000000000000befcdc05bdc7bd06" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 04:07:47 -0000 --000000000000befcdc05bdc7bd06 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, the AS is the policy manager and the token issuer for that delegation, based on the knowledge it has of the RO. We don't assume much on the lifecycle of the protected resource, except that they expect a valid access token issued by the AS to provide access. We defined client instances related to one client software. The client does matter, we could even define its class or posture, but it's possible to make a request to the AS even if you're not pre registered. Fabien Le jeu. 18 mars 2021 =C3=A0 04:54, Adrian Gropper = a =C3=A9crit : > Sure! > > Is there an AS involved in the delegation? How and where in the > lifecycle of the protected resource? > > Also your use of "the client" seems to imply that either there is only on= e > client or the client doesn't matter. Which is it? > > Adrian > > On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault > wrote: > >> Thanks for that. >> >> Trying to reframe it: >> GNAP is defined as a delegation protocol so the main intent is related t= o >> a delegate of the RO (i.e. the end user) that wishes to access the RO's >> protected resources, through the client. >> >> Fabien >> >> Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper a >> =C3=A9crit : >> >>> At various points in the lifecycle of the protected resource the client >>> at the resource server (RS) might be: >>> >>> - The RO (subject) user agent trading payment for a service promise >>> - The RO user agent using the promise to access the protected >>> resource >>> - A delegate of the RO user agent using a different client >>> >>> What's vague is where the GNAP AS enters the picture as described above= . >>> How would you describe it? >>> >>> Adrian >>> >>> >>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault < >>> fabien.imbault@gmail.com> wrote: >>> >>>> Hi Adrian >>>> >>>> I'm still confused why you're saying the terminology is vague. >>>> I get the "power" neutrality is not to your liking, but RQ / user agen= t >>>> is no better in my view. >>>> >>>> Can you elaborate? >>>> >>>> Fabien >>>> >>>> Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper >>>> a =C3=A9crit : >>>> >>>>> I'm sure you're right. Our vague terminology around >>>>> client and end-user leads to my confusion. If GNAP is primarily about >>>>> delegation then, of course, we should avoid any incentives to imperso= nate >>>>> or we're wasting our time. This is partly why I'm trying to study up = on >>>>> capabilities and asking for expert advice from folks like Alan Karp a= nd >>>>> Mark Miller (cc'd) >>>>> >>>>> As best I can understand it, the RS has only two choices, it can: >>>>> >>>>> - store an attribute of the RO a [DID, email address, GNAP AS >>>>> URL], or >>>>> - hand the RO a capability as a sort-of promise and avoid making >>>>> any entries in an ACL or equivalent. >>>>> >>>>> When a token comes back to the RS, it will either be: >>>>> >>>>> - validated according to something associated with the stored RO >>>>> attribute, or >>>>> - signed by the RS itself. >>>>> >>>>> Either way, trust in the client seems moot. >>>>> >>>>> Adrian >>>>> >>>>> >>>>> >>>>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer wrote= : >>>>> >>>>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper >>>>>> wrote: >>>>>> >>>>>> >>>>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker < >>>>>> tobias.looker@mattr.global> wrote: >>>>>> >>>>>>> >>>>>>> > A client might not have a DID but it could have a VC as a >>>>>>> certificate of authenticity linked to some audit mechanism. >>>>>>> >>>>>>> To me a VC would come under the assertions umbrella (that is to say >>>>>>> a VC could be one type of valid assertion). The client may possess = or been >>>>>>> presented with a VC that it could include in its request to the AS = as a way >>>>>>> to identify the subject and perhaps prove authentication and author= ization. >>>>>>> >>>>>> >>>>>> I do not assume that the client that interacts with the AS to make a >>>>>> request and receive a token is the same as the client that will pres= ent the >>>>>> token to the RS. In the US HIPAA use-case, for example, the root of = trust >>>>>> is a contract between the patient-subject and the doctor-requesting = party >>>>>> but the doctor workflow is expected to delegate the token to some ot= her >>>>>> end-user that may be using a totally different client such as an EHR= . >>>>>> >>>>>> >>>>>> If the client that gets the token is not same as the client that use= s >>>>>> the token, that is a violation of core security principles as it all= ows for >>>>>> (and really designs for) impersonation by client software. I would h= ave no >>>>>> reason to trust client software that would hand its credentials over= to >>>>>> another piece of software, and in fact I shouldn=E2=80=99t trust it. >>>>>> >>>>>> I think you may be conflating several different kinds of parties >>>>>> under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80= =99s entirely possible that one >>>>>> client might call an RS that in turn acts as a client for something = else >>>>>> down stream. But each of those hops is different from the last. >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> --000000000000befcdc05bdc7bd06 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Yes, the AS is the policy manager and the token issu= er for that delegation, based on the knowledge it has of the RO.=C2=A0
    We don't assume much on the lifecycle of the protect= ed resource, except that they expect a valid access token issued by the AS = to provide access.=C2=A0

    We defined client instances related to one client software. The client doe= s matter, we could even define its class or posture, but it's possible = to make a request to the AS even if you're not pre registered.=C2=A0

    Fabien=C2=A0

    Le jeu. 18 mars 2021 =C3=A0 04:54, Adrian Gropper <agropper@healthurl.com> a =C3= =A9crit=C2=A0:
    Sur= e!=C2=A0

    Is there an AS involved in the delegation? How = and where in the lifecycle=C2=A0of the protected resource?=C2=A0

    Also your use of "the client" seems to imply that either= there is only one client or the client doesn't matter. Which is it?

    Adrian

    On Wed, Mar 17, 2021 at 11:43 PM F= abien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks for that.=C2=A0

    Trying to reframe it:
    GNAP is defined as a delegation protocol so the main intent is re= lated to a delegate of the RO (i.e. the end user) that wishes to access the= RO's protected resources, through the client.=C2=A0

    Fabien=C2=A0

    Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian G= ropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    At various points in the lifecycle=C2=A0= of the protected resource the client at the resource server (RS) might be:<= div>
    • The RO (subject) user agent trading payment for a service promi= se
    • The RO user agent using the promise to access the protected reso= urce
    • A delegate of the RO user agent using a different client
      • <= /ul>
      What's vague is where the GNAP AS enters the picture as descri= bed above. How would you describe it?

    Adrian=


    On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Adrian

    I'm still confused why you're saying the terminology is vague.= =C2=A0
    I get the "power" neutrality is not= to your liking, but RQ / user agent is no better in my view.=C2=A0

    Can you elaborate?=C2=A0
    <= div dir=3D"auto">
    Fabien=C2=A0

    Le jeu. 18 m= ars 2021 =C3=A0 00:18, Adrian Gropper <agropper@healthurl= .com> a =C3=A9crit=C2=A0:
    I'm sure you're right. Our vague terminology=C2=A0around client=C2= =A0and=C2=A0end-user leads to my confusion. If GNAP is primarily about dele= gation=C2=A0then, of course, we should=C2=A0avoid any incentives to imperso= nate or we're wasting our time. This is partly why I'm trying to st= udy up on capabilities and asking for expert advice from folks like Alan Ka= rp and Mark Miller (cc'd)

    As best I can understand i= t, the RS has only two choices, it can:
    • store an attribut= e of the RO a [DID, email address, GNAP AS URL], or
    • hand the RO a c= apability as a sort-of promise and avoid making any entries in an ACL or eq= uivalent.
    When a token comes back to the RS, it will either b= e:
    • validated according to something associated with the s= tored RO attribute, or
    • signed by the RS itself.
    E= ither way, trust in the client seems moot.

    Adrian<= /div>



    On Wed, Mar 17, 2021 at 5:29= PM Justin Richer <jricher@mit.edu> wrote:
    =
    On Mar 17, 2021, at 4:55 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    On Wed, Mar 17, 2021 a= t 4:23 PM Tobias Looker <tobias.looker@mat= tr.global> wrote:
    <snip>
    > A client might not hav= e a DID but it could have a VC as a certificate of authenticity linked to s= ome audit mechanism.

    To me a VC would come under t= he assertions umbrella (that is to say a VC could be one type of valid asse= rtion). The client may possess or been presented with a VC that it could in= clude in its request to the AS as a way to identify the subject and perhaps= prove authentication and authorization.

    <= /div>
    I do not assume that the client that interacts with the AS to mak= e a request and receive a token is the same as the client that will present= the token to the RS. In the US HIPAA use-case, for example, the root of tr= ust is a contract between the patient-subject and the doctor-requesting par= ty but the doctor workflow is expected to delegate the token to some other = end-user that may be using a totally different client such as an EHR.
    =


    If the client = that gets the token is not same as the client that uses the token, that is = a violation of core security principles as it allows for (and really design= s for) impersonation by client software. I would have no reason to trust cl= ient software that would hand its credentials over to another piece of soft= ware, and in fact I shouldn=E2=80=99t trust it.=C2=A0

    <= div>I think you may be conflating several different kinds of parties under = the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80=99s entirely p= ossible that one client might call an RS that in turn acts as a client for = something else down stream. But each of those hops is different from the la= st.

    =C2=A0=E2=80=94 Justin

    --000000000000befcdc05bdc7bd06-- From alanhkarp@gmail.com Wed Mar 17 21:03:40 2021 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 A5D7F3A1F41 for ; Wed, 17 Mar 2021 21:03:40 -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 BY73ey3PjsK4 for ; Wed, 17 Mar 2021 21:03:38 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 A9BB03A1F40 for ; Wed, 17 Mar 2021 21:03:38 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id l4so812812qkl.0 for ; Wed, 17 Mar 2021 21:03: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:from:date:message-id:subject:to :cc; bh=W5bFA9eBxv/tP4bEQYUIQT5Gn2EAOiQuel/Rm6KWF0o=; b=S9tiy1NIbhmBDSyW1Ih7MJdGFu7O9I9GG2OxWkZfn1W1CKFZ9zFp/wpaz01P60dc0v qRZzcPOVQoYIxW+5ukEBfQcBRF9/VAJ+BwbX3HAlrG9l0K5lI2ujMAc9idGo6jaKvXvP QtK4Y2ef7JNmn55VBwI9v/xHPMVeMeyCl+CmHsG+ovzOWnOm7f42VInTmasjQ/KgAHVh Dgdrs5ThQ/wXTXP3zDcBn0VL5Lka/vzWQJLx6kq4HKBedna9Tlj1sEFjpzmrCvYpoZvw X/gagilsbvT5aWH/u4BW7k7/lxe0yoX8USOU5Pn6a4ATYVQ9+OCYn8UI4qoeRayVJ1K/ QQuA== 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=W5bFA9eBxv/tP4bEQYUIQT5Gn2EAOiQuel/Rm6KWF0o=; b=TIM4Di+NRzquuD+PskGF/U1I6yjPkycQfIEy2oMCeldE8uiARyFm11/MmmizTdPoiR RmwA3BegdKj/WuTXTcz+wo51+OchTQbNPHM1P26ZqHhyKZG4D0JAXwj9ijRNyY5HYckp TYzFcW3bPu/oECBicC9HxZQAMTDy0Ooq67Sb0JaKo1Rrx9HSCC4QIpNEQSJfoBwjU3jU eV5XGQsW1pdd+sKtpO347SI5L4p6RiBUqqbCkLrDuCSRHxpoQuN+ZB4f9DelJKHcScQx yr2z2vf3k60B3Yb1CdD6G8TTaa35+cTZZjkMtt7fDSs1x+BZ2RiPpVGEAxFm9A8GOcgc 2hzg== X-Gm-Message-State: AOAM533zKCP8pQ0lHGuP1TPm78C25Csy8I9Ph1Sm8y+XUig6ZlFC1x2A T2NC76U/+8Cei+FCapTdsU3AjEZg+ae9D6IFDSo= X-Google-Smtp-Source: ABdhPJzgXAnHpYCrv50rqO2jrIG1lBqphtFi8gzADxaHeXg5SpF4Wf8NqKWLVTgGmgYhNwWDOENXZWMR+FQnYl6kzbY= X-Received: by 2002:a37:9fd2:: with SMTP id i201mr2475274qke.435.1616040217188; Wed, 17 Mar 2021 21:03:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alan Karp Date: Wed, 17 Mar 2021 21:03:25 -0700 Message-ID: To: Adrian Gropper Cc: Justin Richer , Tobias Looker , Fabien Imbault , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="000000000000169b6205bdc7af07" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 04:12:26 -0000 --000000000000169b6205bdc7af07 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If the client that gets the token is not same as the client that uses the token, that is a violation of core security principles as it allows for (and really designs for) impersonation by client software. I would have no reason to trust client software that would hand its credentials over to another piece of software, and in fact I shouldn=E2=80=99t trust it. How would you know if the client using the token is not the client it was given to if the two clients are in cahoots? Sharing tokens is actually a useful pattern. Client A running on your behalf could delegate to Client B also running on your behalf, but it's sometimes easier to share the credential. For example, you might not mind if the client you use to retrieve the prices of stocks in your portfolio shares permission to know what stocks you own with the client you use to plot that data. You would only need to delegate if you wanted to sub-scope, separately revoke, or have an audit trail. -------------- Alan Karp On Wed, Mar 17, 2021 at 4:18 PM Adrian Gropper wrote: > I'm sure you're right. Our vague terminology around client and end-user > leads to my confusion. If GNAP is primarily about delegation then, of > course, we should avoid any incentives to impersonate or we're wasting ou= r > time. This is partly why I'm trying to study up on capabilities and askin= g > for expert advice from folks like Alan Karp and Mark Miller (cc'd) > > As best I can understand it, the RS has only two choices, it can: > > - store an attribute of the RO a [DID, email address, GNAP AS URL], or > - hand the RO a capability as a sort-of promise and avoid making any > entries in an ACL or equivalent. > > When a token comes back to the RS, it will either be: > > - validated according to something associated with the stored RO > attribute, or > - signed by the RS itself. > > Either way, trust in the client seems moot. > > Adrian > > > > On Wed, Mar 17, 2021 at 5:29 PM Justin Richer wrote: > >> On Mar 17, 2021, at 4:55 PM, Adrian Gropper >> wrote: >> >> >> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker >> wrote: >> >>> >>> > A client might not have a DID but it could have a VC as a certificate >>> of authenticity linked to some audit mechanism. >>> >>> To me a VC would come under the assertions umbrella (that is to say a V= C >>> could be one type of valid assertion). The client may possess or been >>> presented with a VC that it could include in its request to the AS as a= way >>> to identify the subject and perhaps prove authentication and authorizat= ion. >>> >> >> I do not assume that the client that interacts with the AS to make a >> request and receive a token is the same as the client that will present = the >> token to the RS. In the US HIPAA use-case, for example, the root of trus= t >> is a contract between the patient-subject and the doctor-requesting part= y >> but the doctor workflow is expected to delegate the token to some other >> end-user that may be using a totally different client such as an EHR. >> >> >> If the client that gets the token is not same as the client that uses th= e >> token, that is a violation of core security principles as it allows for >> (and really designs for) impersonation by client software. I would have = no >> reason to trust client software that would hand its credentials over to >> another piece of software, and in fact I shouldn=E2=80=99t trust it. >> >> I think you may be conflating several different kinds of parties under >> the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80=99s entirel= y possible that one client >> might call an RS that in turn acts as a client for something else down >> stream. But each of those hops is different from the last. >> >> =E2=80=94 Justin >> >> --000000000000169b6205bdc7af07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    If the client that gets the token is not same as the client that uses= the token, that is a violation of core security principles as it allows fo= r (and really designs for) impersonation by client software. I would have n= o reason to trust client software that would hand its credentials over to a= nother piece of software, and in fact I shouldn=E2=80=99t trust it.=C2=A0

    How would you know if the client using the token is n= ot the client it was given to if the two clients are in cahoots?=C2=A0 Shar= ing tokens is actually a useful pattern.=C2=A0 Client A running on your beh= alf could delegate to Client B also running on your behalf, but it's so= metimes easier to share the credential.=C2=A0 For example, you might not mi= nd if the client you use to retrieve the prices of stocks in your portfolio= shares permission to know what stocks you own with the client you use to p= lot that data.=C2=A0 You would only need to delegate if you wanted to sub-s= cope, separately revoke, or have an audit trail.=C2=A0

    --------= ------
    Alan Karp


    On Wed, Mar 17, 2021 at 4:18 PM Adrian G= ropper <agropper@healthurl.com= > wrote:
    =
    I'm sure you're right. Our vague terminology=C2=A0= around client=C2=A0and=C2=A0end-user leads to my confusion. If GNAP is prim= arily about delegation=C2=A0then, of course, we should=C2=A0avoid any incen= tives to impersonate or we're wasting our time. This is partly why I= 9;m trying to study up on capabilities and asking for expert advice from fo= lks like Alan Karp and Mark Miller (cc'd)

    As best I = can understand it, the RS has only two choices, it can:
    • s= tore an attribute of the RO a [DID, email address, GNAP AS URL], or
      • hand the RO a capability as a sort-of promise and avoid making any entries= in an ACL or equivalent.
    When a token comes back to the RS, = it will either be:
    • validated according to something assoc= iated with the stored RO attribute, or
    • signed by the RS itself.=
    Either way, trust in the client seems moot.

    Adrian



    On Wed, Mar = 17, 2021 at 5:29 PM Justin Richer <jricher@mit.edu> wrote:
    = On Mar 17, 2021, at 4:55 PM, Adrian Gropper <agropper@healthurl.com> wrote:
    <= div>

    On= Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <tobias.looker@mattr.global> wro= te:
    <snip>
    > A client m= ight not have a DID but it could have a VC as a certificate of authenticity= linked to some audit mechanism.

    To me a VC would = come under the assertions umbrella (that is to say a VC could be one type o= f valid assertion). The client may possess or been presented with a VC that= it could include in its request to the AS as a way to identify the subject= and perhaps prove authentication and authorization.

    I do not assume that the client that interacts with t= he AS to make a request and receive a token is the same as the client that = will present the token to the RS. In the US HIPAA use-case, for example, th= e root of trust is a contract between the patient-subject and the doctor-re= questing party but the doctor workflow is expected to delegate the token to= some other end-user that may be using a totally different client such as a= n EHR.


    If= the client that gets the token is not same as the client that uses the tok= en, that is a violation of core security principles as it allows for (and r= eally designs for) impersonation by client software. I would have no reason= to trust client software that would hand its credentials over to another p= iece of software, and in fact I shouldn=E2=80=99t trust it.=C2=A0

    I think you may be conflating several different kinds of pa= rties under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80=99= s entirely possible that one client might call an RS that in turn acts as a= client for something else down stream. But each of those hops is different= from the last.

    =C2=A0=E2=80=94 Justin

    --000000000000169b6205bdc7af07-- From alanhkarp@gmail.com Wed Mar 17 21:08:35 2021 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 E96553A1F5D for ; Wed, 17 Mar 2021 21:08:35 -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 R6wGtIpPAEc0 for ; Wed, 17 Mar 2021 21:08:34 -0700 (PDT) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 1A18B3A1F5C for ; Wed, 17 Mar 2021 21:08:34 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id l4so820097qkl.0 for ; Wed, 17 Mar 2021 21:08: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=YV+y/eEAJpri00QQ0UlPddgkuA928srXoW/+koVF1q4=; b=sZs3m76iqzKj1mzT/UAkJycHRbpRULgqrU8ifBf8XJqAS+DNtS042/eFqksHLrr+XH w6XIfsXz+a7al9sCFFR1q3ESNu4RHTYHNEEpMnLAcrVkueuaFpc9ack4aayQxaVUI6hs 0p8Goe7mMILSHGnXLCsk8GQszOfvyHj3exfEN4XVTLpFumjpYUkhGjcK3q1yc9Fos+N+ 036C8jcYMk+0Z1j1P+drBDuXobFZ4P/sAgQT057H8c5oUDTVLJLA5GqiXxoY7W7gGk3J WtEA4YQdPaVjH8V4rvLJMu8Ni1H5kXTijhKZovWLhV4a01vWef0u5Oj2WbURUFS1OY5t otag== 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=YV+y/eEAJpri00QQ0UlPddgkuA928srXoW/+koVF1q4=; b=Cg5J6Ys68u9Jh40la+DppkM3sOlICvjd0VA5hz71BHC8nrD5g3tWlzbyLbL3SvVk5c WSU9xHPKwyd0L5OaXczfyS25+vyUjU4PJaeEu45NhdShg6ewRhIiHnY8lViWaQxMOlRd lfpJ9Dwt1UT+OpTo3ZR36ZkOB7EX9/yjnFFo8zJfUFvJt6QxrCHcyiopnsMlXP4vem7L GqsQrsUxRJNVQhduGwZVcKfj2c5GhSF32j0V40SjdXQYfyrCLLYDrmItNU3Af/xTkF7r 8wg29B0QbqLQ9rxKtnc+Lk965L3nyYnZ51S9zHbyX2bK0S6jeAo93b4dNB6GHOL+fX9f DNZQ== X-Gm-Message-State: AOAM530OPbNj0jXx5YOvkrni5Y7nssNdugw/ll5e9hrA0k8yAnaTmoqs Fh0nmpgp+uyhe6Ok8eaconmqcJ3M8d/RuALI6dA= X-Google-Smtp-Source: ABdhPJx8ZHJzERRLx1ImqJ9v5kSfIfHHLAIPDS7pe/m1l4OBJkFv7Fa+/B+VOMmxCWQrf4IYMtFQELdMrWtbD/sdVBQ= X-Received: by 2002:a37:a845:: with SMTP id r66mr2559774qke.89.1616040510089; Wed, 17 Mar 2021 21:08:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alan Karp Date: Wed, 17 Mar 2021 21:08:18 -0700 Message-ID: To: Adrian Gropper Cc: Fabien Imbault , Justin Richer , Tobias Looker , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="0000000000008bee1f05bdc7c053" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 04:12:43 -0000 --0000000000008bee1f05bdc7c053 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Adrian Gropper wrote: > > Is there an AS involved in the delegation? How and where in the > lifecycle of the protected resource? > If tokens are certificates, the AS need not be involved in subsequent delegations. The AS must be involved if the tokens are opaque. -------------- Alan Karp On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper wrote: > Sure! > > Is there an AS involved in the delegation? How and where in the > lifecycle of the protected resource? > > Also your use of "the client" seems to imply that either there is only on= e > client or the client doesn't matter. Which is it? > > Adrian > > On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault > wrote: > >> Thanks for that. >> >> Trying to reframe it: >> GNAP is defined as a delegation protocol so the main intent is related t= o >> a delegate of the RO (i.e. the end user) that wishes to access the RO's >> protected resources, through the client. >> >> Fabien >> >> Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper a >> =C3=A9crit : >> >>> At various points in the lifecycle of the protected resource the client >>> at the resource server (RS) might be: >>> >>> - The RO (subject) user agent trading payment for a service promise >>> - The RO user agent using the promise to access the protected >>> resource >>> - A delegate of the RO user agent using a different client >>> >>> What's vague is where the GNAP AS enters the picture as described above= . >>> How would you describe it? >>> >>> Adrian >>> >>> >>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault < >>> fabien.imbault@gmail.com> wrote: >>> >>>> Hi Adrian >>>> >>>> I'm still confused why you're saying the terminology is vague. >>>> I get the "power" neutrality is not to your liking, but RQ / user agen= t >>>> is no better in my view. >>>> >>>> Can you elaborate? >>>> >>>> Fabien >>>> >>>> Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper >>>> a =C3=A9crit : >>>> >>>>> I'm sure you're right. Our vague terminology around >>>>> client and end-user leads to my confusion. If GNAP is primarily about >>>>> delegation then, of course, we should avoid any incentives to imperso= nate >>>>> or we're wasting our time. This is partly why I'm trying to study up = on >>>>> capabilities and asking for expert advice from folks like Alan Karp a= nd >>>>> Mark Miller (cc'd) >>>>> >>>>> As best I can understand it, the RS has only two choices, it can: >>>>> >>>>> - store an attribute of the RO a [DID, email address, GNAP AS >>>>> URL], or >>>>> - hand the RO a capability as a sort-of promise and avoid making >>>>> any entries in an ACL or equivalent. >>>>> >>>>> When a token comes back to the RS, it will either be: >>>>> >>>>> - validated according to something associated with the stored RO >>>>> attribute, or >>>>> - signed by the RS itself. >>>>> >>>>> Either way, trust in the client seems moot. >>>>> >>>>> Adrian >>>>> >>>>> >>>>> >>>>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer wrote= : >>>>> >>>>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper >>>>>> wrote: >>>>>> >>>>>> >>>>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker < >>>>>> tobias.looker@mattr.global> wrote: >>>>>> >>>>>>> >>>>>>> > A client might not have a DID but it could have a VC as a >>>>>>> certificate of authenticity linked to some audit mechanism. >>>>>>> >>>>>>> To me a VC would come under the assertions umbrella (that is to say >>>>>>> a VC could be one type of valid assertion). The client may possess = or been >>>>>>> presented with a VC that it could include in its request to the AS = as a way >>>>>>> to identify the subject and perhaps prove authentication and author= ization. >>>>>>> >>>>>> >>>>>> I do not assume that the client that interacts with the AS to make a >>>>>> request and receive a token is the same as the client that will pres= ent the >>>>>> token to the RS. In the US HIPAA use-case, for example, the root of = trust >>>>>> is a contract between the patient-subject and the doctor-requesting = party >>>>>> but the doctor workflow is expected to delegate the token to some ot= her >>>>>> end-user that may be using a totally different client such as an EHR= . >>>>>> >>>>>> >>>>>> If the client that gets the token is not same as the client that use= s >>>>>> the token, that is a violation of core security principles as it all= ows for >>>>>> (and really designs for) impersonation by client software. I would h= ave no >>>>>> reason to trust client software that would hand its credentials over= to >>>>>> another piece of software, and in fact I shouldn=E2=80=99t trust it. >>>>>> >>>>>> I think you may be conflating several different kinds of parties >>>>>> under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80= =99s entirely possible that one >>>>>> client might call an RS that in turn acts as a client for something = else >>>>>> down stream. But each of those hops is different from the last. >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> --0000000000008bee1f05bdc7c053 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Adr= ian Gropper <agropper@healthur= l.com> wrote:

    Is there an AS involved in the de= legation? How and where in the lifecycle=C2=A0of the protected resource?=C2= =A0

    If tokens are certificates,= the AS need not be involved in subsequent delegations.=C2=A0 The AS must b= e involved if the tokens are opaque.=C2=A0

    ----= ----------
    Alan Karp


    On Wed, Mar 17, 2021 at 8:54 PM Adri= an Gropper <agropper@healthurl= .com> wrote:
    Sure!=C2=A0

    Is there an AS involved= in the delegation? How and where in the lifecycle=C2=A0of the protected re= source?=C2=A0

    Also your use of "the client" se= ems to imply that either there is only one client or the client doesn't= matter. Which is it?

    Adrian

    =
    On Wed, Ma= r 17, 2021 at 11:43 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks for that.=C2=A0

    = Trying to reframe it:
    GNAP is defined as a delegatio= n protocol so the main intent is related to a delegate of the RO (i.e. the = end user) that wishes to access the RO's protected resources, through t= he client.=C2=A0

    Fabien=C2=A0

    Le jeu.= 18 mars 2021 =C3=A0 04:29, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit= =C2=A0:
    At various points in the lifecycle=C2=A0of the protected resource = the client at the resource server (RS) might be:
    • The RO (subjec= t) user agent trading payment for a service promise
    • The RO user age= nt using the promise to access the protected resource
    • A delegate of= the RO user agent using a different client
    What's vague = is where the GNAP AS enters the picture as described above. How would you d= escribe it?

    Adrian


    On We= d, Mar 17, 2021 at 10:20 PM Fabien Imbault <fabien.imbault@gmail.c= om> wrote:
    Hi Adrian

    = I'm still confused why you're saying the terminology is vague.=C2= =A0
    I get the "power" neutrality is not to= your liking, but RQ / user agent is no better in my view.=C2=A0

    Can you elaborate?=C2=A0

    Fabien=C2=A0

    Le jeu. 18 mars= 2021 =C3=A0 00:18, Adrian Gropper <agropper@healthurl.com> a= =C3=A9crit=C2=A0:
    I'm sure you're right. Our vague terminology=C2= =A0around client=C2=A0and=C2=A0end-user leads to my confusion. If GNAP is p= rimarily about delegation=C2=A0then, of course, we should=C2=A0avoid any in= centives to impersonate or we're wasting our time. This is partly why I= 'm trying to study up on capabilities and asking for expert advice from= folks like Alan Karp and Mark Miller (cc'd)

    As best= I can understand it, the RS has only two choices, it can:
      store an attribute of the RO a [DID, email address, GNAP AS URL], or=
    • hand the RO a capability as a sort-of promise and avoid making any entr= ies in an ACL or equivalent.
    When a token comes back to the R= S, it will either be:
    • validated according to something as= sociated with the stored RO attribute, or
    • signed by the RS itse= lf.
    Either way, trust in the client seems moot.
    Adrian


    On Wed, M= ar 17, 2021 at 5:29 PM Justin Richer <jricher@mit.edu> wr= ote:
    On Mar 17, 2021, at 4:55 PM, Adrian Gropper= <agropper@healthurl.com> wrote:

    On Wed, Mar 17,= 2021 at 4:23 PM Tobias Looker <tobias.looker@mattr.g= lobal> wrote:
    <snip>
    > A client might not have a DID but it could have a VC as a certifica= te of authenticity linked to some audit mechanism.

    To me a VC would come under the assertions umbrella (that is to say a VC c= ould be one type of valid assertion). The client may possess or been presen= ted with a VC that it could include in its request to the AS as a way to id= entify the subject and perhaps prove authentication and authorization.

    I do not assume that the client tha= t interacts with the AS to make a request and receive a token is the same a= s the client that will present the token to the RS. In the US HIPAA use-cas= e, for example, the root of trust is a contract between the patient-subject= and the doctor-requesting party but the doctor workflow is expected to del= egate the token to some other end-user that may be using a totally differen= t client such as an EHR.


    If the client that gets the token is not same as the client= that uses the token, that is a violation of core security principles as it= allows for (and really designs for) impersonation by client software. I wo= uld have no reason to trust client software that would hand its credentials= over to another piece of software, and in fact I shouldn=E2=80=99t trust i= t.=C2=A0

    I think you may be conflating several dif= ferent kinds of parties under the =E2=80=9Cclient=E2=80=9D umbrella here, t= hough. It=E2=80=99s entirely possible that one client might call an RS that= in turn acts as a client for something else down stream. But each of those= hops is different from the last.

    =C2=A0=E2=80=94 = Justin

    --0000000000008bee1f05bdc7c053-- From nobody Wed Mar 17 21:21:57 2021 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 A4BE83A1F98 for ; Wed, 17 Mar 2021 21:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 57u5M5gMsORu for ; Wed, 17 Mar 2021 21:21:53 -0700 (PDT) Received: from mail-vs1-f45.google.com (mail-vs1-f45.google.com [209.85.217.45]) (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 A05D63A1F97 for ; Wed, 17 Mar 2021 21:21:53 -0700 (PDT) Received: by mail-vs1-f45.google.com with SMTP id 124so826122vsg.12 for ; Wed, 17 Mar 2021 21:21:53 -0700 (PDT) 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=XttAYr3ULoynznIANFCpbuUquYbDJ/likkiqFwmZ4FE=; b=fkWZ2Fbx+ka5GMBiDYnotHbqmPp3EN8b84IQ5fLgdxLtcFGDfOe434hY2HTZJxhtMf QK7mfkzMPjb6O0ziuhJCkaJemxWmvoBB/f/6+qYZ0hA0HX7gN0DQryrpcH/Wak62+T8a V3pJKhP3FpayiqqfNwcWopJIZQlEABUr1kcrrpIq+xisRiN0flY+tq27qX/Xvyfn7wP/ 0s9cG3sv3g7QkfodYv4vK1vADtqxLrhvDJeF9bcqgqvioKKl+mh7IgO5QYi2J4c4gWHd pBJys8ny1BLZoTL8ndjEArRvoMNq/rhCEGOOWgvjaAA93gLCtRV3eB+zoXKX6HirQKMR MZBg== X-Gm-Message-State: AOAM530ICZD4+j7ypr9qIigZzD1tujFRkSyl63d4DuwzcT/zWjQvqO7y m56Zp5vxNqwWzSNvXQO9nRPxvgKr6EcZLVcsTL8= X-Google-Smtp-Source: ABdhPJw+/BituRG/jV+dF5IC0nvyOhGMi3k0J7CkU5qw34n1+YpbFMNhkp1uqIbbn8icCU/9wWA9zFPTq1nT0A5F9wg= X-Received: by 2002:a05:6102:222f:: with SMTP id d15mr5545474vsb.1.1616041312601; Wed, 17 Mar 2021 21:21:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Adrian Gropper Date: Thu, 18 Mar 2021 00:21:40 -0400 Message-ID: To: Fabien Imbault Cc: Justin Richer , Tobias Looker , GNAP Mailing List , Alan Karp , Mark Miller Content-Type: multipart/alternative; boundary="000000000000614a1005bdc7f030" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 04:21:56 -0000 --000000000000614a1005bdc7f030 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ... "the knowledge the AS has of the RO" is a combination of policies the RO controls and the promise the RO received from the RS. Once the RS has made and signed a promise in some form, why does it need to know whether an AS was involved as long as the token has privileges that are equal or less than the promise? As Alan says, if the token is opaque, then of course it has to be introspected by some entity the RS trusts, such as an AS. Was that AS set as part of the promise made to the RO? What does client registration have to do with any of this? Adrian On Thu, Mar 18, 2021 at 12:07 AM Fabien Imbault wrote: > Yes, the AS is the policy manager and the token issuer for that > delegation, based on the knowledge it has of the RO. > We don't assume much on the lifecycle of the protected resource, except > that they expect a valid access token issued by the AS to provide access. > > We defined client instances related to one client software. The client > does matter, we could even define its class or posture, but it's possible > to make a request to the AS even if you're not pre registered. > > Fabien > > Le jeu. 18 mars 2021 =C3=A0 04:54, Adrian Gropper a > =C3=A9crit : > >> Sure! >> >> Is there an AS involved in the delegation? How and where in the >> lifecycle of the protected resource? >> >> Also your use of "the client" seems to imply that either there is only >> one client or the client doesn't matter. Which is it? >> >> Adrian >> >> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault >> wrote: >> >>> Thanks for that. >>> >>> Trying to reframe it: >>> GNAP is defined as a delegation protocol so the main intent is related >>> to a delegate of the RO (i.e. the end user) that wishes to access the R= O's >>> protected resources, through the client. >>> >>> Fabien >>> >>> Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper a >>> =C3=A9crit : >>> >>>> At various points in the lifecycle of the protected resource the clien= t >>>> at the resource server (RS) might be: >>>> >>>> - The RO (subject) user agent trading payment for a service promise >>>> - The RO user agent using the promise to access the protected >>>> resource >>>> - A delegate of the RO user agent using a different client >>>> >>>> What's vague is where the GNAP AS enters the picture as described >>>> above. How would you describe it? >>>> >>>> Adrian >>>> >>>> >>>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Hi Adrian >>>>> >>>>> I'm still confused why you're saying the terminology is vague. >>>>> I get the "power" neutrality is not to your liking, but RQ / user >>>>> agent is no better in my view. >>>>> >>>>> Can you elaborate? >>>>> >>>>> Fabien >>>>> >>>>> Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper >>>>> a =C3=A9crit : >>>>> >>>>>> I'm sure you're right. Our vague terminology around >>>>>> client and end-user leads to my confusion. If GNAP is primarily abou= t >>>>>> delegation then, of course, we should avoid any incentives to impers= onate >>>>>> or we're wasting our time. This is partly why I'm trying to study up= on >>>>>> capabilities and asking for expert advice from folks like Alan Karp = and >>>>>> Mark Miller (cc'd) >>>>>> >>>>>> As best I can understand it, the RS has only two choices, it can: >>>>>> >>>>>> - store an attribute of the RO a [DID, email address, GNAP AS >>>>>> URL], or >>>>>> - hand the RO a capability as a sort-of promise and avoid making >>>>>> any entries in an ACL or equivalent. >>>>>> >>>>>> When a token comes back to the RS, it will either be: >>>>>> >>>>>> - validated according to something associated with the stored RO >>>>>> attribute, or >>>>>> - signed by the RS itself. >>>>>> >>>>>> Either way, trust in the client seems moot. >>>>>> >>>>>> Adrian >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer >>>>>> wrote: >>>>>> >>>>>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker < >>>>>>> tobias.looker@mattr.global> wrote: >>>>>>> >>>>>>>> >>>>>>>> > A client might not have a DID but it could have a VC as a >>>>>>>> certificate of authenticity linked to some audit mechanism. >>>>>>>> >>>>>>>> To me a VC would come under the assertions umbrella (that is to sa= y >>>>>>>> a VC could be one type of valid assertion). The client may possess= or been >>>>>>>> presented with a VC that it could include in its request to the AS= as a way >>>>>>>> to identify the subject and perhaps prove authentication and autho= rization. >>>>>>>> >>>>>>> >>>>>>> I do not assume that the client that interacts with the AS to make = a >>>>>>> request and receive a token is the same as the client that will pre= sent the >>>>>>> token to the RS. In the US HIPAA use-case, for example, the root of= trust >>>>>>> is a contract between the patient-subject and the doctor-requesting= party >>>>>>> but the doctor workflow is expected to delegate the token to some o= ther >>>>>>> end-user that may be using a totally different client such as an EH= R. >>>>>>> >>>>>>> >>>>>>> If the client that gets the token is not same as the client that >>>>>>> uses the token, that is a violation of core security principles as = it >>>>>>> allows for (and really designs for) impersonation by client softwar= e. I >>>>>>> would have no reason to trust client software that would hand its >>>>>>> credentials over to another piece of software, and in fact I should= n=E2=80=99t >>>>>>> trust it. >>>>>>> >>>>>>> I think you may be conflating several different kinds of parties >>>>>>> under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80= =99s entirely possible that one >>>>>>> client might call an RS that in turn acts as a client for something= else >>>>>>> down stream. But each of those hops is different from the last. >>>>>>> >>>>>>> =E2=80=94 Justin >>>>>>> >>>>>>> --000000000000614a1005bdc7f030 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    ... "the knowledge the AS has of the RO" is a co= mbination of policies the RO controls and the promise the RO received from = the RS.

    Once the RS has made and signed a promise in some form, why= does it need to know whether an AS was involved as long as the token has p= rivileges that are equal or less than the promise?

    As Al= an says, if the token is opaque, then of course it has to be introspected= =C2=A0by some entity the RS trusts, such as an AS. Was that AS set as part = of the promise made to the RO?

    What does client re= gistration have to do with any of this?

    Adrian

    On Thu, Mar 18, 2021 at 12:07 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Yes, the AS is the policy manager and = the token issuer for that delegation, based on the knowledge it has of the = RO.=C2=A0
    We don't assume much on the lifecycle = of the protected resource, except that they expect a valid access token iss= ued by the AS to provide access.=C2=A0

    We defined client instances related to one client software. = The client does matter, we could even define its class or posture, but it&#= 39;s possible to make a request to the AS even if you're not pre regist= ered.=C2=A0

    Fabien=C2=A0=

    Le jeu. 18 mars 2021 =C3=A0 04:54, Adrian Gr= opper <agrop= per@healthurl.com> a =C3=A9crit=C2=A0:
    Sure!=C2=A0

    Is there an AS involved in the= delegation? How and where in the lifecycle=C2=A0of the protected resource?= =C2=A0

    Also your use of "the client" seems to = imply that either there is only one client or the client doesn't matter= . Which is it?

    Adrian

    On Wed, Mar 17, 2= 021 at 11:43 PM Fabien Imbault <fabien.imbault@gmail.com> w= rote:
    Thanks for that.=C2= =A0

    Trying to reframe it= :
    GNAP is defined as a delegation protocol so the ma= in intent is related to a delegate of the RO (i.e. the end user) that wishe= s to access the RO's protected resources, through the client.=C2=A0

    Fabien=C2=A0

    Le jeu. 18 mars 2021 =C3=A0= 04:29, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit= =C2=A0:
    At various points in the= lifecycle=C2=A0of the protected resource the client at the resource server= (RS) might be:
    • The RO (subject) user agent trading payment for= a service promise
    • The RO user agent using the promise to access th= e protected resource
    • A delegate of the RO user agent using a differ= ent client
    What's vague is where the GNAP AS enters the p= icture as described above. How would you describe it?

    <= /div>
    Adrian


    <= div dir=3D"ltr" class=3D"gmail_attr">On Wed, Mar 17, 2021 at 10:20 PM Fabie= n Imbault <fabien.imbault@gmail.com> wrote:
    <= /div>
    Hi Adrian

    I'm still confused why you're saying the termin= ology is vague.=C2=A0
    I get the "power" ne= utrality is not to your liking, but RQ / user agent is no better in my view= .=C2=A0

    Can you elaborat= e?=C2=A0

    Fabien=C2=A0

    Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper <agr= opper@healthurl.com> a =C3=A9crit=C2=A0:
    =
    I'm sure you're right. Our vague terminology=C2=A0= around client=C2=A0and=C2=A0end-user leads to my confusion. If GNAP is prim= arily about delegation=C2=A0then, of course, we should=C2=A0avoid any incen= tives to impersonate or we're wasting our time. This is partly why I= 9;m trying to study up on capabilities and asking for expert advice from fo= lks like Alan Karp and Mark Miller (cc'd)

    As best I = can understand it, the RS has only two choices, it can:
    • s= tore an attribute of the RO a [DID, email address, GNAP AS URL], or
      • hand the RO a capability as a sort-of promise and avoid making any entries= in an ACL or equivalent.
    When a token comes back to the RS, = it will either be:
    • validated according to something assoc= iated with the stored RO attribute, or
    • signed by the RS itself.=
    Either way, trust in the client seems moot.

    Adrian



    On Wed, Mar = 17, 2021 at 5:29 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 17, 2021, at 4:55 PM, Adrian Gropper &l= t;agropper@healthurl.com> wrote:
    <= blockquote type=3D"cite">
    On Wed,= Mar 17, 2021 at 4:23 PM Tobias Looker <to= bias.looker@mattr.global> wrote:
    <snip>
    > A clien= t might not have a DID but it could have a VC as a certificate of authentic= ity linked to some audit mechanism.

    To me a VC wou= ld come under the assertions umbrella (that is to say a VC could be one typ= e of valid assertion). The client may possess or been presented with a VC t= hat it could include in its request to the AS as a way to identify the subj= ect and perhaps prove authentication and authorization.

    I do not assume that the client that interacts wit= h the AS to make a request and receive a token is the same as the client th= at will present the token to the RS. In the US HIPAA use-case, for example,= the root of trust is a contract between the patient-subject and the doctor= -requesting party but the doctor workflow is expected to delegate the token= to some other end-user that may be using a totally different client such a= s an EHR.


    If the client that gets the token is not same as the client that uses the = token, that is a violation of core security principles as it allows for (an= d really designs for) impersonation by client software. I would have no rea= son to trust client software that would hand its credentials over to anothe= r piece of software, and in fact I shouldn=E2=80=99t trust it.=C2=A0
    <= div>
    I think you may be conflating several different kinds of= parties under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80= =99s entirely possible that one client might call an RS that in turn acts a= s a client for something else down stream. But each of those hops is differ= ent from the last.

    =C2=A0=E2=80=94 Justin
    --000000000000614a1005bdc7f030-- From nobody Wed Mar 17 21:49:12 2021 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 E46263A1DFC for ; Wed, 17 Mar 2021 21:49:10 -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 v6RRFnCq6L6M for ; Wed, 17 Mar 2021 21:49:08 -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 AA0B73A1DFB for ; Wed, 17 Mar 2021 21:49:08 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id e8so955920iok.5 for ; Wed, 17 Mar 2021 21:49: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=lpuNJ2iXtsqUAvQSIu3wXMeU5b+it5D9Tn0mJOb3m7M=; b=hBREDmzvrn2nnniLNEqOKNzBsNAAF6T5b4fRqwpfA4ZDIXBuxJlpzsVOphXfAoT93E /wcyks6H4g5wGcbccUZuIpxEaLdZx9k0lZSsZ6lsDfQcamsGBQFAxniRMW4Gj6eWtBfh feAf8dqoUk5hHtUBRkE8qLTd9VZDR6ZBS11+6QfCplFKy4BVFXoiZkKMQeXuHD905HYS ybOJOrWZEW86rsR1YfVf3clxUJwGHUaQg4jPDLbooGnMWTPVuucRLNBlVLN5ILueEu8+ +4gsAs9hCaKHlAPndXV8nK7Tv3kzekjsyaOXtoNxFKnx/svhHd4sRMXv7GsZy1gvrm3P s0Kg== 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=lpuNJ2iXtsqUAvQSIu3wXMeU5b+it5D9Tn0mJOb3m7M=; b=Tkf07yokadqvTl8GoWHxtl1tnlvoym53Fy0lqJf0O/2+NByTleX4zrO1rqP+BF1heO taoMd7ZHdKid1IZUey6JsOzuvbpI+JIprVmtIRCNQPKi3lXhZYcrt0ZHTZcGWJQJ8oxS NrWfbaFQ0gVSRAAGBVz4n51GZU7ip1H3NTmjHb+gBuK4hmfnMwF5qybm6GJMdk0Q11vN Fy+NGr6ITJL2dohvaLQGskFgPzeQ47le4x91bmv4cYUy6LqsTkiQaL+jTMUs4sfsYTRs SajCMT0mJHWc3SBE85wtYs4B5lQ7s0MXi7KPlohzrP9OVLZidqRbE0bYkSmzqvzXhBSq oPzw== X-Gm-Message-State: AOAM532q1O8TAj3gzXtWIjIlV9lAp9SQhaOW2/KQBQOnS/kvACsofNXu qOQh+KnMvAYtUBASSgBUwjTMHred7CWrFctol1Y= X-Google-Smtp-Source: ABdhPJwyVBUZGJyN0CvRgt5XQ6lNBQmuap4LoWBsFOU0Z2aaQkfbKO9DpynUYoTxAwp/m8kIXRT6kTKuM4+7k74/L8c= X-Received: by 2002:a02:94cb:: with SMTP id x69mr5751123jah.8.1616042946238; Wed, 17 Mar 2021 21:49:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Thu, 18 Mar 2021 05:48:52 +0100 Message-ID: To: Adrian Gropper Cc: Justin Richer , Tobias Looker , GNAP Mailing List , Alan Karp , Mark Miller Content-Type: multipart/alternative; boundary="000000000000c09d2705bdc851e0" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 04:49:11 -0000 --000000000000c09d2705bdc851e0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There are 2 different things : - there's a generic protocol where the client doesn't need to understand the token, based on some joint knowledge between the RS and the AS (i.e. what these tokens represent) - and there could be some additional assumptions (e.g. token format, RS preflight, etc.) on how the RS gets involved in a more dynamic way. Both views are valid, but the goal is to keep easy things simple, and allow complex stuff too. "if the token is opaque, then of course it has to be introspected by some entity the RS trusts, such as an AS." not necessarily, it's entirely possible for the RS to simply say "thanks reputable AS, I accept to process that access token". Or you might introspect at run time. Or in some more sensitive scenarii you might really want to go one step further and indeed establish some agreement on what tokens mean. All I'm saying is that there are shades in what is possible. On your last point that's just to say that the client posture may be part of the policy decision (since you asked if the client matters). Fabien Le jeu. 18 mars 2021 =C3=A0 05:21, Adrian Gropper = a =C3=A9crit : > ... "the knowledge the AS has of the RO" is a combination of policies the > RO controls and the promise the RO received from the RS. > > Once the RS has made and signed a promise in some form, why does it need > to know whether an AS was involved as long as the token has privileges th= at > are equal or less than the promise? > > As Alan says, if the token is opaque, then of course it has to be > introspected by some entity the RS trusts, such as an AS. Was that AS set > as part of the promise made to the RO? > > What does client registration have to do with any of this? > > Adrian > > On Thu, Mar 18, 2021 at 12:07 AM Fabien Imbault > wrote: > >> Yes, the AS is the policy manager and the token issuer for that >> delegation, based on the knowledge it has of the RO. >> We don't assume much on the lifecycle of the protected resource, except >> that they expect a valid access token issued by the AS to provide access= . >> >> We defined client instances related to one client software. The client >> does matter, we could even define its class or posture, but it's possibl= e >> to make a request to the AS even if you're not pre registered. >> >> Fabien >> >> Le jeu. 18 mars 2021 =C3=A0 04:54, Adrian Gropper a >> =C3=A9crit : >> >>> Sure! >>> >>> Is there an AS involved in the delegation? How and where in the >>> lifecycle of the protected resource? >>> >>> Also your use of "the client" seems to imply that either there is only >>> one client or the client doesn't matter. Which is it? >>> >>> Adrian >>> >>> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault < >>> fabien.imbault@gmail.com> wrote: >>> >>>> Thanks for that. >>>> >>>> Trying to reframe it: >>>> GNAP is defined as a delegation protocol so the main intent is related >>>> to a delegate of the RO (i.e. the end user) that wishes to access the = RO's >>>> protected resources, through the client. >>>> >>>> Fabien >>>> >>>> Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper >>>> a =C3=A9crit : >>>> >>>>> At various points in the lifecycle of the protected resource the >>>>> client at the resource server (RS) might be: >>>>> >>>>> - The RO (subject) user agent trading payment for a service promis= e >>>>> - The RO user agent using the promise to access the protected >>>>> resource >>>>> - A delegate of the RO user agent using a different client >>>>> >>>>> What's vague is where the GNAP AS enters the picture as described >>>>> above. How would you describe it? >>>>> >>>>> Adrian >>>>> >>>>> >>>>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Hi Adrian >>>>>> >>>>>> I'm still confused why you're saying the terminology is vague. >>>>>> I get the "power" neutrality is not to your liking, but RQ / user >>>>>> agent is no better in my view. >>>>>> >>>>>> Can you elaborate? >>>>>> >>>>>> Fabien >>>>>> >>>>>> Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper >>>>>> a =C3=A9crit : >>>>>> >>>>>>> I'm sure you're right. Our vague terminology around >>>>>>> client and end-user leads to my confusion. If GNAP is primarily abo= ut >>>>>>> delegation then, of course, we should avoid any incentives to imper= sonate >>>>>>> or we're wasting our time. This is partly why I'm trying to study u= p on >>>>>>> capabilities and asking for expert advice from folks like Alan Karp= and >>>>>>> Mark Miller (cc'd) >>>>>>> >>>>>>> As best I can understand it, the RS has only two choices, it can: >>>>>>> >>>>>>> - store an attribute of the RO a [DID, email address, GNAP AS >>>>>>> URL], or >>>>>>> - hand the RO a capability as a sort-of promise and avoid making >>>>>>> any entries in an ACL or equivalent. >>>>>>> >>>>>>> When a token comes back to the RS, it will either be: >>>>>>> >>>>>>> - validated according to something associated with the stored RO >>>>>>> attribute, or >>>>>>> - signed by the RS itself. >>>>>>> >>>>>>> Either way, trust in the client seems moot. >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer >>>>>>> wrote: >>>>>>> >>>>>>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker < >>>>>>>> tobias.looker@mattr.global> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> > A client might not have a DID but it could have a VC as a >>>>>>>>> certificate of authenticity linked to some audit mechanism. >>>>>>>>> >>>>>>>>> To me a VC would come under the assertions umbrella (that is to >>>>>>>>> say a VC could be one type of valid assertion). The client may po= ssess or >>>>>>>>> been presented with a VC that it could include in its request to = the AS as >>>>>>>>> a way to identify the subject and perhaps prove authentication an= d >>>>>>>>> authorization. >>>>>>>>> >>>>>>>> >>>>>>>> I do not assume that the client that interacts with the AS to make >>>>>>>> a request and receive a token is the same as the client that will = present >>>>>>>> the token to the RS. In the US HIPAA use-case, for example, the ro= ot of >>>>>>>> trust is a contract between the patient-subject and the doctor-req= uesting >>>>>>>> party but the doctor workflow is expected to delegate the token to= some >>>>>>>> other end-user that may be using a totally different client such a= s an EHR. >>>>>>>> >>>>>>>> >>>>>>>> If the client that gets the token is not same as the client that >>>>>>>> uses the token, that is a violation of core security principles as= it >>>>>>>> allows for (and really designs for) impersonation by client softwa= re. I >>>>>>>> would have no reason to trust client software that would hand its >>>>>>>> credentials over to another piece of software, and in fact I shoul= dn=E2=80=99t >>>>>>>> trust it. >>>>>>>> >>>>>>>> I think you may be conflating several different kinds of parties >>>>>>>> under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80= =99s entirely possible that one >>>>>>>> client might call an RS that in turn acts as a client for somethin= g else >>>>>>>> down stream. But each of those hops is different from the last. >>>>>>>> >>>>>>>> =E2=80=94 Justin >>>>>>>> >>>>>>>> --000000000000c09d2705bdc851e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    There are 2 different things :
    - there's a generic protocol where the client doesn'= t need to understand the token, based on some joint knowledge between the R= S and the AS (i.e. what these tokens represent)
    - an= d there could be some additional assumptions (e.g. token format, RS preflig= ht, etc.) on how the RS gets involved in a more dynamic way.=C2=A0

    Both views are valid, but the go= al is to keep easy things simple, and allow complex stuff too.=C2=A0
    <= div dir=3D"auto">
    "if the token is opaque, = then of course it has to be introspected by some entity the RS trusts, such= as an AS." not necessarily, it's entirely possible for the RS to = simply say "thanks reputable AS, I accept to process that access token= ". Or you might introspect at run time. Or in some more sensitive scen= arii you might really want to go one step further and indeed establish some= agreement on what tokens mean. All I'm saying is that there are shades= in what is possible.=C2=A0

    On your l= ast point that's just to say that the client posture may be part of the= policy decision (since you asked if the client matters).=C2=A0

    Fabien=C2=A0

    Le jeu. 18 m= ars 2021 =C3=A0 05:21, Adrian Gropper <agropper@healthurl.com>= ; a =C3=A9crit=C2=A0:
    ... "the knowledge the AS has of the RO" is a combination of = policies the RO controls and the promise the RO received from the RS.
    <= br>Once the RS has made and signed a promise in some form, why does it need= to know whether an AS was involved as long as the token has privileges tha= t are equal or less than the promise?

    As Alan says, if t= he token is opaque, then of course it has to be introspected=C2=A0by some e= ntity the RS trusts, such as an AS. Was that AS set as part of the promise = made to the RO?

    What does client registration have= to do with any of this?

    Adrian

    On Thu, Mar 1= 8, 2021 at 12:07 AM Fabien Imbault <fabien.imbault@gmai= l.com> wrote:
    Yes, = the AS is the policy manager and the token issuer for that delegation, base= d on the knowledge it has of the RO.=C2=A0
    We don= 9;t assume much on the lifecycle of the protected resource, except that the= y expect a valid access token issued by the AS to provide access.=C2=A0

    We defined client instances= related to one client software. The client does matter, we could even defi= ne its class or posture, but it's possible to make a request to the AS = even if you're not pre registered.=C2=A0

    Fabien=C2=A0

    Le jeu. 18 = mars 2021 =C3=A0 04:54, Adrian Gropper <agropper@healthur= l.com> a =C3=A9crit=C2=A0:
    Sure!=C2=A0

    Is there an AS involved in the delegation?= How and where in the lifecycle=C2=A0of the protected resource?=C2=A0
    <= br>
    Also your use of "the client" seems to imply that e= ither there is only one client or the client doesn't matter. Which is i= t?

    Adrian

    On Wed, Mar 17, 2021 at 11:43= PM Fabien Imbault <fabien.imbault@gmail.com= > wrote:
    Thanks for= that.=C2=A0

    Trying to r= eframe it:
    GNAP is defined as a delegation protocol = so the main intent is related to a delegate of the RO (i.e. the end user) t= hat wishes to access the RO's protected resources, through the client.= =C2=A0

    Fabien=C2=A0

    Le jeu. 18 mars 20= 21 =C3=A0 04:29, Adrian Gropper <agropper@heal= thurl.com> a =C3=A9crit=C2=A0:
    At various points in the lifecycle=C2=A0of the protected resource the= client at the resource server (RS) might be:
    • The RO (subject) = user agent trading payment for a service promise
    • The RO user agent = using the promise to access the protected resource
    • A delegate of th= e RO user agent using a different client
    What's vague is = where the GNAP AS enters the picture as described above. How would you desc= ribe it?

    Adrian

    On Wed, = Mar 17, 2021 at 10:20 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    =
    Hi Adrian

    I&= #39;m still confused why you're saying the terminology is vague.=C2=A0<= /div>
    I get the "power" neutrality is not to you= r liking, but RQ / user agent is no better in my view.=C2=A0

    Can you elaborate?=C2=A0

    Fabien=C2=A0

    Le jeu. 18 mars 20= 21 =C3=A0 00:18, Adrian Gropper <ag= ropper@healthurl.com> a =C3=A9crit=C2=A0:
    =
    I'm sure you're right. Our vague terminology=C2=A0= around client=C2=A0and=C2=A0end-user leads to my confusion. If GNAP is prim= arily about delegation=C2=A0then, of course, we should=C2=A0avoid any incen= tives to impersonate or we're wasting our time. This is partly why I= 9;m trying to study up on capabilities and asking for expert advice from fo= lks like Alan Karp and Mark Miller (cc'd)

    As best I = can understand it, the RS has only two choices, it can:
    • s= tore an attribute of the RO a [DID, email address, GNAP AS URL], or
      • hand the RO a capability as a sort-of promise and avoid making any entries= in an ACL or equivalent.
    When a token comes back to the RS, = it will either be:
    • validated according to something assoc= iated with the stored RO attribute, or
    • signed by the RS itself.=
    Either way, trust in the client seems moot.

    Adrian



    On Wed, Mar = 17, 2021 at 5:29 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 17, 2021, at 4:55= PM, Adrian Gropper <agr= opper@healthurl.com> wrote:

    On Wed, Mar 17, 2021 at 4:23 PM Tobias= Looker <tobias.look= er@mattr.global> wrote:
    <snip>
    > A client might n= ot have a DID but it could have a VC as a certificate of authenticity linke= d to some audit mechanism.

    To me a VC would come u= nder the assertions umbrella (that is to say a VC could be one type of vali= d assertion). The client may possess or been presented with a VC that it co= uld include in its request to the AS as a way to identify the subject and p= erhaps prove authentication and authorization.

    I do not assume that the client that interacts with the AS = to make a request and receive a token is the same as the client that will p= resent the token to the RS. In the US HIPAA use-case, for example, the root= of trust is a contract between the patient-subject and the doctor-requesti= ng party but the doctor workflow is expected to delegate the token to some = other end-user that may be using a totally different client such as an EHR.=


    If the c= lient that gets the token is not same as the client that uses the token, th= at is a violation of core security principles as it allows for (and really = designs for) impersonation by client software. I would have no reason to tr= ust client software that would hand its credentials over to another piece o= f software, and in fact I shouldn=E2=80=99t trust it.=C2=A0

    <= /div>
    I think you may be conflating several different kinds of parties = under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80=99s enti= rely possible that one client might call an RS that in turn acts as a clien= t for something else down stream. But each of those hops is different from = the last.

    =C2=A0=E2=80=94 Justin

    --000000000000c09d2705bdc851e0-- From nobody Thu Mar 18 04:53:07 2021 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 C9EC23A2914 for ; Thu, 18 Mar 2021 04:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 kzFWmAwP7yyM for ; Thu, 18 Mar 2021 04:53:03 -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 632143A2915 for ; Thu, 18 Mar 2021 04:53:03 -0700 (PDT) Received: from [192.168.1.22] (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 12IBquEo014992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Mar 2021 07:52:56 -0400 From: Justin Richer Message-Id: <16A7F150-6AD9-410F-BC14-7CCC1D580BB3@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_6ACB2929-28FB-4F90-93DA-163C3341A0D3" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 18 Mar 2021 07:52:56 -0400 In-Reply-To: Cc: Adrian Gropper , Tobias Looker , Fabien Imbault , GNAP Mailing List , Mark Miller To: Alan Karp References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 11:53:06 -0000 --Apple-Mail=_6ACB2929-28FB-4F90-93DA-163C3341A0D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 18, 2021, at 12:03 AM, Alan Karp wrote: >=20 > If the client that gets the token is not same as the client that uses = the token, that is a violation of core security principles as it allows = for (and really designs for) impersonation by client software. I would = have no reason to trust client software that would hand its credentials = over to another piece of software, and in fact I shouldn=E2=80=99t trust = it.=20 >=20 > How would you know if the client using the token is not the client it = was given to if the two clients are in cahoots? Sharing tokens is = actually a useful pattern. Client A running on your behalf could = delegate to Client B also running on your behalf, but it's sometimes = easier to share the credential. For example, you might not mind if the = client you use to retrieve the prices of stocks in your portfolio shares = permission to know what stocks you own with the client you use to plot = that data. You would only need to delegate if you wanted to sub-scope, = separately revoke, or have an audit trail.=20 =46rom the protocol's perspective, these are functionally the same = client. Remember, =E2=80=9Cclient instance=E2=80=9D is a role in the = system and it could be made up of many pieces of software deployed with = their own internal sharing system. If two pieces of software have the = same key material and token material, then they are, as far as GNAP is = concerned, the same client instance. It=E2=80=99s important not to = confuse the deployment pattern with the protocol roles. GNAP has mechanisms to enable the kind of explicitly derived delegation = that you=E2=80=99re describing here by allowing a client instance to ask = for a new token in the context of an existing grant request or an = existing access token. Those mechanisms have not been fully explored by = the WG yet but they are based on the OAuth 2 token exchange concept. =E2=80=94 Justin >=20 > -------------- > Alan Karp >=20 >=20 > On Wed, Mar 17, 2021 at 4:18 PM Adrian Gropper > wrote: > I'm sure you're right. Our vague terminology around client and = end-user leads to my confusion. If GNAP is primarily about delegation = then, of course, we should avoid any incentives to impersonate or we're = wasting our time. This is partly why I'm trying to study up on = capabilities and asking for expert advice from folks like Alan Karp and = Mark Miller (cc'd) >=20 > As best I can understand it, the RS has only two choices, it can: > store an attribute of the RO a [DID, email address, GNAP AS URL], or > hand the RO a capability as a sort-of promise and avoid making any = entries in an ACL or equivalent. > When a token comes back to the RS, it will either be: > validated according to something associated with the stored RO = attribute, or > signed by the RS itself. > Either way, trust in the client seems moot. >=20 > Adrian >=20 >=20 >=20 > On Wed, Mar 17, 2021 at 5:29 PM Justin Richer > wrote: > On Mar 17, 2021, at 4:55 PM, Adrian Gropper > wrote: >>=20 >> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker = > wrote: >> >> > A client might not have a DID but it could have a VC as a = certificate of authenticity linked to some audit mechanism. >>=20 >> To me a VC would come under the assertions umbrella (that is to say a = VC could be one type of valid assertion). The client may possess or been = presented with a VC that it could include in its request to the AS as a = way to identify the subject and perhaps prove authentication and = authorization. >>=20 >> I do not assume that the client that interacts with the AS to make a = request and receive a token is the same as the client that will present = the token to the RS. In the US HIPAA use-case, for example, the root of = trust is a contract between the patient-subject and the = doctor-requesting party but the doctor workflow is expected to delegate = the token to some other end-user that may be using a totally different = client such as an EHR. >>=20 >=20 > If the client that gets the token is not same as the client that uses = the token, that is a violation of core security principles as it allows = for (and really designs for) impersonation by client software. I would = have no reason to trust client software that would hand its credentials = over to another piece of software, and in fact I shouldn=E2=80=99t trust = it.=20 >=20 > I think you may be conflating several different kinds of parties under = the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80=99s = entirely possible that one client might call an RS that in turn acts as = a client for something else down stream. But each of those hops is = different from the last. >=20 > =E2=80=94 Justin >=20 --Apple-Mail=_6ACB2929-28FB-4F90-93DA-163C3341A0D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

    On Mar 18, 2021, at 12:03 AM, Alan Karp <alanhkarp@gmail.com>= wrote:

    If the client that gets the = token is not same as the client that uses the token, that is a violation = of core security principles as it allows for (and really designs for) = impersonation by client software. I would have no reason to trust client = software that would hand its credentials over to another piece of = software, and in fact I shouldn=E2=80=99t trust = it. 

    How would you know if the client = using the token is not the client it was given to if the two clients are = in cahoots?  Sharing tokens is actually a useful pattern.  = Client A running on your behalf could delegate to Client B also running = on your behalf, but it's sometimes easier to share the credential.  = For example, you might not mind if the client you use to retrieve the = prices of stocks in your portfolio shares permission to know what stocks = you own with the client you use to plot that data.  You would only = need to delegate if you wanted to sub-scope, separately revoke, or have = an audit trail. 

    =46rom the protocol's perspective, these are = functionally the same client. Remember, =E2=80=9Cclient instance=E2=80=9D = is a role in the system and it could be made up of many pieces of = software deployed with their own internal sharing system. If two pieces = of software have the same key material and token material, then they = are, as far as GNAP is concerned, the same client instance. It=E2=80=99s = important not to confuse the deployment pattern with the protocol = roles.

    GNAP has mechanisms to enable = the kind of explicitly derived delegation that you=E2=80=99re describing = here by allowing a client instance to ask for a new token in the context = of an existing grant request or an existing access token. Those = mechanisms have not been fully explored by the WG yet but they are based = on the OAuth 2 token exchange concept.

     =E2=80=94 Justin


    --------------
    Alan Karp


    On Wed, Mar 17, 2021 at 4:18 PM Adrian = Gropper <agropper@healthurl.com> wrote:
    I'm sure = you're right. Our vague terminology around = client and end-user leads to my confusion. If GNAP is = primarily about delegation then, of course, we should avoid = any incentives to impersonate or we're wasting our time. This is partly = why I'm trying to study up on capabilities and asking for expert advice = from folks like Alan Karp and Mark Miller (cc'd)

    As best I can understand it, the RS has = only two choices, it can:
    • store an attribute of the RO a [DID, email address, GNAP AS = URL], or
    • hand the RO a capability as a sort-of = promise and avoid making any entries in an ACL or = equivalent.
    When a token comes back to the RS, = it will either be:
    • validated according to something associated with the stored = RO attribute, or
    • signed by the RS = itself.
    Either way, trust in the client seems = moot.

    Adrian



    On Wed, Mar = 17, 2021 at 5:29 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 17, 2021, at 4:55 PM, Adrian Gropper = <agropper@healthurl.com> wrote:

    On = Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <tobias.looker@mattr.global> wrote:
    <snip>
    > A client might not = have a DID but it could have a VC as a certificate of authenticity = linked to some audit mechanism.

    To me a VC would come under the = assertions umbrella (that is to say a VC could be one type of valid = assertion). The client may possess or been presented with a VC that it = could include in its request to the AS as a way to identify the subject = and perhaps prove authentication and = authorization.

    I do not assume that the client that = interacts with the AS to make a request and receive a token is the same = as the client that will present the token to the RS. In the US HIPAA = use-case, for example, the root of trust is a contract between the = patient-subject and the doctor-requesting party but the doctor workflow = is expected to delegate the token to some other end-user that may be = using a totally different client such as an EHR.


    If the client that gets the token is not same as the client = that uses the token, that is a violation of core security principles as = it allows for (and really designs for) impersonation by client software. = I would have no reason to trust client software that would hand its = credentials over to another piece of software, and in fact I shouldn=E2=80= =99t trust it. 

    I think you may be conflating several different kinds of = parties under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80= =99s entirely possible that one client might call an RS that in turn = acts as a client for something else down stream. But each of those hops = is different from the last.

     =E2=80=94 Justin


    = --Apple-Mail=_6ACB2929-28FB-4F90-93DA-163C3341A0D3-- From nobody Thu Mar 18 04:57:04 2021 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 CA9683A292B for ; Thu, 18 Mar 2021 04:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 1wqRbWTrgiiH for ; Thu, 18 Mar 2021 04:57:00 -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 2B4D63A29E4 for ; Thu, 18 Mar 2021 04:56:46 -0700 (PDT) Received: from [192.168.1.22] (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 12IBugMP016233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Mar 2021 07:56:43 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_73519074-74FC-476A-9F14-0D6FB61CBEE1" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 18 Mar 2021 07:56:42 -0400 In-Reply-To: Cc: Adrian Gropper , Fabien Imbault , Tobias Looker , GNAP Mailing List , Mark Miller To: Alan Karp References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 11:57:03 -0000 --Apple-Mail=_73519074-74FC-476A-9F14-0D6FB61CBEE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 18, 2021, at 12:08 AM, Alan Karp wrote: >=20 > Adrian Gropper > wrote: >=20 > Is there an AS involved in the delegation? How and where in the = lifecycle of the protected resource?=20 >=20 > If tokens are certificates, the AS need not be involved in subsequent = delegations. The AS must be involved if the tokens are opaque.=20 Tokens are opaque to the client instance. They are not opaque to the AS. = They might be opaque to the RS, but that depends on the kind of = relationship the RS and AS have. GNAP should allow different options = here as there are different use cases for that. It would probably be worthwhile to separate the portions of the spec = that talk about the RS-AS relationship into its own standalone document. = A similar approach was taken in UMA2 and it was helpful. (Though = admittedly, as with anything, there are missteps there that we can = hopefully learn from.) =E2=80=94 Justin >=20 > -------------- > Alan Karp >=20 >=20 > On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper > wrote: > Sure!=20 >=20 > Is there an AS involved in the delegation? How and where in the = lifecycle of the protected resource?=20 >=20 > Also your use of "the client" seems to imply that either there is only = one client or the client doesn't matter. Which is it? >=20 > Adrian >=20 > On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault = > wrote: > Thanks for that.=20 >=20 > Trying to reframe it: > GNAP is defined as a delegation protocol so the main intent is related = to a delegate of the RO (i.e. the end user) that wishes to access the = RO's protected resources, through the client.=20 >=20 > Fabien=20 >=20 > Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper = > a =C3=A9crit : > At various points in the lifecycle of the protected resource the = client at the resource server (RS) might be: > The RO (subject) user agent trading payment for a service promise > The RO user agent using the promise to access the protected resource > A delegate of the RO user agent using a different client > What's vague is where the GNAP AS enters the picture as described = above. How would you describe it? >=20 > Adrian >=20 >=20 > On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault = > wrote: > Hi Adrian >=20 > I'm still confused why you're saying the terminology is vague.=20 > I get the "power" neutrality is not to your liking, but RQ / user = agent is no better in my view.=20 >=20 > Can you elaborate?=20 >=20 > Fabien=20 >=20 > Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper = > a =C3=A9crit : > I'm sure you're right. Our vague terminology around client and = end-user leads to my confusion. If GNAP is primarily about delegation = then, of course, we should avoid any incentives to impersonate or we're = wasting our time. This is partly why I'm trying to study up on = capabilities and asking for expert advice from folks like Alan Karp and = Mark Miller (cc'd) >=20 > As best I can understand it, the RS has only two choices, it can: > store an attribute of the RO a [DID, email address, GNAP AS URL], or > hand the RO a capability as a sort-of promise and avoid making any = entries in an ACL or equivalent. > When a token comes back to the RS, it will either be: > validated according to something associated with the stored RO = attribute, or > signed by the RS itself. > Either way, trust in the client seems moot. >=20 > Adrian >=20 >=20 >=20 > On Wed, Mar 17, 2021 at 5:29 PM Justin Richer > wrote: > On Mar 17, 2021, at 4:55 PM, Adrian Gropper > wrote: >>=20 >> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker = > wrote: >> >> > A client might not have a DID but it could have a VC as a = certificate of authenticity linked to some audit mechanism. >>=20 >> To me a VC would come under the assertions umbrella (that is to say a = VC could be one type of valid assertion). The client may possess or been = presented with a VC that it could include in its request to the AS as a = way to identify the subject and perhaps prove authentication and = authorization. >>=20 >> I do not assume that the client that interacts with the AS to make a = request and receive a token is the same as the client that will present = the token to the RS. In the US HIPAA use-case, for example, the root of = trust is a contract between the patient-subject and the = doctor-requesting party but the doctor workflow is expected to delegate = the token to some other end-user that may be using a totally different = client such as an EHR. >>=20 >=20 > If the client that gets the token is not same as the client that uses = the token, that is a violation of core security principles as it allows = for (and really designs for) impersonation by client software. I would = have no reason to trust client software that would hand its credentials = over to another piece of software, and in fact I shouldn=E2=80=99t trust = it.=20 >=20 > I think you may be conflating several different kinds of parties under = the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80=99s = entirely possible that one client might call an RS that in turn acts as = a client for something else down stream. But each of those hops is = different from the last. >=20 > =E2=80=94 Justin >=20 --Apple-Mail=_73519074-74FC-476A-9F14-0D6FB61CBEE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Mar 18, 2021, at 12:08 AM, Alan Karp <alanhkarp@gmail.com>= wrote:

    Adrian Gropper <agropper@healthurl.com> wrote:

    Is there an AS involved = in the delegation? How and where in the lifecycle of the protected = resource? 

    If tokens are certificates, the AS need = not be involved in subsequent delegations.  The AS must be involved = if the tokens are = opaque. 

    Tokens are opaque to the client instance. They are = not opaque to the AS. They might be opaque to the RS, but that depends = on the kind of relationship the RS and AS have. GNAP should allow = different options here as there are different use cases for = that.

    It would probably be = worthwhile to separate the portions of the spec that talk about the = RS-AS relationship into its own standalone document. A similar approach = was taken in UMA2 and it was helpful. (Though admittedly, as with = anything, there are missteps there that we can hopefully learn = from.)

     =E2=80=94 = Justin


    --------------
    Alan = Karp


    On Wed, Mar = 17, 2021 at 8:54 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Sure! 

    Is there an AS involved in the delegation? How and where in = the lifecycle of the protected resource? 

    Also your use of "the client" seems to = imply that either there is only one client or the client doesn't matter. = Which is it?

    Adrian

    On Wed, Mar = 17, 2021 at 11:43 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks for that. 

    Trying to reframe = it:
    GNAP is defined as a delegation = protocol so the main intent is related to a delegate of the RO (i.e. the = end user) that wishes to access the RO's protected resources, through = the client. 

    Fabien 

    Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper = <agropper@healthurl.com> a =C3=A9crit :
    At = various points in the lifecycle of the protected resource the = client at the resource server (RS) might be:
    • The RO (subject) user agent trading payment = for a service promise
    • The RO user agent using the = promise to access the protected resource
    • A delegate = of the RO user agent using a different client
    What's vague is where the GNAP AS enters the picture as = described above. How would you describe it?
    Adrian


    On Wed, Mar 17, 2021 at 10:20 PM Fabien = Imbault <fabien.imbault@gmail.com> wrote:
    Hi = Adrian

    I'm still confused why you're saying the terminology is = vague. 
    I get the "power" = neutrality is not to your liking, but RQ / user agent is no better in my = view. 

    Can you elaborate? 

    Fabien 

    Le jeu. 18 = mars 2021 =C3=A0 00:18, Adrian Gropper <agropper@healthurl.com> a = =C3=A9crit :
    I'm sure = you're right. Our vague terminology around = client and end-user leads to my confusion. If GNAP is = primarily about delegation then, of course, we should avoid = any incentives to impersonate or we're wasting our time. This is partly = why I'm trying to study up on capabilities and asking for expert advice = from folks like Alan Karp and Mark Miller (cc'd)

    As best I can understand it, the RS has = only two choices, it can:
    • store an attribute of the RO a [DID, email address, GNAP AS = URL], or
    • hand the RO a capability as a sort-of = promise and avoid making any entries in an ACL or = equivalent.
    When a token comes back to the RS, = it will either be:
    • validated according to something associated with the stored = RO attribute, or
    • signed by the RS = itself.
    Either way, trust in the client seems = moot.

    Adrian



    On Wed, Mar = 17, 2021 at 5:29 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 17, 2021, at 4:55 PM, Adrian Gropper = <agropper@healthurl.com> = wrote:

    On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker = <tobias.looker@mattr.global> wrote:
    <snip>
    > A client might not = have a DID but it could have a VC as a certificate of authenticity = linked to some audit mechanism.

    To me a VC would come under the = assertions umbrella (that is to say a VC could be one type of valid = assertion). The client may possess or been presented with a VC that it = could include in its request to the AS as a way to identify the subject = and perhaps prove authentication and = authorization.

    I do not assume that the client that = interacts with the AS to make a request and receive a token is the same = as the client that will present the token to the RS. In the US HIPAA = use-case, for example, the root of trust is a contract between the = patient-subject and the doctor-requesting party but the doctor workflow = is expected to delegate the token to some other end-user that may be = using a totally different client such as an EHR.


    If the client that gets the token is not same as the client = that uses the token, that is a violation of core security principles as = it allows for (and really designs for) impersonation by client software. = I would have no reason to trust client software that would hand its = credentials over to another piece of software, and in fact I shouldn=E2=80= =99t trust it. 

    I think you may be conflating several different kinds of = parties under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80= =99s entirely possible that one client might call an RS that in turn = acts as a client for something else down stream. But each of those hops = is different from the last.

     =E2=80=94 Justin


    = --Apple-Mail=_73519074-74FC-476A-9F14-0D6FB61CBEE1-- From nobody Thu Mar 18 06:39:22 2021 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 09C8B3A2BDD for ; Thu, 18 Mar 2021 06:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 eVAPyfLeUVNA for ; Thu, 18 Mar 2021 06:39:18 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A482C3A2BDC for ; Thu, 18 Mar 2021 06:39:17 -0700 (PDT) Received: from [192.168.1.11] ([90.79.53.231]) by mwinf5d18 with ME id hpfB240044zJUWJ03pfB1W; Thu, 18 Mar 2021 14:39:14 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Thu, 18 Mar 2021 14:39:14 +0100 X-ME-IP: 90.79.53.231 To: Justin Richer , Alan Karp Cc: GNAP Mailing List , Adrian Gropper , Fabien Imbault , Mark Miller , Tobias Looker References: From: Denis Message-ID: <08a4567d-404f-effd-67b3-57f4cdeeab90@free.fr> Date: Thu, 18 Mar 2021 14:39:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9B9480A28CFF42722466B8E0" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 13:39:21 -0000 This is a multi-part message in MIME format. --------------9B9480A28CFF42722466B8E0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Justin, You wrote: Tokens are opaque to the client instance. This is certainly your point of view, but not mine. This topic is still under discussion under the issue #145 (Opaque / Non opaque access token) that you would like to close next week. But it closely relates to the issue #214 (Trust relationships) to which you have not yet participated. I took a look at the subject of this thread which is [GNAP] DID as sub_id or assertion?  We are far beyond the original topic of this thread. Denis > On Mar 18, 2021, at 12:08 AM, Alan Karp > wrote: >> >> Adrian Gropper > > wrote: >> >> >> Is there an AS involved in the delegation? How and where in the >> lifecycle of the protected resource? >> >> >> If tokens are certificates, the AS need not be involved in subsequent >> delegations.  The AS must be involved if the tokens are opaque. > > Tokens are opaque to the client instance. They are not opaque to the > AS. They might be opaque to the RS, but that depends on the kind of > relationship the RS and AS have. GNAP should allow different options > here as there are different use cases for that. > > It would probably be worthwhile to separate the portions of the spec > that talk about the RS-AS relationship into its own standalone > document. A similar approach was taken in UMA2 and it was helpful. > (Though admittedly, as with anything, there are missteps there that we > can hopefully learn from.) > >  — Justin > >> >> -------------- >> Alan Karp >> >> >> On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper >> > wrote: >> >> Sure! >> >> Is there an AS involved in the delegation? How and where in the >> lifecycle of the protected resource? >> >> Also your use of "the client" seems to imply that either there is >> only one client or the client doesn't matter. Which is it? >> >> Adrian >> >> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault >> > wrote: >> >> Thanks for that. >> >> Trying to reframe it: >> GNAP is defined as a delegation protocol so the main intent >> is related to a delegate of the RO (i.e. the end user) that >> wishes to access the RO's protected resources, through the >> client. >> >> Fabien >> >> Le jeu. 18 mars 2021 à 04:29, Adrian Gropper >> > a >> écrit : >> >> At various points in the lifecycle of the protected >> resource the client at the resource server (RS) might be: >> >> * The RO (subject) user agent trading payment for a >> service promise >> * The RO user agent using the promise to access the >> protected resource >> * A delegate of the RO user agent using a different client >> >> What's vague is where the GNAP AS enters the picture as >> described above. How would you describe it? >> >> Adrian >> >> >> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault >> > > wrote: >> >> Hi Adrian >> >> I'm still confused why you're saying the terminology >> is vague. >> I get the "power" neutrality is not to your liking, >> but RQ / user agent is no better in my view. >> >> Can you elaborate? >> >> Fabien >> >> Le jeu. 18 mars 2021 à 00:18, Adrian Gropper >> > > a écrit : >> >> I'm sure you're right. Our vague >> terminology around client and end-user leads to >> my confusion. If GNAP is primarily about >> delegation then, of course, we should avoid any >> incentives to impersonate or we're wasting our >> time. This is partly why I'm trying to study up >> on capabilities and asking for expert advice from >> folks like Alan Karp and Mark Miller (cc'd) >> >> As best I can understand it, the RS has only two >> choices, it can: >> >> * store an attribute of the RO a [DID, email >> address, GNAP AS URL], or >> * hand the RO a capability as a sort-of promise >> and avoid making any entries in an ACL or >> equivalent. >> >> When a token comes back to the RS, it will either be: >> >> * validated according to something associated >> with the stored RO attribute, or >> * signed by the RS itself. >> >> Either way, trust in the client seems moot. >> >> Adrian >> >> >> >> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer >> > wrote: >> >> On Mar 17, 2021, at 4:55 PM, Adrian Gropper >> > > wrote: >>> >>> On Wed, Mar 17, 2021 at 4:23 PM Tobias >>> Looker >> > wrote: >>> >>> >>> > A client might not have a DID but it >>> could have a VC as a certificate of >>> authenticity linked to some audit mechanism. >>> >>> To me a VC would come under the >>> assertions umbrella (that is to say a VC >>> could be one type of valid assertion). >>> The client may possess or been presented >>> with a VC that it could include in its >>> request to the AS as a way to identify >>> the subject and perhaps prove >>> authentication and authorization. >>> >>> >>> I do not assume that the client that >>> interacts with the AS to make a request and >>> receive a token is the same as the client >>> that will present the token to the RS. In >>> the US HIPAA use-case, for example, the root >>> of trust is a contract between the >>> patient-subject and the doctor-requesting >>> party but the doctor workflow is expected to >>> delegate the token to some other end-user >>> that may be using a totally different client >>> such as an EHR. >>> >> >> If the client that gets the token is not same >> as the client that uses the token, that is a >> violation of core security principles as it >> allows for (and really designs for) >> impersonation by client software. I would >> have no reason to trust client software that >> would hand its credentials over to another >> piece of software, and in fact I shouldn’t >> trust it. >> >> I think you may be conflating several >> different kinds of parties under the “client” >> umbrella here, though. It’s entirely possible >> that one client might call an RS that in turn >> acts as a client for something else down >> stream. But each of those hops is different >> from the last. >> >>  — Justin >> > > --------------9B9480A28CFF42722466B8E0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
    Hi Justin,

    You wrote:
    Tokens are opaque to the client instance.
    This is certainly your point of view, but not mine. This topic is still under discussion under the issue #145 (Opaque / Non opaque access token)
    that you would like to close next week. But it closely relates to the issue #214 (Trust relationships) to which you have not yet participated.

    I took a look at the subject of this thread which is [GNAP] DID as sub_id or assertion?  We are far beyond the original topic of this thread.

    Denis

    On Mar 18, 2021, at 12:08 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Adrian Gropper <agropper@healthurl.com> wrote:

    Is there an AS involved in the delegation? How and where in the lifecycle of the protected resource? 

    If tokens are certificates, the AS need not be involved in subsequent delegations.  The AS must be involved if the tokens are opaque. 

    Tokens are opaque to the client instance. They are not opaque to the AS. They might be opaque to the RS, but that depends on the kind of relationship the RS and AS have. GNAP should allow different options here as there are different use cases for that.

    It would probably be worthwhile to separate the portions of the spec that talk about the RS-AS relationship into its own standalone document. A similar approach was taken in UMA2 and it was helpful. (Though admittedly, as with anything, there are missteps there that we can hopefully learn from.)

     — Justin


    --------------
    Alan Karp


    On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Sure! 

    Is there an AS involved in the delegation? How and where in the lifecycle of the protected resource? 

    Also your use of "the client" seems to imply that either there is only one client or the client doesn't matter. Which is it?

    Adrian

    On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks for that. 

    Trying to reframe it:
    GNAP is defined as a delegation protocol so the main intent is related to a delegate of the RO (i.e. the end user) that wishes to access the RO's protected resources, through the client. 

    Fabien 

    Le jeu. 18 mars 2021 à 04:29, Adrian Gropper <agropper@healthurl.com> a écrit :
    At various points in the lifecycle of the protected resource the client at the resource server (RS) might be:
    • The RO (subject) user agent trading payment for a service promise
    • The RO user agent using the promise to access the protected resource
    • A delegate of the RO user agent using a different client
    What's vague is where the GNAP AS enters the picture as described above. How would you describe it?

    Adrian


    On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Adrian

    I'm still confused why you're saying the terminology is vague. 
    I get the "power" neutrality is not to your liking, but RQ / user agent is no better in my view. 

    Can you elaborate? 

    Fabien 

    Le jeu. 18 mars 2021 à 00:18, Adrian Gropper <agropper@healthurl.com> a écrit :
    I'm sure you're right. Our vague terminology around client and end-user leads to my confusion. If GNAP is primarily about delegation then, of course, we should avoid any incentives to impersonate or we're wasting our time. This is partly why I'm trying to study up on capabilities and asking for expert advice from folks like Alan Karp and Mark Miller (cc'd)

    As best I can understand it, the RS has only two choices, it can:
    • store an attribute of the RO a [DID, email address, GNAP AS URL], or
    • hand the RO a capability as a sort-of promise and avoid making any entries in an ACL or equivalent.
    When a token comes back to the RS, it will either be:
    • validated according to something associated with the stored RO attribute, or
    • signed by the RS itself.
    Either way, trust in the client seems moot.

    Adrian



    On Wed, Mar 17, 2021 at 5:29 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 17, 2021, at 4:55 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <tobias.looker@mattr.global> wrote:
    <snip>
    > A client might not have a DID but it could have a VC as a certificate of authenticity linked to some audit mechanism.

    To me a VC would come under the assertions umbrella (that is to say a VC could be one type of valid assertion). The client may possess or been presented with a VC that it could include in its request to the AS as a way to identify the subject and perhaps prove authentication and authorization.

    I do not assume that the client that interacts with the AS to make a request and receive a token is the same as the client that will present the token to the RS. In the US HIPAA use-case, for example, the root of trust is a contract between the patient-subject and the doctor-requesting party but the doctor workflow is expected to delegate the token to some other end-user that may be using a totally different client such as an EHR.


    If the client that gets the token is not same as the client that uses the token, that is a violation of core security principles as it allows for (and really designs for) impersonation by client software. I would have no reason to trust client software that would hand its credentials over to another piece of software, and in fact I shouldn’t trust it. 

    I think you may be conflating several different kinds of parties under the “client” umbrella here, though. It’s entirely possible that one client might call an RS that in turn acts as a client for something else down stream. But each of those hops is different from the last.

     — Justin




    --------------9B9480A28CFF42722466B8E0-- From nobody Thu Mar 18 06:42:19 2021 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 3DB6F3A2BEF for ; Thu, 18 Mar 2021 06:42:18 -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, 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 V4QYi7Dv94_R for ; Thu, 18 Mar 2021 06:42:16 -0700 (PDT) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 1D5A33A2BEE for ; Thu, 18 Mar 2021 06:42:16 -0700 (PDT) Received: by mail-il1-x129.google.com with SMTP id z9so4878599ilb.4 for ; Thu, 18 Mar 2021 06:42: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=pMH/xs9r62UyqjXvKuL3LN3fVGZQjOvdj3rEtyInn30=; b=c6ACxV0NN8K8kA63dH8/6Zwc/Fcr/+XReoJA+rZow00DyjH/f3ucegu9G+PMmmTH6T LXJ0tsMAM8f9W3Mtaiv/bA5GPd9mMMOWPr9+MyiwlLpt4dlbSPz+tUT1v9BN4u1mEmWB C0+1qRPZXZScIBYoszag49rhxibpJxvZDmDWsVz+UEPmbxq8usjJPB548rs8Wvphhq35 URf9anmWPXW8aqmvUhqnAvOnZaowPT0+Uasth4bBHUSs72LUP+yyT51JQGIqrJGw0Uxd rBMBJaUaLpOQO+5UvxRhvg2G2b4eMVTJsitqbqj/JizHZ96oSb6NY2UNnS6DWK+ehLV/ 03Wg== 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=pMH/xs9r62UyqjXvKuL3LN3fVGZQjOvdj3rEtyInn30=; b=qsK2L9B8OmhWRf2vyJ/S5S/LIKlmywANCLOQHiIz9k8vdR624gg09KJqy6Z42rSeKe Eg9SgMEXVClm2zTnpnE5TGoAqBvHs7NJ0pzWgwTgq5Gi+xIEuWEIuU3nXbLJQfUi54uc KkwyNiBtLSBRjstVwC5KtwvU/6JTl9N/vZn5AN/GfsPCYigypKMS9r/JxpL9uZ5q9m/t LO/Kb4BI6vxgpSg0yPPDBFSHRnXUxyGLbzSPVkehX32oV2nvW2elA99iMQU19sQvdBDm mIyZqu19vjso7Tc4EJ+71t02QIjLXM1k8E1Owmhihnvnc/UXo5zu+zXaHhGxC+0coCxY w6+g== X-Gm-Message-State: AOAM531IUAECmNzarhfCFZqDDSwc5BBplUJr6pAVIzUVBd7Rp3vrlqli 0CtekFhx4xq0NODlS5VQu+DkMuYpSlGm3AxmE4Q= X-Google-Smtp-Source: ABdhPJztTgLhkTrEizM6fosnwoIM2odfLb1dhuEahn8AJD4We8v0ljskPlx4YSiTYFPYxAyHVAPaLZ4QWBgmFoRvytE= X-Received: by 2002:a92:1a11:: with SMTP id a17mr11987287ila.188.1616074934209; Thu, 18 Mar 2021 06:42:14 -0700 (PDT) MIME-Version: 1.0 References: <08a4567d-404f-effd-67b3-57f4cdeeab90@free.fr> In-Reply-To: <08a4567d-404f-effd-67b3-57f4cdeeab90@free.fr> From: Fabien Imbault Date: Thu, 18 Mar 2021 14:42:03 +0100 Message-ID: To: Denis Cc: Justin Richer , Alan Karp , GNAP Mailing List , Adrian Gropper , Mark Miller , Tobias Looker Content-Type: multipart/alternative; boundary="000000000000624fda05bdcfc497" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 13:42:18 -0000 --000000000000624fda05bdcfc497 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes I think we can close the current thread. Compared to the original objective of the thread, I just want to summarize what I understood as a rough consensus for the WG : go along with sub_ids, and consider DIDs as identifiers (knowing that the demand has been pushed to the related WG). Best Fabien On Thu, Mar 18, 2021 at 2:39 PM Denis wrote: > Hi Justin, > > You wrote: > > Tokens are opaque to the client instance. > > This is certainly your point of view, but not mine. This topic is still > under discussion under the issue #145 (Opaque / Non opaque access token) > that you would like to close next week. But it closely relates to the > issue #214 (Trust relationships) to which you have not yet participated. > > I took a look at the subject of this thread which is [GNAP] DID as sub_id > or assertion? We are far beyond the original topic of this thread. > > Denis > > On Mar 18, 2021, at 12:08 AM, Alan Karp wrote: > > > Adrian Gropper wrote: > >> >> Is there an AS involved in the delegation? How and where in the >> lifecycle of the protected resource? >> > > If tokens are certificates, the AS need not be involved in subsequent > delegations. The AS must be involved if the tokens are opaque. > > > Tokens are opaque to the client instance. They are not opaque to the AS. > They might be opaque to the RS, but that depends on the kind of > relationship the RS and AS have. GNAP should allow different options here > as there are different use cases for that. > > It would probably be worthwhile to separate the portions of the spec that > talk about the RS-AS relationship into its own standalone document. A > similar approach was taken in UMA2 and it was helpful. (Though admittedly= , > as with anything, there are missteps there that we can hopefully learn > from.) > > =E2=80=94 Justin > > > -------------- > Alan Karp > > > On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper > wrote: > >> Sure! >> >> Is there an AS involved in the delegation? How and where in the >> lifecycle of the protected resource? >> >> Also your use of "the client" seems to imply that either there is only >> one client or the client doesn't matter. Which is it? >> >> Adrian >> >> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault >> wrote: >> >>> Thanks for that. >>> >>> Trying to reframe it: >>> GNAP is defined as a delegation protocol so the main intent is related >>> to a delegate of the RO (i.e. the end user) that wishes to access the R= O's >>> protected resources, through the client. >>> >>> Fabien >>> >>> Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper a >>> =C3=A9crit : >>> >>>> At various points in the lifecycle of the protected resource the clien= t >>>> at the resource server (RS) might be: >>>> >>>> - The RO (subject) user agent trading payment for a service promise >>>> - The RO user agent using the promise to access the protected >>>> resource >>>> - A delegate of the RO user agent using a different client >>>> >>>> What's vague is where the GNAP AS enters the picture as described >>>> above. How would you describe it? >>>> >>>> Adrian >>>> >>>> >>>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Hi Adrian >>>>> >>>>> I'm still confused why you're saying the terminology is vague. >>>>> I get the "power" neutrality is not to your liking, but RQ / user >>>>> agent is no better in my view. >>>>> >>>>> Can you elaborate? >>>>> >>>>> Fabien >>>>> >>>>> Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper >>>>> a =C3=A9crit : >>>>> >>>>>> I'm sure you're right. Our vague terminology around >>>>>> client and end-user leads to my confusion. If GNAP is primarily abou= t >>>>>> delegation then, of course, we should avoid any incentives to impers= onate >>>>>> or we're wasting our time. This is partly why I'm trying to study up= on >>>>>> capabilities and asking for expert advice from folks like Alan Karp = and >>>>>> Mark Miller (cc'd) >>>>>> >>>>>> As best I can understand it, the RS has only two choices, it can: >>>>>> >>>>>> - store an attribute of the RO a [DID, email address, GNAP AS >>>>>> URL], or >>>>>> - hand the RO a capability as a sort-of promise and avoid making >>>>>> any entries in an ACL or equivalent. >>>>>> >>>>>> When a token comes back to the RS, it will either be: >>>>>> >>>>>> - validated according to something associated with the stored RO >>>>>> attribute, or >>>>>> - signed by the RS itself. >>>>>> >>>>>> Either way, trust in the client seems moot. >>>>>> >>>>>> Adrian >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer >>>>>> wrote: >>>>>> >>>>>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker < >>>>>>> tobias.looker@mattr.global> wrote: >>>>>>> >>>>>>>> >>>>>>>> > A client might not have a DID but it could have a VC as a >>>>>>>> certificate of authenticity linked to some audit mechanism. >>>>>>>> >>>>>>>> To me a VC would come under the assertions umbrella (that is to sa= y >>>>>>>> a VC could be one type of valid assertion). The client may possess= or been >>>>>>>> presented with a VC that it could include in its request to the AS= as a way >>>>>>>> to identify the subject and perhaps prove authentication and autho= rization. >>>>>>>> >>>>>>> >>>>>>> I do not assume that the client that interacts with the AS to make = a >>>>>>> request and receive a token is the same as the client that will pre= sent the >>>>>>> token to the RS. In the US HIPAA use-case, for example, the root of= trust >>>>>>> is a contract between the patient-subject and the doctor-requesting= party >>>>>>> but the doctor workflow is expected to delegate the token to some o= ther >>>>>>> end-user that may be using a totally different client such as an EH= R. >>>>>>> >>>>>>> >>>>>>> If the client that gets the token is not same as the client that >>>>>>> uses the token, that is a violation of core security principles as = it >>>>>>> allows for (and really designs for) impersonation by client softwar= e. I >>>>>>> would have no reason to trust client software that would hand its >>>>>>> credentials over to another piece of software, and in fact I should= n=E2=80=99t >>>>>>> trust it. >>>>>>> >>>>>>> I think you may be conflating several different kinds of parties >>>>>>> under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80= =99s entirely possible that one >>>>>>> client might call an RS that in turn acts as a client for something= else >>>>>>> down stream. But each of those hops is different from the last. >>>>>>> >>>>>>> =E2=80=94 Justin >>>>>>> >>>>>>> > > > --000000000000624fda05bdcfc497 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Yes I think we can close the current thread.=C2=A0
    Com= pared to the original objective of the thread, I just want to summarize wha= t I understood as a rough consensus for the WG : go along with sub_ids, and= consider DIDs as identifiers (knowing that the demand has been pushed to t= he related WG).

    Best
    Fabien=C2=A0
    <= /div>
    O= n Thu, Mar 18, 2021 at 2:39 PM Denis <denis.ietf@free.fr> wrote:
    =20 =20 =20
    Hi Justin,

    You wrote:
    Tokens are opaque to the client instance.
    This is certainly your point of view, but not mine. This topic is still under discussion under the issue #145 (Opaque / Non opaque access token)
    that you would like to close next week. But it closely relates to the issue #214 (Trust relationships) to which you have not yet participated.

    I took a look at the subject of this thread which is [GNAP] DID as sub_id or assertion?=C2=A0 We are far beyond the original topic of this thread.

    Denis

    =20 On Mar 18, 2021, at 12:08 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    =20
    Adrian Gropper <agropper@healthur= l.com> wrote:

    Is there an AS involved in the delegation? How and where in the lifecycle=C2=A0of th= e protected resource?=C2=A0

    If tokens are certificates, the AS need not be involved in subsequent delegations.=C2=A0 The AS must be involved if the tokens are opaque.=C2=A0

    Tokens are opaque to the client instance. They are not opaque to the AS. They might be opaque to the RS, but that depends on the kind of relationship the RS and AS have. GNAP should allow different options here as there are different use cases for that.

    It would probably be worthwhile to separate the portions of the spec that talk about the RS-AS relationship into its own standalone document. A similar approach was taken in UMA2 and it was helpful. (Though admittedly, as with anything, there are missteps there that we can hopefully learn from.)

    =C2=A0=E2=80=94 Justin


    --------------
    Alan Karp


    On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Sure!=C2=A0

    Is there an AS involved in the delegation? How and where in the lifecycle=C2=A0of th= e protected resource?=C2=A0

    Also your use of "the client" seems to imply that either there is only one client or the client doesn't matter. Which is it?

    Adrian

    On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault <fabien.imbault@gmail.com&g= t; wrote:
    Thanks for that.=C2=A0

    Trying to reframe it:
    GNAP is defined as a delegation protocol so the main intent is related to a delegate of the RO (i.e. the end user) that wishes to access the RO's protecte= d resources, through the client.=C2=A0

    Fabien=C2=A0

    Le jeu. 1= 8 mars 2021 =C3=A0 04:29, Adrian Gropper <agropper@healthur= l.com> a =C3=A9crit=C2=A0:
    At various points in the lifecycle=C2=A0of the protected resource the client at the resource server (RS) might be:
    • The RO (subject) user agent trading payment for a service promise
    • The RO user agent using the promise to access the protected resource
    • A delegate of the RO user agent using a different client
    What's vague is where the GNAP AS enters the picture as described above. How would you describe it?

    Adrian


    On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault <fabien.imbault@gmail.co= m> wrote:
    Hi Adrian

    I'm still confused why you're saying the terminology is vague.=C2=A0
    I get the "power" neutrality is not t= o your liking, but RQ / user agent is no better in my view.=C2=A0

    Can you elaborate?=C2=A0

    Fabien=C2=A0

    L= e jeu. 18 mars 2021 =C3=A0 00:18, Adria= n Gropper <agropper@healthurl.co= m> a =C3=A9crit=C2=A0:
    I'm sure you're right. Our vague terminology=C2=A0around client=C2=A0and=C2=A0end-user leads= to my confusion. If GNAP is primarily about delegation=C2=A0then, of course, we should=C2=A0avoid any incentives to impersonate or we're wasting our time. This is partly why I'm trying to study up on capabilities and asking for expert advice from folks like Alan Karp and Mark Miller (cc'd)

    As best I can understand it, the RS has only two choices, it can:
    • store an attribute of the RO a [DID, email address, GNAP AS URL], or
    • hand the RO a capability as a sort-of promise and avoid making any entries in an ACL or equivalent.
    When a token comes back to the RS, it will either be:
    • validated according to something associated with the stored RO attribute, or
    • signed by the RS itself.
    Either way, trust in the client seems moot.

    Adrian



    On Wed, Mar 17, 2021 at 5:29 PM Justin Richer <jricher@mit.ed= u> wrote:
    On Mar 17, 2021, at 4:55 PM, Adrian Gropper <agropper@healthurl.com> wrote:
    On Wed= , Mar 17, 2021 at 4:23 PM Tobias Looker <tobias.looker@mattr.global> wrote:
    <snip>=
    > A client might not have a DID but it could have a VC as a certificate of authenticity linked to some audit mechanism.

    To me a VC would come under the assertions umbrella (that is to say a VC could be one type of valid assertion). The client may possess or been presented with a VC that it could include in its request to the AS as a way to identify the subject and perhaps prove authentication and authorization.

    I do not assume that the client that interacts with the AS to make a request and receive a token is the same as the client that will present the token to the RS. In the US HIPAA use-case, for example, the root of trust is a contract between the patient-subject and the doctor-requesting party but the doctor workflow is expected to delegate the token to some other end-user that may be using a totally different client such as an EHR.


    If the client that gets the token is not same as the client that uses the token, that is a violation of core security principles as it allows for (and really designs for) impersonation by client software. I would have no reason to trust client software that would hand its credentials over to another piece of software, and in fact I shouldn=E2=80=99t trust it.= =C2=A0

    I think you may be conflating several different kinds of parties under the =E2=80=9Cclient=E2= =80=9D umbrella here, though. It=E2=80=99s entirely possibl= e that one client might call an RS that in turn acts as a client for something else down stream. But each of those hops is different from the last.

    =C2=A0=E2=80=94 Justin



    --000000000000624fda05bdcfc497-- From nobody Thu Mar 18 07:04:38 2021 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 7B2A73A2C45 for ; Thu, 18 Mar 2021 07:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 dQAblJF_FBye for ; Thu, 18 Mar 2021 07:04:34 -0700 (PDT) Received: from mail-vs1-f49.google.com (mail-vs1-f49.google.com [209.85.217.49]) (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 15C7C3A2C46 for ; Thu, 18 Mar 2021 07:04:34 -0700 (PDT) Received: by mail-vs1-f49.google.com with SMTP id 124so1600151vsg.12 for ; Thu, 18 Mar 2021 07:04:34 -0700 (PDT) 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=iFkPShtfQOOaH7xyhk0YzvUVBXBy6XQra8UDLShyUkU=; b=VmKL8DUBNnF8JX63aWL2SALePljIiFxgXGSlpcYnPVFBCX4s7GEgvhZ4h/X9K2wCNr fr9Q2Ndiu9/GXOp/j1kNngqWu/ic0+i7zsavdC2jyG3wbtui1MWayhdtINfONG0FRmDq thKmeEuurEyEFpTK0Z1MW+H5jh0R3KicppOjjGJ7P+Ry7pAwDSIkDibT3EqTpyLUBBLe sLTO7/SFAFHcb4KAb4RuTbMVjJSR5dV9a9BA0Nvl9dcxxhF5C/yrCF1uxCyQQw6acQp/ LRf4wTjuOg+I9icwZImh5UrvRU2itySEO5knrZA5ATe0SKZ5qAp7JZAzg1lqlAGq19zz OpWg== X-Gm-Message-State: AOAM533YFw7gYxkW7QWKPk1EGrIBrogwglDEpgHV2boXwBopRmNUZ4/j WKVe1NS1ycw5bdoxEO3SKvYk+EWjvFRE0Asqph0mKIjzuSE= X-Google-Smtp-Source: ABdhPJzSoIi0IySpnJmYdC/1MxoRiuyiz938Pj9DbofnLQhM4zvE11ZqCJlKqnqS2TF0nZHlBAb4FqYaKWROmsjvjsY= X-Received: by 2002:a67:db84:: with SMTP id f4mr6788933vsk.20.1616076272877; Thu, 18 Mar 2021 07:04:32 -0700 (PDT) MIME-Version: 1.0 References: <08a4567d-404f-effd-67b3-57f4cdeeab90@free.fr> In-Reply-To: From: Adrian Gropper Date: Thu, 18 Mar 2021 10:04:20 -0400 Message-ID: To: Fabien Imbault Cc: Denis , Justin Richer , Alan Karp , GNAP Mailing List , Mark Miller , Tobias Looker Content-Type: multipart/alternative; boundary="0000000000002cc5d805bdd0149f" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 14:04:37 -0000 --0000000000002cc5d805bdd0149f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, I think we can close the current thread. Justin's explanation above of how we're using client is clear to me. Adrian On Thu, Mar 18, 2021 at 9:42 AM Fabien Imbault wrote: > Yes I think we can close the current thread. > Compared to the original objective of the thread, I just want to summariz= e > what I understood as a rough consensus for the WG : go along with sub_ids= , > and consider DIDs as identifiers (knowing that the demand has been pushed > to the related WG). > > Best > Fabien > > On Thu, Mar 18, 2021 at 2:39 PM Denis wrote: > >> Hi Justin, >> >> You wrote: >> >> Tokens are opaque to the client instance. >> >> This is certainly your point of view, but not mine. This topic is still >> under discussion under the issue #145 (Opaque / Non opaque access token) >> that you would like to close next week. But it closely relates to the >> issue #214 (Trust relationships) to which you have not yet participated. >> >> I took a look at the subject of this thread which is [GNAP] DID as sub_i= d >> or assertion? We are far beyond the original topic of this thread. >> >> Denis >> >> On Mar 18, 2021, at 12:08 AM, Alan Karp wrote: >> >> >> Adrian Gropper wrote: >> >>> >>> Is there an AS involved in the delegation? How and where in the >>> lifecycle of the protected resource? >>> >> >> If tokens are certificates, the AS need not be involved in subsequent >> delegations. The AS must be involved if the tokens are opaque. >> >> >> Tokens are opaque to the client instance. They are not opaque to the AS. >> They might be opaque to the RS, but that depends on the kind of >> relationship the RS and AS have. GNAP should allow different options her= e >> as there are different use cases for that. >> >> It would probably be worthwhile to separate the portions of the spec tha= t >> talk about the RS-AS relationship into its own standalone document. A >> similar approach was taken in UMA2 and it was helpful. (Though admittedl= y, >> as with anything, there are missteps there that we can hopefully learn >> from.) >> >> =E2=80=94 Justin >> >> >> -------------- >> Alan Karp >> >> >> On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper >> wrote: >> >>> Sure! >>> >>> Is there an AS involved in the delegation? How and where in the >>> lifecycle of the protected resource? >>> >>> Also your use of "the client" seems to imply that either there is only >>> one client or the client doesn't matter. Which is it? >>> >>> Adrian >>> >>> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault < >>> fabien.imbault@gmail.com> wrote: >>> >>>> Thanks for that. >>>> >>>> Trying to reframe it: >>>> GNAP is defined as a delegation protocol so the main intent is related >>>> to a delegate of the RO (i.e. the end user) that wishes to access the = RO's >>>> protected resources, through the client. >>>> >>>> Fabien >>>> >>>> Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper >>>> a =C3=A9crit : >>>> >>>>> At various points in the lifecycle of the protected resource the >>>>> client at the resource server (RS) might be: >>>>> >>>>> - The RO (subject) user agent trading payment for a service promis= e >>>>> - The RO user agent using the promise to access the protected >>>>> resource >>>>> - A delegate of the RO user agent using a different client >>>>> >>>>> What's vague is where the GNAP AS enters the picture as described >>>>> above. How would you describe it? >>>>> >>>>> Adrian >>>>> >>>>> >>>>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Hi Adrian >>>>>> >>>>>> I'm still confused why you're saying the terminology is vague. >>>>>> I get the "power" neutrality is not to your liking, but RQ / user >>>>>> agent is no better in my view. >>>>>> >>>>>> Can you elaborate? >>>>>> >>>>>> Fabien >>>>>> >>>>>> Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper >>>>>> a =C3=A9crit : >>>>>> >>>>>>> I'm sure you're right. Our vague terminology around >>>>>>> client and end-user leads to my confusion. If GNAP is primarily abo= ut >>>>>>> delegation then, of course, we should avoid any incentives to imper= sonate >>>>>>> or we're wasting our time. This is partly why I'm trying to study u= p on >>>>>>> capabilities and asking for expert advice from folks like Alan Karp= and >>>>>>> Mark Miller (cc'd) >>>>>>> >>>>>>> As best I can understand it, the RS has only two choices, it can: >>>>>>> >>>>>>> - store an attribute of the RO a [DID, email address, GNAP AS >>>>>>> URL], or >>>>>>> - hand the RO a capability as a sort-of promise and avoid making >>>>>>> any entries in an ACL or equivalent. >>>>>>> >>>>>>> When a token comes back to the RS, it will either be: >>>>>>> >>>>>>> - validated according to something associated with the stored RO >>>>>>> attribute, or >>>>>>> - signed by the RS itself. >>>>>>> >>>>>>> Either way, trust in the client seems moot. >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer >>>>>>> wrote: >>>>>>> >>>>>>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker < >>>>>>>> tobias.looker@mattr.global> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> > A client might not have a DID but it could have a VC as a >>>>>>>>> certificate of authenticity linked to some audit mechanism. >>>>>>>>> >>>>>>>>> To me a VC would come under the assertions umbrella (that is to >>>>>>>>> say a VC could be one type of valid assertion). The client may po= ssess or >>>>>>>>> been presented with a VC that it could include in its request to = the AS as >>>>>>>>> a way to identify the subject and perhaps prove authentication an= d >>>>>>>>> authorization. >>>>>>>>> >>>>>>>> >>>>>>>> I do not assume that the client that interacts with the AS to make >>>>>>>> a request and receive a token is the same as the client that will = present >>>>>>>> the token to the RS. In the US HIPAA use-case, for example, the ro= ot of >>>>>>>> trust is a contract between the patient-subject and the doctor-req= uesting >>>>>>>> party but the doctor workflow is expected to delegate the token to= some >>>>>>>> other end-user that may be using a totally different client such a= s an EHR. >>>>>>>> >>>>>>>> >>>>>>>> If the client that gets the token is not same as the client that >>>>>>>> uses the token, that is a violation of core security principles as= it >>>>>>>> allows for (and really designs for) impersonation by client softwa= re. I >>>>>>>> would have no reason to trust client software that would hand its >>>>>>>> credentials over to another piece of software, and in fact I shoul= dn=E2=80=99t >>>>>>>> trust it. >>>>>>>> >>>>>>>> I think you may be conflating several different kinds of parties >>>>>>>> under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80= =99s entirely possible that one >>>>>>>> client might call an RS that in turn acts as a client for somethin= g else >>>>>>>> down stream. But each of those hops is different from the last. >>>>>>>> >>>>>>>> =E2=80=94 Justin >>>>>>>> >>>>>>>> >> >> >> --0000000000002cc5d805bdd0149f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Yes, I think we can close the current thread. Justin's= explanation above of how we're using client is clear to me.=C2=A0
    =
    Adrian

    On Thu, Mar 18, 2021 at 9:42 AM Fabien Imbault &= lt;fabien.imbault@gmail.com= > wrote:
    Yes I think we can c= lose the current thread.=C2=A0
    Compared to the original objective of th= e thread, I just want to summarize what I understood as a rough consensus f= or the WG : go along with sub_ids, and consider DIDs as identifiers (knowin= g that the demand has been pushed to the related WG).

    <= div>Best
    Fabien=C2=A0

    <= div dir=3D"ltr" class=3D"gmail_attr">On Thu, Mar 18, 2021 at 2:39 PM Denis = <denis.ietf@free= .fr> wrote:
    =20 =20 =20
    Hi Justin,

    You wrote:
    Tokens are opaque to the client instance.
    This is certainly your point of view, but not mine. This topic is still under discussion under the issue #145 (Opaque / Non opaque access token)
    that you would like to close next week. But it closely relates to the issue #214 (Trust relationships) to which you have not yet participated.

    I took a look at the subject of this thread which is [GNAP] DID as sub_id or assertion?=C2=A0 We are far beyond the original topic of this thread.

    Denis

    =20 On Mar 18, 2021, at 12:08 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    =20
    Adrian Gropper <agropper@healthur= l.com> wrote:

    Is there an AS involved in the delegation? How and where in the lifecycle=C2=A0of th= e protected resource?=C2=A0

    If tokens are certificates, the AS need not be involved in subsequent delegations.=C2=A0 The AS must be involved if the tokens are opaque.=C2=A0

    Tokens are opaque to the client instance. They are not opaque to the AS. They might be opaque to the RS, but that depends on the kind of relationship the RS and AS have. GNAP should allow different options here as there are different use cases for that.

    It would probably be worthwhile to separate the portions of the spec that talk about the RS-AS relationship into its own standalone document. A similar approach was taken in UMA2 and it was helpful. (Though admittedly, as with anything, there are missteps there that we can hopefully learn from.)

    =C2=A0=E2=80=94 Justin


    --------------
    Alan Karp


    On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Sure!=C2=A0

    Is there an AS involved in the delegation? How and where in the lifecycle=C2=A0of th= e protected resource?=C2=A0

    Also your use of "the client" seems to imply that either there is only one client or the client doesn't matter. Which is it?

    Adrian

    On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault <fabien.imbault@gmail.com&g= t; wrote:
    Thanks for that.=C2=A0

    Trying to reframe it:
    GNAP is defined as a delegation protocol so the main intent is related to a delegate of the RO (i.e. the end user) that wishes to access the RO's protecte= d resources, through the client.=C2=A0

    Fabien=C2=A0

    Le jeu. 1= 8 mars 2021 =C3=A0 04:29, Adrian Gropper <agropper@healthur= l.com> a =C3=A9crit=C2=A0:
    At various points in the lifecycle=C2=A0of the protected resource the client at the resource server (RS) might be:
    • The RO (subject) user agent trading payment for a service promise
    • The RO user agent using the promise to access the protected resource
    • A delegate of the RO user agent using a different client
    What's vague is where the GNAP AS enters the picture as described above. How would you describe it?

    Adrian


    On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault <fabien.imbault@gmail.co= m> wrote:
    Hi Adrian

    I'm still confused why you're saying the terminology is vague.=C2=A0
    I get the "power" neutrality is not t= o your liking, but RQ / user agent is no better in my view.=C2=A0

    Can you elaborate?=C2=A0

    Fabien=C2=A0

    L= e jeu. 18 mars 2021 =C3=A0 00:18, Adria= n Gropper <agropper@healthurl.co= m> a =C3=A9crit=C2=A0:
    I'm sure you're right. Our vague terminology=C2=A0around client=C2=A0and=C2=A0end-user leads= to my confusion. If GNAP is primarily about delegation=C2=A0then, of course, we should=C2=A0avoid any incentives to impersonate or we're wasting our time. This is partly why I'm trying to study up on capabilities and asking for expert advice from folks like Alan Karp and Mark Miller (cc'd)

    As best I can understand it, the RS has only two choices, it can:
    • store an attribute of the RO a [DID, email address, GNAP AS URL], or
    • hand the RO a capability as a sort-of promise and avoid making any entries in an ACL or equivalent.
    When a token comes back to the RS, it will either be:
    • validated according to something associated with the stored RO attribute, or
    • signed by the RS itself.
    Either way, trust in the client seems moot.

    Adrian



    On Wed, Mar 17, 2021 at 5:29 PM Justin Richer <jricher@mit.ed= u> wrote:
    On Mar 17, 2021, at 4:55 PM, Adrian Gropper <agropper@healthurl.com> wrote:
    On Wed= , Mar 17, 2021 at 4:23 PM Tobias Looker <tobias.looker@mattr.global> wrote:
    <snip>=
    > A client might not have a DID but it could have a VC as a certificate of authenticity linked to some audit mechanism.

    To me a VC would come under the assertions umbrella (that is to say a VC could be one type of valid assertion). The client may possess or been presented with a VC that it could include in its request to the AS as a way to identify the subject and perhaps prove authentication and authorization.

    I do not assume that the client that interacts with the AS to make a request and receive a token is the same as the client that will present the token to the RS. In the US HIPAA use-case, for example, the root of trust is a contract between the patient-subject and the doctor-requesting party but the doctor workflow is expected to delegate the token to some other end-user that may be using a totally different client such as an EHR.


    If the client that gets the token is not same as the client that uses the token, that is a violation of core security principles as it allows for (and really designs for) impersonation by client software. I would have no reason to trust client software that would hand its credentials over to another piece of software, and in fact I shouldn=E2=80=99t trust it.= =C2=A0

    I think you may be conflating several different kinds of parties under the =E2=80=9Cclient=E2= =80=9D umbrella here, though. It=E2=80=99s entirely possibl= e that one client might call an RS that in turn acts as a client for something else down stream. But each of those hops is different from the last.

    =C2=A0=E2=80=94 Justin



    --0000000000002cc5d805bdd0149f-- From nobody Thu Mar 18 08:27:25 2021 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 54BE33A2DD5 for ; Thu, 18 Mar 2021 08:27:23 -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 2a2WrSPiRwPP for ; Thu, 18 Mar 2021 08:27:21 -0700 (PDT) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 09D623A2DD6 for ; Thu, 18 Mar 2021 08:27:21 -0700 (PDT) Received: by mail-qv1-xf2b.google.com with SMTP id d10so3358796qve.7 for ; Thu, 18 Mar 2021 08:27:20 -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=BXHNSkKk1+oS8qkexvMDuh9xmeDWSxNLejM7YZqml7c=; b=nz8uLAEHrPpJTf5G+u9UK0sktM6ZSpMARJPjIIAfAxeAmP3oKDOtHFJ3gsmYBBmisT youtff9CNk29CLyXCGtnX0nuP3DjtQ3XkoO+ZIevQg8RKfOC7EU+XFD+iCxeKThlq6Zm bftGfMcysB/4HEj3fgIKmAMjdglDc5MtRH+cligTyuwclSHmzEMG9SyUBw8wDe6mp2c8 NLmWsmjbW85qxMH2Nf89xApG+AHAy1iaQstV3dHgHarZEGQ33+GM5d4Ar42jYv5zhATl 2oJUONjxfD9OOvTu9h2KAEoSh13W4Px5K3byMXLaa8BooBcguU7Ri5/L/rcF9AyQODyr EAWQ== 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=BXHNSkKk1+oS8qkexvMDuh9xmeDWSxNLejM7YZqml7c=; b=V+jfdiUITR/JjrPpmlPRpHjywIhetf/joqK0z17uODS7pXO51NfRK7lK70otenrXM4 6c8tuooK6Y0+p+UA77beLY76qwwZ2u8TO5VrHb7a4RCrLRGJNqhcugRxG/CCR3c/OKKL qBWwDhHIRL2tf2xzNIMYDw9pGRw8j7y6wFSUD4gyGppzTnEcfRK5xrfUVOFgh5TAhlkE 1jilP2zPMlxGbRouy/+Yw1TTiNPr3LHsanXzW0xKLHku0tdFiNo601KpJgnvgblA4oTn 5LS+LAYlJoB/8eG0LOviIZbUz4ebqkV8DXrV15dKprrJyVWlqLwTZTNBdVkfskG+IRy+ B+RA== X-Gm-Message-State: AOAM533EcXt1QEKwIAtVdn9xZEO6yqf3NWnccmgawSnP6nxWwseUyHrE SyWSP5cS8Hj53iwARszFv6B1d6BKM7AxEYpeko4= X-Google-Smtp-Source: ABdhPJxBJva+AzcookQB2xpbFR4ALQgGwDT4wYr10eziOxMjPVf94lnrR2ABlw/QqpWafXeLqAmlnnlxz/YXxl2kGGw= X-Received: by 2002:a0c:eac9:: with SMTP id y9mr4810278qvp.58.1616081238894; Thu, 18 Mar 2021 08:27:18 -0700 (PDT) MIME-Version: 1.0 References: <16A7F150-6AD9-410F-BC14-7CCC1D580BB3@mit.edu> In-Reply-To: <16A7F150-6AD9-410F-BC14-7CCC1D580BB3@mit.edu> From: Alan Karp Date: Thu, 18 Mar 2021 08:27:07 -0700 Message-ID: To: Justin Richer Cc: Adrian Gropper , Tobias Looker , Fabien Imbault , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="0000000000002c2bad05bdd13c97" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 15:27:23 -0000 --0000000000002c2bad05bdd13c97 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Justin Richer wrote: > > From the protocol's perspective, these are functionally the same client. > Remember, =E2=80=9Cclient instance=E2=80=9D is a role in the system and i= t could be made up > of many pieces of software deployed with their own internal sharing syste= m. > If two pieces of software have the same key material and token material, > then they are, as far as GNAP is concerned, the same client instance. It= =E2=80=99s > important not to confuse the deployment pattern with the protocol roles. > That's exactly the right perspective. I've been surprised by how many people don't see it that way. > > GNAP has mechanisms to enable the kind of explicitly derived delegation > that you=E2=80=99re describing here by allowing a client instance to ask = for a new > token in the context of an existing grant request or an existing access > token. Those mechanisms have not been fully explored by the WG yet but th= ey > are based on the OAuth 2 token exchange concept. > You don't need token exchange if your tokens are certificates. -------------- Alan Karp On Thu, Mar 18, 2021 at 4:53 AM Justin Richer wrote: > > > On Mar 18, 2021, at 12:03 AM, Alan Karp wrote: > > If the client that gets the token is not same as the client that uses the > token, that is a violation of core security principles as it allows for > (and really designs for) impersonation by client software. I would have n= o > reason to trust client software that would hand its credentials over to > another piece of software, and in fact I shouldn=E2=80=99t trust it. > > > How would you know if the client using the token is not the client it was > given to if the two clients are in cahoots? Sharing tokens is actually a > useful pattern. Client A running on your behalf could delegate to Client= B > also running on your behalf, but it's sometimes easier to share the > credential. For example, you might not mind if the client you use to > retrieve the prices of stocks in your portfolio shares permission to know > what stocks you own with the client you use to plot that data. You would > only need to delegate if you wanted to sub-scope, separately revoke, or > have an audit trail. > > > From the protocol's perspective, these are functionally the same client. > Remember, =E2=80=9Cclient instance=E2=80=9D is a role in the system and i= t could be made up > of many pieces of software deployed with their own internal sharing syste= m. > If two pieces of software have the same key material and token material, > then they are, as far as GNAP is concerned, the same client instance. It= =E2=80=99s > important not to confuse the deployment pattern with the protocol roles. > > GNAP has mechanisms to enable the kind of explicitly derived delegation > that you=E2=80=99re describing here by allowing a client instance to ask = for a new > token in the context of an existing grant request or an existing access > token. Those mechanisms have not been fully explored by the WG yet but th= ey > are based on the OAuth 2 token exchange concept. > > =E2=80=94 Justin > > > -------------- > Alan Karp > > > On Wed, Mar 17, 2021 at 4:18 PM Adrian Gropper > wrote: > >> I'm sure you're right. Our vague terminology around client and end-user >> leads to my confusion. If GNAP is primarily about delegation then, of >> course, we should avoid any incentives to impersonate or we're wasting o= ur >> time. This is partly why I'm trying to study up on capabilities and aski= ng >> for expert advice from folks like Alan Karp and Mark Miller (cc'd) >> >> As best I can understand it, the RS has only two choices, it can: >> >> - store an attribute of the RO a [DID, email address, GNAP AS URL], o= r >> - hand the RO a capability as a sort-of promise and avoid making any >> entries in an ACL or equivalent. >> >> When a token comes back to the RS, it will either be: >> >> - validated according to something associated with the stored RO >> attribute, or >> - signed by the RS itself. >> >> Either way, trust in the client seems moot. >> >> Adrian >> >> >> >> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer wrote: >> >>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper >>> wrote: >>> >>> >>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker < >>> tobias.looker@mattr.global> wrote: >>> >>>> >>>> > A client might not have a DID but it could have a VC as a certificat= e >>>> of authenticity linked to some audit mechanism. >>>> >>>> To me a VC would come under the assertions umbrella (that is to say a >>>> VC could be one type of valid assertion). The client may possess or be= en >>>> presented with a VC that it could include in its request to the AS as = a way >>>> to identify the subject and perhaps prove authentication and authoriza= tion. >>>> >>> >>> I do not assume that the client that interacts with the AS to make a >>> request and receive a token is the same as the client that will present= the >>> token to the RS. In the US HIPAA use-case, for example, the root of tru= st >>> is a contract between the patient-subject and the doctor-requesting par= ty >>> but the doctor workflow is expected to delegate the token to some other >>> end-user that may be using a totally different client such as an EHR. >>> >>> >>> If the client that gets the token is not same as the client that uses >>> the token, that is a violation of core security principles as it allows= for >>> (and really designs for) impersonation by client software. I would have= no >>> reason to trust client software that would hand its credentials over to >>> another piece of software, and in fact I shouldn=E2=80=99t trust it. >>> >>> I think you may be conflating several different kinds of parties under >>> the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80=99s entire= ly possible that one client >>> might call an RS that in turn acts as a client for something else down >>> stream. But each of those hops is different from the last. >>> >>> =E2=80=94 Justin >>> >>> > --0000000000002c2bad05bdd13c97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Justin Richer <jricher@mit.edu> wrote:
    =

    From the protocol's perspective, these are function= ally the same client. Remember, =E2=80=9Cclient instance=E2=80=9D is a role= in the system and it could be made up of many pieces of software deployed = with their own internal sharing system. If two pieces of software have the = same key material and token material, then they are, as far as GNAP is conc= erned, the same client instance. It=E2=80=99s important not to confuse the = deployment pattern with the protocol roles.
    <= div>
    That's exactly the right perspective.=C2=A0 I've= been surprised by how many people don't see it that way.=C2=A0

    GNAP has mechanisms to enable the k= ind of explicitly derived delegation that you=E2=80=99re describing here by= allowing a client instance to ask for a new token in the context of an exi= sting grant request or an existing access token. Those mechanisms have not = been fully explored by the WG yet but they are based on the OAuth 2 token e= xchange concept.
    Yo= u don't need token exchange if your tokens are certificates.=C2=A0

    --------------
    Alan Karp


    On Thu, Mar 18, 2021 at = 4:53 AM Justin Richer <jricher@mit.ed= u> wrote:


    On Mar 18, 2021, at 12:03 AM, Alan Karp <alanhkarp@gmail.com> wrote:
    If the client that gets the token is not same as th= e client that uses the token, that is a violation of core security principl= es as it allows for (and really designs for) impersonation by client softwa= re. I would have no reason to trust client software that would hand its cre= dentials over to another piece of software, and in fact I shouldn=E2=80=99t= trust it.=C2=A0

    How would= you know if the client using the token is not the client it was given to i= f the two clients are in cahoots?=C2=A0 Sharing tokens is actually a useful= pattern.=C2=A0 Client A running on your behalf could delegate to Client B = also running on your behalf, but it's sometimes easier to share the cre= dential.=C2=A0 For example, you might not mind if the client you use to ret= rieve the prices of stocks in your portfolio shares permission to know what= stocks you own with the client you use to plot that data.=C2=A0 You would = only need to delegate if you wanted to sub-scope, separately revoke, or hav= e an audit trail.=C2=A0

    =
    From the protocol's perspective, these are functionally the same c= lient. Remember, =E2=80=9Cclient instance=E2=80=9D is a role in the system = and it could be made up of many pieces of software deployed with their own = internal sharing system. If two pieces of software have the same key materi= al and token material, then they are, as far as GNAP is concerned, the same= client instance. It=E2=80=99s important not to confuse the deployment patt= ern with the protocol roles.

    GNAP has mechanisms t= o enable the kind of explicitly derived delegation that you=E2=80=99re desc= ribing here by allowing a client instance to ask for a new token in the con= text of an existing grant request or an existing access token. Those mechan= isms have not been fully explored by the WG yet but they are based on the O= Auth 2 token exchange concept.

    =C2=A0=E2=80=94 Jus= tin


    --------------
    Alan Karp


    On Wed, Mar 17, 202= 1 at 4:18 PM Adrian Gropper <agropper@healthurl.com> wrote:
    I'm sure you= 9;re right. Our vague terminology=C2=A0around client=C2=A0and=C2=A0end-user= leads to my confusion. If GNAP is primarily about delegation=C2=A0then, of= course, we should=C2=A0avoid any incentives to impersonate or we're wa= sting our time. This is partly why I'm trying to study up on capabiliti= es and asking for expert advice from folks like Alan Karp and Mark Miller (= cc'd)

    As best I can understand it, the RS has only t= wo choices, it can:
    • store an attribute of the RO a [DID, = email address, GNAP AS URL], or
    • hand the RO a capability as a sort-= of promise and avoid making any entries in an ACL or equivalent.
    <= div>When a token comes back to the RS, it will either be:
      validated according to something associated with the stored RO attribute, = or
    • signed by the RS itself.
    Either way, trust in = the client seems moot.

    Adrian

    =


    On Wed, Mar 17, 2021 at 5:29 PM Justin Richer &l= t;jricher@mit.edu&= gt; wrote:
    = On Mar 17, 2021, at 4:55 PM, Adrian Gropper <agropper@healthurl.com> wrote:
    <= div>

    On= Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <tobias.looker@mattr.global> wro= te:
    <snip>
    > A client m= ight not have a DID but it could have a VC as a certificate of authenticity= linked to some audit mechanism.

    To me a VC would = come under the assertions umbrella (that is to say a VC could be one type o= f valid assertion). The client may possess or been presented with a VC that= it could include in its request to the AS as a way to identify the subject= and perhaps prove authentication and authorization.

    I do not assume that the client that interacts with t= he AS to make a request and receive a token is the same as the client that = will present the token to the RS. In the US HIPAA use-case, for example, th= e root of trust is a contract between the patient-subject and the doctor-re= questing party but the doctor workflow is expected to delegate the token to= some other end-user that may be using a totally different client such as a= n EHR.


    If= the client that gets the token is not same as the client that uses the tok= en, that is a violation of core security principles as it allows for (and r= eally designs for) impersonation by client software. I would have no reason= to trust client software that would hand its credentials over to another p= iece of software, and in fact I shouldn=E2=80=99t trust it.=C2=A0

    I think you may be conflating several different kinds of pa= rties under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80=99= s entirely possible that one client might call an RS that in turn acts as a= client for something else down stream. But each of those hops is different= from the last.

    =C2=A0=E2=80=94 Justin


    --0000000000002c2bad05bdd13c97-- From nobody Thu Mar 18 08:31:14 2021 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 7DC653A2DE5 for ; Thu, 18 Mar 2021 08:31:13 -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, 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 WT__TIBOoUn0 for ; Thu, 18 Mar 2021 08:31:11 -0700 (PDT) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (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 2622A3A2DE4 for ; Thu, 18 Mar 2021 08:31:11 -0700 (PDT) Received: by mail-qv1-xf35.google.com with SMTP id d10so3366453qve.7 for ; Thu, 18 Mar 2021 08:31: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:from:date:message-id:subject:to :cc; bh=h2SoRdeDu25qSK4nxNdS/F/w+iYbcqMwKJ/diUFQmO4=; b=D7pUmfsnZK7Fr2CEbJi61Ajpiqikoy4QbcdOPgSTvzPmkskEKIPq8WTCoTNcJlzTAB 6Lb7A79ynY+XZTPT9F5lsl8Fq1+KEOhbO4Ut58C81lfcpX03iHCUbqFwlb+xbjE3++ut UviLlBVvfCYPxvl754cMenCSP21ElPF6ZzI2NZ2fYrHlLU00iqBd3RNU0ZxBmCGhcnDw qqIWA29ZiHSgQ6gAL5I0Ne6uakIfn2iotPf52BVuDGEKiNZU+wtU/gGHQdXkk3bPQvm6 zNirdCNqcniDdTpaXDHw6j5NgFuWJhNV1ktGmZ8KaOiyO4J1g+6iH2YysTZbYsAM7Mqb ZM/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=h2SoRdeDu25qSK4nxNdS/F/w+iYbcqMwKJ/diUFQmO4=; b=Z9muwGLZX79EMci/KOSz4UtHhM44PVOTgmJ4U2yOp2IT3ZHMOcj6T5LkpIT4cY9lhF F4nJQjmWVkWm/KiQfkmj2sTPNJB8mExC/6YJbDpFGFhN2ifhPiGwLlkhSOOc+h4fKXub A9+cjMOVq43wQRMCGPTNNgQ0e87qcyMLKR1VCQuIHxAHXYWk15sYbfmvdRZXM/257PyD lEtBmA5gengBAvWpPSUEVBcjiR590Ho9zmRoR5PcLxGb4uB1et4wTFH0Dt/t0lxX6K9l yVI2jAYhQ0Hdq7NlMbWfoKM4GwkhLj/nixYBPCU5O213oJe5Glo7NCHDYIJS+sShoojE JWuA== X-Gm-Message-State: AOAM531vQCWZUQWVpiJfVp7eigx/3UY8DSXS1zaM4B4GSap1y+Xv4MMz CQQCiFzOeNL/Qi+KHKk61KkGvNwU8V19Ovm2FSk= X-Google-Smtp-Source: ABdhPJw8SwLtp+gvbdoV+cs6AMzgsQ1txf8/5iXKgJyJJNdE7R93In5NnkALqqVntGjK7oegiZ80iWTJnoifxcYsGaE= X-Received: by 2002:a0c:80ca:: with SMTP id 68mr4905088qvb.12.1616081470261; Thu, 18 Mar 2021 08:31:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alan Karp Date: Thu, 18 Mar 2021 08:30:58 -0700 Message-ID: To: Justin Richer Cc: Adrian Gropper , Fabien Imbault , Tobias Looker , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="000000000000f68c4705bdd14964" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 15:31:14 -0000 --000000000000f68c4705bdd14964 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Justin Richer wrote: > On Mar 18, 2021, at 12:08 AM, Alan Karp wrote: > > > Adrian Gropper wrote: > >> >> Is there an AS involved in the delegation? How and where in the >> lifecycle of the protected resource? >> > > If tokens are certificates, the AS need not be involved in subsequent > delegations. The AS must be involved if the tokens are opaque. > > > Tokens are opaque to the client instance. They are not opaque to the AS. > They might be opaque to the RS, but that depends on the kind of > relationship the RS and AS have. GNAP should allow different options here > as there are different use cases for that. > Tokens are not opaque to the client in SPKI, zcap-ld, Orie's implementation with VCs, or our Zebra Copy work. Why must they be in GNAP? -------------- Alan Karp On Thu, Mar 18, 2021 at 4:56 AM Justin Richer wrote: > On Mar 18, 2021, at 12:08 AM, Alan Karp wrote: > > > Adrian Gropper wrote: > >> >> Is there an AS involved in the delegation? How and where in the >> lifecycle of the protected resource? >> > > If tokens are certificates, the AS need not be involved in subsequent > delegations. The AS must be involved if the tokens are opaque. > > > Tokens are opaque to the client instance. They are not opaque to the AS. > They might be opaque to the RS, but that depends on the kind of > relationship the RS and AS have. GNAP should allow different options here > as there are different use cases for that. > > It would probably be worthwhile to separate the portions of the spec that > talk about the RS-AS relationship into its own standalone document. A > similar approach was taken in UMA2 and it was helpful. (Though admittedly= , > as with anything, there are missteps there that we can hopefully learn > from.) > > =E2=80=94 Justin > > > -------------- > Alan Karp > > > On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper > wrote: > >> Sure! >> >> Is there an AS involved in the delegation? How and where in the >> lifecycle of the protected resource? >> >> Also your use of "the client" seems to imply that either there is only >> one client or the client doesn't matter. Which is it? >> >> Adrian >> >> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault >> wrote: >> >>> Thanks for that. >>> >>> Trying to reframe it: >>> GNAP is defined as a delegation protocol so the main intent is related >>> to a delegate of the RO (i.e. the end user) that wishes to access the R= O's >>> protected resources, through the client. >>> >>> Fabien >>> >>> Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper a >>> =C3=A9crit : >>> >>>> At various points in the lifecycle of the protected resource the clien= t >>>> at the resource server (RS) might be: >>>> >>>> - The RO (subject) user agent trading payment for a service promise >>>> - The RO user agent using the promise to access the protected >>>> resource >>>> - A delegate of the RO user agent using a different client >>>> >>>> What's vague is where the GNAP AS enters the picture as described >>>> above. How would you describe it? >>>> >>>> Adrian >>>> >>>> >>>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Hi Adrian >>>>> >>>>> I'm still confused why you're saying the terminology is vague. >>>>> I get the "power" neutrality is not to your liking, but RQ / user >>>>> agent is no better in my view. >>>>> >>>>> Can you elaborate? >>>>> >>>>> Fabien >>>>> >>>>> Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper >>>>> a =C3=A9crit : >>>>> >>>>>> I'm sure you're right. Our vague terminology around >>>>>> client and end-user leads to my confusion. If GNAP is primarily abou= t >>>>>> delegation then, of course, we should avoid any incentives to impers= onate >>>>>> or we're wasting our time. This is partly why I'm trying to study up= on >>>>>> capabilities and asking for expert advice from folks like Alan Karp = and >>>>>> Mark Miller (cc'd) >>>>>> >>>>>> As best I can understand it, the RS has only two choices, it can: >>>>>> >>>>>> - store an attribute of the RO a [DID, email address, GNAP AS >>>>>> URL], or >>>>>> - hand the RO a capability as a sort-of promise and avoid making >>>>>> any entries in an ACL or equivalent. >>>>>> >>>>>> When a token comes back to the RS, it will either be: >>>>>> >>>>>> - validated according to something associated with the stored RO >>>>>> attribute, or >>>>>> - signed by the RS itself. >>>>>> >>>>>> Either way, trust in the client seems moot. >>>>>> >>>>>> Adrian >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer >>>>>> wrote: >>>>>> >>>>>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker < >>>>>>> tobias.looker@mattr.global> wrote: >>>>>>> >>>>>>>> >>>>>>>> > A client might not have a DID but it could have a VC as a >>>>>>>> certificate of authenticity linked to some audit mechanism. >>>>>>>> >>>>>>>> To me a VC would come under the assertions umbrella (that is to sa= y >>>>>>>> a VC could be one type of valid assertion). The client may possess= or been >>>>>>>> presented with a VC that it could include in its request to the AS= as a way >>>>>>>> to identify the subject and perhaps prove authentication and autho= rization. >>>>>>>> >>>>>>> >>>>>>> I do not assume that the client that interacts with the AS to make = a >>>>>>> request and receive a token is the same as the client that will pre= sent the >>>>>>> token to the RS. In the US HIPAA use-case, for example, the root of= trust >>>>>>> is a contract between the patient-subject and the doctor-requesting= party >>>>>>> but the doctor workflow is expected to delegate the token to some o= ther >>>>>>> end-user that may be using a totally different client such as an EH= R. >>>>>>> >>>>>>> >>>>>>> If the client that gets the token is not same as the client that >>>>>>> uses the token, that is a violation of core security principles as = it >>>>>>> allows for (and really designs for) impersonation by client softwar= e. I >>>>>>> would have no reason to trust client software that would hand its >>>>>>> credentials over to another piece of software, and in fact I should= n=E2=80=99t >>>>>>> trust it. >>>>>>> >>>>>>> I think you may be conflating several different kinds of parties >>>>>>> under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80= =99s entirely possible that one >>>>>>> client might call an RS that in turn acts as a client for something= else >>>>>>> down stream. But each of those hops is different from the last. >>>>>>> >>>>>>> =E2=80=94 Justin >>>>>>> >>>>>>> > --000000000000f68c4705bdd14964 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Jus= tin Richer <jricher@mit.edu> w= rote:
    On Mar 18, 2021, at 12:08 AM, Alan Karp <= ;alanhkarp@gmail.c= om> wrote:

    Adrian Gropper &l= t;agropper@heal= thurl.com> wrote:

    Is there an AS involved in = the delegation? How and where in the lifecycle=C2=A0of the protected resour= ce?=C2=A0

    If tokens are certifi= cates, the AS need not be involved in subsequent delegations.=C2=A0 The AS = must be involved if the tokens are opaque.=C2=A0

    Tokens are opaque to the client instance. The= y are not opaque to the AS. They might be opaque to the RS, but that depend= s on the kind of relationship the RS and AS have. GNAP should allow differe= nt options here as there are different use cases for that.
    =

    Tokens are not opaque to the client in SP= KI, zcap-ld, Orie's implementation with VCs, or our Zebra Copy work.=C2= =A0 Why must they be in GNAP?

    --------------
    Alan Karp
    =


    On Thu, Mar 18, 2021 at 4:56 AM Justin Richer <jricher@mit.edu> wrote:
    alanhkarp@gmail.com> wrote:

    Adrian Gropper <agropper@healthurl.com> wrote:
    =

    Is there an AS involved in the delegation? How and where = in the lifecycle=C2=A0of the protected resource?=C2=A0

    If tokens are certificates, the AS need not be invo= lved in subsequent delegations.=C2=A0 The AS must be involved if the tokens= are opaque.=C2=A0

    = Tokens are opaque to the client instance. They are not opaque to the AS. Th= ey might be opaque to the RS, but that depends on the kind of relationship = the RS and AS have. GNAP should allow different options here as there are d= ifferent use cases for that.

    It would probably be = worthwhile to separate the portions of the spec that talk about the RS-AS r= elationship into its own standalone document. A similar approach was taken = in UMA2 and it was helpful. (Though admittedly, as with anything, there are= missteps there that we can hopefully learn from.)

    =C2=A0=E2=80=94 Justin


    --------------<= br>Alan Karp


    On Wed, Mar 17, 2021 at 8:54 PM Adrian Groppe= r <agropper@= healthurl.com> wrote:
    Sure!=C2=A0

    Is there an AS= involved in the delegation? How and where in the lifecycle=C2=A0of the pro= tected resource?=C2=A0

    Also your use of "the client= " seems to imply that either there is only one client or the client do= esn't matter. Which is it?

    Adrian
    <= /div>
    O= n Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault <fabien.imbault@gmail.com> wrot= e:
    Thanks for that.=C2=A0

    Trying to reframe it:
    GNAP is defined as a= delegation protocol so the main intent is related to a delegate of the RO = (i.e. the end user) that wishes to access the RO's protected resources,= through the client.=C2=A0

    Fabien=C2=A0

    <= div class=3D"gmail_quote" dir=3D"auto">
    Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper <agropper@healthurl.com> a = =C3=A9crit=C2=A0:
    At various points in the lifecycle=C2=A0of the protected= resource the client at the resource server (RS) might be:
    • The = RO (subject) user agent trading payment for a service promise
    • The R= O user agent using the promise to access the protected resource
    • A d= elegate of the RO user agent using a different client
    What= 9;s vague is where the GNAP AS enters the picture as described above. How w= ould you describe it?

    Adrian

    <= /div>

    On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault <fabien.imbau= lt@gmail.com> wrote:
    Hi Adrian

    I'm still confused why you're saying the terminology is v= ague.=C2=A0
    I get the "power" neutrality i= s not to your liking, but RQ / user agent is no better in my view.=C2=A0

    Can you elaborate?=C2=A0

    Fabien=C2=A0
    <= br>
    Le jeu.= 18 mars 2021 =C3=A0 00:18, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    • store an attribute of the RO a [DID, email address, GNAP AS URL],= or
    • hand the RO a capability as a sort-of promise and avoid making = any entries in an ACL or equivalent.
    When a token comes back = to the RS, it will either be:
    • validated according to some= thing associated with the stored RO attribute, or
    • signed by the= RS itself.
    Either way, trust in the client seems moot.
    =

    Adrian


    <= /div>
    O= n Wed, Mar 17, 2021 at 5:29 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 17, 2021, at 4:55 PM, Adrian Gropper <agropper@h= ealthurl.com> wrote:

    On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker= <tobias.looker@mattr.global> wrote:
    =
    <snip>
    > A client might not have= a DID but it could have a VC as a certificate of authenticity linked to so= me audit mechanism.

    To me a VC would come under th= e assertions umbrella (that is to say a VC could be one type of valid asser= tion). The client may possess or been presented with a VC that it could inc= lude in its request to the AS as a way to identify the subject and perhaps = prove authentication and authorization.

    I do not assume that the client that interacts with the AS to make= a request and receive a token is the same as the client that will present = the token to the RS. In the US HIPAA use-case, for example, the root of tru= st is a contract between the patient-subject and the doctor-requesting part= y but the doctor workflow is expected to delegate the token to some other e= nd-user that may be using a totally different client such as an EHR.
    <= div>

    If the client t= hat gets the token is not same as the client that uses the token, that is a= violation of core security principles as it allows for (and really designs= for) impersonation by client software. I would have no reason to trust cli= ent software that would hand its credentials over to another piece of softw= are, and in fact I shouldn=E2=80=99t trust it.=C2=A0

    I think you may be conflating several different kinds of parties under t= he =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80=99s entirely po= ssible that one client might call an RS that in turn acts as a client for s= omething else down stream. But each of those hops is different from the las= t.

    =C2=A0=E2=80=94 Justin


    --000000000000f68c4705bdd14964-- From nobody Thu Mar 18 09:59:50 2021 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 AA7703A2FAA for ; Thu, 18 Mar 2021 09:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.918 X-Spam-Level: X-Spam-Status: No, score=-6.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Kn57xraDxs_P for ; Thu, 18 Mar 2021 09:59:45 -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 71AE23A2FA4 for ; Thu, 18 Mar 2021 09:59:45 -0700 (PDT) Received: from [192.168.1.22] (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 12IGxdbp020959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Mar 2021 12:59:40 -0400 From: Justin Richer Message-Id: <43447446-4061-49F2-8486-5A196C3C75E2@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_3BC5515E-2F9E-4555-9853-494CC431CA21" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 18 Mar 2021 12:59:39 -0400 In-Reply-To: Cc: Adrian Gropper , Fabien Imbault , Tobias Looker , GNAP Mailing List , Mark Miller To: Alan Karp References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 16:59:49 -0000 --Apple-Mail=_3BC5515E-2F9E-4555-9853-494CC431CA21 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 18, 2021, at 11:30 AM, Alan Karp wrote: >=20 > Justin Richer > wrote: > On Mar 18, 2021, at 12:08 AM, Alan Karp > wrote: >>=20 >> Adrian Gropper > wrote: >>=20 >> Is there an AS involved in the delegation? How and where in the = lifecycle of the protected resource?=20 >>=20 >> If tokens are certificates, the AS need not be involved in subsequent = delegations. The AS must be involved if the tokens are opaque.=20 >=20 > Tokens are opaque to the client instance. They are not opaque to the = AS. They might be opaque to the RS, but that depends on the kind of = relationship the RS and AS have. GNAP should allow different options = here as there are different use cases for that. >=20 > Tokens are not opaque to the client in SPKI, zcap-ld, Orie's = implementation with VCs, or our Zebra Copy work. Why must they be in = GNAP? The existence of the AS is exactly the reason for this. The AS is the = role that =E2=80=9Cknowledge about the token contents=E2=80=9D has been = outsourced to in the GNAP model (which is based on the OAuth model). It brings significant simplicity for the client developer. The question = I have is =E2=80=94 why does the client need to know what=E2=80=99s in = the token? Not if they could possibly know, but why would we expect a = client to know and manage the contents of the token?=20 The access token is fundamentally a conversational artifact between the = AS and the RS which the client is the carrier of. The client is not the = audience of the token, nor the creator of the token, nor even the = manager of the token and the rights it represents. The client as a = simple carrier is a powerful model that allows the security layer to get = out of the way of the actual application logic that developers want to = do. =E2=80=94 Justin >=20 > -------------- > Alan Karp >=20 >=20 > On Thu, Mar 18, 2021 at 4:56 AM Justin Richer > wrote: > On Mar 18, 2021, at 12:08 AM, Alan Karp > wrote: >>=20 >> Adrian Gropper > wrote: >>=20 >> Is there an AS involved in the delegation? How and where in the = lifecycle of the protected resource?=20 >>=20 >> If tokens are certificates, the AS need not be involved in subsequent = delegations. The AS must be involved if the tokens are opaque.=20 >=20 > Tokens are opaque to the client instance. They are not opaque to the = AS. They might be opaque to the RS, but that depends on the kind of = relationship the RS and AS have. GNAP should allow different options = here as there are different use cases for that. >=20 > It would probably be worthwhile to separate the portions of the spec = that talk about the RS-AS relationship into its own standalone document. = A similar approach was taken in UMA2 and it was helpful. (Though = admittedly, as with anything, there are missteps there that we can = hopefully learn from.) >=20 > =E2=80=94 Justin >=20 >>=20 >> -------------- >> Alan Karp >>=20 >>=20 >> On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper = > wrote: >> Sure!=20 >>=20 >> Is there an AS involved in the delegation? How and where in the = lifecycle of the protected resource?=20 >>=20 >> Also your use of "the client" seems to imply that either there is = only one client or the client doesn't matter. Which is it? >>=20 >> Adrian >>=20 >> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault = > wrote: >> Thanks for that.=20 >>=20 >> Trying to reframe it: >> GNAP is defined as a delegation protocol so the main intent is = related to a delegate of the RO (i.e. the end user) that wishes to = access the RO's protected resources, through the client.=20 >>=20 >> Fabien=20 >>=20 >> Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper = > a =C3=A9crit : >> At various points in the lifecycle of the protected resource the = client at the resource server (RS) might be: >> The RO (subject) user agent trading payment for a service promise >> The RO user agent using the promise to access the protected resource >> A delegate of the RO user agent using a different client >> What's vague is where the GNAP AS enters the picture as described = above. How would you describe it? >>=20 >> Adrian >>=20 >>=20 >> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault = > wrote: >> Hi Adrian >>=20 >> I'm still confused why you're saying the terminology is vague.=20 >> I get the "power" neutrality is not to your liking, but RQ / user = agent is no better in my view.=20 >>=20 >> Can you elaborate?=20 >>=20 >> Fabien=20 >>=20 >> Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper = > a =C3=A9crit : >> I'm sure you're right. Our vague terminology around client and = end-user leads to my confusion. If GNAP is primarily about delegation = then, of course, we should avoid any incentives to impersonate or we're = wasting our time. This is partly why I'm trying to study up on = capabilities and asking for expert advice from folks like Alan Karp and = Mark Miller (cc'd) >>=20 >> As best I can understand it, the RS has only two choices, it can: >> store an attribute of the RO a [DID, email address, GNAP AS URL], or >> hand the RO a capability as a sort-of promise and avoid making any = entries in an ACL or equivalent. >> When a token comes back to the RS, it will either be: >> validated according to something associated with the stored RO = attribute, or >> signed by the RS itself. >> Either way, trust in the client seems moot. >>=20 >> Adrian >>=20 >>=20 >>=20 >> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer > wrote: >> On Mar 17, 2021, at 4:55 PM, Adrian Gropper > wrote: >>>=20 >>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker = > wrote: >>> >>> > A client might not have a DID but it could have a VC as a = certificate of authenticity linked to some audit mechanism. >>>=20 >>> To me a VC would come under the assertions umbrella (that is to say = a VC could be one type of valid assertion). The client may possess or = been presented with a VC that it could include in its request to the AS = as a way to identify the subject and perhaps prove authentication and = authorization. >>>=20 >>> I do not assume that the client that interacts with the AS to make a = request and receive a token is the same as the client that will present = the token to the RS. In the US HIPAA use-case, for example, the root of = trust is a contract between the patient-subject and the = doctor-requesting party but the doctor workflow is expected to delegate = the token to some other end-user that may be using a totally different = client such as an EHR. >>>=20 >>=20 >> If the client that gets the token is not same as the client that uses = the token, that is a violation of core security principles as it allows = for (and really designs for) impersonation by client software. I would = have no reason to trust client software that would hand its credentials = over to another piece of software, and in fact I shouldn=E2=80=99t trust = it.=20 >>=20 >> I think you may be conflating several different kinds of parties = under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80=99s = entirely possible that one client might call an RS that in turn acts as = a client for something else down stream. But each of those hops is = different from the last. >>=20 >> =E2=80=94 Justin >>=20 >=20 --Apple-Mail=_3BC5515E-2F9E-4555-9853-494CC431CA21 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Mar 18, 2021, at 11:30 AM, Alan Karp <alanhkarp@gmail.com>= wrote:

    Justin Richer <jricher@mit.edu> = wrote:
    On Mar 18, 2021, at 12:08 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Adrian Gropper <agropper@healthurl.com> wrote:

    Is there an AS involved = in the delegation? How and where in the lifecycle of the protected = resource? 

    If tokens are certificates, the AS need = not be involved in subsequent delegations.  The AS must be involved = if the tokens are opaque. 

    Tokens are opaque to the = client instance. They are not opaque to the AS. They might be opaque to = the RS, but that depends on the kind of relationship the RS and AS have. = GNAP should allow different options here as there are different use = cases for that.

    Tokens are = not opaque to the client in SPKI, zcap-ld, Orie's implementation with = VCs, or our Zebra Copy work.  Why must they be in = GNAP?

    The existence of the AS is exactly the reason for = this. The AS is the role that =E2=80=9Cknowledge about the token = contents=E2=80=9D has been outsourced to in the GNAP model (which is = based on the OAuth model).

    It brings = significant simplicity for the client developer. The question I have is = =E2=80=94 why does the client need to know what=E2=80=99s in the token? = Not if they could possibly know, but why would we expect a client to = know and manage the contents of the token? 

    The access token is fundamentally a conversational = artifact between the AS and the RS which the client is the carrier of. = The client is not the audience of the token, nor the creator of the = token, nor even the manager of the token and the rights it represents. = The client as a simple carrier is a powerful model that allows the = security layer to get out of the way of the actual application logic = that developers want to do.

     =E2=80= =94 Justin


    --------------
    Alan Karp


    On Thu, Mar = 18, 2021 at 4:56 AM Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 12:08 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Adrian Gropper <agropper@healthurl.com> wrote:

    Is there an AS involved = in the delegation? How and where in the lifecycle of the protected = resource? 

    If tokens are certificates, the AS need = not be involved in subsequent delegations.  The AS must be involved = if the tokens are opaque. 

    Tokens are opaque to the = client instance. They are not opaque to the AS. They might be opaque to = the RS, but that depends on the kind of relationship the RS and AS have. = GNAP should allow different options here as there are different use = cases for that.

    It would probably be worthwhile to separate the portions of = the spec that talk about the RS-AS relationship into its own standalone = document. A similar approach was taken in UMA2 and it was helpful. = (Though admittedly, as with anything, there are missteps there that we = can hopefully learn from.)

     =E2=80=94 Justin


    --------------
    Alan = Karp


    On Wed, Mar = 17, 2021 at 8:54 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Sure! 

    Is there an AS involved in the delegation? How and where in = the lifecycle of the protected resource? 

    Also your use of "the client" seems to = imply that either there is only one client or the client doesn't matter. = Which is it?

    Adrian

    On Wed, Mar = 17, 2021 at 11:43 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks for that. 

    Trying to reframe = it:
    GNAP is defined as a delegation = protocol so the main intent is related to a delegate of the RO (i.e. the = end user) that wishes to access the RO's protected resources, through = the client. 

    Fabien 

    Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper = <agropper@healthurl.com> a =C3=A9crit :
    At = various points in the lifecycle of the protected resource the = client at the resource server (RS) might be:
    • The RO (subject) user agent trading payment = for a service promise
    • The RO user agent using the = promise to access the protected resource
    • A delegate = of the RO user agent using a different client
    What's vague is where the GNAP AS enters the picture as = described above. How would you describe it?
    Adrian


    On Wed, Mar 17, 2021 at 10:20 PM Fabien = Imbault <fabien.imbault@gmail.com> wrote:
    Hi = Adrian

    I'm still confused why you're saying the terminology is = vague. 
    I get the "power" = neutrality is not to your liking, but RQ / user agent is no better in my = view. 

    Can you elaborate? 

    Fabien 

    Le jeu. 18 = mars 2021 =C3=A0 00:18, Adrian Gropper <agropper@healthurl.com> a = =C3=A9crit :
    I'm sure = you're right. Our vague terminology around = client and end-user leads to my confusion. If GNAP is = primarily about delegation then, of course, we should avoid = any incentives to impersonate or we're wasting our time. This is partly = why I'm trying to study up on capabilities and asking for expert advice = from folks like Alan Karp and Mark Miller (cc'd)

    As best I can understand it, the RS has = only two choices, it can:
    • store an attribute of the RO a [DID, email address, GNAP AS = URL], or
    • hand the RO a capability as a sort-of = promise and avoid making any entries in an ACL or = equivalent.
    When a token comes back to the RS, = it will either be:
    • validated according to something associated with the stored = RO attribute, or
    • signed by the RS = itself.
    Either way, trust in the client seems = moot.

    Adrian



    On Wed, Mar = 17, 2021 at 5:29 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 17, = 2021, at 4:55 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <tobias.looker@mattr.global> = wrote:
    <snip>
    > A client might not = have a DID but it could have a VC as a certificate of authenticity = linked to some audit mechanism.

    To me a VC would come under the = assertions umbrella (that is to say a VC could be one type of valid = assertion). The client may possess or been presented with a VC that it = could include in its request to the AS as a way to identify the subject = and perhaps prove authentication and = authorization.

    I do not assume that the client that = interacts with the AS to make a request and receive a token is the same = as the client that will present the token to the RS. In the US HIPAA = use-case, for example, the root of trust is a contract between the = patient-subject and the doctor-requesting party but the doctor workflow = is expected to delegate the token to some other end-user that may be = using a totally different client such as an EHR.


    If the client that gets the token is not same as the client = that uses the token, that is a violation of core security principles as = it allows for (and really designs for) impersonation by client software. = I would have no reason to trust client software that would hand its = credentials over to another piece of software, and in fact I shouldn=E2=80= =99t trust it. 

    I think you may be conflating several different kinds of = parties under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80= =99s entirely possible that one client might call an RS that in turn = acts as a client for something else down stream. But each of those hops = is different from the last.

     =E2=80=94 Justin



    = --Apple-Mail=_3BC5515E-2F9E-4555-9853-494CC431CA21-- From nobody Thu Mar 18 10:13:49 2021 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 66BBA3A3012 for ; Thu, 18 Mar 2021 10:13:42 -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 JeQv2VK1B638 for ; Thu, 18 Mar 2021 10:13:39 -0700 (PDT) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 BF79C3A301C for ; Thu, 18 Mar 2021 10:13:39 -0700 (PDT) Received: by mail-il1-x129.google.com with SMTP id v3so5559932ilj.12 for ; Thu, 18 Mar 2021 10:13: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=6XsgfC/xZFA/ZUdz8hXAQKsg0yob4+KT6WHB0LDeKF0=; b=kSMH0dJHmq31RgV8kz6GiKCUK9liAeTH7Balc8usIAJJjQRd2T+sChz2qLQUGdQgAL VPofSZk37Xdnh7AVENi6x4ohYHOqK7IyO7uSRi8qL/9YQmDZuWu2Z4B+Z/obaZ/ROsWJ RrmoYMZSsmGijZFEvlkseNCwrScU0d39SihfjtUkFrXJQwp6DC/M+r8PbHTG8eSeZWeT jZRRG8+RPAKEwBw4JWKfl8hPuZng8frWVVgqvndunweForxvH4QjbpqKMpCLk16YQRSm HvXhE8vd+KAr7504gkvSlPnLnNPDRG+UrVQKtldjfmi2ir3cryBCCDwkR4UJngQJUC1R +4qQ== 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=6XsgfC/xZFA/ZUdz8hXAQKsg0yob4+KT6WHB0LDeKF0=; b=hblnbLoIB7+2wFRDf16C/PQ6DJU8Q3BflsQFRQ8j6B8bsS1lm7qLNkJ3ILD0wZDom8 ZkzbL2N1HOuk0HgOKzjjpymrMaPs2PbFy4uPRDzNDksd1yRLGxNT1mm6yfK/ApkAblUF 3R3oXAshDp5biLzV4Yls+yRMxKrObTnvbe5Kr9DSgeNBchxKd/Etc3tN3q9TUoeZ9bwx G2lOfMsdq1qvmgmhiZWiv7uRGEHsewtxJ0bhOBjugDHIrqxE6si6+gQM01+syaKPoNPD H/LyaFcbO1ySB9hZLuqTqWxEf5NqFnTI+IZLvWFilllH9hne9Tq+2AxJHpVi8RVBN6EC vYAw== X-Gm-Message-State: AOAM530ZTOZq7vFK3BMvpKyf4cyf8f9wnJ8k7OkhU5s9eeDtaYr3aLVC kbvKR8RyEEE0eumvo5+mx++bIpMM3FCeh4sHa/Y= X-Google-Smtp-Source: ABdhPJzGtiVpfRF47TSPdPbj6PP2btAtVNcLbUGziSep6/aQZ5swCnLacnk5zabKSejlhjAT804GvJMBhTTBi1kHtLc= X-Received: by 2002:a05:6e02:df2:: with SMTP id m18mr6568043ilj.123.1616087618482; Thu, 18 Mar 2021 10:13:38 -0700 (PDT) MIME-Version: 1.0 References: <43447446-4061-49F2-8486-5A196C3C75E2@mit.edu> In-Reply-To: <43447446-4061-49F2-8486-5A196C3C75E2@mit.edu> From: Fabien Imbault Date: Thu, 18 Mar 2021 18:13:27 +0100 Message-ID: To: Justin Richer Cc: Alan Karp , Adrian Gropper , Tobias Looker , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="0000000000006cf8a105bdd2b81a" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 17:13:48 -0000 --0000000000006cf8a105bdd2b81a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Justin, "The access token is fundamentally a conversational artifact between the AS and the RS which the client is the carrier of." That's right, and a good opportunity to distinguish between the need for token inspection (i.e. a runtime verification, wherever that may be) and the need to negotiate the token format (a discovery). That last part could very well be an extension, as a way to open up the ecosystem beyond JWTs (which are fine, but come with their own limitations). Fabien On Thu, Mar 18, 2021 at 5:59 PM Justin Richer wrote: > On Mar 18, 2021, at 11:30 AM, Alan Karp wrote: > > > Justin Richer wrote: > >> On Mar 18, 2021, at 12:08 AM, Alan Karp wrote: >> >> >> Adrian Gropper wrote: >> >>> >>> Is there an AS involved in the delegation? How and where in the >>> lifecycle of the protected resource? >>> >> >> If tokens are certificates, the AS need not be involved in subsequent >> delegations. The AS must be involved if the tokens are opaque. >> >> >> Tokens are opaque to the client instance. They are not opaque to the AS. >> They might be opaque to the RS, but that depends on the kind of >> relationship the RS and AS have. GNAP should allow different options her= e >> as there are different use cases for that. >> > > Tokens are not opaque to the client in SPKI, zcap-ld, Orie's > implementation with VCs, or our Zebra Copy work. Why must they be in GNA= P? > > > The existence of the AS is exactly the reason for this. The AS is the rol= e > that =E2=80=9Cknowledge about the token contents=E2=80=9D has been outsou= rced to in the > GNAP model (which is based on the OAuth model). > > It brings significant simplicity for the client developer. The question I > have is =E2=80=94 why does the client need to know what=E2=80=99s in the = token? Not if they > could possibly know, but why would we expect a client to know and manage > the contents of the token? > > The access token is fundamentally a conversational artifact between the A= S > and the RS which the client is the carrier of. The client is not the > audience of the token, nor the creator of the token, nor even the manager > of the token and the rights it represents. The client as a simple carrier > is a powerful model that allows the security layer to get out of the way = of > the actual application logic that developers want to do. > > =E2=80=94 Justin > > > -------------- > Alan Karp > > > On Thu, Mar 18, 2021 at 4:56 AM Justin Richer wrote: > >> On Mar 18, 2021, at 12:08 AM, Alan Karp wrote: >> >> >> Adrian Gropper wrote: >> >>> >>> Is there an AS involved in the delegation? How and where in the >>> lifecycle of the protected resource? >>> >> >> If tokens are certificates, the AS need not be involved in subsequent >> delegations. The AS must be involved if the tokens are opaque. >> >> >> Tokens are opaque to the client instance. They are not opaque to the AS. >> They might be opaque to the RS, but that depends on the kind of >> relationship the RS and AS have. GNAP should allow different options her= e >> as there are different use cases for that. >> >> It would probably be worthwhile to separate the portions of the spec tha= t >> talk about the RS-AS relationship into its own standalone document. A >> similar approach was taken in UMA2 and it was helpful. (Though admittedl= y, >> as with anything, there are missteps there that we can hopefully learn >> from.) >> >> =E2=80=94 Justin >> >> >> -------------- >> Alan Karp >> >> >> On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper >> wrote: >> >>> Sure! >>> >>> Is there an AS involved in the delegation? How and where in the >>> lifecycle of the protected resource? >>> >>> Also your use of "the client" seems to imply that either there is only >>> one client or the client doesn't matter. Which is it? >>> >>> Adrian >>> >>> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault < >>> fabien.imbault@gmail.com> wrote: >>> >>>> Thanks for that. >>>> >>>> Trying to reframe it: >>>> GNAP is defined as a delegation protocol so the main intent is related >>>> to a delegate of the RO (i.e. the end user) that wishes to access the = RO's >>>> protected resources, through the client. >>>> >>>> Fabien >>>> >>>> Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper >>>> a =C3=A9crit : >>>> >>>>> At various points in the lifecycle of the protected resource the >>>>> client at the resource server (RS) might be: >>>>> >>>>> - The RO (subject) user agent trading payment for a service promis= e >>>>> - The RO user agent using the promise to access the protected >>>>> resource >>>>> - A delegate of the RO user agent using a different client >>>>> >>>>> What's vague is where the GNAP AS enters the picture as described >>>>> above. How would you describe it? >>>>> >>>>> Adrian >>>>> >>>>> >>>>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Hi Adrian >>>>>> >>>>>> I'm still confused why you're saying the terminology is vague. >>>>>> I get the "power" neutrality is not to your liking, but RQ / user >>>>>> agent is no better in my view. >>>>>> >>>>>> Can you elaborate? >>>>>> >>>>>> Fabien >>>>>> >>>>>> Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper >>>>>> a =C3=A9crit : >>>>>> >>>>>>> I'm sure you're right. Our vague terminology around >>>>>>> client and end-user leads to my confusion. If GNAP is primarily abo= ut >>>>>>> delegation then, of course, we should avoid any incentives to imper= sonate >>>>>>> or we're wasting our time. This is partly why I'm trying to study u= p on >>>>>>> capabilities and asking for expert advice from folks like Alan Karp= and >>>>>>> Mark Miller (cc'd) >>>>>>> >>>>>>> As best I can understand it, the RS has only two choices, it can: >>>>>>> >>>>>>> - store an attribute of the RO a [DID, email address, GNAP AS >>>>>>> URL], or >>>>>>> - hand the RO a capability as a sort-of promise and avoid making >>>>>>> any entries in an ACL or equivalent. >>>>>>> >>>>>>> When a token comes back to the RS, it will either be: >>>>>>> >>>>>>> - validated according to something associated with the stored RO >>>>>>> attribute, or >>>>>>> - signed by the RS itself. >>>>>>> >>>>>>> Either way, trust in the client seems moot. >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer >>>>>>> wrote: >>>>>>> >>>>>>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker < >>>>>>>> tobias.looker@mattr.global> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> > A client might not have a DID but it could have a VC as a >>>>>>>>> certificate of authenticity linked to some audit mechanism. >>>>>>>>> >>>>>>>>> To me a VC would come under the assertions umbrella (that is to >>>>>>>>> say a VC could be one type of valid assertion). The client may po= ssess or >>>>>>>>> been presented with a VC that it could include in its request to = the AS as >>>>>>>>> a way to identify the subject and perhaps prove authentication an= d >>>>>>>>> authorization. >>>>>>>>> >>>>>>>> >>>>>>>> I do not assume that the client that interacts with the AS to make >>>>>>>> a request and receive a token is the same as the client that will = present >>>>>>>> the token to the RS. In the US HIPAA use-case, for example, the ro= ot of >>>>>>>> trust is a contract between the patient-subject and the doctor-req= uesting >>>>>>>> party but the doctor workflow is expected to delegate the token to= some >>>>>>>> other end-user that may be using a totally different client such a= s an EHR. >>>>>>>> >>>>>>>> >>>>>>>> If the client that gets the token is not same as the client that >>>>>>>> uses the token, that is a violation of core security principles as= it >>>>>>>> allows for (and really designs for) impersonation by client softwa= re. I >>>>>>>> would have no reason to trust client software that would hand its >>>>>>>> credentials over to another piece of software, and in fact I shoul= dn=E2=80=99t >>>>>>>> trust it. >>>>>>>> >>>>>>>> I think you may be conflating several different kinds of parties >>>>>>>> under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80= =99s entirely possible that one >>>>>>>> client might call an RS that in turn acts as a client for somethin= g else >>>>>>>> down stream. But each of those hops is different from the last. >>>>>>>> >>>>>>>> =E2=80=94 Justin >>>>>>>> >>>>>>>> >> > --0000000000006cf8a105bdd2b81a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Justin,=C2=A0

    "The access token= is fundamentally a conversational artifact between the AS and the RS which= the client is the carrier of."
    That's right,=C2=A0and a= good=C2=A0opportunity to distinguish between the need for token=C2=A0inspe= ction (i.e. a runtime verification, wherever that may be) and the need to n= egotiate the token format (a discovery). That last part could very well be = an extension, as a way to open up the ecosystem beyond JWTs (which are fine= , but come with their own limitations).=C2=A0

    Fabi= en

    On Thu, Mar 18, 2021 at 5:59 PM Justin Richer <jricher@mit.edu> wrote:
    = On Mar 18, 2021, at 11:30 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 12:08 AM, Ala= n Karp <alanhka= rp@gmail.com> wrote:

    Adrian = Gropper <agr= opper@healthurl.com> wrote:

    Is there an AS invo= lved in the delegation? How and where in the lifecycle=C2=A0of the protecte= d resource?=C2=A0

    If tokens are= certificates, the AS need not be involved in subsequent delegations.=C2=A0= The AS must be involved if the tokens are opaque.=C2=A0
    <= /div>

    Tokens are opaque to the client insta= nce. They are not opaque to the AS. They might be opaque to the RS, but tha= t depends on the kind of relationship the RS and AS have. GNAP should allow= different options here as there are different use cases for that.

    Token= s are not opaque to the client in SPKI, zcap-ld, Orie's implementation = with VCs, or our Zebra Copy work.=C2=A0 Why must they be in GNAP?

    The existence of the A= S is exactly the reason for this. The AS is the role that =E2=80=9Cknowledg= e about the token contents=E2=80=9D has been outsourced to in the GNAP mode= l (which is based on the OAuth model).

    It brings s= ignificant simplicity for the client developer. The question I have is =E2= =80=94 why does the client need to know what=E2=80=99s in the token? Not if= they could possibly know, but why would we expect a client to know and man= age the contents of the token?=C2=A0

    The access to= ken is fundamentally a conversational artifact between the AS and the RS wh= ich the client is the carrier of. The client is not the audience of the tok= en, nor the creator of the token, nor even the manager of the token and the= rights it represents. The client as a simple carrier is a powerful model t= hat allows the security layer to get out of the way of the actual applicati= on logic that developers want to do.

    =C2=A0=E2=80= =94 Justin


    --------------
    Alan Karp
    =

    On Thu, Mar 18, 2021 at 4:56 AM Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 12:= 08 AM, Alan Karp <alanhkarp@gmail.com> wrote:
    Adrian Gropper <agropper@healthurl.com> wrote:

    Is there = an AS involved in the delegation? How and where in the lifecycle=C2=A0of th= e protected resource?=C2=A0

    If = tokens are certificates, the AS need not be involved in subsequent delegati= ons.=C2=A0 The AS must be involved if the tokens are opaque.=C2=A0

    Tokens are opaque to the cl= ient instance. They are not opaque to the AS. They might be opaque to the R= S, but that depends on the kind of relationship the RS and AS have. GNAP sh= ould allow different options here as there are different use cases for that= .

    It would probably be worthwhile to separate the = portions of the spec that talk about the RS-AS relationship into its own st= andalone document. A similar approach was taken in UMA2 and it was helpful.= (Though admittedly, as with anything, there are missteps there that we can= hopefully learn from.)

    =C2=A0=E2=80=94 Justin

    --------------
    Alan Karp

    On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper <agropper@healthurl.com> wrote:<= br>
    Sure!=C2=A0

    Is there an AS involved in the delegation? = How and where in the lifecycle=C2=A0of the protected resource?=C2=A0
    Also your use of "the client" seems to imply that ei= ther there is only one client or the client doesn't matter. Which is it= ?

    Adrian

    On Wed, Mar 17, 2021 at 11:43 = PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks for that.=C2= =A0

    Trying to reframe it= :
    GNAP is defined as a delegation protocol so the ma= in intent is related to a delegate of the RO (i.e. the end user) that wishe= s to access the RO's protected resources, through the client.=C2=A0

    Fabien=C2=A0

    Le jeu. 18 mars 2021 =C3=A0= 04:29, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    At various = points in the lifecycle=C2=A0of the protected resource the client at the re= source server (RS) might be:
    • The RO (subject) user agent tradin= g payment for a service promise
    • The RO user agent using the promise= to access the protected resource
    • A delegate of the RO user agent u= sing a different client
    What's vague is where the GNAP AS= enters the picture as described above. How would you describe it?

    Adrian


    On Wed, Mar 17, 2021 at 1= 0:20 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Adrian

    I'm still confu= sed why you're saying the terminology is vague.=C2=A0
    I get the "power" neutrality is not to your liking, but RQ = / user agent is no better in my view.=C2=A0

    Can you elaborate?=C2=A0

    Fabien=C2=A0

    Le jeu. 18 mars 2021 =C3=A0 00:18, A= drian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    I= 'm sure you're right. Our vague terminology=C2=A0around client=C2= =A0and=C2=A0end-user leads to my confusion. If GNAP is primarily about dele= gation=C2=A0then, of course, we should=C2=A0avoid any incentives to imperso= nate or we're wasting our time. This is partly why I'm trying to st= udy up on capabilities and asking for expert advice from folks like Alan Ka= rp and Mark Miller (cc'd)

    As best I can understand i= t, the RS has only two choices, it can:
    • store an attribut= e of the RO a [DID, email address, GNAP AS URL], or
    • hand the RO a c= apability as a sort-of promise and avoid making any entries in an ACL or eq= uivalent.
    When a token comes back to the RS, it will either b= e:
    • validated according to something associated with the s= tored RO attribute, or
    • signed by the RS itself.
    E= ither way, trust in the client seems moot.

    Adrian<= /div>



    On Wed, Mar 17, 2021 at 5:29= PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 17, 2021, at 4:55 = PM, Adrian Gropper <agropper@healthurl.com> wrote:=

    On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <tob= ias.looker@mattr.global> wrote:
    =
    <= ;snip>
    > A client might not have a DID but it could have a = VC as a certificate of authenticity linked to some audit mechanism.

    To me a VC would come under the assertions umbrella (that= is to say a VC could be one type of valid assertion). The client may posse= ss or been presented with a VC that it could include in its request to the = AS as a way to identify the subject and perhaps prove authentication and au= thorization.

    I do not assume th= at the client that interacts with the AS to make a request and receive a to= ken is the same as the client that will present the token to the RS. In the= US HIPAA use-case, for example, the root of trust is a contract between th= e patient-subject and the doctor-requesting party but the doctor workflow i= s expected to delegate the token to some other end-user that may be using a= totally different client such as an EHR.

    <= /div>

    If the client that gets the token is not s= ame as the client that uses the token, that is a violation of core security= principles as it allows for (and really designs for) impersonation by clie= nt software. I would have no reason to trust client software that would han= d its credentials over to another piece of software, and in fact I shouldn= =E2=80=99t trust it.=C2=A0

    I think you may be conf= lating several different kinds of parties under the =E2=80=9Cclient=E2=80= =9D umbrella here, though. It=E2=80=99s entirely possible that one client m= ight call an RS that in turn acts as a client for something else down strea= m. But each of those hops is different from the last.

    <= div>=C2=A0=E2=80=94 Justin



    --0000000000006cf8a105bdd2b81a-- From nobody Thu Mar 18 10:21:15 2021 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 B13853A301D for ; Thu, 18 Mar 2021 10:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 ZgeIHqK8g6IC for ; Thu, 18 Mar 2021 10:21:09 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr [80.12.242.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5E283A301A for ; Thu, 18 Mar 2021 10:21:08 -0700 (PDT) Received: from [192.168.1.11] ([90.79.53.231]) by mwinf5d55 with ME id htM22400H4zJUWJ03tM229; Thu, 18 Mar 2021 18:21:06 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Thu, 18 Mar 2021 18:21:06 +0100 X-ME-IP: 90.79.53.231 To: txauth@ietf.org References: <43447446-4061-49F2-8486-5A196C3C75E2@mit.edu> From: Denis Message-ID: <37a04505-84ef-aecf-6913-5aad8330c97c@free.fr> Date: Thu, 18 Mar 2021 18:21:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------84426050735C88B0CAB42E59" Content-Language: en-GB Archived-At: Subject: [GNAP] Should access tokens be opaque or not for the clients ? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 17:21:13 -0000 This is a multi-part message in MIME format. --------------84426050735C88B0CAB42E59 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I have changed the title of this thread, since the original topic has been closed. Justin, you are raising the following question: The question I have is — why does the client need to know what’s in the token? Not if they could possibly know, but why would we expect a client to know and manage the contents of the token? The answer is quite simple: so that the end-user may have confidence into the architecture. The seventh of the eleven privacy principles from ISO 29100 (page 14) is: *7. Openness, transparency and notice * If the access token is considered as a black box for the end-user, it cannot be confident about the content of the access token. Such access token may disclose some private information without the consent of the end-user. If the access token that it has obtained does not match with what has been requested, the client will first not forward the access token to the RS and then will complain about the AS. Denis > Hi Justin, > > "The access token is fundamentally a conversational artifact between > the AS and the RS which the client is the carrier of." > That's right, and a good opportunity to distinguish between the need > for token inspection (i.e. a runtime verification, wherever that may be) > and the need to negotiate the token format (a discovery). That last > part could very well be an extension, as a way to open up the ecosystem > beyond JWTs (which are fine, but come with their own limitations). > > Fabien > > On Thu, Mar 18, 2021 at 5:59 PM Justin Richer > wrote: > > On Mar 18, 2021, at 11:30 AM, Alan Karp > wrote: >> >> Justin Richer > wrote: >> >> On Mar 18, 2021, at 12:08 AM, Alan Karp > > wrote: >>> >>> Adrian Gropper >> > wrote: >>> >>> >>> Is there an AS involved in the delegation? How and where >>> in the lifecycle of the protected resource? >>> >>> >>> If tokens are certificates, the AS need not be involved in >>> subsequent delegations.  The AS must be involved if the >>> tokens are opaque. >> >> Tokens are opaque to the client instance. They are not opaque >> to the AS. They might be opaque to the RS, but that depends >> on the kind of relationship the RS and AS have. GNAP should >> allow different options here as there are different use cases >> for that. >> >> >> Tokens are not opaque to the client in SPKI, zcap-ld, Orie's >> implementation with VCs, or our Zebra Copy work.  Why must they >> be in GNAP? > > The existence of the AS is exactly the reason for this. The AS is > the role that “knowledge about the token contents” has been > outsourced to in the GNAP model (which is based on the OAuth model). > > It brings significant simplicity for the client developer. The > question I have is — why does the client need to know what’s in > the token? Not if they could possibly know, but why would we > expect a client to know and manage the contents of the token? > > The access token is fundamentally a conversational artifact > between the AS and the RS which the client is the carrier of. The > client is not the audience of the token, nor the creator of the > token, nor even the manager of the token and the rights it > represents. The client as a simple carrier is a powerful model > that allows the security layer to get out of the way of the actual > application logic that developers want to do. > >  — Justin > >> >> -------------- >> Alan Karp >> >> >> On Thu, Mar 18, 2021 at 4:56 AM Justin Richer > > wrote: >> >> On Mar 18, 2021, at 12:08 AM, Alan Karp > > wrote: >>> >>> Adrian Gropper >> > wrote: >>> >>> >>> Is there an AS involved in the delegation? How and where >>> in the lifecycle of the protected resource? >>> >>> >>> If tokens are certificates, the AS need not be involved in >>> subsequent delegations.  The AS must be involved if the >>> tokens are opaque. >> >> Tokens are opaque to the client instance. They are not opaque >> to the AS. They might be opaque to the RS, but that depends >> on the kind of relationship the RS and AS have. GNAP should >> allow different options here as there are different use cases >> for that. >> >> It would probably be worthwhile to separate the portions of >> the spec that talk about the RS-AS relationship into its own >> standalone document. A similar approach was taken in UMA2 and >> it was helpful. (Though admittedly, as with anything, there >> are missteps there that we can hopefully learn from.) >> >>  — Justin >> >>> >>> -------------- >>> Alan Karp >>> >>> >>> On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper >>> > wrote: >>> >>> Sure! >>> >>> Is there an AS involved in the delegation? How and where >>> in the lifecycle of the protected resource? >>> >>> Also your use of "the client" seems to imply that either >>> there is only one client or the client doesn't matter. >>> Which is it? >>> >>> Adrian >>> >>> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault >>> >> > wrote: >>> >>> Thanks for that. >>> >>> Trying to reframe it: >>> GNAP is defined as a delegation protocol so the main >>> intent is related to a delegate of the RO (i.e. the >>> end user) that wishes to access the RO's protected >>> resources, through the client. >>> >>> Fabien >>> >>> Le jeu. 18 mars 2021 à 04:29, Adrian Gropper >>> >> > a écrit : >>> >>> At various points in the lifecycle of the >>> protected resource the client at the resource >>> server (RS) might be: >>> >>> * The RO (subject) user agent trading payment >>> for a service promise >>> * The RO user agent using the promise to >>> access the protected resource >>> * A delegate of the RO user agent using a >>> different client >>> >>> What's vague is where the GNAP AS enters the >>> picture as described above. How would you >>> describe it? >>> >>> Adrian >>> >>> >>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault >>> >> > wrote: >>> >>> Hi Adrian >>> >>> I'm still confused why you're saying the >>> terminology is vague. >>> I get the "power" neutrality is not to your >>> liking, but RQ / user agent is no better in >>> my view. >>> >>> Can you elaborate? >>> >>> Fabien >>> >>> Le jeu. 18 mars 2021 à 00:18, Adrian Gropper >>> >> > a écrit : >>> >>> I'm sure you're right. Our vague >>> terminology around client and end-user >>> leads to my confusion. If GNAP is >>> primarily about delegation then, of >>> course, we should avoid any incentives >>> to impersonate or we're wasting our >>> time. This is partly why I'm trying to >>> study up on capabilities and asking for >>> expert advice from folks like Alan Karp >>> and Mark Miller (cc'd) >>> >>> As best I can understand it, the RS has >>> only two choices, it can: >>> >>> * store an attribute of the RO a [DID, >>> email address, GNAP AS URL], or >>> * hand the RO a capability as a >>> sort-of promise and avoid making any >>> entries in an ACL or equivalent. >>> >>> When a token comes back to the RS, it >>> will either be: >>> >>> * validated according to something >>> associated with the stored RO >>> attribute, or >>> * signed by the RS itself. >>> >>> Either way, trust in the client seems moot. >>> >>> Adrian >>> >>> >>> >>> On Wed, Mar 17, 2021 at 5:29 PM Justin >>> Richer >> > wrote: >>> >>> On Mar 17, 2021, at 4:55 PM, Adrian >>> Gropper >> > wrote: >>>> >>>> On Wed, Mar 17, 2021 at 4:23 PM >>>> Tobias Looker >>>> >>> > >>>> wrote: >>>> >>>> >>>> > A client might not have a DID >>>> but it could have a VC as a >>>> certificate of authenticity >>>> linked to some audit mechanism. >>>> >>>> To me a VC would come under the >>>> assertions umbrella (that is to >>>> say a VC could be one type of >>>> valid assertion). The client >>>> may possess or been presented >>>> with a VC that it could include >>>> in its request to the AS as a >>>> way to identify the subject and >>>> perhaps prove authentication >>>> and authorization. >>>> >>>> >>>> I do not assume that the client >>>> that interacts with the AS to make >>>> a request and receive a token is >>>> the same as the client that will >>>> present the token to the RS. In the >>>> US HIPAA use-case, for example, the >>>> root of trust is a contract between >>>> the patient-subject and the >>>> doctor-requesting party but the >>>> doctor workflow is expected to >>>> delegate the token to some other >>>> end-user that may be using a >>>> totally different client such as an >>>> EHR. >>>> >>> >>> If the client that gets the token is >>> not same as the client that uses the >>> token, that is a violation of core >>> security principles as it allows for >>> (and really designs for) >>> impersonation by client software. I >>> would have no reason to trust client >>> software that would hand its >>> credentials over to another piece of >>> software, and in fact I shouldn’t >>> trust it. >>> >>> I think you may be conflating >>> several different kinds of parties >>> under the “client” umbrella here, >>> though. It’s entirely possible that >>> one client might call an RS that in >>> turn acts as a client for something >>> else down stream. But each of those >>> hops is different from the last. >>> >>>  — Justin >>> >> > > --------------84426050735C88B0CAB42E59 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
    I have changed the title of this thread, since the original topic has been closed.

    Justin, you are raising the following question:
    The question I have is — why does the client need to know what’s in the token?
    Not if they could possibly know, but why would we expect a client to know and manage the contents of the token?
    The answer is quite simple: so that the end-user may have confidence into the architecture.
    The seventh of the eleven privacy principles from ISO 29100 (page 14) is:
    7. Openness, transparency and notice
    If the access token is considered as a black box for the end-user, it cannot be confident about the content of the access token.
    Such access token may disclose some private information without the consent of the end-user. If the access token that it has obtained
    does not match with what has been requested, the client will first not forward the access token to the RS and then will complain about the AS.

    Denis


    Hi Justin, 

    "The access token is fundamentally a conversational artifact between the AS and the RS which the client is the carrier of."
    That's right, and a good opportunity to distinguish between the need for token inspection (i.e. a runtime verification, wherever that may be)
    and the need to negotiate the token format (a discovery). That last part could very well be an extension, as a way to open up the ecosystem
    beyond JWTs (which are fine, but come with their own limitations). 

    Fabien

    On Thu, Mar 18, 2021 at 5:59 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 11:30 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 12:08 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Adrian Gropper <agropper@healthurl.com> wrote:

    Is there an AS involved in the delegation? How and where in the lifecycle of the protected resource? 

    If tokens are certificates, the AS need not be involved in subsequent delegations.  The AS must be involved if the tokens are opaque. 

    Tokens are opaque to the client instance. They are not opaque to the AS. They might be opaque to the RS, but that depends on the kind of relationship the RS and AS have. GNAP should allow different options here as there are different use cases for that.

    Tokens are not opaque to the client in SPKI, zcap-ld, Orie's implementation with VCs, or our Zebra Copy work.  Why must they be in GNAP?

    The existence of the AS is exactly the reason for this. The AS is the role that “knowledge about the token contents” has been outsourced to in the GNAP model (which is based on the OAuth model).

    It brings significant simplicity for the client developer. The question I have is — why does the client need to know what’s in the token? Not if they could possibly know, but why would we expect a client to know and manage the contents of the token? 

    The access token is fundamentally a conversational artifact between the AS and the RS which the client is the carrier of. The client is not the audience of the token, nor the creator of the token, nor even the manager of the token and the rights it represents. The client as a simple carrier is a powerful model that allows the security layer to get out of the way of the actual application logic that developers want to do.

     — Justin


    --------------
    Alan Karp


    On Thu, Mar 18, 2021 at 4:56 AM Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 12:08 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Adrian Gropper <agropper@healthurl.com> wrote:

    Is there an AS involved in the delegation? How and where in the lifecycle of the protected resource? 

    If tokens are certificates, the AS need not be involved in subsequent delegations.  The AS must be involved if the tokens are opaque. 

    Tokens are opaque to the client instance. They are not opaque to the AS. They might be opaque to the RS, but that depends on the kind of relationship the RS and AS have. GNAP should allow different options here as there are different use cases for that.

    It would probably be worthwhile to separate the portions of the spec that talk about the RS-AS relationship into its own standalone document. A similar approach was taken in UMA2 and it was helpful. (Though admittedly, as with anything, there are missteps there that we can hopefully learn from.)

     — Justin


    --------------
    Alan Karp


    On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Sure! 

    Is there an AS involved in the delegation? How and where in the lifecycle of the protected resource? 

    Also your use of "the client" seems to imply that either there is only one client or the client doesn't matter. Which is it?

    Adrian

    On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks for that. 

    Trying to reframe it:
    GNAP is defined as a delegation protocol so the main intent is related to a delegate of the RO (i.e. the end user) that wishes to access the RO's protected resources, through the client. 

    Fabien 

    Le jeu. 18 mars 2021 à 04:29, Adrian Gropper <agropper@healthurl.com> a écrit :
    At various points in the lifecycle of the protected resource the client at the resource server (RS) might be:
    • The RO (subject) user agent trading payment for a service promise
    • The RO user agent using the promise to access the protected resource
    • A delegate of the RO user agent using a different client
    What's vague is where the GNAP AS enters the picture as described above. How would you describe it?

    Adrian


    On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Adrian

    I'm still confused why you're saying the terminology is vague. 
    I get the "power" neutrality is not to your liking, but RQ / user agent is no better in my view. 

    Can you elaborate? 

    Fabien 

    Le jeu. 18 mars 2021 à 00:18, Adrian Gropper <agropper@healthurl.com> a écrit :
    I'm sure you're right. Our vague terminology around client and end-user leads to my confusion. If GNAP is primarily about delegation then, of course, we should avoid any incentives to impersonate or we're wasting our time. This is partly why I'm trying to study up on capabilities and asking for expert advice from folks like Alan Karp and Mark Miller (cc'd)

    As best I can understand it, the RS has only two choices, it can:
    • store an attribute of the RO a [DID, email address, GNAP AS URL], or
    • hand the RO a capability as a sort-of promise and avoid making any entries in an ACL or equivalent.
    When a token comes back to the RS, it will either be:
    • validated according to something associated with the stored RO attribute, or
    • signed by the RS itself.
    Either way, trust in the client seems moot.

    Adrian



    On Wed, Mar 17, 2021 at 5:29 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 17, 2021, at 4:55 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <tobias.looker@mattr.global> wrote:
    <snip>
    > A client might not have a DID but it could have a VC as a certificate of authenticity linked to some audit mechanism.

    To me a VC would come under the assertions umbrella (that is to say a VC could be one type of valid assertion). The client may possess or been presented with a VC that it could include in its request to the AS as a way to identify the subject and perhaps prove authentication and authorization.

    I do not assume that the client that interacts with the AS to make a request and receive a token is the same as the client that will present the token to the RS. In the US HIPAA use-case, for example, the root of trust is a contract between the patient-subject and the doctor-requesting party but the doctor workflow is expected to delegate the token to some other end-user that may be using a totally different client such as an EHR.


    If the client that gets the token is not same as the client that uses the token, that is a violation of core security principles as it allows for (and really designs for) impersonation by client software. I would have no reason to trust client software that would hand its credentials over to another piece of software, and in fact I shouldn’t trust it. 

    I think you may be conflating several different kinds of parties under the “client” umbrella here, though. It’s entirely possible that one client might call an RS that in turn acts as a client for something else down stream. But each of those hops is different from the last.

     — Justin





    --------------84426050735C88B0CAB42E59-- From nobody Thu Mar 18 10:25:56 2021 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 342183A302C for ; Thu, 18 Mar 2021 10:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.218 X-Spam-Level: X-Spam-Status: No, score=-4.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 eWYgW8of_05N for ; Thu, 18 Mar 2021 10:25:52 -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 18CD13A302A for ; Thu, 18 Mar 2021 10:25:51 -0700 (PDT) Received: from [192.168.1.22] (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 12IHPkLu031683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Mar 2021 13:25:47 -0400 From: Justin Richer Message-Id: <714CB4F1-DF58-4841-AAA5-93D3B89979E5@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_0B1CAAC3-58AD-44DD-9E6E-0EA863E271D8" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 18 Mar 2021 13:25:46 -0400 In-Reply-To: Cc: Alan Karp , Adrian Gropper , Tobias Looker , GNAP Mailing List , Mark Miller To: Fabien Imbault References: <43447446-4061-49F2-8486-5A196C3C75E2@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 17:25:55 -0000 --Apple-Mail=_0B1CAAC3-58AD-44DD-9E6E-0EA863E271D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Fabien, Exactly, this is why I am more and more thinking that the core protocol = should focus on the client instance->AS / client instance->RS = connections (for which the token is opaque) and a secondary document = would talk about the AS<->RS connection (for which the token is not = opaque). The mapping of the AS and RS roles is also key. In OAuth 1, these were a = single entity known as the =E2=80=9Cserver=E2=80=9D. In OAuth 2, we = decided to split the roles to ease the discussion of how to deploy them. = OAuth 2 doesn=E2=80=99t say anything about how they relate to each other = except that the RS trusts tokens coming from the AS. An AS could have = multiple RS=E2=80=99s that it protects, an RS could accept tokens from = multiple AS=E2=80=99s, these relationships could be statically = configured, they could be dynamic at runtime, etc. The community has = come up with two key extensions =E2=80=94 JWTs and Introspection =E2=80=94= that allow for interoperable ways to make this connection, but OAuth = 2=E2=80=99s core doesn=E2=80=99t actually care how this happens and it = could be proprietary or internal (and often times is in practice). But = in all cases, the RS has outsourced its trust to the AS to create tokens = the RS will accept.=20 =E2=80=94 Justin > On Mar 18, 2021, at 1:13 PM, Fabien Imbault = wrote: >=20 > Hi Justin,=20 >=20 > "The access token is fundamentally a conversational artifact between = the AS and the RS which the client is the carrier of." > That's right, and a good opportunity to distinguish between the need = for token inspection (i.e. a runtime verification, wherever that may be) = and the need to negotiate the token format (a discovery). That last part = could very well be an extension, as a way to open up the ecosystem = beyond JWTs (which are fine, but come with their own limitations).=20 >=20 > Fabien >=20 > On Thu, Mar 18, 2021 at 5:59 PM Justin Richer > wrote: > On Mar 18, 2021, at 11:30 AM, Alan Karp > wrote: >>=20 >> Justin Richer > wrote: >> On Mar 18, 2021, at 12:08 AM, Alan Karp > wrote: >>>=20 >>> Adrian Gropper > wrote: >>>=20 >>> Is there an AS involved in the delegation? How and where in the = lifecycle of the protected resource?=20 >>>=20 >>> If tokens are certificates, the AS need not be involved in = subsequent delegations. The AS must be involved if the tokens are = opaque.=20 >>=20 >> Tokens are opaque to the client instance. They are not opaque to the = AS. They might be opaque to the RS, but that depends on the kind of = relationship the RS and AS have. GNAP should allow different options = here as there are different use cases for that. >>=20 >> Tokens are not opaque to the client in SPKI, zcap-ld, Orie's = implementation with VCs, or our Zebra Copy work. Why must they be in = GNAP? >=20 > The existence of the AS is exactly the reason for this. The AS is the = role that =E2=80=9Cknowledge about the token contents=E2=80=9D has been = outsourced to in the GNAP model (which is based on the OAuth model). >=20 > It brings significant simplicity for the client developer. The = question I have is =E2=80=94 why does the client need to know what=E2=80=99= s in the token? Not if they could possibly know, but why would we expect = a client to know and manage the contents of the token?=20 >=20 > The access token is fundamentally a conversational artifact between = the AS and the RS which the client is the carrier of. The client is not = the audience of the token, nor the creator of the token, nor even the = manager of the token and the rights it represents. The client as a = simple carrier is a powerful model that allows the security layer to get = out of the way of the actual application logic that developers want to = do. >=20 > =E2=80=94 Justin >=20 >>=20 >> -------------- >> Alan Karp >>=20 >>=20 >> On Thu, Mar 18, 2021 at 4:56 AM Justin Richer > wrote: >> On Mar 18, 2021, at 12:08 AM, Alan Karp > wrote: >>>=20 >>> Adrian Gropper > wrote: >>>=20 >>> Is there an AS involved in the delegation? How and where in the = lifecycle of the protected resource?=20 >>>=20 >>> If tokens are certificates, the AS need not be involved in = subsequent delegations. The AS must be involved if the tokens are = opaque.=20 >>=20 >> Tokens are opaque to the client instance. They are not opaque to the = AS. They might be opaque to the RS, but that depends on the kind of = relationship the RS and AS have. GNAP should allow different options = here as there are different use cases for that. >>=20 >> It would probably be worthwhile to separate the portions of the spec = that talk about the RS-AS relationship into its own standalone document. = A similar approach was taken in UMA2 and it was helpful. (Though = admittedly, as with anything, there are missteps there that we can = hopefully learn from.) >>=20 >> =E2=80=94 Justin >>=20 >>>=20 >>> -------------- >>> Alan Karp >>>=20 >>>=20 >>> On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper = > wrote: >>> Sure!=20 >>>=20 >>> Is there an AS involved in the delegation? How and where in the = lifecycle of the protected resource?=20 >>>=20 >>> Also your use of "the client" seems to imply that either there is = only one client or the client doesn't matter. Which is it? >>>=20 >>> Adrian >>>=20 >>> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault = > wrote: >>> Thanks for that.=20 >>>=20 >>> Trying to reframe it: >>> GNAP is defined as a delegation protocol so the main intent is = related to a delegate of the RO (i.e. the end user) that wishes to = access the RO's protected resources, through the client.=20 >>>=20 >>> Fabien=20 >>>=20 >>> Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper = > a =C3=A9crit : >>> At various points in the lifecycle of the protected resource the = client at the resource server (RS) might be: >>> The RO (subject) user agent trading payment for a service promise >>> The RO user agent using the promise to access the protected resource >>> A delegate of the RO user agent using a different client >>> What's vague is where the GNAP AS enters the picture as described = above. How would you describe it? >>>=20 >>> Adrian >>>=20 >>>=20 >>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault = > wrote: >>> Hi Adrian >>>=20 >>> I'm still confused why you're saying the terminology is vague.=20 >>> I get the "power" neutrality is not to your liking, but RQ / user = agent is no better in my view.=20 >>>=20 >>> Can you elaborate?=20 >>>=20 >>> Fabien=20 >>>=20 >>> Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper = > a =C3=A9crit : >>> I'm sure you're right. Our vague terminology around client and = end-user leads to my confusion. If GNAP is primarily about delegation = then, of course, we should avoid any incentives to impersonate or we're = wasting our time. This is partly why I'm trying to study up on = capabilities and asking for expert advice from folks like Alan Karp and = Mark Miller (cc'd) >>>=20 >>> As best I can understand it, the RS has only two choices, it can: >>> store an attribute of the RO a [DID, email address, GNAP AS URL], or >>> hand the RO a capability as a sort-of promise and avoid making any = entries in an ACL or equivalent. >>> When a token comes back to the RS, it will either be: >>> validated according to something associated with the stored RO = attribute, or >>> signed by the RS itself. >>> Either way, trust in the client seems moot. >>>=20 >>> Adrian >>>=20 >>>=20 >>>=20 >>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer > wrote: >>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper > wrote: >>>>=20 >>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker = > wrote: >>>> >>>> > A client might not have a DID but it could have a VC as a = certificate of authenticity linked to some audit mechanism. >>>>=20 >>>> To me a VC would come under the assertions umbrella (that is to say = a VC could be one type of valid assertion). The client may possess or = been presented with a VC that it could include in its request to the AS = as a way to identify the subject and perhaps prove authentication and = authorization. >>>>=20 >>>> I do not assume that the client that interacts with the AS to make = a request and receive a token is the same as the client that will = present the token to the RS. In the US HIPAA use-case, for example, the = root of trust is a contract between the patient-subject and the = doctor-requesting party but the doctor workflow is expected to delegate = the token to some other end-user that may be using a totally different = client such as an EHR. >>>>=20 >>>=20 >>> If the client that gets the token is not same as the client that = uses the token, that is a violation of core security principles as it = allows for (and really designs for) impersonation by client software. I = would have no reason to trust client software that would hand its = credentials over to another piece of software, and in fact I shouldn=E2=80= =99t trust it.=20 >>>=20 >>> I think you may be conflating several different kinds of parties = under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80=99s = entirely possible that one client might call an RS that in turn acts as = a client for something else down stream. But each of those hops is = different from the last. >>>=20 >>> =E2=80=94 Justin >>>=20 >>=20 >=20 --Apple-Mail=_0B1CAAC3-58AD-44DD-9E6E-0EA863E271D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Fabien,

    Exactly, this is why I am more and more thinking that the = core protocol should focus on the client instance->AS / client = instance->RS connections (for which the token is opaque) and a = secondary document would talk about the AS<->RS connection (for = which the token is not opaque).

    The mapping of the AS and RS roles is = also key. In OAuth 1, these were a single entity known as the = =E2=80=9Cserver=E2=80=9D. In OAuth 2, we decided to split the roles to = ease the discussion of how to deploy them. OAuth 2 doesn=E2=80=99t say = anything about how they relate to each other except that the RS trusts = tokens coming from the AS. An AS could have multiple RS=E2=80=99s that = it protects, an RS could accept tokens from multiple AS=E2=80=99s, these = relationships could be statically configured, they could be dynamic at = runtime, etc. The community has come up with two key extensions =E2=80=94 = JWTs and Introspection =E2=80=94 that allow for interoperable ways to = make this connection, but OAuth 2=E2=80=99s core doesn=E2=80=99t = actually care how this happens and it could be proprietary or internal = (and often times is in practice). But in all cases, the RS has = outsourced its trust to the AS to create tokens the RS will = accept. 

     =E2=80=94 Justin

    On Mar = 18, 2021, at 1:13 PM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    Hi Justin, 
    "The access token is fundamentally a = conversational artifact between the AS and the RS which the client is = the carrier of."
    That's right, and a = good opportunity to distinguish between the need for = token inspection (i.e. a runtime verification, wherever that may = be) and the need to negotiate the token format (a discovery). That last = part could very well be an extension, as a way to open up the ecosystem = beyond JWTs (which are fine, but come with their own = limitations). 

    Fabien

    On Thu, Mar = 18, 2021 at 5:59 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 11:30 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, = 2021, at 12:08 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Adrian Gropper <agropper@healthurl.com> wrote:

    Is there an AS involved = in the delegation? How and where in the lifecycle of the protected = resource? 

    If tokens are certificates, the AS need = not be involved in subsequent delegations.  The AS must be involved = if the tokens are opaque. 

    Tokens are opaque to the = client instance. They are not opaque to the AS. They might be opaque to = the RS, but that depends on the kind of relationship the RS and AS have. = GNAP should allow different options here as there are different use = cases for that.

    Tokens are not opaque to the client in SPKI, zcap-ld, Orie's = implementation with VCs, or our Zebra Copy work.  Why must they be = in GNAP?

    The existence of the AS is exactly the = reason for this. The AS is the role that =E2=80=9Cknowledge about the = token contents=E2=80=9D has been outsourced to in the GNAP model (which = is based on the OAuth model).

    It brings significant simplicity for = the client developer. The question I have is =E2=80=94 why does the = client need to know what=E2=80=99s in the token? Not if they could = possibly know, but why would we expect a client to know and manage the = contents of the token? 

    The access token is fundamentally a = conversational artifact between the AS and the RS which the client is = the carrier of. The client is not the audience of the token, nor the = creator of the token, nor even the manager of the token and the rights = it represents. The client as a simple carrier is a powerful model that = allows the security layer to get out of the way of the actual = application logic that developers want to do.

     =E2=80=94 Justin


    --------------
    Alan = Karp


    On Thu, Mar = 18, 2021 at 4:56 AM Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at = 12:08 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Adrian Gropper <agropper@healthurl.com> wrote:

    Is there an AS involved = in the delegation? How and where in the lifecycle of the protected = resource? 

    If tokens are certificates, the AS need = not be involved in subsequent delegations.  The AS must be involved = if the tokens are opaque. 

    Tokens are opaque to the = client instance. They are not opaque to the AS. They might be opaque to = the RS, but that depends on the kind of relationship the RS and AS have. = GNAP should allow different options here as there are different use = cases for that.

    It would probably be worthwhile to separate the portions of = the spec that talk about the RS-AS relationship into its own standalone = document. A similar approach was taken in UMA2 and it was helpful. = (Though admittedly, as with anything, there are missteps there that we = can hopefully learn from.)

     =E2=80=94 Justin


    --------------
    Alan = Karp


    On Wed, Mar = 17, 2021 at 8:54 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Sure! 

    Is there an AS involved in the delegation? How and where in = the lifecycle of the protected resource? 

    Also your use of "the client" seems to = imply that either there is only one client or the client doesn't matter. = Which is it?

    Adrian

    On Wed, Mar = 17, 2021 at 11:43 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks for that. 

    Trying to reframe = it:
    GNAP is defined as a delegation = protocol so the main intent is related to a delegate of the RO (i.e. the = end user) that wishes to access the RO's protected resources, through = the client. 

    Fabien 

    Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper = <agropper@healthurl.com> a =C3=A9crit :
    At = various points in the lifecycle of the protected resource the = client at the resource server (RS) might be:
    • The RO (subject) user agent trading payment = for a service promise
    • The RO user agent using the = promise to access the protected resource
    • A delegate = of the RO user agent using a different client
    What's vague is where the GNAP AS enters the picture as = described above. How would you describe it?
    Adrian


    On Wed, Mar 17, 2021 at 10:20 PM Fabien = Imbault <fabien.imbault@gmail.com> wrote:
    Hi = Adrian

    I'm still confused why you're saying the terminology is = vague. 
    I get the "power" = neutrality is not to your liking, but RQ / user agent is no better in my = view. 

    Can you elaborate? 

    Fabien 

    Le jeu. 18 = mars 2021 =C3=A0 00:18, Adrian Gropper <agropper@healthurl.com> a = =C3=A9crit :
    I'm sure = you're right. Our vague terminology around = client and end-user leads to my confusion. If GNAP is = primarily about delegation then, of course, we should avoid = any incentives to impersonate or we're wasting our time. This is partly = why I'm trying to study up on capabilities and asking for expert advice = from folks like Alan Karp and Mark Miller (cc'd)

    As best I can understand it, the RS has = only two choices, it can:
    • store an attribute of the RO a [DID, email address, GNAP AS = URL], or
    • hand the RO a capability as a sort-of = promise and avoid making any entries in an ACL or = equivalent.
    When a token comes back to the RS, = it will either be:
    • validated according to something associated with the stored = RO attribute, or
    • signed by the RS = itself.
    Either way, trust in the client seems = moot.

    Adrian



    On Wed, Mar = 17, 2021 at 5:29 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 17, = 2021, at 4:55 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <tobias.looker@mattr.global> = wrote:
    <snip>
    > A client might not = have a DID but it could have a VC as a certificate of authenticity = linked to some audit mechanism.

    To me a VC would come under the = assertions umbrella (that is to say a VC could be one type of valid = assertion). The client may possess or been presented with a VC that it = could include in its request to the AS as a way to identify the subject = and perhaps prove authentication and = authorization.

    I do not assume that the client that = interacts with the AS to make a request and receive a token is the same = as the client that will present the token to the RS. In the US HIPAA = use-case, for example, the root of trust is a contract between the = patient-subject and the doctor-requesting party but the doctor workflow = is expected to delegate the token to some other end-user that may be = using a totally different client such as an EHR.


    If the client that gets the token is not same as the client = that uses the token, that is a violation of core security principles as = it allows for (and really designs for) impersonation by client software. = I would have no reason to trust client software that would hand its = credentials over to another piece of software, and in fact I shouldn=E2=80= =99t trust it. 

    I think you may be conflating several different kinds of = parties under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80= =99s entirely possible that one client might call an RS that in turn = acts as a client for something else down stream. But each of those hops = is different from the last.

     =E2=80=94 Justin




    = --Apple-Mail=_0B1CAAC3-58AD-44DD-9E6E-0EA863E271D8-- From nobody Thu Mar 18 10:28:39 2021 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 A7D813A303E for ; Thu, 18 Mar 2021 10:28:37 -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 gW2XRELHioc3 for ; Thu, 18 Mar 2021 10:28:35 -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 E584D3A303B for ; Thu, 18 Mar 2021 10:28:34 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id x16so3124555iob.1 for ; Thu, 18 Mar 2021 10:28: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=Cd2PIRcDoVAGKeKohKakN/tIx+0MPny6Q8S7eNQKBuw=; b=X2/I7qAhPAmSOwBRrDPT3Hb5utzHPsYKFveU8vyIgK+6plC+xtmvI94Y8+tb/k3IAM myBHyvWaVmG5JwFwhzQkFBZBAhHFZ2gmobn+FgrmjU+AJFZjBAVT4Jf/OIsl/dcULjkY /QI+NcqeIkm2vEdf0HA7h9p1VYWa3wMe1+Sg7VaI7GkmJacaU17yjvJ4ZeePsACy2AK7 HfXYbtCUErA9BnN8DuWYrMjW/m/imFbqVWHvb3ZD0r5laEXiXaXnOMfq31Sqn7BbBB1b tH2QaBHiPgB2IoWsJTSiBmMP5S7aFrP32Ew4fl4hHM0Oc42ApBoeaUC3nn0YRMtGl7cP Jyww== 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=Cd2PIRcDoVAGKeKohKakN/tIx+0MPny6Q8S7eNQKBuw=; b=F8SpLXbNOte3N9SYw1Ut3BgHanxhJla3sY6QVbrtq5cmrPWHsfDdQkO2aTkbF4obEv /e+E4t9lInQyuaQUFXkiyg4EF5WMT6fqJQy/p7QxyaQSXTGdIjsEp5xTG1v6OQOKYM0P 3ey7go4HeJDf0iaxC9s6zomLJbY9+Dh2m7fagxwhH+6geoISuIeQ9Sqgk9MdozGFPPIq +hYGXCXCh1x+h1moru60rG7E7eSnn/tWWOsoOB5q/yNpqD84JGVc7eIdCH3QuqKvSywe IaE4DEXi+Excn1XSoHIjJI4hPghnOLz9NkWtrApdX/F5tt6uNrqZZmTwOwL6/vDNVf8E 3DDg== X-Gm-Message-State: AOAM532YcmGrCMZ3DdhyN3+w45dUcK8nLwLbJESOFt8chwfUZ0idQYIP Q/aHXCoYLf9GQ1HELMPfwtNib0nrXalgdWb27mI= X-Google-Smtp-Source: ABdhPJyBAyEDQCv/hOKsyYrD/V4KvL25MNtKzdJIp1Mm3PzouQ94xkVSM4Ky1TXsVn6NnFlErdi0mRl3OcT6Fa7X0NE= X-Received: by 2002:a02:ca13:: with SMTP id i19mr8014502jak.47.1616088513514; Thu, 18 Mar 2021 10:28:33 -0700 (PDT) MIME-Version: 1.0 References: <43447446-4061-49F2-8486-5A196C3C75E2@mit.edu> <714CB4F1-DF58-4841-AAA5-93D3B89979E5@mit.edu> In-Reply-To: <714CB4F1-DF58-4841-AAA5-93D3B89979E5@mit.edu> From: Fabien Imbault Date: Thu, 18 Mar 2021 18:28:22 +0100 Message-ID: To: Justin Richer Cc: Alan Karp , Adrian Gropper , Tobias Looker , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="000000000000c614ac05bdd2eda1" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 17:28:38 -0000 --000000000000c614ac05bdd2eda1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 with that On Thu, Mar 18, 2021 at 6:25 PM Justin Richer wrote: > Fabien, > > Exactly, this is why I am more and more thinking that the core protocol > should focus on the client instance->AS / client instance->RS connections > (for which the token is opaque) and a secondary document would talk about > the AS<->RS connection (for which the token is not opaque). > > The mapping of the AS and RS roles is also key. In OAuth 1, these were a > single entity known as the =E2=80=9Cserver=E2=80=9D. In OAuth 2, we decid= ed to split the > roles to ease the discussion of how to deploy them. OAuth 2 doesn=E2=80= =99t say > anything about how they relate to each other except that the RS trusts > tokens coming from the AS. An AS could have multiple RS=E2=80=99s that it= protects, > an RS could accept tokens from multiple AS=E2=80=99s, these relationships= could be > statically configured, they could be dynamic at runtime, etc. The communi= ty > has come up with two key extensions =E2=80=94 JWTs and Introspection =E2= =80=94 that allow > for interoperable ways to make this connection, but OAuth 2=E2=80=99s cor= e doesn=E2=80=99t > actually care how this happens and it could be proprietary or internal (a= nd > often times is in practice). But in all cases, the RS has outsourced its > trust to the AS to create tokens the RS will accept. > > =E2=80=94 Justin > > On Mar 18, 2021, at 1:13 PM, Fabien Imbault > wrote: > > Hi Justin, > > "The access token is fundamentally a conversational artifact between the > AS and the RS which the client is the carrier of." > That's right, and a good opportunity to distinguish between the need for > token inspection (i.e. a runtime verification, wherever that may be) and > the need to negotiate the token format (a discovery). That last part coul= d > very well be an extension, as a way to open up the ecosystem beyond JWTs > (which are fine, but come with their own limitations). > > Fabien > > On Thu, Mar 18, 2021 at 5:59 PM Justin Richer wrote: > >> On Mar 18, 2021, at 11:30 AM, Alan Karp wrote: >> >> >> Justin Richer wrote: >> >>> On Mar 18, 2021, at 12:08 AM, Alan Karp wrote: >>> >>> >>> Adrian Gropper wrote: >>> >>>> >>>> Is there an AS involved in the delegation? How and where in the >>>> lifecycle of the protected resource? >>>> >>> >>> If tokens are certificates, the AS need not be involved in subsequent >>> delegations. The AS must be involved if the tokens are opaque. >>> >>> >>> Tokens are opaque to the client instance. They are not opaque to the AS= . >>> They might be opaque to the RS, but that depends on the kind of >>> relationship the RS and AS have. GNAP should allow different options he= re >>> as there are different use cases for that. >>> >> >> Tokens are not opaque to the client in SPKI, zcap-ld, Orie's >> implementation with VCs, or our Zebra Copy work. Why must they be in GN= AP? >> >> >> The existence of the AS is exactly the reason for this. The AS is the >> role that =E2=80=9Cknowledge about the token contents=E2=80=9D has been = outsourced to in >> the GNAP model (which is based on the OAuth model). >> >> It brings significant simplicity for the client developer. The question = I >> have is =E2=80=94 why does the client need to know what=E2=80=99s in the= token? Not if they >> could possibly know, but why would we expect a client to know and manage >> the contents of the token? >> >> The access token is fundamentally a conversational artifact between the >> AS and the RS which the client is the carrier of. The client is not the >> audience of the token, nor the creator of the token, nor even the manage= r >> of the token and the rights it represents. The client as a simple carrie= r >> is a powerful model that allows the security layer to get out of the way= of >> the actual application logic that developers want to do. >> >> =E2=80=94 Justin >> >> >> -------------- >> Alan Karp >> >> >> On Thu, Mar 18, 2021 at 4:56 AM Justin Richer wrote: >> >>> On Mar 18, 2021, at 12:08 AM, Alan Karp wrote: >>> >>> >>> Adrian Gropper wrote: >>> >>>> >>>> Is there an AS involved in the delegation? How and where in the >>>> lifecycle of the protected resource? >>>> >>> >>> If tokens are certificates, the AS need not be involved in subsequent >>> delegations. The AS must be involved if the tokens are opaque. >>> >>> >>> Tokens are opaque to the client instance. They are not opaque to the AS= . >>> They might be opaque to the RS, but that depends on the kind of >>> relationship the RS and AS have. GNAP should allow different options he= re >>> as there are different use cases for that. >>> >>> It would probably be worthwhile to separate the portions of the spec >>> that talk about the RS-AS relationship into its own standalone document= . A >>> similar approach was taken in UMA2 and it was helpful. (Though admitted= ly, >>> as with anything, there are missteps there that we can hopefully learn >>> from.) >>> >>> =E2=80=94 Justin >>> >>> >>> -------------- >>> Alan Karp >>> >>> >>> On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper >>> wrote: >>> >>>> Sure! >>>> >>>> Is there an AS involved in the delegation? How and where in the >>>> lifecycle of the protected resource? >>>> >>>> Also your use of "the client" seems to imply that either there is only >>>> one client or the client doesn't matter. Which is it? >>>> >>>> Adrian >>>> >>>> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Thanks for that. >>>>> >>>>> Trying to reframe it: >>>>> GNAP is defined as a delegation protocol so the main intent is relate= d >>>>> to a delegate of the RO (i.e. the end user) that wishes to access the= RO's >>>>> protected resources, through the client. >>>>> >>>>> Fabien >>>>> >>>>> Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper >>>>> a =C3=A9crit : >>>>> >>>>>> At various points in the lifecycle of the protected resource the >>>>>> client at the resource server (RS) might be: >>>>>> >>>>>> - The RO (subject) user agent trading payment for a service >>>>>> promise >>>>>> - The RO user agent using the promise to access the protected >>>>>> resource >>>>>> - A delegate of the RO user agent using a different client >>>>>> >>>>>> What's vague is where the GNAP AS enters the picture as described >>>>>> above. How would you describe it? >>>>>> >>>>>> Adrian >>>>>> >>>>>> >>>>>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>>> Hi Adrian >>>>>>> >>>>>>> I'm still confused why you're saying the terminology is vague. >>>>>>> I get the "power" neutrality is not to your liking, but RQ / user >>>>>>> agent is no better in my view. >>>>>>> >>>>>>> Can you elaborate? >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper >>>>>>> a =C3=A9crit : >>>>>>> >>>>>>>> I'm sure you're right. Our vague terminology around >>>>>>>> client and end-user leads to my confusion. If GNAP is primarily ab= out >>>>>>>> delegation then, of course, we should avoid any incentives to impe= rsonate >>>>>>>> or we're wasting our time. This is partly why I'm trying to study = up on >>>>>>>> capabilities and asking for expert advice from folks like Alan Kar= p and >>>>>>>> Mark Miller (cc'd) >>>>>>>> >>>>>>>> As best I can understand it, the RS has only two choices, it can: >>>>>>>> >>>>>>>> - store an attribute of the RO a [DID, email address, GNAP AS >>>>>>>> URL], or >>>>>>>> - hand the RO a capability as a sort-of promise and avoid >>>>>>>> making any entries in an ACL or equivalent. >>>>>>>> >>>>>>>> When a token comes back to the RS, it will either be: >>>>>>>> >>>>>>>> - validated according to something associated with the stored >>>>>>>> RO attribute, or >>>>>>>> - signed by the RS itself. >>>>>>>> >>>>>>>> Either way, trust in the client seems moot. >>>>>>>> >>>>>>>> Adrian >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper < >>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker < >>>>>>>>> tobias.looker@mattr.global> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> > A client might not have a DID but it could have a VC as a >>>>>>>>>> certificate of authenticity linked to some audit mechanism. >>>>>>>>>> >>>>>>>>>> To me a VC would come under the assertions umbrella (that is to >>>>>>>>>> say a VC could be one type of valid assertion). The client may p= ossess or >>>>>>>>>> been presented with a VC that it could include in its request to= the AS as >>>>>>>>>> a way to identify the subject and perhaps prove authentication a= nd >>>>>>>>>> authorization. >>>>>>>>>> >>>>>>>>> >>>>>>>>> I do not assume that the client that interacts with the AS to mak= e >>>>>>>>> a request and receive a token is the same as the client that will= present >>>>>>>>> the token to the RS. In the US HIPAA use-case, for example, the r= oot of >>>>>>>>> trust is a contract between the patient-subject and the doctor-re= questing >>>>>>>>> party but the doctor workflow is expected to delegate the token t= o some >>>>>>>>> other end-user that may be using a totally different client such = as an EHR. >>>>>>>>> >>>>>>>>> >>>>>>>>> If the client that gets the token is not same as the client that >>>>>>>>> uses the token, that is a violation of core security principles a= s it >>>>>>>>> allows for (and really designs for) impersonation by client softw= are. I >>>>>>>>> would have no reason to trust client software that would hand its >>>>>>>>> credentials over to another piece of software, and in fact I shou= ldn=E2=80=99t >>>>>>>>> trust it. >>>>>>>>> >>>>>>>>> I think you may be conflating several different kinds of parties >>>>>>>>> under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2= =80=99s entirely possible that one >>>>>>>>> client might call an RS that in turn acts as a client for somethi= ng else >>>>>>>>> down stream. But each of those hops is different from the last. >>>>>>>>> >>>>>>>>> =E2=80=94 Justin >>>>>>>>> >>>>>>>>> >>> >> > --000000000000c614ac05bdd2eda1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    +1 with that

    On Thu, Mar 18, 2021 at 6:25 PM Justin Ric= her <jricher@mit.edu> wrote:
    Fabien,

    Exactly, this is why I = am more and more thinking that the core protocol should focus on the client= instance->AS / client instance->RS connections (for which the token = is opaque) and a secondary document would talk about the AS<->RS conn= ection (for which the token is not opaque).

    The ma= pping of the AS and RS roles is also key. In OAuth 1, these were a single e= ntity known as the =E2=80=9Cserver=E2=80=9D. In OAuth 2, we decided to spli= t the roles to ease the discussion of how to deploy them. OAuth 2 doesn=E2= =80=99t say anything about how they relate to each other except that the RS= trusts tokens coming from the AS. An AS could have multiple RS=E2=80=99s t= hat it protects, an RS could accept tokens from multiple AS=E2=80=99s, thes= e relationships could be statically configured, they could be dynamic at ru= ntime, etc. The community has come up with two key extensions =E2=80=94 JWT= s and Introspection =E2=80=94 that allow for interoperable ways to make thi= s connection, but OAuth 2=E2=80=99s core doesn=E2=80=99t actually care how = this happens and it could be proprietary or internal (and often times is in= practice). But in all cases, the RS has outsourced its trust to the AS to = create tokens the RS will accept.=C2=A0

    =C2=A0=E2= =80=94 Justin

    On Mar 18, 2021, a= t 1:13 PM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    Hi Justin,=C2=A0

    "The access token is = fundamentally a conversational artifact between the AS and the RS which the= client is the carrier of."
    That's right,=C2=A0and a goo= d=C2=A0opportunity to distinguish between the need for token=C2=A0inspectio= n (i.e. a runtime verification, wherever that may be) and the need to negot= iate the token format (a discovery). That last part could very well be an e= xtension, as a way to open up the ecosystem beyond JWTs (which are fine, bu= t come with their own limitations).=C2=A0

    Fabien

    On Thu, Mar 18, 2021 at 5:59 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 11:= 30 AM, Alan Karp <alanhkarp@gmail.com> wrote:
    Justin Richer <j= richer@mit.edu> wrote:
    On Mar 18, 2021, at 12:08 AM, Alan Karp <alanhkarp@gmail.com> wr= ote:

    Adrian Gropper <agropper@healthurl.com= > wrote:
    =

    Is there an AS involved in the delegat= ion? How and where in the lifecycle=C2=A0of the protected resource?=C2=A0

    If tokens are certificates, the = AS need not be involved in subsequent delegations.=C2=A0 The AS must be inv= olved if the tokens are opaque.=C2=A0
    <= div>
    Tokens are opaque to the client instance. They are not o= paque to the AS. They might be opaque to the RS, but that depends on the ki= nd of relationship the RS and AS have. GNAP should allow different options = here as there are different use cases for that.

    Tokens are not opaque to= the client in SPKI, zcap-ld, Orie's implementation with VCs, or our Ze= bra Copy work.=C2=A0 Why must they be in GNAP?

    The existence of the AS is exactly the re= ason for this. The AS is the role that =E2=80=9Cknowledge about the token c= ontents=E2=80=9D has been outsourced to in the GNAP model (which is based o= n the OAuth model).

    It brings significant simplici= ty for the client developer. The question I have is =E2=80=94 why does the = client need to know what=E2=80=99s in the token? Not if they could possibly= know, but why would we expect a client to know and manage the contents of = the token?=C2=A0

    The access token is fundamentally= a conversational artifact between the AS and the RS which the client is th= e carrier of. The client is not the audience of the token, nor the creator = of the token, nor even the manager of the token and the rights it represent= s. The client as a simple carrier is a powerful model that allows the secur= ity layer to get out of the way of the actual application logic that develo= pers want to do.

    =C2=A0=E2=80=94 Justin

    <= blockquote type=3D"cite">

    --------------
    Alan Karp


    On Thu, Mar 18, 2= 021 at 4:56 AM Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 12:08 AM, Alan Karp <= ;alanhkarp@gmail.c= om> wrote:

    Adrian Gropper &l= t;agropper@heal= thurl.com> wrote:

    Is there an AS involved in = the delegation? How and where in the lifecycle=C2=A0of the protected resour= ce?=C2=A0

    If tokens are certifi= cates, the AS need not be involved in subsequent delegations.=C2=A0 The AS = must be involved if the tokens are opaque.=C2=A0

    Tokens are opaque to the client instance. The= y are not opaque to the AS. They might be opaque to the RS, but that depend= s on the kind of relationship the RS and AS have. GNAP should allow differe= nt options here as there are different use cases for that.

    It would probably be worthwhile to separate the portions of the sp= ec that talk about the RS-AS relationship into its own standalone document.= A similar approach was taken in UMA2 and it was helpful. (Though admittedl= y, as with anything, there are missteps there that we can hopefully learn f= rom.)

    =C2=A0=E2=80=94 Justin


    --------------
    Alan Karp


    On Wed, Mar 17, 2= 021 at 8:54 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Sure!=C2=A0
    <= br>
    Is there an AS involved in the delegation? How and where in t= he lifecycle=C2=A0of the protected resource?=C2=A0

    Also = your use of "the client" seems to imply that either there is only= one client or the client doesn't matter. Which is it?
    =
    Adrian

    On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault = <fabien.im= bault@gmail.com> wrote:
    Thanks for that.=C2=A0

    Trying to reframe it:
    GNAP is defined as a delegation protocol so the main intent is re= lated to a delegate of the RO (i.e. the end user) that wishes to access the= RO's protected resources, through the client.=C2=A0

    Fabien=C2=A0

    Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian G= ropper <agro= pper@healthurl.com> a =C3=A9crit=C2=A0:
    At various points in the = lifecycle=C2=A0of the protected resource the client at the resource server = (RS) might be:
    • The RO (subject) user agent trading payment for = a service promise
    • The RO user agent using the promise to access the= protected resource
    • A delegate of the RO user agent using a differe= nt client
    What's vague is where the GNAP AS enters the pi= cture as described above. How would you describe it?

    Adrian


    On Wed, Mar 17, 2021 at 10:20 PM Fabien= Imbault <fabien.imbault@gmail.com> wrote:
    Hi Adrian

    I'm still confused why you'= ;re saying the terminology is vague.=C2=A0
    I get the= "power" neutrality is not to your liking, but RQ / user agent is= no better in my view.=C2=A0

    Can you elaborate?=C2=A0

    Fabien=C2=A0

    Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper &= lt;agropper@healthurl.com> a =C3=A9crit=C2=A0:
    I'm sure you= 're right. Our vague terminology=C2=A0around client=C2=A0and=C2=A0end-u= ser leads to my confusion. If GNAP is primarily about delegation=C2=A0then,= of course, we should=C2=A0avoid any incentives to impersonate or we're= wasting our time. This is partly why I'm trying to study up on capabil= ities and asking for expert advice from folks like Alan Karp and Mark Mille= r (cc'd)

    As best I can understand it, the RS has onl= y two choices, it can:
    • store an attribute of the RO a [DI= D, email address, GNAP AS URL], or
    • hand the RO a capability as a so= rt-of promise and avoid making any entries in an ACL or equivalent.
      • When a token comes back to the RS, it will either be:
        =
      • validated according to something associated with the stored RO attribut= e, or
      • signed by the RS itself.
      Either way, trust = in the client seems moot.

      Adrian
      <= br>


    On Wed, Mar 17, 2021 at 5:29 PM Justin Richer= <jricher@mit.edu> wrote:
    On Mar 17, 2021, at 4:55 PM, Adrian Groppe= r <agropper@healthurl.com> wrote:

    On Wed, Mar 17= , 2021 at 4:23 PM Tobias Looker <tobias.looker@mattr.= global> wrote:
    <snip>
    > A client might not have a DID but it could have a VC as a certifica= te of authenticity linked to some audit mechanism.

    To me a VC would come under the assertions umbrella (that is to say a VC c= ould be one type of valid assertion). The client may possess or been presen= ted with a VC that it could include in its request to the AS as a way to id= entify the subject and perhaps prove authentication and authorization.

    I do not assume that the client tha= t interacts with the AS to make a request and receive a token is the same a= s the client that will present the token to the RS. In the US HIPAA use-cas= e, for example, the root of trust is a contract between the patient-subject= and the doctor-requesting party but the doctor workflow is expected to del= egate the token to some other end-user that may be using a totally differen= t client such as an EHR.


    If the client that gets the token is not same as the client= that uses the token, that is a violation of core security principles as it= allows for (and really designs for) impersonation by client software. I wo= uld have no reason to trust client software that would hand its credentials= over to another piece of software, and in fact I shouldn=E2=80=99t trust i= t.=C2=A0

    I think you may be conflating several dif= ferent kinds of parties under the =E2=80=9Cclient=E2=80=9D umbrella here, t= hough. It=E2=80=99s entirely possible that one client might call an RS that= in turn acts as a client for something else down stream. But each of those= hops is different from the last.

    =C2=A0=E2=80=94 = Justin




    --000000000000c614ac05bdd2eda1-- From nobody Thu Mar 18 10:59:23 2021 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 7D5A63A30C0 for ; Thu, 18 Mar 2021 10:59:21 -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, 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 y7316njtD9NV for ; Thu, 18 Mar 2021 10:59:18 -0700 (PDT) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (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 25C5E3A3187 for ; Thu, 18 Mar 2021 10:59:08 -0700 (PDT) Received: by mail-ej1-x632.google.com with SMTP id b9so5358191ejc.11 for ; Thu, 18 Mar 2021 10:59: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; bh=C4UUcHZVvkvt3rN6yaKjMbtEzzWUuSpKUjfwBJgpF3g=; b=AMcSYQ13eszVgVJVoUTsU710C2Snw5lFj3I6WHrXY7bh+QED48MiUZRH7uuGplr3wt KpZewYielCETqhI6Y7QtkRkN/XQkgRnmdy+pYa78mHWTW9xqGlTzfCuwL9uHmrCInepC 1aPCelLuTac5AtOFHTJblkToSB4ZHMCD/OhBeUDRitDVPNev0cMKDlWNVTCBGYNtVh+4 kGilElPAIpwuWesP72uVnne0znqt7JFCkliBm3EMFTrN8xTMVSa1RVnRb+yTl5iu10Gs kFprFE7nBqWpAKGeDk6I/7zmF0YJyCbtdjAJKYzsmaD7b/dBlTnN3DiADQPtFhJDNpoI eYzA== 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=C4UUcHZVvkvt3rN6yaKjMbtEzzWUuSpKUjfwBJgpF3g=; b=Uea/eaRDZLn7Wv4dOkYoG+FmGZNYlDKIV/xVTLcHPgqS8vlpHsFV4C6bSAqN5OYCHI c5OFS10xW6DvwE7ooUU2JJ6LxNlbJGxlOmElz1nSGnKIc6s9uYoePSF15emvd2xXYyg+ +PzhOARUkciTe2j63l/++w7JGrKRGPArB+7PdnCK3lz7Viy7w3DXJQkpUSRoHw/XgckE v3FrUrXHc0TBizU9yfro0jh/KANekwBAmpcitr0+y2hKMCdc/jf1G9QrGDq7DYJjNQaw lJmECnzyGViHsG6+iEF++vKPDFJoVQzp72ucehCpo1TDKHvUWf+4LmUb9Z3ztEY53jIm 0l1Q== X-Gm-Message-State: AOAM5307pAAHZ7532VMC9H3abdSOyKkZGkoJbeADC3vHAJse3VuukZgZ l2QhBW5FgtTghVBT9+N9O4jZym+U9gbKhtPS3A2WGzZOU84= X-Google-Smtp-Source: ABdhPJxmsGTXrrqSDFMpsH7Gzamg0tEqTEEO54octmF1U0Su5bjGs1khmT7XaBywGvrOutAvfnXDBwYB3+Um4KYP/EE= X-Received: by 2002:a17:906:ae96:: with SMTP id md22mr40809223ejb.409.1616090345675; Thu, 18 Mar 2021 10:59:05 -0700 (PDT) MIME-Version: 1.0 References: <43447446-4061-49F2-8486-5A196C3C75E2@mit.edu> <37a04505-84ef-aecf-6913-5aad8330c97c@free.fr> In-Reply-To: <37a04505-84ef-aecf-6913-5aad8330c97c@free.fr> From: Stephen Moore Date: Thu, 18 Mar 2021 13:58:54 -0400 Message-ID: To: txauth gnap Content-Type: multipart/alternative; boundary="000000000000fa9f2305bdd35a5e" Archived-At: Subject: Re: [GNAP] Should access tokens be opaque or not for the clients ? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 17:59:22 -0000 --000000000000fa9f2305bdd35a5e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm having some concerns with the way you're flipping the trust here Denis. You seem to indicate that the user has trust in the RS and the Client and has to gain the trust of the AS. I feel like the least trustworthy portion of the architecture is the client, because that seems like it is the most interchangeable component. Let me explain by way of a use case I have in mind. Let's say I have a smart home. I have devices and data storage and rule engines that are parts of sensors and hubs I buy for the house. I have a trust in those devices, because it's hardware, if the company is leaking data at the hardware level there isn't much I can do other than buy different sensors. In this case, the primary home hub, which is under control of the homeowner, would also be the AS, as well as a policy agent. Authentication in the example is outsourced to whatever auth providers you want. I set up my home using a google account, a friend is staying and wants access and uses FB for auth... whatever. The part that I have little control over is the client my friend uses on his phone. Or if I change the client on the tablet in the kitchen to try out something new. These pieces might be single page web apps, they might be downloaded apps, etc. I do not want them having any additional information than is necessary. If I give my friend permission to unlock the door, and control the lights because they are feeding my cats while I'm away, the client doesn't need to know anything beyond, I see this home controller, and I have access to these lights and that door lock. In your scenarios, the client is spy by design, and if it is a web app, I don't trust them to not grab my user email address from the AS and put it on a mailing list it sells to some sketchy company, when the only other component that needs that information is the RS. -steve On Thu, Mar 18, 2021 at 1:21 PM Denis wrote: > I have changed the title of this thread, since the original topic has bee= n > closed. > > Justin, you are raising the following question: > > The question I have is =E2=80=94 why does the client need to know what=E2= =80=99s in the > token? > Not if they could possibly know, but why would we expect a client to know > and manage the contents of the token? > > The answer is quite simple: so that the end-user may have confidence into > the architecture. > The seventh of the eleven privacy principles from ISO 29100 (page 14) is: > > *7. Openness, transparency and notice * > > If the access token is considered as a black box for the end-user, it > cannot be confident about the content of the access token. > Such access token may disclose some private information without the > consent of the end-user. If the access token that it has obtained > does not match with what has been requested, the client will first not > forward the access token to the RS and then will complain about the AS. > > Denis > > > Hi Justin, > > "The access token is fundamentally a conversational artifact between the > AS and the RS which the client is the carrier of." > That's right, and a good opportunity to distinguish between the need for > token inspection (i.e. a runtime verification, wherever that may be) > and the need to negotiate the token format (a discovery). That last part > could very well be an extension, as a way to open up the ecosystem > beyond JWTs (which are fine, but come with their own limitations). > > Fabien > > On Thu, Mar 18, 2021 at 5:59 PM Justin Richer wrote: > >> On Mar 18, 2021, at 11:30 AM, Alan Karp wrote: >> >> >> Justin Richer wrote: >> >>> On Mar 18, 2021, at 12:08 AM, Alan Karp wrote: >>> >>> >>> Adrian Gropper wrote: >>> >>>> >>>> Is there an AS involved in the delegation? How and where in the >>>> lifecycle of the protected resource? >>>> >>> >>> If tokens are certificates, the AS need not be involved in subsequent >>> delegations. The AS must be involved if the tokens are opaque. >>> >>> >>> Tokens are opaque to the client instance. They are not opaque to the AS= . >>> They might be opaque to the RS, but that depends on the kind of >>> relationship the RS and AS have. GNAP should allow different options he= re >>> as there are different use cases for that. >>> >> >> Tokens are not opaque to the client in SPKI, zcap-ld, Orie's >> implementation with VCs, or our Zebra Copy work. Why must they be in GN= AP? >> >> >> The existence of the AS is exactly the reason for this. The AS is the >> role that =E2=80=9Cknowledge about the token contents=E2=80=9D has been = outsourced to in >> the GNAP model (which is based on the OAuth model). >> >> It brings significant simplicity for the client developer. The question = I >> have is =E2=80=94 why does the client need to know what=E2=80=99s in the= token? Not if they >> could possibly know, but why would we expect a client to know and manage >> the contents of the token? >> >> The access token is fundamentally a conversational artifact between the >> AS and the RS which the client is the carrier of. The client is not the >> audience of the token, nor the creator of the token, nor even the manage= r >> of the token and the rights it represents. The client as a simple carrie= r >> is a powerful model that allows the security layer to get out of the way= of >> the actual application logic that developers want to do. >> >> =E2=80=94 Justin >> >> >> -------------- >> Alan Karp >> >> >> On Thu, Mar 18, 2021 at 4:56 AM Justin Richer wrote: >> >>> On Mar 18, 2021, at 12:08 AM, Alan Karp wrote: >>> >>> >>> Adrian Gropper wrote: >>> >>>> >>>> Is there an AS involved in the delegation? How and where in the >>>> lifecycle of the protected resource? >>>> >>> >>> If tokens are certificates, the AS need not be involved in subsequent >>> delegations. The AS must be involved if the tokens are opaque. >>> >>> >>> Tokens are opaque to the client instance. They are not opaque to the AS= . >>> They might be opaque to the RS, but that depends on the kind of >>> relationship the RS and AS have. GNAP should allow different options he= re >>> as there are different use cases for that. >>> >>> It would probably be worthwhile to separate the portions of the spec >>> that talk about the RS-AS relationship into its own standalone document= . A >>> similar approach was taken in UMA2 and it was helpful. (Though admitted= ly, >>> as with anything, there are missteps there that we can hopefully learn >>> from.) >>> >>> =E2=80=94 Justin >>> >>> >>> -------------- >>> Alan Karp >>> >>> >>> On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper >>> wrote: >>> >>>> Sure! >>>> >>>> Is there an AS involved in the delegation? How and where in the >>>> lifecycle of the protected resource? >>>> >>>> Also your use of "the client" seems to imply that either there is only >>>> one client or the client doesn't matter. Which is it? >>>> >>>> Adrian >>>> >>>> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Thanks for that. >>>>> >>>>> Trying to reframe it: >>>>> GNAP is defined as a delegation protocol so the main intent is relate= d >>>>> to a delegate of the RO (i.e. the end user) that wishes to access the= RO's >>>>> protected resources, through the client. >>>>> >>>>> Fabien >>>>> >>>>> Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper >>>>> a =C3=A9crit : >>>>> >>>>>> At various points in the lifecycle of the protected resource the >>>>>> client at the resource server (RS) might be: >>>>>> >>>>>> - The RO (subject) user agent trading payment for a service >>>>>> promise >>>>>> - The RO user agent using the promise to access the protected >>>>>> resource >>>>>> - A delegate of the RO user agent using a different client >>>>>> >>>>>> What's vague is where the GNAP AS enters the picture as described >>>>>> above. How would you describe it? >>>>>> >>>>>> Adrian >>>>>> >>>>>> >>>>>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>>> Hi Adrian >>>>>>> >>>>>>> I'm still confused why you're saying the terminology is vague. >>>>>>> I get the "power" neutrality is not to your liking, but RQ / user >>>>>>> agent is no better in my view. >>>>>>> >>>>>>> Can you elaborate? >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper >>>>>>> a =C3=A9crit : >>>>>>> >>>>>>>> I'm sure you're right. Our vague terminology around >>>>>>>> client and end-user leads to my confusion. If GNAP is primarily ab= out >>>>>>>> delegation then, of course, we should avoid any incentives to impe= rsonate >>>>>>>> or we're wasting our time. This is partly why I'm trying to study = up on >>>>>>>> capabilities and asking for expert advice from folks like Alan Kar= p and >>>>>>>> Mark Miller (cc'd) >>>>>>>> >>>>>>>> As best I can understand it, the RS has only two choices, it can: >>>>>>>> >>>>>>>> - store an attribute of the RO a [DID, email address, GNAP AS >>>>>>>> URL], or >>>>>>>> - hand the RO a capability as a sort-of promise and avoid >>>>>>>> making any entries in an ACL or equivalent. >>>>>>>> >>>>>>>> When a token comes back to the RS, it will either be: >>>>>>>> >>>>>>>> - validated according to something associated with the stored >>>>>>>> RO attribute, or >>>>>>>> - signed by the RS itself. >>>>>>>> >>>>>>>> Either way, trust in the client seems moot. >>>>>>>> >>>>>>>> Adrian >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper < >>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker < >>>>>>>>> tobias.looker@mattr.global> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> > A client might not have a DID but it could have a VC as a >>>>>>>>>> certificate of authenticity linked to some audit mechanism. >>>>>>>>>> >>>>>>>>>> To me a VC would come under the assertions umbrella (that is to >>>>>>>>>> say a VC could be one type of valid assertion). The client may p= ossess or >>>>>>>>>> been presented with a VC that it could include in its request to= the AS as >>>>>>>>>> a way to identify the subject and perhaps prove authentication a= nd >>>>>>>>>> authorization. >>>>>>>>>> >>>>>>>>> >>>>>>>>> I do not assume that the client that interacts with the AS to mak= e >>>>>>>>> a request and receive a token is the same as the client that will= present >>>>>>>>> the token to the RS. In the US HIPAA use-case, for example, the r= oot of >>>>>>>>> trust is a contract between the patient-subject and the doctor-re= questing >>>>>>>>> party but the doctor workflow is expected to delegate the token t= o some >>>>>>>>> other end-user that may be using a totally different client such = as an EHR. >>>>>>>>> >>>>>>>>> >>>>>>>>> If the client that gets the token is not same as the client that >>>>>>>>> uses the token, that is a violation of core security principles a= s it >>>>>>>>> allows for (and really designs for) impersonation by client softw= are. I >>>>>>>>> would have no reason to trust client software that would hand its >>>>>>>>> credentials over to another piece of software, and in fact I shou= ldn=E2=80=99t >>>>>>>>> trust it. >>>>>>>>> >>>>>>>>> I think you may be conflating several different kinds of parties >>>>>>>>> under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2= =80=99s entirely possible that one >>>>>>>>> client might call an RS that in turn acts as a client for somethi= ng else >>>>>>>>> down stream. But each of those hops is different from the last. >>>>>>>>> >>>>>>>>> =E2=80=94 Justin >>>>>>>>> >>>>>>>>> >>> >> > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000fa9f2305bdd35a5e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I'm having some concerns with the way you're flipp= ing the trust here Denis. You seem to indicate that the user has trust in t= he RS and the Client and has to gain the trust of the AS. I feel like the l= east trustworthy portion of the architecture is the client, because that se= ems like it is the most interchangeable component.
    =C2=A0Let me explain= by way of a use case I have in mind.
    Let's say I have a smar= t home. I have devices and data storage and rule engines that are parts of = sensors and hubs I buy for the house. I have a trust in those devices, beca= use it's hardware, if the company is leaking data at the hardware level= there isn't much I can do other than buy different sensors.
    = In this case, the primary home hub, which is under control of the homeowner= , would also be the AS, as well as a policy agent.=C2=A0 Authentication in = the example is outsourced to whatever auth providers you want. I set up my = home using a google account, a friend is staying and wants access and uses = FB for auth... whatever.
    The part that I have little control over= is the client my friend uses on his phone. Or if I change the client on th= e tablet in the kitchen to try out something new. These pieces=C2=A0might b= e single page web apps, they might be downloaded apps, etc. I do not want t= hem having any additional information than is necessary. If I give my frien= d permission to unlock the door, and control the lights because they are fe= eding my cats while I'm away, the client doesn't need to know anyth= ing beyond, I see this home controller, and I have access to these lights a= nd that door lock.

    In your scenarios, the client i= s spy by design, and if it is a web app, I don't trust them to not grab= my user email address from the=C2=A0AS and put it on a mailing list it sel= ls to some sketchy company,=C2=A0when the only other component=C2=A0that ne= eds that information is the RS.

    -steve
    =
    On Thu= , Mar 18, 2021 at 1:21 PM Denis <d= enis.ietf@free.fr> wrote:
    =20 =20 =20
    I have changed the title of this thread, since the original topic has been closed.

    Justin, you are raising the following question:
    The question I have is =E2=80=94 why does the client need to know what=E2=80=99s in the token?
    Not if they could possibly know, but why would we expect a client to know and manage the contents of the token?
    The answer is quite simple: so that the end-user may have confidence into the architecture.
    The seventh of the eleven privacy principles from ISO 29100 (page 14) is:
    7. Openness, transparency and notice
    If the access token is considered as a black box for the end-user, it cannot be confident about the content of the access token.
    Such access token may disclose some private information without the consent of the end-user. If the access token that it has obtained
    does not match with what has been requested, the client will first not forward the access token to the RS and then will complain about the AS.

    Denis


    =20
    Hi Justin,=C2=A0

    "The access token is fundamentally a conversational artifact between the AS and the RS which the client is the carrier of."
    That's right,=C2=A0and a good=C2=A0opportunity to distingu= ish between the need for token=C2=A0inspection (i.e. a runtime verification, wherever that may be)
    and the need to negotiate the token format (a discovery). That last part could very well be an extension, as a way to open up the ecosystem
    beyond JWTs (which are fine, but come with their own limitations).=C2=A0

    Fabien

    On Thu, Mar 18, 2021 at 5:59 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 11:30 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 12:08 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    A= drian Gropper <agropper@healthurl.com> wrote:

    Is there an AS involved in the delegation? How and where in the lifecycle=C2=A0of the protected resource?=C2=A0

    If tokens are certificates, the AS need not be involved in subsequent delegations.=C2=A0 The AS must be involved if the tokens are opaque.=C2=A0

    Tokens are opaque to the client instance. They are not opaque to the AS. They might be opaque to the RS, but that depends on the kind of relationship the RS and AS have. GNAP should allow different options here as there are different use cases for that.

    Tokens are not opaque to the client in SPKI, zcap-ld, Orie's implementation with VCs= , or our Zebra Copy work.=C2=A0 Why must they be in GNAP?

    The existence of the AS is exactly the reason for this. The AS is the role that =E2=80=9Cknowledge about the = token contents=E2=80=9D has been outsourced to in the GNAP model (which is based on the OAuth model).

    It brings significant simplicity for the client developer. The question I have is =E2=80=94 why does the cl= ient need to know what=E2=80=99s in the token? Not if they could possibly know, but why would we expect a client to know and manage the contents of the token?=C2=A0

    The access token is fundamentally a conversational artifact between the AS and the RS which the client is the carrier of. The client is not the audience of the token, nor the creator of the token, nor even the manager of the token and the rights it represents. The client as a simple carrier is a powerful model that allows the security layer to get out of the way of the actual application logic that developers want to do.

    =C2=A0=E2=80=94 Justin


    --------------
    Alan Karp


    On Thu, Mar 18, 2021 at 4:56 AM Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 12:08 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    A= drian Gropper <agropper@healthurl.com> wrote:

    Is there an AS involved in the delegation? How and where in the lifecycle=C2=A0of the protected resource?=C2=A0

    If tokens are certificates, the AS need not be involved in subsequent delegations.=C2=A0 The AS must be involved if the tokens are opaque.=C2=A0

    Tokens are opaque to the client instance. They are not opaque to the AS. They might be opaque to the RS, but that depends on the kind of relationship the RS and AS have. GNAP should allow different options here as there are different use cases for that.

    It would probably be worthwhile to separate the portions of the spec that talk about the RS-AS relationship into its own standalone document. A similar approach was taken in UMA2 and it was helpful. (Though admittedly, as with anything, there are missteps there that we can hopefully learn from.)

    =C2=A0=E2=80=94 Justin


    --------------
    Alan Karp


    O= n Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Sure!=C2=A0

    Is there an AS involved in the delegation? How and where in the lifecycle=C2=A0of the protected resource?=C2=A0

    Also your use of "the client" seems to imply tha= t either there is only one client or the client doesn'= t matter. Which is it?

    Adrian

    On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks for that.=C2=A0

    Trying to reframe it:
    GNAP is defined as a delegation protocol so the main intent is related to a delegate of the RO (i.e. the end user) that wishes to access the RO's protected resources, through the client.=C2=A0

    Fabien=C2=A0

    Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    At various points in the lifecycle=C2=A0of t= he protected resource the client at the resource server (RS) might be:
    • The RO (subject) user agent trading payment for a service promise
    • The RO user agent using the promise to access the protected resource
    • A delegate of the RO user agent using a different client
    What's vague is where the GNAP AS enters the picture as described above. How would you describe it?

    Adrian


    On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault <f= abien.imbault@gmail.com> wrote:
    Hi Adrian
    <= br>
    I= 'm still confused why you're saying the terminology is vague.=C2=A0
    I get the "power" neutrality is not to your liking, but RQ / user agent is no better in my view.=C2=A0=
    <= br>
    C= an you elaborate?=C2=A0<= /div>
    <= br>
    F= abien=C2=A0

    Le jeu. 18 mars 2021 =C3=A0 00:18= , Adrian Gropper <agropper@= healthurl.com> a =C3=A9crit=C2= =A0:
    = I'm sure you're right. Our vague terminology=C2=A0= around client=C2=A0and=C2=A0end-user leads to my confusion. If GNAP is primarily a= bout delegation=C2=A0t= hen, of course, we should=C2=A0avoid any incentives to impersonate or we're wasting our time. This is partly why I'= m trying to study up on capabilities and asking for expert advice from folks like Alan Karp and Mark Miller (cc'd)

    As best I can understand it, the RS has only two choices, it can:
    • store an attribute of the RO a [DID, email address, GNAP AS URL], or
    • hand the RO a capability as a sort-of promise and avoid making any entries in an ACL or equivalent.
    When a token comes back to the RS, it will either be:
    • validated according to something associated with the stored RO attribute, or
    • signed by the RS itself.
    Either way, trust in the client seems moot.

    Adrian



    On Wed, Mar 17, 2021 at 5:29 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 17, 2021, at 4:55 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    = On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <tobias.looker@mattr.global> wrote:
    <snip>=
    > A client might not have a DID but it could have a VC as a certificate of authenticity linked to some audit mechanism.

    To me a VC would come under the assertions umbrella (that is to say a VC could be one type of valid assertion). The client may possess or been presented with a VC that it could include in its request to the AS as a way to identify the subject and perhaps prove authentication and authorization.

    I do not assume that the client that interacts with the AS to make a request and receive a token is the same as the client that will present the token to the RS. In the US HIPAA use-case, for example, the root of trust is a contract between the patient-subject and the doctor-requesting party but the doctor workflow is expected to delegate the token to some other end-user that may be using a totally different client such as an EHR.


    If the client that gets the token is not same as the client that uses the token, that is a violation of core security principles as it allows for (and really designs for) impersonation by client software. I would have no reason to trust client software that would hand its credentials over to another piece of software, and in fact I shouldn=E2=80=99t trust it.=C2=A0

    I think you may be conflating several different kinds of parties under the =E2=80=9Cclie= nt=E2=80=9D umbrella here, though. It=E2=80= =99s entirely possible that one client might call an RS that in turn acts as a client for something else down stream. But each of those hops is different from the last.

    =C2=A0=E2=80= =94 Justin





    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --000000000000fa9f2305bdd35a5e-- From nobody Thu Mar 18 11:08:54 2021 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 A637C3A30F0 for ; Thu, 18 Mar 2021 11:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.218 X-Spam-Level: X-Spam-Status: No, score=-4.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 2TTFkR9FyS0a for ; Thu, 18 Mar 2021 11:08:49 -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 309F43A30EF for ; Thu, 18 Mar 2021 11:08:48 -0700 (PDT) Received: from [192.168.1.22] (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 12II8jRG016272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Mar 2021 14:08:45 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_ABDC6179-5BC5-4929-A36C-3714D60E9A4E" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 18 Mar 2021 14:08:45 -0400 In-Reply-To: Cc: txauth gnap To: Steve Moore References: <43447446-4061-49F2-8486-5A196C3C75E2@mit.edu> <37a04505-84ef-aecf-6913-5aad8330c97c@free.fr> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Should access tokens be opaque or not for the clients ? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 18:08:54 -0000 --Apple-Mail=_ABDC6179-5BC5-4929-A36C-3714D60E9A4E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think Steve=E2=80=99s use case gives an interesting example of = something that I believe Adrian=E2=80=99s been talking about as well =E2=80= =94 delegating to another person. We traditionally think of delegation at the AS to mean =E2=80=9Ca = different user account logs in to the AS=E2=80=9D, and it=E2=80=99s = important to know that this does in fact work. But this could just as = easily be =E2=80=9CSteve sends his friend an artifact to present to the = AS to get access=E2=80=9D. This isn=E2=80=99t Steve (or Steve=E2=80=99s = client software) getting and sending an access token, this is sending = some other set of rights credential to his friend, or his friend=E2=80=99s= software. So then Steve=E2=80=99s AS can have policy that says =E2=80=9Cw= hen I see this rights credential, give an access token for the following = attenuated things, because Steve said so=E2=80=9D. The AS doesn=E2=80=99t = even ever need to know who Steve=E2=80=99s friend is!=20 And importantly here, we don=E2=80=99t expect Steve=E2=80=99s friend to = bring their own AS to the party. Steve=E2=80=99s RS has no reason to = trust his friend=E2=80=99s AS, let alone his friend=E2=80=99s client. = But Steve=E2=80=99s AS is in a position to know more about the rights = policies that Steve wants to apply, and so it can use other technologies = like VC=E2=80=99s, DIDs, OIDC, or any number of other things to let = things go through. This pattern is exactly why I think we need to think = of this in terms of what=E2=80=99s currently called =E2=80=9Cinteraction=E2= =80=9D at the AS. It=E2=80=99s not really just about how the end-user = interacts, it=E2=80=99s about how the AS gathers all the consent and = authorization information. I plan to rewrite section 4 to that effect. =E2=80=94 Justin > On Mar 18, 2021, at 1:58 PM, Stephen Moore wrote: >=20 > I'm having some concerns with the way you're flipping the trust here = Denis. You seem to indicate that the user has trust in the RS and the = Client and has to gain the trust of the AS. I feel like the least = trustworthy portion of the architecture is the client, because that = seems like it is the most interchangeable component. > Let me explain by way of a use case I have in mind. > Let's say I have a smart home. I have devices and data storage and = rule engines that are parts of sensors and hubs I buy for the house. I = have a trust in those devices, because it's hardware, if the company is = leaking data at the hardware level there isn't much I can do other than = buy different sensors. > In this case, the primary home hub, which is under control of the = homeowner, would also be the AS, as well as a policy agent. = Authentication in the example is outsourced to whatever auth providers = you want. I set up my home using a google account, a friend is staying = and wants access and uses FB for auth... whatever. > The part that I have little control over is the client my friend uses = on his phone. Or if I change the client on the tablet in the kitchen to = try out something new. These pieces might be single page web apps, they = might be downloaded apps, etc. I do not want them having any additional = information than is necessary. If I give my friend permission to unlock = the door, and control the lights because they are feeding my cats while = I'm away, the client doesn't need to know anything beyond, I see this = home controller, and I have access to these lights and that door lock. >=20 > In your scenarios, the client is spy by design, and if it is a web = app, I don't trust them to not grab my user email address from the AS = and put it on a mailing list it sells to some sketchy company, when the = only other component that needs that information is the RS. >=20 > -steve >=20 > On Thu, Mar 18, 2021 at 1:21 PM Denis > wrote: > I have changed the title of this thread, since the original topic has = been closed.=20 >=20 > Justin, you are raising the following question: > The question I have is =E2=80=94 why does the client need to know = what=E2=80=99s in the token?=20 > Not if they could possibly know, but why would we expect a client to = know and manage the contents of the token?=20 > The answer is quite simple: so that the end-user may have confidence = into the architecture.=20 > The seventh of the eleven privacy principles from ISO 29100 (page 14) = is: > 7. Openness, transparency and notice=20 > If the access token is considered as a black box for the end-user, it = cannot be confident about the content of the access token. > Such access token may disclose some private information without the = consent of the end-user. If the access token that it has obtained=20 > does not match with what has been requested, the client will first not = forward the access token to the RS and then will complain about the AS. >=20 > Denis >=20 >=20 >> Hi Justin,=20 >>=20 >> "The access token is fundamentally a conversational artifact between = the AS and the RS which the client is the carrier of." >> That's right, and a good opportunity to distinguish between the need = for token inspection (i.e. a runtime verification, wherever that may be)=20= >> and the need to negotiate the token format (a discovery). That last = part could very well be an extension, as a way to open up the ecosystem=20= >> beyond JWTs (which are fine, but come with their own limitations).=20 >>=20 >> Fabien >>=20 >> On Thu, Mar 18, 2021 at 5:59 PM Justin Richer > wrote: >> On Mar 18, 2021, at 11:30 AM, Alan Karp > wrote: >>>=20 >>> Justin Richer > wrote: >>> On Mar 18, 2021, at 12:08 AM, Alan Karp > wrote: >>>>=20 >>>> Adrian Gropper > wrote: >>>>=20 >>>> Is there an AS involved in the delegation? How and where in the = lifecycle of the protected resource?=20 >>>>=20 >>>> If tokens are certificates, the AS need not be involved in = subsequent delegations. The AS must be involved if the tokens are = opaque.=20 >>>=20 >>> Tokens are opaque to the client instance. They are not opaque to the = AS. They might be opaque to the RS, but that depends on the kind of = relationship the RS and AS have. GNAP should allow different options = here as there are different use cases for that. >>>=20 >>> Tokens are not opaque to the client in SPKI, zcap-ld, Orie's = implementation with VCs, or our Zebra Copy work. Why must they be in = GNAP? >>=20 >> The existence of the AS is exactly the reason for this. The AS is the = role that =E2=80=9Cknowledge about the token contents=E2=80=9D has been = outsourced to in the GNAP model (which is based on the OAuth model). >>=20 >> It brings significant simplicity for the client developer. The = question I have is =E2=80=94 why does the client need to know what=E2=80=99= s in the token? Not if they could possibly know, but why would we expect = a client to know and manage the contents of the token?=20 >>=20 >> The access token is fundamentally a conversational artifact between = the AS and the RS which the client is the carrier of. The client is not = the audience of the token, nor the creator of the token, nor even the = manager of the token and the rights it represents. The client as a = simple carrier is a powerful model that allows the security layer to get = out of the way of the actual application logic that developers want to = do. >>=20 >> =E2=80=94 Justin >>=20 >>>=20 >>> -------------- >>> Alan Karp >>>=20 >>>=20 >>> On Thu, Mar 18, 2021 at 4:56 AM Justin Richer > wrote: >>> On Mar 18, 2021, at 12:08 AM, Alan Karp > wrote: >>>>=20 >>>> Adrian Gropper > wrote: >>>>=20 >>>> Is there an AS involved in the delegation? How and where in the = lifecycle of the protected resource?=20 >>>>=20 >>>> If tokens are certificates, the AS need not be involved in = subsequent delegations. The AS must be involved if the tokens are = opaque.=20 >>>=20 >>> Tokens are opaque to the client instance. They are not opaque to the = AS. They might be opaque to the RS, but that depends on the kind of = relationship the RS and AS have. GNAP should allow different options = here as there are different use cases for that. >>>=20 >>> It would probably be worthwhile to separate the portions of the spec = that talk about the RS-AS relationship into its own standalone document. = A similar approach was taken in UMA2 and it was helpful. (Though = admittedly, as with anything, there are missteps there that we can = hopefully learn from.) >>>=20 >>> =E2=80=94 Justin >>>=20 >>>>=20 >>>> -------------- >>>> Alan Karp >>>>=20 >>>>=20 >>>> On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper = > wrote: >>>> Sure!=20 >>>>=20 >>>> Is there an AS involved in the delegation? How and where in the = lifecycle of the protected resource?=20 >>>>=20 >>>> Also your use of "the client" seems to imply that either there is = only one client or the client doesn't matter. Which is it? >>>>=20 >>>> Adrian >>>>=20 >>>> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault = > wrote: >>>> Thanks for that.=20 >>>>=20 >>>> Trying to reframe it: >>>> GNAP is defined as a delegation protocol so the main intent is = related to a delegate of the RO (i.e. the end user) that wishes to = access the RO's protected resources, through the client.=20 >>>>=20 >>>> Fabien=20 >>>>=20 >>>> Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper = > a =C3=A9crit : >>>> At various points in the lifecycle of the protected resource the = client at the resource server (RS) might be: >>>> The RO (subject) user agent trading payment for a service promise >>>> The RO user agent using the promise to access the protected = resource >>>> A delegate of the RO user agent using a different client >>>> What's vague is where the GNAP AS enters the picture as described = above. How would you describe it? >>>>=20 >>>> Adrian >>>>=20 >>>>=20 >>>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault = > wrote: >>>> Hi Adrian >>>>=20 >>>> I'm still confused why you're saying the terminology is vague.=20 >>>> I get the "power" neutrality is not to your liking, but RQ / user = agent is no better in my view.=20 >>>>=20 >>>> Can you elaborate?=20 >>>>=20 >>>> Fabien=20 >>>>=20 >>>> Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper = > a =C3=A9crit : >>>> I'm sure you're right. Our vague terminology around client and = end-user leads to my confusion. If GNAP is primarily about delegation = then, of course, we should avoid any incentives to impersonate or we're = wasting our time. This is partly why I'm trying to study up on = capabilities and asking for expert advice from folks like Alan Karp and = Mark Miller (cc'd) >>>>=20 >>>> As best I can understand it, the RS has only two choices, it can: >>>> store an attribute of the RO a [DID, email address, GNAP AS URL], = or >>>> hand the RO a capability as a sort-of promise and avoid making any = entries in an ACL or equivalent. >>>> When a token comes back to the RS, it will either be: >>>> validated according to something associated with the stored RO = attribute, or >>>> signed by the RS itself. >>>> Either way, trust in the client seems moot. >>>>=20 >>>> Adrian >>>>=20 >>>>=20 >>>>=20 >>>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer > wrote: >>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper > wrote: >>>>>=20 >>>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker = > wrote: >>>>> >>>>> > A client might not have a DID but it could have a VC as a = certificate of authenticity linked to some audit mechanism. >>>>>=20 >>>>> To me a VC would come under the assertions umbrella (that is to = say a VC could be one type of valid assertion). The client may possess = or been presented with a VC that it could include in its request to the = AS as a way to identify the subject and perhaps prove authentication and = authorization. >>>>>=20 >>>>> I do not assume that the client that interacts with the AS to make = a request and receive a token is the same as the client that will = present the token to the RS. In the US HIPAA use-case, for example, the = root of trust is a contract between the patient-subject and the = doctor-requesting party but the doctor workflow is expected to delegate = the token to some = other end-user that may be using a totally different client such as = an EHR. >>>>>=20 >>>>=20 >>>> If the client that gets the token is not same as the client that = uses the token, that is a violation of core security principles as it = allows for (and really designs for) impersonation by client software. I = would have no reason to trust client software that would hand its = credentials over to another piece of software, and in fact I shouldn=E2=80= =99t trust it.=20 >>>>=20 >>>> I think you may be conflating several different kinds of parties = under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80=99s = entirely possible that one client might call an RS that in turn acts as = a client for something else down stream. But each of those hops is = different from the last. >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>=20 >>=20 >>=20 >=20 > --=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=_ABDC6179-5BC5-4929-A36C-3714D60E9A4E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = think Steve=E2=80=99s use case gives an interesting example of something = that I believe Adrian=E2=80=99s been talking about as well =E2=80=94 = delegating to another person.

    We traditionally think of delegation at the AS to mean =E2=80=9C= a different user account logs in to the AS=E2=80=9D, and it=E2=80=99s = important to know that this does in fact work. But this could just as = easily be =E2=80=9CSteve sends his friend an artifact to present to the = AS to get access=E2=80=9D. This isn=E2=80=99t Steve (or Steve=E2=80=99s = client software) getting and sending an access token, this is sending = some other set of rights credential to his friend, or his friend=E2=80=99s= software. So then Steve=E2=80=99s AS can have policy that says =E2=80=9Cw= hen I see this rights credential, give an access token for the following = attenuated things, because Steve said so=E2=80=9D. The AS doesn=E2=80=99t = even ever need to know who Steve=E2=80=99s friend is! 

    And importantly here, we = don=E2=80=99t expect Steve=E2=80=99s friend to bring their own AS to the = party. Steve=E2=80=99s RS has no reason to trust his friend=E2=80=99s = AS, let alone his friend=E2=80=99s client. But Steve=E2=80=99s AS is in = a position to know more about the rights policies that Steve wants to = apply, and so it can use other technologies like VC=E2=80=99s, DIDs, = OIDC, or any number of other things to let things go through. This = pattern is exactly why I think we need to think of this in terms of = what=E2=80=99s currently called =E2=80=9Cinteraction=E2=80=9D at the AS. = It=E2=80=99s not really just about how the end-user interacts, it=E2=80=99= s about how the AS gathers all the consent and authorization = information. I plan to rewrite section 4 to that effect.

     =E2=80=94 = Justin

    On Mar 18, 2021, at 1:58 PM, Stephen Moore = <srmoore@gmail.com> wrote:

    I'm having some concerns with the = way you're flipping the trust here Denis. You seem to indicate that the = user has trust in the RS and the Client and has to gain the trust of the = AS. I feel like the least trustworthy portion of the architecture is the = client, because that seems like it is the most interchangeable = component.
     Let me explain by way of a use case I = have in mind.
    Let's say I have a smart home. I have = devices and data storage and rule engines that are parts of sensors and = hubs I buy for the house. I have a trust in those devices, because it's = hardware, if the company is leaking data at the hardware level there = isn't much I can do other than buy different sensors.
    In this case, the primary home hub, which is under control of = the homeowner, would also be the AS, as well as a policy agent.  = Authentication in the example is outsourced to whatever auth providers = you want. I set up my home using a google account, a friend is staying = and wants access and uses FB for auth... whatever.
    The part that I have little control over is the client my = friend uses on his phone. Or if I change the client on the tablet in the = kitchen to try out something new. These pieces might be single page = web apps, they might be downloaded apps, etc. I do not want them having = any additional information than is necessary. If I give my friend = permission to unlock the door, and control the lights because they are = feeding my cats while I'm away, the client doesn't need to know anything = beyond, I see this home controller, and I have access to these lights = and that door lock.

    In your scenarios, the client is spy by design, and if it is = a web app, I don't trust them to not grab my user email address from = the AS and put it on a mailing list it sells to some sketchy = company, when the only other component that needs that = information is the RS.

    -steve

    On Thu, Mar = 18, 2021 at 1:21 PM Denis <denis.ietf@free.fr> wrote:
    =20 =20 =20
    I have changed the title of this thread, since the original topic has been closed.

    Justin, you are raising the following question:
    The question I have is =E2=80=94 why does the client need to know what=E2=80=99s in the token?
    Not if they could possibly know, but why would we expect a client to know and manage the contents of the token?
    The answer is quite simple: so that the end-user may have confidence into the architecture.
    The seventh of the eleven privacy principles from ISO 29100 (page 14) is:
    7. Openness, transparency and notice
    If the access token is considered as a black box for the end-user, it cannot be confident about the content of the access token.
    Such access token may disclose some private information without the consent of the end-user. If the access token that it has obtained
    does not match with what has been requested, the client will first not forward the access token to the RS and then will complain about the AS.

    Denis


    =20
    Hi Justin, 

    "The access token is fundamentally a = conversational artifact between the AS and the RS which the client is the carrier of."
    That's right, and a good opportunity = to distinguish between the need for token inspection (i.e. a runtime = verification, wherever that may be)
    and the need to negotiate the token format (a discovery). That last part could very well be an extension, as a way to open up the ecosystem
    beyond JWTs (which are fine, but come with their own limitations). 

    Fabien

    On Thu, Mar 18, 2021 at = 5:59 PM Justin Richer <jricher@mit.edu> wrote:
    =
    On Mar 18, 2021, at 11:30 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Justin = Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 12:08 AM, = Alan Karp <alanhkarp@gmail.com> wrote:

    Adrian Gropper <agropper@healthurl.com> wrote:

    Is there an AS = involved in the delegation? How and where in the lifecycle of the protected = resource? 

    If tokens are = certificates, the AS need not be involved in subsequent delegations.  The = AS must be involved if the tokens are opaque. 

    Tokens are opaque to the = client instance. They are not opaque to the AS. They might be opaque to the RS, but that depends on the kind of relationship the RS and AS have. GNAP should allow different options here as there are different use cases for that.

    Tokens are not opaque to the = client in SPKI, zcap-ld, Orie's implementation with VCs, or our Zebra Copy work.  Why must they be = in GNAP?

    The existence of the AS is exactly the = reason for this. The AS is the role that =E2=80=9Cknowledge about = the token contents=E2=80=9D has been outsourced to in the GNAP = model (which is based on the OAuth model).

    It brings significant simplicity for the = client developer. The question I have is =E2=80=94 why does the = client need to know what=E2=80=99s in the token? Not if they = could possibly know, but why would we expect a client to know and manage the contents of the token? 

    The access token is fundamentally a = conversational artifact between the AS and the RS which the client is the carrier of. The client is not the audience of the token, nor the creator of the token, nor even the manager of the token and the rights it represents. The client as a simple carrier is a powerful model that allows the security layer to get out of the way of the actual application logic that developers want to = do.

     =E2=80=94 Justin


    --------------
    Alan Karp


    On Thu, Mar = 18, 2021 at 4:56 AM Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 12:08 AM, = Alan Karp <alanhkarp@gmail.com> wrote:

    Adrian Gropper <agropper@healthurl.com> wrote:

    Is there an AS = involved in the delegation? How and where in the lifecycle of the protected = resource? 

    If tokens are = certificates, the AS need not be involved in subsequent delegations.  The = AS must be involved if the tokens are opaque. 

    Tokens are opaque to the = client instance. They are not opaque to the AS. They might be opaque to the RS, but that depends on the kind of relationship the RS and AS have. GNAP should allow different options here as there are different use cases for that.

    It would probably be = worthwhile to separate the portions of the spec that talk about the RS-AS relationship into its own standalone document. A similar approach was taken in UMA2 and it was helpful. (Though admittedly, as with anything, there are missteps there that we can hopefully learn from.)

     =E2=80=94 Justin


    --------------
    Alan Karp


    On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Sure! 

    Is there an AS = involved in the delegation? How and where in the lifecycle of the protected resource? 

    Also your use = of "the client" seems to imply that either there is only one client or the client doesn't matter. Which is it?

    Adrian

    On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks for = that. 

    Trying to reframe it:
    GNAP is defined as a delegation protocol so the main intent is related to a delegate of the RO (i.e. the end user) that wishes to access the RO's protected resources, through the = client. 

    Fabien 

    Le jeu. 18 mars 2021 =C3=A0= 04:29, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit :
    At various points in the = lifecycle of the protected resource the client at the resource server (RS) might be:
    • The= RO (subject) user agent trading payment for a service promise
    • The= RO user agent using the promise to access the protected resource
    • A = delegate of the RO user agent using a different client
    What's vague is where the GNAP AS enters the picture as described above. How would you describe = it?

    Adrian


    On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Adrian

    I'm still confused why you're saying the terminology is = vague. 
    I get the "power" neutrality is not to your liking, but RQ / user agent is no better in my = view. 

    Can you = elaborate? 

    Fabien 

    Le jeu. 18 mars 2021 =C3=A0 = 00:18, Adrian Gropper <agropper@healthurl.com> a = =C3=A9crit :
    I'm sure you're right. Our vague = terminology around client and end-user leads to my confusion. If GNAP is = primarily about = delegation then, of course, we = should avoid any incentives to impersonate or we're wasting our time. This is partly why I'm trying to study up on capabilities and asking for expert advice from folks like Alan Karp and Mark Miller (cc'd)

    As best I can understand it, the RS has only two choices, it can:
    =
    • store an attribute of the RO a [DID, email address, GNAP AS URL], or
    • hand the RO a capability as a sort-of promise and avoid making any entries in an ACL or = equivalent.
    When a token comes back to the RS, it will either = be:
    =
    • validated according to something associated with the stored RO attribute, = or
    • signed by the RS = itself.
    Either way, trust in the client seems = moot.

    Adrian



    On Wed, Mar 17, 2021 at 5:29 PM Justin Richer = <jricher@mit.edu> wrote:
    =
    On Mar 17, 2021, at 4:55 PM, Adrian Gropper <agropper@healthurl.com> wrote:
    =

    =
    On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <tobias.looker@mattr.global> = wrote:
    <snip>
    > A client might not have a DID but it could have a VC as a certificate of authenticity linked to some audit = mechanism.

    To me a VC would come under the assertions umbrella (that is to say a VC could be one type of valid assertion). The client may possess or been presented with a VC that it could include in its request to the AS as a way to identify the subject and perhaps prove authentication and = authorization.

    I do not assume that the client that interacts with the AS to make a request and receive a token is the same as the client that will present the token to the RS. In the US HIPAA use-case, for example, the root of trust is a contract between the = patient-subject and the = doctor-requesting party but the doctor workflow is expected to delegate the token to some other end-user that may be using a totally different client such as an EHR.


    If the client that gets the token is not same as the client that uses the token, that is a violation of core security principles as it allows for (and really designs for) impersonation by client software. I would have no reason to trust client software that would hand its credentials over to another piece of software, and in fact I shouldn=E2=80=99= t trust = it. 

    I think you may be conflating several different kinds of parties under the = =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80= =99s entirely possible that one client might call an RS that in turn acts as a client for something else down stream. But each of those hops is different from the = last.

     =E2=80=94 Justin





    --
    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=_ABDC6179-5BC5-4929-A36C-3714D60E9A4E-- From nobody Thu Mar 18 11:26:55 2021 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 797733A3143 for ; Thu, 18 Mar 2021 11:26:51 -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 BtNuisQk0G2L for ; Thu, 18 Mar 2021 11:26:48 -0700 (PDT) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 44EF83A3140 for ; Thu, 18 Mar 2021 11:26:48 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id z1so7892456edb.8 for ; Thu, 18 Mar 2021 11:26:48 -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=L3ZbROBNSe3LacjCS5EW3/RDb4rjdDxQh9ZNdUjofBQ=; b=f26ChQduACNH/brAu5+fu14XSDslhwT9BZP5vQMwItq68WUajEsdngwmptSyF3+1Li BzJzxTektx+fSMuphFn7954rk/Nt81KHxvJG9QdAySrNwG3hjywvA007gd7EldNaXgdT xW3YSAe9+ibAcCjXAMpHmNZkgWN96ih7wK6HTCZFMJ+KW1saFVZvVMtY76mGPjtaMI4U PaQ+/vHrbCulNU34y0H5jp0E/3q/C9zY4flpzMUKLctEky4A3IqTodNvLGjJUrM37Fio CLIWy+McE7vS/LUoeSj266Y4hfv8Zn7Eo7nU/yvSwpUP6LtzzLfcHYUS7yUoTJxQwG3G zyJg== 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=L3ZbROBNSe3LacjCS5EW3/RDb4rjdDxQh9ZNdUjofBQ=; b=jvy2A+6xKVFASfHWJoh0M3regMx8j9nyuV8ARwTCZ6WzrDe6BvewAwm7VtYYPoTOBl ICTQM/Bt9tuXPx4CdNo5A4naDzBaZCxGiFId3hFrsk69MIhQUOvRrcT5wZjHGn9WXel6 6N5yRujfthywKGz8DDErhRS8nRBsWKAWfFPG+6gFv/8fyEZjeBA86ff36wQJ7KHcGRNx Tys7v00+WkUxlBBvgbBYAcn+dPWDu5Fvb4tXi7G07izQLEfPEOR1cs8Q+ITLcIjqURwV Z+vWTyI32K9KDPqAYR1boE85mw/HgOgBB5Amr4EYWddZfzydowHLOWlcfO92yW3II9ai PNLQ== X-Gm-Message-State: AOAM531++2g3ngheH8smNdDCP5hXhzcznvKh4X3AmTtBBUxQjrgyMeK1 PIL1zoyQFYcaI7tl+wI6HktNZjWJU9S/3m6Kx0Q= X-Google-Smtp-Source: ABdhPJz5MaOAuk3wc4bw9EFtlJnM7VcLlfsU9lnlIBGl8labuVt5sXMT051xUahHKgOn53Go/eH3i+GQiytnJZNhyP0= X-Received: by 2002:a05:6402:10c9:: with SMTP id p9mr5345056edu.268.1616092006447; Thu, 18 Mar 2021 11:26:46 -0700 (PDT) MIME-Version: 1.0 References: <43447446-4061-49F2-8486-5A196C3C75E2@mit.edu> <37a04505-84ef-aecf-6913-5aad8330c97c@free.fr> In-Reply-To: From: Stephen Moore Date: Thu, 18 Mar 2021 14:26:35 -0400 Message-ID: To: Justin Richer Cc: txauth gnap Content-Type: multipart/alternative; boundary="000000000000f8002005bdd3bdd8" Archived-At: Subject: Re: [GNAP] Should access tokens be opaque or not for the clients ? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 18:26:52 -0000 --000000000000f8002005bdd3bdd8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That in my mind works out great... Say I'm logged into my home hub/AS. Justin is over and agrees to cat sit, I pull up my client app, and generate a QR code that has maybe The AS URI, the HomeHub API URL, and the 'special token to present to AS for a real token'. Justin scans that QR code with his home controller app, and BAM, he's onboarded as a guest without even logging into my AS or me dealing with his Auth provider. -steve On Thu, Mar 18, 2021 at 2:08 PM Justin Richer wrote: > I think Steve=E2=80=99s use case gives an interesting example of somethin= g that I > believe Adrian=E2=80=99s been talking about as well =E2=80=94 delegating = to another person. > > We traditionally think of delegation at the AS to mean =E2=80=9Ca differe= nt user > account logs in to the AS=E2=80=9D, and it=E2=80=99s important to know th= at this does in > fact work. But this could just as easily be =E2=80=9CSteve sends his frie= nd an > artifact to present to the AS to get access=E2=80=9D. This isn=E2=80=99t = Steve (or Steve=E2=80=99s > client software) getting and sending an access token, this is sending som= e > other set of rights credential to his friend, or his friend=E2=80=99s sof= tware. So > then Steve=E2=80=99s AS can have policy that says =E2=80=9Cwhen I see thi= s rights > credential, give an access token for the following attenuated things, > because Steve said so=E2=80=9D. The AS doesn=E2=80=99t even ever need to = know who Steve=E2=80=99s > friend is! > > And importantly here, we don=E2=80=99t expect Steve=E2=80=99s friend to b= ring their own AS > to the party. Steve=E2=80=99s RS has no reason to trust his friend=E2=80= =99s AS, let alone > his friend=E2=80=99s client. But Steve=E2=80=99s AS is in a position to k= now more about the > rights policies that Steve wants to apply, and so it can use other > technologies like VC=E2=80=99s, DIDs, OIDC, or any number of other things= to let > things go through. This pattern is exactly why I think we need to think o= f > this in terms of what=E2=80=99s currently called =E2=80=9Cinteraction=E2= =80=9D at the AS. It=E2=80=99s not > really just about how the end-user interacts, it=E2=80=99s about how the = AS gathers > all the consent and authorization information. I plan to rewrite section = 4 > to that effect. > > =E2=80=94 Justin > > On Mar 18, 2021, at 1:58 PM, Stephen Moore wrote: > > I'm having some concerns with the way you're flipping the trust here > Denis. You seem to indicate that the user has trust in the RS and the > Client and has to gain the trust of the AS. I feel like the least > trustworthy portion of the architecture is the client, because that seems > like it is the most interchangeable component. > Let me explain by way of a use case I have in mind. > Let's say I have a smart home. I have devices and data storage and rule > engines that are parts of sensors and hubs I buy for the house. I have a > trust in those devices, because it's hardware, if the company is leaking > data at the hardware level there isn't much I can do other than buy > different sensors. > In this case, the primary home hub, which is under control of the > homeowner, would also be the AS, as well as a policy agent. Authenticati= on > in the example is outsourced to whatever auth providers you want. I set u= p > my home using a google account, a friend is staying and wants access and > uses FB for auth... whatever. > The part that I have little control over is the client my friend uses on > his phone. Or if I change the client on the tablet in the kitchen to try > out something new. These pieces might be single page web apps, they might > be downloaded apps, etc. I do not want them having any additional > information than is necessary. If I give my friend permission to unlock t= he > door, and control the lights because they are feeding my cats while I'm > away, the client doesn't need to know anything beyond, I see this home > controller, and I have access to these lights and that door lock. > > In your scenarios, the client is spy by design, and if it is a web app, I > don't trust them to not grab my user email address from the AS and put it > on a mailing list it sells to some sketchy company, when the only other > component that needs that information is the RS. > > -steve > > On Thu, Mar 18, 2021 at 1:21 PM Denis wrote: > >> I have changed the title of this thread, since the original topic has >> been closed. >> >> Justin, you are raising the following question: >> >> The question I have is =E2=80=94 why does the client need to know what= =E2=80=99s in the >> token? >> Not if they could possibly know, but why would we expect a client to kno= w >> and manage the contents of the token? >> >> The answer is quite simple: so that the end-user may have confidence int= o >> the architecture. >> The seventh of the eleven privacy principles from ISO 29100 (page 14) is= : >> >> *7. Openness, transparency and notice * >> >> If the access token is considered as a black box for the end-user, it >> cannot be confident about the content of the access token. >> Such access token may disclose some private information without the >> consent of the end-user. If the access token that it has obtained >> does not match with what has been requested, the client will first not >> forward the access token to the RS and then will complain about the AS. >> >> Denis >> >> >> Hi Justin, >> >> "The access token is fundamentally a conversational artifact between the >> AS and the RS which the client is the carrier of." >> That's right, and a good opportunity to distinguish between the need for >> token inspection (i.e. a runtime verification, wherever that may be) >> and the need to negotiate the token format (a discovery). That last part >> could very well be an extension, as a way to open up the ecosystem >> beyond JWTs (which are fine, but come with their own limitations). >> >> Fabien >> >> On Thu, Mar 18, 2021 at 5:59 PM Justin Richer wrote: >> >>> On Mar 18, 2021, at 11:30 AM, Alan Karp wrote: >>> >>> >>> Justin Richer wrote: >>> >>>> On Mar 18, 2021, at 12:08 AM, Alan Karp wrote: >>>> >>>> >>>> Adrian Gropper wrote: >>>> >>>>> >>>>> Is there an AS involved in the delegation? How and where in the >>>>> lifecycle of the protected resource? >>>>> >>>> >>>> If tokens are certificates, the AS need not be involved in subsequent >>>> delegations. The AS must be involved if the tokens are opaque. >>>> >>>> >>>> Tokens are opaque to the client instance. They are not opaque to the >>>> AS. They might be opaque to the RS, but that depends on the kind of >>>> relationship the RS and AS have. GNAP should allow different options h= ere >>>> as there are different use cases for that. >>>> >>> >>> Tokens are not opaque to the client in SPKI, zcap-ld, Orie's >>> implementation with VCs, or our Zebra Copy work. Why must they be in G= NAP? >>> >>> >>> The existence of the AS is exactly the reason for this. The AS is the >>> role that =E2=80=9Cknowledge about the token contents=E2=80=9D has been= outsourced to in >>> the GNAP model (which is based on the OAuth model). >>> >>> It brings significant simplicity for the client developer. The question >>> I have is =E2=80=94 why does the client need to know what=E2=80=99s in = the token? Not if >>> they could possibly know, but why would we expect a client to know and >>> manage the contents of the token? >>> >>> The access token is fundamentally a conversational artifact between the >>> AS and the RS which the client is the carrier of. The client is not the >>> audience of the token, nor the creator of the token, nor even the manag= er >>> of the token and the rights it represents. The client as a simple carri= er >>> is a powerful model that allows the security layer to get out of the wa= y of >>> the actual application logic that developers want to do. >>> >>> =E2=80=94 Justin >>> >>> >>> -------------- >>> Alan Karp >>> >>> >>> On Thu, Mar 18, 2021 at 4:56 AM Justin Richer wrote: >>> >>>> On Mar 18, 2021, at 12:08 AM, Alan Karp wrote: >>>> >>>> >>>> Adrian Gropper wrote: >>>> >>>>> >>>>> Is there an AS involved in the delegation? How and where in the >>>>> lifecycle of the protected resource? >>>>> >>>> >>>> If tokens are certificates, the AS need not be involved in subsequent >>>> delegations. The AS must be involved if the tokens are opaque. >>>> >>>> >>>> Tokens are opaque to the client instance. They are not opaque to the >>>> AS. They might be opaque to the RS, but that depends on the kind of >>>> relationship the RS and AS have. GNAP should allow different options h= ere >>>> as there are different use cases for that. >>>> >>>> It would probably be worthwhile to separate the portions of the spec >>>> that talk about the RS-AS relationship into its own standalone documen= t. A >>>> similar approach was taken in UMA2 and it was helpful. (Though admitte= dly, >>>> as with anything, there are missteps there that we can hopefully learn >>>> from.) >>>> >>>> =E2=80=94 Justin >>>> >>>> >>>> -------------- >>>> Alan Karp >>>> >>>> >>>> On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper >>>> wrote: >>>> >>>>> Sure! >>>>> >>>>> Is there an AS involved in the delegation? How and where in the >>>>> lifecycle of the protected resource? >>>>> >>>>> Also your use of "the client" seems to imply that either there is onl= y >>>>> one client or the client doesn't matter. Which is it? >>>>> >>>>> Adrian >>>>> >>>>> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Thanks for that. >>>>>> >>>>>> Trying to reframe it: >>>>>> GNAP is defined as a delegation protocol so the main intent is >>>>>> related to a delegate of the RO (i.e. the end user) that wishes to a= ccess >>>>>> the RO's protected resources, through the client. >>>>>> >>>>>> Fabien >>>>>> >>>>>> Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper >>>>>> a =C3=A9crit : >>>>>> >>>>>>> At various points in the lifecycle of the protected resource the >>>>>>> client at the resource server (RS) might be: >>>>>>> >>>>>>> - The RO (subject) user agent trading payment for a service >>>>>>> promise >>>>>>> - The RO user agent using the promise to access the protected >>>>>>> resource >>>>>>> - A delegate of the RO user agent using a different client >>>>>>> >>>>>>> What's vague is where the GNAP AS enters the picture as described >>>>>>> above. How would you describe it? >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>> >>>>>>>> Hi Adrian >>>>>>>> >>>>>>>> I'm still confused why you're saying the terminology is vague. >>>>>>>> I get the "power" neutrality is not to your liking, but RQ / user >>>>>>>> agent is no better in my view. >>>>>>>> >>>>>>>> Can you elaborate? >>>>>>>> >>>>>>>> Fabien >>>>>>>> >>>>>>>> Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper < >>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>> >>>>>>>>> I'm sure you're right. Our vague terminology around >>>>>>>>> client and end-user leads to my confusion. If GNAP is primarily a= bout >>>>>>>>> delegation then, of course, we should avoid any incentives to imp= ersonate >>>>>>>>> or we're wasting our time. This is partly why I'm trying to study= up on >>>>>>>>> capabilities and asking for expert advice from folks like Alan Ka= rp and >>>>>>>>> Mark Miller (cc'd) >>>>>>>>> >>>>>>>>> As best I can understand it, the RS has only two choices, it can: >>>>>>>>> >>>>>>>>> - store an attribute of the RO a [DID, email address, GNAP AS >>>>>>>>> URL], or >>>>>>>>> - hand the RO a capability as a sort-of promise and avoid >>>>>>>>> making any entries in an ACL or equivalent. >>>>>>>>> >>>>>>>>> When a token comes back to the RS, it will either be: >>>>>>>>> >>>>>>>>> - validated according to something associated with the stored >>>>>>>>> RO attribute, or >>>>>>>>> - signed by the RS itself. >>>>>>>>> >>>>>>>>> Either way, trust in the client seems moot. >>>>>>>>> >>>>>>>>> Adrian >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper < >>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker < >>>>>>>>>> tobias.looker@mattr.global> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> > A client might not have a DID but it could have a VC as a >>>>>>>>>>> certificate of authenticity linked to some audit mechanism. >>>>>>>>>>> >>>>>>>>>>> To me a VC would come under the assertions umbrella (that is to >>>>>>>>>>> say a VC could be one type of valid assertion). The client may = possess or >>>>>>>>>>> been presented with a VC that it could include in its request t= o the AS as >>>>>>>>>>> a way to identify the subject and perhaps prove authentication = and >>>>>>>>>>> authorization. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I do not assume that the client that interacts with the AS to >>>>>>>>>> make a request and receive a token is the same as the client tha= t will >>>>>>>>>> present the token to the RS. In the US HIPAA use-case, for examp= le, the >>>>>>>>>> root of trust is a contract between the patient-subject and the >>>>>>>>>> doctor-requesting party but the doctor workflow is expected to d= elegate the >>>>>>>>>> token to some other end-user that may be using a totally differe= nt client >>>>>>>>>> such as an EHR. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> If the client that gets the token is not same as the client that >>>>>>>>>> uses the token, that is a violation of core security principles = as it >>>>>>>>>> allows for (and really designs for) impersonation by client soft= ware. I >>>>>>>>>> would have no reason to trust client software that would hand it= s >>>>>>>>>> credentials over to another piece of software, and in fact I sho= uldn=E2=80=99t >>>>>>>>>> trust it. >>>>>>>>>> >>>>>>>>>> I think you may be conflating several different kinds of parties >>>>>>>>>> under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2= =80=99s entirely possible that one >>>>>>>>>> client might call an RS that in turn acts as a client for someth= ing else >>>>>>>>>> down stream. But each of those hops is different from the last. >>>>>>>>>> >>>>>>>>>> =E2=80=94 Justin >>>>>>>>>> >>>>>>>>>> >>>> >>> >> >> -- >> 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 > > > --000000000000f8002005bdd3bdd8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    That in my mind works out great... Say I'm logged into= my home hub/AS. Justin is over and agrees to cat sit, I pull up my client = app, and generate a QR code that has maybe The AS URI, the HomeHub API URL,= and the 'special token to present to AS for a real token'. Justin = scans that QR code with his home controller app, and BAM, he's onboarde= d as a guest without even logging into my AS or me dealing with his Auth pr= ovider.
    -steve

    On Thu, Mar 18, 2021 at 2:08 PM Justin Richer <<= a href=3D"mailto:jricher@mit.edu">jricher@mit.edu> 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">
    I think Steve=E2=80=99s use case gives an interesting examp= le of something that I believe Adrian=E2=80=99s been talking about as well = =E2=80=94 delegating to another person.

    We traditionally= think of delegation at the AS to mean =E2=80=9Ca different user account lo= gs in to the AS=E2=80=9D, and it=E2=80=99s important to know that this does= in fact work. But this could just as easily be =E2=80=9CSteve sends his fr= iend an artifact to present to the AS to get access=E2=80=9D. This isn=E2= =80=99t Steve (or Steve=E2=80=99s client software) getting and sending an a= ccess token, this is sending some other set of rights credential to his fri= end, or his friend=E2=80=99s software. So then Steve=E2=80=99s AS can have = policy that says =E2=80=9Cwhen I see this rights credential, give an access= token for the following attenuated things, because Steve said so=E2=80=9D.= The AS doesn=E2=80=99t even ever need to know who Steve=E2=80=99s friend i= s!=C2=A0

    And importantly here, we don=E2=80=99t ex= pect Steve=E2=80=99s friend to bring their own AS to the party. Steve=E2=80= =99s RS has no reason to trust his friend=E2=80=99s AS, let alone his frien= d=E2=80=99s client. But Steve=E2=80=99s AS is in a position to know more ab= out the rights policies that Steve wants to apply, and so it can use other = technologies like VC=E2=80=99s, DIDs, OIDC, or any number of other things t= o let things go through. This pattern is exactly why I think we need to thi= nk of this in terms of what=E2=80=99s currently called =E2=80=9Cinteraction= =E2=80=9D at the AS. It=E2=80=99s not really just about how the end-user in= teracts, it=E2=80=99s about how the AS gathers all the consent and authoriz= ation information. I plan to rewrite section 4 to that effect.
    =C2=A0=E2=80=94 Justin

    <= div>On Mar 18, 2021, at 1:58 PM, Stephen Moore <srmoore@gmail.com> wrote:

    I'm having some concerns with the way you're fl= ipping the trust here Denis. You seem to indicate that the user has trust i= n the RS and the Client and has to gain the trust of the AS. I feel like th= e least trustworthy portion of the architecture is the client, because that= seems like it is the most interchangeable component.
    =C2=A0Let me expl= ain by way of a use case I have in mind.
    Let's say I have a s= mart home. I have devices and data storage and rule engines that are parts = of sensors and hubs I buy for the house. I have a trust in those devices, b= ecause it's hardware, if the company is leaking data at the hardware le= vel there isn't much I can do other than buy different sensors.
    In this case, the primary home hub, which is under control of the homeow= ner, would also be the AS, as well as a policy agent.=C2=A0 Authentication = in the example is outsourced to whatever auth providers you want. I set up = my home using a google account, a friend is staying and wants access and us= es FB for auth... whatever.
    The part that I have little control o= ver is the client my friend uses on his phone. Or if I change the client on= the tablet in the kitchen to try out something new. These pieces=C2=A0migh= t be single page web apps, they might be downloaded apps, etc. I do not wan= t them having any additional information than is necessary. If I give my fr= iend permission to unlock the door, and control the lights because they are= feeding my cats while I'm away, the client doesn't need to know an= ything beyond, I see this home controller, and I have access to these light= s and that door lock.

    In your scenarios, the clien= t is spy by design, and if it is a web app, I don't trust them to not g= rab my user email address from the=C2=A0AS and put it on a mailing list it = sells to some sketchy company,=C2=A0when the only other component=C2=A0that= needs that information is the RS.

    -steve

    On = Thu, Mar 18, 2021 at 1:21 PM Denis <denis.ietf@free.fr> wrote:
    =20 =20 =20
    I have changed the title of this thread, since the original topic has been closed.

    Justin, you are raising the following question:
    The question I have is =E2=80=94 why does the client need to know what=E2=80=99s in the token?
    Not if they could possibly know, but why would we expect a client to know and manage the contents of the token?
    The answer is quite simple: so that the end-user may have confidence into the architecture.
    The seventh of the eleven privacy principles from ISO 29100 (page 14) is:
    7. Openness, transparency and notice
    If the access token is considered as a black box for the end-user, it cannot be confident about the content of the access token.
    Such access token may disclose some private information without the consent of the end-user. If the access token that it has obtained
    does not match with what has been requested, the client will first not forward the access token to the RS and then will complain about the AS.

    Denis


    =20
    Hi Justin,=C2=A0

    "The access token is fundamentally a conversational artifact between the AS and the RS which the client is the carrier of."
    That's right,=C2=A0and a good=C2=A0opportunity to distingu= ish between the need for token=C2=A0inspection (i.e. a runtime verification, wherever that may be)
    and the need to negotiate the token format (a discovery). That last part could very well be an extension, as a way to open up the ecosystem
    beyond JWTs (which are fine, but come with their own limitations).=C2=A0

    Fabien

    On Thu, Mar 18, 2021 at 5:59 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 11:30 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 12:08 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    A= drian Gropper <agropper@healthurl.com> wrote:

    Is there an AS involved in the delegation? How and where in the lifecycle=C2=A0of the protected resource?=C2=A0

    If tokens are certificates, the AS need not be involved in subsequent delegations.=C2=A0 The AS must be involved if the tokens are opaque.=C2=A0

    Tokens are opaque to the client instance. They are not opaque to the AS. They might be opaque to the RS, but that depends on the kind of relationship the RS and AS have. GNAP should allow different options here as there are different use cases for that.

    Tokens are not opaque to the client in SPKI, zcap-ld, Orie's implementation with VCs= , or our Zebra Copy work.=C2=A0 Why must they be in GNAP?

    The existence of the AS is exactly the reason for this. The AS is the role that =E2=80=9Cknowledge about the = token contents=E2=80=9D has been outsourced to in the GNAP model (which is based on the OAuth model).

    It brings significant simplicity for the client developer. The question I have is =E2=80=94 why does the cl= ient need to know what=E2=80=99s in the token? Not if they could possibly know, but why would we expect a client to know and manage the contents of the token?=C2=A0

    The access token is fundamentally a conversational artifact between the AS and the RS which the client is the carrier of. The client is not the audience of the token, nor the creator of the token, nor even the manager of the token and the rights it represents. The client as a simple carrier is a powerful model that allows the security layer to get out of the way of the actual application logic that developers want to do.

    =C2=A0=E2=80=94 Justin


    --------------
    Alan Karp


    On Thu, Mar 18, 2021 at 4:56 AM Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 12:08 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    A= drian Gropper <agropper@healthurl.com> wrote:

    Is there an AS involved in the delegation? How and where in the lifecycle=C2=A0of the protected resource?=C2=A0

    If tokens are certificates, the AS need not be involved in subsequent delegations.=C2=A0 The AS must be involved if the tokens are opaque.=C2=A0

    Tokens are opaque to the client instance. They are not opaque to the AS. They might be opaque to the RS, but that depends on the kind of relationship the RS and AS have. GNAP should allow different options here as there are different use cases for that.

    It would probably be worthwhile to separate the portions of the spec that talk about the RS-AS relationship into its own standalone document. A similar approach was taken in UMA2 and it was helpful. (Though admittedly, as with anything, there are missteps there that we can hopefully learn from.)

    =C2=A0=E2=80=94 Justin


    --------------
    Alan Karp


    O= n Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Sure!=C2=A0

    Is there an AS involved in the delegation? How and where in the lifecycle=C2=A0of the protected resource?=C2=A0

    Also your use of "the client" seems to imply tha= t either there is only one client or the client doesn'= t matter. Which is it?

    Adrian

    On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks for that.=C2=A0

    Trying to reframe it:
    GNAP is defined as a delegation protocol so the main intent is related to a delegate of the RO (i.e. the end user) that wishes to access the RO's protected resources, through the client.=C2=A0

    Fabien=C2=A0

    Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    At various points in the lifecycle=C2=A0of t= he protected resource the client at the resource server (RS) might be:
    • The RO (subject) user agent trading payment for a service promise
    • The RO user agent using the promise to access the protected resource
    • A delegate of the RO user agent using a different client
    What's vague is where the GNAP AS enters the picture as described above. How would you describe it?

    Adrian


    On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault <f= abien.imbault@gmail.com> wrote:
    Hi Adrian
    <= br>
    I= 'm still confused why you're saying the terminology is vague.=C2=A0
    I get the "power" neutrality is not to your liking, but RQ / user agent is no better in my view.=C2=A0=
    <= br>
    C= an you elaborate?=C2=A0<= /div>
    <= br>
    F= abien=C2=A0

    Le jeu. 18 mars 2021 =C3=A0 00:18= , Adrian Gropper <agropper@= healthurl.com> a =C3=A9crit=C2= =A0:
    = I'm sure you're right. Our vague terminology=C2=A0= around client=C2=A0and=C2=A0end-user leads to my confusion. If GNAP is primarily a= bout delegation=C2=A0t= hen, of course, we should=C2=A0avoid any incentives to impersonate or we're wasting our time. This is partly why I'= m trying to study up on capabilities and asking for expert advice from folks like Alan Karp and Mark Miller (cc'd)

    As best I can understand it, the RS has only two choices, it can:
    • store an attribute of the RO a [DID, email address, GNAP AS URL], or
    • hand the RO a capability as a sort-of promise and avoid making any entries in an ACL or equivalent.
    When a token comes back to the RS, it will either be:
    • validated according to something associated with the stored RO attribute, or
    • signed by the RS itself.
    Either way, trust in the client seems moot.

    Adrian



    On Wed, Mar 17, 2021 at 5:29 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 17, 2021, at 4:55 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    = On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <tobias.looker@mattr.global> wrote:
    <snip>=
    > A client might not have a DID but it could have a VC as a certificate of authenticity linked to some audit mechanism.

    To me a VC would come under the assertions umbrella (that is to say a VC could be one type of valid assertion). The client may possess or been presented with a VC that it could include in its request to the AS as a way to identify the subject and perhaps prove authentication and authorization.

    I do not assume that the client that interacts with the AS to make a request and receive a token is the same as the client that will present the token to the RS. In the US HIPAA use-case, for example, the root of trust is a contract between the patient-subject and the doctor-requesting party but the doctor workflow is expected to delegate the token to some other end-user that may be using a totally different client such as an EHR.


    If the client that gets the token is not same as the client that uses the token, that is a violation of core security principles as it allows for (and really designs for) impersonation by client software. I would have no reason to trust client software that would hand its credentials over to another piece of software, and in fact I shouldn=E2=80=99t trust it.=C2=A0

    I think you may be conflating several different kinds of parties under the =E2=80=9Cclie= nt=E2=80=9D umbrella here, though. It=E2=80= =99s entirely possible that one client might call an RS that in turn acts as a client for something else down stream. But each of those hops is different from the last.

    =C2=A0=E2=80= =94 Justin





    --
    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=

    --000000000000f8002005bdd3bdd8-- From nobody Thu Mar 18 11:39:29 2021 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 96A383A3184 for ; Thu, 18 Mar 2021 11:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 FdVfOZhBPF7L for ; Thu, 18 Mar 2021 11:39: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 8A8AA3A317C for ; Thu, 18 Mar 2021 11:39:23 -0700 (PDT) Received: from [192.168.1.22] (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 12IIdKQi027666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Mar 2021 14:39:20 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D313662A-F580-47BF-896D-2D213B8BBEEA" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 18 Mar 2021 14:39:20 -0400 In-Reply-To: Cc: txauth gnap To: Steve Moore References: <43447446-4061-49F2-8486-5A196C3C75E2@mit.edu> <37a04505-84ef-aecf-6913-5aad8330c97c@free.fr> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Should access tokens be opaque or not for the clients ? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 18:39:28 -0000 --Apple-Mail=_D313662A-F580-47BF-896D-2D213B8BBEEA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Right, and in the GNAP model this becomes something my client instance = presents to the AS when I show up. The AS can validate my presentation = of this item and give my client instance a token to call Steve=E2=80=99s = RS. Or if you wanted to get super fancy Steve=E2=80=99s AS could even = challenge my client instance and get a cryptographic response to prove I = have the thing Steve had me scan. But in both cases it=E2=80=99s part of = things that the AS collects in order to create the access token. =E2=80=94 Justin > On Mar 18, 2021, at 2:26 PM, Stephen Moore wrote: >=20 > That in my mind works out great... Say I'm logged into my home hub/AS. = Justin is over and agrees to cat sit, I pull up my client app, and = generate a QR code that has maybe The AS URI, the HomeHub API URL, and = the 'special token to present to AS for a real token'. Justin scans that = QR code with his home controller app, and BAM, he's onboarded as a guest = without even logging into my AS or me dealing with his Auth provider. > -steve >=20 > On Thu, Mar 18, 2021 at 2:08 PM Justin Richer > wrote: > I think Steve=E2=80=99s use case gives an interesting example of = something that I believe Adrian=E2=80=99s been talking about as well =E2=80= =94 delegating to another person. >=20 > We traditionally think of delegation at the AS to mean =E2=80=9Ca = different user account logs in to the AS=E2=80=9D, and it=E2=80=99s = important to know that this does in fact work. But this could just as = easily be =E2=80=9CSteve sends his friend an artifact to present to the = AS to get access=E2=80=9D. This isn=E2=80=99t Steve (or Steve=E2=80=99s = client software) getting and sending an access token, this is sending = some other set of rights credential to his friend, or his friend=E2=80=99s= software. So then Steve=E2=80=99s AS can have policy that says =E2=80=9Cw= hen I see this rights credential, give an access token for the following = attenuated things, because Steve said so=E2=80=9D. The AS doesn=E2=80=99t = even ever need to know who Steve=E2=80=99s friend is!=20 >=20 > And importantly here, we don=E2=80=99t expect Steve=E2=80=99s friend = to bring their own AS to the party. Steve=E2=80=99s RS has no reason to = trust his friend=E2=80=99s AS, let alone his friend=E2=80=99s client. = But Steve=E2=80=99s AS is in a position to know more about the rights = policies that Steve wants to apply, and so it can use other technologies = like VC=E2=80=99s, DIDs, OIDC, or any number of other things to let = things go through. This pattern is exactly why I think we need to think = of this in terms of what=E2=80=99s currently called =E2=80=9Cinteraction=E2= =80=9D at the AS. It=E2=80=99s not really just about how the end-user = interacts, it=E2=80=99s about how the AS gathers all the consent and = authorization information. I plan to rewrite section 4 to that effect. >=20 > =E2=80=94 Justin >=20 >> On Mar 18, 2021, at 1:58 PM, Stephen Moore > wrote: >>=20 >> I'm having some concerns with the way you're flipping the trust here = Denis. You seem to indicate that the user has trust in the RS and the = Client and has to gain the trust of the AS. I feel like the least = trustworthy portion of the architecture is the client, because that = seems like it is the most interchangeable component. >> Let me explain by way of a use case I have in mind. >> Let's say I have a smart home. I have devices and data storage and = rule engines that are parts of sensors and hubs I buy for the house. I = have a trust in those devices, because it's hardware, if the company is = leaking data at the hardware level there isn't much I can do other than = buy different sensors. >> In this case, the primary home hub, which is under control of the = homeowner, would also be the AS, as well as a policy agent. = Authentication in the example is outsourced to whatever auth providers = you want. I set up my home using a google account, a friend is staying = and wants access and uses FB for auth... whatever. >> The part that I have little control over is the client my friend uses = on his phone. Or if I change the client on the tablet in the kitchen to = try out something new. These pieces might be single page web apps, they = might be downloaded apps, etc. I do not want them having any additional = information than is necessary. If I give my friend permission to unlock = the door, and control the lights because they are feeding my cats while = I'm away, the client doesn't need to know anything beyond, I see this = home controller, and I have access to these lights and that door lock. >>=20 >> In your scenarios, the client is spy by design, and if it is a web = app, I don't trust them to not grab my user email address from the AS = and put it on a mailing list it sells to some sketchy company, when the = only other component that needs that information is the RS. >>=20 >> -steve >>=20 >> On Thu, Mar 18, 2021 at 1:21 PM Denis > wrote: >> I have changed the title of this thread, since the original topic has = been closed.=20 >>=20 >> Justin, you are raising the following question: >> The question I have is =E2=80=94 why does the client need to know = what=E2=80=99s in the token?=20 >> Not if they could possibly know, but why would we expect a client to = know and manage the contents of the token?=20 >> The answer is quite simple: so that the end-user may have confidence = into the architecture.=20 >> The seventh of the eleven privacy principles from ISO 29100 (page 14) = is: >> 7. Openness, transparency and notice=20 >> If the access token is considered as a black box for the end-user, it = cannot be confident about the content of the access token. >> Such access token may disclose some private information without the = consent of the end-user. If the access token that it has obtained=20 >> does not match with what has been requested, the client will first = not forward the access token to the RS and then will complain about the = AS. >>=20 >> Denis >>=20 >>=20 >>> Hi Justin,=20 >>>=20 >>> "The access token is fundamentally a conversational artifact between = the AS and the RS which the client is the carrier of." >>> That's right, and a good opportunity to distinguish between the need = for token inspection (i.e. a runtime verification, wherever that may be)=20= >>> and the need to negotiate the token format (a discovery). That last = part could very well be an extension, as a way to open up the ecosystem=20= >>> beyond JWTs (which are fine, but come with their own limitations).=20= >>>=20 >>> Fabien >>>=20 >>> On Thu, Mar 18, 2021 at 5:59 PM Justin Richer > wrote: >>> On Mar 18, 2021, at 11:30 AM, Alan Karp > wrote: >>>>=20 >>>> Justin Richer > wrote: >>>> On Mar 18, 2021, at 12:08 AM, Alan Karp > wrote: >>>>>=20 >>>>> Adrian Gropper > wrote: >>>>>=20 >>>>> Is there an AS involved in the delegation? How and where in the = lifecycle of the protected resource?=20 >>>>>=20 >>>>> If tokens are certificates, the AS need not be involved in = subsequent delegations. The AS must be involved if the tokens are = opaque.=20 >>>>=20 >>>> Tokens are opaque to the client instance. They are not opaque to = the AS. They might be opaque to the RS, but that depends on the kind of = relationship the RS and AS have. GNAP should allow different options = here as there are different use cases for that. >>>>=20 >>>> Tokens are not opaque to the client in SPKI, zcap-ld, Orie's = implementation with VCs, or our Zebra Copy work. Why must they be in = GNAP? >>>=20 >>> The existence of the AS is exactly the reason for this. The AS is = the role that =E2=80=9Cknowledge about the token contents=E2=80=9D has = been outsourced to in the GNAP model (which is based on the OAuth = model). >>>=20 >>> It brings significant simplicity for the client developer. The = question I have is =E2=80=94 why does the client need to know what=E2=80=99= s in the token? Not if they could possibly know, but why would we expect = a client to know and manage the contents of the token?=20 >>>=20 >>> The access token is fundamentally a conversational artifact between = the AS and the RS which the client is the carrier of. The client is not = the audience of the token, nor the creator of the token, nor even the = manager of the token and the rights it represents. The client as a = simple carrier is a powerful model that allows the security layer to get = out of the way of the actual application logic that developers want to = do. >>>=20 >>> =E2=80=94 Justin >>>=20 >>>>=20 >>>> -------------- >>>> Alan Karp >>>>=20 >>>>=20 >>>> On Thu, Mar 18, 2021 at 4:56 AM Justin Richer > wrote: >>>> On Mar 18, 2021, at 12:08 AM, Alan Karp > wrote: >>>>>=20 >>>>> Adrian Gropper > wrote: >>>>>=20 >>>>> Is there an AS involved in the delegation? How and where in the = lifecycle of the protected resource?=20 >>>>>=20 >>>>> If tokens are certificates, the AS need not be involved in = subsequent delegations. The AS must be involved if the tokens are = opaque.=20 >>>>=20 >>>> Tokens are opaque to the client instance. They are not opaque to = the AS. They might be opaque to the RS, but that depends on the kind of = relationship the RS and AS have. GNAP should allow different options = here as there are different use cases for that. >>>>=20 >>>> It would probably be worthwhile to separate the portions of the = spec that talk about the RS-AS relationship into its own standalone = document. A similar approach was taken in UMA2 and it was helpful. = (Though admittedly, as with anything, there are missteps there that we = can hopefully learn from.) >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>>=20 >>>>> -------------- >>>>> Alan Karp >>>>>=20 >>>>>=20 >>>>> On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper = > wrote: >>>>> Sure!=20 >>>>>=20 >>>>> Is there an AS involved in the delegation? How and where in the = lifecycle of the protected resource?=20 >>>>>=20 >>>>> Also your use of "the client" seems to imply that either there is = only one client or the client doesn't matter. Which is it? >>>>>=20 >>>>> Adrian >>>>>=20 >>>>> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault = > wrote: >>>>> Thanks for that.=20 >>>>>=20 >>>>> Trying to reframe it: >>>>> GNAP is defined as a delegation protocol so the main intent is = related to a delegate of the RO (i.e. the end user) that wishes to = access the RO's protected resources, through the client.=20 >>>>>=20 >>>>> Fabien=20 >>>>>=20 >>>>> Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper = > a =C3=A9crit : >>>>> At various points in the lifecycle of the protected resource the = client at the resource server (RS) might be: >>>>> The RO (subject) user agent trading payment for a service promise >>>>> The RO user agent using the promise to access the protected = resource >>>>> A delegate of the RO user agent using a different client >>>>> What's vague is where the GNAP AS enters the picture as described = above. How would you describe it? >>>>>=20 >>>>> Adrian >>>>>=20 >>>>>=20 >>>>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault = > wrote: >>>>> Hi Adrian >>>>>=20 >>>>> I'm still confused why you're saying the terminology is vague.=20 >>>>> I get the "power" neutrality is not to your liking, but RQ / user = agent is no better in my view.=20 >>>>>=20 >>>>> Can you elaborate?=20 >>>>>=20 >>>>> Fabien=20 >>>>>=20 >>>>> Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper = > a =C3=A9crit : >>>>> I'm sure you're right. Our vague terminology around client and = end-user leads to my confusion. If GNAP is primarily about delegation = then, of course, we should avoid any incentives to impersonate or we're = wasting our time. This is partly why I'm trying to study up on = capabilities and asking for expert advice from folks like Alan Karp and = Mark Miller (cc'd) >>>>>=20 >>>>> As best I can understand it, the RS has only two choices, it can: >>>>> store an attribute of the RO a [DID, email address, GNAP AS URL], = or >>>>> hand the RO a capability as a sort-of promise and avoid making any = entries in an ACL or equivalent. >>>>> When a token comes back to the RS, it will either be: >>>>> validated according to something associated with the stored RO = attribute, or >>>>> signed by the RS itself. >>>>> Either way, trust in the client seems moot. >>>>>=20 >>>>> Adrian >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer > wrote: >>>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper = > wrote: >>>>>>=20 >>>>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker = > wrote: >>>>>> >>>>>> > A client might not have a DID but it could have a VC as a = certificate of authenticity linked to some audit mechanism. >>>>>>=20 >>>>>> To me a VC would come under the assertions umbrella (that is to = say a VC could be one type of valid assertion). The client may possess = or been presented with a VC that it could include in its request to the = AS as a way to identify the subject and perhaps prove authentication and = authorization. >>>>>>=20 >>>>>> I do not assume that the client that interacts with the AS to = make a request and receive a token is the same as the client that will = present the token to the RS. In the US HIPAA = use-case, for example, the root of trust = is a contract between the patient-subject and the doctor-requesting = party but the doctor workflow is expected to delegate the token to some = other end-user that may be using a totally different client such as an = EHR. >>>>>>=20 >>>>>=20 >>>>> If the client that gets the token is not same as the client that = uses the token, that is a violation of core security principles as it = allows for (and really designs for) impersonation by client software. I = would have no reason to trust client software that would hand its = credentials over to another piece of software, and in fact I shouldn=E2=80= =99t trust it.=20 >>>>>=20 >>>>> I think you may be conflating several different kinds of parties = under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80=99s = entirely possible that one client might call an RS that in turn acts as = a client for something else down stream. But each of those hops is = different from the last. >>>>>=20 >>>>> =E2=80=94 Justin >>>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >> --=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 = >=20 --Apple-Mail=_D313662A-F580-47BF-896D-2D213B8BBEEA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Right, and in the GNAP model this becomes something my client = instance presents to the AS when I show up. The AS can validate my = presentation of this item and give my client instance a token to call = Steve=E2=80=99s RS. Or if you wanted to get super fancy Steve=E2=80=99s = AS could even challenge my client instance and get a cryptographic = response to prove I have the thing Steve had me scan. But in both cases = it=E2=80=99s part of things that the AS collects in order to create the = access token.

     =E2=80=94 Justin

    On Mar = 18, 2021, at 2:26 PM, Stephen Moore <srmoore@gmail.com> = wrote:

    That in my mind works out = great... Say I'm logged into my home hub/AS. Justin is over and agrees = to cat sit, I pull up my client app, and generate a QR code that has = maybe The AS URI, the HomeHub API URL, and the 'special token to present = to AS for a real token'. Justin scans that QR code with his home = controller app, and BAM, he's onboarded as a guest without even logging = into my AS or me dealing with his Auth provider.
    -steve

    On Thu, Mar = 18, 2021 at 2:08 PM Justin Richer <jricher@mit.edu> wrote:
    I think Steve=E2=80=99s use case gives an = interesting example of something that I believe Adrian=E2=80=99s been = talking about as well =E2=80=94 delegating to another person.

    We traditionally think = of delegation at the AS to mean =E2=80=9Ca different user account logs = in to the AS=E2=80=9D, and it=E2=80=99s important to know that this does = in fact work. But this could just as easily be =E2=80=9CSteve sends his = friend an artifact to present to the AS to get access=E2=80=9D. This = isn=E2=80=99t Steve (or Steve=E2=80=99s client software) getting and = sending an access token, this is sending some other set of rights = credential to his friend, or his friend=E2=80=99s software. So then = Steve=E2=80=99s AS can have policy that says =E2=80=9Cwhen I see this = rights credential, give an access token for the following attenuated = things, because Steve said so=E2=80=9D. The AS doesn=E2=80=99t even ever = need to know who Steve=E2=80=99s friend is! 
    And importantly here, we don=E2=80=99t = expect Steve=E2=80=99s friend to bring their own AS to the party. = Steve=E2=80=99s RS has no reason to trust his friend=E2=80=99s AS, let = alone his friend=E2=80=99s client. But Steve=E2=80=99s AS is in a = position to know more about the rights policies that Steve wants to = apply, and so it can use other technologies like VC=E2=80=99s, DIDs, = OIDC, or any number of other things to let things go through. This = pattern is exactly why I think we need to think of this in terms of = what=E2=80=99s currently called =E2=80=9Cinteraction=E2=80=9D at the AS. = It=E2=80=99s not really just about how the end-user interacts, it=E2=80=99= s about how the AS gathers all the consent and authorization = information. I plan to rewrite section 4 to that effect.

     =E2=80=94 = Justin

    On Mar 18, 2021, at 1:58 PM, = Stephen Moore <srmoore@gmail.com> wrote:

    I'm having some concerns with the = way you're flipping the trust here Denis. You seem to indicate that the = user has trust in the RS and the Client and has to gain the trust of the = AS. I feel like the least trustworthy portion of the architecture is the = client, because that seems like it is the most interchangeable = component.
     Let me explain by way of a use case I = have in mind.
    Let's say I have a smart home. I have = devices and data storage and rule engines that are parts of sensors and = hubs I buy for the house. I have a trust in those devices, because it's = hardware, if the company is leaking data at the hardware level there = isn't much I can do other than buy different sensors.
    In this case, the primary home hub, which is under control of = the homeowner, would also be the AS, as well as a policy agent.  = Authentication in the example is outsourced to whatever auth providers = you want. I set up my home using a google account, a friend is staying = and wants access and uses FB for auth... whatever.
    The part that I have little control over is the client my = friend uses on his phone. Or if I change the client on the tablet in the = kitchen to try out something new. These pieces might be single page = web apps, they might be downloaded apps, etc. I do not want them having = any additional information than is necessary. If I give my friend = permission to unlock the door, and control the lights because they are = feeding my cats while I'm away, the client doesn't need to know anything = beyond, I see this home controller, and I have access to these lights = and that door lock.

    In your scenarios, the client is spy by design, and if it is = a web app, I don't trust them to not grab my user email address from = the AS and put it on a mailing list it sells to some sketchy = company, when the only other component that needs that = information is the RS.

    -steve

    On Thu, Mar = 18, 2021 at 1:21 PM Denis <denis.ietf@free.fr> wrote:
    =20 =20 =20
    I have changed the title of this thread, since the original topic has been closed.

    Justin, you are raising the following question:
    The question I have is =E2=80=94 why does the client need to know what=E2=80=99s in the token?
    Not if they could possibly know, but why would we expect a client to know and manage the contents of the token?
    The answer is quite simple: so that the end-user may have confidence into the architecture.
    The seventh of the eleven privacy principles from ISO 29100 (page 14) is:
    7. Openness, transparency and notice
    If the access token is considered as a black box for the end-user, it cannot be confident about the content of the access token.
    Such access token may disclose some private information without the consent of the end-user. If the access token that it has obtained
    does not match with what has been requested, the client will first not forward the access token to the RS and then will complain about the AS.

    Denis


    =20
    Hi Justin, 

    "The access token is fundamentally a = conversational artifact between the AS and the RS which the client is the carrier of."
    That's right, and a good opportunity = to distinguish between the need for token inspection (i.e. a runtime = verification, wherever that may be)
    and the need to negotiate the token format (a discovery). That last part could very well be an extension, as a way to open up the ecosystem
    beyond JWTs (which are fine, but come with their own limitations). 

    Fabien

    On Thu, Mar 18, 2021 at = 5:59 PM Justin Richer <jricher@mit.edu> wrote:
    =
    On Mar 18, 2021, at 11:30 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Justin = Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 12:08 AM, = Alan Karp <alanhkarp@gmail.com> wrote:

    Adrian Gropper <agropper@healthurl.com> wrote:

    Is there an AS = involved in the delegation? How and where in the lifecycle of the protected = resource? 

    If tokens are = certificates, the AS need not be involved in subsequent delegations.  The = AS must be involved if the tokens are opaque. 

    Tokens are opaque to the = client instance. They are not opaque to the AS. They might be opaque to the RS, but that depends on the kind of relationship the RS and AS have. GNAP should allow different options here as there are different use cases for that.

    Tokens are not opaque to the = client in SPKI, zcap-ld, Orie's implementation with VCs, or our Zebra Copy work.  Why must they be = in GNAP?

    The existence of the AS is exactly the = reason for this. The AS is the role that =E2=80=9Cknowledge about = the token contents=E2=80=9D has been outsourced to in the GNAP = model (which is based on the OAuth model).

    It brings significant simplicity for the = client developer. The question I have is =E2=80=94 why does the = client need to know what=E2=80=99s in the token? Not if they = could possibly know, but why would we expect a client to know and manage the contents of the token? 

    The access token is fundamentally a = conversational artifact between the AS and the RS which the client is the carrier of. The client is not the audience of the token, nor the creator of the token, nor even the manager of the token and the rights it represents. The client as a simple carrier is a powerful model that allows the security layer to get out of the way of the actual application logic that developers want to = do.

     =E2=80=94 Justin


    --------------
    Alan Karp


    On Thu, Mar = 18, 2021 at 4:56 AM Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 12:08 AM, = Alan Karp <alanhkarp@gmail.com> wrote:

    Adrian Gropper <agropper@healthurl.com> wrote:

    Is there an AS = involved in the delegation? How and where in the lifecycle of the protected = resource? 

    If tokens are = certificates, the AS need not be involved in subsequent delegations.  The = AS must be involved if the tokens are opaque. 

    Tokens are opaque to the = client instance. They are not opaque to the AS. They might be opaque to the RS, but that depends on the kind of relationship the RS and AS have. GNAP should allow different options here as there are different use cases for that.

    It would probably be = worthwhile to separate the portions of the spec that talk about the RS-AS relationship into its own standalone document. A similar approach was taken in UMA2 and it was helpful. (Though admittedly, as with anything, there are missteps there that we can hopefully learn from.)

     =E2=80=94 Justin


    --------------
    Alan Karp


    On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Sure! 

    Is there an AS = involved in the delegation? How and where in the lifecycle of the protected resource? 

    Also your use = of "the client" seems to imply that either there is only one client or the client doesn't matter. Which is it?

    Adrian

    On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks for = that. 

    Trying to reframe it:
    GNAP is defined as a delegation protocol so the main intent is related to a delegate of the RO (i.e. the end user) that wishes to access the RO's protected resources, through the = client. 

    Fabien 

    Le jeu. 18 mars 2021 =C3=A0= 04:29, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit :
    At various points in the = lifecycle of the protected resource the client at the resource server (RS) might be:
    • The= RO (subject) user agent trading payment for a service promise
    • The= RO user agent using the promise to access the protected resource
    • A = delegate of the RO user agent using a different client
    What's vague is where the GNAP AS enters the picture as described above. How would you describe = it?

    Adrian


    On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Adrian

    I'm still confused why you're saying the terminology is = vague. 
    I get the "power" neutrality is not to your liking, but RQ / user agent is no better in my = view. 

    Can you = elaborate? 

    Fabien 

    Le jeu. 18 mars 2021 =C3=A0 = 00:18, Adrian Gropper <agropper@healthurl.com> a = =C3=A9crit :
    I'm sure you're right. Our vague = terminology around client and end-user leads to my confusion. If GNAP is = primarily about = delegation then, of course, we = should avoid any incentives to impersonate or we're wasting our time. This is partly why I'm trying to study up on capabilities and asking for expert advice from folks like Alan Karp and Mark Miller (cc'd)

    As best I can understand it, the RS has only two choices, it can:
    =
    • store an attribute of the RO a [DID, email address, GNAP AS URL], or
    • hand the RO a capability as a sort-of promise and avoid making any entries in an ACL or = equivalent.
    When a token comes back to the RS, it will either = be:
    =
    • validated according to something associated with the stored RO attribute, = or
    • signed by the RS = itself.
    Either way, trust in the client seems = moot.

    Adrian



    On Wed, Mar 17, 2021 at 5:29 PM Justin Richer = <jricher@mit.edu> wrote:
    =
    On Mar 17, 2021, at 4:55 PM, Adrian Gropper <agropper@healthurl.com> wrote:
    =

    =
    On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <tobias.looker@mattr.global> = wrote:
    <snip>
    > A client might not have a DID but it could have a VC as a certificate of authenticity linked to some audit = mechanism.

    To me a VC would come under the assertions umbrella (that is to say a VC could be one type of valid assertion). The client may possess or been presented with a VC that it could include in its request to the AS as a way to identify the subject and perhaps prove authentication and = authorization.

    I do not assume that the client that interacts with the AS to make a request and receive a token is the same as the client that will present the token to the RS. In the US HIPAA use-case, for example, the root of trust is a contract between the = patient-subject and the = doctor-requesting party but the doctor workflow is expected to delegate the token to some other end-user that may be using a totally different client such as an EHR.


    If the client that gets the token is not same as the client that uses the token, that is a violation of core security principles as it allows for (and really designs for) impersonation by client software. I would have no reason to trust client software that would hand its credentials over to another piece of software, and in fact I shouldn=E2=80=99= t trust = it. 

    I think you may be conflating several different kinds of parties under the = =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80= =99s entirely possible that one client might call an RS that in turn acts as a client for something else down stream. But each of those hops is different from the = last.

     =E2=80=94 Justin





    --
    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=_D313662A-F580-47BF-896D-2D213B8BBEEA-- From nobody Thu Mar 18 14:02:55 2021 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 208DF3A346C for ; Thu, 18 Mar 2021 14:02:54 -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 H-yXr1wVYn_7 for ; Thu, 18 Mar 2021 14:02:51 -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 E17693A3469 for ; Thu, 18 Mar 2021 14:02:50 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id x9so5202512qto.8 for ; Thu, 18 Mar 2021 14:02:50 -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=hJi0VPrWo+Ra3fFSDxWyvXnaNKwu8xZGz243skho5Vs=; b=Yf1azIAmU0vec+7z5xd/pJfW1Kh07BhGQVc+3LMGcQT/7zqFxW70lDctuaSC3edQ+c zpYOT3yPWCHhoaq8je1RrTZ4jMlg+o1nZXeXdN2kvpzR5F0GUT/qm3ga6WMiKi6MJEnV 3P5dCvZpxG5HBck66I5K3B38dpNyje+ez0NWwAEKPxTQe7EUUPOok95b+N5AtdN2xRY0 k8WSFrhYqlxj/BHjZXNbElDMJ8kiIN0Ah8b8rRKsCTmePkcNB+8CPXYcqXZ6krAq5Eck FbJiFlyoWRBhXiXeMRjOz+clcMm+ESyD9rMYpFUbht7JBp1avqKWyQ1Y/vZKEnbIw2MR ktOA== 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=hJi0VPrWo+Ra3fFSDxWyvXnaNKwu8xZGz243skho5Vs=; b=r7ttj/bM+3W/YvayBj0gDIBcu7vzzNUlDBRoF7/2ATQsMbrgbj1aTiNGzyw1tT1pra NnpyBqBCmMatgnZ5+074Uytn2ZkiczGg6CL8aG94xworJxfJY2ss+QkwLgPIc+Es3sPd AeaGUPxF5NB/HgUsFpXbS2jfWv3c5YLyKel701WrKjyYM5nbZ6/8L3YNAyKoKeU3u0Th hvP8x+551P8bsz+RW496vufmQJQ/RuAO3SCgUYGMdg83elWZUGJPdycu/4IB4fORARaW JdCsDXcbofQ/6oWQVUMh5VfMVTdCtF6BDFJoZVYMnBJoOYqrajO8Z9JVFL8JpddMB8WB +XIQ== X-Gm-Message-State: AOAM532EH32VHUFr9q/Ltcz7Wfl5pt8HuZsGsQCKoAisTgS31Gk4iXDN UM2N36VDhbG0cSol2bH5AFpTedBszYO6RxSgc5c= X-Google-Smtp-Source: ABdhPJzeQ8tUqrRph6rQIVl9hwpt7AEizJBEPJYwapqBKeT7RYpvrLjwnoQYwP1PYWsYu0byaNyWJghv9EPWp5zgrZc= X-Received: by 2002:ac8:7c8d:: with SMTP id y13mr5456990qtv.294.1616101368899; Thu, 18 Mar 2021 14:02:48 -0700 (PDT) MIME-Version: 1.0 References: <614551CF-E544-4376-9576-E2956454D67D@mit.edu> In-Reply-To: From: Alan Karp Date: Thu, 18 Mar 2021 14:02:37 -0700 Message-ID: To: Adrian Gropper Cc: Justin Richer , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000003ac0c05bdd5eca2" Archived-At: Subject: Re: [GNAP] GNAP from a human-centered perspective X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 21:02:54 -0000 --00000000000003ac0c05bdd5eca2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Let's be clear about the trust relationships. The RS has one with its AS, call it AS-RS; the RO has one with its AS, call it AS-RO. I think what Adrian is saying is clear if we keep that distinction in mind. -------------- Alan Karp On Wed, Mar 17, 2021 at 1:42 PM Adrian Gropper wrote: > Hi Justin, > > I just reviewed our charter and I see no clear mandate for an AS-first or > RS-first presumption. > > From my human-centered, subject-empowering perspective, I want to make > sure that I am not forced into an RS-first authorization model. This mean= s > that I want control over discovery of an RS that has a relationship with > me. If I don't trust the RS, and I can't choose an alternative, I will us= e > a pseudonym or lie about my identity before interacting with that RS. > > If an RS does not allow me to control my AS, then they are forcing me to > send requesting parties to an actor that I do not want to share request > data and metadata with. I will then control or hire my own AS and make th= at > discoverable to requesting parties I care about. My AS will determine whi= ch > clients get information about the existence of an RS that does not respec= t > my choice of AS. If I can, (remember that the RS holds all the cards) I > will move my information to another RS that respects my AS choice as soon > as possible and then I will have the power to decide whether to make that > RS discoverable, or not. > > SImply put, I care about where requests are presented and I want GNAP to > call that the AS. How the client gets to the AS, through out-of band > discovery or by visiting an RS-first (UMA-style), may not be that relevan= t > to the core protocol. > > Adrian > > On Wed, Mar 17, 2021 at 1:03 PM Justin Richer wrote: > >> >> >> On Mar 17, 2021, at 12:21 PM, Adrian Gropper >> wrote: >> >> I think Justin and I are starting from the same assumption that "the RS >> holds all the cards" but then reaching different conclusions about the G= NAP >> AS. >> >> The RS can decide what scopes to honor, can ignore tokens, can choose >> their jurisdiction and policies, and can often deny service to subjects = on >> a whim. Giving the RS any additional power or coerced trust (e.g. >> shrink-wrap licenses) over the subject should be avoided by design. >> >> One thing the RS controls is the ability to issue a capability to the >> subject at some point prior to there being any GNAP AS involved. The >> subject can keep this capability in their client (e.g. a wallet) or can >> send that capability to a GNAP AS that they choose. >> >> >> I don=E2=80=99t believe this is in scope for GNAP. The abstraction layer= offered >> by the protocol is such that the only communication between the client >> instance and RS is via an access token issued by an AS. This AS is >> reachable by the client and trusted by the RS. >> >> Fundamentally, what you are describing is function of the AS, at least a= s >> far as the GNAP protocol itself is concerned. Remember, this isn=E2=80= =99t about >> deployment, it=E2=80=99s about the roles and responsibilities of the dif= ferent >> items involved. >> >> >> Instead of issuing a capability, the RS can also choose to accept a >> user-controlled AS. They can do that, for example, by storing a (DID) >> service endpoint to a GNAP AS. The RS could force the subject (as >> controller) to choose from a list of certified ASs or they could ask the= AS >> to present a certificate from a trusted issuer. This last RS-controlled >> option is seen in US HIPAA law but it has provisions for the data subjec= t >> to insist on acceptance of a subject-issued certificate as part of the >> protocol. The UDAP group is active in profiling the format of these >> certificates to be used on top of OAuth. >> >> >> I think that all of these things are functions of the AS, not the RS. >> With many AS deployments in OAuth today, the user can present themselves= to >> the AS using a choice of federated logins. So in GNAP the user=E2=80=99s= agent can >> present a certificate from a trusted issuer. This is not something an AS >> presents to an RS, it=E2=80=99s something that a different component pre= sents to >> the AS. >> >> The result of this is an access token that the RS will accept. The AS an= d >> RS are in the same trust boundary, the crossing of that boundary happens >> inbound to the AS. This is fundamentally the change in language that I h= ave >> been trying to push here. While the RS could accept an arbitrary AS, I >> think it=E2=80=99s both more useful and more realistic for the AS to acc= ept a >> variety of proofs, claims, certifications, etc from the RO and/or user a= t >> runtime in order to make its token. >> >> >> Finally, GNAP should not presume that the AS is either carried by a >> subject or online. A subject can have the option to choose an unreliable= or >> part-time AS. >> >> >> I disagree with this statement. GNAP is a protocol and is based on HTTP. >> From a technical level, we have to assume that it is reachable by the >> client instance at the start of the process. But if we stop trying to pu= t >> the AS into a place where it doesn=E2=80=99t function well, we can start= to talk >> about the unreliable and part-time authorization-and-consent component >> (agent, wallet, whatever) that can feed into the AS when available. This >> leads to a much more robust protocol structure. >> >> =E2=80=94 Justin >> >> Adrian >> >> >> >> >> >> >> >> On Wed, Mar 17, 2021 at 10:55 AM Justin Richer wrote: >> >>> I think this is a fairly reasonable way to look at things, but the >>> sticking point for me is the implication of how the AS =E2=80=9Cbrings = together=E2=80=9D >>> the items. It could be read to mean that the end-user=E2=80=99s policie= s all live >>> on the AS. If the end-user needs to own or control the AS in order for = this >>> to work, I don=E2=80=99t think that pattern has any legs in reality as = it requires >>> an RS to accept access tokens from an unknown source. This means the RS >>> then needs to understand a LOT more about the access token than it woul= d >>> otherwise be able to. >>> >>> Instead, I would encourage us to think of =E2=80=9Cbrings together=E2= =80=9D in the sense >>> that the AS can take as input a number of different things, including >>> things that the user controls and things the RO controls. This is where= I >>> think we can draw the line around the AS in a way that will let it func= tion >>> in this human-facing world. >>> >>> Because you=E2=80=99re absolutely right that the end user shouldn=E2=80= =99t know or care >>> if what they carry is an =E2=80=9CAS=E2=80=9D in the GNAP sense or not.= From their >>> perspective, they need to present something to a service to get somethi= ng >>> done. In the OAuth world this is =E2=80=9Clog in to our web server=E2= =80=9D. In the GNAP >>> world we can have this include a wider variety of things they can prese= nt >>> to the AS, including VCs and DIDs and a bunch of other things. >>> >>> =E2=80=94 Justin >>> >>> > On Mar 17, 2021, at 12:30 AM, Adrian Gropper >>> wrote: >>> > >>> > I truly appreciate the diligence of our editors and contributors. >>> > >>> > Without intruding on the technical discussions, I hope this thread ca= n >>> be an opportunity for us to step out of our comfort zone and look aroun= d. >>> > >>> > As a human data subject, I am cognizant and in control of only two >>> kinds of actors, user agents and services. The user agents are almost >>> exclusively a handful of web browsers, email clients, and apps duplicat= ed >>> and sometimes synchronizing across two to four phones and computers. Th= e >>> services (that I expect have visibility into my persona) are in a dozen >>> categories from banking and ISPs that I expect to be acting as fiduciar= ies >>> to platforms, social networks and other data brokers with their own age= nda. >>> At this altitude, GNAP, DIDs, and ASs are as invisible as MAC addresses= and >>> routers. >>> > >>> > Our success, from a human-centered perspective, will come indirectly >>> as a result of the GNAP Authorization Server. The user agents and servi= ce >>> providers I see (and sometimes choose) will support GNAP along with OAu= th >>> and FIDO and Apple Sign-In as protocols. The common thing about these >>> protocols is that they coexist and overlap in incomprehensible ways mad= e >>> even more obscure by DIDs, VCs, and self-issued identity providers (SIO= P). >>> As we get to DIDcomm, even I get lost. >>> > >>> > My suggestion or proposal to our group is that we respect the human >>> perspective by doing our best to make the concept of an authorization >>> server relevant even if it remains hidden from view behind protocols li= ke >>> GNAP and OAuth and data models like DID and VC. In doing this we would >>> recognize that a human's agent would likely support GNAP AS as well as >>> incumbent attribute management protocols. As a human, I just want my on= line >>> agent to work across as many user-agents and services as possible. As w= ith >>> life partners or spouses, having more than one intelligent semi-autonom= ous >>> agent is not typically a benefit. >>> > >>> > My concrete suggestion is that GNAP define the AS as the entity or >>> actor that brings together the subject's policies, the capabilities gra= nted >>> by services, and requests and serves up authorizations to the requestin= g >>> party. >>> > >>> > Adrian >>> > >>> > >>> > >>> > >>> > -- >>> > TXAuth mailing list >>> > TXAuth@ietf.org >>> > https://www.ietf.org/mailman/listinfo/txauth >>> >>> >> --00000000000003ac0c05bdd5eca2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Let's be clear about the trust relati= onships.=C2=A0 The RS has one with its AS, call it AS-RS; the RO has one wi= th its AS, call it AS-RO.=C2=A0 I think what Adrian is saying is clear if w= e keep that distinction in mind.

    -------------= -
    Alan Karp


    On Wed, Mar 17, 2021 at 1:42 PM Adrian Groppe= r <agropper@healthurl.com&= gt; wrote:
    Hi Justin,

    I just reviewed our charter and I= see no clear mandate for an AS-first or RS-first presumption.=C2=A0
    <= div>
    From my human-centered, subject-empowering perspective, = I want to make sure that I am not forced into an RS-first authorization mod= el. This means that I want control over discovery of an RS that has a relat= ionship with me. If I don't trust the RS, and I can't choose an alt= ernative, I will use a pseudonym or lie about my identity before interactin= g with that RS.

    If an RS does not allow me to cont= rol my AS, then they are forcing me to send requesting parties to an actor = that I do not want to share request data and metadata with. I will then con= trol or hire my own AS and make that discoverable to requesting parties I c= are about. My AS will determine which clients get information about the exi= stence of an RS that does not respect my choice of AS. If I can, (remember = that the RS holds all the cards) I will move my information to another RS t= hat respects my AS choice as soon as possible and then I will have the powe= r to decide whether to make that RS discoverable, or not.

    SImply put, I care about where requests are presented and I want GN= AP to call that the AS. How the client gets to the AS, through out-of band = discovery or by visiting an RS-first (UMA-style), may not be that relevant = to the core protocol.=C2=A0

    Adrian

    =
    On Wed, Ma= r 17, 2021 at 1:03 PM Justin Richer <jricher@mit.edu> wrote:
    =

    On Mar 17, 2021, at 12:21 PM, A= drian Gropper <agropper@healthurl.com> wrote:

    I t= hink Justin and I are starting from the same assumption that "the RS h= olds all the cards" but then reaching different conclusions about the = GNAP AS.=C2=A0

    The RS can decide what scopes to honor, c= an ignore tokens, can choose their jurisdiction and policies, and can often= deny service to subjects on a whim. Giving the RS any additional power or = coerced trust (e.g. shrink-wrap licenses) over the subject should be avoide= d by design.

    One thing the RS controls is the abil= ity=C2=A0to issue a capability to the subject at some point prior to there = being any GNAP AS involved. The subject can keep this capability in their c= lient (e.g. a wallet) or can send that capability to a GNAP AS that they ch= oose.=C2=A0

    I don=E2=80= =99t believe this is in scope for GNAP. The abstraction layer offered by th= e protocol is such that the only communication between the client instance = and RS is via an access token issued by an AS. This AS is reachable by the = client and trusted by the RS.=C2=A0

    Fundamentally,= what you are describing is function of the AS, at least as far as the GNAP= protocol itself is concerned. Remember, this isn=E2=80=99t about deploymen= t, it=E2=80=99s about the roles and responsibilities of the different items= involved.

    Instead of issuing a capability, the RS can also choose to acc= ept a user-controlled AS. They can do that, for=C2=A0example, by storing a = (DID) service endpoint to a GNAP AS. The RS could force the subject (as con= troller) to choose from a list of certified ASs or they could ask the AS to= present a certificate from a trusted issuer. This last RS-controlled optio= n is seen in US HIPAA law but it has provisions for the data subject to ins= ist on acceptance of a subject-issued certificate as part of the protocol. = The UDAP group is active in profiling the format of these certificates to b= e used on top of OAuth.

    I= think that all of these things are functions of the AS, not the RS. With m= any AS deployments in OAuth today, the user can present themselves to the A= S using a choice of federated logins. So in GNAP the user=E2=80=99s agent c= an present a certificate from a trusted issuer. This is not something an AS= presents to an RS, it=E2=80=99s something that a different component prese= nts to the AS.

    The result of this is an access tok= en that the RS will accept. The AS and RS are in the same trust boundary, t= he crossing of that boundary happens inbound to the AS. This is fundamental= ly the change in language that I have been trying to push here. While the R= S could accept an arbitrary AS, I think it=E2=80=99s both more useful and m= ore realistic for the AS to accept a variety of proofs, claims, certificati= ons, etc from the RO and/or user at runtime in order to make its token.

    F= inally, GNAP should not presume that the AS is either carried by a subject = or online. A subject can have the option to choose an unreliable or part-ti= me AS.


    I d= isagree with this statement. GNAP is a protocol and is based on HTTP. From = a technical level, we have to assume that it is reachable by the client ins= tance at the start of the process. But if we stop trying to put the AS into= a place where it doesn=E2=80=99t function well, we can start to talk about= the unreliable and part-time authorization-and-consent component (agent, w= allet, whatever) that can feed into the AS when available. This leads to a = much more robust protocol structure.

    =C2=A0=E2=80= =94 Justin

    Ad= rian=C2=A0




    =


    On Wed, Mar 17, 2021 at 10:55 AM Justin Rich= er <jricher@mit.edu= > wrote:
    = I think this is a fairly reasonable way to look at things, but the sticking= point for me is the implication of how the AS =E2=80=9Cbrings together=E2= =80=9D the items. It could be read to mean that the end-user=E2=80=99s poli= cies all live on the AS. If the end-user needs to own or control the AS in = order for this to work, I don=E2=80=99t think that pattern has any legs in = reality as it requires an RS to accept access tokens from an unknown source= . This means the RS then needs to understand a LOT more about the access to= ken than it would otherwise be able to.

    Instead, I would encourage us to think of =E2=80=9Cbrings together=E2=80=9D= in the sense that the AS can take as input a number of different things, i= ncluding things that the user controls and things the RO controls. This is = where I think we can draw the line around the AS in a way that will let it = function in this human-facing world.

    Because you=E2=80=99re absolutely right that the end user shouldn=E2=80=99t= know or care if what they carry is an =E2=80=9CAS=E2=80=9D in the GNAP sen= se or not. From their perspective, they need to present something to a serv= ice to get something done. In the OAuth world this is =E2=80=9Clog in to ou= r web server=E2=80=9D. In the GNAP world we can have this include a wider v= ariety of things they can present to the AS, including VCs and DIDs and a b= unch of other things.

    =C2=A0=E2=80=94 Justin

    > On Mar 17, 2021, at 12:30 AM, Adrian Gropper <agropper@healthurl.com> wrote= :
    >
    > I truly appreciate the diligence of our editors and contributors.
    >
    > Without intruding on the technical discussions, I hope this thread can= be an opportunity for us to step out of our comfort zone and look around.<= br> >
    > As a human data subject, I am cognizant and in control of only two kin= ds of actors, user agents and services. The user agents are almost exclusiv= ely a handful of web browsers, email clients, and apps duplicated and somet= imes synchronizing across two to four phones and computers. The services (t= hat I expect have visibility into my persona) are in a dozen categories fro= m banking and ISPs that I expect to be acting as fiduciaries to platforms, = social networks and other data brokers with their own agenda. At this altit= ude, GNAP, DIDs, and ASs are as invisible as MAC addresses and routers.
    >
    > Our success, from a human-centered perspective, will come indirectly a= s a result of the GNAP Authorization Server. The user agents and service pr= oviders I see (and sometimes choose) will support GNAP along with OAuth and= FIDO and Apple Sign-In as protocols. The common thing about these protocol= s is that they coexist and overlap in incomprehensible ways made even more = obscure by DIDs, VCs, and self-issued identity providers (SIOP). As we get = to DIDcomm, even I get lost.
    >
    > My suggestion or proposal to our group is that we respect the human pe= rspective by doing our best to make the concept of an authorization server = relevant even if it remains hidden from view behind protocols like GNAP and= OAuth and data models like DID and VC. In doing this we would recognize th= at a human's agent would likely support GNAP AS as well as incumbent at= tribute management protocols. As a human, I just want my online agent to wo= rk across as many user-agents and services as possible. As with life partne= rs or spouses, having more than one intelligent semi-autonomous agent is no= t typically a benefit.
    >
    > My concrete suggestion is that GNAP define the AS as the entity or act= or that brings together the subject's policies, the capabilities grante= d by services, and requests and serves up authorizations to the requesting = party.
    >
    > Adrian
    >
    >=C2=A0 =C2=A0
    >
    >=C2=A0
    > --
    > TXAuth mailing list
    > TXAuth@ietf.org
    >     https://www.ietf.org/mailman/listinfo/txauth

    --00000000000003ac0c05bdd5eca2-- From nobody Thu Mar 18 16:55:23 2021 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 3924D3A0ED3 for ; Thu, 18 Mar 2021 16:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 qtOQr1ZAgh1b for ; Thu, 18 Mar 2021 16:55:19 -0700 (PDT) Received: from mail-vs1-f45.google.com (mail-vs1-f45.google.com [209.85.217.45]) (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 E84E73A0ED2 for ; Thu, 18 Mar 2021 16:55:18 -0700 (PDT) Received: by mail-vs1-f45.google.com with SMTP id z68so2521699vsb.10 for ; Thu, 18 Mar 2021 16:55:18 -0700 (PDT) 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=U0wyWB4qXQh0va9Mze3g8Qb8zoh4LJ6IGMpF/UCC7Q8=; b=aU89YRcCFeeMeKB19cYgNrkXHZEZjWqNn3UFlP+z//3r6z3EeSn6M5Ryyxyvt4rbv8 F2TOixsjEvRHfBh46sUTcTcIOMsIvyXKhV3tP0VjhtEK/7tEfOp9XTYoziKiWgFNyVrj DGVbvWWaup9brzljX2QLhOPRx8XSsiDRXAfPp1oZKTXtYOBQKd9eSDrN7QmYbOnM5vGm iSKx1opDtSgLyoAw/kpqNrqoQNeBwRyE72P3hq2oAhyajEiF35ji0ZMxDG/EXW5487YG wlZWHQVa4ZMdQxk/lrYraxCA5sDwvuOI/XllxaSEMn1UqRMVVuLdNsFYuDUX1X9uWbs+ De5Q== X-Gm-Message-State: AOAM531jKAn9w3UgTRViSOLjH73RPipl4JP25gZ7xaS2onLZgrI+vss5 AOZk0l4v93bqf/4QiY7tmauR7vRKhPbN0+2EW1M= X-Google-Smtp-Source: ABdhPJyQunzR4g9OebcDurV2tHD/ZHnX1KA9d/TWvMoLwk121hMWRgEQNThrtOZeyQCeHOvxnU5F+RAnL69zo1XELHI= X-Received: by 2002:a67:db84:: with SMTP id f4mr1323425vsk.20.1616111717771; Thu, 18 Mar 2021 16:55:17 -0700 (PDT) MIME-Version: 1.0 References: <43447446-4061-49F2-8486-5A196C3C75E2@mit.edu> <37a04505-84ef-aecf-6913-5aad8330c97c@free.fr> In-Reply-To: From: Adrian Gropper Date: Thu, 18 Mar 2021 19:55:06 -0400 Message-ID: To: Justin Richer Cc: Steve Moore , txauth gnap Content-Type: multipart/alternative; boundary="000000000000daee7605bdd85445" Archived-At: Subject: Re: [GNAP] Should access tokens be opaque or not for the clients ? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 23:55:22 -0000 --000000000000daee7605bdd85445 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 This aligns with my healthcare use-case to the extent that Justin can transfer the capability granted by that QR code to Adrian who happens to be nearby Steve's house. I've tried to capture some of this in my comment to #145 https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-= 802388458 - Adrian On Thu, Mar 18, 2021 at 2:39 PM Justin Richer wrote: > Right, and in the GNAP model this becomes something my client instance > presents to the AS when I show up. The AS can validate my presentation of > this item and give my client instance a token to call Steve=E2=80=99s RS.= Or if you > wanted to get super fancy Steve=E2=80=99s AS could even challenge my clie= nt > instance and get a cryptographic response to prove I have the thing Steve > had me scan. But in both cases it=E2=80=99s part of things that the AS co= llects in > order to create the access token. > > =E2=80=94 Justin > > On Mar 18, 2021, at 2:26 PM, Stephen Moore wrote: > > That in my mind works out great... Say I'm logged into my home hub/AS. > Justin is over and agrees to cat sit, I pull up my client app, and genera= te > a QR code that has maybe The AS URI, the HomeHub API URL, and the 'specia= l > token to present to AS for a real token'. Justin scans that QR code with > his home controller app, and BAM, he's onboarded as a guest without even > logging into my AS or me dealing with his Auth provider. > -steve > > On Thu, Mar 18, 2021 at 2:08 PM Justin Richer wrote: > >> I think Steve=E2=80=99s use case gives an interesting example of somethi= ng that I >> believe Adrian=E2=80=99s been talking about as well =E2=80=94 delegating= to another person. >> >> We traditionally think of delegation at the AS to mean =E2=80=9Ca differ= ent user >> account logs in to the AS=E2=80=9D, and it=E2=80=99s important to know t= hat this does in >> fact work. But this could just as easily be =E2=80=9CSteve sends his fri= end an >> artifact to present to the AS to get access=E2=80=9D. This isn=E2=80=99t= Steve (or Steve=E2=80=99s >> client software) getting and sending an access token, this is sending so= me >> other set of rights credential to his friend, or his friend=E2=80=99s so= ftware. So >> then Steve=E2=80=99s AS can have policy that says =E2=80=9Cwhen I see th= is rights >> credential, give an access token for the following attenuated things, >> because Steve said so=E2=80=9D. The AS doesn=E2=80=99t even ever need to= know who Steve=E2=80=99s >> friend is! >> >> And importantly here, we don=E2=80=99t expect Steve=E2=80=99s friend to = bring their own >> AS to the party. Steve=E2=80=99s RS has no reason to trust his friend=E2= =80=99s AS, let >> alone his friend=E2=80=99s client. But Steve=E2=80=99s AS is in a positi= on to know more >> about the rights policies that Steve wants to apply, and so it can use >> other technologies like VC=E2=80=99s, DIDs, OIDC, or any number of other= things to >> let things go through. This pattern is exactly why I think we need to th= ink >> of this in terms of what=E2=80=99s currently called =E2=80=9Cinteraction= =E2=80=9D at the AS. It=E2=80=99s >> not really just about how the end-user interacts, it=E2=80=99s about how= the AS >> gathers all the consent and authorization information. I plan to rewrite >> section 4 to that effect. >> >> =E2=80=94 Justin >> >> On Mar 18, 2021, at 1:58 PM, Stephen Moore wrote: >> >> I'm having some concerns with the way you're flipping the trust here >> Denis. You seem to indicate that the user has trust in the RS and the >> Client and has to gain the trust of the AS. I feel like the least >> trustworthy portion of the architecture is the client, because that seem= s >> like it is the most interchangeable component. >> Let me explain by way of a use case I have in mind. >> Let's say I have a smart home. I have devices and data storage and rule >> engines that are parts of sensors and hubs I buy for the house. I have a >> trust in those devices, because it's hardware, if the company is leaking >> data at the hardware level there isn't much I can do other than buy >> different sensors. >> In this case, the primary home hub, which is under control of the >> homeowner, would also be the AS, as well as a policy agent. Authenticat= ion >> in the example is outsourced to whatever auth providers you want. I set = up >> my home using a google account, a friend is staying and wants access and >> uses FB for auth... whatever. >> The part that I have little control over is the client my friend uses on >> his phone. Or if I change the client on the tablet in the kitchen to try >> out something new. These pieces might be single page web apps, they migh= t >> be downloaded apps, etc. I do not want them having any additional >> information than is necessary. If I give my friend permission to unlock = the >> door, and control the lights because they are feeding my cats while I'm >> away, the client doesn't need to know anything beyond, I see this home >> controller, and I have access to these lights and that door lock. >> >> In your scenarios, the client is spy by design, and if it is a web app, = I >> don't trust them to not grab my user email address from the AS and put i= t >> on a mailing list it sells to some sketchy company, when the only other >> component that needs that information is the RS. >> >> -steve >> >> On Thu, Mar 18, 2021 at 1:21 PM Denis wrote: >> >>> I have changed the title of this thread, since the original topic has >>> been closed. >>> >>> Justin, you are raising the following question: >>> >>> The question I have is =E2=80=94 why does the client need to know what= =E2=80=99s in the >>> token? >>> Not if they could possibly know, but why would we expect a client to >>> know and manage the contents of the token? >>> >>> The answer is quite simple: so that the end-user may have confidence >>> into the architecture. >>> The seventh of the eleven privacy principles from ISO 29100 (page 14) i= s: >>> >>> *7. Openness, transparency and notice * >>> >>> If the access token is considered as a black box for the end-user, it >>> cannot be confident about the content of the access token. >>> Such access token may disclose some private information without the >>> consent of the end-user. If the access token that it has obtained >>> does not match with what has been requested, the client will first not >>> forward the access token to the RS and then will complain about the AS. >>> >>> Denis >>> >>> >>> Hi Justin, >>> >>> "The access token is fundamentally a conversational artifact between th= e >>> AS and the RS which the client is the carrier of." >>> That's right, and a good opportunity to distinguish between the need fo= r >>> token inspection (i.e. a runtime verification, wherever that may be) >>> and the need to negotiate the token format (a discovery). That last par= t >>> could very well be an extension, as a way to open up the ecosystem >>> beyond JWTs (which are fine, but come with their own limitations). >>> >>> Fabien >>> >>> On Thu, Mar 18, 2021 at 5:59 PM Justin Richer wrote: >>> >>>> On Mar 18, 2021, at 11:30 AM, Alan Karp wrote: >>>> >>>> >>>> Justin Richer wrote: >>>> >>>>> On Mar 18, 2021, at 12:08 AM, Alan Karp wrote: >>>>> >>>>> >>>>> Adrian Gropper wrote: >>>>> >>>>>> >>>>>> Is there an AS involved in the delegation? How and where in the >>>>>> lifecycle of the protected resource? >>>>>> >>>>> >>>>> If tokens are certificates, the AS need not be involved in subsequent >>>>> delegations. The AS must be involved if the tokens are opaque. >>>>> >>>>> >>>>> Tokens are opaque to the client instance. They are not opaque to the >>>>> AS. They might be opaque to the RS, but that depends on the kind of >>>>> relationship the RS and AS have. GNAP should allow different options = here >>>>> as there are different use cases for that. >>>>> >>>> >>>> Tokens are not opaque to the client in SPKI, zcap-ld, Orie's >>>> implementation with VCs, or our Zebra Copy work. Why must they be in = GNAP? >>>> >>>> >>>> The existence of the AS is exactly the reason for this. The AS is the >>>> role that =E2=80=9Cknowledge about the token contents=E2=80=9D has bee= n outsourced to in >>>> the GNAP model (which is based on the OAuth model). >>>> >>>> It brings significant simplicity for the client developer. The questio= n >>>> I have is =E2=80=94 why does the client need to know what=E2=80=99s in= the token? Not if >>>> they could possibly know, but why would we expect a client to know and >>>> manage the contents of the token? >>>> >>>> The access token is fundamentally a conversational artifact between th= e >>>> AS and the RS which the client is the carrier of. The client is not th= e >>>> audience of the token, nor the creator of the token, nor even the mana= ger >>>> of the token and the rights it represents. The client as a simple carr= ier >>>> is a powerful model that allows the security layer to get out of the w= ay of >>>> the actual application logic that developers want to do. >>>> >>>> =E2=80=94 Justin >>>> >>>> >>>> -------------- >>>> Alan Karp >>>> >>>> >>>> On Thu, Mar 18, 2021 at 4:56 AM Justin Richer wrote: >>>> >>>>> On Mar 18, 2021, at 12:08 AM, Alan Karp wrote: >>>>> >>>>> >>>>> Adrian Gropper wrote: >>>>> >>>>>> >>>>>> Is there an AS involved in the delegation? How and where in the >>>>>> lifecycle of the protected resource? >>>>>> >>>>> >>>>> If tokens are certificates, the AS need not be involved in subsequent >>>>> delegations. The AS must be involved if the tokens are opaque. >>>>> >>>>> >>>>> Tokens are opaque to the client instance. They are not opaque to the >>>>> AS. They might be opaque to the RS, but that depends on the kind of >>>>> relationship the RS and AS have. GNAP should allow different options = here >>>>> as there are different use cases for that. >>>>> >>>>> It would probably be worthwhile to separate the portions of the spec >>>>> that talk about the RS-AS relationship into its own standalone docume= nt. A >>>>> similar approach was taken in UMA2 and it was helpful. (Though admitt= edly, >>>>> as with anything, there are missteps there that we can hopefully lear= n >>>>> from.) >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> >>>>> -------------- >>>>> Alan Karp >>>>> >>>>> >>>>> On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper >>>>> wrote: >>>>> >>>>>> Sure! >>>>>> >>>>>> Is there an AS involved in the delegation? How and where in the >>>>>> lifecycle of the protected resource? >>>>>> >>>>>> Also your use of "the client" seems to imply that either there is >>>>>> only one client or the client doesn't matter. Which is it? >>>>>> >>>>>> Adrian >>>>>> >>>>>> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>>> Thanks for that. >>>>>>> >>>>>>> Trying to reframe it: >>>>>>> GNAP is defined as a delegation protocol so the main intent is >>>>>>> related to a delegate of the RO (i.e. the end user) that wishes to = access >>>>>>> the RO's protected resources, through the client. >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper >>>>>>> a =C3=A9crit : >>>>>>> >>>>>>>> At various points in the lifecycle of the protected resource the >>>>>>>> client at the resource server (RS) might be: >>>>>>>> >>>>>>>> - The RO (subject) user agent trading payment for a service >>>>>>>> promise >>>>>>>> - The RO user agent using the promise to access the protected >>>>>>>> resource >>>>>>>> - A delegate of the RO user agent using a different client >>>>>>>> >>>>>>>> What's vague is where the GNAP AS enters the picture as described >>>>>>>> above. How would you describe it? >>>>>>>> >>>>>>>> Adrian >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi Adrian >>>>>>>>> >>>>>>>>> I'm still confused why you're saying the terminology is vague. >>>>>>>>> I get the "power" neutrality is not to your liking, but RQ / user >>>>>>>>> agent is no better in my view. >>>>>>>>> >>>>>>>>> Can you elaborate? >>>>>>>>> >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper < >>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>> >>>>>>>>>> I'm sure you're right. Our vague terminology around >>>>>>>>>> client and end-user leads to my confusion. If GNAP is primarily = about >>>>>>>>>> delegation then, of course, we should avoid any incentives to im= personate >>>>>>>>>> or we're wasting our time. This is partly why I'm trying to stud= y up on >>>>>>>>>> capabilities and asking for expert advice from folks like Alan K= arp and >>>>>>>>>> Mark Miller (cc'd) >>>>>>>>>> >>>>>>>>>> As best I can understand it, the RS has only two choices, it can= : >>>>>>>>>> >>>>>>>>>> - store an attribute of the RO a [DID, email address, GNAP AS >>>>>>>>>> URL], or >>>>>>>>>> - hand the RO a capability as a sort-of promise and avoid >>>>>>>>>> making any entries in an ACL or equivalent. >>>>>>>>>> >>>>>>>>>> When a token comes back to the RS, it will either be: >>>>>>>>>> >>>>>>>>>> - validated according to something associated with the stored >>>>>>>>>> RO attribute, or >>>>>>>>>> - signed by the RS itself. >>>>>>>>>> >>>>>>>>>> Either way, trust in the client seems moot. >>>>>>>>>> >>>>>>>>>> Adrian >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper < >>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker < >>>>>>>>>>> tobias.looker@mattr.global> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> > A client might not have a DID but it could have a VC as a >>>>>>>>>>>> certificate of authenticity linked to some audit mechanism. >>>>>>>>>>>> >>>>>>>>>>>> To me a VC would come under the assertions umbrella (that is t= o >>>>>>>>>>>> say a VC could be one type of valid assertion). The client may= possess or >>>>>>>>>>>> been presented with a VC that it could include in its request = to the AS as >>>>>>>>>>>> a way to identify the subject and perhaps prove authentication= and >>>>>>>>>>>> authorization. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I do not assume that the client that interacts with the AS to >>>>>>>>>>> make a request and receive a token is the same as the client th= at will >>>>>>>>>>> present the token to the RS. In the US HIPAA use-case, for exam= ple, the >>>>>>>>>>> root of trust is a contract between the patient-subject and the >>>>>>>>>>> doctor-requesting party but the doctor workflow is expected to = delegate the >>>>>>>>>>> token to some other end-user that may be using a totally differ= ent client >>>>>>>>>>> such as an EHR. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> If the client that gets the token is not same as the client tha= t >>>>>>>>>>> uses the token, that is a violation of core security principles= as it >>>>>>>>>>> allows for (and really designs for) impersonation by client sof= tware. I >>>>>>>>>>> would have no reason to trust client software that would hand i= ts >>>>>>>>>>> credentials over to another piece of software, and in fact I sh= ouldn=E2=80=99t >>>>>>>>>>> trust it. >>>>>>>>>>> >>>>>>>>>>> I think you may be conflating several different kinds of partie= s >>>>>>>>>>> under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2= =80=99s entirely possible that one >>>>>>>>>>> client might call an RS that in turn acts as a client for somet= hing else >>>>>>>>>>> down stream. But each of those hops is different from the last. >>>>>>>>>>> >>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>> >>>>>>>>>>> >>>>> >>>> >>> >>> -- >>> 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 > --000000000000daee7605bdd85445 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    +1 This aligns with my healthcare use-cas= e to the extent that Justin can transfer the capability granted by that QR = code to Adrian who happens to be nearby Steve's house.

    I've tried to capture some of this in my comment to #145=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issu= es/145#issuecomment-802388458

    - Adrian

    On Thu, Mar 18, 2021 at 2:39 PM Justin Richer <jricher@mit.edu> wrote:
    Right, and in = the GNAP model this becomes something my client instance presents to the AS= when I show up. The AS can validate my presentation of this item and give = my client instance a token to call Steve=E2=80=99s RS. Or if you wanted to = get super fancy Steve=E2=80=99s AS could even challenge my client instance = and get a cryptographic response to prove I have the thing Steve had me sca= n. But in both cases it=E2=80=99s part of things that the AS collects in or= der to create the access token.

    =C2=A0=E2=80=94 Jus= tin

    On Mar 18, 2021, at 2:26 PM,= Stephen Moore <s= rmoore@gmail.com> wrote:

    That in my m= ind works out great... Say I'm logged into my home hub/AS. Justin is ov= er and agrees to cat sit, I pull up my client app, and generate a QR code t= hat has maybe The AS URI, the HomeHub API URL, and the 'special token t= o present to AS for a real token'. Justin scans that QR code with his h= ome controller app, and BAM, he's onboarded as a guest without even log= ging into my AS or me dealing with his Auth provider.
    -steve

    On Th= u, Mar 18, 2021 at 2:08 PM Justin Richer <jricher@mit.edu> wrote:
    I think Steve=E2=80=99s use case gives an interesting example of = something that I believe Adrian=E2=80=99s been talking about as well =E2=80= =94 delegating to another person.

    We traditionally think= of delegation at the AS to mean =E2=80=9Ca different user account logs in = to the AS=E2=80=9D, and it=E2=80=99s important to know that this does in fa= ct work. But this could just as easily be =E2=80=9CSteve sends his friend a= n artifact to present to the AS to get access=E2=80=9D. This isn=E2=80=99t = Steve (or Steve=E2=80=99s client software) getting and sending an access to= ken, this is sending some other set of rights credential to his friend, or = his friend=E2=80=99s software. So then Steve=E2=80=99s AS can have policy t= hat says =E2=80=9Cwhen I see this rights credential, give an access token f= or the following attenuated things, because Steve said so=E2=80=9D. The AS = doesn=E2=80=99t even ever need to know who Steve=E2=80=99s friend is!=C2=A0=

    And importantly here, we don=E2=80=99t expect Ste= ve=E2=80=99s friend to bring their own AS to the party. Steve=E2=80=99s RS = has no reason to trust his friend=E2=80=99s AS, let alone his friend=E2=80= =99s client. But Steve=E2=80=99s AS is in a position to know more about the= rights policies that Steve wants to apply, and so it can use other technol= ogies like VC=E2=80=99s, DIDs, OIDC, or any number of other things to let t= hings go through. This pattern is exactly why I think we need to think of t= his in terms of what=E2=80=99s currently called =E2=80=9Cinteraction=E2=80= =9D at the AS. It=E2=80=99s not really just about how the end-user interact= s, it=E2=80=99s about how the AS gathers all the consent and authorization = information. I plan to rewrite section 4 to that effect.

    =C2=A0=E2=80=94 Justin

    On= Mar 18, 2021, at 1:58 PM, Stephen Moore <srmoore@gmail.com> wrote:

    I'm having some concerns with the way you're flipping= the trust here Denis. You seem to indicate that the user has trust in the = RS and the Client and has to gain the trust of the AS. I feel like the leas= t trustworthy portion of the architecture is the client, because that seems= like it is the most interchangeable component.
    =C2=A0Let me explain by= way of a use case I have in mind.
    Let's say I have a smart h= ome. I have devices and data storage and rule engines that are parts of sen= sors and hubs I buy for the house. I have a trust in those devices, because= it's hardware, if the company is leaking data at the hardware level th= ere isn't much I can do other than buy different sensors.
    In = this case, the primary home hub, which is under control of the homeowner, w= ould also be the AS, as well as a policy agent.=C2=A0 Authentication in the= example is outsourced to whatever auth providers you want. I set up my hom= e using a google account, a friend is staying and wants access and uses FB = for auth... whatever.
    The part that I have little control over is= the client my friend uses on his phone. Or if I change the client on the t= ablet in the kitchen to try out something new. These pieces=C2=A0might be s= ingle page web apps, they might be downloaded apps, etc. I do not want them= having any additional information than is necessary. If I give my friend p= ermission to unlock the door, and control the lights because they are feedi= ng my cats while I'm away, the client doesn't need to know anything= beyond, I see this home controller, and I have access to these lights and = that door lock.

    In your scenarios, the client is s= py by design, and if it is a web app, I don't trust them to not grab my= user email address from the=C2=A0AS and put it on a mailing list it sells = to some sketchy company,=C2=A0when the only other component=C2=A0that needs= that information is the RS.

    -steve
    On Thu, M= ar 18, 2021 at 1:21 PM Denis <denis.ietf@free.fr> wrote:
    =20 =20 =20
    I have changed the title of this thread, since the original topic has been closed.

    Justin, you are raising the following question:
    The question I have is =E2=80=94 why does the client need to know what=E2=80=99s in the token?
    Not if they could possibly know, but why would we expect a client to know and manage the contents of the token?
    The answer is quite simple: so that the end-user may have confidence into the architecture.
    The seventh of the eleven privacy principles from ISO 29100 (page 14) is:
    7. Openness, transparency and notice
    If the access token is considered as a black box for the end-user, it cannot be confident about the content of the access token.
    Such access token may disclose some private information without the consent of the end-user. If the access token that it has obtained
    does not match with what has been requested, the client will first not forward the access token to the RS and then will complain about the AS.

    Denis


    =20
    Hi Justin,=C2=A0

    "The access token is fundamentally a conversational artifact between the AS and the RS which the client is the carrier of."
    That's right,=C2=A0and a good=C2=A0opportunity to distingu= ish between the need for token=C2=A0inspection (i.e. a runtime verification, wherever that may be)
    and the need to negotiate the token format (a discovery). That last part could very well be an extension, as a way to open up the ecosystem
    beyond JWTs (which are fine, but come with their own limitations).=C2=A0

    Fabien

    On Thu, Mar 18, 2021 at 5:59 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 11:30 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 12:08 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    A= drian Gropper <agropper@healthurl.com> wrote:

    Is there an AS involved in the delegation? How and where in the lifecycle=C2=A0of the protected resource?=C2=A0

    If tokens are certificates, the AS need not be involved in subsequent delegations.=C2=A0 The AS must be involved if the tokens are opaque.=C2=A0

    Tokens are opaque to the client instance. They are not opaque to the AS. They might be opaque to the RS, but that depends on the kind of relationship the RS and AS have. GNAP should allow different options here as there are different use cases for that.

    Tokens are not opaque to the client in SPKI, zcap-ld, Orie's implementation with VCs= , or our Zebra Copy work.=C2=A0 Why must they be in GNAP?

    The existence of the AS is exactly the reason for this. The AS is the role that =E2=80=9Cknowledge about the = token contents=E2=80=9D has been outsourced to in the GNAP model (which is based on the OAuth model).

    It brings significant simplicity for the client developer. The question I have is =E2=80=94 why does the cl= ient need to know what=E2=80=99s in the token? Not if they could possibly know, but why would we expect a client to know and manage the contents of the token?=C2=A0

    The access token is fundamentally a conversational artifact between the AS and the RS which the client is the carrier of. The client is not the audience of the token, nor the creator of the token, nor even the manager of the token and the rights it represents. The client as a simple carrier is a powerful model that allows the security layer to get out of the way of the actual application logic that developers want to do.

    =C2=A0=E2=80=94 Justin


    --------------
    Alan Karp


    On Thu, Mar 18, 2021 at 4:56 AM Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 12:08 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    A= drian Gropper <agropper@healthurl.com> wrote:

    Is there an AS involved in the delegation? How and where in the lifecycle=C2=A0of the protected resource?=C2=A0

    If tokens are certificates, the AS need not be involved in subsequent delegations.=C2=A0 The AS must be involved if the tokens are opaque.=C2=A0

    Tokens are opaque to the client instance. They are not opaque to the AS. They might be opaque to the RS, but that depends on the kind of relationship the RS and AS have. GNAP should allow different options here as there are different use cases for that.

    It would probably be worthwhile to separate the portions of the spec that talk about the RS-AS relationship into its own standalone document. A similar approach was taken in UMA2 and it was helpful. (Though admittedly, as with anything, there are missteps there that we can hopefully learn from.)

    =C2=A0=E2=80=94 Justin


    --------------
    Alan Karp


    O= n Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Sure!=C2=A0

    Is there an AS involved in the delegation? How and where in the lifecycle=C2=A0of the protected resource?=C2=A0

    Also your use of "the client" seems to imply tha= t either there is only one client or the client doesn'= t matter. Which is it?

    Adrian

    On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks for that.=C2=A0

    Trying to reframe it:
    GNAP is defined as a delegation protocol so the main intent is related to a delegate of the RO (i.e. the end user) that wishes to access the RO's protected resources, through the client.=C2=A0

    Fabien=C2=A0

    Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    At various points in the lifecycle=C2=A0of t= he protected resource the client at the resource server (RS) might be:
    • The RO (subject) user agent trading payment for a service promise
    • The RO user agent using the promise to access the protected resource
    • A delegate of the RO user agent using a different client
    What's vague is where the GNAP AS enters the picture as described above. How would you describe it?

    Adrian


    On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault <f= abien.imbault@gmail.com> wrote:
    Hi Adrian
    <= br>
    I= 'm still confused why you're saying the terminology is vague.=C2=A0
    I get the "power" neutrality is not to your liking, but RQ / user agent is no better in my view.=C2=A0=
    <= br>
    C= an you elaborate?=C2=A0<= /div>
    <= br>
    F= abien=C2=A0

    Le jeu. 18 mars 2021 =C3=A0 00:18= , Adrian Gropper <agropper@= healthurl.com> a =C3=A9crit=C2= =A0:
    = I'm sure you're right. Our vague terminology=C2=A0= around client=C2=A0and=C2=A0end-user leads to my confusion. If GNAP is primarily a= bout delegation=C2=A0t= hen, of course, we should=C2=A0avoid any incentives to impersonate or we're wasting our time. This is partly why I'= m trying to study up on capabilities and asking for expert advice from folks like Alan Karp and Mark Miller (cc'd)

    As best I can understand it, the RS has only two choices, it can:
    • store an attribute of the RO a [DID, email address, GNAP AS URL], or
    • hand the RO a capability as a sort-of promise and avoid making any entries in an ACL or equivalent.
    When a token comes back to the RS, it will either be:
    • validated according to something associated with the stored RO attribute, or
    • signed by the RS itself.
    Either way, trust in the client seems moot.

    Adrian



    On Wed, Mar 17, 2021 at 5:29 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 17, 2021, at 4:55 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    = On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <tobias.looker@mattr.global> wrote:
    <snip>=
    > A client might not have a DID but it could have a VC as a certificate of authenticity linked to some audit mechanism.

    To me a VC would come under the assertions umbrella (that is to say a VC could be one type of valid assertion). The client may possess or been presented with a VC that it could include in its request to the AS as a way to identify the subject and perhaps prove authentication and authorization.

    I do not assume that the client that interacts with the AS to make a request and receive a token is the same as the client that will present the token to the RS. In the US HIPAA use-case, for example, the root of trust is a contract between the patient-subject and the doctor-requesting party but the doctor workflow is expected to delegate the token to some other end-user that may be using a totally different client such as an EHR.


    If the client that gets the token is not same as the client that uses the token, that is a violation of core security principles as it allows for (and really designs for) impersonation by client software. I would have no reason to trust client software that would hand its credentials over to another piece of software, and in fact I shouldn=E2=80=99t trust it.=C2=A0

    I think you may be conflating several different kinds of parties under the =E2=80=9Cclie= nt=E2=80=9D umbrella here, though. It=E2=80= =99s entirely possible that one client might call an RS that in turn acts as a client for something else down stream. But each of those hops is different from the last.

    =C2=A0=E2=80= =94 Justin





    --
    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
    --000000000000daee7605bdd85445-- From nobody Thu Mar 18 17:16:54 2021 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 CBA9E3A0FEA for ; Thu, 18 Mar 2021 17:16:53 -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 OMhYf91ZaGOv for ; Thu, 18 Mar 2021 17:16:50 -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 52EBA3A0FE8 for ; Thu, 18 Mar 2021 17:16:50 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id z136so4260025iof.10 for ; Thu, 18 Mar 2021 17:16:50 -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=iCobvUSCaj3/vIK/Yk5R1DzF4/Reef65UEWkbjvVud8=; b=ZJ8UVcHRe+Juh5zoUZ+YgGO48Qso3GFEBq26MAxhTrbMvZXR6l2iOY/qhG9vYhaXw3 myDx1YyobZNBcdhS6NDC4ClQklyPa+YYJ+E30P47SvFPTjEtQmEIn4rFh+WZmwykzaGn /zbfw3gaWs7obZlWeVviwxG3QqiV00mrdGquc1KAXfPj48KaWN1PXaiYhRSuL6+/gnBP TK69dZTFaTl5eBq7d5RxPxLhKsNAft+gH077MQ0OqbOXRK8OnfYpE6sqcjnl6SgZmTLt T1IQZDauXV+ptR5Mam964YoZ5b6WNKHWIKvRLE4MdaRIGeTga0R6GdH1dykXhKfeT2PD Ktmw== 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=iCobvUSCaj3/vIK/Yk5R1DzF4/Reef65UEWkbjvVud8=; b=Im5f3Q0uVb6qZmRiL2zMmU/kfZsqNXyeJuX4k5mE8F8j080Og0DDhN0J9T143GYzZO Sy/LA/fITb6XQFGeBiNQvK2fZkZDiwSfstnKrGq4evnI0W7r+xahV70czRkbGi4WY2NY k9tz6NQWSSo7vKjjkkoL0PziRdZuvWVP5Ob6J5zRm0YSdDZsnsgj0LZUUDBtOasgwjBP OGPihVkxed1WYcf2easPYqCIKob0H6RyXFSXGvnJ/9RerFGCXgz+4/MCdrU8FrOmu2Vf GOvX3EjR/7eh6ofwQzBi9GUKlqKkAPQsaVksmW0Hhu6m8OBm3hWl1Vu4ulQSHg+hMPKX zKdA== X-Gm-Message-State: AOAM530ugwntGA6GM2YdIsGmXXE/tgZlkn3tCH1NTGzKczcDmPnNRITx WanrRqPY0PKaDcb+d29K7VdYqN0oSduCGy4pZ63zlqQB92w= X-Google-Smtp-Source: ABdhPJyVzgKR8oeVdGtKjQt1R8bl9ds29fRUFO8RgyqP0ci4efocvEKYzRaOTQZf+U+328JohGzMR7kSDHWucnQ2Gmk= X-Received: by 2002:a05:6602:2018:: with SMTP id y24mr879077iod.74.1616113008962; Thu, 18 Mar 2021 17:16:48 -0700 (PDT) MIME-Version: 1.0 References: <43447446-4061-49F2-8486-5A196C3C75E2@mit.edu> <37a04505-84ef-aecf-6913-5aad8330c97c@free.fr> In-Reply-To: From: Fabien Imbault Date: Fri, 19 Mar 2021 01:16:34 +0100 Message-ID: To: Adrian Gropper Cc: Justin Richer , txauth gnap , Steve Moore Content-Type: multipart/alternative; boundary="000000000000d0ed6905bdd8a11d" Archived-At: Subject: Re: [GNAP] Should access tokens be opaque or not for the clients ? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 00:16:54 -0000 --000000000000d0ed6905bdd8a11d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Adrian, I'm really not sure I understand here. I get the idea of putting a policy engine in front of your services to implement ZTA. But I'm not sure I get this way of framing things. It blurs functional roles and actual services, and most importantly if everything gets its own AS, it also gets by transitivity its RO'/RQ' (and then its AS-RO' etc) and so the complexity becomes staggering. Why do we need that? Fabien Le ven. 19 mars 2021 =C3=A0 00:55, Adrian Gropper = a =C3=A9crit : > +1 This aligns with my healthcare use-case to the extent that Justin can > transfer the capability granted by that QR code to Adrian who happens to = be > nearby Steve's house. > > I've tried to capture some of this in my comment to #145 > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecommen= t-802388458 > > - Adrian > > On Thu, Mar 18, 2021 at 2:39 PM Justin Richer wrote: > >> Right, and in the GNAP model this becomes something my client instance >> presents to the AS when I show up. The AS can validate my presentation o= f >> this item and give my client instance a token to call Steve=E2=80=99s RS= . Or if you >> wanted to get super fancy Steve=E2=80=99s AS could even challenge my cli= ent >> instance and get a cryptographic response to prove I have the thing Stev= e >> had me scan. But in both cases it=E2=80=99s part of things that the AS c= ollects in >> order to create the access token. >> >> =E2=80=94 Justin >> >> On Mar 18, 2021, at 2:26 PM, Stephen Moore wrote: >> >> That in my mind works out great... Say I'm logged into my home hub/AS. >> Justin is over and agrees to cat sit, I pull up my client app, and gener= ate >> a QR code that has maybe The AS URI, the HomeHub API URL, and the 'speci= al >> token to present to AS for a real token'. Justin scans that QR code with >> his home controller app, and BAM, he's onboarded as a guest without even >> logging into my AS or me dealing with his Auth provider. >> -steve >> >> On Thu, Mar 18, 2021 at 2:08 PM Justin Richer wrote: >> >>> I think Steve=E2=80=99s use case gives an interesting example of someth= ing that >>> I believe Adrian=E2=80=99s been talking about as well =E2=80=94 delegat= ing to another >>> person. >>> >>> We traditionally think of delegation at the AS to mean =E2=80=9Ca diffe= rent user >>> account logs in to the AS=E2=80=9D, and it=E2=80=99s important to know = that this does in >>> fact work. But this could just as easily be =E2=80=9CSteve sends his fr= iend an >>> artifact to present to the AS to get access=E2=80=9D. This isn=E2=80=99= t Steve (or Steve=E2=80=99s >>> client software) getting and sending an access token, this is sending s= ome >>> other set of rights credential to his friend, or his friend=E2=80=99s s= oftware. So >>> then Steve=E2=80=99s AS can have policy that says =E2=80=9Cwhen I see t= his rights >>> credential, give an access token for the following attenuated things, >>> because Steve said so=E2=80=9D. The AS doesn=E2=80=99t even ever need t= o know who Steve=E2=80=99s >>> friend is! >>> >>> And importantly here, we don=E2=80=99t expect Steve=E2=80=99s friend to= bring their own >>> AS to the party. Steve=E2=80=99s RS has no reason to trust his friend= =E2=80=99s AS, let >>> alone his friend=E2=80=99s client. But Steve=E2=80=99s AS is in a posit= ion to know more >>> about the rights policies that Steve wants to apply, and so it can use >>> other technologies like VC=E2=80=99s, DIDs, OIDC, or any number of othe= r things to >>> let things go through. This pattern is exactly why I think we need to t= hink >>> of this in terms of what=E2=80=99s currently called =E2=80=9Cinteractio= n=E2=80=9D at the AS. It=E2=80=99s >>> not really just about how the end-user interacts, it=E2=80=99s about ho= w the AS >>> gathers all the consent and authorization information. I plan to rewrit= e >>> section 4 to that effect. >>> >>> =E2=80=94 Justin >>> >>> On Mar 18, 2021, at 1:58 PM, Stephen Moore wrote: >>> >>> I'm having some concerns with the way you're flipping the trust here >>> Denis. You seem to indicate that the user has trust in the RS and the >>> Client and has to gain the trust of the AS. I feel like the least >>> trustworthy portion of the architecture is the client, because that see= ms >>> like it is the most interchangeable component. >>> Let me explain by way of a use case I have in mind. >>> Let's say I have a smart home. I have devices and data storage and rule >>> engines that are parts of sensors and hubs I buy for the house. I have = a >>> trust in those devices, because it's hardware, if the company is leakin= g >>> data at the hardware level there isn't much I can do other than buy >>> different sensors. >>> In this case, the primary home hub, which is under control of the >>> homeowner, would also be the AS, as well as a policy agent. Authentica= tion >>> in the example is outsourced to whatever auth providers you want. I set= up >>> my home using a google account, a friend is staying and wants access an= d >>> uses FB for auth... whatever. >>> The part that I have little control over is the client my friend uses o= n >>> his phone. Or if I change the client on the tablet in the kitchen to tr= y >>> out something new. These pieces might be single page web apps, they mig= ht >>> be downloaded apps, etc. I do not want them having any additional >>> information than is necessary. If I give my friend permission to unlock= the >>> door, and control the lights because they are feeding my cats while I'm >>> away, the client doesn't need to know anything beyond, I see this home >>> controller, and I have access to these lights and that door lock. >>> >>> In your scenarios, the client is spy by design, and if it is a web app, >>> I don't trust them to not grab my user email address from the AS and pu= t it >>> on a mailing list it sells to some sketchy company, when the only other >>> component that needs that information is the RS. >>> >>> -steve >>> >>> On Thu, Mar 18, 2021 at 1:21 PM Denis wrote: >>> >>>> I have changed the title of this thread, since the original topic has >>>> been closed. >>>> >>>> Justin, you are raising the following question: >>>> >>>> The question I have is =E2=80=94 why does the client need to know what= =E2=80=99s in the >>>> token? >>>> Not if they could possibly know, but why would we expect a client to >>>> know and manage the contents of the token? >>>> >>>> The answer is quite simple: so that the end-user may have confidence >>>> into the architecture. >>>> The seventh of the eleven privacy principles from ISO 29100 (page 14) >>>> is: >>>> >>>> *7. Openness, transparency and notice * >>>> >>>> If the access token is considered as a black box for the end-user, it >>>> cannot be confident about the content of the access token. >>>> Such access token may disclose some private information without the >>>> consent of the end-user. If the access token that it has obtained >>>> does not match with what has been requested, the client will first not >>>> forward the access token to the RS and then will complain about the AS= . >>>> >>>> Denis >>>> >>>> >>>> Hi Justin, >>>> >>>> "The access token is fundamentally a conversational artifact between >>>> the AS and the RS which the client is the carrier of." >>>> That's right, and a good opportunity to distinguish between the need >>>> for token inspection (i.e. a runtime verification, wherever that may b= e) >>>> and the need to negotiate the token format (a discovery). That last >>>> part could very well be an extension, as a way to open up the ecosyste= m >>>> beyond JWTs (which are fine, but come with their own limitations). >>>> >>>> Fabien >>>> >>>> On Thu, Mar 18, 2021 at 5:59 PM Justin Richer wrote: >>>> >>>>> On Mar 18, 2021, at 11:30 AM, Alan Karp wrote: >>>>> >>>>> >>>>> Justin Richer wrote: >>>>> >>>>>> On Mar 18, 2021, at 12:08 AM, Alan Karp wrote: >>>>>> >>>>>> >>>>>> Adrian Gropper wrote: >>>>>> >>>>>>> >>>>>>> Is there an AS involved in the delegation? How and where in the >>>>>>> lifecycle of the protected resource? >>>>>>> >>>>>> >>>>>> If tokens are certificates, the AS need not be involved in subsequen= t >>>>>> delegations. The AS must be involved if the tokens are opaque. >>>>>> >>>>>> >>>>>> Tokens are opaque to the client instance. They are not opaque to the >>>>>> AS. They might be opaque to the RS, but that depends on the kind of >>>>>> relationship the RS and AS have. GNAP should allow different options= here >>>>>> as there are different use cases for that. >>>>>> >>>>> >>>>> Tokens are not opaque to the client in SPKI, zcap-ld, Orie's >>>>> implementation with VCs, or our Zebra Copy work. Why must they be in= GNAP? >>>>> >>>>> >>>>> The existence of the AS is exactly the reason for this. The AS is the >>>>> role that =E2=80=9Cknowledge about the token contents=E2=80=9D has be= en outsourced to in >>>>> the GNAP model (which is based on the OAuth model). >>>>> >>>>> It brings significant simplicity for the client developer. The >>>>> question I have is =E2=80=94 why does the client need to know what=E2= =80=99s in the token? >>>>> Not if they could possibly know, but why would we expect a client to = know >>>>> and manage the contents of the token? >>>>> >>>>> The access token is fundamentally a conversational artifact between >>>>> the AS and the RS which the client is the carrier of. The client is n= ot the >>>>> audience of the token, nor the creator of the token, nor even the man= ager >>>>> of the token and the rights it represents. The client as a simple car= rier >>>>> is a powerful model that allows the security layer to get out of the = way of >>>>> the actual application logic that developers want to do. >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> >>>>> -------------- >>>>> Alan Karp >>>>> >>>>> >>>>> On Thu, Mar 18, 2021 at 4:56 AM Justin Richer wrote= : >>>>> >>>>>> On Mar 18, 2021, at 12:08 AM, Alan Karp wrote: >>>>>> >>>>>> >>>>>> Adrian Gropper wrote: >>>>>> >>>>>>> >>>>>>> Is there an AS involved in the delegation? How and where in the >>>>>>> lifecycle of the protected resource? >>>>>>> >>>>>> >>>>>> If tokens are certificates, the AS need not be involved in subsequen= t >>>>>> delegations. The AS must be involved if the tokens are opaque. >>>>>> >>>>>> >>>>>> Tokens are opaque to the client instance. They are not opaque to the >>>>>> AS. They might be opaque to the RS, but that depends on the kind of >>>>>> relationship the RS and AS have. GNAP should allow different options= here >>>>>> as there are different use cases for that. >>>>>> >>>>>> It would probably be worthwhile to separate the portions of the spec >>>>>> that talk about the RS-AS relationship into its own standalone docum= ent. A >>>>>> similar approach was taken in UMA2 and it was helpful. (Though admit= tedly, >>>>>> as with anything, there are missteps there that we can hopefully lea= rn >>>>>> from.) >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> >>>>>> -------------- >>>>>> Alan Karp >>>>>> >>>>>> >>>>>> On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper < >>>>>> agropper@healthurl.com> wrote: >>>>>> >>>>>>> Sure! >>>>>>> >>>>>>> Is there an AS involved in the delegation? How and where in the >>>>>>> lifecycle of the protected resource? >>>>>>> >>>>>>> Also your use of "the client" seems to imply that either there is >>>>>>> only one client or the client doesn't matter. Which is it? >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>> >>>>>>>> Thanks for that. >>>>>>>> >>>>>>>> Trying to reframe it: >>>>>>>> GNAP is defined as a delegation protocol so the main intent is >>>>>>>> related to a delegate of the RO (i.e. the end user) that wishes to= access >>>>>>>> the RO's protected resources, through the client. >>>>>>>> >>>>>>>> Fabien >>>>>>>> >>>>>>>> Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper < >>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>> >>>>>>>>> At various points in the lifecycle of the protected resource the >>>>>>>>> client at the resource server (RS) might be: >>>>>>>>> >>>>>>>>> - The RO (subject) user agent trading payment for a service >>>>>>>>> promise >>>>>>>>> - The RO user agent using the promise to access the protected >>>>>>>>> resource >>>>>>>>> - A delegate of the RO user agent using a different client >>>>>>>>> >>>>>>>>> What's vague is where the GNAP AS enters the picture as described >>>>>>>>> above. How would you describe it? >>>>>>>>> >>>>>>>>> Adrian >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault < >>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hi Adrian >>>>>>>>>> >>>>>>>>>> I'm still confused why you're saying the terminology is vague. >>>>>>>>>> I get the "power" neutrality is not to your liking, but RQ / use= r >>>>>>>>>> agent is no better in my view. >>>>>>>>>> >>>>>>>>>> Can you elaborate? >>>>>>>>>> >>>>>>>>>> Fabien >>>>>>>>>> >>>>>>>>>> Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper < >>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>> >>>>>>>>>>> I'm sure you're right. Our vague terminology around >>>>>>>>>>> client and end-user leads to my confusion. If GNAP is primarily= about >>>>>>>>>>> delegation then, of course, we should avoid any incentives to i= mpersonate >>>>>>>>>>> or we're wasting our time. This is partly why I'm trying to stu= dy up on >>>>>>>>>>> capabilities and asking for expert advice from folks like Alan = Karp and >>>>>>>>>>> Mark Miller (cc'd) >>>>>>>>>>> >>>>>>>>>>> As best I can understand it, the RS has only two choices, it ca= n: >>>>>>>>>>> >>>>>>>>>>> - store an attribute of the RO a [DID, email address, GNAP >>>>>>>>>>> AS URL], or >>>>>>>>>>> - hand the RO a capability as a sort-of promise and avoid >>>>>>>>>>> making any entries in an ACL or equivalent. >>>>>>>>>>> >>>>>>>>>>> When a token comes back to the RS, it will either be: >>>>>>>>>>> >>>>>>>>>>> - validated according to something associated with the >>>>>>>>>>> stored RO attribute, or >>>>>>>>>>> - signed by the RS itself. >>>>>>>>>>> >>>>>>>>>>> Either way, trust in the client seems moot. >>>>>>>>>>> >>>>>>>>>>> Adrian >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper < >>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker < >>>>>>>>>>>> tobias.looker@mattr.global> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> > A client might not have a DID but it could have a VC as a >>>>>>>>>>>>> certificate of authenticity linked to some audit mechanism. >>>>>>>>>>>>> >>>>>>>>>>>>> To me a VC would come under the assertions umbrella (that is >>>>>>>>>>>>> to say a VC could be one type of valid assertion). The client= may possess >>>>>>>>>>>>> or been presented with a VC that it could include in its requ= est to the AS >>>>>>>>>>>>> as a way to identify the subject and perhaps prove authentica= tion and >>>>>>>>>>>>> authorization. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I do not assume that the client that interacts with the AS to >>>>>>>>>>>> make a request and receive a token is the same as the client t= hat will >>>>>>>>>>>> present the token to the RS. In the US HIPAA use-case, for exa= mple, the >>>>>>>>>>>> root of trust is a contract between the patient-subject and th= e >>>>>>>>>>>> doctor-requesting party but the doctor workflow is expected to= delegate the >>>>>>>>>>>> token to some other end-user that may be using a totally diffe= rent client >>>>>>>>>>>> such as an EHR. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> If the client that gets the token is not same as the client >>>>>>>>>>>> that uses the token, that is a violation of core security prin= ciples as it >>>>>>>>>>>> allows for (and really designs for) impersonation by client so= ftware. I >>>>>>>>>>>> would have no reason to trust client software that would hand = its >>>>>>>>>>>> credentials over to another piece of software, and in fact I s= houldn=E2=80=99t >>>>>>>>>>>> trust it. >>>>>>>>>>>> >>>>>>>>>>>> I think you may be conflating several different kinds of >>>>>>>>>>>> parties under the =E2=80=9Cclient=E2=80=9D umbrella here, thou= gh. It=E2=80=99s entirely possible >>>>>>>>>>>> that one client might call an RS that in turn acts as a client= for >>>>>>>>>>>> something else down stream. But each of those hops is differen= t from the >>>>>>>>>>>> last. >>>>>>>>>>>> >>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> >>>>> >>>> >>>> -- >>>> 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 >> > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000d0ed6905bdd8a11d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Adrian,

    I= 'm really not sure I understand here.=C2=A0

    I get the idea of putting a policy engine in front of= your services to implement ZTA. But I'm not sure I get this way of fra= ming things. It blurs functional roles and actual services, and most import= antly if everything gets its own AS, it also gets by transitivity its RO= 9;/RQ' (and then its AS-RO' etc) and so the complexity becomes stag= gering.=C2=A0
    Why do we need that?=C2=A0

    Fabien=C2=A0

    <= div class=3D"gmail_quote">
    Le ven. 19 = mars 2021 =C3=A0 00:55, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    +1 This aligns = with my healthcare use-case to the extent that Justin can transfer the capa= bility granted by that QR code to Adrian who happens to be nearby Steve'= ;s house.

    I've tried to capture some of this in = my comment to #145=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issue= comment-802388458

    - Adrian
    On Thu, = Mar 18, 2021 at 2:39 PM Justin Richer <jricher@mit.edu> wrote:
    Right, and in the GNAP model this becomes something my client in= stance presents to the AS when I show up. The AS can validate my presentati= on of this item and give my client instance a token to call Steve=E2=80=99s= RS. Or if you wanted to get super fancy Steve=E2=80=99s AS could even chal= lenge my client instance and get a cryptographic response to prove I have t= he thing Steve had me scan. But in both cases it=E2=80=99s part of things t= hat the AS collects in order to create the access token.

    =C2=A0=E2=80=94 Justin

    On = Mar 18, 2021, at 2:26 PM, Stephen Moore <srmoore@gmail.com> wrote:=

    That in my mind works out great... Say I= 9;m logged into my home hub/AS. Justin is over and agrees to cat sit, I pul= l up my client app, and generate a QR code that has maybe The AS URI, the H= omeHub API URL, and the 'special token to present to AS for a real toke= n'. Justin scans that QR code with his home controller app, and BAM, he= 's onboarded as a guest without even logging into my AS or me dealing w= ith his Auth provider.
    -steve

    On Thu, Mar 18, 2021 at 2:08 PM Just= in Richer <jricher@mit.edu> wrote:
    I = think Steve=E2=80=99s use case gives an interesting example of something th= at I believe Adrian=E2=80=99s been talking about as well =E2=80=94 delegati= ng to another person.

    We traditionally think of delegati= on at the AS to mean =E2=80=9Ca different user account logs in to the AS=E2= =80=9D, and it=E2=80=99s important to know that this does in fact work. But= this could just as easily be =E2=80=9CSteve sends his friend an artifact t= o present to the AS to get access=E2=80=9D. This isn=E2=80=99t Steve (or St= eve=E2=80=99s client software) getting and sending an access token, this is= sending some other set of rights credential to his friend, or his friend= =E2=80=99s software. So then Steve=E2=80=99s AS can have policy that says = =E2=80=9Cwhen I see this rights credential, give an access token for the fo= llowing attenuated things, because Steve said so=E2=80=9D. The AS doesn=E2= =80=99t even ever need to know who Steve=E2=80=99s friend is!=C2=A0

    And importantly here, we don=E2=80=99t expect Steve=E2=80= =99s friend to bring their own AS to the party. Steve=E2=80=99s RS has no r= eason to trust his friend=E2=80=99s AS, let alone his friend=E2=80=99s clie= nt. But Steve=E2=80=99s AS is in a position to know more about the rights p= olicies that Steve wants to apply, and so it can use other technologies lik= e VC=E2=80=99s, DIDs, OIDC, or any number of other things to let things go = through. This pattern is exactly why I think we need to think of this in te= rms of what=E2=80=99s currently called =E2=80=9Cinteraction=E2=80=9D at the= AS. It=E2=80=99s not really just about how the end-user interacts, it=E2= =80=99s about how the AS gathers all the consent and authorization informat= ion. I plan to rewrite section 4 to that effect.

    = =C2=A0=E2=80=94 Justin

    On Mar 18= , 2021, at 1:58 PM, Stephen Moore <srmoore@gmail.com> wrote:
    =
    I'm having some concerns with the way you'= ;re flipping the trust here Denis. You seem to indicate that the user has t= rust in the RS and the Client and has to gain the trust of the AS. I feel l= ike the least trustworthy portion of the architecture is the client, becaus= e that seems like it is the most interchangeable component.
    =C2=A0Let m= e explain by way of a use case I have in mind.
    Let's say I ha= ve a smart home. I have devices and data storage and rule engines that are = parts of sensors and hubs I buy for the house. I have a trust in those devi= ces, because it's hardware, if the company is leaking data at the hardw= are level there isn't much I can do other than buy different sensors.
    In this case, the primary home hub, which is under control of the = homeowner, would also be the AS, as well as a policy agent.=C2=A0 Authentic= ation in the example is outsourced to whatever auth providers you want. I s= et up my home using a google account, a friend is staying and wants access = and uses FB for auth... whatever.
    The part that I have little con= trol over is the client my friend uses on his phone. Or if I change the cli= ent on the tablet in the kitchen to try out something new. These pieces=C2= =A0might be single page web apps, they might be downloaded apps, etc. I do = not want them having any additional information than is necessary. If I giv= e my friend permission to unlock the door, and control the lights because t= hey are feeding my cats while I'm away, the client doesn't need to = know anything beyond, I see this home controller, and I have access to thes= e lights and that door lock.

    In your scenarios, th= e client is spy by design, and if it is a web app, I don't trust them t= o not grab my user email address from the=C2=A0AS and put it on a mailing l= ist it sells to some sketchy company,=C2=A0when the only other component=C2= =A0that needs that information is the RS.

    -steve

    On Thu, Mar 18, 2021 at 1:21 PM Denis <denis.ietf@free.fr> wr= ote:
    =20 =20 =20
    I have changed the title of this thread, since the original topic has been closed.

    Justin, you are raising the following question:
    The question I have is =E2=80=94 why does the client need to know what=E2=80=99s in the token?
    Not if they could possibly know, but why would we expect a client to know and manage the contents of the token?
    The answer is quite simple: so that the end-user may have confidence into the architecture.
    The seventh of the eleven privacy principles from ISO 29100 (page 14) is:
    7. Openness, transparency and notice
    If the access token is considered as a black box for the end-user, it cannot be confident about the content of the access token.
    Such access token may disclose some private information without the consent of the end-user. If the access token that it has obtained
    does not match with what has been requested, the client will first not forward the access token to the RS and then will complain about the AS.

    Denis


    =20
    Hi Justin,=C2=A0

    "The access token is fundamentally a conversational artifact between the AS and the RS which the client is the carrier of."
    That's right,=C2=A0and a good=C2=A0opportunity to distingu= ish between the need for token=C2=A0inspection (i.e. a runtime verification, wherever that may be)
    and the need to negotiate the token format (a discovery). That last part could very well be an extension, as a way to open up the ecosystem
    beyond JWTs (which are fine, but come with their own limitations).=C2=A0

    Fabien

    On Thu, Mar 18, 2021 at 5:59 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 11:30 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 12:08 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    A= drian Gropper <agropper@healthurl.co= m> wrote:

    Is there an AS involved in the delegation? How and where in the lifecycle=C2=A0of the protected resource?=C2=A0

    If tokens are certificates, the AS need not be involved in subsequent delegations.=C2=A0 The AS must be involved if the tokens are opaque.=C2=A0

    Tokens are opaque to the client instance. They are not opaque to the AS. They might be opaque to the RS, but that depends on the kind of relationship the RS and AS have. GNAP should allow different options here as there are different use cases for that.

    Tokens are not opaque to the client in SPKI, zcap-ld, Orie's implementation with VCs= , or our Zebra Copy work.=C2=A0 Why must they be in GNAP?

    The existence of the AS is exactly the reason for this. The AS is the role that =E2=80=9Cknowledge about the = token contents=E2=80=9D has been outsourced to in the GNAP model (which is based on the OAuth model).

    It brings significant simplicity for the client developer. The question I have is =E2=80=94 why does the cl= ient need to know what=E2=80=99s in the token? Not if they could possibly know, but why would we expect a client to know and manage the contents of the token?=C2=A0

    The access token is fundamentally a conversational artifact between the AS and the RS which the client is the carrier of. The client is not the audience of the token, nor the creator of the token, nor even the manager of the token and the rights it represents. The client as a simple carrier is a powerful model that allows the security layer to get out of the way of the actual application logic that developers want to do.

    =C2=A0=E2=80=94 Justin


    --------------
    Alan Karp


    On Thu, Mar 18, 2021 at 4:56 AM Justin Richer <jricher@mit.edu&= gt; wrote:
    On Mar 18, 2021, at 12:08 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    A= drian Gropper <agropper@healthurl.co= m> wrote:

    Is there an AS involved in the delegation? How and where in the lifecycle=C2=A0of the protected resource?=C2=A0

    If tokens are certificates, the AS need not be involved in subsequent delegations.=C2=A0 The AS must be involved if the tokens are opaque.=C2=A0

    Tokens are opaque to the client instance. They are not opaque to the AS. They might be opaque to the RS, but that depends on the kind of relationship the RS and AS have. GNAP should allow different options here as there are different use cases for that.

    It would probably be worthwhile to separate the portions of the spec that talk about the RS-AS relationship into its own standalone document. A similar approach was taken in UMA2 and it was helpful. (Though admittedly, as with anything, there are missteps there that we can hopefully learn from.)

    =C2=A0=E2=80=94 Justin


    --------------
    Alan Karp


    O= n Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper <agropper@healt= hurl.com> wrote:
    Sure!=C2=A0

    Is there an AS involved in the delegation? How and where in the lifecycle=C2=A0of the protected resource?=C2=A0

    Also your use of "the client" seems to imply tha= t either there is only one client or the client doesn'= t matter. Which is it?

    Adrian

    On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault <fabien.imbault@= gmail.com> wrote:
    Thanks for that.=C2=A0

    Trying to reframe it:
    GNAP is defined as a delegation protocol so the main intent is related to a delegate of the RO (i.e. the end user) that wishes to access the RO's protected resources, through the client.=C2=A0

    Fabien=C2=A0

    Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper <agropper@healthur= l.com> a =C3=A9crit=C2=A0:
    At various points in the lifecycle=C2=A0of t= he protected resource the client at the resource server (RS) might be:
    • The RO (subject) user agent trading payment for a service promise
    • The RO user agent using the promise to access the protected resource
    • A delegate of the RO user agent using a different client
    What's vague is where the GNAP AS enters the picture as described above. How would you describe it?

    Adrian


    On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Adrian
    <= br>
    I= 'm still confused why you're saying the terminology is vague.=C2=A0
    I get the "power" neutrality is not to your liking, but RQ / user agent is no better in my view.=C2=A0=
    <= br>
    C= an you elaborate?=C2=A0<= /div>
    <= br>
    F= abien=C2=A0

    Le jeu. 18 mars 2021 =C3=A0 00:18= , Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2= =A0:
    = I'm sure you're right. Our vague terminology=C2=A0= around client=C2=A0and=C2=A0end-user leads to my confusion. If GNAP is primarily a= bout delegation=C2=A0t= hen, of course, we should=C2=A0avoid any incentives to impersonate or we're wasting our time. This is partly why I'= m trying to study up on capabilities and asking for expert advice from folks like Alan Karp and Mark Miller (cc'd)

    As best I can understand it, the RS has only two choices, it can:
    • store an attribute of the RO a [DID, email address, GNAP AS URL], or
    • hand the RO a capability as a sort-of promise and avoid making any entries in an ACL or equivalent.
    When a token comes back to the RS, it will either be:
    • validated according to something associated with the stored RO attribute, or
    • signed by the RS itself.
    Either way, trust in the client seems moot.

    Adrian



    On Wed, Mar 17, 2021 at 5:29 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 17, 2021, at 4:55 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    = On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <tobias.looker@mattr.global> wrote:
    <snip>=
    > A client might not have a DID but it could have a VC as a certificate of authenticity linked to some audit mechanism.

    To me a VC would come under the assertions umbrella (that is to say a VC could be one type of valid assertion). The client may possess or been presented with a VC that it could include in its request to the AS as a way to identify the subject and perhaps prove authentication and authorization.

    I do not assume that the client that interacts with the AS to make a request and receive a token is the same as the client that will present the token to the RS. In the US HIPAA use-case, for example, the root of trust is a contract between the patient-subject and the doctor-requesting party but the doctor workflow is expected to delegate the token to some other end-user that may be using a totally different client such as an EHR.


    If the client that gets the token is not same as the client that uses the token, that is a violation of core security principles as it allows for (and really designs for) impersonation by client software. I would have no reason to trust client software that would hand its credentials over to another piece of software, and in fact I shouldn=E2=80=99t trust it.=C2=A0

    I think you may be conflating several different kinds of parties under the =E2=80=9Cclie= nt=E2=80=9D umbrella here, though. It=E2=80= =99s entirely possible that one client might call an RS that in turn acts as a client for something else down stream. But each of those hops is different from the last.

    =C2=A0=E2=80= =94 Justin





    --
    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

    =

    --
    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>
    --000000000000d0ed6905bdd8a11d-- From nobody Thu Mar 18 17:24:19 2021 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 ECE4C3A101E for ; Thu, 18 Mar 2021 17:24:17 -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 QnufNFQGFBp7 for ; Thu, 18 Mar 2021 17:24:15 -0700 (PDT) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 0FD2B3A1019 for ; Thu, 18 Mar 2021 17:24:15 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id k24so2517873pgl.6 for ; Thu, 18 Mar 2021 17:24: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=pLbRaT6jBU3Jlmg0K4BT95f3n2MWt3YyxBbDieGsfhw=; b=B5AIClJor/CMJ3e7dY6jffM4F/foKenGkJWTzTiMnLBLofqD40YgyjAIk+Felvgd5a TxDy9pRj02yFpuUTAL0Mm9C7+I7w4dGqdGq7DmZqE4hYrarFZ1MqHK4KddUsu7NAoegf 525xg2B+bR0mImGUbZKoHROBm2/yvdtGR+XpvdzRBMXWASlcl01yxKk0AEGT1FyCF7m3 l0Rm3/3acuW3fEJFfT6CZIN5yVsBbH14F8guuiutX5cn5sHzJJ17NIkxBF5SMOZ+u0ce +0R4p1T0jtZK9TBMvKk8EYMJVB+q62qTDx+rc36m4pyXJ81IRBOzGgb+aTNrttssrvN5 d2xw== 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=pLbRaT6jBU3Jlmg0K4BT95f3n2MWt3YyxBbDieGsfhw=; b=WCHJT+uipR6QUwfmcZVVvCTMWIAfhP0UFvjaVSg0029nMbt03xkR2ObrjRrYwfs+tP JZMXLSELyVYNGIjTqznnj0pWs06YJe4fbX7Pe48CzLkkya2xPOdK/VFYOopMrlcRxnqK x4IHj0+nwPHyPW4V+gYTbwwzQQCkgqx9ckdWV9vUbJCUie1HXwtVTDePMC8kw1I06o+2 CaAZBrUkOms7Q7nsXPUbDbxxc/CsCWvMWvX61sTPy+YF+BHmpukHC0KE6uHp3ODZXR9c 60MeBKegm3d3QPeZ6w8TP0WBfZHXQ04ZqHkc577NGxeA75a2WWfR5RYFcFIQvs0XUyCI gk/Q== X-Gm-Message-State: AOAM530tnE0Jevx8O0YhE9aSiHp15ekGrNdvVhb5Xm3EgncFJX/Aya/E fCTR6SzCMWGLecogCTHU/5wOzC2MQb7A72GScK4= X-Google-Smtp-Source: ABdhPJxzTLhL8BY6jmVc1zkQNyKYJjoAEwuHjaDqhr9ZwYpFedV6atg67/Gcrp2JrWEp4ktONUk6fxmnONbmoU77EzI= X-Received: by 2002:a62:fc10:0:b029:1ef:141f:609 with SMTP id e16-20020a62fc100000b02901ef141f0609mr6389590pfh.78.1616113452036; Thu, 18 Mar 2021 17:24:12 -0700 (PDT) MIME-Version: 1.0 References: <43447446-4061-49F2-8486-5A196C3C75E2@mit.edu> <37a04505-84ef-aecf-6913-5aad8330c97c@free.fr> In-Reply-To: From: Alejandro Iacobelli Date: Thu, 18 Mar 2021 21:23:59 -0300 Message-ID: To: Fabien Imbault Cc: Adrian Gropper , txauth gnap , Justin Richer , Steve Moore Content-Type: multipart/alternative; boundary="00000000000039b68505bdd8bc32" Archived-At: Subject: Re: [GNAP] Should access tokens be opaque or not for the clients ? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 00:24:18 -0000 --00000000000039b68505bdd8bc32 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The decision about "opaque" vs "sealed but recoverable" or "signed" access_token goes way back on the stateless protocols session management. In my opinion, the software design principle that we must apply here is the "need to know" principle. This means, the less information an attacker could get, the better. One thing that JWS explse is all the context information about a token, so an attacker can get lots of information just with a look. The next discussion will be what ways of generating opaque tokens are there and which must we choose (Encrypted vs CSPRNG based). On Thu, 18 Mar 2021 at 21:17, Fabien Imbault wrote: > Hi Adrian, > > I'm really not sure I understand here. > > I get the idea of putting a policy engine in front of your services to > implement ZTA. But I'm not sure I get this way of framing things. It blur= s > functional roles and actual services, and most importantly if everything > gets its own AS, it also gets by transitivity its RO'/RQ' (and then its > AS-RO' etc) and so the complexity becomes staggering. > Why do we need that? > > Fabien > > Le ven. 19 mars 2021 =C3=A0 00:55, Adrian Gropper a > =C3=A9crit : > >> +1 This aligns with my healthcare use-case to the extent that Justin can >> transfer the capability granted by that QR code to Adrian who happens to= be >> nearby Steve's house. >> >> I've tried to capture some of this in my comment to #145 >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomme= nt-802388458 >> >> - Adrian >> >> On Thu, Mar 18, 2021 at 2:39 PM Justin Richer wrote: >> >>> Right, and in the GNAP model this becomes something my client instance >>> presents to the AS when I show up. The AS can validate my presentation = of >>> this item and give my client instance a token to call Steve=E2=80=99s R= S. Or if you >>> wanted to get super fancy Steve=E2=80=99s AS could even challenge my cl= ient >>> instance and get a cryptographic response to prove I have the thing Ste= ve >>> had me scan. But in both cases it=E2=80=99s part of things that the AS = collects in >>> order to create the access token. >>> >>> =E2=80=94 Justin >>> >>> On Mar 18, 2021, at 2:26 PM, Stephen Moore wrote: >>> >>> That in my mind works out great... Say I'm logged into my home hub/AS. >>> Justin is over and agrees to cat sit, I pull up my client app, and gene= rate >>> a QR code that has maybe The AS URI, the HomeHub API URL, and the 'spec= ial >>> token to present to AS for a real token'. Justin scans that QR code wit= h >>> his home controller app, and BAM, he's onboarded as a guest without eve= n >>> logging into my AS or me dealing with his Auth provider. >>> -steve >>> >>> On Thu, Mar 18, 2021 at 2:08 PM Justin Richer wrote: >>> >>>> I think Steve=E2=80=99s use case gives an interesting example of somet= hing that >>>> I believe Adrian=E2=80=99s been talking about as well =E2=80=94 delega= ting to another >>>> person. >>>> >>>> We traditionally think of delegation at the AS to mean =E2=80=9Ca diff= erent >>>> user account logs in to the AS=E2=80=9D, and it=E2=80=99s important to= know that this does >>>> in fact work. But this could just as easily be =E2=80=9CSteve sends hi= s friend an >>>> artifact to present to the AS to get access=E2=80=9D. This isn=E2=80= =99t Steve (or Steve=E2=80=99s >>>> client software) getting and sending an access token, this is sending = some >>>> other set of rights credential to his friend, or his friend=E2=80=99s = software. So >>>> then Steve=E2=80=99s AS can have policy that says =E2=80=9Cwhen I see = this rights >>>> credential, give an access token for the following attenuated things, >>>> because Steve said so=E2=80=9D. The AS doesn=E2=80=99t even ever need = to know who Steve=E2=80=99s >>>> friend is! >>>> >>>> And importantly here, we don=E2=80=99t expect Steve=E2=80=99s friend t= o bring their own >>>> AS to the party. Steve=E2=80=99s RS has no reason to trust his friend= =E2=80=99s AS, let >>>> alone his friend=E2=80=99s client. But Steve=E2=80=99s AS is in a posi= tion to know more >>>> about the rights policies that Steve wants to apply, and so it can use >>>> other technologies like VC=E2=80=99s, DIDs, OIDC, or any number of oth= er things to >>>> let things go through. This pattern is exactly why I think we need to = think >>>> of this in terms of what=E2=80=99s currently called =E2=80=9Cinteracti= on=E2=80=9D at the AS. It=E2=80=99s >>>> not really just about how the end-user interacts, it=E2=80=99s about h= ow the AS >>>> gathers all the consent and authorization information. I plan to rewri= te >>>> section 4 to that effect. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Mar 18, 2021, at 1:58 PM, Stephen Moore wrote: >>>> >>>> I'm having some concerns with the way you're flipping the trust here >>>> Denis. You seem to indicate that the user has trust in the RS and the >>>> Client and has to gain the trust of the AS. I feel like the least >>>> trustworthy portion of the architecture is the client, because that se= ems >>>> like it is the most interchangeable component. >>>> Let me explain by way of a use case I have in mind. >>>> Let's say I have a smart home. I have devices and data storage and rul= e >>>> engines that are parts of sensors and hubs I buy for the house. I have= a >>>> trust in those devices, because it's hardware, if the company is leaki= ng >>>> data at the hardware level there isn't much I can do other than buy >>>> different sensors. >>>> In this case, the primary home hub, which is under control of the >>>> homeowner, would also be the AS, as well as a policy agent. Authentic= ation >>>> in the example is outsourced to whatever auth providers you want. I se= t up >>>> my home using a google account, a friend is staying and wants access a= nd >>>> uses FB for auth... whatever. >>>> The part that I have little control over is the client my friend uses >>>> on his phone. Or if I change the client on the tablet in the kitchen t= o try >>>> out something new. These pieces might be single page web apps, they mi= ght >>>> be downloaded apps, etc. I do not want them having any additional >>>> information than is necessary. If I give my friend permission to unloc= k the >>>> door, and control the lights because they are feeding my cats while I'= m >>>> away, the client doesn't need to know anything beyond, I see this home >>>> controller, and I have access to these lights and that door lock. >>>> >>>> In your scenarios, the client is spy by design, and if it is a web app= , >>>> I don't trust them to not grab my user email address from the AS and p= ut it >>>> on a mailing list it sells to some sketchy company, when the only othe= r >>>> component that needs that information is the RS. >>>> >>>> -steve >>>> >>>> On Thu, Mar 18, 2021 at 1:21 PM Denis wrote: >>>> >>>>> I have changed the title of this thread, since the original topic has >>>>> been closed. >>>>> >>>>> Justin, you are raising the following question: >>>>> >>>>> The question I have is =E2=80=94 why does the client need to know wha= t=E2=80=99s in >>>>> the token? >>>>> Not if they could possibly know, but why would we expect a client to >>>>> know and manage the contents of the token? >>>>> >>>>> The answer is quite simple: so that the end-user may have confidence >>>>> into the architecture. >>>>> The seventh of the eleven privacy principles from ISO 29100 (page 14) >>>>> is: >>>>> >>>>> *7. Openness, transparency and notice * >>>>> >>>>> If the access token is considered as a black box for the end-user, it >>>>> cannot be confident about the content of the access token. >>>>> Such access token may disclose some private information without the >>>>> consent of the end-user. If the access token that it has obtained >>>>> does not match with what has been requested, the client will first no= t >>>>> forward the access token to the RS and then will complain about the A= S. >>>>> >>>>> Denis >>>>> >>>>> >>>>> Hi Justin, >>>>> >>>>> "The access token is fundamentally a conversational artifact between >>>>> the AS and the RS which the client is the carrier of." >>>>> That's right, and a good opportunity to distinguish between the need >>>>> for token inspection (i.e. a runtime verification, wherever that may = be) >>>>> and the need to negotiate the token format (a discovery). That last >>>>> part could very well be an extension, as a way to open up the ecosyst= em >>>>> beyond JWTs (which are fine, but come with their own limitations). >>>>> >>>>> Fabien >>>>> >>>>> On Thu, Mar 18, 2021 at 5:59 PM Justin Richer wrote= : >>>>> >>>>>> On Mar 18, 2021, at 11:30 AM, Alan Karp wrote: >>>>>> >>>>>> >>>>>> Justin Richer wrote: >>>>>> >>>>>>> On Mar 18, 2021, at 12:08 AM, Alan Karp wrote= : >>>>>>> >>>>>>> >>>>>>> Adrian Gropper wrote: >>>>>>> >>>>>>>> >>>>>>>> Is there an AS involved in the delegation? How and where in the >>>>>>>> lifecycle of the protected resource? >>>>>>>> >>>>>>> >>>>>>> If tokens are certificates, the AS need not be involved in >>>>>>> subsequent delegations. The AS must be involved if the tokens are = opaque. >>>>>>> >>>>>>> >>>>>>> Tokens are opaque to the client instance. They are not opaque to th= e >>>>>>> AS. They might be opaque to the RS, but that depends on the kind of >>>>>>> relationship the RS and AS have. GNAP should allow different option= s here >>>>>>> as there are different use cases for that. >>>>>>> >>>>>> >>>>>> Tokens are not opaque to the client in SPKI, zcap-ld, Orie's >>>>>> implementation with VCs, or our Zebra Copy work. Why must they be i= n GNAP? >>>>>> >>>>>> >>>>>> The existence of the AS is exactly the reason for this. The AS is th= e >>>>>> role that =E2=80=9Cknowledge about the token contents=E2=80=9D has b= een outsourced to in >>>>>> the GNAP model (which is based on the OAuth model). >>>>>> >>>>>> It brings significant simplicity for the client developer. The >>>>>> question I have is =E2=80=94 why does the client need to know what= =E2=80=99s in the token? >>>>>> Not if they could possibly know, but why would we expect a client to= know >>>>>> and manage the contents of the token? >>>>>> >>>>>> The access token is fundamentally a conversational artifact between >>>>>> the AS and the RS which the client is the carrier of. The client is = not the >>>>>> audience of the token, nor the creator of the token, nor even the ma= nager >>>>>> of the token and the rights it represents. The client as a simple ca= rrier >>>>>> is a powerful model that allows the security layer to get out of the= way of >>>>>> the actual application logic that developers want to do. >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> >>>>>> -------------- >>>>>> Alan Karp >>>>>> >>>>>> >>>>>> On Thu, Mar 18, 2021 at 4:56 AM Justin Richer >>>>>> wrote: >>>>>> >>>>>>> On Mar 18, 2021, at 12:08 AM, Alan Karp wrote= : >>>>>>> >>>>>>> >>>>>>> Adrian Gropper wrote: >>>>>>> >>>>>>>> >>>>>>>> Is there an AS involved in the delegation? How and where in the >>>>>>>> lifecycle of the protected resource? >>>>>>>> >>>>>>> >>>>>>> If tokens are certificates, the AS need not be involved in >>>>>>> subsequent delegations. The AS must be involved if the tokens are = opaque. >>>>>>> >>>>>>> >>>>>>> Tokens are opaque to the client instance. They are not opaque to th= e >>>>>>> AS. They might be opaque to the RS, but that depends on the kind of >>>>>>> relationship the RS and AS have. GNAP should allow different option= s here >>>>>>> as there are different use cases for that. >>>>>>> >>>>>>> It would probably be worthwhile to separate the portions of the spe= c >>>>>>> that talk about the RS-AS relationship into its own standalone docu= ment. A >>>>>>> similar approach was taken in UMA2 and it was helpful. (Though admi= ttedly, >>>>>>> as with anything, there are missteps there that we can hopefully le= arn >>>>>>> from.) >>>>>>> >>>>>>> =E2=80=94 Justin >>>>>>> >>>>>>> >>>>>>> -------------- >>>>>>> Alan Karp >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper < >>>>>>> agropper@healthurl.com> wrote: >>>>>>> >>>>>>>> Sure! >>>>>>>> >>>>>>>> Is there an AS involved in the delegation? How and where in the >>>>>>>> lifecycle of the protected resource? >>>>>>>> >>>>>>>> Also your use of "the client" seems to imply that either there is >>>>>>>> only one client or the client doesn't matter. Which is it? >>>>>>>> >>>>>>>> Adrian >>>>>>>> >>>>>>>> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>> >>>>>>>>> Thanks for that. >>>>>>>>> >>>>>>>>> Trying to reframe it: >>>>>>>>> GNAP is defined as a delegation protocol so the main intent is >>>>>>>>> related to a delegate of the RO (i.e. the end user) that wishes t= o access >>>>>>>>> the RO's protected resources, through the client. >>>>>>>>> >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper < >>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>> >>>>>>>>>> At various points in the lifecycle of the protected resource the >>>>>>>>>> client at the resource server (RS) might be: >>>>>>>>>> >>>>>>>>>> - The RO (subject) user agent trading payment for a service >>>>>>>>>> promise >>>>>>>>>> - The RO user agent using the promise to access the protected >>>>>>>>>> resource >>>>>>>>>> - A delegate of the RO user agent using a different client >>>>>>>>>> >>>>>>>>>> What's vague is where the GNAP AS enters the picture as describe= d >>>>>>>>>> above. How would you describe it? >>>>>>>>>> >>>>>>>>>> Adrian >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault < >>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Adrian >>>>>>>>>>> >>>>>>>>>>> I'm still confused why you're saying the terminology is vague. >>>>>>>>>>> I get the "power" neutrality is not to your liking, but RQ / >>>>>>>>>>> user agent is no better in my view. >>>>>>>>>>> >>>>>>>>>>> Can you elaborate? >>>>>>>>>>> >>>>>>>>>>> Fabien >>>>>>>>>>> >>>>>>>>>>> Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper < >>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>> >>>>>>>>>>>> I'm sure you're right. Our vague terminology around >>>>>>>>>>>> client and end-user leads to my confusion. If GNAP is primaril= y about >>>>>>>>>>>> delegation then, of course, we should avoid any incentives to = impersonate >>>>>>>>>>>> or we're wasting our time. This is partly why I'm trying to st= udy up on >>>>>>>>>>>> capabilities and asking for expert advice from folks like Alan= Karp and >>>>>>>>>>>> Mark Miller (cc'd) >>>>>>>>>>>> >>>>>>>>>>>> As best I can understand it, the RS has only two choices, it >>>>>>>>>>>> can: >>>>>>>>>>>> >>>>>>>>>>>> - store an attribute of the RO a [DID, email address, GNAP >>>>>>>>>>>> AS URL], or >>>>>>>>>>>> - hand the RO a capability as a sort-of promise and avoid >>>>>>>>>>>> making any entries in an ACL or equivalent. >>>>>>>>>>>> >>>>>>>>>>>> When a token comes back to the RS, it will either be: >>>>>>>>>>>> >>>>>>>>>>>> - validated according to something associated with the >>>>>>>>>>>> stored RO attribute, or >>>>>>>>>>>> - signed by the RS itself. >>>>>>>>>>>> >>>>>>>>>>>> Either way, trust in the client seems moot. >>>>>>>>>>>> >>>>>>>>>>>> Adrian >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper < >>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker < >>>>>>>>>>>>> tobias.looker@mattr.global> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> > A client might not have a DID but it could have a VC as a >>>>>>>>>>>>>> certificate of authenticity linked to some audit mechanism. >>>>>>>>>>>>>> >>>>>>>>>>>>>> To me a VC would come under the assertions umbrella (that is >>>>>>>>>>>>>> to say a VC could be one type of valid assertion). The clien= t may possess >>>>>>>>>>>>>> or been presented with a VC that it could include in its req= uest to the AS >>>>>>>>>>>>>> as a way to identify the subject and perhaps prove authentic= ation and >>>>>>>>>>>>>> authorization. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I do not assume that the client that interacts with the AS to >>>>>>>>>>>>> make a request and receive a token is the same as the client = that will >>>>>>>>>>>>> present the token to the RS. In the US HIPAA use-case, for ex= ample, the >>>>>>>>>>>>> root of trust is a contract between the patient-subject and t= he >>>>>>>>>>>>> doctor-requesting party but the doctor workflow is expected t= o delegate the >>>>>>>>>>>>> token to some other end-user that may be using a totally diff= erent client >>>>>>>>>>>>> such as an EHR. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> If the client that gets the token is not same as the client >>>>>>>>>>>>> that uses the token, that is a violation of core security pri= nciples as it >>>>>>>>>>>>> allows for (and really designs for) impersonation by client s= oftware. I >>>>>>>>>>>>> would have no reason to trust client software that would hand= its >>>>>>>>>>>>> credentials over to another piece of software, and in fact I = shouldn=E2=80=99t >>>>>>>>>>>>> trust it. >>>>>>>>>>>>> >>>>>>>>>>>>> I think you may be conflating several different kinds of >>>>>>>>>>>>> parties under the =E2=80=9Cclient=E2=80=9D umbrella here, tho= ugh. It=E2=80=99s entirely possible >>>>>>>>>>>>> that one client might call an RS that in turn acts as a clien= t for >>>>>>>>>>>>> something else down stream. But each of those hops is differe= nt from the >>>>>>>>>>>>> last. >>>>>>>>>>>>> >>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> 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 >>> >> -- >> 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 You know nothing Jon Snow! --00000000000039b68505bdd8bc32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    The decision about "opaque" vs= "sealed but recoverable" or "signed" access_token goes= way back on the stateless protocols session management.=C2=A0

    In my opinion, the software design principle that= we must apply here is the "need to know" principle. This means, = the=C2=A0less information an attacker could get, the better. One thing that= JWS explse is all the context information about a token, so an attacker=C2= =A0can get lots of information just with a look.=C2=A0

    =
    The next discussion will be what ways of generating opaque tokens are = there and which must we choose (Encrypted vs CSPRNG based).

    =
    On Thu, 18= Mar 2021 at 21:17, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Adrian,

    I'm really not sure I understand here.= =C2=A0

    I get the idea of p= utting a policy engine in front of your services to implement ZTA. But I= 9;m not sure I get this way of framing things. It blurs functional roles an= d actual services, and most importantly if everything gets its own AS, it a= lso gets by transitivity its RO'/RQ' (and then its AS-RO' etc) = and so the complexity becomes staggering.=C2=A0
    Why = do we need that?=C2=A0

    F= abien=C2=A0

    Le ven. 19 mars 2021 =C3=A0 00:55, Adrian Gropper &l= t;agropper@heal= thurl.com> a =C3=A9crit=C2=A0:
    +1 This aligns with= my healthcare use-case to the extent that Justin can transfer the capabili= ty granted by that QR code to Adrian who happens to be nearby Steve's h= ouse.

    I've tried to capture some of this in my c= omment to #145=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomm= ent-802388458

    - Adrian

    On Thu, Mar = 18, 2021 at 2:39 PM Justin Richer <jricher@mit.edu> wrote:
    =
    Right, and in the GNAP model this becomes something my cli= ent instance presents to the AS when I show up. The AS can validate my pres= entation of this item and give my client instance a token to call Steve=E2= =80=99s RS. Or if you wanted to get super fancy Steve=E2=80=99s AS could ev= en challenge my client instance and get a cryptographic response to prove I= have the thing Steve had me scan. But in both cases it=E2=80=99s part of t= hings that the AS collects in order to create the access token.
    =C2=A0=E2=80=94 Justin

    <= div>On Mar 18, 2021, at 2:26 PM, Stephen Moore <srmoore@gmail.com>= wrote:

    That in my mind works out great... S= ay I'm logged into my home hub/AS. Justin is over and agrees to cat sit= , I pull up my client app, and generate a QR code that has maybe The AS URI= , the HomeHub API URL, and the 'special token to present to AS for a re= al token'. Justin scans that QR code with his home controller app, and = BAM, he's onboarded as a guest without even logging into my AS or me de= aling with his Auth provider.
    -steve

    On Thu, Mar 18, 2021 at 2:08 = PM Justin Richer <jricher@mit.edu> wrote:
    I think Steve=E2=80=99s use case give= s an interesting example of something that I believe Adrian=E2=80=99s been = talking about as well =E2=80=94 delegating to another person.

    We traditionally think of delegation at the AS to mean =E2=80=9Ca dif= ferent user account logs in to the AS=E2=80=9D, and it=E2=80=99s important = to know that this does in fact work. But this could just as easily be =E2= =80=9CSteve sends his friend an artifact to present to the AS to get access= =E2=80=9D. This isn=E2=80=99t Steve (or Steve=E2=80=99s client software) ge= tting and sending an access token, this is sending some other set of rights= credential to his friend, or his friend=E2=80=99s software. So then Steve= =E2=80=99s AS can have policy that says =E2=80=9Cwhen I see this rights cre= dential, give an access token for the following attenuated things, because = Steve said so=E2=80=9D. The AS doesn=E2=80=99t even ever need to know who S= teve=E2=80=99s friend is!=C2=A0

    And importantly he= re, we don=E2=80=99t expect Steve=E2=80=99s friend to bring their own AS to= the party. Steve=E2=80=99s RS has no reason to trust his friend=E2=80=99s = AS, let alone his friend=E2=80=99s client. But Steve=E2=80=99s AS is in a p= osition to know more about the rights policies that Steve wants to apply, a= nd so it can use other technologies like VC=E2=80=99s, DIDs, OIDC, or any n= umber of other things to let things go through. This pattern is exactly why= I think we need to think of this in terms of what=E2=80=99s currently call= ed =E2=80=9Cinteraction=E2=80=9D at the AS. It=E2=80=99s not really just ab= out how the end-user interacts, it=E2=80=99s about how the AS gathers all t= he consent and authorization information. I plan to rewrite section 4 to th= at effect.

    =C2=A0=E2=80=94 Justin

    On Mar 18, 2021, at 1:58 PM, Stephen Moore <<= a href=3D"mailto:srmoore@gmail.com" rel=3D"noreferrer" target=3D"_blank">sr= moore@gmail.com> wrote:

    I'm havin= g some concerns with the way you're flipping the trust here Denis. You = seem to indicate that the user has trust in the RS and the Client and has t= o gain the trust of the AS. I feel like the least trustworthy portion of th= e architecture is the client, because that seems like it is the most interc= hangeable component.
    =C2=A0Let me explain by way of a use case I have i= n mind.
    Let's say I have a smart home. I have devices and dat= a storage and rule engines that are parts of sensors and hubs I buy for the= house. I have a trust in those devices, because it's hardware, if the = company is leaking data at the hardware level there isn't much I can do= other than buy different sensors.
    In this case, the primary home= hub, which is under control of the homeowner, would also be the AS, as wel= l as a policy agent.=C2=A0 Authentication in the example is outsourced to w= hatever auth providers you want. I set up my home using a google account, a= friend is staying and wants access and uses FB for auth... whatever.
    =
    The part that I have little control over is the client my friend uses = on his phone. Or if I change the client on the tablet in the kitchen to try= out something new. These pieces=C2=A0might be single page web apps, they m= ight be downloaded apps, etc. I do not want them having any additional info= rmation than is necessary. If I give my friend permission to unlock the doo= r, and control the lights because they are feeding my cats while I'm aw= ay, the client doesn't need to know anything beyond, I see this home co= ntroller, and I have access to these lights and that door lock.
    <= br>
    In your scenarios, the client is spy by design, and if it is = a web app, I don't trust them to not grab my user email address from th= e=C2=A0AS and put it on a mailing list it sells to some sketchy company,=C2= =A0when the only other component=C2=A0that needs that information is the RS= .

    -steve

    On Thu, Mar 18, 2021 at 1:21 PM Deni= s <denis.ietf@free.fr> wrote:
    =20 =20 =20
    I have changed the title of this thread, since the original topic has been closed.

    Justin, you are raising the following question:
    The question I have is =E2=80=94 why does the client need to know what=E2=80=99s in the token?
    Not if they could possibly know, but why would we expect a client to know and manage the contents of the token?
    The answer is quite simple: so that the end-user may have confidence into the architecture.
    The seventh of the eleven privacy principles from ISO 29100 (page 14) is:
    7. Openness, transparency and notice
    If the access token is considered as a black box for the end-user, it cannot be confident about the content of the access token.
    Such access token may disclose some private information without the consent of the end-user. If the access token that it has obtained
    does not match with what has been requested, the client will first not forward the access token to the RS and then will complain about the AS.

    Denis


    =20
    Hi Justin,=C2=A0

    "The access token is fundamentally a conversational artifact between the AS and the RS which the client is the carrier of."
    That's right,=C2=A0and a good=C2=A0opportunity to distingu= ish between the need for token=C2=A0inspection (i.e. a runtime verification, wherever that may be)
    and the need to negotiate the token format (a discovery). That last part could very well be an extension, as a way to open up the ecosystem
    beyond JWTs (which are fine, but come with their own limitations).=C2=A0

    Fabien

    On Thu, Mar 18, 2021 at 5:59 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 11:30 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 12:08 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    A= drian Gropper <agropper@healthurl.co= m> wrote:

    Is there an AS involved in the delegation? How and where in the lifecycle=C2=A0of the protected resource?=C2=A0

    If tokens are certificates, the AS need not be involved in subsequent delegations.=C2=A0 The AS must be involved if the tokens are opaque.=C2=A0

    Tokens are opaque to the client instance. They are not opaque to the AS. They might be opaque to the RS, but that depends on the kind of relationship the RS and AS have. GNAP should allow different options here as there are different use cases for that.

    Tokens are not opaque to the client in SPKI, zcap-ld, Orie's implementation with VCs= , or our Zebra Copy work.=C2=A0 Why must they be in GNAP?

    The existence of the AS is exactly the reason for this. The AS is the role that =E2=80=9Cknowledge about the = token contents=E2=80=9D has been outsourced to in the GNAP model (which is based on the OAuth model).

    It brings significant simplicity for the client developer. The question I have is =E2=80=94 why does the cl= ient need to know what=E2=80=99s in the token? Not if they could possibly know, but why would we expect a client to know and manage the contents of the token?=C2=A0

    The access token is fundamentally a conversational artifact between the AS and the RS which the client is the carrier of. The client is not the audience of the token, nor the creator of the token, nor even the manager of the token and the rights it represents. The client as a simple carrier is a powerful model that allows the security layer to get out of the way of the actual application logic that developers want to do.

    =C2=A0=E2=80=94 Justin


    --------------
    Alan Karp


    On Thu, Mar 18, 2021 at 4:56 AM Justin Richer <jricher@mit.edu&= gt; wrote:
    On Mar 18, 2021, at 12:08 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    A= drian Gropper <agropper@healthurl.co= m> wrote:

    Is there an AS involved in the delegation? How and where in the lifecycle=C2=A0of the protected resource?=C2=A0

    If tokens are certificates, the AS need not be involved in subsequent delegations.=C2=A0 The AS must be involved if the tokens are opaque.=C2=A0

    Tokens are opaque to the client instance. They are not opaque to the AS. They might be opaque to the RS, but that depends on the kind of relationship the RS and AS have. GNAP should allow different options here as there are different use cases for that.

    It would probably be worthwhile to separate the portions of the spec that talk about the RS-AS relationship into its own standalone document. A similar approach was taken in UMA2 and it was helpful. (Though admittedly, as with anything, there are missteps there that we can hopefully learn from.)

    =C2=A0=E2=80=94 Justin


    --------------
    Alan Karp


    O= n Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper <agropper@healt= hurl.com> wrote:
    Sure!=C2=A0

    Is there an AS involved in the delegation? How and where in the lifecycle=C2=A0of the protected resource?=C2=A0

    Also your use of "the client" seems to imply tha= t either there is only one client or the client doesn'= t matter. Which is it?

    Adrian

    On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault <fabien.imbault@= gmail.com> wrote:
    Thanks for that.=C2=A0

    Trying to reframe it:
    GNAP is defined as a delegation protocol so the main intent is related to a delegate of the RO (i.e. the end user) that wishes to access the RO's protected resources, through the client.=C2=A0

    Fabien=C2=A0

    Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper <agropper@healthur= l.com> a =C3=A9crit=C2=A0:
    At various points in the lifecycle=C2=A0of t= he protected resource the client at the resource server (RS) might be:
    • The RO (subject) user agent trading payment for a service promise
    • The RO user agent using the promise to access the protected resource
    • A delegate of the RO user agent using a different client
    What's vague is where the GNAP AS enters the picture as described above. How would you describe it?

    Adrian


    On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Adrian
    <= br>
    I= 'm still confused why you're saying the terminology is vague.=C2=A0
    I get the "power" neutrality is not to your liking, but RQ / user agent is no better in my view.=C2=A0=
    <= br>
    C= an you elaborate?=C2=A0<= /div>
    <= br>
    F= abien=C2=A0

    Le jeu. 18 mars 2021 =C3=A0 00:18= , Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2= =A0:
    = I'm sure you're right. Our vague terminology=C2=A0= around client=C2=A0and=C2=A0end-user leads to my confusion. If GNAP is primarily a= bout delegation=C2=A0t= hen, of course, we should=C2=A0avoid any incentives to impersonate or we're wasting our time. This is partly why I'= m trying to study up on capabilities and asking for expert advice from folks like Alan Karp and Mark Miller (cc'd)

    As best I can understand it, the RS has only two choices, it can:
    • store an attribute of the RO a [DID, email address, GNAP AS URL], or
    • hand the RO a capability as a sort-of promise and avoid making any entries in an ACL or equivalent.
    When a token comes back to the RS, it will either be:
    • validated according to something associated with the stored RO attribute, or
    • signed by the RS itself.
    Either way, trust in the client seems moot.

    Adrian



    On Wed, Mar 17, 2021 at 5:29 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 17, 2021, at 4:55 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    = On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <tobias.looker@mattr.global> wrote:
    <snip>=
    > A client might not have a DID but it could have a VC as a certificate of authenticity linked to some audit mechanism.

    To me a VC would come under the assertions umbrella (that is to say a VC could be one type of valid assertion). The client may possess or been presented with a VC that it could include in its request to the AS as a way to identify the subject and perhaps prove authentication and authorization.

    I do not assume that the client that interacts with the AS to make a request and receive a token is the same as the client that will present the token to the RS. In the US HIPAA use-case, for example, the root of trust is a contract between the patient-subject and the doctor-requesting party but the doctor workflow is expected to delegate the token to some other end-user that may be using a totally different client such as an EHR.


    If the client that gets the token is not same as the client that uses the token, that is a violation of core security principles as it allows for (and really designs for) impersonation by client software. I would have no reason to trust client software that would hand its credentials over to another piece of software, and in fact I shouldn=E2=80=99t trust it.=C2=A0

    I think you may be conflating several different kinds of parties under the =E2=80=9Cclie= nt=E2=80=9D umbrella here, though. It=E2=80= =99s entirely possible that one client might call an RS that in turn acts as a client for something else down stream. But each of those hops is different from the last.

    =C2=A0=E2=80= =94 Justin





    --
    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

    =

    --
    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


    --
    You know nothing Jon Snow!
    --00000000000039b68505bdd8bc32-- From nobody Thu Mar 18 18:04:12 2021 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 B9BE93A1165 for ; Thu, 18 Mar 2021 18:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 qiL7NZNPTjlk for ; Thu, 18 Mar 2021 18:04:04 -0700 (PDT) Received: from mail-vs1-f41.google.com (mail-vs1-f41.google.com [209.85.217.41]) (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 336E83A114D for ; Thu, 18 Mar 2021 18:04:04 -0700 (PDT) Received: by mail-vs1-f41.google.com with SMTP id s25so2600275vsa.1 for ; Thu, 18 Mar 2021 18:04:04 -0700 (PDT) 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=8fVsPDCtbE3F+WR9Xj38dDNkW7iUWeGfA9X81LzOjI0=; b=SbuV6wQM8ystvFW3DLAc3qTaLDzh4vUGWiNTXEsySw9fiEYDju2lvdS5eU+qYkOKAr u8ftSgsm0eOEP5yVVFti1Z56uwxye+x+rHhA4hEBFfWY70fTwmAY5KtbqiAiR4OwFEVy zp1yI0Fc1mt1K5ZxqC9JRS+MCNONQmAiopo+DscWYu6z2W9JNyfYI52af/vzCYnzqFWr Bna5r0qWImGdoz1BBZpbfOcsCpOvyRzM3WLBnDwQjJLzspcmYo6zyxMnF3Dq/VyLbLcC dwY6u1KWmgBiglv69SDf8zaVl57e/7jcsmazByCk977fbuNaR6cmKKzndHN0kElOaARo AnZQ== X-Gm-Message-State: AOAM532Bx0NWIOziDt6GsMNRjTeDeREidoByKKSt7s1wgnQSa6dwN2TN DfY6vCMdF5DXxxoKMcK6/aV2Ulg1+9sD3zr0k/qz75KUYNg= X-Google-Smtp-Source: ABdhPJy7bS6S5NdpzR6ZuYhvvvcRFA7MfYMjlFMtSs98MD/Q4qU6fS9pkOK3ME2ZKvQdpzHfQNPtvDYivLa2Z2vmS9Y= X-Received: by 2002:a05:6102:24a:: with SMTP id a10mr1323769vsq.39.1616115843013; Thu, 18 Mar 2021 18:04:03 -0700 (PDT) MIME-Version: 1.0 References: <43447446-4061-49F2-8486-5A196C3C75E2@mit.edu> <37a04505-84ef-aecf-6913-5aad8330c97c@free.fr> In-Reply-To: From: Adrian Gropper Date: Thu, 18 Mar 2021 21:03:51 -0400 Message-ID: To: Alejandro Iacobelli Cc: Fabien Imbault , txauth gnap , Justin Richer , Steve Moore Content-Type: multipart/alternative; boundary="000000000000bd202405bdd94abc" Archived-At: Subject: Re: [GNAP] Should access tokens be opaque or not for the clients ? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 01:04:11 -0000 --000000000000bd202405bdd94abc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm not a security person. I do, however, have a lot of experience with regulatory practices as relates to safety in medical devices and business. I see the security struggles of today as being an over-reliance on institutional trust and a lack of effective audit and individual accountability. I see great promise in moving advanced crypto to the individual through DIDs and VCs and then using these identity-based components in protocols like GNAP that are directly in the security, audit, and accountability role. DIDs, VCs, and capabilities, to me, are just data models. I know that's a very vague and philosophical answer to give to architects like the folks in this group. Sorry. >From this perspective, GNAP is where we get to introduce individual accountability, resilience against single points of failure, practical audit mechanisms, and the benefit of a decade of blockchain-driven cryptography advances. I don't see GNAP as complicated, but what do I know? Adrian On Thu, Mar 18, 2021 at 8:24 PM Alejandro Iacobelli < aiacobelli.sec@gmail.com> wrote: > The decision about "opaque" vs "sealed but recoverable" or "signed" > access_token goes way back on the stateless protocols session management. > > In my opinion, the software design principle that we must apply here is > the "need to know" principle. This means, the less information an attacke= r > could get, the better. One thing that JWS explse is all the context > information about a token, so an attacker can get lots of information jus= t > with a look. > > The next discussion will be what ways of generating opaque tokens are > there and which must we choose (Encrypted vs CSPRNG based). > > On Thu, 18 Mar 2021 at 21:17, Fabien Imbault > wrote: > >> Hi Adrian, >> >> I'm really not sure I understand here. >> >> I get the idea of putting a policy engine in front of your services to >> implement ZTA. But I'm not sure I get this way of framing things. It blu= rs >> functional roles and actual services, and most importantly if everything >> gets its own AS, it also gets by transitivity its RO'/RQ' (and then its >> AS-RO' etc) and so the complexity becomes staggering. >> Why do we need that? >> >> Fabien >> >> Le ven. 19 mars 2021 =C3=A0 00:55, Adrian Gropper a >> =C3=A9crit : >> >>> +1 This aligns with my healthcare use-case to the extent that Justin ca= n >>> transfer the capability granted by that QR code to Adrian who happens t= o be >>> nearby Steve's house. >>> >>> I've tried to capture some of this in my comment to #145 >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomm= ent-802388458 >>> >>> - Adrian >>> >>> On Thu, Mar 18, 2021 at 2:39 PM Justin Richer wrote: >>> >>>> Right, and in the GNAP model this becomes something my client instance >>>> presents to the AS when I show up. The AS can validate my presentation= of >>>> this item and give my client instance a token to call Steve=E2=80=99s = RS. Or if you >>>> wanted to get super fancy Steve=E2=80=99s AS could even challenge my c= lient >>>> instance and get a cryptographic response to prove I have the thing St= eve >>>> had me scan. But in both cases it=E2=80=99s part of things that the AS= collects in >>>> order to create the access token. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Mar 18, 2021, at 2:26 PM, Stephen Moore wrote: >>>> >>>> That in my mind works out great... Say I'm logged into my home hub/AS. >>>> Justin is over and agrees to cat sit, I pull up my client app, and gen= erate >>>> a QR code that has maybe The AS URI, the HomeHub API URL, and the 'spe= cial >>>> token to present to AS for a real token'. Justin scans that QR code wi= th >>>> his home controller app, and BAM, he's onboarded as a guest without ev= en >>>> logging into my AS or me dealing with his Auth provider. >>>> -steve >>>> >>>> On Thu, Mar 18, 2021 at 2:08 PM Justin Richer wrote: >>>> >>>>> I think Steve=E2=80=99s use case gives an interesting example of some= thing >>>>> that I believe Adrian=E2=80=99s been talking about as well =E2=80=94 = delegating to another >>>>> person. >>>>> >>>>> We traditionally think of delegation at the AS to mean =E2=80=9Ca dif= ferent >>>>> user account logs in to the AS=E2=80=9D, and it=E2=80=99s important t= o know that this does >>>>> in fact work. But this could just as easily be =E2=80=9CSteve sends h= is friend an >>>>> artifact to present to the AS to get access=E2=80=9D. This isn=E2=80= =99t Steve (or Steve=E2=80=99s >>>>> client software) getting and sending an access token, this is sending= some >>>>> other set of rights credential to his friend, or his friend=E2=80=99s= software. So >>>>> then Steve=E2=80=99s AS can have policy that says =E2=80=9Cwhen I see= this rights >>>>> credential, give an access token for the following attenuated things, >>>>> because Steve said so=E2=80=9D. The AS doesn=E2=80=99t even ever need= to know who Steve=E2=80=99s >>>>> friend is! >>>>> >>>>> And importantly here, we don=E2=80=99t expect Steve=E2=80=99s friend = to bring their >>>>> own AS to the party. Steve=E2=80=99s RS has no reason to trust his fr= iend=E2=80=99s AS, let >>>>> alone his friend=E2=80=99s client. But Steve=E2=80=99s AS is in a pos= ition to know more >>>>> about the rights policies that Steve wants to apply, and so it can us= e >>>>> other technologies like VC=E2=80=99s, DIDs, OIDC, or any number of ot= her things to >>>>> let things go through. This pattern is exactly why I think we need to= think >>>>> of this in terms of what=E2=80=99s currently called =E2=80=9Cinteract= ion=E2=80=9D at the AS. It=E2=80=99s >>>>> not really just about how the end-user interacts, it=E2=80=99s about = how the AS >>>>> gathers all the consent and authorization information. I plan to rewr= ite >>>>> section 4 to that effect. >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Mar 18, 2021, at 1:58 PM, Stephen Moore wrote: >>>>> >>>>> I'm having some concerns with the way you're flipping the trust here >>>>> Denis. You seem to indicate that the user has trust in the RS and the >>>>> Client and has to gain the trust of the AS. I feel like the least >>>>> trustworthy portion of the architecture is the client, because that s= eems >>>>> like it is the most interchangeable component. >>>>> Let me explain by way of a use case I have in mind. >>>>> Let's say I have a smart home. I have devices and data storage and >>>>> rule engines that are parts of sensors and hubs I buy for the house. = I have >>>>> a trust in those devices, because it's hardware, if the company is le= aking >>>>> data at the hardware level there isn't much I can do other than buy >>>>> different sensors. >>>>> In this case, the primary home hub, which is under control of the >>>>> homeowner, would also be the AS, as well as a policy agent. Authenti= cation >>>>> in the example is outsourced to whatever auth providers you want. I s= et up >>>>> my home using a google account, a friend is staying and wants access = and >>>>> uses FB for auth... whatever. >>>>> The part that I have little control over is the client my friend uses >>>>> on his phone. Or if I change the client on the tablet in the kitchen = to try >>>>> out something new. These pieces might be single page web apps, they m= ight >>>>> be downloaded apps, etc. I do not want them having any additional >>>>> information than is necessary. If I give my friend permission to unlo= ck the >>>>> door, and control the lights because they are feeding my cats while I= 'm >>>>> away, the client doesn't need to know anything beyond, I see this hom= e >>>>> controller, and I have access to these lights and that door lock. >>>>> >>>>> In your scenarios, the client is spy by design, and if it is a web >>>>> app, I don't trust them to not grab my user email address from the AS= and >>>>> put it on a mailing list it sells to some sketchy company, when the o= nly >>>>> other component that needs that information is the RS. >>>>> >>>>> -steve >>>>> >>>>> On Thu, Mar 18, 2021 at 1:21 PM Denis wrote: >>>>> >>>>>> I have changed the title of this thread, since the original topic ha= s >>>>>> been closed. >>>>>> >>>>>> Justin, you are raising the following question: >>>>>> >>>>>> The question I have is =E2=80=94 why does the client need to know wh= at=E2=80=99s in >>>>>> the token? >>>>>> Not if they could possibly know, but why would we expect a client to >>>>>> know and manage the contents of the token? >>>>>> >>>>>> The answer is quite simple: so that the end-user may have confidence >>>>>> into the architecture. >>>>>> The seventh of the eleven privacy principles from ISO 29100 (page 14= ) >>>>>> is: >>>>>> >>>>>> *7. Openness, transparency and notice * >>>>>> >>>>>> If the access token is considered as a black box for the end-user, i= t >>>>>> cannot be confident about the content of the access token. >>>>>> Such access token may disclose some private information without the >>>>>> consent of the end-user. If the access token that it has obtained >>>>>> does not match with what has been requested, the client will first >>>>>> not forward the access token to the RS and then will complain about = the AS. >>>>>> >>>>>> Denis >>>>>> >>>>>> >>>>>> Hi Justin, >>>>>> >>>>>> "The access token is fundamentally a conversational artifact between >>>>>> the AS and the RS which the client is the carrier of." >>>>>> That's right, and a good opportunity to distinguish between the need >>>>>> for token inspection (i.e. a runtime verification, wherever that may= be) >>>>>> and the need to negotiate the token format (a discovery). That last >>>>>> part could very well be an extension, as a way to open up the ecosys= tem >>>>>> beyond JWTs (which are fine, but come with their own limitations). >>>>>> >>>>>> Fabien >>>>>> >>>>>> On Thu, Mar 18, 2021 at 5:59 PM Justin Richer >>>>>> wrote: >>>>>> >>>>>>> On Mar 18, 2021, at 11:30 AM, Alan Karp wrote= : >>>>>>> >>>>>>> >>>>>>> Justin Richer wrote: >>>>>>> >>>>>>>> On Mar 18, 2021, at 12:08 AM, Alan Karp >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> Adrian Gropper wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> Is there an AS involved in the delegation? How and where in the >>>>>>>>> lifecycle of the protected resource? >>>>>>>>> >>>>>>>> >>>>>>>> If tokens are certificates, the AS need not be involved in >>>>>>>> subsequent delegations. The AS must be involved if the tokens are= opaque. >>>>>>>> >>>>>>>> >>>>>>>> Tokens are opaque to the client instance. They are not opaque to >>>>>>>> the AS. They might be opaque to the RS, but that depends on the ki= nd of >>>>>>>> relationship the RS and AS have. GNAP should allow different optio= ns here >>>>>>>> as there are different use cases for that. >>>>>>>> >>>>>>> >>>>>>> Tokens are not opaque to the client in SPKI, zcap-ld, Orie's >>>>>>> implementation with VCs, or our Zebra Copy work. Why must they be = in GNAP? >>>>>>> >>>>>>> >>>>>>> The existence of the AS is exactly the reason for this. The AS is >>>>>>> the role that =E2=80=9Cknowledge about the token contents=E2=80=9D = has been outsourced to >>>>>>> in the GNAP model (which is based on the OAuth model). >>>>>>> >>>>>>> It brings significant simplicity for the client developer. The >>>>>>> question I have is =E2=80=94 why does the client need to know what= =E2=80=99s in the token? >>>>>>> Not if they could possibly know, but why would we expect a client t= o know >>>>>>> and manage the contents of the token? >>>>>>> >>>>>>> The access token is fundamentally a conversational artifact between >>>>>>> the AS and the RS which the client is the carrier of. The client is= not the >>>>>>> audience of the token, nor the creator of the token, nor even the m= anager >>>>>>> of the token and the rights it represents. The client as a simple c= arrier >>>>>>> is a powerful model that allows the security layer to get out of th= e way of >>>>>>> the actual application logic that developers want to do. >>>>>>> >>>>>>> =E2=80=94 Justin >>>>>>> >>>>>>> >>>>>>> -------------- >>>>>>> Alan Karp >>>>>>> >>>>>>> >>>>>>> On Thu, Mar 18, 2021 at 4:56 AM Justin Richer >>>>>>> wrote: >>>>>>> >>>>>>>> On Mar 18, 2021, at 12:08 AM, Alan Karp >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> Adrian Gropper wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> Is there an AS involved in the delegation? How and where in the >>>>>>>>> lifecycle of the protected resource? >>>>>>>>> >>>>>>>> >>>>>>>> If tokens are certificates, the AS need not be involved in >>>>>>>> subsequent delegations. The AS must be involved if the tokens are= opaque. >>>>>>>> >>>>>>>> >>>>>>>> Tokens are opaque to the client instance. They are not opaque to >>>>>>>> the AS. They might be opaque to the RS, but that depends on the ki= nd of >>>>>>>> relationship the RS and AS have. GNAP should allow different optio= ns here >>>>>>>> as there are different use cases for that. >>>>>>>> >>>>>>>> It would probably be worthwhile to separate the portions of the >>>>>>>> spec that talk about the RS-AS relationship into its own standalon= e >>>>>>>> document. A similar approach was taken in UMA2 and it was helpful.= (Though >>>>>>>> admittedly, as with anything, there are missteps there that we can >>>>>>>> hopefully learn from.) >>>>>>>> >>>>>>>> =E2=80=94 Justin >>>>>>>> >>>>>>>> >>>>>>>> -------------- >>>>>>>> Alan Karp >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper < >>>>>>>> agropper@healthurl.com> wrote: >>>>>>>> >>>>>>>>> Sure! >>>>>>>>> >>>>>>>>> Is there an AS involved in the delegation? How and where in the >>>>>>>>> lifecycle of the protected resource? >>>>>>>>> >>>>>>>>> Also your use of "the client" seems to imply that either there is >>>>>>>>> only one client or the client doesn't matter. Which is it? >>>>>>>>> >>>>>>>>> Adrian >>>>>>>>> >>>>>>>>> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault < >>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Thanks for that. >>>>>>>>>> >>>>>>>>>> Trying to reframe it: >>>>>>>>>> GNAP is defined as a delegation protocol so the main intent is >>>>>>>>>> related to a delegate of the RO (i.e. the end user) that wishes = to access >>>>>>>>>> the RO's protected resources, through the client. >>>>>>>>>> >>>>>>>>>> Fabien >>>>>>>>>> >>>>>>>>>> Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper < >>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>> >>>>>>>>>>> At various points in the lifecycle of the protected resource th= e >>>>>>>>>>> client at the resource server (RS) might be: >>>>>>>>>>> >>>>>>>>>>> - The RO (subject) user agent trading payment for a service >>>>>>>>>>> promise >>>>>>>>>>> - The RO user agent using the promise to access the >>>>>>>>>>> protected resource >>>>>>>>>>> - A delegate of the RO user agent using a different client >>>>>>>>>>> >>>>>>>>>>> What's vague is where the GNAP AS enters the picture as >>>>>>>>>>> described above. How would you describe it? >>>>>>>>>>> >>>>>>>>>>> Adrian >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault < >>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Adrian >>>>>>>>>>>> >>>>>>>>>>>> I'm still confused why you're saying the terminology is vague. >>>>>>>>>>>> I get the "power" neutrality is not to your liking, but RQ / >>>>>>>>>>>> user agent is no better in my view. >>>>>>>>>>>> >>>>>>>>>>>> Can you elaborate? >>>>>>>>>>>> >>>>>>>>>>>> Fabien >>>>>>>>>>>> >>>>>>>>>>>> Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper < >>>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>>> >>>>>>>>>>>>> I'm sure you're right. Our vague terminology around >>>>>>>>>>>>> client and end-user leads to my confusion. If GNAP is primari= ly about >>>>>>>>>>>>> delegation then, of course, we should avoid any incentives to= impersonate >>>>>>>>>>>>> or we're wasting our time. This is partly why I'm trying to s= tudy up on >>>>>>>>>>>>> capabilities and asking for expert advice from folks like Ala= n Karp and >>>>>>>>>>>>> Mark Miller (cc'd) >>>>>>>>>>>>> >>>>>>>>>>>>> As best I can understand it, the RS has only two choices, it >>>>>>>>>>>>> can: >>>>>>>>>>>>> >>>>>>>>>>>>> - store an attribute of the RO a [DID, email address, GNAP >>>>>>>>>>>>> AS URL], or >>>>>>>>>>>>> - hand the RO a capability as a sort-of promise and avoid >>>>>>>>>>>>> making any entries in an ACL or equivalent. >>>>>>>>>>>>> >>>>>>>>>>>>> When a token comes back to the RS, it will either be: >>>>>>>>>>>>> >>>>>>>>>>>>> - validated according to something associated with the >>>>>>>>>>>>> stored RO attribute, or >>>>>>>>>>>>> - signed by the RS itself. >>>>>>>>>>>>> >>>>>>>>>>>>> Either way, trust in the client seems moot. >>>>>>>>>>>>> >>>>>>>>>>>>> Adrian >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper < >>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker < >>>>>>>>>>>>>> tobias.looker@mattr.global> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > A client might not have a DID but it could have a VC as a >>>>>>>>>>>>>>> certificate of authenticity linked to some audit mechanism. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> To me a VC would come under the assertions umbrella (that i= s >>>>>>>>>>>>>>> to say a VC could be one type of valid assertion). The clie= nt may possess >>>>>>>>>>>>>>> or been presented with a VC that it could include in its re= quest to the AS >>>>>>>>>>>>>>> as a way to identify the subject and perhaps prove authenti= cation and >>>>>>>>>>>>>>> authorization. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I do not assume that the client that interacts with the AS t= o >>>>>>>>>>>>>> make a request and receive a token is the same as the client= that will >>>>>>>>>>>>>> present the token to the RS. In the US HIPAA use-case, for e= xample, the >>>>>>>>>>>>>> root of trust is a contract between the patient-subject and = the >>>>>>>>>>>>>> doctor-requesting party but the doctor workflow is expected = to delegate the >>>>>>>>>>>>>> token to some other end-user that may be using a totally dif= ferent client >>>>>>>>>>>>>> such as an EHR. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> If the client that gets the token is not same as the client >>>>>>>>>>>>>> that uses the token, that is a violation of core security pr= inciples as it >>>>>>>>>>>>>> allows for (and really designs for) impersonation by client = software. I >>>>>>>>>>>>>> would have no reason to trust client software that would han= d its >>>>>>>>>>>>>> credentials over to another piece of software, and in fact I= shouldn=E2=80=99t >>>>>>>>>>>>>> trust it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think you may be conflating several different kinds of >>>>>>>>>>>>>> parties under the =E2=80=9Cclient=E2=80=9D umbrella here, th= ough. It=E2=80=99s entirely possible >>>>>>>>>>>>>> that one client might call an RS that in turn acts as a clie= nt for >>>>>>>>>>>>>> something else down stream. But each of those hops is differ= ent from the >>>>>>>>>>>>>> last. >>>>>>>>>>>>>> >>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> 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 >>>> >>> -- >>> 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 >> > > > -- > You know nothing Jon Snow! > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000bd202405bdd94abc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I'm not a security person. I do,=C2=A0however, have a = lot of experience with regulatory=C2=A0practices as relates to safety in me= dical devices and business. I see the security struggles of today as being = an over-reliance=C2=A0on institutional trust and a lack of effective audit = and individual accountability. I see great promise in moving advanced crypt= o to the individual through DIDs and VCs and then using these identity-base= d components in protocols like GNAP that are directly in the security, audi= t, and accountability role. DIDs, VCs, and capabilities, to me, are just da= ta models.

    I know that's a very vague and philosophi= cal answer to give to architects like the folks in this group. Sorry.
    =

    From this perspective, GNAP is where we get to introduc= e individual=C2=A0accountability, resilience against single points of failu= re, practical audit mechanisms, and the benefit of a decade of blockchain-d= riven cryptography=C2=A0advances. I don't see GNAP as complicated, but = what do I know?

    Adrian

    On Thu, Mar 18, 2021= at 8:24 PM Alejandro Iacobelli <aiacobelli.sec@gmail.com> wrote:
    The decision about "opaque" vs &qu= ot;sealed but recoverable" or "signed" access_token goes way= back on the stateless protocols session management.=C2=A0

    In my opinion, the software design principle that we = must apply here is the "need to know" principle. This means, the= =C2=A0less information an attacker could get, the better. One thing that JW= S explse is all the context information about a token, so an attacker=C2=A0= can get lots of information just with a look.=C2=A0

    The next discussion will be what ways of generating opaque tokens are the= re and which must we choose (Encrypted vs CSPRNG based).

    On Thu, 18 Ma= r 2021 at 21:17, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Adrian,

    I'm really not sure I understand here.=C2=A0

    I get the idea of putting a policy en= gine in front of your services to implement ZTA. But I'm not sure I get= this way of framing things. It blurs functional roles and actual services,= and most importantly if everything gets its own AS, it also gets by transi= tivity its RO'/RQ' (and then its AS-RO' etc) and so the complex= ity becomes staggering.=C2=A0
    Why do we need that?= =C2=A0

    Fabien=C2=A0

    Le ven. 19 mars 2021 =C3=A0 00:55, Adrian Gropper <agropper@healthurl.com>= ; a =C3=A9crit=C2=A0:
    +1 This aligns with my healthcare use-case to the extent that Just= in can transfer the capability granted by that QR code to Adrian who happen= s to be nearby Steve's house.

    I've tried to = capture some of this in my comment to #145=C2=A0https://github.com/ietf-wg-gnap/gnap-core= -protocol/issues/145#issuecomment-802388458

    - = Adrian

    On Thu, Mar 18, 2021 at 2:39 PM Justin Richer <jricher@mi= t.edu> wrote:
    Right, and in the GNAP = model this becomes something my client instance presents to the AS when I s= how up. The AS can validate my presentation of this item and give my client= instance a token to call Steve=E2=80=99s RS. Or if you wanted to get super= fancy Steve=E2=80=99s AS could even challenge my client instance and get a= cryptographic response to prove I have the thing Steve had me scan. But in= both cases it=E2=80=99s part of things that the AS collects in order to cr= eate the access token.

    =C2=A0=E2=80=94 Justin

    On Mar 18, 2021, at 2:26 PM, Stephen = Moore <srmoore@gmail.com> wrote:

    Th= at in my mind works out great... Say I'm logged into my home hub/AS. Ju= stin is over and agrees to cat sit, I pull up my client app, and generate a= QR code that has maybe The AS URI, the HomeHub API URL, and the 'speci= al token to present to AS for a real token'. Justin scans that QR code = with his home controller app, and BAM, he's onboarded as a guest withou= t even logging into my AS or me dealing with his Auth provider.
    -steve<= /div>

    On Thu, Mar 18, 2021 at 2:08 PM Justin Richer <jricher@mit.edu>= wrote:
    I think Steve=E2=80=99s use case giv= es an interesting example of something that I believe Adrian=E2=80=99s been= talking about as well =E2=80=94 delegating to another person.

    We traditionally think of delegation at the AS to mean =E2=80=9Ca di= fferent user account logs in to the AS=E2=80=9D, and it=E2=80=99s important= to know that this does in fact work. But this could just as easily be =E2= =80=9CSteve sends his friend an artifact to present to the AS to get access= =E2=80=9D. This isn=E2=80=99t Steve (or Steve=E2=80=99s client software) ge= tting and sending an access token, this is sending some other set of rights= credential to his friend, or his friend=E2=80=99s software. So then Steve= =E2=80=99s AS can have policy that says =E2=80=9Cwhen I see this rights cre= dential, give an access token for the following attenuated things, because = Steve said so=E2=80=9D. The AS doesn=E2=80=99t even ever need to know who S= teve=E2=80=99s friend is!=C2=A0

    And importantly he= re, we don=E2=80=99t expect Steve=E2=80=99s friend to bring their own AS to= the party. Steve=E2=80=99s RS has no reason to trust his friend=E2=80=99s = AS, let alone his friend=E2=80=99s client. But Steve=E2=80=99s AS is in a p= osition to know more about the rights policies that Steve wants to apply, a= nd so it can use other technologies like VC=E2=80=99s, DIDs, OIDC, or any n= umber of other things to let things go through. This pattern is exactly why= I think we need to think of this in terms of what=E2=80=99s currently call= ed =E2=80=9Cinteraction=E2=80=9D at the AS. It=E2=80=99s not really just ab= out how the end-user interacts, it=E2=80=99s about how the AS gathers all t= he consent and authorization information. I plan to rewrite section 4 to th= at effect.

    =C2=A0=E2=80=94 Justin

    On Mar 18, 2021, at 1:58 PM, Stephen Moore <<= a href=3D"mailto:srmoore@gmail.com" rel=3D"noreferrer" target=3D"_blank">sr= moore@gmail.com> wrote:

    I'm havin= g some concerns with the way you're flipping the trust here Denis. You = seem to indicate that the user has trust in the RS and the Client and has t= o gain the trust of the AS. I feel like the least trustworthy portion of th= e architecture is the client, because that seems like it is the most interc= hangeable component.
    =C2=A0Let me explain by way of a use case I have i= n mind.
    Let's say I have a smart home. I have devices and dat= a storage and rule engines that are parts of sensors and hubs I buy for the= house. I have a trust in those devices, because it's hardware, if the = company is leaking data at the hardware level there isn't much I can do= other than buy different sensors.
    In this case, the primary home= hub, which is under control of the homeowner, would also be the AS, as wel= l as a policy agent.=C2=A0 Authentication in the example is outsourced to w= hatever auth providers you want. I set up my home using a google account, a= friend is staying and wants access and uses FB for auth... whatever.
    =
    The part that I have little control over is the client my friend uses = on his phone. Or if I change the client on the tablet in the kitchen to try= out something new. These pieces=C2=A0might be single page web apps, they m= ight be downloaded apps, etc. I do not want them having any additional info= rmation than is necessary. If I give my friend permission to unlock the doo= r, and control the lights because they are feeding my cats while I'm aw= ay, the client doesn't need to know anything beyond, I see this home co= ntroller, and I have access to these lights and that door lock.
    <= br>
    In your scenarios, the client is spy by design, and if it is = a web app, I don't trust them to not grab my user email address from th= e=C2=A0AS and put it on a mailing list it sells to some sketchy company,=C2= =A0when the only other component=C2=A0that needs that information is the RS= .

    -steve

    On Thu, Mar 18, 2021 at 1:21 PM Deni= s <denis.ietf@free.fr> wrote:
    =20 =20 =20
    I have changed the title of this thread, since the original topic has been closed.

    Justin, you are raising the following question:
    The question I have is =E2=80=94 why does the client need to know what=E2=80=99s in the token?
    Not if they could possibly know, but why would we expect a client to know and manage the contents of the token?
    The answer is quite simple: so that the end-user may have confidence into the architecture.
    The seventh of the eleven privacy principles from ISO 29100 (page 14) is:
    7. Openness, transparency and notice
    If the access token is considered as a black box for the end-user, it cannot be confident about the content of the access token.
    Such access token may disclose some private information without the consent of the end-user. If the access token that it has obtained
    does not match with what has been requested, the client will first not forward the access token to the RS and then will complain about the AS.

    Denis


    =20
    Hi Justin,=C2=A0

    "The access token is fundamentally a conversational artifact between the AS and the RS which the client is the carrier of."
    That's right,=C2=A0and a good=C2=A0opportunity to distingu= ish between the need for token=C2=A0inspection (i.e. a runtime verification, wherever that may be)
    and the need to negotiate the token format (a discovery). That last part could very well be an extension, as a way to open up the ecosystem
    beyond JWTs (which are fine, but come with their own limitations).=C2=A0

    Fabien

    On Thu, Mar 18, 2021 at 5:59 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 11:30 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 12:08 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    A= drian Gropper <agropper@healthurl.co= m> wrote:

    Is there an AS involved in the delegation? How and where in the lifecycle=C2=A0of the protected resource?=C2=A0

    If tokens are certificates, the AS need not be involved in subsequent delegations.=C2=A0 The AS must be involved if the tokens are opaque.=C2=A0

    Tokens are opaque to the client instance. They are not opaque to the AS. They might be opaque to the RS, but that depends on the kind of relationship the RS and AS have. GNAP should allow different options here as there are different use cases for that.

    Tokens are not opaque to the client in SPKI, zcap-ld, Orie's implementation with VCs= , or our Zebra Copy work.=C2=A0 Why must they be in GNAP?

    The existence of the AS is exactly the reason for this. The AS is the role that =E2=80=9Cknowledge about the = token contents=E2=80=9D has been outsourced to in the GNAP model (which is based on the OAuth model).

    It brings significant simplicity for the client developer. The question I have is =E2=80=94 why does the cl= ient need to know what=E2=80=99s in the token? Not if they could possibly know, but why would we expect a client to know and manage the contents of the token?=C2=A0

    The access token is fundamentally a conversational artifact between the AS and the RS which the client is the carrier of. The client is not the audience of the token, nor the creator of the token, nor even the manager of the token and the rights it represents. The client as a simple carrier is a powerful model that allows the security layer to get out of the way of the actual application logic that developers want to do.

    =C2=A0=E2=80=94 Justin


    --------------
    Alan Karp


    On Thu, Mar 18, 2021 at 4:56 AM Justin Richer <jricher@mit.edu&= gt; wrote:
    On Mar 18, 2021, at 12:08 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    A= drian Gropper <agropper@healthurl.co= m> wrote:

    Is there an AS involved in the delegation? How and where in the lifecycle=C2=A0of the protected resource?=C2=A0

    If tokens are certificates, the AS need not be involved in subsequent delegations.=C2=A0 The AS must be involved if the tokens are opaque.=C2=A0

    Tokens are opaque to the client instance. They are not opaque to the AS. They might be opaque to the RS, but that depends on the kind of relationship the RS and AS have. GNAP should allow different options here as there are different use cases for that.

    It would probably be worthwhile to separate the portions of the spec that talk about the RS-AS relationship into its own standalone document. A similar approach was taken in UMA2 and it was helpful. (Though admittedly, as with anything, there are missteps there that we can hopefully learn from.)

    =C2=A0=E2=80=94 Justin


    --------------
    Alan Karp


    O= n Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper <agropper@healt= hurl.com> wrote:
    Sure!=C2=A0

    Is there an AS involved in the delegation? How and where in the lifecycle=C2=A0of the protected resource?=C2=A0

    Also your use of "the client" seems to imply tha= t either there is only one client or the client doesn'= t matter. Which is it?

    Adrian

    On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault <fabien.imbault@= gmail.com> wrote:
    Thanks for that.=C2=A0

    Trying to reframe it:
    GNAP is defined as a delegation protocol so the main intent is related to a delegate of the RO (i.e. the end user) that wishes to access the RO's protected resources, through the client.=C2=A0

    Fabien=C2=A0

    Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper <agropper@healthur= l.com> a =C3=A9crit=C2=A0:
    At various points in the lifecycle=C2=A0of t= he protected resource the client at the resource server (RS) might be:
    • The RO (subject) user agent trading payment for a service promise
    • The RO user agent using the promise to access the protected resource
    • A delegate of the RO user agent using a different client
    What's vague is where the GNAP AS enters the picture as described above. How would you describe it?

    Adrian


    On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Adrian
    <= br>
    I= 'm still confused why you're saying the terminology is vague.=C2=A0
    I get the "power" neutrality is not to your liking, but RQ / user agent is no better in my view.=C2=A0=
    <= br>
    C= an you elaborate?=C2=A0<= /div>
    <= br>
    F= abien=C2=A0

    Le jeu. 18 mars 2021 =C3=A0 00:18= , Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2= =A0:
    = I'm sure you're right. Our vague terminology=C2=A0= around client=C2=A0and=C2=A0end-user leads to my confusion. If GNAP is primarily a= bout delegation=C2=A0t= hen, of course, we should=C2=A0avoid any incentives to impersonate or we're wasting our time. This is partly why I'= m trying to study up on capabilities and asking for expert advice from folks like Alan Karp and Mark Miller (cc'd)

    As best I can understand it, the RS has only two choices, it can:
    • store an attribute of the RO a [DID, email address, GNAP AS URL], or
    • hand the RO a capability as a sort-of promise and avoid making any entries in an ACL or equivalent.
    When a token comes back to the RS, it will either be:
    • validated according to something associated with the stored RO attribute, or
    • signed by the RS itself.
    Either way, trust in the client seems moot.

    Adrian



    On Wed, Mar 17, 2021 at 5:29 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 17, 2021, at 4:55 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    = On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <tobias.looker@mattr.global> wrote:
    <snip>=
    > A client might not have a DID but it could have a VC as a certificate of authenticity linked to some audit mechanism.

    To me a VC would come under the assertions umbrella (that is to say a VC could be one type of valid assertion). The client may possess or been presented with a VC that it could include in its request to the AS as a way to identify the subject and perhaps prove authentication and authorization.

    I do not assume that the client that interacts with the AS to make a request and receive a token is the same as the client that will present the token to the RS. In the US HIPAA use-case, for example, the root of trust is a contract between the patient-subject and the doctor-requesting party but the doctor workflow is expected to delegate the token to some other end-user that may be using a totally different client such as an EHR.


    If the client that gets the token is not same as the client that uses the token, that is a violation of core security principles as it allows for (and really designs for) impersonation by client software. I would have no reason to trust client software that would hand its credentials over to another piece of software, and in fact I shouldn=E2=80=99t trust it.=C2=A0

    I think you may be conflating several different kinds of parties under the =E2=80=9Cclie= nt=E2=80=9D umbrella here, though. It=E2=80= =99s entirely possible that one client might call an RS that in turn acts as a client for something else down stream. But each of those hops is different from the last.

    =C2=A0=E2=80= =94 Justin





    --
    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

    =

    --
    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


    --
    You know nothing Jon Snow!
    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --000000000000bd202405bdd94abc-- From nobody Fri Mar 19 06:04:23 2021 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 673A13A1341 for ; Fri, 19 Mar 2021 06:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 xvflukqgBiVh for ; Fri, 19 Mar 2021 06:04:18 -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 76E843A133F for ; Fri, 19 Mar 2021 06:04:18 -0700 (PDT) Received: from [192.168.1.22] (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 12JD4BdA010449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Mar 2021 09:04:11 -0400 From: Justin Richer Message-Id: <3FE214B6-CF96-472D-853B-C7C5AC7A73AE@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_786F3F87-FC37-4053-99E3-F8D9386445DF" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 19 Mar 2021 09:04:10 -0400 In-Reply-To: Cc: Fabien Imbault , Adrian Gropper , txauth gnap , Steve Moore To: Alejandro Iacobelli References: <43447446-4061-49F2-8486-5A196C3C75E2@mit.edu> <37a04505-84ef-aecf-6913-5aad8330c97c@free.fr> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Should access tokens be opaque or not for the clients ? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 13:04:23 -0000 --Apple-Mail=_786F3F87-FC37-4053-99E3-F8D9386445DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 One of the best ways to protect information in the token is to not put = it in the token in the first place. This is why a some highly-sensitive = application profiles and deployments us randomized values as tokens. The = RS has a way to dereference it, which is important. For downstream delegation, like one micro service calling another, = we=E2=80=99re no longer talking about the client knowing the access = token, we=E2=80=99re talking about an RS at the first step. This is = where non-opaque, or encrypted, or other kinds of recoverable data = structures come into play more directly.=20 To Adrian=E2=80=99s point, sharing the QR code should be up to the = AS=E2=80=99s policy. If Steve gives me a bearer artifact that isn=E2=80=99= t attached to anything that identifies me, then it=E2=80=99s easy for me = to share because the artifact is the identity and proof all in one. The = strawman description below sounds like that. But it=E2=80=99s important = in this design that the AS can also require me to log in with a specific = account, plus present a token, plus type in a secret code, plus present = a hardware key that completes a circuit in the right way (seems like = something Steve would build, tbh), etc. But all of these aren=E2=80=99t = a client talking to a resource, they=E2=80=99re the end-user presenting = things to the AS so that the AS can make a policy decision to issue a = token and allow access.=20 =E2=80=94 Justin > On Mar 18, 2021, at 8:23 PM, Alejandro Iacobelli = wrote: >=20 > The decision about "opaque" vs "sealed but recoverable" or "signed" = access_token goes way back on the stateless protocols session = management.=20 >=20 > In my opinion, the software design principle that we must apply here = is the "need to know" principle. This means, the less information an = attacker could get, the better. One thing that JWS explse is all the = context information about a token, so an attacker can get lots of = information just with a look.=20 >=20 > The next discussion will be what ways of generating opaque tokens are = there and which must we choose (Encrypted vs CSPRNG based). >=20 > On Thu, 18 Mar 2021 at 21:17, Fabien Imbault > wrote: > Hi Adrian, >=20 > I'm really not sure I understand here.=20 >=20 > I get the idea of putting a policy engine in front of your services to = implement ZTA. But I'm not sure I get this way of framing things. It = blurs functional roles and actual services, and most importantly if = everything gets its own AS, it also gets by transitivity its RO'/RQ' = (and then its AS-RO' etc) and so the complexity becomes staggering.=20 > Why do we need that?=20 >=20 > Fabien=20 >=20 > Le ven. 19 mars 2021 =C3=A0 00:55, Adrian Gropper = > a =C3=A9crit : > +1 This aligns with my healthcare use-case to the extent that Justin = can transfer the capability granted by that QR code to Adrian who = happens to be nearby Steve's house. >=20 > I've tried to capture some of this in my comment to #145 = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment= -802388458 = >=20 > - Adrian >=20 > On Thu, Mar 18, 2021 at 2:39 PM Justin Richer > wrote: > Right, and in the GNAP model this becomes something my client instance = presents to the AS when I show up. The AS can validate my presentation = of this item and give my client instance a token to call Steve=E2=80=99s = RS. Or if you wanted to get super fancy Steve=E2=80=99s AS could even = challenge my client instance and get a cryptographic response to prove I = have the thing Steve had me scan. But in both cases it=E2=80=99s part of = things that the AS collects in order to create the access token. >=20 > =E2=80=94 Justin >=20 >> On Mar 18, 2021, at 2:26 PM, Stephen Moore > wrote: >>=20 >> That in my mind works out great... Say I'm logged into my home = hub/AS. Justin is over and agrees to cat sit, I pull up my client app, = and generate a QR code that has maybe The AS URI, the HomeHub API URL, = and the 'special token to present to AS for a real token'. Justin scans = that QR code with his home controller app, and BAM, he's onboarded as a = guest without even logging into my AS or me dealing with his Auth = provider. >> -steve >>=20 >> On Thu, Mar 18, 2021 at 2:08 PM Justin Richer > wrote: >> I think Steve=E2=80=99s use case gives an interesting example of = something that I believe Adrian=E2=80=99s been talking about as well =E2=80= =94 delegating to another person. >>=20 >> We traditionally think of delegation at the AS to mean =E2=80=9Ca = different user account logs in to the AS=E2=80=9D, and it=E2=80=99s = important to know that this does in fact work. But this could just as = easily be =E2=80=9CSteve sends his friend an artifact to present to the = AS to get access=E2=80=9D. This isn=E2=80=99t Steve (or Steve=E2=80=99s = client software) getting and sending an access token, this is sending = some other set of rights credential to his friend, or his friend=E2=80=99s= software. So then Steve=E2=80=99s AS can have policy that says =E2=80=9Cw= hen I see this rights credential, give an access token for the following = attenuated things, because Steve said so=E2=80=9D. The AS doesn=E2=80=99t = even ever need to know who Steve=E2=80=99s friend is!=20 >>=20 >> And importantly here, we don=E2=80=99t expect Steve=E2=80=99s friend = to bring their own AS to the party. Steve=E2=80=99s RS has no reason to = trust his friend=E2=80=99s AS, let alone his friend=E2=80=99s client. = But Steve=E2=80=99s AS is in a position to know more about the rights = policies that Steve wants to apply, and so it can use other technologies = like VC=E2=80=99s, DIDs, OIDC, or any number of other things to let = things go through. This pattern is exactly why I think we need to think = of this in terms of what=E2=80=99s currently called =E2=80=9Cinteraction=E2= =80=9D at the AS. It=E2=80=99s not really just about how the end-user = interacts, it=E2=80=99s about how the AS gathers all the consent and = authorization information. I plan to rewrite section 4 to that effect. >>=20 >> =E2=80=94 Justin >>=20 >>> On Mar 18, 2021, at 1:58 PM, Stephen Moore > wrote: >>>=20 >>> I'm having some concerns with the way you're flipping the trust here = Denis. You seem to indicate that the user has trust in the RS and the = Client and has to gain the trust of the AS. I feel like the least = trustworthy portion of the architecture is the client, because that = seems like it is the most interchangeable component. >>> Let me explain by way of a use case I have in mind. >>> Let's say I have a smart home. I have devices and data storage and = rule engines that are parts of sensors and hubs I buy for the house. I = have a trust in those devices, because it's hardware, if the company is = leaking data at the hardware level there isn't much I can do other than = buy different sensors. >>> In this case, the primary home hub, which is under control of the = homeowner, would also be the AS, as well as a policy agent. = Authentication in the example is outsourced to whatever auth providers = you want. I set up my home using a google account, a friend is staying = and wants access and uses FB for auth... whatever. >>> The part that I have little control over is the client my friend = uses on his phone. Or if I change the client on the tablet in the = kitchen to try out something new. These pieces might be single page web = apps, they might be downloaded apps, etc. I do not want them having any = additional information than is necessary. If I give my friend permission = to unlock the door, and control the lights because they are feeding my = cats while I'm away, the client doesn't need to know anything beyond, I = see this home controller, and I have access to these lights and that = door lock. >>>=20 >>> In your scenarios, the client is spy by design, and if it is a web = app, I don't trust them to not grab my user email address from the AS = and put it on a mailing list it sells to some sketchy company, when the = only other component that needs that information is the RS. >>>=20 >>> -steve >>>=20 >>> On Thu, Mar 18, 2021 at 1:21 PM Denis > wrote: >>> I have changed the title of this thread, since the original topic = has been closed.=20 >>>=20 >>> Justin, you are raising the following question: >>> The question I have is =E2=80=94 why does the client need to know = what=E2=80=99s in the token?=20 >>> Not if they could possibly know, but why would we expect a client to = know and manage the contents of the token?=20 >>> The answer is quite simple: so that the end-user may have confidence = into the architecture.=20 >>> The seventh of the eleven privacy principles from ISO 29100 (page = 14) is: >>> 7. Openness, transparency and notice=20 >>> If the access token is considered as a black box for the end-user, = it cannot be confident about the content of the access token. >>> Such access token may disclose some private information without the = consent of the end-user. If the access token that it has obtained=20 >>> does not match with what has been requested, the client will first = not forward the access token to the RS and then will complain about the = AS. >>>=20 >>> Denis >>>=20 >>>=20 >>>> Hi Justin,=20 >>>>=20 >>>> "The access token is fundamentally a conversational artifact = between the AS and the RS which the client is the carrier of." >>>> That's right, and a good opportunity to distinguish between the = need for token inspection (i.e. a runtime verification, wherever that = may be)=20 >>>> and the need to negotiate the token format (a discovery). That last = part could very well be an extension, as a way to open up the ecosystem=20= >>>> beyond JWTs (which are fine, but come with their own limitations).=20= >>>>=20 >>>> Fabien >>>>=20 >>>> On Thu, Mar 18, 2021 at 5:59 PM Justin Richer > wrote: >>>> On Mar 18, 2021, at 11:30 AM, Alan Karp > wrote: >>>>>=20 >>>>> Justin Richer > wrote: >>>>> On Mar 18, 2021, at 12:08 AM, Alan Karp > wrote: >>>>>>=20 >>>>>> Adrian Gropper > wrote: >>>>>>=20 >>>>>> Is there an AS involved in the delegation? How and where in the = lifecycle of the protected resource?=20 >>>>>>=20 >>>>>> If tokens are certificates, the AS need not be involved in = subsequent delegations. The AS must be involved if the tokens are = opaque.=20 >>>>>=20 >>>>> Tokens are opaque to the client instance. They are not opaque to = the AS. They might be opaque to the RS, but that depends on the kind of = relationship the RS and AS have. GNAP should allow different options = here as there are different use cases for that. >>>>>=20 >>>>> Tokens are not opaque to the client in SPKI, zcap-ld, Orie's = implementation with VCs, or our Zebra Copy work. Why must they be in = GNAP? >>>>=20 >>>> The existence of the AS is exactly the reason for this. The AS is = the role that =E2=80=9Cknowledge about the token contents=E2=80=9D has = been outsourced to in the GNAP model (which is based on the OAuth = model). >>>>=20 >>>> It brings significant simplicity for the client developer. The = question I have is =E2=80=94 why does the client need to know what=E2=80=99= s in the token? Not if they could possibly know, but why would we expect = a client to know and manage the contents of the token?=20 >>>>=20 >>>> The access token is fundamentally a conversational artifact between = the AS and the RS which the client is the carrier of. The client is not = the audience of the token, nor the creator of the token, nor even the = manager of the token and the rights it represents. The client as a = simple carrier is a powerful model that allows the security layer to get = out of the way of the actual application logic that developers want to = do. >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>>=20 >>>>> -------------- >>>>> Alan Karp >>>>>=20 >>>>>=20 >>>>> On Thu, Mar 18, 2021 at 4:56 AM Justin Richer > wrote: >>>>> On Mar 18, 2021, at 12:08 AM, Alan Karp > wrote: >>>>>>=20 >>>>>> Adrian Gropper > wrote: >>>>>>=20 >>>>>> Is there an AS involved in the delegation? How and where in the = lifecycle of the protected resource?=20 >>>>>>=20 >>>>>> If tokens are certificates, the AS need not be involved in = subsequent delegations. The AS must be involved if the tokens are = opaque.=20 >>>>>=20 >>>>> Tokens are opaque to the client instance. They are not opaque to = the AS. They might be opaque to the RS, but that depends on the kind of = relationship the RS and AS have. GNAP should allow different options = here as there are different use cases for that. >>>>>=20 >>>>> It would probably be worthwhile to separate the portions of the = spec that talk about the RS-AS relationship into its own standalone = document. A similar approach was taken in UMA2 and it was helpful. = (Though admittedly, as with anything, there are missteps there that we = can hopefully learn from.) >>>>>=20 >>>>> =E2=80=94 Justin >>>>>=20 >>>>>>=20 >>>>>> -------------- >>>>>> Alan Karp >>>>>>=20 >>>>>>=20 >>>>>> On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper = > wrote: >>>>>> Sure!=20 >>>>>>=20 >>>>>> Is there an AS involved in the delegation? How and where in the = lifecycle of the protected resource?=20 >>>>>>=20 >>>>>> Also your use of "the client" seems to imply that either there is = only one client or the client doesn't matter. Which is it? >>>>>>=20 >>>>>> Adrian >>>>>>=20 >>>>>> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault = > wrote: >>>>>> Thanks for that.=20 >>>>>>=20 >>>>>> Trying to reframe it: >>>>>> GNAP is defined as a delegation protocol so the main intent is = related to a delegate of the RO (i.e. the end user) that wishes to = access the RO's protected resources, through the client.=20 >>>>>>=20 >>>>>> Fabien=20 >>>>>>=20 >>>>>> Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper = > a =C3=A9crit : >>>>>> At various points in the lifecycle of the protected resource the = client at the resource server (RS) might be: >>>>>> The RO (subject) user agent trading payment for a service promise >>>>>> The RO user agent using the promise to access the protected = resource >>>>>> A delegate of the RO user agent using a different client >>>>>> What's vague is where the GNAP AS enters the picture as described = above. How would you describe it? >>>>>>=20 >>>>>> Adrian >>>>>>=20 >>>>>>=20 >>>>>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault = > wrote: >>>>>> Hi Adrian >>>>>>=20 >>>>>> I'm still confused why you're saying the terminology is vague.=20 >>>>>> I get the "power" neutrality is not to your liking, but RQ / user = agent is no better in my view.=20 >>>>>>=20 >>>>>> Can you elaborate?=20 >>>>>>=20 >>>>>> Fabien=20 >>>>>>=20 >>>>>> Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper = > a =C3=A9crit : >>>>>> I'm sure you're right. Our vague terminology around client and = end-user leads to my confusion. If GNAP is primarily about delegation = then, of course, we should avoid any incentives to impersonate or we're = wasting our time. This is partly why I'm trying to study up on = capabilities and asking for expert advice from folks like Alan Karp and = Mark Miller (cc'd) >>>>>>=20 >>>>>> As best I can understand it, the RS has only two choices, it can: >>>>>> store an attribute of the RO a [DID, email address, GNAP AS URL], = or >>>>>> hand the RO a capability as a sort-of promise and avoid making = any entries in an ACL or equivalent. >>>>>> When a token comes back to the RS, it will either be: >>>>>> validated according to something associated with the stored RO = attribute, or >>>>>> signed by the RS itself. >>>>>> Either way, trust in the client seems moot. >>>>>>=20 >>>>>> Adrian >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer > wrote: >>>>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper = > wrote: >>>>>>>=20 >>>>>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker = > wrote: >>>>>>> >>>>>>> > A client might not have a DID but it could have a VC as a = certificate of authenticity linked to some audit mechanism. >>>>>>>=20 >>>>>>> To me a VC would come under the assertions umbrella (that is to = say a VC could be one type of valid assertion). The client may possess = or been presented with a VC that it could include in its request to the = AS as a way to identify the subject and perhaps prove authentication and = authorization. >>>>>>>=20 >>>>>>> I do not assume that the client that interacts with the AS to = make a request and receive a token is the same as the client that will = present the token to the RS. In the US HIPAA use-case, for example, the = root of trust is a contract between the patient-subject and the = doctor-requesting party but the doctor workflow is expected to delegate = the token to some other end-user that may be using a totally different = client such as an EHR. >>>>>>>=20 >>>>>>=20 >>>>>> If the client that gets the token is not same as the client that = uses the token, that is a violation of core security principles as it = allows for (and really designs for) impersonation by client software. I = would have no reason to trust client software that would hand its = credentials over to another piece of software, and in fact I shouldn=E2=80= =99t trust it.=20 >>>>>>=20 >>>>>> I think you may be conflating several different kinds of parties = under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80=99s = entirely possible that one client might call an RS that in turn acts as = a client for something else down stream. But each of those hops is = different from the last. >>>>>>=20 >>>>>> =E2=80=94 Justin >>>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>> --=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 = >>=20 >=20 > --=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 = > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = >=20 >=20 > --=20 > You know nothing Jon Snow! --Apple-Mail=_786F3F87-FC37-4053-99E3-F8D9386445DF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 One = of the best ways to protect information in the token is to not put it in = the token in the first place. This is why a some highly-sensitive = application profiles and deployments us randomized values as tokens. The = RS has a way to dereference it, which is important.

    For downstream delegation, like one = micro service calling another, we=E2=80=99re no longer talking about the = client knowing the access token, we=E2=80=99re talking about an RS at = the first step. This is where non-opaque, or encrypted, or other kinds = of recoverable data structures come into play more = directly. 

    To Adrian=E2=80=99s point, sharing the QR code should be up = to the AS=E2=80=99s policy. If Steve gives me a bearer artifact that = isn=E2=80=99t attached to anything that identifies me, then it=E2=80=99s = easy for me to share because the artifact is the identity and proof all = in one. The strawman description below sounds like that. But it=E2=80=99s = important in this design that the AS can also require me to log in with = a specific account, plus present a token, plus type in a secret code, = plus present a hardware key that completes a circuit in the right way = (seems like something Steve would build, tbh), etc. But all of these = aren=E2=80=99t a client talking to a resource, they=E2=80=99re the = end-user  presenting things to the AS so that the AS can make a = policy decision to issue a token and allow access. 

     =E2=80=94 = Justin

    On Mar 18, 2021, at 8:23 PM, Alejandro = Iacobelli <aiacobelli.sec@gmail.com> wrote:

    The = decision about "opaque" vs "sealed but recoverable" or "signed" = access_token goes way back on the stateless protocols session = management. 

    In my opinion, the software design = principle that we must apply here is the "need to know" principle. This = means, the less information an attacker could get, the better. One = thing that JWS explse is all the context information about a token, so = an attacker can get lots of information just with a = look. 

    The = next discussion will be what ways of generating opaque tokens are there = and which must we choose (Encrypted vs CSPRNG based).

    On Thu, 18 Mar 2021 at 21:17, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi = Adrian,

    I'm really not sure I understand here. 

    I get the idea of putting a policy engine in = front of your services to implement ZTA. But I'm not sure I get this way = of framing things. It blurs functional roles and actual services, and = most importantly if everything gets its own AS, it also gets by = transitivity its RO'/RQ' (and then its AS-RO' etc) and so the complexity = becomes staggering. 
    Why do we = need that? 

    Fabien 

    Le ven. 19 = mars 2021 =C3=A0 00:55, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit :
    +1 This aligns with my healthcare use-case to the = extent that Justin can transfer the capability granted by that QR code = to Adrian who happens to be nearby Steve's house.

    I've tried to capture = some of this in my comment to #145 https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#i= ssuecomment-802388458

    - Adrian

    On Thu, Mar = 18, 2021 at 2:39 PM Justin Richer <jricher@mit.edu> = wrote:
    Right, and in the GNAP model this becomes = something my client instance presents to the AS when I show up. The AS = can validate my presentation of this item and give my client instance a = token to call Steve=E2=80=99s RS. Or if you wanted to get super fancy = Steve=E2=80=99s AS could even challenge my client instance and get a = cryptographic response to prove I have the thing Steve had me scan. But = in both cases it=E2=80=99s part of things that the AS collects in order = to create the access token.

     =E2=80=94 Justin

    On Mar 18, 2021, at 2:26 PM, Stephen Moore <srmoore@gmail.com> wrote:

    That in my mind works out = great... Say I'm logged into my home hub/AS. Justin is over and agrees = to cat sit, I pull up my client app, and generate a QR code that has = maybe The AS URI, the HomeHub API URL, and the 'special token to present = to AS for a real token'. Justin scans that QR code with his home = controller app, and BAM, he's onboarded as a guest without even logging = into my AS or me dealing with his Auth provider.
    -steve

    On Thu, Mar = 18, 2021 at 2:08 PM Justin Richer <jricher@mit.edu> = wrote:
    I think Steve=E2=80=99s= use case gives an interesting example of something that I believe = Adrian=E2=80=99s been talking about as well =E2=80=94 delegating to = another person.

    We = traditionally think of delegation at the AS to mean =E2=80=9Ca different = user account logs in to the AS=E2=80=9D, and it=E2=80=99s important to = know that this does in fact work. But this could just as easily be = =E2=80=9CSteve sends his friend an artifact to present to the AS to get = access=E2=80=9D. This isn=E2=80=99t Steve (or Steve=E2=80=99s client = software) getting and sending an access token, this is sending some = other set of rights credential to his friend, or his friend=E2=80=99s = software. So then Steve=E2=80=99s AS can have policy that says =E2=80=9Cwh= en I see this rights credential, give an access token for the following = attenuated things, because Steve said so=E2=80=9D. The AS doesn=E2=80=99t = even ever need to know who Steve=E2=80=99s friend is! 

    And importantly here, we = don=E2=80=99t expect Steve=E2=80=99s friend to bring their own AS to the = party. Steve=E2=80=99s RS has no reason to trust his friend=E2=80=99s = AS, let alone his friend=E2=80=99s client. But Steve=E2=80=99s AS is in = a position to know more about the rights policies that Steve wants to = apply, and so it can use other technologies like VC=E2=80=99s, DIDs, = OIDC, or any number of other things to let things go through. This = pattern is exactly why I think we need to think of this in terms of = what=E2=80=99s currently called =E2=80=9Cinteraction=E2=80=9D at the AS. = It=E2=80=99s not really just about how the end-user interacts, it=E2=80=99= s about how the AS gathers all the consent and authorization = information. I plan to rewrite section 4 to that effect.

     =E2=80=94 = Justin

    On Mar 18, 2021, at 1:58 PM, = Stephen Moore <srmoore@gmail.com> wrote:

    I'm having some = concerns with the way you're flipping the trust here Denis. You seem to = indicate that the user has trust in the RS and the Client and has to = gain the trust of the AS. I feel like the least trustworthy portion of = the architecture is the client, because that seems like it is the most = interchangeable component.
     Let me explain by way of = a use case I have in mind.
    Let's say I have a smart = home. I have devices and data storage and rule engines that are parts of = sensors and hubs I buy for the house. I have a trust in those devices, = because it's hardware, if the company is leaking data at the hardware = level there isn't much I can do other than buy different = sensors.
    In this case, the primary home hub, which = is under control of the homeowner, would also be the AS, as well as a = policy agent.  Authentication in the example is outsourced to = whatever auth providers you want. I set up my home using a google = account, a friend is staying and wants access and uses FB for auth... = whatever.
    The part that I have little control over = is the client my friend uses on his phone. Or if I change the client on = the tablet in the kitchen to try out something new. These = pieces might be single page web apps, they might be downloaded = apps, etc. I do not want them having any additional information than is = necessary. If I give my friend permission to unlock the door, and = control the lights because they are feeding my cats while I'm away, the = client doesn't need to know anything beyond, I see this home controller, = and I have access to these lights and that door lock.

    In your scenarios, the = client is spy by design, and if it is a web app, I don't trust them to = not grab my user email address from the AS and put it on a mailing = list it sells to some sketchy company, when the only other = component that needs that information is the RS.

    -steve

    On Thu, Mar 18, 2021 at 1:21 PM Denis <denis.ietf@free.fr> wrote:
    =20 =20 =20
    I have changed the title of this thread, since the original topic has been closed.

    Justin, you are raising the following question:
    The question I have is =E2=80=94 why does the client need to know what=E2=80=99s in the token?
    Not if they could possibly know, but why would we expect a client to know and manage the contents of the token?
    The answer is quite simple: so that the end-user may have confidence into the architecture.
    The seventh of the eleven privacy principles from ISO 29100 (page 14) is:
    7. Openness, transparency and notice
    If the access token is considered as a black box for the end-user, it cannot be confident about the content of the access token.
    Such access token may disclose some private information without the consent of the end-user. If the access token that it has obtained
    does not match with what has been requested, the client will first not forward the access token to the RS and then will complain about the AS.

    Denis


    =20
    Hi Justin, 

    "The access token is fundamentally a = conversational artifact between the AS and the RS which the client is the carrier of."
    That's right, and a good opportunity = to distinguish between the need for token inspection (i.e. a runtime = verification, wherever that may be)
    and the need to negotiate the token format (a discovery). That last part could very well be an extension, as a way to open up the ecosystem
    beyond JWTs (which are fine, but come with their own limitations). 

    Fabien

    On Thu, Mar 18, 2021 at = 5:59 PM Justin Richer <jricher@mit.edu> = wrote:
    On Mar 18, 2021, at 11:30 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Justin = Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 12:08 AM, = Alan Karp <alanhkarp@gmail.com> wrote:

    Adrian Gropper <agropper@healthurl.com> wrote:

    Is there an AS = involved in the delegation? How and where in the lifecycle of the protected = resource? 

    If tokens are = certificates, the AS need not be involved in subsequent delegations.  The = AS must be involved if the tokens are opaque. 

    Tokens are opaque to the = client instance. They are not opaque to the AS. They might be opaque to the RS, but that depends on the kind of relationship the RS and AS have. GNAP should allow different options here as there are different use cases for that.

    Tokens are not opaque to the = client in SPKI, zcap-ld, Orie's implementation with VCs, or our Zebra Copy work.  Why must they be = in GNAP?

    The existence of the AS is exactly the = reason for this. The AS is the role that =E2=80=9Cknowledge about = the token contents=E2=80=9D has been outsourced to in the GNAP = model (which is based on the OAuth model).

    It brings significant simplicity for the = client developer. The question I have is =E2=80=94 why does the = client need to know what=E2=80=99s in the token? Not if they = could possibly know, but why would we expect a client to know and manage the contents of the token? 

    The access token is fundamentally a = conversational artifact between the AS and the RS which the client is the carrier of. The client is not the audience of the token, nor the creator of the token, nor even the manager of the token and the rights it represents. The client as a simple carrier is a powerful model that allows the security layer to get out of the way of the actual application logic that developers want to = do.

     =E2=80=94 Justin


    --------------
    Alan Karp


    On Thu, Mar = 18, 2021 at 4:56 AM Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 12:08 AM, = Alan Karp <alanhkarp@gmail.com> wrote:

    Adrian Gropper <agropper@healthurl.com> wrote:

    Is there an AS = involved in the delegation? How and where in the lifecycle of the protected = resource? 

    If tokens are = certificates, the AS need not be involved in subsequent delegations.  The = AS must be involved if the tokens are opaque. 

    Tokens are opaque to the = client instance. They are not opaque to the AS. They might be opaque to the RS, but that depends on the kind of relationship the RS and AS have. GNAP should allow different options here as there are different use cases for that.

    It would probably be = worthwhile to separate the portions of the spec that talk about the RS-AS relationship into its own standalone document. A similar approach was taken in UMA2 and it was helpful. (Though admittedly, as with anything, there are missteps there that we can hopefully learn from.)

     =E2=80=94 Justin


    --------------
    Alan Karp


    On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Sure! 

    Is there an AS = involved in the delegation? How and where in the lifecycle of the protected resource? 

    Also your use = of "the client" seems to imply that either there is only one client or the client doesn't matter. Which is it?

    Adrian

    On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks for = that. 

    Trying to reframe it:
    GNAP is defined as a delegation protocol so the main intent is related to a delegate of the RO (i.e. the end user) that wishes to access the RO's protected resources, through the = client. 

    Fabien 

    Le jeu. 18 mars 2021 =C3=A0= 04:29, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit :
    At various points in the = lifecycle of the protected resource the client at the resource server (RS) might be:
    • The= RO (subject) user agent trading payment for a service promise
    • The= RO user agent using the promise to access the protected resource
    • A = delegate of the RO user agent using a different client
    What's vague is where the GNAP AS enters the picture as described above. How would you describe = it?

    Adrian


    On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Adrian

    I'm still confused why you're saying the terminology is = vague. 
    I get the "power" neutrality is not to your liking, but RQ / user agent is no better in my = view. 

    Can you = elaborate? 

    Fabien 

    Le jeu. 18 mars 2021 =C3=A0 = 00:18, Adrian Gropper <agropper@healthurl.com> a = =C3=A9crit :
    I'm sure you're right. Our vague = terminology around client and end-user leads to my confusion. If GNAP is = primarily about = delegation then, of course, we = should avoid any incentives to impersonate or we're wasting our time. This is partly why I'm trying to study up on capabilities and asking for expert advice from folks like Alan Karp and Mark Miller (cc'd)

    As best I can understand it, the RS has only two choices, it can:
    =
    • store an attribute of the RO a [DID, email address, GNAP AS URL], or
    • hand the RO a capability as a sort-of promise and avoid making any entries in an ACL or = equivalent.
    When a token comes back to the RS, it will either = be:
    =
    • validated according to something associated with the stored RO attribute, = or
    • signed by the RS = itself.
    Either way, trust in the client seems = moot.

    Adrian



    On Wed, Mar 17, 2021 at 5:29 PM Justin Richer = <jricher@mit.edu> = wrote:
    On Mar 17, 2021, at 4:55 PM, Adrian Gropper <agropper@healthurl.com> wrote:
    =

    =
    On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <tobias.looker@mattr.global> wrote:
    <snip>
    > A client might not have a DID but it could have a VC as a certificate of authenticity linked to some audit = mechanism.

    To me a VC would come under the assertions umbrella (that is to say a VC could be one type of valid assertion). The client may possess or been presented with a VC that it could include in its request to the AS as a way to identify the subject and perhaps prove authentication and = authorization.

    I do not assume that the client that interacts with the AS to make a request and receive a token is the same as the client that will present the token to the RS. In the US HIPAA use-case, for example, the root of trust is a contract between the = patient-subject and the = doctor-requesting party but the doctor workflow is expected to delegate the token to some other end-user that may be using a totally different client such as an EHR.


    If the client that gets the token is not same as the client that uses the token, that is a violation of core security principles as it allows for (and really designs for) impersonation by client software. I would have no reason to trust client software that would hand its credentials over to another piece of software, and in fact I shouldn=E2=80=99= t trust = it. 

    I think you may be conflating several different kinds of parties under the = =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80= =99s entirely possible that one client might call an RS that in turn acts as a client for something else down stream. But each of those hops is different from the = last.

     =E2=80=94 Justin





    --
    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
    =
    --
    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
    =


    --
    You know nothing = Jon Snow!

    = --Apple-Mail=_786F3F87-FC37-4053-99E3-F8D9386445DF-- From nobody Fri Mar 19 07:27:41 2021 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 01A813A1683 for ; Fri, 19 Mar 2021 07:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] 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 N3TC7ET8hn5A for ; Fri, 19 Mar 2021 07:27:38 -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 8E88B3A1678 for ; Fri, 19 Mar 2021 07:27:37 -0700 (PDT) Received: from [192.168.1.11] ([90.79.53.231]) by mwinf5d46 with ME id iETX2400W4zJUWJ03ETX6H; Fri, 19 Mar 2021 15:27:34 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Fri, 19 Mar 2021 15:27:34 +0100 X-ME-IP: 90.79.53.231 To: "txauth@ietf.org" From: Denis Message-ID: <62619e0d-f4ad-bef8-d351-49943542409f@free.fr> Date: Fri, 19 Mar 2021 15:27:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------2117135453141DBAF7C386D0" Content-Language: en-GB Archived-At: Subject: [GNAP] A "privacy by design" delegation scheme X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 14:27:40 -0000 This is a multi-part message in MIME format. --------------2117135453141DBAF7C386D0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit The text that follows is extracted from : * Page 5 from RFC 6749 (OAuth 2.0). October 2012, and * Page 5 & 6 from draft-ietf-oauth-v2-1-01. February 2021           " For example, an end-user (resource owner) can grant a printing service (client) access to her protected photos stored at a photo sharing service (resource server),           without sharing her username and password with the printing service.Instead, she authenticates directly /with a server trusted by the photo-sharing service // //          (authorization server), which issues the printing service delegation-specific credentials (access token)/." These two sentences are part of the foundations of OAuth 2.0 and OAuth 2.1. The same delegation scheme can be supported without the need to use an authorization server (AS). Here is the story:            For example, an end-user can grant a printing service access to her protected photos stored at a photo sharing service, without sharing her username and password            with the printing service.Instead, she authenticates directly to the photo sharing service and asks to that service to deliver delegation-specific credentials (access token)            able to grant to its owner a read access to a subset of her photos during some period of time. Once the access token has been delivered by the photo sharing service,            she transmits it to the printing service. Then the printing service presents that access token to the photo sharing service which will deliver the subset of selected photos            to the printing service. _Requirement_ :_ _ The end-user must have an account on the photo sharing service. _Advantages_: , * Since there is no AS, the photo sharing service does not need to trust any AS nor have a relationship with an AS. * Since there is no AS, the printing service does not need to trust any AS, nor have as relationship with an AS. * Since there is no AS, no account is needed for the end-user at an AS. * Since there is no AS, no AS can know/spy what the end-user is doing. * The access token can be transmitted/communicated to anybody, including herself. * The end-user MAY have an account on the printing service, but she is NOT REQUIRED to have one. * The person that gets the photos printed will need to disclose to the printing service a name and an address for the delivery (not necessarily her name and her home address) /if she is not working at a kiosk /and will need to pay for the printing (/and postage/). Denis --------------2117135453141DBAF7C386D0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

    The text that follows is extracted from :

    • Page 5 from RFC 6749 (OAuth 2.0). October 2012, and
    • Page 5 & 6 from draft-ietf-oauth-v2-1-01. February 2021

              " For example, an end-user (resource owner) can grant a printing service (client) access to her protected photos stored at a photo sharing service (resource server),
              without sharing her username and password with the printing service.  Instead, she authenticates directly with a server trusted by the photo-sharing service
              (authorization server), which issues the printing service delegation-specific credentials (access token)."

    These two sentences are part of the foundations of OAuth 2.0 and OAuth 2.1.

    The same delegation scheme can be supported without the need to use an authorization server (AS). Here is the story:

               For example, an end-user can grant a printing service access to her protected photos stored at a photo sharing service, without sharing her username and password
               with the printing service.  Instead, she authenticates directly to the photo sharing service and asks to that service to deliver delegation-specific credentials (access token)
               able to grant to its owner a read access to a subset of her photos during some period of time. Once the access token has been delivered by the photo sharing service,
               she transmits it to the printing service. Then the printing service presents that access token to the photo sharing service which will deliver the subset of selected     photos
               to the printing service    .

    Requirement :

    The end-user must have an account on the photo sharing service.

    Advantages: ,

    • Since there is no AS, the photo sharing service does not need to trust any AS nor have a relationship with an AS.
    • Since there is no AS, the printing service does not need to trust any AS, nor have as relationship with an AS.
    • Since there is no AS, no account is needed for the end-user at an AS.
    • Since there is no AS, no AS can know/spy what the end-user is doing.
    • The access token can be transmitted/communicated to anybody, including herself.
    • The end-user MAY have an account on the printing service, but she is NOT REQUIRED to have one.
    • The person that gets the photos printed will need to disclose to the printing service a name and an address for the delivery
      (not necessarily her name and her home address) if she is not working at a kiosk and will need to pay for the printing (and postage).

    Denis

    --------------2117135453141DBAF7C386D0-- From nobody Fri Mar 19 07:31:50 2021 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 0D2353A16C8 for ; Fri, 19 Mar 2021 07:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.918 X-Spam-Level: X-Spam-Status: No, score=-6.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 kopbNKl9-yKT for ; Fri, 19 Mar 2021 07:31:46 -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 DE1BB3A1940 for ; Fri, 19 Mar 2021 07:31:09 -0700 (PDT) Received: from [192.168.1.22] (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 12JEV5cU030705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Mar 2021 10:31:06 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_230C00EF-F639-4EF8-AB22-264A74EB9828" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 19 Mar 2021 10:31:05 -0400 In-Reply-To: <62619e0d-f4ad-bef8-d351-49943542409f@free.fr> Cc: "txauth@ietf.org" To: Denis References: <62619e0d-f4ad-bef8-d351-49943542409f@free.fr> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] A "privacy by design" delegation scheme X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 14:31:48 -0000 --Apple-Mail=_230C00EF-F639-4EF8-AB22-264A74EB9828 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Denis, The abstraction of the authorization server is fundamental to the = approach in both OAuth and GNAP. I would personally encourage you to start a BoF and eventually a working = group here in the IETF to pursue such a design as you are proposing. =E2=80=94 Justin > On Mar 19, 2021, at 10:27 AM, Denis wrote: >=20 > The text that follows is extracted from : >=20 > Page 5 from RFC 6749 (OAuth 2.0). October 2012, and > Page 5 & 6 from draft-ietf-oauth-v2-1-01. February 2021 > " For example, an end-user (resource owner) can grant a = printing service (client) access to her protected photos stored at a = photo sharing service (resource server),=20 > without sharing her username and password with the printing = service. Instead, she authenticates directly with a server trusted by = the photo-sharing service=20 > (authorization server), which issues the printing service = delegation-specific credentials (access token)." >=20 > These two sentences are part of the foundations of OAuth 2.0 and OAuth = 2.1. >=20 > The same delegation scheme can be supported without the need to use an = authorization server (AS). Here is the story: >=20 > For example, an end-user can grant a printing service = access to her protected photos stored at a photo sharing service, = without sharing her username and password=20 > with the printing service. Instead, she authenticates = directly to the photo sharing service and asks to that service to = deliver delegation-specific credentials (access token)=20 > able to grant to its owner a read access to a subset of her = photos during some period of time. Once the access token has been = delivered by the photo sharing service,=20 > she transmits it to the printing service. Then the printing = service presents that access token to the photo sharing service which = will deliver the subset of selected photos=20 > to the printing service.=20 >=20 > Requirement : >=20 > The end-user must have an account on the photo sharing service. >=20 > Advantages: , >=20 > Since there is no AS, the photo sharing service does not need to trust = any AS nor have a relationship with an AS. > Since there is no AS, the printing service does not need to trust any = AS, nor have as relationship with an AS. > Since there is no AS, no account is needed for the end-user at an AS. > Since there is no AS, no AS can know/spy what the end-user is doing. > The access token can be transmitted/communicated to anybody, including = herself. > The end-user MAY have an account on the printing service, but she is = NOT REQUIRED to have one. > The person that gets the photos printed will need to disclose to the = printing service a name and an address for the delivery=20 > (not necessarily her name and her home address) if she is not working = at a kiosk and will need to pay for the printing (and postage). > Denis >=20 >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_230C00EF-F639-4EF8-AB22-264A74EB9828 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Denis,

    The = abstraction of the authorization server is fundamental to the approach = in both OAuth and GNAP.

    I would personally encourage you to start a BoF and = eventually a working group here in the IETF to pursue such a design as = you are proposing.

     =E2=80=94 Justin

    On Mar = 19, 2021, at 10:27 AM, Denis <denis.ietf@free.fr> wrote:

    =20

    The text that follows is = extracted from :

    • Page 5 from RFC 6749 (OAuth 2.0). October 2012, = and
    • Page 5 & 6 from draft-ietf-oauth-v2-1-01. February = 2021

              " For = example, an end-user (resource owner) can grant a printing service (client) access to her protected photos stored at a photo sharing service (resource server),
              without = sharing her username and password with the printing service.  = Instead, she authenticates directly with a server trusted by the = photo-sharing service
              = (authorization server), which issues the printing service delegation-specific credentials (access token)."

    These two sentences are part of the foundations of OAuth 2.0 and OAuth 2.1.

    The same delegation scheme can be supported without the need to use an authorization server (AS). Here is the story:

               For = example, an end-user can grant a printing service access to her protected photos stored at a photo sharing service, without sharing her username and password
               = with the printing service.  Instead, she authenticates = directly to the photo sharing = service and asks to that service to deliver delegation-specific credentials (access token)
               = able to grant to its owner a read access to a subset of her photos during some period of time. Once the access token has been delivered by the photo sharing service,
               = she transmits it to the printing service. Then the printing service presents that access token to the photo sharing service which will deliver the subset of selected     photos
               = to the printing service    .

    Requirement :

    The end-user must have an account on the photo sharing = service.

    Advantages: ,

    • Since there is no AS, the photo sharing service does not need to trust any AS nor have a relationship with an AS.
    • Since there is no AS, the printing service does not need to trust any AS, nor have as relationship with an AS.
    • Since there is no AS, no account is needed for the end-user at an AS.
    • Since there is no AS, no AS can know/spy what the end-user is doing.
    • The access token can be transmitted/communicated to anybody, including = herself.
    • The end-user MAY have an = account on the printing service, but she is NOT REQUIRED to have one.
    • The person that gets the photos printed will need to disclose to the printing service a name and an address for the delivery
      (not necessarily her name and her home address) if= she is not working at a kiosk and will need to pay for the printing (and postage).

    Denis

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

    = --Apple-Mail=_230C00EF-F639-4EF8-AB22-264A74EB9828-- From nobody Fri Mar 19 07:37:54 2021 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 4004B3A16CE for ; Fri, 19 Mar 2021 07:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 p7-JGRvhgfpO for ; Fri, 19 Mar 2021 07:37:51 -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 E5FFD3A16CD for ; Fri, 19 Mar 2021 07:37:50 -0700 (PDT) Received: from [192.168.1.22] (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 12JEblBA001064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Mar 2021 10:37:48 -0400 From: Justin Richer Message-Id: <0E07D733-532A-4F87-A534-4519CE0052E3@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_DA1C5B51-1246-4514-83D8-85267E81F728" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 19 Mar 2021 10:37:47 -0400 In-Reply-To: Cc: "txauth@ietf.org" To: Denis References: <62619e0d-f4ad-bef8-d351-49943542409f@free.fr> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] A "privacy by design" delegation scheme X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 14:37:53 -0000 --Apple-Mail=_DA1C5B51-1246-4514-83D8-85267E81F728 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Also, I want to point out that in your description below, the photo = sharing service is the AS and the RS. It=E2=80=99s fulfilling both = roles. This isn=E2=80=99t =E2=80=9Cwithout an AS=E2=80=9D this is simply = saying that one party runs both components in a closely-knit manner.=20 =E2=80=94 Justin > On Mar 19, 2021, at 10:31 AM, Justin Richer wrote: >=20 > Hi Denis, >=20 > The abstraction of the authorization server is fundamental to the = approach in both OAuth and GNAP. >=20 > I would personally encourage you to start a BoF and eventually a = working group here in the IETF to pursue such a design as you are = proposing. >=20 > =E2=80=94 Justin >=20 >> On Mar 19, 2021, at 10:27 AM, Denis > wrote: >>=20 >> The text that follows is extracted from : >>=20 >> Page 5 from RFC 6749 (OAuth 2.0). October 2012, and >> Page 5 & 6 from draft-ietf-oauth-v2-1-01. February 2021 >> " For example, an end-user (resource owner) can grant a = printing service (client) access to her protected photos stored at a = photo sharing service (resource server),=20 >> without sharing her username and password with the printing = service. Instead, she authenticates directly with a server trusted by = the photo-sharing service=20 >> (authorization server), which issues the printing service = delegation-specific credentials (access token)." >>=20 >> These two sentences are part of the foundations of OAuth 2.0 and = OAuth 2.1. >>=20 >> The same delegation scheme can be supported without the need to use = an authorization server (AS). Here is the story: >>=20 >> For example, an end-user can grant a printing service = access to her protected photos stored at a photo sharing service, = without sharing her username and password=20 >> with the printing service. Instead, she authenticates = directly to the photo sharing service and asks to that service to = deliver delegation-specific credentials (access token)=20 >> able to grant to its owner a read access to a subset of = her photos during some period of time. Once the access token has been = delivered by the photo sharing service,=20 >> she transmits it to the printing service. Then the = printing service presents that access token to the photo sharing service = which will deliver the subset of selected photos=20 >> to the printing service.=20 >>=20 >> Requirement : >>=20 >> The end-user must have an account on the photo sharing service. >>=20 >> Advantages: , >>=20 >> Since there is no AS, the photo sharing service does not need to = trust any AS nor have a relationship with an AS. >> Since there is no AS, the printing service does not need to trust any = AS, nor have as relationship with an AS. >> Since there is no AS, no account is needed for the end-user at an AS. >> Since there is no AS, no AS can know/spy what the end-user is doing. >> The access token can be transmitted/communicated to anybody, = including herself. >> The end-user MAY have an account on the printing service, but she is = NOT REQUIRED to have one. >> The person that gets the photos printed will need to disclose to the = printing service a name and an address for the delivery=20 >> (not necessarily her name and her home address) if she is not working = at a kiosk and will need to pay for the printing (and postage). >> Denis >>=20 >>=20 >> --=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 --Apple-Mail=_DA1C5B51-1246-4514-83D8-85267E81F728 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Also,= I want to point out that in your description below, the photo sharing = service is the AS and the RS. It=E2=80=99s fulfilling both roles. This = isn=E2=80=99t =E2=80=9Cwithout an AS=E2=80=9D this is simply saying that = one party runs both components in a closely-knit manner. 

     =E2=80=94 = Justin

    On Mar 19, 2021, at 10:31 AM, Justin Richer = <jricher@mit.edu> = wrote:

    Hi Denis,

    The abstraction of the = authorization server is fundamental to the approach in both OAuth and = GNAP.

    I would = personally encourage you to start a BoF and eventually a working group = here in the IETF to pursue such a design as you are proposing.

     =E2=80=94 = Justin

    On Mar 19, 2021, at 10:27 AM, = Denis <denis.ietf@free.fr> wrote:

    =20

    The text that follows is = extracted from :

    • Page 5 from RFC 6749 (OAuth 2.0). October 2012, = and
    • Page 5 & 6 from draft-ietf-oauth-v2-1-01. February = 2021

              " For = example, an end-user (resource owner) can grant a printing service (client) access to her protected photos stored at a photo sharing service (resource server),
              without = sharing her username and password with the printing service.  = Instead, she authenticates directly with a server trusted by the = photo-sharing service
              = (authorization server), which issues the printing service delegation-specific credentials (access token)."

    These two sentences are part of the foundations of OAuth 2.0 and OAuth 2.1.

    The same delegation scheme can be supported without the need to use an authorization server (AS). Here is the story:

               For = example, an end-user can grant a printing service access to her protected photos stored at a photo sharing service, without sharing her username and password
               = with the printing service.  Instead, she authenticates = directly to the photo sharing = service and asks to that service to deliver delegation-specific credentials (access token)
               = able to grant to its owner a read access to a subset of her photos during some period of time. Once the access token has been delivered by the photo sharing service,
               = she transmits it to the printing service. Then the printing service presents that access token to the photo sharing service which will deliver the subset of selected     photos
               = to the printing service    .

    Requirement :

    The end-user must have an account on the photo sharing = service.

    Advantages: ,

    • Since there is no AS, the photo sharing service does not need to trust any AS nor have a relationship with an AS.
    • Since there is no AS, the printing service does not need to trust any AS, nor have as relationship with an AS.
    • Since there is no AS, no account is needed for the end-user at an AS.
    • Since there is no AS, no AS can know/spy what the end-user is doing.
    • The access token can be transmitted/communicated to anybody, including = herself.
    • The end-user MAY have an = account on the printing service, but she is NOT REQUIRED to have one.
    • The person that gets the photos printed will need to disclose to the printing service a name and an address for the delivery
      (not necessarily her name and her home address) if= she is not working at a kiosk and will need to pay for the printing (and postage).

    Denis

    --
    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=_DA1C5B51-1246-4514-83D8-85267E81F728-- From nobody Fri Mar 19 07:40:55 2021 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 C75A03A16ED for ; Fri, 19 Mar 2021 07:40:54 -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 HyH-ISyujbCC for ; Fri, 19 Mar 2021 07:40:52 -0700 (PDT) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 8CA1A3A169A for ; Fri, 19 Mar 2021 07:40:40 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id y6so11078147eds.1 for ; Fri, 19 Mar 2021 07:40:40 -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=BoCZYactVOm+4LTbwaf3SF4ZqMuy9XHi3xdfAG5LOoU=; b=bP/0PDAxTn90a5oWy5f77tZVJ2f2ykz88sIF2lJMLjjM++JLd8S+Llqt4E5pCzyycs lwGw1hnP/+N/St/i6wNBhwzj8Luw2GWrP0+Qb6xY7IATbn7ODGAegdsx0eYRV259b3cN YU4MW8UC5myMekzhy62eE4foUTkXAcBoq5LSCeHfONJclJu0xDgvqL5fsgXe07J+NdoN B7qTH/v4bN4NSvb+Xq4RYUL6CI0mWhuMPubhct9zhuaIQn/e9VXHIfnhZID+jue+LAeY vFW7U2/KFhyPB4onYGNODHVDzsXGxq8aoTSw3pvCWYTmE0/jJf9GUIHd2POmrXYho//E tt9w== 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=BoCZYactVOm+4LTbwaf3SF4ZqMuy9XHi3xdfAG5LOoU=; b=qy2NQ17slv2EFGgq88At7z26TZSPmOIFDixKXnew1F+cILZ4GR/E8W8v/uOW/gmX1l 4mrfxbA2bm4s756/YnyVMipXo1WQraMI7HVe8g03iA+or8OAV47s3zZOhQfPmpOaYEb0 B0Vp4gXJtxgA8YjrJyyK8QO42QI69c6WhiiTgNRm9naaVEcbbDVONhYTDzeUJ7Ddo1Rv sk1UwouGEfS0wHbynqO1fwhjwIFouI5rQK0cnmSa491QIzqUTR73N1DCIad/UY18JAHB W5NjHw2+MGCPj7n8aq8kMKKzZQZ+UZs9U7N7UIVhS8VkjTJtKvhuUinH7Z/SbBFZxMAI CYLg== X-Gm-Message-State: AOAM531tyP4bUUuMkhxKrL1/ma6hKb4dyyB8FWGfBzr5tz8DMlTU7uVm hqLoKj8mDd9/UhiXzR9gdMU9uh2r1i7R/Ahvv5lBpakE X-Google-Smtp-Source: ABdhPJy0RCztoCc7EkHz0mHcwoANpLOckVj265rzhlifl3J+qihWWRVGS0eWD23L6YYWAsD0qROsuFC0Q3VCeyO1MIs= X-Received: by 2002:a50:eb97:: with SMTP id y23mr10032714edr.170.1616164837629; Fri, 19 Mar 2021 07:40:37 -0700 (PDT) MIME-Version: 1.0 References: <62619e0d-f4ad-bef8-d351-49943542409f@free.fr> In-Reply-To: <62619e0d-f4ad-bef8-d351-49943542409f@free.fr> From: Stephen Moore Date: Fri, 19 Mar 2021 10:40:26 -0400 Message-ID: To: Denis Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000ba3c605bde4b340" Archived-At: Subject: Re: [GNAP] A "privacy by design" delegation scheme X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 14:40:55 -0000 --0000000000000ba3c605bde4b340 Content-Type: text/plain; charset="UTF-8" Denis, All you are doing in that case is putting the AS into the photosharing service. The photo sharing service still has an AS that it explicitly trusts because it owns it, but now I need to have multiple accounts on every RS I have data on it, rather than giving me the option as a user to entrust an AS run by a reputable company that can be trusted by many RS's. The delivery information can be input at the Photo Printing service with or without an account on the service, regardless of where the token comes from. I don't see how your last two bullets matter in differentiating the two takes. I honestly don't see a difference between the two other than one service hosting the two components (RS and AS) -steve On Fri, Mar 19, 2021 at 10:27 AM Denis wrote: > The text that follows is extracted from : > > > - Page 5 from RFC 6749 (OAuth 2.0). October 2012, and > - Page 5 & 6 from draft-ietf-oauth-v2-1-01. February 2021 > > " For example, an end-user (resource owner) can grant a printing > service (client) access to her protected photos stored at a photo sharing > service (resource server), > without sharing her username and password with the printing > service. Instead, she authenticates directly *with a server trusted by > the photo-sharing service * > * (authorization server), which issues the printing service > delegation-specific credentials (access token)*." > > These two sentences are part of the foundations of OAuth 2.0 and OAuth 2.1. > > The same delegation scheme can be supported without the need to use an > authorization server (AS). Here is the story: > > For example, an end-user can grant a printing service access to > her protected photos stored at a photo sharing service, without sharing her > username and password > with the printing service. Instead, she authenticates > directly to the photo sharing service and asks to that service to deliver > delegation-specific credentials (access token) > able to grant to its owner a read access to a subset of her > photos during some period of time. Once the access token has been delivered > by the photo sharing service, > she transmits it to the printing service. Then the printing > service presents that access token to the photo sharing service which will > deliver the subset of selected photos > to the printing service. > > *Requirement* : > > The end-user must have an account on the photo sharing service. > > *Advantages*: , > > - Since there is no AS, the photo sharing service does not need to > trust any AS nor have a relationship with an AS. > - Since there is no AS, the printing service does not need to trust > any AS, nor have as relationship with an AS. > - Since there is no AS, no account is needed for the end-user at an AS. > - Since there is no AS, no AS can know/spy what the end-user is doing. > - The access token can be transmitted/communicated to anybody, > including herself. > - The end-user MAY have an account on the printing service, but she is > NOT REQUIRED to have one. > - The person that gets the photos printed will need to disclose to the > printing service a name and an address for the delivery > (not necessarily her name and her home address) *if she is not working > at a kiosk *and will need to pay for the printing (*and postage*). > > Denis > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000000ba3c605bde4b340 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Denis,=C2=A0
    All you are doing in that case is putting= the AS into the photosharing service. The photo sharing service still has = an AS that it explicitly=C2=A0trusts because it owns it, but now I need to = have multiple accounts on every RS I have data on it, rather than giving me= the option as a user to entrust an AS run by a reputable company that can = be trusted by many RS's.
    The delivery information can be inpu= t at the Photo Printing service with or without an account on the service, = regardless=C2=A0of where the token comes from. I don't see how your las= t two bullets matter in differentiating the two takes.

    =
    I honestly don't see a difference between the two other than one s= ervice hosting the two components (RS and AS)
    -steve
    <= br>
    On Fri,= Mar 19, 2021 at 10:27 AM Denis <d= enis.ietf@free.fr> wrote:
    =20 =20 =20
    =20

    The text that follows is extracted from :

    • Page 5 from RFC 6749 (OAuth 2.0). October 2012, and
    • Page 5 & 6 from draft-ietf-oauth-v2-1-01. February 2021

    =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 " For example, an end-us= er (resource owner) can grant a printing service (client) access to her protected photos stored at a photo sharing service (resource server),
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 without shar= ing her username and password with the printing service.=C2=A0 Instead, she authenticates directly with a server trusted by the photo-sharing service
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (auth= orization server), which issues the printing service delegation-specific credentials (access token)."

    These two sentences are part of the foundations of OAuth 2.0 and OAuth 2.1.

    The same delegation scheme can be supported without the need to use an authorization server (AS). Here is the story:

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For ex= ample, an end-user can grant a printing service access to her protected photos stored at a photo sharing service, without sharing her username and password
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 with t= he printing service.=C2=A0 Instead, she authenticates directly= to the photo sharing service and asks to that service to deliver delegation-specific credentials (access token)
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 able= to grant to its owner a read access to a subset of her photos during some period of time. Once the access token has been delivered by the photo sharing service,
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 she = transmits it to the printing service. Then the printing service presents that access token to the photo sharing service which will deliver the subset of selected     photos
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to t= he printing service    .

    Requirement :

    The end-user must have an account on the photo sharing service.

    Advantages: ,

    • Since there is no AS, the photo sharing service does not need to trust any AS nor have a relationship with an AS.
    • Since there is no AS, the printing service does not need to trust any AS, nor have as relationship with an AS.
    • Since there is no AS, no account is needed for the end-user at an AS.
    • Since there is no AS, no AS can know/spy what the end-user is doing.
    • The access token can be transmitted/communicated to anybody, including herself.<= /span>
    • The end-user M= AY have an account on the printing service, but she is NOT REQUIRED to have one.
    • The person that gets the photos printed will need to disclose to the printing service a name and an address for the delivery
      (not necessarily her name and her home address) if she is not working at a kiosk and will need to pay for the printing (and postage).

    Denis

    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --0000000000000ba3c605bde4b340-- From nobody Fri Mar 19 08:07:22 2021 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 009533A1829 for ; Fri, 19 Mar 2021 08:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 oBOycoNZZkO4 for ; Fri, 19 Mar 2021 08:07:11 -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 258723A18CF for ; Fri, 19 Mar 2021 08:06:41 -0700 (PDT) Received: from [192.168.1.11] ([90.79.53.231]) by mwinf5d46 with ME id iF6e2400U4zJUWJ03F6f4s; Fri, 19 Mar 2021 16:06:39 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Fri, 19 Mar 2021 16:06:39 +0100 X-ME-IP: 90.79.53.231 To: Stephen Moore Cc: "txauth@ietf.org" References: <62619e0d-f4ad-bef8-d351-49943542409f@free.fr> From: Denis Message-ID: <5472b905-fe3c-4d5d-5b05-f6f6a58f43ca@free.fr> Date: Fri, 19 Mar 2021 16:06:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------41826DD7A023B0FF9C0329E9" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] A "privacy by design" delegation scheme X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 15:07:14 -0000 This is a multi-part message in MIME format. --------------41826DD7A023B0FF9C0329E9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Steve, Thank you for your feedback. You wrote: "now I need to have multiple accounts on every RS I have data on it". Yes indeed, but you know that there exists or there will exist solutions for that, one of them being FIDO. With FIDO the RS cannot link their user accounts using the login name. FIDO has been thought with privacy in mind. About the last two bullets, I fear I don't understand your question. The end-user may pick the photos at the delivery service or someone else can pick these photos. An account is useful to avoid the retyping of a name and a home address each time, but is not necessary otherwise. You finally wrote: "I honestly don't see a difference between the two other than one service hosting the two components (RS and AS)". You only see the difference if you consider the trust relationships. In the general case, an AS is trusted by several RSs, but not in this situation. If you rely on the HTTPS protection on both segments, then no cryptography is even necessary: there is no signature needed from anyone. Denis > Denis, > All you are doing in that case is putting the AS into the photosharing > service. The photo sharing service still has an AS that it > explicitly trusts because it owns it, but now I need to have multiple > accounts on every RS I have data on it, rather than giving me the > option as a user to entrust an AS run by a reputable company that can > be trusted by many RS's. > The delivery information can be input at the Photo Printing service > with or without an account on the service, regardless of where the > token comes from. I don't see how your last two bullets matter in > differentiating the two takes. > > I honestly don't see a difference between the two other than one > service hosting the two components (RS and AS) > -steve > > On Fri, Mar 19, 2021 at 10:27 AM Denis > wrote: > > The text that follows is extracted from : > > * Page 5 from RFC 6749 (OAuth 2.0). October 2012, and > * Page 5 & 6 from draft-ietf-oauth-v2-1-01. February 2021 > >           " For example, an end-user (resource owner) can grant a > printing service (client) access to her protected photos stored at > a photo sharing service (resource server), >           without sharing her username and password with the > printing service.Instead, she authenticates directly /with a > server trusted by the photo-sharing service // > //          (authorization server), which issues the printing > service delegation-specific credentials (access token)/." > > These two sentences are part of the foundations of OAuth 2.0 and > OAuth 2.1. > > The same delegation scheme can be supported without the need to > use an authorization server (AS). Here is the story: > >            For example, an end-user can grant a printing service > access to her protected photos stored at a photo sharing service, > without sharing her username and password >            with the printing service.Instead, she authenticates > directly to the photo sharing service and asks to that service to > deliver delegation-specific credentials (access token) >            able to grant to its owner a read access to a subset of > her photos during some period of time. Once the access token has > been delivered by the photo sharing service, >            she transmits it to the printing service. Then the > printing service presents that access token to the photo sharing > service which will deliver the subset of selected photos >            to the printing service. > > _Requirement_ :_ > _ > The end-user must have an account on the photo sharing service. > > _Advantages_: , > > * Since there is no AS, the photo sharing service does not need > to trust any AS nor have a relationship with an AS. > * Since there is no AS, the printing service does not need to > trust any AS, nor have as relationship with an AS. > * Since there is no AS, no account is needed for the end-user at > an AS. > * Since there is no AS, no AS can know/spy what the end-user is > doing. > * The access token can be transmitted/communicated to anybody, > including herself. > * The end-user MAY have an account on the printing service, but > she is NOT REQUIRED to have one. > * The person that gets the photos printed will need to disclose > to the printing service a name and an address for the delivery > (not necessarily her name and her home address) /if she is not > working at a kiosk /and will need to pay for the printing > (/and postage/). > > Denis > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > --------------41826DD7A023B0FF9C0329E9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
    Hi Steve,

    Thank you for your feedback.

    You wrote: "now I need to have multiple accounts on every RS I have data on it". Yes indeed, but you know that there exists
    or there will exist solutions for that, one of them being FIDO. With FIDO the RS cannot link their user accounts using the login name.
    FIDO has been thought with privacy in mind.

    About the last two bullets, I fear I don't understand your question.
    The end-user may pick the photos at the delivery service or someone else can pick these photos.
    An account is useful to avoid the retyping of a name and a home address each time, but is not necessary otherwise.

    You finally wrote: "I honestly don't see a difference between the two other than one service hosting the two components (RS and AS)".

    You only see the difference if you consider the trust relationships. In the general case, an AS is trusted by several RSs, but not in this situation.
    If you rely on the HTTPS protection on both segments, then no cryptography is even necessary: there is no signature needed from anyone.

    Denis

    Denis, 
    All you are doing in that case is putting the AS into the photosharing service. The photo sharing service still has an AS that it explicitly trusts because it owns it, but now I need to have multiple accounts on every RS I have data on it, rather than giving me the option as a user to entrust an AS run by a reputable company that can be trusted by many RS's.
    The delivery information can be input at the Photo Printing service with or without an account on the service, regardless of where the token comes from. I don't see how your last two bullets matter in differentiating the two takes.

    I honestly don't see a difference between the two other than one service hosting the two components (RS and AS)
    -steve

    On Fri, Mar 19, 2021 at 10:27 AM Denis <denis.ietf@free.fr> wrote:

    The text that follows is extracted from :

    • Page 5 from RFC 6749 (OAuth 2.0). October 2012, and
    • Page 5 & 6 from draft-ietf-oauth-v2-1-01. February 2021

              " For example, an end-user (resource owner) can grant a printing service (client) access to her protected photos stored at a photo sharing service (resource server),
              without sharing her username and password with the printing service.  Instead, she authenticates directly with a server trusted by the photo-sharing service
              (authorization server), which issues the printing service delegation-specific credentials (access token)."

    These two sentences are part of the foundations of OAuth 2.0 and OAuth 2.1.

    The same delegation scheme can be supported without the need to use an authorization server (AS). Here is the story:

               For example, an end-user can grant a printing service access to her protected photos stored at a photo sharing service, without sharing her username and password
               with the printing service.  Instead, she authenticates directly to the photo sharing service and asks to that service to deliver delegation-specific credentials (access token)
               able to grant to its owner a read access to a subset of her photos during some period of time. Once the access token has been delivered by the photo sharing service,
               she transmits it to the printing service. Then the printing service presents that access token to the photo sharing service which will deliver the subset of selected     photos
               to the printing service    .

    Requirement :

    The end-user must have an account on the photo sharing service.

    Advantages: ,

    • Since there is no AS, the photo sharing service does not need to trust any AS nor have a relationship with an AS.
    • Since there is no AS, the printing service does not need to trust any AS, nor have as relationship with an AS.
    • Since there is no AS, no account is needed for the end-user at an AS.
    • Since there is no AS, no AS can know/spy what the end-user is doing.
    • The access token can be transmitted/communicated to anybody, including herself.
    • The end-user MAY have an account on the printing service, but she is NOT REQUIRED to have one.
    • The person that gets the photos printed will need to disclose to the printing service a name and an address for the delivery
      (not necessarily her name and her home address) if she is not working at a kiosk and will need to pay for the printing (and postage).

    Denis

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


    --------------41826DD7A023B0FF9C0329E9-- From nobody Fri Mar 19 08:13:26 2021 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 3BB463A1844 for ; Fri, 19 Mar 2021 08:13: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, 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_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 ytOHoa8UG7PR for ; Fri, 19 Mar 2021 08:13:20 -0700 (PDT) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 6212D3A1843 for ; Fri, 19 Mar 2021 08:13:20 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id c204so6105117pfc.4 for ; Fri, 19 Mar 2021 08:13:20 -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=zsVL/MdPBcadF3AT/l2rvLnU2vlOm6fy289V3GHe5yQ=; b=acSKZGUHio3uKylfYsKW/+2E3JLJbdOcFPjb2vz2V5m/B0VLKcguuaXmir91YRasVc zTQ6qgMyZ9xfa2osTr186ARM+Hhzs33JKFd27O/n0+PkqUURnnpZbRdVZD0rBochl2y6 Bc/XEaesIRCIyJwhh7E8j+JkzVuukdl0D1RpSdMkHZCZ3antuk2L7A0p2G6JMp4K1rLu SYYuLl0iX7pdGJKAPewf3c25UrhA7cm9Gi5zKalW12dH/BayERzclnflFoFOsKhqxw4N 5t+TNbHpW5QqXqtgfYHSQH3Ud6XXAOp4vFHTx231GaHgLAnhKavnZPvb3OnC7UD70YEW gKzA== 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=zsVL/MdPBcadF3AT/l2rvLnU2vlOm6fy289V3GHe5yQ=; b=lco1gKrtDQZLRn9KqCzfMmjIeLXi/sepOGgYsYDy5MlKiYD9Ot99D3gmlRZtn0fPvI z5e6BY+kbsFeMedbZ1ZrF+KlOc6SAAwoR9nbdcVM9iqPhtBOXKHKTOUPTwUV6s5vZ8r/ f4xdLSl7Hy/bxlVxDr9D0slKNLlAPTGzBwOKqyWjqkny/WTL/SfbC93/DOM7ZkOSiVlX E882x73qEXO4Oz+DuWA5bCFVlALm8evUcP+rp5xNVlL+S9jrUHWd5VA0vQuRNjR29hpH h69fIqcnGwtRXM5feZBV1xn/sHGpiHBr7zeor8/4xzPZ6VyG4evM6yn2KpYW8STyW1uQ OAZw== X-Gm-Message-State: AOAM533sotZgc4WmriiN9UmSd+C4ljH3KfBG9vnCeJ3tw98nlWF2lCsn rqdYrroHUnY+TUht3qC50o9449bvWxvIGcL+BnQ= X-Google-Smtp-Source: ABdhPJz3UQHY1kigk/NQ9XgQVipJ0P+STTxVxJniiBnM69TPfX0f33C2xVH9naFSrPxBL09kKf24P49w1u+ToJsKWBU= X-Received: by 2002:aa7:9081:0:b029:1f9:26c9:1609 with SMTP id i1-20020aa790810000b02901f926c91609mr9503839pfa.54.1616166798065; Fri, 19 Mar 2021 08:13:18 -0700 (PDT) MIME-Version: 1.0 References: <43447446-4061-49F2-8486-5A196C3C75E2@mit.edu> <37a04505-84ef-aecf-6913-5aad8330c97c@free.fr> <3FE214B6-CF96-472D-853B-C7C5AC7A73AE@mit.edu> In-Reply-To: <3FE214B6-CF96-472D-853B-C7C5AC7A73AE@mit.edu> From: Alejandro Iacobelli Date: Fri, 19 Mar 2021 12:13:07 -0300 Message-ID: To: Justin Richer Cc: Adrian Gropper , Fabien Imbault , Steve Moore , txauth gnap Content-Type: multipart/alternative; boundary="000000000000e5875305bde527ab" Archived-At: Subject: Re: [GNAP] Should access tokens be opaque or not for the clients ? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 15:13:24 -0000 --000000000000e5875305bde527ab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Agree! So what are you saying the proposal should be? Random or sealed tokens? El El vie, 19 mar. 2021 a la(s) 10:04, Justin Richer escribi=C3=B3: > One of the best ways to protect information in the token is to not put it > in the token in the first place. This is why a some highly-sensitive > application profiles and deployments us randomized values as tokens. The = RS > has a way to dereference it, which is important. > > For downstream delegation, like one micro service calling another, we=E2= =80=99re > no longer talking about the client knowing the access token, we=E2=80=99r= e talking > about an RS at the first step. This is where non-opaque, or encrypted, or > other kinds of recoverable data structures come into play more directly. > > To Adrian=E2=80=99s point, sharing the QR code should be up to the AS=E2= =80=99s policy. If > Steve gives me a bearer artifact that isn=E2=80=99t attached to anything = that > identifies me, then it=E2=80=99s easy for me to share because the artifac= t is the > identity and proof all in one. The strawman description below sounds like > that. But it=E2=80=99s important in this design that the AS can also requ= ire me to > log in with a specific account, plus present a token, plus type in a secr= et > code, plus present a hardware key that completes a circuit in the right w= ay > (seems like something Steve would build, tbh), etc. But all of these aren= =E2=80=99t > a client talking to a resource, they=E2=80=99re the end-user presenting = things to > the AS so that the AS can make a policy decision to issue a token and all= ow > access. > > =E2=80=94 Justin > > On Mar 18, 2021, at 8:23 PM, Alejandro Iacobelli > wrote: > > The decision about "opaque" vs "sealed but recoverable" or "signed" > access_token goes way back on the stateless protocols session management. > > In my opinion, the software design principle that we must apply here is > the "need to know" principle. This means, the less information an attacke= r > could get, the better. One thing that JWS explse is all the context > information about a token, so an attacker can get lots of information jus= t > with a look. > > The next discussion will be what ways of generating opaque tokens are > there and which must we choose (Encrypted vs CSPRNG based). > > On Thu, 18 Mar 2021 at 21:17, Fabien Imbault > wrote: > >> Hi Adrian, >> >> I'm really not sure I understand here. >> >> I get the idea of putting a policy engine in front of your services to >> implement ZTA. But I'm not sure I get this way of framing things. It blu= rs >> functional roles and actual services, and most importantly if everything >> gets its own AS, it also gets by transitivity its RO'/RQ' (and then its >> AS-RO' etc) and so the complexity becomes staggering. >> Why do we need that? >> >> Fabien >> >> Le ven. 19 mars 2021 =C3=A0 00:55, Adrian Gropper a >> =C3=A9crit : >> >>> +1 This aligns with my healthcare use-case to the extent that Justin ca= n >>> transfer the capability granted by that QR code to Adrian who happens t= o be >>> nearby Steve's house. >>> >>> I've tried to capture some of this in my comment to #145 >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomm= ent-802388458 >>> >>> - Adrian >>> >>> On Thu, Mar 18, 2021 at 2:39 PM Justin Richer wrote: >>> >>>> Right, and in the GNAP model this becomes something my client instance >>>> presents to the AS when I show up. The AS can validate my presentation= of >>>> this item and give my client instance a token to call Steve=E2=80=99s = RS. Or if you >>>> wanted to get super fancy Steve=E2=80=99s AS could even challenge my c= lient >>>> instance and get a cryptographic response to prove I have the thing St= eve >>>> had me scan. But in both cases it=E2=80=99s part of things that the AS= collects in >>>> order to create the access token. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Mar 18, 2021, at 2:26 PM, Stephen Moore wrote: >>>> >>>> That in my mind works out great... Say I'm logged into my home hub/AS. >>>> Justin is over and agrees to cat sit, I pull up my client app, and gen= erate >>>> a QR code that has maybe The AS URI, the HomeHub API URL, and the 'spe= cial >>>> token to present to AS for a real token'. Justin scans that QR code wi= th >>>> his home controller app, and BAM, he's onboarded as a guest without ev= en >>>> logging into my AS or me dealing with his Auth provider. >>>> -steve >>>> >>>> On Thu, Mar 18, 2021 at 2:08 PM Justin Richer wrote: >>>> >>>>> I think Steve=E2=80=99s use case gives an interesting example of some= thing >>>>> that I believe Adrian=E2=80=99s been talking about as well =E2=80=94 = delegating to another >>>>> person. >>>>> >>>>> We traditionally think of delegation at the AS to mean =E2=80=9Ca dif= ferent >>>>> user account logs in to the AS=E2=80=9D, and it=E2=80=99s important t= o know that this does >>>>> in fact work. But this could just as easily be =E2=80=9CSteve sends h= is friend an >>>>> artifact to present to the AS to get access=E2=80=9D. This isn=E2=80= =99t Steve (or Steve=E2=80=99s >>>>> client software) getting and sending an access token, this is sending= some >>>>> other set of rights credential to his friend, or his friend=E2=80=99s= software. So >>>>> then Steve=E2=80=99s AS can have policy that says =E2=80=9Cwhen I see= this rights >>>>> credential, give an access token for the following attenuated things, >>>>> because Steve said so=E2=80=9D. The AS doesn=E2=80=99t even ever need= to know who Steve=E2=80=99s >>>>> friend is! >>>>> >>>>> And importantly here, we don=E2=80=99t expect Steve=E2=80=99s friend = to bring their >>>>> own AS to the party. Steve=E2=80=99s RS has no reason to trust his fr= iend=E2=80=99s AS, let >>>>> alone his friend=E2=80=99s client. But Steve=E2=80=99s AS is in a pos= ition to know more >>>>> about the rights policies that Steve wants to apply, and so it can us= e >>>>> other technologies like VC=E2=80=99s, DIDs, OIDC, or any number of ot= her things to >>>>> let things go through. This pattern is exactly why I think we need to= think >>>>> of this in terms of what=E2=80=99s currently called =E2=80=9Cinteract= ion=E2=80=9D at the AS. It=E2=80=99s >>>>> not really just about how the end-user interacts, it=E2=80=99s about = how the AS >>>>> gathers all the consent and authorization information. I plan to rewr= ite >>>>> section 4 to that effect. >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Mar 18, 2021, at 1:58 PM, Stephen Moore wrote: >>>>> >>>>> I'm having some concerns with the way you're flipping the trust here >>>>> Denis. You seem to indicate that the user has trust in the RS and the >>>>> Client and has to gain the trust of the AS. I feel like the least >>>>> trustworthy portion of the architecture is the client, because that s= eems >>>>> like it is the most interchangeable component. >>>>> Let me explain by way of a use case I have in mind. >>>>> Let's say I have a smart home. I have devices and data storage and >>>>> rule engines that are parts of sensors and hubs I buy for the house. = I have >>>>> a trust in those devices, because it's hardware, if the company is le= aking >>>>> data at the hardware level there isn't much I can do other than buy >>>>> different sensors. >>>>> In this case, the primary home hub, which is under control of the >>>>> homeowner, would also be the AS, as well as a policy agent. Authenti= cation >>>>> in the example is outsourced to whatever auth providers you want. I s= et up >>>>> my home using a google account, a friend is staying and wants access = and >>>>> uses FB for auth... whatever. >>>>> The part that I have little control over is the client my friend uses >>>>> on his phone. Or if I change the client on the tablet in the kitchen = to try >>>>> out something new. These pieces might be single page web apps, they m= ight >>>>> be downloaded apps, etc. I do not want them having any additional >>>>> information than is necessary. If I give my friend permission to unlo= ck the >>>>> door, and control the lights because they are feeding my cats while I= 'm >>>>> away, the client doesn't need to know anything beyond, I see this hom= e >>>>> controller, and I have access to these lights and that door lock. >>>>> >>>>> In your scenarios, the client is spy by design, and if it is a web >>>>> app, I don't trust them to not grab my user email address from the AS= and >>>>> put it on a mailing list it sells to some sketchy company, when the o= nly >>>>> other component that needs that information is the RS. >>>>> >>>>> -steve >>>>> >>>>> On Thu, Mar 18, 2021 at 1:21 PM Denis wrote: >>>>> >>>>>> I have changed the title of this thread, since the original topic ha= s >>>>>> been closed. >>>>>> >>>>>> Justin, you are raising the following question: >>>>>> >>>>>> The question I have is =E2=80=94 why does the client need to know wh= at=E2=80=99s in >>>>>> the token? >>>>>> Not if they could possibly know, but why would we expect a client to >>>>>> know and manage the contents of the token? >>>>>> >>>>>> The answer is quite simple: so that the end-user may have confidence >>>>>> into the architecture. >>>>>> The seventh of the eleven privacy principles from ISO 29100 (page 14= ) >>>>>> is: >>>>>> >>>>>> *7. Openness, transparency and notice * >>>>>> >>>>>> If the access token is considered as a black box for the end-user, i= t >>>>>> cannot be confident about the content of the access token. >>>>>> Such access token may disclose some private information without the >>>>>> consent of the end-user. If the access token that it has obtained >>>>>> does not match with what has been requested, the client will first >>>>>> not forward the access token to the RS and then will complain about = the AS. >>>>>> >>>>>> Denis >>>>>> >>>>>> >>>>>> Hi Justin, >>>>>> >>>>>> "The access token is fundamentally a conversational artifact between >>>>>> the AS and the RS which the client is the carrier of." >>>>>> That's right, and a good opportunity to distinguish between the need >>>>>> for token inspection (i.e. a runtime verification, wherever that may= be) >>>>>> and the need to negotiate the token format (a discovery). That last >>>>>> part could very well be an extension, as a way to open up the ecosys= tem >>>>>> beyond JWTs (which are fine, but come with their own limitations). >>>>>> >>>>>> Fabien >>>>>> >>>>>> On Thu, Mar 18, 2021 at 5:59 PM Justin Richer >>>>>> wrote: >>>>>> >>>>>>> On Mar 18, 2021, at 11:30 AM, Alan Karp wrote= : >>>>>>> >>>>>>> >>>>>>> Justin Richer wrote: >>>>>>> >>>>>>>> On Mar 18, 2021, at 12:08 AM, Alan Karp >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> Adrian Gropper wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> Is there an AS involved in the delegation? How and where in the >>>>>>>>> lifecycle of the protected resource? >>>>>>>>> >>>>>>>> >>>>>>>> If tokens are certificates, the AS need not be involved in >>>>>>>> subsequent delegations. The AS must be involved if the tokens are= opaque. >>>>>>>> >>>>>>>> >>>>>>>> Tokens are opaque to the client instance. They are not opaque to >>>>>>>> the AS. They might be opaque to the RS, but that depends on the ki= nd of >>>>>>>> relationship the RS and AS have. GNAP should allow different optio= ns here >>>>>>>> as there are different use cases for that. >>>>>>>> >>>>>>> >>>>>>> Tokens are not opaque to the client in SPKI, zcap-ld, Orie's >>>>>>> implementation with VCs, or our Zebra Copy work. Why must they be = in GNAP? >>>>>>> >>>>>>> >>>>>>> The existence of the AS is exactly the reason for this. The AS is >>>>>>> the role that =E2=80=9Cknowledge about the token contents=E2=80=9D = has been outsourced to >>>>>>> in the GNAP model (which is based on the OAuth model). >>>>>>> >>>>>>> It brings significant simplicity for the client developer. The >>>>>>> question I have is =E2=80=94 why does the client need to know what= =E2=80=99s in the token? >>>>>>> Not if they could possibly know, but why would we expect a client t= o know >>>>>>> and manage the contents of the token? >>>>>>> >>>>>>> The access token is fundamentally a conversational artifact between >>>>>>> the AS and the RS which the client is the carrier of. The client is= not the >>>>>>> audience of the token, nor the creator of the token, nor even the m= anager >>>>>>> of the token and the rights it represents. The client as a simple c= arrier >>>>>>> is a powerful model that allows the security layer to get out of th= e way of >>>>>>> the actual application logic that developers want to do. >>>>>>> >>>>>>> =E2=80=94 Justin >>>>>>> >>>>>>> >>>>>>> -------------- >>>>>>> Alan Karp >>>>>>> >>>>>>> >>>>>>> On Thu, Mar 18, 2021 at 4:56 AM Justin Richer >>>>>>> wrote: >>>>>>> >>>>>>>> On Mar 18, 2021, at 12:08 AM, Alan Karp >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> Adrian Gropper wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> Is there an AS involved in the delegation? How and where in the >>>>>>>>> lifecycle of the protected resource? >>>>>>>>> >>>>>>>> >>>>>>>> If tokens are certificates, the AS need not be involved in >>>>>>>> subsequent delegations. The AS must be involved if the tokens are= opaque. >>>>>>>> >>>>>>>> >>>>>>>> Tokens are opaque to the client instance. They are not opaque to >>>>>>>> the AS. They might be opaque to the RS, but that depends on the ki= nd of >>>>>>>> relationship the RS and AS have. GNAP should allow different optio= ns here >>>>>>>> as there are different use cases for that. >>>>>>>> >>>>>>>> It would probably be worthwhile to separate the portions of the >>>>>>>> spec that talk about the RS-AS relationship into its own standalon= e >>>>>>>> document. A similar approach was taken in UMA2 and it was helpful.= (Though >>>>>>>> admittedly, as with anything, there are missteps there that we can >>>>>>>> hopefully learn from.) >>>>>>>> >>>>>>>> =E2=80=94 Justin >>>>>>>> >>>>>>>> >>>>>>>> -------------- >>>>>>>> Alan Karp >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper < >>>>>>>> agropper@healthurl.com> wrote: >>>>>>>> >>>>>>>>> Sure! >>>>>>>>> >>>>>>>>> Is there an AS involved in the delegation? How and where in the >>>>>>>>> lifecycle of the protected resource? >>>>>>>>> >>>>>>>>> Also your use of "the client" seems to imply that either there is >>>>>>>>> only one client or the client doesn't matter. Which is it? >>>>>>>>> >>>>>>>>> Adrian >>>>>>>>> >>>>>>>>> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault < >>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Thanks for that. >>>>>>>>>> >>>>>>>>>> Trying to reframe it: >>>>>>>>>> GNAP is defined as a delegation protocol so the main intent is >>>>>>>>>> related to a delegate of the RO (i.e. the end user) that wishes = to access >>>>>>>>>> the RO's protected resources, through the client. >>>>>>>>>> >>>>>>>>>> Fabien >>>>>>>>>> >>>>>>>>>> Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper < >>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>> >>>>>>>>>>> At various points in the lifecycle of the protected resource th= e >>>>>>>>>>> client at the resource server (RS) might be: >>>>>>>>>>> >>>>>>>>>>> - The RO (subject) user agent trading payment for a service >>>>>>>>>>> promise >>>>>>>>>>> - The RO user agent using the promise to access the >>>>>>>>>>> protected resource >>>>>>>>>>> - A delegate of the RO user agent using a different client >>>>>>>>>>> >>>>>>>>>>> What's vague is where the GNAP AS enters the picture as >>>>>>>>>>> described above. How would you describe it? >>>>>>>>>>> >>>>>>>>>>> Adrian >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault < >>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Adrian >>>>>>>>>>>> >>>>>>>>>>>> I'm still confused why you're saying the terminology is vague. >>>>>>>>>>>> I get the "power" neutrality is not to your liking, but RQ / >>>>>>>>>>>> user agent is no better in my view. >>>>>>>>>>>> >>>>>>>>>>>> Can you elaborate? >>>>>>>>>>>> >>>>>>>>>>>> Fabien >>>>>>>>>>>> >>>>>>>>>>>> Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper < >>>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>>> >>>>>>>>>>>>> I'm sure you're right. Our vague terminology around >>>>>>>>>>>>> client and end-user leads to my confusion. If GNAP is primari= ly about >>>>>>>>>>>>> delegation then, of course, we should avoid any incentives to= impersonate >>>>>>>>>>>>> or we're wasting our time. This is partly why I'm trying to s= tudy up on >>>>>>>>>>>>> capabilities and asking for expert advice from folks like Ala= n Karp and >>>>>>>>>>>>> Mark Miller (cc'd) >>>>>>>>>>>>> >>>>>>>>>>>>> As best I can understand it, the RS has only two choices, it >>>>>>>>>>>>> can: >>>>>>>>>>>>> >>>>>>>>>>>>> - store an attribute of the RO a [DID, email address, GNAP >>>>>>>>>>>>> AS URL], or >>>>>>>>>>>>> - hand the RO a capability as a sort-of promise and avoid >>>>>>>>>>>>> making any entries in an ACL or equivalent. >>>>>>>>>>>>> >>>>>>>>>>>>> When a token comes back to the RS, it will either be: >>>>>>>>>>>>> >>>>>>>>>>>>> - validated according to something associated with the >>>>>>>>>>>>> stored RO attribute, or >>>>>>>>>>>>> - signed by the RS itself. >>>>>>>>>>>>> >>>>>>>>>>>>> Either way, trust in the client seems moot. >>>>>>>>>>>>> >>>>>>>>>>>>> Adrian >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper < >>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker < >>>>>>>>>>>>>> tobias.looker@mattr.global> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > A client might not have a DID but it could have a VC as a >>>>>>>>>>>>>>> certificate of authenticity linked to some audit mechanism. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> To me a VC would come under the assertions umbrella (that i= s >>>>>>>>>>>>>>> to say a VC could be one type of valid assertion). The clie= nt may possess >>>>>>>>>>>>>>> or been presented with a VC that it could include in its re= quest to the AS >>>>>>>>>>>>>>> as a way to identify the subject and perhaps prove authenti= cation and >>>>>>>>>>>>>>> authorization. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I do not assume that the client that interacts with the AS t= o >>>>>>>>>>>>>> make a request and receive a token is the same as the client= that will >>>>>>>>>>>>>> present the token to the RS. In the US HIPAA use-case, for e= xample, the >>>>>>>>>>>>>> root of trust is a contract between the patient-subject and = the >>>>>>>>>>>>>> doctor-requesting party but the doctor workflow is expected = to delegate the >>>>>>>>>>>>>> token to some other end-user that may be using a totally dif= ferent client >>>>>>>>>>>>>> such as an EHR. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> If the client that gets the token is not same as the client >>>>>>>>>>>>>> that uses the token, that is a violation of core security pr= inciples as it >>>>>>>>>>>>>> allows for (and really designs for) impersonation by client = software. I >>>>>>>>>>>>>> would have no reason to trust client software that would han= d its >>>>>>>>>>>>>> credentials over to another piece of software, and in fact I= shouldn=E2=80=99t >>>>>>>>>>>>>> trust it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think you may be conflating several different kinds of >>>>>>>>>>>>>> parties under the =E2=80=9Cclient=E2=80=9D umbrella here, th= ough. It=E2=80=99s entirely possible >>>>>>>>>>>>>> that one client might call an RS that in turn acts as a clie= nt for >>>>>>>>>>>>>> something else down stream. But each of those hops is differ= ent from the >>>>>>>>>>>>>> last. >>>>>>>>>>>>>> >>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> 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 >>>> >>> -- >>> 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 >> > > > -- > You know nothing Jon Snow! > > > -- You know nothing Jon Snow! --000000000000e5875305bde527ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Agree! So what are you saying the proposal should be? Ran= dom or sealed tokens?

    El El vie, 19 mar. 2021 a la(s) 10:04, Justin Ric= her <jricher@mit.edu> escribi= =C3=B3:
    One of the best ways to protect information in the = token is to not put it in the token in the first place. This is why a some = highly-sensitive application profiles and deployments us randomized values = as tokens. The RS has a way to dereference it, which is important.

    =
    For downstream delegation, like one micro service calling anothe= r, we=E2=80=99re no longer talking about the client knowing the access toke= n, we=E2=80=99re talking about an RS at the first step. This is where non-o= paque, or encrypted, or other kinds of recoverable data structures come int= o play more directly.=C2=A0

    To Adrian=E2=80=99s po= int, sharing the QR code should be up to the AS=E2=80=99s policy. If Steve = gives me a bearer artifact that isn=E2=80=99t attached to anything that ide= ntifies me, then it=E2=80=99s easy for me to share because the artifact is = the identity and proof all in one. The strawman description below sounds li= ke that. But it=E2=80=99s important in this design that the AS can also req= uire me to log in with a specific account, plus present a token, plus type = in a secret code, plus present a hardware key that completes a circuit in t= he right way (seems like something Steve would build, tbh), etc. But all of= these aren=E2=80=99t a client talking to a resource, they=E2=80=99re the e= nd-user =C2=A0presenting things to the AS so that the AS can make a policy = decision to issue a token and allow access.=C2=A0

    =C2= =A0=E2=80=94 Justin

    On Mar 18, 2= 021, at 8:23 PM, Alejandro Iacobelli <aiacobelli.sec@gmail.com> wrote:
    The decision about "opaque&q= uot; vs "sealed but recoverable" or "signed" access_tok= en goes way back on the stateless protocols session management.=C2=A0
    =

    In my opinion, the software design princip= le that we must apply here is the "need to know" principle. This = means, the=C2=A0less information an attacker could get, the better. One thi= ng that JWS explse is all the context information about a token, so an atta= cker=C2=A0can get lots of information just with a look.=C2=A0
    The next discussion will be what ways of generating opaque toke= ns are there and which must we choose (Encrypted vs CSPRNG based).

    On = Thu, 18 Mar 2021 at 21:17, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Adrian,

    <= /div>
    I'm really not sure I understand here.=C2=A0
    =

    I get the idea of putting a p= olicy engine in front of your services to implement ZTA. But I'm not su= re I get this way of framing things. It blurs functional roles and actual s= ervices, and most importantly if everything gets its own AS, it also gets b= y transitivity its RO'/RQ' (and then its AS-RO' etc) and so the= complexity becomes staggering.=C2=A0
    Why do we need= that?=C2=A0

    Fabien=C2= =A0

    Le ven. 19 mars 2021 =C3=A0 00:55, Adrian Gropper <agropper@healthurl.c= om> a =C3=A9crit=C2=A0:
    <= div dir=3D"ltr">+1 This aligns with my healthcare use-case to the extent th= at Justin can transfer the capability granted by that QR code to Adrian who= happens to be nearby Steve's house.

    I've tr= ied to capture some of this in my comment to #145=C2=A0https://github.com/ietf-wg-gnap/gnap= -core-protocol/issues/145#issuecomment-802388458

    - Adrian

    On Thu, Mar 18, 2021 at 2:39 PM Justin Richer <jrich= er@mit.edu> wrote:
    Right, and in the= GNAP model this becomes something my client instance presents to the AS wh= en I show up. The AS can validate my presentation of this item and give my = client instance a token to call Steve=E2=80=99s RS. Or if you wanted to get= super fancy Steve=E2=80=99s AS could even challenge my client instance and= get a cryptographic response to prove I have the thing Steve had me scan. = But in both cases it=E2=80=99s part of things that the AS collects in order= to create the access token.

    =C2=A0=E2=80=94 Justin=

    On Mar 18, 2021, at 2:26 PM, St= ephen Moore <srmoore@gmail.com> wrote:

    That in my mind works out great... Say I'm logged into my home hub/= AS. Justin is over and agrees to cat sit, I pull up my client app, and gene= rate a QR code that has maybe The AS URI, the HomeHub API URL, and the '= ;special token to present to AS for a real token'. Justin scans that QR= code with his home controller app, and BAM, he's onboarded as a guest = without even logging into my AS or me dealing with his Auth provider.
    -= steve

    On Thu, Mar 18, 2021 at 2:08 PM Justin Richer <jricher@mit.edu> wrote:
    I think Steve=E2=80=99s use ca= se gives an interesting example of something that I believe Adrian=E2=80=99= s been talking about as well =E2=80=94 delegating to another person.
    We traditionally think of delegation at the AS to mean =E2=80= =9Ca different user account logs in to the AS=E2=80=9D, and it=E2=80=99s im= portant to know that this does in fact work. But this could just as easily = be =E2=80=9CSteve sends his friend an artifact to present to the AS to get = access=E2=80=9D. This isn=E2=80=99t Steve (or Steve=E2=80=99s client softwa= re) getting and sending an access token, this is sending some other set of = rights credential to his friend, or his friend=E2=80=99s software. So then = Steve=E2=80=99s AS can have policy that says =E2=80=9Cwhen I see this right= s credential, give an access token for the following attenuated things, bec= ause Steve said so=E2=80=9D. The AS doesn=E2=80=99t even ever need to know = who Steve=E2=80=99s friend is!=C2=A0

    And important= ly here, we don=E2=80=99t expect Steve=E2=80=99s friend to bring their own = AS to the party. Steve=E2=80=99s RS has no reason to trust his friend=E2=80= =99s AS, let alone his friend=E2=80=99s client. But Steve=E2=80=99s AS is i= n a position to know more about the rights policies that Steve wants to app= ly, and so it can use other technologies like VC=E2=80=99s, DIDs, OIDC, or = any number of other things to let things go through. This pattern is exactl= y why I think we need to think of this in terms of what=E2=80=99s currently= called =E2=80=9Cinteraction=E2=80=9D at the AS. It=E2=80=99s not really ju= st about how the end-user interacts, it=E2=80=99s about how the AS gathers = all the consent and authorization information. I plan to rewrite section 4 = to that effect.

    =C2=A0=E2=80=94 Justin

    I'm = having some concerns with the way you're flipping the trust here Denis.= You seem to indicate that the user has trust in the RS and the Client and = has to gain the trust of the AS. I feel like the least trustworthy portion = of the architecture is the client, because that seems like it is the most i= nterchangeable component.
    =C2=A0Let me explain by way of a use case I h= ave in mind.
    Let's say I have a smart home. I have devices an= d data storage and rule engines that are parts of sensors and hubs I buy fo= r the house. I have a trust in those devices, because it's hardware, if= the company is leaking data at the hardware level there isn't much I c= an do other than buy different sensors.
    In this case, the primary= home hub, which is under control of the homeowner, would also be the AS, a= s well as a policy agent.=C2=A0 Authentication in the example is outsourced= to whatever auth providers you want. I set up my home using a google accou= nt, a friend is staying and wants access and uses FB for auth... whatever.<= /div>
    The part that I have little control over is the client my friend = uses on his phone. Or if I change the client on the tablet in the kitchen t= o try out something new. These pieces=C2=A0might be single page web apps, t= hey might be downloaded apps, etc. I do not want them having any additional= information than is necessary. If I give my friend permission to unlock th= e door, and control the lights because they are feeding my cats while I'= ;m away, the client doesn't need to know anything beyond, I see this ho= me controller, and I have access to these lights and that door lock.
    <= div>
    In your scenarios, the client is spy by design, and if i= t is a web app, I don't trust them to not grab my user email address fr= om the=C2=A0AS and put it on a mailing list it sells to some sketchy compan= y,=C2=A0when the only other component=C2=A0that needs that information is t= he RS.

    -steve

    On Thu, Mar 18, 2021 at 1:21 PM= Denis <denis.ietf@free.fr> wrote:
    =20 =20 =20
    I have changed the title of this thread, since the original topic has been closed.

    Justin, you are raising the following question:
    The question I have is =E2=80=94 why does the client need to know what=E2=80=99s in the token?
    Not if they could possibly know, but why would we expect a client to know and manage the contents of the token?
    The answer is quite simple: so that the end-user may have confidence into the architecture.
    The seventh of the eleven privacy principles from ISO 29100 (page 14) is:
    7. Openness, transparency and notice
    If the access token is considered as a black box for the end-user, it cannot be confident about the content of the access token.
    Such access token may disclose some private information without the consent of the end-user. If the access token that it has obtained
    does not match with what has been requested, the client will first not forward the access token to the RS and then will complain about the AS.

    Denis


    =20
    Hi Justin,=C2=A0

    "The access token is fundamentally a conversational artifact between the AS and the RS which the client is the carrier of."
    That's right,=C2=A0and a good=C2=A0opportunity to distingu= ish between the need for token=C2=A0inspection (i.e. a runtime verification, wherever that may be)
    and the need to negotiate the token format (a discovery). That last part could very well be an extension, as a way to open up the ecosystem
    beyond JWTs (which are fine, but come with their own limitations).=C2=A0

    Fabien

    On Thu, Mar 18, 2021 at 5:59 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 11:30 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 12:08 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    A= drian Gropper <agropper@healthurl.co= m> wrote:

    Is there an AS involved in the delegation? How and where in the lifecycle=C2=A0of the protected resource?=C2=A0

    If tokens are certificates, the AS need not be involved in subsequent delegations.=C2=A0 The AS must be involved if the tokens are opaque.=C2=A0

    Tokens are opaque to the client instance. They are not opaque to the AS. They might be opaque to the RS, but that depends on the kind of relationship the RS and AS have. GNAP should allow different options here as there are different use cases for that.

    Tokens are not opaque to the client in SPKI, zcap-ld, Orie's implementation with VCs= , or our Zebra Copy work.=C2=A0 Why must they be in GNAP?

    The existence of the AS is exactly the reason for this. The AS is the role that =E2=80=9Cknowledge about the = token contents=E2=80=9D has been outsourced to in the GNAP model (which is based on the OAuth model).

    It brings significant simplicity for the client developer. The question I have is =E2=80=94 why does the cl= ient need to know what=E2=80=99s in the token? Not if they could possibly know, but why would we expect a client to know and manage the contents of the token?=C2=A0

    The access token is fundamentally a conversational artifact between the AS and the RS which the client is the carrier of. The client is not the audience of the token, nor the creator of the token, nor even the manager of the token and the rights it represents. The client as a simple carrier is a powerful model that allows the security layer to get out of the way of the actual application logic that developers want to do.

    =C2=A0=E2=80=94 Justin


    --------------
    Alan Karp


    On Thu, Mar 18, 2021 at 4:56 AM Justin Richer <jricher@mit.edu&= gt; wrote:
    On Mar 18, 2021, at 12:08 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    A= drian Gropper <agropper@healthurl.co= m> wrote:

    Is there an AS involved in the delegation? How and where in the lifecycle=C2=A0of the protected resource?=C2=A0

    If tokens are certificates, the AS need not be involved in subsequent delegations.=C2=A0 The AS must be involved if the tokens are opaque.=C2=A0

    Tokens are opaque to the client instance. They are not opaque to the AS. They might be opaque to the RS, but that depends on the kind of relationship the RS and AS have. GNAP should allow different options here as there are different use cases for that.

    It would probably be worthwhile to separate the portions of the spec that talk about the RS-AS relationship into its own standalone document. A similar approach was taken in UMA2 and it was helpful. (Though admittedly, as with anything, there are missteps there that we can hopefully learn from.)

    =C2=A0=E2=80=94 Justin


    --------------
    Alan Karp


    O= n Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper <agropper@healt= hurl.com> wrote:
    Sure!=C2=A0

    Is there an AS involved in the delegation? How and where in the lifecycle=C2=A0of the protected resource?=C2=A0

    Also your use of "the client" seems to imply tha= t either there is only one client or the client doesn'= t matter. Which is it?

    Adrian

    On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault <fabien.imbault@= gmail.com> wrote:
    Thanks for that.=C2=A0

    Trying to reframe it:
    GNAP is defined as a delegation protocol so the main intent is related to a delegate of the RO (i.e. the end user) that wishes to access the RO's protected resources, through the client.=C2=A0

    Fabien=C2=A0

    Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper <agropper@healthur= l.com> a =C3=A9crit=C2=A0:
    At various points in the lifecycle=C2=A0of t= he protected resource the client at the resource server (RS) might be:
    • The RO (subject) user agent trading payment for a service promise
    • The RO user agent using the promise to access the protected resource
    • A delegate of the RO user agent using a different client
    What's vague is where the GNAP AS enters the picture as described above. How would you describe it?

    Adrian


    On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Adrian
    <= br>
    I= 'm still confused why you're saying the terminology is vague.=C2=A0
    I get the "power" neutrality is not to your liking, but RQ / user agent is no better in my view.=C2=A0=
    <= br>
    C= an you elaborate?=C2=A0<= /div>
    <= br>
    F= abien=C2=A0

    Le jeu. 18 mars 2021 =C3=A0 00:18= , Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2= =A0:
    = I'm sure you're right. Our vague terminology=C2=A0= around client=C2=A0and=C2=A0end-user leads to my confusion. If GNAP is primarily a= bout delegation=C2=A0t= hen, of course, we should=C2=A0avoid any incentives to impersonate or we're wasting our time. This is partly why I'= m trying to study up on capabilities and asking for expert advice from folks like Alan Karp and Mark Miller (cc'd)

    As best I can understand it, the RS has only two choices, it can:
    • store an attribute of the RO a [DID, email address, GNAP AS URL], or
    • hand the RO a capability as a sort-of promise and avoid making any entries in an ACL or equivalent.
    When a token comes back to the RS, it will either be:
    • validated according to something associated with the stored RO attribute, or
    • signed by the RS itself.
    Either way, trust in the client seems moot.

    Adrian



    On Wed, Mar 17, 2021 at 5:29 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 17, 2021, at 4:55 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    = On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <tobias.looker@mattr.global> wrote:
    <snip>=
    > A client might not have a DID but it could have a VC as a certificate of authenticity linked to some audit mechanism.

    To me a VC would come under the assertions umbrella (that is to say a VC could be one type of valid assertion). The client may possess or been presented with a VC that it could include in its request to the AS as a way to identify the subject and perhaps prove authentication and authorization.

    I do not assume that the client that interacts with the AS to make a request and receive a token is the same as the client that will present the token to the RS. In the US HIPAA use-case, for example, the root of trust is a contract between the patient-subject and the doctor-requesting party but the doctor workflow is expected to delegate the token to some other end-user that may be using a totally different client such as an EHR.


    If the client that gets the token is not same as the client that uses the token, that is a violation of core security principles as it allows for (and really designs for) impersonation by client software. I would have no reason to trust client software that would hand its credentials over to another piece of software, and in fact I shouldn=E2=80=99t trust it.=C2=A0

    I think you may be conflating several different kinds of parties under the =E2=80=9Cclie= nt=E2=80=9D umbrella here, though. It=E2=80= =99s entirely possible that one client might call an RS that in turn acts as a client for something else down stream. But each of those hops is different from the last.

    =C2=A0=E2=80= =94 Justin





    --
    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

    =

    --
    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


    --
    You know nothing Jon Snow!

    --
    You know nothing Jon Snow!
    --000000000000e5875305bde527ab-- From nobody Fri Mar 19 08:37:22 2021 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 F04813A18AB for ; Fri, 19 Mar 2021 08:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.218 X-Spam-Level: X-Spam-Status: No, score=-4.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 6Pfa1VVEVukw for ; Fri, 19 Mar 2021 08:37:16 -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 7F2373A18AE for ; Fri, 19 Mar 2021 08:37:15 -0700 (PDT) Received: from [192.168.1.22] (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 12JFbA2A027881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Mar 2021 11:37:10 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_63F558EF-07BA-45F3-A530-0BFB92BB0CCE" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 19 Mar 2021 11:37:09 -0400 In-Reply-To: Cc: Adrian Gropper , Fabien Imbault , Steve Moore , txauth gnap To: Alejandro Iacobelli References: <43447446-4061-49F2-8486-5A196C3C75E2@mit.edu> <37a04505-84ef-aecf-6913-5aad8330c97c@free.fr> <3FE214B6-CF96-472D-853B-C7C5AC7A73AE@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Should access tokens be opaque or not for the clients ? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 15:37:21 -0000 --Apple-Mail=_63F558EF-07BA-45F3-A530-0BFB92BB0CCE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 My proposal is that the client instance shouldn=E2=80=99t care what=E2=80=99= s in the token, what format it is, etc. The RS can care and there should be choices that include random, sealed, = and even plainly signed tokens. That choice is part of the relationship = between the RS and AS, which the core GNAP protocol doesn=E2=80=99t = specify.=20 This is why I propose that we extract what=E2=80=99s now section 10 in = the draft and put it into a new document that can more directly discuss = that relationship. These different relationships should be modular.=20 =E2=80=94 Justin > On Mar 19, 2021, at 11:13 AM, Alejandro Iacobelli = wrote: >=20 > Agree! So what are you saying the proposal should be? Random or sealed = tokens? >=20 > El El vie, 19 mar. 2021 a la(s) 10:04, Justin Richer > escribi=C3=B3: > One of the best ways to protect information in the token is to not put = it in the token in the first place. This is why a some highly-sensitive = application profiles and deployments us randomized values as tokens. The = RS has a way to dereference it, which is important. >=20 > For downstream delegation, like one micro service calling another, = we=E2=80=99re no longer talking about the client knowing the access = token, we=E2=80=99re talking about an RS at the first step. This is = where non-opaque, or encrypted, or other kinds of recoverable data = structures come into play more directly.=20 >=20 > To Adrian=E2=80=99s point, sharing the QR code should be up to the = AS=E2=80=99s policy. If Steve gives me a bearer artifact that isn=E2=80=99= t attached to anything that identifies me, then it=E2=80=99s easy for me = to share because the artifact is the identity and proof all in one. The = strawman description below sounds like that. But it=E2=80=99s important = in this design that the AS can also require me to log in with a specific = account, plus present a token, plus type in a secret code, plus present = a hardware key that completes a circuit in the right way (seems like = something Steve would build, tbh), etc. But all of these aren=E2=80=99t = a client talking to a resource, they=E2=80=99re the end-user presenting = things to the AS so that the AS can make a policy decision to issue a = token and allow access.=20 >=20 > =E2=80=94 Justin >=20 >> On Mar 18, 2021, at 8:23 PM, Alejandro Iacobelli = > wrote: >>=20 >> The decision about "opaque" vs "sealed but recoverable" or "signed" = access_token goes way back on the stateless protocols session = management.=20 >>=20 >> In my opinion, the software design principle that we must apply here = is the "need to know" principle. This means, the less information an = attacker could get, the better. One thing that JWS explse is all the = context information about a token, so an attacker can get lots of = information just with a look.=20 >>=20 >> The next discussion will be what ways of generating opaque tokens are = there and which must we choose (Encrypted vs CSPRNG based). >>=20 >> On Thu, 18 Mar 2021 at 21:17, Fabien Imbault = > wrote: >> Hi Adrian, >>=20 >> I'm really not sure I understand here.=20 >>=20 >> I get the idea of putting a policy engine in front of your services = to implement ZTA. But I'm not sure I get this way of framing things. It = blurs functional roles and actual services, and most importantly if = everything gets its own AS, it also gets by transitivity its RO'/RQ' = (and then its AS-RO' etc) and so the complexity becomes staggering.=20 >> Why do we need that?=20 >>=20 >> Fabien=20 >>=20 >> Le ven. 19 mars 2021 =C3=A0 00:55, Adrian Gropper = > a =C3=A9crit : >> +1 This aligns with my healthcare use-case to the extent that Justin = can transfer the capability granted by that QR code to Adrian who = happens to be nearby Steve's house. >>=20 >> I've tried to capture some of this in my comment to #145 = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment= -802388458 = >>=20 >> - Adrian >>=20 >> On Thu, Mar 18, 2021 at 2:39 PM Justin Richer > wrote: >> Right, and in the GNAP model this becomes something my client = instance presents to the AS when I show up. The AS can validate my = presentation of this item and give my client instance a token to call = Steve=E2=80=99s RS. Or if you wanted to get super fancy Steve=E2=80=99s = AS could even challenge my client instance and get a cryptographic = response to prove I have the thing Steve had me scan. But in both cases = it=E2=80=99s part of things that the AS collects in order to create the = access token. >>=20 >> =E2=80=94 Justin >>=20 >>> On Mar 18, 2021, at 2:26 PM, Stephen Moore > wrote: >>>=20 >>> That in my mind works out great... Say I'm logged into my home = hub/AS. Justin is over and agrees to cat sit, I pull up my client app, = and generate a QR code that has maybe The AS URI, the HomeHub API URL, = and the 'special token to present to AS for a real token'. Justin scans = that QR code with his home controller app, and BAM, he's onboarded as a = guest without even logging into my AS or me dealing with his Auth = provider. >>> -steve >>>=20 >>> On Thu, Mar 18, 2021 at 2:08 PM Justin Richer > wrote: >>> I think Steve=E2=80=99s use case gives an interesting example of = something that I believe Adrian=E2=80=99s been talking about as well =E2=80= =94 delegating to another person. >>>=20 >>> We traditionally think of delegation at the AS to mean =E2=80=9Ca = different user account logs in to the AS=E2=80=9D, and it=E2=80=99s = important to know that this does in fact work. But this could just as = easily be =E2=80=9CSteve sends his friend an artifact to present to the = AS to get access=E2=80=9D. This isn=E2=80=99t Steve (or Steve=E2=80=99s = client software) getting and sending an access token, this is sending = some other set of rights credential to his friend, or his friend=E2=80=99s= software. So then Steve=E2=80=99s AS can have policy that says =E2=80=9Cw= hen I see this rights credential, give an access token for the following = attenuated things, because Steve said so=E2=80=9D. The AS doesn=E2=80=99t = even ever need to know who Steve=E2=80=99s friend is!=20 >>>=20 >>> And importantly here, we don=E2=80=99t expect Steve=E2=80=99s friend = to bring their own AS to the party. Steve=E2=80=99s RS has no reason to = trust his friend=E2=80=99s AS, let alone his friend=E2=80=99s client. = But Steve=E2=80=99s AS is in a position to know more about the rights = policies that Steve wants to apply, and so it can use other technologies = like VC=E2=80=99s, DIDs, OIDC, or any number of other things to let = things go through. This pattern is exactly why I think we need to think = of this in terms of what=E2=80=99s currently called =E2=80=9Cinteraction=E2= =80=9D at the AS. It=E2=80=99s not really just about how the end-user = interacts, it=E2=80=99s about how the AS gathers all the consent and = authorization information. I plan to rewrite section 4 to that effect. >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Mar 18, 2021, at 1:58 PM, Stephen Moore > wrote: >>>>=20 >>>> I'm having some concerns with the way you're flipping the trust = here Denis. You seem to indicate that the user has trust in the RS and = the Client and has to gain the trust of the AS. I feel like the least = trustworthy portion of the architecture is the client, because that = seems like it is the most interchangeable component. >>>> Let me explain by way of a use case I have in mind. >>>> Let's say I have a smart home. I have devices and data storage and = rule engines that are parts of sensors and hubs I buy for the house. I = have a trust in those devices, because it's hardware, if the company is = leaking data at the hardware level there isn't much I can do other than = buy different sensors. >>>> In this case, the primary home hub, which is under control of the = homeowner, would also be the AS, as well as a policy agent. = Authentication in the example is outsourced to whatever auth providers = you want. I set up my home using a google account, a friend is staying = and wants access and uses FB for auth... whatever. >>>> The part that I have little control over is the client my friend = uses on his phone. Or if I change the client on the tablet in the = kitchen to try out something new. These pieces might be single page web = apps, they might be downloaded apps, etc. I do not want them having any = additional information than is necessary. If I give my friend permission = to unlock the door, and control the lights because they are feeding my = cats while I'm away, the client doesn't need to know anything beyond, I = see this home controller, and I have access to these lights and that = door lock. >>>>=20 >>>> In your scenarios, the client is spy by design, and if it is a web = app, I don't trust them to not grab my user email address from the AS = and put it on a mailing list it sells to some sketchy company, when the = only other component that needs that information is the RS. >>>>=20 >>>> -steve >>>>=20 >>>> On Thu, Mar 18, 2021 at 1:21 PM Denis > wrote: >>>> I have changed the title of this thread, since the original topic = has been closed.=20 >>>>=20 >>>> Justin, you are raising the following question: >>>> The question I have is =E2=80=94 why does the client need to know = what=E2=80=99s in the token?=20 >>>> Not if they could possibly know, but why would we expect a client = to know and manage the contents of the token?=20 >>>> The answer is quite simple: so that the end-user may have = confidence into the architecture.=20 >>>> The seventh of the eleven privacy principles from ISO 29100 (page = 14) is: >>>> 7. Openness, transparency and notice=20 >>>> If the access token is considered as a black box for the end-user, = it cannot be confident about the content of the access token. >>>> Such access token may disclose some private information without the = consent of the end-user. If the access token that it has obtained=20 >>>> does not match with what has been requested, the client will first = not forward the access token to the RS and then will complain about the = AS. >>>>=20 >>>> Denis >>>>=20 >>>>=20 >>>>> Hi Justin,=20 >>>>>=20 >>>>> "The access token is fundamentally a conversational artifact = between the AS and the RS which the client is the carrier of." >>>>> That's right, and a good opportunity to distinguish between the = need for token inspection (i.e. a runtime verification, wherever that = may be)=20 >>>>> and the need to negotiate the token format (a discovery). That = last part could very well be an extension, as a way to open up the = ecosystem=20 >>>>> beyond JWTs (which are fine, but come with their own limitations).=20= >>>>>=20 >>>>> Fabien >>>>>=20 >>>>> On Thu, Mar 18, 2021 at 5:59 PM Justin Richer > wrote: >>>>> On Mar 18, 2021, at 11:30 AM, Alan Karp > wrote: >>>>>>=20 >>>>>> Justin Richer > wrote: >>>>>> On Mar 18, 2021, at 12:08 AM, Alan Karp > wrote: >>>>>>>=20 >>>>>>> Adrian Gropper > wrote: >>>>>>>=20 >>>>>>> Is there an AS involved in the delegation? How and where in the = lifecycle of the protected resource?=20 >>>>>>>=20 >>>>>>> If tokens are certificates, the AS need not be involved in = subsequent delegations. The AS must be involved if the tokens are = opaque.=20 >>>>>>=20 >>>>>> Tokens are opaque to the client instance. They are not opaque to = the AS. They might be opaque to the RS, but that depends on the kind of = relationship the RS and AS have. GNAP should allow different options = here as there are different use cases for that. >>>>>>=20 >>>>>> Tokens are not opaque to the client in SPKI, zcap-ld, Orie's = implementation with VCs, or our Zebra Copy work. Why must they be in = GNAP? >>>>>=20 >>>>> The existence of the AS is exactly the reason for this. The AS is = the role that =E2=80=9Cknowledge about the token contents=E2=80=9D has = been outsourced to in the GNAP model (which is based on the OAuth = model). >>>>>=20 >>>>> It brings significant simplicity for the client developer. The = question I have is =E2=80=94 why does the client need to know what=E2=80=99= s in the token? Not if they could possibly know, but why would we expect = a client to know and manage the contents of the token?=20 >>>>>=20 >>>>> The access token is fundamentally a conversational artifact = between the AS and the RS which the client is the carrier of. The client = is not the audience of the token, nor the creator of the token, nor even = the manager of the token and the rights it represents. The client as a = simple carrier is a powerful model that allows the security layer to get = out of the way of the actual application logic that developers want to = do. >>>>>=20 >>>>> =E2=80=94 Justin >>>>>=20 >>>>>>=20 >>>>>> -------------- >>>>>> Alan Karp >>>>>>=20 >>>>>>=20 >>>>>> On Thu, Mar 18, 2021 at 4:56 AM Justin Richer > wrote: >>>>>> On Mar 18, 2021, at 12:08 AM, Alan Karp > wrote: >>>>>>>=20 >>>>>>> Adrian Gropper > wrote: >>>>>>>=20 >>>>>>> Is there an AS involved in the delegation? How and where in the = lifecycle of the protected resource?=20 >>>>>>>=20 >>>>>>> If tokens are certificates, the AS need not be involved in = subsequent delegations. The AS must be involved if the tokens are = opaque.=20 >>>>>>=20 >>>>>> Tokens are opaque to the client instance. They are not opaque to = the AS. They might be opaque to the RS, but that depends on the kind of = relationship the RS and AS have. GNAP should allow different options = here as there are different use cases for that. >>>>>>=20 >>>>>> It would probably be worthwhile to separate the portions of the = spec that talk about the RS-AS relationship into its own standalone = document. A similar approach was taken in UMA2 and it was helpful. = (Though admittedly, as with anything, there are missteps there that we = can hopefully learn from.) >>>>>>=20 >>>>>> =E2=80=94 Justin >>>>>>=20 >>>>>>>=20 >>>>>>> -------------- >>>>>>> Alan Karp >>>>>>>=20 >>>>>>>=20 >>>>>>> On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper = > wrote: >>>>>>> Sure!=20 >>>>>>>=20 >>>>>>> Is there an AS involved in the delegation? How and where in the = lifecycle of the protected resource?=20 >>>>>>>=20 >>>>>>> Also your use of "the client" seems to imply that either there = is only one client or the client doesn't matter. Which is it? >>>>>>>=20 >>>>>>> Adrian >>>>>>>=20 >>>>>>> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault = > wrote: >>>>>>> Thanks for that.=20 >>>>>>>=20 >>>>>>> Trying to reframe it: >>>>>>> GNAP is defined as a delegation protocol so the main intent is = related to a delegate of the RO (i.e. the end user) that wishes to = access the RO's protected resources, through the client.=20 >>>>>>>=20 >>>>>>> Fabien=20 >>>>>>>=20 >>>>>>> Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper = > a =C3=A9crit : >>>>>>> At various points in the lifecycle of the protected resource the = client at the resource server (RS) might be: >>>>>>> The RO (subject) user agent trading payment for a service = promise >>>>>>> The RO user agent using the promise to access the protected = resource >>>>>>> A delegate of the RO user agent using a different client >>>>>>> What's vague is where the GNAP AS enters the picture as = described above. How would you describe it? >>>>>>>=20 >>>>>>> Adrian >>>>>>>=20 >>>>>>>=20 >>>>>>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault = > wrote: >>>>>>> Hi Adrian >>>>>>>=20 >>>>>>> I'm still confused why you're saying the terminology is vague.=20= >>>>>>> I get the "power" neutrality is not to your liking, but RQ / = user agent is no better in my view.=20 >>>>>>>=20 >>>>>>> Can you elaborate?=20 >>>>>>>=20 >>>>>>> Fabien=20 >>>>>>>=20 >>>>>>> Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper = > a =C3=A9crit : >>>>>>> I'm sure you're right. Our vague terminology around client and = end-user leads to my confusion. If GNAP is primarily about delegation = then, of course, we should avoid any incentives to impersonate or we're = wasting our time. This is partly why I'm trying to study up on = capabilities and asking for expert advice from folks like Alan Karp and = Mark Miller (cc'd) >>>>>>>=20 >>>>>>> As best I can understand it, the RS has only two choices, it = can: >>>>>>> store an attribute of the RO a [DID, email address, GNAP AS = URL], or >>>>>>> hand the RO a capability as a sort-of promise and avoid making = any entries in an ACL or equivalent. >>>>>>> When a token comes back to the RS, it will either be: >>>>>>> validated according to something associated with the stored RO = attribute, or >>>>>>> signed by the RS itself. >>>>>>> Either way, trust in the client seems moot. >>>>>>>=20 >>>>>>> Adrian >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer > wrote: >>>>>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper = > wrote: >>>>>>>>=20 >>>>>>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker = > wrote: >>>>>>>> >>>>>>>> > A client might not have a DID but it could have a VC as a = certificate of authenticity linked to some audit mechanism. >>>>>>>>=20 >>>>>>>> To me a VC would come under the assertions umbrella (that is to = say a VC could be one type of valid assertion). The client may possess = or been presented with a VC that it could include in its request to the = AS as a way to identify the subject and perhaps prove authentication and = authorization. >>>>>>>>=20 >>>>>>>> I do not assume that the client that interacts with the AS to = make a request and receive a token is the same as the client that will = present the token to the RS. In the US HIPAA use-case, for example, the = root of trust is a contract between the patient-subject and the = doctor-requesting party but the doctor workflow is expected to delegate = the token to some other end-user that may be using a totally different = client such as an EHR. >>>>>>>>=20 >>>>>>>=20 >>>>>>> If the client that gets the token is not same as the client that = uses the token, that is a violation of core security principles as it = allows for (and really designs for) impersonation by client software. I = would have no reason to trust client software that would hand its = credentials over to another piece of software, and in fact I shouldn=E2=80= =99t trust it.=20 >>>>>>>=20 >>>>>>> I think you may be conflating several different kinds of parties = under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80=99s = entirely possible that one client might call an RS that in turn acts as = a client for something else down stream. But each of those hops is = different from the last. >>>>>>>=20 >>>>>>> =E2=80=94 Justin >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>> --=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 = >>>=20 >>=20 >> --=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 = >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >>=20 >>=20 >> --=20 >> You know nothing Jon Snow! >=20 > --=20 > You know nothing Jon Snow! --Apple-Mail=_63F558EF-07BA-45F3-A530-0BFB92BB0CCE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 My = proposal is that the client instance shouldn=E2=80=99t care what=E2=80=99s= in the token, what format it is, etc.

    The RS can care and there should be = choices that include random, sealed, and even plainly signed tokens. = That choice is part of the relationship between the RS and AS, which the = core GNAP protocol doesn=E2=80=99t specify. 
    This is why I propose that we extract = what=E2=80=99s now section 10 in the draft and put it into a new = document that can more directly discuss that relationship. These = different relationships should be modular. 

     =E2=80=94 Justin

    On Mar 19, 2021, at 11:13 AM, Alejandro Iacobelli <aiacobelli.sec@gmail.com> wrote:

    Agree! = So what are you saying the proposal should be? Random or sealed = tokens?

    El El vie, 19 mar. 2021 a la(s) 10:04, = Justin Richer <jricher@mit.edu> escribi=C3=B3:
    One of the best ways to protect information in the token is = to not put it in the token in the first place. This is why a some = highly-sensitive application profiles and deployments us randomized = values as tokens. The RS has a way to dereference it, which is = important.

    For = downstream delegation, like one micro service calling another, we=E2=80=99= re no longer talking about the client knowing the access token, we=E2=80=99= re talking about an RS at the first step. This is where non-opaque, or = encrypted, or other kinds of recoverable data structures come into play = more directly. 

    To Adrian=E2=80=99s point, sharing the QR code should be up = to the AS=E2=80=99s policy. If Steve gives me a bearer artifact that = isn=E2=80=99t attached to anything that identifies me, then it=E2=80=99s = easy for me to share because the artifact is the identity and proof all = in one. The strawman description below sounds like that. But it=E2=80=99s = important in this design that the AS can also require me to log in with = a specific account, plus present a token, plus type in a secret code, = plus present a hardware key that completes a circuit in the right way = (seems like something Steve would build, tbh), etc. But all of these = aren=E2=80=99t a client talking to a resource, they=E2=80=99re the = end-user  presenting things to the AS so that the AS can make a = policy decision to issue a token and allow access. 

     =E2=80= =94 Justin

    On Mar 18, 2021, at 8:23 PM, = Alejandro Iacobelli <aiacobelli.sec@gmail.com> = wrote:

    The decision about "opaque" vs = "sealed but recoverable" or "signed" access_token goes way back on the = stateless protocols session management. 

    In my opinion, the = software design principle that we must apply here is the "need to know" = principle. This means, the less information an attacker could get, = the better. One thing that JWS explse is all the context information = about a token, so an attacker can get lots of information just with = a look. 

    The next discussion will be what ways of generating opaque = tokens are there and which must we choose (Encrypted vs CSPRNG = based).

    On Thu, 18 Mar 2021 at 21:17, Fabien = Imbault <fabien.imbault@gmail.com> wrote:
    Hi Adrian,

    I'm really not sure I = understand here. 

    I get the idea of putting = a policy engine in front of your services to implement ZTA. But I'm not = sure I get this way of framing things. It blurs functional roles and = actual services, and most importantly if everything gets its own AS, it = also gets by transitivity its RO'/RQ' (and then its AS-RO' etc) and so = the complexity becomes staggering. 
    Why do we need that? 

    Fabien 

    Le ven. 19 = mars 2021 =C3=A0 00:55, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit :
    +1 This aligns with = my healthcare use-case to the extent that Justin can transfer the = capability granted by that QR code to Adrian who happens to be nearby = Steve's house.

    I've tried to capture some of this in my comment to = #145 https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#i= ssuecomment-802388458

    - Adrian

    On Thu, Mar = 18, 2021 at 2:39 PM Justin Richer <jricher@mit.edu> = wrote:
    Right, and in the GNAP model this becomes = something my client instance presents to the AS when I show up. The AS = can validate my presentation of this item and give my client instance a = token to call Steve=E2=80=99s RS. Or if you wanted to get super fancy = Steve=E2=80=99s AS could even challenge my client instance and get a = cryptographic response to prove I have the thing Steve had me scan. But = in both cases it=E2=80=99s part of things that the AS collects in order = to create the access token.

     =E2=80=94 Justin

    On Mar 18, 2021, at 2:26 PM, Stephen Moore <srmoore@gmail.com> wrote:

    That in my mind works out = great... Say I'm logged into my home hub/AS. Justin is over and agrees = to cat sit, I pull up my client app, and generate a QR code that has = maybe The AS URI, the HomeHub API URL, and the 'special token to present = to AS for a real token'. Justin scans that QR code with his home = controller app, and BAM, he's onboarded as a guest without even logging = into my AS or me dealing with his Auth provider.
    -steve

    On Thu, Mar = 18, 2021 at 2:08 PM Justin Richer <jricher@mit.edu> = wrote:
    I think Steve=E2=80=99s use case gives an = interesting example of something that I believe Adrian=E2=80=99s been = talking about as well =E2=80=94 delegating to another person.

    We traditionally think = of delegation at the AS to mean =E2=80=9Ca different user account logs = in to the AS=E2=80=9D, and it=E2=80=99s important to know that this does = in fact work. But this could just as easily be =E2=80=9CSteve sends his = friend an artifact to present to the AS to get access=E2=80=9D. This = isn=E2=80=99t Steve (or Steve=E2=80=99s client software) getting and = sending an access token, this is sending some other set of rights = credential to his friend, or his friend=E2=80=99s software. So then = Steve=E2=80=99s AS can have policy that says =E2=80=9Cwhen I see this = rights credential, give an access token for the following attenuated = things, because Steve said so=E2=80=9D. The AS doesn=E2=80=99t even ever = need to know who Steve=E2=80=99s friend is! 
    And importantly here, we don=E2=80=99t = expect Steve=E2=80=99s friend to bring their own AS to the party. = Steve=E2=80=99s RS has no reason to trust his friend=E2=80=99s AS, let = alone his friend=E2=80=99s client. But Steve=E2=80=99s AS is in a = position to know more about the rights policies that Steve wants to = apply, and so it can use other technologies like VC=E2=80=99s, DIDs, = OIDC, or any number of other things to let things go through. This = pattern is exactly why I think we need to think of this in terms of = what=E2=80=99s currently called =E2=80=9Cinteraction=E2=80=9D at the AS. = It=E2=80=99s not really just about how the end-user interacts, it=E2=80=99= s about how the AS gathers all the consent and authorization = information. I plan to rewrite section 4 to that effect.

     =E2=80=94 = Justin

    On Mar 18, 2021, at 1:58 PM, = Stephen Moore <srmoore@gmail.com> wrote:

    I'm having some = concerns with the way you're flipping the trust here Denis. You seem to = indicate that the user has trust in the RS and the Client and has to = gain the trust of the AS. I feel like the least trustworthy portion of = the architecture is the client, because that seems like it is the most = interchangeable component.
     Let me explain by way of = a use case I have in mind.
    Let's say I have a smart = home. I have devices and data storage and rule engines that are parts of = sensors and hubs I buy for the house. I have a trust in those devices, = because it's hardware, if the company is leaking data at the hardware = level there isn't much I can do other than buy different = sensors.
    In this case, the primary home hub, which = is under control of the homeowner, would also be the AS, as well as a = policy agent.  Authentication in the example is outsourced to = whatever auth providers you want. I set up my home using a google = account, a friend is staying and wants access and uses FB for auth... = whatever.
    The part that I have little control over = is the client my friend uses on his phone. Or if I change the client on = the tablet in the kitchen to try out something new. These = pieces might be single page web apps, they might be downloaded = apps, etc. I do not want them having any additional information than is = necessary. If I give my friend permission to unlock the door, and = control the lights because they are feeding my cats while I'm away, the = client doesn't need to know anything beyond, I see this home controller, = and I have access to these lights and that door lock.

    In your scenarios, the = client is spy by design, and if it is a web app, I don't trust them to = not grab my user email address from the AS and put it on a mailing = list it sells to some sketchy company, when the only other = component that needs that information is the RS.

    -steve

    On Thu, Mar 18, 2021 at 1:21 PM Denis <denis.ietf@free.fr> wrote:
    I have changed the title of = this thread, since the original topic has been closed. 

    Justin, you are raising = the following question:
    The = question I have is =E2=80=94 why does the client need to know what=E2=80=99= s in the token? 
    Not if they could possibly know, but why would we expect a = client to know and manage the contents of the token? 
    The answer is quite = simple: so that the end-user may have confidence into the = architecture. 
    The seventh of the eleven privacy = principles from ISO 29100 (page 14) is:
    7. Openness, transparency and notice 
    If the access token is = considered as a black box for the end-user, it cannot be confident about = the content of the access token.
    Such access token may = disclose some private information without the consent of the end-user. = If the access token that it has obtained 
    does not = match with what has been requested, the client will first not forward = the access token to the RS and then will complain about the = AS.

    Denis


    Hi Justin, 

    "The access token is fundamentally a conversational artifact = between the AS and the RS which the client is the carrier of."
    That's right, and a good opportunity to distinguish = between the need for token inspection (i.e. a runtime verification, = wherever that may be) 
    and the need = to negotiate the token format (a discovery). That last part could very = well be an extension, as a way to open up the ecosystem 
    beyond JWTs = (which are fine, but come with their own limitations). 

    Fabien

    On Thu, Mar 18, 2021 at 5:59 PM Justin Richer = <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 11:30 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, = at 12:08 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Adrian Gropper <agropper@healthurl.com> wrote:

    Is there an AS involved in the delegation? How and where in = the lifecycle of the protected = resource? 

    If tokens are certificates, the AS need = not be involved in subsequent delegations.  The AS must be involved = if the tokens are opaque. 

    Tokens are opaque to the = client instance. They are not opaque to the AS. They might be opaque to = the RS, but that depends on the kind of relationship the RS and AS have. = GNAP should allow different options here as there are different use = cases for that.

    Tokens are = not opaque to the client in SPKI, zcap-ld, Orie's implementation with = VCs, or our Zebra Copy work.  Why must they be in = GNAP?

    The existence of the AS is exactly the = reason for this. The AS is the role that =E2=80=9Cknowledge about the = token contents=E2=80=9D has been outsourced to in the GNAP model (which = is based on the OAuth model).

    It brings significant simplicity for = the client developer. The question I have is =E2=80=94 why does the = client need to know what=E2=80=99s in the token? Not if they could = possibly know, but why would we expect a client to know and manage the = contents of the token? 

    The access token is fundamentally a = conversational artifact between the AS and the RS which the client is = the carrier of. The client is not the audience of the token, nor the = creator of the token, nor even the manager of the token and the rights = it represents. The client as a simple carrier is a powerful model that = allows the security layer to get out of the way of the actual = application logic that developers want to do.

     =E2=80=94 Justin


    --------------
    Alan = Karp


    On Thu, Mar = 18, 2021 at 4:56 AM Justin Richer <jricher@mit.edu> = wrote:
    On Mar 18, 2021, at 12:08 AM, Alan Karp = <alanhkarp@gmail.com> wrote:

    Adrian Gropper <agropper@healthurl.com> wrote:

    Is there an AS involved in the delegation? How and where in = the lifecycle of the protected = resource? 

    If tokens are certificates, the AS need = not be involved in subsequent delegations.  The AS must be involved = if the tokens are opaque. 

    Tokens are opaque to the = client instance. They are not opaque to the AS. They might be opaque to = the RS, but that depends on the kind of relationship the RS and AS have. = GNAP should allow different options here as there are different use = cases for that.

    It would probably be worthwhile to separate the portions of = the spec that talk about the RS-AS relationship into its own standalone = document. A similar approach was taken in UMA2 and it was helpful. = (Though admittedly, as with anything, there are missteps there that we = can hopefully learn from.)

     =E2=80=94 Justin


    --------------
    Alan = Karp


    On Wed, Mar = 17, 2021 at 8:54 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Sure! 

    Is there an AS involved in the = delegation? How and where in the lifecycle of the protected = resource? 

    Also = your use of "the client" seems to imply that either there is only one = client or the client doesn't matter. Which is it?

    Adrian

    On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Thanks for that. 

    Trying to reframe it:
    GNAP = is defined as a delegation protocol so the main intent is related to a = delegate of the RO (i.e. the end user) that wishes to access the RO's = protected resources, through the client. 

    Fabien 

    Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper = <agropper@healthurl.com> a = =C3=A9crit :
    At various points in the = lifecycle of the protected resource the client at the resource = server (RS) might be:
    • The = RO (subject) user agent trading payment for a service promise
    • The RO user agent using the promise to access the protected = resource
    • A delegate of the RO user agent using a = different client
    What's vague is where the GNAP = AS enters the picture as described above. How would you describe = it?

    Adrian


    On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault = <fabien.imbault@gmail.com> = wrote:
    Hi Adrian

    I'm still = confused why you're saying the terminology is vague. 
    I get the "power" neutrality is not to your = liking, but RQ / user agent is no better in my view. 

    Can you elaborate? 

    Fabien 

    Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper = <agropper@healthurl.com> = a =C3=A9crit :
    I'm sure you're right. Our vague = terminology around client and end-user leads to my = confusion. If GNAP is primarily about delegation then, of course, = we should avoid any incentives to impersonate or we're wasting our = time. This is partly why I'm trying to study up on capabilities and = asking for expert advice from folks like Alan Karp and Mark Miller = (cc'd)

    As best I can = understand it, the RS has only two choices, it can:
    • store an attribute of the RO a = [DID, email address, GNAP AS URL], or
    • hand the RO a = capability as a sort-of promise and avoid making any entries in an ACL = or equivalent.
    When a token comes back to the = RS, it will either be:
    • validated according to something associated with the stored = RO attribute, or
    • signed by the RS = itself.
    Either way, trust in the client seems = moot.

    Adrian



    On Wed, Mar = 17, 2021 at 5:29 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 17, 2021, = at 4:55 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    On = Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <tobias.looker@mattr.global> wrote:
    <snip>
    > A client might not = have a DID but it could have a VC as a certificate of authenticity = linked to some audit mechanism.

    To me a VC would come under the = assertions umbrella (that is to say a VC could be one type of valid = assertion). The client may possess or been presented with a VC that it = could include in its request to the AS as a way to identify the subject = and perhaps prove authentication and = authorization.

    I do not assume that the client that = interacts with the AS to make a request and receive a token is the same = as the client that will present the token to the RS. In the US HIPAA = use-case, for example, the root of trust is a contract between the = patient-subject and the doctor-requesting party but the doctor workflow = is expected to delegate the token to some other end-user that may be = using a totally different client such as an EHR.


    If the client that gets the token is not same as the client = that uses the token, that is a violation of core security principles as = it allows for (and really designs for) impersonation by client software. = I would have no reason to trust client software that would hand its = credentials over to another piece of software, and in fact I shouldn=E2=80= =99t trust it. 

    I think you may be conflating several different kinds of = parties under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80= =99s entirely possible that one client might call an RS that in turn = acts as a client for something else down stream. But each of those hops = is different from the last.

     =E2=80=94 Justin

    =




    -- 
    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
    -- 
    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


    -- 
    You know nothing Jon = Snow!

    -- 
    You know nothing Jon = Snow!

    = --Apple-Mail=_63F558EF-07BA-45F3-A530-0BFB92BB0CCE-- From nobody Fri Mar 19 09:37:41 2021 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 6EC5C3A19EB for ; Fri, 19 Mar 2021 09:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 VHLtoPbxIQen for ; Fri, 19 Mar 2021 09:37:35 -0700 (PDT) Received: from mail-ua1-f54.google.com (mail-ua1-f54.google.com [209.85.222.54]) (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 9599C3A19E5 for ; Fri, 19 Mar 2021 09:37:35 -0700 (PDT) Received: by mail-ua1-f54.google.com with SMTP id b10so3235468uap.4 for ; Fri, 19 Mar 2021 09:37:35 -0700 (PDT) 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=BcDyfdv7nYnxjTd8GneZdcrMiZVD7/tcCOnSR8GZFxY=; b=EWZquw317SD1YPUXTk6Fgjd6KtkBImcULUtIN63/x6eiccv6ZHczD3trOq9FNq0cDA 21rWooROsFY+KoMqKIjCBejqA56c1Fc7n1irILRR2LxnTFx6iSxv82tv6r2q/Vc4D5c4 cyEzTYEWg3gQJ+x620IczGqdwO0KWmHSEA3EPC0IMyVBPHQdeHMh8WCG2xbAm4gNpE77 VqvvVwuB4x2YqUGaIi/2vVJdZnVlU6GRJnWtSdw+Eq6ZGzRx3lP+WQBfN5fx25smjkWI RoL+MWvgzlzbB571CykR1ERhMOkvOEcw38S81kiA8pn+v/I0MCfn2GG6FlGsgQwURB8i uvRA== X-Gm-Message-State: AOAM533Qdug6Y0Wef7OcrRvRESBxElqupNKqjlh2Oaoj2+XWFpnN8m5P N5FYslq+OWpF+Wl0SloHHLq3OSfn2AvuTzfT52mZcLxnqVA= X-Google-Smtp-Source: ABdhPJwvwqUlyCRdnIO4LG7RbuRaHo7sIXbvg2izDQn7NvO9yj7xW+3u7tx9A6MjUByvipCPhR/ZDngzNbBwmb+bFsQ= X-Received: by 2002:a9f:280a:: with SMTP id c10mr6375791uac.7.1616171854412; Fri, 19 Mar 2021 09:37:34 -0700 (PDT) MIME-Version: 1.0 References: <43447446-4061-49F2-8486-5A196C3C75E2@mit.edu> <37a04505-84ef-aecf-6913-5aad8330c97c@free.fr> <3FE214B6-CF96-472D-853B-C7C5AC7A73AE@mit.edu> In-Reply-To: From: Adrian Gropper Date: Fri, 19 Mar 2021 12:37:22 -0400 Message-ID: To: Justin Richer Cc: Alejandro Iacobelli , Fabien Imbault , Steve Moore , txauth gnap Content-Type: multipart/alternative; boundary="00000000000047423a05bde65503" Archived-At: Subject: Re: [GNAP] Should access tokens be opaque or not for the clients ? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 16:37:40 -0000 --00000000000047423a05bde65503 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It might be a good idea to keep the RS to AS relationship out of the GNAP spec but I=E2=80=99m having a hard time analyzing it in the abstract. My starting perspective is that the RS should not know or care whether it is dealing with the AS or the RO. This is super important because it gives the RO unlimited delegation power. Cases where the RO wants to give the RS a separate endpoint or other identity should be allowed by GNAP but might be out of band. This is the HIPAA API Task Force use case that I have referenced in another thread. The issue here is that the RS has the option of reaching out to the RO and requesting confirmation. Adrian On Fri, Mar 19, 2021 at 11:37 AM Justin Richer wrote: > My proposal is that the client instance shouldn=E2=80=99t care what=E2=80= =99s in the > token, what format it is, etc. > > The RS can care and there should be choices that include random, sealed, > and even plainly signed tokens. That choice is part of the relationship > between the RS and AS, which the core GNAP protocol doesn=E2=80=99t speci= fy. > > This is why I propose that we extract what=E2=80=99s now section 10 in th= e draft > and put it into a new document that can more directly discuss that > relationship. These different relationships should be modular. > > =E2=80=94 Justin > > On Mar 19, 2021, at 11:13 AM, Alejandro Iacobelli < > aiacobelli.sec@gmail.com> wrote: > > Agree! So what are you saying the proposal should be? Random or sealed > tokens? > > El El vie, 19 mar. 2021 a la(s) 10:04, Justin Richer > escribi=C3=B3: > >> One of the best ways to protect information in the token is to not put i= t >> in the token in the first place. This is why a some highly-sensitive >> application profiles and deployments us randomized values as tokens. The= RS >> has a way to dereference it, which is important. >> >> For downstream delegation, like one micro service calling another, we=E2= =80=99re >> no longer talking about the client knowing the access token, we=E2=80=99= re talking >> about an RS at the first step. This is where non-opaque, or encrypted, o= r >> other kinds of recoverable data structures come into play more directly. >> >> To Adrian=E2=80=99s point, sharing the QR code should be up to the AS=E2= =80=99s policy. >> If Steve gives me a bearer artifact that isn=E2=80=99t attached to anyth= ing that >> identifies me, then it=E2=80=99s easy for me to share because the artifa= ct is the >> identity and proof all in one. The strawman description below sounds lik= e >> that. But it=E2=80=99s important in this design that the AS can also req= uire me to >> log in with a specific account, plus present a token, plus type in a sec= ret >> code, plus present a hardware key that completes a circuit in the right = way >> (seems like something Steve would build, tbh), etc. But all of these are= n=E2=80=99t >> a client talking to a resource, they=E2=80=99re the end-user presenting= things to >> the AS so that the AS can make a policy decision to issue a token and al= low >> access. >> >> =E2=80=94 Justin >> >> On Mar 18, 2021, at 8:23 PM, Alejandro Iacobelli < >> aiacobelli.sec@gmail.com> wrote: >> >> The decision about "opaque" vs "sealed but recoverable" or "signed" >> access_token goes way back on the stateless protocols session management= . >> >> In my opinion, the software design principle that we must apply here is >> the "need to know" principle. This means, the less information an attack= er >> could get, the better. One thing that JWS explse is all the context >> information about a token, so an attacker can get lots of information ju= st >> with a look. >> >> The next discussion will be what ways of generating opaque tokens are >> there and which must we choose (Encrypted vs CSPRNG based). >> >> On Thu, 18 Mar 2021 at 21:17, Fabien Imbault >> wrote: >> >>> Hi Adrian, >>> >>> I'm really not sure I understand here. >>> >>> I get the idea of putting a policy engine in front of your services to >>> implement ZTA. But I'm not sure I get this way of framing things. It bl= urs >>> functional roles and actual services, and most importantly if everythin= g >>> gets its own AS, it also gets by transitivity its RO'/RQ' (and then its >>> AS-RO' etc) and so the complexity becomes staggering. >>> Why do we need that? >>> >>> Fabien >>> >>> Le ven. 19 mars 2021 =C3=A0 00:55, Adrian Gropper a >>> =C3=A9crit : >>> >>>> +1 This aligns with my healthcare use-case to the extent that Justin >>>> can transfer the capability granted by that QR code to Adrian who happ= ens >>>> to be nearby Steve's house. >>>> >>>> I've tried to capture some of this in my comment to #145 >>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecom= ment-802388458 >>>> >>>> - Adrian >>>> >>>> On Thu, Mar 18, 2021 at 2:39 PM Justin Richer wrote: >>>> >>>>> Right, and in the GNAP model this becomes something my client instanc= e >>>>> presents to the AS when I show up. The AS can validate my presentatio= n of >>>>> this item and give my client instance a token to call Steve=E2=80=99s= RS. Or if you >>>>> wanted to get super fancy Steve=E2=80=99s AS could even challenge my = client >>>>> instance and get a cryptographic response to prove I have the thing S= teve >>>>> had me scan. But in both cases it=E2=80=99s part of things that the A= S collects in >>>>> order to create the access token. >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Mar 18, 2021, at 2:26 PM, Stephen Moore wrote: >>>>> >>>>> That in my mind works out great... Say I'm logged into my home hub/AS= . >>>>> Justin is over and agrees to cat sit, I pull up my client app, and ge= nerate >>>>> a QR code that has maybe The AS URI, the HomeHub API URL, and the 'sp= ecial >>>>> token to present to AS for a real token'. Justin scans that QR code w= ith >>>>> his home controller app, and BAM, he's onboarded as a guest without e= ven >>>>> logging into my AS or me dealing with his Auth provider. >>>>> -steve >>>>> >>>>> On Thu, Mar 18, 2021 at 2:08 PM Justin Richer wrote= : >>>>> >>>>>> I think Steve=E2=80=99s use case gives an interesting example of som= ething >>>>>> that I believe Adrian=E2=80=99s been talking about as well =E2=80=94= delegating to another >>>>>> person. >>>>>> >>>>>> We traditionally think of delegation at the AS to mean =E2=80=9Ca di= fferent >>>>>> user account logs in to the AS=E2=80=9D, and it=E2=80=99s important = to know that this does >>>>>> in fact work. But this could just as easily be =E2=80=9CSteve sends = his friend an >>>>>> artifact to present to the AS to get access=E2=80=9D. This isn=E2=80= =99t Steve (or Steve=E2=80=99s >>>>>> client software) getting and sending an access token, this is sendin= g some >>>>>> other set of rights credential to his friend, or his friend=E2=80=99= s software. So >>>>>> then Steve=E2=80=99s AS can have policy that says =E2=80=9Cwhen I se= e this rights >>>>>> credential, give an access token for the following attenuated things= , >>>>>> because Steve said so=E2=80=9D. The AS doesn=E2=80=99t even ever nee= d to know who Steve=E2=80=99s >>>>>> friend is! >>>>>> >>>>>> And importantly here, we don=E2=80=99t expect Steve=E2=80=99s friend= to bring their >>>>>> own AS to the party. Steve=E2=80=99s RS has no reason to trust his f= riend=E2=80=99s AS, let >>>>>> alone his friend=E2=80=99s client. But Steve=E2=80=99s AS is in a po= sition to know more >>>>>> about the rights policies that Steve wants to apply, and so it can u= se >>>>>> other technologies like VC=E2=80=99s, DIDs, OIDC, or any number of o= ther things to >>>>>> let things go through. This pattern is exactly why I think we need t= o think >>>>>> of this in terms of what=E2=80=99s currently called =E2=80=9Cinterac= tion=E2=80=9D at the AS. It=E2=80=99s >>>>>> not really just about how the end-user interacts, it=E2=80=99s about= how the AS >>>>>> gathers all the consent and authorization information. I plan to rew= rite >>>>>> section 4 to that effect. >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> On Mar 18, 2021, at 1:58 PM, Stephen Moore wrote= : >>>>>> >>>>>> I'm having some concerns with the way you're flipping the trust here >>>>>> Denis. You seem to indicate that the user has trust in the RS and th= e >>>>>> Client and has to gain the trust of the AS. I feel like the least >>>>>> trustworthy portion of the architecture is the client, because that = seems >>>>>> like it is the most interchangeable component. >>>>>> Let me explain by way of a use case I have in mind. >>>>>> Let's say I have a smart home. I have devices and data storage and >>>>>> rule engines that are parts of sensors and hubs I buy for the house.= I have >>>>>> a trust in those devices, because it's hardware, if the company is l= eaking >>>>>> data at the hardware level there isn't much I can do other than buy >>>>>> different sensors. >>>>>> In this case, the primary home hub, which is under control of the >>>>>> homeowner, would also be the AS, as well as a policy agent. Authent= ication >>>>>> in the example is outsourced to whatever auth providers you want. I = set up >>>>>> my home using a google account, a friend is staying and wants access= and >>>>>> uses FB for auth... whatever. >>>>>> The part that I have little control over is the client my friend use= s >>>>>> on his phone. Or if I change the client on the tablet in the kitchen= to try >>>>>> out something new. These pieces might be single page web apps, they = might >>>>>> be downloaded apps, etc. I do not want them having any additional >>>>>> information than is necessary. If I give my friend permission to unl= ock the >>>>>> door, and control the lights because they are feeding my cats while = I'm >>>>>> away, the client doesn't need to know anything beyond, I see this ho= me >>>>>> controller, and I have access to these lights and that door lock. >>>>>> >>>>>> In your scenarios, the client is spy by design, and if it is a web >>>>>> app, I don't trust them to not grab my user email address from the A= S and >>>>>> put it on a mailing list it sells to some sketchy company, when the = only >>>>>> other component that needs that information is the RS. >>>>>> >>>>>> -steve >>>>>> >>>>>> On Thu, Mar 18, 2021 at 1:21 PM Denis wrote: >>>>>> >>>>>>> I have changed the title of this thread, since the original topic >>>>>>> has been closed. >>>>>>> >>>>>>> Justin, you are raising the following question: >>>>>>> >>>>>>> The question I have is =E2=80=94 why does the client need to know w= hat=E2=80=99s in >>>>>>> the token? >>>>>>> Not if they could possibly know, but why would we expect a client t= o >>>>>>> know and manage the contents of the token? >>>>>>> >>>>>>> The answer is quite simple: so that the end-user may have confidenc= e >>>>>>> into the architecture. >>>>>>> The seventh of the eleven privacy principles from ISO 29100 (page >>>>>>> 14) is: >>>>>>> >>>>>>> *7. Openness, transparency and notice * >>>>>>> >>>>>>> If the access token is considered as a black box for the end-user, >>>>>>> it cannot be confident about the content of the access token. >>>>>>> Such access token may disclose some private information without the >>>>>>> consent of the end-user. If the access token that it has obtained >>>>>>> does not match with what has been requested, the client will first >>>>>>> not forward the access token to the RS and then will complain about= the AS. >>>>>>> >>>>>>> Denis >>>>>>> >>>>>>> >>>>>>> Hi Justin, >>>>>>> >>>>>>> "The access token is fundamentally a conversational artifact betwee= n >>>>>>> the AS and the RS which the client is the carrier of." >>>>>>> That's right, and a good opportunity to distinguish between the nee= d >>>>>>> for token inspection (i.e. a runtime verification, wherever that ma= y be) >>>>>>> >>>>>>> and the need to negotiate the token format (a discovery). That last >>>>>>> part could very well be an extension, as a way to open up the ecosy= stem >>>>>>> >>>>>>> beyond JWTs (which are fine, but come with their own limitations). >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> On Thu, Mar 18, 2021 at 5:59 PM Justin Richer >>>>>>> wrote: >>>>>>> >>>>>>>> On Mar 18, 2021, at 11:30 AM, Alan Karp >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> Justin Richer wrote: >>>>>>>> >>>>>>>>> On Mar 18, 2021, at 12:08 AM, Alan Karp >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Adrian Gropper wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Is there an AS involved in the delegation? How and where in the >>>>>>>>>> lifecycle of the protected resource? >>>>>>>>>> >>>>>>>>> >>>>>>>>> If tokens are certificates, the AS need not be involved in >>>>>>>>> subsequent delegations. The AS must be involved if the tokens ar= e opaque. >>>>>>>>> >>>>>>>>> >>>>>>>>> Tokens are opaque to the client instance. They are not opaque to >>>>>>>>> the AS. They might be opaque to the RS, but that depends on the k= ind of >>>>>>>>> relationship the RS and AS have. GNAP should allow different opti= ons here >>>>>>>>> as there are different use cases for that. >>>>>>>>> >>>>>>>> >>>>>>>> Tokens are not opaque to the client in SPKI, zcap-ld, Orie's >>>>>>>> implementation with VCs, or our Zebra Copy work. Why must they be= in GNAP? >>>>>>>> >>>>>>>> >>>>>>>> The existence of the AS is exactly the reason for this. The AS is >>>>>>>> the role that =E2=80=9Cknowledge about the token contents=E2=80=9D= has been outsourced to >>>>>>>> in the GNAP model (which is based on the OAuth model). >>>>>>>> >>>>>>>> It brings significant simplicity for the client developer. The >>>>>>>> question I have is =E2=80=94 why does the client need to know what= =E2=80=99s in the token? >>>>>>>> Not if they could possibly know, but why would we expect a client = to know >>>>>>>> and manage the contents of the token? >>>>>>>> >>>>>>>> The access token is fundamentally a conversational artifact betwee= n >>>>>>>> the AS and the RS which the client is the carrier of. The client i= s not the >>>>>>>> audience of the token, nor the creator of the token, nor even the = manager >>>>>>>> of the token and the rights it represents. The client as a simple = carrier >>>>>>>> is a powerful model that allows the security layer to get out of t= he way of >>>>>>>> the actual application logic that developers want to do. >>>>>>>> >>>>>>>> =E2=80=94 Justin >>>>>>>> >>>>>>>> >>>>>>>> -------------- >>>>>>>> Alan Karp >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Mar 18, 2021 at 4:56 AM Justin Richer >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On Mar 18, 2021, at 12:08 AM, Alan Karp >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Adrian Gropper wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Is there an AS involved in the delegation? How and where in the >>>>>>>>>> lifecycle of the protected resource? >>>>>>>>>> >>>>>>>>> >>>>>>>>> If tokens are certificates, the AS need not be involved in >>>>>>>>> subsequent delegations. The AS must be involved if the tokens ar= e opaque. >>>>>>>>> >>>>>>>>> >>>>>>>>> Tokens are opaque to the client instance. They are not opaque to >>>>>>>>> the AS. They might be opaque to the RS, but that depends on the k= ind of >>>>>>>>> relationship the RS and AS have. GNAP should allow different opti= ons here >>>>>>>>> as there are different use cases for that. >>>>>>>>> >>>>>>>>> It would probably be worthwhile to separate the portions of the >>>>>>>>> spec that talk about the RS-AS relationship into its own standalo= ne >>>>>>>>> document. A similar approach was taken in UMA2 and it was helpful= . (Though >>>>>>>>> admittedly, as with anything, there are missteps there that we ca= n >>>>>>>>> hopefully learn from.) >>>>>>>>> >>>>>>>>> =E2=80=94 Justin >>>>>>>>> >>>>>>>>> >>>>>>>>> -------------- >>>>>>>>> Alan Karp >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper < >>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>> >>>>>>>>>> Sure! >>>>>>>>>> >>>>>>>>>> Is there an AS involved in the delegation? How and where in the >>>>>>>>>> lifecycle of the protected resource? >>>>>>>>>> >>>>>>>>>> Also your use of "the client" seems to imply that either there i= s >>>>>>>>>> only one client or the client doesn't matter. Which is it? >>>>>>>>>> >>>>>>>>>> Adrian >>>>>>>>>> >>>>>>>>>> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault < >>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Thanks for that. >>>>>>>>>>> >>>>>>>>>>> Trying to reframe it: >>>>>>>>>>> GNAP is defined as a delegation protocol so the main intent is >>>>>>>>>>> related to a delegate of the RO (i.e. the end user) that wishes= to access >>>>>>>>>>> the RO's protected resources, through the client. >>>>>>>>>>> >>>>>>>>>>> Fabien >>>>>>>>>>> >>>>>>>>>>> Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper < >>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>> >>>>>>>>>>>> At various points in the lifecycle of the protected resource >>>>>>>>>>>> the client at the resource server (RS) might be: >>>>>>>>>>>> >>>>>>>>>>>> - The RO (subject) user agent trading payment for a service >>>>>>>>>>>> promise >>>>>>>>>>>> - The RO user agent using the promise to access the >>>>>>>>>>>> protected resource >>>>>>>>>>>> - A delegate of the RO user agent using a different client >>>>>>>>>>>> >>>>>>>>>>>> What's vague is where the GNAP AS enters the picture as >>>>>>>>>>>> described above. How would you describe it? >>>>>>>>>>>> >>>>>>>>>>>> Adrian >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault < >>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Adrian >>>>>>>>>>>>> >>>>>>>>>>>>> I'm still confused why you're saying the terminology is vague= . >>>>>>>>>>>>> I get the "power" neutrality is not to your liking, but RQ / >>>>>>>>>>>>> user agent is no better in my view. >>>>>>>>>>>>> >>>>>>>>>>>>> Can you elaborate? >>>>>>>>>>>>> >>>>>>>>>>>>> Fabien >>>>>>>>>>>>> >>>>>>>>>>>>> Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper < >>>>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>>>> >>>>>>>>>>>>>> I'm sure you're right. Our vague terminology around >>>>>>>>>>>>>> client and end-user leads to my confusion. If GNAP is primar= ily about >>>>>>>>>>>>>> delegation then, of course, we should avoid any incentives t= o impersonate >>>>>>>>>>>>>> or we're wasting our time. This is partly why I'm trying to = study up on >>>>>>>>>>>>>> capabilities and asking for expert advice from folks like Al= an Karp and >>>>>>>>>>>>>> Mark Miller (cc'd) >>>>>>>>>>>>>> >>>>>>>>>>>>>> As best I can understand it, the RS has only two choices, it >>>>>>>>>>>>>> can: >>>>>>>>>>>>>> >>>>>>>>>>>>>> - store an attribute of the RO a [DID, email address, >>>>>>>>>>>>>> GNAP AS URL], or >>>>>>>>>>>>>> - hand the RO a capability as a sort-of promise and avoid >>>>>>>>>>>>>> making any entries in an ACL or equivalent. >>>>>>>>>>>>>> >>>>>>>>>>>>>> When a token comes back to the RS, it will either be: >>>>>>>>>>>>>> >>>>>>>>>>>>>> - validated according to something associated with the >>>>>>>>>>>>>> stored RO attribute, or >>>>>>>>>>>>>> - signed by the RS itself. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Either way, trust in the client seems moot. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer < >>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper < >>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker < >>>>>>>>>>>>>>> tobias.looker@mattr.global> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > A client might not have a DID but it could have a VC as = a >>>>>>>>>>>>>>>> certificate of authenticity linked to some audit mechanism= . >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> To me a VC would come under the assertions umbrella (that >>>>>>>>>>>>>>>> is to say a VC could be one type of valid assertion). The = client may >>>>>>>>>>>>>>>> possess or been presented with a VC that it could include = in its request to >>>>>>>>>>>>>>>> the AS as a way to identify the subject and perhaps prove = authentication >>>>>>>>>>>>>>>> and authorization. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I do not assume that the client that interacts with the AS >>>>>>>>>>>>>>> to make a request and receive a token is the same as the cl= ient that will >>>>>>>>>>>>>>> present the token to the RS. In the US HIPAA use-case, for = example, the >>>>>>>>>>>>>>> root of trust is a contract between the patient-subject and= the >>>>>>>>>>>>>>> doctor-requesting party but the doctor workflow is expected= to delegate the >>>>>>>>>>>>>>> token to some other end-user that may be using a totally di= fferent client >>>>>>>>>>>>>>> such as an EHR. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If the client that gets the token is not same as the client >>>>>>>>>>>>>>> that uses the token, that is a violation of core security p= rinciples as it >>>>>>>>>>>>>>> allows for (and really designs for) impersonation by client= software. I >>>>>>>>>>>>>>> would have no reason to trust client software that would ha= nd its >>>>>>>>>>>>>>> credentials over to another piece of software, and in fact = I shouldn=E2=80=99t >>>>>>>>>>>>>>> trust it. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think you may be conflating several different kinds of >>>>>>>>>>>>>>> parties under the =E2=80=9Cclient=E2=80=9D umbrella here, t= hough. It=E2=80=99s entirely possible >>>>>>>>>>>>>>> that one client might call an RS that in turn acts as a cli= ent for >>>>>>>>>>>>>>> something else down stream. But each of those hops is diffe= rent from the >>>>>>>>>>>>>>> last. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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 >>>>> >>>> -- >>>> 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 >>> >> >> >> -- >> You know nothing Jon Snow! >> >> >> -- > You know nothing Jon Snow! > > > --00000000000047423a05bde65503 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    It might be a good idea to keep the RS to AS relationship= out of the GNAP spec but I=E2=80=99m having a hard time analyzing it in th= e abstract.=C2=A0

    My sta= rting perspective is that the RS should not know or care whether it is deal= ing with the AS or the RO. This is super important because it gives the RO = unlimited delegation power.=C2=A0

    Cases where the RO wants to give the RS a separate endpoint or ot= her identity should be allowed by GNAP but might be out of band. This is th= e HIPAA API Task Force use case that I have referenced in another thread. T= he issue here is that the RS has the option of reaching out to the RO and r= equesting confirmation.

    = Adrian =C2=A0

    On Fri, Mar 19, 2021 at 11:37 AM Justin Richer <jricher@mit.edu> wrote:
    My proposal is that the client instance shouldn=E2=80=99t ca= re what=E2=80=99s in the token, what format it is, etc.

    = The RS can care and there should be choices that include random, sealed, an= d even plainly signed tokens. That choice is part of the relationship betwe= en the RS and AS, which the core GNAP protocol doesn=E2=80=99t specify.=C2= =A0

    This is why I propose that we extract what=E2= =80=99s now section 10 in the draft and put it into a new document that can= more directly discuss that relationship. These different relationships sho= uld be modular.=C2=A0

    =C2=A0=E2=80=94 Justin
    <= br>
    On Mar 19, 2021, at 11:13 AM, Alejandro I= acobelli <= aiacobelli.sec@gmail.com> wrote:

    Agree! So what are you saying the proposal should be? Random o= r sealed tokens?

    <= div dir=3D"ltr" class=3D"gmail_attr">El El vie, 19 mar. 2021 a la(s) 10:04,= Justin Richer <jri= cher@mit.edu> escribi=C3=B3:
    One of the best ways to= protect information in the token is to not put it in the token in the firs= t place. This is why a some highly-sensitive application profiles and deplo= yments us randomized values as tokens. The RS has a way to dereference it, = which is important.

    For downstream delegation, like one = micro service calling another, we=E2=80=99re no longer talking about the cl= ient knowing the access token, we=E2=80=99re talking about an RS at the fir= st step. This is where non-opaque, or encrypted, or other kinds of recovera= ble data structures come into play more directly.=C2=A0

    To Adrian=E2=80=99s point, sharing the QR code should be up to the AS= =E2=80=99s policy. If Steve gives me a bearer artifact that isn=E2=80=99t a= ttached to anything that identifies me, then it=E2=80=99s easy for me to sh= are because the artifact is the identity and proof all in one. The strawman= description below sounds like that. But it=E2=80=99s important in this des= ign that the AS can also require me to log in with a specific account, plus= present a token, plus type in a secret code, plus present a hardware key t= hat completes a circuit in the right way (seems like something Steve would = build, tbh), etc. But all of these aren=E2=80=99t a client talking to a res= ource, they=E2=80=99re the end-user =C2=A0presenting things to the AS so th= at the AS can make a policy decision to issue a token and allow access.=C2= =A0

    =C2=A0=E2=80=94 Justin

    On Mar 18, 2021, at 8:23 PM, Alejandro Iacobelli <aiacobelli.sec@gmai= l.com> wrote:

    The d= ecision about "opaque" vs "sealed but recoverable" or &= quot;signed" access_token goes way back on the stateless protocols ses= sion management.=C2=A0

    In my opinion,= the software design principle that we must apply here is the "need to= know" principle. This means, the=C2=A0less information an attacker co= uld get, the better. One thing that JWS explse is all the context informati= on about a token, so an attacker=C2=A0can get lots of information just with= a look.=C2=A0

    The next discussion will be what wa= ys of generating opaque tokens are there and which must we choose (Encrypte= d vs CSPRNG based).

    On Thu, 18 Mar 2021 at 21:17, Fabien Imbault <<= a href=3D"mailto:fabien.imbault@gmail.com" target=3D"_blank">fabien.imbault= @gmail.com> wrote:
    Hi A= drian,

    I'm really not sure= I understand here.=C2=A0

    = I get the idea of putting a policy engine in front of your services to impl= ement ZTA. But I'm not sure I get this way of framing things. It blurs = functional roles and actual services, and most importantly if everything ge= ts its own AS, it also gets by transitivity its RO'/RQ' (and then i= ts AS-RO' etc) and so the complexity becomes staggering.=C2=A0
    Why do we need that?=C2=A0

    =
    Fabien=C2=A0

    Le ven. 19 mars 2021 =C3=A0 00:55= , Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    +1 This aligns with my healthcare= use-case to the extent that Justin can transfer the capability granted by = that QR code to Adrian who happens to be nearby Steve's house.
    =
    I've tried to capture some of this in my comment to #145= =C2=A0https://gi= thub.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-802388458<= /a>


    On Thu, Mar 18, 2021 at 2:= 39 PM Justin Richer <jricher@mit.edu> wrote:
    Right, and in the GNAP model this becomes something my client insta= nce presents to the AS when I show up. The AS can validate my presentation = of this item and give my client instance a token to call Steve=E2=80=99s RS= . Or if you wanted to get super fancy Steve=E2=80=99s AS could even challen= ge my client instance and get a cryptographic response to prove I have the = thing Steve had me scan. But in both cases it=E2=80=99s part of things that= the AS collects in order to create the access token.

    =C2=A0=E2=80=94 Justin

    On Mar= 18, 2021, at 2:26 PM, Stephen Moore <srmoore@gmail.com> wrote:
    That in my mind works out great... Say I'm= logged into my home hub/AS. Justin is over and agrees to cat sit, I pull u= p my client app, and generate a QR code that has maybe The AS URI, the Home= Hub API URL, and the 'special token to present to AS for a real token&#= 39;. Justin scans that QR code with his home controller app, and BAM, he= 9;s onboarded as a guest without even logging into my AS or me dealing with= his Auth provider.
    -steve

    On Thu, Mar 18, 2021 at 2:08 PM Justin = Richer <jricher@mit.edu> wrote:
    I thi= nk Steve=E2=80=99s use case gives an interesting example of something that = I believe Adrian=E2=80=99s been talking about as well =E2=80=94 delegating = to another person.

    We traditionally think of delegation = at the AS to mean =E2=80=9Ca different user account logs in to the AS=E2=80= =9D, and it=E2=80=99s important to know that this does in fact work. But th= is could just as easily be =E2=80=9CSteve sends his friend an artifact to p= resent to the AS to get access=E2=80=9D. This isn=E2=80=99t Steve (or Steve= =E2=80=99s client software) getting and sending an access token, this is se= nding some other set of rights credential to his friend, or his friend=E2= =80=99s software. So then Steve=E2=80=99s AS can have policy that says =E2= =80=9Cwhen I see this rights credential, give an access token for the follo= wing attenuated things, because Steve said so=E2=80=9D. The AS doesn=E2=80= =99t even ever need to know who Steve=E2=80=99s friend is!=C2=A0
    =
    And importantly here, we don=E2=80=99t expect Steve=E2=80=99= s friend to bring their own AS to the party. Steve=E2=80=99s RS has no reas= on to trust his friend=E2=80=99s AS, let alone his friend=E2=80=99s client.= But Steve=E2=80=99s AS is in a position to know more about the rights poli= cies that Steve wants to apply, and so it can use other technologies like V= C=E2=80=99s, DIDs, OIDC, or any number of other things to let things go thr= ough. This pattern is exactly why I think we need to think of this in terms= of what=E2=80=99s currently called =E2=80=9Cinteraction=E2=80=9D at the AS= . It=E2=80=99s not really just about how the end-user interacts, it=E2=80= =99s about how the AS gathers all the consent and authorization information= . I plan to rewrite section 4 to that effect.

    =C2= =A0=E2=80=94 Justin

    On Mar 18, 2= 021, at 1:58 PM, Stephen Moore <srmoore@gmail.com> wrote:
    I'm having some concerns with the way you're= flipping the trust here Denis. You seem to indicate that the user has trus= t in the RS and the Client and has to gain the trust of the AS. I feel like= the least trustworthy portion of the architecture is the client, because t= hat seems like it is the most interchangeable component.
    =C2=A0Let me e= xplain by way of a use case I have in mind.
    Let's say I have = a smart home. I have devices and data storage and rule engines that are par= ts of sensors and hubs I buy for the house. I have a trust in those devices= , because it's hardware, if the company is leaking data at the hardware= level there isn't much I can do other than buy different sensors.
    In this case, the primary home hub, which is under control of the hom= eowner, would also be the AS, as well as a policy agent.=C2=A0 Authenticati= on in the example is outsourced to whatever auth providers you want. I set = up my home using a google account, a friend is staying and wants access and= uses FB for auth... whatever.
    The part that I have little contro= l over is the client my friend uses on his phone. Or if I change the client= on the tablet in the kitchen to try out something new. These pieces=C2=A0m= ight be single page web apps, they might be downloaded apps, etc. I do not = want them having any additional information than is necessary. If I give my= friend permission to unlock the door, and control the lights because they = are feeding my cats while I'm away, the client doesn't need to know= anything beyond, I see this home controller, and I have access to these li= ghts and that door lock.

    In your scenarios, the cl= ient is spy by design, and if it is a web app, I don't trust them to no= t grab my user email address from the=C2=A0AS and put it on a mailing list = it sells to some sketchy company,=C2=A0when the only other component=C2=A0t= hat needs that information is the RS.

    -steve
    =

    = On Thu, Mar 18, 2021 at 1:21 PM Denis <denis.ietf@free.fr> wrote:=
    I have changed the title of this = thread, since the original topic has been closed.=C2=A0

    Justin, you are raising the following question:
    The question I have is =E2=80=94 why does the client need= to know what=E2=80=99s in the token?=C2=A0
    Not if they cou= ld possibly know, but why would we expect a client to know and manage the c= ontents of the token?=C2=A0
    The ans= wer is quite simple: so that the end-user may have confidence into the arch= itecture.=C2=A0
    The seventh of the eleven privac= y principles from ISO 29100 (page 14) is:
    7. Openn= ess, transparency and notice=C2=A0
    <= div>If the access token is considered as a black box for the end-user, it c= annot be confident about the content of the access token.
    Such access to= ken may disclose some private information without the consent of the end-us= er. If the access token that it has obtained=C2=A0
    does not= match with what has been requested, the client will first not forward the = access token to the RS and then will complain about the AS.

    <= /div>
    Denis


    Hi Justin,=C2=A0

    "The access token is= fundamentally a conversational artifact between the AS and the RS which th= e client is the carrier of."
    That's right,=C2=A0and a go= od=C2=A0opportunity to distinguish between the need for token=C2=A0inspecti= on (i.e. a runtime verification, wherever that may be)=C2=A0and the need to negotiate the token format (a discovery). That last part = could very well be an extension, as a way to open up the ecosystem=C2= =A0
    beyond JWTs (which are fine, but come with their own limitati= ons).=C2=A0

    Fabien

    On Thu, Mar 18, 2021 at 5:= 59 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 11:30 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Justin Richer <jricher= @mit.edu> wrote:
    On Mar 18, 2021, at = 12:08 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Adrian Gropper <agropper@healthurl.com&= gt; wrote:

    I= s there an AS involved in the delegation? How and where in the lifecycle=C2= =A0of the protected resource?=C2=A0

    =
    If tokens are certificates, the AS need not be involved in subsequent = delegations.=C2=A0 The AS must be involved if the tokens are opaque.=C2=A0<= /div>

    Tokens are opaque t= o the client instance. They are not opaque to the AS. They might be opaque = to the RS, but that depends on the kind of relationship the RS and AS have.= GNAP should allow different options here as there are different use cases = for that.

    Tokens are not opaque to the client in SPKI, zcap-ld, Orie's implemen= tation with VCs, or our Zebra Copy work.=C2=A0 Why must they be in GNAP?

    The existence o= f the AS is exactly the reason for this. The AS is the role that =E2=80=9Ck= nowledge about the token contents=E2=80=9D has been outsourced to in the GN= AP model (which is based on the OAuth model).

    It b= rings significant simplicity for the client developer. The question I have = is =E2=80=94 why does the client need to know what=E2=80=99s in the token? = Not if they could possibly know, but why would we expect a client to know a= nd manage the contents of the token?=C2=A0

    The acc= ess token is fundamentally a conversational artifact between the AS and the= RS which the client is the carrier of. The client is not the audience of t= he token, nor the creator of the token, nor even the manager of the token a= nd the rights it represents. The client as a simple carrier is a powerful m= odel that allows the security layer to get out of the way of the actual app= lication logic that developers want to do.

    =C2=A0= =E2=80=94 Justin

    <= div dir=3D"ltr">

    --------------
    Alan Karp
    =


    On Thu, Mar 18, 2021 at 4:56 AM Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 12:08 AM, A= lan Karp <alanhkarp@gmail.com> wrote:

    Adrian Gropper <agropper@healthurl.com> wrote= :

    Is there a= n AS involved in the delegation? How and where in the lifecycle=C2=A0of the= protected resource?=C2=A0

    If t= okens are certificates, the AS need not be involved in subsequent delegatio= ns.=C2=A0 The AS must be involved if the tokens are opaque.=C2=A0

    Tokens are opaque to the cli= ent instance. They are not opaque to the AS. They might be opaque to the RS= , but that depends on the kind of relationship the RS and AS have. GNAP sho= uld allow different options here as there are different use cases for that.=

    It would probably be worthwhile to separate the p= ortions of the spec that talk about the RS-AS relationship into its own sta= ndalone document. A similar approach was taken in UMA2 and it was helpful. = (Though admittedly, as with anything, there are missteps there that we can = hopefully learn from.)

    =C2=A0=E2=80=94 Justin
    =
    --------------
    Alan Karp

    =

    = On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper <agropper@healthurl.c= om> wrote:
    Sure!=C2=A0
    Is there an AS involved in the delegation? How and where i= n the lifecycle=C2=A0of the protected resource?=C2=A0

    Al= so your use of "the client" seems to imply that either there is o= nly one client or the client doesn't matter. Which is it?

    Adrian

    On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbau= lt <fabien.imbault@gmail.com> wrote:
    Thanks for that.=C2=A0
    Trying to reframe it:
    GNAP= is defined as a delegation protocol so the main intent is related to a del= egate of the RO (i.e. the end user) that wishes to access the RO's prot= ected resources, through the client.=C2=A0

    Fabie= n=C2=A0

    Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    At various points in the lifecycle=C2=A0of the protecte= d resource the client at the resource server (RS) might be:
    • The= RO (subject) user agent trading payment for a service promise
    • The = RO user agent using the promise to access the protected resource
    • A = delegate of the RO user agent using a different client
    What&#= 39;s vague is where the GNAP AS enters the picture as described above. How = would you describe it?

    Adrian

    =

    On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault <= fabien.imbault@gmail.com> wrote:
    Hi Adrian

    I'm st= ill confused why you're saying the terminology is vague.=C2=A0
    I get the "power" neutrality is not to your liking= , but RQ / user agent is no better in my view.=C2=A0

    Can you elaborate?=C2=A0

    Fabien=C2=A0

    Le jeu. 18 mars 2021 =C3=A0= 00:18, Adrian Gropper <agropper@healthurl.com> a = =C3=A9crit=C2=A0:
    I'm sure y= ou're right. Our vague terminology=C2=A0around client=C2=A0and=C2=A0end= -user leads to my confusion. If GNAP is primarily about delegation=C2=A0the= n, of course, we should=C2=A0avoid any incentives to impersonate or we'= re wasting our time. This is partly why I'm trying to study up on capab= ilities and asking for expert advice from folks like Alan Karp and Mark Mil= ler (cc'd)

    As best I can understand it, the RS has o= nly two choices, it can:
    • store an attribute of the RO a [= DID, email address, GNAP AS URL], or
    • hand the RO a capability as a = sort-of promise and avoid making any entries in an ACL or equivalent.
      • <= /ul>
      When a token comes back to the RS, it will either be:
    • validated according to something associated with the stored RO attrib= ute, or
    • signed by the RS itself.
    Either way, trus= t in the client seems moot.

    Adrian



    On Wed, Mar 17, 2021 at 5:29 PM Justin Rich= er <jricher@mit.edu> wrote:
    On Mar 17, 2021, at 4:55 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    On Wed, Mar 17, 2021 a= t 4:23 PM Tobias Looker <tobias.looker@mat= tr.global> wrote:
    <snip>
    > A client might not hav= e a DID but it could have a VC as a certificate of authenticity linked to s= ome audit mechanism.

    To me a VC would come under t= he assertions umbrella (that is to say a VC could be one type of valid asse= rtion). The client may possess or been presented with a VC that it could in= clude in its request to the AS as a way to identify the subject and perhaps= prove authentication and authorization.

    <= /div>
    I do not assume that the client that interacts with the AS to mak= e a request and receive a token is the same as the client that will present= the token to the RS. In the US HIPAA use-case, for example, the root of tr= ust is a contract between the patient-subject and the doctor-requesting par= ty but the doctor workflow is expected to delegate the token to some other = end-user that may be using a totally different client such as an EHR.
    =


    If the client = that gets the token is not same as the client that uses the token, that is = a violation of core security principles as it allows for (and really design= s for) impersonation by client software. I would have no reason to trust cl= ient software that would hand its credentials over to another piece of soft= ware, and in fact I shouldn=E2=80=99t trust it.=C2=A0

    <= div>I think you may be conflating several different kinds of parties under = the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80=99s entirely p= ossible that one client might call an RS that in turn acts as a client for = something else down stream. But each of those hops is different from the la= st.

    =C2=A0=E2=80=94 Justin

    <= /div>
    <= br>



    --=C2=A0
    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


    --=C2=A0
    TXAuth mailing li= st
    TXAuth@ietf.org
    https://www.ietf.or= g/mailman/listinfo/txauth
    --=C2=A0TXAuth 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


    --=C2=A0
    You know nothing Jon Snow!

    = --=C2=A0
    You= know nothing Jon Snow!

    --00000000000047423a05bde65503-- From nobody Fri Mar 19 10:22:10 2021 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 48D473A1AC4 for ; Fri, 19 Mar 2021 10:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 CCJ9bARtvF2e for ; Fri, 19 Mar 2021 10:22:03 -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 683513A1AC9 for ; Fri, 19 Mar 2021 10:22:03 -0700 (PDT) Received: from [192.168.1.22] (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 12JHLin3004911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Mar 2021 13:21:53 -0400 From: Justin Richer Message-Id: <8DF709AE-B17D-4B53-92FC-723F2C8C2503@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_62CAE91D-E681-40FA-926D-841BB88D02B5" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 19 Mar 2021 13:21:44 -0400 In-Reply-To: Cc: Alejandro Iacobelli , Fabien Imbault , Steve Moore , txauth gnap To: Adrian Gropper References: <43447446-4061-49F2-8486-5A196C3C75E2@mit.edu> <37a04505-84ef-aecf-6913-5aad8330c97c@free.fr> <3FE214B6-CF96-472D-853B-C7C5AC7A73AE@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Should access tokens be opaque or not for the clients ? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 17:22:08 -0000 --Apple-Mail=_62CAE91D-E681-40FA-926D-841BB88D02B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 There=E2=80=99s an important difference here: The AS is software. Always. It plays a specific role within the = protocol. The RO could be a person. It could be an agency. It could be a policy. = They don=E2=80=99t take part in the protocol directly but are involved = in decisions made in the course of the protocol. These are two very, very different things, and they can=E2=80=99t be = conflated. I like the idea of talking in terms of relationships, such as AS-RS (a = protocol relationship) and AS-RO (a trust relationship).=20 =E2=80=94 Justin > On Mar 19, 2021, at 12:37 PM, Adrian Gropper = wrote: >=20 > It might be a good idea to keep the RS to AS relationship out of the = GNAP spec but I=E2=80=99m having a hard time analyzing it in the = abstract.=20 >=20 > My starting perspective is that the RS should not know or care whether = it is dealing with the AS or the RO. This is super important because it = gives the RO unlimited delegation power.=20 >=20 > Cases where the RO wants to give the RS a separate endpoint or other = identity should be allowed by GNAP but might be out of band. This is the = HIPAA API Task Force use case that I have referenced in another thread. = The issue here is that the RS has the option of reaching out to the RO = and requesting confirmation. >=20 > Adrian =20 >=20 > On Fri, Mar 19, 2021 at 11:37 AM Justin Richer > wrote: > My proposal is that the client instance shouldn=E2=80=99t care = what=E2=80=99s in the token, what format it is, etc. >=20 > The RS can care and there should be choices that include random, = sealed, and even plainly signed tokens. That choice is part of the = relationship between the RS and AS, which the core GNAP protocol = doesn=E2=80=99t specify.=20 >=20 > This is why I propose that we extract what=E2=80=99s now section 10 in = the draft and put it into a new document that can more directly discuss = that relationship. These different relationships should be modular.=20 >=20 > =E2=80=94 Justin >=20 >> On Mar 19, 2021, at 11:13 AM, Alejandro Iacobelli = > wrote: >>=20 >> Agree! So what are you saying the proposal should be? Random or = sealed tokens? >>=20 >> El El vie, 19 mar. 2021 a la(s) 10:04, Justin Richer > escribi=C3=B3: >> One of the best ways to protect information in the token is to not = put it in the token in the first place. This is why a some = highly-sensitive application profiles and deployments us randomized = values as tokens. The RS has a way to dereference it, which is = important. >>=20 >> For downstream delegation, like one micro service calling another, = we=E2=80=99re no longer talking about the client knowing the access = token, we=E2=80=99re talking about an RS at the first step. This is = where non-opaque, or encrypted, or other kinds of recoverable data = structures come into play more directly.=20 >>=20 >> To Adrian=E2=80=99s point, sharing the QR code should be up to the = AS=E2=80=99s policy. If Steve gives me a bearer artifact that isn=E2=80=99= t attached to anything that identifies me, then it=E2=80=99s easy for me = to share because the artifact is the identity and proof all in one. The = strawman description below sounds like that. But it=E2=80=99s important = in this design that the AS can also require me to log in with a specific = account, plus present a token, plus type in a secret code, plus present = a hardware key that completes a circuit in the right way (seems like = something Steve would build, tbh), etc. But all of these aren=E2=80=99t = a client talking to a resource, they=E2=80=99re the end-user presenting = things to the AS so that the AS can make a policy decision to issue a = token and allow access.=20 >>=20 >> =E2=80=94 Justin >>=20 >>> On Mar 18, 2021, at 8:23 PM, Alejandro Iacobelli = > wrote: >>>=20 >>> The decision about "opaque" vs "sealed but recoverable" or "signed" = access_token goes way back on the stateless protocols session = management.=20 >>>=20 >>> In my opinion, the software design principle that we must apply here = is the "need to know" principle. This means, the less information an = attacker could get, the better. One thing that JWS explse is all the = context information about a token, so an attacker can get lots of = information just with a look.=20 >>>=20 >>> The next discussion will be what ways of generating opaque tokens = are there and which must we choose (Encrypted vs CSPRNG based). >>>=20 >>> On Thu, 18 Mar 2021 at 21:17, Fabien Imbault = > wrote: >>> Hi Adrian, >>>=20 >>> I'm really not sure I understand here.=20 >>>=20 >>> I get the idea of putting a policy engine in front of your services = to implement ZTA. But I'm not sure I get this way of framing things. It = blurs functional roles and actual services, and most importantly if = everything gets its own AS, it also gets by transitivity its RO'/RQ' = (and then its AS-RO' etc) and so the complexity becomes staggering.=20 >>> Why do we need that?=20 >>>=20 >>> Fabien=20 >>>=20 >>> Le ven. 19 mars 2021 =C3=A0 00:55, Adrian Gropper = > a =C3=A9crit : >>> +1 This aligns with my healthcare use-case to the extent that Justin = can transfer the capability granted by that QR code to Adrian who = happens to be nearby Steve's house. >>>=20 >>> I've tried to capture some of this in my comment to #145 = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment= -802388458 = >>>=20 >>> - Adrian >>>=20 >>> On Thu, Mar 18, 2021 at 2:39 PM Justin Richer > wrote: >>> Right, and in the GNAP model this becomes something my client = instance presents to the AS when I show up. The AS can validate my = presentation of this item and give my client instance a token to call = Steve=E2=80=99s RS. Or if you wanted to get super fancy Steve=E2=80=99s = AS could even challenge my client instance and get a cryptographic = response to prove I have the thing Steve had me scan. But in both cases = it=E2=80=99s part of things that the AS collects in order to create the = access token. >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Mar 18, 2021, at 2:26 PM, Stephen Moore > wrote: >>>>=20 >>>> That in my mind works out great... Say I'm logged into my home = hub/AS. Justin is over and agrees to cat sit, I pull up my client app, = and generate a QR code that has maybe The AS URI, the HomeHub API URL, = and the 'special token to present to AS for a real token'. Justin scans = that QR code with his home controller app, and BAM, he's onboarded as a = guest without even logging into my AS or me dealing with his Auth = provider. >>>> -steve >>>>=20 >>>> On Thu, Mar 18, 2021 at 2:08 PM Justin Richer > wrote: >>>> I think Steve=E2=80=99s use case gives an interesting example of = something that I believe Adrian=E2=80=99s been talking about as well =E2=80= =94 delegating to another person. >>>>=20 >>>> We traditionally think of delegation at the AS to mean =E2=80=9Ca = different user account logs in to the AS=E2=80=9D, and it=E2=80=99s = important to know that this does in fact work. But this could just as = easily be =E2=80=9CSteve sends his friend an artifact to present to the = AS to get access=E2=80=9D. This isn=E2=80=99t Steve (or Steve=E2=80=99s = client software) getting and sending an access token, this is sending = some other set of rights credential to his friend, or his friend=E2=80=99s= software. So then Steve=E2=80=99s AS can have policy that says =E2=80=9Cw= hen I see this rights credential, give an access token for the following = attenuated things, because Steve said so=E2=80=9D. The AS doesn=E2=80=99t = even ever need to know who Steve=E2=80=99s friend is!=20 >>>>=20 >>>> And importantly here, we don=E2=80=99t expect Steve=E2=80=99s = friend to bring their own AS to the party. Steve=E2=80=99s RS has no = reason to trust his friend=E2=80=99s AS, let alone his friend=E2=80=99s = client. But Steve=E2=80=99s AS is in a position to know more about the = rights policies that Steve wants to apply, and so it can use other = technologies like VC=E2=80=99s, DIDs, OIDC, or any number of other = things to let things go through. This pattern is exactly why I think we = need to think of this in terms of what=E2=80=99s currently called = =E2=80=9Cinteraction=E2=80=9D at the AS. It=E2=80=99s not really just = about how the end-user interacts, it=E2=80=99s about how the AS gathers = all the consent and authorization information. I plan to rewrite section = 4 to that effect. >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>> On Mar 18, 2021, at 1:58 PM, Stephen Moore > wrote: >>>>>=20 >>>>> I'm having some concerns with the way you're flipping the trust = here Denis. You seem to indicate that the user has trust in the RS and = the Client and has to gain the trust of the AS. I feel like the least = trustworthy portion of the architecture is the client, because that = seems like it is the most interchangeable component. >>>>> Let me explain by way of a use case I have in mind. >>>>> Let's say I have a smart home. I have devices and data storage and = rule engines that are parts of sensors and hubs I buy for the house. I = have a trust in those devices, because it's hardware, if the company is = leaking data at the hardware level there isn't much I can do other than = buy different sensors. >>>>> In this case, the primary home hub, which is under control of the = homeowner, would also be the AS, as well as a policy agent. = Authentication in the example is outsourced to whatever auth providers = you want. I set up my home using a google account, a friend is staying = and wants access and uses FB for auth... whatever. >>>>> The part that I have little control over is the client my friend = uses on his phone. Or if I change the client on the tablet in the = kitchen to try out something new. These pieces might be single page web = apps, they might be downloaded apps, etc. I do not want them having any = additional information than is necessary. If I give my friend permission = to unlock the door, and control the lights because they are feeding my = cats while I'm away, the client doesn't need to know anything beyond, I = see this home controller, and I have access to these lights and that = door lock. >>>>>=20 >>>>> In your scenarios, the client is spy by design, and if it is a web = app, I don't trust them to not grab my user email address from the AS = and put it on a mailing list it sells to some sketchy company, when the = only other component that needs that information is the RS. >>>>>=20 >>>>> -steve >>>>>=20 >>>>> On Thu, Mar 18, 2021 at 1:21 PM Denis > wrote: >>>>> I have changed the title of this thread, since the original topic = has been closed.=20 >>>>>=20 >>>>> Justin, you are raising the following question: >>>>> The question I have is =E2=80=94 why does the client need to know = what=E2=80=99s in the token?=20 >>>>> Not if they could possibly know, but why would we expect a client = to know and manage the contents of the token?=20 >>>>> The answer is quite simple: so that the end-user may have = confidence into the architecture.=20 >>>>> The seventh of the eleven privacy principles from ISO 29100 (page = 14) is: >>>>> 7. Openness, transparency and notice=20 >>>>> If the access token is considered as a black box for the end-user, = it cannot be confident about the content of the access token. >>>>> Such access token may disclose some private information without = the consent of the end-user. If the access token that it has obtained=20 >>>>> does not match with what has been requested, the client will first = not forward the access token to the RS and then will complain about the = AS. >>>>>=20 >>>>> Denis >>>>>=20 >>>>>=20 >>>>>> Hi Justin,=20 >>>>>>=20 >>>>>> "The access token is fundamentally a conversational artifact = between the AS and the RS which the client is the carrier of." >>>>>> That's right, and a good opportunity to distinguish between the = need for token inspection (i.e. a runtime verification, wherever that = may be)=20 >>>>>> and the need to negotiate the token format (a discovery). That = last part could very well be an extension, as a way to open up the = ecosystem=20 >>>>>> beyond JWTs (which are fine, but come with their own = limitations).=20 >>>>>>=20 >>>>>> Fabien >>>>>>=20 >>>>>> On Thu, Mar 18, 2021 at 5:59 PM Justin Richer > wrote: >>>>>> On Mar 18, 2021, at 11:30 AM, Alan Karp > wrote: >>>>>>>=20 >>>>>>> Justin Richer > wrote: >>>>>>> On Mar 18, 2021, at 12:08 AM, Alan Karp > wrote: >>>>>>>>=20 >>>>>>>> Adrian Gropper > wrote: >>>>>>>>=20 >>>>>>>> Is there an AS involved in the delegation? How and where in the = lifecycle of the protected resource?=20 >>>>>>>>=20 >>>>>>>> If tokens are certificates, the AS need not be involved in = subsequent delegations. The AS must be involved if the tokens are = opaque.=20 >>>>>>>=20 >>>>>>> Tokens are opaque to the client instance. They are not opaque to = the AS. They might be opaque to the RS, but that depends on the kind of = relationship the RS and AS have. GNAP should allow different options = here as there are different use cases for that. >>>>>>>=20 >>>>>>> Tokens are not opaque to the client in SPKI, zcap-ld, Orie's = implementation with VCs, or our Zebra Copy work. Why must they be in = GNAP? >>>>>>=20 >>>>>> The existence of the AS is exactly the reason for this. The AS is = the role that =E2=80=9Cknowledge about the token contents=E2=80=9D has = been outsourced to in the GNAP model (which is based on the OAuth = model). >>>>>>=20 >>>>>> It brings significant simplicity for the client developer. The = question I have is =E2=80=94 why does the client need to know what=E2=80=99= s in the token? Not if they could possibly know, but why would we expect = a client to know and manage the contents of the token?=20 >>>>>>=20 >>>>>> The access token is fundamentally a conversational artifact = between the AS and the RS which the client is the carrier of. The client = is not the audience of the token, nor the creator of the token, nor even = the manager of the token and the rights it represents. The client as a = simple carrier is a powerful model that allows the security layer to get = out of the way of the actual application logic that developers want to = do. >>>>>>=20 >>>>>> =E2=80=94 Justin >>>>>>=20 >>>>>>>=20 >>>>>>> -------------- >>>>>>> Alan Karp >>>>>>>=20 >>>>>>>=20 >>>>>>> On Thu, Mar 18, 2021 at 4:56 AM Justin Richer > wrote: >>>>>>> On Mar 18, 2021, at 12:08 AM, Alan Karp > wrote: >>>>>>>>=20 >>>>>>>> Adrian Gropper > wrote: >>>>>>>>=20 >>>>>>>> Is there an AS involved in the delegation? How and where in the = lifecycle of the protected resource?=20 >>>>>>>>=20 >>>>>>>> If tokens are certificates, the AS need not be involved in = subsequent delegations. The AS must be involved if the tokens are = opaque.=20 >>>>>>>=20 >>>>>>> Tokens are opaque to the client instance. They are not opaque to = the AS. They might be opaque to the RS, but that depends on the kind of = relationship the RS and AS have. GNAP should allow different options = here as there are different use cases for that. >>>>>>>=20 >>>>>>> It would probably be worthwhile to separate the portions of the = spec that talk about the RS-AS relationship into its own standalone = document. A similar approach was taken in UMA2 and it was helpful. = (Though admittedly, as with anything, there are missteps there that we = can hopefully learn from.) >>>>>>>=20 >>>>>>> =E2=80=94 Justin >>>>>>>=20 >>>>>>>>=20 >>>>>>>> -------------- >>>>>>>> Alan Karp >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper = > wrote: >>>>>>>> Sure!=20 >>>>>>>>=20 >>>>>>>> Is there an AS involved in the delegation? How and where in the = lifecycle of the protected resource?=20 >>>>>>>>=20 >>>>>>>> Also your use of "the client" seems to imply that either there = is only one client or the client doesn't matter. Which is it? >>>>>>>>=20 >>>>>>>> Adrian >>>>>>>>=20 >>>>>>>> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault = > wrote: >>>>>>>> Thanks for that.=20 >>>>>>>>=20 >>>>>>>> Trying to reframe it: >>>>>>>> GNAP is defined as a delegation protocol so the main intent is = related to a delegate of the RO (i.e. the end user) that wishes to = access the RO's protected resources, through the client.=20 >>>>>>>>=20 >>>>>>>> Fabien=20 >>>>>>>>=20 >>>>>>>> Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper = > a =C3=A9crit : >>>>>>>> At various points in the lifecycle of the protected resource = the client at the resource server (RS) might be: >>>>>>>> The RO (subject) user agent trading payment for a service = promise >>>>>>>> The RO user agent using the promise to access the protected = resource >>>>>>>> A delegate of the RO user agent using a different client >>>>>>>> What's vague is where the GNAP AS enters the picture as = described above. How would you describe it? >>>>>>>>=20 >>>>>>>> Adrian >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault = > wrote: >>>>>>>> Hi Adrian >>>>>>>>=20 >>>>>>>> I'm still confused why you're saying the terminology is vague.=20= >>>>>>>> I get the "power" neutrality is not to your liking, but RQ / = user agent is no better in my view.=20 >>>>>>>>=20 >>>>>>>> Can you elaborate?=20 >>>>>>>>=20 >>>>>>>> Fabien=20 >>>>>>>>=20 >>>>>>>> Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper = > a =C3=A9crit : >>>>>>>> I'm sure you're right. Our vague terminology around client and = end-user leads to my confusion. If GNAP is primarily about delegation = then, of course, we should avoid any incentives to impersonate or we're = wasting our time. This is partly why I'm trying to study up on = capabilities and asking for expert advice from folks like Alan Karp and = Mark Miller (cc'd) >>>>>>>>=20 >>>>>>>> As best I can understand it, the RS has only two choices, it = can: >>>>>>>> store an attribute of the RO a [DID, email address, GNAP AS = URL], or >>>>>>>> hand the RO a capability as a sort-of promise and avoid making = any entries in an ACL or equivalent. >>>>>>>> When a token comes back to the RS, it will either be: >>>>>>>> validated according to something associated with the stored RO = attribute, or >>>>>>>> signed by the RS itself. >>>>>>>> Either way, trust in the client seems moot. >>>>>>>>=20 >>>>>>>> Adrian >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer > wrote: >>>>>>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper = > wrote: >>>>>>>>>=20 >>>>>>>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker = > wrote: >>>>>>>>> >>>>>>>>> > A client might not have a DID but it could have a VC as a = certificate of authenticity linked to some audit mechanism. >>>>>>>>>=20 >>>>>>>>> To me a VC would come under the assertions umbrella (that is = to say a VC could be one type of valid assertion). The client may = possess or been presented with a VC that it could include in its request = to the AS as a way to identify the subject and perhaps prove = authentication and authorization. >>>>>>>>>=20 >>>>>>>>> I do not assume that the client that interacts with the AS to = make a request and receive a token is the same as the client that will = present the token to the RS. In the US HIPAA use-case, for example, the = root of trust is a contract between the patient-subject and the = doctor-requesting party but the doctor workflow is expected to delegate = the token to some other end-user that may be using a totally different = client such as an EHR. >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> If the client that gets the token is not same as the client = that uses the token, that is a violation of core security principles as = it allows for (and really designs for) impersonation by client software. = I would have no reason to trust client software that would hand its = credentials over to another piece of software, and in fact I shouldn=E2=80= =99t trust it.=20 >>>>>>>>=20 >>>>>>>> I think you may be conflating several different kinds of = parties under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80= =99s entirely possible that one client might call an RS that in turn = acts as a client for something else down stream. But each of those hops = is different from the last. >>>>>>>>=20 >>>>>>>> =E2=80=94 Justin >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> --=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 = >>>>=20 >>>=20 >>> --=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 = >>> --=20 >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >>>=20 >>>=20 >>> --=20 >>> You know nothing Jon Snow! >>=20 >> --=20 >> You know nothing Jon Snow! >=20 --Apple-Mail=_62CAE91D-E681-40FA-926D-841BB88D02B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 There=E2=80=99s an important difference here:

    The AS is software. = Always. It plays a specific role within the protocol.

    The RO could be a = person. It could be an agency. It could be a policy. They don=E2=80=99t = take part in the protocol directly but are involved in decisions made in = the course of the protocol.

    These are two very, very different things, and they can=E2=80=99= t be conflated.

    I like the idea of talking in terms of relationships, such as = AS-RS (a protocol relationship) and AS-RO (a trust = relationship). 

     =E2=80=94 Justin

    On Mar = 19, 2021, at 12:37 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    It might be a good idea to keep = the RS to AS relationship out of the GNAP spec but I=E2=80=99m having a = hard time analyzing it in the abstract. 

    My starting = perspective is that the RS should not know or care whether it is dealing = with the AS or the RO. This is super important because it gives the RO = unlimited delegation power. 

    Cases where the RO wants = to give the RS a separate endpoint or other identity should be allowed = by GNAP but might be out of band. This is the HIPAA API Task Force use = case that I have referenced in another thread. The issue here is that = the RS has the option of reaching out to the RO and requesting = confirmation.

    Adrian  

    On Fri, Mar 19, 2021 at 11:37 AM Justin Richer = <jricher@mit.edu> = wrote:
    My = proposal is that the client instance shouldn=E2=80=99t care what=E2=80=99s= in the token, what format it is, etc.

    The RS can care and there should be = choices that include random, sealed, and even plainly signed tokens. = That choice is part of the relationship between the RS and AS, which the = core GNAP protocol doesn=E2=80=99t specify. 
    This is why I propose that we extract = what=E2=80=99s now section 10 in the draft and put it into a new = document that can more directly discuss that relationship. These = different relationships should be modular. 

     =E2=80= =94 Justin

    On Mar 19, 2021, at 11:13 AM, = Alejandro Iacobelli <aiacobelli.sec@gmail.com> = wrote:

    Agree! So what are you saying the proposal = should be? Random or sealed tokens?

    El El vie, = 19 mar. 2021 a la(s) 10:04, Justin Richer <jricher@mit.edu> escribi=C3=B3:
    One= of the best ways to protect information in the token is to not put it = in the token in the first place. This is why a some highly-sensitive = application profiles and deployments us randomized values as tokens. The = RS has a way to dereference it, which is important.

    For downstream delegation, like one = micro service calling another, we=E2=80=99re no longer talking about the = client knowing the access token, we=E2=80=99re talking about an RS at = the first step. This is where non-opaque, or encrypted, or other kinds = of recoverable data structures come into play more = directly. 

    To Adrian=E2=80=99s point, sharing the QR code should be up = to the AS=E2=80=99s policy. If Steve gives me a bearer artifact that = isn=E2=80=99t attached to anything that identifies me, then it=E2=80=99s = easy for me to share because the artifact is the identity and proof all = in one. The strawman description below sounds like that. But it=E2=80=99s = important in this design that the AS can also require me to log in with = a specific account, plus present a token, plus type in a secret code, = plus present a hardware key that completes a circuit in the right way = (seems like something Steve would build, tbh), etc. But all of these = aren=E2=80=99t a client talking to a resource, they=E2=80=99re the = end-user  presenting things to the AS so that the AS can make a = policy decision to issue a token and allow access. 

     =E2=80= =94 Justin

    On Mar 18, 2021, at 8:23 PM, = Alejandro Iacobelli <aiacobelli.sec@gmail.com> = wrote:

    The decision about "opaque" vs = "sealed but recoverable" or "signed" access_token goes way back on the = stateless protocols session management. 

    In my opinion, the = software design principle that we must apply here is the "need to know" = principle. This means, the less information an attacker could get, = the better. One thing that JWS explse is all the context information = about a token, so an attacker can get lots of information just with = a look. 

    The next discussion will be what ways of generating opaque = tokens are there and which must we choose (Encrypted vs CSPRNG = based).

    On Thu, 18 Mar 2021 at 21:17, Fabien = Imbault <fabien.imbault@gmail.com> wrote:
    Hi = Adrian,

    I'm really not sure I understand here. 

    I get the idea of putting a policy engine in = front of your services to implement ZTA. But I'm not sure I get this way = of framing things. It blurs functional roles and actual services, and = most importantly if everything gets its own AS, it also gets by = transitivity its RO'/RQ' (and then its AS-RO' etc) and so the complexity = becomes staggering. 
    Why do we = need that? 

    Fabien 

    Le ven. 19 = mars 2021 =C3=A0 00:55, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit :
    +1 This aligns with my healthcare use-case to the = extent that Justin can transfer the capability granted by that QR code = to Adrian who happens to be nearby Steve's house.

    I've tried to capture = some of this in my comment to #145 https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#i= ssuecomment-802388458

    - Adrian

    On Thu, Mar = 18, 2021 at 2:39 PM Justin Richer <jricher@mit.edu> = wrote:
    Right, and in the GNAP = model this becomes something my client instance presents to the AS when = I show up. The AS can validate my presentation of this item and give my = client instance a token to call Steve=E2=80=99s RS. Or if you wanted to = get super fancy Steve=E2=80=99s AS could even challenge my client = instance and get a cryptographic response to prove I have the thing = Steve had me scan. But in both cases it=E2=80=99s part of things that = the AS collects in order to create the access token.

     =E2=80=94 = Justin

    On Mar 18, 2021, at 2:26 PM, = Stephen Moore <srmoore@gmail.com> wrote:

    That in my mind = works out great... Say I'm logged into my home hub/AS. Justin is over = and agrees to cat sit, I pull up my client app, and generate a QR code = that has maybe The AS URI, the HomeHub API URL, and the 'special token = to present to AS for a real token'. Justin scans that QR code with his = home controller app, and BAM, he's onboarded as a guest without even = logging into my AS or me dealing with his Auth provider.
    -steve

    On Thu, Mar = 18, 2021 at 2:08 PM Justin Richer <jricher@mit.edu> = wrote:
    I think Steve=E2=80=99s = use case gives an interesting example of something that I believe = Adrian=E2=80=99s been talking about as well =E2=80=94 delegating to = another person.

    We = traditionally think of delegation at the AS to mean =E2=80=9Ca different = user account logs in to the AS=E2=80=9D, and it=E2=80=99s important to = know that this does in fact work. But this could just as easily be = =E2=80=9CSteve sends his friend an artifact to present to the AS to get = access=E2=80=9D. This isn=E2=80=99t Steve (or Steve=E2=80=99s client = software) getting and sending an access token, this is sending some = other set of rights credential to his friend, or his friend=E2=80=99s = software. So then Steve=E2=80=99s AS can have policy that says =E2=80=9Cwh= en I see this rights credential, give an access token for the following = attenuated things, because Steve said so=E2=80=9D. The AS doesn=E2=80=99t = even ever need to know who Steve=E2=80=99s friend is! 

    And importantly here, we = don=E2=80=99t expect Steve=E2=80=99s friend to bring their own AS to the = party. Steve=E2=80=99s RS has no reason to trust his friend=E2=80=99s = AS, let alone his friend=E2=80=99s client. But Steve=E2=80=99s AS is in = a position to know more about the rights policies that Steve wants to = apply, and so it can use other technologies like VC=E2=80=99s, DIDs, = OIDC, or any number of other things to let things go through. This = pattern is exactly why I think we need to think of this in terms of = what=E2=80=99s currently called =E2=80=9Cinteraction=E2=80=9D at the AS. = It=E2=80=99s not really just about how the end-user interacts, it=E2=80=99= s about how the AS gathers all the consent and authorization = information. I plan to rewrite section 4 to that effect.

     =E2=80=94 = Justin

    On Mar 18, 2021, at 1:58 PM, = Stephen Moore <srmoore@gmail.com> wrote:

    I'm having some = concerns with the way you're flipping the trust here Denis. You seem to = indicate that the user has trust in the RS and the Client and has to = gain the trust of the AS. I feel like the least trustworthy portion of = the architecture is the client, because that seems like it is the most = interchangeable component.
     Let me explain by way of = a use case I have in mind.
    Let's say I have a smart = home. I have devices and data storage and rule engines that are parts of = sensors and hubs I buy for the house. I have a trust in those devices, = because it's hardware, if the company is leaking data at the hardware = level there isn't much I can do other than buy different = sensors.
    In this case, the primary home hub, which = is under control of the homeowner, would also be the AS, as well as a = policy agent.  Authentication in the example is outsourced to = whatever auth providers you want. I set up my home using a google = account, a friend is staying and wants access and uses FB for auth... = whatever.
    The part that I have little control over = is the client my friend uses on his phone. Or if I change the client on = the tablet in the kitchen to try out something new. These = pieces might be single page web apps, they might be downloaded = apps, etc. I do not want them having any additional information than is = necessary. If I give my friend permission to unlock the door, and = control the lights because they are feeding my cats while I'm away, the = client doesn't need to know anything beyond, I see this home controller, = and I have access to these lights and that door lock.

    In your scenarios, the = client is spy by design, and if it is a web app, I don't trust them to = not grab my user email address from the AS and put it on a mailing = list it sells to some sketchy company, when the only other = component that needs that information is the RS.

    -steve

    On Thu, Mar 18, 2021 at 1:21 PM Denis <denis.ietf@free.fr> wrote:
    I have changed the title of this thread, since the original = topic has been closed. 

    Justin, you are raising the following = question:
    The question I = have is =E2=80=94 why does the client need to know what=E2=80=99s in the = token? 
    Not if they could = possibly know, but why would we expect a client to know and manage the = contents of the token? 
    The answer is quite = simple: so that the end-user may have confidence into the = architecture. 
    The seventh of the eleven privacy principles from ISO 29100 = (page 14) is:
    7.= Openness, transparency and notice 
    If the access token is = considered as a black box for the end-user, it cannot be confident about = the content of the access token.
    Such access token may = disclose some private information without the consent of the end-user. = If the access token that it has obtained 
    does not match with what has been requested, the client will = first not forward the access token to the RS and then will complain = about the AS.

    Denis


    Hi Justin, 

    "The access token is fundamentally a conversational artifact = between the AS and the RS which the client is the carrier of."
    That's right, and a good opportunity to distinguish = between the need for token inspection (i.e. a runtime verification, = wherever that may be) 
    and = the need to negotiate the token format (a discovery). That last part = could very well be an extension, as a way to open up the ecosystem 
    beyond JWTs (which are fine, but = come with their own limitations). 

    Fabien

    On Thu, Mar = 18, 2021 at 5:59 PM Justin Richer <jricher@mit.edu> = wrote:
    On Mar 18, 2021, at 11:30 = AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 12:08 = AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Adrian Gropper <agropper@healthurl.com> wrote:

    Is there an AS involved = in the delegation? How and where in the lifecycle of the protected = resource? 

    If tokens are certificates, the AS need = not be involved in subsequent delegations.  The AS must be involved = if the tokens are opaque. 

    Tokens are opaque to the = client instance. They are not opaque to the AS. They might be opaque to = the RS, but that depends on the kind of relationship the RS and AS have. = GNAP should allow different options here as there are different use = cases for that.

    Tokens are = not opaque to the client in SPKI, zcap-ld, Orie's implementation with = VCs, or our Zebra Copy work.  Why must they be in = GNAP?

    The existence of the AS is exactly the = reason for this. The AS is the role that =E2=80=9Cknowledge about the = token contents=E2=80=9D has been outsourced to in the GNAP model (which = is based on the OAuth model).

    It brings significant simplicity for = the client developer. The question I have is =E2=80=94 why does the = client need to know what=E2=80=99s in the token? Not if they could = possibly know, but why would we expect a client to know and manage the = contents of the token? 

    The access token is fundamentally a = conversational artifact between the AS and the RS which the client is = the carrier of. The client is not the audience of the token, nor the = creator of the token, nor even the manager of the token and the rights = it represents. The client as a simple carrier is a powerful model that = allows the security layer to get out of the way of the actual = application logic that developers want to do.

     =E2=80=94 Justin


    --------------
    Alan = Karp


    On Thu, Mar = 18, 2021 at 4:56 AM Justin Richer <jricher@mit.edu> = wrote:
    On Mar 18, 2021, at 12:08 = AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Adrian Gropper <agropper@healthurl.com> wrote:

    Is there an AS involved = in the delegation? How and where in the lifecycle of the protected = resource? 

    If tokens are certificates, the AS need = not be involved in subsequent delegations.  The AS must be involved = if the tokens are opaque. 

    Tokens are opaque to the = client instance. They are not opaque to the AS. They might be opaque to = the RS, but that depends on the kind of relationship the RS and AS have. = GNAP should allow different options here as there are different use = cases for that.

    It would probably be worthwhile to separate the portions of = the spec that talk about the RS-AS relationship into its own standalone = document. A similar approach was taken in UMA2 and it was helpful. = (Though admittedly, as with anything, there are missteps there that we = can hopefully learn from.)

     =E2=80=94 Justin


    --------------
    Alan = Karp


    On Wed, Mar = 17, 2021 at 8:54 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Sure! 
    Is there an AS involved = in the delegation? How and where in the lifecycle of the protected = resource? 

    Also = your use of "the client" seems to imply that either there is only one = client or the client doesn't matter. Which is it?

    Adrian

    On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Thanks for that. 

    Trying to reframe = it:
    GNAP is defined as a delegation = protocol so the main intent is related to a delegate of the RO (i.e. the = end user) that wishes to access the RO's protected resources, through = the client. 

    Fabien 

    Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper = <agropper@healthurl.com> a = =C3=A9crit :
    At various = points in the lifecycle of the protected resource the client at the = resource server (RS) might be:
    • The RO (subject) user agent trading payment for a service = promise
    • The RO user agent using the promise to access = the protected resource
    • A delegate of the RO user = agent using a different client
    What's vague is = where the GNAP AS enters the picture as described above. How would you = describe it?

    Adrian


    On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault = <fabien.imbault@gmail.com> = wrote:
    Hi = Adrian

    I'm still confused why you're saying the terminology is = vague. 
    I get the "power" = neutrality is not to your liking, but RQ / user agent is no better in my = view. 

    Can you elaborate? 

    Fabien 

    Le jeu. 18 = mars 2021 =C3=A0 00:18, Adrian Gropper <agropper@healthurl.com> a = =C3=A9crit :
    I'm sure = you're right. Our vague terminology around = client and end-user leads to my confusion. If GNAP is = primarily about delegation then, of course, we should avoid = any incentives to impersonate or we're wasting our time. This is partly = why I'm trying to study up on capabilities and asking for expert advice = from folks like Alan Karp and Mark Miller (cc'd)

    As best I can understand it, the RS has = only two choices, it can:
    • store an attribute of the RO a [DID, email address, GNAP AS = URL], or
    • hand the RO a capability as a sort-of = promise and avoid making any entries in an ACL or = equivalent.
    When a token comes back to the RS, = it will either be:
    • validated according to something associated with the stored = RO attribute, or
    • signed by the RS = itself.
    Either way, trust in the client seems = moot.

    Adrian



    On Wed, Mar = 17, 2021 at 5:29 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 17, 2021, at 4:55 = PM, Adrian Gropper <agropper@healthurl.com> wrote:

    On = Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <tobias.looker@mattr.global> wrote:
    <snip>
    > A client might not = have a DID but it could have a VC as a certificate of authenticity = linked to some audit mechanism.

    To me a VC would come under the = assertions umbrella (that is to say a VC could be one type of valid = assertion). The client may possess or been presented with a VC that it = could include in its request to the AS as a way to identify the subject = and perhaps prove authentication and = authorization.

    I do not assume that the client that = interacts with the AS to make a request and receive a token is the same = as the client that will present the token to the RS. In the US HIPAA = use-case, for example, the root of trust is a contract between the = patient-subject and the doctor-requesting party but the doctor workflow = is expected to delegate the token to some other end-user that may be = using a totally different client such as an EHR.


    If the client that gets the token is not same as the client = that uses the token, that is a violation of core security principles as = it allows for (and really designs for) impersonation by client software. = I would have no reason to trust client software that would hand its = credentials over to another piece of software, and in fact I shouldn=E2=80= =99t trust it. 

    I think you may be conflating several different kinds of = parties under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80= =99s entirely possible that one client might call an RS that in turn = acts as a client for something else down stream. But each of those hops = is different from the last.

     =E2=80=94 Justin

    =




    -- 
    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
    -- 
    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


    -- 
    You = know nothing Jon Snow!

    -- 
    You know = nothing Jon Snow!


    = --Apple-Mail=_62CAE91D-E681-40FA-926D-841BB88D02B5-- From nobody Fri Mar 19 10:26:58 2021 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 652583A1AD9 for ; Fri, 19 Mar 2021 10:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 LllbeiExI0ni for ; Fri, 19 Mar 2021 10:26:51 -0700 (PDT) Received: from mail-ua1-f45.google.com (mail-ua1-f45.google.com [209.85.222.45]) (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 404643A1B2B for ; Fri, 19 Mar 2021 10:26:47 -0700 (PDT) Received: by mail-ua1-f45.google.com with SMTP id 97so3279239uav.7 for ; Fri, 19 Mar 2021 10:26:47 -0700 (PDT) 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=HrvMJAPyZJ+W0Vrn/wUpHL4RqY4XSFTSXGhWFBR6zxA=; b=gs1wv00hsQuHU3BWNnQu81NmrVDHThplmcX75q9cL6uD4ktCvK5vTHA8vioUgXjxW6 utKSA57nlPkHg03rkrtnyMwwR9/RMt4Msf+WQLOjeZKAefSeb88/sZGrrm6ZPDD9tlTP rHhJqxMS1YXsJ9JjM5pBRTumLL/1GO4lzpPEW1xR8pF3N30AYxRYIMJuBfMJPcYXfxB7 akg/QLy8aE1hTp49o4lQ9fqKMsz/XvzVWsDalzDX3mBi4uxXzTLnemWiHysQp3eV2v0N jmbpjtnr6CQ8D3lazo8m3ThjaQV9ytKXF0xZATgvDSGOA9T1LVfF2+Ke4Kjv2Pnu5BuP c/Ew== X-Gm-Message-State: AOAM532SzFFv3ft5KkXExooesS8i4/e6zsdGVyOx8WTkfG9M6RO9APix AMmGnb2JmXzhuu0ouwAbSFxb7BR2NgDITDQv3LQ= X-Google-Smtp-Source: ABdhPJzGfZxl1M7k6xoR8cjxLgRutHO+DBLFgNBOevG5FTZCtcuS3EWSNbiMn8o/ApOxOT9MNtVxYQXgI2YAzhJbG1c= X-Received: by 2002:a9f:3766:: with SMTP id a35mr2948203uae.128.1616174806014; Fri, 19 Mar 2021 10:26:46 -0700 (PDT) MIME-Version: 1.0 References: <43447446-4061-49F2-8486-5A196C3C75E2@mit.edu> <37a04505-84ef-aecf-6913-5aad8330c97c@free.fr> <3FE214B6-CF96-472D-853B-C7C5AC7A73AE@mit.edu> <8DF709AE-B17D-4B53-92FC-723F2C8C2503@mit.edu> In-Reply-To: <8DF709AE-B17D-4B53-92FC-723F2C8C2503@mit.edu> From: Adrian Gropper Date: Fri, 19 Mar 2021 13:26:34 -0400 Message-ID: To: Justin Richer Cc: Alejandro Iacobelli , Fabien Imbault , Steve Moore , txauth gnap Content-Type: multipart/alternative; boundary="000000000000351fc205bde70583" Archived-At: Subject: Re: [GNAP] Should access tokens be opaque or not for the clients ? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 17:26:56 -0000 --000000000000351fc205bde70583 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree. The problem is that powerful RS operators introduce things like Capchas that hassle the RO. Sometimes this is justified but often it reflects an inadequate protocol. Adrian On Fri, Mar 19, 2021 at 1:22 PM Justin Richer wrote: > There=E2=80=99s an important difference here: > > The AS is software. Always. It plays a specific role within the protocol. > > The RO could be a person. It could be an agency. It could be a policy. > They don=E2=80=99t take part in the protocol directly but are involved in= decisions > made in the course of the protocol. > > These are two very, very different things, and they can=E2=80=99t be conf= lated. > > I like the idea of talking in terms of relationships, such as AS-RS (a > protocol relationship) and AS-RO (a trust relationship). > > =E2=80=94 Justin > > On Mar 19, 2021, at 12:37 PM, Adrian Gropper > wrote: > > It might be a good idea to keep the RS to AS relationship out of the GNAP > spec but I=E2=80=99m having a hard time analyzing it in the abstract. > > My starting perspective is that the RS should not know or care whether it > is dealing with the AS or the RO. This is super important because it give= s > the RO unlimited delegation power. > > Cases where the RO wants to give the RS a separate endpoint or other > identity should be allowed by GNAP but might be out of band. This is the > HIPAA API Task Force use case that I have referenced in another thread. T= he > issue here is that the RS has the option of reaching out to the RO and > requesting confirmation. > > Adrian > > On Fri, Mar 19, 2021 at 11:37 AM Justin Richer wrote: > >> My proposal is that the client instance shouldn=E2=80=99t care what=E2= =80=99s in the >> token, what format it is, etc. >> >> The RS can care and there should be choices that include random, sealed, >> and even plainly signed tokens. That choice is part of the relationship >> between the RS and AS, which the core GNAP protocol doesn=E2=80=99t spec= ify. >> >> This is why I propose that we extract what=E2=80=99s now section 10 in t= he draft >> and put it into a new document that can more directly discuss that >> relationship. These different relationships should be modular. >> >> =E2=80=94 Justin >> >> On Mar 19, 2021, at 11:13 AM, Alejandro Iacobelli < >> aiacobelli.sec@gmail.com> wrote: >> >> Agree! So what are you saying the proposal should be? Random or sealed >> tokens? >> >> El El vie, 19 mar. 2021 a la(s) 10:04, Justin Richer >> escribi=C3=B3: >> >>> One of the best ways to protect information in the token is to not put >>> it in the token in the first place. This is why a some highly-sensitive >>> application profiles and deployments us randomized values as tokens. Th= e RS >>> has a way to dereference it, which is important. >>> >>> For downstream delegation, like one micro service calling another, we= =E2=80=99re >>> no longer talking about the client knowing the access token, we=E2=80= =99re talking >>> about an RS at the first step. This is where non-opaque, or encrypted, = or >>> other kinds of recoverable data structures come into play more directly= . >>> >>> To Adrian=E2=80=99s point, sharing the QR code should be up to the AS= =E2=80=99s policy. >>> If Steve gives me a bearer artifact that isn=E2=80=99t attached to anyt= hing that >>> identifies me, then it=E2=80=99s easy for me to share because the artif= act is the >>> identity and proof all in one. The strawman description below sounds li= ke >>> that. But it=E2=80=99s important in this design that the AS can also re= quire me to >>> log in with a specific account, plus present a token, plus type in a se= cret >>> code, plus present a hardware key that completes a circuit in the right= way >>> (seems like something Steve would build, tbh), etc. But all of these ar= en=E2=80=99t >>> a client talking to a resource, they=E2=80=99re the end-user presentin= g things to >>> the AS so that the AS can make a policy decision to issue a token and a= llow >>> access. >>> >>> =E2=80=94 Justin >>> >>> On Mar 18, 2021, at 8:23 PM, Alejandro Iacobelli < >>> aiacobelli.sec@gmail.com> wrote: >>> >>> The decision about "opaque" vs "sealed but recoverable" or "signed" >>> access_token goes way back on the stateless protocols session managemen= t. >>> >>> In my opinion, the software design principle that we must apply here is >>> the "need to know" principle. This means, the less information an attac= ker >>> could get, the better. One thing that JWS explse is all the context >>> information about a token, so an attacker can get lots of information j= ust >>> with a look. >>> >>> The next discussion will be what ways of generating opaque tokens are >>> there and which must we choose (Encrypted vs CSPRNG based). >>> >>> On Thu, 18 Mar 2021 at 21:17, Fabien Imbault >>> wrote: >>> >>>> Hi Adrian, >>>> >>>> I'm really not sure I understand here. >>>> >>>> I get the idea of putting a policy engine in front of your services to >>>> implement ZTA. But I'm not sure I get this way of framing things. It b= lurs >>>> functional roles and actual services, and most importantly if everythi= ng >>>> gets its own AS, it also gets by transitivity its RO'/RQ' (and then it= s >>>> AS-RO' etc) and so the complexity becomes staggering. >>>> Why do we need that? >>>> >>>> Fabien >>>> >>>> Le ven. 19 mars 2021 =C3=A0 00:55, Adrian Gropper >>>> a =C3=A9crit : >>>> >>>>> +1 This aligns with my healthcare use-case to the extent that Justin >>>>> can transfer the capability granted by that QR code to Adrian who hap= pens >>>>> to be nearby Steve's house. >>>>> >>>>> I've tried to capture some of this in my comment to #145 >>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issueco= mment-802388458 >>>>> >>>>> - Adrian >>>>> >>>>> On Thu, Mar 18, 2021 at 2:39 PM Justin Richer wrote= : >>>>> >>>>>> Right, and in the GNAP model this becomes something my client >>>>>> instance presents to the AS when I show up. The AS can validate my >>>>>> presentation of this item and give my client instance a token to cal= l >>>>>> Steve=E2=80=99s RS. Or if you wanted to get super fancy Steve=E2=80= =99s AS could even >>>>>> challenge my client instance and get a cryptographic response to pro= ve I >>>>>> have the thing Steve had me scan. But in both cases it=E2=80=99s par= t of things >>>>>> that the AS collects in order to create the access token. >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> On Mar 18, 2021, at 2:26 PM, Stephen Moore wrote= : >>>>>> >>>>>> That in my mind works out great... Say I'm logged into my home >>>>>> hub/AS. Justin is over and agrees to cat sit, I pull up my client ap= p, and >>>>>> generate a QR code that has maybe The AS URI, the HomeHub API URL, a= nd the >>>>>> 'special token to present to AS for a real token'. Justin scans that= QR >>>>>> code with his home controller app, and BAM, he's onboarded as a gues= t >>>>>> without even logging into my AS or me dealing with his Auth provider= . >>>>>> -steve >>>>>> >>>>>> On Thu, Mar 18, 2021 at 2:08 PM Justin Richer >>>>>> wrote: >>>>>> >>>>>>> I think Steve=E2=80=99s use case gives an interesting example of so= mething >>>>>>> that I believe Adrian=E2=80=99s been talking about as well =E2=80= =94 delegating to another >>>>>>> person. >>>>>>> >>>>>>> We traditionally think of delegation at the AS to mean =E2=80=9Ca d= ifferent >>>>>>> user account logs in to the AS=E2=80=9D, and it=E2=80=99s important= to know that this does >>>>>>> in fact work. But this could just as easily be =E2=80=9CSteve sends= his friend an >>>>>>> artifact to present to the AS to get access=E2=80=9D. This isn=E2= =80=99t Steve (or Steve=E2=80=99s >>>>>>> client software) getting and sending an access token, this is sendi= ng some >>>>>>> other set of rights credential to his friend, or his friend=E2=80= =99s software. So >>>>>>> then Steve=E2=80=99s AS can have policy that says =E2=80=9Cwhen I s= ee this rights >>>>>>> credential, give an access token for the following attenuated thing= s, >>>>>>> because Steve said so=E2=80=9D. The AS doesn=E2=80=99t even ever ne= ed to know who Steve=E2=80=99s >>>>>>> friend is! >>>>>>> >>>>>>> And importantly here, we don=E2=80=99t expect Steve=E2=80=99s frien= d to bring their >>>>>>> own AS to the party. Steve=E2=80=99s RS has no reason to trust his = friend=E2=80=99s AS, let >>>>>>> alone his friend=E2=80=99s client. But Steve=E2=80=99s AS is in a p= osition to know more >>>>>>> about the rights policies that Steve wants to apply, and so it can = use >>>>>>> other technologies like VC=E2=80=99s, DIDs, OIDC, or any number of = other things to >>>>>>> let things go through. This pattern is exactly why I think we need = to think >>>>>>> of this in terms of what=E2=80=99s currently called =E2=80=9Cintera= ction=E2=80=9D at the AS. It=E2=80=99s >>>>>>> not really just about how the end-user interacts, it=E2=80=99s abou= t how the AS >>>>>>> gathers all the consent and authorization information. I plan to re= write >>>>>>> section 4 to that effect. >>>>>>> >>>>>>> =E2=80=94 Justin >>>>>>> >>>>>>> On Mar 18, 2021, at 1:58 PM, Stephen Moore >>>>>>> wrote: >>>>>>> >>>>>>> I'm having some concerns with the way you're flipping the trust her= e >>>>>>> Denis. You seem to indicate that the user has trust in the RS and t= he >>>>>>> Client and has to gain the trust of the AS. I feel like the least >>>>>>> trustworthy portion of the architecture is the client, because that= seems >>>>>>> like it is the most interchangeable component. >>>>>>> Let me explain by way of a use case I have in mind. >>>>>>> Let's say I have a smart home. I have devices and data storage and >>>>>>> rule engines that are parts of sensors and hubs I buy for the house= . I have >>>>>>> a trust in those devices, because it's hardware, if the company is = leaking >>>>>>> data at the hardware level there isn't much I can do other than buy >>>>>>> different sensors. >>>>>>> In this case, the primary home hub, which is under control of the >>>>>>> homeowner, would also be the AS, as well as a policy agent. Authen= tication >>>>>>> in the example is outsourced to whatever auth providers you want. I= set up >>>>>>> my home using a google account, a friend is staying and wants acces= s and >>>>>>> uses FB for auth... whatever. >>>>>>> The part that I have little control over is the client my friend >>>>>>> uses on his phone. Or if I change the client on the tablet in the k= itchen >>>>>>> to try out something new. These pieces might be single page web app= s, they >>>>>>> might be downloaded apps, etc. I do not want them having any additi= onal >>>>>>> information than is necessary. If I give my friend permission to un= lock the >>>>>>> door, and control the lights because they are feeding my cats while= I'm >>>>>>> away, the client doesn't need to know anything beyond, I see this h= ome >>>>>>> controller, and I have access to these lights and that door lock. >>>>>>> >>>>>>> In your scenarios, the client is spy by design, and if it is a web >>>>>>> app, I don't trust them to not grab my user email address from the = AS and >>>>>>> put it on a mailing list it sells to some sketchy company, when the= only >>>>>>> other component that needs that information is the RS. >>>>>>> >>>>>>> -steve >>>>>>> >>>>>>> On Thu, Mar 18, 2021 at 1:21 PM Denis wrote: >>>>>>> >>>>>>>> I have changed the title of this thread, since the original topic >>>>>>>> has been closed. >>>>>>>> >>>>>>>> Justin, you are raising the following question: >>>>>>>> >>>>>>>> The question I have is =E2=80=94 why does the client need to know = what=E2=80=99s in >>>>>>>> the token? >>>>>>>> Not if they could possibly know, but why would we expect a client >>>>>>>> to know and manage the contents of the token? >>>>>>>> >>>>>>>> The answer is quite simple: so that the end-user may have >>>>>>>> confidence into the architecture. >>>>>>>> The seventh of the eleven privacy principles from ISO 29100 (page >>>>>>>> 14) is: >>>>>>>> >>>>>>>> *7. Openness, transparency and notice * >>>>>>>> >>>>>>>> If the access token is considered as a black box for the end-user, >>>>>>>> it cannot be confident about the content of the access token. >>>>>>>> Such access token may disclose some private information without th= e >>>>>>>> consent of the end-user. If the access token that it has obtained >>>>>>>> does not match with what has been requested, the client will first >>>>>>>> not forward the access token to the RS and then will complain abou= t the AS. >>>>>>>> >>>>>>>> Denis >>>>>>>> >>>>>>>> >>>>>>>> Hi Justin, >>>>>>>> >>>>>>>> "The access token is fundamentally a conversational artifact >>>>>>>> between the AS and the RS which the client is the carrier of." >>>>>>>> That's right, and a good opportunity to distinguish between the >>>>>>>> need for token inspection (i.e. a runtime verification, wherever t= hat may >>>>>>>> be) >>>>>>>> and the need to negotiate the token format (a discovery). That las= t >>>>>>>> part could very well be an extension, as a way to open up the ecos= ystem >>>>>>>> >>>>>>>> beyond JWTs (which are fine, but come with their own limitations). >>>>>>>> >>>>>>>> Fabien >>>>>>>> >>>>>>>> On Thu, Mar 18, 2021 at 5:59 PM Justin Richer >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On Mar 18, 2021, at 11:30 AM, Alan Karp >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Justin Richer wrote: >>>>>>>>> >>>>>>>>>> On Mar 18, 2021, at 12:08 AM, Alan Karp >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Adrian Gropper wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Is there an AS involved in the delegation? How and where in the >>>>>>>>>>> lifecycle of the protected resource? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> If tokens are certificates, the AS need not be involved in >>>>>>>>>> subsequent delegations. The AS must be involved if the tokens a= re opaque. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Tokens are opaque to the client instance. They are not opaque to >>>>>>>>>> the AS. They might be opaque to the RS, but that depends on the = kind of >>>>>>>>>> relationship the RS and AS have. GNAP should allow different opt= ions here >>>>>>>>>> as there are different use cases for that. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Tokens are not opaque to the client in SPKI, zcap-ld, Orie's >>>>>>>>> implementation with VCs, or our Zebra Copy work. Why must they b= e in GNAP? >>>>>>>>> >>>>>>>>> >>>>>>>>> The existence of the AS is exactly the reason for this. The AS is >>>>>>>>> the role that =E2=80=9Cknowledge about the token contents=E2=80= =9D has been outsourced to >>>>>>>>> in the GNAP model (which is based on the OAuth model). >>>>>>>>> >>>>>>>>> It brings significant simplicity for the client developer. The >>>>>>>>> question I have is =E2=80=94 why does the client need to know wha= t=E2=80=99s in the token? >>>>>>>>> Not if they could possibly know, but why would we expect a client= to know >>>>>>>>> and manage the contents of the token? >>>>>>>>> >>>>>>>>> The access token is fundamentally a conversational artifact >>>>>>>>> between the AS and the RS which the client is the carrier of. The= client is >>>>>>>>> not the audience of the token, nor the creator of the token, nor = even the >>>>>>>>> manager of the token and the rights it represents. The client as = a simple >>>>>>>>> carrier is a powerful model that allows the security layer to get= out of >>>>>>>>> the way of the actual application logic that developers want to d= o. >>>>>>>>> >>>>>>>>> =E2=80=94 Justin >>>>>>>>> >>>>>>>>> >>>>>>>>> -------------- >>>>>>>>> Alan Karp >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Mar 18, 2021 at 4:56 AM Justin Richer >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> On Mar 18, 2021, at 12:08 AM, Alan Karp >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Adrian Gropper wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Is there an AS involved in the delegation? How and where in the >>>>>>>>>>> lifecycle of the protected resource? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> If tokens are certificates, the AS need not be involved in >>>>>>>>>> subsequent delegations. The AS must be involved if the tokens a= re opaque. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Tokens are opaque to the client instance. They are not opaque to >>>>>>>>>> the AS. They might be opaque to the RS, but that depends on the = kind of >>>>>>>>>> relationship the RS and AS have. GNAP should allow different opt= ions here >>>>>>>>>> as there are different use cases for that. >>>>>>>>>> >>>>>>>>>> It would probably be worthwhile to separate the portions of the >>>>>>>>>> spec that talk about the RS-AS relationship into its own standal= one >>>>>>>>>> document. A similar approach was taken in UMA2 and it was helpfu= l. (Though >>>>>>>>>> admittedly, as with anything, there are missteps there that we c= an >>>>>>>>>> hopefully learn from.) >>>>>>>>>> >>>>>>>>>> =E2=80=94 Justin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -------------- >>>>>>>>>> Alan Karp >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper < >>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>> >>>>>>>>>>> Sure! >>>>>>>>>>> >>>>>>>>>>> Is there an AS involved in the delegation? How and where in the >>>>>>>>>>> lifecycle of the protected resource? >>>>>>>>>>> >>>>>>>>>>> Also your use of "the client" seems to imply that either there >>>>>>>>>>> is only one client or the client doesn't matter. Which is it? >>>>>>>>>>> >>>>>>>>>>> Adrian >>>>>>>>>>> >>>>>>>>>>> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault < >>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Thanks for that. >>>>>>>>>>>> >>>>>>>>>>>> Trying to reframe it: >>>>>>>>>>>> GNAP is defined as a delegation protocol so the main intent is >>>>>>>>>>>> related to a delegate of the RO (i.e. the end user) that wishe= s to access >>>>>>>>>>>> the RO's protected resources, through the client. >>>>>>>>>>>> >>>>>>>>>>>> Fabien >>>>>>>>>>>> >>>>>>>>>>>> Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper < >>>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>>> >>>>>>>>>>>>> At various points in the lifecycle of the protected resource >>>>>>>>>>>>> the client at the resource server (RS) might be: >>>>>>>>>>>>> >>>>>>>>>>>>> - The RO (subject) user agent trading payment for a >>>>>>>>>>>>> service promise >>>>>>>>>>>>> - The RO user agent using the promise to access the >>>>>>>>>>>>> protected resource >>>>>>>>>>>>> - A delegate of the RO user agent using a different client >>>>>>>>>>>>> >>>>>>>>>>>>> What's vague is where the GNAP AS enters the picture as >>>>>>>>>>>>> described above. How would you describe it? >>>>>>>>>>>>> >>>>>>>>>>>>> Adrian >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault < >>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Adrian >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm still confused why you're saying the terminology is >>>>>>>>>>>>>> vague. >>>>>>>>>>>>>> I get the "power" neutrality is not to your liking, but RQ / >>>>>>>>>>>>>> user agent is no better in my view. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Can you elaborate? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>> >>>>>>>>>>>>>> Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper < >>>>>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm sure you're right. Our vague terminology around >>>>>>>>>>>>>>> client and end-user leads to my confusion. If GNAP is prima= rily about >>>>>>>>>>>>>>> delegation then, of course, we should avoid any incentives = to impersonate >>>>>>>>>>>>>>> or we're wasting our time. This is partly why I'm trying to= study up on >>>>>>>>>>>>>>> capabilities and asking for expert advice from folks like A= lan Karp and >>>>>>>>>>>>>>> Mark Miller (cc'd) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> As best I can understand it, the RS has only two choices, i= t >>>>>>>>>>>>>>> can: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - store an attribute of the RO a [DID, email address, >>>>>>>>>>>>>>> GNAP AS URL], or >>>>>>>>>>>>>>> - hand the RO a capability as a sort-of promise and >>>>>>>>>>>>>>> avoid making any entries in an ACL or equivalent. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> When a token comes back to the RS, it will either be: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - validated according to something associated with the >>>>>>>>>>>>>>> stored RO attribute, or >>>>>>>>>>>>>>> - signed by the RS itself. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Either way, trust in the client seems moot. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer < >>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper < >>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker < >>>>>>>>>>>>>>>> tobias.looker@mattr.global> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > A client might not have a DID but it could have a VC as >>>>>>>>>>>>>>>>> a certificate of authenticity linked to some audit mechan= ism. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> To me a VC would come under the assertions umbrella (that >>>>>>>>>>>>>>>>> is to say a VC could be one type of valid assertion). The= client may >>>>>>>>>>>>>>>>> possess or been presented with a VC that it could include= in its request to >>>>>>>>>>>>>>>>> the AS as a way to identify the subject and perhaps prove= authentication >>>>>>>>>>>>>>>>> and authorization. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I do not assume that the client that interacts with the AS >>>>>>>>>>>>>>>> to make a request and receive a token is the same as the c= lient that will >>>>>>>>>>>>>>>> present the token to the RS. In the US HIPAA use-case, for= example, the >>>>>>>>>>>>>>>> root of trust is a contract between the patient-subject an= d the >>>>>>>>>>>>>>>> doctor-requesting party but the doctor workflow is expecte= d to delegate the >>>>>>>>>>>>>>>> token to some other end-user that may be using a totally d= ifferent client >>>>>>>>>>>>>>>> such as an EHR. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If the client that gets the token is not same as the clien= t >>>>>>>>>>>>>>>> that uses the token, that is a violation of core security = principles as it >>>>>>>>>>>>>>>> allows for (and really designs for) impersonation by clien= t software. I >>>>>>>>>>>>>>>> would have no reason to trust client software that would h= and its >>>>>>>>>>>>>>>> credentials over to another piece of software, and in fact= I shouldn=E2=80=99t >>>>>>>>>>>>>>>> trust it. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I think you may be conflating several different kinds of >>>>>>>>>>>>>>>> parties under the =E2=80=9Cclient=E2=80=9D umbrella here, = though. It=E2=80=99s entirely possible >>>>>>>>>>>>>>>> that one client might call an RS that in turn acts as a cl= ient for >>>>>>>>>>>>>>>> something else down stream. But each of those hops is diff= erent from the >>>>>>>>>>>>>>>> last. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> 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 >>>>>> >>>>> -- >>>>> 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 >>>> >>> >>> >>> -- >>> You know nothing Jon Snow! >>> >>> >>> -- >> You know nothing Jon Snow! >> >> >> > --000000000000351fc205bde70583 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I agree. The problem is that powerful RS operators introd= uce things like Capchas that hassle the RO. Sometimes this is justified but= often it reflects an inadequate protocol.=C2=A0
    Adrian

    On Fri, Mar 19, 2021 at 1:22 PM Justin = Richer <jricher@mit.edu> wrote= :
    There=E2=80=99s an important difference her= e:

    The AS is software. Always. It plays a specific role = within the protocol.

    The RO could be a person. It = could be an agency. It could be a policy. They don=E2=80=99t take part in t= he protocol directly but are involved in decisions made in the course of th= e protocol.

    These are two very, very different thi= ngs, and they can=E2=80=99t be conflated.

    I like t= he idea of talking in terms of relationships, such as AS-RS (a protocol rel= ationship) and AS-RO (a trust relationship).=C2=A0

    =C2= =A0=E2=80=94 Justin

    On Mar 19, 2= 021, at 12:37 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    <= div dir=3D"auto">It might be a good idea to keep the RS to AS relationship = out of the GNAP spec but I=E2=80=99m having a hard time analyzing it in the= abstract.=C2=A0

    My star= ting perspective is that the RS should not know or care whether it is deali= ng with the AS or the RO. This is super important because it gives the RO u= nlimited delegation power.=C2=A0

    Cases where the RO wants to give the RS a separate endpoint or ot= her identity should be allowed by GNAP but might be out of band. This is th= e HIPAA API Task Force use case that I have referenced in another thread. T= he issue here is that the RS has the option of reaching out to the RO and r= equesting confirmation.

    = Adrian =C2=A0

    On Fri, Mar 19, 2021 at 11:37 AM Justin Richer <jricher@mit.edu> wrot= e:
    My proposal is that the client instance sh= ouldn=E2=80=99t care what=E2=80=99s in the token, what format it is, etc.
    The RS can care and there should be choices that include = random, sealed, and even plainly signed tokens. That choice is part of the = relationship between the RS and AS, which the core GNAP protocol doesn=E2= =80=99t specify.=C2=A0

    This is why I propose that = we extract what=E2=80=99s now section 10 in the draft and put it into a new= document that can more directly discuss that relationship. These different= relationships should be modular.=C2=A0

    =C2=A0=E2=80= =94 Justin

    On Mar 19, 2021, at 1= 1:13 AM, Alejandro Iacobelli <aiacobelli.sec@gmail.com> wrote:

    <= div dir=3D"auto" style=3D"font-family:Helvetica;font-size:12px;font-style:n= ormal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;tex= t-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s= pacing:0px;text-decoration:none">Agree! So what are you saying the proposal= should be? Random or sealed tokens?

    El El vie, 19 mar.= 2021 a la(s) 10:04, Justin Richer <jricher@mit.edu> escribi=C3=B3:
    One= of the best ways to protect information in the token is to not put it in t= he token in the first place. This is why a some highly-sensitive applicatio= n profiles and deployments us randomized values as tokens. The RS has a way= to dereference it, which is important.

    For downstream d= elegation, like one micro service calling another, we=E2=80=99re no longer = talking about the client knowing the access token, we=E2=80=99re talking ab= out an RS at the first step. This is where non-opaque, or encrypted, or oth= er kinds of recoverable data structures come into play more directly.=C2=A0=

    To Adrian=E2=80=99s point, sharing the QR code sh= ould be up to the AS=E2=80=99s policy. If Steve gives me a bearer artifact = that isn=E2=80=99t attached to anything that identifies me, then it=E2=80= =99s easy for me to share because the artifact is the identity and proof al= l in one. The strawman description below sounds like that. But it=E2=80=99s= important in this design that the AS can also require me to log in with a = specific account, plus present a token, plus type in a secret code, plus pr= esent a hardware key that completes a circuit in the right way (seems like = something Steve would build, tbh), etc. But all of these aren=E2=80=99t a c= lient talking to a resource, they=E2=80=99re the end-user =C2=A0presenting = things to the AS so that the AS can make a policy decision to issue a token= and allow access.=C2=A0

    =C2=A0=E2=80=94 Justin

    On Mar 18, 2021, at 8:23 PM, Alejandro= Iacobelli <aiacobelli.sec@gmail.com> wrote:

    The decision about "opaque" vs "sealed but r= ecoverable" or "signed" access_token goes way back on the st= ateless protocols session management.=C2=A0

    In my opinion, the software design principle that we must apply here= is the "need to know" principle. This means, the=C2=A0less infor= mation an attacker could get, the better. One thing that JWS explse is all = the context information about a token, so an attacker=C2=A0can get lots of = information just with a look.=C2=A0

    The next discu= ssion will be what ways of generating opaque tokens are there and which mus= t we choose (Encrypted vs CSPRNG based).

    On Thu, 18 Mar 2021 at 21:17,= Fabien Imbault <fabien.imbault@gmail.com> wrote:
    =
    Hi Adrian,

    I= 'm really not sure I understand here.=C2=A0

    I get the idea of putting a policy engine in front of= your services to implement ZTA. But I'm not sure I get this way of fra= ming things. It blurs functional roles and actual services, and most import= antly if everything gets its own AS, it also gets by transitivity its RO= 9;/RQ' (and then its AS-RO' etc) and so the complexity becomes stag= gering.=C2=A0
    Why do we need that?=C2=A0

    Fabien=C2=A0

    <= div class=3D"gmail_quote">
    Le ven. 19 = mars 2021 =C3=A0 00:55, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2= =A0:
    +1 This al= igns with my healthcare use-case to the extent that Justin can transfer the= capability granted by that QR code to Adrian who happens to be nearby Stev= e's house.

    I've tried to capture some of thi= s in my comment to #145=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#= issuecomment-802388458

    - Adrian

    On = Thu, Mar 18, 2021 at 2:39 PM Justin Richer <jricher@mit.edu> wrote:<= br>
    Right, and in the GNAP model this becomes so= mething my client instance presents to the AS when I show up. The AS can va= lidate my presentation of this item and give my client instance a token to = call Steve=E2=80=99s RS. Or if you wanted to get super fancy Steve=E2=80=99= s AS could even challenge my client instance and get a cryptographic respon= se to prove I have the thing Steve had me scan. But in both cases it=E2=80= =99s part of things that the AS collects in order to create the access toke= n.

    =C2=A0=E2=80=94 Justin

    On Mar 18, 2021, at 2:26 PM, Stephen Moore <srmoore@gma= il.com> wrote:

    That in my mind works = out great... Say I'm logged into my home hub/AS. Justin is over and agr= ees to cat sit, I pull up my client app, and generate a QR code that has ma= ybe The AS URI, the HomeHub API URL, and the 'special token to present = to AS for a real token'. Justin scans that QR code with his home contro= ller app, and BAM, he's onboarded as a guest without even logging into = my AS or me dealing with his Auth provider.
    -steve

    On Thu, Mar 18,= 2021 at 2:08 PM Justin Richer <jricher@mit.edu> wrote:
    <= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rg= b(204,204,204)">
    I think Steve=E2=80=99s use case gives an interesting = example of something that I believe Adrian=E2=80=99s been talking about as = well =E2=80=94 delegating to another person.

    We traditio= nally think of delegation at the AS to mean =E2=80=9Ca different user accou= nt logs in to the AS=E2=80=9D, and it=E2=80=99s important to know that this= does in fact work. But this could just as easily be =E2=80=9CSteve sends h= is friend an artifact to present to the AS to get access=E2=80=9D. This isn= =E2=80=99t Steve (or Steve=E2=80=99s client software) getting and sending a= n access token, this is sending some other set of rights credential to his = friend, or his friend=E2=80=99s software. So then Steve=E2=80=99s AS can ha= ve policy that says =E2=80=9Cwhen I see this rights credential, give an acc= ess token for the following attenuated things, because Steve said so=E2=80= =9D. The AS doesn=E2=80=99t even ever need to know who Steve=E2=80=99s frie= nd is!=C2=A0

    And importantly here, we don=E2=80=99= t expect Steve=E2=80=99s friend to bring their own AS to the party. Steve= =E2=80=99s RS has no reason to trust his friend=E2=80=99s AS, let alone his= friend=E2=80=99s client. But Steve=E2=80=99s AS is in a position to know m= ore about the rights policies that Steve wants to apply, and so it can use = other technologies like VC=E2=80=99s, DIDs, OIDC, or any number of other th= ings to let things go through. This pattern is exactly why I think we need = to think of this in terms of what=E2=80=99s currently called =E2=80=9Cinter= action=E2=80=9D at the AS. It=E2=80=99s not really just about how the end-u= ser interacts, it=E2=80=99s about how the AS gathers all the consent and au= thorization information. I plan to rewrite section 4 to that effect.
    <= div>
    =C2=A0=E2=80=94 Justin

    On Mar 18, 2021, at 1:58 PM, Stephen Moore <srmoore@gmail.com> wrote:

    I'm having some concerns w= ith the way you're flipping the trust here Denis. You seem to indicate = that the user has trust in the RS and the Client and has to gain the trust = of the AS. I feel like the least trustworthy portion of the architecture is= the client, because that seems like it is the most interchangeable compone= nt.
    =C2=A0Let me explain by way of a use case I have in mind.
    Let's say I have a smart home. I have devices and data storage and rul= e engines that are parts of sensors and hubs I buy for the house. I have a = trust in those devices, because it's hardware, if the company is leakin= g data at the hardware level there isn't much I can do other than buy d= ifferent sensors.
    In this case, the primary home hub, which is un= der control of the homeowner, would also be the AS, as well as a policy age= nt.=C2=A0 Authentication in the example is outsourced to whatever auth prov= iders you want. I set up my home using a google account, a friend is stayin= g and wants access and uses FB for auth... whatever.
    The part tha= t I have little control over is the client my friend uses on his phone. Or = if I change the client on the tablet in the kitchen to try out something ne= w. These pieces=C2=A0might be single page web apps, they might be downloade= d apps, etc. I do not want them having any additional information than is n= ecessary. If I give my friend permission to unlock the door, and control th= e lights because they are feeding my cats while I'm away, the client do= esn't need to know anything beyond, I see this home controller, and I h= ave access to these lights and that door lock.

    In = your scenarios, the client is spy by design, and if it is a web app, I don&= #39;t trust them to not grab my user email address from the=C2=A0AS and put= it on a mailing list it sells to some sketchy company,=C2=A0when the only = other component=C2=A0that needs that information is the RS.

    <= /div>
    -steve

    On Thu, Mar 18, 2021 at 1:21 PM Denis <denis.ietf@= free.fr> wrote:
    I have chan= ged the title of this thread, since the original topic has been closed.=C2=A0

    Justin, you are raising the fo= llowing question:
    The question I have is =E2=80=94 wh= y does the client need to know what=E2=80=99s in the token?=C2=A0
    Not if they could possibly know, but why would we expect a client to= know and manage the contents of the token?=C2=A0
    The answer is quite simple: so that the end-user may have co= nfidence into the architecture.=C2=A0
    The sevent= h of the eleven privacy principles from ISO 29100 (page 14) is:
    7. Openness, transparency and notice=C2=A0
    If the access token is considered as a black box = for the end-user, it cannot be confident about the content of the access to= ken.
    Such access token may disclose some private information without the= consent of the end-user. If the access token that it has obtained=C2= =A0
    does not match with what has been requested, the client will = first not forward the access token to the RS and then will complain about t= he AS.

    Denis


    Hi Justin,=C2=A0

    &qu= ot;The access token is fundamentally a conversational artifact between the = AS and the RS which the client is the carrier of."
    That'= s right,=C2=A0and a good=C2=A0opportunity to distinguish between the need f= or token=C2=A0inspection (i.e. a runtime verification, wherever that may be= )=C2=A0
    and the need to negotiate the token format (a disco= very). That last part could very well be an extension, as a way to open up = the ecosystem=C2=A0
    beyond JWTs (which are fine, but come w= ith their own limitations).=C2=A0

    Fabien

    On T= hu, Mar 18, 2021 at 5:59 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 11:30 AM, Alan Karp <<= a href=3D"mailto:alanhkarp@gmail.com" rel=3D"noreferrer" target=3D"_blank">= alanhkarp@gmail.com> wrote:

    = Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 12:08 AM, Alan Karp <alanhkarp@gmail.com> = wrote:

    Adrian Gropper <agr= opper@healthurl.com> wrote:

    Is there an AS involved in the delegation? How and w= here in the lifecycle=C2=A0of the protected resource?=C2=A0

    If tokens are certificates, the AS need not be= involved in subsequent delegations.=C2=A0 The AS must be involved if the t= okens are opaque.=C2=A0

    =
    Tokens are opaque to the client instance. They are not opaque to the A= S. They might be opaque to the RS, but that depends on the kind of relation= ship the RS and AS have. GNAP should allow different options here as there = are different use cases for that.

    Tokens are not opaque to the client in SPKI, zcap= -ld, Orie's implementation with VCs, or our Zebra Copy work.=C2=A0 Why = must they be in GNAP?

    The existence of the AS is exactly the reason for this. The AS is = the role that =E2=80=9Cknowledge about the token contents=E2=80=9D has been= outsourced to in the GNAP model (which is based on the OAuth model).
    =

    It brings significant simplicity for the client develop= er. The question I have is =E2=80=94 why does the client need to know what= =E2=80=99s in the token? Not if they could possibly know, but why would we = expect a client to know and manage the contents of the token?=C2=A0

    The access token is fundamentally a conversational artifa= ct between the AS and the RS which the client is the carrier of. The client= is not the audience of the token, nor the creator of the token, nor even t= he manager of the token and the rights it represents. The client as a simpl= e carrier is a powerful model that allows the security layer to get out of = the way of the actual application logic that developers want to do.

    =C2=A0=E2=80=94 Justin


    ---------= -----
    Alan Karp


    On Thu, Mar 18, 2021 at 4:56 AM Justin Ri= cher <jricher@mit.edu> wrote:
    On Mar = 18, 2021, at 12:08 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    =
    Adrian Gropper <agropper@healt= hurl.com> wrote:
    Is there an AS involved in the delegation? How and where in the= lifecycle=C2=A0of the protected resource?=C2=A0

    If tokens are certificates, the AS need not be involved i= n subsequent delegations.=C2=A0 The AS must be involved if the tokens are o= paque.=C2=A0

    Tokens= are opaque to the client instance. They are not opaque to the AS. They mig= ht be opaque to the RS, but that depends on the kind of relationship the RS= and AS have. GNAP should allow different options here as there are differe= nt use cases for that.

    It would probably be worthw= hile to separate the portions of the spec that talk about the RS-AS relatio= nship into its own standalone document. A similar approach was taken in UMA= 2 and it was helpful. (Though admittedly, as with anything, there are misst= eps there that we can hopefully learn from.)

    =C2= =A0=E2=80=94 Justin


    --------------
    A= lan Karp


    On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper <= agropper@healthurl.com> wrote:
    Sure!=C2=A0

    Is there an AS involved in the del= egation? How and where in the lifecycle=C2=A0of the protected resource?=C2= =A0

    Also your use of "the client" seems to imp= ly that either there is only one client or the client doesn't matter. W= hich is it?

    Adrian

    On Wed, Mar 17, 2021= at 11:43 PM Fabien Imbault <fabien.imbault@gmail.com> wrot= e:
    Thanks for that.=C2=A0<= /div>

    Trying to reframe it:
    GNAP is defined as a delegation protocol so the main i= ntent is related to a delegate of the RO (i.e. the end user) that wishes to= access the RO's protected resources, through the client.=C2=A0

    Fabien=C2=A0

    Le jeu. 18 mars 2021 =C3=A0 04:2= 9, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0= :
    At various points in the lifec= ycle=C2=A0of the protected resource the client at the resource server (RS) = might be:
    • The RO (subject) user agent trading payment for a ser= vice promise
    • The RO user agent using the promise to access the prot= ected resource
    • A delegate of the RO user agent using a different cl= ient
    What's vague is where the GNAP AS enters the picture= as described above. How would you describe it?

    <= div>Adrian


    On Wed, Mar 17, 2021 at 10:20 PM Fabien Imba= ult <fabien.imbault@gmail.com> wrote:
    <= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rg= b(204,204,204)">
    Hi Adrian

    I'm still confused why you're saying the terminology = is vague.=C2=A0
    I get the "power" neutrali= ty is not to your liking, but RQ / user agent is no better in my view.=C2= =A0

    Can you elaborate?= =C2=A0

    Fabien=C2=A0

    Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper <agrop= per@healthurl.com> a =C3=A9crit=C2=A0:
    I'm sure you're right. Our vague terminology=C2=A0aro= und client=C2=A0and=C2=A0end-user leads to my confusion. If GNAP is primari= ly about delegation=C2=A0then, of course, we should=C2=A0avoid any incentiv= es to impersonate or we're wasting our time. This is partly why I'm= trying to study up on capabilities and asking for expert advice from folks= like Alan Karp and Mark Miller (cc'd)

    As best I can= understand it, the RS has only two choices, it can:
    • stor= e an attribute of the RO a [DID, email address, GNAP AS URL], or
    • ha= nd the RO a capability as a sort-of promise and avoid making any entries in= an ACL or equivalent.
    When a token comes back to the RS, it = will either be:
    • validated according to something associat= ed with the stored RO attribute, or
    • signed by the RS itself.
    Either way, trust in the client seems moot.

    Adrian



    On Wed, Mar 17,= 2021 at 5:29 PM Justin Richer <jricher@mit.edu= > wrote:
    On Mar 17, 2021, at 4:55 PM, Adr= ian Gropper <agropper@healthurl.com> wr= ote:

    On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <tobias.looker@mattr.global> wrote:
    <snip>
    <= div>> A client might not have a DID but it could have a VC as a certific= ate of authenticity linked to some audit mechanism.

    To me a VC would come under the assertions umbrella (that is to say a VC = could be one type of valid assertion). The client may possess or been prese= nted with a VC that it could include in its request to the AS as a way to i= dentify the subject and perhaps prove authentication and authorization.

    I do not assume that the client th= at interacts with the AS to make a request and receive a token is the same = as the client that will present the token to the RS. In the US HIPAA use-ca= se, for example, the root of trust is a contract between the patient-subjec= t and the doctor-requesting party but the doctor workflow is expected to de= legate the token to some other end-user that may be using a totally differe= nt client such as an EHR.


    If the client that gets the token is not same as the clien= t that uses the token, that is a violation of core security principles as i= t allows for (and really designs for) impersonation by client software. I w= ould have no reason to trust client software that would hand its credential= s over to another piece of software, and in fact I shouldn=E2=80=99t trust = it.=C2=A0

    I think you may be conflating several di= fferent kinds of parties under the =E2=80=9Cclient=E2=80=9D umbrella here, = though. It=E2=80=99s entirely possible that one client might call an RS tha= t in turn acts as a client for something else down stream. But each of thos= e hops is different from the last.

    =C2=A0=E2=80=94= Justin

    <= /div>
    <= /div>




    --=C2=A0
    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


    --=C2= =A0
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    --=C2=A0
    TXAuth mailing list
    TXAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/txauth=
    --=C2=A0
    TXAuth mailing list
    = TXAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/txauth


    --=C2=A0
    <= div dir=3D"ltr">
    You know nothing Jon Snow!

    --=C2=A0=
    You know nothing Jon Snow!
    <= /blockquote>

    --000000000000351fc205bde70583-- From nobody Fri Mar 19 10:32:34 2021 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 E9B9E3A1AF4 for ; Fri, 19 Mar 2021 10:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 LB21wbwLyLkf for ; Fri, 19 Mar 2021 10:32:27 -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 E50B53A1AF1 for ; Fri, 19 Mar 2021 10:32:26 -0700 (PDT) Received: from [192.168.1.22] (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 12JHWMfv008984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Mar 2021 13:32:23 -0400 From: Justin Richer Message-Id: <48B35DA4-9B92-493B-B2CC-C03544A1707D@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_E30FC26F-685B-4000-8D12-A530D90A34DE" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 19 Mar 2021 13:32:21 -0400 In-Reply-To: Cc: Alejandro Iacobelli , Fabien Imbault , Steve Moore , txauth gnap To: Adrian Gropper References: <43447446-4061-49F2-8486-5A196C3C75E2@mit.edu> <37a04505-84ef-aecf-6913-5aad8330c97c@free.fr> <3FE214B6-CF96-472D-853B-C7C5AC7A73AE@mit.edu> <8DF709AE-B17D-4B53-92FC-723F2C8C2503@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Should access tokens be opaque or not for the clients ? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 17:32:33 -0000 --Apple-Mail=_E30FC26F-685B-4000-8D12-A530D90A34DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The only way for the RS operator could introduce a captcha, within the = definitions of the GNAP protocol, is through an AS. Or more properly, = through this yes-unnamed aspect of =E2=80=9Cinteracting with the RO=E2=80=9D= that the AS is in charge of coordinating the results of. The RS is not = an end-user-facing service, it is an API, software meant to be called by = other software. The defined way for the =E2=80=9CRS=E2=80=9D to interact = with a person, issue tokens, or anything of the sort is through an AS.=20= In OAuth 1, the AS and RS were just called the =E2=80=9Cauthorization = server=E2=80=9D or even just =E2=80=9Cserver", and it seems like a lot = of the discussion on this thread is collapsing that same set of roles = back but instead calling it the =E2=80=9CRS=E2=80=9D. I think this is = problematic both in terms of the flexibility of the protocol and also in = terms of clarity in what we=E2=80=99re describing and discussing.=20 =E2=80=94 Justin > On Mar 19, 2021, at 1:26 PM, Adrian Gropper = wrote: >=20 > I agree. The problem is that powerful RS operators introduce things = like Capchas that hassle the RO. Sometimes this is justified but often = it reflects an inadequate protocol.=20 >=20 > Adrian >=20 > On Fri, Mar 19, 2021 at 1:22 PM Justin Richer > wrote: > There=E2=80=99s an important difference here: >=20 > The AS is software. Always. It plays a specific role within the = protocol. >=20 > The RO could be a person. It could be an agency. It could be a policy. = They don=E2=80=99t take part in the protocol directly but are involved = in decisions made in the course of the protocol. >=20 > These are two very, very different things, and they can=E2=80=99t be = conflated. >=20 > I like the idea of talking in terms of relationships, such as AS-RS (a = protocol relationship) and AS-RO (a trust relationship).=20 >=20 > =E2=80=94 Justin >=20 >> On Mar 19, 2021, at 12:37 PM, Adrian Gropper > wrote: >>=20 >> It might be a good idea to keep the RS to AS relationship out of the = GNAP spec but I=E2=80=99m having a hard time analyzing it in the = abstract.=20 >>=20 >> My starting perspective is that the RS should not know or care = whether it is dealing with the AS or the RO. This is super important = because it gives the RO unlimited delegation power.=20 >>=20 >> Cases where the RO wants to give the RS a separate endpoint or other = identity should be allowed by GNAP but might be out of band. This is the = HIPAA API Task Force use case that I have referenced in another thread. = The issue here is that the RS has the option of reaching out to the RO = and requesting confirmation. >>=20 >> Adrian =20 >>=20 >> On Fri, Mar 19, 2021 at 11:37 AM Justin Richer > wrote: >> My proposal is that the client instance shouldn=E2=80=99t care = what=E2=80=99s in the token, what format it is, etc. >>=20 >> The RS can care and there should be choices that include random, = sealed, and even plainly signed tokens. That choice is part of the = relationship between the RS and AS, which the core GNAP protocol = doesn=E2=80=99t specify.=20 >>=20 >> This is why I propose that we extract what=E2=80=99s now section 10 = in the draft and put it into a new document that can more directly = discuss that relationship. These different relationships should be = modular.=20 >>=20 >> =E2=80=94 Justin >>=20 >>> On Mar 19, 2021, at 11:13 AM, Alejandro Iacobelli = > wrote: >>>=20 >>> Agree! So what are you saying the proposal should be? Random or = sealed tokens? >>>=20 >>> El El vie, 19 mar. 2021 a la(s) 10:04, Justin Richer = > escribi=C3=B3: >>> One of the best ways to protect information in the token is to not = put it in the token in the first place. This is why a some = highly-sensitive application profiles and deployments us randomized = values as tokens. The RS has a way to dereference it, which is = important. >>>=20 >>> For downstream delegation, like one micro service calling another, = we=E2=80=99re no longer talking about the client knowing the access = token, we=E2=80=99re talking about an RS at the first step. This is = where non-opaque, or encrypted, or other kinds of recoverable data = structures come into play more directly.=20 >>>=20 >>> To Adrian=E2=80=99s point, sharing the QR code should be up to the = AS=E2=80=99s policy. If Steve gives me a bearer artifact that isn=E2=80=99= t attached to anything that identifies me, then it=E2=80=99s easy for me = to share because the artifact is the identity and proof all in one. The = strawman description below sounds like that. But it=E2=80=99s important = in this design that the AS can also require me to log in with a specific = account, plus present a token, plus type in a secret code, plus present = a hardware key that completes a circuit in the right way (seems like = something Steve would build, tbh), etc. But all of these aren=E2=80=99t = a client talking to a resource, they=E2=80=99re the end-user presenting = things to the AS so that the AS can make a policy decision to issue a = token and allow access.=20 >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Mar 18, 2021, at 8:23 PM, Alejandro Iacobelli = > wrote: >>>>=20 >>>> The decision about "opaque" vs "sealed but recoverable" or "signed" = access_token goes way back on the stateless protocols session = management.=20 >>>>=20 >>>> In my opinion, the software design principle that we must apply = here is the "need to know" principle. This means, the less information = an attacker could get, the better. One thing that JWS explse is all the = context information about a token, so an attacker can get lots of = information just with a look.=20 >>>>=20 >>>> The next discussion will be what ways of generating opaque tokens = are there and which must we choose (Encrypted vs CSPRNG based). >>>>=20 >>>> On Thu, 18 Mar 2021 at 21:17, Fabien Imbault = > wrote: >>>> Hi Adrian, >>>>=20 >>>> I'm really not sure I understand here.=20 >>>>=20 >>>> I get the idea of putting a policy engine in front of your services = to implement ZTA. But I'm not sure I get this way of framing things. It = blurs functional roles and actual services, and most importantly if = everything gets its own AS, it also gets by transitivity its RO'/RQ' = (and then its AS-RO' etc) and so the complexity becomes staggering.=20 >>>> Why do we need that?=20 >>>>=20 >>>> Fabien=20 >>>>=20 >>>> Le ven. 19 mars 2021 =C3=A0 00:55, Adrian Gropper = > a =C3=A9crit : >>>> +1 This aligns with my healthcare use-case to the extent that = Justin can transfer the capability granted by that QR code to Adrian who = happens to be nearby Steve's house. >>>>=20 >>>> I've tried to capture some of this in my comment to #145 = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment= -802388458 = >>>>=20 >>>> - Adrian >>>>=20 >>>> On Thu, Mar 18, 2021 at 2:39 PM Justin Richer > wrote: >>>> Right, and in the GNAP model this becomes something my client = instance presents to the AS when I show up. The AS can validate my = presentation of this item and give my client instance a token to call = Steve=E2=80=99s RS. Or if you wanted to get super fancy Steve=E2=80=99s = AS could even challenge my client instance and get a cryptographic = response to prove I have the thing Steve had me scan. But in both cases = it=E2=80=99s part of things that the AS collects in order to create the = access token. >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>> On Mar 18, 2021, at 2:26 PM, Stephen Moore > wrote: >>>>>=20 >>>>> That in my mind works out great... Say I'm logged into my home = hub/AS. Justin is over and agrees to cat sit, I pull up my client app, = and generate a QR code that has maybe The AS URI, the HomeHub API URL, = and the 'special token to present to AS for a real token'. Justin scans = that QR code with his home controller app, and BAM, he's onboarded as a = guest without even logging into my AS or me dealing with his Auth = provider. >>>>> -steve >>>>>=20 >>>>> On Thu, Mar 18, 2021 at 2:08 PM Justin Richer > wrote: >>>>> I think Steve=E2=80=99s use case gives an interesting example of = something that I believe Adrian=E2=80=99s been talking about as well =E2=80= =94 delegating to another person. >>>>>=20 >>>>> We traditionally think of delegation at the AS to mean =E2=80=9Ca = different user account logs in to the AS=E2=80=9D, and it=E2=80=99s = important to know that this does in fact work. But this could just as = easily be =E2=80=9CSteve sends his friend an artifact to present to the = AS to get access=E2=80=9D. This isn=E2=80=99t Steve (or Steve=E2=80=99s = client software) getting and sending an access token, this is sending = some other set of rights credential to his friend, or his friend=E2=80=99s= software. So then Steve=E2=80=99s AS can have policy that says =E2=80=9Cw= hen I see this rights credential, give an access token for the following = attenuated things, because Steve said so=E2=80=9D. The AS doesn=E2=80=99t = even ever need to know who Steve=E2=80=99s friend is!=20 >>>>>=20 >>>>> And importantly here, we don=E2=80=99t expect Steve=E2=80=99s = friend to bring their own AS to the party. Steve=E2=80=99s RS has no = reason to trust his friend=E2=80=99s AS, let alone his friend=E2=80=99s = client. But Steve=E2=80=99s AS is in a position to know more about the = rights policies that Steve wants to apply, and so it can use other = technologies like VC=E2=80=99s, DIDs, OIDC, or any number of other = things to let things go through. This pattern is exactly why I think we = need to think of this in terms of what=E2=80=99s currently called = =E2=80=9Cinteraction=E2=80=9D at the AS. It=E2=80=99s not really just = about how the end-user interacts, it=E2=80=99s about how the AS gathers = all the consent and authorization information. I plan to rewrite section = 4 to that effect. >>>>>=20 >>>>> =E2=80=94 Justin >>>>>=20 >>>>>> On Mar 18, 2021, at 1:58 PM, Stephen Moore > wrote: >>>>>>=20 >>>>>> I'm having some concerns with the way you're flipping the trust = here Denis. You seem to indicate that the user has trust in the RS and = the Client and has to gain the trust of the AS. I feel like the least = trustworthy portion of the architecture is the client, because that = seems like it is the most interchangeable component. >>>>>> Let me explain by way of a use case I have in mind. >>>>>> Let's say I have a smart home. I have devices and data storage = and rule engines that are parts of sensors and hubs I buy for the house. = I have a trust in those devices, because it's hardware, if the company = is leaking data at the hardware level there isn't much I can do other = than buy different sensors. >>>>>> In this case, the primary home hub, which is under control of the = homeowner, would also be the AS, as well as a policy agent. = Authentication in the example is outsourced to whatever auth providers = you want. I set up my home using a google account, a friend is staying = and wants access and uses FB for auth... whatever. >>>>>> The part that I have little control over is the client my friend = uses on his phone. Or if I change the client on the tablet in the = kitchen to try out something new. These pieces might be single page web = apps, they might be downloaded apps, etc. I do not want them having any = additional information than is necessary. If I give my friend permission = to unlock the door, and control the lights because they are feeding my = cats while I'm away, the client doesn't need to know anything beyond, I = see this home controller, and I have access to these lights and that = door lock. >>>>>>=20 >>>>>> In your scenarios, the client is spy by design, and if it is a = web app, I don't trust them to not grab my user email address from the = AS and put it on a mailing list it sells to some sketchy company, when = the only other component that needs that information is the RS. >>>>>>=20 >>>>>> -steve >>>>>>=20 >>>>>> On Thu, Mar 18, 2021 at 1:21 PM Denis > wrote: >>>>>> I have changed the title of this thread, since the original topic = has been closed.=20 >>>>>>=20 >>>>>> Justin, you are raising the following question: >>>>>> The question I have is =E2=80=94 why does the client need to know = what=E2=80=99s in the token?=20 >>>>>> Not if they could possibly know, but why would we expect a client = to know and manage the contents of the token?=20 >>>>>> The answer is quite simple: so that the end-user may have = confidence into the architecture.=20 >>>>>> The seventh of the eleven privacy principles from ISO 29100 (page = 14) is: >>>>>> 7. Openness, transparency and notice=20 >>>>>> If the access token is considered as a black box for the = end-user, it cannot be confident about the content of the access token. >>>>>> Such access token may disclose some private information without = the consent of the end-user. If the access token that it has obtained=20 >>>>>> does not match with what has been requested, the client will = first not forward the access token to the RS and then will complain = about the AS. >>>>>>=20 >>>>>> Denis >>>>>>=20 >>>>>>=20 >>>>>>> Hi Justin,=20 >>>>>>>=20 >>>>>>> "The access token is fundamentally a conversational artifact = between the AS and the RS which the client is the carrier of." >>>>>>> That's right, and a good opportunity to distinguish between the = need for token inspection (i.e. a runtime verification, wherever that = may be)=20 >>>>>>> and the need to negotiate the token format (a discovery). That = last part could very well be an extension, as a way to open up the = ecosystem=20 >>>>>>> beyond JWTs (which are fine, but come with their own = limitations).=20 >>>>>>>=20 >>>>>>> Fabien >>>>>>>=20 >>>>>>> On Thu, Mar 18, 2021 at 5:59 PM Justin Richer > wrote: >>>>>>> On Mar 18, 2021, at 11:30 AM, Alan Karp > wrote: >>>>>>>>=20 >>>>>>>> Justin Richer > wrote: >>>>>>>> On Mar 18, 2021, at 12:08 AM, Alan Karp > wrote: >>>>>>>>>=20 >>>>>>>>> Adrian Gropper > wrote: >>>>>>>>>=20 >>>>>>>>> Is there an AS involved in the delegation? How and where in = the lifecycle of the protected resource?=20 >>>>>>>>>=20 >>>>>>>>> If tokens are certificates, the AS need not be involved in = subsequent delegations. The AS must be involved if the tokens are = opaque.=20 >>>>>>>>=20 >>>>>>>> Tokens are opaque to the client instance. They are not opaque = to the AS. They might be opaque to the RS, but that depends on the kind = of relationship the RS and AS have. GNAP should allow different options = here as there are different use cases for that. >>>>>>>>=20 >>>>>>>> Tokens are not opaque to the client in SPKI, zcap-ld, Orie's = implementation with VCs, or our Zebra Copy work. Why must they be in = GNAP? >>>>>>>=20 >>>>>>> The existence of the AS is exactly the reason for this. The AS = is the role that =E2=80=9Cknowledge about the token contents=E2=80=9D = has been outsourced to in the GNAP model (which is based on the OAuth = model). >>>>>>>=20 >>>>>>> It brings significant simplicity for the client developer. The = question I have is =E2=80=94 why does the client need to know what=E2=80=99= s in the token? Not if they could possibly know, but why would we expect = a client to know and manage the contents of the token?=20 >>>>>>>=20 >>>>>>> The access token is fundamentally a conversational artifact = between the AS and the RS which the client is the carrier of. The client = is not the audience of the token, nor the creator of the token, nor even = the manager of the token and the rights it represents. The client as a = simple carrier is a powerful model that allows the security layer to get = out of the way of the actual application logic that developers want to = do. >>>>>>>=20 >>>>>>> =E2=80=94 Justin >>>>>>>=20 >>>>>>>>=20 >>>>>>>> -------------- >>>>>>>> Alan Karp >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Thu, Mar 18, 2021 at 4:56 AM Justin Richer > wrote: >>>>>>>> On Mar 18, 2021, at 12:08 AM, Alan Karp > wrote: >>>>>>>>>=20 >>>>>>>>> Adrian Gropper > wrote: >>>>>>>>>=20 >>>>>>>>> Is there an AS involved in the delegation? How and where in = the lifecycle of the protected resource?=20 >>>>>>>>>=20 >>>>>>>>> If tokens are certificates, the AS need not be involved in = subsequent delegations. The AS must be involved if the tokens are = opaque.=20 >>>>>>>>=20 >>>>>>>> Tokens are opaque to the client instance. They are not opaque = to the AS. They might be opaque to the RS, but that depends on the kind = of relationship the RS and AS have. GNAP should allow different options = here as there are different use cases for that. >>>>>>>>=20 >>>>>>>> It would probably be worthwhile to separate the portions of the = spec that talk about the RS-AS relationship into its own standalone = document. A similar approach was taken in UMA2 and it was helpful. = (Though admittedly, as with anything, there are missteps there that we = can hopefully learn from.) >>>>>>>>=20 >>>>>>>> =E2=80=94 Justin >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -------------- >>>>>>>>> Alan Karp >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper = > wrote: >>>>>>>>> Sure!=20 >>>>>>>>>=20 >>>>>>>>> Is there an AS involved in the delegation? How and where in = the lifecycle of the protected resource?=20 >>>>>>>>>=20 >>>>>>>>> Also your use of "the client" seems to imply that either there = is only one client or the client doesn't matter. Which is it? >>>>>>>>>=20 >>>>>>>>> Adrian >>>>>>>>>=20 >>>>>>>>> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault = > wrote: >>>>>>>>> Thanks for that.=20 >>>>>>>>>=20 >>>>>>>>> Trying to reframe it: >>>>>>>>> GNAP is defined as a delegation protocol so the main intent is = related to a delegate of the RO (i.e. the end user) that wishes to = access the RO's protected resources, through the client.=20 >>>>>>>>>=20 >>>>>>>>> Fabien=20 >>>>>>>>>=20 >>>>>>>>> Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper = > a =C3=A9crit : >>>>>>>>> At various points in the lifecycle of the protected resource = the client at the resource server (RS) might be: >>>>>>>>> The RO (subject) user agent trading payment for a service = promise >>>>>>>>> The RO user agent using the promise to access the protected = resource >>>>>>>>> A delegate of the RO user agent using a different client >>>>>>>>> What's vague is where the GNAP AS enters the picture as = described above. How would you describe it? >>>>>>>>>=20 >>>>>>>>> Adrian >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault = > wrote: >>>>>>>>> Hi Adrian >>>>>>>>>=20 >>>>>>>>> I'm still confused why you're saying the terminology is vague.=20= >>>>>>>>> I get the "power" neutrality is not to your liking, but RQ / = user agent is no better in my view.=20 >>>>>>>>>=20 >>>>>>>>> Can you elaborate?=20 >>>>>>>>>=20 >>>>>>>>> Fabien=20 >>>>>>>>>=20 >>>>>>>>> Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper = > a =C3=A9crit : >>>>>>>>> I'm sure you're right. Our vague terminology around client and = end-user leads to my confusion. If GNAP is primarily about delegation = then, of course, we should avoid any incentives to impersonate or we're = wasting our time. This is partly why I'm trying to study up on = capabilities and asking for expert advice from folks like Alan Karp and = Mark Miller (cc'd) >>>>>>>>>=20 >>>>>>>>> As best I can understand it, the RS has only two choices, it = can: >>>>>>>>> store an attribute of the RO a [DID, email address, GNAP AS = URL], or >>>>>>>>> hand the RO a capability as a sort-of promise and avoid making = any entries in an ACL or equivalent. >>>>>>>>> When a token comes back to the RS, it will either be: >>>>>>>>> validated according to something associated with the stored RO = attribute, or >>>>>>>>> signed by the RS itself. >>>>>>>>> Either way, trust in the client seems moot. >>>>>>>>>=20 >>>>>>>>> Adrian >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer > wrote: >>>>>>>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper = > wrote: >>>>>>>>>>=20 >>>>>>>>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker = > wrote: >>>>>>>>>> >>>>>>>>>> > A client might not have a DID but it could have a VC as a = certificate of authenticity linked to some audit mechanism. >>>>>>>>>>=20 >>>>>>>>>> To me a VC would come under the assertions umbrella (that is = to say a VC could be one type of valid assertion). The client may = possess or been presented with a VC that it could include in its request = to the AS as a way to identify the subject and perhaps prove = authentication and authorization. >>>>>>>>>>=20 >>>>>>>>>> I do not assume that the client that interacts with the AS to = make a request and receive a token is the same as the client that will = present the token to the RS. In the US HIPAA use-case, for example, the = root of trust is a contract between the patient-subject and the = doctor-requesting party but the doctor workflow is expected to delegate = the token to some other end-user that may be using a totally different = client such as an EHR. >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> If the client that gets the token is not same as the client = that uses the token, that is a violation of core security principles as = it allows for (and really designs for) impersonation by client software. = I would have no reason to trust client software that would hand its = credentials over to another piece of software, and in fact I shouldn=E2=80= =99t trust it.=20 >>>>>>>>>=20 >>>>>>>>> I think you may be conflating several different kinds of = parties under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80= =99s entirely possible that one client might call an RS that in turn = acts as a client for something else down stream. But each of those hops = is different from the last. >>>>>>>>>=20 >>>>>>>>> =E2=80=94 Justin >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> --=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 = >>>>>=20 >>>>=20 >>>> --=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 = >>>> --=20 >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = >>>>=20 >>>>=20 >>>> --=20 >>>> You know nothing Jon Snow! >>>=20 >>> --=20 >>> You know nothing Jon Snow! >>=20 >=20 --Apple-Mail=_E30FC26F-685B-4000-8D12-A530D90A34DE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = only way for the RS operator could introduce a captcha, within the = definitions of the GNAP protocol, is through an AS. Or more properly, = through this yes-unnamed aspect of =E2=80=9Cinteracting with the RO=E2=80=9D= that the AS is in charge of coordinating the results of. The RS is not = an end-user-facing service, it is an API, software meant to be called by = other software. The defined way for the =E2=80=9CRS=E2=80=9D to interact = with a person, issue tokens, or anything of the sort is through an = AS. 

    In OAuth = 1, the AS and RS were just called the =E2=80=9Cauthorization server=E2=80=9D= or even just =E2=80=9Cserver", and it seems like a lot of the = discussion on this thread is collapsing that same set of roles back but = instead calling it the =E2=80=9CRS=E2=80=9D. I think this is problematic = both in terms of the flexibility of the protocol and also in terms of = clarity in what we=E2=80=99re describing and discussing. 

     =E2=80=94 = Justin

    On Mar 19, 2021, at 1:26 PM, Adrian Gropper = <agropper@healthurl.com> wrote:

    I agree. The problem is that = powerful RS operators introduce things like Capchas that hassle the RO. = Sometimes this is justified but often it reflects an inadequate = protocol. 

    Adrian

    On Fri, Mar 19, 2021 at 1:22 PM Justin Richer = <jricher@mit.edu> = wrote:
    There=E2=80=99s an important difference here:

    The AS is software. = Always. It plays a specific role within the protocol.

    The RO could be a = person. It could be an agency. It could be a policy. They don=E2=80=99t = take part in the protocol directly but are involved in decisions made in = the course of the protocol.

    These are two very, very different things, and they can=E2=80=99= t be conflated.

    I like the idea of talking in terms of relationships, such as = AS-RS (a protocol relationship) and AS-RO (a trust = relationship). 

     =E2=80= =94 Justin

    On Mar 19, 2021, at 12:37 PM, = Adrian Gropper <agropper@healthurl.com> = wrote:

    It= might be a good idea to keep the RS to AS relationship out of the GNAP = spec but I=E2=80=99m having a hard time analyzing it in the = abstract. 

    My starting perspective is = that the RS should not know or care whether it is dealing with the AS or = the RO. This is super important because it gives the RO unlimited = delegation power. 

    Cases where the RO wants = to give the RS a separate endpoint or other identity should be allowed = by GNAP but might be out of band. This is the HIPAA API Task Force use = case that I have referenced in another thread. The issue here is that = the RS has the option of reaching out to the RO and requesting = confirmation.

    Adrian  

    On Fri, Mar 19, 2021 at 11:37 AM Justin Richer = <jricher@mit.edu> wrote:
    My = proposal is that the client instance shouldn=E2=80=99t care what=E2=80=99s= in the token, what format it is, etc.

    The RS can care and there should be = choices that include random, sealed, and even plainly signed tokens. = That choice is part of the relationship between the RS and AS, which the = core GNAP protocol doesn=E2=80=99t specify. 
    This is why I propose that we extract = what=E2=80=99s now section 10 in the draft and put it into a new = document that can more directly discuss that relationship. These = different relationships should be modular. 

     =E2=80= =94 Justin

    On Mar 19, 2021, at 11:13 AM, = Alejandro Iacobelli <aiacobelli.sec@gmail.com> = wrote:

    Agree! So what are you saying the proposal = should be? Random or sealed tokens?

    El El vie, = 19 mar. 2021 a la(s) 10:04, Justin Richer <jricher@mit.edu> escribi=C3=B3:
    One= of the best ways to protect information in the token is to not put it = in the token in the first place. This is why a some highly-sensitive = application profiles and deployments us randomized values as tokens. The = RS has a way to dereference it, which is important.

    For downstream delegation, like one = micro service calling another, we=E2=80=99re no longer talking about the = client knowing the access token, we=E2=80=99re talking about an RS at = the first step. This is where non-opaque, or encrypted, or other kinds = of recoverable data structures come into play more = directly. 

    To Adrian=E2=80=99s point, sharing the QR code should be up = to the AS=E2=80=99s policy. If Steve gives me a bearer artifact that = isn=E2=80=99t attached to anything that identifies me, then it=E2=80=99s = easy for me to share because the artifact is the identity and proof all = in one. The strawman description below sounds like that. But it=E2=80=99s = important in this design that the AS can also require me to log in with = a specific account, plus present a token, plus type in a secret code, = plus present a hardware key that completes a circuit in the right way = (seems like something Steve would build, tbh), etc. But all of these = aren=E2=80=99t a client talking to a resource, they=E2=80=99re the = end-user  presenting things to the AS so that the AS can make a = policy decision to issue a token and allow access. 

     =E2=80= =94 Justin

    On Mar 18, 2021, at 8:23 PM, = Alejandro Iacobelli <aiacobelli.sec@gmail.com> = wrote:

    The decision about "opaque" vs = "sealed but recoverable" or "signed" access_token goes way back on the = stateless protocols session management. 

    In my opinion, the = software design principle that we must apply here is the "need to know" = principle. This means, the less information an attacker could get, = the better. One thing that JWS explse is all the context information = about a token, so an attacker can get lots of information just with = a look. 

    The next discussion will be what ways of generating opaque = tokens are there and which must we choose (Encrypted vs CSPRNG = based).

    On Thu, 18 Mar 2021 at 21:17, Fabien = Imbault <fabien.imbault@gmail.com> wrote:
    Hi = Adrian,

    I'm really not sure I understand here. 

    I get the idea of putting a policy engine in = front of your services to implement ZTA. But I'm not sure I get this way = of framing things. It blurs functional roles and actual services, and = most importantly if everything gets its own AS, it also gets by = transitivity its RO'/RQ' (and then its AS-RO' etc) and so the complexity = becomes staggering. 
    Why do we = need that? 

    Fabien 

    Le ven. 19 = mars 2021 =C3=A0 00:55, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit :
    +1 This aligns with my healthcare use-case to the = extent that Justin can transfer the capability granted by that QR code = to Adrian who happens to be nearby Steve's house.

    I've tried to capture = some of this in my comment to #145 https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#i= ssuecomment-802388458

    - Adrian

    On Thu, Mar = 18, 2021 at 2:39 PM Justin Richer <jricher@mit.edu> = wrote:
    Right, and in the GNAP = model this becomes something my client instance presents to the AS when = I show up. The AS can validate my presentation of this item and give my = client instance a token to call Steve=E2=80=99s RS. Or if you wanted to = get super fancy Steve=E2=80=99s AS could even challenge my client = instance and get a cryptographic response to prove I have the thing = Steve had me scan. But in both cases it=E2=80=99s part of things that = the AS collects in order to create the access token.

     =E2=80=94 = Justin

    On Mar 18, 2021, at 2:26 PM, = Stephen Moore <srmoore@gmail.com> wrote:

    That in my mind = works out great... Say I'm logged into my home hub/AS. Justin is over = and agrees to cat sit, I pull up my client app, and generate a QR code = that has maybe The AS URI, the HomeHub API URL, and the 'special token = to present to AS for a real token'. Justin scans that QR code with his = home controller app, and BAM, he's onboarded as a guest without even = logging into my AS or me dealing with his Auth provider.
    -steve

    On Thu, Mar = 18, 2021 at 2:08 PM Justin Richer <jricher@mit.edu> = wrote:
    I think Steve=E2=80=99s = use case gives an interesting example of something that I believe = Adrian=E2=80=99s been talking about as well =E2=80=94 delegating to = another person.

    We = traditionally think of delegation at the AS to mean =E2=80=9Ca different = user account logs in to the AS=E2=80=9D, and it=E2=80=99s important to = know that this does in fact work. But this could just as easily be = =E2=80=9CSteve sends his friend an artifact to present to the AS to get = access=E2=80=9D. This isn=E2=80=99t Steve (or Steve=E2=80=99s client = software) getting and sending an access token, this is sending some = other set of rights credential to his friend, or his friend=E2=80=99s = software. So then Steve=E2=80=99s AS can have policy that says =E2=80=9Cwh= en I see this rights credential, give an access token for the following = attenuated things, because Steve said so=E2=80=9D. The AS doesn=E2=80=99t = even ever need to know who Steve=E2=80=99s friend is! 

    And importantly here, we = don=E2=80=99t expect Steve=E2=80=99s friend to bring their own AS to the = party. Steve=E2=80=99s RS has no reason to trust his friend=E2=80=99s = AS, let alone his friend=E2=80=99s client. But Steve=E2=80=99s AS is in = a position to know more about the rights policies that Steve wants to = apply, and so it can use other technologies like VC=E2=80=99s, DIDs, = OIDC, or any number of other things to let things go through. This = pattern is exactly why I think we need to think of this in terms of = what=E2=80=99s currently called =E2=80=9Cinteraction=E2=80=9D at the AS. = It=E2=80=99s not really just about how the end-user interacts, it=E2=80=99= s about how the AS gathers all the consent and authorization = information. I plan to rewrite section 4 to that effect.

     =E2=80=94 = Justin

    On Mar 18, 2021, at 1:58 PM, = Stephen Moore <srmoore@gmail.com> wrote:

    I'm having some = concerns with the way you're flipping the trust here Denis. You seem to = indicate that the user has trust in the RS and the Client and has to = gain the trust of the AS. I feel like the least trustworthy portion of = the architecture is the client, because that seems like it is the most = interchangeable component.
     Let me explain by way of = a use case I have in mind.
    Let's say I have a smart = home. I have devices and data storage and rule engines that are parts of = sensors and hubs I buy for the house. I have a trust in those devices, = because it's hardware, if the company is leaking data at the hardware = level there isn't much I can do other than buy different = sensors.
    In this case, the primary home hub, which = is under control of the homeowner, would also be the AS, as well as a = policy agent.  Authentication in the example is outsourced to = whatever auth providers you want. I set up my home using a google = account, a friend is staying and wants access and uses FB for auth... = whatever.
    The part that I have little control over = is the client my friend uses on his phone. Or if I change the client on = the tablet in the kitchen to try out something new. These = pieces might be single page web apps, they might be downloaded = apps, etc. I do not want them having any additional information than is = necessary. If I give my friend permission to unlock the door, and = control the lights because they are feeding my cats while I'm away, the = client doesn't need to know anything beyond, I see this home controller, = and I have access to these lights and that door lock.

    In your scenarios, the = client is spy by design, and if it is a web app, I don't trust them to = not grab my user email address from the AS and put it on a mailing = list it sells to some sketchy company, when the only other = component that needs that information is the RS.

    -steve

    On Thu, Mar 18, 2021 at 1:21 PM Denis <denis.ietf@free.fr> wrote:
    I have changed the title of this thread, since the original = topic has been closed. 

    Justin, you are raising the following = question:
    The question I = have is =E2=80=94 why does the client need to know what=E2=80=99s in the = token? 
    Not if they could = possibly know, but why would we expect a client to know and manage the = contents of the token? 
    The answer is quite = simple: so that the end-user may have confidence into the = architecture. 
    The seventh of the eleven privacy principles from ISO 29100 = (page 14) is:
    7.= Openness, transparency and notice 
    If the access token is = considered as a black box for the end-user, it cannot be confident about = the content of the access token.
    Such access token may = disclose some private information without the consent of the end-user. = If the access token that it has obtained 
    does not match with what has been requested, the client will = first not forward the access token to the RS and then will complain = about the AS.

    Denis


    Hi Justin, 

    "The access token is fundamentally a conversational artifact = between the AS and the RS which the client is the carrier of."
    That's right, and a good opportunity to distinguish = between the need for token inspection (i.e. a runtime verification, = wherever that may be) 
    and = the need to negotiate the token format (a discovery). That last part = could very well be an extension, as a way to open up the ecosystem 
    beyond JWTs (which are fine, but = come with their own limitations). 

    Fabien

    On Thu, Mar = 18, 2021 at 5:59 PM Justin Richer <jricher@mit.edu> = wrote:
    On Mar 18, 2021, at 11:30 = AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 12:08 = AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Adrian Gropper <agropper@healthurl.com> wrote:

    Is there an AS involved = in the delegation? How and where in the lifecycle of the protected = resource? 

    If tokens are certificates, the AS need = not be involved in subsequent delegations.  The AS must be involved = if the tokens are opaque. 

    Tokens are opaque to the = client instance. They are not opaque to the AS. They might be opaque to = the RS, but that depends on the kind of relationship the RS and AS have. = GNAP should allow different options here as there are different use = cases for that.

    Tokens are = not opaque to the client in SPKI, zcap-ld, Orie's implementation with = VCs, or our Zebra Copy work.  Why must they be in = GNAP?

    The existence of the AS is exactly the = reason for this. The AS is the role that =E2=80=9Cknowledge about the = token contents=E2=80=9D has been outsourced to in the GNAP model (which = is based on the OAuth model).

    It brings significant simplicity for = the client developer. The question I have is =E2=80=94 why does the = client need to know what=E2=80=99s in the token? Not if they could = possibly know, but why would we expect a client to know and manage the = contents of the token? 

    The access token is fundamentally a = conversational artifact between the AS and the RS which the client is = the carrier of. The client is not the audience of the token, nor the = creator of the token, nor even the manager of the token and the rights = it represents. The client as a simple carrier is a powerful model that = allows the security layer to get out of the way of the actual = application logic that developers want to do.

     =E2=80=94 Justin


    --------------
    Alan = Karp


    On Thu, Mar = 18, 2021 at 4:56 AM Justin Richer <jricher@mit.edu> = wrote:
    On Mar 18, 2021, at 12:08 = AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Adrian Gropper <agropper@healthurl.com> wrote:

    Is there an AS involved = in the delegation? How and where in the lifecycle of the protected = resource? 

    If tokens are certificates, the AS need = not be involved in subsequent delegations.  The AS must be involved = if the tokens are opaque. 

    Tokens are opaque to the = client instance. They are not opaque to the AS. They might be opaque to = the RS, but that depends on the kind of relationship the RS and AS have. = GNAP should allow different options here as there are different use = cases for that.

    It would probably be worthwhile to separate the portions of = the spec that talk about the RS-AS relationship into its own standalone = document. A similar approach was taken in UMA2 and it was helpful. = (Though admittedly, as with anything, there are missteps there that we = can hopefully learn from.)

     =E2=80=94 Justin


    --------------
    Alan = Karp


    On Wed, Mar = 17, 2021 at 8:54 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Sure! 
    Is there an AS involved = in the delegation? How and where in the lifecycle of the protected = resource? 

    Also = your use of "the client" seems to imply that either there is only one = client or the client doesn't matter. Which is it?

    Adrian

    On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Thanks for that. 

    Trying to reframe = it:
    GNAP is defined as a delegation = protocol so the main intent is related to a delegate of the RO (i.e. the = end user) that wishes to access the RO's protected resources, through = the client. 

    Fabien 

    Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper = <agropper@healthurl.com> a = =C3=A9crit :
    At various = points in the lifecycle of the protected resource the client at the = resource server (RS) might be:
    • The RO (subject) user agent trading payment for a service = promise
    • The RO user agent using the promise to access = the protected resource
    • A delegate of the RO user = agent using a different client
    What's vague is = where the GNAP AS enters the picture as described above. How would you = describe it?

    Adrian


    On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault = <fabien.imbault@gmail.com> = wrote:
    Hi = Adrian

    I'm still confused why you're saying the terminology is = vague. 
    I get the "power" = neutrality is not to your liking, but RQ / user agent is no better in my = view. 

    Can you elaborate? 

    Fabien 

    Le jeu. 18 = mars 2021 =C3=A0 00:18, Adrian Gropper <agropper@healthurl.com> a = =C3=A9crit :
    I'm sure = you're right. Our vague terminology around = client and end-user leads to my confusion. If GNAP is = primarily about delegation then, of course, we should avoid = any incentives to impersonate or we're wasting our time. This is partly = why I'm trying to study up on capabilities and asking for expert advice = from folks like Alan Karp and Mark Miller (cc'd)

    As best I can understand it, the RS has = only two choices, it can:
    • store an attribute of the RO a [DID, email address, GNAP AS = URL], or
    • hand the RO a capability as a sort-of = promise and avoid making any entries in an ACL or = equivalent.
    When a token comes back to the RS, = it will either be:
    • validated according to something associated with the stored = RO attribute, or
    • signed by the RS = itself.
    Either way, trust in the client seems = moot.

    Adrian



    On Wed, Mar = 17, 2021 at 5:29 PM Justin Richer <jricher@mit.edu> wrote:
    On Mar 17, 2021, at 4:55 = PM, Adrian Gropper <agropper@healthurl.com> wrote:

    On = Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <tobias.looker@mattr.global> wrote:
    <snip>
    > A client might not = have a DID but it could have a VC as a certificate of authenticity = linked to some audit mechanism.

    To me a VC would come under the = assertions umbrella (that is to say a VC could be one type of valid = assertion). The client may possess or been presented with a VC that it = could include in its request to the AS as a way to identify the subject = and perhaps prove authentication and = authorization.

    I do not assume that the client that = interacts with the AS to make a request and receive a token is the same = as the client that will present the token to the RS. In the US HIPAA = use-case, for example, the root of trust is a contract between the = patient-subject and the doctor-requesting party but the doctor workflow = is expected to delegate the token to some other end-user that may be = using a totally different client such as an EHR.


    If the client that gets the token is not same as the client = that uses the token, that is a violation of core security principles as = it allows for (and really designs for) impersonation by client software. = I would have no reason to trust client software that would hand its = credentials over to another piece of software, and in fact I shouldn=E2=80= =99t trust it. 

    I think you may be conflating several different kinds of = parties under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80= =99s entirely possible that one client might call an RS that in turn = acts as a client for something else down stream. But each of those hops = is different from the last.

     =E2=80=94 Justin

    =




    -- 
    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
    -- 
    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


    -- 
    You = know nothing Jon Snow!

    -- 
    You know = nothing Jon Snow!



    = --Apple-Mail=_E30FC26F-685B-4000-8D12-A530D90A34DE-- From nobody Fri Mar 19 10:38:43 2021 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 7AC583A1B0C for ; Fri, 19 Mar 2021 10:38: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, 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 79e_z2MfY8yf for ; Fri, 19 Mar 2021 10:38:35 -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 93F1E3A1B0A for ; Fri, 19 Mar 2021 10:38:35 -0700 (PDT) Received: by mail-il1-x130.google.com with SMTP id j11so8754087ilu.13 for ; Fri, 19 Mar 2021 10:38:35 -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=2nUSkr+RU6KZ2LoxJn9Q8DWkNGY5BJyHqv7tOChpE08=; b=IInBF6zMk0Z+bjaBqteAv25Lf6u0QAqW7Yf0/hoJ2KB4o7EiL8lSxomOG5BVZQWfJg 2iXb6PxIH6aMV0dJx2oBWKn8hMEV+eSg+bjQj1Tax+TGzL0y1Uc+TJC75Vk0V2rf76hq bgISJbssnyy5hLgTZabvdwfDar9Q6w+B8tJQXXRsf7EKlg8xfnbENQxtUU8J9FZR2nyd 5hQtIIyJdbVs6oahRwCjZeYCoODPaSBlj5OxqEbA2U1M2ksxQFfflYqWWsjfPcd1mMQc 2Bwxxc9VR9gJd0pAxhKMQWk0dXrwujYIKa2mOcOTNJciLwaawKuQ5ozF/tNWl1UvxHYW FpPA== 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=2nUSkr+RU6KZ2LoxJn9Q8DWkNGY5BJyHqv7tOChpE08=; b=Ef00hJ4q7gnIXBpnG5LzRje6+7ICupu+c7N6c7piZPNe0ZmSbkgTm/UiDVBicqHJ4o JqmhJDfMJIp5z2JLbnGH/KJic8GyOZqX5cqwfdXYZoIh/4mQ80dd7znzx+m7StybMGnE FEYDm05pv9cuddczr1I8U+ECKle/jA2C4tUCkI9+SFNq3L+fHWtzpdBBTDR1A+lqqBlr GcyT/zjCIscTvUcbdlrKZjmeMOuh9iiCMcrNguxNu2wl9aOtT6SeNiuzIYS2qpwkC0ke b58K2KVk3oYa5Jgx4WI2WaTxctUULkumnj6hM/KctgRBp1RdmR/pfGuMLrmugracXiMx bSYw== X-Gm-Message-State: AOAM533c2PMmxGmdi+HF+TRR5jLNZYyB6FriacBiVPNacwc4mnfr1qzw JDGe1G1kZ5yqH+R8ejELOSjX4hh3w16IFtpRGCM= X-Google-Smtp-Source: ABdhPJxSk8yEqWM3ANehdh5ZP+ot26TcaPo86oukS9f7As92/VFV8quN7TYNizmi/dClFr2M2vu+IjkxIejyppngu9s= X-Received: by 2002:a92:1a11:: with SMTP id a17mr3771354ila.188.1616175513904; Fri, 19 Mar 2021 10:38:33 -0700 (PDT) MIME-Version: 1.0 References: <43447446-4061-49F2-8486-5A196C3C75E2@mit.edu> <37a04505-84ef-aecf-6913-5aad8330c97c@free.fr> <3FE214B6-CF96-472D-853B-C7C5AC7A73AE@mit.edu> <8DF709AE-B17D-4B53-92FC-723F2C8C2503@mit.edu> <48B35DA4-9B92-493B-B2CC-C03544A1707D@mit.edu> In-Reply-To: <48B35DA4-9B92-493B-B2CC-C03544A1707D@mit.edu> From: Fabien Imbault Date: Fri, 19 Mar 2021 18:38:22 +0100 Message-ID: To: Justin Richer Cc: Adrian Gropper , Alejandro Iacobelli , Steve Moore , txauth gnap Content-Type: multipart/alternative; boundary="00000000000066aacd05bde72f02" Archived-At: Subject: Re: [GNAP] Should access tokens be opaque or not for the clients ? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 17:38:42 -0000 --00000000000066aacd05bde72f02 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Oh I thought capchas were mostly a way to train your AI for free ;-) Joke aside, I support Justin's view of what goes into core versus what the kind of modularity we might bring in addition to that. Fabien On Fri, Mar 19, 2021 at 6:32 PM Justin Richer wrote: > The only way for the RS operator could introduce a captcha, within the > definitions of the GNAP protocol, is through an AS. Or more properly, > through this yes-unnamed aspect of =E2=80=9Cinteracting with the RO=E2=80= =9D that the AS is > in charge of coordinating the results of. The RS is not an end-user-facin= g > service, it is an API, software meant to be called by other software. The > defined way for the =E2=80=9CRS=E2=80=9D to interact with a person, issue= tokens, or > anything of the sort is through an AS. > > In OAuth 1, the AS and RS were just called the =E2=80=9Cauthorization ser= ver=E2=80=9D or > even just =E2=80=9Cserver", and it seems like a lot of the discussion on = this > thread is collapsing that same set of roles back but instead calling it t= he > =E2=80=9CRS=E2=80=9D. I think this is problematic both in terms of the fl= exibility of the > protocol and also in terms of clarity in what we=E2=80=99re describing an= d > discussing. > > =E2=80=94 Justin > > On Mar 19, 2021, at 1:26 PM, Adrian Gropper > wrote: > > I agree. The problem is that powerful RS operators introduce things like > Capchas that hassle the RO. Sometimes this is justified but often it > reflects an inadequate protocol. > > Adrian > > On Fri, Mar 19, 2021 at 1:22 PM Justin Richer wrote: > >> There=E2=80=99s an important difference here: >> >> The AS is software. Always. It plays a specific role within the protocol= . >> >> The RO could be a person. It could be an agency. It could be a policy. >> They don=E2=80=99t take part in the protocol directly but are involved i= n decisions >> made in the course of the protocol. >> >> These are two very, very different things, and they can=E2=80=99t be con= flated. >> >> I like the idea of talking in terms of relationships, such as AS-RS (a >> protocol relationship) and AS-RO (a trust relationship). >> >> =E2=80=94 Justin >> >> On Mar 19, 2021, at 12:37 PM, Adrian Gropper >> wrote: >> >> It might be a good idea to keep the RS to AS relationship out of the GNA= P >> spec but I=E2=80=99m having a hard time analyzing it in the abstract. >> >> My starting perspective is that the RS should not know or care whether i= t >> is dealing with the AS or the RO. This is super important because it giv= es >> the RO unlimited delegation power. >> >> Cases where the RO wants to give the RS a separate endpoint or other >> identity should be allowed by GNAP but might be out of band. This is the >> HIPAA API Task Force use case that I have referenced in another thread. = The >> issue here is that the RS has the option of reaching out to the RO and >> requesting confirmation. >> >> Adrian >> >> On Fri, Mar 19, 2021 at 11:37 AM Justin Richer wrote: >> >>> My proposal is that the client instance shouldn=E2=80=99t care what=E2= =80=99s in the >>> token, what format it is, etc. >>> >>> The RS can care and there should be choices that include random, sealed= , >>> and even plainly signed tokens. That choice is part of the relationship >>> between the RS and AS, which the core GNAP protocol doesn=E2=80=99t spe= cify. >>> >>> This is why I propose that we extract what=E2=80=99s now section 10 in = the draft >>> and put it into a new document that can more directly discuss that >>> relationship. These different relationships should be modular. >>> >>> =E2=80=94 Justin >>> >>> On Mar 19, 2021, at 11:13 AM, Alejandro Iacobelli < >>> aiacobelli.sec@gmail.com> wrote: >>> >>> Agree! So what are you saying the proposal should be? Random or sealed >>> tokens? >>> >>> El El vie, 19 mar. 2021 a la(s) 10:04, Justin Richer >>> escribi=C3=B3: >>> >>>> One of the best ways to protect information in the token is to not put >>>> it in the token in the first place. This is why a some highly-sensitiv= e >>>> application profiles and deployments us randomized values as tokens. T= he RS >>>> has a way to dereference it, which is important. >>>> >>>> For downstream delegation, like one micro service calling another, >>>> we=E2=80=99re no longer talking about the client knowing the access to= ken, we=E2=80=99re >>>> talking about an RS at the first step. This is where non-opaque, or >>>> encrypted, or other kinds of recoverable data structures come into pla= y >>>> more directly. >>>> >>>> To Adrian=E2=80=99s point, sharing the QR code should be up to the AS= =E2=80=99s policy. >>>> If Steve gives me a bearer artifact that isn=E2=80=99t attached to any= thing that >>>> identifies me, then it=E2=80=99s easy for me to share because the arti= fact is the >>>> identity and proof all in one. The strawman description below sounds l= ike >>>> that. But it=E2=80=99s important in this design that the AS can also r= equire me to >>>> log in with a specific account, plus present a token, plus type in a s= ecret >>>> code, plus present a hardware key that completes a circuit in the righ= t way >>>> (seems like something Steve would build, tbh), etc. But all of these a= ren=E2=80=99t >>>> a client talking to a resource, they=E2=80=99re the end-user presenti= ng things to >>>> the AS so that the AS can make a policy decision to issue a token and = allow >>>> access. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Mar 18, 2021, at 8:23 PM, Alejandro Iacobelli < >>>> aiacobelli.sec@gmail.com> wrote: >>>> >>>> The decision about "opaque" vs "sealed but recoverable" or "signed" >>>> access_token goes way back on the stateless protocols session manageme= nt. >>>> >>>> In my opinion, the software design principle that we must apply here i= s >>>> the "need to know" principle. This means, the less information an atta= cker >>>> could get, the better. One thing that JWS explse is all the context >>>> information about a token, so an attacker can get lots of information = just >>>> with a look. >>>> >>>> The next discussion will be what ways of generating opaque tokens are >>>> there and which must we choose (Encrypted vs CSPRNG based). >>>> >>>> On Thu, 18 Mar 2021 at 21:17, Fabien Imbault >>>> wrote: >>>> >>>>> Hi Adrian, >>>>> >>>>> I'm really not sure I understand here. >>>>> >>>>> I get the idea of putting a policy engine in front of your services t= o >>>>> implement ZTA. But I'm not sure I get this way of framing things. It = blurs >>>>> functional roles and actual services, and most importantly if everyth= ing >>>>> gets its own AS, it also gets by transitivity its RO'/RQ' (and then i= ts >>>>> AS-RO' etc) and so the complexity becomes staggering. >>>>> Why do we need that? >>>>> >>>>> Fabien >>>>> >>>>> Le ven. 19 mars 2021 =C3=A0 00:55, Adrian Gropper >>>>> a =C3=A9crit : >>>>> >>>>>> +1 This aligns with my healthcare use-case to the extent that Justin >>>>>> can transfer the capability granted by that QR code to Adrian who ha= ppens >>>>>> to be nearby Steve's house. >>>>>> >>>>>> I've tried to capture some of this in my comment to #145 >>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuec= omment-802388458 >>>>>> >>>>>> - Adrian >>>>>> >>>>>> On Thu, Mar 18, 2021 at 2:39 PM Justin Richer >>>>>> wrote: >>>>>> >>>>>>> Right, and in the GNAP model this becomes something my client >>>>>>> instance presents to the AS when I show up. The AS can validate my >>>>>>> presentation of this item and give my client instance a token to ca= ll >>>>>>> Steve=E2=80=99s RS. Or if you wanted to get super fancy Steve=E2=80= =99s AS could even >>>>>>> challenge my client instance and get a cryptographic response to pr= ove I >>>>>>> have the thing Steve had me scan. But in both cases it=E2=80=99s pa= rt of things >>>>>>> that the AS collects in order to create the access token. >>>>>>> >>>>>>> =E2=80=94 Justin >>>>>>> >>>>>>> On Mar 18, 2021, at 2:26 PM, Stephen Moore >>>>>>> wrote: >>>>>>> >>>>>>> That in my mind works out great... Say I'm logged into my home >>>>>>> hub/AS. Justin is over and agrees to cat sit, I pull up my client a= pp, and >>>>>>> generate a QR code that has maybe The AS URI, the HomeHub API URL, = and the >>>>>>> 'special token to present to AS for a real token'. Justin scans tha= t QR >>>>>>> code with his home controller app, and BAM, he's onboarded as a gue= st >>>>>>> without even logging into my AS or me dealing with his Auth provide= r. >>>>>>> -steve >>>>>>> >>>>>>> On Thu, Mar 18, 2021 at 2:08 PM Justin Richer >>>>>>> wrote: >>>>>>> >>>>>>>> I think Steve=E2=80=99s use case gives an interesting example of s= omething >>>>>>>> that I believe Adrian=E2=80=99s been talking about as well =E2=80= =94 delegating to another >>>>>>>> person. >>>>>>>> >>>>>>>> We traditionally think of delegation at the AS to mean =E2=80=9Ca = different >>>>>>>> user account logs in to the AS=E2=80=9D, and it=E2=80=99s importan= t to know that this does >>>>>>>> in fact work. But this could just as easily be =E2=80=9CSteve send= s his friend an >>>>>>>> artifact to present to the AS to get access=E2=80=9D. This isn=E2= =80=99t Steve (or Steve=E2=80=99s >>>>>>>> client software) getting and sending an access token, this is send= ing some >>>>>>>> other set of rights credential to his friend, or his friend=E2=80= =99s software. So >>>>>>>> then Steve=E2=80=99s AS can have policy that says =E2=80=9Cwhen I = see this rights >>>>>>>> credential, give an access token for the following attenuated thin= gs, >>>>>>>> because Steve said so=E2=80=9D. The AS doesn=E2=80=99t even ever n= eed to know who Steve=E2=80=99s >>>>>>>> friend is! >>>>>>>> >>>>>>>> And importantly here, we don=E2=80=99t expect Steve=E2=80=99s frie= nd to bring their >>>>>>>> own AS to the party. Steve=E2=80=99s RS has no reason to trust his= friend=E2=80=99s AS, let >>>>>>>> alone his friend=E2=80=99s client. But Steve=E2=80=99s AS is in a = position to know more >>>>>>>> about the rights policies that Steve wants to apply, and so it can= use >>>>>>>> other technologies like VC=E2=80=99s, DIDs, OIDC, or any number of= other things to >>>>>>>> let things go through. This pattern is exactly why I think we need= to think >>>>>>>> of this in terms of what=E2=80=99s currently called =E2=80=9Cinter= action=E2=80=9D at the AS. It=E2=80=99s >>>>>>>> not really just about how the end-user interacts, it=E2=80=99s abo= ut how the AS >>>>>>>> gathers all the consent and authorization information. I plan to r= ewrite >>>>>>>> section 4 to that effect. >>>>>>>> >>>>>>>> =E2=80=94 Justin >>>>>>>> >>>>>>>> On Mar 18, 2021, at 1:58 PM, Stephen Moore >>>>>>>> wrote: >>>>>>>> >>>>>>>> I'm having some concerns with the way you're flipping the trust >>>>>>>> here Denis. You seem to indicate that the user has trust in the RS= and the >>>>>>>> Client and has to gain the trust of the AS. I feel like the least >>>>>>>> trustworthy portion of the architecture is the client, because tha= t seems >>>>>>>> like it is the most interchangeable component. >>>>>>>> Let me explain by way of a use case I have in mind. >>>>>>>> Let's say I have a smart home. I have devices and data storage and >>>>>>>> rule engines that are parts of sensors and hubs I buy for the hous= e. I have >>>>>>>> a trust in those devices, because it's hardware, if the company is= leaking >>>>>>>> data at the hardware level there isn't much I can do other than bu= y >>>>>>>> different sensors. >>>>>>>> In this case, the primary home hub, which is under control of the >>>>>>>> homeowner, would also be the AS, as well as a policy agent. Authe= ntication >>>>>>>> in the example is outsourced to whatever auth providers you want. = I set up >>>>>>>> my home using a google account, a friend is staying and wants acce= ss and >>>>>>>> uses FB for auth... whatever. >>>>>>>> The part that I have little control over is the client my friend >>>>>>>> uses on his phone. Or if I change the client on the tablet in the = kitchen >>>>>>>> to try out something new. These pieces might be single page web ap= ps, they >>>>>>>> might be downloaded apps, etc. I do not want them having any addit= ional >>>>>>>> information than is necessary. If I give my friend permission to u= nlock the >>>>>>>> door, and control the lights because they are feeding my cats whil= e I'm >>>>>>>> away, the client doesn't need to know anything beyond, I see this = home >>>>>>>> controller, and I have access to these lights and that door lock. >>>>>>>> >>>>>>>> In your scenarios, the client is spy by design, and if it is a web >>>>>>>> app, I don't trust them to not grab my user email address from the= AS and >>>>>>>> put it on a mailing list it sells to some sketchy company, when th= e only >>>>>>>> other component that needs that information is the RS. >>>>>>>> >>>>>>>> -steve >>>>>>>> >>>>>>>> On Thu, Mar 18, 2021 at 1:21 PM Denis wrote: >>>>>>>> >>>>>>>>> I have changed the title of this thread, since the original topic >>>>>>>>> has been closed. >>>>>>>>> >>>>>>>>> Justin, you are raising the following question: >>>>>>>>> >>>>>>>>> The question I have is =E2=80=94 why does the client need to know= what=E2=80=99s >>>>>>>>> in the token? >>>>>>>>> Not if they could possibly know, but why would we expect a client >>>>>>>>> to know and manage the contents of the token? >>>>>>>>> >>>>>>>>> The answer is quite simple: so that the end-user may have >>>>>>>>> confidence into the architecture. >>>>>>>>> The seventh of the eleven privacy principles from ISO 29100 (page >>>>>>>>> 14) is: >>>>>>>>> >>>>>>>>> *7. Openness, transparency and notice * >>>>>>>>> >>>>>>>>> If the access token is considered as a black box for the end-user= , >>>>>>>>> it cannot be confident about the content of the access token. >>>>>>>>> Such access token may disclose some private information without >>>>>>>>> the consent of the end-user. If the access token that it has obta= ined >>>>>>>>> >>>>>>>>> does not match with what has been requested, the client will firs= t >>>>>>>>> not forward the access token to the RS and then will complain abo= ut the AS. >>>>>>>>> >>>>>>>>> Denis >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Justin, >>>>>>>>> >>>>>>>>> "The access token is fundamentally a conversational artifact >>>>>>>>> between the AS and the RS which the client is the carrier of." >>>>>>>>> That's right, and a good opportunity to distinguish between the >>>>>>>>> need for token inspection (i.e. a runtime verification, wherever = that may >>>>>>>>> be) >>>>>>>>> and the need to negotiate the token format (a discovery). That >>>>>>>>> last part could very well be an extension, as a way to open up th= e ecosystem >>>>>>>>> >>>>>>>>> beyond JWTs (which are fine, but come with their own limitations)= . >>>>>>>>> >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> On Thu, Mar 18, 2021 at 5:59 PM Justin Richer >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> On Mar 18, 2021, at 11:30 AM, Alan Karp >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Justin Richer wrote: >>>>>>>>>> >>>>>>>>>>> On Mar 18, 2021, at 12:08 AM, Alan Karp >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Adrian Gropper wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Is there an AS involved in the delegation? How and where in th= e >>>>>>>>>>>> lifecycle of the protected resource? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> If tokens are certificates, the AS need not be involved in >>>>>>>>>>> subsequent delegations. The AS must be involved if the tokens = are opaque. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Tokens are opaque to the client instance. They are not opaque t= o >>>>>>>>>>> the AS. They might be opaque to the RS, but that depends on the= kind of >>>>>>>>>>> relationship the RS and AS have. GNAP should allow different op= tions here >>>>>>>>>>> as there are different use cases for that. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Tokens are not opaque to the client in SPKI, zcap-ld, Orie's >>>>>>>>>> implementation with VCs, or our Zebra Copy work. Why must they = be in GNAP? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The existence of the AS is exactly the reason for this. The AS i= s >>>>>>>>>> the role that =E2=80=9Cknowledge about the token contents=E2=80= =9D has been outsourced to >>>>>>>>>> in the GNAP model (which is based on the OAuth model). >>>>>>>>>> >>>>>>>>>> It brings significant simplicity for the client developer. The >>>>>>>>>> question I have is =E2=80=94 why does the client need to know wh= at=E2=80=99s in the token? >>>>>>>>>> Not if they could possibly know, but why would we expect a clien= t to know >>>>>>>>>> and manage the contents of the token? >>>>>>>>>> >>>>>>>>>> The access token is fundamentally a conversational artifact >>>>>>>>>> between the AS and the RS which the client is the carrier of. Th= e client is >>>>>>>>>> not the audience of the token, nor the creator of the token, nor= even the >>>>>>>>>> manager of the token and the rights it represents. The client as= a simple >>>>>>>>>> carrier is a powerful model that allows the security layer to ge= t out of >>>>>>>>>> the way of the actual application logic that developers want to = do. >>>>>>>>>> >>>>>>>>>> =E2=80=94 Justin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -------------- >>>>>>>>>> Alan Karp >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Mar 18, 2021 at 4:56 AM Justin Richer >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> On Mar 18, 2021, at 12:08 AM, Alan Karp >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Adrian Gropper wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Is there an AS involved in the delegation? How and where in th= e >>>>>>>>>>>> lifecycle of the protected resource? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> If tokens are certificates, the AS need not be involved in >>>>>>>>>>> subsequent delegations. The AS must be involved if the tokens = are opaque. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Tokens are opaque to the client instance. They are not opaque t= o >>>>>>>>>>> the AS. They might be opaque to the RS, but that depends on the= kind of >>>>>>>>>>> relationship the RS and AS have. GNAP should allow different op= tions here >>>>>>>>>>> as there are different use cases for that. >>>>>>>>>>> >>>>>>>>>>> It would probably be worthwhile to separate the portions of the >>>>>>>>>>> spec that talk about the RS-AS relationship into its own standa= lone >>>>>>>>>>> document. A similar approach was taken in UMA2 and it was helpf= ul. (Though >>>>>>>>>>> admittedly, as with anything, there are missteps there that we = can >>>>>>>>>>> hopefully learn from.) >>>>>>>>>>> >>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -------------- >>>>>>>>>>> Alan Karp >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper < >>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Sure! >>>>>>>>>>>> >>>>>>>>>>>> Is there an AS involved in the delegation? How and where in th= e >>>>>>>>>>>> lifecycle of the protected resource? >>>>>>>>>>>> >>>>>>>>>>>> Also your use of "the client" seems to imply that either there >>>>>>>>>>>> is only one client or the client doesn't matter. Which is it? >>>>>>>>>>>> >>>>>>>>>>>> Adrian >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault < >>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Thanks for that. >>>>>>>>>>>>> >>>>>>>>>>>>> Trying to reframe it: >>>>>>>>>>>>> GNAP is defined as a delegation protocol so the main intent i= s >>>>>>>>>>>>> related to a delegate of the RO (i.e. the end user) that wish= es to access >>>>>>>>>>>>> the RO's protected resources, through the client. >>>>>>>>>>>>> >>>>>>>>>>>>> Fabien >>>>>>>>>>>>> >>>>>>>>>>>>> Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper < >>>>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>>>> >>>>>>>>>>>>>> At various points in the lifecycle of the protected resource >>>>>>>>>>>>>> the client at the resource server (RS) might be: >>>>>>>>>>>>>> >>>>>>>>>>>>>> - The RO (subject) user agent trading payment for a >>>>>>>>>>>>>> service promise >>>>>>>>>>>>>> - The RO user agent using the promise to access the >>>>>>>>>>>>>> protected resource >>>>>>>>>>>>>> - A delegate of the RO user agent using a different clien= t >>>>>>>>>>>>>> >>>>>>>>>>>>>> What's vague is where the GNAP AS enters the picture as >>>>>>>>>>>>>> described above. How would you describe it? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault < >>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Adrian >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm still confused why you're saying the terminology is >>>>>>>>>>>>>>> vague. >>>>>>>>>>>>>>> I get the "power" neutrality is not to your liking, but RQ = / >>>>>>>>>>>>>>> user agent is no better in my view. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Can you elaborate? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper < >>>>>>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm sure you're right. Our vague terminology around >>>>>>>>>>>>>>>> client and end-user leads to my confusion. If GNAP is prim= arily about >>>>>>>>>>>>>>>> delegation then, of course, we should avoid any incentives= to impersonate >>>>>>>>>>>>>>>> or we're wasting our time. This is partly why I'm trying t= o study up on >>>>>>>>>>>>>>>> capabilities and asking for expert advice from folks like = Alan Karp and >>>>>>>>>>>>>>>> Mark Miller (cc'd) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> As best I can understand it, the RS has only two choices, >>>>>>>>>>>>>>>> it can: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - store an attribute of the RO a [DID, email address, >>>>>>>>>>>>>>>> GNAP AS URL], or >>>>>>>>>>>>>>>> - hand the RO a capability as a sort-of promise and >>>>>>>>>>>>>>>> avoid making any entries in an ACL or equivalent. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> When a token comes back to the RS, it will either be: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - validated according to something associated with the >>>>>>>>>>>>>>>> stored RO attribute, or >>>>>>>>>>>>>>>> - signed by the RS itself. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Either way, trust in the client seems moot. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer < >>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper < >>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker < >>>>>>>>>>>>>>>>> tobias.looker@mattr.global> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > A client might not have a DID but it could have a VC a= s >>>>>>>>>>>>>>>>>> a certificate of authenticity linked to some audit mecha= nism. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> To me a VC would come under the assertions umbrella (tha= t >>>>>>>>>>>>>>>>>> is to say a VC could be one type of valid assertion). Th= e client may >>>>>>>>>>>>>>>>>> possess or been presented with a VC that it could includ= e in its request to >>>>>>>>>>>>>>>>>> the AS as a way to identify the subject and perhaps prov= e authentication >>>>>>>>>>>>>>>>>> and authorization. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I do not assume that the client that interacts with the A= S >>>>>>>>>>>>>>>>> to make a request and receive a token is the same as the = client that will >>>>>>>>>>>>>>>>> present the token to the RS. In the US HIPAA use-case, fo= r example, the >>>>>>>>>>>>>>>>> root of trust is a contract between the patient-subject a= nd the >>>>>>>>>>>>>>>>> doctor-requesting party but the doctor workflow is expect= ed to delegate the >>>>>>>>>>>>>>>>> token to some other end-user that may be using a totally = different client >>>>>>>>>>>>>>>>> such as an EHR. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> If the client that gets the token is not same as the >>>>>>>>>>>>>>>>> client that uses the token, that is a violation of core s= ecurity principles >>>>>>>>>>>>>>>>> as it allows for (and really designs for) impersonation b= y client software. >>>>>>>>>>>>>>>>> I would have no reason to trust client software that woul= d hand its >>>>>>>>>>>>>>>>> credentials over to another piece of software, and in fac= t I shouldn=E2=80=99t >>>>>>>>>>>>>>>>> trust it. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I think you may be conflating several different kinds of >>>>>>>>>>>>>>>>> parties under the =E2=80=9Cclient=E2=80=9D umbrella here,= though. It=E2=80=99s entirely possible >>>>>>>>>>>>>>>>> that one client might call an RS that in turn acts as a c= lient for >>>>>>>>>>>>>>>>> something else down stream. But each of those hops is dif= ferent from the >>>>>>>>>>>>>>>>> last. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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 >>>>>>> >>>>>> -- >>>>>> 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 >>>>> >>>> >>>> >>>> -- >>>> You know nothing Jon Snow! >>>> >>>> >>>> -- >>> You know nothing Jon Snow! >>> >>> >>> >> > --00000000000066aacd05bde72f02 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Oh I thought capchas were mostly a way to train your AI fo= r free ;-)=C2=A0

    Joke aside, I support Justin's view= of what goes into core versus what the kind of modularity we might bring i= n addition to that.

    Fabien

    On Fri, Mar 19, 20= 21 at 6:32 PM Justin Richer <jricher@= mit.edu> wrote:
    The only way for the RS op= erator could introduce a captcha, within the definitions of the GNAP protoc= ol, is through an AS. Or more properly, through this yes-unnamed aspect of = =E2=80=9Cinteracting with the RO=E2=80=9D that the AS is in charge of coord= inating the results of. The RS is not an end-user-facing service, it is an = API, software meant to be called by other software. The defined way for the= =E2=80=9CRS=E2=80=9D to interact with a person, issue tokens, or anything = of the sort is through an AS.=C2=A0

    In OAuth 1, the AS a= nd RS were just called the =E2=80=9Cauthorization server=E2=80=9D or even j= ust =E2=80=9Cserver", and it seems like a lot of the discussion on thi= s thread is collapsing that same set of roles back but instead calling it t= he =E2=80=9CRS=E2=80=9D. I think this is problematic both in terms of the f= lexibility of the protocol and also in terms of clarity in what we=E2=80=99= re describing and discussing.=C2=A0

    =C2=A0=E2=80= =94 Justin

    On Mar 19, 2021, at 1= :26 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I agree. The problem is that powerful RS operators introduce things = like Capchas that hassle the RO. Sometimes this is justified but often it r= eflects an inadequate protocol.=C2=A0

    Adrian

    On Fri, Mar 19, 2021 at 1:22 PM Justin Richer <= jricher@mit.edu>= ; wrote:
    There=E2=80=99s an important difference = here:

    The AS is software. Always. It plays a specific ro= le within the protocol.

    The RO could be a person. = It could be an agency. It could be a policy. They don=E2=80=99t take part i= n the protocol directly but are involved in decisions made in the course of= the protocol.

    These are two very, very different = things, and they can=E2=80=99t be conflated.

    I lik= e the idea of talking in terms of relationships, such as AS-RS (a protocol = relationship) and AS-RO (a trust relationship).=C2=A0

    =C2=A0=E2=80=94 Justin<= br>

    On Mar 19, 2021, at 12:37 PM, Ad= rian Gropper <agropper@healthurl.com> wrote:

    It = might be a good idea to keep the RS to AS relationship out of the GNAP spec= but I=E2=80=99m having a hard time analyzing it in the abstract.=C2=A0

    My starting perspective is = that the RS should not know or care whether it is dealing with the AS or th= e RO. This is super important because it gives the RO unlimited delegation = power.=C2=A0

    Cases where= the RO wants to give the RS a separate endpoint or other identity should b= e allowed by GNAP but might be out of band. This is the HIPAA API Task Forc= e use case that I have referenced in another thread. The issue here is that= the RS has the option of reaching out to the RO and requesting confirmatio= n.

    Adrian =C2=A0

    On = Fri, Mar 19, 2021 at 11:37 AM Justin Richer <jricher@mit.edu> wrote:
    My proposal is that the client instance shouldn=E2=80=99t care what= =E2=80=99s in the token, what format it is, etc.

    The RS = can care and there should be choices that include random, sealed, and even = plainly signed tokens. That choice is part of the relationship between the = RS and AS, which the core GNAP protocol doesn=E2=80=99t specify.=C2=A0

    This is why I propose that we extract what=E2=80=99s n= ow section 10 in the draft and put it into a new document that can more dir= ectly discuss that relationship. These different relationships should be mo= dular.=C2=A0

    =
    =C2=A0=E2=80=94 Justin

    On Mar 19, 2021, at 11:13 AM, Alejandro Iacobelli <aiacobelli.sec@gmail.com>= wrote:

    Agree! So what are = you saying the proposal should be? Random or sealed tokens?

    El El vie, 19 mar. 2021 a la(s) 10:04, Justin Richer <jricher@mit.edu> escribi=C3= =B3:
    One of the best ways to protect information= in the token is to not put it in the token in the first place. This is why= a some highly-sensitive application profiles and deployments us randomized= values as tokens. The RS has a way to dereference it, which is important.<= div>
    For downstream delegation, like one micro service callin= g another, we=E2=80=99re no longer talking about the client knowing the acc= ess token, we=E2=80=99re talking about an RS at the first step. This is whe= re non-opaque, or encrypted, or other kinds of recoverable data structures = come into play more directly.=C2=A0

    To Adrian=E2= =80=99s point, sharing the QR code should be up to the AS=E2=80=99s policy.= If Steve gives me a bearer artifact that isn=E2=80=99t attached to anythin= g that identifies me, then it=E2=80=99s easy for me to share because the ar= tifact is the identity and proof all in one. The strawman description below= sounds like that. But it=E2=80=99s important in this design that the AS ca= n also require me to log in with a specific account, plus present a token, = plus type in a secret code, plus present a hardware key that completes a ci= rcuit in the right way (seems like something Steve would build, tbh), etc. = But all of these aren=E2=80=99t a client talking to a resource, they=E2=80= =99re the end-user =C2=A0presenting things to the AS so that the AS can mak= e a policy decision to issue a token and allow access.=C2=A0

    =C2=A0=E2=80=94 = Justin

    On Mar 18, 2021, at 8:23 = PM, Alejandro Iacobelli <aiacobelli.sec@gmail.com> wrote:

    The decision about "opaque" vs "= ;sealed but recoverable" or "signed" access_token goes way b= ack on the stateless protocols session management.=C2=A0

    In my opinion, the software design principle that we mu= st apply here is the "need to know" principle. This means, the=C2= =A0less information an attacker could get, the better. One thing that JWS e= xplse is all the context information about a token, so an attacker=C2=A0can= get lots of information just with a look.=C2=A0

    T= he next discussion will be what ways of generating opaque tokens are there = and which must we choose (Encrypted vs CSPRNG based).

    On Thu, 18 Mar 2= 021 at 21:17, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Adrian,
    I'm really not sure I unders= tand here.=C2=A0

    I get the= idea of putting a policy engine in front of your services to implement ZTA= . But I'm not sure I get this way of framing things. It blurs functiona= l roles and actual services, and most importantly if everything gets its ow= n AS, it also gets by transitivity its RO'/RQ' (and then its AS-RO&= #39; etc) and so the complexity becomes staggering.=C2=A0
    Why do we need that?=C2=A0

    Fabien=C2=A0

    Le ven. 19 mars 2021 =C3=A0 00:55, Adrian= Gropper <ag= ropper@healthurl.com> a =C3=A9crit=C2=A0:
    +1 This = aligns with my healthcare use-case to the extent that Justin can transfer t= he capability granted by that QR code to Adrian who happens to be nearby St= eve's house.

    I've tried to capture some of t= his in my comment to #145=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/14= 5#issuecomment-802388458

    - Adrian
    <= /div>
    O= n Thu, Mar 18, 2021 at 2:39 PM Justin Richer <jricher@mit.edu> wrote= :
    Right, an= d in the GNAP model this becomes something my client instance presents to t= he AS when I show up. The AS can validate my presentation of this item and = give my client instance a token to call Steve=E2=80=99s RS. Or if you wante= d to get super fancy Steve=E2=80=99s AS could even challenge my client inst= ance and get a cryptographic response to prove I have the thing Steve had m= e scan. But in both cases it=E2=80=99s part of things that the AS collects = in order to create the access token.

    =C2=A0=E2=80= =94 Justin

    On Mar 18, 2021, at 2= :26 PM, Stephen Moore <srmoore@gmail.com> wrote:

    That in my mind works out great... Say I'm logged into my= home hub/AS. Justin is over and agrees to cat sit, I pull up my client app= , and generate a QR code that has maybe The AS URI, the HomeHub API URL, an= d the 'special token to present to AS for a real token'. Justin sca= ns that QR code with his home controller app, and BAM, he's onboarded a= s a guest without even logging into my AS or me dealing with his Auth provi= der.
    -steve

    On Thu, Mar 18, 2021 at 2:08 PM Justin Richer <jricher= @mit.edu> wrote:
    I think Steve=E2=80=99s use case gives an interesting example = of something that I believe Adrian=E2=80=99s been talking about as well =E2= =80=94 delegating to another person.

    We traditionally th= ink of delegation at the AS to mean =E2=80=9Ca different user account logs = in to the AS=E2=80=9D, and it=E2=80=99s important to know that this does in= fact work. But this could just as easily be =E2=80=9CSteve sends his frien= d an artifact to present to the AS to get access=E2=80=9D. This isn=E2=80= =99t Steve (or Steve=E2=80=99s client software) getting and sending an acce= ss token, this is sending some other set of rights credential to his friend= , or his friend=E2=80=99s software. So then Steve=E2=80=99s AS can have pol= icy that says =E2=80=9Cwhen I see this rights credential, give an access to= ken for the following attenuated things, because Steve said so=E2=80=9D. Th= e AS doesn=E2=80=99t even ever need to know who Steve=E2=80=99s friend is!= =C2=A0

    And importantly here, we don=E2=80=99t expe= ct Steve=E2=80=99s friend to bring their own AS to the party. Steve=E2=80= =99s RS has no reason to trust his friend=E2=80=99s AS, let alone his frien= d=E2=80=99s client. But Steve=E2=80=99s AS is in a position to know more ab= out the rights policies that Steve wants to apply, and so it can use other = technologies like VC=E2=80=99s, DIDs, OIDC, or any number of other things t= o let things go through. This pattern is exactly why I think we need to thi= nk of this in terms of what=E2=80=99s currently called =E2=80=9Cinteraction= =E2=80=9D at the AS. It=E2=80=99s not really just about how the end-user in= teracts, it=E2=80=99s about how the AS gathers all the consent and authoriz= ation information. I plan to rewrite section 4 to that effect.
    =C2=A0=E2=80=94 Justin

    <= div>On Mar 18, 2021, at 1:58 PM, Stephen Moore <srmoore@gmail.com>= wrote:

    I'm having some concerns with th= e way you're flipping the trust here Denis. You seem to indicate that t= he user has trust in the RS and the Client and has to gain the trust of the= AS. I feel like the least trustworthy portion of the architecture is the c= lient, because that seems like it is the most interchangeable component.=C2=A0Let me explain by way of a use case I have in mind.
    Let&#= 39;s say I have a smart home. I have devices and data storage and rule engi= nes that are parts of sensors and hubs I buy for the house. I have a trust = in those devices, because it's hardware, if the company is leaking data= at the hardware level there isn't much I can do other than buy differe= nt sensors.
    In this case, the primary home hub, which is under co= ntrol of the homeowner, would also be the AS, as well as a policy agent.=C2= =A0 Authentication in the example is outsourced to whatever auth providers = you want. I set up my home using a google account, a friend is staying and = wants access and uses FB for auth... whatever.
    The part that I ha= ve little control over is the client my friend uses on his phone. Or if I c= hange the client on the tablet in the kitchen to try out something new. The= se pieces=C2=A0might be single page web apps, they might be downloaded apps= , etc. I do not want them having any additional information than is necessa= ry. If I give my friend permission to unlock the door, and control the ligh= ts because they are feeding my cats while I'm away, the client doesn= 9;t need to know anything beyond, I see this home controller, and I have ac= cess to these lights and that door lock.

    In your s= cenarios, the client is spy by design, and if it is a web app, I don't = trust them to not grab my user email address from the=C2=A0AS and put it on= a mailing list it sells to some sketchy company,=C2=A0when the only other = component=C2=A0that needs that information is the RS.

    <= div>-steve

    On Thu, Mar 18, 2021 at 1:21 PM Denis <denis.ietf@free.f= r> wrote:
    I have changed the title of this thread, since the original= topic has been closed.=C2=A0

    Jus= tin, you are raising the following question:
    The ques= tion I have is =E2=80=94 why does the client need to know what=E2=80=99s in= the token?=C2=A0
    Not if they could possibly know, but why = would we expect a client to know and manage the contents of the token?=C2=A0
    The answer is quite simple: so th= at the end-user may have confidence into the architecture.=C2=A0
    The seventh of the eleven privacy principles from ISO 2910= 0 (page 14) is:
    7. Openness, transparency and noti= ce=C2=A0
    If the access token is= considered as a black box for the end-user, it cannot be confident about t= he content of the access token.
    Such access token may disclose some priv= ate information without the consent of the end-user. If the access token th= at it has obtained=C2=A0
    does not match with what has been = requested, the client will first not forward the access token to the RS and= then will complain about the AS.

    Denis


    Hi Justin,= =C2=A0

    "The access token is fundamentally a convers= ational artifact between the AS and the RS which the client is the carrier = of."
    That's right,=C2=A0and a good=C2=A0opportunity to d= istinguish between the need for token=C2=A0inspection (i.e. a runtime verif= ication, wherever that may be)=C2=A0
    and the need to negoti= ate the token format (a discovery). That last part could very well be an ex= tension, as a way to open up the ecosystem=C2=A0
    beyond JWT= s (which are fine, but come with their own limitations).=C2=A0
    Fabien

    On Thu, Mar 18, 2021 at 5:59 PM Justin Richer <= jri= cher@mit.edu> wrote:
    On Mar 18, 2021, at 11:30 AM, Alan Karp <alanhkarp@gma= il.com> wrote:

    Justin Rich= er <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 12:08 AM, Alan Karp <alanhk= arp@gmail.com> wrote:

    Adrian= Gropper <agropper@healthurl.com> wrote:

    Is there an AS involved in the delegation? How and where in the lifecycle= =C2=A0of the protected resource?=C2=A0

    If tokens are certificates, the AS need not be involved in subseque= nt delegations.=C2=A0 The AS must be involved if the tokens are opaque.=C2= =A0

    Tokens are opaq= ue to the client instance. They are not opaque to the AS. They might be opa= que to the RS, but that depends on the kind of relationship the RS and AS h= ave. GNAP should allow different options here as there are different use ca= ses for that.

    Tokens are not opaque to the client in SPKI, zcap-ld, Orie's impl= ementation with VCs, or our Zebra Copy work.=C2=A0 Why must they be in GNAP= ?

    The existen= ce of the AS is exactly the reason for this. The AS is the role that =E2=80= =9Cknowledge about the token contents=E2=80=9D has been outsourced to in th= e GNAP model (which is based on the OAuth model).

    = It brings significant simplicity for the client developer. The question I h= ave is =E2=80=94 why does the client need to know what=E2=80=99s in the tok= en? Not if they could possibly know, but why would we expect a client to kn= ow and manage the contents of the token?=C2=A0

    The= access token is fundamentally a conversational artifact between the AS and= the RS which the client is the carrier of. The client is not the audience = of the token, nor the creator of the token, nor even the manager of the tok= en and the rights it represents. The client as a simple carrier is a powerf= ul model that allows the security layer to get out of the way of the actual= application logic that developers want to do.

    =C2= =A0=E2=80=94 Justin


    --------------
    Alan Karp


    On Thu, Mar 18, 2021 at 4:56 AM Justin Richer <jricher@mit.edu= > wrote:
    =
    On Mar 18, 2021, at 12:08 AM, Alan Karp <alanhkarp@gmail.com&g= t; wrote:

    Adrian Gropper <ag= ropper@healthurl.com> wrote:

    Is there an AS inv= olved in the delegation? How and where in the lifecycle=C2=A0of the protect= ed resource?=C2=A0

    If tokens ar= e certificates, the AS need not be involved in subsequent delegations.=C2= =A0 The AS must be involved if the tokens are opaque.=C2=A0

    Tokens are opaque to the client in= stance. They are not opaque to the AS. They might be opaque to the RS, but = that depends on the kind of relationship the RS and AS have. GNAP should al= low different options here as there are different use cases for that.
    =

    It would probably be worthwhile to separate the portion= s of the spec that talk about the RS-AS relationship into its own standalon= e document. A similar approach was taken in UMA2 and it was helpful. (Thoug= h admittedly, as with anything, there are missteps there that we can hopefu= lly learn from.)

    =C2=A0=E2=80=94 Justin

    <= blockquote type=3D"cite">

    --------------
    Alan Karp

    =
    On Wed= , Mar 17, 2021 at 8:54 PM Adrian Gropper <agropper@healthurl.com= > wrote:
    Sure!=C2=A0

    Is there an AS involved in the = delegation? How and where in the lifecycle=C2=A0of the protected resource?= =C2=A0

    Also your use of "the client" seems to = imply that either there is only one client or the client doesn't matter= . Which is it?

    Adrian

    On Wed, Mar 17, 2= 021 at 11:43 PM Fabien Imbault <fabien.imbault@gmail.com> w= rote:
    Thanks for that.=C2=A0

    Trying to reframe it:
    GNAP is defined = as a delegation protocol so the main intent is related to a delegate of the= RO (i.e. the end user) that wishes to access the RO's protected resour= ces, through the client.=C2=A0

    Fabien=C2=A0
    <= br>
    Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper <agropper@he= althurl.com> a =C3=A9crit=C2=A0:
    At various points in the lifecycle= =C2=A0of the protected resource the client at the resource server (RS) migh= t be:
    • The RO (subject) user agent trading payment for a service= promise
    • The RO user agent using the promise to access the protecte= d resource
    • A delegate of the RO user agent using a different client=
    What's vague is where the GNAP AS enters the picture as = described above. How would you describe it?

    = Adrian


    On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Hi Adrian
    I'm still confused why you&#= 39;re saying the terminology is vague.=C2=A0
    I get t= he "power" neutrality is not to your liking, but RQ / user agent = is no better in my view.=C2=A0

    Can you elaborate?=C2=A0

    Fabien=C2=A0

    Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gro= pper <agropper@healthurl.com> a =C3=A9crit=C2=A0:<= br>
    I'm sure you're right. Our vague terminology=C2=A0around client=C2= =A0and=C2=A0end-user leads to my confusion. If GNAP is primarily about dele= gation=C2=A0then, of course, we should=C2=A0avoid any incentives to imperso= nate or we're wasting our time. This is partly why I'm trying to st= udy up on capabilities and asking for expert advice from folks like Alan Ka= rp and Mark Miller (cc'd)

    As best I can understand i= t, the RS has only two choices, it can:
    • store an attribut= e of the RO a [DID, email address, GNAP AS URL], or
    • hand the RO a c= apability as a sort-of promise and avoid making any entries in an ACL or eq= uivalent.
    When a token comes back to the RS, it will either b= e:
    • validated according to something associated with the s= tored RO attribute, or
    • signed by the RS itself.
    E= ither way, trust in the client seems moot.

    Adrian<= /div>



    On Wed, Mar 17, 2021 at 5:29= PM Justin Richer <jricher@mit.edu> wrote:
    =
    On Mar 17, 202= 1, at 4:55 PM, Adrian Gropper <agropper@health= url.com> wrote:

    On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <= ;tobias.looker@mattr.global> wrote:
    <snip>
    > A client might= not have a DID but it could have a VC as a certificate of authenticity lin= ked to some audit mechanism.

    To me a VC would come= under the assertions umbrella (that is to say a VC could be one type of va= lid assertion). The client may possess or been presented with a VC that it = could include in its request to the AS as a way to identify the subject and= perhaps prove authentication and authorization.

    I do not assume that the client that interacts with the A= S to make a request and receive a token is the same as the client that will= present the token to the RS. In the US HIPAA use-case, for example, the ro= ot of trust is a contract between the patient-subject and the doctor-reques= ting party but the doctor workflow is expected to delegate the token to som= e other end-user that may be using a totally different client such as an EH= R.


    If the= client that gets the token is not same as the client that uses the token, = that is a violation of core security principles as it allows for (and reall= y designs for) impersonation by client software. I would have no reason to = trust client software that would hand its credentials over to another piece= of software, and in fact I shouldn=E2=80=99t trust it.=C2=A0
    I think you may be conflating several different kinds of partie= s under the =E2=80=9Cclient=E2=80=9D umbrella here, though. It=E2=80=99s en= tirely possible that one client might call an RS that in turn acts as a cli= ent for something else down stream. But each of those hops is different fro= m the last.

    =C2=A0=E2=80=94 Justin

    =




    --=C2=A0
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    --=C2=A0
    TXAuth mailing list
    TXAuth@iet= f.org
    https://www.ietf.org/mailman/listinfo/txa= uth


    --=C2=A0
    TXAuth = mailing list
    TXAuth@ietf.org
    https://w= ww.ietf.org/mailman/listinfo/txauth
    --=C2= =A0
    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

    --=C2=A0
    You know nothing Jon Snow!

    --=C2=A0
    You know nothing Jon Snow!



    --00000000000066aacd05bde72f02-- From nobody Fri Mar 19 11:23:36 2021 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 1D88A3A0883 for ; Fri, 19 Mar 2021 11:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 SOaK3Ebie8V0 for ; Fri, 19 Mar 2021 11:23:29 -0700 (PDT) Received: from mail-vk1-f169.google.com (mail-vk1-f169.google.com [209.85.221.169]) (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 6E1693A086E for ; Fri, 19 Mar 2021 11:23:29 -0700 (PDT) Received: by mail-vk1-f169.google.com with SMTP id o4so2304081vka.12 for ; Fri, 19 Mar 2021 11:23:29 -0700 (PDT) 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=97SihIWrdW4PIU+DQpC3jvUPLRhtlpYbt8vnAPH3QH8=; b=j1vGV/XwW8cJl5zjnnnAoxVcL64RSJV4QpxYjXiZ8AdJ5PmlP4/ns6rkLY5zXiiEex 8kK+xBKBtxPFlxdxAtA8AlqsTXRlL/lm5v7ZvJiMH6Yet07eiMP8cojPeoNAZXhTTu3A M9G0RjtV4GxLl+VLABJ/hfz/MOLuUcRPWn8i92GRpBbmcmiiXQ/g3QQuwP9fn0/rYOhc heoYdillMEKq0I54mOaZZEruilvqzGWez7QiYDRog6B5cKrAwuWlvsI8DECBLiv4/Tq7 EYWvOrxJ3QV6Sqt8LsI5C4d+NE+fw5cDlO9mtq8dhe0SGD6b3A1nJfMdEQbFhJP97PKA f5Uw== X-Gm-Message-State: AOAM533pDAtmqjqaKpEsZTVPMDmTln69u/1KUw1shRg174+aemsvUP4P KKiWa1xI8uDKqgBJACLt/JJGB5tnFPLQP24eELQ= X-Google-Smtp-Source: ABdhPJxDphF/3WVgNN04JHjLJ+6b/L8ogN7PM6nbXABESy64Aa3IOCwL+LkBacK5d4+xejN2x5sZzRBRG10lGUb3Oh0= X-Received: by 2002:a1f:914c:: with SMTP id t73mr3808317vkd.7.1616178208152; Fri, 19 Mar 2021 11:23:28 -0700 (PDT) MIME-Version: 1.0 References: <43447446-4061-49F2-8486-5A196C3C75E2@mit.edu> <37a04505-84ef-aecf-6913-5aad8330c97c@free.fr> <3FE214B6-CF96-472D-853B-C7C5AC7A73AE@mit.edu> <8DF709AE-B17D-4B53-92FC-723F2C8C2503@mit.edu> <48B35DA4-9B92-493B-B2CC-C03544A1707D@mit.edu> In-Reply-To: From: Adrian Gropper Date: Fri, 19 Mar 2021 14:23:15 -0400 Message-ID: To: Fabien Imbault Cc: Justin Richer , Alejandro Iacobelli , txauth gnap , Steve Moore Content-Type: multipart/alternative; boundary="000000000000fd9eed05bde7cf6b" Archived-At: Subject: Re: [GNAP] Should access tokens be opaque or not for the clients ? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 18:23:34 -0000 --000000000000fd9eed05bde7cf6b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm not disagreeing, just reserving judgement until I see a PR about this AS-RS idea. My mention of the Capcha was a shortcut and a bad example. What I meant to say is that relying parties, the RS in this case, can make demands. FIDO, for example, can demand a certificate signed by some trusted entity and that a person touch a thing. As Justin says, the RO could be a person - but it could also be a thing or an entity or software. So, I'm not sure where we're headed and look forward to a proposal. Adrian On Fri, Mar 19, 2021 at 1:38 PM Fabien Imbault wrote: > Oh I thought capchas were mostly a way to train your AI for free ;-) > > Joke aside, I support Justin's view of what goes into core versus what th= e > kind of modularity we might bring in addition to that. > > Fabien > > On Fri, Mar 19, 2021 at 6:32 PM Justin Richer wrote: > >> The only way for the RS operator could introduce a captcha, within the >> definitions of the GNAP protocol, is through an AS. Or more properly, >> through this yes-unnamed aspect of =E2=80=9Cinteracting with the RO=E2= =80=9D that the AS is >> in charge of coordinating the results of. The RS is not an end-user-faci= ng >> service, it is an API, software meant to be called by other software. Th= e >> defined way for the =E2=80=9CRS=E2=80=9D to interact with a person, issu= e tokens, or >> anything of the sort is through an AS. >> >> In OAuth 1, the AS and RS were just called the =E2=80=9Cauthorization se= rver=E2=80=9D or >> even just =E2=80=9Cserver", and it seems like a lot of the discussion on= this >> thread is collapsing that same set of roles back but instead calling it = the >> =E2=80=9CRS=E2=80=9D. I think this is problematic both in terms of the f= lexibility of the >> protocol and also in terms of clarity in what we=E2=80=99re describing a= nd >> discussing. >> >> =E2=80=94 Justin >> >> On Mar 19, 2021, at 1:26 PM, Adrian Gropper >> wrote: >> >> I agree. The problem is that powerful RS operators introduce things like >> Capchas that hassle the RO. Sometimes this is justified but often it >> reflects an inadequate protocol. >> >> Adrian >> >> On Fri, Mar 19, 2021 at 1:22 PM Justin Richer wrote: >> >>> There=E2=80=99s an important difference here: >>> >>> The AS is software. Always. It plays a specific role within the protoco= l. >>> >>> The RO could be a person. It could be an agency. It could be a policy. >>> They don=E2=80=99t take part in the protocol directly but are involved = in decisions >>> made in the course of the protocol. >>> >>> These are two very, very different things, and they can=E2=80=99t be co= nflated. >>> >>> I like the idea of talking in terms of relationships, such as AS-RS (a >>> protocol relationship) and AS-RO (a trust relationship). >>> >>> =E2=80=94 Justin >>> >>> On Mar 19, 2021, at 12:37 PM, Adrian Gropper >>> wrote: >>> >>> It might be a good idea to keep the RS to AS relationship out of the >>> GNAP spec but I=E2=80=99m having a hard time analyzing it in the abstra= ct. >>> >>> My starting perspective is that the RS should not know or care whether >>> it is dealing with the AS or the RO. This is super important because it >>> gives the RO unlimited delegation power. >>> >>> Cases where the RO wants to give the RS a separate endpoint or other >>> identity should be allowed by GNAP but might be out of band. This is th= e >>> HIPAA API Task Force use case that I have referenced in another thread.= The >>> issue here is that the RS has the option of reaching out to the RO and >>> requesting confirmation. >>> >>> Adrian >>> >>> On Fri, Mar 19, 2021 at 11:37 AM Justin Richer wrote: >>> >>>> My proposal is that the client instance shouldn=E2=80=99t care what=E2= =80=99s in the >>>> token, what format it is, etc. >>>> >>>> The RS can care and there should be choices that include random, >>>> sealed, and even plainly signed tokens. That choice is part of the >>>> relationship between the RS and AS, which the core GNAP protocol doesn= =E2=80=99t >>>> specify. >>>> >>>> This is why I propose that we extract what=E2=80=99s now section 10 in= the >>>> draft and put it into a new document that can more directly discuss th= at >>>> relationship. These different relationships should be modular. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Mar 19, 2021, at 11:13 AM, Alejandro Iacobelli < >>>> aiacobelli.sec@gmail.com> wrote: >>>> >>>> Agree! So what are you saying the proposal should be? Random or sealed >>>> tokens? >>>> >>>> El El vie, 19 mar. 2021 a la(s) 10:04, Justin Richer >>>> escribi=C3=B3: >>>> >>>>> One of the best ways to protect information in the token is to not pu= t >>>>> it in the token in the first place. This is why a some highly-sensiti= ve >>>>> application profiles and deployments us randomized values as tokens. = The RS >>>>> has a way to dereference it, which is important. >>>>> >>>>> For downstream delegation, like one micro service calling another, >>>>> we=E2=80=99re no longer talking about the client knowing the access t= oken, we=E2=80=99re >>>>> talking about an RS at the first step. This is where non-opaque, or >>>>> encrypted, or other kinds of recoverable data structures come into pl= ay >>>>> more directly. >>>>> >>>>> To Adrian=E2=80=99s point, sharing the QR code should be up to the AS= =E2=80=99s >>>>> policy. If Steve gives me a bearer artifact that isn=E2=80=99t attach= ed to anything >>>>> that identifies me, then it=E2=80=99s easy for me to share because th= e artifact is >>>>> the identity and proof all in one. The strawman description below sou= nds >>>>> like that. But it=E2=80=99s important in this design that the AS can = also require >>>>> me to log in with a specific account, plus present a token, plus type= in a >>>>> secret code, plus present a hardware key that completes a circuit in = the >>>>> right way (seems like something Steve would build, tbh), etc. But all= of >>>>> these aren=E2=80=99t a client talking to a resource, they=E2=80=99re = the end-user >>>>> presenting things to the AS so that the AS can make a policy decisio= n to >>>>> issue a token and allow access. >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Mar 18, 2021, at 8:23 PM, Alejandro Iacobelli < >>>>> aiacobelli.sec@gmail.com> wrote: >>>>> >>>>> The decision about "opaque" vs "sealed but recoverable" or "signed" >>>>> access_token goes way back on the stateless protocols session managem= ent. >>>>> >>>>> In my opinion, the software design principle that we must apply here >>>>> is the "need to know" principle. This means, the less information an >>>>> attacker could get, the better. One thing that JWS explse is all the >>>>> context information about a token, so an attacker can get lots of >>>>> information just with a look. >>>>> >>>>> The next discussion will be what ways of generating opaque tokens are >>>>> there and which must we choose (Encrypted vs CSPRNG based). >>>>> >>>>> On Thu, 18 Mar 2021 at 21:17, Fabien Imbault >>>>> wrote: >>>>> >>>>>> Hi Adrian, >>>>>> >>>>>> I'm really not sure I understand here. >>>>>> >>>>>> I get the idea of putting a policy engine in front of your services >>>>>> to implement ZTA. But I'm not sure I get this way of framing things.= It >>>>>> blurs functional roles and actual services, and most importantly if >>>>>> everything gets its own AS, it also gets by transitivity its RO'/RQ'= (and >>>>>> then its AS-RO' etc) and so the complexity becomes staggering. >>>>>> Why do we need that? >>>>>> >>>>>> Fabien >>>>>> >>>>>> Le ven. 19 mars 2021 =C3=A0 00:55, Adrian Gropper >>>>>> a =C3=A9crit : >>>>>> >>>>>>> +1 This aligns with my healthcare use-case to the extent that Justi= n >>>>>>> can transfer the capability granted by that QR code to Adrian who h= appens >>>>>>> to be nearby Steve's house. >>>>>>> >>>>>>> I've tried to capture some of this in my comment to #145 >>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issue= comment-802388458 >>>>>>> >>>>>>> - Adrian >>>>>>> >>>>>>> On Thu, Mar 18, 2021 at 2:39 PM Justin Richer >>>>>>> wrote: >>>>>>> >>>>>>>> Right, and in the GNAP model this becomes something my client >>>>>>>> instance presents to the AS when I show up. The AS can validate my >>>>>>>> presentation of this item and give my client instance a token to c= all >>>>>>>> Steve=E2=80=99s RS. Or if you wanted to get super fancy Steve=E2= =80=99s AS could even >>>>>>>> challenge my client instance and get a cryptographic response to p= rove I >>>>>>>> have the thing Steve had me scan. But in both cases it=E2=80=99s p= art of things >>>>>>>> that the AS collects in order to create the access token. >>>>>>>> >>>>>>>> =E2=80=94 Justin >>>>>>>> >>>>>>>> On Mar 18, 2021, at 2:26 PM, Stephen Moore >>>>>>>> wrote: >>>>>>>> >>>>>>>> That in my mind works out great... Say I'm logged into my home >>>>>>>> hub/AS. Justin is over and agrees to cat sit, I pull up my client = app, and >>>>>>>> generate a QR code that has maybe The AS URI, the HomeHub API URL,= and the >>>>>>>> 'special token to present to AS for a real token'. Justin scans th= at QR >>>>>>>> code with his home controller app, and BAM, he's onboarded as a gu= est >>>>>>>> without even logging into my AS or me dealing with his Auth provid= er. >>>>>>>> -steve >>>>>>>> >>>>>>>> On Thu, Mar 18, 2021 at 2:08 PM Justin Richer >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I think Steve=E2=80=99s use case gives an interesting example of = something >>>>>>>>> that I believe Adrian=E2=80=99s been talking about as well =E2=80= =94 delegating to another >>>>>>>>> person. >>>>>>>>> >>>>>>>>> We traditionally think of delegation at the AS to mean =E2=80=9Ca >>>>>>>>> different user account logs in to the AS=E2=80=9D, and it=E2=80= =99s important to know that >>>>>>>>> this does in fact work. But this could just as easily be =E2=80= =9CSteve sends his >>>>>>>>> friend an artifact to present to the AS to get access=E2=80=9D. T= his isn=E2=80=99t Steve >>>>>>>>> (or Steve=E2=80=99s client software) getting and sending an acces= s token, this is >>>>>>>>> sending some other set of rights credential to his friend, or his= friend=E2=80=99s >>>>>>>>> software. So then Steve=E2=80=99s AS can have policy that says = =E2=80=9Cwhen I see this >>>>>>>>> rights credential, give an access token for the following attenua= ted >>>>>>>>> things, because Steve said so=E2=80=9D. The AS doesn=E2=80=99t ev= en ever need to know who >>>>>>>>> Steve=E2=80=99s friend is! >>>>>>>>> >>>>>>>>> And importantly here, we don=E2=80=99t expect Steve=E2=80=99s fri= end to bring >>>>>>>>> their own AS to the party. Steve=E2=80=99s RS has no reason to tr= ust his friend=E2=80=99s >>>>>>>>> AS, let alone his friend=E2=80=99s client. But Steve=E2=80=99s AS= is in a position to know >>>>>>>>> more about the rights policies that Steve wants to apply, and so = it can use >>>>>>>>> other technologies like VC=E2=80=99s, DIDs, OIDC, or any number o= f other things to >>>>>>>>> let things go through. This pattern is exactly why I think we nee= d to think >>>>>>>>> of this in terms of what=E2=80=99s currently called =E2=80=9Cinte= raction=E2=80=9D at the AS. It=E2=80=99s >>>>>>>>> not really just about how the end-user interacts, it=E2=80=99s ab= out how the AS >>>>>>>>> gathers all the consent and authorization information. I plan to = rewrite >>>>>>>>> section 4 to that effect. >>>>>>>>> >>>>>>>>> =E2=80=94 Justin >>>>>>>>> >>>>>>>>> On Mar 18, 2021, at 1:58 PM, Stephen Moore >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> I'm having some concerns with the way you're flipping the trust >>>>>>>>> here Denis. You seem to indicate that the user has trust in the R= S and the >>>>>>>>> Client and has to gain the trust of the AS. I feel like the least >>>>>>>>> trustworthy portion of the architecture is the client, because th= at seems >>>>>>>>> like it is the most interchangeable component. >>>>>>>>> Let me explain by way of a use case I have in mind. >>>>>>>>> Let's say I have a smart home. I have devices and data storage an= d >>>>>>>>> rule engines that are parts of sensors and hubs I buy for the hou= se. I have >>>>>>>>> a trust in those devices, because it's hardware, if the company i= s leaking >>>>>>>>> data at the hardware level there isn't much I can do other than b= uy >>>>>>>>> different sensors. >>>>>>>>> In this case, the primary home hub, which is under control of the >>>>>>>>> homeowner, would also be the AS, as well as a policy agent. Auth= entication >>>>>>>>> in the example is outsourced to whatever auth providers you want.= I set up >>>>>>>>> my home using a google account, a friend is staying and wants acc= ess and >>>>>>>>> uses FB for auth... whatever. >>>>>>>>> The part that I have little control over is the client my friend >>>>>>>>> uses on his phone. Or if I change the client on the tablet in the= kitchen >>>>>>>>> to try out something new. These pieces might be single page web a= pps, they >>>>>>>>> might be downloaded apps, etc. I do not want them having any addi= tional >>>>>>>>> information than is necessary. If I give my friend permission to = unlock the >>>>>>>>> door, and control the lights because they are feeding my cats whi= le I'm >>>>>>>>> away, the client doesn't need to know anything beyond, I see this= home >>>>>>>>> controller, and I have access to these lights and that door lock. >>>>>>>>> >>>>>>>>> In your scenarios, the client is spy by design, and if it is a we= b >>>>>>>>> app, I don't trust them to not grab my user email address from th= e AS and >>>>>>>>> put it on a mailing list it sells to some sketchy company, when t= he only >>>>>>>>> other component that needs that information is the RS. >>>>>>>>> >>>>>>>>> -steve >>>>>>>>> >>>>>>>>> On Thu, Mar 18, 2021 at 1:21 PM Denis wrote: >>>>>>>>> >>>>>>>>>> I have changed the title of this thread, since the original topi= c >>>>>>>>>> has been closed. >>>>>>>>>> >>>>>>>>>> Justin, you are raising the following question: >>>>>>>>>> >>>>>>>>>> The question I have is =E2=80=94 why does the client need to kno= w what=E2=80=99s >>>>>>>>>> in the token? >>>>>>>>>> Not if they could possibly know, but why would we expect a clien= t >>>>>>>>>> to know and manage the contents of the token? >>>>>>>>>> >>>>>>>>>> The answer is quite simple: so that the end-user may have >>>>>>>>>> confidence into the architecture. >>>>>>>>>> The seventh of the eleven privacy principles from ISO 29100 (pag= e >>>>>>>>>> 14) is: >>>>>>>>>> >>>>>>>>>> *7. Openness, transparency and notice * >>>>>>>>>> >>>>>>>>>> If the access token is considered as a black box for the >>>>>>>>>> end-user, it cannot be confident about the content of the access= token. >>>>>>>>>> Such access token may disclose some private information without >>>>>>>>>> the consent of the end-user. If the access token that it has obt= ained >>>>>>>>>> >>>>>>>>>> does not match with what has been requested, the client will >>>>>>>>>> first not forward the access token to the RS and then will compl= ain about >>>>>>>>>> the AS. >>>>>>>>>> >>>>>>>>>> Denis >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi Justin, >>>>>>>>>> >>>>>>>>>> "The access token is fundamentally a conversational artifact >>>>>>>>>> between the AS and the RS which the client is the carrier of." >>>>>>>>>> That's right, and a good opportunity to distinguish between the >>>>>>>>>> need for token inspection (i.e. a runtime verification, wherever= that may >>>>>>>>>> be) >>>>>>>>>> and the need to negotiate the token format (a discovery). That >>>>>>>>>> last part could very well be an extension, as a way to open up t= he ecosystem >>>>>>>>>> >>>>>>>>>> beyond JWTs (which are fine, but come with their own >>>>>>>>>> limitations). >>>>>>>>>> >>>>>>>>>> Fabien >>>>>>>>>> >>>>>>>>>> On Thu, Mar 18, 2021 at 5:59 PM Justin Richer >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> On Mar 18, 2021, at 11:30 AM, Alan Karp >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Justin Richer wrote: >>>>>>>>>>> >>>>>>>>>>>> On Mar 18, 2021, at 12:08 AM, Alan Karp >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Adrian Gropper wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Is there an AS involved in the delegation? How and where in >>>>>>>>>>>>> the lifecycle of the protected resource? >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> If tokens are certificates, the AS need not be involved in >>>>>>>>>>>> subsequent delegations. The AS must be involved if the tokens= are opaque. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Tokens are opaque to the client instance. They are not opaque >>>>>>>>>>>> to the AS. They might be opaque to the RS, but that depends on= the kind of >>>>>>>>>>>> relationship the RS and AS have. GNAP should allow different o= ptions here >>>>>>>>>>>> as there are different use cases for that. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Tokens are not opaque to the client in SPKI, zcap-ld, Orie's >>>>>>>>>>> implementation with VCs, or our Zebra Copy work. Why must they= be in GNAP? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The existence of the AS is exactly the reason for this. The AS >>>>>>>>>>> is the role that =E2=80=9Cknowledge about the token contents=E2= =80=9D has been outsourced >>>>>>>>>>> to in the GNAP model (which is based on the OAuth model). >>>>>>>>>>> >>>>>>>>>>> It brings significant simplicity for the client developer. The >>>>>>>>>>> question I have is =E2=80=94 why does the client need to know w= hat=E2=80=99s in the token? >>>>>>>>>>> Not if they could possibly know, but why would we expect a clie= nt to know >>>>>>>>>>> and manage the contents of the token? >>>>>>>>>>> >>>>>>>>>>> The access token is fundamentally a conversational artifact >>>>>>>>>>> between the AS and the RS which the client is the carrier of. T= he client is >>>>>>>>>>> not the audience of the token, nor the creator of the token, no= r even the >>>>>>>>>>> manager of the token and the rights it represents. The client a= s a simple >>>>>>>>>>> carrier is a powerful model that allows the security layer to g= et out of >>>>>>>>>>> the way of the actual application logic that developers want to= do. >>>>>>>>>>> >>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -------------- >>>>>>>>>>> Alan Karp >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Mar 18, 2021 at 4:56 AM Justin Richer >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> On Mar 18, 2021, at 12:08 AM, Alan Karp >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Adrian Gropper wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Is there an AS involved in the delegation? How and where in >>>>>>>>>>>>> the lifecycle of the protected resource? >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> If tokens are certificates, the AS need not be involved in >>>>>>>>>>>> subsequent delegations. The AS must be involved if the tokens= are opaque. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Tokens are opaque to the client instance. They are not opaque >>>>>>>>>>>> to the AS. They might be opaque to the RS, but that depends on= the kind of >>>>>>>>>>>> relationship the RS and AS have. GNAP should allow different o= ptions here >>>>>>>>>>>> as there are different use cases for that. >>>>>>>>>>>> >>>>>>>>>>>> It would probably be worthwhile to separate the portions of th= e >>>>>>>>>>>> spec that talk about the RS-AS relationship into its own stand= alone >>>>>>>>>>>> document. A similar approach was taken in UMA2 and it was help= ful. (Though >>>>>>>>>>>> admittedly, as with anything, there are missteps there that we= can >>>>>>>>>>>> hopefully learn from.) >>>>>>>>>>>> >>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -------------- >>>>>>>>>>>> Alan Karp >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper < >>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Sure! >>>>>>>>>>>>> >>>>>>>>>>>>> Is there an AS involved in the delegation? How and where in >>>>>>>>>>>>> the lifecycle of the protected resource? >>>>>>>>>>>>> >>>>>>>>>>>>> Also your use of "the client" seems to imply that either ther= e >>>>>>>>>>>>> is only one client or the client doesn't matter. Which is it? >>>>>>>>>>>>> >>>>>>>>>>>>> Adrian >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault < >>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks for that. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Trying to reframe it: >>>>>>>>>>>>>> GNAP is defined as a delegation protocol so the main intent >>>>>>>>>>>>>> is related to a delegate of the RO (i.e. the end user) that = wishes to >>>>>>>>>>>>>> access the RO's protected resources, through the client. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>> >>>>>>>>>>>>>> Le jeu. 18 mars 2021 =C3=A0 04:29, Adrian Gropper < >>>>>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>>>>> >>>>>>>>>>>>>>> At various points in the lifecycle of the protected resourc= e >>>>>>>>>>>>>>> the client at the resource server (RS) might be: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - The RO (subject) user agent trading payment for a >>>>>>>>>>>>>>> service promise >>>>>>>>>>>>>>> - The RO user agent using the promise to access the >>>>>>>>>>>>>>> protected resource >>>>>>>>>>>>>>> - A delegate of the RO user agent using a different >>>>>>>>>>>>>>> client >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> What's vague is where the GNAP AS enters the picture as >>>>>>>>>>>>>>> described above. How would you describe it? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault < >>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Adrian >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm still confused why you're saying the terminology is >>>>>>>>>>>>>>>> vague. >>>>>>>>>>>>>>>> I get the "power" neutrality is not to your liking, but RQ >>>>>>>>>>>>>>>> / user agent is no better in my view. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Can you elaborate? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper < >>>>>>>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'm sure you're right. Our vague terminology around >>>>>>>>>>>>>>>>> client and end-user leads to my confusion. If GNAP is pri= marily about >>>>>>>>>>>>>>>>> delegation then, of course, we should avoid any incentive= s to impersonate >>>>>>>>>>>>>>>>> or we're wasting our time. This is partly why I'm trying = to study up on >>>>>>>>>>>>>>>>> capabilities and asking for expert advice from folks like= Alan Karp and >>>>>>>>>>>>>>>>> Mark Miller (cc'd) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> As best I can understand it, the RS has only two choices, >>>>>>>>>>>>>>>>> it can: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - store an attribute of the RO a [DID, email address, >>>>>>>>>>>>>>>>> GNAP AS URL], or >>>>>>>>>>>>>>>>> - hand the RO a capability as a sort-of promise and >>>>>>>>>>>>>>>>> avoid making any entries in an ACL or equivalent. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> When a token comes back to the RS, it will either be: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - validated according to something associated with the >>>>>>>>>>>>>>>>> stored RO attribute, or >>>>>>>>>>>>>>>>> - signed by the RS itself. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Either way, trust in the client seems moot. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer < >>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper < >>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker < >>>>>>>>>>>>>>>>>> tobias.looker@mattr.global> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > A client might not have a DID but it could have a VC >>>>>>>>>>>>>>>>>>> as a certificate of authenticity linked to some audit m= echanism. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> To me a VC would come under the assertions umbrella >>>>>>>>>>>>>>>>>>> (that is to say a VC could be one type of valid asserti= on). The client may >>>>>>>>>>>>>>>>>>> possess or been presented with a VC that it could inclu= de in its request to >>>>>>>>>>>>>>>>>>> the AS as a way to identify the subject and perhaps pro= ve authentication >>>>>>>>>>>>>>>>>>> and authorization. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I do not assume that the client that interacts with the >>>>>>>>>>>>>>>>>> AS to make a request and receive a token is the same as = the client that >>>>>>>>>>>>>>>>>> will present the token to the RS. In the US HIPAA use-ca= se, for example, >>>>>>>>>>>>>>>>>> the root of trust is a contract between the patient-subj= ect and the >>>>>>>>>>>>>>>>>> doctor-requesting party but the doctor workflow is expec= ted to delegate the >>>>>>>>>>>>>>>>>> token to some other end-user that may be using a totally= different client >>>>>>>>>>>>>>>>>> such as an EHR. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> If the client that gets the token is not same as the >>>>>>>>>>>>>>>>>> client that uses the token, that is a violation of core = security principles >>>>>>>>>>>>>>>>>> as it allows for (and really designs for) impersonation = by client software. >>>>>>>>>>>>>>>>>> I would have no reason to trust client software that wou= ld hand its >>>>>>>>>>>>>>>>>> credentials over to another piece of software, and in fa= ct I shouldn=E2=80=99t >>>>>>>>>>>>>>>>>> trust it. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I think you may be conflating several different kinds of >>>>>>>>>>>>>>>>>> parties under the =E2=80=9Cclient=E2=80=9D umbrella here= , though. It=E2=80=99s entirely possible >>>>>>>>>>>>>>>>>> that one client might call an RS that in turn acts as a = client for >>>>>>>>>>>>>>>>>> something else down stream. But each of those hops is di= fferent from the >>>>>>>>>>>>>>>>>> last. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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 >>>>>>>> >>>>>>> -- >>>>>>> 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 >>>>>> >>>>> >>>>> >>>>> -- >>>>> You know nothing Jon Snow! >>>>> >>>>> >>>>> -- >>>> You know nothing Jon Snow! >>>> >>>> >>>> >>> >> -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000fd9eed05bde7cf6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I'm not disagreeing, just reserving judgement until I = see a PR about this AS-RS idea.=C2=A0

    My mention of the = Capcha=C2=A0was a shortcut and a bad example. What I meant to say is that r= elying parties, the RS in this case, can make demands. FIDO, for example, c= an demand a certificate signed by some trusted entity and that a person=C2= =A0touch a thing.=C2=A0

    As Justin says, the RO cou= ld be a person - but it could also be a thing or an entity or software. So,= I'm not sure where we're headed and look forward to a proposal.

    Adrian



    =
    On Fri, Ma= r 19, 2021 at 1:38 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Oh I thought capchas were mostly a way to train your AI f= or free ;-)=C2=A0

    Joke aside, I support Justin's vie= w of what goes into core versus what the kind of modularity we might bring = in addition to that.

    Fabien

    On Fri, Mar 19, 2= 021 at 6:32 PM Justin Richer <jricher@mit.edu> wrote:
    T= he only way for the RS operator could introduce a captcha, within the defin= itions of the GNAP protocol, is through an AS. Or more properly, through th= is yes-unnamed aspect of =E2=80=9Cinteracting with the RO=E2=80=9D that the= AS is in charge of coordinating the results of. The RS is not an end-user-= facing service, it is an API, software meant to be called by other software= . The defined way for the =E2=80=9CRS=E2=80=9D to interact with a person, i= ssue tokens, or anything of the sort is through an AS.=C2=A0

    =
    In OAuth 1, the AS and RS were just called the =E2=80=9Cauthorization = server=E2=80=9D or even just =E2=80=9Cserver", and it seems like a lot= of the discussion on this thread is collapsing that same set of roles back= but instead calling it the =E2=80=9CRS=E2=80=9D. I think this is problemat= ic both in terms of the flexibility of the protocol and also in terms of cl= arity in what we=E2=80=99re describing and discussing.=C2=A0

    =
    =C2=A0=E2=80=94 Justin

    On Mar 19, 2021, at 1:26 PM, Adrian Gropper <agropper@healthurl.com> wrote:
    I agree. The problem is that powerful RS oper= ators introduce things like Capchas that hassle the RO. Sometimes this is j= ustified but often it reflects an inadequate protocol.=C2=A0

    Adrian

    On Fri, Mar 19, 2021 at 1:= 22 PM Justin Richer <jricher@mit.edu> wrote:
    There=E2=80= =99s an important difference here:

    The AS is software. A= lways. It plays a specific role within the protocol.

    The RO could be a person. It could be an agency. It could be a policy. T= hey don=E2=80=99t take part in the protocol directly but are involved in de= cisions made in the course of the protocol.

    These = are two very, very different things, and they can=E2=80=99t be conflated.

    I like the idea of talking in terms of relationship= s, such as AS-RS (a protocol relationship) and AS-RO (a trust relationship)= .=C2=A0

    =C2=A0=E2=80=94 Justin
    =
    On Mar 19, 2021, at 12:37 PM, Adrian Gro= pper <agropp= er@healthurl.com> wrote:

    It might be= a good idea to keep the RS to AS relationship out of the GNAP spec but I= =E2=80=99m having a hard time analyzing it in the abstract.=C2=A0

    My starting perspective is that t= he RS should not know or care whether it is dealing with the AS or the RO. = This is super important because it gives the RO unlimited delegation power.= =C2=A0

    Cases where the R= O wants to give the RS a separate endpoint or other identity should be allo= wed by GNAP but might be out of band. This is the HIPAA API Task Force use = case that I have referenced in another thread. The issue here is that the R= S has the option of reaching out to the RO and requesting confirmation.

    Adrian =C2=A0
    On Fri, M= ar 19, 2021 at 11:37 AM Justin Richer <jricher@mit.edu> wrote:
    My proposal is that the client instance shouldn=E2=80=99t care what= =E2=80=99s in the token, what format it is, etc.

    The RS = can care and there should be choices that include random, sealed, and even = plainly signed tokens. That choice is part of the relationship between the = RS and AS, which the core GNAP protocol doesn=E2=80=99t specify.=C2=A0

    This is why I propose that we extract what=E2=80=99s n= ow section 10 in the draft and put it into a new document that can more dir= ectly discuss that relationship. These different relationships should be mo= dular.=C2=A0

    =C2=A0=E2=80=94 Justin
    =

    On Mar 19, 2021, at 11:13 AM, Aleja= ndro Iacobelli <aiacobelli.sec@gmail.com> wrote:

    Agree! So what are you saying the proposal should be? Ra= ndom or sealed tokens?

    El El vie, 19 mar. 2021 a la(s) = 10:04, Justin Richer <jricher@mit.edu> escribi=C3=B3:
    On= e of the best ways to protect information in the token is to not put it in = the token in the first place. This is why a some highly-sensitive applicati= on profiles and deployments us randomized values as tokens. The RS has a wa= y to dereference it, which is important.

    For downstream = delegation, like one micro service calling another, we=E2=80=99re no longer= talking about the client knowing the access token, we=E2=80=99re talking a= bout an RS at the first step. This is where non-opaque, or encrypted, or ot= her kinds of recoverable data structures come into play more directly.=C2= =A0

    To Adrian=E2=80=99s point, sharing the QR code= should be up to the AS=E2=80=99s policy. If Steve gives me a bearer artifa= ct that isn=E2=80=99t attached to anything that identifies me, then it=E2= =80=99s easy for me to share because the artifact is the identity and proof= all in one. The strawman description below sounds like that. But it=E2=80= =99s important in this design that the AS can also require me to log in wit= h a specific account, plus present a token, plus type in a secret code, plu= s present a hardware key that completes a circuit in the right way (seems l= ike something Steve would build, tbh), etc. But all of these aren=E2=80=99t= a client talking to a resource, they=E2=80=99re the end-user =C2=A0present= ing things to the AS so that the AS can make a policy decision to issue a t= oken and allow access.=C2=A0

    =C2=A0=E2= =80=94 Justin

    On Mar 18, 2021, a= t 8:23 PM, Alejandro Iacobelli <aiacobelli.sec@gmail.com> wrote:

    The decision about "opaque" v= s "sealed but recoverable" or "signed" access_token goe= s way back on the stateless protocols session management.=C2=A0

    In my opinion, the software design principle tha= t we must apply here is the "need to know" principle. This means,= the=C2=A0less information an attacker could get, the better. One thing tha= t JWS explse is all the context information about a token, so an attacker= =C2=A0can get lots of information just with a look.=C2=A0

    The next discussion will be what ways of generating opaque tokens a= re there and which must we choose (Encrypted vs CSPRNG based).
    <= br>
    On Thu,= 18 Mar 2021 at 21:17, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Adrian,

    I'm really not sure I understand here.=C2=A0

    I get the idea of putting a polic= y engine in front of your services to implement ZTA. But I'm not sure I= get this way of framing things. It blurs functional roles and actual servi= ces, and most importantly if everything gets its own AS, it also gets by tr= ansitivity its RO'/RQ' (and then its AS-RO' etc) and so the com= plexity becomes staggering.=C2=A0
    Why do we need tha= t?=C2=A0

    Fabien=C2=A0

    Le ven. 19 mars 2021 =C3=A0 00:55, Adrian Gropper <agropper@healthurl.com&= gt; a =C3=A9crit=C2=A0:
    +1 This aligns with my healthcare use-case to the extent that Just= in can transfer the capability granted by that QR code to Adrian who happen= s to be nearby Steve's house.

    I've tried to = capture some of this in my comment to #145=C2=A0https://github.com/ietf-wg-gnap/gnap-core= -protocol/issues/145#issuecomment-802388458

    - = Adrian

    On Thu, Mar 18, 2021 at 2:39 PM Justin Richer <jricher@mi= t.edu> wrote:
    Right, and in the GNAP = model this becomes something my client instance presents to the AS when I s= how up. The AS can validate my presentation of this item and give my client= instance a token to call Steve=E2=80=99s RS. Or if you wanted to get super= fancy Steve=E2=80=99s AS could even challenge my client instance and get a= cryptographic response to prove I have the thing Steve had me scan. But in= both cases it=E2=80=99s part of things that the AS collects in order to cr= eate the access token.

    =C2=A0=E2=80=94 Justin

    On Mar 18, 2021, at 2:26 PM, Stephen = Moore <srmoore@gmail.com> wrote:

    Th= at in my mind works out great... Say I'm logged into my home hub/AS. Ju= stin is over and agrees to cat sit, I pull up my client app, and generate a= QR code that has maybe The AS URI, the HomeHub API URL, and the 'speci= al token to present to AS for a real token'. Justin scans that QR code = with his home controller app, and BAM, he's onboarded as a guest withou= t even logging into my AS or me dealing with his Auth provider.
    -steve<= /div>

    On Thu, Mar 18, 2021 at 2:08 PM Justin Richer <jricher@mit.edu>= wrote:
    I think Steve=E2=80=99s use case giv= es an interesting example of something that I believe Adrian=E2=80=99s been= talking about as well =E2=80=94 delegating to another person.

    We traditionally think of delegation at the AS to mean =E2=80=9Ca di= fferent user account logs in to the AS=E2=80=9D, and it=E2=80=99s important= to know that this does in fact work. But this could just as easily be =E2= =80=9CSteve sends his friend an artifact to present to the AS to get access= =E2=80=9D. This isn=E2=80=99t Steve (or Steve=E2=80=99s client software) ge= tting and sending an access token, this is sending some other set of rights= credential to his friend, or his friend=E2=80=99s software. So then Steve= =E2=80=99s AS can have policy that says =E2=80=9Cwhen I see this rights cre= dential, give an access token for the following attenuated things, because = Steve said so=E2=80=9D. The AS doesn=E2=80=99t even ever need to know who S= teve=E2=80=99s friend is!=C2=A0

    And importantly he= re, we don=E2=80=99t expect Steve=E2=80=99s friend to bring their own AS to= the party. Steve=E2=80=99s RS has no reason to trust his friend=E2=80=99s = AS, let alone his friend=E2=80=99s client. But Steve=E2=80=99s AS is in a p= osition to know more about the rights policies that Steve wants to apply, a= nd so it can use other technologies like VC=E2=80=99s, DIDs, OIDC, or any n= umber of other things to let things go through. This pattern is exactly why= I think we need to think of this in terms of what=E2=80=99s currently call= ed =E2=80=9Cinteraction=E2=80=9D at the AS. It=E2=80=99s not really just ab= out how the end-user interacts, it=E2=80=99s about how the AS gathers all t= he consent and authorization information. I plan to rewrite section 4 to th= at effect.

    =C2=A0=E2=80=94 Justin

    On Mar 18, 2021, at 1:58 PM, Stephen Moore <<= a href=3D"mailto:srmoore@gmail.com" rel=3D"noreferrer" target=3D"_blank">sr= moore@gmail.com> wrote:

    I'm havin= g some concerns with the way you're flipping the trust here Denis. You = seem to indicate that the user has trust in the RS and the Client and has t= o gain the trust of the AS. I feel like the least trustworthy portion of th= e architecture is the client, because that seems like it is the most interc= hangeable component.
    =C2=A0Let me explain by way of a use case I have i= n mind.
    Let's say I have a smart home. I have devices and dat= a storage and rule engines that are parts of sensors and hubs I buy for the= house. I have a trust in those devices, because it's hardware, if the = company is leaking data at the hardware level there isn't much I can do= other than buy different sensors.
    In this case, the primary home= hub, which is under control of the homeowner, would also be the AS, as wel= l as a policy agent.=C2=A0 Authentication in the example is outsourced to w= hatever auth providers you want. I set up my home using a google account, a= friend is staying and wants access and uses FB for auth... whatever.
    =
    The part that I have little control over is the client my friend uses = on his phone. Or if I change the client on the tablet in the kitchen to try= out something new. These pieces=C2=A0might be single page web apps, they m= ight be downloaded apps, etc. I do not want them having any additional info= rmation than is necessary. If I give my friend permission to unlock the doo= r, and control the lights because they are feeding my cats while I'm aw= ay, the client doesn't need to know anything beyond, I see this home co= ntroller, and I have access to these lights and that door lock.
    <= br>
    In your scenarios, the client is spy by design, and if it is = a web app, I don't trust them to not grab my user email address from th= e=C2=A0AS and put it on a mailing list it sells to some sketchy company,=C2= =A0when the only other component=C2=A0that needs that information is the RS= .

    -steve

    On Thu, Mar 18, 2021 at 1:21 PM Deni= s <denis.ietf@free.fr> wrote:
    I have changed the title of this thread, since the original topic has= been closed.=C2=A0

    Justin, you a= re raising the following question:
    The question I hav= e is =E2=80=94 why does the client need to know what=E2=80=99s in the token= ?=C2=A0
    Not if they could possibly know, but why would we e= xpect a client to know and manage the contents of the token?=C2=A0
    The answer is quite simple: so that the end= -user may have confidence into the architecture.=C2=A0
    The seventh of the eleven privacy principles from ISO 29100 (page 14= ) is:
    7. Openness, transparency and notice= =C2=A0
    If the access token is conside= red as a black box for the end-user, it cannot be confident about the conte= nt of the access token.
    Such access token may disclose some private info= rmation without the consent of the end-user. If the access token that it ha= s obtained=C2=A0
    does not match with what has been requeste= d, the client will first not forward the access token to the RS and then wi= ll complain about the AS.

    Denis


    Hi Justin,=C2=A0
    "The access token is fundamentally a conversational ar= tifact between the AS and the RS which the client is the carrier of."<= /div>
    That's right,=C2=A0and a good=C2=A0opportunity to distinguish= between the need for token=C2=A0inspection (i.e. a runtime verification, w= herever that may be)=C2=A0
    and the need to negotiate the to= ken format (a discovery). That last part could very well be an extension, a= s a way to open up the ecosystem=C2=A0
    beyond JWTs (which a= re fine, but come with their own limitations).=C2=A0

    Fabien

    On Thu, Mar 18, 2021 at 5:59 PM Justin Richer <jricher@mi= t.edu> wrote:
    On Mar 18, 2021, at 11:= 30 AM, Alan Karp <alanhkarp@gmail.com> wrote:

    Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 12:08 AM, Alan Karp <alanhk= arp@gmail.com> wrote:

    Adrian= Gropper <agropper@healthurl.com> wrote:

    Is there an AS involved in the d= elegation? How and where in the lifecycle=C2=A0of the protected resource?= =C2=A0

    If tokens are certificat= es, the AS need not be involved in subsequent delegations.=C2=A0 The AS mus= t be involved if the tokens are opaque.=C2=A0

    Tokens are opaque to the client instance. They a= re not opaque to the AS. They might be opaque to the RS, but that depends o= n the kind of relationship the RS and AS have. GNAP should allow different = options here as there are different use cases for that.

    Tokens are not opaque to th= e client in SPKI, zcap-ld, Orie's implementation with VCs, or our Zebra= Copy work.=C2=A0 Why must they be in GNAP?

    The existence of the AS is exactly the reaso= n for this. The AS is the role that =E2=80=9Cknowledge about the token cont= ents=E2=80=9D has been outsourced to in the GNAP model (which is based on t= he OAuth model).

    It brings significant simplicity = for the client developer. The question I have is =E2=80=94 why does the cli= ent need to know what=E2=80=99s in the token? Not if they could possibly kn= ow, but why would we expect a client to know and manage the contents of the= token?=C2=A0

    The access token is fundamentally a = conversational artifact between the AS and the RS which the client is the c= arrier of. The client is not the audience of the token, nor the creator of = the token, nor even the manager of the token and the rights it represents. = The client as a simple carrier is a powerful model that allows the security= layer to get out of the way of the actual application logic that developer= s want to do.

    =C2=A0=E2=80=94 Justin


    --------------
    Alan Karp


    On Thu, Mar 18, 202= 1 at 4:56 AM Justin Richer <jricher@mit.edu> wrote:
    On Mar 18, 2021, at 12:08 AM, Alan Karp <alanhkarp@gmail= .com> wrote:

    Adrian Gropper = <agropper@healthurl.com> wrote:

    Is there an AS involved in the delegation= ? How and where in the lifecycle=C2=A0of the protected resource?=C2=A0

    If tokens are certificates, the AS = need not be involved in subsequent delegations.=C2=A0 The AS must be involv= ed if the tokens are opaque.=C2=A0

    Tokens are opaque to the client instance. They are not opaq= ue to the AS. They might be opaque to the RS, but that depends on the kind = of relationship the RS and AS have. GNAP should allow different options her= e as there are different use cases for that.

    It wo= uld probably be worthwhile to separate the portions of the spec that talk a= bout the RS-AS relationship into its own standalone document. A similar app= roach was taken in UMA2 and it was helpful. (Though admittedly, as with any= thing, there are missteps there that we can hopefully learn from.)

    =C2=A0=E2=80=94 Justin

    =

    --------------
    Alan Karp


    On Wed, Mar 17, 2021 at 8:54 PM= Adrian Gropper <agropper@healthurl.com> wrote:
    Sure!=C2=A0

    Is there an AS= involved in the delegation? How and where in the lifecycle=C2=A0of the pro= tected resource?=C2=A0

    Also your use of "the client= " seems to imply that either there is only one client or the client do= esn't matter. Which is it?

    Adrian
    <= /div>
    O= n Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault <fabien.imbault@gma= il.com> wrote:
    Than= ks for that.=C2=A0

    Tryin= g to reframe it:
    GNAP is defined as a delegation pro= tocol so the main intent is related to a delegate of the RO (i.e. the end u= ser) that wishes to access the RO's protected resources, through the cl= ient.=C2=A0

    Fabien=C2=A0

    Le jeu. 18 ma= rs 2021 =C3=A0 04:29, Adrian Gropper <agropper@healthurl.com>= a =C3=A9crit=C2=A0:
    At various = points in the lifecycle=C2=A0of the protected resource the client at the re= source server (RS) might be:
    • The RO (subject) user agent tradin= g payment for a service promise
    • The RO user agent using the promise= to access the protected resource
    • A delegate of the RO user agent u= sing a different client
    What's vague is where the GNAP AS= enters the picture as described above. How would you describe it?

    Adrian


    On Wed, Mar 17, 2021 at 1= 0:20 PM Fabien Imbault <fabien.imbault@gmail.com&g= t; wrote:
    Hi Adrian

    I'm still confused why you're say= ing the terminology is vague.=C2=A0
    I get the "= power" neutrality is not to your liking, but RQ / user agent is no bet= ter in my view.=C2=A0

    Ca= n you elaborate?=C2=A0

    F= abien=C2=A0

    Le jeu. 18 mars 2021 =C3=A0 00:18, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    I'm sure you're right. Our vague ter= minology=C2=A0around client=C2=A0and=C2=A0end-user leads to my confusion. I= f GNAP is primarily about delegation=C2=A0then, of course, we should=C2=A0a= void any incentives to impersonate or we're wasting our time. This is p= artly why I'm trying to study up on capabilities and asking for expert = advice from folks like Alan Karp and Mark Miller (cc'd)

    <= div>As best I can understand it, the RS has only two choices, it can:
    =
    • store an attribute of the RO a [DID, email address, GNAP AS UR= L], or
    • hand the RO a capability as a sort-of promise and avoid maki= ng any entries in an ACL or equivalent.
    When a token comes ba= ck to the RS, it will either be:
    • validated according to s= omething associated with the stored RO attribute, or
    • signed by = the RS itself.
    Either way, trust in the client seems moot.

    Adrian



    On Wed, Mar 17, 2021 at 5:29 PM Justin Richer <jric= her@mit.edu> wrote:
    On Mar 17, 2021, = at 4:55 PM, Adrian Gropper <agropper@healthurl= .com> wrote:

    On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <tobias.looker@mattr.global> wrote:
    <sn= ip>
    > A client might not have a DID but it could have a VC = as a certificate of authenticity linked to some audit mechanism.
    =
    To me a VC would come under the assertions umbrella (that is= to say a VC could be one type of valid assertion). The client may possess = or been presented with a VC that it could include in its request to the AS = as a way to identify the subject and perhaps prove authentication and autho= rization.

    I do not assume that = the client that interacts with the AS to make a request and receive a token= is the same as the client that will present the token to the RS. In the US= HIPAA use-case, for example, the root of trust is a contract between the p= atient-subject and the doctor-requesting party but the doctor workflow is e= xpected to delegate the token to some other end-user that may be using a to= tally different client such as an EHR.


    If the client that gets the token is not same= as the client that uses the token, that is a violation of core security pr= inciples as it allows for (and really designs for) impersonation by client = software. I would have no reason to trust client software that would hand i= ts credentials over to another piece of software, and in fact I shouldn=E2= =80=99t trust it.=C2=A0

    I think you may be conflat= ing several different kinds of parties under the =E2=80=9Cclient=E2=80=9D u= mbrella here, though. It=E2=80=99s entirely possible that one client might = call an RS that in turn acts as a client for something else down stream. Bu= t each of those hops is different from the last.

    = =C2=A0=E2=80=94 Justin


    <= /div>



    --=C2=A0
    TXAuth mail= ing list
    TXAuth@ietf.org
    https://www.i= etf.org/mailman/listinfo/txauth
    --=C2=A0
    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=
    --=C2=A0
    TXAuth mailing list
    TXAuth@= ietf.org
    https://www.ietf.org/mailman/= listinfo/txauth
    --=C2=A0
    TXAuth m= ailing list
    TXAuth@= ietf.org
    https://www.ietf.org/mailman/listinfo/tx= auth


    --=C2= =A0
    You know nothing Jon Snow!<= /div>

    --=C2=A0
    Yo= u know nothing Jon Snow!



    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --000000000000fd9eed05bde7cf6b-- From nobody Fri Mar 19 22:08:00 2021 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 3D0C63A1A5E for ; Fri, 19 Mar 2021 22:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 V9Xth9xTxehN for ; Fri, 19 Mar 2021 22:07:56 -0700 (PDT) Received: from mail-ua1-f53.google.com (mail-ua1-f53.google.com [209.85.222.53]) (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 329FB3A1A5D for ; Fri, 19 Mar 2021 22:07:55 -0700 (PDT) Received: by mail-ua1-f53.google.com with SMTP id c13so3703778uao.10 for ; Fri, 19 Mar 2021 22:07:55 -0700 (PDT) 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=jdDfqa1s6nihxHnU/TdGnK8I6UM4t3vFh/qVD1afxP8=; b=uVuKL8f+sj0yzO24vJuiWmv7qO7AL1TqYVQSoKUhkLryOi/1sckQ8Dta+9mccli025 gKGZvJXO8GzY3xvLAQ/Bk3UV/lODUflhPvVaY0A6jbW41JwLqESOs9Jp8eJrTUeY+Cwt 0iL53vh8boyF7MsSP/9zgTp6uxXZtSx+rTFubNEd7aXxvNtqK68qr1J3HF7RCpVaKAyi wDrDbUrPPUtp9A4mDKQc2vSjDiuIOV2Ahjrzumo2KvXtbXuQt/exNTqHkT1PK2HogqPM JJf/w/9aAbtIG9kew+iGgwChUeLzMwBDewC6wpKKq3riiqMTzHj4+riY44yPnSm60yAB cuZw== X-Gm-Message-State: AOAM532Oc4u/+env34hy9viJrDb1m9cLUdSdg1nAKHu6xBmq6uMZzcmE kkdVfyFst4UNWbi1FiPgttxYBH1L+19yhKrcd1qsoXf9MrqB9Q== X-Google-Smtp-Source: ABdhPJwCkY/s5GcghjRzPZDpmuYi92qcMO6kjlMj1ouF5u+2heyknyp4+09+Ok/mfBgN04JTVsfY8a5DUSoc9cccKGU= X-Received: by 2002:a9f:280a:: with SMTP id c10mr903121uac.7.1616216873997; Fri, 19 Mar 2021 22:07:53 -0700 (PDT) MIME-Version: 1.0 From: Adrian Gropper Date: Sat, 20 Mar 2021 01:07:42 -0400 Message-ID: To: GNAP Mailing List , Alan Karp , Mark Miller Content-Type: multipart/alternative; boundary="000000000000a79b6705bdf0d035" Archived-At: Subject: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2021 05:07:58 -0000 --000000000000a79b6705bdf0d035 Content-Type: text/plain; charset="UTF-8" @Alan Karp shared a talk about the Principle Of Least Authority (POLA) in a recent comment https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-803099693 I recommend it. We might expect a protocol with authorization in the title to use authority as a core principle. I advocate for a GNAP design that maximizes the power of the RO, to be seen as a human rights issue when the RO is a human. This causes me to ask how to combine better security with better human rights in GNAP. Who should have the least authority in the GNAP design? The AS derives authority as a delegate of the RO. If we ask the RO to partition limited authority across dozens of different ASs by domain and function, then we are not using technology to empower the individual. Probably the opposite, as we introduce consent fatigue and burden normal people to partition their lives into non-overlapping domains. My experience says we should aim for one AS per persona because that maps into the way we manage our public and private identities. POLA would then teach care in keeping ASs and RSs related to work / public separate from ASs and RSs related to private life so that a policy vulnerability in our delegation to an AS would have the least likelihood of harm. Beyond that fairly obvious principle, we could spread our interactions among as many services as possible. We already do this when we spread assets across multiple banks, internet services across redundant platforms, or we use LinkedIn, Twitter, and Facebook with limited overlap in social graphs. At the next level down, we want to manage resources at each RS using least authority in order to make AS policy vulnerabilities easier to spot and debug. My AS might get multiple capabilities or access to scopes from an RS, each one carefully labeled with its intended uses so that the policy engine of my AS could be structured to consider requests relative to only one capability or scope family at a time. For example, in issuing health record authorizations, I might separate the behavioral health capabilities from capabilities to access the physical parts of my record at a given hospital's GNAP RS API. Lastly, at the level of attenuation, I would choose a relationship with RSs that issue to me capabilities that can be attenuated not only by my AS but also by the requesting parties that receive them as part of an access token. Adrian --000000000000a79b6705bdf0d035 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    @Alan Karp=C2=A0shared a talk about the Principle Of Least A= uthority (POLA) in a recent comment=C2=A0https://gith= ub.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-803099693 I recommend it.

    We might expect = a protocol with authorization in the title to use authority as a core princ= iple. I advocate for a GNAP design that maximizes the power of the RO, to b= e seen as a human rights=C2=A0issue when the RO is a human. This causes me = to ask how to combine better security with better human rights in GNAP.

    Who should have the least authority in the GNAP desig= n?

    The AS derives authority as a delegate of the R= O. If we ask the RO to partition limited authority across dozens of differe= nt ASs by domain and function, then we are not using technology to empower = the individual. Probably the opposite, as we introduce consent fatigue and = burden normal people to partition their lives into non-overlapping domains.= =C2=A0

    My experience says we should aim for one AS= per persona because that maps into the way we manage our public and privat= e identities. POLA would then teach care in keeping ASs and RSs related to = work / public separate from ASs and RSs related to private=C2=A0life so tha= t a policy vulnerability in our delegation to an AS would have the least li= kelihood=C2=A0of harm.

    Beyond that fairly obvious = principle, we could spread our interactions among as many services as possi= ble. We already do this when we spread assets across multiple banks, intern= et services across redundant platforms, or we use LinkedIn, Twitter, and Fa= cebook with limited overlap in social graphs.

    At t= he next level down, we want to manage resources at each RS using least auth= ority in order to make AS policy vulnerabilities easier to spot and debug. = My AS might get multiple capabilities or access to scopes from an RS, each = one carefully labeled with its intended uses so that the policy engine of m= y AS could be structured to consider requests relative to only one capabili= ty or scope family at a time. For example, in issuing health record authori= zations, I might separate the behavioral health capabilities from capabilit= ies to access the physical parts of my record at a given hospital's GNA= P RS API.

    Lastly, at the level of attenuation, I w= ould choose a relationship with RSs that issue to me capabilities that can = be attenuated not only by my AS but also by the requesting parties that rec= eive them as part of an access token.

    Adrian
    =


    --000000000000a79b6705bdf0d035-- From nobody Sat Mar 20 01:23:32 2021 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 2B3873A1D79 for ; Sat, 20 Mar 2021 01:23:31 -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 7dLLoEw5m8mq for ; Sat, 20 Mar 2021 01:23:29 -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 426753A1D74 for ; Sat, 20 Mar 2021 01:23:29 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id h1so10179080ilr.1 for ; Sat, 20 Mar 2021 01:23: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=JmoXcq1g1J8HzITtTcemBfHNgDKQO+yPTq4iM432Sd8=; b=Wz2IDru6fNdp2+Av/yuXgLG3kR6u7oM117McpBp7OO+jZSg/qoprEF1S0mantGoanR p7jOkXdLc8bCakPataZ0D4sqWqFF5m9qmjWyeaPpmoyfMF0yOIUeeTy8wshhIFK0B29s Ab3yP0KXKg4tTsuB3fPfGzEvA7dbirkfmKROJJdQWIyzKyLEbjXFrHu4plQG6ctVnR+l +SHF2mStaMDpw9sFTwI7wpJsUp/xJBqWURLuXU4iqNa6HAyntXmyUYSS1KSej4NPUS2F 6Y+t6tsckSGkvOIpmSztC5r7OZNAZRH5EqNTs8nD952SSMGv+sLx0elHTBfzpCabH9D1 fiCQ== 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=JmoXcq1g1J8HzITtTcemBfHNgDKQO+yPTq4iM432Sd8=; b=Vzw4DGiQ6ryLwCEYp22wagy53mtMMemKXiih7EBalae3Xs21XN2dDOtmzNuaDpQoRD lMzPzjEMMrPqCS3YbEyeDkDeNsyS33i9AtT/tMHBCAu8W6J19D2QUorEDfga1+O++rG9 +tx6ej2fbta6AGUkgCt451wQlxaiSxHZZqlYwPqn3H4fFj8B+nw0jRZ6x0wQr3Hj3ITD E2RjOI/m6Gz/4C9qpl5IcmnBxfBEwg6dRZS/c8sPwrP6AhasqT2yw4OB0XZr1ZcLQtb7 ywga/TLywkm42RILUMGMhUL7QrPx5n00xBvy1cfcmfKhe47Qceynk8SITI6zKTfmtjrr UXLw== X-Gm-Message-State: AOAM533ZWn6Dy78j3fLykpIC1tD9yIeojTBuqJGypxhXg4AuCD/0stT8 owb71+jHIN1UDkl7/HSyFdy84VMWaBZxClbezp0= X-Google-Smtp-Source: ABdhPJxz8yQXcYmxrZvywR/4OYwoZsJELY48pDQifKL9TCFFQFIN8X43ryPoQ1JjQKYa6MlSMfcF9FmQXcVCLNpu5HI= X-Received: by 2002:a92:1a11:: with SMTP id a17mr5690984ila.188.1616228607267; Sat, 20 Mar 2021 01:23:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Sat, 20 Mar 2021 09:23:14 +0100 Message-ID: To: Adrian Gropper Cc: GNAP Mailing List , Alan Karp , Mark Miller Content-Type: multipart/alternative; boundary="0000000000000317af05bdf38c61" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2021 08:23:31 -0000 --0000000000000317af05bdf38c61 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Adrian, Calling to one AS per persona can only be optional, as we have no way, and no wish, of knowing all the identities used by the RO. I think this relates to the idea of the RO having its own distinct agent, but I still don't understand how that would work (even re-reading the thread in issue 145). Could you elaborate? Thxs Fabien Le sam. 20 mars 2021 =C3=A0 06:08, Adrian Gropper = a =C3=A9crit : > @Alan Karp shared a talk about the Principle Of > Least Authority (POLA) in a recent comment > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecommen= t-803099693 > I recommend it. > > We might expect a protocol with authorization in the title to use > authority as a core principle. I advocate for a GNAP design that maximize= s > the power of the RO, to be seen as a human rights issue when the RO is a > human. This causes me to ask how to combine better security with better > human rights in GNAP. > > Who should have the least authority in the GNAP design? > > The AS derives authority as a delegate of the RO. If we ask the RO to > partition limited authority across dozens of different ASs by domain and > function, then we are not using technology to empower the individual. > Probably the opposite, as we introduce consent fatigue and burden normal > people to partition their lives into non-overlapping domains. > > My experience says we should aim for one AS per persona because that maps > into the way we manage our public and private identities. POLA would then > teach care in keeping ASs and RSs related to work / public separate from > ASs and RSs related to private life so that a policy vulnerability in our > delegation to an AS would have the least likelihood of harm. > > Beyond that fairly obvious principle, we could spread our interactions > among as many services as possible. We already do this when we spread > assets across multiple banks, internet services across redundant platform= s, > or we use LinkedIn, Twitter, and Facebook with limited overlap in social > graphs. > > At the next level down, we want to manage resources at each RS using leas= t > authority in order to make AS policy vulnerabilities easier to spot and > debug. My AS might get multiple capabilities or access to scopes from an > RS, each one carefully labeled with its intended uses so that the policy > engine of my AS could be structured to consider requests relative to only > one capability or scope family at a time. For example, in issuing health > record authorizations, I might separate the behavioral health capabilitie= s > from capabilities to access the physical parts of my record at a given > hospital's GNAP RS API. > > Lastly, at the level of attenuation, I would choose a relationship with > RSs that issue to me capabilities that can be attenuated not only by my A= S > but also by the requesting parties that receive them as part of an access > token. > > Adrian > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000000317af05bdf38c61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Adrian,=C2=A0

    Calling to one AS per persona can only be opti= onal, as we have no way, and no wish, of knowing all the identities used by= the RO.=C2=A0

    I think t= his relates to the idea of the RO having its own distinct agent, but I stil= l don't understand how that would work (even re-reading the thread in i= ssue 145). Could you elaborate?=C2=A0

    Thxs
    Fabien=C2=A0


    Le s= am. 20 mars 2021 =C3=A0 06:08, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    @Alan Karp=C2=A0shared a talk about the Principle Of Least = Authority (POLA) in a recent comment=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protoco= l/issues/145#issuecomment-803099693 I recommend it.

    We might expect a protocol with authorization in th= e title to use authority as a core principle. I advocate for a GNAP design = that maximizes the power of the RO, to be seen as a human rights=C2=A0issue= when the RO is a human. This causes me to ask how to combine better securi= ty with better human rights in GNAP.

    Who should ha= ve the least authority in the GNAP design?

    The AS = derives authority as a delegate of the RO. If we ask the RO to partition li= mited authority across dozens of different ASs by domain and function, then= we are not using technology to empower the individual. Probably the opposi= te, as we introduce consent fatigue and burden normal people to partition t= heir lives into non-overlapping domains.=C2=A0

    My = experience says we should aim for one AS per persona because that maps into= the way we manage our public and private identities. POLA would then teach= care in keeping ASs and RSs related to work / public separate from ASs and= RSs related to private=C2=A0life so that a policy vulnerability in our del= egation to an AS would have the least likelihood=C2=A0of harm.
    Beyond that fairly obvious principle, we could spread our inte= ractions among as many services as possible. We already do this when we spr= ead assets across multiple banks, internet services across redundant platfo= rms, or we use LinkedIn, Twitter, and Facebook with limited overlap in soci= al graphs.

    At the next level down, we want to mana= ge resources at each RS using least authority in order to make AS policy vu= lnerabilities easier to spot and debug. My AS might get multiple capabiliti= es or access to scopes from an RS, each one carefully labeled with its inte= nded uses so that the policy engine of my AS could be structured to conside= r requests relative to only one capability or scope family at a time. For e= xample, in issuing health record authorizations, I might separate the behav= ioral health capabilities from capabilities to access the physical parts of= my record at a given hospital's GNAP RS API.

    = Lastly, at the level of attenuation, I would choose a relationship with RSs= that issue to me capabilities that can be attenuated not only by my AS but= also by the requesting parties that receive them as part of an access toke= n.

    Adrian


    --
    TXAuth mailing list
    TXA= uth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= /a>
    --0000000000000317af05bdf38c61-- From nobody Sat Mar 20 02:49:44 2021 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 D294F3A1EB3 for ; Sat, 20 Mar 2021 02:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 NRefAzdjZrer for ; Sat, 20 Mar 2021 02:49:38 -0700 (PDT) Received: from mail-vk1-f173.google.com (mail-vk1-f173.google.com [209.85.221.173]) (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 9E2863A1EB4 for ; Sat, 20 Mar 2021 02:49:38 -0700 (PDT) Received: by mail-vk1-f173.google.com with SMTP id j15so2673164vkc.1 for ; Sat, 20 Mar 2021 02:49:38 -0700 (PDT) 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=ywy/n5Oo0OSfdi2iivrF0D7zGNE2cGnZUxb0qg1Qz1c=; b=uagDryNE8LAYhfpFVlsSYIqS5ugHtVKKwwIdZC2Z7za6XB/lbnsdLc4t5zmhBNeOcv iAgNB5eyb0qIadymzMBV1hFhTO7vQn/CY6APV8XktP3WBPsgBLSIFZ+5OQ0F5zT8HeOC HvfGmujREYz++KGqQwTaZLst4lVOAk3Lee9AhFNChTLveX9GhT4pfCUTMW/52gpM5cqg qr7svmPnMMDxXFb2PWKC6yBPoWUQw1CKkoCYp3I1ngC7VNAtIgCg40YxGPbxYnWSQ+/u tWOjty1rxa4ziUghJYMhdHqKVxs50YzxCl+ThN4NmjJUlzNUlS1HLkSXVwvCTS71mvlj v/hQ== X-Gm-Message-State: AOAM532DzzMsXjMCJrHXx7S/Fm9K2Yqm44ZVCShVIPQiy4WSpYwFSZMw d5xO53rANiGuq9X0nmMCegHiVF9ROXAFZ4gdZb0= X-Google-Smtp-Source: ABdhPJxdtiHySS07JmzUaHabXAR2VjF7fGSXp0eRLW7K96iQC7Q+3PdLoyOgSvy61E6O4KeqVa1is4+Clc5adn/kxFs= X-Received: by 2002:a1f:914c:: with SMTP id t73mr4901582vkd.7.1616233777304; Sat, 20 Mar 2021 02:49:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Adrian Gropper Date: Sat, 20 Mar 2021 05:49:25 -0400 Message-ID: To: Fabien Imbault Cc: Alan Karp , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="0000000000002b997305bdf4c0c7" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2021 09:49:41 -0000 --0000000000002b997305bdf4c0c7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Fabien, Yes, it=E2=80=99s optional and adding meaningful options is one way to cons= ider the ethical imperative http://www.cybsoc.org/heinz.htm If I understand Alan=E2=80=99s teachings, the RS has the option to either i= ssue one or more capabilities to the RO or to store some identity-related information about the RO such as the DID of the RO and, by reference, the AS service endpoint controlled by that DID. Given some capabilities, the RO can either deal with them manually or hand them to an AS. Either way, the RS has no idea of the RO=E2=80=99s choice un= til it receives a token from some end user. This seems to be what the Letters of Transit in Casablanca were all about. If, on the other hand, the RO chooses to give 5e RS a DID, a self-sovereign identifier, instead of taking some capabilities, then the RS has the expectation to trust tokens signed by that DID. It=E2=80=99s my hope that GNAP can allow an ethical RS to offer both choice= s to the RO. Adrian On Sat, Mar 20, 2021 at 4:23 AM Fabien Imbault wrote: > Hi Adrian, > > Calling to one AS per persona can only be optional, as we have no way, an= d > no wish, of knowing all the identities used by the RO. > > I think this relates to the idea of the RO having its own distinct agent, > but I still don't understand how that would work (even re-reading the > thread in issue 145). Could you elaborate? > > Thxs > Fabien > > > Le sam. 20 mars 2021 =C3=A0 06:08, Adrian Gropper a > =C3=A9crit : > >> @Alan Karp shared a talk about the Principle Of >> Least Authority (POLA) in a recent comment >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomme= nt-803099693 >> I recommend it. >> >> We might expect a protocol with authorization in the title to use >> authority as a core principle. I advocate for a GNAP design that maximiz= es >> the power of the RO, to be seen as a human rights issue when the RO is a >> human. This causes me to ask how to combine better security with better >> human rights in GNAP. >> >> Who should have the least authority in the GNAP design? >> >> The AS derives authority as a delegate of the RO. If we ask the RO to >> partition limited authority across dozens of different ASs by domain and >> function, then we are not using technology to empower the individual. >> Probably the opposite, as we introduce consent fatigue and burden normal >> people to partition their lives into non-overlapping domains. >> >> My experience says we should aim for one AS per persona because that map= s >> into the way we manage our public and private identities. POLA would the= n >> teach care in keeping ASs and RSs related to work / public separate from >> ASs and RSs related to private life so that a policy vulnerability in ou= r >> delegation to an AS would have the least likelihood of harm. >> >> Beyond that fairly obvious principle, we could spread our interactions >> among as many services as possible. We already do this when we spread >> assets across multiple banks, internet services across redundant platfor= ms, >> or we use LinkedIn, Twitter, and Facebook with limited overlap in social >> graphs. >> >> At the next level down, we want to manage resources at each RS using >> least authority in order to make AS policy vulnerabilities easier to spo= t >> and debug. My AS might get multiple capabilities or access to scopes fro= m >> an RS, each one carefully labeled with its intended uses so that the pol= icy >> engine of my AS could be structured to consider requests relative to onl= y >> one capability or scope family at a time. For example, in issuing health >> record authorizations, I might separate the behavioral health capabiliti= es >> from capabilities to access the physical parts of my record at a given >> hospital's GNAP RS API. >> >> Lastly, at the level of attenuation, I would choose a relationship with >> RSs that issue to me capabilities that can be attenuated not only by my = AS >> but also by the requesting parties that receive them as part of an acces= s >> token. >> >> Adrian >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --0000000000002b997305bdf4c0c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Fabien,

    If I understand Alan=E2=80=99s teaching= s, the RS has the option to either issue one or more capabilities to the RO= or to store some identity-related information about the RO such as the DID= of the RO and, by reference, the AS service endpoint controlled by that DI= D.

    Given some capabiliti= es, the RO can either deal with them manually or hand them to an AS. Either= way, the RS has no idea of the RO=E2=80=99s choice until it receives a tok= en from some end user. This seems to be what the Letters of Transit in Casa= blanca were all about.=C2=A0

    If, on the other hand, the RO chooses to give 5e RS a DID, a self-sove= reign identifier, instead of taking some capabilities, then the RS has the = expectation =C2=A0to trust tokens signed by that DID.=C2=A0

    It=E2=80=99s my hope that GNAP can al= low an ethical RS to offer both choices to the RO.
    <= br>
    Adrian

    On Sat, M= ar 20, 2021 at 4:23 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Adrian,=C2=A0

    Calling to one AS per pers= ona can only be optional, as we have no way, and no wish, of knowing all th= e identities used by the RO.=C2=A0

    I think this relates to the idea of the RO having its own distin= ct agent, but I still don't understand how that would work (even re-rea= ding the thread in issue 145). Could you elaborate?=C2=A0

    Thxs
    Fabien=C2=A0<= /div>

    Le sam. 20 mars 2021 =C3=A0 06:08, Adrian Gropper <agropper@healthurl.com= > a =C3=A9crit=C2=A0:
    @Alan Karp=C2=A0shared a talk about the Principle Of Least Authority= (POLA) in a recent comment=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/= 145#issuecomment-803099693 I recommend it.
    We might expect a protocol with authorization in the title to = use authority as a core principle. I advocate for a GNAP design that maximi= zes the power of the RO, to be seen as a human rights=C2=A0issue when the R= O is a human. This causes me to ask how to combine better security with bet= ter human rights in GNAP.

    Who should have the leas= t authority in the GNAP design?

    The AS derives aut= hority as a delegate of the RO. If we ask the RO to partition limited autho= rity across dozens of different ASs by domain and function, then we are not= using technology to empower the individual. Probably the opposite, as we i= ntroduce consent fatigue and burden normal people to partition their lives = into non-overlapping domains.=C2=A0

    My experience = says we should aim for one AS per persona because that maps into the way we= manage our public and private identities. POLA would then teach care in ke= eping ASs and RSs related to work / public separate from ASs and RSs relate= d to private=C2=A0life so that a policy vulnerability in our delegation to = an AS would have the least likelihood=C2=A0of harm.

    Beyond that fairly obvious principle, we could spread our interactions am= ong as many services as possible. We already do this when we spread assets = across multiple banks, internet services across redundant platforms, or we = use LinkedIn, Twitter, and Facebook with limited overlap in social graphs.<= /div>

    At the next level down, we want to manage resource= s at each RS using least authority in order to make AS policy vulnerabiliti= es easier to spot and debug. My AS might get multiple capabilities or acces= s to scopes from an RS, each one carefully labeled with its intended uses s= o that the policy engine of my AS could be structured to consider requests = relative to only one capability or scope family at a time. For example, in = issuing health record authorizations, I might separate the behavioral healt= h capabilities from capabilities to access the physical parts of my record = at a given hospital's GNAP RS API.

    Lastly, at = the level of attenuation, I would choose a relationship with RSs that issue= to me capabilities that can be attenuated not only by my AS but also by th= e requesting parties that receive them as part of an access token.

    Adrian


    --
    TXAuth mailing list
    TXA= uth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= /a>
    --0000000000002b997305bdf4c0c7-- From nobody Sat Mar 20 03:53:00 2021 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 591E33A1FC0 for ; Sat, 20 Mar 2021 03:52:59 -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 4k4UzTJq3PfS for ; Sat, 20 Mar 2021 03:52:57 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 073E23A1FBF for ; Sat, 20 Mar 2021 03:52:56 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id e8so8808487iok.5 for ; Sat, 20 Mar 2021 03:52: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=R7p1lDjE35Ig9rW+xR8eQUyqp9raUZJY+larhF2Mfw4=; b=ZTPKUfEa06FBFwCqhK+8V7CjfyZMWfY0CvSFupqfta15WqR13HtAFL60uNtnB6dup0 f4d3p5dEt2cJApNmTjthN68HikU/ZHF8tqghHr5/nt1nnGIgb5/8G/pNRr4Bl84zY6JB O8XPh7tu8BCmhaLq9wkBcjFxDtXAWXW5zJRhfbr9oeIIqrWn0dht5N2xdK2iTOFRk7E+ i9cq1dBEk6N0tAP4386cJpXs0uOSQ6VtLEpwBkjH3kZ4w2Fe3IwdRkPEnW1sSUV0R4xw ogDvavw84h8wfjksxI1aJpAU1qIE4X/gcNkLEZQxWsYyFCeUguewL8deRXLklXFZv9bO qJZw== 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=R7p1lDjE35Ig9rW+xR8eQUyqp9raUZJY+larhF2Mfw4=; b=nvMD8y0dMhmwxt4qt8MAwfOFGthoDC0QWOVbwJPJy9is/DjqtRlG4f5ouvFyQXlyUb WndYLJKp3/FUN07+rpgbOgkSVAiuarJ0Mc3AgenfSorsYFVf0xoIJ5risC39WtR97inh KDNP84Axf+PB5FOqFqYDH4FXYC9Quij6CjhBFQfBRULPOC6+WS/27ptbRR4Pblptvgwd tfSsDvISUgpyJWITRWXhCq5ZEPs24lqfyR/WB8D9CD6ZzBcr+I8QiQnNHUVpbLHMrtZK ENCqz6855ggnkzkFrESsug8OSR1Zzy39Gfdf56ycXQaTDTIc+yIlPFeVCnd4AS5eLhGu efuw== X-Gm-Message-State: AOAM532jR4AGxB4l1/cSI1P0opL1Nse8b4+S4a2dBCURV0yUdzTNDxnb ClhIMkelLCM40jKLiZFUAIa8IV2/OxfddzluV+0= X-Google-Smtp-Source: ABdhPJx9e3iztUMvbrpFSVEC00L3v2Jx2qsrUVWUW+Vl25u98jVsU5Rt7BifueGdId1riLoBmMnHZOqHgDStLuIXOP0= X-Received: by 2002:a05:6602:228f:: with SMTP id d15mr5325441iod.141.1616237573796; Sat, 20 Mar 2021 03:52:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Sat, 20 Mar 2021 11:52:40 +0100 Message-ID: To: Adrian Gropper Cc: Alan Karp , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="000000000000757b5505bdf5a2a9" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2021 10:52:59 -0000 --000000000000757b5505bdf5a2a9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the description. Trying to summarize what a capability flow would look like following those ideas: 1) RS issues a capability for the RO. For instance "view and download photo". 2) RO can delegate that capability (or an attenuated version) to the AS. Say "view photo", possibly with some ambient conditions. If the RO further wants to choose between a list of possible ASs, the RO would have to signal its choice to the RS, which would then have to signal it to the client (what we had called RS preflight in some discussions). So the AS-RS relationship would be mediated via the RO (or more precisely its agent). 3) a core GNAP negociation takes place with the AS (traditional photo example). Is that correct? Do not hesitate to correct me if I didn't accurately capture what you said. (I volontarily put DID aside for now) Steps occurring before 3 are optional (for reasons discussed before and also because we can't assume all RSs would be able to support that). Fabien Le sam. 20 mars 2021 =C3=A0 10:49, Adrian Gropper = a =C3=A9crit : > Hi Fabien, > > Yes, it=E2=80=99s optional and adding meaningful options is one way to co= nsider > the ethical imperative http://www.cybsoc.org/heinz.htm > > If I understand Alan=E2=80=99s teachings, the RS has the option to either= issue > one or more capabilities to the RO or to store some identity-related > information about the RO such as the DID of the RO and, by reference, the > AS service endpoint controlled by that DID. > > Given some capabilities, the RO can either deal with them manually or han= d > them to an AS. Either way, the RS has no idea of the RO=E2=80=99s choice = until it > receives a token from some end user. This seems to be what the Letters of > Transit in Casablanca were all about. > > If, on the other hand, the RO chooses to give 5e RS a DID, a > self-sovereign identifier, instead of taking some capabilities, then the = RS > has the expectation to trust tokens signed by that DID. > > It=E2=80=99s my hope that GNAP can allow an ethical RS to offer both choi= ces to > the RO. > > Adrian > > > On Sat, Mar 20, 2021 at 4:23 AM Fabien Imbault > wrote: > >> Hi Adrian, >> >> Calling to one AS per persona can only be optional, as we have no way, >> and no wish, of knowing all the identities used by the RO. >> >> I think this relates to the idea of the RO having its own distinct agent= , >> but I still don't understand how that would work (even re-reading the >> thread in issue 145). Could you elaborate? >> >> Thxs >> Fabien >> >> >> Le sam. 20 mars 2021 =C3=A0 06:08, Adrian Gropper a >> =C3=A9crit : >> >>> @Alan Karp shared a talk about the Principle Of >>> Least Authority (POLA) in a recent comment >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomm= ent-803099693 >>> I recommend it. >>> >>> We might expect a protocol with authorization in the title to use >>> authority as a core principle. I advocate for a GNAP design that maximi= zes >>> the power of the RO, to be seen as a human rights issue when the RO is = a >>> human. This causes me to ask how to combine better security with better >>> human rights in GNAP. >>> >>> Who should have the least authority in the GNAP design? >>> >>> The AS derives authority as a delegate of the RO. If we ask the RO to >>> partition limited authority across dozens of different ASs by domain an= d >>> function, then we are not using technology to empower the individual. >>> Probably the opposite, as we introduce consent fatigue and burden norma= l >>> people to partition their lives into non-overlapping domains. >>> >>> My experience says we should aim for one AS per persona because that >>> maps into the way we manage our public and private identities. POLA wou= ld >>> then teach care in keeping ASs and RSs related to work / public separat= e >>> from ASs and RSs related to private life so that a policy vulnerability= in >>> our delegation to an AS would have the least likelihood of harm. >>> >>> Beyond that fairly obvious principle, we could spread our interactions >>> among as many services as possible. We already do this when we spread >>> assets across multiple banks, internet services across redundant platfo= rms, >>> or we use LinkedIn, Twitter, and Facebook with limited overlap in socia= l >>> graphs. >>> >>> At the next level down, we want to manage resources at each RS using >>> least authority in order to make AS policy vulnerabilities easier to sp= ot >>> and debug. My AS might get multiple capabilities or access to scopes fr= om >>> an RS, each one carefully labeled with its intended uses so that the po= licy >>> engine of my AS could be structured to consider requests relative to on= ly >>> one capability or scope family at a time. For example, in issuing healt= h >>> record authorizations, I might separate the behavioral health capabilit= ies >>> from capabilities to access the physical parts of my record at a given >>> hospital's GNAP RS API. >>> >>> Lastly, at the level of attenuation, I would choose a relationship with >>> RSs that issue to me capabilities that can be attenuated not only by my= AS >>> but also by the requesting parties that receive them as part of an acce= ss >>> token. >>> >>> Adrian >>> >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> --000000000000757b5505bdf5a2a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Thanks for the description.=C2=A0

    Trying to summarize what a capability=C2=A0 flow woul= d look like following those ideas:

    1) RS issues a capability for the RO. For instance "view and down= load photo".=C2=A0

    = 2) RO can delegate that capability (or an attenuated version) to the AS. Sa= y "view photo", possibly with some ambient conditions.=C2=A0
    If the RO further wants to choose between a list of poss= ible ASs, the RO would have to signal its choice to the RS, which would the= n have to signal it to the client (what we had called RS preflight in some = discussions).=C2=A0So the AS-RS rela= tionship would be mediated via the RO (or more precisely its agent).=C2=A0<= /span>

    3) a core GNAP ne= gociation takes place with the AS (traditional photo example).=C2=A0
    <= div dir=3D"auto">
    Is that correct? Do not hesita= te to correct me if I didn't accurately capture what you said.=C2=A0
    (I volontarily put DID aside for now)=C2=A0

    Steps occurring before 3 are optio= nal (for reasons discussed before and also because we can't assume all = RSs would be able to support that).=C2=A0

    =
    Fabien=C2=A0

    Le sam. 20 mars 2021 =C3=A0 10:4= 9, Adrian Gropper <agropper@he= althurl.com> a =C3=A9crit=C2=A0:
    Hi Fabien,

    Yes, it=E2=80=99s optional and adding meaningful options is = one way to consider the ethical imperative http://www.cybsoc.org/hein= z.htm=C2=A0

    If I understand Alan=E2=80=99s teachings, the RS has the option to eithe= r issue one or more capabilities to the RO or to store some identity-relate= d information about the RO such as the DID of the RO and, by reference, the= AS service endpoint controlled by that DID.

    Given some capabilities, the RO can either deal with t= hem manually or hand them to an AS. Either way, the RS has no idea of the R= O=E2=80=99s choice until it receives a token from some end user. This seems= to be what the Letters of Transit in Casablanca were all about.=C2=A0

    If, on the other hand, the R= O chooses to give 5e RS a DID, a self-sovereign identifier, instead of taki= ng some capabilities, then the RS has the expectation =C2=A0to trust tokens= signed by that DID.=C2=A0

    It=E2=80=99s my hope that GNAP can allow an ethical RS to offer both cho= ices to the RO.

    Adrian


    On Sat, Mar 20, 2021 at 4:23 AM Fabien Imbau= lt <fabien.imbault@gmail.com> wrote:
    Hi Adrian,=C2=A0

    Calling to one AS per persona can only be = optional, as we have no way, and no wish, of knowing all the identities use= d by the RO.=C2=A0

    I thi= nk this relates to the idea of the RO having its own distinct agent, but I = still don't understand how that would work (even re-reading the thread = in issue 145). Could you elaborate?=C2=A0

    =
    Thxs
    Fabien=C2=A0


    Le sa= m. 20 mars 2021 =C3=A0 06:08, Adrian Gropper <agropper@healthurl.com= > a =C3=A9crit=C2=A0:
    @Alan Karp=C2=A0shared a talk about= the Principle Of Least Authority (POLA) in a recent comment=C2=A0https://gith= ub.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-803099693 I recommend it.

    We might expect = a protocol with authorization in the title to use authority as a core princ= iple. I advocate for a GNAP design that maximizes the power of the RO, to b= e seen as a human rights=C2=A0issue when the RO is a human. This causes me = to ask how to combine better security with better human rights in GNAP.

    Who should have the least authority in the GNAP desig= n?

    The AS derives authority as a delegate of the R= O. If we ask the RO to partition limited authority across dozens of differe= nt ASs by domain and function, then we are not using technology to empower = the individual. Probably the opposite, as we introduce consent fatigue and = burden normal people to partition their lives into non-overlapping domains.= =C2=A0

    My experience says we should aim for one AS= per persona because that maps into the way we manage our public and privat= e identities. POLA would then teach care in keeping ASs and RSs related to = work / public separate from ASs and RSs related to private=C2=A0life so tha= t a policy vulnerability in our delegation to an AS would have the least li= kelihood=C2=A0of harm.

    Beyond that fairly obvious = principle, we could spread our interactions among as many services as possi= ble. We already do this when we spread assets across multiple banks, intern= et services across redundant platforms, or we use LinkedIn, Twitter, and Fa= cebook with limited overlap in social graphs.

    At t= he next level down, we want to manage resources at each RS using least auth= ority in order to make AS policy vulnerabilities easier to spot and debug. = My AS might get multiple capabilities or access to scopes from an RS, each = one carefully labeled with its intended uses so that the policy engine of m= y AS could be structured to consider requests relative to only one capabili= ty or scope family at a time. For example, in issuing health record authori= zations, I might separate the behavioral health capabilities from capabilit= ies to access the physical parts of my record at a given hospital's GNA= P RS API.

    Lastly, at the level of attenuation, I w= ould choose a relationship with RSs that issue to me capabilities that can = be attenuated not only by my AS but also by the requesting parties that rec= eive them as part of an access token.

    Adrian
    =


    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listi= nfo/txauth
    --000000000000757b5505bdf5a2a9-- From nobody Sat Mar 20 05:03:28 2021 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 669923A20CB for ; Sat, 20 Mar 2021 05:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 eF66oTxt3PVm for ; Sat, 20 Mar 2021 05:03:24 -0700 (PDT) Received: from mail-vk1-f182.google.com (mail-vk1-f182.google.com [209.85.221.182]) (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 7A80F3A20CA for ; Sat, 20 Mar 2021 05:03:24 -0700 (PDT) Received: by mail-vk1-f182.google.com with SMTP id o4so2704930vka.12 for ; Sat, 20 Mar 2021 05:03:24 -0700 (PDT) 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=NkPahGnCyEQBDrnvQwuXTDi24IEhIn3lLPclcOiP1FA=; b=eJ0YRpvz5ntwDcf79veq3WdiGdXqhHercEamuMi2+i6DT36CzLWSwBdlOPb72SC1gn pKvibhIF6/SUM0i+0zmNq+3q7OUcPllnxVNoMZVCyH1a2iLxIe2iIHZ2WKhNWUuKBKAE b1nmseiTQB129ZTyxx+sDPox2e20qHw/FOTBQ8iX/jw2TbQUdN+5OEk2CHtySV9gjBXr +en1GYQkjdjj+VPYc3hZrmFs0cHLuKVfCG+RyAiVokRCLc1/bqmjQMvkrdIrX090DWUb P6jcAQQFGRUzbn5x+hTHsQdzEEPOsTGI1zFTYNsouDX9EjV7ZuheyuUfMLylyq8PENwK OExQ== X-Gm-Message-State: AOAM533fI0tCqsgU95+CmFdgdXxJKTC4yS03nWXbmnDFhrdbbEGCdzrd tUeIxi5oInt0k/u6Urp2ApgPzUDg52Kr+GGIFb4= X-Google-Smtp-Source: ABdhPJzAIrhymK3gPp+vY9pIqmfEHScH/XHFosYIK6lrEhbNeSv2m4iOcJFY/4FHatd4YMwsepxnNzLJz+vUBJQLoRk= X-Received: by 2002:a05:6122:889:: with SMTP id 9mr5100092vkf.10.1616241803358; Sat, 20 Mar 2021 05:03:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Adrian Gropper Date: Sat, 20 Mar 2021 08:03:10 -0400 Message-ID: To: Fabien Imbault Cc: Alan Karp , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="0000000000008f78bb05bdf69e74" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2021 12:03:27 -0000 --0000000000008f78bb05bdf69e74 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Fabien, that is not the way I think of capabilities working. I would prefer to leave the explanation to experts that have tried to teach me over the years. That=E2=80=99s, in part, why I recommended Alan=E2=80=99s 40 minute = talk at the beginning of this thread. To hold us over until one of them responds, I think of capabilities as a token that is signed by the issuer so no trust is involved. If the RS issues a capability to the RO signed by the RS, then it=E2=80=99s a pure be= arer token and any client that appears at the RS API with that capability will access the resource. That=E2=80=99s option 1. Option 2 is not based on capabilities. The RS stores a public key and trusts any token signed to that public key. The public key represents the identity of the RO or the AS that the RO delegated to. That=E2=80=99s opaqu= e to the RS. So the difference between the two options is in who signed the access token. The RS can offer both options to the RO if they=E2=80=99re nice. Adrian On Sat, Mar 20, 2021 at 6:52 AM Fabien Imbault wrote: > Thanks for the description. > > Trying to summarize what a capability flow would look like following > those ideas: > > 1) RS issues a capability for the RO. For instance "view and download > photo". > > 2) RO can delegate that capability (or an attenuated version) to the AS. > Say "view photo", possibly with some ambient conditions. > If the RO further wants to choose between a list of possible ASs, the RO > would have to signal its choice to the RS, which would then have to signa= l > it to the client (what we had called RS preflight in some discussions). S= o > the AS-RS relationship would be mediated via the RO (or more precisely it= s > agent). > > 3) a core GNAP negociation takes place with the AS (traditional photo > example). > > Is that correct? Do not hesitate to correct me if I didn't accurately > capture what you said. > (I volontarily put DID aside for now) > > Steps occurring before 3 are optional (for reasons discussed before and > also because we can't assume all RSs would be able to support that). > > Fabien > > Le sam. 20 mars 2021 =C3=A0 10:49, Adrian Gropper a > =C3=A9crit : > >> Hi Fabien, >> >> Yes, it=E2=80=99s optional and adding meaningful options is one way to c= onsider >> the ethical imperative http://www.cybsoc.org/heinz.htm >> >> If I understand Alan=E2=80=99s teachings, the RS has the option to eithe= r issue >> one or more capabilities to the RO or to store some identity-related >> information about the RO such as the DID of the RO and, by reference, th= e >> AS service endpoint controlled by that DID. >> >> Given some capabilities, the RO can either deal with them manually or >> hand them to an AS. Either way, the RS has no idea of the RO=E2=80=99s c= hoice until >> it receives a token from some end user. This seems to be what the Letter= s >> of Transit in Casablanca were all about. >> >> If, on the other hand, the RO chooses to give 5e RS a DID, a >> self-sovereign identifier, instead of taking some capabilities, then the= RS >> has the expectation to trust tokens signed by that DID. >> >> It=E2=80=99s my hope that GNAP can allow an ethical RS to offer both cho= ices to >> the RO. >> >> Adrian >> >> >> On Sat, Mar 20, 2021 at 4:23 AM Fabien Imbault >> wrote: >> >>> Hi Adrian, >>> >>> Calling to one AS per persona can only be optional, as we have no way, >>> and no wish, of knowing all the identities used by the RO. >>> >>> I think this relates to the idea of the RO having its own distinct >>> agent, but I still don't understand how that would work (even re-readin= g >>> the thread in issue 145). Could you elaborate? >>> >>> Thxs >>> Fabien >>> >>> >>> Le sam. 20 mars 2021 =C3=A0 06:08, Adrian Gropper a >>> =C3=A9crit : >>> >>>> @Alan Karp shared a talk about the Principle Of >>>> Least Authority (POLA) in a recent comment >>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecom= ment-803099693 >>>> I recommend it. >>>> >>>> We might expect a protocol with authorization in the title to use >>>> authority as a core principle. I advocate for a GNAP design that maxim= izes >>>> the power of the RO, to be seen as a human rights issue when the RO is= a >>>> human. This causes me to ask how to combine better security with bette= r >>>> human rights in GNAP. >>>> >>>> Who should have the least authority in the GNAP design? >>>> >>>> The AS derives authority as a delegate of the RO. If we ask the RO to >>>> partition limited authority across dozens of different ASs by domain a= nd >>>> function, then we are not using technology to empower the individual. >>>> Probably the opposite, as we introduce consent fatigue and burden norm= al >>>> people to partition their lives into non-overlapping domains. >>>> >>>> My experience says we should aim for one AS per persona because that >>>> maps into the way we manage our public and private identities. POLA wo= uld >>>> then teach care in keeping ASs and RSs related to work / public separa= te >>>> from ASs and RSs related to private life so that a policy vulnerabilit= y in >>>> our delegation to an AS would have the least likelihood of harm. >>>> >>>> Beyond that fairly obvious principle, we could spread our interactions >>>> among as many services as possible. We already do this when we spread >>>> assets across multiple banks, internet services across redundant platf= orms, >>>> or we use LinkedIn, Twitter, and Facebook with limited overlap in soci= al >>>> graphs. >>>> >>>> At the next level down, we want to manage resources at each RS using >>>> least authority in order to make AS policy vulnerabilities easier to s= pot >>>> and debug. My AS might get multiple capabilities or access to scopes f= rom >>>> an RS, each one carefully labeled with its intended uses so that the p= olicy >>>> engine of my AS could be structured to consider requests relative to o= nly >>>> one capability or scope family at a time. For example, in issuing heal= th >>>> record authorizations, I might separate the behavioral health capabili= ties >>>> from capabilities to access the physical parts of my record at a given >>>> hospital's GNAP RS API. >>>> >>>> Lastly, at the level of attenuation, I would choose a relationship wit= h >>>> RSs that issue to me capabilities that can be attenuated not only by m= y AS >>>> but also by the requesting parties that receive them as part of an acc= ess >>>> token. >>>> >>>> Adrian >>>> >>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> --0000000000008f78bb05bdf69e74 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Fabien, that is not the way I think of capabilities worki= ng. I would prefer to leave the explanation to experts that have tried to t= each me over the years. That=E2=80=99s, in part, why I recommended Alan=E2= =80=99s 40 minute talk at the beginning of this thread.=C2=A0

    To hold us over until one of them res= ponds, I think of capabilities as a token that is signed by the issuer so n= o trust is involved. If the RS issues a capability to the RO signed by the = RS, then it=E2=80=99s a pure bearer token and any client that appears at th= e RS API with that capability will access the resource. That=E2=80=99s opti= on 1.

    Option 2 is not ba= sed on capabilities. The RS stores a public key and trusts any token signed= to that public key. The public key represents the identity of the RO or th= e AS that the RO delegated to. That=E2=80=99s opaque to the RS.=C2=A0
    =

    So the difference between the= two options is in who signed the access token. The RS can offer both optio= ns to the RO if they=E2=80=99re nice.=C2=A0

    Adrian

    On Sat, Mar 20, 2021 at 6:52 AM Fabien Imbau= lt <fabien.imbault@gmail.com= > wrote:
    T= hanks for the description.=C2=A0

    Trying to summarize what a capability=C2=A0 flow would look like followi= ng those ideas:

    1) RS issues a= capability for the RO. For instance "view and download photo".= =C2=A0

    2) RO can delegat= e that capability (or an attenuated version) to the AS. Say "view phot= o", possibly with some ambient conditions.=C2=A0
    If the RO further wants to choose between a list of possible ASs, the RO = would have to signal its choice to the RS, which would then have to signal = it to the client (what we had called RS preflight in some discussions).=C2= =A0So the AS-RS relationship would b= e mediated via the RO (or more precisely its agent).=C2=A0

    3) a core GNAP negociation takes = place with the AS (traditional photo example).=C2=A0

    Is that correct? Do not hesitate to correct me= if I didn't accurately capture what you said.=C2=A0
    (I volontarily put DID aside for now)=C2=A0
    Steps occurring before 3 are optional (for reasons= discussed before and also because we can't assume all RSs would be abl= e to support that).=C2=A0

    Fabien=C2=A0

    = Le sam. 20 mars 2021 =C3=A0 10:49, Adrian Gropper <agropper@healthurl.com> a =C3= =A9crit=C2=A0:
    Hi Fabien,

    Yes, it=E2= =80=99s optional and adding meaningful options is one way to consider the e= thical imperative http://www.cybsoc.org/heinz.htm=C2=A0

    If I understand Alan= =E2=80=99s teachings, the RS has the option to either issue one or more cap= abilities to the RO or to store some identity-related information about the= RO such as the DID of the RO and, by reference, the AS service endpoint co= ntrolled by that DID.

    Gi= ven some capabilities, the RO can either deal with them manually or hand th= em to an AS. Either way, the RS has no idea of the RO=E2=80=99s choice unti= l it receives a token from some end user. This seems to be what the Letters= of Transit in Casablanca were all about.=C2=A0

    =
    If, on the other hand, the RO chooses to give 5e RS= a DID, a self-sovereign identifier, instead of taking some capabilities, t= hen the RS has the expectation =C2=A0to trust tokens signed by that DID.=C2= =A0

    It=E2=80=99s my hope= that GNAP can allow an ethical RS to offer both choices to the RO.

    Adrian
    <= br>

    On Sat, Mar 20, 2021 at 4:23 AM Fabien Imbault <fabien.imb= ault@gmail.com> wrote:
    <= div dir=3D"auto">Hi Adrian,=C2=A0

    Calling to one AS per persona can only be optional, as we have no= way, and no wish, of knowing all the identities used by the RO.=C2=A0

    I think this relates to the = idea of the RO having its own distinct agent, but I still don't underst= and how that would work (even re-reading the thread in issue 145). Could yo= u elaborate?=C2=A0

    Thxs<= /div>
    Fabien=C2=A0


    Le sam. 20 mars 2021 =C3=A0= 06:08, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit= =C2=A0:
    @Alan Karp=C2=A0shared a talk about= the Principle Of Least Authority (POLA) in a recent comment=C2=A0https://gith= ub.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-803099693 I recommend it.

    We might expect = a protocol with authorization in the title to use authority as a core princ= iple. I advocate for a GNAP design that maximizes the power of the RO, to b= e seen as a human rights=C2=A0issue when the RO is a human. This causes me = to ask how to combine better security with better human rights in GNAP.

    Who should have the least authority in the GNAP desig= n?

    The AS derives authority as a delegate of the R= O. If we ask the RO to partition limited authority across dozens of differe= nt ASs by domain and function, then we are not using technology to empower = the individual. Probably the opposite, as we introduce consent fatigue and = burden normal people to partition their lives into non-overlapping domains.= =C2=A0

    My experience says we should aim for one AS= per persona because that maps into the way we manage our public and privat= e identities. POLA would then teach care in keeping ASs and RSs related to = work / public separate from ASs and RSs related to private=C2=A0life so tha= t a policy vulnerability in our delegation to an AS would have the least li= kelihood=C2=A0of harm.

    Beyond that fairly obvious = principle, we could spread our interactions among as many services as possi= ble. We already do this when we spread assets across multiple banks, intern= et services across redundant platforms, or we use LinkedIn, Twitter, and Fa= cebook with limited overlap in social graphs.

    At t= he next level down, we want to manage resources at each RS using least auth= ority in order to make AS policy vulnerabilities easier to spot and debug. = My AS might get multiple capabilities or access to scopes from an RS, each = one carefully labeled with its intended uses so that the policy engine of m= y AS could be structured to consider requests relative to only one capabili= ty or scope family at a time. For example, in issuing health record authori= zations, I might separate the behavioral health capabilities from capabilit= ies to access the physical parts of my record at a given hospital's GNA= P RS API.

    Lastly, at the level of attenuation, I w= ould choose a relationship with RSs that issue to me capabilities that can = be attenuated not only by my AS but also by the requesting parties that rec= eive them as part of an access token.

    Adrian
    =


    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listi= nfo/txauth
    --0000000000008f78bb05bdf69e74-- From nobody Sat Mar 20 05:42:04 2021 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 8AE193A2168 for ; Sat, 20 Mar 2021 05:42: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, 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 dwr_a1m3Y8Sx for ; Sat, 20 Mar 2021 05:42:00 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 D50563A2167 for ; Sat, 20 Mar 2021 05:41:59 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id x16so9006611iob.1 for ; Sat, 20 Mar 2021 05:41: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=HRGSVwueXjo+aiUgZQSbZi5SrEOX2RfwBa1pxgStOLs=; b=Ele3+c0sT7pfmygJMMMpz3GnOsRLOXjNQmFi1VCfXoP7twcurrg2Jp8ZTufROb/k4o Lh6ibgBuKJGr7BMUTGW1ELjgAnHbh7cST6P+7csIqTbgf12lzMLAWLutME1o1ab1Phe1 cbU00kNpG4CgKho49jgjw2HyhdOXS7bWdmrRc0JSBQafTpqxzKKHNXz1o4q003fAV2A0 stu5eW86kQZrYMJKvch3gVqqT7tkqe80Kcu2u3Mt6YbpS2VB+5bmGzC+I3g3PSGDP4AO 7U0MuZ+St3X+3FJXXmq+XNoibhdGv8Y1NpYnXn0liG3VCSGNrgwwg4WjkzXwT3As1X8r nK6A== 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=HRGSVwueXjo+aiUgZQSbZi5SrEOX2RfwBa1pxgStOLs=; b=h09cW6SOtdtctWpxhULnzdSzpXXkcFb4Za4qFAUNvihmuI3HZL5ORKUS3BPxN5cp7o H3mwFP/zhsvB5dyjDj1kq375S3jm0344OzskbrC+ye6CkZdzcIjwtJAMhMEKnzRE5HcW +jZ5tSkW5uHM1CkiCc7ocX+4jJIj4MDWO8vflQm47bkR5Pvp/JgO7ymGlNd4kRnTXvFv U3Dh497pCGOerQxCwi6iK0f7kgmny846oaacG+ex1dZCyNmCQodPisoZHm2OSgnaXZvz 9dAlqfXoq9nMXm6l6Wm665H3nD+ffJMR4T1PfTAxZpdMozC53udMadEia6kSngSmIBL4 IqOQ== X-Gm-Message-State: AOAM531wsLCIzXSMYXA4xdNpPjU0G0t/HLmUQi6beVykesEiUh10hd9I oAx5soCSl1Uk9pMBSrJcBgURDaXWs8XEIwZj80qXGDDGMiw= X-Google-Smtp-Source: ABdhPJwQjKBjIfJ25cO2sY3hqd2yOzZiWJe03I6uWo6lm7paQ++e1kfLnln1rGu9AqIT6epOMH0vUw5FQ3s8PFLMTMM= X-Received: by 2002:a05:6638:224e:: with SMTP id m14mr5068815jas.8.1616244119188; Sat, 20 Mar 2021 05:41:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Sat, 20 Mar 2021 13:41:46 +0100 Message-ID: To: Adrian Gropper Cc: Alan Karp , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="00000000000098367705bdf72812" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2021 12:42:02 -0000 --00000000000098367705bdf72812 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Indeed I was asking because it's easy to get it wrong, so the feedback of higher authorities (Mark or Alan) is most welcome! In the flow I was indeed expecting bearer tokens. Fabien Le sam. 20 mars 2021 =C3=A0 13:03, Adrian Gropper = a =C3=A9crit : > Fabien, that is not the way I think of capabilities working. I would > prefer to leave the explanation to experts that have tried to teach me ov= er > the years. That=E2=80=99s, in part, why I recommended Alan=E2=80=99s 40 m= inute talk at the > beginning of this thread. > > To hold us over until one of them responds, I think of capabilities as a > token that is signed by the issuer so no trust is involved. If the RS > issues a capability to the RO signed by the RS, then it=E2=80=99s a pure = bearer > token and any client that appears at the RS API with that capability will > access the resource. That=E2=80=99s option 1. > > Option 2 is not based on capabilities. The RS stores a public key and > trusts any token signed to that public key. The public key represents the > identity of the RO or the AS that the RO delegated to. That=E2=80=99s opa= que to the > RS. > > So the difference between the two options is in who signed the access > token. The RS can offer both options to the RO if they=E2=80=99re nice. > > Adrian > > On Sat, Mar 20, 2021 at 6:52 AM Fabien Imbault > wrote: > >> Thanks for the description. >> >> Trying to summarize what a capability flow would look like following >> those ideas: >> >> 1) RS issues a capability for the RO. For instance "view and download >> photo". >> >> 2) RO can delegate that capability (or an attenuated version) to the AS. >> Say "view photo", possibly with some ambient conditions. >> If the RO further wants to choose between a list of possible ASs, the RO >> would have to signal its choice to the RS, which would then have to sign= al >> it to the client (what we had called RS preflight in some discussions). = So >> the AS-RS relationship would be mediated via the RO (or more precisely i= ts >> agent). >> >> 3) a core GNAP negociation takes place with the AS (traditional photo >> example). >> >> Is that correct? Do not hesitate to correct me if I didn't accurately >> capture what you said. >> (I volontarily put DID aside for now) >> >> Steps occurring before 3 are optional (for reasons discussed before and >> also because we can't assume all RSs would be able to support that). >> >> Fabien >> >> Le sam. 20 mars 2021 =C3=A0 10:49, Adrian Gropper a >> =C3=A9crit : >> >>> Hi Fabien, >>> >>> Yes, it=E2=80=99s optional and adding meaningful options is one way to = consider >>> the ethical imperative http://www.cybsoc.org/heinz.htm >>> >>> If I understand Alan=E2=80=99s teachings, the RS has the option to eith= er issue >>> one or more capabilities to the RO or to store some identity-related >>> information about the RO such as the DID of the RO and, by reference, t= he >>> AS service endpoint controlled by that DID. >>> >>> Given some capabilities, the RO can either deal with them manually or >>> hand them to an AS. Either way, the RS has no idea of the RO=E2=80=99s = choice until >>> it receives a token from some end user. This seems to be what the Lette= rs >>> of Transit in Casablanca were all about. >>> >>> If, on the other hand, the RO chooses to give 5e RS a DID, a >>> self-sovereign identifier, instead of taking some capabilities, then th= e RS >>> has the expectation to trust tokens signed by that DID. >>> >>> It=E2=80=99s my hope that GNAP can allow an ethical RS to offer both ch= oices to >>> the RO. >>> >>> Adrian >>> >>> >>> On Sat, Mar 20, 2021 at 4:23 AM Fabien Imbault >>> wrote: >>> >>>> Hi Adrian, >>>> >>>> Calling to one AS per persona can only be optional, as we have no way, >>>> and no wish, of knowing all the identities used by the RO. >>>> >>>> I think this relates to the idea of the RO having its own distinct >>>> agent, but I still don't understand how that would work (even re-readi= ng >>>> the thread in issue 145). Could you elaborate? >>>> >>>> Thxs >>>> Fabien >>>> >>>> >>>> Le sam. 20 mars 2021 =C3=A0 06:08, Adrian Gropper >>>> a =C3=A9crit : >>>> >>>>> @Alan Karp shared a talk about the Principle Of >>>>> Least Authority (POLA) in a recent comment >>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issueco= mment-803099693 >>>>> I recommend it. >>>>> >>>>> We might expect a protocol with authorization in the title to use >>>>> authority as a core principle. I advocate for a GNAP design that maxi= mizes >>>>> the power of the RO, to be seen as a human rights issue when the RO i= s a >>>>> human. This causes me to ask how to combine better security with bett= er >>>>> human rights in GNAP. >>>>> >>>>> Who should have the least authority in the GNAP design? >>>>> >>>>> The AS derives authority as a delegate of the RO. If we ask the RO to >>>>> partition limited authority across dozens of different ASs by domain = and >>>>> function, then we are not using technology to empower the individual. >>>>> Probably the opposite, as we introduce consent fatigue and burden nor= mal >>>>> people to partition their lives into non-overlapping domains. >>>>> >>>>> My experience says we should aim for one AS per persona because that >>>>> maps into the way we manage our public and private identities. POLA w= ould >>>>> then teach care in keeping ASs and RSs related to work / public separ= ate >>>>> from ASs and RSs related to private life so that a policy vulnerabili= ty in >>>>> our delegation to an AS would have the least likelihood of harm. >>>>> >>>>> Beyond that fairly obvious principle, we could spread our interaction= s >>>>> among as many services as possible. We already do this when we spread >>>>> assets across multiple banks, internet services across redundant plat= forms, >>>>> or we use LinkedIn, Twitter, and Facebook with limited overlap in soc= ial >>>>> graphs. >>>>> >>>>> At the next level down, we want to manage resources at each RS using >>>>> least authority in order to make AS policy vulnerabilities easier to = spot >>>>> and debug. My AS might get multiple capabilities or access to scopes = from >>>>> an RS, each one carefully labeled with its intended uses so that the = policy >>>>> engine of my AS could be structured to consider requests relative to = only >>>>> one capability or scope family at a time. For example, in issuing hea= lth >>>>> record authorizations, I might separate the behavioral health capabil= ities >>>>> from capabilities to access the physical parts of my record at a give= n >>>>> hospital's GNAP RS API. >>>>> >>>>> Lastly, at the level of attenuation, I would choose a relationship >>>>> with RSs that issue to me capabilities that can be attenuated not onl= y by >>>>> my AS but also by the requesting parties that receive them as part of= an >>>>> access token. >>>>> >>>>> Adrian >>>>> >>>>> >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> --00000000000098367705bdf72812 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Indeed I was asking because it's easy to get it wrong= , so the feedback of higher authorities (Mark or Alan) is most welcome!=C2= =A0

    In the flow I was indeed e= xpecting bearer tokens.

    = Fabien

    Le sam. 20 mars 2021 =C3=A0 13:03, Adrian Gropper <agropper@healthurl.com> a =C3=A9c= rit=C2=A0:
    Fabien= , that is not the way I think of capabilities working. I would prefer to le= ave the explanation to experts that have tried to teach me over the years. = That=E2=80=99s, in part, why I recommended Alan=E2=80=99s 40 minute talk at= the beginning of this thread.=C2=A0

    To hold us over until one of them responds, I think of capabil= ities as a token that is signed by the issuer so no trust is involved. If t= he RS issues a capability to the RO signed by the RS, then it=E2=80=99s a p= ure bearer token and any client that appears at the RS API with that capabi= lity will access the resource. That=E2=80=99s option 1.

    Option 2 is not based on capabilities. The = RS stores a public key and trusts any token signed to that public key. The = public key represents the identity of the RO or the AS that the RO delegate= d to. That=E2=80=99s opaque to the RS.=C2=A0

    So the difference between the two options is in who si= gned the access token. The RS can offer both options to the RO if they=E2= =80=99re nice.=C2=A0

    Adr= ian

    On Sat, Mar 20, 2021 at 6:52 AM Fabien Imbault <fabien.imb= ault@gmail.com> wrote:
    Thanks for the description.=C2=A0

    <= div dir=3D"auto">Trying to summarize what a capability=C2=A0 flow would loo= k like following those ideas:

    = 1) RS issues a capability for the RO. For instance "view and download = photo".=C2=A0

    2) RO= can delegate that capability (or an attenuated version) to the AS. Say &qu= ot;view photo", possibly with some ambient conditions.=C2=A0
    If the RO further wants to choose between a list of possible = ASs, the RO would have to signal its choice to the RS, which would then hav= e to signal it to the client (what we had called RS preflight in some discu= ssions).=C2=A0So the AS-RS relations= hip would be mediated via the RO (or more precisely its agent).=C2=A0

    3) a core GNAP negocia= tion takes place with the AS (traditional photo example).=C2=A0

    Is that correct? Do not hesitate to= correct me if I didn't accurately capture what you said.=C2=A0
    (I volontarily put DID aside for now)=C2=A0

    Steps occurring before 3 are optional= (for reasons discussed before and also because we can't assume all RSs= would be able to support that).=C2=A0
    <= div dir=3D"auto">

    Fabien=C2=A0=

    Le sam. 20 mars 2021 =C3=A0 10:49, Adrian Gropper <agr= opper@healthurl.com> a =C3=A9crit=C2=A0:
    Hi Fabien,

    =
    Yes, it=E2=80=99s optional and adding meaningful op= tions is one way to consider the ethical imperative http:/= /www.cybsoc.org/heinz.htm=C2=A0

    =
    If I understand Alan=E2=80=99s teachings, the RS has= the option to either issue one or more capabilities to the RO or to store = some identity-related information about the RO such as the DID of the RO an= d, by reference, the AS service endpoint controlled by that DID.

    Given some capabilities, the RO ca= n either deal with them manually or hand them to an AS. Either way, the RS = has no idea of the RO=E2=80=99s choice until it receives a token from some = end user. This seems to be what the Letters of Transit in Casablanca were a= ll about.=C2=A0

    If, on t= he other hand, the RO chooses to give 5e RS a DID, a self-sovereign identif= ier, instead of taking some capabilities, then the RS has the expectation = =C2=A0to trust tokens signed by that DID.=C2=A0

    =
    It=E2=80=99s my hope that GNAP can allow an ethical= RS to offer both choices to the RO.

    Adrian


    On Sat, Mar 20, 2021 at= 4:23 AM Fabien Imbault <fabien.imbault@gmail.com&g= t; wrote:
    Hi = Adrian,=C2=A0

    Calling to= one AS per persona can only be optional, as we have no way, and no wish, o= f knowing all the identities used by the RO.=C2=A0
    <= br>
    I think this relates to the idea of the RO havin= g its own distinct agent, but I still don't understand how that would w= ork (even re-reading the thread in issue 145). Could you elaborate?=C2=A0

    Thxs
    Fabien=C2=A0


    =
    Le sam. 20 mars 2021 =C3=A0 06:08, Adrian Groppe= r <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    =
    <= a class=3D"gmail_plusreply" id=3D"m_142655982414963792m_2883249642916220317= m_-9131117252956894446m_-5429822836039521715m_-4880039689634828922m_-591525= 9234616404125gmail-plusReplyChip-1" href=3D"mailto:alanhkarp@gmail.com" rel= =3D"noreferrer noreferrer noreferrer" target=3D"_blank">@Alan Karp=C2= =A0shared a talk about the Principle Of Least Authority (POLA) in a recent = comment=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issue= s/145#issuecomment-803099693 I recommend it.
    =
    We might expect a protocol with authorization in the title t= o use authority as a core principle. I advocate for a GNAP design that maxi= mizes the power of the RO, to be seen as a human rights=C2=A0issue when the= RO is a human. This causes me to ask how to combine better security with b= etter human rights in GNAP.

    Who should have the le= ast authority in the GNAP design?

    The AS derives a= uthority as a delegate of the RO. If we ask the RO to partition limited aut= hority across dozens of different ASs by domain and function, then we are n= ot using technology to empower the individual. Probably the opposite, as we= introduce consent fatigue and burden normal people to partition their live= s into non-overlapping domains.=C2=A0

    My experienc= e says we should aim for one AS per persona because that maps into the way = we manage our public and private identities. POLA would then teach care in = keeping ASs and RSs related to work / public separate from ASs and RSs rela= ted to private=C2=A0life so that a policy vulnerability in our delegation t= o an AS would have the least likelihood=C2=A0of harm.

    <= div>Beyond that fairly obvious principle, we could spread our interactions = among as many services as possible. We already do this when we spread asset= s across multiple banks, internet services across redundant platforms, or w= e use LinkedIn, Twitter, and Facebook with limited overlap in social graphs= .

    At the next level down, we want to manage resour= ces at each RS using least authority in order to make AS policy vulnerabili= ties easier to spot and debug. My AS might get multiple capabilities or acc= ess to scopes from an RS, each one carefully labeled with its intended uses= so that the policy engine of my AS could be structured to consider request= s relative to only one capability or scope family at a time. For example, i= n issuing health record authorizations, I might separate the behavioral hea= lth capabilities from capabilities to access the physical parts of my recor= d at a given hospital's GNAP RS API.

    Lastly, a= t the level of attenuation, I would choose a relationship with RSs that iss= ue to me capabilities that can be attenuated not only by my AS but also by = the requesting parties that receive them as part of an access token.
    <= div>
    Adrian


    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/ma= ilman/listinfo/txauth
    --00000000000098367705bdf72812-- From nobody Sat Mar 20 06:55:51 2021 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 DC0493A23CB for ; Sat, 20 Mar 2021 06:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 fL6z758KSLE2 for ; Sat, 20 Mar 2021 06:55:47 -0700 (PDT) Received: from mail-vk1-f177.google.com (mail-vk1-f177.google.com [209.85.221.177]) (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 1C4EC3A23CA for ; Sat, 20 Mar 2021 06:55:47 -0700 (PDT) Received: by mail-vk1-f177.google.com with SMTP id k76so2758088vkk.10 for ; Sat, 20 Mar 2021 06:55:47 -0700 (PDT) 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=4PVz/0h7LC3C5QuNs0jyc4AGbQooZVO781I8oq8yL8Q=; b=RxQw6JSccNwPhe0+IOwvCYTjNUPnkUTyJTsbZ0HGxetE2iUQNaBDwIU7QWOnSsEYYq hqiJoy2WkKrEHwwgZcGYdzOKjWN10ToqwjMil2Sw/mv82ZiFwUIFF7V1clPqV//GsK8O a+KoUQ/EamZnT+YxlEF+3dnISJMgkQFEpXED2m1o+BBSZH/tKzmh1IoFluDTOm7pQuna XJuxheQ5l49yaF1enc8Ui1AMrARunLe71EkU8lfO/hYuuKPL7LTaKz/FWCEmtaFjYlY3 LzadGxNFUw6pq6TvZ+XJz4wDqFIj2R7ANwr7MAVINE5+TAtRDFuvWEnFw5+Zmvx94k4F jTlg== X-Gm-Message-State: AOAM532mkdlN1Hd0Rd0xZvaItl8/7lO5itAhOw4jMLohVT+gYSdOUzJV IlLbRecvNLnh72N1lFnRJ3K7N1O0fGQ+FLF4hXc= X-Google-Smtp-Source: ABdhPJwRVy7Z5vwhYMkXo2Ims1xEDsh60JaBBYPToqrCw3io9d8ntkcxpkAwetdzJNXE7KFG5vZKIVrKR4nP0+fU+e0= X-Received: by 2002:a1f:3250:: with SMTP id y77mr3526513vky.20.1616248545894; Sat, 20 Mar 2021 06:55:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Adrian Gropper Date: Sat, 20 Mar 2021 09:55:33 -0400 Message-ID: To: Fabien Imbault Cc: Alan Karp , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="0000000000007266a605bdf8303a" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2021 13:55:50 -0000 --0000000000007266a605bdf8303a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable While we wait, I might add this other perspective: If the RS trusts an access token, then honor it. If the RS doesn=E2=80=99t trust the access tok= en, contact an AS with adequate authority. If it knows no AS with adequate authority, deny the request, with malice. Adrian On Sat, Mar 20, 2021 at 8:42 AM Fabien Imbault wrote: > Indeed I was asking because it's easy to get it wrong, so the feedback of > higher authorities (Mark or Alan) is most welcome! > > In the flow I was indeed expecting bearer tokens. > > Fabien > > Le sam. 20 mars 2021 =C3=A0 13:03, Adrian Gropper a > =C3=A9crit : > >> Fabien, that is not the way I think of capabilities working. I would >> prefer to leave the explanation to experts that have tried to teach me o= ver >> the years. That=E2=80=99s, in part, why I recommended Alan=E2=80=99s 40 = minute talk at the >> beginning of this thread. >> >> To hold us over until one of them responds, I think of capabilities as a >> token that is signed by the issuer so no trust is involved. If the RS >> issues a capability to the RO signed by the RS, then it=E2=80=99s a pure= bearer >> token and any client that appears at the RS API with that capability wil= l >> access the resource. That=E2=80=99s option 1. >> >> Option 2 is not based on capabilities. The RS stores a public key and >> trusts any token signed to that public key. The public key represents th= e >> identity of the RO or the AS that the RO delegated to. That=E2=80=99s op= aque to the >> RS. >> >> So the difference between the two options is in who signed the access >> token. The RS can offer both options to the RO if they=E2=80=99re nice. >> >> Adrian >> >> On Sat, Mar 20, 2021 at 6:52 AM Fabien Imbault >> wrote: >> >>> Thanks for the description. >>> >>> Trying to summarize what a capability flow would look like following >>> those ideas: >>> >>> 1) RS issues a capability for the RO. For instance "view and download >>> photo". >>> >>> 2) RO can delegate that capability (or an attenuated version) to the AS= . >>> Say "view photo", possibly with some ambient conditions. >>> If the RO further wants to choose between a list of possible ASs, the R= O >>> would have to signal its choice to the RS, which would then have to sig= nal >>> it to the client (what we had called RS preflight in some discussions).= So >>> the AS-RS relationship would be mediated via the RO (or more precisely = its >>> agent). >>> >>> 3) a core GNAP negociation takes place with the AS (traditional photo >>> example). >>> >>> Is that correct? Do not hesitate to correct me if I didn't accurately >>> capture what you said. >>> (I volontarily put DID aside for now) >>> >>> Steps occurring before 3 are optional (for reasons discussed before and >>> also because we can't assume all RSs would be able to support that). >>> >>> Fabien >>> >>> Le sam. 20 mars 2021 =C3=A0 10:49, Adrian Gropper a >>> =C3=A9crit : >>> >>>> Hi Fabien, >>>> >>>> Yes, it=E2=80=99s optional and adding meaningful options is one way to= consider >>>> the ethical imperative http://www.cybsoc.org/heinz.htm >>>> >>>> If I understand Alan=E2=80=99s teachings, the RS has the option to eit= her issue >>>> one or more capabilities to the RO or to store some identity-related >>>> information about the RO such as the DID of the RO and, by reference, = the >>>> AS service endpoint controlled by that DID. >>>> >>>> Given some capabilities, the RO can either deal with them manually or >>>> hand them to an AS. Either way, the RS has no idea of the RO=E2=80=99s= choice until >>>> it receives a token from some end user. This seems to be what the Lett= ers >>>> of Transit in Casablanca were all about. >>>> >>>> If, on the other hand, the RO chooses to give 5e RS a DID, a >>>> self-sovereign identifier, instead of taking some capabilities, then t= he RS >>>> has the expectation to trust tokens signed by that DID. >>>> >>>> It=E2=80=99s my hope that GNAP can allow an ethical RS to offer both c= hoices to >>>> the RO. >>>> >>>> Adrian >>>> >>>> >>>> On Sat, Mar 20, 2021 at 4:23 AM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Hi Adrian, >>>>> >>>>> Calling to one AS per persona can only be optional, as we have no way= , >>>>> and no wish, of knowing all the identities used by the RO. >>>>> >>>>> I think this relates to the idea of the RO having its own distinct >>>>> agent, but I still don't understand how that would work (even re-read= ing >>>>> the thread in issue 145). Could you elaborate? >>>>> >>>>> Thxs >>>>> Fabien >>>>> >>>>> >>>>> Le sam. 20 mars 2021 =C3=A0 06:08, Adrian Gropper >>>>> a =C3=A9crit : >>>>> >>>>>> @Alan Karp shared a talk about the Principle >>>>>> Of Least Authority (POLA) in a recent comment >>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuec= omment-803099693 >>>>>> I recommend it. >>>>>> >>>>>> We might expect a protocol with authorization in the title to use >>>>>> authority as a core principle. I advocate for a GNAP design that max= imizes >>>>>> the power of the RO, to be seen as a human rights issue when the RO = is a >>>>>> human. This causes me to ask how to combine better security with bet= ter >>>>>> human rights in GNAP. >>>>>> >>>>>> Who should have the least authority in the GNAP design? >>>>>> >>>>>> The AS derives authority as a delegate of the RO. If we ask the RO t= o >>>>>> partition limited authority across dozens of different ASs by domain= and >>>>>> function, then we are not using technology to empower the individual= . >>>>>> Probably the opposite, as we introduce consent fatigue and burden no= rmal >>>>>> people to partition their lives into non-overlapping domains. >>>>>> >>>>>> My experience says we should aim for one AS per persona because that >>>>>> maps into the way we manage our public and private identities. POLA = would >>>>>> then teach care in keeping ASs and RSs related to work / public sepa= rate >>>>>> from ASs and RSs related to private life so that a policy vulnerabil= ity in >>>>>> our delegation to an AS would have the least likelihood of harm. >>>>>> >>>>>> Beyond that fairly obvious principle, we could spread our >>>>>> interactions among as many services as possible. We already do this = when we >>>>>> spread assets across multiple banks, internet services across redund= ant >>>>>> platforms, or we use LinkedIn, Twitter, and Facebook with limited ov= erlap >>>>>> in social graphs. >>>>>> >>>>>> At the next level down, we want to manage resources at each RS using >>>>>> least authority in order to make AS policy vulnerabilities easier to= spot >>>>>> and debug. My AS might get multiple capabilities or access to scopes= from >>>>>> an RS, each one carefully labeled with its intended uses so that the= policy >>>>>> engine of my AS could be structured to consider requests relative to= only >>>>>> one capability or scope family at a time. For example, in issuing he= alth >>>>>> record authorizations, I might separate the behavioral health capabi= lities >>>>>> from capabilities to access the physical parts of my record at a giv= en >>>>>> hospital's GNAP RS API. >>>>>> >>>>>> Lastly, at the level of attenuation, I would choose a relationship >>>>>> with RSs that issue to me capabilities that can be attenuated not on= ly by >>>>>> my AS but also by the requesting parties that receive them as part o= f an >>>>>> access token. >>>>>> >>>>>> Adrian >>>>>> >>>>>> >>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>> --0000000000007266a605bdf8303a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    While we wait, I might add this other perspective: If the= RS trusts an access token, then honor it. If the RS doesn=E2=80=99t trust = the access token, contact an AS with adequate authority. If it knows no AS = with adequate authority, deny the request, with malice.

    Adrian=C2=A0

    On Sat, Mar 20, 2021 at 8:= 42 AM Fabien Imbault <fabien= .imbault@gmail.com> wrote:
    <= div dir=3D"auto">Indeed I was asking because it's easy to get it wrong,= so the feedback of higher authorities (Mark or Alan) is most welcome!=C2= =A0

    In the flow I was indeed e= xpecting bearer tokens.

    =
    Fabien

    Le sam. 20 mars 2021 =C3=A0 13:03, Adri= an Gropper <= agropper@healthurl.com> a =C3=A9crit=C2=A0:
    Fabien, that is not the way I think of ca= pabilities working. I would prefer to leave the explanation to experts that= have tried to teach me over the years. That=E2=80=99s, in part, why I reco= mmended Alan=E2=80=99s 40 minute talk at the beginning of this thread.=C2= =A0

    To hold us over unti= l one of them responds, I think of capabilities as a token that is signed b= y the issuer so no trust is involved. If the RS issues a capability to the = RO signed by the RS, then it=E2=80=99s a pure bearer token and any client t= hat appears at the RS API with that capability will access the resource. Th= at=E2=80=99s option 1.

    O= ption 2 is not based on capabilities. The RS stores a public key and trusts= any token signed to that public key. The public key represents the identit= y of the RO or the AS that the RO delegated to. That=E2=80=99s opaque to th= e RS.=C2=A0

    So the diffe= rence between the two options is in who signed the access token. The RS can= offer both options to the RO if they=E2=80=99re nice.=C2=A0

    Adrian

    On Sat, Mar 20, 2021 at 6:= 52 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    <= /div>
    Thanks for the descri= ption.=C2=A0

    Trying to summari= ze what a capability=C2=A0 flow would look like following those ideas:

    1) RS issues a capability for the = RO. For instance "view and download photo".=C2=A0

    2) RO can delegate that capability (o= r an attenuated version) to the AS. Say "view photo", possibly wi= th some ambient conditions.=C2=A0
    If the RO further = wants to choose between a list of possible ASs, the RO would have to signal= its choice to the RS, which would then have to signal it to the client (wh= at we had called RS preflight in some discussions).=C2=A0So the AS-RS relationship would be mediated via the RO= (or more precisely its agent).=C2=A0

    3) a core GNAP negociation takes place with the AS (tr= aditional photo example).=C2=A0

    Is that correct? Do not hesitate to correct me if I didn't ac= curately capture what you said.=C2=A0
    (I volontarily= put DID aside for now)=C2=A0

    Steps occurring before 3 are optional (for reasons discussed before a= nd also because we can't assume all RSs would be able to support that).= =C2=A0

    Fabien=C2=A0

    Le sam. 20 mars 202= 1 =C3=A0 10:49, Adrian Gropper <agropper@healthurl.com> a =C3= =A9crit=C2=A0:
    Hi Fabien,

    Yes, it=E2= =80=99s optional and adding meaningful options is one way to consider the e= thical imperative http://www.cybsoc.org/heinz.htm=C2= =A0

    If I unde= rstand Alan=E2=80=99s teachings, the RS has the option to either issue one = or more capabilities to the RO or to store some identity-related informatio= n about the RO such as the DID of the RO and, by reference, the AS service = endpoint controlled by that DID.

    Given some capabilities, the RO can either deal with them manuall= y or hand them to an AS. Either way, the RS has no idea of the RO=E2=80=99s= choice until it receives a token from some end user. This seems to be what= the Letters of Transit in Casablanca were all about.=C2=A0

    If, on the other hand, the RO chooses= to give 5e RS a DID, a self-sovereign identifier, instead of taking some c= apabilities, then the RS has the expectation =C2=A0to trust tokens signed b= y that DID.=C2=A0

    It=E2= =80=99s my hope that GNAP can allow an ethical RS to offer both choices to = the RO.

    Adrian


    On Sat, Mar 20, 2021 at 4:23 AM Fabien Imbault <<= a href=3D"mailto:fabien.imbault@gmail.com" rel=3D"noreferrer noreferrer" ta= rget=3D"_blank">fabien.imbault@gmail.com> wrote:
    Hi Adrian,=C2=A0

    Calling to one AS per persona can onl= y be optional, as we have no way, and no wish, of knowing all the identitie= s used by the RO.=C2=A0

    = I think this relates to the idea of the RO having its own distinct agent, b= ut I still don't understand how that would work (even re-reading the th= read in issue 145). Could you elaborate?=C2=A0

    <= /div>
    Thxs
    Fabien=C2=A0

    = Le sam. 20 mars 2021 =C3=A0 06:08, Adrian Gropper <agropp= er@healthurl.com> a =C3=A9crit=C2=A0:
    @Alan Karp=C2=A0share= d a talk about the Principle Of Least Authority (POLA) in a recent comment= =C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#i= ssuecomment-803099693 I recommend it.

    We might expect a protocol with authorization in the title to use a= uthority as a core principle. I advocate for a GNAP design that maximizes t= he power of the RO, to be seen as a human rights=C2=A0issue when the RO is = a human. This causes me to ask how to combine better security with better h= uman rights in GNAP.

    Who should have the least aut= hority in the GNAP design?

    The AS derives authorit= y as a delegate of the RO. If we ask the RO to partition limited authority = across dozens of different ASs by domain and function, then we are not usin= g technology to empower the individual. Probably the opposite, as we introd= uce consent fatigue and burden normal people to partition their lives into = non-overlapping domains.=C2=A0

    My experience says = we should aim for one AS per persona because that maps into the way we mana= ge our public and private identities. POLA would then teach care in keeping= ASs and RSs related to work / public separate from ASs and RSs related to = private=C2=A0life so that a policy vulnerability in our delegation to an AS= would have the least likelihood=C2=A0of harm.

    Bey= ond that fairly obvious principle, we could spread our interactions among a= s many services as possible. We already do this when we spread assets acros= s multiple banks, internet services across redundant platforms, or we use L= inkedIn, Twitter, and Facebook with limited overlap in social graphs.
    =

    At the next level down, we want to manage resources at = each RS using least authority in order to make AS policy vulnerabilities ea= sier to spot and debug. My AS might get multiple capabilities or access to = scopes from an RS, each one carefully labeled with its intended uses so tha= t the policy engine of my AS could be structured to consider requests relat= ive to only one capability or scope family at a time. For example, in issui= ng health record authorizations, I might separate the behavioral health cap= abilities from capabilities to access the physical parts of my record at a = given hospital's GNAP RS API.

    Lastly, at the l= evel of attenuation, I would choose a relationship with RSs that issue to m= e capabilities that can be attenuated not only by my AS but also by the req= uesting parties that receive them as part of an access token.
    Adrian


    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/ma= ilman/listinfo/txauth
    --0000000000007266a605bdf8303a-- From nobody Sat Mar 20 07:13:28 2021 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 A5C9B3A2410 for ; Sat, 20 Mar 2021 07:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 1HIcMsBsHZTB for ; Sat, 20 Mar 2021 07:13:24 -0700 (PDT) Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) (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 CFDD63A240E for ; Sat, 20 Mar 2021 07:13:23 -0700 (PDT) Received: by mail-vs1-f52.google.com with SMTP id k14so5083647vsb.6 for ; Sat, 20 Mar 2021 07:13:23 -0700 (PDT) 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=j6/VYLcHrAXgjwmBCKS5IL6SMyeoOov2mwj67d1U99g=; b=NA8+PpCPissMBE9isWos9/BU7MZYA9YSAjPDw7M8kBq5BderDh7526lahxviYDynWE SrIs3skXLUFnhM6Z5ALwxjV473cckuLRjEzLZxY1/sqnB+kXpbcwti7QrUdwbONEOuWc ssdtnmZj83jr9GWPFLwDrPXIfHEZenzly++r7ddpcq/zad3BCDG2WqD/ClcnUBBy1Bti PuMX/G6BL6Clqha6dm+Lu/1/mwF3zVcO8rwDNkw7IFBOBitiykgdk96dN4nddvNVhxuv mH3XAGZxU4XhpNl8iw3RG0XZKK6w7uXDRdl22Md8ogEXHgwfeW5jjg8bc42AlBb0qa6v w2Tg== X-Gm-Message-State: AOAM532CX98qUxEhQ/TtgUgH38MrhueCKYCu2KmfKh2ylWxcXk5c3IzE cjZ6ltnsW9E6qRwhU4i/x2Xq2vUN52vJzSdtuX5AA0WXMWM= X-Google-Smtp-Source: ABdhPJxHeRLjySdz+SahOQsB51TwaoX4phk2p79yRMIpGho2TNZfCR62fkr/fRZebD/W4MAg+lQvEpEWmgvaylKVY08= X-Received: by 2002:a67:db84:: with SMTP id f4mr5702645vsk.20.1616249602771; Sat, 20 Mar 2021 07:13:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Adrian Gropper Date: Sat, 20 Mar 2021 10:13:09 -0400 Message-ID: To: Fabien Imbault Cc: Alan Karp , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="000000000000710d4005bdf86feb" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2021 14:13:27 -0000 --000000000000710d4005bdf86feb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable While we still wait, here=E2=80=99s yet another framing: When an RS gets a = request that it thinks it has adequate policies to evaluate, do it. If it does not have adequate policies, refer the request to someone that might have adequate policies and don=E2=80=99t worry about it, you might hear back or = not. Adrian On Sat, Mar 20, 2021 at 9:55 AM Adrian Gropper wrote: > While we wait, I might add this other perspective: If the RS trusts an > access token, then honor it. If the RS doesn=E2=80=99t trust the access t= oken, > contact an AS with adequate authority. If it knows no AS with adequate > authority, deny the request, with malice. > > Adrian > > On Sat, Mar 20, 2021 at 8:42 AM Fabien Imbault > wrote: > >> Indeed I was asking because it's easy to get it wrong, so the feedback o= f >> higher authorities (Mark or Alan) is most welcome! >> >> In the flow I was indeed expecting bearer tokens. >> >> Fabien >> >> Le sam. 20 mars 2021 =C3=A0 13:03, Adrian Gropper a >> =C3=A9crit : >> >>> Fabien, that is not the way I think of capabilities working. I would >>> prefer to leave the explanation to experts that have tried to teach me = over >>> the years. That=E2=80=99s, in part, why I recommended Alan=E2=80=99s 40= minute talk at the >>> beginning of this thread. >>> >>> To hold us over until one of them responds, I think of capabilities as = a >>> token that is signed by the issuer so no trust is involved. If the RS >>> issues a capability to the RO signed by the RS, then it=E2=80=99s a pur= e bearer >>> token and any client that appears at the RS API with that capability wi= ll >>> access the resource. That=E2=80=99s option 1. >>> >>> Option 2 is not based on capabilities. The RS stores a public key and >>> trusts any token signed to that public key. The public key represents t= he >>> identity of the RO or the AS that the RO delegated to. That=E2=80=99s o= paque to the >>> RS. >>> >>> So the difference between the two options is in who signed the access >>> token. The RS can offer both options to the RO if they=E2=80=99re nice. >>> >>> Adrian >>> >>> On Sat, Mar 20, 2021 at 6:52 AM Fabien Imbault >>> wrote: >>> >>>> Thanks for the description. >>>> >>>> Trying to summarize what a capability flow would look like following >>>> those ideas: >>>> >>>> 1) RS issues a capability for the RO. For instance "view and download >>>> photo". >>>> >>>> 2) RO can delegate that capability (or an attenuated version) to the >>>> AS. Say "view photo", possibly with some ambient conditions. >>>> If the RO further wants to choose between a list of possible ASs, the >>>> RO would have to signal its choice to the RS, which would then have to >>>> signal it to the client (what we had called RS preflight in some >>>> discussions). So the AS-RS relationship would be mediated via the RO >>>> (or more precisely its agent). >>>> >>>> 3) a core GNAP negociation takes place with the AS (traditional photo >>>> example). >>>> >>>> Is that correct? Do not hesitate to correct me if I didn't accurately >>>> capture what you said. >>>> (I volontarily put DID aside for now) >>>> >>>> Steps occurring before 3 are optional (for reasons discussed before an= d >>>> also because we can't assume all RSs would be able to support that). >>>> >>>> Fabien >>>> >>>> Le sam. 20 mars 2021 =C3=A0 10:49, Adrian Gropper >>>> a =C3=A9crit : >>>> >>>>> Hi Fabien, >>>>> >>>>> Yes, it=E2=80=99s optional and adding meaningful options is one way t= o >>>>> consider the ethical imperative http://www.cybsoc.org/heinz.htm >>>>> >>>>> If I understand Alan=E2=80=99s teachings, the RS has the option to ei= ther >>>>> issue one or more capabilities to the RO or to store some identity-re= lated >>>>> information about the RO such as the DID of the RO and, by reference,= the >>>>> AS service endpoint controlled by that DID. >>>>> >>>>> Given some capabilities, the RO can either deal with them manually or >>>>> hand them to an AS. Either way, the RS has no idea of the RO=E2=80=99= s choice until >>>>> it receives a token from some end user. This seems to be what the Let= ters >>>>> of Transit in Casablanca were all about. >>>>> >>>>> If, on the other hand, the RO chooses to give 5e RS a DID, a >>>>> self-sovereign identifier, instead of taking some capabilities, then = the RS >>>>> has the expectation to trust tokens signed by that DID. >>>>> >>>>> It=E2=80=99s my hope that GNAP can allow an ethical RS to offer both = choices >>>>> to the RO. >>>>> >>>>> Adrian >>>>> >>>>> >>>>> On Sat, Mar 20, 2021 at 4:23 AM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Hi Adrian, >>>>>> >>>>>> Calling to one AS per persona can only be optional, as we have no >>>>>> way, and no wish, of knowing all the identities used by the RO. >>>>>> >>>>>> I think this relates to the idea of the RO having its own distinct >>>>>> agent, but I still don't understand how that would work (even re-rea= ding >>>>>> the thread in issue 145). Could you elaborate? >>>>>> >>>>>> Thxs >>>>>> Fabien >>>>>> >>>>>> >>>>>> Le sam. 20 mars 2021 =C3=A0 06:08, Adrian Gropper >>>>>> a =C3=A9crit : >>>>>> >>>>>>> @Alan Karp shared a talk about the Principle >>>>>>> Of Least Authority (POLA) in a recent comment >>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issue= comment-803099693 >>>>>>> I recommend it. >>>>>>> >>>>>>> We might expect a protocol with authorization in the title to use >>>>>>> authority as a core principle. I advocate for a GNAP design that ma= ximizes >>>>>>> the power of the RO, to be seen as a human rights issue when the RO= is a >>>>>>> human. This causes me to ask how to combine better security with be= tter >>>>>>> human rights in GNAP. >>>>>>> >>>>>>> Who should have the least authority in the GNAP design? >>>>>>> >>>>>>> The AS derives authority as a delegate of the RO. If we ask the RO >>>>>>> to partition limited authority across dozens of different ASs by do= main and >>>>>>> function, then we are not using technology to empower the individua= l. >>>>>>> Probably the opposite, as we introduce consent fatigue and burden n= ormal >>>>>>> people to partition their lives into non-overlapping domains. >>>>>>> >>>>>>> My experience says we should aim for one AS per persona because tha= t >>>>>>> maps into the way we manage our public and private identities. POLA= would >>>>>>> then teach care in keeping ASs and RSs related to work / public sep= arate >>>>>>> from ASs and RSs related to private life so that a policy vulnerabi= lity in >>>>>>> our delegation to an AS would have the least likelihood of harm. >>>>>>> >>>>>>> Beyond that fairly obvious principle, we could spread our >>>>>>> interactions among as many services as possible. We already do this= when we >>>>>>> spread assets across multiple banks, internet services across redun= dant >>>>>>> platforms, or we use LinkedIn, Twitter, and Facebook with limited o= verlap >>>>>>> in social graphs. >>>>>>> >>>>>>> At the next level down, we want to manage resources at each RS usin= g >>>>>>> least authority in order to make AS policy vulnerabilities easier t= o spot >>>>>>> and debug. My AS might get multiple capabilities or access to scope= s from >>>>>>> an RS, each one carefully labeled with its intended uses so that th= e policy >>>>>>> engine of my AS could be structured to consider requests relative t= o only >>>>>>> one capability or scope family at a time. For example, in issuing h= ealth >>>>>>> record authorizations, I might separate the behavioral health capab= ilities >>>>>>> from capabilities to access the physical parts of my record at a gi= ven >>>>>>> hospital's GNAP RS API. >>>>>>> >>>>>>> Lastly, at the level of attenuation, I would choose a relationship >>>>>>> with RSs that issue to me capabilities that can be attenuated not o= nly by >>>>>>> my AS but also by the requesting parties that receive them as part = of an >>>>>>> access token. >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> TXAuth mailing list >>>>>>> TXAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >>>>>> --000000000000710d4005bdf86feb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    While we still wait, here=E2=80=99s yet another framing: = When an RS gets a request that it thinks it has adequate policies to evalua= te, do it. If it does not have adequate policies, refer the request to some= one that might have adequate policies and don=E2=80=99t worry about it, you= might hear back or not.

    Adrian

    On Sat, Mar 20, 2021 at 9:55 AM Adrian Gropper <agropper@healthurl.com> wrote:
    While we wait, I might a= dd this other perspective: If the RS trusts an access token, then honor it.= If the RS doesn=E2=80=99t trust the access token, contact an AS with adequ= ate authority. If it knows no AS with adequate authority, deny the request,= with malice.

    Adrian=C2= =A0

    On Sat, Mar 20, 2021 at 8:42 AM Fabien Imbault <fabien.imbault@gmail.com&= gt; wrote:
    Indeed= I was asking because it's easy to get it wrong, so the feedback of hig= her authorities (Mark or Alan) is most welcome!=C2=A0

    =
    In the flow I was indeed expecting bearer tokens.

    F= abien

    Le sam. 20 mars 2021 =C3=A0 13:03, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:

    To hold us over until one of them responds, I = think of capabilities as a token that is signed by the issuer so no trust i= s involved. If the RS issues a capability to the RO signed by the RS, then = it=E2=80=99s a pure bearer token and any client that appears at the RS API = with that capability will access the resource. That=E2=80=99s option 1.

    Option 2 is not based on ca= pabilities. The RS stores a public key and trusts any token signed to that = public key. The public key represents the identity of the RO or the AS that= the RO delegated to. That=E2=80=99s opaque to the RS.=C2=A0

    So the difference between the two opt= ions is in who signed the access token. The RS can offer both options to th= e RO if they=E2=80=99re nice.=C2=A0

    Adrian

    On Sat, Mar 20, 2021 at 6:52 AM Fabien Imbault <<= a href=3D"mailto:fabien.imbault@gmail.com" rel=3D"noreferrer" target=3D"_bl= ank">fabien.imbault@gmail.com> wrote:
    Thanks for the description.=C2=A0

    Trying to summarize what a capability=C2=A0= flow would look like following those ideas:

    1) RS issues a capability for the RO. For instance "vie= w and download photo".=C2=A0

    2) RO can delegate that capability (or an attenuated version) to = the AS. Say "view photo", possibly with some ambient conditions.= =C2=A0
    If the RO further wants to choose between a l= ist of possible ASs, the RO would have to signal its choice to the RS, whic= h would then have to signal it to the client (what we had called RS preflig= ht in some discussions).=C2=A0So the= AS-RS relationship would be mediated via the RO (or more precisely its age= nt).=C2=A0

    3) a c= ore GNAP negociation takes place with the AS (traditional photo example).= =C2=A0

    Is that correct? = Do not hesitate to correct me if I didn't accurately capture what you s= aid.=C2=A0
    (I volontarily put DID aside for now)=C2= =A0

    Steps occurring befo= re 3 are optional (for reasons discussed before and also because we can'= ;t assume all RSs would be able to support that).=C2=A0

    Fabien=C2=A0

    Le sam. 20 mars 2021 =C3=A0 10:49, Adrian Gro= pper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    Hi Fabien,

    Yes, it=E2=80=99s optional and addin= g meaningful options is one way to consider the ethical imperative http://www.cybsoc.org/heinz.htm=C2=A0

    =
    If I understand Alan=E2=80=99s tea= chings, the RS has the option to either issue one or more capabilities to t= he RO or to store some identity-related information about the RO such as th= e DID of the RO and, by reference, the AS service endpoint controlled by th= at DID.

    Given some capab= ilities, the RO can either deal with them manually or hand them to an AS. E= ither way, the RS has no idea of the RO=E2=80=99s choice until it receives = a token from some end user. This seems to be what the Letters of Transit in= Casablanca were all about.=C2=A0

    If, on the other hand, the RO chooses to give 5e RS a DID, a self= -sovereign identifier, instead of taking some capabilities, then the RS has= the expectation =C2=A0to trust tokens signed by that DID.=C2=A0

    It=E2=80=99s my hope that GNAP can= allow an ethical RS to offer both choices to the RO.

    Adrian

    =
    On Sat= , Mar 20, 2021 at 4:23 AM Fabien Imbault <fabien.imbaul= t@gmail.com> wrote:
    Hi Adrian,=C2=A0

    Calling to one AS per persona can only be optional, as we have no wa= y, and no wish, of knowing all the identities used by the RO.=C2=A0

    I think this relates to the ide= a of the RO having its own distinct agent, but I still don't understand= how that would work (even re-reading the thread in issue 145). Could you e= laborate?=C2=A0

    Thxs
    Fabien=C2=A0


    Le sam. 20 mars 2021 =C3=A0 06:= 08, Adrian Gropper <agropper@healthurl.com> a =C3= =A9crit=C2=A0:
    =
    @Alan Karp=C2=A0shared a talk = about the Principle Of Least Authority (POLA) in a recent comment=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecommen= t-803099693 I recommend it.

    We= might expect a protocol with authorization in the title to use authority a= s a core principle. I advocate for a GNAP design that maximizes the power o= f the RO, to be seen as a human rights=C2=A0issue when the RO is a human. T= his causes me to ask how to combine better security with better human right= s in GNAP.

    Who should have the least authority in = the GNAP design?

    The AS derives authority as a del= egate of the RO. If we ask the RO to partition limited authority across doz= ens of different ASs by domain and function, then we are not using technolo= gy to empower the individual. Probably the opposite, as we introduce consen= t fatigue and burden normal people to partition their lives into non-overla= pping domains.=C2=A0

    My experience says we should = aim for one AS per persona because that maps into the way we manage our pub= lic and private identities. POLA would then teach care in keeping ASs and R= Ss related to work / public separate from ASs and RSs related to private=C2= =A0life so that a policy vulnerability in our delegation to an AS would hav= e the least likelihood=C2=A0of harm.

    Beyond that f= airly obvious principle, we could spread our interactions among as many ser= vices as possible. We already do this when we spread assets across multiple= banks, internet services across redundant platforms, or we use LinkedIn, T= witter, and Facebook with limited overlap in social graphs.

    <= /div>
    At the next level down, we want to manage resources at each RS us= ing least authority in order to make AS policy vulnerabilities easier to sp= ot and debug. My AS might get multiple capabilities or access to scopes fro= m an RS, each one carefully labeled with its intended uses so that the poli= cy engine of my AS could be structured to consider requests relative to onl= y one capability or scope family at a time. For example, in issuing health = record authorizations, I might separate the behavioral health capabilities = from capabilities to access the physical parts of my record at a given hosp= ital's GNAP RS API.

    Lastly, at the level of at= tenuation, I would choose a relationship with RSs that issue to me capabili= ties that can be attenuated not only by my AS but also by the requesting pa= rties that receive them as part of an access token.

    Adrian


    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/ma= ilman/listinfo/txauth
    --000000000000710d4005bdf86feb-- From nobody Sat Mar 20 10:58:08 2021 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 2F4283A2753 for ; Sat, 20 Mar 2021 10:58:07 -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 9sD5M8_SBgv2 for ; Sat, 20 Mar 2021 10:58:04 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 556D23A2752 for ; Sat, 20 Mar 2021 10:58:04 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id 7so6395475qka.7 for ; Sat, 20 Mar 2021 10:58:04 -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=nTTpfGwLlcW5SbV0jOcm2o7hN/wQbJ4C3+0IyH3sRyM=; b=OJBos3430kiGU4EdK9ieHucfO77DoRZwTYzvHEVKHzbDSM6d2NFgAErw5fjgLlLRTt Wh/uWrjoJt0cxiTGUOyOoMhP0mdzHNkp7IH9zlnUWhVFzxOTtgRD4v1MlEeFo6mcgocJ PoDYQvsouS0U3PyYDpmityA0HCPQu+62H+eIBFvncv/iAOEk3AwAlJyNPox80HF/TfCs RY7AkZx/K4PrQnczYWY3lRE2NDMtmoENg6+A0yBRM2ir9LKoRGZtjGVue1fF6IX3Mqus +n47skwfBnT76Mo2D0lWMx4oymiav0OtKkE5K+aYsklexdm9d9S+iKsfrvVyK4PGnWcr djPQ== 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=nTTpfGwLlcW5SbV0jOcm2o7hN/wQbJ4C3+0IyH3sRyM=; b=uFA30Ay3ByHzoaByKQ+q9IvP/IZO3LUjbUtuQ/FHCra1kTOzoGm/ViVAFO2vhZzD7Q jgYvzRU3Vll3quJvKPy+GBK/a6vADtrk5KCl+5/FJEFOWU+hw7l2DszAEvvLnG5nHSqp 5poPldZF5yINCchllu1AobZtBqOI+ZEBIkaZ873ZCaHXgaMqGFGjoiQzmwc7dJkWgHt0 7+jvzBODg7qNH5fT1s71MCL93JlZglfXnVdEH3l3BeD+1oVxdMheDe9EFZaSkeRxpCxT oUYEU5Mtwhz/FFaBp78rg0sBeTxFVimKsMvHFZuI4uQigfkSZAeAjcXhzWttQdFOcUOQ bDMQ== X-Gm-Message-State: AOAM530P+YwNwAbc7ftBZ39PKtkzdEu8KV74o4f3apjfvlBuNiEOfILP CF6G3zG5khl2LpgB6UoYHvy5ENWIhWVf4U7fHXg= X-Google-Smtp-Source: ABdhPJyUSkLBLgHo9xKsePQzv9HcGFBMPXXVdf4UijlE0pCqV68F+Z37wZ7Qxd5rnM7T0mB/xTiEH6F+DgpUl7dBCH4= X-Received: by 2002:a37:2785:: with SMTP id n127mr3998799qkn.320.1616263082815; Sat, 20 Mar 2021 10:58:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alan Karp Date: Sat, 20 Mar 2021 10:57:51 -0700 Message-ID: To: Fabien Imbault Cc: Adrian Gropper , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="000000000000ea32a005bdfb9289" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2021 17:58:07 -0000 --000000000000ea32a005bdfb9289 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You are close on the flow. The only change is that the RO does not need to inform the RS that the RO is using an AS. The flow is described in our Zebra Copy tech report, https://www.hpl.hp.com/techreports/2007/HPL-2007-105.pdf, which, by the way, uses non-opaque tokens. (Don't worry about the length. The last 60 pages are a walkthrough of the reference implementation.) I believe that example is closer to the GNAP use cases than the one in the talk Adrian mentioned. Also, I hope the different terminology isn't too confusing. 1. The owner of RS delegates a set of rights to the administrator of the service, AS-RS. 2. RO contacts AS-RS and gets back a capability authorizing a specific set of methods at RS. 3. RO can use that capability to invoke RS with any of the authorized permissions. 4. RO can delegate a subset of those rights to a client, who can then invoke the RS with any of the authorized permissions. 5. RO can delegate a subset of those rights to an AS-RO. 6. AS-RO can delegate a subset of those rights to a client based on a policy specified by RO. 7. That client can invoke RO with any of the authorized permissions. Note that AS-RS doesn't need to know anything about the various delegatees. It just needs to verify that the delegations are valid. Responsibility tracking follows those steps. AS-RS will hold RO responsible for all uses of any token delegated from the one AS-RS gave RO. Each delegator is responsible for knowing who to hold responsible for each of its delegations. Say there's a $100 penalty for misuse, and the client in step 6 does something bad. AS-RS will collect $100 from RO. It's up to RO to collect $100 from AS-RO and up to AS-RO to collect from the client. This approach is the only thing that makes sense. What would RS or AS-RS do with the information that RO delegated to AS-RO? AS-RS has no way of collecting from AS-RO; only RO does. -------------- Alan Karp On Sat, Mar 20, 2021 at 3:52 AM Fabien Imbault wrote: > Thanks for the description. > > Trying to summarize what a capability flow would look like following > those ideas: > > 1) RS issues a capability for the RO. For instance "view and download > photo". > > 2) RO can delegate that capability (or an attenuated version) to the AS. > Say "view photo", possibly with some ambient conditions. > If the RO further wants to choose between a list of possible ASs, the RO > would have to signal its choice to the RS, which would then have to signa= l > it to the client (what we had called RS preflight in some discussions). S= o > the AS-RS relationship would be mediated via the RO (or more precisely it= s > agent). > > 3) a core GNAP negociation takes place with the AS (traditional photo > example). > > Is that correct? Do not hesitate to correct me if I didn't accurately > capture what you said. > (I volontarily put DID aside for now) > > Steps occurring before 3 are optional (for reasons discussed before and > also because we can't assume all RSs would be able to support that). > > Fabien > > Le sam. 20 mars 2021 =C3=A0 10:49, Adrian Gropper a > =C3=A9crit : > >> Hi Fabien, >> >> Yes, it=E2=80=99s optional and adding meaningful options is one way to c= onsider >> the ethical imperative http://www.cybsoc.org/heinz.htm >> >> If I understand Alan=E2=80=99s teachings, the RS has the option to eithe= r issue >> one or more capabilities to the RO or to store some identity-related >> information about the RO such as the DID of the RO and, by reference, th= e >> AS service endpoint controlled by that DID. >> >> Given some capabilities, the RO can either deal with them manually or >> hand them to an AS. Either way, the RS has no idea of the RO=E2=80=99s c= hoice until >> it receives a token from some end user. This seems to be what the Letter= s >> of Transit in Casablanca were all about. >> >> If, on the other hand, the RO chooses to give 5e RS a DID, a >> self-sovereign identifier, instead of taking some capabilities, then the= RS >> has the expectation to trust tokens signed by that DID. >> >> It=E2=80=99s my hope that GNAP can allow an ethical RS to offer both cho= ices to >> the RO. >> >> Adrian >> >> >> On Sat, Mar 20, 2021 at 4:23 AM Fabien Imbault >> wrote: >> >>> Hi Adrian, >>> >>> Calling to one AS per persona can only be optional, as we have no way, >>> and no wish, of knowing all the identities used by the RO. >>> >>> I think this relates to the idea of the RO having its own distinct >>> agent, but I still don't understand how that would work (even re-readin= g >>> the thread in issue 145). Could you elaborate? >>> >>> Thxs >>> Fabien >>> >>> >>> Le sam. 20 mars 2021 =C3=A0 06:08, Adrian Gropper a >>> =C3=A9crit : >>> >>>> @Alan Karp shared a talk about the Principle Of >>>> Least Authority (POLA) in a recent comment >>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecom= ment-803099693 >>>> I recommend it. >>>> >>>> We might expect a protocol with authorization in the title to use >>>> authority as a core principle. I advocate for a GNAP design that maxim= izes >>>> the power of the RO, to be seen as a human rights issue when the RO is= a >>>> human. This causes me to ask how to combine better security with bette= r >>>> human rights in GNAP. >>>> >>>> Who should have the least authority in the GNAP design? >>>> >>>> The AS derives authority as a delegate of the RO. If we ask the RO to >>>> partition limited authority across dozens of different ASs by domain a= nd >>>> function, then we are not using technology to empower the individual. >>>> Probably the opposite, as we introduce consent fatigue and burden norm= al >>>> people to partition their lives into non-overlapping domains. >>>> >>>> My experience says we should aim for one AS per persona because that >>>> maps into the way we manage our public and private identities. POLA wo= uld >>>> then teach care in keeping ASs and RSs related to work / public separa= te >>>> from ASs and RSs related to private life so that a policy vulnerabilit= y in >>>> our delegation to an AS would have the least likelihood of harm. >>>> >>>> Beyond that fairly obvious principle, we could spread our interactions >>>> among as many services as possible. We already do this when we spread >>>> assets across multiple banks, internet services across redundant platf= orms, >>>> or we use LinkedIn, Twitter, and Facebook with limited overlap in soci= al >>>> graphs. >>>> >>>> At the next level down, we want to manage resources at each RS using >>>> least authority in order to make AS policy vulnerabilities easier to s= pot >>>> and debug. My AS might get multiple capabilities or access to scopes f= rom >>>> an RS, each one carefully labeled with its intended uses so that the p= olicy >>>> engine of my AS could be structured to consider requests relative to o= nly >>>> one capability or scope family at a time. For example, in issuing heal= th >>>> record authorizations, I might separate the behavioral health capabili= ties >>>> from capabilities to access the physical parts of my record at a given >>>> hospital's GNAP RS API. >>>> >>>> Lastly, at the level of attenuation, I would choose a relationship wit= h >>>> RSs that issue to me capabilities that can be attenuated not only by m= y AS >>>> but also by the requesting parties that receive them as part of an acc= ess >>>> token. >>>> >>>> Adrian >>>> >>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> --000000000000ea32a005bdfb9289 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    You are close on the flow.=C2=A0 The only change is that t= he RO does not need to inform the RS that the RO is using an AS.=C2=A0=C2= =A0

    The flow is described in our Zebra Copy tech report,= =C2=A0= https://www.hpl.hp.com/techreports/2007/HPL-2007-105.pdf, which, by the= way, uses non-opaque tokens.=C2=A0 (Don't worry about the length.=C2= =A0 The last 60 pages are a walkthrough of the reference implementation.)= =C2=A0 I believe that example is closer to the GNAP use cases than the one = in the talk Adrian mentioned.=C2=A0 Also, I hope the different terminology = isn't too confusing.
    1. The owner of RS delegates a set of rig= hts to the administrator of the service, AS-RS.
    2. RO contacts AS-RS a= nd gets back a capability authorizing a specific set of methods at RS.
      3. =
    3. RO can use that capability to invoke RS with any of the authorized perm= issions.
    4. RO can delegate a subset of those rights to a client, who = can then invoke the RS with any of the authorized permissions.
    5. RO c= an delegate a subset of those rights to an AS-RO.
    6. AS-RO can delegat= e a subset of those rights to a client based on a policy specified by RO.
    7. That client can invoke RO with any of the authorized permissions.
    Note that AS-RS doesn't need to know anything about the var= ious delegatees.=C2=A0 It=C2=A0just needs to verify that the delegations ar= e valid.

    Responsibility tracking follows those ste= ps.=C2=A0 AS-RS will hold RO responsible for all uses of any token delegate= d from the one AS-RS gave RO.=C2=A0 Each delegator is responsible for knowi= ng who to hold responsible for each of its delegations.=C2=A0 Say there'= ;s a $100 penalty for misuse, and the client in step 6 does something bad.= =C2=A0 AS-RS will collect $100 from RO.=C2=A0 It's up to RO to collect = $100 from AS-RO and up to AS-RO to collect from the client.

    This approach is the only thing that makes sense.=C2=A0 Wha= t would RS or AS-RS do with the information that RO delegated to AS-RO?=C2= =A0 AS-RS has no way of collecting from AS-RO; only RO does.

    --------------
    Alan Karp


    On Sat, Mar = 20, 2021 at 3:52 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks for the descripti= on.=C2=A0

    Trying to summarize = what a capability=C2=A0 flow would look like following those ideas:

    1) RS issues a capability for the RO.= For instance "view and download photo".=C2=A0

    2) RO can delegate that capability (or an = attenuated version) to the AS. Say "view photo", possibly with so= me ambient conditions.=C2=A0
    If the RO further wants= to choose between a list of possible ASs, the RO would have to signal its = choice to the RS, which would then have to signal it to the client (what we= had called RS preflight in some discussions).=C2=A0So the AS-RS relationship would be mediated via the RO (or = more precisely its agent).=C2=A0

    3) a core GNAP negociation takes place with the AS (traditi= onal photo example).=C2=A0

    Is that correct? Do not hesitate to correct me if I didn't accuratel= y capture what you said.=C2=A0
    (I volontarily put DI= D aside for now)=C2=A0

    S= teps occurring before 3 are optional (for reasons discussed before and also= because we can't assume all RSs would be able to support that).=C2=A0<= /div>

    Fabien=C2=A0

    Le sam. 20 mars 2021 =C3=A0 10:49, Adrian Gropper <agropper@healthurl.com> a = =C3=A9crit=C2=A0:
    Hi Fabien,

    Yes, it=E2=80=99s optional and adding meaningful options is one= way to consider the ethical imperative http://www.cybsoc.org/heinz.h= tm=C2=A0

    = If I understand Alan=E2=80=99s teachings, the RS has the option to either i= ssue one or more capabilities to the RO or to store some identity-related i= nformation about the RO such as the DID of the RO and, by reference, the AS= service endpoint controlled by that DID.

    =
    Given some capabilities, the RO can either deal with them= manually or hand them to an AS. Either way, the RS has no idea of the RO= =E2=80=99s choice until it receives a token from some end user. This seems = to be what the Letters of Transit in Casablanca were all about.=C2=A0
    =

    If, on the other hand, the RO= chooses to give 5e RS a DID, a self-sovereign identifier, instead of takin= g some capabilities, then the RS has the expectation =C2=A0to trust tokens = signed by that DID.=C2=A0

    It=E2=80=99s my hope that GNAP can allow an ethical RS to offer both choi= ces to the RO.

    Adrian


    On Sat, Mar 20, 2021 at 4:23 AM Fabien Imbaul= t <fabien.imbault@gmail.com> wrote:
    Hi = Adrian,=C2=A0

    Calling to= one AS per persona can only be optional, as we have no way, and no wish, o= f knowing all the identities used by the RO.=C2=A0
    <= br>
    I think this relates to the idea of the RO havin= g its own distinct agent, but I still don't understand how that would w= ork (even re-reading the thread in issue 145). Could you elaborate?=C2=A0

    Thxs
    Fabien=C2=A0


    =
    Le sam. 20 mars 2021 =C3=A0 06:08, Adrian Groppe= r <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    @Alan Karp=C2= =A0shared a talk about the Principle Of Least Authority (POLA) in a recent = comment=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issue= comment-803099693 I recommend it.

    <= div>We might expect a protocol with authorization in the title to use autho= rity as a core principle. I advocate for a GNAP design that maximizes the p= ower of the RO, to be seen as a human rights=C2=A0issue when the RO is a hu= man. This causes me to ask how to combine better security with better human= rights in GNAP.

    Who should have the least authori= ty in the GNAP design?

    The AS derives authority as= a delegate of the RO. If we ask the RO to partition limited authority acro= ss dozens of different ASs by domain and function, then we are not using te= chnology to empower the individual. Probably the opposite, as we introduce = consent fatigue and burden normal people to partition their lives into non-= overlapping domains.=C2=A0

    My experience says we s= hould aim for one AS per persona because that maps into the way we manage o= ur public and private identities. POLA would then teach care in keeping ASs= and RSs related to work / public separate from ASs and RSs related to priv= ate=C2=A0life so that a policy vulnerability in our delegation to an AS wou= ld have the least likelihood=C2=A0of harm.

    Beyond = that fairly obvious principle, we could spread our interactions among as ma= ny services as possible. We already do this when we spread assets across mu= ltiple banks, internet services across redundant platforms, or we use Linke= dIn, Twitter, and Facebook with limited overlap in social graphs.

    At the next level down, we want to manage resources at each= RS using least authority in order to make AS policy vulnerabilities easier= to spot and debug. My AS might get multiple capabilities or access to scop= es from an RS, each one carefully labeled with its intended uses so that th= e policy engine of my AS could be structured to consider requests relative = to only one capability or scope family at a time. For example, in issuing h= ealth record authorizations, I might separate the behavioral health capabil= ities from capabilities to access the physical parts of my record at a give= n hospital's GNAP RS API.

    Lastly, at the level= of attenuation, I would choose a relationship with RSs that issue to me ca= pabilities that can be attenuated not only by my AS but also by the request= ing parties that receive them as part of an access token.

    Adrian


    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listi= nfo/txauth
    --000000000000ea32a005bdfb9289-- From nobody Sat Mar 20 11:22:42 2021 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 3B2E73A27E1 for ; Sat, 20 Mar 2021 11:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.097 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, 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 uoKJmK69Swby for ; Sat, 20 Mar 2021 11:22:38 -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 21EA43A27DF for ; Sat, 20 Mar 2021 11:22:38 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id k8so9614193iop.12 for ; Sat, 20 Mar 2021 11:22: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:from:date:message-id:subject:to :cc; bh=N5J8cf/uR+no5WH7IUJlTzbicem9xGosan9uvv/wJvM=; b=LmIQN4t6eDXYQV57jocSR0UiBorT0VT8zfSh7qzdQ+NRITinhOFI3b0Nnk9OYJ31y2 eMdKMCyzpnfW/+jpZJ6z7xnO0sWL4F9AiIV0rT96i3Oklz9UUzDmLXWaBFQK2UzGDqsl IJTwAxH3m41XGeNnob67rZBIAvxiudUYEN8gOjzvNHWqWM+aEQSCXlns5ekY81/s8crw 1mpR2B7H/V/NuUPsZTAI3d7Vbu1pX3tj8J99c4hxWlC4mRkoyK3j3J02WL7kQ2PJaT19 d7nWXpr+6VtgAJ0qiypgJKAUW/wEWwmHAxiq114VsAe69sQSe/YUpkmveIuijJuYSa7u GoQg== 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=N5J8cf/uR+no5WH7IUJlTzbicem9xGosan9uvv/wJvM=; b=QBdsyODqYrwWwDHzwgB5jAUVQdfoUUuB32B22Z9orTXYdcFgixGagXO7J7WaSdksJj kXGLI+Uydpifs978MGTQGLpqdA08K77yTyq36JalcPwFYZxFCuqxaGEWDsGLnCkS+m5p o7P2RCklLAXyV66Hy6hKYqLI0avYcxKNc7e59qwE0Xnz3QnyGHKn6daT2PZrezLvfAI+ baCZ1ZAaHC7QWYt56BNonozaJve/2pJs20f4gM2ANCU42Eu0cBDKvD7cegDYAWzVPKx+ tyWv8Q37eB7yLjRk69EH0zprchNzbArT22JC69RpOJ9S+TCETWB6ZEkPa990jGNUim2I FzgA== X-Gm-Message-State: AOAM531ROK9qJJeqjwNy558JVn0v/sY4qfLsvwAD1HKm0fevQ+K8N9qq sgXjwzV408vsN31PLWRt5EDeL4bWUvKaO6ng7ZYc4ta48MM= X-Google-Smtp-Source: ABdhPJzt0Y8mquCFUrbUbV+zBPyiIZYJLlaygbUDcFfp55LJVaV2IjBbvXfMDa9KDXq00kBBsmRTwa/ZmZiVCENH0kg= X-Received: by 2002:a05:6602:2018:: with SMTP id y24mr6631759iod.74.1616264556611; Sat, 20 Mar 2021 11:22:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Sat, 20 Mar 2021 19:22:21 +0100 Message-ID: To: Alan Karp Cc: Adrian Gropper , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="000000000000c28c1205bdfbea9b" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2021 18:22:41 -0000 --000000000000c28c1205bdfbea9b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alan, Thanks a lot. This looks good. I'll have a detailed look at zebra copy. Actually I was suggesting a feedback to the RS only for the worst case scenario: if the RO has the choice of AS and is different from the end-user, then the client wouldn't be able to know which AS is to be called. Fabien Le sam. 20 mars 2021 =C3=A0 18:58, Alan Karp a =C3=A9= crit : > You are close on the flow. The only change is that the RO does not need > to inform the RS that the RO is using an AS. > > The flow is described in our Zebra Copy tech report, > https://www.hpl.hp.com/techreports/2007/HPL-2007-105.pdf, which, by the > way, uses non-opaque tokens. (Don't worry about the length. The last 60 > pages are a walkthrough of the reference implementation.) I believe that > example is closer to the GNAP use cases than the one in the talk Adrian > mentioned. Also, I hope the different terminology isn't too confusing. > > 1. The owner of RS delegates a set of rights to the administrator of > the service, AS-RS. > 2. RO contacts AS-RS and gets back a capability authorizing a specific > set of methods at RS. > 3. RO can use that capability to invoke RS with any of the authorized > permissions. > 4. RO can delegate a subset of those rights to a client, who can then > invoke the RS with any of the authorized permissions. > 5. RO can delegate a subset of those rights to an AS-RO. > 6. AS-RO can delegate a subset of those rights to a client based on a > policy specified by RO. > 7. That client can invoke RO with any of the authorized permissions. > > Note that AS-RS doesn't need to know anything about the various > delegatees. It just needs to verify that the delegations are valid. > > Responsibility tracking follows those steps. AS-RS will hold RO > responsible for all uses of any token delegated from the one AS-RS gave > RO. Each delegator is responsible for knowing who to hold responsible fo= r > each of its delegations. Say there's a $100 penalty for misuse, and the > client in step 6 does something bad. AS-RS will collect $100 from RO. > It's up to RO to collect $100 from AS-RO and up to AS-RO to collect from > the client. > > This approach is the only thing that makes sense. What would RS or AS-RS > do with the information that RO delegated to AS-RO? AS-RS has no way of > collecting from AS-RO; only RO does. > > -------------- > Alan Karp > > > On Sat, Mar 20, 2021 at 3:52 AM Fabien Imbault > wrote: > >> Thanks for the description. >> >> Trying to summarize what a capability flow would look like following >> those ideas: >> >> 1) RS issues a capability for the RO. For instance "view and download >> photo". >> >> 2) RO can delegate that capability (or an attenuated version) to the AS. >> Say "view photo", possibly with some ambient conditions. >> If the RO further wants to choose between a list of possible ASs, the RO >> would have to signal its choice to the RS, which would then have to sign= al >> it to the client (what we had called RS preflight in some discussions). = So >> the AS-RS relationship would be mediated via the RO (or more precisely i= ts >> agent). >> >> 3) a core GNAP negociation takes place with the AS (traditional photo >> example). >> >> Is that correct? Do not hesitate to correct me if I didn't accurately >> capture what you said. >> (I volontarily put DID aside for now) >> >> Steps occurring before 3 are optional (for reasons discussed before and >> also because we can't assume all RSs would be able to support that). >> >> Fabien >> >> Le sam. 20 mars 2021 =C3=A0 10:49, Adrian Gropper a >> =C3=A9crit : >> >>> Hi Fabien, >>> >>> Yes, it=E2=80=99s optional and adding meaningful options is one way to = consider >>> the ethical imperative http://www.cybsoc.org/heinz.htm >>> >>> If I understand Alan=E2=80=99s teachings, the RS has the option to eith= er issue >>> one or more capabilities to the RO or to store some identity-related >>> information about the RO such as the DID of the RO and, by reference, t= he >>> AS service endpoint controlled by that DID. >>> >>> Given some capabilities, the RO can either deal with them manually or >>> hand them to an AS. Either way, the RS has no idea of the RO=E2=80=99s = choice until >>> it receives a token from some end user. This seems to be what the Lette= rs >>> of Transit in Casablanca were all about. >>> >>> If, on the other hand, the RO chooses to give 5e RS a DID, a >>> self-sovereign identifier, instead of taking some capabilities, then th= e RS >>> has the expectation to trust tokens signed by that DID. >>> >>> It=E2=80=99s my hope that GNAP can allow an ethical RS to offer both ch= oices to >>> the RO. >>> >>> Adrian >>> >>> >>> On Sat, Mar 20, 2021 at 4:23 AM Fabien Imbault >>> wrote: >>> >>>> Hi Adrian, >>>> >>>> Calling to one AS per persona can only be optional, as we have no way, >>>> and no wish, of knowing all the identities used by the RO. >>>> >>>> I think this relates to the idea of the RO having its own distinct >>>> agent, but I still don't understand how that would work (even re-readi= ng >>>> the thread in issue 145). Could you elaborate? >>>> >>>> Thxs >>>> Fabien >>>> >>>> >>>> Le sam. 20 mars 2021 =C3=A0 06:08, Adrian Gropper >>>> a =C3=A9crit : >>>> >>>>> @Alan Karp shared a talk about the Principle Of >>>>> Least Authority (POLA) in a recent comment >>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issueco= mment-803099693 >>>>> I recommend it. >>>>> >>>>> We might expect a protocol with authorization in the title to use >>>>> authority as a core principle. I advocate for a GNAP design that maxi= mizes >>>>> the power of the RO, to be seen as a human rights issue when the RO i= s a >>>>> human. This causes me to ask how to combine better security with bett= er >>>>> human rights in GNAP. >>>>> >>>>> Who should have the least authority in the GNAP design? >>>>> >>>>> The AS derives authority as a delegate of the RO. If we ask the RO to >>>>> partition limited authority across dozens of different ASs by domain = and >>>>> function, then we are not using technology to empower the individual. >>>>> Probably the opposite, as we introduce consent fatigue and burden nor= mal >>>>> people to partition their lives into non-overlapping domains. >>>>> >>>>> My experience says we should aim for one AS per persona because that >>>>> maps into the way we manage our public and private identities. POLA w= ould >>>>> then teach care in keeping ASs and RSs related to work / public separ= ate >>>>> from ASs and RSs related to private life so that a policy vulnerabili= ty in >>>>> our delegation to an AS would have the least likelihood of harm. >>>>> >>>>> Beyond that fairly obvious principle, we could spread our interaction= s >>>>> among as many services as possible. We already do this when we spread >>>>> assets across multiple banks, internet services across redundant plat= forms, >>>>> or we use LinkedIn, Twitter, and Facebook with limited overlap in soc= ial >>>>> graphs. >>>>> >>>>> At the next level down, we want to manage resources at each RS using >>>>> least authority in order to make AS policy vulnerabilities easier to = spot >>>>> and debug. My AS might get multiple capabilities or access to scopes = from >>>>> an RS, each one carefully labeled with its intended uses so that the = policy >>>>> engine of my AS could be structured to consider requests relative to = only >>>>> one capability or scope family at a time. For example, in issuing hea= lth >>>>> record authorizations, I might separate the behavioral health capabil= ities >>>>> from capabilities to access the physical parts of my record at a give= n >>>>> hospital's GNAP RS API. >>>>> >>>>> Lastly, at the level of attenuation, I would choose a relationship >>>>> with RSs that issue to me capabilities that can be attenuated not onl= y by >>>>> my AS but also by the requesting parties that receive them as part of= an >>>>> access token. >>>>> >>>>> Adrian >>>>> >>>>> >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>>> --000000000000c28c1205bdfbea9b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Alan,

    Tha= nks a lot. This looks good. I'll have a detailed look at zebra copy.=C2= =A0

    Actually I was sugge= sting a feedback to the RS only for the worst case scenario: if the RO has = the choice of AS and is different from the end-user, then the client wouldn= 't be able to know which AS is to be called.=C2=A0

    Fabien


    Le sam. 20 mars 2021 = =C3=A0 18:58, Alan Karp <alanhkar= p@gmail.com> a =C3=A9crit=C2=A0:
    You are close on the flow.=C2=A0 The only change is t= hat the RO does not need to inform the RS that the RO is using an AS.=C2=A0= =C2=A0

    The flow is described in our Zebra Copy tech repo= rt,=C2=A0https://www.hpl.hp.com/techreports/= 2007/HPL-2007-105.pdf, which, by the way, uses non-opaque tokens.=C2=A0= (Don't worry about the length.=C2=A0 The last 60 pages are a walkthrou= gh of the reference implementation.)=C2=A0 I believe that example is closer= to the GNAP use cases than the one in the talk Adrian mentioned.=C2=A0 Als= o, I hope the different terminology isn't too confusing.
    1. Th= e owner of RS delegates a set of rights to the administrator of the service= , AS-RS.
    2. RO contacts AS-RS and gets back a capability authorizing a= specific set of methods at RS.
    3. RO can use that capability to invok= e RS with any of the authorized permissions.
    4. RO can delegate a subs= et of those rights to a client, who can then invoke the RS with any of the = authorized permissions.
    5. RO can delegate a subset of those rights to= an AS-RO.
    6. AS-RO can delegate a subset of those rights to a client = based on a policy specified by RO.
    7. That client can invoke RO with a= ny of the authorized permissions.
    Note that AS-RS doesn't= need to know anything about the various delegatees.=C2=A0 It=C2=A0just nee= ds to verify that the delegations are valid.

    Respo= nsibility tracking follows those steps.=C2=A0 AS-RS will hold RO responsibl= e for all uses of any token delegated from the one AS-RS gave RO.=C2=A0 Eac= h delegator is responsible for knowing who to hold responsible for each of = its delegations.=C2=A0 Say there's a $100 penalty for misuse, and the c= lient in step 6 does something bad.=C2=A0 AS-RS will collect $100 from RO.= =C2=A0 It's up to RO to collect $100 from AS-RO and up to AS-RO to coll= ect from the client.

    This approach is the on= ly thing that makes sense.=C2=A0 What would RS or AS-RS do with the informa= tion that RO delegated to AS-RO?=C2=A0 AS-RS has no way of collecting from = AS-RO; only RO does.

    --------------
    Alan Karp


    On = Sat, Mar 20, 2021 at 3:52 AM Fabien Imbault <fabien.imbault@gmail.= com> wrote:
    Thanks for the description.=C2=A0
    Trying to summarize what a capability=C2=A0 flow w= ould look like following those ideas:

    1) RS issues a capability for the RO. For instance "view and= download photo".=C2=A0

    2) RO can delegate that capability (or an attenuated version) to the A= S. Say "view photo", possibly with some ambient conditions.=C2=A0=
    If the RO further wants to choose between a list of= possible ASs, the RO would have to signal its choice to the RS, which woul= d then have to signal it to the client (what we had called RS preflight in = some discussions).=C2=A0So the AS-RS= relationship would be mediated via the RO (or more precisely its agent).= =C2=A0

    3) a core = GNAP negociation takes place with the AS (traditional photo example).=C2=A0=

    Is that correct? Do not= hesitate to correct me if I didn't accurately capture what you said.= =C2=A0
    (I volontarily put DID aside for now)=C2=A0

    Steps occurring before 3 = are optional (for reasons discussed before and also because we can't as= sume all RSs would be able to support that).=C2=A0
    <= br>
    Fabien=C2=A0

    Le sam. 20 mars 2021 = =C3=A0 10:49, Adrian Gropper <agropper@healthurl.com> a =C3= =A9crit=C2=A0:
    <= div>
    Hi Fabien,

    Yes, it=E2=80=99s optional and adding meaningful options is one w= ay to consider the ethical imperative http://www.cybsoc.or= g/heinz.htm=C2=A0

    If I understand Alan=E2=80=99s teachings, the RS has the option t= o either issue one or more capabilities to the RO or to store some identity= -related information about the RO such as the DID of the RO and, by referen= ce, the AS service endpoint controlled by that DID.
    =
    Given some capabilities, the RO can either deal= with them manually or hand them to an AS. Either way, the RS has no idea o= f the RO=E2=80=99s choice until it receives a token from some end user. Thi= s seems to be what the Letters of Transit in Casablanca were all about.=C2= =A0

    If, on the other han= d, the RO chooses to give 5e RS a DID, a self-sovereign identifier, instead= of taking some capabilities, then the RS has the expectation =C2=A0to trus= t tokens signed by that DID.=C2=A0

    It=E2=80=99s my hope that GNAP can allow an ethical RS to offer = both choices to the RO.

    = Adrian


    On Sat, Mar 20, 2021 at 4:23 AM Fabi= en Imbault <fabien.imbault@gmail.com> wrote:
    =
    <= div dir=3D"auto">Hi Adrian,=C2=A0

    Calling to one AS per persona can only be optional, as we have no= way, and no wish, of knowing all the identities used by the RO.=C2=A0

    I think this relates to the = idea of the RO having its own distinct agent, but I still don't underst= and how that would work (even re-reading the thread in issue 145). Could yo= u elaborate?=C2=A0

    Thxs<= /div>
    Fabien=C2=A0


    Le sam. 20 mars 2021 =C3=A0= 06:08, Adrian Gropper <agropper@healthurl.com> a = =C3=A9crit=C2=A0:
    @Alan Karp=C2=A0shared a ta= lk about the Principle Of Least Authority (POLA) in a recent comment=C2=A0<= a href=3D"https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#iss= uecomment-803099693" rel=3D"noreferrer noreferrer noreferrer" target=3D"_bl= ank">https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecom= ment-803099693 I recommend it.

    We might expect a protocol with authorization in the title to use authorit= y as a core principle. I advocate for a GNAP design that maximizes the powe= r of the RO, to be seen as a human rights=C2=A0issue when the RO is a human= . This causes me to ask how to combine better security with better human ri= ghts in GNAP.

    Who should have the least authority = in the GNAP design?

    The AS derives authority as a = delegate of the RO. If we ask the RO to partition limited authority across = dozens of different ASs by domain and function, then we are not using techn= ology to empower the individual. Probably the opposite, as we introduce con= sent fatigue and burden normal people to partition their lives into non-ove= rlapping domains.=C2=A0

    My experience says we shou= ld aim for one AS per persona because that maps into the way we manage our = public and private identities. POLA would then teach care in keeping ASs an= d RSs related to work / public separate from ASs and RSs related to private= =C2=A0life so that a policy vulnerability in our delegation to an AS would = have the least likelihood=C2=A0of harm.

    Beyond tha= t fairly obvious principle, we could spread our interactions among as many = services as possible. We already do this when we spread assets across multi= ple banks, internet services across redundant platforms, or we use LinkedIn= , Twitter, and Facebook with limited overlap in social graphs.
    At the next level down, we want to manage resources at each RS= using least authority in order to make AS policy vulnerabilities easier to= spot and debug. My AS might get multiple capabilities or access to scopes = from an RS, each one carefully labeled with its intended uses so that the p= olicy engine of my AS could be structured to consider requests relative to = only one capability or scope family at a time. For example, in issuing heal= th record authorizations, I might separate the behavioral health capabiliti= es from capabilities to access the physical parts of my record at a given h= ospital's GNAP RS API.

    Lastly, at the level of= attenuation, I would choose a relationship with RSs that issue to me capab= ilities that can be attenuated not only by my AS but also by the requesting= parties that receive them as part of an access token.

    =
    Adrian


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

    --000000000000c28c1205bdfbea9b-- From nobody Sat Mar 20 13:20:27 2021 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 2D4AA3A29BD for ; Sat, 20 Mar 2021 13:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 mUuPSBiAjF2K for ; Sat, 20 Mar 2021 13:20:23 -0700 (PDT) Received: from mail-vs1-f54.google.com (mail-vs1-f54.google.com [209.85.217.54]) (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 7E3163A29BC for ; Sat, 20 Mar 2021 13:20:23 -0700 (PDT) Received: by mail-vs1-f54.google.com with SMTP id e5so5410310vse.4 for ; Sat, 20 Mar 2021 13:20:23 -0700 (PDT) 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=zVtQVOEl6e83purPY6EsTpAwzkAQs1BhkKgckkRE6PA=; b=Kfi3imDt4aUcOopw1EickXfsmcA7mIPPhFdW6SPD/itN6wtER8od/GFxekmy9f0xOm AldunCUsPYxyDxKfpU042B+V4i98KV5UAalNhEt7H3JyrVJ8cACgYTPfZ5wZfRET5FeS IZIQRtEz9mKAXJLRe8APUiXrZZo0Vr/TyVV5GzZKlt8MJKoB+A6FXX7xbwZuOJcYvEx5 Slr4Ax+ipOU8p1uoerkwBR8Ah65fMWOve89rut3UrCoZqQy/qhxSo5M3NhURqBpg1DXq q5lGTFwbs0qtnAGnpLI5PTN9/HuLrlaRa9oC0HgYG8fo7fE9U3jRLJy+3T59b+X9H8Ht +fvQ== X-Gm-Message-State: AOAM530UX1y2HXAY85LWg+O9QdhQiJ1f7LUqIRq5CeHc9O673iPjEppQ Qa02HLOuSN6RtRfXjyXbKmqT1Ue3cGXBFlO4e7I= X-Google-Smtp-Source: ABdhPJx4wUKu+eScedm7ec1FmENjZIzfp74qO6JuGQiA1qzHi70j1mHqiraPUTMHAcQadAJohBwtAkpUvzAss07GIwU= X-Received: by 2002:a67:cb87:: with SMTP id h7mr5896969vsl.33.1616271622478; Sat, 20 Mar 2021 13:20:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Adrian Gropper Date: Sat, 20 Mar 2021 16:20:11 -0400 Message-ID: To: Alan Karp Cc: Fabien Imbault , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="000000000000eb201f05bdfd8fd7" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2021 20:20:26 -0000 --000000000000eb201f05bdfd8fd7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To be clear, I'm suggesting that GNAP standardize two separate flows if necessary and give the RS the option of supporting one or both of them. - Option 1 is capabilities and exactly as Alan just outlined where the RO does not need to inform the RS that it is using an AS. - Option 2 is an RO-controlled AS as might be linked to a DID service endpoint. Adrian On Sat, Mar 20, 2021 at 1:58 PM Alan Karp wrote: > You are close on the flow. The only change is that the RO does not need > to inform the RS that the RO is using an AS. > > The flow is described in our Zebra Copy tech report, > https://www.hpl.hp.com/techreports/2007/HPL-2007-105.pdf, which, by the > way, uses non-opaque tokens. (Don't worry about the length. The last 60 > pages are a walkthrough of the reference implementation.) I believe that > example is closer to the GNAP use cases than the one in the talk Adrian > mentioned. Also, I hope the different terminology isn't too confusing. > > 1. The owner of RS delegates a set of rights to the administrator of > the service, AS-RS. > 2. RO contacts AS-RS and gets back a capability authorizing a specific > set of methods at RS. > 3. RO can use that capability to invoke RS with any of the authorized > permissions. > 4. RO can delegate a subset of those rights to a client, who can then > invoke the RS with any of the authorized permissions. > 5. RO can delegate a subset of those rights to an AS-RO. > 6. AS-RO can delegate a subset of those rights to a client based on a > policy specified by RO. > 7. That client can invoke RO with any of the authorized permissions. > > Note that AS-RS doesn't need to know anything about the various > delegatees. It just needs to verify that the delegations are valid. > > Responsibility tracking follows those steps. AS-RS will hold RO > responsible for all uses of any token delegated from the one AS-RS gave > RO. Each delegator is responsible for knowing who to hold responsible fo= r > each of its delegations. Say there's a $100 penalty for misuse, and the > client in step 6 does something bad. AS-RS will collect $100 from RO. > It's up to RO to collect $100 from AS-RO and up to AS-RO to collect from > the client. > > This approach is the only thing that makes sense. What would RS or AS-RS > do with the information that RO delegated to AS-RO? AS-RS has no way of > collecting from AS-RO; only RO does. > > -------------- > Alan Karp > > > On Sat, Mar 20, 2021 at 3:52 AM Fabien Imbault > wrote: > >> Thanks for the description. >> >> Trying to summarize what a capability flow would look like following >> those ideas: >> >> 1) RS issues a capability for the RO. For instance "view and download >> photo". >> >> 2) RO can delegate that capability (or an attenuated version) to the AS. >> Say "view photo", possibly with some ambient conditions. >> If the RO further wants to choose between a list of possible ASs, the RO >> would have to signal its choice to the RS, which would then have to sign= al >> it to the client (what we had called RS preflight in some discussions). = So >> the AS-RS relationship would be mediated via the RO (or more precisely i= ts >> agent). >> >> 3) a core GNAP negociation takes place with the AS (traditional photo >> example). >> >> Is that correct? Do not hesitate to correct me if I didn't accurately >> capture what you said. >> (I volontarily put DID aside for now) >> >> Steps occurring before 3 are optional (for reasons discussed before and >> also because we can't assume all RSs would be able to support that). >> >> Fabien >> >> Le sam. 20 mars 2021 =C3=A0 10:49, Adrian Gropper a >> =C3=A9crit : >> >>> Hi Fabien, >>> >>> Yes, it=E2=80=99s optional and adding meaningful options is one way to = consider >>> the ethical imperative http://www.cybsoc.org/heinz.htm >>> >>> If I understand Alan=E2=80=99s teachings, the RS has the option to eith= er issue >>> one or more capabilities to the RO or to store some identity-related >>> information about the RO such as the DID of the RO and, by reference, t= he >>> AS service endpoint controlled by that DID. >>> >>> Given some capabilities, the RO can either deal with them manually or >>> hand them to an AS. Either way, the RS has no idea of the RO=E2=80=99s = choice until >>> it receives a token from some end user. This seems to be what the Lette= rs >>> of Transit in Casablanca were all about. >>> >>> If, on the other hand, the RO chooses to give 5e RS a DID, a >>> self-sovereign identifier, instead of taking some capabilities, then th= e RS >>> has the expectation to trust tokens signed by that DID. >>> >>> It=E2=80=99s my hope that GNAP can allow an ethical RS to offer both ch= oices to >>> the RO. >>> >>> Adrian >>> >>> >>> On Sat, Mar 20, 2021 at 4:23 AM Fabien Imbault >>> wrote: >>> >>>> Hi Adrian, >>>> >>>> Calling to one AS per persona can only be optional, as we have no way, >>>> and no wish, of knowing all the identities used by the RO. >>>> >>>> I think this relates to the idea of the RO having its own distinct >>>> agent, but I still don't understand how that would work (even re-readi= ng >>>> the thread in issue 145). Could you elaborate? >>>> >>>> Thxs >>>> Fabien >>>> >>>> >>>> Le sam. 20 mars 2021 =C3=A0 06:08, Adrian Gropper >>>> a =C3=A9crit : >>>> >>>>> @Alan Karp shared a talk about the Principle Of >>>>> Least Authority (POLA) in a recent comment >>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issueco= mment-803099693 >>>>> I recommend it. >>>>> >>>>> We might expect a protocol with authorization in the title to use >>>>> authority as a core principle. I advocate for a GNAP design that maxi= mizes >>>>> the power of the RO, to be seen as a human rights issue when the RO i= s a >>>>> human. This causes me to ask how to combine better security with bett= er >>>>> human rights in GNAP. >>>>> >>>>> Who should have the least authority in the GNAP design? >>>>> >>>>> The AS derives authority as a delegate of the RO. If we ask the RO to >>>>> partition limited authority across dozens of different ASs by domain = and >>>>> function, then we are not using technology to empower the individual. >>>>> Probably the opposite, as we introduce consent fatigue and burden nor= mal >>>>> people to partition their lives into non-overlapping domains. >>>>> >>>>> My experience says we should aim for one AS per persona because that >>>>> maps into the way we manage our public and private identities. POLA w= ould >>>>> then teach care in keeping ASs and RSs related to work / public separ= ate >>>>> from ASs and RSs related to private life so that a policy vulnerabili= ty in >>>>> our delegation to an AS would have the least likelihood of harm. >>>>> >>>>> Beyond that fairly obvious principle, we could spread our interaction= s >>>>> among as many services as possible. We already do this when we spread >>>>> assets across multiple banks, internet services across redundant plat= forms, >>>>> or we use LinkedIn, Twitter, and Facebook with limited overlap in soc= ial >>>>> graphs. >>>>> >>>>> At the next level down, we want to manage resources at each RS using >>>>> least authority in order to make AS policy vulnerabilities easier to = spot >>>>> and debug. My AS might get multiple capabilities or access to scopes = from >>>>> an RS, each one carefully labeled with its intended uses so that the = policy >>>>> engine of my AS could be structured to consider requests relative to = only >>>>> one capability or scope family at a time. For example, in issuing hea= lth >>>>> record authorizations, I might separate the behavioral health capabil= ities >>>>> from capabilities to access the physical parts of my record at a give= n >>>>> hospital's GNAP RS API. >>>>> >>>>> Lastly, at the level of attenuation, I would choose a relationship >>>>> with RSs that issue to me capabilities that can be attenuated not onl= y by >>>>> my AS but also by the requesting parties that receive them as part of= an >>>>> access token. >>>>> >>>>> Adrian >>>>> >>>>> >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> --000000000000eb201f05bdfd8fd7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    To be clear, I'm suggesting that GNAP standardize two = separate flows if necessary and give the RS the option of supporting one or= both of them.
    - Option 1 is capabilities and exactly as Alan just outl= ined where the RO does not need to inform the RS that it is using an AS.
    - Option 2 is an RO-controlled AS as might be linked to a DID servi= ce endpoint.

    Adrian=C2=A0

    On Sat, Mar 20, 202= 1 at 1:58 PM Alan Karp <alanhkarp= @gmail.com> wrote:
    You a= re close on the flow.=C2=A0 The only change is that the RO does not need to= inform the RS that the RO is using an AS.=C2=A0=C2=A0

    T= he flow is described in our Zebra Copy tech report,=C2=A0https:= //www.hpl.hp.com/techreports/2007/HPL-2007-105.pdf, which, by the way, = uses non-opaque tokens.=C2=A0 (Don't worry about the length.=C2=A0 The = last 60 pages are a walkthrough of the reference implementation.)=C2=A0 I b= elieve that example is closer to the GNAP use cases than the one in the tal= k Adrian mentioned.=C2=A0 Also, I hope the different terminology isn't = too confusing.
    1. The owner of RS delegates a set of rights to the= administrator of the service, AS-RS.
    2. RO contacts AS-RS and gets ba= ck a capability authorizing a specific set of methods at RS.
    3. RO can= use that capability to invoke RS with any of the authorized permissions.
    4. RO can delegate a subset of those rights to a client, who can then i= nvoke the RS with any of the authorized permissions.
    5. RO can delegat= e a subset of those rights to an AS-RO.
    6. AS-RO can delegate a subset= of those rights to a client based on a policy specified by RO.
    7. Tha= t client can invoke RO with any of the authorized permissions.
    Note that AS-RS doesn't need to know anything about the various deleg= atees.=C2=A0 It=C2=A0just needs to verify that the delegations are valid.

    Responsibility tracking follows those steps.=C2=A0 = AS-RS will hold RO responsible for all uses of any token delegated from the= one AS-RS gave RO.=C2=A0 Each delegator is responsible for knowing who to = hold responsible for each of its delegations.=C2=A0 Say there's a $100 = penalty for misuse, and the client in step 6 does something bad.=C2=A0 AS-R= S will collect $100 from RO.=C2=A0 It's up to RO to collect $100 from A= S-RO and up to AS-RO to collect from the client.

    =
    This approach is the only thing that makes sense.=C2=A0 What would RS = or AS-RS do with the information that RO delegated to AS-RO?=C2=A0 AS-RS ha= s no way of collecting from AS-RO; only RO does.

    --------------
    Alan Karp


    =
    On Sat, Ma= r 20, 2021 at 3:52 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks for the description.=C2=A0

    Trying to summarize what a capabil= ity=C2=A0 flow would look like following those ideas:

    =
    1) RS issues a capability for the RO. For instance = "view and download photo".=C2=A0

    2) RO can delegate that capability (or an attenuated ver= sion) to the AS. Say "view photo", possibly with some ambient con= ditions.=C2=A0
    If the RO further wants to choose bet= ween a list of possible ASs, the RO would have to signal its choice to the = RS, which would then have to signal it to the client (what we had called RS= preflight in some discussions).=C2=A0So the AS-RS relationship would be mediated via the RO (or more precisely= its agent).=C2=A0

    3) a core GNAP negociation takes place with the AS (traditional photo exa= mple).=C2=A0

    Is that cor= rect? Do not hesitate to correct me if I didn't accurately capture what= you said.=C2=A0
    (I volontarily put DID aside for no= w)=C2=A0

    Steps occurring= before 3 are optional (for reasons discussed before and also because we ca= n't assume all RSs would be able to support that).=C2=A0

    Fabien=C2=A0

    Le sam. 20 m= ars 2021 =C3=A0 10:49, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2= =A0:
    Hi Fabien,

    Yes, it=E2=80=99s optional and add= ing meaningful options is one way to consider the ethical imperative = http://www.cybsoc.org/heinz.htm=C2=A0

    =
    If I understand Alan=E2=80=99s teachings, the = RS has the option to either issue one or more capabilities to the RO or to = store some identity-related information about the RO such as the DID of the= RO and, by reference, the AS service endpoint controlled by that DID.

    Given some capabilities, the= RO can either deal with them manually or hand them to an AS. Either way, t= he RS has no idea of the RO=E2=80=99s choice until it receives a token from= some end user. This seems to be what the Letters of Transit in Casablanca = were all about.=C2=A0

    If= , on the other hand, the RO chooses to give 5e RS a DID, a self-sovereign i= dentifier, instead of taking some capabilities, then the RS has the expecta= tion =C2=A0to trust tokens signed by that DID.=C2=A0

    It=E2=80=99s my hope that GNAP can allow an et= hical RS to offer both choices to the RO.

    =
    Adrian


    On Sat, Mar 20, 20= 21 at 4:23 AM Fabien Imbault <fabien.imbault@gmail.com> wro= te:
    Hi Adrian= ,=C2=A0

    Calling to one A= S per persona can only be optional, as we have no way, and no wish, of know= ing all the identities used by the RO.=C2=A0

    I think this relates to the idea of the RO having its = own distinct agent, but I still don't understand how that would work (e= ven re-reading the thread in issue 145). Could you elaborate?=C2=A0

    Thxs
    Fab= ien=C2=A0


    =
    Le sam. 20 mars 2021 =C3=A0 06:08, Adrian Gropper <= agropper@healthurl.com> a =C3=A9crit=C2=A0:
    @Alan Karp=C2=A0shared a t= alk about the Principle Of Least Authority (POLA) in a recent comment=C2=A0= https= ://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-80309= 9693 I recommend it.

    We might = expect a protocol with authorization in the title to use authority as a cor= e principle. I advocate for a GNAP design that maximizes the power of the R= O, to be seen as a human rights=C2=A0issue when the RO is a human. This cau= ses me to ask how to combine better security with better human rights in GN= AP.

    Who should have the least authority in the GNA= P design?

    The AS derives authority as a delegate o= f the RO. If we ask the RO to partition limited authority across dozens of = different ASs by domain and function, then we are not using technology to e= mpower the individual. Probably the opposite, as we introduce consent fatig= ue and burden normal people to partition their lives into non-overlapping d= omains.=C2=A0

    My experience says we should aim for= one AS per persona because that maps into the way we manage our public and= private identities. POLA would then teach care in keeping ASs and RSs rela= ted to work / public separate from ASs and RSs related to private=C2=A0life= so that a policy vulnerability in our delegation to an AS would have the l= east likelihood=C2=A0of harm.

    Beyond that fairly o= bvious principle, we could spread our interactions among as many services a= s possible. We already do this when we spread assets across multiple banks,= internet services across redundant platforms, or we use LinkedIn, Twitter,= and Facebook with limited overlap in social graphs.

    At the next level down, we want to manage resources at each RS using lea= st authority in order to make AS policy vulnerabilities easier to spot and = debug. My AS might get multiple capabilities or access to scopes from an RS= , each one carefully labeled with its intended uses so that the policy engi= ne of my AS could be structured to consider requests relative to only one c= apability or scope family at a time. For example, in issuing health record = authorizations, I might separate the behavioral health capabilities from ca= pabilities to access the physical parts of my record at a given hospital= 9;s GNAP RS API.

    Lastly, at the level of attenuati= on, I would choose a relationship with RSs that issue to me capabilities th= at can be attenuated not only by my AS but also by the requesting parties t= hat receive them as part of an access token.

    Adria= n


    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listi= nfo/txauth
    --000000000000eb201f05bdfd8fd7-- From nobody Sat Mar 20 13:58:30 2021 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 2283D3A2A6B for ; Sat, 20 Mar 2021 13:58: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 O4qauM-ZVzN0 for ; Sat, 20 Mar 2021 13:58:26 -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 7CE6A3A2A6A for ; Sat, 20 Mar 2021 13:58:26 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id d10so4507300ils.5 for ; Sat, 20 Mar 2021 13:58:26 -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=LSOeN7EcXavv0OkFIfIJphk5seO6RmCUFWJKs+2p2w4=; b=Awm99kYwaoiTKa0OR/xvN1gdRAgasoE7d7ElPAfnCOKGdl2MQsnyxd6sCGDjgq/VTZ 2FrWDAG3666o3qjEHGmGIHj+H5uXJrrpgGaU6VCP2jQtGS1/3qtuUMBh72LJKImtBBZ7 cYxvYjESeMzCcsD71/9cBW1+mdBcX19YYvAphsQ4N+9ykXswGboszWmomGeyBN7kCwek dR7n78WmNr/YmlIxBq7aJ3bu2ph9B7KsXS7Gnsh+ltlpx+HN4I8FMNLjt6mY5YlK01cf lKkWwcoyAARnXzVjgg8fvqmbGveF0J+p+EPeyU+TsUSmR6y6Jjoxd6KlaF06r2kbXO1s FNRg== 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=LSOeN7EcXavv0OkFIfIJphk5seO6RmCUFWJKs+2p2w4=; b=ZCWtyt8+NFlnNePYq8pnvKyhn9Wx0E+DcNOjkYwkOsiXjHMmB5Iks4Dd11u0+tlvmV eJMl63BKeSu0CnD2D6PeyYGRTbQJDc+rhWAfVvfbmvHkm7kWlH2IJbruFy27T/sdJi3Y 0Y1wCD3ReAIR7emfZB5e9u9TiC+O4GWLkzJVxhMghA8gnkWUs76nDs9qgjfB1wOS+FFq ZUTThBbROTFNcUzlPTKySBCzvfjgdiORIQOjMF6gxXQMSQLFet6kN/3RoZD3CnXgl+UN uvzitUFDOtgyYI4sCtxEcRKWg1ftrlK0k6iTSDDBcyOkfcdbzth4o716K5jLl/RMGwtH hlfA== X-Gm-Message-State: AOAM533LQoAr6edtduhz8U+1TlKuksdBLLvRVmtFFqjx9G0DVG1sFXlc uFgVhZDrlU12vEXf1DEFZ7OyFWtiIb2Sc5ZtGM8= X-Google-Smtp-Source: ABdhPJy6AcbTjxXTxopYFScsRSs1dWSVdXVFSnR5rakLI2/lE2e8Ke2VaBq49sadT24+x7k0FcNkCNAYOliTEUqRnwY= X-Received: by 2002:a92:1a11:: with SMTP id a17mr7199989ila.188.1616273904781; Sat, 20 Mar 2021 13:58:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Sat, 20 Mar 2021 21:58:11 +0100 Message-ID: To: Adrian Gropper Cc: Alan Karp , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="000000000000f44e5705bdfe179b" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2021 20:58:29 -0000 --000000000000f44e5705bdfe179b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable OK fine then. I just remembered that you suggested a choice between several AS-RSs by the RO. If that's not the case, there's no problem. Fabien Le sam. 20 mars 2021 =C3=A0 21:20, Adrian Gropper = a =C3=A9crit : > To be clear, I'm suggesting that GNAP standardize two separate flows if > necessary and give the RS the option of supporting one or both of them. > - Option 1 is capabilities and exactly as Alan just outlined where the RO > does not need to inform the RS that it is using an AS. > - Option 2 is an RO-controlled AS as might be linked to a DID service > endpoint. > > Adrian > > On Sat, Mar 20, 2021 at 1:58 PM Alan Karp wrote: > >> You are close on the flow. The only change is that the RO does not need >> to inform the RS that the RO is using an AS. >> >> The flow is described in our Zebra Copy tech report, >> https://www.hpl.hp.com/techreports/2007/HPL-2007-105.pdf, which, by the >> way, uses non-opaque tokens. (Don't worry about the length. The last 6= 0 >> pages are a walkthrough of the reference implementation.) I believe tha= t >> example is closer to the GNAP use cases than the one in the talk Adrian >> mentioned. Also, I hope the different terminology isn't too confusing. >> >> 1. The owner of RS delegates a set of rights to the administrator of >> the service, AS-RS. >> 2. RO contacts AS-RS and gets back a capability authorizing a >> specific set of methods at RS. >> 3. RO can use that capability to invoke RS with any of the authorized >> permissions. >> 4. RO can delegate a subset of those rights to a client, who can then >> invoke the RS with any of the authorized permissions. >> 5. RO can delegate a subset of those rights to an AS-RO. >> 6. AS-RO can delegate a subset of those rights to a client based on a >> policy specified by RO. >> 7. That client can invoke RO with any of the authorized permissions. >> >> Note that AS-RS doesn't need to know anything about the various >> delegatees. It just needs to verify that the delegations are valid. >> >> Responsibility tracking follows those steps. AS-RS will hold RO >> responsible for all uses of any token delegated from the one AS-RS gave >> RO. Each delegator is responsible for knowing who to hold responsible f= or >> each of its delegations. Say there's a $100 penalty for misuse, and the >> client in step 6 does something bad. AS-RS will collect $100 from RO. >> It's up to RO to collect $100 from AS-RO and up to AS-RO to collect from >> the client. >> >> This approach is the only thing that makes sense. What would RS or AS-R= S >> do with the information that RO delegated to AS-RO? AS-RS has no way of >> collecting from AS-RO; only RO does. >> >> -------------- >> Alan Karp >> >> >> On Sat, Mar 20, 2021 at 3:52 AM Fabien Imbault >> wrote: >> >>> Thanks for the description. >>> >>> Trying to summarize what a capability flow would look like following >>> those ideas: >>> >>> 1) RS issues a capability for the RO. For instance "view and download >>> photo". >>> >>> 2) RO can delegate that capability (or an attenuated version) to the AS= . >>> Say "view photo", possibly with some ambient conditions. >>> If the RO further wants to choose between a list of possible ASs, the R= O >>> would have to signal its choice to the RS, which would then have to sig= nal >>> it to the client (what we had called RS preflight in some discussions).= So >>> the AS-RS relationship would be mediated via the RO (or more precisely = its >>> agent). >>> >>> 3) a core GNAP negociation takes place with the AS (traditional photo >>> example). >>> >>> Is that correct? Do not hesitate to correct me if I didn't accurately >>> capture what you said. >>> (I volontarily put DID aside for now) >>> >>> Steps occurring before 3 are optional (for reasons discussed before and >>> also because we can't assume all RSs would be able to support that). >>> >>> Fabien >>> >>> Le sam. 20 mars 2021 =C3=A0 10:49, Adrian Gropper a >>> =C3=A9crit : >>> >>>> Hi Fabien, >>>> >>>> Yes, it=E2=80=99s optional and adding meaningful options is one way to= consider >>>> the ethical imperative http://www.cybsoc.org/heinz.htm >>>> >>>> If I understand Alan=E2=80=99s teachings, the RS has the option to eit= her issue >>>> one or more capabilities to the RO or to store some identity-related >>>> information about the RO such as the DID of the RO and, by reference, = the >>>> AS service endpoint controlled by that DID. >>>> >>>> Given some capabilities, the RO can either deal with them manually or >>>> hand them to an AS. Either way, the RS has no idea of the RO=E2=80=99s= choice until >>>> it receives a token from some end user. This seems to be what the Lett= ers >>>> of Transit in Casablanca were all about. >>>> >>>> If, on the other hand, the RO chooses to give 5e RS a DID, a >>>> self-sovereign identifier, instead of taking some capabilities, then t= he RS >>>> has the expectation to trust tokens signed by that DID. >>>> >>>> It=E2=80=99s my hope that GNAP can allow an ethical RS to offer both c= hoices to >>>> the RO. >>>> >>>> Adrian >>>> >>>> >>>> On Sat, Mar 20, 2021 at 4:23 AM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Hi Adrian, >>>>> >>>>> Calling to one AS per persona can only be optional, as we have no way= , >>>>> and no wish, of knowing all the identities used by the RO. >>>>> >>>>> I think this relates to the idea of the RO having its own distinct >>>>> agent, but I still don't understand how that would work (even re-read= ing >>>>> the thread in issue 145). Could you elaborate? >>>>> >>>>> Thxs >>>>> Fabien >>>>> >>>>> >>>>> Le sam. 20 mars 2021 =C3=A0 06:08, Adrian Gropper >>>>> a =C3=A9crit : >>>>> >>>>>> @Alan Karp shared a talk about the Principle >>>>>> Of Least Authority (POLA) in a recent comment >>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuec= omment-803099693 >>>>>> I recommend it. >>>>>> >>>>>> We might expect a protocol with authorization in the title to use >>>>>> authority as a core principle. I advocate for a GNAP design that max= imizes >>>>>> the power of the RO, to be seen as a human rights issue when the RO = is a >>>>>> human. This causes me to ask how to combine better security with bet= ter >>>>>> human rights in GNAP. >>>>>> >>>>>> Who should have the least authority in the GNAP design? >>>>>> >>>>>> The AS derives authority as a delegate of the RO. If we ask the RO t= o >>>>>> partition limited authority across dozens of different ASs by domain= and >>>>>> function, then we are not using technology to empower the individual= . >>>>>> Probably the opposite, as we introduce consent fatigue and burden no= rmal >>>>>> people to partition their lives into non-overlapping domains. >>>>>> >>>>>> My experience says we should aim for one AS per persona because that >>>>>> maps into the way we manage our public and private identities. POLA = would >>>>>> then teach care in keeping ASs and RSs related to work / public sepa= rate >>>>>> from ASs and RSs related to private life so that a policy vulnerabil= ity in >>>>>> our delegation to an AS would have the least likelihood of harm. >>>>>> >>>>>> Beyond that fairly obvious principle, we could spread our >>>>>> interactions among as many services as possible. We already do this = when we >>>>>> spread assets across multiple banks, internet services across redund= ant >>>>>> platforms, or we use LinkedIn, Twitter, and Facebook with limited ov= erlap >>>>>> in social graphs. >>>>>> >>>>>> At the next level down, we want to manage resources at each RS using >>>>>> least authority in order to make AS policy vulnerabilities easier to= spot >>>>>> and debug. My AS might get multiple capabilities or access to scopes= from >>>>>> an RS, each one carefully labeled with its intended uses so that the= policy >>>>>> engine of my AS could be structured to consider requests relative to= only >>>>>> one capability or scope family at a time. For example, in issuing he= alth >>>>>> record authorizations, I might separate the behavioral health capabi= lities >>>>>> from capabilities to access the physical parts of my record at a giv= en >>>>>> hospital's GNAP RS API. >>>>>> >>>>>> Lastly, at the level of attenuation, I would choose a relationship >>>>>> with RSs that issue to me capabilities that can be attenuated not on= ly by >>>>>> my AS but also by the requesting parties that receive them as part o= f an >>>>>> access token. >>>>>> >>>>>> Adrian >>>>>> >>>>>> >>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>> --000000000000f44e5705bdfe179b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    OK fine then.

    I ju= st remembered that you suggested a choice between several AS-RSs by the RO.= If that's not the case, there's no problem.

    Fabien=C2=A0

    Le sam. 20 mars 2021= =C3=A0 21:20, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    To be clear, I'm suggesting that GNAP= standardize two separate flows if necessary and give the RS the option of = supporting one or both of them.
    - Option 1 is capabilities and exactly = as Alan just outlined where the RO does not need to inform the RS that it i= s using an AS.
    - Option 2 is an RO-controlled AS as might be link= ed to a DID service endpoint.

    Adrian=C2=A0

    On= Sat, Mar 20, 2021 at 1:58 PM Alan Karp <alanhkarp@gmail.com> wr= ote:
    You are close on the flow.= =C2=A0 The only change is that the RO does not need to inform the RS that t= he RO is using an AS.=C2=A0=C2=A0

    The flow is described = in our Zebra Copy tech report,=C2=A0https://= www.hpl.hp.com/techreports/2007/HPL-2007-105.pdf, which, by the way, us= es non-opaque tokens.=C2=A0 (Don't worry about the length.=C2=A0 The la= st 60 pages are a walkthrough of the reference implementation.)=C2=A0 I bel= ieve that example is closer to the GNAP use cases than the one in the talk = Adrian mentioned.=C2=A0 Also, I hope the different terminology isn't to= o confusing.
    1. The owner of RS delegates a set of rights to the a= dministrator of the service, AS-RS.
    2. RO contacts AS-RS and gets back= a capability authorizing a specific set of methods at RS.
    3. RO can u= se that capability to invoke RS with any of the authorized permissions.
    4. RO can delegate a subset of those rights to a client, who can then inv= oke the RS with any of the authorized permissions.
    5. RO can delegate = a subset of those rights to an AS-RO.
    6. AS-RO can delegate a subset o= f those rights to a client based on a policy specified by RO.
    7. That = client can invoke RO with any of the authorized permissions.
    = Note that AS-RS doesn't need to know anything about the various delegat= ees.=C2=A0 It=C2=A0just needs to verify that the delegations are valid.

    Responsibility tracking follows those steps.=C2=A0 AS= -RS will hold RO responsible for all uses of any token delegated from the o= ne AS-RS gave RO.=C2=A0 Each delegator is responsible for knowing who to ho= ld responsible for each of its delegations.=C2=A0 Say there's a $100 pe= nalty for misuse, and the client in step 6 does something bad.=C2=A0 AS-RS = will collect $100 from RO.=C2=A0 It's up to RO to collect $100 from AS-= RO and up to AS-RO to collect from the client.

    This approach is the only thing that makes sense.=C2=A0 What would RS or= AS-RS do with the information that RO delegated to AS-RO?=C2=A0 AS-RS has = no way of collecting from AS-RO; only RO does.

    --------------
    Alan Karp


    On Sat, Mar = 20, 2021 at 3:52 AM Fabien Imbault <fabien.imbault@gmail.com&g= t; wrote:
    Thanks for the descri= ption.=C2=A0

    Trying to summari= ze what a capability=C2=A0 flow would look like following those ideas:

    1) RS issues a capability for the = RO. For instance "view and download photo".=C2=A0

    2) RO can delegate that capability (o= r an attenuated version) to the AS. Say "view photo", possibly wi= th some ambient conditions.=C2=A0
    If the RO further = wants to choose between a list of possible ASs, the RO would have to signal= its choice to the RS, which would then have to signal it to the client (wh= at we had called RS preflight in some discussions).=C2=A0So the AS-RS relationship would be mediated via the RO= (or more precisely its agent).=C2=A0

    3) a core GNAP negociation takes place with the AS (tr= aditional photo example).=C2=A0

    Is that correct? Do not hesitate to correct me if I didn't ac= curately capture what you said.=C2=A0
    (I volontarily= put DID aside for now)=C2=A0

    Steps occurring before 3 are optional (for reasons discussed before a= nd also because we can't assume all RSs would be able to support that).= =C2=A0

    Fabien=C2=A0
    Le sam. 20 mars 2021 =C3=A0 10:49, Adrian Gropper <agropper@= healthurl.com> a =C3=A9crit=C2=A0:
    Hi Fabien,

    Yes, it=E2=80=99s optional and adding meaningful options is one way to c= onsider the ethical imperative http://www.cybsoc.org/heinz= .htm=C2=A0

    If I understand Alan=E2=80=99s teachings, the RS has the option to either= issue one or more capabilities to the RO or to store some identity-related= information about the RO such as the DID of the RO and, by reference, the = AS service endpoint controlled by that DID.

    Given some capabilities, the RO can either deal with th= em manually or hand them to an AS. Either way, the RS has no idea of the RO= =E2=80=99s choice until it receives a token from some end user. This seems = to be what the Letters of Transit in Casablanca were all about.=C2=A0
    =

    If, on the other hand, the RO= chooses to give 5e RS a DID, a self-sovereign identifier, instead of takin= g some capabilities, then the RS has the expectation =C2=A0to trust tokens = signed by that DID.=C2=A0

    It=E2=80=99s my hope that GNAP can allow an ethical RS to offer both choi= ces to the RO.

    Adrian


    On Sat, Mar 20, 2021 at 4:23 AM Fabien Imbaul= t <fabien.imbault@gmail.com> wrote:
    Hi Adrian,=C2=A0

    Calling to one AS per persona ca= n only be optional, as we have no way, and no wish, of knowing all the iden= tities used by the RO.=C2=A0

    I think this relates to the idea of the RO having its own distinct age= nt, but I still don't understand how that would work (even re-reading t= he thread in issue 145). Could you elaborate?=C2=A0
    =
    Thxs
    Fabien=C2=A0
    <= br>
    Le sam. 20 mars 2021 =C3=A0 06:08, Adrian Gropper <a= gropper@healthurl.com> a =C3=A9crit=C2=A0:
    @Alan= Karp=C2=A0shared a talk about the Principle Of Least Authority (POLA) = in a recent comment=C2=A0https://github.com/ietf-wg-gnap/gnap-core-pr= otocol/issues/145#issuecomment-803099693 I recommend it.

    We might expect a protocol with authorization in= the title to use authority as a core principle. I advocate for a GNAP desi= gn that maximizes the power of the RO, to be seen as a human rights=C2=A0is= sue when the RO is a human. This causes me to ask how to combine better sec= urity with better human rights in GNAP.

    Who should= have the least authority in the GNAP design?

    The = AS derives authority as a delegate of the RO. If we ask the RO to partition= limited authority across dozens of different ASs by domain and function, t= hen we are not using technology to empower the individual. Probably the opp= osite, as we introduce consent fatigue and burden normal people to partitio= n their lives into non-overlapping domains.=C2=A0

    = My experience says we should aim for one AS per persona because that maps i= nto the way we manage our public and private identities. POLA would then te= ach care in keeping ASs and RSs related to work / public separate from ASs = and RSs related to private=C2=A0life so that a policy vulnerability in our = delegation to an AS would have the least likelihood=C2=A0of harm.

    Beyond that fairly obvious principle, we could spread our i= nteractions among as many services as possible. We already do this when we = spread assets across multiple banks, internet services across redundant pla= tforms, or we use LinkedIn, Twitter, and Facebook with limited overlap in s= ocial graphs.

    At the next level down, we want to m= anage resources at each RS using least authority in order to make AS policy= vulnerabilities easier to spot and debug. My AS might get multiple capabil= ities or access to scopes from an RS, each one carefully labeled with its i= ntended uses so that the policy engine of my AS could be structured to cons= ider requests relative to only one capability or scope family at a time. Fo= r example, in issuing health record authorizations, I might separate the be= havioral health capabilities from capabilities to access the physical parts= of my record at a given hospital's GNAP RS API.

    Lastly, at the level of attenuation, I would choose a relationship with = RSs that issue to me capabilities that can be attenuated not only by my AS = but also by the requesting parties that receive them as part of an access t= oken.

    Adrian


    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/ma= ilman/listinfo/txauth
    --000000000000f44e5705bdfe179b-- From nobody Sat Mar 20 14:06:55 2021 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 0A2413A2A87 for ; Sat, 20 Mar 2021 14:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 0W8TSTfZ4quK for ; Sat, 20 Mar 2021 14:06:51 -0700 (PDT) Received: from mail-vk1-f175.google.com (mail-vk1-f175.google.com [209.85.221.175]) (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 399793A2A82 for ; Sat, 20 Mar 2021 14:06:51 -0700 (PDT) Received: by mail-vk1-f175.google.com with SMTP id w63so2910077vkf.11 for ; Sat, 20 Mar 2021 14:06:51 -0700 (PDT) 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=Ep2oFqKoyxpfT5QPtlo91DmbyFrx60FP1EM4TBjF9fA=; b=BTU6E4alE+yagOY4i24o9AW7kNJIq2wCD+z/uh4/Q4kzU86wNDtaqga8x+fa7dtcx4 02M4100diRORjkcZVeAmCiV53+wpQEevSxslULYzodoWbgLE+l/a1AX0td66VWYnp6bp LV0enAK0+KMzvmr/4ml0UO9x/+Hb6yDalM8y2bkjFToBFDOvbyhdAZbFEPZmko1EXCNA 3qUSFSf6i5dz5xbP0vHFyXcdEniWqA4S+xw0uiqLMiV8mzlYrk247ip6zo3VrEQXzsrv Ukva6dpkHLtlCMI4aPphJTfo67vh3qdhrI1GXVzX656Kv8K1RCaC3DmowZ1EnuRsSf0y VbiQ== X-Gm-Message-State: AOAM533Iafv/otgFcA4WOkNpQZX1ANe4nD0xOczc7muM+lwAq2Xhm508 5cD3EoXauSlDS59tPWHfrQ6XtrSVBzvh/Qj/ZbU= X-Google-Smtp-Source: ABdhPJz51sw5T0KCrYsydw0v+THaEuxOvhzOp1fkX5wI3y42+tAdzo3eXcmzD07DA4p6kg1omjH/okRfu0UsZzXiBVQ= X-Received: by 2002:a05:6122:889:: with SMTP id 9mr5921756vkf.10.1616274409789; Sat, 20 Mar 2021 14:06:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Adrian Gropper Date: Sat, 20 Mar 2021 17:06:38 -0400 Message-ID: To: Fabien Imbault Cc: Alan Karp , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="0000000000000e1dd905bdfe3636" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2021 21:06:54 -0000 --0000000000000e1dd905bdfe3636 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You remember accurately, Fabien. It was one of the ways I was trying to explain my suggestion. Sorry to mislead. I hope the case I'm making with Alan's help is clearer now. Adrian On Sat, Mar 20, 2021 at 4:58 PM Fabien Imbault wrote: > OK fine then. > > I just remembered that you suggested a choice between several AS-RSs by > the RO. If that's not the case, there's no problem. > > Fabien > > Le sam. 20 mars 2021 =C3=A0 21:20, Adrian Gropper a > =C3=A9crit : > >> To be clear, I'm suggesting that GNAP standardize two separate flows if >> necessary and give the RS the option of supporting one or both of them. >> - Option 1 is capabilities and exactly as Alan just outlined where the R= O >> does not need to inform the RS that it is using an AS. >> - Option 2 is an RO-controlled AS as might be linked to a DID service >> endpoint. >> >> Adrian >> >> On Sat, Mar 20, 2021 at 1:58 PM Alan Karp wrote: >> >>> You are close on the flow. The only change is that the RO does not nee= d >>> to inform the RS that the RO is using an AS. >>> >>> The flow is described in our Zebra Copy tech report, >>> https://www.hpl.hp.com/techreports/2007/HPL-2007-105.pdf, which, by the >>> way, uses non-opaque tokens. (Don't worry about the length. The last = 60 >>> pages are a walkthrough of the reference implementation.) I believe th= at >>> example is closer to the GNAP use cases than the one in the talk Adrian >>> mentioned. Also, I hope the different terminology isn't too confusing. >>> >>> 1. The owner of RS delegates a set of rights to the administrator of >>> the service, AS-RS. >>> 2. RO contacts AS-RS and gets back a capability authorizing a >>> specific set of methods at RS. >>> 3. RO can use that capability to invoke RS with any of the >>> authorized permissions. >>> 4. RO can delegate a subset of those rights to a client, who can >>> then invoke the RS with any of the authorized permissions. >>> 5. RO can delegate a subset of those rights to an AS-RO. >>> 6. AS-RO can delegate a subset of those rights to a client based on >>> a policy specified by RO. >>> 7. That client can invoke RO with any of the authorized permissions. >>> >>> Note that AS-RS doesn't need to know anything about the various >>> delegatees. It just needs to verify that the delegations are valid. >>> >>> Responsibility tracking follows those steps. AS-RS will hold RO >>> responsible for all uses of any token delegated from the one AS-RS gave >>> RO. Each delegator is responsible for knowing who to hold responsible = for >>> each of its delegations. Say there's a $100 penalty for misuse, and th= e >>> client in step 6 does something bad. AS-RS will collect $100 from RO. >>> It's up to RO to collect $100 from AS-RO and up to AS-RO to collect fro= m >>> the client. >>> >>> This approach is the only thing that makes sense. What would RS or >>> AS-RS do with the information that RO delegated to AS-RO? AS-RS has no= way >>> of collecting from AS-RO; only RO does. >>> >>> -------------- >>> Alan Karp >>> >>> >>> On Sat, Mar 20, 2021 at 3:52 AM Fabien Imbault >>> wrote: >>> >>>> Thanks for the description. >>>> >>>> Trying to summarize what a capability flow would look like following >>>> those ideas: >>>> >>>> 1) RS issues a capability for the RO. For instance "view and download >>>> photo". >>>> >>>> 2) RO can delegate that capability (or an attenuated version) to the >>>> AS. Say "view photo", possibly with some ambient conditions. >>>> If the RO further wants to choose between a list of possible ASs, the >>>> RO would have to signal its choice to the RS, which would then have to >>>> signal it to the client (what we had called RS preflight in some >>>> discussions). So the AS-RS relationship would be mediated via the RO >>>> (or more precisely its agent). >>>> >>>> 3) a core GNAP negociation takes place with the AS (traditional photo >>>> example). >>>> >>>> Is that correct? Do not hesitate to correct me if I didn't accurately >>>> capture what you said. >>>> (I volontarily put DID aside for now) >>>> >>>> Steps occurring before 3 are optional (for reasons discussed before an= d >>>> also because we can't assume all RSs would be able to support that). >>>> >>>> Fabien >>>> >>>> Le sam. 20 mars 2021 =C3=A0 10:49, Adrian Gropper >>>> a =C3=A9crit : >>>> >>>>> Hi Fabien, >>>>> >>>>> Yes, it=E2=80=99s optional and adding meaningful options is one way t= o >>>>> consider the ethical imperative http://www.cybsoc.org/heinz.htm >>>>> >>>>> If I understand Alan=E2=80=99s teachings, the RS has the option to ei= ther >>>>> issue one or more capabilities to the RO or to store some identity-re= lated >>>>> information about the RO such as the DID of the RO and, by reference,= the >>>>> AS service endpoint controlled by that DID. >>>>> >>>>> Given some capabilities, the RO can either deal with them manually or >>>>> hand them to an AS. Either way, the RS has no idea of the RO=E2=80=99= s choice until >>>>> it receives a token from some end user. This seems to be what the Let= ters >>>>> of Transit in Casablanca were all about. >>>>> >>>>> If, on the other hand, the RO chooses to give 5e RS a DID, a >>>>> self-sovereign identifier, instead of taking some capabilities, then = the RS >>>>> has the expectation to trust tokens signed by that DID. >>>>> >>>>> It=E2=80=99s my hope that GNAP can allow an ethical RS to offer both = choices >>>>> to the RO. >>>>> >>>>> Adrian >>>>> >>>>> >>>>> On Sat, Mar 20, 2021 at 4:23 AM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Hi Adrian, >>>>>> >>>>>> Calling to one AS per persona can only be optional, as we have no >>>>>> way, and no wish, of knowing all the identities used by the RO. >>>>>> >>>>>> I think this relates to the idea of the RO having its own distinct >>>>>> agent, but I still don't understand how that would work (even re-rea= ding >>>>>> the thread in issue 145). Could you elaborate? >>>>>> >>>>>> Thxs >>>>>> Fabien >>>>>> >>>>>> >>>>>> Le sam. 20 mars 2021 =C3=A0 06:08, Adrian Gropper >>>>>> a =C3=A9crit : >>>>>> >>>>>>> @Alan Karp shared a talk about the Principle >>>>>>> Of Least Authority (POLA) in a recent comment >>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issue= comment-803099693 >>>>>>> I recommend it. >>>>>>> >>>>>>> We might expect a protocol with authorization in the title to use >>>>>>> authority as a core principle. I advocate for a GNAP design that ma= ximizes >>>>>>> the power of the RO, to be seen as a human rights issue when the RO= is a >>>>>>> human. This causes me to ask how to combine better security with be= tter >>>>>>> human rights in GNAP. >>>>>>> >>>>>>> Who should have the least authority in the GNAP design? >>>>>>> >>>>>>> The AS derives authority as a delegate of the RO. If we ask the RO >>>>>>> to partition limited authority across dozens of different ASs by do= main and >>>>>>> function, then we are not using technology to empower the individua= l. >>>>>>> Probably the opposite, as we introduce consent fatigue and burden n= ormal >>>>>>> people to partition their lives into non-overlapping domains. >>>>>>> >>>>>>> My experience says we should aim for one AS per persona because tha= t >>>>>>> maps into the way we manage our public and private identities. POLA= would >>>>>>> then teach care in keeping ASs and RSs related to work / public sep= arate >>>>>>> from ASs and RSs related to private life so that a policy vulnerabi= lity in >>>>>>> our delegation to an AS would have the least likelihood of harm. >>>>>>> >>>>>>> Beyond that fairly obvious principle, we could spread our >>>>>>> interactions among as many services as possible. We already do this= when we >>>>>>> spread assets across multiple banks, internet services across redun= dant >>>>>>> platforms, or we use LinkedIn, Twitter, and Facebook with limited o= verlap >>>>>>> in social graphs. >>>>>>> >>>>>>> At the next level down, we want to manage resources at each RS usin= g >>>>>>> least authority in order to make AS policy vulnerabilities easier t= o spot >>>>>>> and debug. My AS might get multiple capabilities or access to scope= s from >>>>>>> an RS, each one carefully labeled with its intended uses so that th= e policy >>>>>>> engine of my AS could be structured to consider requests relative t= o only >>>>>>> one capability or scope family at a time. For example, in issuing h= ealth >>>>>>> record authorizations, I might separate the behavioral health capab= ilities >>>>>>> from capabilities to access the physical parts of my record at a gi= ven >>>>>>> hospital's GNAP RS API. >>>>>>> >>>>>>> Lastly, at the level of attenuation, I would choose a relationship >>>>>>> with RSs that issue to me capabilities that can be attenuated not o= nly by >>>>>>> my AS but also by the requesting parties that receive them as part = of an >>>>>>> access token. >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> TXAuth mailing list >>>>>>> TXAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >>>>>> --0000000000000e1dd905bdfe3636 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    You remember accurately, Fabien. It was one of the ways I = was trying to explain my suggestion. Sorry to mislead. I hope the case I= 9;m making with Alan's help is clearer now.

    Adrian

    On Sat, Mar 20, 2021 at 4:58 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    OK fine then.

    I just remembered that you suggested a choice between several AS= -RSs by the RO. If that's not the case, there's no problem.

    Fabien=C2=A0
    <= br>
    Le sam.= 20 mars 2021 =C3=A0 21:20, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit= =C2=A0:
    To be clear, I'm sug= gesting that GNAP standardize two separate flows if necessary and give the = RS the option of supporting one or both of them.
    - Option 1 is capabili= ties and exactly as Alan just outlined where the RO does not need to inform= the RS that it is using an AS.
    - Option 2 is an RO-controlled AS= as might be linked to a DID service endpoint.

    Adr= ian=C2=A0

    On Sat, Mar 20, 2021 at 1:58 PM Alan Karp <alanhkarp@gm= ail.com> wrote:
    You are c= lose on the flow.=C2=A0 The only change is that the RO does not need to inf= orm the RS that the RO is using an AS.=C2=A0=C2=A0

    The f= low is described in our Zebra Copy tech report,=C2=A0https://www.hpl.hp.com/techreports/2007/HPL-2007-105.pdf, whic= h, by the way, uses non-opaque tokens.=C2=A0 (Don't worry about the len= gth.=C2=A0 The last 60 pages are a walkthrough of the reference implementat= ion.)=C2=A0 I believe that example is closer to the GNAP use cases than the= one in the talk Adrian mentioned.=C2=A0 Also, I hope the different termino= logy isn't too confusing.
    1. The owner of RS delegates a set o= f rights to the administrator of the service, AS-RS.
    2. RO contacts AS= -RS and gets back a capability authorizing a specific set of methods at RS.=
    3. RO can use that capability to invoke RS with any of the authorized= permissions.
    4. RO can delegate a subset of those rights to a client,= who can then invoke the RS with any of the authorized permissions.
      5. RO can delegate a subset of those rights to an AS-RO.
    5. AS-RO can de= legate a subset of those rights to a client based on a policy specified by = RO.
    6. That client can invoke RO with any of the authorized permission= s.
    Note that AS-RS doesn't need to know anything about th= e various delegatees.=C2=A0 It=C2=A0just needs to verify that the delegatio= ns are valid.

    Responsibility tracking follows thos= e steps.=C2=A0 AS-RS will hold RO responsible for all uses of any token del= egated from the one AS-RS gave RO.=C2=A0 Each delegator is responsible for = knowing who to hold responsible for each of its delegations.=C2=A0 Say ther= e's a $100 penalty for misuse, and the client in step 6 does something = bad.=C2=A0 AS-RS will collect $100 from RO.=C2=A0 It's up to RO to coll= ect $100 from AS-RO and up to AS-RO to collect from the client.
    =

    This approach is the only thing that makes sense.=C2=A0= What would RS or AS-RS do with the information that RO delegated to AS-RO?= =C2=A0 AS-RS has no way of collecting from AS-RO; only RO does.
    <= div>

    --------------
    Alan Karp

    <= /div>

    On Sat, Mar 20, 2021 at 3:52 AM Fabien Imbault <fabien.imbaul= t@gmail.com> wrote:
    Than= ks for the description.=C2=A0

    = Trying to summarize what a capability=C2=A0 flow would look like following = those ideas:

    1) RS issues a ca= pability for the RO. For instance "view and download photo".=C2= =A0

    2) RO can delegate t= hat capability (or an attenuated version) to the AS. Say "view photo&q= uot;, possibly with some ambient conditions.=C2=A0
    I= f the RO further wants to choose between a list of possible ASs, the RO wou= ld have to signal its choice to the RS, which would then have to signal it = to the client (what we had called RS preflight in some discussions).=C2=A0<= span style=3D"font-family:sans-serif">So the AS-RS relationship would be me= diated via the RO (or more precisely its agent).=C2=A0

    3) a core GNAP negociation takes plac= e with the AS (traditional photo example).=C2=A0
    Is that correct? Do not hesitate to correct me if = I didn't accurately capture what you said.=C2=A0
    (I volontarily put DID aside for now)=C2=A0

    Steps occurring before 3 are optional (for reasons dis= cussed before and also because we can't assume all RSs would be able to= support that).=C2=A0

    Fa= bien=C2=A0

    Le sam. 20 mars 2021 =C3=A0 10:49, Adrian Gropper &l= t;agropper@healthurl.com> a =C3=A9crit=C2=A0:
    Hi Fabien,

    =
    Yes, it=E2=80=99s optional and adding meaningful options = is one way to consider the ethical imperative http://www.c= ybsoc.org/heinz.htm=C2=A0

    <= div dir=3D"auto">If I understand Alan=E2=80=99s teachings, the RS has the o= ption to either issue one or more capabilities to the RO or to store some i= dentity-related information about the RO such as the DID of the RO and, by = reference, the AS service endpoint controlled by that DID.

    Given some capabilities, the RO can eith= er deal with them manually or hand them to an AS. Either way, the RS has no= idea of the RO=E2=80=99s choice until it receives a token from some end us= er. This seems to be what the Letters of Transit in Casablanca were all abo= ut.=C2=A0

    If, on the oth= er hand, the RO chooses to give 5e RS a DID, a self-sovereign identifier, i= nstead of taking some capabilities, then the RS has the expectation =C2=A0t= o trust tokens signed by that DID.=C2=A0

    <= div dir=3D"auto">It=E2=80=99s my hope that GNAP can allow an ethical RS to = offer both choices to the RO.

    Adrian


    On Sat, Mar 20, 2021 at 4:23 A= M Fabien Imbault <fabien.imbault@gmail.com> wrot= e:
    Hi Adrian,= =C2=A0

    Calling to one AS= per persona can only be optional, as we have no way, and no wish, of knowi= ng all the identities used by the RO.=C2=A0

    I think this relates to the idea of the RO having its o= wn distinct agent, but I still don't understand how that would work (ev= en re-reading the thread in issue 145). Could you elaborate?=C2=A0

    Thxs
    Fabi= en=C2=A0


    <= div dir=3D"auto">
    Le sam. 20 mars 2021 =C3=A0 06:08, Adrian Gropper <<= a href=3D"mailto:agropper@healthurl.com" rel=3D"noreferrer noreferrer" targ= et=3D"_blank">agropper@healthurl.com> a =C3=A9crit=C2=A0:
    <= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa= dding-left:1ex">
    @Alan Karp=C2=A0shared a talk abo= ut the Principle Of Least Authority (POLA) in a recent comment=C2=A0h= ttps://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-8= 03099693 I recommend it.

    We mi= ght expect a protocol with authorization in the title to use authority as a= core principle. I advocate for a GNAP design that maximizes the power of t= he RO, to be seen as a human rights=C2=A0issue when the RO is a human. This= causes me to ask how to combine better security with better human rights i= n GNAP.

    Who should have the least authority in the= GNAP design?

    The AS derives authority as a delega= te of the RO. If we ask the RO to partition limited authority across dozens= of different ASs by domain and function, then we are not using technology = to empower the individual. Probably the opposite, as we introduce consent f= atigue and burden normal people to partition their lives into non-overlappi= ng domains.=C2=A0

    My experience says we should aim= for one AS per persona because that maps into the way we manage our public= and private identities. POLA would then teach care in keeping ASs and RSs = related to work / public separate from ASs and RSs related to private=C2=A0= life so that a policy vulnerability in our delegation to an AS would have t= he least likelihood=C2=A0of harm.

    Beyond that fair= ly obvious principle, we could spread our interactions among as many servic= es as possible. We already do this when we spread assets across multiple ba= nks, internet services across redundant platforms, or we use LinkedIn, Twit= ter, and Facebook with limited overlap in social graphs.

    At the next level down, we want to manage resources at each RS using= least authority in order to make AS policy vulnerabilities easier to spot = and debug. My AS might get multiple capabilities or access to scopes from a= n RS, each one carefully labeled with its intended uses so that the policy = engine of my AS could be structured to consider requests relative to only o= ne capability or scope family at a time. For example, in issuing health rec= ord authorizations, I might separate the behavioral health capabilities fro= m capabilities to access the physical parts of my record at a given hospita= l's GNAP RS API.

    Lastly, at the level of atten= uation, I would choose a relationship with RSs that issue to me capabilitie= s that can be attenuated not only by my AS but also by the requesting parti= es that receive them as part of an access token.

    A= drian


    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/ma= ilman/listinfo/txauth
    --0000000000000e1dd905bdfe3636-- From nobody Sat Mar 20 19:33:29 2021 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 B4FCA3A12B2 for ; Sat, 20 Mar 2021 19:33:22 -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=[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 ryby98304amF for ; Sat, 20 Mar 2021 19:33:18 -0700 (PDT) Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (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 3C21F3A1274 for ; Sat, 20 Mar 2021 19:33:18 -0700 (PDT) Received: by mail-qv1-xf32.google.com with SMTP id o19so7097931qvu.0 for ; Sat, 20 Mar 2021 19:33:18 -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=WHGXzYh289d5xWUSYIrksKTzW8dRbnPvnTLt9wCUOH4=; b=HQ4Y7SARsMoNHKzbrLUJmw+tZ3MCFUb9kshdpn3DZs6XCgE9aDBczYmRPsNWBwkOvz D+iBYua0NO088hBH6S1Uo8SbFI+hEskKY+rpAsppU7v/3wyb6mUXgn68aWzNVxqvBm5f ZuDuYacrYzg6x/Q+kJBvlREywBU3KWVo1usWkP9yT5WKclXN7fB4PSD2he1w4dvumj9U QkhPXoIQsAXBOAmBlCqu4V/EQQ1crSSgrwkRl/4cI2qNE4uXi2MdekW/CDQw/KOaaAG9 IXdBwp8BHr00qNwyDynFSJdt+BYJODidIe6dGtjauFwSQhL5NBxDmwSOw7SXw9K4xVDe TdzA== 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=WHGXzYh289d5xWUSYIrksKTzW8dRbnPvnTLt9wCUOH4=; b=OdfNZmj3Yr7LAkjMKaB8UqXQEaY/4HI1HujgmTarJnryaUvzPH2KZepRSNR0bEWWK9 fQbX/7Aul5llciAo2s4i6p74t1niDZmRrBsdoTV/MsKKT93142hreyRgGa3WvI/daHP3 5s7NhqHvr8QlmfxS5gxJI6mbSkuuUEBpXZv32Ug05w59dneia4iShUsNiBWKMeQmWeZu ETxC6kFyGiUXk+qs9kHYE7X+vwZrOsiSRLY348ihtqjtpOEDqUejYtV1oSODHKZXMK3+ U9eil3zsj6zpuJsSY44h7RUUKyZw4qJhRKWYSYv/xOpD+Shz27A70ZJKjQcu3bDROeMQ ajog== X-Gm-Message-State: AOAM533qEB7Voc9KPp/eO2SD12Q1cge6UoFjQLIhdMWKGnhWf9rcfgix HYYBDg1jhUMAWQCnStZyixmE9w6zomA/NRSdzFOmgTFKhjc= X-Google-Smtp-Source: ABdhPJzDbOWMFs1xIZ3tM3sVRaF4UfR2FfAeenEz3o13VMG4h6NXoJNcIu3HEWSaDyWdRw0FLS34YYmIvfPh6loGtt0= X-Received: by 2002:a0c:eac9:: with SMTP id y9mr15805926qvp.58.1616293996769; Sat, 20 Mar 2021 19:33:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alan Karp Date: Sat, 20 Mar 2021 19:33:05 -0700 Message-ID: To: Adrian Gropper Cc: GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="00000000000087b3ec05be02c599" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2021 02:33:26 -0000 --00000000000087b3ec05be02c599 Content-Type: text/plain; charset="UTF-8" Adrian Gropper wrote: > > Lastly, at the level of attenuation, I would choose a relationship with > RSs that issue to me capabilities that can be attenuated not only by my AS > but also by the requesting parties that receive them as part of an access > token. > The ability to attenuate at each delegation is key to enforcing least privilege. -------------- Alan Karp On Fri, Mar 19, 2021 at 10:07 PM Adrian Gropper wrote: > @Alan Karp shared a talk about the Principle Of > Least Authority (POLA) in a recent comment > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-803099693 > I recommend it. > > We might expect a protocol with authorization in the title to use > authority as a core principle. I advocate for a GNAP design that maximizes > the power of the RO, to be seen as a human rights issue when the RO is a > human. This causes me to ask how to combine better security with better > human rights in GNAP. > > Who should have the least authority in the GNAP design? > > The AS derives authority as a delegate of the RO. If we ask the RO to > partition limited authority across dozens of different ASs by domain and > function, then we are not using technology to empower the individual. > Probably the opposite, as we introduce consent fatigue and burden normal > people to partition their lives into non-overlapping domains. > > My experience says we should aim for one AS per persona because that maps > into the way we manage our public and private identities. POLA would then > teach care in keeping ASs and RSs related to work / public separate from > ASs and RSs related to private life so that a policy vulnerability in our > delegation to an AS would have the least likelihood of harm. > > Beyond that fairly obvious principle, we could spread our interactions > among as many services as possible. We already do this when we spread > assets across multiple banks, internet services across redundant platforms, > or we use LinkedIn, Twitter, and Facebook with limited overlap in social > graphs. > > At the next level down, we want to manage resources at each RS using least > authority in order to make AS policy vulnerabilities easier to spot and > debug. My AS might get multiple capabilities or access to scopes from an > RS, each one carefully labeled with its intended uses so that the policy > engine of my AS could be structured to consider requests relative to only > one capability or scope family at a time. For example, in issuing health > record authorizations, I might separate the behavioral health capabilities > from capabilities to access the physical parts of my record at a given > hospital's GNAP RS API. > > Lastly, at the level of attenuation, I would choose a relationship with > RSs that issue to me capabilities that can be attenuated not only by my AS > but also by the requesting parties that receive them as part of an access > token. > > Adrian > > > --00000000000087b3ec05be02c599 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Adr= ian Gropper <agropper@healthurl.com> wrote:

    La= stly, at the level of attenuation, I would choose a relationship with RSs t= hat issue to me capabilities that can be attenuated not only by my AS but a= lso by the requesting parties that receive them as part of an access token.=

    The ability to attenuate at each delegation is key to enforcing = least privilege.
    <= br>--------------
    Alan Karp


    On Fri, Mar 19, 2021 at 10:07= PM Adrian Gropper <agropper@healthurl.com> wrote:
    @Alan Karp=C2=A0shared a talk about the Principle Of L= east Authority (POLA) in a recent comment=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#i= ssuecomment-803099693 I recommend it.

    We might expect a protocol with authorization in the title to use a= uthority as a core principle. I advocate for a GNAP design that maximizes t= he power of the RO, to be seen as a human rights=C2=A0issue when the RO is = a human. This causes me to ask how to combine better security with better h= uman rights in GNAP.

    Who should have the least aut= hority in the GNAP design?

    The AS derives authorit= y as a delegate of the RO. If we ask the RO to partition limited authority = across dozens of different ASs by domain and function, then we are not usin= g technology to empower the individual. Probably the opposite, as we introd= uce consent fatigue and burden normal people to partition their lives into = non-overlapping domains.=C2=A0

    My experience says = we should aim for one AS per persona because that maps into the way we mana= ge our public and private identities. POLA would then teach care in keeping= ASs and RSs related to work / public separate from ASs and RSs related to = private=C2=A0life so that a policy vulnerability in our delegation to an AS= would have the least likelihood=C2=A0of harm.

    Bey= ond that fairly obvious principle, we could spread our interactions among a= s many services as possible. We already do this when we spread assets acros= s multiple banks, internet services across redundant platforms, or we use L= inkedIn, Twitter, and Facebook with limited overlap in social graphs.
    =

    At the next level down, we want to manage resources at = each RS using least authority in order to make AS policy vulnerabilities ea= sier to spot and debug. My AS might get multiple capabilities or access to = scopes from an RS, each one carefully labeled with its intended uses so tha= t the policy engine of my AS could be structured to consider requests relat= ive to only one capability or scope family at a time. For example, in issui= ng health record authorizations, I might separate the behavioral health cap= abilities from capabilities to access the physical parts of my record at a = given hospital's GNAP RS API.

    Lastly, at the l= evel of attenuation, I would choose a relationship with RSs that issue to m= e capabilities that can be attenuated not only by my AS but also by the req= uesting parties that receive them as part of an access token.
    Adrian


    --00000000000087b3ec05be02c599-- From nobody Sun Mar 21 00:56:18 2021 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 736193A18A8 for ; Sun, 21 Mar 2021 00:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 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, 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=mnot.net header.b=gi5qMLEe; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=tYEo4QC4 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 R2l-ZHXBGddl for ; Sun, 21 Mar 2021 00:56:07 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACA633A18A7 for ; Sun, 21 Mar 2021 00:56:07 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 77DC91728 for ; Sun, 21 Mar 2021 03:38:58 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 21 Mar 2021 03:38:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=Qw27bOd02bO5yzClq+9v6TQY/rtWRkxZqj0Yh4/y1Mg=; b=gi5qMLEe YSByQkwg22hymYVXUaOvi/P686YfO+eP8Vj+TQ66L/51KTCxTpOr/ud3ki8FGt4B 38vQOVOOO09XMyIFNIGfifH9+0TZs8U5NL8fWzRyfxJsVKTgftMw0hUOv/C8ify5 5OWdewN/rsAKnsZyJ7123/ciJM21xiEAZzdaaawPWxhSzi1fsxTGoqDdIvhDrMCR q2Hb+jDzN1rZf0MjqeECKvsEl5VCHMfLxFKWXQPV9FPKeusYUcFP07MZhFAqQ1wO UpJZMipuluqjMdPgogV5D3OA0AKjhKWPaCFBdJvzwoMC6tuPiZg7fX02DclwwySl EyzKcqZHeBeBvA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=Qw27bOd02bO5yzClq+9v6TQY/rtWR kxZqj0Yh4/y1Mg=; b=tYEo4QC4Gi43NHIy2BiuTbzFqgNzdKiPf/8f9fFjyu3ZX N7SrXQEGW8tQzbcDiRI8c1lg7rGt3qbIwD5KFi19HTtqycIDyu4KMbK6m+GWnUgG GzBneBcA+R9IkAwV/6YcWE91O4c7D4hxdUVlVG/wmQZNXFJy1sv0bdwaBVF/xJLM t6CZDlL0GyrSD3Kh8iwyeSUEceC9FCjtUJG6d6bX0pwqODl4D2Yrj2OL2pmYNiqf Ztl+8v/mPoROn7LL8hPAiLS/CLnrbcK7zCEN3bFfqT9GdrryZ5Qhc1TkfpUGJXxw yarNcZCQYatiRajqSkJAx43+ja9URfdRkeasTAu6A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudeguddgudduvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeehvddrvdehuddruddvtd drudehleenucevlhhushhtvghrufhiiigvpeegnecurfgrrhgrmhepmhgrihhlfhhrohhm peguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az194-582.internal.cloudapp.net (unknown [52.251.120.159]) by mail.messagingengine.com (Postfix) with ESMTPA id EC7E91080054 for ; Sun, 21 Mar 2021 03:38:57 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============6641509812561356821==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20210321073857.EC7E91080054@mailuser.nyi.internal> Date: Sun, 21 Mar 2021 03:38:57 -0400 (EDT) Archived-At: Subject: [GNAP] Weekly github digest (GNAP Weekly GitHub Activity Summary) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2021 07:56:13 -0000 --===============6641509812561356821== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * ietf-wg-gnap/core-protocol (+5/-4/=F0=9F=92=AC45) 5 issues created: - DID as identifier (by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/221=20 - xml2rfc (by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/219=20 - Update HTTP Message Signature Formats (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/218=20 - Add Roles Diagram (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/217=20 - Simplify access token hash (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/216=20 8 issues received 45 new comments: - #221 DID as identifier (1 by tplooker) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/221=20 - #219 xml2rfc (4 by fimbault, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/219=20 - #216 Simplify access token hash (4 by fimbault, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/216=20 - #215 User choice and consent, and user notice (3 by agropper, fimbault,= jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/215=20 - #210 "sub_id" claims (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210=20 - #203 Requesting resources with insufficient access (2 by Denisthemalice= , fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/203=20 - #145 Opaque / Non opaque access token (27 by Denisthemalice, agropper, = alanhkarp, fimbault, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145 [Pending = Close]=20 - #114 Resource Server Section (3 by Denisthemalice, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/114=20 4 issues closed: - xml2rfc https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/219=20 - sub_ids and different contexts https://github.com/ietf-wg-gnap/gnap-cor= e-protocol/issues/178=20 - Add access token hash to DPoP https://github.com/ietf-wg-gnap/gnap-core= -protocol/issues/174=20 - Rename DPoP digest parameter https://github.com/ietf-wg-gnap/gnap-core-= protocol/issues/173=20 Pull requests ------------- * ietf-wg-gnap/core-protocol (+1/-5/=F0=9F=92=AC17) 1 pull requests submitted: - change subject type to format to comply with secevent draft07 (by fimba= ult) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/220=20 6 pull requests received 17 new comments: - #220 change subject type to format to comply with secevent draft07 (2 b= y netlify, tplooker) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/220=20 - #211 updated diagrams, included subject-only flow (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/211 [Pending Me= rge]=20 - #209 These are examples of not sender-constrained tokens. Hence, the "b= ound" v=E2=80=A6 (2 by adeinega, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/209 [Pending Me= rge]=20 - #207 Mnr editorial changes for jws and jwsd (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/207=20 - #206 HTTP status codes and responses (4 by Denisthemalice, adeinega, jr= icher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/206 [Pending Cl= ose]=20 - #184 sub_ids and different contexts (7 by adeinega, agropper, fimbault,= jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/184 [Pending Me= rge]=20 5 pull requests merged: - Adding information about the Cache-Control header and its value. https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/199 [Pending Me= rge]=20 - Update DPoP Syntax https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/195 [Pending Me= rge]=20 - Syntax and schema based normalization for URI in the htu claim. https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/202 [Pending Me= rge]=20 - Suggested changes for Discovery field names https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/194 [Pending Me= rge]=20 - sub_ids and different contexts https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/184 [Pending Me= rge]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol --===============6641509812561356821== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (GNAP Weekly GitHub Activity Summary)

    Sunday March 21, 2021

    Events without label "editorial"

    Issues

    ietf-wg-gnap/core-protocol (+5/-4/=F0=9F=92=AC45)

    5 issues created:

    8 issues received 45 new comments:

    4 issues closed:

    Pull requests

    ietf-wg-gnap/core-protocol (+1/-5/=F0=9F=92=AC17)

    1 pull requests submitted:

    6 pull requests received 17 new comments:

    5 pull requests merged:

    Repositories tracked by this digest:

    --===============6641509812561356821==-- From nobody Sun Mar 21 10:18:16 2021 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 587943A1157 for ; Sun, 21 Mar 2021 10:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.403 X-Spam-Level: X-Spam-Status: No, score=0.403 tagged_above=-999 required=5 tests=[KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 Qbb-j6kNmTmt for ; Sun, 21 Mar 2021 10:18:14 -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 E285B3A1154 for ; Sun, 21 Mar 2021 10:18:13 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 12LHI0Xe029890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 21 Mar 2021 13:18:06 -0400 Date: Sun, 21 Mar 2021 10:18:00 -0700 From: Benjamin Kaduk To: Adrian Gropper Cc: GNAP Mailing List , Alan Karp , Mark Miller Message-ID: <20210321171800.GT79563@kduck.mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2021 17:18:15 -0000 On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote: > @Alan Karp shared a talk about the Principle Of Least > Authority (POLA) in a recent comment > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-803099693 > I recommend it. > > We might expect a protocol with authorization in the title to use authority > as a core principle. I advocate for a GNAP design that maximizes the power > of the RO, to be seen as a human rights issue when the RO is a human. This > causes me to ask how to combine better security with better human rights in > GNAP. > > Who should have the least authority in the GNAP design? > > The AS derives authority as a delegate of the RO. If we ask the RO to > partition limited authority across dozens of different ASs by domain and > function, then we are not using technology to empower the individual. > Probably the opposite, as we introduce consent fatigue and burden normal > people to partition their lives into non-overlapping domains. > > My experience says we should aim for one AS per persona because that maps > into the way we manage our public and private identities. POLA would then > teach care in keeping ASs and RSs related to work / public separate from > ASs and RSs related to private life so that a policy vulnerability in our > delegation to an AS would have the least likelihood of harm. Thinking about how least authority/least privilege would apply to GNAP seems like a useful exercise. I do want to point out some potential pitfalls with one-AS-per-persona that we can also be aware of. If one-AS-per-persona becomes one-persona-per-AS as well, then the AS's identity in effect also serves as a persona identity and there are privacy considerations to that. If, on the other hand, the multiple-personas-per-AS (presumably corresponding to multiple humans) route is taken, we should consider whether that would lead to various (e.g., market) forces driving consolidation to just a handful of super-popular AS services. That topic is a current matter of concern to some IETF participants. Thanks, Ben From nobody Sun Mar 21 11:34:55 2021 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 570B23A12BC for ; Sun, 21 Mar 2021 11:34:53 -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=[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 xw5e6pJV_xVH for ; Sun, 21 Mar 2021 11:34:50 -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 610733A12BA for ; Sun, 21 Mar 2021 11:34:50 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id t14so3008986ilu.3 for ; Sun, 21 Mar 2021 11:34:50 -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=OyeulO5oajj3u6mow6mQJ9m+Z5o6X0gwKdQkR4ynBFo=; b=DtbWQEs73yzBhJxj6vt00WkuSsrzpbODPYj599oPr5WKtsUtgLYibVCGewgoJFIkTz R0Zgph4gzPqc+8ct6fTYRIE8vRPrk1zta6AdJbf02lTzqN/qltt/vz78UH9APOzCXZU4 hQ1lUqSEzeKfXZ/1dX5OVwXKz7fa4XcnEGWY61CRYsz4tMkPh0RoPx5/s0gWmqAsYYFb zVkOjGn4VrC+2ichRYMhOaxB0zgtWt9V4Q35Ct8h1dHUta58Ld+If8erJZISGbcdVxZt itLB6WkkJkacKEPkega1GaUhHPpQeg+1pkrzfjJ7rYkqg1YOj2eYFHo8rF5CevtCK1US 8XzA== 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=OyeulO5oajj3u6mow6mQJ9m+Z5o6X0gwKdQkR4ynBFo=; b=mWiZJZ5Ae1qmL1IQkmdwxlJ6TYyJQ0tp0guBzI5fyCJZOsUrPNhNR+3ufVwykogZZy /7tzz97ZuBUN0mw6hWtlEIv4+hNv0S/LTNmHXRrkXc5QisQUUtyGRHWp9gt2dT3CfLLL y6kwlAzK1RK56Ti/z3nbA4mjB5c0o/dNNFfw5vEYwT9GxcJf/3WVp/3iXXNbR7P6GJAp cRL42Nn/ys8T1h3NeqHDZuel4r08i79ES0OPOYf6Oq7dXXRf5s1+1ntcjbh2AtW+HuS3 dKhEz3YUxyyVUUQRtpeunrOTboVTfjny5TeJSlTT+3Qnl019zd6ggT3x/aSDvqJBfDtU pt6A== X-Gm-Message-State: AOAM531WXOWmzknZMFJ689kW2Dufo6DeqUfQoN2b4+L+XDMJUh3iFTvD LxNO5GaqerPdas2ksVH7MXL5uL7/1eeGqqfswkRN6FNQVno= X-Google-Smtp-Source: ABdhPJz/oFfQDaAyBRCyfXsuLpl7wBhzO2WSDdL3MtfXgM87RgTIJHyw4jSUjrWYUIZPDVC4NHml2RFpqQeIgPoBDj4= X-Received: by 2002:a92:c6d0:: with SMTP id v16mr8547642ilm.289.1616351688361; Sun, 21 Mar 2021 11:34:48 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> In-Reply-To: <20210321171800.GT79563@kduck.mit.edu> From: Fabien Imbault Date: Sun, 21 Mar 2021 19:34:35 +0100 Message-ID: To: Benjamin Kaduk Cc: Adrian Gropper , Alan Karp , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="000000000000378b9105be1034fd" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2021 18:34:53 -0000 --000000000000378b9105be1034fd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ben Very good question. The core protocol probably will be able to elude providing an answer, focusing on singular requests. Any extension covering AS-RS relationships will have to handle its socio technical impact. Fabien Le dim. 21 mars 2021 =C3=A0 18:18, Benjamin Kaduk a =C3=A9c= rit : > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote: > > @Alan Karp shared a talk about the Principle Of > Least > > Authority (POLA) in a recent comment > > > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecommen= t-803099693 > > I recommend it. > > > > We might expect a protocol with authorization in the title to use > authority > > as a core principle. I advocate for a GNAP design that maximizes the > power > > of the RO, to be seen as a human rights issue when the RO is a human. > This > > causes me to ask how to combine better security with better human right= s > in > > GNAP. > > > > Who should have the least authority in the GNAP design? > > > > The AS derives authority as a delegate of the RO. If we ask the RO to > > partition limited authority across dozens of different ASs by domain an= d > > function, then we are not using technology to empower the individual. > > Probably the opposite, as we introduce consent fatigue and burden norma= l > > people to partition their lives into non-overlapping domains. > > > > My experience says we should aim for one AS per persona because that ma= ps > > into the way we manage our public and private identities. POLA would th= en > > teach care in keeping ASs and RSs related to work / public separate fro= m > > ASs and RSs related to private life so that a policy vulnerability in o= ur > > delegation to an AS would have the least likelihood of harm. > > Thinking about how least authority/least privilege would apply to GNAP > seems like a useful exercise. I do want to point out some potential > pitfalls with one-AS-per-persona that we can also be aware of. If > one-AS-per-persona becomes one-persona-per-AS as well, then the AS's > identity in effect also serves as a persona identity and there are privac= y > considerations to that. If, on the other hand, the > multiple-personas-per-AS (presumably corresponding to multiple humans) > route is taken, we should consider whether that would lead to various > (e.g., market) forces driving consolidation to just a handful of > super-popular AS services. That topic is a current matter of concern to > some IETF participants. > > Thanks, > > Ben > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000378b9105be1034fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Ben

    Very good question.=C2=A0

    The core protocol probably will be able to elude provi= ding an answer, focusing on singular requests.=C2=A0

    Any extension covering AS-RS relationships= will have to handle its socio technical impact.=C2=A0

    Fabien=C2=A0

    Le dim. 21 mars 202= 1 =C3=A0 18:18, Benjamin Kaduk <kaduk@mit.edu> a =C3=A9crit=C2=A0:
    On Sat, Mar 20, 2021 at 01:07:42AM -0= 400, Adrian Gropper wrote:
    > @Alan Karp <alanhkarp@gmail.com> shared a talk a= bout the Principle Of Least
    > Authority (POLA) in a recent comment
    > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#i= ssuecomment-803099693
    > I recommend it.
    >
    > We might expect a protocol with authorization in the title to use auth= ority
    > as a core principle. I advocate for a GNAP design that maximizes the p= ower
    > of the RO, to be seen as a human rights issue when the RO is a human. = This
    > causes me to ask how to combine better security with better human righ= ts in
    > GNAP.
    >
    > Who should have the least authority in the GNAP design?
    >
    > The AS derives authority as a delegate of the RO. If we ask the RO to<= br> > partition limited authority across dozens of different ASs by domain a= nd
    > function, then we are not using technology to empower the individual.<= br> > Probably the opposite, as we introduce consent fatigue and burden norm= al
    > people to partition their lives into non-overlapping domains.
    >
    > My experience says we should aim for one AS per persona because that m= aps
    > into the way we manage our public and private identities. POLA would t= hen
    > teach care in keeping ASs and RSs related to work / public separate fr= om
    > ASs and RSs related to private life so that a policy vulnerability in = our
    > delegation to an AS would have the least likelihood of harm.

    Thinking about how least authority/least privilege would apply to GNAP
    seems like a useful exercise.=C2=A0 I do want to point out some potential pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 If
    one-AS-per-persona becomes one-persona-per-AS as well, then the AS's identity in effect also serves as a persona identity and there are privacy<= br> considerations to that.=C2=A0 If, on the other hand, the
    multiple-personas-per-AS (presumably corresponding to multiple humans)
    route is taken, we should consider whether that would lead to various
    (e.g., market) forces driving consolidation to just a handful of
    super-popular AS services.=C2=A0 That topic is a current matter of concern = to
    some IETF participants.

    Thanks,

    Ben

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listi= nfo/txauth
    --000000000000378b9105be1034fd-- From nobody Sun Mar 21 12:38:55 2021 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 47EFD3A091C for ; Sun, 21 Mar 2021 12:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 iyz3TLB6P486 for ; Sun, 21 Mar 2021 12:38:52 -0700 (PDT) Received: from mail-ua1-f49.google.com (mail-ua1-f49.google.com [209.85.222.49]) (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 42DF53A091B for ; Sun, 21 Mar 2021 12:38:52 -0700 (PDT) Received: by mail-ua1-f49.google.com with SMTP id c2so4894938uaj.3 for ; Sun, 21 Mar 2021 12:38:52 -0700 (PDT) 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=7km2GcSCtNLnLloTfRixW19L730RFupc7r3kCSrAMBo=; b=LDDt9G2Z9QCFX4t/EMxVJvL6V2qTQHNfCpbaduJPeMrH1C4pJ8+l9W0ZQKzGT0OOn4 iaQICypWnrkv/GMkjyPD69Xu/3nmQK01B8HWn3VrR2QvLvrOK6/+7w2t5Pm8nsWW+dLl t5W9NVIf35+eB4BX0HNtjVqPmBSairEngLB9mgPMA3ywvc2bXn9j0ooahDjD0ZTjYXWf jS0tkT03h2NKgJjkpV6YCXlO4YD9siLbM5ru5KyK4vuKZF6VuTceTPigFrJBPfjTUC7Y Hjxm7ow0X+fulGX/w4mSyapvA/yBTDMg4hdB9uIRAQQupZIR+swyXfC7Fy28kThWXEIE y2og== X-Gm-Message-State: AOAM531I2w7bigvoG+s+TnxyMaCkJW8N8PiRLp2cqMN4m3ujxSoJuPii 0WCtg6QtA8yhXYxdAhyxmmnXyJote3Tlx+FhAgY= X-Google-Smtp-Source: ABdhPJwr4C1wJtmJaEFB3IqXStf3puZ8L5LlQralbhyx20NWdelA8mTvyKVohoCxsExuqm9hwsddZBbzboSdJST2loQ= X-Received: by 2002:ab0:30a3:: with SMTP id b3mr3101472uam.0.1616355531192; Sun, 21 Mar 2021 12:38:51 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> In-Reply-To: From: Adrian Gropper Date: Sun, 21 Mar 2021 15:38:39 -0400 Message-ID: To: Fabien Imbault Cc: Benjamin Kaduk , Alan Karp , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="000000000000447dbe05be1119bc" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2021 19:38:54 -0000 --000000000000447dbe05be1119bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In the SSI community, we have had more than a year of discussion, often intense, over the relationship between DIDs (decentralized identifiers), service endpoints (and their protocols) in DIDs (how many and what do they point to) and concepts like "herd privacy" that are essential to avoiding unwanted correlation and traffic analysis. With the recent ascension of DID core to Candidate Recommendation https://www.w3.org/TR/2021/CR-did-core-20210318/ We consider some of these issues settled. Along the way we've created various privacy analyses and had review by W3C. Section 10 is a great place to start as we consider the privacy of protocols like GNAP CR-did-core-20210318 . tl:dr My personal perspective after all of this work, is that mediator roles are a useful option at the intersection between a data model like DID and a protocol like GNAP. There were two classes of DID service endpoint protocols that stood out: messaging and authorization. Either one might be enhanced by the DID controller introducing a mediator but it doesn't change the core aspects of the messaging or authorization protocol itself. YMMV Adrian On Sun, Mar 21, 2021 at 2:34 PM Fabien Imbault wrote: > Hi Ben > > Very good question. > > The core protocol probably will be able to elude providing an answer, > focusing on singular requests. > > Any extension covering AS-RS relationships will have to handle its socio > technical impact. > > Fabien > > Le dim. 21 mars 2021 =C3=A0 18:18, Benjamin Kaduk a =C3= =A9crit : > >> On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote: >> > @Alan Karp shared a talk about the Principle Of >> Least >> > Authority (POLA) in a recent comment >> > >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomme= nt-803099693 >> > I recommend it. >> > >> > We might expect a protocol with authorization in the title to use >> authority >> > as a core principle. I advocate for a GNAP design that maximizes the >> power >> > of the RO, to be seen as a human rights issue when the RO is a human. >> This >> > causes me to ask how to combine better security with better human >> rights in >> > GNAP. >> > >> > Who should have the least authority in the GNAP design? >> > >> > The AS derives authority as a delegate of the RO. If we ask the RO to >> > partition limited authority across dozens of different ASs by domain a= nd >> > function, then we are not using technology to empower the individual. >> > Probably the opposite, as we introduce consent fatigue and burden norm= al >> > people to partition their lives into non-overlapping domains. >> > >> > My experience says we should aim for one AS per persona because that >> maps >> > into the way we manage our public and private identities. POLA would >> then >> > teach care in keeping ASs and RSs related to work / public separate fr= om >> > ASs and RSs related to private life so that a policy vulnerability in >> our >> > delegation to an AS would have the least likelihood of harm. >> >> Thinking about how least authority/least privilege would apply to GNAP >> seems like a useful exercise. I do want to point out some potential >> pitfalls with one-AS-per-persona that we can also be aware of. If >> one-AS-per-persona becomes one-persona-per-AS as well, then the AS's >> identity in effect also serves as a persona identity and there are priva= cy >> considerations to that. If, on the other hand, the >> multiple-personas-per-AS (presumably corresponding to multiple humans) >> route is taken, we should consider whether that would lead to various >> (e.g., market) forces driving consolidation to just a handful of >> super-popular AS services. That topic is a current matter of concern to >> some IETF participants. >> >> Thanks, >> >> Ben >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --000000000000447dbe05be1119bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    In the SSI community, we= have had more than a year of discussion, often intense, over the relations= hip between DIDs (decentralized identifiers), service endpoints (and their = protocols) in DIDs (how many and what do they point to) and concepts like &= quot;herd privacy" that are essential to avoiding unwanted correlation= and traffic analysis. With the recent ascension of DID core to Candidate R= ecommendation=C2=A0https://www.w3.org/TR/2021/CR-did-core-20210318/=C2=A0We consider = some of these issues settled. Along the way we've created various priva= cy analyses and had review by W3C. Section 10 is a great place to start as = we consider the privacy of protocols like GNAP=C2=A0CR-did-core-20= 210318.

    tl:dr My perso= nal=C2=A0perspective after all of this work, is that mediator roles are a u= seful option at the intersection between a data model like DID and a protoc= ol=C2=A0like GNAP. There were two classes of DID service endpoint protocols= that stood out: messaging and authorization. Either one might be enhanced = by the DID controller introducing a mediator but it doesn't change the = core aspects of the messaging or authorization protocol itself. YMMV
    <= div dir=3D"ltr">
    Adrian



    On Sun, Mar 21, 2021 at 2:34 PM = Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Ben

    Very good question.=C2=A0

    =
    The core protocol probably will be able to elude providin= g an answer, focusing on singular requests.=C2=A0

    Any extension covering AS-RS relationships wi= ll have to handle its socio technical impact.=C2=A0
    =
    Fabien=C2=A0

    Le dim. 21 mars 2021 = =C3=A0 18:18, Benjamin Kaduk <kaduk@mit.edu> a =C3=A9crit=C2=A0:
    On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropp= er wrote:
    > @Alan Karp <alanhkarp@gmail.com> shared a talk a= bout the Principle Of Least
    > Authority (POLA) in a recent comment
    > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#i= ssuecomment-803099693
    > I recommend it.
    >
    > We might expect a protocol with authorization in the title to use auth= ority
    > as a core principle. I advocate for a GNAP design that maximizes the p= ower
    > of the RO, to be seen as a human rights issue when the RO is a human. = This
    > causes me to ask how to combine better security with better human righ= ts in
    > GNAP.
    >
    > Who should have the least authority in the GNAP design?
    >
    > The AS derives authority as a delegate of the RO. If we ask the RO to<= br> > partition limited authority across dozens of different ASs by domain a= nd
    > function, then we are not using technology to empower the individual.<= br> > Probably the opposite, as we introduce consent fatigue and burden norm= al
    > people to partition their lives into non-overlapping domains.
    >
    > My experience says we should aim for one AS per persona because that m= aps
    > into the way we manage our public and private identities. POLA would t= hen
    > teach care in keeping ASs and RSs related to work / public separate fr= om
    > ASs and RSs related to private life so that a policy vulnerability in = our
    > delegation to an AS would have the least likelihood of harm.

    Thinking about how least authority/least privilege would apply to GNAP
    seems like a useful exercise.=C2=A0 I do want to point out some potential pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 If
    one-AS-per-persona becomes one-persona-per-AS as well, then the AS's identity in effect also serves as a persona identity and there are privacy<= br> considerations to that.=C2=A0 If, on the other hand, the
    multiple-personas-per-AS (presumably corresponding to multiple humans)
    route is taken, we should consider whether that would lead to various
    (e.g., market) forces driving consolidation to just a handful of
    super-popular AS services.=C2=A0 That topic is a current matter of concern = to
    some IETF participants.

    Thanks,

    Ben

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listi= nfo/txauth
    --000000000000447dbe05be1119bc-- From nobody Mon Mar 22 06:55:39 2021 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 31D3D3A1569 for ; Mon, 22 Mar 2021 06:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.403 X-Spam-Level: X-Spam-Status: No, score=0.403 tagged_above=-999 required=5 tests=[KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 WZC1OINgTLbu for ; Mon, 22 Mar 2021 06:55:34 -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 89D343A1565 for ; Mon, 22 Mar 2021 06:55:34 -0700 (PDT) Received: from [192.168.1.22] (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 12MDtT7t006974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 Mar 2021 09:55:30 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Justin Richer In-Reply-To: <20210321171800.GT79563@kduck.mit.edu> Date: Mon, 22 Mar 2021 09:55:29 -0400 Cc: Adrian Gropper , Alan Karp , GNAP Mailing List , Mark Miller Content-Transfer-Encoding: quoted-printable Message-Id: <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> References: <20210321171800.GT79563@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2021 13:55:38 -0000 On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk wrote: >=20 > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote: >> @Alan Karp shared a talk about the Principle Of = Least >> Authority (POLA) in a recent comment >> = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment= -803099693 >> I recommend it. >>=20 >> We might expect a protocol with authorization in the title to use = authority >> as a core principle. I advocate for a GNAP design that maximizes the = power >> of the RO, to be seen as a human rights issue when the RO is a human. = This >> causes me to ask how to combine better security with better human = rights in >> GNAP. >>=20 >> Who should have the least authority in the GNAP design? >>=20 >> The AS derives authority as a delegate of the RO. If we ask the RO to >> partition limited authority across dozens of different ASs by domain = and >> function, then we are not using technology to empower the individual. >> Probably the opposite, as we introduce consent fatigue and burden = normal >> people to partition their lives into non-overlapping domains. >>=20 >> My experience says we should aim for one AS per persona because that = maps >> into the way we manage our public and private identities. POLA would = then >> teach care in keeping ASs and RSs related to work / public separate = from >> ASs and RSs related to private life so that a policy vulnerability in = our >> delegation to an AS would have the least likelihood of harm. >=20 > Thinking about how least authority/least privilege would apply to GNAP > seems like a useful exercise. I do want to point out some potential > pitfalls with one-AS-per-persona that we can also be aware of. If > one-AS-per-persona becomes one-persona-per-AS as well, then the AS's > identity in effect also serves as a persona identity and there are = privacy > considerations to that. If, on the other hand, the > multiple-personas-per-AS (presumably corresponding to multiple humans) > route is taken, we should consider whether that would lead to various > (e.g., market) forces driving consolidation to just a handful of > super-popular AS services. That topic is a current matter of concern = to > some IETF participants. >=20 Hi Ben, big +1 to this. This is something that we discussed ages ago in = the UMA working group, and it=E2=80=99s one of the biggest problems with = the personal AS (and personal data store) model. This kind of thing = makes RS-first trust models really difficult in practice. As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that = wants to access my medical information. It calls an RS and requests = access, but it hasn=E2=80=99t been granted anything yet. Now I as the RO = have set up the RS so that it talks to my personal AS, that only I use. = In addition to the RS having to be able to figure out which medical = records are being requested from the context of the unauthenticated = request (which means it needs identifiers in the URL or something = similar for the RS to be able to tell, assuming that it protects data = for more than one person). So this client software doesn=E2=80=99t know = who I am and doesn=E2=80=99t know my medical record information, makes a = completely unauthorized request to the RS, and the RS says =E2=80=9CGo = to Justin=E2=80=99s personal AS to get a token=E2=80=9D. The client can = now make a direct correlation between the data that=E2=80=99s being = protected at the RS and the person running the AS that protects it. = Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This = is a design feature in the good case, and terrifying in the bad case. If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please = talk to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t = exposed anything at all. And from the perspective of both the patient = and the RS, this is more privacy-preserving, and it=E2=80=99s really the = least surprising option. Once the client gets to the AS, it can start a = negotiation of figuring out who the RO is for the information being = accessed. On top of this, the usability expectations of people managing their own = AS, or set of AS=E2=80=99s for multiple personas to keep things = separate, is a huge burden. Even in the tech community, I know people = who can=E2=80=99t reliably manage more than one email address for = different purposes. I wouldn=E2=80=99t expect my partner to do that =E2=80= =94 they have trouble enough balancing all the logins and sessions = required for different kids remote schooling, I couldn=E2=80=99t imagine = them having to understand all the requirements for managing multiple = authorization servers and associated policies. I also don=E2=80=99t = expect any person to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve = been on the internet for decades and I can barely keep tabs on my GPG = keys, and only use them when I am forced to. This is exactly the kind of = =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions above, = people will just want to outsource that to someone else, and the reality = will be a few popular providers. In which case, we could end up doing a ton of work to allow an RS choice = only to end up with a world where the RS ends up making a limited choice = anyway. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99= s could allow arbitrary IdPs but they choose Google because it works and = that=E2=80=99s where the users are. (And that=E2=80=99s not to say = anything of the proprietary OIDC-like protocols, but that=E2=80=99s = another discussion). For further reading on these topics, I recommend both =E2=80=9CWhy = Johnny Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems = Fail=E2=80=9D. So what does this have to do with GNAP? I think we can be clear-eyed on = what kinds of expectations we have for the participants. If we expect = users (RO=E2=80=99s) to have to set up the AS-RS relationship, or expect = them to carry their AS, or manage their personal keys =E2=80=94 I think = we=E2=80=99ve lost the battle for relevance. =E2=80=94 Justin= From nobody Mon Mar 22 10:29:00 2021 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 B184A3A0E5C for ; Mon, 22 Mar 2021 10:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 fLQ5ZwzqKSd9 for ; Mon, 22 Mar 2021 10:28:57 -0700 (PDT) Received: from mail-ua1-f52.google.com (mail-ua1-f52.google.com [209.85.222.52]) (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 6B3E63A0CEB for ; Mon, 22 Mar 2021 10:28:55 -0700 (PDT) Received: by mail-ua1-f52.google.com with SMTP id b10so5795412uap.4 for ; Mon, 22 Mar 2021 10:28:55 -0700 (PDT) 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=F59LNHmDaZv694bXm0KluMQNPg5QuNemyIl/JxJZWbU=; b=Dqcj3s/kBHohRESd4335Twf8BK7dTt7ektLrABWetu/Iti2PvWBDPTmyvSsqIBnadq YIQA2mqkRXB3GslsltLyfHPhWPJ7AN1IkP4ENYSyNIiBzf5jqG+44BRaEg3QwNuvV/GC 27u9q2Ht1EZC8hOjaVLZRLMqOK4KFK5KhPhG3Uivr1K4TQMEzo6DhGod5womvfZver3q +UUfjR2a7vOJOJ4jNtKmAfhsDrCzGLpSi30oGkJsrVC/YPwXoRP+evwmrvp3nJn+QeHU mllBWN5X3WE64G1GxwRc1ZxF/WSZ0GUDw5hFQwNoyS7KEiRPJFUPr1aWXTFVm5UVcbE8 ZI3g== X-Gm-Message-State: AOAM532ZyPECFkzVSVZ5ceNQ/C3Kd5ksT2JAiVGgh+27NPqDOAYIRA09 CdBbNT4Q4FoSoVfs9pMf3zz8VnpxXQI2lRyi+Oc= X-Google-Smtp-Source: ABdhPJwdOSmJM5PlKzanozOq9qe5/339oEcOw80AsvYViNFj49IknxGhBXam1TuslXIDascu43mQ3S5jlHCPjQgdQHw= X-Received: by 2002:ab0:5e5:: with SMTP id e92mr895566uae.70.1616434134344; Mon, 22 Mar 2021 10:28:54 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> In-Reply-To: <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> From: Adrian Gropper Date: Mon, 22 Mar 2021 13:28:42 -0400 Message-ID: To: Justin Richer Cc: Benjamin Kaduk , Alan Karp , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="0000000000006166a205be23661f" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2021 17:29:00 -0000 --0000000000006166a205be23661f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I too am in favor of avoiding consolidation and correlation. Right now, when I approach a service provider (RS) for the first time, I'm offered the opportunity to identify my persona as: email, sign-in with Google, Facebook, or Apple. I know there are people who try to create one-off email addresses but that is mostly a waste of time. So, along come FIDO2 and DID wallets to the rescue. Now, in theory, I have a way to start out my RS relationship pseudonymously. When I want my resource to be discovered or shared I will post that RS URL including my pseudonym. If I then want to introduce a mediator in front of my AS or messaging service endpoint, I have that option. If I want to keep requests away from the mediator, I would publish an encryption key along with my pseudonym. - Adrian On Mon, Mar 22, 2021 at 9:55 AM Justin Richer wrote: > On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk wrote: > > > > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote: > >> @Alan Karp shared a talk about the Principle Of > Least > >> Authority (POLA) in a recent comment > >> > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecommen= t-803099693 > >> I recommend it. > >> > >> We might expect a protocol with authorization in the title to use > authority > >> as a core principle. I advocate for a GNAP design that maximizes the > power > >> of the RO, to be seen as a human rights issue when the RO is a human. > This > >> causes me to ask how to combine better security with better human > rights in > >> GNAP. > >> > >> Who should have the least authority in the GNAP design? > >> > >> The AS derives authority as a delegate of the RO. If we ask the RO to > >> partition limited authority across dozens of different ASs by domain a= nd > >> function, then we are not using technology to empower the individual. > >> Probably the opposite, as we introduce consent fatigue and burden norm= al > >> people to partition their lives into non-overlapping domains. > >> > >> My experience says we should aim for one AS per persona because that > maps > >> into the way we manage our public and private identities. POLA would > then > >> teach care in keeping ASs and RSs related to work / public separate fr= om > >> ASs and RSs related to private life so that a policy vulnerability in > our > >> delegation to an AS would have the least likelihood of harm. > > > > Thinking about how least authority/least privilege would apply to GNAP > > seems like a useful exercise. I do want to point out some potential > > pitfalls with one-AS-per-persona that we can also be aware of. If > > one-AS-per-persona becomes one-persona-per-AS as well, then the AS's > > identity in effect also serves as a persona identity and there are > privacy > > considerations to that. If, on the other hand, the > > multiple-personas-per-AS (presumably corresponding to multiple humans) > > route is taken, we should consider whether that would lead to various > > (e.g., market) forces driving consolidation to just a handful of > > super-popular AS services. That topic is a current matter of concern t= o > > some IETF participants. > > > > Hi Ben, big +1 to this. This is something that we discussed ages ago in > the UMA working group, and it=E2=80=99s one of the biggest problems with = the > personal AS (and personal data store) model. This kind of thing makes > RS-first trust models really difficult in practice. > > As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that want= s to access my > medical information. It calls an RS and requests access, but it hasn=E2= =80=99t been > granted anything yet. Now I as the RO have set up the RS so that it talks > to my personal AS, that only I use. In addition to the RS having to be ab= le > to figure out which medical records are being requested from the context = of > the unauthenticated request (which means it needs identifiers in the URL = or > something similar for the RS to be able to tell, assuming that it protect= s > data for more than one person). So this client software doesn=E2=80=99t k= now who I > am and doesn=E2=80=99t know my medical record information, makes a comple= tely > unauthorized request to the RS, and the RS says =E2=80=9CGo to Justin=E2= =80=99s personal AS > to get a token=E2=80=9D. The client can now make a direct correlation bet= ween the > data that=E2=80=99s being protected at the RS and the person running the = AS that > protects it. Importantly, this client makes this call with no prior > relationship to the RS and no really auditable way to track it down after > the fact. This is a design feature in the good case, and terrifying in th= e > bad case. > > If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please tal= k to the > Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t exposed any= thing at all. And > from the perspective of both the patient and the RS, this is more > privacy-preserving, and it=E2=80=99s really the least surprising option. = Once the > client gets to the AS, it can start a negotiation of figuring out who the > RO is for the information being accessed. > > On top of this, the usability expectations of people managing their own > AS, or set of AS=E2=80=99s for multiple personas to keep things separate,= is a huge > burden. Even in the tech community, I know people who can=E2=80=99t relia= bly manage > more than one email address for different purposes. I wouldn=E2=80=99t ex= pect my > partner to do that =E2=80=94 they have trouble enough balancing all the l= ogins and > sessions required for different kids remote schooling, I couldn=E2=80=99t= imagine > them having to understand all the requirements for managing multiple > authorization servers and associated policies. I also don=E2=80=99t expec= t any > person to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve been on th= e internet for decades and I can > barely keep tabs on my GPG keys, and only use them when I am forced to. > This is exactly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I thin= k Ben mentions > above, people will just want to outsource that to someone else, and the > reality will be a few popular providers. > > In which case, we could end up doing a ton of work to allow an RS choice > only to end up with a world where the RS ends up making a limited choice > anyway. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80= =99s could allow > arbitrary IdPs but they choose Google because it works and that=E2=80=99s= where the > users are. (And that=E2=80=99s not to say anything of the proprietary OID= C-like > protocols, but that=E2=80=99s another discussion). > > For further reading on these topics, I recommend both =E2=80=9CWhy Johnny= Can=E2=80=99t > Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D. > > So what does this have to do with GNAP? I think we can be clear-eyed on > what kinds of expectations we have for the participants. If we expect use= rs > (RO=E2=80=99s) to have to set up the AS-RS relationship, or expect them t= o carry > their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve l= ost the battle for > relevance. > > =E2=80=94 Justin --0000000000006166a205be23661f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I too am in favor of avoiding consolidation and correlatio= n. Right now, when I approach a service provider (RS) for the first time, I= 'm offered the opportunity to identify my persona as: email, sign-in wi= th Google, Facebook, or Apple. I know there are people who try to create on= e-off email addresses but that is mostly a waste of time.=C2=A0

    So, along come FIDO2 and DID wallets to the rescue. Now, in theory,= I have a way to start out my RS relationship pseudonymously.=C2=A0

    When I want my resource to be discovered or shared I will= post that RS URL including my pseudonym. If I then want to introduce a med= iator=C2=A0in front of my AS or messaging service=C2=A0endpoint, I have tha= t option. If I want to keep requests away from the mediator, I would publis= h an encryption key along with my pseudonym.

    - Adr= ian



    On Mon, Mar 22, 2021 at 9:55 AM Just= in Richer <jricher@mit.edu> wr= ote:
    On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk = <kaduk@mit.edu>= ; wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhkarp@gmail.com> shared a talk about the Principle Of Leas= t
    >> Authority (POLA) in a recent comment
    >> https:/= /github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-8030996= 93
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin
    --0000000000006166a205be23661f-- From nobody Mon Mar 22 10:49:03 2021 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 1464B3A0EE8 for ; Mon, 22 Mar 2021 10:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.405 X-Spam-Level: X-Spam-Status: No, score=0.405 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 P9JIU7JXK7F7 for ; Mon, 22 Mar 2021 10:48: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 191203A0EDB for ; Mon, 22 Mar 2021 10:48:56 -0700 (PDT) Received: from [192.168.1.22] (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 12MHmnh3013707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 Mar 2021 13:48:50 -0400 From: Justin Richer Message-Id: <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_5F758942-3A18-489D-8070-0E450D7B1F13" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 22 Mar 2021 13:48:48 -0400 In-Reply-To: Cc: Benjamin Kaduk , Alan Karp , GNAP Mailing List , Mark Miller To: Adrian Gropper References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2021 17:49:02 -0000 --Apple-Mail=_5F758942-3A18-489D-8070-0E450D7B1F13 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Adrian, What you=E2=80=99re discussing below, in terms of logging in to a site, = is not approaching the RS. You are in fact approaching the client, and = identifying both the AS and RS to the client. The client is a client of = your identity in this model, and the RS is part of the identity = provider. It=E2=80=99s really important that we don=E2=80=99t conflate = the RS and client in this way as it leads to a lot of confusion = downstream and a lot of broken trust boundaries. With that model in mind, approaching the =E2=80=9CRS" and providing it = your identity is really just a case of the =E2=80=9Cfederated login to = AS=E2=80=9D pattern that we discussed on the WG call. The user here = approaches an RS, which has its own AS. To share things from this RS, = the RO has to authenticate to the RS=E2=80=99s AS. This particular AS = allows the RO to do so using an external identity =E2=80=94 in which = case, the AS is now a =E2=80=9Cclient=E2=80=9D of a separate, = disconnected (but layered) delegation. The ultimate client that = eventually calls the RS down the way may or may not know about these = layers.=20 This same AS, which is closely tied to the RS and trusted by the RS, = might also take in FIDO credentials, or DIDs, or any number of other = proof mechanisms. The output of this is an access token the RS trusts, = but the input is up to the AS. The RS is not what you=E2=80=99re logging = in to. =E2=80=94 Justin > On Mar 22, 2021, at 1:28 PM, Adrian Gropper = wrote: >=20 > I too am in favor of avoiding consolidation and correlation. Right = now, when I approach a service provider (RS) for the first time, I'm = offered the opportunity to identify my persona as: email, sign-in with = Google, Facebook, or Apple. I know there are people who try to create = one-off email addresses but that is mostly a waste of time.=20 >=20 > So, along come FIDO2 and DID wallets to the rescue. Now, in theory, I = have a way to start out my RS relationship pseudonymously.=20 >=20 > When I want my resource to be discovered or shared I will post that RS = URL including my pseudonym. If I then want to introduce a mediator in = front of my AS or messaging service endpoint, I have that option. If I = want to keep requests away from the mediator, I would publish an = encryption key along with my pseudonym. >=20 > - Adrian >=20 >=20 >=20 > On Mon, Mar 22, 2021 at 9:55 AM Justin Richer > wrote: > On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk > wrote: > >=20 > > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote: > >> @Alan Karp > = shared a talk about the Principle Of Least > >> Authority (POLA) in a recent comment > >> = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment= -803099693 = > >> I recommend it. > >>=20 > >> We might expect a protocol with authorization in the title to use = authority > >> as a core principle. I advocate for a GNAP design that maximizes = the power > >> of the RO, to be seen as a human rights issue when the RO is a = human. This > >> causes me to ask how to combine better security with better human = rights in > >> GNAP. > >>=20 > >> Who should have the least authority in the GNAP design? > >>=20 > >> The AS derives authority as a delegate of the RO. If we ask the RO = to > >> partition limited authority across dozens of different ASs by = domain and > >> function, then we are not using technology to empower the = individual. > >> Probably the opposite, as we introduce consent fatigue and burden = normal > >> people to partition their lives into non-overlapping domains. > >>=20 > >> My experience says we should aim for one AS per persona because = that maps > >> into the way we manage our public and private identities. POLA = would then > >> teach care in keeping ASs and RSs related to work / public separate = from > >> ASs and RSs related to private life so that a policy vulnerability = in our > >> delegation to an AS would have the least likelihood of harm. > >=20 > > Thinking about how least authority/least privilege would apply to = GNAP > > seems like a useful exercise. I do want to point out some potential > > pitfalls with one-AS-per-persona that we can also be aware of. If > > one-AS-per-persona becomes one-persona-per-AS as well, then the AS's > > identity in effect also serves as a persona identity and there are = privacy > > considerations to that. If, on the other hand, the > > multiple-personas-per-AS (presumably corresponding to multiple = humans) > > route is taken, we should consider whether that would lead to = various > > (e.g., market) forces driving consolidation to just a handful of > > super-popular AS services. That topic is a current matter of = concern to > > some IETF participants. > >=20 >=20 > Hi Ben, big +1 to this. This is something that we discussed ages ago = in the UMA working group, and it=E2=80=99s one of the biggest problems = with the personal AS (and personal data store) model. This kind of thing = makes RS-first trust models really difficult in practice. >=20 > As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that = wants to access my medical information. It calls an RS and requests = access, but it hasn=E2=80=99t been granted anything yet. Now I as the RO = have set up the RS so that it talks to my personal AS, that only I use. = In addition to the RS having to be able to figure out which medical = records are being requested from the context of the unauthenticated = request (which means it needs identifiers in the URL or something = similar for the RS to be able to tell, assuming that it protects data = for more than one person). So this client software doesn=E2=80=99t know = who I am and doesn=E2=80=99t know my medical record information, makes a = completely unauthorized request to the RS, and the RS says =E2=80=9CGo = to Justin=E2=80=99s personal AS to get a token=E2=80=9D. The client can = now make a direct correlation between the data that=E2=80=99s being = protected at the RS and the person running the AS that protects it. = Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This = is a design feature in the good case, and terrifying in the bad case. >=20 > If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please = talk to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t = exposed anything at all. And from the perspective of both the patient = and the RS, this is more privacy-preserving, and it=E2=80=99s really the = least surprising option. Once the client gets to the AS, it can start a = negotiation of figuring out who the RO is for the information being = accessed. >=20 > On top of this, the usability expectations of people managing their = own AS, or set of AS=E2=80=99s for multiple personas to keep things = separate, is a huge burden. Even in the tech community, I know people = who can=E2=80=99t reliably manage more than one email address for = different purposes. I wouldn=E2=80=99t expect my partner to do that =E2=80= =94 they have trouble enough balancing all the logins and sessions = required for different kids remote schooling, I couldn=E2=80=99t imagine = them having to understand all the requirements for managing multiple = authorization servers and associated policies. I also don=E2=80=99t = expect any person to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve = been on the internet for decades and I can barely keep tabs on my GPG = keys, and only use them when I am forced to. This is exactly the kind of = =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions above, = people will just want to outsource that to someone else, and the reality = will be a few popular providers. >=20 > In which case, we could end up doing a ton of work to allow an RS = choice only to end up with a world where the RS ends up making a limited = choice anyway. We see how that plays out with OpenID Connect =E2=80=94 = RP=E2=80=99s could allow arbitrary IdPs but they choose Google because = it works and that=E2=80=99s where the users are. (And that=E2=80=99s not = to say anything of the proprietary OIDC-like protocols, but that=E2=80=99s= another discussion). >=20 > For further reading on these topics, I recommend both =E2=80=9CWhy = Johnny Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems = Fail=E2=80=9D. >=20 > So what does this have to do with GNAP? I think we can be clear-eyed = on what kinds of expectations we have for the participants. If we expect = users (RO=E2=80=99s) to have to set up the AS-RS relationship, or expect = them to carry their AS, or manage their personal keys =E2=80=94 I think = we=E2=80=99ve lost the battle for relevance. >=20 > =E2=80=94 Justin --Apple-Mail=_5F758942-3A18-489D-8070-0E450D7B1F13 Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_E7A8E8C5-9820-41C8-A175-340A25AD0B61" --Apple-Mail=_E7A8E8C5-9820-41C8-A175-340A25AD0B61 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Adrian,

    What you=E2=80=99re discussing below, in terms of logging in = to a site, is not approaching the RS. You are in fact approaching the = client, and identifying both the AS and RS to the client. The client is = a client of your identity in this model, and the RS is = part of the identity provider. It=E2=80=99s really important that we = don=E2=80=99t conflate the RS and client in this way as it leads to a = lot of confusion downstream and a lot of broken trust = boundaries.

    With= that model in mind, approaching the =E2=80=9CRS" and providing it your = identity is really just a case of the =E2=80=9Cfederated login to AS=E2=80= =9D pattern that we discussed on the WG call. The user here approaches = an RS, which has its own AS. To share things from this RS, the RO has to = authenticate to the RS=E2=80=99s AS. This particular AS allows the RO to = do so using an external identity =E2=80=94 in which case, the AS is now = a =E2=80=9Cclient=E2=80=9D of a separate, disconnected (but layered) = delegation. The ultimate client that eventually calls the RS down the = way may or may not know about these layers. 
    This same AS, which is closely tied to the RS and trusted by = the RS, might also take in FIDO credentials, or DIDs, or any number of = other proof mechanisms. The output of this is an access token the RS = trusts, but the input is up to the AS. The RS is not what you=E2=80=99re = logging in to.

     =E2=80=94 Justin

    On Mar = 22, 2021, at 1:28 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I too am in favor of avoiding = consolidation and correlation. Right now, when I approach a service = provider (RS) for the first time, I'm offered the opportunity to = identify my persona as: email, sign-in with Google, Facebook, or Apple. = I know there are people who try to create one-off email addresses but = that is mostly a waste of time. 

    So, along come FIDO2 and DID wallets to = the rescue. Now, in theory, I have a way to start out my RS relationship = pseudonymously. 

    When I want my resource to be discovered or shared I will = post that RS URL including my pseudonym. If I then want to introduce a = mediator in front of my AS or messaging service endpoint, I = have that option. If I want to keep requests away from the mediator, I = would publish an encryption key along with my pseudonym.

    - Adrian



    On Mon, Mar 22, 2021 at 9:55 AM Justin = Richer <jricher@mit.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin = Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhkarp@gmail.com> shared a talk = about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#i= ssuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to = use authority
    >> as a core principle. I advocate for a GNAP design that = maximizes the power
    >> of the RO, to be seen as a human rights issue when the RO is a = human. This
    >> causes me to ask how to combine better security with better = human rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the = RO to
    >> partition limited authority across dozens of different ASs by = domain and
    >> function, then we are not using technology to empower the = individual.
    >> Probably the opposite, as we introduce consent fatigue and = burden normal
    >> people to partition their lives into non-overlapping = domains.
    >>
    >> My experience says we should aim for one AS per persona because = that maps
    >> into the way we manage our public and private identities. POLA = would then
    >> teach care in keeping ASs and RSs related to work / public = separate from
    >> ASs and RSs related to private life so that a policy = vulnerability in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to = GNAP
    > seems like a useful exercise.  I do want to point out some = potential
    > pitfalls with one-AS-per-persona that we can also be aware = of.  If
    > one-AS-per-persona becomes one-persona-per-AS as well, then the = AS's
    > identity in effect also serves as a persona identity and there are = privacy
    > considerations to that.  If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple = humans)
    > route is taken, we should consider whether that would lead to = various
    > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.  That topic is a current matter of = concern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in = the UMA working group, and it=E2=80=99s one of the biggest problems with = the personal AS (and personal data store) model. This kind of thing = makes RS-first trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that = wants to access my medical information. It calls an RS and requests = access, but it hasn=E2=80=99t been granted anything yet. Now I as the RO = have set up the RS so that it talks to my personal AS, that only I use. = In addition to the RS having to be able to figure out which medical = records are being requested from the context of the unauthenticated = request (which means it needs identifiers in the URL or something = similar for the RS to be able to tell, assuming that it protects data = for more than one person). So this client software doesn=E2=80=99t know = who I am and doesn=E2=80=99t know my medical record information, makes a = completely unauthorized request to the RS, and the RS says =E2=80=9CGo = to Justin=E2=80=99s personal AS to get a token=E2=80=9D. The client can = now make a direct correlation between the data that=E2=80=99s being = protected at the RS and the person running the AS that protects it. = Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This = is a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please = talk to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t = exposed anything at all. And from the perspective of both the patient = and the RS, this is more privacy-preserving, and it=E2=80=99s really the = least surprising option. Once the client gets to the AS, it can start a = negotiation of figuring out who the RO is for the information being = accessed.

    On top of this, the usability expectations of people managing their own = AS, or set of AS=E2=80=99s for multiple personas to keep things = separate, is a huge burden. Even in the tech community, I know people = who can=E2=80=99t reliably manage more than one email address for = different purposes. I wouldn=E2=80=99t expect my partner to do that =E2=80= =94 they have trouble enough balancing all the logins and sessions = required for different kids remote schooling, I couldn=E2=80=99t imagine = them having to understand all the requirements for managing multiple = authorization servers and associated policies. I also don=E2=80=99t = expect any person to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve = been on the internet for decades and I can barely keep tabs on my GPG = keys, and only use them when I am forced to. This is exactly the kind of = =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions above, = people will just want to outsource that to someone else, and the reality = will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice = only to end up with a world where the RS ends up making a limited choice = anyway. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99= s could allow arbitrary IdPs but they choose Google because it works and = that=E2=80=99s where the users are. (And that=E2=80=99s not to say = anything of the proprietary OIDC-like protocols, but that=E2=80=99s = another discussion).

    For further reading on these topics, I recommend both =E2=80=9CWhy = Johnny Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems = Fail=E2=80=9D.

    So what does this have to do with GNAP? I think we can be clear-eyed on = what kinds of expectations we have for the participants. If we expect = users (RO=E2=80=99s) to have to set up the AS-RS relationship, or expect = them to carry their AS, or manage their personal keys =E2=80=94 I think = we=E2=80=99ve lost the battle for relevance.

     =E2=80=94 Justin

    = --Apple-Mail=_E7A8E8C5-9820-41C8-A175-340A25AD0B61 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=PastedGraphic-1.png Content-Type: image/png; x-unix-mode=0666; name="PastedGraphic-1.png" Content-Id: <6D4EF756-B1EF-49D4-9AF4-5B7D5EF220A7> iVBORw0KGgoAAAANSUhEUgAABbAAAAOOCAYAAADReDRcAAAK42lDQ1BJQ0MgUHJvZmlsZQAASImV lwdUU9kWhs+9N73QAhGQEnpHOgGkhB5AQTqISkhCEkoIKajYlcERHAsqIlhGdKQpODrUsSAWbINg 7wMyqKjjYMGGylzgEWbmrffeenutk/NlZ5999r7rnKz/AkBN4UgkWbAaANliuTQ6xJ+RmJTMwA8A BNABBbgBHIcrk7CioiIAapPz3+3dTQCNzdfsxnL9++//1TR4fBkXACgF5TSejJuNcjs6vnIlUjkA CMrAZKFcMsa/oawpRQtE+cMYC8YZQxnjtAlmjMfERgeg7AIAgcLhSAUAUPxQPyOPK0DzUFJRdhDz RGKUN6HswxVyeCh3o2ybnZ0zxp9RtkTjJQBQTVFmpv0lp+Bv+dOU+TkcgZIn+ho3QqBIJsniLP4/ H83/tuwsxeQe5uigCKWh0RMM3c7MCVeyOG125CSLeJPx0G2hIjRukrmygORJ5nECw5Vrs2ZHTHK6 KJitzCNnx04yXxYUM8nSnGjlXunSANYkc6RT+yoy45R+IZ+tzJ8vjE2Y5DxR/OxJlmXGhE/FBCj9 UkW0sn6+OMR/at9gZe/Zsr/0K2Ir18qFsaHK3jlT9fPFrKmcskRlbTx+YNBUTJwyXiL3V+4lyYpS xvOzQpR+WV6Mcq0cPZxTa6OUzzCDExY1ySAWCIECiAEP8IEUpIEckAXkgAECgQjIgAT9xgHocZLz F8nHmgvIkSyWigRCOYOF3kA+gy3m2tsynBycHAEYu88TR+QNffyeQvSLU77cdgA8ilCnYMrHMQGg 9TEAtHdTPpPXE3fleDdXIc2b8GHGPrCABFSBJtABBsAEWAI74IT+a3gBPxAEwkAk2kkSmA+4aD/Z aCcLwVKwChSCYrAJbAPlYA/YB6rBIXAENINj4BQ4By6BbnAD3AO9YAA8B0PgHRiBIAgPUSEapAMZ QmaQDeQEMSEfKAiKgKKhJCgVEkBiSAEthdZAxVAJVA7thWqgH6FW6BR0AeqB7kB90CD0GvoEIzAF 1oT1YXN4BsyEWXA4HAvPgwVwLpwPF8Ab4DK4Ej4IN8Gn4EvwDbgXfg4PIwAhI3TECLFDmEgAEokk I+mIFFmOFCGlSCVSj7Qhncg1pBd5gXzE4DA0DANjh/HChGLiMFxMLmY5Zj2mHFONacKcwVzD9GGG MF+xVKwe1gbriWVjE7EC7EJsIbYUewDbiD2LvYEdwL7D4XB0nAXOHReKS8Jl4Jbg1uN24Rpw7bge XD9uGI/H6+Bt8N74SDwHL8cX4nfgD+JP4q/iB/AfCGSCIcGJEExIJogJqwmlhFrCCcJVwhPCCFGN aEb0JEYSecTFxI3E/cQ24hXiAHGEpE6yIHmTYkkZpFWkMlI96SzpPukNmUw2JnuQ55BF5JXkMvJh 8nlyH/kjRYNiTQmgpFAUlA2UKko75Q7lDZVKNaf6UZOpcuoGag31NPUh9YMKTcVeha3CU1mhUqHS pHJV5aUqUdVMlaU6XzVftVT1qOoV1RdqRDVztQA1jtpytQq1VrVbasPqNHVH9Uj1bPX16rXqF9Sf auA1zDWCNHgaBRr7NE5r9NMQmgktgMalraHtp52lDWjiNC002ZoZmsWahzS7NIe0NLRctOK1FmlV aB3X6qUjdHM6m55F30g/Qr9J/zRNfxprGn/aumn1065Oe689XdtPm69dpN2gfUP7kw5DJ0gnU2ez TrPOA12MrrXuHN2Furt1z+q+mK453Ws6d3rR9CPT7+rBetZ60XpL9PbpXdYb1jfQD9GX6O/QP63/ woBu4GeQYbDV4ITBoCHN0MdQZLjV8KThM4YWg8XIYpQxzjCGjPSMQo0URnuNuoxGjC2M44xXGzcY PzAhmTBN0k22mnSYDJkams4yXWpaZ3rXjGjGNBOabTfrNHtvbmGeYL7WvNn8qYW2Bdsi36LO4r4l 1dLXMtey0vK6Fc6KaZVptcuq2xq2drUWWldYX7GBbdxsRDa7bHpssbYetmLbSttbdhQ7ll2eXZ1d nz3dPsJ+tX2z/csZpjOSZ2ye0Tnjq4OrQ5bDfod7jhqOYY6rHdscXztZO3GdKpyuO1Odg51XOLc4 v3KxceG77Ha57UpzneW61rXD9Yubu5vUrd5t0N3UPdV9p/stpiYzirmeed4D6+HvscLjmMdHTzdP uecRzz+87LwyvWq9ns60mMmfuX9mv7exN8d7r3evD8Mn1ed7n15fI1+Ob6XvIz8TP57fAb8nLCtW Busg66W/g7/Uv9H/fYBnwLKA9kAkMCSwKLArSCMoLqg86GGwcbAguC54KMQ1ZElIeyg2NDx0c+gt tj6by65hD4W5hy0LOxNOCY8JLw9/FGEdIY1omwXPCpu1Zdb92WazxbObI0EkO3JL5IMoi6jcqJ/n 4OZEzamY8zjaMXppdGcMLWZBTG3Mu1j/2I2x9+Is4xRxHfGq8SnxNfHvEwITShJ6E2ckLku8lKSb JEpqScYnxycfSB6eGzR329yBFNeUwpSb8yzmLZp3Yb7u/Kz5xxeoLuAsOJqKTU1IrU39zInkVHKG 09hpO9OGuAHc7dznPD/eVt4g35tfwn+S7p1ekv5U4C3YIhgU+gpLhS9EAaJy0auM0Iw9Ge8zIzOr MkezErIasgnZqdmtYg1xpvhMjkHOopweiY2kUNKb65m7LXdIGi49IINk82Qtck1UOF1WWCq+UfTl +eRV5H1YGL/w6CL1ReJFlxdbL163+El+cP4PSzBLuEs6lhotXbW0bxlr2d7l0PK05R0rTFYUrBhY GbKyehVpVeaqX1Y7rC5Z/XZNwpq2Av2ClQX934R8U1eoUigtvLXWa+2ebzHfir7tWue8bse6r0W8 oovFDsWlxZ/Xc9df/M7xu7LvRjekb+ja6LZx9ybcJvGmm5t9N1eXqJfkl/RvmbWlaStja9HWt9sW bLtQ6lK6Zztpu2J7b1lEWcsO0x2bdnwuF5bfqPCvaNipt3Pdzve7eLuu7vbbXb9Hf0/xnk/fi76/ vTdkb1OleWXpPty+vH2P98fv7/yB+UPNAd0DxQe+VImrequjq8/UuNfU1OrVbqyD6xR1gwdTDnYf CjzUUm9Xv7eB3lB8GBxWHH72Y+qPN4+EH+k4yjxa/5PZTzsbaY1FTVDT4qahZmFzb0tSS09rWGtH m1db48/2P1cdMzpWcVzr+MYTpBMFJ0ZP5p8cbpe0vzglONXfsaDj3unE09fPzDnTdTb87PlzwedO d7I6T573Pn/sgueF1ovMi82X3C41XXa93PiL6y+NXW5dTVfcr7R0e3S39czsOXHV9+qpa4HXzl1n X790Y/aNnptxN2/fSrnVe5t3++mdrDuv7ubdHbm38j72ftEDtQelD/UeVv5q9WtDr1vv8b7AvsuP Yh7d6+f2P/9N9tvngYLH1MelTwyf1Dx1enpsMHiw+9ncZwPPJc9HXhT+rv77zpeWL3/6w++Py0OJ QwOvpK9GX69/o/Om6q3L247hqOGH77Lfjbwv+qDzofoj82Pnp4RPT0YWfsZ/Lvti9aXta/jX+6PZ o6MSjpQzLgUQdMDp6QC8rkL1chKqHVAtTZo7obfHDZp4Rxgn8J94QpOPmxsAVX4AxK0EIALVKLvR YYYyBZ3HZFKsH4CdnZXjXyZLd3aayEVB1Sb2w+joG30A8G0AfJGOjo7sGh39sh8t9g4A7bkTOn/M cOjbT4mFNlm9+kpQLPinTbwD/KXHf85grAIX8M/5Ty3AIe1FGuUcAAAAVmVYSWZNTQAqAAAACAAB h2kABAAAAAEAAAAaAAAAAAADkoYABwAAABIAAABEoAIABAAAAAEAAAWwoAMABAAAAAEAAAOOAAAA AEFTQ0lJAAAAU2NyZWVuc2hvdKgXULYAAAHXaVRYdFhNTDpjb20uYWRvYmUueG1wAAAAAAA8eDp4 bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSJYTVAgQ29yZSA1LjQuMCI+ CiAgIDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYt c3ludGF4LW5zIyI+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAg ICAgIHhtbG5zOmV4aWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20vZXhpZi8xLjAvIj4KICAgICAgICAg PGV4aWY6UGl4ZWxYRGltZW5zaW9uPjE0NTY8L2V4aWY6UGl4ZWxYRGltZW5zaW9uPgogICAgICAg ICA8ZXhpZjpVc2VyQ29tbWVudD5TY3JlZW5zaG90PC9leGlmOlVzZXJDb21tZW50PgogICAgICAg ICA8ZXhpZjpQaXhlbFlEaW1lbnNpb24+OTEwPC9leGlmOlBpeGVsWURpbWVuc2lvbj4KICAgICAg PC9yZGY6RGVzY3JpcHRpb24+CiAgIDwvcmRmOlJERj4KPC94OnhtcG1ldGE+CothOfwAAEAASURB VHgB7J0FuBxF1oYrijtBgksWZ3F3d3dZ4MfdHRZYYHFYLDhhcVkcFlssuPsSJIQECwQInoSEzF9f Q9/t6dtV3T3TM7fn3vfkuZnu8nrbT5061a1ixSAQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAA gZIR6F6y9tAcCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgEBAAAU2JwIEIAABCEAAAhCAAAQg AAEIQAACEIAABCAAAQiUkgAK7FIeFhoFAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACKLA5ByAA AQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQKCUBFBgl/Kw0CgIQAACEIAABCAAAQhAAAIQgAAEIAAB CEAAAhBAgc05AAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAqUkgAK7lIeFRkEAAhCAAAQgAAEI QAACEIAABCAAAQhAAAIQgAAKbM4BCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQKCUBFNilPCw0 CgIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABFBgcw5AAAIQgAAEIAABCEAAAhCAAAQgAAEIQAAC EIBAKQmgwC7lYaFREIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQggAKbcwACEIAABCAAAQhAAAIQ gAAEIAABCEAAAhCAAARKSQAFdikPC42CAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABFNicAxCA AAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIFBKAiiwS3lYaBQEIAABCEAAAhCAAAQgAAEIQAACEIAA BCAAAQigwOYcgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAgVISQIFdysNCoyAAAQhAAAIQgAAE IAABCEAAAhCAAAQgAAEIQAAFNucABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIlJIACuxSHhYa BQEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAiiwOQcgAAEIQAACEIAABCAAAQhAAAIQgAAEIAAB CECglARQYJfysNAoCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQ6AkCCEAAAhCAQKMI/Prrr+br r78O/kaMGGG+//57M+mkk5o+ffqYaaed1kwzzTRm4oknblT1lAsBCEAAAhCAQCchwDtFJzmQdAMC EIAABCBQA4EOV2B/8cUX5oYbbqih6clZunXrZnr27Gl69+5tevXqZSaZZJJAQSIlSd++fc0MM8xg lAaBQGcgoBf5/v37m3HjxrXrziKLLGLWWGONduEEQKCRBKSkfvTRR829994b/P3444+ZqltmmWXM hhtuaNZZZx2jc7d7dyYIZQJXcKIXXnjBPPXUU4ml7rLLLsHzNDGyBQLffPNN8/DDDye2dNtttzUz zTRTYlyjAj/77DNz0003JRavQZ699torMY7AchP4/PPPzY033pjYyDXXXNP8+c9/TowjEALNInDn nXeawYMHO6vTs3ieeeZxxjczgneKZtKmLghAAAIQgEC5CXSrWOnIJj7wwANmvfXWa1oTJptsMrPJ JpsEir1VVlnFzDrrrE2rm4ogUDQBDQBpYCZJttxyS3PrrbcmRRHWYAJjxowxH330kZlvvvkaXFM5 iv/tt98CRdyll15qnnnmmbobNd1005nNNtvMHHrooWbuueeuuzwKyE7giCOOMGeddVZihieffNKs tNJKiXGtEHjGGWeYo446KrGpUujo3aCZcvfdd3vr7ODXs2ai6FR13XfffcFgXFKnTj75ZHPccccl RRHWYgTeeOMNs/DCC7ecUcwvv/wSGPP4Bpd33nlnM2DAgA47IrxTdBh6KoYABCAAAQiUmkCXM3HT C9t1111ndtppJzPbbLOZv/zlL+bDDz8s9UGicRCAQOsQkPWxPmq32GKL1ml0HS197LHHzGKLLWZ2 3HHHQpTXaspXX31lpAzv16+fOf74481PP/1URwvJCgEIQAACECiGgL4ZZHijmUJyj9Vqcs899xif 8lr9ueaaa8w333zTIV3jnaJDsFMpBCAAAQhAoCUIdDkFdvyoSJktJYmszpLcMMTTsw8BCEAgiYDc AWy99dbB7I73338/KUmnCtP9crfddjOrr766kWuGRskpp5xi5pprLnPXXXc1qgrKhQAEIAABCHgJ yHL5pJNOCr4ZNHu0VeWKK67I1PTrr78+U7qiEvFOURRJyoEABCAAAQh0XgJdXoEdHlpNmd5uu+2M pv4jEIAABLISGDt2rDn33HPNzDPP3GVctsj3+vbbb2+uuuqqrJjqSieL7E033dTcdtttdZVDZghA AAIQgEBeAnILI5/QJ554Yt6spUov63FZOGeRCy64wIwfPz5L0rrT8E5RN0IKgAAEIAABCHQJAiiw I4dZyhEpSeR7DYEABCCQhcASSywR+GrOkrYzpNH9cauttuoQZb3qlYsWBAIQgAAEINAMAocddljg 0/zTTz9tRnUNrcO1uGhSpVrH4/HHH0+KKjSMd4pCcVIYBCAAAQhAoFMT6Nmpe1dD5zQtUNPr9tpr rxpykwUCEOhqBBrpPqOMLPv372+0+FwW+dOf/mRWW201s9BCC5k555zTaBHdCSec0IwcOdJIGTBs 2DAzZMgQ88EHH2T2n73GGmuYV1991Sy66KJZmkAaCEAAAhCAQM0EOss6OXLRcfHFF+ficNlllwVu wnJlypmYd4qcwEgOAQhAAAIQ6MIESq/AHjp0qOnZM18z5QZE09H0q4VKpCCRT1q9iGkqeprsvffe ZoMNNghcAqSlJR4CEIBAVyEgH6DHHntsand33XVXc8ABBwSLWaYm/iOBBgLk7zqLm5D999/fPP30 01mLJh0EIAABCECgSxN44oknMn0DRSHpefz555+bvn37RoML2+adojCUFAQBCEAAAhDoEgTyaYY7 AIlemvIqsOPNXH755YOg4447ztxyyy1G0wHTFNnyc3fllVfGi2IfAhCAQJcloEWdNCjok6eeesqs sMIKviSJcQsvvHDglkSK7IMPPtjrp/OZZ54xAwcONCuttFJiWQTWTkADD2uttVZiAUsvvXRiOIEQ gMD/CKy66qrmkUce+V9AZGvBBReM7LEJgeYRGDBgQGJlmh0lw53DDz88MV75sgxcJ2ZOCeSdIgUQ 0RCAAAQgAAEIVBEovQK7qrV17vTu3dvsuOOOZqmllgoUHz4lthYn0wImE088cZ21kh0CEIBA6xPQ 9OOTTz7Z25F///vfNSmvo4VKkX3HHXcE92nNnHHJ6aefjgLbBaeOcC1Gqj8EAhCojcAkk0xi5OoI gUBZCHz99dfG5f9aM0433HBDpwJb30JHHnlk3cZEcRa8U8SJsA8BCEAAAhCAQBqBLrmIo1YSf/LJ J9PYGPnDRiAAAQhAwJh333038FvtYnHRRReZdddd1xWdK3yKKaYIlNi+TLo/v/32274kxEEAAhCA AAS6PIFbb73VyWCdddYx+i7SmhVJImOfRnwP8U6RRJswCEAAAhCAAAR8BLqkAltA5p13XnPEEUf4 2ATT2b0JiIQABCDQRQgMHjzY29M999zTG583coEFFjDXXXedN9tLL73kjScSAhCAAAQg0NUJaA0g l6y44opBlGaouuSSSy5xRdUczjtFzejICAEIQAACEOiyBLqsAltH/MADD/Qe+EGDBnnjiYQABCDQ VQh8+OGHzq7K8rretQqSCt9iiy2SgtvC3nnnnbZtNiAAAQhAAAIQqCbw2muvGa0tkSRrrrmmmXTS SYOobbbZJilJECYLbN87gDOjJ8JXHu8UHnBEQQACEIAABLowgS7lAzt+nLVApF7eXIvtDBkyJJ6l 5v3x48ebL774wqjM7t27Gy2aMsMMM9RcXjxjpVIx3333nZGfuxEjRphRo0aZqaaayvTp08dMO+20 ZqKJJopnafr+yJEjzSeffBK0b+qppzZzzDGHmXLKKZvejjKz+u2334IV34cOHWp0zsw444zBX/iB 0XRYsQrLzC7WVPPDDz8E19yXX34ZsNS1oL9pppnG9OjRI56c/RQCPmsp+a1uhEw44YRm/fXXN/ff f39i8Y1yIaJ71bfffhv8ff/998FaCOG9VO5NdA/vSPn111+D+8Rnn31mdM+YddZZA7/VjRhEaGQ/ dT/RoqDireeXfnXf09oT8iMs1rPMMovp1q1bI5tB2QUQ+Pnnn80333wT/OlY6h6re63eP/Tbkeem fO3qWhk2bFhwfundS386vzqbdPbnnu594b1C94uffvrJTDDBBMH9QvcMvTNNPvnkne2w1tWfa665 xpl/vfXWa4ube+65zTLLLGOef/75trDohtYGOu2006JBdW13pXeKukCRGQIQgAAEIACBNgJdWoEt Cnphcymw9WGtjzK9FCfJDTfcECg44nHbbrtt8NGm8F9++cVoBe+//e1vJr5o5GSTTRYseHbAAQeY tddeO/dHuj7GHn74YXPfffeZu+++O96Mqn0pzDfddNPAR+0KK6wQvPBXJSh4R4qJZ555xujFWdP8 XdYfYiDlV79+/cyyyy5r/vKXvxgprYqWsrISp8cee8xcfvnl5vXXXzeuReumm246s9tuuwWLkMr9 TTOlI9m98MIL5sUXX2zXXS3EuvTSS1eFjxkzJriW5XbC5+9RmTbffHOz8cYbB9eDFCxZRZZMTz/9 dKbk//3vf82FF17YLq0UOzqWWlQ2SfTx6HKN0atXryBvRyqDktqsgalGie6NLgW2jkcRIoWI7qNP PPGEuffee9vdq+N1aMErKda1UNtcc80Vjy58X4rBm266ydx+++2BFdynn36aWId8mIa+THfaaSez 0EILJabzBb7yyivm2WefTUyyww47BAOjiZEZAvU81DX91FNPmf/85z/Bb1o2PSNWWmkls9xyywUL e+r51YhnRFo7iK8mIKXwQw89ZB5//PHgvut6xoe5ll9++eCakdHAYost1tBBICk5b7nlluBPfnY/ +uijsBlVv3qubr/99marrbYKnifRgRL1J2mtFA0W6dnhk+HDh5vbbrstMckqq6ySel2W7bmX2JEm BcpKV89cHQstEhx/j05qht4pdb5JGav7ht7zs4oMQG6++eaq5LonuuTiiy8OBmji8Ztsskkw+BYP b/Z++A3iqje+2Oguu+ziVGCrryeccEJT7r+t/k7h4k04BCAAAQhAAAJ1ErAKtA4V+0JasV1w/o0d O7ah7Tv11FOddatd9iXKWb/9sE7Maz/MgzzWOqSy5JJLJqaJ99m+cFfEIot88MEHFfvBlanceD3a tx9tlWuvvbZiP0CzVJcrjbUAr9gVyytWkVJT+2aeeeaKVfhXijruZWWl/lkla8V+yOfmZAciKtaa Pzgun3/+uTP/lltumevYxROXgd1+++2X2D+Fh2ItNiv9+/evuK7HpGsgGnbKKadU7EBVWJz39/jj j09sT7S8LNt2UMBZz1577eWtQ9dYR8gZZ5zhbJeu20bcT9TPt956Kzi2uqdYX50Vnf977LFH5Zhj jqmcd955daGwiuDKkUce6exXlmOp9lhL8LrakZRZ5/XAgQMr1i9pze2zCueKruM8cvjhhzvrs0qk PEW1pbWWdhU7UOssNwvnMI2eX1aRkvmabWuE3Tj99NOdbbjzzjujSZuyfddddznbo/6WUazFa8Bf 13x4TPL+5nnfycPAzpYI7gk6R/K2Se9qVmndVt1JJ52UWIbaniZ2ECwxr9p08sknp2WvlO25l9rg ghPo/cgqkStinfc4JqXXu5A1EMjUSmvQUkiddsAxU32NTqT3zCQmCtN1oudMVKwC35leeYrsV2d8 p4iyZBsCEIAABCAAgeIJdPgXUkcrsA866CDvy5qU0C5xKcykwNaHVFbldfhyGVXKJdVpLSkqhxxy iLe9YVlZfvVx8PLLLydVVVOY+u1ikqU90TTWYryij/tapcys7FTmuj/MxFkfyY1QYJeJXdqHvPpv fSXWfU3oQy6qvHCdd11Zge37ENa1K+Vgq4g+2qUEjd5z6t3eddddK3b6fiEIpCTcbrvtCmufBkWk mMgiRSqwR48eXTn00EML60f0GOkZYdepyNKltjQosNtQ1LRhra0DpVf0ONSzrQEpO+uoprbEM1mr /kLeP+xsuYp1y1MpswK72c+9OOtG7tsZVxVd2/WcV668en7HFbbxvnQ2BbadweRkefDBB8e7H+xr UNbF0Fq2J+apJbAzvVPU0n/yQAACEIAABCCQn0DHOvK0b0gdLXLb4JNafSRaRbPTDYCrPrkecYmm kGvq7bnnnutKkjtcU2SXWGIJ5/T8rAXa086cffbZwXR6uV0pQjTlV1Mw77jjjtzFlZnVe++9F0xV Fvt6RJzlxsAq+esppl3eMrOLN1Z+whdZZBGjxYXqFU1L1pRjFgV0k5RrCp8cddRRgQsOX5oyxGmd ALkA2HfffQttjvyDyr2FXO7UI7r3adr7jTfeWE8xVXkvvfRSI1+nmk7eLNEUcPXjnHPOaUiV4mQH iY0dhG1I+RT6PwJyF3LssceaVVddNZMLh//l9G/Jlcziiy9e931D7n+sMjzwp+6vMT32r3/9q9l/ //1l3JGeuANSdObn3kUXXRS4CXK5fKkXt7V+N3KtVNZjW2//4vmH2DV35ObHJXIJlSRi5BK5Bqz3 /TUsu7O8U4T94RcCEIAABCAAgcYT6NIKbL3E+nzbWavM3H6pdcjkU1vKjDwiH9XyAZ0kegmVIkAv jo2QDTbYwFx55ZU1FW0t7IxWLrdWezXlT8skX8Uuf8BJecvMSv2QwsXlvzapP2lh++yzT1qSzPFl ZhfvhHwWSyGXxR9mPK9rX4MCG220kZH/VKQ9ATtjIzh/28f8L0QKrqOPPjpYqPV/oeXZ0oKM8qkt P9eNEH3Y6xqv1Te3/AlrUKYoBUG0j7r/yL+ptUCMBjdkWwtgyrfqq6++2pDyw0J1zcqHsfzfI40h oPckPWf+/ve/N6QCHUPdN6xbs5rKVz4N5hYp1iWVOfHEE4ssspCyOvNz75JLLgkGDgoB5SlEa2QU OTjoqarDo7ROj0vmn3/+wBd9Uvw666xj7Cy/pKggrNbvhXiBneGdIt4n9iEAAQhAAAIQaCyBno0t vtyl64NeH08ucSmUXenDcOvXLdzM/Gunnycqy2UxJwWza3G/eAV6IdQCSVKIq292inUmZc3uu+8e LKS48sorx4v07p955pmpC+aFBay22mrmz3/+c7DgjawgZe2qBet8x0B51X8dKy2e5JMys7KuaMzq q6+e2lf1T8dQ1sB9+vQx+mDVIlSuhUZ9PPLElZldUj+uv/76pOB2YboWNMiiBRWziCy/tKCmdV2S mNy1oGtiYk/gBBNM4Iktb5QGqrTgmU+smwajv5133jlQLsoysgz9HTVqVDCrI6tSVfcrfeRrkU/r GsRogMf6SfZ1PYjToIoUANZ3t9EgaFZRPlmGp90PVZ7K1QCO7olaFFQzOzSbKO08t1O2gwXN7NoP WZtVU7rjjjsu0zNL/VhwwQXNTDPNZPr27RvUJc7607MrCws9G2VhfuCBB9bUVjL5CWhA6oorrvAn +iNWzy4trjvDDDMY68fYWHdZgQVoloFGWX3OMcccgSV1pspsIllw+6xFo+XoPqTBoamnntpoppEG mRplFBCtt8jtjnruFdmHpLJ0vWcdjNczfZZZZgn+dCy16KKe29bXv3Oxznide++9d7Co+cQTTxyP Mklh7RJlCJh00kkzpGpcEusGx1x22WXOCvTO7xI9rxXvmvGpxan1DPEpuV1lx8Nb+Z0i3hf2IQAB CEAAAhBoAgFrXdOh0lE+sLVoW9pCg/KR6pNa/D2rzqR89gU8sSr7Eun0RWdPjyDOKgEqdgptRf5G k0T+uK3FRGK9YRn6VTn2QzOpiMQwLVwWze/aPuussyquhefk69XlazJanhY7TJMys5KvwWh/kra1 0JBVVid2U4s2Wouw1DKi5eZZxLGs7Fw+sKP9jG7rPLn77rsrup7kxzQUbduptJX1118/laGugzwL Ekbrj25b5WdYfa7fsi7iqE5Y6/TU+2aUQbgtf87//Oc/cy8omAtcSmKrtEg99ro3249zp79oO9BT sW6NMvlotQrwXIvRZlmscZVVVqlYpVvVuR3t9nPPPZdp7QU9L1xSrw9sO0CQylls5MM/7TrTugq6 psPzyPVrFaeu7lSF4wO7CkfqjhbSczGPhuv55losVPdenZc+X7xhWbr3yr9zFtFCfzruYV7X7xFH HFHRuhNJYt1x5F5XJMu51qhFHF197IjnXhLPWsN8PpfVZ92X5b/at6i66rYzP4LFfV2couF6T8gq dmDReZ7leWfOWl8R6R599FFnm8UhXAjcVVfafdwOarmy5gpv5XeKXB0lMQQgAAEIQAAChRDosos4 ZlGMWWs2L+QkRXT0BTncltJaCxJGP9a1oNY//vGPyswzz1yRUiJJbrvtNu8LqMqXssta6SZlbxcm JbLvRVzl6UMii6gvWswl7GPSr+KzfoxK4aiP16RywjDr7sXZtDKz0nkU9sH1K0VBFrFWncE54yon Gp5VgV1mdlmuU/VZ16K1nK66xlw87fTw1OMhhUtWiTKPbndGBbaYSFGV9d4X5RFu6zq3VpOVq6++ OliEL21RrazHwZcu7WNcbbNuCDIP4Gmw8Jhjjkk9j6QwzSIaXAn5uH4HDBiQugCZ6pLCMG2wS88B l9SrwJZy2tUHhWdlErZP/clyj3IpUMNy9IsCO0rDv63B5bRnshbbs+5u/AVFYtMWbdP5IUV3Fklb hFVt13WfRfRukdbX8JwukwK7I597WbhmSaPFN0O2Sb96R05Ttsbr0YBF2ruunSEUz+bc95VVVgW2 9W/t5KpnXRbxDRBluQ6y1KE0rfhOkbVvpIMABCAAAQhAoFgCXU6BLaud0047zfliF75A6yM8TbIo cezCixU7dd1ZlNojC+m46KM9zUI8q9IzWrasHaTYDPuZ9Jvlg1QW3Ul5wzB9hOoDOI/Yxbi8ZcqS KknKzirN8iyPJZD6L6sxfdSFrF2/WRTYZWeXRYGt6yTvR2Sa8kMKwKzi4l+rAlsf37KyTfqzrnSy Nquh6dQ2V7/zhus+av3oV6wbiIp1B1F4u6Ugt+4DvO2VQl334rwia21ff9U36wbDW6yeD2nXs89i Oqlw9dm6evG2TYOoSVKPAlvnro+HdZWVVGWmMOuuylu2de+SWg4K7FREbQnSZkZJgTV8+PC29Fk3 nn766dQBsLQBRN3vfe9fup4+/PDDrE0K0mkQPe061LmdRXHXDAvsjn7u5YLrSZz2jNegfS0ia2zf oESe53OrKbCtixzvvVKziLKIXVTTW07adZqljjBNK71ThG3mFwIQgAAEIACB5hPoMgps68O0Yhdv yTQdWR8pTz75ZOrR8H1AqQx9YKQpL1yVSGHhUwTksR6J15GmMMmiZFhmmWWc7dNHg16gaxGfYlzl JimZyswqzfra+oqtBVNgWeY7PxSXRYFdZnYCk/Zxq37WovTUeeSzLpLyL6u4jkOeD+SsdZUpne6R WRQ+Lj6ucN03jzzyyOAeHJ21Umvf0z6MdS9Luq9krc+n8FUfNdPGJ2nW13ZNBV92Z5yePbKQdXG2 /lET8/r6k/Zc9N2/9bx0ublKbEgsMG2qeZrLLxWHAjsG1bErF2uu80bhOpZ2MWJH7vRgn4JX5ftm CKh0XRO+9umar0WyzNQoiwK7o597tfCN59EAuk/JLAVqPaJ3ftd5onM4q7SaAluDwb5++4xqoky+ /PJLZzkqv57vkGg94XarvFOE7eUXAhCAAAQgAIHmEyi9Als+su0Cdrn+5K5DL676oN1///1TXV3E X/TkJzeLpCmw7YI7WYpJTOObhq0XfrsoYGK+rIFqW7zf0X2fZZXcgkTTxrfFv1YZM2aM17JKPlHj UmZWUl7F+YT7Uv5JUVCrSMkXlpX0m0WBXWZ24pKmwBaDWuXss8928pNSM6sksVdYZ1dgi49mj6T5 7HbxyRKua+Tkk0+u636X5n++FkVQ9NyQX2wda1d/XANvYRl6RrnyyrdtPcr1Cy64wFm2XDwlST0K bJ+P+Xqu1bCdvnNN50maoMBOI/R7vJ7hrnNS4TfeeGO2gjypNFDuq8O1HoSK9A2gH3rooZ5a06N0 HvnaVQYFdj3XUlHPvXSS6SlefPFFL2vX2inpJf+eYtiwYd7ys95bW02B7Vs34IADDsiKL0i3+eab exnWe4zijWmFd4p4m9mHAAQgAAEIQKB5BEqvwPZ9SDQiTsqGrO4IfApsxclirBZJUxDnnU6e1AZZ NvosUG+66aakbEGYfNe62Mvir16ftj6FU/zDreys5ELGxeqcc85xMs4SkTZNNE2BXXZ2YpCmwNa0 71rFZ5mr8ziruI5vV1Bgh4wef/zxyrrrrus8112MsobrfqpBybz3Ft3nfBZ+eT/mw/7GfzUl29cX ly9e9cfXPt99ON6GpH35jvW1K2kgtB4FtpSSLmV+2poSSe2Ph/nciPz1r3+NJ2+3jwK7HZLEAJ// 3KLua2nuZuSeJ0nS8im+HtFsPd81UwYFdhmee/UwDvM+8cQTwRowSfdAuZWqV3T/9x3LrAYEraTA fv311719zuuGLG22xHnnnVfvYUrMX9Z3isTGEggBCEAAAhCAQNMIdLcvd0iEgPWjafr06RMJqW1z jTXWML169aops7VK8eZba621vPFZInv06GG23357Z1Kr3HPGWZ/Nzrg999zTdOvWzRmfJcJ+PBtr eWms72hjldnmkksuMdby2ljfz+bUU0+tKqLMrKwlibGzB6raG92xbiqiu7m3p556amOtY3LnCzOU mV3YRt+vVaSYOeaYw5fEGzfffPM54+3gkzOOiPYE7EK0xs6WMYMGDTJ2cUNjBwDaJ6ojxLrDMDvu uKNZeeWVjfWJmrkkqzg2dkDSmd4qXJ1xeSI22GADY5UwzizPPvtsYtxrr73mbJ9V2puNNtooMV/W wBlmmCHgZpVuRvdVa11q7EJ6Rlysos5MOeWUWYvKlM66EDHvvPOOsa4BjFUkGj1H7GwfYxdYNb7r LVPhNpHveueazUrRn84q/YJj5kq1zz77uKJyhfft29f4noGPPfZYYnnW5U5iuALtItRG5dYjuu72 3nvveopoaN7O9NzT/dwqKo11VWGsMjm4d1gDDWNnT5pjjz22bo56z7UuqZzl6FzvbPLPf/7T2SWd O0sssYQzPilC7+G6JlxiB5qMHYh1RdccXtZ3ipo7REYIQAACEIAABAoh0LOQUjpBIVI+6MV5ySWX LKQ3yy23XM3luJQdKlAvdbUqxuMNWmSRReJBbfuuj0c75dL4FNh2dfO2MmrdsNMfzSeffJIpe5lZ DRw40NkHnWdS0tcr1krJ3H777TUVU2Z2WTpkXSBkSeZM4/soQxnmxOaNmGeeeYJBJg00SdEspfbD Dz9sXPcTb2EJkU899ZSRMla/K6ywQkKK6iDrhqA6ILKnj3mVVYTonmwXgjRnnXVWYnFS0uy7777t 4nwDXLqXTjzxxO3y5A249tpr82apO3337t0DRaKUifU8C+MNmWSSSeJBbftcs20o6trQQLFPfEpn X76kOA1KaUAlSTRorYEQKSGjYi1Co7tV25tssknVfq07W2yxRTBwXmv+RubrrM893et0T9ZfkTLF FFM4i9P7bGcS69vaaBDRJbvttpsryhmuZ5sGdOzsl8Q0djZAMAix+uqrJ8bXG1i2d4p6+0N+CEAA AhCAAATqI9C9vuydI7csDKRsKUp5LSpLL710zXCk7HDJiiuu6IrKHe5T3tjp3oGFXrzQESNGxIOq 9vv161e13+idMrP68MMPnd1ffPHFnXF5IqTsr1XKzC5LnxZddNEsyZxpevZ0j9/pQxCpj8BCCy1k rMsf8+ijjwbWdfq1bh5MvQoYtWq99dYLrIjTWvjee+85k6y00krOuFoifPd8KdyTxC6ElxQchNV7 fjsLbrGIjz/+2Nx2221G1vJbb721s/V23pozjojsBAYPHuxMrJkVRcxQCyvwWYNq1sWQIUPCpG2/ svB3iW9Q3pUnKbzM1169bevszz27JoHR4Lxd6NMsu+yyxrrMSDrEQVhnu2dowFjXjUt8909XHoVr 9o5P7ILAvujC4srwTlFYZygIAhCAAAQgAIGaCLg1ODUV11qZdt9998CyoN4PgqRezzbbbEnBmcI0 Dd8lN9xwg2mWpZmm3k8++eRVTbELtlTtR3fswkrG93EUTVvUdplZ+VwX6EW8CJl99tlrLqbM7LJ0 atppp82SzJtGMy98x8mbmcjMBGRdZxcMDf5OOumkQKEtFzbWB6p54IEHvEqGpEr0ka7ZKFJOyELL JT4L7KIGkcK6fc8R1zlmfVSH2dv9FqWMa1dwCQOkSJIbASmrNfCnAdQ333wzOL4udiXsRqdokl3U 1NkPPeOLFLm48d2Dv/3223bV+a6ZItzUqMKpppoqcIMk69KyCc+934+IFNWaqadjpHcZDWzIJZPc I3VVueqqq5xdtwvs1uxeR++rMpZwsdUAo11TpebynY32RHTUO4WnSURBAAIQgAAEINAEAl1GgS13 AbK4W2qppYIXMU1rlg/hRkmtvkU1ZdZnQaGXdVmWNEPkwzkuPgtsnyIpXk4R+2Vn5VO8+Hy55mGj qfpSKjz//PN5sgVTs8t8nmXpjM8FSJb8pOk4AnIFseqqqwZ/UmjbBUkDNyN33XWXufHGGzM1TOev LLyVxyU+a9Ki71dp17TaGz9nhw8f7mq6qWdwylloB0doZoNmO0lBLaWTlKWyktc+Ug4CSVbPYcuK du+gcjWQpEGsJIkrsKW0dD23pAgvyr2a2qLZZGVUYMfvIUncOlOYlNRvvPFGcL/QPUP3dN0vfO9X nan/Wfsi1z+u60hl6Lp2uQHJUodvtpDyDxgwoBC/5VnakpSmWe8USXUTBgEIQAACEIBA8wiUXoEt f4d5rXp79+4dWA7rRT/8m3TSSeteXDDPYan1I0MLa5VFRo4c2a4pPgV23Fq7XeaCA8rOymcpViSr WqZ0l51dllOlSIZZ6iNN4whMM800Zssttwz+LrroomARL31su5RVYUvkj//tt982Cy64YBhU9RtX gEUjfb5Ro+mybmvxWt33XW3+7rvv2imwffcIPbM6i8ja/pxzznH6O+4s/ewM/fjpp5+c3ZBlctHi uw51zUTF9/5RhGVytC5fu6Lpmr3dFZ57uodqMUIZa6QpTpvNv6z1pQ38SumvAd9GyQUXXBCUn/d7 rVHtadQ7RaPaS7kQgAAEIAABCGQjUHoF9jrrrJNbgZ2t641LJSWGlBm1SJLVcy3lFJEn/vGoMjXN 2yW1Ku1d5aWFtzKrIpVTtXxol51d2rFXfFk+lLK0lTTZCUhJdtxxx5n99tvPHHbYYcY3LVqlSjEq 668k8blbasT9SoNJLgW2rrlZZpmlqpk+C88i7xFVlTZpZ/z48YFFoJRQLh/gTWoK1eQg4PP/3wjl qW+2WvwdxGd1W/SgbCPuDzkOgzNpZ37uyQ3FJZdcYs4//3znfdQJpgtH6F7bv3//DiWga1M+uDfa aKMObUdS5UW+UySVTxgEIAABCEAAAs0jwCKODWA90UQT1Vyqz/qp5kJrzJi0QrtLOaMqZPneTCk7 K1/7fv7558JQ1aLo8rWtsIZlLCjpPMuYlWSdmIAUW1dccYWRixGfXHPNNc51AXxWmePGjfMVW3jc hBNOWFVmWv2trKiSZblcG22wwQYor6uOevl3fNdMXKFcRG/kBssl8WtGbsNcIhciRYqvriLroazf CWghwJlmmsmccsophSmviz4nynqsBg4cWApL9Y5WoqcdnyLeKdLqIB4CEIAABCAAgcYSKL0FdmO7 X77S61F+F92bJAWKzyqpSKVslr6UndX0008f+HhN6ksS26R0WcJqUQCXnV2WfpOmeQTke1YLuOpP llbh7xprrGEWXnjhhjVEM1n++te/mtdff93ceeedznqGDRtm5p577nbxo0ePbhcWBshqrWjxDQxp SnNU0u4BsoSNK/Ci+cu6/cEHHwSLdRYx9X/mmWc2OsdWX331oEwt0ialONI4Aj4LbC2cVrT4BsXj yvQ81tr1trNMs5Tq7UvZ8x9zzDHmtNNOK6SZa6+9ttEaN2uttVaw5s2SSy7pXHywkApLUIgGccsg Dz30ULAIb9KzON6+Vn2niPeDfQhAAAIQgAAEmksABXZzeafWluZjUquA+5TIqRXkSDDDDDO0S+1r n+9DtF1BBQT42qLiO5rVjDPO6OxlkaxqmTpddnZOcEQ0ncBZZ51ljjjiiMR6jzrqqIYqsMNKTz31 VK8C++OPP05UYEtp7HLTUeQ1GLbT5+IgydWPLARdeaQMT7tOw3rL8qsBg0022aQma8Dll1/eLLTQ QkYLBc4333xmkUUWMXEF5gsvvFCWrnbadvgWt26EUtdn1R0//j4Fts8/di0HqxF9raUdnT3PzTff XJPyes455zSLLrqoWWCBBYL7RfgbHxj0DWJ2BrZaq0b+wssicvmVNhjRyu8UZeFMOyAAAQhAAAJd lQAK7JId+TQfk5p2nsW6oVHdauYHZFofys5K02FdUuTH9jfffOOqxhlednbOhhPRdAI+10DPPPNM U9ojhaYUm1qIKkmGDBmSFNxOARpN5PPnH02Xddu3YKQU1UmuEjRI6FJgSzER95mdtS0dle7EE090 HqNom2S1v9lmmwUWkjqus846a6Z1I5IWFo6Wy3b9BHyDJsOHD6+/glgJQ4cOjYX8bzePAlsDUnqu 1rKo8f9q/N+WFodFGkvgs88+M3vssUemSrbZZhsj62ot2KvnwSSTTJIpn2YLuaRSqbiiWib89ttv 97ZVfGtxM+cqVOtKaKFll1x88cXmhBNO8M4eauV3Cle/CYcABCAAAQhAoDkEUGA3h3PmWmQ9Igtr l3Xgm2++aTQlsqPEp8DW9O6iRNP7ZTnjm7JcdlZJFuwhH7lE0AdZEVLLh3bZ2RXBhTKKIfCnP/3J WZAW55MLm169ejnTFBUxzzzzOJWjLivOuNuOaFt0v1p//fWjQXVt697sErnCSBKftauU9UW4Z5GS RvdSuSOpdXHhpLbHw6Rc1oKNPpEi/+677w78Y/vSueJ8gwSdQRnl6nczw30K7BdffLHQpshdie+6 iV+/Ood1Lbnc0+hZuOqqq9bdRg1uuQaW6i6cAtoIyO+16103TKTFfGWxW4s7Jd0TfMexM9wzLr/8 8hBVu189u8W4aHnjjTecaxvoeMrd17bbbuustpXfKZydIgICEIAABCAAgaYQcK+e05TqqSSJwLzz zpsUHITJLUZHyuyzz+6sXlP10z5GnJljEdtvv31gYSM/0iuttJLZZZddzMknn2yuv/76qjrKzMqn wH7ppZdiPa5tV4ul+T7QfKWWmZ2v3cQ1l4DvY1Mtuffee5vSIFl+ucRlqew7x19++WVXcTWF+wbw dB9LEh/bt956KylL7jC1SwOBsgDXNHu5+DjkkEOMLOWKdMlxyy23eNumgVe1RYs71io+BTaL7tVK tTqf75x84oknTJGc33nnnerKY3tJA+Y+BXVR70e+aznWRHZrJKCBzzTl6qWXXmouvPDCmpTXapZv TQLFN2IdBJXbLNHgj+9dcvfdd29IU9Ks5vVs8YnvHqN8ZX6n8PWLOAhAAAIQgAAEGk8ABXbjGeeu YbXVVnPm8b2sOjM5IvQh+q9//cvIB+Gzzz5rPvnkEyMXJT7RVG/fyu6vvPKKL3umuDFjxgRtUmIp Z2XlqUVqtJjbjjvuWPVRUmZWSy21lLO/jz32WFU/nAlTIur5YC8zu5RuE91EArPNNpu3tpNOOsk0 w5JNVl8ucblV0mJeLtE1qIWkipIHHnjAWdRcc82VGLfssssmhitQ970i5NFHH20rRlbdsoA+77zz jCwbb7jhhra4ejcefPBBZxGaVSTeffv2dabJEvHcc885kzXjHHRW3okiFl98cW9vinwH+c9//uOs S0qupBkDvmv6xhtvdJaXJyJtMCZPWaRNJqABOt/g+5lnnmn23HPP5MwZQ9Pej1r9niGDDp9stdVW vuia4zQI6hO5FvPNrGjldwpfv4mDAAQgAAEIQKDxBFBgN55x7hp8H2j6eHz++edzl5mUQYqMLbfc MpjqpwW0pJyWKwApW7SCu/wTJskaa6yRFByEFfHh55umLCu+6OKIZWYl60+fpckdd9zh5Jg1Iu0D xldOmdn52k1ccwnI3YzuDy7Rh+p9993nii4k/PHHH3e6DVAFLgXxEkss4aw/nOrsTJAjQrNPHnnk EWeODTfcMDFu6aWXTgxXoBTYw4YNc8ZnjfApljfYYIOsxaSm++CDD5xp9t9//7r9sMpFiSyAXZI2 +OrKR3g1AVnr+6zkr7766uoMNe7J+tVnqelSvq244orOGqWw9CnOnBkjEVq8UQPmSGMJyGDCJ2lW vr68YZzv3qc0rXzPkKGHLNRdIgMFvdM3QuRTe6+99vIWfcUVVzjjW/mdwtkpIiAAAQhAAAIQaAoB FNhNwZyvEt/Ho0qSVUq9L976eJTlZJJIGSNrR5eltU/xKYu+eq0aZannkvhHbdlZyRWKSy655JK6 LFe1OJGs52uVsrOrtV9lyVfvNVqWfqgdBx10kLc5Os/rVRy5KpCV3PHHH++KDu5TLr+9svz1rRmg xaiKsMLz+SFVG1ZZZZXE9suvt+JdctNNN7miMoVrCr3vfrryyitnKidLItcCm8qrRdfqlbvuustb hPx8I8UQcJ2vKl2KKd/CeFlb8NBDD3kHpVxWnnKD43t2aaZWPXL66afXk528GQm4/Jgru/ycTzHF FBlLSk6m+8Gtt96aHPlHqM8tVTRj0gK8YbxcoXSE/Pvf/65ypxdvw0477RQPKnQ/rXw9W30uBVv1 naJQiBQGAQhAAAIQgEBuAiiwcyNrfAYpjl0We6pdiiKf5UWWFt5///1ehdOhhx7qXJht0003dVah F9ZTTz3VGZ8WMXz4cHPOOec4k8W5lJ2V6yNcHZQlfT2WXj6lnhNgJKLs7CJNLfWmSwHpWliw1J1x NE7n8ZxzzumINcGH6gorrGDee+89Z5paIqRc1r1IU5JdcsQRR7iigvDddtvNGa9rMM0PqzPzHxHy l+tbvFCDbr17904sRooRX/t0L5Wf+1rFdy/dYYcdzAQTTFBr0bny6b5ej2g20IEHHugtIqsyylsI kQEBueryyb777uuLTo3Te4LPwlYKzMUWW8xZzgEHHOCM08yyWgd+dD9Age1E27QIKbfrHQA+8cQT jYwxfJJV+exbpFgLkXaEXHXVVd5qN954Y298vZEaRPLNMFT5vhmZrfxOUS878kMAAhCAAAQgUDsB FNi1s2tozsMPP9xbvqZku1x8eDPaSL3U+5Qmyv9///d/zmLkx3TnnXd2xv/97383tfjClrJK7XJZ behlWRaLcSkzq4UXXtj7ki+lzIcffhjvUur+ww8/XPcghiopM7tUCCVPIP+eWT+QS94Voym/xxxz jLeZum7lNkf+lYtQJsqCTooqlecSDR6k3cukqHUNMqjcvffe27z99tuuKrzhcjeg8n2yxRZb+KLN Pvvs44wXU93ra1lsTMo4KXFc4htcc+XxhfsGONSWWkVrNey6667O50JYbkcpksL6O9Pv/PPPb9Zf f31nl2TZWuvgq85lXdc+C1wp0JP8X4cN0iC6a4aY0my33XZGz8g8ooEouU5DmkPAd/zUAt+MjrQW yv2Sb1AxzJ/1nuEagFQ5X375ZVhc03517cgIxSU6/+u1YHeVHQ33PbuUTgtwuqSV3ylcfSIcAhCA AAQgAIHGE0CB3XjGNdUgP4++qe8qdKWVVsqt/Pz888/Nmmuu6V08R77tpp12Wm+7pVTxyaqrrmr0 QZhH+vfv730p33bbbROLKzsrn7W8FFTyL5xHiT1w4ECz9tprJ7LIG1h2dnn70xHp+/Tp46w2rxJF BV177bVGysWkv6233tpk/eh2NqrGCLkJSVM6qOhDDjkkcBkhlw+1uHWQ5Z0Y9OvXz2gask80DTnt Q10+fQ877DBfMUZukV5++WVvmnik3CjIz6hP0aIBLN9iqSpTC1D6rOVuv/32QMkuRW5WkfW/z32R yilaWafj5RL1wbdgnyvfN998E7CRu4k00WACUhwBzXzwyS677GLy+sPWtS3L6zTltwYsfDLhhBOm 3hv0jJSP7TRLXg2cy1JU7nRcg+e+thBXG4FZZpnFm1GD+2nHLqmA2267LXg3ToqLh8nFUhaZfPLJ nclk8d9sSVusNG1Qtaj2brPNNt6iNFvUN3jZqu8U3k4TCQEIQAACEIBAYwnYl/cOFevHrWJ76Pyz Fowd2j5f5daqL7HdVsnjy5Y57rnnnkssP8pLbRgwYEAljZO1eqrYhdYq1oo5tUz70pmpjfYl2VuW 2nbllVdW7EeItzw7vbxi/el5y7JTiitWmeEsp+ysrEW7t39i9a9//cvZP0WIo/0g95YTPTfsAp3e 8sLIMrPbb7/9nP194YUXwi7U/KtrNcos3NbxyCp2Km1iGWFZ1k95ZejQoRVdg1bJVtH57rte7QCS tzyrOM3atMLTWSWvt21hn6O/1oVGxU7pDxhY5Xu7NomLtWKrWCVnRX13HZNomdrWPWHEiBHtyksK +Pbbb4P08TLi++eee27FLo6VVERVmO6lqj+eP77/zjvvVOVz7eieG88b37cWsZXBgwe7imgLF8c0 hv/4xz/a0sc37KwMZ1uefPLJePK2/QsuuMCZT33RNfXuu++2pU/bsAN1mRiHnOxgQVqRFesewtnG O++8MzV/0QnsII+zPeqXHShu6J91v+O8F+m63Hzzzb3tUxt1zWa5Du0sh4r1rZ1a3j//+c/MmHVN hMff9WtdkVRUZvy++cMPP1SsJXmmNkXLznKe3Xvvvc52nXzyyan9a4XnXmonUhLYWTrBPSHKNr5t B1Gc52e8eD1b7YCmk3u8bO3rOGWR4447zluudfVU0b1ez3W7BkzFLlCZud1Z6o+msQOZFTvbxdke 3WfFtlmi98wktmGYna3pbUqrvlN4O0UkBCAAAQhAAAINI6AFrDpUUGD78Vsfpt6Xw/Al0U75rZx5 5pkVKUL0Ai3RB5pdjLEiBZq15s5UjsrIKvpg8L1Ih23TB5+UGx988EGgHNKHsV7wH3nkkcppp52W +hGjcl599dXUZpWZlT6e9WERMnH9WmvNirWuCRR64iSl9bBhwyrWiruiD3FXvqTwrApsgS0ru1b4 kLfTdXMdFx0ra5XkPJ/LrMBWo601bO7+Rs9PXQe6b0jJmqZojeaLbquMQYMGORkmRWT9UFbbpJDQ vfPnn38OipJC4OOPP67YBewyK7zswo5JzXCG6RqP9tG1rfNDx0BKed0j1MbXX389GCRYd911U8vQ +eqTWhXYQ4YMSa1bfbLTzoN7WlIbNEgpDnpmuPrvCtc5kSatpsB29bXIcGt17MQ2cuTITM94sT/4 4IMrGuBQHokUbdaNUkUDA2mD3WF/0s7NeEN1TaruMH/ar+43Sp9l8MlVFgrs+FGofT/tWadjIKOL O+64I1Epq/cjDcDvvvvumc+B6HG16x9karzu5dF8WbY1GNoI0cCer35dh82UtG84tTU+eBRvX6u+ U8T7wT4EIAABCEAAAo0ngAK7DsauDyd9JBUlUlBYf4/eF1bfy2yeuCOPPDJ3s7MqhfK0I57WuhPI 1K6ys7JTTZtyHEN+eRTYZWXXCgps6/M993H1WRmmfdSnfQxmuljqTKRrMjzPOuJXSota5JJLLmlK u/Nce2E/dA2mWbPVy1oDnXbafFhl4m+tCmwVZt3HZOar56cG5aR016/reZqnz2kW3iiw28928ymw dUw1eJznGNSaVgNHofJb9WYVDTQVce5kbbfO1TTBAjuN0O/x1pdzrnNLAw8a5NdfFuOJtGOadcDk 6aefztVO1ZtmeZyNUPtUabP5XnrppfaZGhgiq/O0gWi7jkVqC1r1nSK1YySAAAQgAAEIQKBQAvjA tm+aZRYtZGSn33sXTSyi/fJLaa2hcxe1+OKLmyeeeMK7SFruQiMZrALTaEGnLFJ2VhtttJGxVudZ upI5jf2IM/JjXa+UnV29/Wtkft9iZ656fX6TXXnKFK5r8rrrrmvYde/qq1VUBdeQddviSuINt4MD xlrTedPUG2ndMpgbbrghdzG6BuX72ypVcufNkkHs5K91kkkmyZK8pjR2qr130dpoofI3bJWj5oEH Hgh+s/gfHjBggLEuGKLFVG1rcUGkWAKLLrqosQNGDb3W5a9adUw55ZS5G28tomvyr+6qSNeJdRHk ijYTTTSRM46IfARmmmkmY62gM2fS4oWPPfZY8KfFyNNE6w/YmX/OZPIlbWcqOuPDCK1HY5W04W6m X/l/Llq0toHP77wWOl9iiSWKrtZbnhZj3HPPPb1ptJijHaD1pmnVdwpvp4iEAAQgAAEIQKBwAiiw C0dafIETTDBB8NJai4I5S2uspUiw2JEUKLWIFj+y/oiNtY6pJbszz957722sawtnfFJE2VmtscYa gbIm78dQUl/1oX3PPfeYGWaYISk6d1jZ2eXuUJMySIGixQTziPUHmyd5KdNqoSgpEez07aa0T8pn 6zLA6BqqR9ReLSio66dICa/HM844w/Tq1aumorU4nQYGjj766JryuzLpfvPggw8GC0a60hQRPtVU UxktXFrE/S3aHms5HiyWqWeV7/hbFy+aVRbNynYBBDRgJIWcjkPRogGJ+++/v65zZqmllgruDRtu uGFdzdNgsAZVFlhgAWc5ek4ixRGQ8cSJJ55YXIF/lHTKKacE9yItkmtneTjL1ztUmvTu3dv4FuNO yq/zKM/Cu0llxMOsK5V4UNW+tc6u2m/WTpqRid4TNPCQJq36TpHWL+IhAAEIQAACECiOAArs4lg2 tCQpl4866ihjpwcaWSsVIRtvvLF55ZVXjKzaZEVRj8w333zBB+4xxxxTTzFBXimCZCnYv39/ow+H vFJ2VrJoe/HFF41d3C5v19rS28WwAoWO70O7LXGOjbKzy9GVpia1PpNzWc7aae9NbV+jKpt22mkD i2ZZT8pKrRGiAYJnnnnGWPcfZuqppy6kitVXX91YH9rG+mMupDzr5im4/9WrQFNjunfvbqxbGvPo o48a666g7vbJolt9XW655eouK0sBs802W2D1ePzxx2dJ7k2jQVFZHFof30bPGIksDF2DD7LQ1GAq UjyB2WefPXj/OPvss53889Sq+4WUWrLa79GjR56siWl13kkZaRdDzn0v0oCL3oM0m0wKT7uQa2Id CsQC24mm5ogTTjjBWN/OhdzvpEzV/e7YY49tO69878zXX399pnbrHp/XoMKuX5Kp7KyJNEDnk623 3toX3bC4fv36pc4EzDrzqVXfKRoGl4IhAAEIQAACEKgmUKhDkhoK06I/tkXOPy3SUlZxLQQk33yN Fi3kYhWgNfl+lE9t+bVslGiBRq0Gbz8Kncc16ZiLmxbLCRdOK6p9ZWb1/vvvV9J8HkdZaUGjiy66 qGqFe5dPRGutWDfCjmYnv+zR/ke333rrrbr7J57RMsNtnbu1iBbgtANDiWWGZYe/8h2ZJIceeqg3 vxZPLat8+OGHwfm55pprevsQMnD9yleztaCrFHGM01hpcVktLJj3fqX7v/yfy49ro0QL4Vm3GIHP VxcrV/hOO+0ULESZt20nnXSS89hpzYM8MnTo0IpVKDnLc7V9+eWXr1x11VXBor9J9enZ58p78cUX J2UJwnTvdOXTQmLNFi1k7GpPs8LDRZ/z9F0CRVfPAABAAElEQVS+qq3ldEXXad527r///g19/wj7 oUVFtXi0/MrrfIq+r+ldww4CBwtPyr9x/D1T70eufmlByjSxinln/iz+gFvtuZfGI2u87ndWoZz7 Xqx7t96jXD7w9RxxHU87GBYsOJq1jXYwtbLrrrtmevdW2qJEvupdfVC4nT1QVFU1lWNnDnnbl5dz 2IhWfKcI284vBCAAAQhAAALFE+imIu3LD9KiBOyHV2BF/dRTT5nPPvvMfPXVV2b48OFGvvLkT1I+ 8eQneY455jCyoNKfLByaITq13nnnncCS0CoyzJdffhm0zS5CZ6aYYopgyrD98Ags6jR1V1YcjZQy s/riiy+C42hf1gPrRVkQ6RjOOOOMZpZZZgncs8iKqNn+DcPjUWZ2YRvL9Dtq1Cjz7LPPBtPa5ftR LiV0PcqiVH4/dd4XYXVYpj7H26LzVzM8Pv/88+DepPuTHdwK/uxCgqZv377GKvEDHmIy/fTTB+f7 sssu2/B7Qbyt2tf9Sq5dZIVplV/B/WrEiBHmm2++CY6d7qGy8tQ9dK655jJLL710U4+hfLWqbZqF E95Lda/XNHWx031d93rdS+XyoZG+rpP4+cJ0DmgaubgOHjw4uMeFvmnlAin8k1Wu2l+LL2Rf/cQ1 jkDol1h+/XVehn+yVA7fO2adddbg2rGK5FKdly4qsgzXLI0kkY97uQlCGkdAFvC6P+h+ofuG7hl2 sN/ofqx7g+4XuufpficXdgsuuKCp1QVerb3Qc/21114zVjlu9DybZpppgjbofU3PMz3faplBWGt7 ukK+Vnun6ArHhD5CAAIQgAAEmk0ABXaziVMfBCAAAQhAAAIQgEApCWgRVvnjTZJzzz3XHHzwwUlR hEEAAhCAAAQgAAEIQAACDSRQn+PjBjaMoiEAAQhAAAIQgAAEIBAlID/XsnqVv2pZ4WqmUpEWuFqw 0iWysEUgAAEIQAACEIAABCAAgeYTwAK7+cypEQIQgAAEIAABCECgBgJJymq5n9loo42CRSFrKLIt i9w/yT2F9TncFhbdkCuLRrs7i9bHNgQgAAEIQAACEIAABCDwOwEU2JwJEIAABCAAAQhAAAItQUAK Zq33kSR2UUoj/9u1yrXXXmvsAqjO7PI53717d2c8ERCAAAQgAAEIQAACEIBAYwjwFt4YrpQKAQhA AAIQgAAEIFAwAS3i5xItdFqrjBw50px66qnO7FtuuSXKaycdIiAAAQhAAAIQgAAEINBYAiiwG8uX 0iEAAQhAAAIQgAAECiKw/PLLO0vaY489zIgRI5zxrgi5DFlvvfWMXIS4ZMcdd3RFEQ4BCEAAAhCA AAQgAAEINJgACuwGA6Z4CEAAAhCAAAQgAIFiCKy//vrOgj799FOj+DfeeMOZJh7x2muvBXmef/75 eFTb/sILL2zWXnvttn02IAABCEAAAhCAAAQgAIHmEsAHdnN5UxsEIAABCEAAAhCAQI0E5Od6jjnm cPrBDouVIvuggw4y88wzj5lxxhlNz549g6jRo0ebL774wvz3v/81559/vnnkkUfCLM7ft99+2yyw wALOeCIgAAEIQAACEIAABCAAgcYSQIHdWL6UDgEIQAACEIAABCBQIIE77rjDbL755rlKnG666YL0 rgUgXYVdeOGFZr/99nNFEw4BCEAAAhCAAAQgAAEINIEACuwmQKYKCEAAAhCAAAQgAIHiCOy2227m qquuKq7AhJJ23XVXc/nll7N4YwIbgiAAAQhAAAIQgAAEINBMAvjAbiZt6oIABCAAAQhAAAIQqJuA FMtyEdIoufbaa82VV16J8rpRgCkXAhCAAAQgAAEIQAACOQhggZ0DFkkhAAEIQAACEIAABMpDYODA geb00083DzzwQCGN0oKNN998s5lvvvkKKY9CIAABCEAAAhCAAAQgAIH6CaDArp8hJUAAAhCAAAQg AAEIdCCBV1991Zxxxhnm1ltvzd2KySabzGy//fZmxx13NMsuu6zp1q1b7jLIAAEIQAACEIAABCAA AQg0jgAK7MaxpWQIQAACEIAABCAAgSYSGDJkiHnnnXfM0KFDg7+PPvrIKOyDDz4IWtGvXz8z00wz mZlnntn07dvXzD///Gbdddc1E000URNbSVUQgAAEIAABCEAAAhCAQB4CKLDz0CItBCAAAQhAAAIQ gAAEIAABCEAAAhCAAAQgAAEINI0Aizg2DTUVQQACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAQB4C KLDz0CItBCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEINI0ACuymoaYiCEAAAhCAAAQgAAEIQAAC EIAABCAAAQhAAAIQyEMABXYeWqSFAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIACBphFAgd001FQE AQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACeQigwM5Di7QQgAAEIAABCEAAAhCAAAQgAAEIQAAC EIAABCDQNAIosJuGmoogAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAgDwEU2HlokRYCEIAABCAA AQhAAAIQgAAEIAABCEAAAhCAAASaRgAFdtNQUxEEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQjk IYACOw8t0kIAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgEDTCKDAbhpqKoIABCAAAQhAAAIQgAAE IAABCEAAAhCAAAQgAIE8BFBg56FFWghAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEGgaARTYTUNN RRCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIJCHAArsPLRICwEIQAACEIAABCAAAQhAAAIQgAAE IAABCEAAAk0jgAK7aaipCAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABPIQQIGdhxZpIQABCEAA AhCAAAQgAAEIQAACEIAABCAAAQhAoGkEUGA3DTUVQQACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCA QB4CKLDz0CItBCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEINI0ACuymoaYiCEAAAhCAAAQgAAEI QAACEIAABCAAAQhAAAIQyEMABXYeWqSFAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIACBphFAgd00 1FQEAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACeQigwM5Di7QQgAAEIAABCEAAAhCAAAQgAAEI QAACEIAABCDQNAIosJuGmoogAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAgDwEU2HlokRYCEIAA BCAAAQhAAAIQgAAEIAABCEAAAhCAAASaRgAFdtNQUxEEIAABCEAAAhCAAAQgAAEIQAACEIAABCAA AQjkIYACOw8t0kIAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgEDTCKDAbhpqKoIABCAAAQhAAAIQ gAAEIAABCEAAAhCAAAQgAIE8BFBg56FFWghAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEGgaARTY TUNNRRCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIJCHAArsPLRICwEIQAACEIAABCAAAQhAAAIQ gAAEIAABCEAAAk0jgAK7aaipCAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABPIQQIGdhxZpIQAB CEAAAhCAAAQgAAEIQAACEIAABCAAAQhAoGkEUGA3DTUVQQACEIAABCAAAQhAAAIQgAAEIAABCEAA AhCAQB4CKLDz0CItBCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEINI0ACuymoaYiCEAAAhCAAAQg AAEIQAACEIAABCAAAQhAAAIQyEMABXYeWqSFAAQgAAEIQAACEIAABBIJ7LLLLkZ/CAQgAAEIQAAC EIAABIokgAK7SJqUBQEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAoURQIFdGEoKggAEIAABCEAA AhCAAAQgAAEIQAACEIAABCAAgSIJoMAukiZlQQACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAQGEE UGAXhpKCIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAoEgCKLCLpElZEIAABCAAAQhAAAIQgAAE IAABCEAAAhCAAAQgUBgBFNiFoaQgCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQKJIACuwiaVIW BCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIFEYABXZhKCkIAhCAAAQgAAEIQAACEIAABCAAAQhA AAIQgAAEiiSAArtImpQFAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAAChRFAgV0YSgqCAAQgAAEI QAACEIAABCAAAQhAAAIQgAAEIACBIgmgwC6SJmVBAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIBA YQRQYBeGkoIgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCECgSAIosIukSVkQgAAEIAABCEAAAhCA AAQgAAEIQAACEIAABCBQGAEU2IWhpCAIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhAokkC3ipUi C6QsCEAAAhCAAAQgAAEIQKDrERg0aJDp1q2bmWeeebpe5+kxBCAAAQhAAAIQgEDDCKDAbhhaCoYA BCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAIF6COBCpB565IUABCAAAQhAAAIQgAAEIAABCEAAAhCA AAQgAIGGEUCB3TC0FAwBCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAL1EECBXQ898kIAAhCAAAQg AAEIQAACEIAABCAAAQhAAAIQgEDDCKDAbhhaCoYABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAIF6 CKDAroceeSEAAQhAAAIQgAAEIACBgMAuu+xi9IdAAAIQgAAEIAABCECgSAIosIukSVkQgAAEIAAB CEAAAhCAAAQgAAEIQAACEIAABCBQGAEU2IWhpCAIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhAo kgAK7CJpUhYEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQgURgAFdmEoKQgCEIAABCAAAQhAAAIQ gAAEIAABCEAAAhCAAASKJIACu0ialAUBCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAKFEUCBXRhK CoIABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAIEiCaDALpImZUEAAhCAAAQgAAEIQAACEIAABCAA AQhAAAIQgEBhBFBgF4aSgiAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQKBIAiiwi6RJWRCAAAQg AAEIQAACEIAABCAAAQhAAAIQgAAEIFAYARTYhaGkIAhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAAC ECiSQM8iC6MsCEAAAhCAAAQgAAEIQAACECgXgTG/ji1Xg2gNBJpAoFu3bqZ3L1QeTUBNFRCAAAQa TgAL7IYjpgIIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCohQAK7FqokQcCEIAABCAAAQhAAAIQ gAAEIAABCEAAAhCAAAQaTgAFdsMRUwEEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQjUQqBbxUot GckDAQhAAAIQgAAEIAABCEAgJDBo0CAjn7PzzDNPGMRvSQjgA7skB4JmNJUAPrCbipvKIAABCDSU AArshuKlcAhAAAIQgAAEIAABCEAAAh1LAAV2x/Kn9o4hgAK7Y7hTKwQgAIFGEMCFSCOoUiYEIAAB CEAAAhCAAAQgAAEIQAACEIAABCAAAQjUTQAFdt0IKQACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCA AAQaQQAFdiOoUiYEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQjUTQAFdt0IKQACEIAABCAAAQhA AAIQgAAEIAABCEAAAhCAAAQaQQAFdiOoUiYEIAABCEAAAhCAAAS6GIFddtnF6A+BAAQgAAEIQAAC EIBAkQRQYBdJk7IgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCECgMAIosAtDSUEQgAAEIAABCEAA AhCAAAQgAAEIQAACEIAABCBQJAEU2EXSpCwIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhAojAAK 7MJQUhAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQgUSaBnkYVRFgQgAIE4gUqlEg9iv4UIdOvW rYVaS1MhAAEIQAACEIAABCAAAQhAAAIQ6GwEUGB3tiNKfyBQQgK/jh1XwlbRpCwEJujdK0sy0kAA AhCAAAQgAAEIQAACEIAABCAAgYYQQIHdEKwUCgEIQAACEIAABCAAAQhAoLUJaCbdr2PHmm+//d78 /MsoM2r0GDN23FhTpgl2mi3W2w64TzThBGaySSY2U045hendi8/c1j7zaD0EIAABCECgmgBP9moe 7EEAAhCAAAQgAAEIQAACEOjyBMaN+81898MP5osvvzY//vizGfPrr1aZPc789ttvpWPTs2cPq7Tu ZSa0Suwpv//RzDjdNGbyySY1uEIr3aGiQRCAAAQgAIGaCKDArgkbmSAAgaIJyMJHHxmhz+zAc3aZ zHuK7nCHlNfNMv6jYv3+4Z6cj7sOORhUCgEIQAACECgtgbHW6nrkdz+YYZ99YUZ8813b+1lZGyxl u/5+GTXa/PjTz+bXMb+a2Wbpaya1Ftk9enQva7NpFwQgAAEIQAACGQmgwM4IimQQgEBjCIQK61B5 rf3u3bubnj16mO5W2xooVyPK1sa0opOXGvCrmPGW7fjx463l1PhAeR0qrsPBg05Oge5BAAIQgAAE IJCBwG/2XeHHn34xQz+V8npkhhzlSjLWWol/Pvwr+z7Zzcwx28xm4okmxBK7XIeI1kAAAhCAAARy E0CBnRsZGSAAgSIIRBXXKk+KVVnI9OzR01rPjDHfjPzOjBkz1sgCCAVrfcTFr4cdEJhggt5mIvsR N8VkkwQfcmPH/hZYZIeDB6olVGrXVyO5IQABCEAAAhBoVQJjrPXy199+15LK65C5Bu0/+Xy4meoP f9i9rHsRBAIQgAAEIACB1iWAArt1jx0th0BLEwgVpaEiu1fPnuanX34xHw351Ppb/NH8PGqUVWD/ ahcKGocCu84j3abA7t078A05+aSTmJlm7GNmnL6PZWuNse1/0eMRbtdZLdkhAAEIQAACEGhBAj// /EtgSNCCTa9qst5xRnzzrfWFPYlBgV2Fhh0IQAACEIBAyxFAgd1yh4wGQ6D1CYQKU1ldy11IpTLe vDf4YzP0k8+tEntU0EG5EJHVcE+r2MaDSH3HPOQn3j/9/LP53g4QfDXiWzNsmuFmvn5zmikmn/R3 tyK2Gimvw+NTX63khgAEIAABCECgFQmMtgYEUmJ3BvnJ9kMuRRAIQAACEIAABFqbAArs1j5+tB4C LUcgVI6Gymv9vj3oQ/PxsM8C5akssbXQoKxmJEqvaaBYBf/Oo5b/Q35i2KObHRSwblrk3/KL4SMC H5eLLjSvmXbqqawS+zeU17UAJg8EIAABCECgExHQ+4BmwHUG0aKO42x/EAhAAAIQgAAEWpsACuzW Pn60HgItRyBq4Svl9H8HDQ6U17K2DpXU48dXK6zD8JbrbEkaHOVXMfIZYoIFMrtbf5C/WMuk194c ZJZYZAEz5RSTBb7Iw0GGkjSfZkAAAhCAQIsQGDBgQIu0lGb6CMiGIDQk8KVrhbhx434fnG+FttJG CEAAAhCAAATcBLq7o4iBAAQgUCwBKUbDv169egYuQz6ylteh8lpxkqjCtdgWUFq3wCHL75bt4i0X LXIr8tZ/3w+srcQ+PEbQggAEIAABCEAAAq1OIHy/bPV+0H4IQAACEIBAVyaAArsrH336DoEmEwiV o/J7/dPPo8ywz4ZbbTV+l5t8GILqdCz0J/ciWtjom+++D1yKKEwS/gY7/AcBCEAAAhCAAAQgAAEI QAACEIAABDqIAArsDgJPtRDoigRCC5iePXuYTz8fbr4d+Z31x9wDv8sdeDJIUa3j0sMOKgz++NPA D3YY1oHNomoIQAACEIAABCAAAQhAAAIQgAAEIBAQQIHNiQABCDSNgBSlsr4ePXqMGfndj21Wvlj7 Nu0QeCsaNWqU+Wbk98ExCnxle1MTCQEIQAACEIAABCAAAQhAAAIQgAAEGk8ABXbjGVMDBCDwBwEp qrt372ZGj/nV/PDjT4Hv69AqG0gdR0DHRX+/jR9vvrWuRGSNXan87kqk41pFzRCAAAQg0GoEBg0a ZN57771WazbthQAEIAABCEAAAhAoOYGeJW8fzYMABDoZAS0iOHbcuECJ3d0qTa3mtJP1sDW7Eyiw f/vNjBo1Ojgk3ay1fOCgvDW7Q6shAAEIQKADCJxxxhlBrQMGDOiA2qkSAhCAAAQgAAEIQKCzEsAC u7MeWfoFgZISCBSl434zv/46ps2FSEmb2qWaJUt4/Y0e/evvx6WbFNgIBCAAAQhAAAIQgAAEIAAB CEAAAhDoWAJYYHcsf2qHQJcjUJFi1FpdBwpTWV8Hlr5dDkPpOqyBBR0KHZ/f3YeU1zJ++PDhZuWV V66L4TzzzGPuueeeusooMvOdd95pjjrqqLYiH3vsMTPTTDO17XfWjc8//9wMHjzYrLjiiqXr4kor rWS+/PLLoF1bbbWVOfnkk2tq47nnnmsuu+yytrw33HCDWWKJJdr2O9PG0Ucfbe64446gSzPPPLN5 9NFHO1P36AsEIAABCEAAAhCAAAQg0EEEUGB3EHiqhUBXJdDtD9/KUpjKTQV2vuU5EzSeIBcv3Upu ff3aa6+Z999/vy5wUmCXSZ544omqPk0zzTRlal7hbRk7dqzp37+/Oeigg4yUnmVTYGuQ5Kmnnmrr 94QTTti2nXfjwQcfrDq20047bd4iWia9lNfhtdm3b9+WaTcNhQAEIAABCEAAAhCAAATKTQAFdrmP D62DQOcjEDXsxQK7pMc3epDK18SXX3657kYts8wydZdRZAHPPfdcW3FLLrmkqUdh2lZQSTc+/PBD s/HGG5v//ve/QQvV37KJBkmisvjii0d3M2//Zv3KP/LII23pJ5tsMjP77LO37Xemje+//75Nea1+ Lbvssp2pe/QFAhCAAAQgAAEIQAACEOhAAiiwOxA+VUMAAhCAQH4CL7zwQlWmU045xUw55ZRVYWk7 a621VlqSpsWPGjXKvPTSS231Lb/88m3bnXFDVrqh8lr9W3TRRUvXzfggyWKLLVZTG6Wsj8oqq6wS 3e1U24MGDarqTxkHJqoayA4EIAABCEAAAhCAAAQg0DIEUGC3zKGioRCAAAQgIN/pAwcObAMhi1a5 oOjevXXXJH7rrbfa+qONWq19qwop8c7zzz/f1rqyWiRHB0nky3m66aZra3OejVdffbUq+dJLL121 35l2dN7Kp3kondlVSthHfiEAAQhAAAIQgAAEIACB5hBAgd0cztQCAQhAAAIFEBgyZIj58ccf20pa brnlWlp5rY7ElZy1Wvu2QSn5xjPPPNPWwtVWW61tuywb8UGSFVZYoeamRS3rVUhnHpzo2bOnmXHG GWtmRUYIQAACEIAABCAAAQhAAAIuAiiwXWQIhwAEIACB0hGIK3sbZdEq38WyJv3ss89Mnz59Ar/F PXr0qJnHF198YYYOHWqmmmoqM+uss5qJJpqorayota8CsywwKSX+xx9/bMaMGWP69etnpphiirby at346aefzHvvvRdYG88yyyzOYsaNG2fUH7GZdNJJzWyzzWZkSZ1FPv30U/PVV1+1Jc1z/Irs8+jR o43ce8h9iyyso4rXjz76qGqQJE8b2zr2x0bUt7mCGuEu5csvvzQa2JlpppmCvmiB3FpE5/wnn3wS nPeyONd52rt371qKyp1nxIgRZtiwYcFg1Nxzz535fMpdERkgAAEIQAACEIAABCAAgZYk0LpzrlsS N42GAAQgAIF6CMR9Ey+xxBL1FNcu79NPP20222wzI2tSKfC0EJ0UatrX9sMPP9wujytACtczzzzT TD755KZv375B/nnnnddMPPHE5sgjjzS//PJLkPXZZ59tK0IWyS5F+ciRI80555xjpFxWmQsvvLCR n2H5/1bY/vvvb7777ru2spI2xo4da/785z+bBRZYIPiTEleL7x1yyCGB0lA81W+libJWvptvvtks tdRSplevXm1sFlpooaAtao/qj7qQiNYvpqozvrDfMccc09aWKIcwbxF9DsvSr9yXrLfeesEAgtqu /oTH5oknngiSxgdJarWa1uBC1F2KFOXTTz99UEc9/+lY/OMf/zAbbbRRUN4MM8wQcNVx00DGqquu apJYuurUObD33nsH5/gcc8xh5INdgyJyAXLUUUcZDWxITj311LZjdeihh1YVpwGN8JzS72233VYV L6ZhvM4t9UGW7uE5JYW5zj3NPtC5JB/1cZ/aVQWyAwEIQAACEIAABCAAAQh0KQJYYHepw01nIQAB CLQ2gbi1clEWrVI2b7/99ubee+91ApIycu211za77757oECUItolr7zySqBIVLlJIsX2448/bm69 9Vbz/vvvtyVxWfvef//9ZoMNNmhLF9+QZfNFF10UlHfTTTcZl2uOd99917z55ptt2WV1q7Rxpa3S yLJa8sEHH5h11lnHyDLZJeqn6tdf//79A4VomFZWznfeeWe42+43XNBx6qmnroorqs8qVFbjUrBf eumlVXWEOzq2UvzeeOON5vXXXw+Dg18pXGuRsF9h3npckYRlyNJ6u+22q1KMh3H61XGQIl5KaCmZ pXSeYIIJokmqtnW8xCVJVNYZZ5xhHnjgAfPggw+a++67r23xzfi5qPMn2l9Z5kdFluhhvBT5X3/9 tdl1112DsqPpwu1HHnkkGFyQElsDDAgEIAABCEAAAhCAAAQg0LUJYIHd4ON/9dVXB9PBNSU8/Hvt tdcaXGu24mUp99RTTyUmlhVi2F79Ri3xEjN0kkAfE01vjjK55557WqrXUiLdfffdLdVmGguBKAEp IUMrWYXLalPKsHpF1/0qq6zSTnn9pz/9yWy55ZZmxRVXrKriiiuuMH/729+qwqI7jz32WGBNGlde zznnnFWLAco/clxhLYvquEghHFcYymWHFM+bb755FQO551h99dWdltBRRbX47bjjju2U16p/r732 ClynSOEtxWtcea2+iMv8888fb67ZZ599qizVde9ME/VHvEMpss9yF7LVVlslKq/j7Zdy+JJLLgmb EfRPFsG1iAYxoiJr73pECmQp06NW3SpPx0L9k0V+VGStf/rpp0eDqrZldZ+kvNY5qHMjFA1m6DqI 1huf+RDva9yPe9QXuHiKhRTjoai+aJ0K1/Vz4oknhkn4hQAEIAABCEAAAhCAAAS6MAEU2A08+Jr6 fNBBBwXWdbKwC//efvvtBtaaXrSm7p5//vmBv8zoB2Q0pxbZCturX00l7syShYmU+FEmmrbfKqLj vOCCCwbWeK3SZtoJgTiBuEsBWZnWK+PHjw8sr6OKXSkCdQ+UP2hZSA8cODDwl7zMMsu0VSfL1Lfe eqttP9wYPny42WSTTcLd4HfnnXcOfEYPHjzYyF+xlPChsi7qD1qJ4xblSrvvvvtWlXf88ccH5T36 6KPmX//6V+Bb+8ILL6xKc/jhh1fthzsvvvhiuBn4og4Vi+uuu27gzkH9lVL7gAMOMLLO3mKLLap8 Vq+//vpGSm31RVzeeecdI//FUnhH5aqrrmrb1cCf3EWovKivbCmLFa6/H374oW0xzqL7LCvkqAW4 2iALX9331X65yIi2PzrwEHd50tapDBsh2zBpXOkbhmf51XkiXtG27bDDDsGx17G45ZZbzBtvvBFY SUcZSwGs4xUXDa6fd955VcHXXXddwELniM7TO+64o+14RRfeVKb4eRpVbie5SokOlssSWzMGJHIh o76pPl078Xri+0Em/oMABCAAAQhAAAIQgAAEuhwBXIg08JDrozn6sRlWpQ/mjhL5utx4443bpvIm WfupbdFp+voYnn322TuqyQ2vNyuTuDJikUUWaXjb6q1AVtdyixAqb+QzFYFAqxKIz17ReS3laB6R ZahcbIQiRZ4UpqFISS0L6ugii4qba665gusoutif/BBHFbVKd+CBB1bd9w8++GBz9tlntylnlWbl lVcOXDLErVTj91r5yJabhaioz3EFeffu3c1+++0XLKoYWtzKFcbJJ58cWOdG8ycpBE855RRz9NFH t7VR1rYSKUVDtw/al4W0wiaZZBLttokGOGXte8MNN7T1PckHs1yRRJ+JSRbJRfdZ1sPqXygaONDx lT/mUNQfWV1LiRreK8O4uIV8GJ7lVzOZolKrKxKVIUVvlJ2s3C+44IJ2/tI1wKBjJD/foWiw5Zpr rgl3g4GZ+HklJnKhEpVNN93UTDPNNMH5Gg3XearrIRQNAkX7GneV8u2337az4FcZTz75ZJUiXItP LrfccsE7SjhbKHr+hfXxCwEIQAACEIAABCAAAQh0PQJYYDfomOtDXR/0SdKRFtiyqIp+EMatqML2 RpUcmlrfmSUrE1m3haJp57VOKw/LaMav2hxVyNS6GFkz2kodEEgjELUeDtNGZ0Vk2ZayNxQpBOVG IRQpN3W9xJXXYbwWy9Pii6HELbB135QFcyiy5I4rr8M43Xvl9iEq8XutFORR1x1yWxJXXkfzR9um cFmQR0XK4aj/a8XJ0vrYY49tU15H08sHtRSNoWhhvrjyOoyTP/Bo+5Puj/EBiCSL5KL7fNhhh4VN DH4vv/zyKuV1NDLJLUx8kCGa3retcyv6rJXyP4mJr4wwTgPK0YESnTfyXe1a7FPW9FG3N/HB17/+ 9a9h0cGvBnTiyuswwUorrRS4qQn39SsFtZTNoegcjSrX4wMT8eOufHLD43r/iJ5jRbgICtvJLwQg AAEIQAACEIAABCDQugT+9yXfun0oZcvj07ejU92jitBmNz46zTdu7Re2RVN7o9Pa67FAC8ss828W Jmq/LBrlK9fnJ7ts/Yz7JUWBXbYjRHvyEEiy6s2TX2mjbkBk5RlVvGnROympfSJXPKFIMSjr01Cu v/76cDP4lQV0VGFeFWl34gq86L1W5UZ9Met+rfb5RG6Nogo/KfSjEldeq0yfj+Frr702cO0hVxvf f/99Ox/L0bK1HZ1d1K9fv3i0iStS4xbJRff5k08+CVyFhA3RgMKGG24Y7rb7nXfeeduFRY93u0hP QJx1VKHsyZYYFfdTrQGHqAI5KVO0PinS5T9e8sUXX1QNssh/ttzE+CRaltJFryHtxxXU8YGJ+HNo m222MVtvvbWyJkp0zY355psvMQ2B5SUwYMAAoz8EAhCAAAQgAAEIQAACRRLAhUiRNP8oS1Nxw+mv ClpzzTWDv9CqWQpi+fus1RqrniaHbVAZWgAsSeIfo51d6ZmFiThJOdRKfq/V5qgrGO1HF0nTPgKB ViEg6+Gon2pZS8ctSbP0RS4WQpGCNipyRxId0IrGhdtS5Eblm2++CRY7HDNmTOBCI4xLU5Yq3aST ThomD36jLp3UjtBPsCLl8iKuFK3K/MfO1FNP3ZZv6NChVUniisRzzz3XTDXVVFVpknZ69uwZtFU+ iqUA1fNLf+q7/F9rkUY996LW4lKMxiU6AKFZLPH+F91n+QePStqAgvoZFR2PCSaYIBqUeTt6ripT 3Co5a0HiHFX8r7322qkDCSp7lllmqapCA6+zzjqrkZ/rqMhqP97vaLy2o4Mi2o+/E0Tbp/j4wET8 mtLaIC5Rf6MDL/FBHlc+wiEAAQhAAAIQgAAEIACBzk2g+mutc/e1Kb2TlZN8nkZFFm7RD3vF6QMt bqUUzdOI7ayW1VHrJ7Uj/gEpf5ZqvywV9ZHsmsbs64OUHlKuSDkgS70JJ5zQlzxzXKhMkdXj3HPP XTX9PamQrEyS8qaF/fzzz+bjjz82+pUyp5aFMLW4mfoUKrKkgMhTTlQ5r4GUrMdKi61J4fHZZ58F yjn5QM+aN41LR8eLaWi9GP6626QF5n6PjeZzpyemUQTirpekyIsvbpinbinEtZBfVHzuOaLpotuh uwPdN6PW3H/5y1/azrNo+uh2/LkQ9av/0EMPRZMGivW8CwpG3X+osPiAVpb+yk+x/CfffvvtVf2r alzCTtwC+9dff60aHJBrirgU3ef4IsVRv9DxurWve21UojOnouFZtuNK21pdkcgdWVTk6zyLaLAh KuFgQfz5roUh00QDFVGJvxPEBybig/PR55AGnqIDNdFytR2foRavK56efQhAAAIQgAAEIAABCECg axDAhUjBx1nWTVErOVn7aVGiOeaYo6qmQYMGVe0n7ciCS1Z34V/0IzApvRaqCtNGFR2bbbZZEB4N U34tChWmj36ARpUcsryafvrpzZAhQwLFvNJrUSeVpT7Jcuuss84ysj5MEy2WKOW+Pm7Dj1hZKcrf rCwfzz//fCPFqU+iTGTlpantUizefPPNgYWbytXAgJQFqmettdYySazzMjnppJPaWMUXqIq297vv vjNnnnlmoNiXwkDTz+UWoE+fPkF75I9VFmZp8tRTTwW+bqWIF39ZvOlP5UjpqsUY49aUYZk6HuFx jSrIpKwLwy+88MIwedWvFuISGx1XKct1nDUQoH1tP/zww1XpW2FH50dUxE9hOtekVBttz91Ro0e3 +1P4r7+ODdIlKa/j5UbrYLt4AnGL1qi7jVpq0+BMESLfz5JwkCksM26FGoZHf6P3Jt1rdf8KRffc eiVansqKPkPkBiJtMEwW7vJrLQV2VDmfpV1xJWXUvYjyx+MVVnSfBw8erGIDkTI6zdI4er9Upril 8e8lZft/4MCBVQlrdUUStUZWgbJczyLxAZ/Q0j7KRMcgVGz7yoz6Utc51bdv37bkegZHz6v4e0Z8 kFiuQ3xudeLPNRTYbajZgAAEIAABCEAAAhCAQJcmgAV2gYdfismjjjqqqsRTTz012J9tttmqwt99 992q/aSd5557rmoRqPADNCmtwu6555629FIMS0aNGlW1iF8QGPkvXGRK084l8kEaVWZL+d6/f3+v peMRRxwRTCF3KUWl6NPU7RNOOCFSc/WmPtI1rViLhGkQIK7wD1NHmUjh8/XXX5tdd93VxC3twvRS 2mrqthRF4Ud3XiYqK8o2SfGiNLJQ3GWXXZyKHimAtLCn+vfoo48Gym3li4qstbfccktnf8K09957 r9HfzjvvbK688soq62iFh8c1TB/+huHxRerUtu233z4oM0wb/5VFoaxed999d6OF1kLFXTxdWfZD pXNoZT1+vLWmtv90jk84QW8z1eRTmikmn8wuSjeR6dWrV6DUDtuuPFJg//LLKPPDjz/bv5+sgnuM 6WYHFBTX3f6F5Yb1hHn5bQyB6MCaaqhHuaj88o8cFfnlnd3ONMgjUZdCmrEQlYUWWii6m7gdXQQy bpEcVaZKafh///d/iWX4AqPKRFnRRsvceOONfVmDe7bu21FRO9ZYY43AFZFm3+ieqj9x22GHHaru H+EzKMwfH4BIUkxG21dvn3VdRstLqi9sW/irQdao1HqORWfNqDw9M2qdZRQd5FBZGljMIlFXYJoB FN6vohbdaf7eVY84RhcmXXnllauqj7/LxAeWou1QxjQr+Oh1rhkEcUv+qsrZgQAEIAABCEAAAhCA AAS6DAEU2AUe6rPPPrtq8UMpF0MrvBlnnLGqprg1WlXkHztxv5I+/8WjrQVpNH049Vm+SdNEH4lh 2fq4jVra6cM1+vGqtFIuR63MVf5FF11k9t5773bWYbJw3W233dr53ZRyQh+6UibKUi2sU5ZcstCS ojrJZUW0j7KwlnI6avmociXRRShV9onWjcvll18exOVlEve9G1UKBQXa/+RLd6eddgp3235lLadj E1WkqG1KK4WwFKehaABkgw02MLK+jor6pI94Kd7jx0eWkVIk/e1vf2vLErWWawuMbUQVM1K8aWGz uIJJ54TOX01Fj7bpiiuuMBrwOP3002Ollmc3qlQOrfp79+5lpp1mKjPbzH3NpFZp3aN7D8u/pz3P uluFdPd2jde5Oc5aaY8bZ/9+G2d+/Oln89kXX5kRX39rxljLbCmElNeY3y26QwVRu4IIKIRAdGBN BcYVpHkrGTlyZFWWPfbYw6y66qpVYXl2vvzyy6rkmjnhkxdffLHq3hUfGIu6s9AMldNOO81XXGpc XJGo2Sku0cBg3L/4pZdeasQo6TyX66wnnniirTgt+te7d++2fW2ov1HRbJC4FNnn+EwXzV5Jk5tu uqkqSfhcrArMsBNnnfTMyFBMkCT6fNPzN82KXJnkJiT6zNGgQygavAyft/GBzDBN9FfP3Ggb4grq uMV03FVK3GVJmus0zQIKRQPoPmvtMB2/5SKgQRfdJ3TfQiAAAQhAAAIQgAAEIFAUgfZam6JK7mLl yNdx3Fotui9lbHTqb/yjLwlXVGmoBRd9H65xhXioDNEHhJR5UuLp4zcU+b1UuP70oR9+JMY/vMP0 mm4ua2a5yJCPSi1kJsvnqMQVoIqTkjO6aJTaIGWvFgKTVfN9990X+FmOlqUP5quvvjpadNt2lIms icMPa7lDkWJYSiQpXKNTmpU5up+XSVxZH7ING6U2xZXXxx9/fKAk0HHRlG2VET3+YhXlorKUJ9o/ KU/+85//BP3RR73OGSl4LrvssrDq4FfW0DqOoYiB9jfddNMwKDj24fHWb2iNKCWtLK+jx06KQfGS IlyDFxpgkGWizoFQzjjjDBO1Hg3Dy/Cr/nXv3s2Mt79SrE0y8UTmT3POZlZdfimzxJ/nN32sEnvi iSY0va3yWiIFtRTSY+xU+LY/uy/ltT7ClW4Sq/SZvs80ZrGF5zfLL7OYmXO2/2fvTMCkqs70//W+ rzRbA91NoGXTRIgmkEXhMc4o+EhQkjxkjPPIjBNcMkSJSyZ5ZuafmcngOErII4ZEB5OMyyRDXDKC kzgGjEYYo+KoLAIC3UA30E0v9Ebv//Oe4hSnLlXVVdW113v0crez/m511bnv/e73TZJsZcUNFyNI yId2mSJDAGKz7UoBn9HRvgHgdJ9hvkv8jeDf/u3f9NsoeLMGD4/sZN5iMceMSGj2netvf/vbHoec wp55YwSZAnkohf7DJzjeAsLbMOZtC9OI8zfHn4W4LSKiPFw0ff3rX/cqXuP8li1b3KIo9iFgO5Nd Jx6wOgVu5A/nmJ2uMfAg0V9C/zAOk/Cb6+0hqjnvb+1k7fzN8FfWeQ4uOkzCZwrfaSMlPGywE97q Mcn+HXJanJs89tr5IMN++Il89kNl7DtdpdgW1Xhryvl3hzIm4bfL/ju0f3NMHq7jnwDmB/H8gDv+ CbKHJEACJEACJEACJEAC3ghQwPZGJYRj3/nOdzxKwV0GbtbsZFsM4iats7PTPu2xjUCJtgXVSDdy zhtm502m03IXlsvekvNmFHkgNkC8hhWXEbph/Xz33Xd7VOEMGgUfnLbbEIjXEMi/9rWvuetBBTgO 62j7Jv+73/2uR93YcTLBMZSF+ApByVjYQUyE5Zb9irxTzEHZQJnY4i7K2RZmeDAA1yd2ghUfLKJt AQVi0ebNm+1sHjf+eADywx/+0OM8XJJcddVVHqIRgl7CChIW0yZB1PBmVW6L9hBjvCU8KLAtJ/E5 g2U4+Nlp2rRpF7iigXAebwkiMq5/f/+AZKqHRlOrJ8tnLr9U5syargSzTCUyu9zkDA4OaYHbiM4Q vNPUYNyL2kfCeQjhg0rohwsSCP4Qsz8xZ4bM/+QlMrlygn44hOMUsTWyiPzjDOxm3jAZTWO2WIp6 nJaizrrxfYa3SeBSCd9PTz/9tEcWuGmwk78HPHgw9bvf/c7O7n5bxxzEmxUm4eGc8/vVnDPre+65 R/cN4tFf//Vf64eN5hzWtpAIgdl++8POh237QRr2r732Wqy8JrwZYlxlmQz2dySOwTWS/R3stOI1 5cI5ZojPtgW183vctGnWTvdfI/3mmnLe1jZrnHfy8FbG1zGn+7GRRGd8f+NBi0n4jbTdfjiZOB9+ m3JYP//88+IMrGkHGkUe+3cGv+H4jTIJ34v2mxPwp+4vOa+R86GOv7I8RwIkQAIkQAIkQAIkQAIk kNwEKGCH4friBs0WM3DD6BR30cysWbM8WoOA6iu9++67HqdGupFzvp7tbMtpWe2rPueNN4Qi+Je2 xVjTMSNmm32nZdXq1avNKb2Gb2YIod4S6kKgRJMg2MDK207OMeAc3FkYa2I7L7YLCgrch5wPE3DC WZ8vJk62tgAAsdq+6b799tsFvnS9JVwTWxSxr/HWrVs9ArhB0Hdastl1Ol0dOK1R4d8XDE3yJhhB +LY/p3BV8txzz+mgmqacvYa/1Pvuu899yJ9A584UpQ0jRLvE637t2/qTytr60otnKt+zOdpSWknb qjcuK2nkQ8Laua2PnTunM1n/4Bza6lMCeanyn33ZpXNk7iWztKUmLCNNXVYRboaBgPMBna8HcME0 heCk9vcCHiA5/WKb+hDw8cYbbzS7eo03JuxUU1Nj7+qHWBDwnAkue2ApbSdYxeJ3w05OFx/+XIis W7dOW0mb8nhg5XwIZQuNznOmnFk7raNtK2CTB2tYNYOL88Gn87vLKZI6RVBTZ7jHbLswgBBrW4Gb NrEGP5sPjvn6PcC5kZLz4YT9mzFSWed5+zcD577//e87s7j38YaO/eAWJ/DAxX5Y4RzXl7/8ZeXr v9tdh9lAwF77LR4cxzhsv+94MGG/oeQMcBzoQ2LTpvPvfDTCv6mTaxIgARIgARIgARIgARIggeQg QAF7lNcRAoXTAheB+mCh7EzOm1h/r4U7rQFHupGzLeYgOts3rOiHU2AwvrntPsJftfMm/he/+MUF woopA4tEO9njO3z4sIeFIYL/2VZgdjmz7RTd4XrDTs6bWwjF8JftK9kMnXWjTCBMkM9m63TlAnco dvrWt75l716wjdexYR0H62qIJiZB+Mbr0/g8wV0CAiX6S7Y7BeRzPjxwivO2dbup94UXXvB47X/N mjUyUlAvW5gCP28Cnak/WmsIykY4hkX8pAnj5PK5l8iEseXKErtfC876YYvKBxtrk9es/fUTeezF COWoD65H0F71lEpZcPknpKSoMC54+BtPop5zPlgb6fswkHHiusKi2k5f/OIXBW9DmITrDTdHEBHt vznEN3C6ycDfhi2IQzCFNbQt/uI7Hw+T7LrQljeLcvjDtxME9vXr1+vPszkOq2yI4faDKJyzv1uw 73yg5RQxkcdOzt8HfDc4XVfgewrip7cAurYlNep1jhe/Nd5SOMeM+q+//nqPZlasWOFxffH3iwcR Tn4oFOpnDG/D2O5j8GAQb7nA6j7QxX7jAKK+ie2AfsH1FK6v87sXbaDP9oNL/O7CRZSdbr75ZrHf FoBlPD73eHgJARy/Hfi7QFlncj74sPuJvM43v5y/QyMxhfW4SRiz8y0Jc45rEiABEiABEiABEiAB EiCB1CPgcgKbeuMO24jhI9gWQiHi3nLLLV7rtwVeZLBfqXYWsK1+YZnnfI3Yzg9LZVsgcN5kIq/9 Gi+s/bxZVDut5CBOTJo0yW7KY9t582oH5YLwbSdY3Nk3p/Y5s20LPTgGIcC+4XWWdz44MPVgDb/e NhNvVtqBMIFIY7tysS2ZcQ6uVUyCW4+pU6eaXa9rf6/iowBENVi4oW5YfeLaYizwPQ5hAr7D0W9b VMf1RDk72eI9jnuzeHSK77BWdDK268S20yr+9OnTbtctzrxR2z83dAjKUyaNl08oq+t0xaNf7Rvx 2Ra50S+zbwRpfcx1Av968EQdJr/hjH2I2BCR8LkdU1Yq45SP7DMq0CNT+Am8+uqrHpV6eyDlkSHA HQiz+Dswf+N4mwJ/w/g7HTNmjA48aH+PoFr8nZuAsHYzubm58uCDDwpEUpPgmx+W0yiDNnz9fXl7 wITvAfi7h+9pk/CdB4tafA8h0KI38RhCpu2uCmWDFRLxhgd+d4wQ+7Of/UwH1l2+fLl+2wDfzTjm K5m/E3PeaeELgfThhx/WY8AYIaAihXPMqA8PGnBNzDWE6y5cXzwwwG8b+JkxIr9JI/3mmnze1vYb OTiP7+2rr77aW1afx/Cg9JVXXtHn8TAaDz1tt1EQ3J988kkddBTfQbi+uO52wm8n/LQ7rwVcfEAA ty218Ttm/5bZ9djb9u8fjjs/V04B254bIb/zwQiOmYTvVMRbMGmkB94mH9ckQAIkQAIkQAIkQAIk QAKpQYAC9iiuM27KnW4yYNkGy1ZvCaKknZwWzPY5W6D05b/Y5HfeRDrFEFi72cLJFVdcYYp6rJ31 INCjv2QLwLDoKikpcWeH1aKdYImIJZjkFNlt63BYZznHadftFNedAnaoTOw2na+JO1/1tvsTyDZ8 m0IYg3W2EdQCKWc/ODD57euNa+O00MZn1ylYGBHJ1BHI2nbTEkj+cOcxwjIsKadMmqDE6xlavIao k5aWrpbzYjXaNvmxDZ/WcCkCX7kQebBA+FahTWUY/q6VoIJ67TLYRkJecxz+s/cfPCyHjhz18O2u M/KfURPAQxvbqtTbGyahNoLvGFieLlmyxCN4nDdhGG3A/zzEP+cbLqZ9PPTDQ03UaRIEUqeLKdRh W3/bD+pMOazxJsa+ffs8LKohxhpB1s4L62+Iyt6EP/uBFsRZiLj+0vjx47VoivGYhDa9ua+AWyHU acctwPeX/b1kf2+a+swDXOd3U7jGjHYQ+Pjxxx/X19cWqu3fEuRDEGHEWDDXbSRfzSjjKznfFPKV z99x528JLNMRmPMb3/iGuxiEcqdYbk7CrQs+C76+n2GZjsCcYG1zMeWxxrwDD0cfeeQR92Hn59T5 ZkRtba07LzbsOYKvB+emAN7asvsSDjdBpm6uSYAESIAESIAESIAESIAEEp8AXYiM4hpChLCFFVQF oQJWat4Wp1sIp8hqugLLW7vekW7k7JtE1OEUa52W1d7EBJRzWks5/Vkij0kQ9mwB1ymK+/PvbeoY aW2CMiIfLOdsJnAdot1C+KjEKSKEysQWftCUXY/TxQlu0ENNEMxw8w9rwWDEa7S3YMECj2ZxbWxx 2pt7AnzGwpGcvrfDUWegdUBAdlla98v4ijEqsOJFlnitlGsI0ecEZ6yN4GyOZWVlqsCO2cr/a4+0 tZ+Rk02npe5Yoxw7flKaW9qlR/n3zVHns7OzdJdMeSNe42C6Esk/OnxM9uw/pFpzCds6M/8JGwHn 35m3z/NoGoO1MvzR33nnnT6rQZt4KwbWwv4+8/hOwgMoXwFOYfUKn8FOVz22ax67E/iswVIZwqqv 722Ix//wD/8gcE/i62EnRHCTIM6i3pHSl770Jdm2bZtHIES7DOoBk7Vr13q8KYM8cIdkJ3xvPvHE E17dUTmtxcM1ZtM+XL3g+jpFYZzHW1EQaCFy19XVmSJe87pPjrCxd+/eEXKMfNrbtcbnE79HtuW0 syZYaeOaIWCwL/HalMFvKLgg+Kdxh4OHILBah5sS+MB2ujlDMGI72XMLWJnjYaCd7PP+5hMo4wxO OZKbG7sdbpMACZBAMhLAfB5z1Na2M9J0ukXPU5tOt+r9LnV84JyRRSKPHWPEWFpa2+VUs2uMzWqM be0deux4u5KJBEiABEiABAwBWmAbEkGuEYjLtjgLsrjODqESlrBOQcRpVTXSjZwtVkLMcAZKdNZn i7B2v20hHJZWeIXeV3JaANo33AjsZYvNEH/MDbKv+rwdr6qqch92WocvXrzYfc7bhm0ZBiZOy7BA mThdudTU1Libg/9ZO4Xq1gB+UZ3jQZ/xUADCFjhAWMAr79h+6qmn5K677nI37Xyt2ykEeHsA4gxW B3/i9tjcJKIkAgAAQABJREFUlfvZsIN5+ckWkVNGTMbkvUgF65w1Y5pkKPFwUFteu6yp0bDJZ7ax n6lElj7l9qP+WIO6IWhVLlo6ZUCVg4/ffhWcEQJajhKtIW7n5+VKRXmZTFauSbIyM5RF9pC7TrR3 8PBR2b3/oH6YgnJ2exEZeApWCuELXCOZ8F0HC1e4+8CbMfj7wE0V3OpA5BxJDLT7hs8B3sy57bbb BGIm6sPfLf4O4b4BqUZ9jwQzJrwdgQUPBiHo4/sV/oHRP3w3oE1/CVbhoSSI1BAhYR0LMRMWsrCs xnedbYUOlysjjQfCKERT9B/fnWAODt7iRaCvox2zPV68hbJjxw7dLkRbuEKCqy3bV7fzoaddPpht iMeRSnDR8fzzz2tf1XgogQeRuPawqMfvvr/fbG99Apd/+Zd/8XZKz03suQV8Yufl5XnkHYkZ3F8F muDre6TPUKB1MR8JkAAJJCoB8z3Yq96e7ezsUQYVEKzbpavnrI69kqXeLMLctLSkSM1PS6WosEAb Wvgz6olHFpivwwVfZ2e3mou3yWk1zp7ePj33ylYGJgX5eToge3lZiY4xk5OTHY/DYJ9IgARIgASi TIACdojAEfjJThB8A7HAhXBqXp1GeQgSTr+QuMG2ky/BGXkgtGy3fF9C7HGKGbYIizL2q93YR+rs 7NSWga498foaujmHtfPG1fZ9CX/NdsKNKYIXjiY5LaFHEvVff/11d3MQKpwTu0CYoALblQvEHDs5 rZghBvhLuJmHKApfuXaCH147wdIO7lacDzZMHvt645jTv7VTnHe+9o0yTnc2cI0Av7eJkvAZH1aT X7jvuGhatZrIF0pfX7+HkIyx6HxK+xweHtICN9yC1B9vlIOHjkp3T48WstOUEA1LbuTV+ZUtdc/Z Xn2zcLq1TU6capYjR4/L9KlVMmniON0m9NT9Hx2RvQcOqzJwVULxOlE+O/76CZcisNT1Zq3rr5y3 c/hbx3e78/vdW95Aj+FBnPNhXKBlQ80HNxzhahcCKB7K+bI499bHcLWNumH5fs0113hrJqGO4e0k +w2lQDuP3xU8UJk4caKOq4EAoL4SHqzayVtQR/s8t0mABEiABEZHAOI1XODByOJQ3TFpPNms57Z2 rRC2sbSqNwcbGk8qA4sJMrlygha1MReN9+Qa47B0dnXJMdX/hsZTOmaN3e+zSsjGclpZZR9X56dU jpdpag6OOX8ijNEeC7dJgARIgATCS4ACdgg8IRBu2rTJoyT8XsMSbqSEV5VtVyKwonIKHLa1MXw9 +7tR/c53vuPRpDfhxRZzYQ0NYcWZ8Fq7nbxZ7drnne5G7FeLy8vL7awer2Z7nLB2ELzpmWeeEYwX loVwwWJbk9kW1eDs9JtqVaVfX4fLEZNCZeJ05eKsB1bSdrItEu3j2IYfX4wLCeVMEDNYUtrsYbUJ S1BfCZaLto91WL47hW7ntXF+vlC3k5/Ny1fbCCSGzz7GAWtwWFTGLKlJPqw3JqlJbfWUSm05jYcU RkhGv8w2Jss4d1ZN+P/vg/1ysvk0FG19LFsFSHPa9qrpsaSpSXI66lBW1/CVfaajU955f4+aTLfJ zOk1su/AEeVupEHXYdqJxKQafR+p3kDyxOw6sWESIIG4IYDAkLZVNQJOO38/0FkIKP/v//0/j37D pQwTCZAACZBA5Aj0KkMMuLM7XHdcCbi9+rvYX2u9/QNqLqreBlUT2WlTp+i4D/7yx8O5QeUS5GjD STl+4pQynurS8Wb89QtifX3DCcnITJeqyZXqbUhKF/548RwJkAAJJDsB/goEeYUhFn3zm9/0KPX3 f//3AYnXKOR0M2H7JjWV2n4jvYmPJh8C9cFXpZ1sS2gc71JPuG2Lb6e7CVPWabXrz+obZfA6tkmw 8LVvgiGQQ4g2bkTQT38iG9yo/Nmf/Zk7iBoE3hUrVpjq9QTOdm/itIR2Zzy34RyL01o7VCbOembO nOnR9OnTpz1Ed/vkj370I/cuXsM3vmrtYIvIgOBa/pLzdW+nqI6y9rWBf1lv7g+MmG7agoX71772 NbN7wRpWe3bQOfg7jaWADUvqnJwsuehjNTI06BJ5nUIyPnNYMjLSlQDdJW//31617nAFbVSCNhLE a3+fTVVcC8jw7Yp8dUcbBL75zp7tUyL3ecF8JJFZNxbCP2ZM/opGqm1/bfIcCZBA4hHA744tYCPm wt/93d95DATuYvBdb/+O4rs+kAf0HhVxhwRIgARIICACcIfXogwkYG3covxd441CzDkDSXB/16zK FhTkK0vs8YEUiUkePBhtbmmTo8dPSLty3denhGnM5QNJ4HG4vkHKS0uluKhQz+sDKcc8JEACJEAC yUfApeIk37giNiL4n7TdSkCovfvuuwNuzyl62mK1qcT2L+10fWHy4ObSm0WUU3h21u90N2Hqc7rU 8PeaOnxc21a+cNHhTAgmZRIEdAQh85Z6lYUBbo5tC+D77rvPwy8q3KxA9DVpJOtwp3sTpwuNQJk4 63GydTLy5WcWIjWCrJkEVzPG57XTahsTOl8JdSBwqJ2cDzgwkbVFcds3uV1u+vTpHoLED3/4Q+2O xs5jtmGJfuONN5pdvXa60PE4GeEdTOox5a1Qlv5lygfg4NCg29raCL46j8oH4bm7p1f+uGu3Fq9h uWHesDQ3ByMJwHY+XZ9yL6KMtLXbEZwbqfxocJj6EXAyUy1mbbbxOiXymD6Opi2WJQESSG4C1113 nccA8fAdPsjh5gsPT+FTHa6w7ADNeGDsKyipR2XcIQESIAESCJoA3vCDuxDEVEFcll7lOiPYOV1n V7cWh/uURXa8JcSOwRgPHKrXC0RsbV2u5q7BJIjYp5R1el+/7/ukYOpjXhIgARIggcQkQAE7iOsG 4fZb3/qWR4nvf//72iWEx0E/O3CLAdHbJKdIiuP2+d/85jdy5MgRk116lN/en/70pwJLa1v0NeWc lrW2GI48vgTSP/zhD+42YF3rSzhHpvfff9+dFxtOq28c++pXv4qVO0Gktm+KcQKuM+CP9D//8z/d +SDufuMb33DvY8N2qYJ9pyCNY3ayBVywDJWJXQ+sz5yuXOBv3HYjAuEdlsp22rZtmxYH7GP/+I// 6Obr9AV7zz33SEtLi51dBzn53ve+59WPeHV1tUde52cCDwi8JYiutkU18iBomv1ZwwT6xRdf1P6A 7c8RrmUoQTm99SPYY5juasFY9Q2vS8JqBfvoqxGSzT4+wwjEt+v9vdKh3kSA+Ouy9nD5CDT5R+qD yeeSzV3CNcrYbY5UR6jn0UZpcaEsuOwTMn/eJTL/k671ArX+tNovLy3RwSdNH0Nth+VIgASSnwB+ b5y/r3g4DKvs//qv/xL7ex40li5dKlu3bpWSkpLkh8MRkgAJkECUCGBuB0H2mHKlAfH6uFq3tXfo II2hdAEicY+6R+1RgR7jKXWr/jScPKXF+ePK33X7mQ49Lw+1j7BO749DkT7U8bAcCZAACZBA8AQo YAfB7NFHH5VDhw65S0Bs/fM//3P3fqAbtiUv6oMobacFCxbYuzJ16lS56qqr9AJXHfBbiQTx1H6t 98orr/Qohx2457ATREsEcRw/frzAmhypubnZY1ze3FLYddivFuO4NwEbryrbIjZukjEGiL7oP8YI 6+HtVgBKjAU30rAIs5Nt7Y3jTqtjOy8mhfCnbVKoTPCqm+225IorrjBVutd4GPHwww+79zFG+AL/ +te/LhCzYWUNDrb1OKyoly1b5i6DMcMvuUkQEGpqarRVP3yQrl69Wl9j52veJr9z7bzeTz75pEyb Nk0v9957r0d2BI+0A0/iuuKzhn7DnQjeFoAlvS2KY/8nP/mJRz3R3ElT1xfXprysWIrU65IQtJGM gIvrj8UcQ7DGpuYW7TMPvqxNPp0hyH/gG9tOo6nLrsffNsaCIHplJcXnliKPNSK1I080+uKvnzxH AiSQGATWr18vv/rVrzx+d5w9x+8SHppu3rxZEHiTiQRIgARIIDwEYFiBAIxHlEu6w/XHVaDw0zpw +Ghrh29piNjxkPrV26Cnz7kLqT/aKCdVMHQEZRxtQvB1iPVMJEACJEACqUuAPrADvPbw54zXbe30 0EMPhRQwA1ZQsKw26eDBg1r4NPsQOe1AfTjutF6Gb2O4rLCFVW+uNby5kDA+sU0gv3fffdc0rdfe BGk7g9PdiNOvt8n7yCOPSENDg4dIDUtv29rb5IVFLyzLndbSOG8LyXhoUFhYaIpdsIb/TlswDpVJ oG5LIMZDdLfdh/gSeGFd/d3vftejzxAef/aznwlcepiE/jtdheAcxGO0d8MNN5is8tFHH8kXvvAF 9z7EajzYsBmYhy6lynecncARrl2WLFniIVK/9NJLdjb39l/91V/pfjndnrgzRGEDvOAmpXLCePW3 l+GeyBoBF2sIurC+hiXKERVo0eW/+rzIHYVuhq0JMx5YmkO4N/tmDYtysx22RlkRCZBA0hLA9wV+ Q7BASDl69Ki2vG5vb9cxHPAbfNFFF7nfEkpaEBwYCZAACUSRAOZwff39OiZLgwpg2Hiy2W1wEY5u YD4I4ThWyRiPwD0IfFw3KH/ep1vbw9onuEgx7cRqnGyXBEiABEggtgRogR0g/x//+MceoiDcbMD9 RSgJFtB2amxstHe1mA3XE7Z1rMkAlxj//M//LBCRJ06c6A6UiPPOIIM4BmvvJ554wsPVBY4jQQRH glhrp5FcdBgBHGUgPMNC1FsqKyvT4i4CRdmW4nZeHP+P//gPefXVV72OF3ltn9Ww4PaX8DDATqEy MaKvqctbPTgHcfQXv/iFPP30014ZIw+ssBEk0RmAEeeQIDpDiL722mtdBxz/QrSHJfWvf/1rbcVu nz5xQkUft1JOTo789re/FZRxJtvy35zDZwAPMO68805z6II1LMTxecPfgB2s84KMUTgA22rYQSOI C0RqiDFYTMLEFgsCN+4/VKd8CZ49d97YapucF64jPSkOtX4zRl9rjMRmcOHIeIQESIAELiSA368a 9cYPfGAjpgZ+q/DmjT8XYhfWwiMk4EkAc04sTCRAAi53cwPKOrqzu0e7DPlg7wFpONEUdiFWz3/V m4axSGhbuzFRhiN1yuJ6z4eH5ITyVx1uQV2P0f3uZSxGyjZJgARIgARiTUC9ka9+dZjikgD8VUO8 hSiLJ/dTlXsHiJChWMDCTQlEUgiecH2Bm1YIzNFKsJqF72xYe505c0aL1bDyMlbg0eqH3U64meAa 1dfX62vW2tqqraoR6BG8A01w1/Hhhx9qy3UI2xCY/Vmc+6oXlnWwRkd/IDrDV/aECRP8Cp2dnZ3a hzeuEcojoBeuUUFBga9mAjqOrxgTWAbb8EWNVyZf2/GW5ObmBjyJR1kwLikukssvvViNK9dtlWw6 gvMQXzBpfn3nLuno7NKW2ua8rzXqhgiMdaSSrl9Vfl5ud7Vk2vbWLsYzrqJcPqX8XZt89hr+vRHR PTs722vfTV5vdXs71q+sg8aPq5Ar5n9SB9kBy5zsLG9ZeYwESIAESIAESCCBCPQqv8uBJri32Lv/ vNvEQMvFa755H58lE9T8JtoJ8+nGE81KvD4hLcp1SKRSQX6eTK2aJFWTJ0aqCZ/19ivLaLgM2XdA ucVUFtgRnErLpz95iYwp83yj1GfHzp3A/Bsu95hIgARIgAQSnwC/zeP4GkKUgmDtzXI22G7DjyVc lziDBgZbT6j5YaUdrrGE2gdnuXAzgdiHBwNYQk2wSPdlrR5MnbCsg1sS2zXJSOUhlMP/+Ug+0Eeq J1LnMQHFK5IFeblKBM9wC7ZGpMUa8nCGug4n1ES6Vz0AwjUx5/31y4jXWIc7ufrlqhU+vJVS7tGE aRtitTPhGBY99nNrMx6scQ43R1jsdlAPxh6J8Tj7yH0SIAESIAESIAESIAFPAm3KYOdI3XFB8EEE bUy2NKjmoAjMCEOKpuZWZTzSH1HxOtn4cTwkQAIkQALBE6CAHTwzliABEogBAei+EGxzcrK12xoI tlgg1CIZkRfuQ1rVzQKC2eSoh0CBJlhtz6qdKtOnVql2XJbYoxGAh4fPCc+qj++8t0cFsTnt9e0J M4a83By34G5E7mE1XhxHHtMXe52rzhWpBw+watc9Vvl0WbXuOQsrmPPlAuXAfCRAAiRAAiRAAiRA AsETGFbzx15lhXxM+YA+dbpFOru6VeyWweArivMSeMMRfrybT7dKl3KPEm53IXE+fHaPBEiABEgg RgQoYMcIPJslARIIjsDwsMvFR67y840AjrBmMWIuaoJYq/5VNthpbotknHcd99+WyQcxHC56hoZc NxtpaaGHCUC7ELELsnOUCH3e3YmzP/AbWFSQr92EFBUWCCxanOOChbU5Zq8/PnuGXDpnptsjIOrG eQjwL73ymg54afL7J8CzJEACJEACJEACJEACoRLo7e1T1tbtclL5f4YhBQIa6qlpqBXGWTnMMRFU HAYZTUq4blMuUc6qMTvntXHWbXaHBEiABEggiQhQwE6ii8mhkEAyE0hLc1lcQ7w2rkGM9TXGbcRb RHnHkh6geG2XRR0utx3GAvtCtx6BM3YJyaL6jb4oXd3rJB+nzE0BfMU7BWy0BxHajM9ea/chVofM OQjYZts6zU0SIAESIAESiCiBffv26d8sxNFgIoFUIABRFxbJzafbpLmlVbvVMG/yJcv4Md8809Gp hOs25S7EZVmO+SoTCZAACZAACUSTAAXsaNJmWyRAAqMgoGyrzwm5Rpw1a1SKc1hwI9GvXtd07UPI VQrxCAl5kUwd9v4IRX2eNn2D9Q22oWCjXte2ZzG7XbPtmcPVNxwbqW+u8ufzOevhPgmQAAmQAAlE isADDzygq37iiSci1QTrJYGYEzBzObira2vvkFNK1D3d0q7jr8S8c2HsAIw64JIO1tYYI3xdY57N lPwEuru75eTJk9Le3q7eeu0TxEoqLS2VcePGaVeOyU+AIyQBEohHAhSw4/GqsE8kQAJeCLisoiEE +0q4oYA/6GzlBgTbgYjXvuricRIgARIgARIgARIgARKwCWB+CRG3q6tHWSSf1r6gO9V2MiWMsb9/ QDqVf2tYXDecOKWF7GQaYzKM5dVXX5X9+/e7h4I3U2+66SYVLyjHfSyYDVjav/zyy9LY2Kiuv+/A o3l5eVJTUyOf+9zn3IY1wbTDvCRAAiQQKgEK2KGSYzkSIIGoEoAYDetiuAeB32hvCZYiuSrIY5Zy MzKkJt/Ij0n4iOlcHpfo7XK/MWIZK4NpB2uTsI3+YG3Oq86Y0x5rtOtyXTLkLmNnMC5TTD1mrfur MppWsY9zxoWIXQe3SYAESIAESIAESIAEQiNg5oi9KgYLrK4PHq5TAQzP6nlbaDXGZynMR/uUeI0A jccaTmq/3vHZU/bq0KFDHvc5EKDfeOMNWbRoUdBwTpw4IS+99JJf4dpU2tPTI3v37pUDBw7IFVdc IdOnTzenuCYBEiCBiBKggB1RvKycBEggXATgAxvi7Fn1uiZ8RRsRF2sk19olWOfmZktmRobHpM5f P4ZVHUb8RT2edfor6Tpnyto5zTGIyVhQJ9pxitjQtNPT05TwnqMsJrL1aWQzCUK8HbDS7hsszVHW JNSFsurew9XeOUHbnOeaBEiABEiABEiABEggeAIwQejo7JYj9cfluLJITtYEy/KDh+t1oEa6C4nf q3zkyBGvYvPhw4eDFrD/+Mc/yq5du4IeLO7Hfve732mXIjU1NUGXZwESIAESCJYABexgiTE/CZBA TAgYQbivTwU6VBbYcBWCZI6b9YDyfz2mvEzwehvEblgvG9HXV8fTzgm9sFzoVX7ehpXgjDRSObSJ oJIZ58RyO7/pT6+yGMeCc2jHVfP5nqB/iOK++8ODbtcn5izqKCrMl+opky4YJ84dqjuqIt136D5g 3yRsGutvc4xrEiABEiABEiABEiCB4AnA1/WJU8pdyIkmZXWdXO5CQANzSFiWH284ISebVJBG5f+Y 4nXwn5Nolnj77be9NgdRGZbRtbW1Xs87D3Z1dXkVr4uLi2XKlCna73VBQYG0trZKS0uL1NfXXyCc w+3ILbfcQt/YTrjcJwESCDsBCthhR8oKSYAEIkEALkQylNjb1tEhZ5XInJOdJYNqwm1EY9d6SBAV vaykWFkzZwlecTPn/fUJE/eszEw5ql6VxMQ9kIR6EdRkzszpMmXSBA8radSH8yYP/MhhW4vMam0n WFD3qlc1YdHjPD+kBPUJ48ZKTdVktyBt6sa6Qd1IHTnacM5y+7yAjfphnY02mUiABEiABEiABEiA BIInAMOGJuVK42TTaWlVgQx7enpdc7Xgq4rbEnjLr6XtjPZz3X5GzbGVUYWej8Ztj9kxfC4hJpuU n58vCLpoEsTtQAVs+NG2Ewxrrr/+eh2s0T5eY1lY79ixQ95//333aXxeXnvttaAtv90VcIMESIAE AiRAATtAUMxGAiQQWwLQYtPT0qWzq1tN0nqkpKjQPcE+L9S6RGJYRU8aP1bOnOn0kufCccC1B6Te XjVpP6uirQeSYOGcrVx+uNx+eIrH6A/OwzK7W/lH7O45q8V3045dPyZ96Sq/t4Aruo3sTD0GM0Z7 na2s0PNycyVbifnOmw3sYzH57Ta5TQIkQAIkQAIkQAIk4J0A5k8dnV1yUgUwPN3SJh0dXdKvLFuT KQ0ODepxQaBvVmNsV3NmzDuZ4p8AXH7Y8/4ZM2ZoQRnW10hnzpxRQUa7BJbTI6WmpiaPLPCfPW7c OI9jzp0FCxZoi+xjx465T9XV1bm3uUECJEACkSKQHqmKWS8JkAAJhJsAJmuwDGhpbVNuRAbPWzWf awhiLRa4EampmiTFRQVuy2V/fYF4beqG6DzSAoFcNSTjK8plTGmJbs8WilGX+l/3Fa+dwmJHuzLx 0glTzlXGJTp7bvt2ZQLZfHh4SPfds4xLUDd1e2mWh0iABEiABEiABEiABCwCiFkCC+TGk836Dbf6 Y406iGGyidcwrDipXKLgLb6jx08od3RnKF5bn4N439y/f79HFz/+8Y9LZWWlx7HXX3/dY9/XDt4S NQn3DdOmTTO7ftdXXXWVx3m8lcpEAiRAApEmQAE70oRZPwmQQNgIwIIZwRmPNZ7Uvvkw0cIC8RYJ a7OfqVyC1H6s2t22znMun/ugtYFyIyXTDnxww+q5evIkLUybdlEe22YfIjuswAcHEXRypNq9nzf1 +VqbNr2X5lESIAESIAESIAESIIGRCEDIgwuNBhWgEUEMjym3cngz74LgJSNVFKfnMY+EX+s25Qrl uJpHf3TkmBbqIdgzJQ6B5uZmHePH9BhvcGL51Kc+ZQ7ptW0d7XHCzw4+I729gb2JijZz1VugSDDS wX0XRWw/cHmKBEggLAToQiQsGFkJCZBANAhoDVgpwT09fXJK+aqeXDleW4xg4oRJlxGv0Re8Blmp 3IhMn1olHx48rHxmZ+t7EJMv2P6aclij7uoJlTKuoky/UmraxdoI4fBt3aPckeC1TEzqUE7ZUgfV rGnT1Gvqttcmj6v+oKpnZhIgARIgARIgARJIaQKY07n8QLdr8brpdNu5OVtyYMH8EAuClHd0dqsA 4Me0UA9jDKbEI/C///u/Hp2ePHmy3i8vL9eCMgLYI8GIBn6qL7nkEr3v659sdX9kyiDPc889J1/6 0pf026i+ypjjN998s9nkmgRIgASiQoACdlQwsxESIIFwEcAkHOLwIWU5UjlhrFu0tkVdtIV8mJrP rJ2qJ+116jVJBGo0+XDebI/UNzsvrFfGjx0jsy76mA4YCUnargd5dX5J1/4ET7e1q3Yz1DGI2yO1 dOF5Ux/WSPbatX3eAv3C0rE5cvvtt+tJdFlZmWBCjfWYMWP0GvtYSktLtcVGbHrIVkmABEiABEiA BFKVgJlLDam5FWKV1B1rUC41mtV88bw7hWRgg3FCoEfsGLgKqVOLGXsyjC8Vx9DY2Ogx7E9/+tPu fbj/2L17t3v/vffeG1HArqqqEtslCfxnb9q0SaZOnSqXXnqpVFRUuOvjBgmQAAnEmgAF7FhfAbZP AiQQFAEjFnd0dapXH5tkyqSJ4vTfhjxYMGnH+uOzZ2ix9HD9cR0wERbRJmEib+o0x8zanIOFNyxV 4ApkbMUY+cScGZKlAijiGMqafFibbQjdsHJRPVHVhSZeo10E1XnjzXfd9aJ+V33D0qVuSOyxmH7H co2gMW1tbboLJ06c8NkVcIOIbQRuI2wb0dvsewtu6bNSniABEiABEiABEiCBAAhgPnVU+biGsNul fEJjzphsyeXPu0m7DOnq6qF4neAXGOK0/TlFkMbCwkL3qOBGxBawMSdvaWnRc213JsfG5z73OTl0 6JCK53M+SCn+NnAMC+ICYb4OoXv27NkBBYZ0NMFdEiABEggbgfMqTtiqZEUkQAIkEFkCED8RqPGj I0eVoFymxOQsGVJisnElgtaRx+yrTZl7yUwpzM/TAWsQWd4EasQ5rQl76TLKY6IIgRwuSKqnTJYZ 0z+mtrO09TUswU0ywjXWKHdSuThpVcEmMzLOuzcxeQNdYwwIHNSirLi9JdcYzwvo3vJE+xgm0489 9piOTt7a2qonzmaNSTS2sbS3t7u3/fUxLy9PT7ydQre9X1xc7PMhhL+6eY4ESIAESIAESCC1CECo a2vvkMPKyKCjq1tbXWPulkwJc1e42juu/HnD53Vf/wDF6yS4wHAJYqeZM2fau/p+CGKzMSTByR07 dsiSJUs88tk7MIS5/vrr5fnnn/cQx00euCI5ffq0Xnbt2qUNZ/BWJcTs2tpak41rEiABEogKAQrY UcHMRkiABMJJADcamUoYRtT0/R/VycUzXRMoW0Q2NyMQebHdrybvF02vkXHK/Uf98UZpPNGkfAF2 uYVu5DMJr5TCYfaAsrguUKL3xHEVUjV5oipbriZ3rtcx08/Va8qYdsz6wEdHtMgNoTzUZMZj981Z l8njPB7LfYjYWIxfPm99wc0VJthOcdsWubHd09Mjx48f14u3enDMWIcYUdt2V2JbdONBBxMJkAAJ kAAJkEDqEcC8o1MJ1idOnZam0y3SqfxBD6pjyZQwJ8QYEYASxg+wusYbgUyJT6C7u1sFhj/jHgju DebNm+feNxuf+MQn5NVXXzW70tDQoO+D/N1LwE0I/Flv2bJFmpqa3GW9beAB0MmTJ/Xy2muvyYIF C2TWrFnesvIYCZAACYSdAAXssCNlhSRAApEmYCZh6ekZUne0UcpKSnRAR/P6G84bYdes0ScE6Sku KpDZF02TKuV6BC44WlSQxW4VbLFbCaXaJYiyni4uyJcM5be6vLRE5S9UInauivCdrcujbm/1ox0s cC2yb/9hfeNw3gL8vDgeDBszTn9lAsnjr3yszoGNcRMCn32+EgLLGFHb1xpCuLEO8VUPjkNUN20a sdvsG6G7qKjIXxU8RwIkQAIk4IfAjBkul11+svAUCUSdAIJqN55sllPNLdoiGfvJlDD/PHu2T44r 4bqpRb391tqu56zJZVeeTFcs+LE4gzfCWMPbPQC+g19//XV1T+N6cIHPxltvvSWXX36530YRzHHZ smXS0dEhb775pjYcsYM7eiuM+y6I2Pv27dNlveXhMRIgARIIJwEK2OGkybpIgASiRgATMrjwgEXN 3v0fKXEyTwnZxW4fbt5EZhyDSI0EYbq0uEgHZIQFDuqB1TVcVmcocVXNCnXwReRFGYjfKO+tXvQF ltnZ2Znasucj+L4+lxflmUInkJubK5WVlXrxVQv4Q8Q2Arcvq274AsRy9OhRX1Xp1y+NmO0Ut43o jfOjsaz32ThPkAAJkECCE7j//vsTfATsfjISaD7dpueH7Wc6RL9ll2SDhFu9FuWarallUFnpdurp bJINMeWHc+TIEQ8Gn/zkJz327Z2JEyfKsWPH3If27t07ooBtMsOQ46qrrtK7EKhR9vBhZZij3ors 6+sz2TzWsNr+9a9/rV2ReJzgDgmQAAmEmQAF7DADZXUkQALRIWCEZFjydqvgO2+9u1sunztHi9jw 9ack6AvEZvTMlINlAmwTsA/BOtNy9QFBFAk3BCYZa2rsmzrMGvmzsjKUO4wz8v6e/dpnNgROHEce psgSAGOIylj8pd7eXrfIbcRu5xpC+KlTp/Tir64SZfXvS+jGcVjGwH83EwmQAAmQAAmQQGwJwGVI Mqc+FasFVtdMyUmgrq7OI2A9Rvnb3/7W52DNfYzJAEtquP0YP368ORTQGv6xL7nkEr2gAObR8IN9 4MAB7eLPrgSB27FMmDDBPsxtEiABEggrAQrYYcXJykiABKJJwAjIEIu7lTuQt97dI5/8xCwpKy7R /qvRF5PHbJv+meNmkmfW5rxZm3xm3+Qzx7EP38pnOjrl/3Z/qAMCZasJHyx8kIcpfgjk5OQIrFKw +Eq4nvAxaKy4zdoI3WYfQSixOC1i7HrRntOK2yl6QwjHwxEmEiABEiABEiABEiABEnASePvtt52H tJHMBQf9HEAwxy9+8Yt+cox8CvPa+fPn62X37t3yhz/8waMQ2oAbEiYSIAESiBQBCtiRIst6SYAE okLACMlGxH7z7Q9k9oxpMmXSeO3WwwjOpjPYN8KyWZtzvtamDb3Gi5n4X9WDlKXE6hOnmmTvh4ek VUV6h5hN8doXyfg/jmsMURlLTU2Nzw73K2snI2YbcduszXGsGxtVwFC1+EpoDxHjjXsSp+Bt9nHT wEQCJEACJEACJEACJJA6BPDGKOK8jDbBzQfqsl3gPf/889oYA65CYExxyy23BNzMnDlztMX1Rx99 5C4D/9lMJEACJBBJAhSwI0mXdZMACUSFgBGYMfk6q15ve/eDD6W17YzMqK2RbCUoQ2w2i+mQLWSb Y97Wdj5smwT/24ODw3LgUJ3sP1SvX+2DeG3nN3m5Tj4CuNbjxo3Ti7/RebPmtgVubJvFXz1wR2LE bKcVt9kvLi52P5zxVxfPkQAJkAAJkAAJkAAJxD8BBGC07z8w/5w1a1ZAHX/vvffc+VDHzp075bOf /az7GOafMMhAgrj94YcfCoJABprgh9sWsE1dgZZnPhIgARIIlgAF7GCJMT8JkEBcEjAitvE9fbj+ mIo2f1pm1k6VcWPLJScrW/d7QE3QELDR5MdBs+1cm4HqAI9qBwJ5Rka69CtLhdPK3/W+/YeluaXt 3PEMnR11MJGAIQBRGUt1dbU5dMEali/erLfNMbM+fvy4jgp/QQXnDuCzb8Rsp0W3vQ+fhkwkQAIk EAkCsOjD7+DSpUsjUT3rJAESIIGUIrB//36P8U6bNk278PA46GMH80bbehu+q20BG8YRtugMtyDB CNgIjG4nzi9tGtwmARKIBAHexUaCKuskARKICQFbgNYuRc4FdywvLZGp1ZOVkFggJYWFkpmZoSwN hmRQCdmwSDACtbFwwBp1YUlXixHFO7u65UxnpxxrPCkNjU26LARt0y4GjW0mEgiGACb8gVhzd6rP nrHWhqhthG0cM9vNzc2CxV9ChHkjdGONgJP2PsTuQvV3wkQCJEACwRJ44YUXdBEK2MGSY34SIAES 8CSAuV1PT4/HwU996lMe+/52YCFtB3vs6+sTBIQ0RhWICYM3BU3C/LGhoUEqKyvNIb9rBHS0U35+ vr3LbRIgARIIOwEK2GFHygpJgARiScCIyVp8VhbTsJqGb+rmXe9LUVGhjK8ol6LCAikoyNPrvNwc 7cfa7RxEbUCDHhgYlJ6zvdKjXJJ0dHRJR2eXsrpul9MtrVqktq0MjOAdy3Gz7eQnAFEZy5QpU3wO Fq+AtrW1uQVtI3SbY0borq+vFyy+El5RNaK2N9clOIcFD3eYSIAESIAESIAESIAEwksALj/sBAOE 3Nxc+5Df7ZqaGmW0k6nuaQbc+f74xz+6BezPfe5zAgtvY8CDTFu2bJHLL79cLr30UncZ5wYMf158 8UXtA9s+9/GPf9ze5TYJkAAJhJ0ABeywI2WFJEACsSZgW0FjUgaRDRO4HmWRfeBwvWSq/VwVFC83 N1v7yDYW1jiOSRnE7CFlod2n/ML1qUkfyvUqqwUEbMzOVq5IVJ3IY4Rru71Yj53tpzYBfJZhUY3F X8Jrn7Y1t7HiNgI39hHw59SpU/6q0cEufQndOF5RURHUzZbfxniSBEiABEiABEiABFKEAKyh7TRz 5kx7N6BtWFvbfqoxz+tVxjkIDo45I1yG7Nu3z10X7m3efPNNgXU1XOCNHTtWqqqq9P3PsWPH9Nzw 5MmTHqI4CkNYD8b9iLtBbpAACZBAEAQoYAcBi1lJgAQSj4CxyEbPYY0N4RqTs96+fm1dPXxOsMZ5 OP/QltjqPMqlqfxYZ6h1npqYoZxZ9HmYajORQAISKCjAWwgFMnnyZJ+9x8McWG47xW1b5Mb2kSNH 9OKrItzU2D64vVl0l5SU6L81X3XwOAmQAAmQAAmQAAmkCoE9e/a4XRxizLjv8GcV7YvLggULPARs 5HvjjTdk0aJFusgVV1yh53onTpzwqAK+seE/G4stcHtkOreD+yu6jfJGhsdIgATCTYACdriJsj4S IIG4I4BJn0kQ5bCfnq4WUe4PlPWBOa30aS1iGyVbi9nnCppy2LXrM/VyTQLJRgA3JEZsRtAgX+ns 2bMeLkuM4G2vcWPktCSy60NbpaWl7vaMVbdZm37oNyDsgtwmARIgARIgARIggSQj8N5773mMCG/W hXL/Ab/UcD3S0dHhru/w4cNuARsHr7/+enn55ZcFx4NNMFK45ppr9Bt5wZZlfhIgARIIlgAF7GCJ MT8JkEBCE/A2+YNwDctqnINoPTzk2rYH6q2cfZ7bJJCqBHDzgoA//oL+4O+rvb39AmtuW+SGNffB gwf9YsSNmBGzbXEb2yYYJW7U+PfqFyNPkgAJkAAJkAAJxDEBW3BGN0OxvjbDu/jii2XHjh1mV7v/ gBuQ8ePHu49dffXV2hhh+/bteg3DHX8Jc7/a2lqBhTcTCZAACUSLAAXsaJFmOyRAAnFNwBa87O24 7jQ7RwIJQgB/U7CwxjJ16lSfve5TvubxuqpT2Lb3GxsbBX4YfSX4dHSK20b0xtqcswOx+qqLx0mA BEiABEiABEgg2gRuvfXWsDV5ySWXCJaREuZIN9xwg86GGCiYb8H4oLu7WxDcG2/BwS/29OnTtRu6 kerjeRIgARIINwEK2OEmyvpIgARIgARIgARCIoCbo4kTJ+rFVwWw5j5z5swFIrfTN/f+/ft9VaGP w1LbiNm2BbctchcWFvqtgydJgARIgARIgARIINkIjBs3TrAwkQAJkEA8EaCAHU9Xg30hARIgARIg ARLwSwDW3Aj6iKWmpsZnXgQgMpbbRtw2a3Mcfrnr6+t91gFB3Ra0nUI3zsGqHD68mUiABEiABEiA BEiABEiABEiABCJDgAJ2ZLiyVhJIWgJNTU3y1ltvCdY333xz0o6TAyMBEkhsAnjdNRALIviZNII2 1mbbiN1YIwilr2QEdWPNDVHbLPYx+ItkIgESIAESIAESIAESIAESIAESCJ4ABezgmbEECaQcASNa //73v5e6ujo9/vXr16ccBw6YBEgg+QjAlQiWqqoqn4MbHBx0++Y2ArdzDb/chw8f9lkHBGynNbdz n9bcPvHxBAmQAAmQAAmQAAmQAAmQQAoToICdwhefQycBfwS6uroEgrUtWpv8CPAxduxYs8s1CZAA CSQ1AQSGDMSaG9+btuW2LXKbbbgt8ZcgYnuz4IY1t3FhQmtufwR5jgRIgARIgARIgARIgARIINkI UMBOtivK8ZDAKAhAfHn77be1ixC4CbETAqfhVfmKigq59tpr7VPcJgESIAESUAQKCgr0MmXKFJ88 YM0NMdsI2k7BG8dhzX3o0CGfddCa2ycaniABEiABEiABEiABEiABEkhCAhSwk/CickgkEAwBX6I1 BGtvCX6vIdIwkQAJkAAJBE8A1tx4EIjFX8J3sxG5zdopdvuz5ja+uX1Zcxv3JXl5ef66wXMkQAIk QAIkQAIkQAIkQAIkEHMCFLBjfgnYARKIDQFYWGOBixA7GUtriB8mmWOzZs2Syy67zBzmmgRIgARI IEIEjDX35MmTfbYQDmvunJwc7ZrEKXTbASjpm9vnJeAJB4EZM2ZIenq64yh3SYAESIAESIAESIAE SGB0BChgj44fS5NAwhGAaL1x40bp7u52990I1DhgC9fYt8+tWrUKh5hIgARIgATigEA4rbn37Nnj c0TGmtsWtY1PbmPJjXV+fr7POngiNQjcf//9qTFQjpIESIAESIAESIAESCCqBChgRxU3GyOB2BOA BXV1dbXs3btXd8YWqL31zgjaDNzojQ6PkQAJkED8EwiXNffx48fl8OHDPgdMa26faHiCBEggCAIZ yoo/Py9XcnNzVKk0ZVwRRGGVFV7whoeHpOdsr/T0nJUhH27xgqv1wtx56g2W3LwcyczIDLqPqA1z 8L7+ftXHXr2+sIXRH8nKzJQ8xTEnJ/sCI5VAage6oaFBzbJbsWQiARIgARIggVgRoIAdK/JslwRi SODuu++Wb3/729Lc3BxQLxi4MSBMzEQCJEACCUuA1twJe+nYcRJIKgIZGelSqN7mKCstkYL8XDU2 CNjBKdgQhrF0qbcNT7e0S/dZJWIPDYWVE0ThspJiKSwsEIjEwfYRnUEfz/b2SvuZTrV0SP/AQFj7 iH4VFxVISVGR5CmhPS0tePc+6OOgErA7u7rP9bdPr8PaUVZGAiRAAiRAAgEQoIAdACRmIYFkIwBr vDVr1sj3vvc9ZfXR43V4mLAiYUIe1sCNrmpdbZ5rw7XDf0mABEiABOKdAK254/0KsX8kkNgEcpVV c3kZxOvQXRJh7oqlqLBQCdfDMnB6QAnFfWEDg7rHqD4Wqvl0phKJQ02oJy83FxK9Fthb2tpDrcpr uYKCPC2y56o2Qk3oIyzMiwuLZFixPNncIgNhFtpD7RvLkQAJkAAJpBaB0H9xU4sTR0sCSUcAbkQg TP/4xz/2OTZMWsMduHE4zWUVA4F8WNWvzDh8ts8T0SOgr4e6FK41r0n0yLMlEkg+ArTmTr5ryhGR QLQIQBCGqBuuVFSYL23tZ8IuYBfkFwi+68KRcnKytLV5uAXsnOxs5ToEblhGnzBlLykulObWNiVg j74+1kACJEACJEACwRKggB0sMeYngSQh0NHRIa+//roWLCFUI0G8xLZZ41i4AzemDbusYtKUf8M0 iNhohCn2BNR1x8cgPd11fdSHIPZ9Yg9IgASSmkA8WXOXlJSETYxK6os2wuCef/55PY9YunTpCDl5 mgS8E3DNRYJ3deG9NsxrlMiMSsOc3POlMNQL1x6huPcYqWnM6c0cf6S8I5131ZWhbMWZSIAESIAE SCA2BChgx4Y7WyWBmBJoaGiQtWvXah/YlZWVUl5eLrt373b3yUx2IxG4EeK4sa4ZHBzUbZr23B3g RtQJ4GFCug6alKeCHQ25rOOj3gs2SAIkQAKeBKJlzY1WIWKXlZXp30Szxu+j2cYaojuTbwIvvPCC PkkB2zcjniEBEiABEiABEiABEgieAAXs4JmxBAkkNIF33nlHNmzYoH1fz549WxDQEaLyP/zDP0h9 fb3b+jpSgRshjmZnZeiI6Gc6OmnxFiefJoQ2goBdkJ+nfRwqm5046Rm7QQIkQAIjEwiXNTce8B45 csRng9nqlXwjatvCNo7Zx8PlWsBnR3iCBEiABEiABEiABEiABFKIAAXsFLrYHGpqE4BI/dxzz8nm zZs1iCVLlsiKFSu0aIkDt912m0dQx7AGbjyHHn1AEPj8PBVUprRYWpQfPVhj4zhT7Aho/uoaZGRm yLiKchVtHnI2rglF7NhdFbZMAiQQbgLhtOY+ceKE3+7RmtsvHp4kARIgARIgARIgARIggaAIUMAO Chczk0BiEuju7tZW17t27ZKsrCzt13rBggUeg0FQR4jYDz/8cNgDN5qG4CoEYmmmEkorysvkWMMJ HXXdPm+2uY4WAZff8yElWo8pLZHCgny3FX60esB2SIAESCCeCNCaO56uBvtCAiRAAiRAAiRAAiRA AiIUsPkpIIEkJ9DU1KT9XTc2NgrcgqxZs0YgVntLl112mcDv9ZVXXunt9KiPuXxdD0t//6BUThir BeyGk03KpUgWrbBHTTf4CvAwwTxUgLH1tI9V6X2I2XAnwkQCJEACJOCdAK25vXPhURIgARIgARIg ARIgARKIBAEK2JGgyjpJIE4IIDDj+vXrpbOzU6ZPny733HOPFBUV+e3d8uXL/Z4fzUmXqxC4pXAF DJxWM0Va289IX1+/9oVtBNXRtMGygREwrJVRvOY/Y/pU7dYF4rURtV0PHAKrj7lIgARIgAQuJEBr 7guZ8AgJkAAJkAAJkAAJkAAJBEuAAnawxJifBBKEwNatW+Wpp57Sls0LFy6UlStXan/Tsey+EUSx HhgYlLHK3/Ils2rlvd37pX9gwO0P24irsexrcretHiCoawBP1/3q4UHVpIlS+7FqZYStXLxo39fK +zWUbSYSIAESIIGIE6A1d8QRswESIAESIAESIAESIIEEJ0ABO8EvILtPAk4CA0oIfvTRR2Xnzp3a qhnC9aJFi5zZYrZvrLAhkA4ODsrkyglaOH1/3wHp6u6RnOxs5b4CvrJNFxlM0JAIde18IJCWlq7c uAxosXpq1SSZddE05Rs9Q/kjd7kUCbUdliMBEiABEogcgWhZcyNWRllZmZSXl+vFbGNttnEOwjsT CZAACZAACZAACZAACUSDAAXsaFBmGyQQJQKtra2ybt06OXjwoBQWFmqXIbW1tVFqPbBmIFwbQRVr CO6TJo6TvLxcqTvWqP1i9ylxNVPdGCMvLYED4+ovl2EO3lgGhwZljBIiaqoqZfLE8ZqxEa9xHonc /RHlORIgARKITwLhtObet2+f30HCJRmEbFvUxoNp/H7U19frc5iLMJEACZAACZAACZAACZDAaAlQ wB4tQZYngTghcODAAS1et7W1SVVVlQ7WOHbs2DjpnWc3jKBqRNKBwSEpLyuW0pIi5c5ivDS3tOml u/us9Jw961mYe0ETgCSNBwIFBXlSXFgg48eOkfLSYsnPz9OuXCBaO69J0I2wAAmQAAmQQMIQCJc1 NwJE19XVeYwbvyn333+/PpZK1txvvfWWzJo1S/3WFnjw4A4JkAAJkAAJkAAJkMDoCVDAHj1D1kAC MSewbds22bRpk3bJMX/+fFm1apVkK1cc8ZxswVQZawlEbPhlrihXry2XlcjHqqfI0PCQDCu3Fkxh IKAYp6enSwYWJWZDYIAbEVwH+1qEoSVWQQIkQAIkkAQEQrHmfuihh5Q7qiFB7A28FdbS0qLXoVhz G8tus453a+7Nmzdry/MrrrhCbrzxRolXI4Ik+GhyCCRAAiRAAiRAAilIgAJ2Cl50Djl5COAm8fHH H5ft27drEfKmm26SxYsXJ8wAjXCKDkO8hqg6gNeP1X8ZGemSmUb/mmG9mIovHgfgFW+kNCVmK13b 7dJFH+Q/JEACJEACJBAEAduaGw9KsfzFX/yFRw343YGgbURtI2ybNY57s+a2K4l3a264TUH6/e9/ rxcK2fbV4zYJkAAJkAAJkAAJjI4ABezR8WNpEogZgY6ODlm/fr3s2bNH+Y/Ok7vvvlvmzJkTs/6E 2jBEbCTbjYWWWZXSimNMkSEA7OALwuYaRKYl1koCJEACJJDqBEKx5vYldsezNbeZt+B3lUJ2iJ/6 c/O/cM1NzDUJsTc+i2H+hLrD0U89H4vQlDecffQJgydIgARIgARIIAoEKGBHATKbIIFwE4C/Sbym 29zcLBMnTtT+risrK8PdTFTrMzcAZh3VxlO0sXPPDlJ09Bw2CZAACZBAvBGwrbl99S1a1txwXZKZ GditkvEDbuYwRjTFPoVsX1fS+3GwwxuGeOgRjjQwMBgRd3RD6q0CuGULR0IgbfN2XDjqM3WA47By x5cWpjca+8EyQkK76TPXJEACJEACJOCLQGCzMl+leZwESCDqBHbs2CEbN25U/ov7Ze7cuXLHHXeo YHz5Ue9HMA1mKncgTCRAAiRAAiRAAslNYMaMGdqFSCRHGW1rbuODG2uzXV5e7t4uKiqSrq4uPWRj 7UohO/RPQP/AgHSrAN6F1tzW8Ay0VvMAAfm7e3qUe7qBQIsGlA/1d3Z3S1FhoQ6SjULB9hFlTD/7 +vvkbG/4g5b39vWrevslL9c1Dx9NH9FXfM4HlSjORAIkQAIkQAKxIJCmfoz4HDUW5NkmCQRJAH+q Tz/9tGzZskWXXL58uSxbtiykCXOQTTM7CZAACZAACZAACSQlAbzN5stdiTne19fnd+wIMNnZ2enT pYS53bIFxMsuu0yuueYamT17tt+6w3USYmag6XD9cdm7/1Cg2cOeLy83VyaMq5Dc3GwVI0XF6wjy lTHwHhoaVOJ1r5w41STBjD3QwaBPE8ZWKBE7XzKzMnU/Ay1r8sFCuld9tlrbzkhre3vYrZvhpK+4 qFDGqADpOTlZymI8eKt2sBxUDwC6us9Kw8lTajt2AvanP3mJjCkrNfgCWuM6Zavrw0QCJEACJJD4 BChgJ/415AhSgEC3svLYsGGD7Nq1SxDEaPXq1TJv3rwUGDmHSAIkQAIkQAIkQAKxJQDLUyNmm7UJ QIk1AlD29vb6FLBN742QjX0jys6aNUtuvPHGiAvZwYi4sRawwSZLuW9JS0dY79ASTLSGlPuMgf4B He8jtFr8l8rMzHC5EVH9DaWfsCIbPuc+JFKWzQiqmqncsYyapRLbYR0fy0QBO5b02TYJkAAJxJ4A BezYXwP2gAT8EmhoaND+rnFzVFFRof1dV1dX+y3DkyRAAiRAAiRAAiRAAtEhsHnzZnn22WdHFLDR G28iNo5HWshOJAEbPJhIwEmAAraTCPdJgARIILUI8H2a1LreHG2CEXjnnXe05XWP8t+HV0xheQ1f i0wkQAIkQAIkQAIkQALxQWDv3r0+O2IEa2NxbdamAIwTIF5jnjd27FhzmGsSIAESIAESIAESIAGL AAVsCwY3SSCeCMCSBxY9SEuWLJEVK1ZEPDBSPI2ffSEBEiABEiABEiCBRCNgBGvTb3+CNUVrQ4lr EiABEiABEiABEvBPgAK2fz48SwJRJ4BAQRs3bpSdO3dKhvJZd/vtt8uCBQui3g82SAIkQAIkQAIk QALBEHj++ee1b+elS5cGUyzh8x45csQ9BgrWbhTcIAESIAESIAESIIGwEaCAHTaUrIgERk+gqalJ +7uur6+X0tJSueuuu6S2tnb0FbMGEiABEiABEiABEogwgRdeeEG3kGoCNly9IUG8tl2C0MJaY+E/ JEACJEACJEACJDBqAhSwR42QFZBAeAjs3r1b1q9fL52dnTJ9+nQtXpeVlYWnctZCAiRAAiRAAiRA AiQQEQKf//zntQ9rCtYRwctKSYAESIAESIAESEAoYPNDQAJxQGDbtm3y+OOP68j0CxculJUrV0pm Jv884+DSsAskQAIkQAIkQAIk4JfAbbfd5vc8T5IACZAACZAACZAACYyOABWy0fFjaRIYFYGBgQHZ tGmTbN++Xb92euutt8qiRYtGVScLkwAJkAAJkAAJkAAJkAAJkAAJkAAJkAAJkECyEKCAnSxXkuNI OAKtra2ybt06OXjwoBQWFsrq1atlzpw5CTcOdpgESIAESIAESIAESIAESIAESIAESIAESIAEIkWA AnakyLJeEvBD4MCBA1q8bmtrk6qqKlmzZo2MHTvWTwmeIgESIAESIAESIAESIAESIAESIAESIAES IIHUI0ABO/WuOUccYwI7duyQRx99VAYHB2X+/PmyatUqyc7OjnGvkqP5P/zhD7Jnzx73YGDR/pnP fMa9H8rGc889J83Nzboo/JLfcsstHtUcOnRIXnnlFY9jvnbS0tIkPT1dL+GRudwAAEAASURBVLjm U6dOlcsvv5z+zn0B43ESIAESIAESIAESIAESIAESIAESIIGUJ0ABO+U/AgQQLQJDQ0PyzDPPyJYt W3STy5cvlxtuuCFazadEO93d3ToQphks9kebzp49666zv7//gup6enrc5y846TgwPDws+Bwg9fX1 yfvvv6+XMWPGyNKlSylkO3hxlwRIgARIgARIgARIgARIgARIgARIgATSiYAESCDyBDo6OuT73/++ Fq/z8vLkW9/6FsXryGNPmBZOnz4tzz77bML0lx0lARIgARIgARIgARIgARIgARIgARIggWgRoAV2 tEiznZQlUFdXJw899JB2QzFx4kTt77qysjJleST7wOEipKSk5IJhwvoaC1zH9Pb2itOaG/7Qf/Ob 38if/umfXlCWB0iABEiABEiABEiABEiABEiABEiABEggVQlQwE7VK89xR4XAO++8I+vXr9di5dy5 c+WOO+6Q/Pz8qLTNRmJDoLi4WL70pS+N2Pibb74p7777rkc+POyAixGI4EwkQAIkQAIkQAIkQAIk QAIkQAIkQAIkQAIiFLD5KSCBCBCApS2C/23evFnXvmTJEvnqV78qCOLHRAIg8KlPfUqmTZsmv/rV rzyAfPTRR1JbW+txjDskQAIkQAIkQAIkQAIkQAIkQAIkQAIkkKoEKGCn6pXnuCNGAIEDN2zYILt2 7ZKsrCxZtWqVLFiwIGLtseLRE0BAxYaGBmltbZXq6mopLy8ffaUB1IDgjRUVFdq9jMl+5MgRCtgG BtckQAIkQAIkQAIkQAIkQAIkQAIkQAIpT4ACdsp/BAggnASamppk7dq10tjYqIXJNWvWaEE0nG2w rvAR2LNnj7z99tvS09PjrvSPf/yjduEBVyDXXXed+3ikNiBiNzc3u6tHQEcmEiABEiABEiABEiAB EiABEiABEiABEiABFwEK2PwkkECYCOzevVv7u+7s7JTp06fLPffcI0VFRWGqndWEm8DWrVvl2LFj XquFH2oEVXzmmWckMzOyX5O2eI7OZGdne+0TD5IACZAACZBAvBOYMWMG4zjE+0Vi/0iABEiABEiA BEggAQlEVplJQCDsMgmEQgBi6FNPPSXwfb1w4UJZuXJlxIXPUPrJMi4CvsRr+CjHNTRpcHBQsEQy 2dbXaAcW2UwkQAIkQAIkkIgE7r///kTsNvtMAiRAAiRAAiRAAiQQ5wQoYMf5BWL34psAfCdv3LhR du7cKRkZGVq4XrRoUXx3OsV7d+LEiQssr/Pz82Xx4sXa9zUE7A8++EBfU1vMjgQ2uCuBz3Q7VVZW 2rvcJgESIAESIAESIAESIAESIAESIAESIIGUJkABO6UvPwc/GgII+PfAAw9IfX29lJaWyl133cXg e6MBGqWyr776qkdLuHZf/vKX3cdghX3JJZfIpEmT5NlnnxW4Ewl3OnnypLz22mvS0tLiUTXch9TW 1noc4w4JkAAJkAAJkAAJkAAJkAAJkAAJkAAJpDIBCtipfPU59pAJHDhwQNatW6f9JFdVVcl9990n ZWVlIdfHgtEjcObMGY/G/uRP/sRj3+yUl5cLfHnu3bvXHApoDd/ZTzzxxAV5Yc0NMdyfIA73M0wk QAIkQAIkQAIkQAIkQALnCcDARAQLEwmQAAmQQKoSoICdqlee4w6ZwLZt22TTpk3aN/L8+fNl1apV DLwXMs3oFty/f7+Hj2tYX2PxlT772c/Kvn37PMr4ymsf7+/vt3cD2q6pqREsTCRAAiRAAiRAAiQQ SwIZ6emSqVzjDUQ4Dkgsx8i2E4tAdlampGsRO7H6zd6SAAmQAAmEjwAF7PCxZE1JTmBgYEAL19u3 bxdYAdx0003ab3KSDzuphnfq1CmP8YwUMDFd3cDBP3ZXV5dHuXDuwG3IpZdeqpdw1su6SIAESIAE SCDaBNauXSv47bz33nuj3TTbCyOBrKwsycvLkY5OzzgdYWyCVZFAUAQKCvJ0vKGgCjEzCZAACZBA UhGggJ1Ul5ODiRSBjo4OefDBB+XgwYNSWFgoq1evljlz5kSqOdYbIQJOIbq4uHjElvLy8oISsPFw A2W8JdzUZ2ZmCm4MKyoqZNq0acKgjd5I8RgJkAAJkEAiEvjwww8Tsdvss4NAvhKvi4sKKWA7uHA3 dgTGlJUKrLCZSIAESIAEUpcAfwVS99pz5AESqKurk4ceekiam5tl4sSJcv/998vYsWMDLM1s8USg t7fXozs5OTke+952YIEdTCopKfEIChlMWeYlARIgARIgARIggVgTyM/Pk4ryUmluaZPe3r5Yd4ft pzABGIbk5+XKuIpyycrOSmESHDoJkAAJkAAFbH4GSMAPgR07dsjGjRsFPo3nzp0rd9xxh3Yp4acI T8UxAbjrsFNf38g3ZXAdw0QCJEACJEACJEACqUIgS70tVlZaIlMqx0vd0QbpHxhMlaFznHFEQL/V mJsj06dOkQJlUALf7EwkQAIkQAKpS4ACdupee47cD4GhoSF55plnZMuWLTrX8uXLZdmyZdr3tZ9i PBXnBAoKCjx62NbW5rHvbae7m/4fvXHhMRIgARIgARIggeQlAKvXmimVKphjuuw/dFQwN2YigWgR gHhdWJAv02qmSOUEvvkaLe5shwRIgATimQAF7Hi+OuxbTAhAsHz44Ydlz5492pcxrK7nzZsXk76w 0fASgN9pO7W0tNi7XrcpYHvFwoMkQAIkQAIkQAJJTgAxO6ZMmiilyj3aiaZmOXOmU7q6e6S3rz/J R87hxYIAYsXk5mQra+s8KS8r0W5D8tSDFCYSIAESIAESAAEK2PwckIBFoKGhQfu7bmxs1EH24O+a QfYsQAm+OXPmTHn99ddleHhYjwQW2BCxy8vLvY7s8OHDEoibEa+FeZAESIAESIAESIAEEpgArGAR fLqkuFBylSsHuFUbHBySIT2Pcs2lEnh47HqcEUiTNIGInaGs/vHwBEEbsc9EAiRAAiRAAiBAAZuf AxI4R+Cdd96RDRs2SE9Pj8yePVtWr14tRUVF5JNEBHAjhiCLtuuQ//mf//EZdBFiNxMJkAAJkAAJ kAAJpCoBzJ0yMjJUIL2MVEXAcZMACZAACZAACcQBAT7SjIOLwC7ElgCscZ999ln513/9Vy1eL1my RP7mb/6G4nVsL0vEWl+4cKFH3RCz4e/ctrTu6uqSf//3f9efB4/M3CEBEiABEiABEiABEiABEiAB EiABEiABEogqAVpgRxU3G4s3AhAt169fL7t27dKvqq1atUoWLFgQb91kf8JIYNy4cTJ16lSBexCT Ojo65Kc//alkZ2frQ7aYbfJwTQIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkEH0CtMCOPnO2GCcEmpqa 5G//9m+1eF1aWirf+973KF7HybWJdDeuvvpqqaqquqAZCNdO8ZpuZC7AxAMkQAIkQAIkQAIkQAIk QAIkQAIkQAIkEDUCFLCjhpoNxROB3bt3y3e+8x2pr6+X6dOnyz/90z9JdXV1PHWRfQmBAHw02slf 4JdrrrlGPv3pT7utru1y2EZdixYtElhsmwQ/kM4UTJvOstwnARIgARIgARIgARIgARIgARIgARIg ARLwTyBN+f9lCGn/jHg2yQhs3bpVnnrqKcFHH/6QV65cqSOsJ9kwOZwgCBw/flyOHTsm7e3tUl5e LjNnzpTCwsIgamBWEiABEiABEiCBW265RUN44oknCCPOCPT29cdZj9gdEog8ARifZGfRa2rkSbMF EiABEog8AX6bR54xW4gTAgMDA/Loo4/Kzp07tXUthGtY2DKRwKRJkwQLEwmQAAmQAAmQAAmQAAmQ AAmQAAmQAAmQQHwRoIAdX9eDvYkQgdbWVlm3bp0cPHhQW9bec889UltbG6HWWC0JkAAJkAAJkAAJ kAAJkAAJkAAJkAAJkAAJkEA4CFDADgdF1hHXBA4cOKDF67a2Nh24b82aNTJ27Ni47jM7RwIkQAIk QAIkQAKJRmDp0qXiLV5Eoo2D/SUBEiABEiABEiABEogvAvSBHV/Xg70JM4Ft27bJpk2bZHBwUObP ny+rVq3yGbQvzE2zOhIgARIgARIgARIggRQkcOrUKXnjjTfki1/8YtyMnj6w4+ZSsCNRJEAf2FGE zaZIgARIIMIEaIEdYcCsPjYEhoaG5PHHH5ft27drS6CbbrpJFi9eHJvOsFUSIAESIAESIAESIIGU IIBYKz/+8Y+lt7dXv/k3b968lBg3B0kCJEACJEACJEACkSRAATuSdFl3TAh0dHTI+vXrZc+ePZKX lyd33323zJkzJyZ9YaMkQAIkQAIkQAIkQALJT+Ds2bPy2GOPyY4dO7TxxA033CCXXnpp8g+cIyQB EiABEiABEiCBKBCggB0FyGwiegTq6urkoYcekubmZpk4caLA33VlZWX0OsCWSIAESIAESIAESIAE UorAkSNH5Ac/+IHAdUhZWZmsXr1aLrroopRiwMGSAAmQAAmQAAmQQCQJ0Ad2JOmy7qgSgMXLxo0b pb+/X+bOnSt33HGH5OfnR7UPbIwESIAESIAESIAESCA1CMBl3ZYtW+SXv/yljrcCdyG33XabFBQU pAYAjpIESIAESIAESIAEokSAAnaUQLOZyBEYHh6Wp59+Wt9AoJXly5fLsmXL9OubkWuVNZMACZAA CZAACZAACdgE1q5dK+np6XLvvffah5Nyu6WlRbusO3DggOTk5Mgtt9wiV1xxRVKOlYMiARIgARIg ARIggVgToAuRWF8Btj8qAt3d3bJhwwbZtWuXZGVl6Vc2GSxnVEhZmARIgARIgARIgARCIvDhhx+G VC7RCr3zzjvy6KOPCuah1dXVctddd8m4ceMSbRjsLwmQAAmQAAmQAAkkDAEK2AlzqdhRJ4GGhgbt 77qxsVEqKiq0v2vcRDCRAAmQAAmQAAmQAAmQQLgJIFDjU089Ja+88oquevHixbJixQrJyMgId1Os jwRIgARIgARIgARIwCJAAduCwc3EIbB79255+OGHpaenR2bPnq0tr4uKihJnAOwpCZAACZAACZAA CZBAwhBwBmqEr+uLL744YfrPjpIACZAACZAACZBAIhOggJ3IVy9F+75161Zt/QLf1wsXLpS//Mu/ 1P4WUxQHh00CJEACJEACJEACJBAhAphvvvjiiwzUGCG+rJYESIAESIAESIAEAiFAATsQSswTFwT6 +vpk48aNsnPnTv2q5sqVK2XRokVx0Td2ggRIgARIgARIgARIILkItLe3yyOPPCJ48w+xVm6++Wa5 +uqrk2uQHA0JkAAJkAAJkAAJJAABCtgJcJHYRZGmpibt77q+vl5KS0t1sJza2lqiIQESIAESIAES IAESIIGwE0Cgxp/85Cdy5swZqays1HPPSZMmhb0dVkgCJEACJEACJEACJDAyAQrYIzNijhgTOHDg gDz44IPS2dkp06dP1zcQZWVlMe4VmycBEiABEiABEiABEkg2Av39/fLzn//cI1DjV77yFW2BnWxj 5XhIgARIgARIgARIIFEIUMBOlCuVov3ctm2bbNq0SQYHB2X+/Ply++23S2YmP7Yp+nHgsEmABEiA BEiABEggYgSOHz8u69atk4aGBikuLpY777yTgRojRpsVkwAJkAAJkAAJkEDgBKgEBs6KOaNIYGBg QAvX27dvl7S0NLnppptk8eLFUewBmyIBEiABEiABEiABEkgVAi+//LI8+eSTAgvsOXPmaPG6pKQk VYbPcZIACZAACZAACZBAXBOggB3Xlyc1O9fa2qqtXw4ePCiFhYWyevVqfSORmjQ4ahIgARIgARIg ARIggUgRQKDGxx57TODzOiMjQ1asWCHXXXedNqCIVJuslwRIgARIgARIgARIIDgCFLCD48XcESZQ V1cnDzzwgLS1tUlVVZWsWbNGxo4dG+FWWT0JkAAJkAAJkAAJkECqEfjggw/kkUcecQdqhMuQmpqa VMPA8ZIACZAACZAACZBA3BOggB33lyh1Orhjxw7ZuHGjfnVz7ty52vI6Ozs7dQBwpCRAAiRAAiRA AiRAAhEngNgqzzzzjGzdulW3ddVVV8nNN9/MQI0RJ88GSIAESIAESIAESCA0AhSwQ+PGUmEkMDQ0 pG8itmzZomtdvny5LFu2jK9uhpExqyIBEiABEiABEiABEhBBoEZYXeOtv/z8fB0gfN68eURDAiRA AiRAAiRAAiQQxwQoYMfxxUmFrnV0dMj69etlz549kpeXJ3fccYfwJiIVrjzHSAIkQAIkQAIkQALR JWAHaqytrdVv+5WXl0e3E2yNBEiABEiABEiABEggaAIUsINGxgLhItDQ0CBr166V5uZmmThxovZ3 XVlZGa7qWQ8JkAAJkAAJkAAJkEAUCSxdujQu36Dr6uqSH/3oRx6BGpcsWSLp6elRpMOmSIAESIAE SIAESIAEQiWQNqxSqIVZjgRCJYBI7xs2bJCenh6ZPXu23H333fo1zlDrYzkSIAESIAESIAESIAES cBLYv3+/ftuvtbVVxo0bJ9/85jcZqNEJifskQAIkQAIkQAIkEOcEaIEd5xco2bqH5yXPPfecbN68 WQ8N1i8rVqygBUyyXWiOhwRIgARIgARIgARiSACBGjHnxIL554IFC+TWW2+V3NzcGPaKTZMACZAA CZAACZAACYRCgAJ2KNRYJiQC3d3d2up6165dOsr7qlWr9M1ESJWxEAmQAAmQAAmQAAmQAAl4IXDq 1ClZt26dO1DjypUr5TOf+YyXnDxEAiRAAiRAAiRAAiSQCAQoYCfCVUqCPjY1NWl/142NjVJRUaH9 XVdXVyfByDgEEiABEiABEiABEiCBeCHwxhtvyGOPPSa9vb3CQI3xclXYD/hhr6ur064TSYMESIAE SIAESCB4AhSwg2fGEkES2L17t/Y92NnZKdOnT5d77rlHioqKgqyF2UmABEiABEiABEiABEjAOwEI hJs2bZIdO3boQJI33HCDYGGgRu+8eDS6BPbu3SsvvfQSBezoYmdrJEACJEACSUSAAnYSXcx4HMrW rVvlqaee0r4HFy5cKHiFMzOTH7t4vFbsEwmQAAmQAAmQAAmMhsDatWu1YHzvvfeOppqgy9qBGsvK ymT16tVy0UUXBV0PC5BApAgcOXJEIGLv2bOHInakILNeEiABEiCBpCZAJTGpL2/sBtfX1ycbN26U nTt3SkZGhhauFy1aFLsOsWUSIAESIAESIAESIIGIEvjwww8jWr+z8qGhIXn22Wc9AjXCWKKgoMCZ lfskEFMCEK+RcH/0wx/+MKZ9YeMkQAIkQAIkkIgEKGAn4lWL8z63trbKAw88IPX19VJaWip33XWX 9kEY591m90iABEiABEiABEiABBKEQEtLi3ZRd+DAAcnJyZFbb72VgRoT5NqlYjeNgN3c3Cyvvvqq XHnllamIgWMmARIgARIggZAJUMAOGR0LeiOAmwhEfW9ra5Oqqiq57777BK9yMpEACZAACZAACZAA CZBAOAggUCP8XXd3dwuCgsNYYty4ceGomnWQQNgJIHgj0vDwsPbP/qtf/YoCdtgps0ISIAESIIFk J0ABO9mvcBTHt23bNn0zMTg4KPPnz5dVq1ZJdnZ2FHvApkiABEiABEiABEiABJKVwNmzZ+Wxxx7T gRoxxsWLF8uKFSu0u7pkHTPHlfgE4PfaTrTCtmlwmwRIgARIgAQCI0ABOzBOzOWHwMDAgBaut2/f rq0KbrrpJn1D4acIT5EACZAACZAACZAACZBAwAQQBO8HP/iBnDp1Sr/dd9ttt8nFF18ccHlmJIFY EcBnFyktLc3DCvuyyy6jv3ZNhv+QAAmQAAmQwMgEKGCPzIg5/BDo6OiQBx98UA4ePCiFhYU66vuc OXP8lOApEiABEiABEiABEiABEgiMAAI1btmyRX75y18K3vKbN2+eQLxmoMbA+DFX7Ak4XYigR7DC fumll2T58uWx7yB7QAIkQAIkQAIJQIACdgJcpHjtIiZjDz30kJ6ATZw4Ue6//34ZO3ZsvHaX/SIB EiABEiABEiABEkggAnagxqysLLn55pvl6quvTqARsKupTqCrq0sHtgcHWGAjGV/Y//3f/y3XXnst H8ZoKvyHBEiABEiABPwToIDtnw/P+iCwY8cO2bhxo/T398vcuXPljjvukPz8fB+5eZgESIAESIAE SIAESIAEAifwzjvvyKOPPqoDNVZWVupAjZMmTQq8AuYkgTgg4M362rgSQRBSWmHHwUViF0iABEiA BBKCAAXshLhM8dNJWAw8/fTT+lVO9AqvvS1btsxtURA/PWVPSIAESIAESIAESIAEEo0AjCN+/vOf yyuvvKK7jkCNX/nKVwQW2EwkkGgETABHY33t7D+tsJ1EuE8CJEACJEAC3glQwPbOhUe9EICVwIYN G2TXrl36JmL16tXaD6GXrDxEAiRAAiRAAiRAAiRAAkERQLC7Rx55RBoaGqS4uFjuvPNOBmoMiiAz xxuBvXv36i4ZtyGmf7TCNiS4JgESIAESIIHACFDADoxTyufCjQT8XTc2NkpFRYWsWbNGqqurU54L AZAACZAACZAACZAACYyOAMS9F1980R2oEQHBIV6XlJSMrmKWJoEYE8BDGSRfFtg49+yzz8qVV17J WEKAwUQCJEACJEACPghQwPYBhofPE4APQlhe9/T0yOzZswWW10VFReczcIsESIAESIAESIAESIAE QiDQ3t6ura53796t3/BDoMYvfOELfgW/EJphERKIOoGmpiZ9/+S0vjYdMVbYWG/evFluu+02c4pr EiABEiABEiABBwEK2A4g3PUkAIsATKiQlixZIitWrJD09HTPTNwjARIgARIgARIgARIggSAJfPDB B1q8PnPmjDBQY5DwmD3uCRj/1yN1FAL3a6+9pmMLjR07dqTsPE8CJEACJEACKUmAAnZKXvaRB93X 1ycbN26UnTt3SkZGhtx+++2yYMGCkQsyBwmQAAmQAAmQAAmQAAn4IYBAjb/4xS9k69atOtdVV10l sLxmoEY/0Hgq4QjU1dW5+2yssLFGMtbXZhtrWmGDAhMJkAAJkAAJeCdAAds7l5Q+itfd4O+6vr5e SktL5a677pLa2tqUZsLBkwAJkAAJkAAJkAAJ+CewdOnSEV1/HD9+XNatW6cDNebn52sjiXnz5vmv mGdJIAEJGAts2/+1t23EF4LldUFBQQKOkl0mARIgARIggegQSFNPgV2PgaPTHluJcwLwP7h+/Xrp 7OyU6dOna/G6rKwsznvN7pEACZAACZAACZAACcQ7gZdfflmefPJJgQU2AjXC5295eXm8d5v9I4GQ CHz1q191l5s1a5bexlsG7733nnz+85+nyxA3HW6QAAmQAAmQwMgEaIE9MqOUybFt2zZ5/PHHBc80 Fi5cKCtXrpTMTH5EUuYDwIGSAAmQAAmQAAmQQAQIIFDjY489JggMDtd0iKly3XXXjWitHYGusEoS iAqBrq4u+e53vyvV1dUeltVvvfWWFrDRCfq7jsqlYCMkQAIkQAJJQoDqZJJcyNEMY2BgQDZt2iTb t2/XNxK33nqrLFq0aDRVsiwJkAAJkAAJkAAJkAAJiB2ocdy4cfLNb35TampqSIYEkpoA3IHMnj37 gjEa0bq5ufmCczxAAiRAAiRAAiTgmwAFbN9sUuJMa2ur9kN48OBBKSwslNWrV+tXOlNi8BwkCZAA CZAACZAACZBARAgMDg7KM8884w7UiGDgMJLIzc2NSHuslAQSgQAEbPjBRswhJhIgARL4/+ydB4BV xfn2X7YvK034K0UpIqggosQeRREwCgoRRYqIgiKCIBq/xJJoYjdqBCxYiKIGRBFBVLAisbFGDVaw IAoYqnS2N77zDM5xzuy5ZXfvvXvL8ybXe8qcOTO/uZfdfeY9z5AACZBA+AQoYIfPKulKrly5UonX O3bskLZt28o111zDR9mSbpTZIRIgARIgARIgARKILYHNmzer3zHXrFkjWKgRtnQnnnhibBvBu5FA HBLA96F58+aydetWqaqqkrS0tDhsJZtEAiRAAiRAAvFHgAJ2/I1JTFqUn58v06ZNE2THHH/88XL5 5ZdLVlZWTO7Nm5AACZAACZAACZAACSQfgVGjRqnfLeFzXVpaKp06dVJP93GhxuQba/ao9gSQhQ0L kY0bN0rr1q1rXxGvJAESIAESIIEUIkABO4UGG13FTD8e51y4cKHq+XnnnSeDBg1KMQrsLgmQAAmQ AAmQAAmQQCQJYNG68vJyJWAjQQK/X+LFDNNIUmZdyUCgRYsWqhvr16+ngJ0MA8o+kAAJkAAJxIQA BeyYYI6Pm+zevVumTp0qK1askNzcXLniiiukR48e8dE4toIESIAESIAESIAESCAhCXz33Xfqd0wk SsDf969//at07tw5IfvCRpNAtAnohRzpgx1t0qyfBEiABEggmQhQwE6m0QzSF3gQ/uMf/1CPq7Vq 1Ur5XfORtSDAeIoESIAESIAESIAESCAoAWRaz58/X7327Nmjsq0zMzMpXgelxpOpToACdqp/Ath/ EiABEiCB2hCggF0bagl2zbJly1RWDB7rPOqoo1TmNRYQYZAACZAACZAACZAACZBAbQiYCzVmZ2fL mDFjZPr06bWpiteQQEoR0ElEzMBOqWFnZ0mABEiABOpIgAJ2HQHG8+XIhEFWzNy5c1Uz+/fvL8OH D1ePdsZzu9k2EiABEiABEiABEiCB+CWwdOlSJVZjocZ27drJ1VdfLfvttx8F7PgdMrYsjghQwI6j wWBTSIAESIAEEoYABeyEGaqaNbSoqEgeeugh+fTTTwWPcl5++eVywgkn1KwSliYBEiABEiABEiAB EiCBXwiUlJQokTo/P18lRGCRxnPOOUfS09PJiARIIEwCeXl5aj0iZGDDN54LnYYJjsVIgARIgARS mgAF7CQcfqxoDb/rDRs2CFa5vuaaa1R2TBJ2lV0iARIgARIgARIgARKIAQEs1Dht2jSBdUizZs1k 0qRJ9LqOAXfeIjkJwAd77dq1snXrVtGe2MnZU/aKBEiABEiABCJDgAJ2ZDjGTS3Lly+X++67T4qL i6VLly7qj4tGjRrFTfvYEBIgARIgARIgARIggcQhgAzRefPmuQs19ujRQ8aNGyfIImWQAAnUjoAW sJGFTQG7dgx5FQmQAAmQQGoRoICdROO9aNEimTVrlsD7+tRTT5VLL72Uj6Ql0fiyKyRAAiRAAiRA AiQQSwLbtm1TC4GvXLlSWdKNGDFC+vbtG8sm8F4kkJQEtGjNhRyTcnjZKRIgARIggSgQoIAdBaix rrKsrEweeeQR+fDDD5UH4ejRo6VXr16xbgbvRwIkQAIkQAIkQAIkkCQEli1bpixDsK4KFmqcMGGC tGnTJkl6x26QQP0S4EKO9cufdycBEiABEkg8AhSwE2/MqrX4k08+UeJ106ZN1SrwnTp1qlaGB0iA BEiABEiABEiABEggFAEs1Ign+hYvXqyK9uvXT4YNG8aFGkOB43kSqAEBCtg1gMWiJEACJEACJOAQ oICdBB+DE088UbZs2SI9e/YUiNgMEiABEiABEiABEiABEqgpgdWrV8uUKVPUQo2NGzdWWdeHH354 TatheRIggRAEtIXI+vXrQ5TkaRIgARIgARIgARCggJ0kn4MBAwYkSU/YDRIgARIgARIgARIggVgS wPopr7zyisyZM0cqKyula9euSrxu0qRJLJvBe5FAyhBo3ry5NGjQQChgp8yQs6MkQAIkQAJ1JEAB u44AeTkJkAAJkAAJkAAJkAAJJCoBLNT48MMPy/Lly9VCjSNHjpQ+ffoocS1R+8R2k0C8E0hLSxOI 2HiKtrCwUPLy8uK9yWwfCZAACZAACdQrAQrY9YqfNycBEiABEiABEiABEiCB+iFgLtQIT96rr766 Tgs1XnvttRS+62coedcEJAAbEQjYeFHATsABZJNJgARIgARiSoACdkxx82YkQAIkQAIkQAIkQAIk UL8EysvL5emnn3YXauzdu7cg8zozM7NODTv00EPrdD0vJoFUIoBJo6+//lp+/vlnadeuXSp1nX0l ARIgARIggRoToIBdY2S8gARIgARIgARIgARIgAQSk8C6detk8uTJynsXCzVedtll0qNHj8TsDFtN AglMAAI2AgI2gwRIgARIgARIIDgBCtjB+fAsCZAACZAACZAACZAACSQ8ASzU+NZbb8nMmTMFGdhc qDHhh5QdSHACsBBBUMBO8IFk80mABEiABGJCgAJ2TDDzJiRAAiRAAiRAAiRAAiRQPwR27twpDz74 oFqoMT09XYYNGyZnnXUW/arrZzh4VxJQBLSAvX79ehIhARIgARIgARIIQYACdghAPE0CJEACJEAC JEACJEACiUrgq6++UuL1rl27ZL/99pOrrrpK2rdvn6jdYbtJIGkItGjRQvWFAnbSDCk7QgIkQAIk EEUCFLCjCJdVkwAJkAAJkAAJkAAJkEB9EIBNyHPPPSeLFi1St8dCjRdccIHk5ORErTmjRo1Sdc+Y MSNq92DFJJAsBPLy8iQ3N1e2bt0qVVVVkpaWlixdYz9IgARIgARIIOIEKGBHHCkrJAESIAESIAES IAESIIH6I2Au1NiwYUMZP348F2qsv+HgnUkgIAHYiKxdu1aJ2NpSJGBhniABEiABEiCBFCZAATuF B59dJwESIAESIAESIAESSC4Cb775prtQY6dOnWTSpEmy7777Jlcn2RsSSBICrVu3VgI2FnKkgJ0k g8pukAAJkAAJRIUABeyoYGWlJEACJEACJEACJEACJBA7AoWFhfLwww/LsmXL1OKMgwYNErxoSxC7 MeCdSKCmBCBgIyBgM0iABEiABEiABAIToIAdmA3PkAAJkAAJkAAJkAAJkEDcE8BCjRCvt2/frhZq hGVI586d477dbCAJpDoBnXXNhRxT/ZPA/pMACZAACYQiQAE7FCGeJwESIAESIAESIAESIIE4JFBZ WSmzZ892F2o84YQTZMyYMVFdqDEOMbBJJJCwBChgJ+zQseEkQAIkQAIxJkABO8bAeTsSIAESIAES IAESIAESqCuBzZs3y+TJk2XNmjWSnZ2thOsTTzyxrtXyehIggRgS0AI2LURiCJ23IgESIAESSEgC FLATctjYaBIgARIgARIgARIggVQlsHTpUpk+fbqUlpZKu3bt5Oqrr1bWIanKg/0mgUQl0Lx5c+VZ TwE7UUeQ7SYBEiABEogVAQrYsSLN+5AACZAACZAACZAACZBAHQhgocYnnnhC8vPz3YUazznnHElP T69DrbyUBEigvghgkdWWLVvKhg0bBN/vvLy8+moK70sCJEACJEACcU0gaQXsPXv2xDV4No4Eok2g QYMG0b4F6ycBEiABEiABEogRge+++06mTp2qFmps1qyZTJo0iQs1xog9b0MC0STQunVrJWBv2bKF AnY0QbNuEiABEiCBhCaQtAJ2RUWlVFHETugPJxtfNwLZWZl1q4BXkwAJkAAJkAAJ1DuBqqoqmTdv nsyfP1+QoNGjRw8ZN24cha56Hxk2gAQiQ0D7YK9bt05ZAkWmVtZCAiRAAiRAAslFIGkF7OQaJvaG BEiABEiABCJL4Pvvv5f+/fu7lQ4fPlz++te/uvvciDyBUaNGCbyLIxUYv/vuuy8i1VVUVEj37t0F 74jx48erDN+IVM5Kak0ACzU+9NBDsnLlSrVQIz5DPXv2rHV9vJAESCD+CGgBe/369fHXOLaIBEiA BEiABOKEAAXsOBkINoMESIAESIAEYkng448/FlgS6MjJydGbfI8CAWTRvvDCC7J79+6I1Q7v40jF ihUrBC8d9GHVJOrvHZMd8LsuKiqSDh06qKzrAw44oP4axDuTAAlEhYAWsLmQY1TwslISIAESIIEk IUABO0kGkt0gARIgARIggZoQgIBtxtFHH23ucjvCBFatWhVR8RrNi+SYLVu2zNPj3/zmN5597sSO QElJiUyfPl0t1Ii7ItN+6NChXKgxdkPAO5FATAloARse2AwSIAESIAESIAF/AhSw/bnwKAmQAAmQ AAkkNYH8/HxP/4466ijPPnciS6B58+by4IMPBqy0sLBQrr32Wvf8fvvtJzfddJO777dxyimn+B2u 1TF7QqNr1661qocX1Y3A6tWrZcqUKQLrkCZNmqis6yOOOKJulfJqEiCBuCYAARuLrzMDO66HiY0j ARIgARKoZwIUsOt5AHh7EiABEiABEog1gdLSUvnwww/d2x500EGy7777uvvciDwB8L3iiisCVvzR Rx95zp155plBy3sKR2DH/Dwcf/zxkpWVFYFaWUW4BGAxs3DhQpkzZ45UVlZKt27dlA85ROxECkzC QIhjkAAJhE+gYcOGgknOrVu3Cv4tSEtLC/9iliQBEiABEiCBFCFAATtFBprdJAESIAESIAFNYPny 5XpTvf/2t7/17HMn9gT++9//em56zDHHePajuQOPZdNC5IQTTojm7Vi3RWDbtm0ydepUtVBjZmam jBw5Uvr06ZOQQvChhx5q9Y67JEAC4RBAFjYsRDZu3CitW7cO5xKWIQESIAESIIGUIkABO6WGm50l ARIgARIgARFbLD3uuONCYsHig7A3KC4uFiwk17Jly1plieEPdNSDaN++vbRo0UJt1/d/kJW+du1a lQHXrl07adWqVUybZGdg18aDGmP07bffSqNGjaRjx46SkRHer3lffPGFp6/HHnusZ78uO/pzA76d OnVSthh1qU9fi3rXrFmjFjjE5wiWK4kYmDiYNm2a6ge+V1deeaX6fiViX9hmEiCB2hPQPwvXr19P Abv2GHklCZAACZBAEhPg80lJPLjsGgmQAAmQAAn4EbD9jgOJpRCr77nnHtl///2lcePGAi9eiN1t 2rRRC8r17NlT/v3vf/vdwnNsw4YNyssXdSDLDNnFeGEbx4YNG6ayTz0XGTsQ+eDJrF8ffPCBcbb6 5m233eaWDZZNXF5eLs8995xAsM3JyZHOnTsLyiP7De36/e9/rwTh6neI/JGlS5d6Kg3X9/jFF1+U Cy64QAnWaDO4IgsWmbzdu3eXJ598Uvbs2eOp296xJzQC+aG/9tprLlc9FrNmzbKrk+3bt8s//vEP OfDAA93PDdrVtGlTdWzixImyY8eOateZBzA2aL++j84Qh9XJeeedp+qFzQY+j/h8QrB/9dVXzSri ehv9e/zxx+Xee+9V4nXv3r3l9ttvp3gd16PGxpFA9Ajg5yGCPtjRY8yaSYAESIAEEptAA+ePmuB/ 1SRo/8rLK6QqObuWoCPCZseaQHZWZqxvyfuRAAkkCAGIgitWrHBbiwUE4cFpBrKRYS3yv//9zzzs uz106FCZOXOmErXtAhA94eccTtx///0CcdOOhx56SCZMmOAehgVKly5d3H17A4K0FukhBH/++ed2 ESWYn3HGGfLDDz9UO2cfCNQuu1xt9yH4mh7kgdps1l9QUCBXXXWVEkHN437b4P/Pf/4zYFbfxRdf LE899ZS6FNnbEJdtD1YI5eecc46n+uuvv14wWWCWhY/zWWed5Snnt4OM6dmzZ8tpp53md1qQFQ4B W8c333wjTzzxhNx99936kO87RGyMazwHnkDAgp7ItMzLy5OxY8fK0UcfHc9NZttIgASiTOCdd96R Rx99VP37BRshBgmQAAmQAAmQgJcAM7C9PLhHAiRAAiRAAklNYNeuXR7xGmKpLV7D7gFipS1en3rq qXL++eerTGUT0rPPPqsytc1j2F61apUqbx8fOHCg4GXbPsA+4f3337eLu2K0PoFM6UBRUlLiKe/n 741sZ2Sd2+I1soTRvx49eniqR7sgzEYrbIH9pJNOCnor2ISg/cjgNQPiM8bN7jNEXUwyYHEwv3jv vffcw1jA0RSkcQJCsy1eQ2i54447PGVhhWGL12gTROpzzz3Xk128efNmQdYxRFy/0BnX+tykSZM8 4jXqxeKjdowZM8Y+FDf7yBl5+eWX5cYbb1T9Rgb5XXfdRfE6bkaIDSGB+iOgfa+ZgV1/Y8A7kwAJ kAAJxDcBCtjxPT5sHQmQAAmQAAlElIAtltpiJ262ZMkSz6J+sDbAQnM4DssNZMM+//zznnYhG3fr 1q2eYxBY4VWsY8GCBQKBGdm8eP34449y00036dPq/YorrvDsY8cUWCGGBvN2theohChtBsQBZOia 7Ro8eLDyU4YPNfoHS4233nrLI7BffvnlyurBrCtS25988omnKrvN5kmI0Jdccol899137mFMQnz2 2Wcqc3revHlqEgBjhOM6wPDpp5/Wu+47xtUU8m3LFYzh8OHD3fLYWLRokVx22WWeY7CSsccOQi3s YxYvXixz585VjB944AHPdX/84x89+3rH9gR//fXX1SlMfKBvO3fuVBMkyGY2JzQw6RKPAhDaC8Ef kwEIML3uuuukefPmaj9Z/jNq1CjBi0ECJFAzAlrADjSpV7PaWJoESIAESIAEko8ABezkG9M69wgZ QvgDubISr0qpqKiU8ooKgS2LfpWVlYv7cnwc9XGUQ/kK5zpcj3pg5ZKkTjV1Zs0KSIAESCDWBGy/ Yz+xFEK1DmS53nDDDdKsWTN9SBo0aKB8iGGDYIZdtxYdUQYC8IABAyQ7O9u9BJnfN998s0BA1gHr CFNctgVWZAgHC7sNtr83bDfM+q+++mqZM2eOtG3b1lMtsoPhH60DwugLL7ygdyP6bou1dga4ebNn nnlGTA9w8IB4DLsNM3P6kEMOEdi3mHHttdeau2r7008/9RwzeUFsvvTSS93zyJgHX9sSpqioSInq bkFnY/78+XLLLbcoiwx9HO2DFQyEWx3ojymg6+NmH/WxGTNmqIkP9A2fQQQW3Bw/frwuot7jTQBC NjnYY3IFDMEFmeq6D57Gc4cESCAlCcBOKDc3VzZu3BjwaZmUBMNOkwAJkAAJkMAvBChgp/hHAcKy flVV7RWuIUKXlJZJobN4166CItm5a7ds275TtmzbIT9v3S6bf94mmzZvlY2/vDb/7Bzbsl22OmVQ bsfOXY44UCgFRcVSXFKqhG6I2BCz9b0oaKf4B4/dJwESqDcC//nPfzz3NgVLfQKLN+qAuAhR2S9g C2GGnd0Nn2YdyAw269XH8T5kyBBzVwl9+gAyi80I5RVsi8GHHXaYeznsSSCY6ujbt6/HlkIf1+8Q ak0x2fQN12Ui8Q7vUzPMNpvHkcV7zTXXuIcOOOAAefPNNz2TC+5JZ6NVq1ZqgkAfg23Hli1b9K56 t7O/dX/vvPNOgXWKDmQ547Ojz+vjeJ8yZYpHhIZAiwUwA4UtpMMSxQwI4vZnbty4cQKvbr+wLXCa NGniVyzmx8yFGmHdA2sYWIZ06NAh5m3hDUmABOKfABZyxN9I9tNM8d9ytpAESIAESIAEok+AAnb0 Gcf1HfBLEgTrwuIS2e4Iz5sccRoC9dZtO53Hc3crIbqwqERKS/dmWSO7uhJCtNGrvdnalUqoRrmi 4lLZ7Qjfu5TwvUt+dsTtTZu2KnF7d2GRlDrZ27iGQQIkQAIkEHsCtse0n1h68sknexrWv39/lflq /9vdsmVL+frrr2XdunUCsdq2g+jTp49bD8TTfv36iZ3xiwI4DlsIZJ5B5DazrAMJrG7F1oZpNwJ7 lMzMXxe0NTOqcRmE1mB2JChz1FFH4U0F+hrpQLYw2Oiw26yP4x0LGJplkcm8zz77mEWqbZsscdK0 HsG+OaGB7OA2bdooj2Zk3euA9/mHH34o7du314fcd3wmHn74YXcf3tSmyO6eMDaaNm3q8cO222SL 13gK4J577jFq8G5++eWXngPoQ30HvhOw1YF9CjIrkSWOV05OTn03jfcnARKIUwIQsBHxaIMUp8jY LBIgARIggRQikJFCfWVXDQIQokudLOtiZ6EuWIFAyEYGdiQzo50qndgrdStLkZIqJ7O73HnEuYEj GKQ7f8RlS47zKHlWJj+GxtBwkwRIgASiRgACsbkwYyCx9JRTTvG0AddgET9k4f75z39WGdPaCuTQ Qw/1lDV3zj77bMHCfjpgdYEM3t/97ndK7IafNWwU8Ng0bCH8wsyohjgKy4hAgQxlUww98cQT3aLI 6rUXPcRJCLPhxsqVK8MtGnY5W9A322xXgmxrHWBx0UUX6d2A79pXVRdYs2aNmPcwrTrgfw3xefLk ybq4eocdCERnvwA/8zPVtWvXatnTftftu+++7nVokxm2DQyyryECBwpzDPH5MictAl0TzeMYp5kz Zzr2auXqcw3blGTzuo4mP9ZNAqlKgAJ2qo48+00CJEACJBAOASqH4VBKgjIQpvFC9rP2rt6bTV2p hOtYdFG3AcnX8MfG/YudbG0I2FnZWZKTlan8O+kJGYvR4D1IgARSkUC4YikycfPz8+X000/3+EVD HIZoikzrv/zlLzJmzJigGaVYLBHZuRAgzYA3Nl5YZPC2224TCN2BwsyohuAdLOz+mf7eS5curXap vWBhtQLWAdMH3DpV611brDXbbFaKTOePP/7YPQRP8VDZ1yi8adMm9xpsmNdAeDYzurHIpl/AS3vo 0KF+p9Q4micgJteUK8R4M8yscBwP9vnAoqAml2OPPdasKqbbmECZPn26WgAVv8sMGjRIvUxv8pg2 iDcjARJIKAJ6wpEZ2Ak1bGwsCZAACZBAjAjQQiRGoOvrNhCNYfkBT+tdji+18qZ2bDzgTQ3rEGRd 10egXToLvNDxyka70D7Yj+A4zjNIgARIgAQiS8AWS/38r/UdYT0B0ddPNIboCX/kTp06qTL6Gr93 CK0vvviiwAbCDlhFYGFHLJhoZvHqcrBhMAXWUOKkLVKb9h8//fSTrrbW7xD2Ix1m9jDqNtts3svm 061bN/N0wG1Ys5gB2xcdWFwwnLAX6zSv+fHHH83dWm3bXM2scGT9B8rOx82wMKIZgSYAzDLR2P7q q6/UQo1giuzym266SS10SvE6GrRZJwkkJwEtYMfbQrTJSZu9IgESIAESSDQCzMBOtBGrQXuRrVVe 7izIWFamPKyReW37l9aguqgVhYiOtqGtWXh3srGznWzsrKwsSU/nHEvUwLNiEiCBlCNgi6V+C/KZ UA4//HDl4YuM2Pvvv9+zACLKQVSFDQkysyFmB4qBAwcKfLRfeuklue+++8QUKHHN22+/rWxF4HcN OxEdtsAaagFH22KjY8eOuipZu3atu42NP/3pT+qpH8/BEDvBBP8Ql/qexmSt6UmOTGSzzeZFpjUK jgcqZ16DbQirZmBhRx22v7g+jkxsZF1rb2uMFyYbkDFvBxb51AEhevTo0Xo37HczYxuLl5l12guF 2pXWZFLGvjYS+5WVlTJ79mxZtGiRqg4LNeIphWCWJ5G4L+sgARJIPgLaQoQCdvKNLXtEAiRAAiRQ dwIUsOvOMO5qcLObHTG4xMm0LnF8rusr07omcNBuZXHiCNmlWRnSMLdKCdmZv3hk01qkJjRZlgRI gAS8BPBv7LvvvuseDCaWuoV+2TjuuONk1qxZcvPNN6vF9B577DFPkcsuu0yWLFniOWbvYLFEbamA dqAuCNc6VqxYIffee69aQFAf++yzz/Smeg+UnYyTyLCGx7YOCInmzw0Io2bceuutaqLUPBbr7VWr VnksWuw2m+3ZsGGDuSvh2JlgQUyMmw5kwZsLHNoTGhCgFy5cKJgoQKa2FrBxPawxHnjgAV2V+24+ 6o5M6TvvvNM9V5sN2wYGn71gYXqko1yXLl2CFY/oOTwhgOx0eHjDE/6SSy4RjCGDBEiABGpDAF75 +Lll/rtam3p4DQmQAAmQAAkkIwGmtybZqEKohjVIgbNY1c5dBY4lR0lCiNfmMCgh21nsceeu3bKr oFDKnEWQcAwvBgmQAAmQQO0IwOph9+7d7sVYyM+0N0DGFzyvkWWM7N7nn3/eLas3Dj74YHn00Uc9 QjHOQTjGIomIN954Q3r16iXdu3eXAw88UIl76oTxn549e8pbb72lxHDjsJgZ1DhuipkQV3V2mnmN 3sbikmbAAsUM+1rbksMsi+0K52fpddddJ3/4wx+UsI72RjrM/qHuYGIt2mPG9u3bzV3f7RdeeMEz 5hdccIEr6iNz2OQNqw6IwTrLHXYtphgMoXbXrl3V7qMfeceJb7/9ttp5+wC4X3HFFYotBHFMXJhh Z1QHm7TAdaZHeqBFSc36I7UNdjfccIP6fHfo0EHuuusuiteRgst6SCBFCeBnMkRsTD4WFhamKAV2 mwRIgARIgAT8CVDA9ueSsEfhdb11207nD9YiZ6HEyoTtBxoOMb6oqEQ2/7xdCgqL49L+JKEBs/Ek QAIpRcAWS03bBoDAH84Q5WDbAQuHQPYSKHvKKaeobFNs69C2DxDJIWjDcgJipW1hocsjywzi8AEH HKAPiZ1xbfobQxAPFMgk/te//uU5bdt9mPdBQftenoudnSeeeEL+/ve/y+TJk9WilcF42NeGu2+L tVo89rvezJzGeVv4ta9Bxvn111/vOXzeeee5+99//727jQ14mrdr185zbPz48Z59WGXYgUkKHfAr 37hxo971fccCoNOmTVNscc8dO3Z4ypkLOOIpgbZt23rOmztYNNG0VsGkTLQDohKeFJgxY4ZjfVau rHFuueUW2X///aN9a9ZPAiSQAgT0ZOuWLVtSoLfsIgmQAAmQAAmET4ACdvis4rYkMpORdb11+07Z vmOn8pKO28bWomHo3y4nm3z7zl177VCYiV0LiryEBEgg1Ql8/PHHHgS2wAvLCAiGOl555ZWgGWCm lzKuadGihbrU9sKeP3++rrLaO0RzU1i26zTFSTNb3KwIgvvgwYPNQ2rbztw99dRTPWVuvPHGgBO9 sDgZO3asWx5cxo0b5+5HaiPYopP2PWy/cliwlJSU2MXUPiaw4cNsZpnD3sL0sLb9xW1eqGjo0KGe +uGDbgey9s0IZiGCyYBnn33WLY4FQm3R2fRH91tA1L3Y2fj888/NXYn2Ao74PMI7HeywUCMy9JHV np6e7mkHd0iABEigtgT0Uy20EaktQV5HAiRAAiSQrAQoYCf4yGJRxmLH53r79t3O42Ylzh/jVQne I//mVzmidUlJmezYWeBkYxdJRYJnl/v3kkdJgARIIHoEwhFLjzzySLcByPAdMGCAaw3innA2YNtw 2223uYdgNQEBHGEvLvj4449XywRGOfz8mjJlipg+zP369cMpN2AbouP111+X1atX6131iPWTTz6p LE9MoRYFcJ0WAfQFsHmAxYQO9G/UqFGe/uGxbVhlIMPcDAi3TZo0MQ/VeRuWIKb9hV+bzZtgguD8 8893D6HPY8aM8ViE4CSsYvr06aO8rHVh1H3PPffoXfVuT2j4ZbjjUfbhw4e714GZKTDjxFlnneWe xwZYTZ061WP7haxs2IYg494MCNpmwMccWdw6glmqoIydFe8nwuu66vKOCYG5c+cq33ZYtyBTHtn5 5oRAXerntSRAAiSgCeifXVzIURPhOwmQAAmQAAnsJcBFHBP4kwCxGgs0FhQUqcUPE7grYTUdliJl zsKUyg/b2c7Ly5UMZj2FxY6FSIAEUpuAn1hqW1KAEDyJTREbiyzm5eXJ7373O+VpnZOTI7B4gJhs xu233+7uojwW/IO4qgP+wLDkQBY0vJZhvfDyyy9Xs8G46qqr9CXqHTYnCxYscI9BhNZZueYCkMiQ hsCshWxbgNYVwLrCFGphO4K+oDwEdfh3mz7huA5tv/jii3UVEXv/+uuvPXUFarNZ6O6775ZXX33V bePMmTOVXQsmGvbZZx9ZuXKl2BnvYAOG9qKP+fn5btUQYjFufjF69Gh55pln3FOPPPKIZyKgadOm yhfdzFjHOII1BGg8Bo822wGbGVsAtm1uQmVU23Yj9uSJfc/a7ENQh9COhRozMzNlxIgR0rdv39pU xWtIgARIICQBbSGCRWIZJEACJEACJEB86d/gAABAAElEQVQCvxKggP0ri4TaqqioVOJ1oeMRXeqI uqkU5eUVUrin2OnyHsnNzZWsTH6MU2n82VcSIIGaE7DF0pNPPtm3Eoi78DkeNmyY5zxEXlu0RgGI oyjfv39/T/lLL71U2Tsgm1kHhMA5c+boXc87MrjnzZtXzYP51ltv9QjYuMgUrrEPERT1YmFIHViA 0C9Q1u4f2uW3YCWuRzbxxIkT/aqq8zHb/zqUWIsbwqMa1i7IetZCO0R7iMV+gckCiMcHHXSQ53Sp M/ltZr7bNh5mYUw6wOZFTw5ANIcHtOn5jMmKb775Rgm9+lrYbZgWMPo46nrqqaeqZbnjvJ1RbU6m 6OvNd4jgOk466SR3gUp9rK7veGoBkzHghXbDsxvvDBIgARKIFgEtYNMDO1qEWS8JkAAJkECiEqCF SAKOHDKvYRtSUFDs/FFVloA9qHuTIeBjYcdC2Ik428jKZpAACZAACfgTWLVqledEIIEXheB7DBuK YMItBFFkosKD2Bav9Y2QzQ27ibPPPlsfqvYOQRmL+n300UdyyCGHVDvfrVs3WbJkSTUBFgVhiwG/ ZVwL72zTeiLYYojoH9o9cODAavfTBy688EJB9lswBrpsbd+RLW1GsDab5SDUQxiGJzcmEPwCXJFd joU0bfEa5WHVYUawzwP8nW3/74ULF5qXK+H4vvvuU9nfgYR4tBUTEt9++62bRe+pxNmBCK4DQrH2 VdfHzPeCggLPmB9//PHm6TptY6FGfH4xAQPxGp9xPGVA8To01muvvVZ5g4cuyRIkQAJ+BPS/e/TA 9qPDYyRAAiRAAqlMoIEj/CWl8ldeXiHwTU6mUNYZTp8gXu/eXShlTh9TPRo0aCCNG+VJw4Y5yk4E +4y9BLKzMomCBEiABOpEAJ7Qa9euVfYJ8DGGhcfhhx9ezY4i1E127Nih6oEwDuHxsMMOE2Rdw5Ik nCgrK5Ply5fL999/r6w+0A74HcPSoS6BPkE0RXYxBNZDDz1UCb51rbcubarJtUVFRfLll18qsR3b bdu2Ve2HPUx9/jyEOI9JE0wqwM8VkxMQf+uzTeFyxeQAPLzhdQ1bGoj3mBBgkAAJkECsCGDRXSzS i4nIQAsYx6otvA8JkAAJkAAJxAsBCtjxMhIh2qHEa6cMMoGwkCEEesavBJo2bSQNc3MkPS0tIf5A /rXl0duigB09tqyZBEiABEgguQjAAx02NvAQx+9cyP4fP358xBfvTC5q7A0JkEA0CNx4441qEhCT adpSJBr3YZ0kQAIkQAIkkEgEaB6cQKOFRa+2bd8tlZWVCdTq2DR1pyPqpzVIc0TsbArYsUHOu5AA CZAACZBAUhDYtm2byrpG5jgsU4YMGaJsQxIhYzwpBoCdIAES8BDAkyt4imX9+vUUsD1kuEMCJEAC JJDKBChgJ8DoIxOo3PF53rGjgOJ1gPECo90FhUq8pogdABIPkwAJkAAJkAAJeAhgocYnnnhCYMEC mxNYhsCihkECJEAC9UVAZ11DwMbiygwSIAESIAESIAERCtgJ8CmocDKuC50/rMqcDGxGYAJYzLHI 8WtNT28gOdnZgQvyDAmQAAmQAAmQQEoTgL/s9OnTJT8/X3Ho3bu3jBw5ss6+6ikN1ek8POWRue63 KGuqs2H/SSBcAlrA5kKO4RJjORIgARIggVQgQAE7zkcZdiElJWVOZlCJ8mSM8+bWa/OQhV1aWqYW c8QjwJkZ/HjX64Dw5iRAAiRAAiQQhwRWr14tU6ZMUYtM5uXlydixY+Xoo4+Ow5YmXpP+/ve/q0bP mDEj8RrPFpNAnBCggB0nA8FmkAAJkAAJxBUBKnxxNRzexihBtqzCySoucaxDqrwnuedLoKpqjyP4 l0p6Rrqk56U7vtgNfMvxIAmQAAmQAAmQQGoRwEKNCxculDlz5ihLNmQJT5gwQZo3b55aINhbEiCB uCZAATuuh4eNIwESIAESqCcCFLDrCXw4t4V1SGlpqcoqDqc8y+wlAL/wkuJSycnKkqysTGIhARIg ARIgARJIcQL2Qo3Dhw+Xfv36SVpaWoqTYfdJgATijQAm1XJzc4UWIvE2MmwPCZAACZBAfRKggF2f 9IPcW9thwBKDUXMC5RV7M9czMjMEOdjwY2SQAAmQAAmQAAmkHoFly5bJtGnT1EKN++23n0yaNIkL Nabex4A9JoGEIYCJNWRhr127Vnbs2CFNmzZNmLazoSRAAiRAAiQQLQIUsKNFto71YkFCeF+XlVfU sabUvByWK8VOFnZubrZkZTILOzU/Bew1CZAACZBAKhModxa/fvrpp2Xx4sUKw0knnSSjR4+WnJyc VMbCvpMACSQAAS1gr1+/ngJ2AowXm0gCJEACJBB9AhSwo8+4VncodHyvS8vKa3UtL9pLABYsBYWF 0qxJE2Zg80NBAiRAAiRAAilEAAs1PvjggwLxJzs7Wy655BKBgM0gARIggUQgQB/sRBgltpEESIAE SCCWBChgx5J2mPeC/UVZWZlaYCjMS1jMhwBsWEpKyqU8r0JlYdNGxAcSD5EACZAACZBAEhHAz/5X XnnFs1Dj5ZdfLvvvv38S9ZJdIQESSHYCFLCTfYTZPxIgARIggZoSoIBdU2IxKF/sZF/DQoRRdwKw EiksKpb0RumSkZ5e9wpZAwmQAAmQAAmQQFwS2Llzp8q6Xr58uXryatCgQYIXF2qMy+Fio0iABIIQ oIAdBA5PkQAJkAAJpCQBCthxNOzIGqqqqlLe15WO/QUjMgTghd3Q8btMa5Dm/BHLxRwjQ5W1kAAJ kAAJkED8EMBCjY899pjs2rVL9t13X5k4caIccsgh8dNAtoQESIAEakCgdevWqvSWLVtqcBWLkgAJ kAAJkEDyEqCAHWdjW+b4XsNCxNGyGREigCxscM3IyHAEbGZhRwgrqyEBEiABEiCBeidgL9R49NFH y9ixYyUvL6/e28YGkAAJkEBtCbRs2VI9SQIffwYJkAAJkAAJkIAIBew4+RQg+xqvIsc+pKqK6nWk h6WktEyyc7IkfU8aF3SMNFzWRwIkQAIkQAL1QGDdunUyefJkd6HG0aNHy8knn1wPLeEtSYAESCCy BGB91Lx5c0EGdqGzKD0n5SLLl7WRAAmQAAkkHgEK2HE0ZrAPKXUyhSFkMyJLABnY8BXPysyMbMWs jQRIgARIgARIIOYE3nzzTZk5c6YgA7tDhw5y5ZVXcqHGmI8Cb0gCJBBNAvDBhoCNFwXsaJJm3SRA AiRAAolAgAJ2nIwSROuS0nKB3QUj8gSqHL5l5RWSlVUpmY6VCIMESIAESIAESCDxCGChxunTpws8 rxH9+/eXoUOHSjoXak68wWSLSYAEghJo0aKFOv/zzz9Lu3btgpblSRIgARIgARJIdgJU8uJkhGEb UlxSwuzrKI5HWVmZVGRnUcCOImNWTQIkQAIkQALRIvDVV1/Jgw8+qBZqbNKkiYwbN06OOOKIaN2O 9ZIACZBAvRJABjYCAjaDBEiABEiABFKdAAXsOPkEVO1x7EOcDGxG9AhUlFdKpWMjgmz3Bg0aRO9G rJkESIAESIAESCBiBCorK2X27NmyaNEiVScWarzkkksEIjaDBEiABJKVQOvWrVXXKGAn6wizXyRA AiRAAjUhQAG7JrSiVBbiNf44gwc2I3oEKh2+4LzHyXZvkE4BO3qkWTMJkAAJkAAJRIYAFmpE1vWa NWsk01nHYsSIEdK3b9/IVM5aIk5gxowZEa+TFZJAqhJo06aN6vr69etTFQH7TQLVCBQVFUl+fr46 npWVxcWbqxHiARJIXgIUsONgbGEfAn9mRvQJVDgCNl5Z6WnRvxnvQAIkQAIkQAIkUGsC5kKNBxxw gFqoEe8MEiABEkgFAtoDO1UF7CeffFLuvPNOd6jnzp0r3bp1c/drsnHBBRfIJ5984l7y7LPPylFH HeXuR2Jj2LBh7voMJ5xwgqD9Zlx//fUyb948dQg/yxYvXmyertE2JnVPP/1095p77rlHBgwY4O5H cwMcmzVrJh07dozmbQLWjUnta6+9Vp3HIs6Y3I5kvPTSS3LIIYdEssp6rasu44WFso888kipqIic VnXzzTertUsiAQVrotx7772qqgxnnbOPP/5YGjZsGImqWUecEqCAHQcDU+Us3FhWRvuQWAxFuWMh UlHpLOYokf1BF4u28x4kQAIkQAIkkAoECgsL5eGHH3aFgN69e8vIkSMj/kdqKrBkH0mABBKXQF5e nuTm5srWrVvVk7ppaamVgIP+f/fdd+4A/ve//62VgP3WW2/JM88849bTo0ePiK+fAKEPoriOk08+ WW+67xCvdX+0PYx7soYbYKHrwqUQlKMd27ZtkxtvvFGmTZsmr776ar0I2Nu3b5fbbrvN7SpE/Ecf fdTdj8TG/vvvH4lq6r2OSIzXihUrBK9IRqNGjSJWHRId9PcA9VK8jhjauK2IAnYcDE2V48lc4Qir jOgTgIVIpTNhwCABEiABEiABEog/AvhDZOrUqYI/UuFxDa9reF4zSIAESCAVCWAhx7Vr1yoRWy/q mCoc7EV6P/30U7n44otr1H387XfNNdd4rrn77rslPT3dc6yuO19//bWnimOOOcazv3PnTldowwlk aNclkGlqRvfu3c3diG8vXLhQkGG+e/duVTcmAeoj7r//frcNYAw7kUhG586dpWnTppGssl7qitR4 LVu2LOLtj+Rn55133nHbd9ppp7nb3EheAhSw63lssaAgXhRVYzMQYA2vcS7kGBvevAsJkAAJkAAJ hEMAIsP8+fPVCz+j8Zj4+PHjuVBjOPBYhgRIIGkJaAEbCzmmmoBtW1R89NFHNR5nZEV/8cUX7nVn nnmm4KmeSIct9P3mN7/x3OKbb77x7NsCt+dkGDsffvihW6pLly7SuHFjdz8aGw888IArHMP+ZL/9 9ovGbYLWuXnzZvnb3/7mlrnjjjuUtcVxxx3nHrM3HnvsMc/4X3755XL44Yfbxdz99u3bu9uJvBGp 8UICASxbAsW7774rc+bMcU9DRB40aJC7b2/A7qVVq1b24Vrtw1oJnwkdwT4HugzfE58ABew4GEMI qlzAMTYDAb9xvBgkQAIkQAIkQALxQQB/gEyePFkt1IisuCFDhkj//v2lQQMuuBwfIxR+KyDSYNyS yT80/N6zJAlEngCsJmAXAQE71QKetr/97W/lgw8+UF2HaAsvXhwPJ4qLi+W6667zFL3rrrs8+5Ha sTOibZEUgrbpZa79zWtzfzD497//7V5a12xut6IAG9Apli5d6p7t2bOnux3LjX/84x/u7U499VTp 06ePux9oA1Yn5gQGsvEPPvjgQMWT4ngkxwvJBMF850tKSjwC9oUXXljjpyRqCx1PZJhR10khsy5u xy+B8P71j9/2J3zL9kBQpaVFTMdRTRg4zNMzIvvoWEw7wZuRAAmQAAmQQBIQwB/FWISntLRUZXRN mjRJsCgTIzEJ/P3vf1cNnzFjRmJ2gK0mgTgjoL2STfEzzpoY1eYce+yxroCNG3377bfStWvXsO75 yCOPyP/+9z+3LCypbFsS92QdN8yMaAhpOTk5nhohukcq89TO5gajaMbKlSvd7GvcJ9r38+vLunXr BNYvOm6//Xa9GfAdT3MhQ1gHPJIPOuggvZu077Ecr//85z8ejpG0B/FU7LNjLsqK01hskpH8BChg 1/MYw/+aGcGxHQTwrnRmktOd/zFIgARIgARIgARiTwALNT7xxBOSn5+vbo5Hui+44IJqf/THvmW8 IwmQAAnEDwFtG5KqArYtSn355ZdhCdhYR+Gvf/2rZyBN+wnPiV924FP9008/SUFBgcAmA4JzOF7Z 8GE2LUQikRGNtnz//fdq8eK2bdt6fJnNe6Hptl2JX9+QjQ4RGE88wf7jwAMPlOzsbL+i1Y7Zma41 WZcCntmrV69Wk9SdOnWqtS0Y7EJ04AmtE088Ue8GfP/hhx88wjuuqe1CqPhMYPJEswt40wieKCsr U/73eszwOcjKygp5h7qMV8jKrQKmBzVOHXbYYVaJ4LtILMTnA0+YIDO+efPmwS8wzpriOSYm6vJU g1GtY+1bqZ6WwPcF//7CViacfwfMOvy20VfUiRcWXUW94X4H/epL1WNpqdrxeOm344AtjiNzvDQn JdoB2piRZZAACZAACZAACcSeABZq/NOf/qTE67y8PPnDH/6gFmu0M9Zi3zLekQRIgATii4AWsFPR QgQjYS9OaItzgUYLT4PoBQdR5sYbb1SitF0eIvHEiROVhzQW74NdAgRoCLzImoY4PG/evKB2n6ZF Beq3rQw2bNigRHdkjuP1/PPP281Q+xDOnnvuOVUGbYFQjP5D7IK11o8//qjK2XYlgTLSIeLfc889 qi8NGzYUCMiwZME7ft6ij/fdd5/vQog7duxw23zZZZd52guPY9wTbcNktB24L+w+UD+8uZH1Dibo E46BN+oPN1atWiXTpk1zi996663udrAN+7MSamKhvLxc9UmPEz4bmEjA7yjI3sZ4QERGv5H9i4kE XRbv2uomUJtuu+02t3ygtkCjwOcN9UHcNMcM+7Dnevzxx5WVjnmfuoyXWU9NtvG5Nj2o8dmCx3Wo 2LJli7L26dWrlxKG4XV//PHHKwF6//33V8kM5pMTfvVBDH7//ffdU4EmNDC5hMVHzXE66aSTBJMD dqA+fLbxvcc4Y4wgqmMf22+88YZ9SbV9PFGo73XppZeq82gD/j1q166dW++hhx6qvoP4LuD7wgif ADOww2cVlZLQUSmmRgVt4Eod6JSvA+PhGRIgARIgARKIBgH8wYE/zLBYI373wR9iEyZMqFHGTTTa xTpJgARIIF4JICMRvvKpKmDbfvrhLOS4du1aJRjpMYX4CO9jOyBqQ1QMFhApzz33XIE1AvyU/RYv hEe5GbaNAupYsWKFW2SfffZxt/UGxheZxbY4rc9joTzcHyKp6UftZ1eCa1566SUZOHCgvtz3HSIh uEBcw89lUwT87LPPPG02K4BoiRe4YhLajIULF8pZZ51lHvJs455YFBD9mT17tmDRv1BhjtH5558v Rx11VKhL1HnbYiJUpvrXX3/t8cvGhALaZ2e8Y8ICYiT6YI4rJhqCBcZEl/ezsoGo+vvf/16Nc6B6 kAAAYRQTD0uWLHE/j7Udr0D3Cee4zcX8/AS6/u2331aCsil8m2Vx/JlnnpGXX35Z7r///oB+2nZ2 vd8CjpjAGjBggMcvHk9WzJ0715PJjnJ4AhD3DBSwCPrd734nY8aMkSlTpggmhPzi9ddfd8cYgj6+ zyNGjBCMm1/gu4CJFnjaQyhnhCbADOzQjKJbAmIqVGxGzAiANpnHDDdvRAIkQAIkQAKybds2ufnm m5WADRzIcoF4UJPHRYmRBEiABFKNACwP8O8kLCD8sl2TnQcyhU1BGEIPJkODhW0dcuedd3qsK/B3 ILJqTWEU9UGQxb0gPNlCNcS68847T9kL2Pe2RefOnTt7ioQSuCG4IyvUrgdtMD2bIbT169fPI6ii rXa88MILvuJ1ly5d5OSTT/bUiWshGp5xxhnK2kDXhaznUGEvoogsaVu8BlOIwJgEgHioA/eEdVgo axwIvk8++aS+TP72t7+526E2TKEfZc3Pkd+1piAL9liQ0Dymr7n88suVtYQ9Xva46/J4x2KHZnm/ cbv22muridcYMwigdnlwufjii93vQm3Gy2xfbbbtz7X95IFdJ34HxJjb4jWusz8f+KyPGjVKIHj7 hX1ve2yR1Xz66acrYVhfjzIYA9PmBJ8/LAhqi9cYy8GDB6vvi74e78iwvuWWW8xDnu333nvP3Yc1 CvziTfEa32d8J8zApBSevGCER4ACdnicolYKucAUU6OG17di8A71i4/vhTxIAiRAAiRAAiRQYwL4 IxKWIVhYCH8U3nTTTUoIqK0XZY0bwAtIgARIIIEJ6IUc8eh9KobtuYzsy0Dx+eefewRPCEbImjQD 2caTJ082DwkWnkUWNIQxWAls2rRJ3nzzTY+QDXEKWbp2mKIVxDA7k9Jc4BEiLmwSdCDLd/jw4R6R C0IbBMqNGzcKhElYh2gB07ZWsLOKcR5CuxkQRtG35cuXq0UNUSfq13WiLARDU8TDgpf4m9kWcCHg 4TheeKJKByYWrrjiCr2r3jFJDZuJxYsXq6zXNWvWyAMPPOAp88c//tGzb++YgjUEW1N8tMua+xUV FWKOC3730N8js5y5bWb3Q2TVgvOZZ54pzz77rMq4hqh95ZVXqsvM+iHS2+Nu1g32ZthiLyxAkNmr A+IpeOG6f/3rX+ozic+mOaGBjPxFixapS2o6Xvo+dXk3P9eoJ1hm/FtvvVVt8uHee+9VyQ3gjqxo CL6YbDID311M3tmhx0YfN62G8FnH5IrZvrPPPlvg192yZUt9idKDkHltfsaRGQ9BGX7nyLDHIqCw koHFiQ48sQAvfju0x7w+jn8/EBCsn376aeWtj+8e/h23//2xBXldB9+rE6CAXZ1JTI84//ZTwI4p cd6MBEiABEiABEggFgSQcYQ/VvGIJDwAkWF21113KeuQWNyf9yABEiCBZCCghTcIJKkYtjBme06b TK6//npzV+6++26PXQCETbsMFhSGOGovqAYR7LrrrvPUB4HcDDxdZArqtrex7dWLn4Nm/POf//R4 JyNDGlmnEGphHYPAYm+wJoAIa4ctYJuLHaIsBFf83LUXuEP9pmCKsqaQh32E7SNtZ7qiDH6+Q0A1 A5MEyFQ1LUYwaQ3bMJMp7CJMfmYdaI/pFw5BPNywJxrANVT4eVgjS/+VV15RHuQQlSFEgp097qbA 6XcfW6C0x82+N8YGPsxmgD24mmEuZIjj4YyXeX1ttzGBYXpQQ6Q1xXWzXlij2JMbEOVhX2ParmCh RHw2MOGiA58Nv+xkU5yG6Kw/Zzqj2vwsjx8/Xk222NY9+N5j4kUHxhD12lYo8Oi2udvfHdRhs8cx TFQgeQPfQ91GLMSJNpmZ2BDvGeERoIAdHqeolcLPJf3DKWo3YcXVCez9faD6cR4hARIgARIgARKo MwH8Mo4/RPLz85UogF/W8eJCjXVGywpIgARSjIBeyDGU3UKyYjnyyCM9XYPfr18g0xdZqTogSMGu ygwIiRCxdSD7GVYFgcIWPrUIpcvbbfHLFkd2sw5YCugoKCgQ2FGYgUzfJk2amIfUNu4LCwY7TNsK CMnIMtXCGATFhx56yL7E3bdFVFvgQ0E70/Xwww93r9cbEPNMERrCNbycA4UpUKIMsl39Ak9r6YDw HUgg1WXMd1tM9PNINsuDnT0xgkzrP//5z+L3tFiocTfrxraZ3Y19O5McE/5mLFiwwNx1tyHWmmNu C+PhjJdbWR02MN7m5xoTM36ccAskMpg2GrCagS1KoDAnOFDGHhcI4qbgrwVnWPHg+4qnC3QgWxrf ATs7Hm2HjZAOTA5BpM7NzdWHPO/I3DY/t34Z2LbnOirABI35xIWuFCK2Gfvuu6+5y+0gBOgUHgRO LE5BvKaAHQvSv94DvNMacO7mVyLcIgESIAESIIHIEEC2GRZxwqOXeDS6Q4cO6nFbv1/gI3NH1kIC JEACyU1AC9h4ND4VAz7AZvgJRfjZA6sqM2BRYP+dDSFT+wVDQLazrs3rsQ37ADPsrFhbQLQzlG0h 1RS4kdlrBgQ1nW1vHtfb9sJ/sK1A1qoOLCynrSogiIJJoMXmcI2d0Y+FCe0wfaQxIWALb7jHww8/ 7F4G8dxvwUy3gLPRtGlT5Yet7VAgbsKmwwwIlPhdQoedNa+PB3q3hVxbrLevs0VS9MO0L7HL259B e9zt8qbdCKxbMjMzPUXszH1M+MM6AxMc9hjCmgIZ0OCoJyt0ZaHGS5er67uZ4Yy6Ak0Q4N+s//f/ /p97OwjFwSaMUBD9QuayHkNTkMZ5O7seZfE97dWrl+jPFMphMmjIkCHYrBaYIDAFeHxmTXuRahc4 B8zJG7QNn31TtDezwnH9o48+KgcffLBfVcoeyLx/oHK+F6f4QQrY9fwBcOTraj9Y67lJSX97Zr0n /RCzgyRAAiRAAvVAAI/UTp06VT0uCdEAmW/nnHOO5w/semgWb0kCJEACCU1AC9ip6oHduHFjlXWq szhN6wI9sJg0NUU1/OwxPZ51OfMdGcfIvEU2KRZ927Vrl+zcuVP5RUN4gzhtWgzgWlvANi0cICa2 b9/evIUrwumDplcvsjPNCCX82tmhwWwr8LRTeXm58lFGX9Av9G/r1q1qEb1vvvlG2ZKY97fbDoHf FHZtkRXXQrQzRcOuXbt6rjHrN7eRcaqvg9ezHX/5y1/cQ5iYCCbsuwWNDVPIxWHbhsYoqjbtiYj7 7rvPY29hlzczqjHufuK/vgbs9WcXx3TGsD6Pd/TPFG1xDJ8HiOjoP4RsbQNjfwZRFhHOeO0tWff/ 2rwCTRDY5dCncJ7EQ/KDFrD1pIxutV0nJlXwXTcXh8R9AonXqAdWMGYccsghHs9s85zexjiage+S /rcZYrb9mbvooovM4p5t83uFE926dfOc505gAhSwA7OJzZkGtBCJDWjzLpg2YJAACZAACZAACUSK AIQDPBYKMQB/mE6cOJFe15GCy3pIgARSmoAWrlI1AxuDD+sNLQIic/Gnn36SAw88UH0ukG1sLwZo LwZnfoAgVj/++OPywgsvhBStzOsgVOqx0MfNzFos4GiHKWohkxxiPAI2Juaiif379w8p0tpCr5nN re+LeuEZjJdZvz4f7N226LBFNtP+RNcDb24zIGj7Cd1mGXvbziLGgn/mxIGZwWtf67eP30PMyQz0 y/Ra9rvGnIjA+WAWKDhvjjsy4YOFnYUPodovMF6nn366ZwIAn3V4f+N19dVXKxuLQE+0hTNefvet zTHzc43rA2WgY6LEjEsvvdTcDbhtPh1g22toYVtfDH9pO2AHAv97M0Nal8HnQy+wqI+FGm9dznw3 7YTwVIeZUQ2LlGBPd9h9MCe2zHtwuzoB+ihUZxLTI5BS0yinxpg5Jw1iCpw3IwESIAESSFoCyPCC EIBHtfFHAf6ghucgslkYJEACJEACdScAoQS+yMj4Q6ZfKoadQWtmZeJRfZ3NCzbwSw70M+jHH3+U Qw89VAne9iP/objaAjVENjPr07ZRwM9H06vXFHY3bdrkuV2gDFazkG1nYjOB5US/fv2Uv3BNxWvc x/ZltjNd7fvhGvCsa5iLU8Ia44YbbnCrhO+3znJ1D4bYsP2JbR9zv8vNcUJmuz1RYV5jj7ufsG+W t8VeP44oD2F6yZIl1RbE1HVNnjxZ2Vw89thj+pDnPZzx8lxQyx1MkpgCPsYvUIa8afeBcrYY7dcE fAZMMV5PVOmyNk993HzHUxVYDNUvTHHc73y4x0xrF5t9KEHcnDABlwMOOCDc26Z8OWZg1/NHIM15 xDYtnfnAsRyGtLQGku6sgswgARIgARIgARKoPQEs1Pjggw8KFhaDnyMyTvr27Vv7CnklCZAACZCA LwEIRHiEfePGjQHFIt8Lk+SgnaH41VdfyRlnnKFsMZCdagYW3vMLLPLWs2dPj+iMcrAfQFYsrBkg JLVp00Zld2/YsMHj7WtbP9iZtbYIbYp3uI8pcKNuM0x/XfO4ua0z0HHMtispLS2Vc889t1pmKbK+ scAe7EEgBKJv+Cyhn+aijfjZbS90Z9tkdOrUyWyO2jYXb4QQN3r06GplQh0whX0I7zo7FX3EQoo1 DTP7GteGEpgxMWT2Y+DAgUFvadfvlwlvVmBm+6JPHTt2NE97tiHw/vOf/1QZ1/AWx5NtZmYvCo8d O1aN/7BhwzzXhjNengtquWN/rk855ZSANZkTTfZ3ONBFEJjNPpsCtm2TouuAhzoyrk0rjkceeUT6 9Omji7jveHrDjKFDh6rvh3ks1DZ8us2wPdH97qvLQ6A3nzAIZXWkr+P7XgIUsOv5k9AAYqqz+AK8 IvFhZkSfAB4lAXcGCZAACZAACZBAzQng9xUsPmUu1Dhu3DhmkNQcJa8gARIggbAI6IxQTBgGynYM q6IELWQKU+iCztB84IEHPGLXbbfdFnAxNqzRYGZqI6P6ySefDOhf/OKLL3pomQI0TthZl3ZmrX3e tFmw7WBCZRlD0MOidDrsbHBYebz66qv6tPp5DI/tQNnHtvgOkdsOU2SDeO9nx2D2A1nvwaxb7Prt fSz8bC7WiIkJWyi0r/HbN4VcnDe5+5W3WcDGI1h89tlnntP2uJsnIZaaHMHZXljULK+34al91113 KcsQCNnYNkVdiNgQbU0+5n0CjZeuvy7v9uc6kCUK7rFy5Ur3VmZb3YM+G88//7znKCaddOjvvd7H O37/vP/++9UEDKx49OKfsAjC993OboaFkBmXXXaZWgDSPFbTbfNpDkwa4YmZQIHkD3Msg3nZB6oj lY8zDbWeRx//gOGFrGBG9AmAM374+v0Ajv7deQcSIAESIAESSGwCyAC84447ZPbs2YI/NvHHwi23 3FLtD4TE7iVbTwIkQALxRUALnKZgGF8tjG5rkN2Ll47PP/9cLbwIyyodOH/VVVfp3Wrvr732mnus c+fOAq/lYIvvIYPTDDvDOj8/3z0Nkcz2JtaZxLqQmWVtezLDxztY2EK9LXqZ4iXqQdsCidc4/69/ /Qtvbtj1YcFQU+y3xXt9oTmZ8u233+rDAd9R5xVXXCHXXXedoE8rVqxwy0K41PsYy/Hjx7vnarJh W0wcccQRQS+3BVl7ssS+2BS80U793bTLYd9+GsDmfMEFFyjPcIj/f/jDH6pVgc8JLFVgi4LPrA4I oGY7wh0vfX1d3m1e9vciUN1YRDRU4PdKLKBpBmxxdNj3xvcfWer66QHbY/uJJ57Ql7rvejJQHzA/ 5/qY/Q6rPHxub7/9djXpZZ4vKyvzWAX5TQaZ5c1xw/Fw+Zl1pPI2M7DjYPQhYKenpzl/CKamp1ks h2CveM3Jglgy571IgARIgASSgwAe2YZlCP4IQXYJsl5C/WGYHD1nL8IlMGPGjHCLshwJkEANCGiR LFUFbKDCo/ZYnA2BTEz8PDIzGZH9ay6spgr+8h8IfFocxSHYbeAp6ECB7GuzPMRDvQAjroEXuSmU +olWpq8yslTNRd1s4RyCPCxR/AJtt4VQ27Zi8eLF7qW4l5116p50NpABCpsKM+yf5XaWcSCRzbR3 gB84LG5atmxpVu3ZxmKbZia5ZgS/cLOPN910U8Cx9FRo7SC71rRaQfa16VVsFVe7ph8xRH9YogWL cG0xkJVrTxTYHGE9odtrWrrY98fnBRnp5oKFmDDo1auXKhrueNn11mbf/Nzj+mAZ6FhAU/vEQ7iF f7YWm/3ubT8lMXjwYE82s5ldDzsWe4FPiN04rv9deOihh1RWvzmm5qQL2oAxMLna7cLvvqYwDrud iy++2C1mfh5wMJRljT2xFeoJAfdG3FAEmIEdBx8EZAUH+yLHQROTpgmYKAj2y0rSdJQdIQESIAES IIEIEcAfljNnzlSZ1xCvkZ2Ex1ntP3gjdDtWQwIkQAIkYBGggF3dCgIipw4IzCNHjtS71d5NAQsn 4RkdKJCZfc4553hO26IUPJO1SIaCdoZyYWGha3OC87bAbWdrI+sUQrUdyO70y0Q+8sgjPUVNcTxY 39asWaMys822Q/CzRWcI6mYEykq27TaCWYhgEUJTvD7ttNNE+4rjdwztQw3x/ZJLLjFvH/a2LeTa Gc9+FWkRHed0e/zK6WNacMZ+oKe64ZMN8dUOW+w1ueKaYFns5hMIqFf/m4DtcMcLZesSWKzb9ACH QG0/TWDWb9p/QMh++umnzdOebQjj11xzjefYrbfe6tk3nzTws0nJysryfF9wT1jemXHwwQd7Jnhg P2L7Yuvy8OPGZJcZtue+nVEdSpA27UZC8TPvy+29BChgx8EnAf/wZWUyGT4WQ5GRke5MFgSebY9F G3gPEiABEiABEkgUAvjlHZ6UixYtUllJo0aNUo/+BvP3S5S+sZ0kQAIkkCgEdNYgPLBTNWzR1uQA AThYQhh+ZkEs0oHytvCEc1hE0G8x4g4dOuhL1bttZWBn1tqCon0ef/8PHz7crRNCG7I8YdOlAxPG AwYMENsTGAKvLWaa9SM7/bHHHtPVuO8QRyGk25YJXbt2dcvoDXuhPgjpfnHWWWd5DkMMRBatubYX srJhv2BbZEDQRsA+BZYiOmBLlpOTo3dr9G6PSzB/ZlQM4VJnCGPfzmzHMTtM9vAeR0a7juLiYmUx gfGwOeM6/T3W5e1EAAi+33//vT7tvuN3sYkTJ7r72DAXvwx3vDwV1GIHViZmBLOpQTk7sxkWP5gg MgNPM8Dn217MEIkSsFbRgadPTKaBJifM7Ghci7rNgPuBmVGNc7///e8946jXesE9zAkL1G332c6o 9vs+6fsjA90U4U2BX5fhe3ACVE2D84nJWWRgZzoCNowtuIxjdJFnpGdIRjoF7OhSZu0kQAIkQALJ QODNN99UmdfIwMYfzFdeeaUnayUZ+sg+kAAJkEAiEMACaLm5ucqiAYJPoMzPROhLbdtoi326Hixo iPUYQgXEtJtvvtkthkzJiy66SPlgQ6DFRK3fInG4AKKXGbZQ2r17d/N0NXHcFJh1QWSXYqFFHQsW LFCL8p199tnKokQvRqfP63c/0eu8884T07Mbi/zNnTtXIOAi+xzWC+Yij7ouvPs9nYwMcjMOPfRQ 9dQVxGhk4LZp00adxufy0UcfFdxPB0RK+BIjKx1Z5X73hYinxxP+wlpExiSDLXrqesN5Ny0mUD5U Nqw9iRGqPOqEcIyx0oHJDWSTI95++219WFlZYOJEi66nnHKKe05vgNWsWbNckRQcOnXqpMYN/CB6 YyFE24rk6quv9ojh4Y6Xvm9t383sa9RhP5lg1wvfd9jG3HPPPeoUMv8xQYTvKz5TeFoAzEy7HhSE UGxPeNhj5fedwrWoF2K4zqzH77KYvDHFcGR6IxtcZ/2jXxhHLIzZvHlz9X0xhWvUi++l38SQaakC wRtZ4IHim2++8ZwKNcHiKcwdRYACdhx8EJxlHNUPDmQGl1dUxkGLkrMJ6b/Yh6TiL3zJOaLsFQmQ AAmQQDQIIANs+vTp7mOivXv3Vo9m249gR+PerJMESIAESMCfACwD1q5dK1u3bvXYB/iXTr6j8Fs2 /W11D7U4pvcDveNpInhomyL1U089Va047Ejg529mhNrCkyladenSxeOPjQpNX2XsQ5S0A2ItspAh RpqBLHAzIBDD61fbfviJXvg5PWHCBOULrq+FcIeXGeAH73CI2/o+Jg9dFn037T5wXJezF8EbM2aM gI/OqEZZiH+2AIjjmAwHcy3mFhQUqKe8cA6BRaKDZdLvLRX4v++8847nJMYmWMD/WAfY2Jn2+pz5 jokHU8DGOVO4xj7E+Tlz5og52eAn9sJXHXXhnB5fXI+sXjuzF8cRWEjQzFjHsZqMF8rXNmo6QYD7 oL0bNmxQCRH6vpicCTRBAxuaa6+9NuSkkW3HouvGOyZUtICNffxOe++992JTBfzG8W8BhHQ9wYAT fpMtOH7ZZZepz7f9ezA+v/p7gXJmVjz27QhXhLev4/6vBGgh8iuLetvCjG5aA8dGJMhsTb01Lolu jCz3DEfEZpAACZAACZAACfgTwGI1+MMB2ShYDAsZMPCitH9p97+aR1OdAESMYB6eqc6H/SeBuhDQ nrepupAj/ma2PYphwxGO7QO4wyf6/fffr5bZqccE2a7w1Yb9B+5jCsWwcDAjlGhlLuyGjFO/LGfU py0VTFsKfR+IklicEV7KprgZqL9TpkxRGaIQYu3AsREjRiihGV7hps0B6oa3sRmXX365LycwMf22 cQ3GBZYsEARNZmZ9uD+EX/x80NnKOI9Mbd03iM3IJK9toB6dyY06YPUQSgw3JyaQyW9n2vu1Bb7V S5Ys8VjS6HIYRwiwEHpbtWrlaU+gcUPGMERUTMT4jR3qxnGIrfg83HDDDdWewKjJeOm21ubd/Fzj ep1FH6wu/P6IDHII+oE+H7geXu8YD4jzfuNg/m4BzpgMCRS2h72dwY7r0HZ4pmPiJ1DgO4ixxCSS 32KgP/74o+fSYP1DQXtSx/RA91TEnYAEGjj+LknpWlFeXiFVCdQ1PApWXFIm27bv9HhGBRw5nqgx gcaN8pw/xhtKZop4YGdnBV9BucYAeQEJkAAJkEDSEqisrJTZs2erR6jRSfxSjYwTPErJIIFwCcAj HYHsRQYJkEBkCeCR99dee01lF+oM1sjeIXVq27ZtmxKT4DcMMQwWIPbCirGkAS0AdgYQxpHUBq9q 2HPUJiBGw3YCYhkEXAh1yPb2EwVD1b99+3ZZtWqV7NixQ9mGtGvXzlfIM+vBvXENxGR4PsO6AWKj 3/2RMa1tHGAJEY4gat6rPrdhOwNBF58hjB+yt5EVXJcJf3gkY7IEvtrw58bvYGCiLVtC9bc24xWq zkifx2cDwi+yspGBDm4dO3ZUSRORvle49SGTGgkcYI7fh/GZxZMYSORgxBcBCthxMh6YR6isrJLN P2+TCudLw4gsAfiM79usieTmZPv+8Izs3eKjNgrY8TEObAUJkAAJxDsB/JGJR3/XrFmjssSGDBmi Mn38/tiM976wffVLgAJ2/fLn3ZObAB5vRybhoEGD6pSpmtyU2DsSIAESIIFkJUAP7DgaWYisOTlZ ziM8JQmVPR5HCAM2JduZyebijQHx8AQJkAAJkECKEnj33XdVtiwW0kEW2qRJk8LygExRXOw2CZAA CdQbAWSzItavX19vbeCNSYAESIAESKC+CFDAri/y1n11llNubrayEnHSsa0S3K0LgezsLCerLC1l sq/rworXkgAJkAAJJD8BrFj/8MMPuws14nHl0aNHOxPpOcnfefaQBEiABBKQAAXsBBw0NpkESIAE SCBiBChgRwxlZCrKckzus5zFBkscH6UktSePDKga1JLheF7DTiMtjQs41gAbi5IACZAACSQpAfhi Tp06VeCVCH+/iy66SPltJml32S0SIAESSAoC8MNF0lOqLuKYFIPITpAACZAACdSaAAXsWqOL/IX4 hQQrFCMLu9wx8K+oYBZ2XSk3cCrIa5jjLGCRzuzrusLk9SRAAiRAAglNAAvTzJ8/X70wSY5FarD6 OhdqTOhhZeNJgARShACScfDv9ZYtWwRP0XCBsRQZeHaTBEiABEhAEaCAHYcfBPhgF5eUqhVQnb8v GXUggAmBhrk5zL6uA0NeSgIkQAIkkPgEzIUaMWGORcDw4tNJiT+27AEJkEDqEPi///s/JWBDxKaA nTrjzp6SAAmQAAmIUMCOw09BRnqGwLO5vJxZ2HUZHr0oZrrDU3uM16U+XhucwKZNm+Sll14KXijM s82aNYur1dU//PBD+fLLL93W9+/fX7QPoXswjA0surNw4UK3ZIsWLeScc85x98PZeO211+Snn35y i/72t7+VLl26uPvcIAESIAGbwNKlS2X69OmChRr33XdfmThxosq+tstxnwRIgARIIL4J4HdHBGxE 2rVrF9+NZetIgARIgARIIIIEKGBHEGYkq2qY49iIKAG7OJLVplRdmAhotE+eI16nVLfrrbMlJSUR 820vLo6vzz3aY3rSo6+1CZtRbfpZVFTkaUtt6qhN23kNCZBA4hHAvzkQrvPz81XjsVAj/K6ZtZd4 Y8kWkwAJkAAItGnTRoFAUgSDBEiABEiABFKJAAXsOB1tWF/k/JKFXVZWHqetjN9mpaenKS9xeF8z SIAESIAESCDVCGChxmnTpgmsQ7Kzs+WSSy7hQo2p9iFgf0mABJKOgH4CcN26dUnXN3aIBEiABEiA BIIRoIAdjE49noPlRXZWlpRlVziZ2OVOxmU9NiYBb52ZkSG5ThY7rUPqb/DAvmnTprVqwH777Ver 63gRCZAACaQ6gaqqKpk3b567UGOHDh3kyiuvlP333z/V0bD/JEACJJDwBOCBjYAHNoMESIAESIAE UokABew4Hm1kEassbCcDu6S0LI5bGl9Ny8x0xGtn4Ua8M+qPQMOGDWXw4MH11wDemQRIgARSjMC2 bdtk6tSpsnLlStVz+PUPHTpU8FQXgwRIgARIIPEJmB7Yid8b9oAESIAESIAEwidAhS98VjEviQzW rMxMadgwRyoqK6WiojLmbUi0GyrrECfzOicni9nXiTZ4bC8JkAAJkECtCWChxieeeELgk4+FGi+7 7DI54ogjal0fLyQBEiABEog/AljDIDc3V7Zu3Sp44iYtLS3+GskWkQAJkAAJkEAUCFDAjgLUSFap s7AhYBcUFDm/qNBLJBBfCP45js9nbm62wEKEkToEKp3vx/fffy94P+igg5wJjJwadx5/BGzcuFH5 xTZv3lwOPPDAGtcRrxdgITd4Je7atUvZCLRq1apOEzz4o+mnn36SZs2aSdu2betUV2lpqXzzzTfS uHFjxTyD3914/RixXXFKwF6o8eijj5axY8dyocY4HS82iwRIgATqSgA2ImvXrlUitrYUqWudvJ4E SIAESIAE4p0AVb54HyGnfXj0N69hrsrALi4udfywKWL7DVtWVqayDkHWOiP5CDz11FPKDx4969at mxx77LGycOFC+fnnn93jOPf++++rbBT4aJ911lkhM1MgWr/33nuyfft2XO4GJkSQ4XLSSSe5xxJp Y8eOHfLOO+8oQd7v3wz8u9KoUSPp2bOntGzZMmTXPvroI/n6668FgrMdEJ0hip9xxhkBxewPPvhA XY9rsxx/f9gavPDCC7J7925PdRi3AQMGhBw3z0XcIYEUJbB69WqZMmWK+p5nOj/7RowYIX379k1R Guw2CZAACaQGASzkCAF7/fr1QgE7NcacvSQBEiABEhChgJ0AnwIIaRmO2NSk8T6OUAcrkQqK2Na4 QYzbJy/XycDODCigWZdwN8EIlJWVuZ/7goICmTVrlnpU3q8bOpsaovfZZ58t2i/QLvvpp5/Kxx9/ bB9W+xB98Sj+G2+8obKDfQvF6UGI13PnzlWPlgZqIrLVUe6ll15SNgPHH3+8b9Hi4mJ5+eWXVVnf As5B/JuEjGzwPvPMM30XiwNLjAsCYzlnzhzf8cOEBP7NY5AACQQmgH+fXnnlFfU9wnf5gAMOUAs1 4p1BAvVJYMaMGfV5e96bBFKCAARsBATs7t27p0Sf2UkSIAESIAESoGlWgnwGtIi9b7NGXJzQGjOw adrE8YNzvK/pA2fBSdLdVatW+YqfdnfLy8uVAG0fx/6XX34ZULy2BVRYbyRKQMyaN2+eKxbrduO7 gUxpu284/8UXX0hhYaEu6r6D3zPPPOMrXvt91yBML1iwQGWDupX4bEDIhqDtF/Du9WujX1keI4FU JICFGu+44w6ZPXu2sk3CQo233367ErFTkQf7TAIkQAKpRkBnXWPSn0ECJEACJEACqUKAGdgJNtKw x2jcKE927S50shjLE6z1kW9uWhrE68ZO5jUXbYw83brVCJGyNsIv7CXC9bCG0NmlSxc56qij1DXw Ul62bJlHHEW2Njyb4WutA22DJYYZyOLv1auX8tDGcWS1IPsaomwiBRggI1pHtuML36dPH2nTpo0+ JD/88IMsWbJEiV/64Icffii9e/fWu+r99ddf95TBwU6dOskpp5ziThatXLlS3n33XU+5t956S4YP H+6pK9AORPUmTZqozwoEc4wlgwRIwJ8A/n2bNm2a+jcO35tx48ZxoUZ/VDxKAiRAAklLgAJ20g4t O0YCJEACJBCEAAXsIHDi7ZTOSoRYi8eHCwqKpTTBxLVIMlW2Ifs0VIs2pjlCpuYTyXuwrtoTgPXE s88+W+MKIF6PHDky5HUY7wsuuEAaNmzoloWY3blzZ5k5c6ZHeP7ss8884iz8mJGprAMiKjyZzbrw eOaFF16oshwDZQvr6+Pp/ccff/Q0Z/DgwZ5+4SQWuoSwD9FaB7wUzdiyZYsS8c1jyPQ0hXCcg6AN 24LnnnvOZY66v/rqKzn88MPNy6ttw3sbftc64K8NwZ1BAiTgJYDJnaeffloWL16sTmAdgPHjx6vJ H29J7pEACZAACSQ7AQrYyT7C7B8JkAAJkIAfAVqI+FGJ82N4dD/HEXkaNXLEW8c2IxUjMzPDyURv KHm5OZLu8KB4nTyfAr8FB/1617Vr12rCLMpBjD7yyCM9l9j2GGvWrPGchxhkitf6JCZJkL2cSIGJ AzM2bdpk7rrbRxxxhDRr1kz1Gx7hHTp0cM9hAwtAmtGxY8dq4rU+j8UuTzvtNL2r3pEpGizAFoK4 GRSvTRrcJoG9BLBQ4/XXX6/Ea3xv8HTDddddR/GaHxASIAESSFECeKoQf/vQQiRFPwDsNgmQAAmk KAFmYCfowKenQ8T+xTbD+QWmpKTUXeAuQbsUVrOdrkpWVqY0dASzhrnZgj/mGalJ4MQTTwzY8bZt 23osQsxsa704o74YE0LHHHOM3q32jizhRo0aye7du6udi8cDyIbevn2727Q333xTidPoY9OmTd3j 2EB2dqCw+3vyyScHKqqOg3mmY3GETFFEKOsV2B/w+6tQ8T8k4EvAb6FGWIbYk02+F/MgCdQTgRdf fFEJawMHDqynFvC2JJD8BPC7K34/3bBhg1qnxP79LvkJsIckQAIkQAKpSIACdgKPOn55yXbEXMzA O7qulJSWVVu4LYG7V63p8LveK17nqMxzil/VEMXVAWRCH3zwwTVuExbxCxX47AeLffbZx3Mantc6 THEXx5A9HCrwqKYt6Ia6pr7OI7MaC1SaAVsRvDAm4ItsatitBPsOaSFa1/Pvf/9bbwZ8NycKwByv QGPVuHHjgPXwBAmkOoGdO3fKgw8+KMuXL1co4E8PayVMEjFIIJ4JYCFfBAXseB4lti0ZCMDqDgI2 1myhgJ0MI8o+kAAJkAAJhCJAATsUoTg/r0Xs9Cb7SFpBkcrEhojkWGQnVcAmJCc3S/Icv2OI2PC8 ZsQ3AdhB9OzZMyqNhBAbLIKd37Fjh+fScARsZAtHImzB2BTWw63fFpZtgTgvL09giWKL2Kgfiztu 3rxZvfLz81Vm+SGHHCI9evTw3B73sK1cYGNQ08AfVcgI9wtzUU2/8zxGAqlKAP7xEK+xCC6+z2PH jpWjjz46VXGw3yRAAiRAAj4E6IPtA4WHSIAESIAEkppAcBUoqbuePJ1DBnYmMiubNpai4hLZ7QjZ ZWXVBahE7TEEusaN8xzLEMfvmpYhiTqMEW13XT4HdiZ1MLFbNzpSmS2wIjHDzFg2jwfbxkKHZvh5 d59wwgnKH3fp0qVBn8oAi08++US+++47Offcc93szo0bN5q3qPU2FoKkgF1rfLwwxQhg4giLoS5a tEj1HJNLEyZMEE72pNgHgd0lARIggTAIUMAOAxKLkAAJkAAJJBUBCthJNZyOHYKzqGOWs8BhQVGx FBWVOBmXlQnbQ1iG5Dj9adIoTwnXXKgxYYcyrhpuC77ISg4VdtZzqPKBztuZ3LURsO322nYp+t6w CMELmdgQqGGdEijjG5meM2fOlFGjRqnLbaEd373aWH4Es4OxM8d1u/lOAqlIYN26dTJ58mT1KDgm 6IYMGSL9+vULaMGTiozYZxIgARIggV8JUMD+lQW3SIAESIAEUoMABewkG2cITfjjt1FeQ8cfO0tl ZBc7WdlVVYnjKYI+ZGdnOnYhuaoPWLASQQE7yT6s9dQdO5uxuLg4ZEu2bdsWskw4BezMcYjRwXyi /eq0RW9bFLevgZ0IXghkREPQhlhWVFTkKQqRfs2aNdKuXbtqXorIUoegxiABEog8ASy0igkkfAf3 228/mTRpEhdqjDxm1kgCJEACSUVAC9j43Y5BAiRAAiRAAqlAgAJ2Eo6yFrGzlZi9d6HHkpKyuF/k ce8ijVmSk52lFqfMcDLJ4X3NIIFIEmjWrJmnupKSEs++34698KNfmXCPYRE2M6P722+/lcMOOyys y7/4hEY0FAAAQABJREFU4guPNzWymO0M7LKyMlm7dq3ABgRiWOfOnd26W7RoIb169VL7sA+ZP3++ 45v/a/+//vprJWCjAERrne2N9sITO9Qk0g8//CBbt24V3KdVq1bOExQ57r25QQIk4CWAhRqnT58u y5YtUydOOukkGT16NL83XkzcIwESIAES8CEAARu/l2G9EQYJkAAJkAAJpAIBCthJPMoQtzKdX2wy nIxsiGaw44C4Ver4Y0OYipeFHpFhneVki+c4WddoZ2ZGunpsOpRYlsRDx65FkQA+V7AR0RnIyGj+ +OOP5ZhjjvG9K8TbSHlC4waw1di0aZN7r48++ihsAfvTTz91r8MGFngzA2L0008/7R7CwoumgO2e cDZgE4JFNt944w33sLnAJcTngoIC9xyyRE8//XR3397Avy2LFy/2COyDBg1SYrZdlvskkOoEzIUa seDtJZdcIhCwGSRAAiRAAiQQDgH8LounCpGBXVhYWO13wnDqYBkSIAESIAESSCQCTG9NpNGqRVsh 1kHIzs7KlH3ycp1szYbSyHnlOb/0wKZD23PUouo6XbI32zrDaUeO0548t03IvobNAsXrOuHlxSEI tG/f3lMCmc324oi6gC3K6uO1fbcFZdz3+eefF9saxKwfIvrLL79crY0HHXSQWUxlbpqLUkKkh4gd KGxh3vQH79q1q+cy1LN582bPMXPn1Vdf9YjXEMCRic0gARL4lQC+57ALueOOOwTe81io8a677qJ4 /SsibpEACZAACYRJgDYiYYJiMRIgARIggaQgwAzspBjG8DuR5WQ441WRU+lkY5erbGy8w4dXv6KV mQ0hHa/09AZOlnWGI6D/YhXibDOSjwCygV977bVadwwZ0bZfda0rsy488cQT1cKG2iIDotKsWbOk f//+sv/++6vSsMyAaGyLvFZVNd6FXch///tfNwMcFcCiZMaMGdKmTRs5+OCDVZY2xGdkasOS46ef flLfT/NmyNo87rjjzENqu2XLlvK///3PPf7WW2/JCSecILYgDS9sCPdmQEzT0b17d1m+fLknC/vF F1+UI488Uo499lhdTInqr7/+uierHCft+7kXcIMEUpQAJoCwUCO85jFJe8455wieUsDPRQYJkAAJ kAAJ1JSAThT4+eefXQu4mtbB8iRAAiRAAiSQKASoHCbKSEW4nbAVychNl1zHVqTSEa9hK1KOV3mF VDhi3h5n0Uf1P7X2o7P1yxqQEPUChc6aboACzh/nzv+xod7hZZ3pZIFnOb7WWc57RnqG80e7KoBC jCQkAFEYXsy1Dfg3R0vAhmB08skny5IlS9zmQcxesGCB8n5GFrPpDe0WitDGGWecofynze8TJpAg VOMVKvBd6927t28x9Ou5555zBW/U+8EHH8iHH37oTBplq2uQ9W1nfCP72hSwUbBPnz4C0dqMzz77 TD7//HO3Lj9OTZs2ld/85jfmZdwmgZQmgCc5kHmN7x5shMaNG8dJnpT+RLDzJEACJFB3AjoDGwI2 gwRIgARIgASSnQAF7GQf4RD9gxCmxWxHzValyysqlUc2hOzKSicz23lXorajXWN/D7K1HSFbi28Q pxs4LwjSe+tzth2BHPYkyn/bEQMzHF9rLXCHaBJPk0BMCHTq1EmKi4uVsGveEEK2zszWx7HwYyQX ckTGzMCBA2XhwoWeBR31/YK9Q1wfMGBAQHsOeFvDq9rOfodgrX2/7frhPY9MUDswidC3b18l9JtM 8N33E65xPRaVHDx4sF0V90kgJQnAl/Thhx92F2o8+uijZezYsfQqTclPAztNAiRAApElQAE7sjxZ GwmQAAmQQHwToIAd3+NTL63LcITn9HTH3uOXbOu9b3szr9V/92562+YkU/+aT713Z+++zsT2Fude 8hGAd3kkw64PEyB60iTUZIh9PtAj+kcccYTKhnzvvfdk9+7d1ZqPeuBZDa9peDzrMH2m9bGavkMc vvDCCwX3hqUAFkEMFljotGPHjnL88cerxU6DlW3btq2cd9558vbbb8u2bdsCFkU/DjjgAJVpHYhR hw4d1GOpixYtkg0bNrhjYFcKERw8A2Ve2/VHgqHdBu6TQDwRWLFihTz00ENq8gtPP4wcOVJ69eoV T01kW0iABEiABBKYQOvWrVXr169fn8C9YNNJgARIgARIIDwCDRxByE+ODO/qOC4FKwxkCTNIIFUJ YOFORvgEIPRCSMY7xCYI1xCZYxU7duwQ/AGCTO+CggJlZQJbD9hx1MVORVu5rFu3Tq1Sj8UVDzzw QGnfvn2tvHch9K/+ZUFHTDLA5qVVq1YBM8JjxY/3IYF4IQDbnnnz5rk2Qe3atZOrr746pv+exAsL tiP1CIwaNUp1Gus6MEiABKJLAE/5jBkzRv0Odv/990f3ZqydBEiABEiABOqZADOw63kAeHsSIIH4 IABfWrzqKyBU4xXpgMiMLGq8IhGwKOnWrVskqmIdJJB0BLBQI7KuV65cqfrWr18/GTZsmPNUU2Sf UEk6cOwQCZAACZBAjQnk5eVJbm6uWvAbk6f20241rpAXkAAJkAAJkEAcE6CAHceDw6aRAAmQAAmQ AAkkBoGlS5fK9OnT1UKNjRs3lgkTJsjhhx+eGI1nK0kgQgSwGDBFtAjBZDUkEAYB+GBj0fStW7eK 9sQO4zIWIQESIAESIIGEI0ABO+GGjA0mARIgARIgARKIFwJY0BTCdX5+vmpSjx491CPdTZo0iZcm sh0kEDMC1113XczuxRuRAAmIEq0hYP/8888UsPmBIAESIAESSGoCFLCTenjZORIgARIgARIggWgR +O6772TatGkC6xAsZDpixAjp27dvtG7HekmABEiABEjAQ0BnXUPAZpAACZAACZBAMhOggJ3Mo8u+ kQAJkAAJkAAJRJyAvVBj69at1UKNbdq0ifi9WCEJkAAJkAAJBCKAnz8ILATOIAESIAESIIFkJkAB O5lHl30jARIgARIgARKIKIFt27bJ1KlTPQs1DhkyRGVgR/RGrIwESIAESIAEQhCggB0CEE+TAAmQ AAkkDQEK2EkzlOwICZAACZAACZBANAksW7ZMWYYUFRUJF2qMJmnWTQIkQAIkEA4BWoiEQ4llSIAE SIAEkoEABexkGEX2gQRIgARIgARIIGoEsFDjrFmzZPHixeoeXbt2lQkTJggXaowaclacoARefPFF adCggQwcODBBe8Bmk0BiEWjevLn6ztEDO7HGja0lARIgARKoOQEK2DVnVucrSkpLpaysXMorKqW8 3Hkvr5CKykqpdF5VVXvU+549e+p8H/wBkZWVKY33yZPGjfZR2zgWzwEWBYVFsmt3gRQ5gsEeh0ck Ij09XdLT0yQtLU0ynO2MzAzJyshwHvnGK1Oys7Mk3TnHIAESIAESIAGTwOrVq2XKlClqoUb8LDn/ /PPlrLPOUoKBWY7bJEACIgsWLFAYKGDz00ACsSGAv20gYm/ZskUKCwslLy8vNjfmXUiABEiABEgg xgQoYEcZeIUjUpeWlUlxCUTrMilzBNq92+VSUVGhxOvyCmw7AnaVI2BX7lFidqSale0I2I0a5UmT Ro1kn7xcyWvY0HnlSkZGelz88Q2hvsp5FRUVSyFehcWyq6BAdjoCdnGxI2BHRr9W4nSaI2BDpIYA sVe41iJ2puRkZyuBH7xycrLVK9MRuBkkQAIkQAKpSQA/n1555RWZM2eOmliGzyiyrtu3b5+aQNhr EiABEiCBuCQAGxEI2HhRwI7LIWKjSIAESIAEIkCACl0EINpVVFVVOaJ1uZQ6mdaFRSVKkN29u1CK HEEW4nUksqvtewbaV+3YukO2btspuTlZ0qxJE2natLHk5eaorOMsJ/sYYi5m72MV4APBvszJPkcm eklpmWzfsdN57ZJChxEy0SMdlc498SoPULHOVgeXRr9krEPoz3GYZWdlO3wa/H/2zgVOrvMs76/2 ftOudnWXbEuJY9mJFRJEgNrQEJBNiW0wNuBEtTHY/OQixSCL0iRQCqQpxeUSWakihai1QTgoFkWO iS0CtimkrZ2mrYDEl1iyY11X0t7vO5fdVb/nk8/67Gj2PrNzzsz/DcOcOXPOd/l/49XMc97zvJEQ /CcZPrshAAEIQCCHBHp7e23Pnj328ssv+1Y3b95s9957r79jJ4fd0BQEIAABCEBg3gR0gfXVV1+1 s2fP2rp16+bdHg1AAAIQgAAEokgAATtHqxJkEqedICuRuqu7x9qdcNw3MOgzrXPUzZyb0fiGhpPu 0WatF9qtzmUZNzUttiVNjU6wrXMibZXPyi5bdMlmIxBs52M5oj4DLhedeCx7FFmlSLiWTUhvb7/1 9A1Yv2Ok4woZ6j/phHQ9upyQrkzthvo6W7Z0iS1tabY6J2xL7JcNyXyYFHKO9A0BCEAAAtMTUKHG L3zhC9bX12d17q6l7du326ZNm6Y/kSMgAAEIQAACBSAgAVvR2tpagN7pEgIQgAAEILAwBBCwc8A5 8K0eHB62M60X7LwTiGUVEtWQWKtMZz1az7f77GKJtcrOrqurceJ2jcvWdpYa1RJsndWI+58P9zTR QVuv3hae/db4S+fl7UTrSxnWSWcHknLi+bD1ONFagnXa2adEOTR22ZjoceJ0q61cttTWrl5hTY2L Lwn9C5ixHmVOjA0CEIBAsRBQTYoDBw5MKNS4bds2a2lpKZYpMg8IQAACEChCArIQUVDIsQgXlylB AAIQgMA4AQTscRRz3+jr67fTZ89ba1uHKzroMo0LnE0825lIgO9zFicDA0NOoZZVhoTqRV7YrpQn tPOHrnSe2YF/dHmZCiKW+/c11zGXVT2iebvn0dFL9iDy/dZDr10e9lte1peeC51tPVs+msM5t7Zt nd22tLnJrly7ylYsQ9CYLUeOhwAEIBBVArrteteuXT57jUKNUV0lxgUBCEAAAtkIBAK2PLAJCEAA AhCAQLESQMCex8rKKqT1fJudd+KmChDmw7t5HsOb9aleeA+L786KOu28qoed9YhsMwJhW2nYPiv7 rQRsCdSX/u+tZ9eGROq4CflTAdN8VHSzo6vHF5fsdM/rr1rrxP0qz2aqc3kPAhCAAASiS+DZZ5+1 xx9/3BVVTtuKFSvsoYcesvXr10d3wIwMAhCAAAQgECKwbNky/4oM7BAUNiEAAQhAoOgIIGDPcUnb O7q8l7QKDy50YcY5DnlOp0m4jVvG9JwmOsOTdJGi3/l3qzimfLyvWLPS+WQ3uwx1/lOaIUIOgwAE IBAJAirUuH//fpPnteKGG26wrVu3uuK9NZEYH4OAAAQgAAEIzIRAfX291dbWWmdnp6s5NObuki2b yWkcAwEIQAACEIgVAVS3WSyXhFx5W8vj+kJ7l/U665CoeznPYnocOkMC+hzIHqWjK+XXf3AoYauW L/X+4XxhnCFEDoMABCBQQAIvvfSS7dmzZ7xQ4/3332833nhjAUdE1xCAAAQgAIG5E1AhxzfeeMPO nz9vQVHHubfGmRCAAAQgAIHoEUDAnuGaKPNWNiEX2jvtrLMNka0GmckzhFekhzkd2xelTCZTlnKP VSuXWePiBl/ksUinzLQgAAEIxJqA/i0/ePCgHTlyxM/jmmuusR07dlCoMdaryuAhAAEIQCAQsFtb WxGw+ThAAAIQgEBREkDAnsGy6gev7CJaXeb1ydPn/K1ZMziNQ0qEgCxkTp+7YOnREW8p0rR4MSJ2 iaw904QABOJDQIUalXV98uRJX7vgjjvusDvvvJNbreOzhIwUAhCAAAQmIRAUcsQHexJA7IYABCAA gdgTQMCeZgklXvf1D9rp1vN2pvXCNEfzdqkS0Oek9VybLwKm4o7NTY1WXl5eqjiYNwQgAIFIEcgs 1Lh9+3bbsGFDpMbIYCAAAQhAAAJzJYCAPVdynAcBCEAAAnEhgIA9zUp19/bZm6daTUUbCQhMRcA5 ilhbR7clk2m75up1tmJZy1SH8x4EIAABCOSZwODgoO3bt49CjXnmTPMQgAAEIFBYAgjYheVP7xCA AAQgkH8CCNhTMO7s7vGWIZ1dPVMcxVsQmEigb2DQjr9x0mVgl/lMbAo7TuTDKwhAAAILQeDYsWO2 e/du6+7uturqatu6dSuFGhcCPH1AAAIQgMCCEwgEbHlgExCAAAQgAIFiJICAPcmq9vT2XxKvnYg9 NjY2yVHshsDlBFTcs995pr/2+gl7z4arbXFDvRezLz+SPRCAAAQgkGsCsnR68skn/UN/j1Wo8WMf +5itWLEi113RHgQgkEHg2muvxVc+gwkvIbAQBJYuXWq1tbV2/vx5/9uVBJqFoE4fEIAABCCwkAQQ sDNo68duwhXlO3mm1ZSBPTIymnEELyEwPQFd9OjtG7DX3zxlG65ebw31tfygmx4bR0AAAhCYF4G2 tjbbtWvXeKFGFWmkUOO8kHIyBGZF4JOf/OSsjudgCEAgNwQkWCsL+9SpU9bZ2em3c9MyrUAAAhCA AASiQQABO7QOEq8lWJ86e97aO7tdQb6R0LtsQmB2BPR56nCfo/q6WrvqitVWV1tjixYtml0jHA0B CEAAAjMi8MILL9j+/ftdHYKkNTc3244dOyjUOCNyHAQBCEAAAsVAIBCw29vbEbCLYUGZAwQgAAEI TCCAgB3CIcG6o6vbzrResFQqHXqHTQjMjcCYE7HPXWj34vXK5UutpqZ6bg1xFgQgAAEIZCWQSCS8 cP3iiy/69zdt2mTbtm2z+vr6rMezEwIQgAAEIFCMBAIfbAnYBAQgAAEIQKDYCCBgv7Wi8sxU8b3v nDxryVSq2NaZ+RSQQCKZstbz7VZZUWErVy6zcneLHwEBCEAAAvMnoEKNe/fuNVmHqFDjfffdZx/8 4Afn3zAtQAACEIAABGJGAAE7ZgvGcCEAAQhAYFYEELAdLlk9DA0n7EJ7p/X1D8wKIAdDYCYEunv7 rK6uxhY3Ntji+rqZnMIxEIAABCAwCQHVGTh8+PB4ocZ169bZzp07KdQ4CS92QwACEIBA8RMIBOzW 1tbinywzhAAEIACBkiOAgO2WXAJ2T++Atw4puU8AE14wAp1dPd5KZPE71y1Yn3QEAQhAoNgIdHV1 2e7du+348eN+arfccott2bLFysvLi22qzAcCsSPw5S9/2df7uP3222M3dgYMgbgTWLNmjZ8CAnbc V5LxQwACEIBANgII2I5KT1+/877uMtmIEBDIF4Gk81Xv7umzru5ea2luylc3tAsBCECgaAkcPXrU W4YMDQ35Qo3yut64cWPRzpeJQSBuBJ566ik/ZATsuK0c4y0GAqtWrfIXkPDALobVZA4QgAAEIJBJ oOQFbInWPT391ulERQIC+SSgTP9+57N+vq3Dmpc0+i+Y+eyPtiEAAQgUCwEVavziF79ozz//vJ8S hRqLZWWZBwQgAAEI5IpAmauzs3TpUuvo6LDBwUGKGecKLO1AAAIQgEAkCJS8gN0/MOQzsFMuO5aA QL4J6HPW0zfghezGxQ357o72IQABCMSewIkTJ+yRRx7xhRorKyvtnnvusZtvvjn282ICEIAABCAA gVwTkA+2BGw96uvrc9087UEAAhCAAAQKRqCkBewxlxGrzGsKNxbs81dyHV90Mx52mYTn2zoNAbvk lp8JQwACsyCgu1aefvppO3TokLf4krenCjWuXbt2Fq1wKAQgAAEIQKB0CCxbtsxPVjYiKnBMQAAC EIAABIqFQEkL2IlE0nqd//WweyYgsFAElIXd3tFl669cY5WVFViJLBR4+oEABGJDoLe31/bs2WMv v/yyH7MKNX7kIx9xfzMrYzMHBgoBCEAAAhBYaALKwFZQyHGhydMfBCAAAQjkm0BJC9hd3T02ODRs yvIiILBQBPR500WTrp5eW7602crLyxeqa/qBAAQgEHkCKtT4hS98wfr6+qyxsdEefPBBCjVGftUY IAQgAAEIRIFAIGCfPXs2CsNhDBCAAAQgAIGcEShZAVsiYpezD5GdAwGBhSYwOjY6XsxRBVcWLVq0 0EOgPwhAAAKRIpBOp+3AgQPjhRqvv/56L143NTVFapwMBgIQgAAEIBBVArLbUsgDm4AABCAAAQgU E4GSFbCHh5M24LKvR0ZGi2k9mUtMCIyOjllbR7dd885Rq+KW+JisGsOEAATyRUCZYrt27fK3PAeF Gm+66SYu7uULOO1CAAIQgEBREggEbHlgExCAAAQgAIFiIlCyAnZnV7fJi5iAQKEIjIyMWE9vvxew 5YVNQAACECg1Arob6rnnnrPHH3/clIFNocZS+wQwXwhAAAIQyCWB+vp6q62ttc7OThsbGzPd6UlA AAIQgAAEioFAyapm3U44TKdHimENmUOMCfT2DVjzkkZfzDHG02DoEIAABGZNILNQ4+bNm+3ee++l UOOsSXICBCAAAQhA4G0C8sE+deqUF7EDT+y332ULAhCAAAQgEE8CJSdgK9tLj/6BQRsZxT4knh/b 4hl1X38/NjbFs5zMBAIQmCGBl156yfbs2eMLNdbV1dn27dtt06ZNMzybwyAAAQhAAAIQmIxAIGC3 trYaAvZklNgPAQhAAAJxI1CSAnYimbRkKuWF7LgtGOMtLgKD3oc97T+LFHIsrrVlNhCAwOUERt2F 44MHD9qRI0f8myrUuG3bNmtpabn8YPZAAAIQgAAEIDBrAoFoLQH7fe9736zP5wQIQAACEIBAFAmU nIA95rKvZdswNnYxiuvBmEqMQNL5sOtiyqjzqKsoLy+x2TNdCECglAioUKOyrk+ePGnl7u/dXXfd ZbfddhuFGkvpQ8BcIQABCEAg7wQo5Jh3xHQAAQhAAAIFIFByAvZFJ1wPDA7Z2MWxAuCmSwhcTmA4 kXQ2IiMI2JejYQ8EIFAkBJ599tnxQo0rVqywhx56yNavX18ks2MaEIAABCAAgegQQMCOzlowEghA AAIQyB2B0hOwXQb20HAC+5DcfYZoaZ4Eksn0JR/s6nk2xOkQgAAEIkZgcHDQ9u3bZ0ePHvUjU6HG u+++22pqaiI2UoYDAQjkgsC1115rZWVluWiKNiAAgTkSCCxE2tvb59gCp0EAAhCAAASiR6DkBGxZ iAwNOQEbC5HofRpLdESJpLMQoaBoia4+04ZA8RI4duyY7d6927q7u41CjcW7zswMAmECn/zkJ8Mv 2YYABApAYOnSpd6eCwG7APDpEgIQgAAE8kag5ATsi07AHnZFHC+6/xEQiAKBlPPAHkHAjsJSMAYI QCAHBHRB7sknn/QP/Zt7zTXX2I4dOyjUmAO2NAEBCEAAAhCYjoDugpCI3dHRYT09PbZkyZLpTuF9 CEAAAhCAQOQJlJyAbU64HhkZdRYikV8bBlgiBFLpERsbxZO9RJabaUKgqAm0tbXZrl27fKHGRYsW 2Z133ukfWAoU9bIzOQhAAAIQiBgB2YhIwG5tbUXAjtjaMBwIQAACEJgbgdITsJ1wfZECjnP7tHBW XgiogOPoGAJ2XuDSKAQgsGAEXnjhBdu/f78l3V1OKtS4fft227Bhw4L1T0cQgAAEIAABCFwioEKO r776qmEjwicCAhCAAASKhUDJCdhKvB5DLCyWz29RzEN3BIzhyV4Ua8kkIFCKBBKJhBeuX3zxRT/9 G264wbZu3UqhxlL8MDBnCEAAAhCIBAEJ2AoE7EgsB4OAAAQgAIEcECg5AVvMsA/JwSeHJnJGQP7X 3BWQM5w0BAEILCABFWrcu3evyTqkurraC9c33njjAo6AriAAgSgR+PKXv+yLx91+++1RGhZjgUDJ EZCFiAIBu+SWnglDAAIQKFoCJSlgF+1qMrFYElCRMy6qxHLpGDQESpaA7mQ6fPjwhEKNH/vYx7x1 SMlCYeIQgIA99dRTngICNh8GCBSWQCBgywebgAAEIAABCBQDAQTsYlhF5gABCEAAAhBYIAJdXV22 e/duO378uM+0pFDjAoGnGwhAAAIQgMAMCaxatcofqVo7BAQgAAEIQKAYCCBgF8MqMgcIQAACEIDA AhBQocZHH33UhoaGrLm52Xbs2EGhxgXgThcQgAAEIACB2RCQrZcuNgeZ2LM5l2MhAAEIQAACUSSA gB3FVWFMEIAABCAAgQgRyCzUuGnTJtu2bZvV19dHaJQMBQIQgAAEIACBgADidUCCZwhAAAIQKAYC CNjFsIrMAQIQgAAEIJAnAidOnLBHHnlkvFDjfffdZx/84Afz1BvNQgACEIAABCAAAQhAAAIQgAAE JhIoOQF7kZt/WVmZqQAVAYEoEChbtMj5yEZhJIwBAhCAwNsEVGD26aeftkOHDtno6KitW7fOdu7c SaHGtxGxBQEIQAACEIAABCAAAQhAAAILQKDkBGwphVVVlZZMJs39NicgUHAClZUV/qJKwQfCACAA AQi8RUCFGvft22cvv/yy33PLLbfYli1brLy8HEYQgAAEIAABCEAAAhCAAAQgAIEFJVByArYyXWuq Ky2VTNlF9z8CAoUmUOkuqCAKFXoV6B8CEAgIHD161Pbu3TteqFFe1xs3bgze5hkCEIAABCAAAQhA AAIQgAAEILCgBEpOwC5bVGYNdXXWPzBkNoqAvaCfNjrLSqDWVQmvqCCrMSscdkIAAgtGIJ1O24ED B+z555/3fVKoccHQ0xEEIAABCEAAAhCAAAQgAAEITEGg9ARs53/d0rzELnR0OU9PfLCn+Gzw1gIR aGpc7O4KqF6g3ugGAhCAwOUEzp49a7t27bLW1larrKy0e+65x26++ebLD2QPBCAAAQhAAAIQgAAE IAABCEBggQmUnoBdXmZLly6x8jfKLL3AsOkOApkEVMCxqbHBqquqMt/iNQQgAIG8E1Chxueee84e f/xxUwb2mjVrfKHGtWvX5r1vOoAABCAAAQhAAAIQgAAEIAABCMyEQMkJ2M4C26pddtnSliXW1t5l 6ZGRmXDiGAjkhcBSdzdAXU2NK+KoTyYBAQhAYOEI9Pb22p49eyYUavzIRz7iM7AXbhT0BAEIQAAC EIAABCAAAQhAAAIQmJpA6QnYLuN1kXusXb3S+WAPWrofAXvqjwjv5otAmbsbYM3qFVZTU+U/k/nq h3YhAAEIZBJ46aWXvHjd19dnjY2N9uCDD1KoMRMSryEAAQhAAAIQgAAEIAABCEAgEgRKTsAOqDc3 NdqylmZLpdKWSKaC3TxDYEEIlDkv9uVLW2xpc5Mr4Fiy/xkuCGs6gQAE3iYwOjpqBw8etCNHjvid 119/vRevm5qa3j6ILQhAAAIQgAAEIAABCEAAAhCAQIQIlKxyVu6yX9e67NdkKmUX2jttZGQ0QsvC UIqZgMTrxsX19q53XGlVVZVkXxfzYjM3CESIgAo1yjLk5MmT44Uab7rpJv4GRWiNGAoE4k7g9ttv 529K3BeR8UMAAhCAAAQgAIEIEljkCjhdjOC45j2kdHrExmYwtY7Objt55py1u+exsbF590sDEJiK gOxrJF5fve4KW7Vy+VSHzvu9aieOExCAAARE4Nlnn6VQIx8FCEAAAhCAAAQgAAEIQAACEIglgZLN wA5Wa9nS5kuZIk7svtDRFezmGQJ5IdDYUG/vuCr/4nVeBk+jEIBA7AgMDg7avn377OjRo37smzdv tnvvvZdCjbFbSQYMAQhAAAIQgAAEIAABCECgdAmUvICtpV/i/LCvfkeZs3OostOt50v308DM80ZA mdcrlrXYVVessuYleM3mDTQNQwAC4wRUqFHidXd3ty/U+MADD9imTZvG32cDAhCAAAQgAAEIQAAC EIAABCAQBwIlbyESLJIKWw0nktbXP2CtF9qts6vXtI+AwHwJqFDjqhXLnHDdaHW1NQtWtBELkfmu HOdDIJ4EKNQYz3Vj1BCAAAQgAAEIQAACEIAABCCQnQACdoiL7MBHR8es391yPTDgHoPD1u+eJWyn R0Zs1BV6HMUnO0SMzTCBMpdlXV5RbpUVFVZTXWUNzi6koa7OFjfUue06q6pc2IKNCNjh1WEbAqVB oK2tzXbt2uULNZaXl9tdd91lt912G0XVSmP5mSUEIAABCEAAAhCAAAQgAIGiJICAPcmyKoMtkUzZ 0PCwJd3zyFviNYUeJwHGbi8QSTCqcI8qV0CxrrbWamuqrby8rCDiEQI2H0oIlBaBF154wfbv3+/+ zUraihUr7KGHHrL169eXFgRmCwEIFJTAww8/bGVlZfbxj3+8oOOg88sJJFPpy3eyBwIQKDgBfrMV fAkYAAQgEBMCeGBPslASIuvrav1jkkPYDQEIQAACECg4ARVqfPTRR+3FF1/0Y1GhxrvvvttqamoK PjYGAAEIlBaB1157rbQmzGwhAAEIQAACEIAABBaEAAL2gmCmEwhAAAIQgEDuCRw7dsx2797tCzXW Ocui7du3U6gx95hpEQIQgAAEIAABCEAAAhCAAAQKSAABu4Dw6RoCEIAABCAwFwKyszp8+LA9+eST pvoN11xzje3YscNaWlrm0hznQAACEIAABCAAAQhAAAIQgAAEIksAATuyS8PAIAABCEAAApcT6Orq 8lnXx48fdx77lwo13nrrrd539vKj2QMBCEAAAhCAAAQgAAEIQAACEIg3AQTseK8fo4cABCAAgRIi oEKN8rseGhqiUGMJrTtThQAEIAABCEAAAhCAAAQgUMoEELBLefWZOwQgAAEIxIJAIpGw/fv3jxdq vOGGG2zr1q0UaozF6jFICEAAAhCAAAQgAAEIQAACEJgPAQTs+dDjXAhAAAIQgECeCZw4ccIeeeQR a2trs+rqai9c33jjjXnuleYhAAEIQAACEIAABCAAAQhAAALRIICAHY11YBQQgAAEIACBCQRUnPHp p5+2Q4cO2ejoqC/U+LGPfcxbh0w4kBcQgAAEIAABCEAAAhCAAAQgAIEiJoCAXcSLy9QgAAEIQCCe BFSocd++ffbyyy/bokWL7M477/SPsrKyeE6IUUMAAhCAAAQgAAEIQAACEIAABOZIAAF7juA4DQIQ gAAEIJAPAkePHrW9e/f6Qo3Nzc22Y8cO27BhQz66ok0IQAACEIAABCAAAQhAAAIQgEDkCSBgR36J GCAEIAABCJQCgXQ6bQcOHLDnn3/eT1eFGu+//36rr68vhekzRwhAAAIQgAAEIAABCEAAAhCAQFYC RStgV1YW7dSyLiQ7IQABCEAgvgTOnj1ru3btstbWVgo1xncZGTkEIAABCEAAAhCAAAQgAAEI5IEA Km8eoNIkBCAAAQhAYCYEVKjxueees8cff9yUgb1u3TrbuXMnhRpnAo9jIAABCEAAAhCAAAQgAAEI QKAkCCBgl8QyM0kIQAACEIgagd7eXtuzZ48v1Kix3XLLLbZlyxYrLy+P2lAZDwQgAAEIQAACEMg5 AV3IV+j50vYiV7zafAFrFbGeTwRtXuri4oQ259v2fMbFuRCAAAQgMDcCCNhz48ZZEIAABCAAgTkT eOmll7x43dfXZyrUuG3bNtu4ceOc2+NECEAAAlEgcPvtt3uRKApjYQwQgED0CUhkTo+MWDKZtkQy aeVlZVZbU+3s1KrmfUF/bGzMkqmUDQ8nbdRtV1dVubZrrLKSRIHofzIYIQQgAIHLCSxy/2hcuux5 +XvsgQAEIAABCEAghwRkE/LEE0/YkSNHfKubNm3y4jWFGnMImaYgAAEIQOAyAslU+rJ97IBAoQiM joxeEpcTSfectotjF23MyRLKuV5Utsjq62r9Y651rdLpERscGvYPtS3BQ1nXZa7tqqpKL5LX5EAk zwW/ajceAgIQgAAEpidABvb0jDgCAhCAAAQgMG8C4UKNlZWVds8999jNN98873ZpAAIQgAAEIAAB CMSBwMioE66TKUs44TrlROZR93rMCcxB+K3RizY0nHBic5lVVJTP+q4O5eclXB9qY3R0LGjaW5S4 RGwbc/skcA+7MdRWu2zvGpft7frCVmQcFRsQgAAEIkkAATuSy8KgIAABCECgmAg8++yzEwo1Pvjg g7Z27dpimiJzgQAEIAABCEAAAlkJKLs6EK6VcS0BeaobwUeUoe1EaGUny05kNqH2ZUeiNrKFxjLm +tf7vh93d1ydsy1RZrZEcwICEIAABKJJAAE7muvCqCAAAQhAoAgIDA4O2r59++zo0aN+NhRqLIJF ZQoQgAAEIAABCMyIgETqIOt6cChhKdmFuH0zCR0r/2rZiMxUWJbvdSJxqZ/p+tA41IfEdFma1DgR W7Yic8n6nq4v3ocABCAAgfkTQMCeP0NagAAEIAABCFxGQIUaJV53d3dbY2OjKeuaQo2XYWIHBCAA AQhAAAJFSEBictoJw8POykPitexCZhMqvKhM6upUlReWJThPJn1772zncS1BWgUhw9Yh0/WpdmUn knKZ2COjNb7QY9UsRPPp2ud9CEAAAhDIDQEE7NxwpBUIQAACEICAJ6AfaAcPHhwv1Hj99dd78bqp qQlCEIAABIqawMMPP+wzJT/+8Y8X9TyZHAQgMDUBn93sMpsHB4e9F7VezyWUvT0wOOQ9qkdGRnyh x2ztOAdrK68stwFXuDHtjptLSPQeGBh2tiJj1lBf60VzfLHnQpJzIAABCOSHAAJ2frjSKgQgAAEI lCCBtrY227Vrl508edLd8nqpUONNN91EYaAS/CwwZQiUIoHXXnutFKfNnCEAgQwCsuQYdlnXKqQ4 V/FaTarAo2xE9FiI8NnYbszK6K5wftiVzhebgAAEIACBaBBAwI7GOjAKCEAAAhCIOYEXXnjB9u/f 725dTdqaNWts586dFGqM+ZoyfAhAAAIQgAAEZk8gkUpZ0j3mI17PvtfcnZEecf7b7vscAnbumNIS BCAAgfkSQMCeL0HOhwAEIACBkiagQo2PPvqovfjii57D5s2b7d577/UZ2CUNhslDAAIQgAAEYkZA vs3yXr741rO2x5y1hGKRy8gtf+tRVrbIFfur4A6rSdZXHMfmaBsySZMLuluZ31p7AgIQgAAEokMA ATs6a8FIIAABCEAgZgSOHTtmu3fvHi/U+MADD9imTZtiNguGCwEIQAACECgNAqpTkUi67GD3UNE+ X/TPFf5LuWzhtPNslueysobl2Oyftf2WECs/ZP9w7/lnJ2KXLyqzKmczUeVsw/yztquqrNo919bW eMG7NMhOnOUlVhP3xemVxl/mHgQEIAABCESHAAJ2dNaCkUAAAhCAQEwIKLPo8OHD9uSTT/ofthRq jMnCMUwIQAACEChJAhKse/r6rbunz4YTSVeoz4nVzqd5ZPStZ799SbyeDSDvlewysSsqyq2i3D3c c7l7Xem2q2uqrGlxgzUvabI6J2aXUkjQV4Z6Oj0ay2lrHXUhgoAABCAAgegQQMCOzlowEghAAAIQ iAGBrq4un3V9/PhxK3c/UO+66y677bbbuI04BmvHECEAAQhAoPQIDAwOWXtnt11o77TevgFTFnau QpnaaSeG65EZyuJtbKj3hQxXLltqixfXl8x3hcrKCpeFXuUy20dyyjuTcT5el5eX+bEro56AAAQg AIHoEEDAjs5aMBIIQAACEIg4ARVqlN/10NCQrVixwh566CFbv359xEfN8CAAAQhAAAKlSSDhCvGd Pd9m5y902ODQ8IJCkPVIb/+AtyyRPclVZauswQnapRBlziu8prrK27IsNPf58q12466pqS5Z+5f5 8uN8CEAAAvkigICdL7K0CwEIQAACRUMgkUjY/v37JxRqvPvuu90PnNK6JbhoFpSJQAACEIBAURMI fKsvtHVZ67l2ZxuSKNh8k85fW9nfstS4urbW3b1VVrCxLGTHysKWiC3LFlmvxSFUpFOZ41Vu7AQE IAABCESLAH+Zo7UejAYCEIAABCJG4MSJE/bII49YW1ub1dXV2fbt2ynUGLE1YjgQgAAEIACBTAIq yHjy7DmXAZ3MfGvBX0vE7ezusZXLl1pTY8OC91+IDmWhUllV4fy/q21gcGGz3+c637q6Gi+6a+wE BCAAAQhEiwACdrTWg9FAAAIQgEBECChb6JlnnrFDhw55/8ZrrrnGduzYYS0tLREZIcOAAAQgAAEI QCAbAf0b3tXd6zyYU77YcrZjFnpfwonY7V3dJSNgi2/ZojIrc/VC4hKyPllUhngdl/VinBCAQGkR QMAurfVmthCAAAQgMAMCmYUat2zZYrfeeqvphw0BAQhAAAIQgEC0CYyNXbSBgSFnXaEyi9GIkZFR G3RjKpXQRYREMuXqhhTOvmW2rAfdWMucxUtdbQ0e2LOFx/EQgAAE8kwAATvPgGkeAhCAAATiReDo 0aO2d+9eCjXGa9kYLQQgAAEIQCBE4KIrIJg2l34d2lfYzVFnaSJBt1Qi5fjLe3xkZCQ2U9ZYh4cT VuFE7FrqnMRm3RgoBCBQGgQQsEtjnZklBCAAAQhMQ0A/dA8cOGDPP/+8P/KGG26wrVu3UqhxGm68 DQEIQAACEIgaAcnWEUq+9nhUWHJ0bDRqqPIynnRaQnDSkjEU7FMpJ7y7sZc765Oqysq88KFRCEAA AhCYPQEE7Nkz4wwIQAACECgyAirUuGfPHmttbfWFGu+//3678cYbi2yWTAcCEIAABCAAgUIRiE4u eH4JSKhXprkeUbJwmemsNWaNXQJ2ZUWFUdBxpuQ4DgIQgEB+CSBg55cvrUMAAhCAQIQJ6EfW008/ TaHGCK8RQ4MABOJD4Pbbb0fsic9yMVII5IXAyOiYz7xWFnZcQ37liUTKe2FXViKZxHUdGTcEIFBc BPhrXFzryWwgAAEIQGCGBHp7e33W9csvv+wFlzvvvNP0oFDjDAFyGAQgAIEMAj/5kz+ZsYeXEIBA qREYTiQtlWPxWlnQ7v/GL5CVlZX71/IVV8jqXEkJeuQqRkZHbND5YS+pbMhVk7QDAQhAAALzIICA PQ94nAoBCEAAAvEk8NJLL3nxuq+vz5qbm23Hjh22YcOGeE6GUUMAAhCAAAQgAIGIEEg6ATuXhRvL yhZZbW21VVdVWU11tbP2KBsXsiVYy/Ij6XyrE8mEK8CddK/HckJC7SSTSdcWAnZOgNIIBCAAgXkS QMCeJ0BOhwAEIACB+BBQocYnnnjCjhw54getQo3yu66vr4/PJBgpBCAAAQhAAAIQiBgBicnyjh55 Kyt6vsNT1nVNTZU11Ne6YopVEzKww21L4K6prrLq6kqrr6t1IrYTsl0RxiA7O3zsbLaVzD2SHjVl lFe79suUAk5AAAIQgEDBCCBgFww9HUMAAhCAwEISOHv2rO3atcsXaqx2GTxbt26lUONCLgB9QQAC EIAABCAQWwISqEedN/TA0LC3CLnMruOtbGhZb8w3KirKvf90XW2NaXsye7egwOIlbXmRlVVWWnlD mVW5bO0hN06Jz/OJUZeF3dPT7/r3/iUTmlKfla6/xU40L3djDMYy4SBeQAACEIBAzgggYOcMJQ1B AAIQgEBUCTz77LP2+OOPmzKw161bZzt37rQVK1ZEdbiMCwIQgAAEIAABCESGgMRqZVb39Q/6LOv5 ZjdPNTFZhNTX1VidE4YrymcnDEtErqioGBe8JUCnnL3IfCI9Mrkgr0KVEvUbG+ut0vWLiD0f0pwL AQhAYGoCCNhT8+FdCEAAAhCIMYHBwUHbt2+fHT161P+oUJHGO+64w/knlsd4VgwdAhCAQDQJPPzw w144+vjHPx7NATIqCEBgTgQkYEsIHk4kvOf0nBqZ4Um1NTXO87rGC8IzPOWyw5SxXeMsRcbGalzy wkhOizuGOxsdHfNZ3rI6KXeFJcvLsRkJ82EbAhCAQC4JIGDnkiZtQQACEIBAZAioUKPE6+7ubgo1 RmZVGAgEIFDMBF577bVinh5zixMB51+s7Fv3FKmQEKzigMrUjVO27pgbdzKZzrt4XVlZ4Qs2Kpt5 vqFkBXlXyxs7kUjNt7lJz9eaqoik+nJmJ5MexxsQgAAEIDA/AvP/l2F+/XM2BCAAAQhAIKcEdFvr wYMHxws1btq0ybZt20ahxpxSpjEIQAACEIBAtAhISFRGbCqVskHnfzw0PJy3zNu5znzE2U10dvda bU21VTufZvk7x0LIdmxz4W09HTd5XufSikMidn1tbV4FbM1pxNmM6PNHQAACEIBA/gggYOePLS1D AAIQgMACE2hra/OFGk+ePOkL69xzzz128803L/Ao6A4CEIAABCAAgYUicEm4HvVWEf0DQ3ahvdPa OrpcVmz+sm7nOjcJ6//wzVds2bJmW71iuTU21LuCg67woBNaJytUONe+cnmepNmxsfwKtCqKKGFf on6uotxZiSgzWkUY8zl+L17nF0+ukNAOBCAAgdgSQMCO7dIxcAhAAAIQCBN44YUXbP/+/e4W16Qv 1Pjggw/a2rVrw4ewDQEIQAACEIBAkRFIugLNF9o67Oy5NuvtG4h8JuyIyxI/f6HTPxrq62zl8hZb vdKJ2YsbIrsyEmjlJZ3PCITmXPchYVxty0YkX1nS6fRo3trONQ/agwAEIBBXAgjYcV05xg0BCEAA Ap6ACjU++uij9uKLL/rXt9xyi23ZsoVCjXw+IAABCEAAAkVKwHsyuwzrM2cvuGzrTmcXkrBRZ8+R L4EyXxiVkX3yzDmXNd5lS5sbbc3qldbc1Jiv7uberssuzjfbCvleS23Odbg21faiRem8zUFsSMDO 9cLRHgQgAIGJBBCwJ/LgFQQgAAEIxIjAsWPHbPfu3b5QY2NjoynreuPGjTGaAUOFAAQgAAEIFA+B gcFh6+ntcx7UQy7jNWnDyZTzeq40ZRovbWn2lhnzsYhQAUSJ1ecutFt7Z7fvQwX08i2u5muFNG75 Yg+ODnvv7h6XQd7kMrGvWLPSFjt7EVmLzDXEqn9wyLqc53b/wKC7Qy1lZYvKvE1HXV2NtTQ3WX1d nesjGoUHy5zQnAf52reptgkIQAACEIg3AQTseK8fo4cABCBQkgT0o+zw4cP25JNP+h+tKtS4detW a2pqKkkeTBoCEIAABCBQSAL6d1m+0x2dPdbXP+D9p9OusJ3E2Qonwvb1D3p7jyVNi12mcZO3y5it OJtwFmFd3X2uj27r7u11InmikFPOad8SslPOoiOVHhgX5ZcvbbZl7iFf6NkWehTvzu4edzGh3wac iC12Wgu1oyKJuqjQ7d6Tfckyd2FBPtyFDOnLlzzA8yM0a975abmQ1OgbAhCAQGkRQMAurfVmthCA AARiT0CFGj/3uc/Z8ePHKdQY+9VkAhCAAAQgUAwElOV7+ux5J4r2eaE0PKeR0VEbcVYZssuQuK1s 4GXNS2zJkkafmT2dODvqPKN1TmdXjxfJe10bEsyLNZRRrkKUyjQfdg8VfGxsaHDfeab+6S4mOlcZ 8LqQIAF72GXBh7PTta3ilnooO1t1Q7Rv5fJlOS2eOJe1yacJh+aIxcdcVoVzIAABCESHwNT/CkZn nIwEAhCAAAQgYOFCjWvWrLGdO3dSqJHPBQQgAAEIQKBABCQMBj7O2cTrzGElnI3FuQsdPvt31fKl PsN4cUOdywiueisD9+0z1LayhtWuLEM6nIAtG4xSCYn2ErAHnB2Lijw2L2ny2diZ8xentCtkKUG6 22Wot55vs0F3nvZPFXpfWdi6gFBVWWlLXbZ3oaw2NFStdT5kZlEY9Rc8puYxFavp3lMGOQEBCEAA AvklgICdX760DgEIQAACOSCQSCRs//7944UaN2/ebPfee6/PwM5B8zQBAQhAAAIQgMAsCUgATbmM 35OnW73PsgTImYb8sXWexOyrrlxly52NRV1drS+2JxF1bEyWGilvGfL6iVM26Ly1pxNkZ9p3nI5T 9roKPMpbXL7Ya5yQXeMsRYIYde/rokB3T6+dOdfmnvuCt2b0LKayGTnh1qK2tsZnxGc90Qm0Errz uQYjznImL+27OUrgl0ier5AdDiJ2vujSLgQgAIFLBBCw+SRAAAIQgECkCZw4ccIeeeQRk3WICjU+ 8MADJs9rAgIQgAAEIACBwhCQ0Jh2ns3yvT7TeuGtDNfZjUV6oqwsjr9xyi5c6LQr166yFctavB+z hPHT587bmyfPmixESj2U5f7GiTPeS/y6a9b7C/gXXVZxp6xbHH/5gs9V/FV2skTsN75z2ja+5xqX Ce/8ojPUWJ+lXVXhMuDTeVuKVMoJ2O7CheaR2f9cO1VbuhiSz3FrbCqEmasxz3WunAcBCECg2Akg YBf7CjM/CEAAAjElIC/HZ555xg4dOuR+vI7a9ddfbw8++CCFGmO6ngwbAhCAAASKh4D+XZa1x7eP vzkn8TqTRJ+zy3jVtXW+rcOWNC52tiRD1uZEWYmPxCUCylCWN7asRdauXuG9riU8q/jjXMXrgK0K brZ3dblM7DN21RVrfKHH4L2FetYcVGyyzInBKvyZi9DFD4n/+Q4v+ue7E9qHAAQgUOIEELBL/APA 9CEAAQhEkUCX+xG1e/duX6hRt2Vu2bLFbrvtNrJborhYjAkCEIAABEqKgC4wyzv59e+cMgmfuYqg XQm0o064Rry+nKwYSZA9ceqsjThxVhcSchUSwt881Wp1tXW2rGXJhKKRsnWRT3a+M5kHhxIuA78q JwK2BHHZ2gy5NvMdFeUV7jtqWb67oX0IQAACJU0AAbukl5/JQwACEIgegaNHj9revXvdD44hU6FG ZV2vX78+egNlRBCAAAQgAIESJNDbN+BtQ/oHB3M+ewm0KfcgJicgYTbpLFbyEbJuefPkGVdUs9Ka XCa8rDEUsseorq7yXuRjrv98hbLMh50/enlZ2QQBfS79yeJGBTDlI57vqHK8lIVNQAACEIBA/ggg YOePLS1DAAIQgMAsCKjAzoEDB+z555/3Z1GocRbwOBQCEIBABAh84hOf4E6ZCKxDPocwNDzsrD26 rLOrhwzpfIIuYNu9/e4CxbkLtsiJyM1Ni/1ILnlgV9rihjobGk7mNPM+PFVp48Ou/YqKcm8lIiF7 tiGBX+K1MtVVLDSfoXHW1dR4wR8P7HySpm0IQAACZgjYfAogAAEIQKDgBFSocc+ePdba6m5drauz 7du3U6ix4KvCACAAAQjMjsB11103uxM4OlYElB3b3tljbe1dznc5PxnAsQJSpIOVAKzinDXV1Vbj Motra2v8hSmJyQ31dS4ru9wJ2KPuAsboBO9t5WXLc1risdqYa+hzJtsPFamsdnYilZUVLrt5ZkK2 ClIqi1wiuMTrXNjQKLvaF2kMT8hlpItHRUWFE7CrvdiOgB0GxDYEIACB3BNAwM49U1qEAAQgAIEZ EtAPnKeffnq8UOM111xjO3bssJaWlhm2wGEQgAAEIAABCOSbgP69lu/1BVdkUR7VRHETkAjc1tHp ROwqW7Nqhc+IlkBb7jKOG1wWtj4PEoslMgchyVrCdm/vgPOenp83ejKZ8kJ4dXXaap1ALP9tLyI7 0VhGHYFYrHGo3zEnnMt+JukurAwPJ7yInQvxWn0q61wietggRH7XEtWxDQlWn2cIQAAC+SeAgJ1/ xvQAAQhAAAJZCPT29vqs65dfftln86hQ46233jrjLJssTbILAhCAAAQgAIE8EJCgeKb1vBOx+/LQ Ok1GkUBf/6BdaO/0WdfNSxrHRWONVQJyhcvEdl/gJgxdQvOwy55WcUmJy/MJCdKXMqlTTsSu8sUd g2xsFZVUyI/bC9dOcB9x4nXCfU5zIVyrbc2x0s2nvq5WLwkIQAACECgwAQTsAi8A3UMAAhAoRQIv vfSSF6/7+vpsxYoV9tBDD9n69etLEQVzhgAEIAABCESWQCBCnjl7wXpcBrYsIojSIdDV3euzjxc3 1Pvnmcy8prbae2TLSiQXoc+gfLf1CMJnYzuBecRlfOcrlGFd47K/CQhAAAIQiAYBBOxorAOjgAAE IFASBFSo8YknnrAjR474+d5www22detW9wOhpiTmzyQhAAEIQAACcSPQPzBkrW3tNpzngnhx41IK 45VNSG/fgJ270G5XXbF6RlOudd7Z8p/OlYCdrdOFuJCiAo31zv+bgPLCRAMAAEAASURBVAAEIACB aBBAwI7GOjAKCEAAAkVP4OzZs7Zr167xQo3333+/3XjjjUU/byYIAQhAoFQI3HfffX6qjz32WKlM uejnKaHw9TdPeUGy6CfLBLMSGE4krPV8uy1b2uKtPAL/6awHu53yhZZvtbKj5aUdx5BVSZ0Tr/G4 juPqMWYIQKBYCSBgF+vKMi8IQAACESLw7LPP2uOPP+6ycdJGocYILQxDgQAEIAABCExCQIX42ju7 rbun10acpzFRmgTkKT0wOGQnz7Tahnde5euWTEVCAreKP0rAlhf2QmRLTzWe2b4nexIJ8HpMJ9bP tm2OhwAEIACBuRNAwJ47O86EAAQgAIFpCKhQ4/79++3o0aP+R8Cdd95peshXkIAABCAAAQhAIJoE 5Dusgnhnzl2wVI68jKM5U0Y1EwJpdzGjraPTVq1Yao0NDU7Envp7XLkr7igRWzYiQ8OJmXQRmWOq qiqdtV2VyUKEgAAEIACB6BBAwI7OWjASCEAAAkVFIFyosbm52Xbs2GEbNmwoqjkyGQhAAAIQgEAx EpD1Q3dPn3V09lhQyLEY58mcZkZAn4HhIWclcq7NatdXOwF7+uKGsuGodQUdvZWIuwMvDiHxWtYh VZWVcRguY4QABCBQUgQQsEtquZksBCAAgfwT0O2iBw8enFCoUX7X9fX1+e+cHiAAAQhAAAIQmBcB iZWyjFDhPsTreaEsqpPH3OdCn4nVK5ebhN7p7qbT+1VVVS6b2Xlhx0TArnWZ19VuzNPNragWlslA AAIQiAkBBOyYLBTDhAAEIBAHAm1tbb5Q48mTJ63aVaHfunUrhRrjsHCMEQIQgAAEIPAWAV2I7h8Y tM7uXphAYAIB2cl0dPU4UbraZypPeDPjhS5+jI2NOf/0kYx3ovtyxBUt1ZgvXizD/zq6y8TIIACB EiWAgF2iC8+0IQABCOSawNe+9jV77LHHLJlM2rp162znzp22YsWKXHdDexCAAAQgAAEI5JFA/8CQ dff2kX2dR8ZxbvpCW7stbWmaVsDWHOWBPTycjM10h5xNSmVFhfO/rnACdmyGzUAhAAEIlAQBBOyS WGYmCQEIQCB/BAYHB23fvn0TCjXecccd01apz9+IaBkCEIAABCAAgbkQUNZsb18/2ddzgVci5ww4 kbe3b8Aa6urc3XZVk846mUw78ToRqwsh+vyreGml88CWnQgBAQhAAALRIYCAHZ21YCQQgAAEYkfg 2LFjtnv3buvu7jYKNcZu+RgwBCAAAQhAYAIBeV/39g9Y2hVxJCCQjYBEXtmINC5umFTAHnU2HIlU 0t2Vl8rWRKT3acyVFeWukGM5yRiRXikGBwEIlBoBBOxSW3HmCwEIQCAHBOQPePjwYXvyySd9Zs2m TZts27ZtFGrMAVuagAAEIAABCBSKQG//oC/geLFQA6DfWBBQlv6gu9jRsqQxa8HDVCplKZeBrcKP cQsJ9Cl3AUeZ2PV1tXEbPuOFAAQgULQEELCLdmmZGAQgAIH8EFChxs997nN2/Phxf4vlPffcYzff fHN+OqNVCEAAAhCAAAQWjMDg0LANJ+LjWZwPMOUu+7baWUiUlZX5R7l7XvSWIfLYxbFxcVMX80s1 vLe1q3mi52w2IiMjo65442hs8SiDPD0Sn+KTsQXNwCEAAQjMggAC9ixgcSgEIACBUifwwgsv2P79 +8cLNT744IO2du3aUsfC/CEAAQhAAAJFQSCdTpeccKeifdVVlVbl/Jyrq9zDPde45/LyskuPsnIn ZKui3yIbHRv1mblDzttZVhPKNE66bF1l7MZZsJ3Lh1fidXoknVXAVhZznMOPP95TiDN+xg4BCEAg KwEE7KxY2AkBCEAAAmECiUTCC9cvvvii333LLbfYli1b8AYMQ2IbAhCAAAQgUAQEJNWWgnYn0Vpi dWNDg/NzrrfF7lHvChPWTFGYMLy8ErHlGd4/MOgeQzY4NGSJhATt+Pk+h+c1022JvGNj2T8p5eWB 6D/T1qJ1nC5eVLhMfAICEIAABKJDAAE7OmvBSCAAAQhEksCJEyfskUceMVmHNDY2mrKuN27cGMmx MigIQAACEIAABOZOoKqywgl3FT6jeO6tRPdMWYFUOHG1yonXK5a12JpVK6yhvnZOF+TramtMD7Uj O5EBJ2Kfa+uw1vPtlkqnbHS0uC1GJFJPJvLq4kDKZbGn06O+Vsp8PhFaM58B77Ty7HK5cuNduP8n QX2+2d/qr8pZyMz0QsZ85sa5EIAABCAwcwII2DNnxZEQgAAESoqAfow988wzdujQIfcjbNRUqHHr 1q3W1NRUUhyYLAQgAAEIQKBUCDS4DOS6mpqiFbBra6rtijWr7Kq1K30dj8Dber7rK7/sxsYGa2io s7WrV9jrb56yto4ukxd0sYa3W3EidbbQRZCG+jonOC9ywv5gtkNmtE/CtS4SNLtikSPOsmRsEgnb uZRbhbv40uOKSw4NJeZ18aDOFW7U2DUHAgIQgAAEokOAv8rRWQtGAgEIQCAyBLq6umz37t3jhRrv vfdeCjVGZnUYCAQgAIFoEvjEJz4xXuwumiNkVNMRaG5usu7efuvtH5h3Jut0fS3k+8oUXukypa9c u9oWN9RPmjk83zFJEJfg+p4NV9vS5iX25qmz3mZkvu1G7fwlTYsdxzpf5HKysYl5ozum0j339Q/6 ZIjJjp1sv/zJdVFAIYF6uqivrbV0asT1NXsbF2WUa061tdU+S3+6vngfAhCAAAQWlsD0/wos7Hjo DQIQgAAECkzg6NGjtnfvXpfBMmRr1qyxnTt3UqixwGtC9xCAAATiQOC6666LwzAZ4xQEZP2wfFmz DQ4PWUdnzxRHxuetpUuabOWKZbZs6RJTBraEynyFBGxvQVFVZiuXL7VKx/P0mfPW2d3jbUby1e9C tlvuss1XO55LXMb5VBnsek9e0hL0JWIPuMzoYecbPlOLD1m9aL2UCT1VP+G5+4KcNVW+oOZMs9/V do3rR1YystBRNv1M+wv3zTYEIAABCOSXAAJ2fvnSOgQgAIHYEEin03bgwAF7/vnn/Zg3b95syryu dD6ABAQgAAEIQAACxU9A4t2SxsXOBmOlXXR+wp3dvbGe9LKWJc4uZLW3oJDv9UIKk+pvqctol+Bb WVluF9q75pSFHKUFkPh/hbNIWdbS7HzEs9uHhMcr3uXl8rCu8sKwBOJkMukKXaYnLQAZnC9+tU78 LnNtzDQWOcsRid4jznt7ZGR4ytNkT6I+aqqrfTHPSonXs+hrysZ5EwIQgAAEck4AATvnSGkQAhCA QPwIvPnmm7Zv3z47c+aML9T4wAMPeM/r+M2EEUMAAhCAAAQgMB8CgfAq2VAZtD29A64YX3oS9+H5 9JTfc5X1u9YVaWxpafJF+fLbW/bWlRHc4vyblXWsjOD2zu4ZZyBnb7Ewe/U5kC90c1OjL3xZV1cz q4sBErL1uSp3ayIxvyKRcoUu055JtmKXPpO6umpOVi/BuWo/7XyzM0PCtcRqFWqsdn3orgOyrjMp 8RoCEIBA9AggYEdvTRgRBCAAgQUjoB9UKtT4xBNP+Kyg66+/3h588EEKNS7YCtARBCAAAQhAIHoE lJUqCwxlwJ6/0OE9sQcHh73oOFMLiELOSoLrCud5vdw9JFQWMpS13OJsTMQtmUpZb99AIYczq74l 9Kqop3yolc0uprOx9MjsTNnota493d2niyKJpBOyk2kbdYXDx1zGvxKgdYwKKSqTei4Z8zqnprrS tVdrQ8PD7vutK/3o2Euk1sNndjubEWWQqy8CAhCAAATiQWCR+2N+MR5DZZQQgAAEIJBLAr29vd7r +lvf+pb3g7zrrrvstttum9OPhVyOi7YgAAEIQAACEMgtAVk2zCd6evvsnBOyu3p6nSiY8JmzUf0Z KQFT2cLf/d53O//lai9azmfuuTpXGcEdLgP7lde+4y8E5KrdXLejzHsJ18pObnJ2MqvchYwWJ17L kzrXMeaE65HRUUu5z6f4yMJD/eqiw3y9yiWKq11Zlkgc91nXLttaGdoSsqMSygAnZkZAFz0uXLhg 3d3dvlZPXV2dT7pZvny5u9hWO7NGOAoCEIgtAQTs2C4dA4cABCAwdwLf/OY3vWWIRGwValTW9fr1 6+feIGcWFYGRkRH7nu/5HkskEn5eysw/fPjwrOb427/923bw4MHxc/7yL//Srr322vHXcd3Qj6f3 v//9Try5/Lbkuc7pU5/6lH30ox+d6+kTzvuHf/iHCW099thjduONN044hhcQyBeB++67zzetzx0R LQLzFbCD2fT1D1jr+Xbn59xpwwkJg2PBW5F5VubuuivW2DvXXxGZMQUDSbqM4xOnz9qbp1ojyU7C bo3LTF69apkrfLnUGhsaIiX2BhyL6TlOAnZra6u/c3Om/HUxSQ9djFDmfmNjo1199dWm75Wzia9/ /et2/PhxVwR0cl9zZfWvXLnSPvShD7kM/rrZNM+xEIBATAhgIRKThWKYEIAABHJBQOLboUOHxr98 UqgxF1SLr41vf/vbposcQbz3ve8NNmf8/JWvfMWOHTs2fvyKFSvGt+O88corr5geuYzFixfnrLkX X3xxAveWlpactU1DEIAABBY31Ns176y1K9astPNtHXbqzHlnA5GMFBhZVKx1hQajGLKvuOqK1T6b XRcAopLFLl/oemfbceWaVV64Vgb0IidmKxubgEBAQIkNs/nMBseO+iz7lM+aPn/+vP2///f/7Kab bvJJNEHb2Z7V31NPPWVKuJku9BtHtXy++MUv2saNG+2GG26Y7hTehwAEYkYAATtmC8ZwIQABCMyV gL7Uffazn/Vf7pSZsH37dgo1zhVmkZ+nLN5wfN/3fV/45bTbQ0NDdvTo0fHjNmzYYM3NzeOv47wR nleu5rFp06ZcNWX/5//8nwltXXPNNRNe8wICEIDAfAgE2ZR1zhv7yrWrvCeyChO2nmuzQZcdKauG QobE66XO7kJCcVRD4vC6K9fYd06c8Z7YhRynPKBlE7LGCf4qNqmxyWpDobUmIJAPAhKmjxw5Yj/z Mz8zad0d/W756le/Ous7FSSayx5RovkP/uAP5mP4tAkBCBSIAAJ2gcDTLQQgAIGFJPDss8/a448/ 7gvm6La9bdu2OT9DMjMXcg3i1Nc3vvGNCcOVnchsIpy9rfOKycLiAx/4gO3Zs2dSHF/72tf8XQ7B AT/yIz9id955Z/Dysmfd8rp69erL9s91h/oP4uabb563h2jQFs8QgAAEwgRkNVHtrCYkeOohi4CT p1ttcGjyW/zD5+dru76uxovqURVfNS6xW+XsOc5faC94UUzZOixxArYKdsbJyiJfnx/anR0BfX7e 8Y53THqSsqIHBgZ85rWSG8Ih+yEVkv+X//JfhnePbz/33HOXidfVrrjs+vXrbcmSJV74HhwctK6u Ljt9+rTvZ/xkt6G75a644gp/fHg/2xCAQHwJIGDHd+0YOQQgAIFpCeiL3R/90R/Z//2//9f/uNyy ZQuFGqelxgEvvPDCBAjf/d3fPeH1dC90a2g4vvd7vzf8MtbbslOZylJFWUWy6QniZ3/2Z+3nf/7n g5d5fVZRo+985zvjffyzf/bPxrfZgAAEIJAPAhJka5zntMTPQhfGk5DeuLjBFXCMfjG3GifEtTQ3 eR/xhPPFLlRcvDjmrEJc4cQIZ6wXig39Tk+gxt3x8MM//MPTH+iOUPHFv/7rvx6vr6KTJG63tbVZ ps2crOxSqYn/XXz/93+/ve9975u0rxMnTpgSdgLbEh0oWzUJ3gQEIFAcBKJTfrc4eDILCEAAApEh oCzYT3ziE1681hfDT3/60/bjP/7j3BIamRWK5kBUICdsk/HOd75z1tn6//t//+8Jk8ulRcaEhiP4 opBzz7R+mW3mfARxMiQIQCAmBFSccHRstKCjrautNnl0Kxs8yiHRX4/ly1q8+F/IsY6MjPq78wo5 BvouDQIqsPjTP/3Tl13okt1HZrz++usTdl111VVTitc6WEJ1pu91f39/TotuTxgULyAAgQUnQAb2 giOnQwhAAAL5JSDPty996UsTCjXefffd7kdSTX47pvWiIJD5Q+IHfuAHZj2v//W//teEc77ru75r wuvMF/rMnjt3zvuz19fX+9tRGxoaMg+b0eukKyZ26tQp6+zstHXr1uXUnmMmA/j7v//7CYe9+93v nvB6Ji+UpfTmm2/a2rVr/e2vEjpmEpmZ77m8cNDe3m4nT5403b4rX+1c/T1Ru1ovZW6+613vslwW tJwJM46BAARyQyDhsiXHRsdy09gcW9HfpfoYZF8H02t0/87Vuuz1vv7By6wSgmPy/Tzm/IJH3L/B +nc46sJ/vlnQfv4JqAbP8uXLfTZ20Fu2Ao3KzA7HddddF3456baKN6oWiKxLgtB3DCVjEBCAQPwJ kIEd/zVkBhCAAATGCUj4+s3f/E0vXutL4q/+6q/aL/zCL+RMbBrviI2iJZApguqWzdmEvAjDNhYS UfVZzBbKGP6xH/sxk4filVde6TNnJHZLxFSmzq/92q+ZbDGmC/1QeeKJJ0zFJiVgqGiksnDWrFlj jY2N9pM/+ZP22muvTdfMvN+XCK9bYYOQ+C+P6+lC43/kkUfsJ37iJ/y8V61a5cevjKOmpiZ/e26m rUu2NsPZ37rrQkyzxe/8zu+YvPDDD3lFZoYyoHbu3OkZqj1ZwWh9amtr7dprr7Xdu3d70SPzvPBr ZfMH/ejWX81Vt/fqIpvWS+3KV1yfE63Vj/7oj5puHSYgAIF4EUgm0+7vQWEFbInBdTG6WF9RUW71 7t/H6uqqgi621i2ZelvwK+hg6LzoCWR+LxoZGZl2ztlE7slOkkCu0MV/fb/UnYUEBCBQHATIwC6O dWQWEIAABOx//s//af/1v/5XUwaqMiR37Ngxa+sHMEJgvgUcM20sJvNhlqWNLrZMFhKCH374Yfvc 5z7nK9VPVkn++PHjXgQPi+bhNnX76FNPPeUfn/3sZ+2XfumXwm/ndDtsvaKGZ1K8UpnWKmD09a9/ PetYNP6/+7u/M4nh//pf/2uT+Kws6GzxP/7H/xjfnS1zXsKxLgr8p//0n8aP08bhw4ftPe95z/g+ Haf1+a3f+q3xfZkbx44ds4ceesj+/M//3P70T/900iJO8p8MxHEVU+ro6PAX1f7qr/4qs0n/Wv6V ErYlYusCBAEBCMSDQCqVLFgWsQhVOqGqxgnBVTHzcq6vq7UaVwxzeDhRsIWW9Ut6RAI2d+oVbBFK qGPdeRUOXbzODCUy9PX1je9WLR9ZhOii/nRx2223TXcI70MAAjElQAZ2TBeOYUMAAhAICKhQ4969 e/1DBU/uvPNOLzy1tLQEh/AMgRkTyMz0nc7+I7Nh/cgIR7YCjk8++eRl4rUycSXk/ot/8S/Cp5sE 3J/6qZ+yzB88Okhjlc9zpnitPu+66y6f1Rtu7Jd/+ZfHrXXC+3O1nZm9nm3u4b6efvpp7+mYKV7r VleNP5P9H/7hH3pRP9xGsH327NkJ2d8SgcMxNjZmmn9YvNYPRAnMd9xxx/ih+hvycz/3c5eJ11of eejfeuutE2w+ZBfzkY98ZNJMbN3KG4R+pGpcYfFa7eoRDq35b//2b4d3sQ0BCEScgLJ4ZUdRqKh1 /teFzmSey9yjILq7Oo7ub3jh1m4u3DgnngT+8R//0SfahEevu84yI7N4uCxudKfdl7/8ZVOxRgIC EChNAgjYpbnuzBoCECgSArJFUKFGZV9LBFLGZLYCKUUyXaaRZwKy61BmbRASUCez/wiOyXwO21jo vWw+zL/7u787fprsPpS5fP78efviF79oX/3qV01irMTSIJSN/fu///vBS/8sQVv2IxI7g/iZn/kZ 79OsLHL90JGg/Nxzz00QSH/xF3/RhoaGglNy+pwpRGf+AAt3pjlJsA+P/5577vHjf+ONN/z4/+mf /skkcod9oSXsvvrqq+Gm/HZm9rdsOYLQ7blbt261PXv2BLu8H6TOycyQV9a7MqqDUN8HDhzwHuV/ +Zd/6cej9ZE1URASqR999NHg5YTncFa4MrHPnDnj3//1X/91L7jL9khrn+mbnvl6QqO8gAAEIkdg xAnYunujUFFZXmEVES/emI2NMsaVPV7I0LrpIicBgXwR0PeQZ555xjLv8pPvunyrM0N3YDU3N2fu 9t8b/uZv/sb279/vrcj0HUN3dhEQgEBpECjsv5alwZhZQgACEMg5Af3Q0G3/ymTVDw/5/UqgylVh tZwPmAZjQUCCaTiy2VCE38+2nSk8ZhYxlEgezsr91Kc+ZZlCr364SMyWrUUgeIaFUPUr+4qw+Cuv 5s985jOXDWnz5s32x3/8x3bLLbf499TeX/zFX9jP/uzPXnbsfHbov0NdSApCwu9URYMk4IbHv337 dpPFSWYRLWU8S4wPxq/2lUWtOYUjM/s7YKqMas310KFD44drXZXFtGzZsvF92njppZcmZF5rDrKE ufrqqyccp/1f+MIX7Jvf/Ob4Wv7Gb/yG/xsUPjDTD13v6VwVugzGp33yqZTdyu233+6tXrQvsB3R NgEBCESXgP72uf8rqHgtOuXOTzrz72d0qb09sqrKSufTW/72jgJsjbkU7EIX4CzAtOkyBwR0F+if /dmfZW1JfxuUOS3xejKfa11El091ttDdd2o7W9KB2pbFiB66qK9C0LrLS99X9P1CrwkIQKD4CPBf dvGtKTOCAASKnEBnZ6f3p5WAXeV8Ex988EHv64t4XeQLvwDTy7T/yLShmG4IEoenK2Ioj/Zw6HOc LSR0hq0tlN2sH0IKCcXhH0w333yz/d7v/V62Zvy+D3/4wxMywfMhjsrGJCxIy7N7sh9QylKXX30Q sgtRdvRk4ovG/8//+T8PDh8Xjcd3uI1w9reE86VLl1oikfBWJGHxWlnqyl7KFK/Vlnzzw/GVr3zl MvE6eF9z08WHILTumUWWMv3QdayypsLidXC+nuvr68dfyi+bgAAE4kFAAqiTsAs6WGVfl5XH76dt RWXFpH/7FwyoW7pLa7hgPdJRkRCQkDwwMJD1IXFb30MmE6+VpKAiz5OFvmfozjTdqacL3VOFEnt6 enr8nXf6fvW1r31tqsN5DwIQiCmB+P0rH1PQDBsCEIBALghIuPvkJz9psg5RoUZlYs6kUFwu+qaN 4ieQeWtnNvuPqShk2lhk+2zK6zCcmawigNu2bbPW1tbLmlaRx9dff93fHppOp8d/5GdmH//7f//v J83gCRoNi6bZLDiC4+b6nDn37//+75+0qcxCkv/23/7baX+chQVsCfDhH4T64Rb2LleGtX44/sRP /MR4RrMG8yu/8it28ODBrLYwKib5t3/7t+Njlhf5D/3QD42/zraRmV0v65NwZGaFf/SjH/V+2eFj wtvhCyiZbYePYxsCEIgWAYlYhY5FZYusbBqRq9BjzNa/xjydOJftvFzuczn0SqHPZZO0BYFJCSxZ ssTfVTZZce7MEz/0oQ/Z/fff7+uCKLlhuv9e9PdIhaD/5E/+xBVHHc5sjtcQgECMCWS/XyPGE2Lo EIAABIqRgDIY5DErAVtf3FSoUY/JMjyLkQFzyj8BWTuEY7YiogoChmOyIoYq+hf2wf785z9vejzw wAMmK5DrrrvON6Ms4cxMYd1KGs5eDvoLZyAH+yZ7Pn78+GRvzXl/plir4pLZQre7hi1UJBRnFmvM dt6VV145YbcE/6uuusrv03zC2d+6uKWs7bDtivpQEcjJQjYl4Xj/+98/Ias7/F6wrYsK4Th16tSE TPfMNZHty2QhLmH/9fAFh8nOYT8EIBANApeE46kzJPM9UolWURDSZzvPKIzbSejycprt0DkeAp5A +A5QXVDX3XLBHXNhRLozTPVNdPfobEN3qMluJKjbobve9J1B9VAmE6l1x5/uQJONGr+XZkuc4yEQ TQII2NFcF0YFAQhAYJyAMiN3797trRlU0ES3+et2OgICuSSgIjjT2X9M19/zzz8/4ZDJMriVMS27 kXCxQJ0oX2U95IWsY7IJu+FM46AzecDPJrIVBprN+dmOzRzXZHPPFM9lATSTUKHDcDQ0NIy/zLTq UOZ6Zsiv+uTJk7Zu3brMt/xrFYsMh+7u0GM2ER6Tzgv7oavI7GQXNHRspv86AraoxC9UVHi67Lj4 zYoRT0VA6y1xqdDyp4SzsRhmEadHnNjnxl7I8GtYVlgf7kLOn77nTkD/7qsgdWbI7lB3danuSRDa pxokW7ZsCXbN+Vl38gV38+ki0Msvv+y9sMP9qXGJ2Er++eAHPzjnvjgRAhCIDgEsRKKzFowEAhCA wAQC+kImUUlilIRFiXTy+UW8noCJFzkioAJ+4ZjKAiN8XLCdWZxRHsaZxf+CY1Ww57HHHvNZ2Lod NDOeeuope9/73me//Mu/fFlmzenTpzMPn/Vriam5DNl5hLOd1b4KUWaLcJax3pcH5Ewic33CInw4 o3uqtnQXx2SRKaxPdtxU+5cvXz7+dqYfurLup8qAysxgR8AeRxmrDd09ce2118ZqzAw2NwSm+u87 Nz1M3UraF4obnfqgCL6rfz+yZasu5FAlYBd6/RZyvvSVfwLKtlbNDdnGhUN3i2VeMA+/P5dtfX43 btzo+9PdqZlFITPtzebSB+dAAALRIEAGdjTWgVFAAAIQmEBAWQrKRP3Wt75l1dXV3iM4m5/whJN4 AYF5EDhx4sSEs9/73vdOeD3di0z7EfkvTxXK2JOf+/bt2+3AgQM+21eiZzj+83/+zz575o/+6I/G d8umIhwf//jHZ/3DezJ7j3C7s9nO9NSeyjtavozhCGxAwvuybYezrJV1pB9sQWRmf2u/jnnmmWfs 1ltvNd1qq9i1a5fJbzvz9l1ZFGVm34c9t/3JM/h/4bmEx6tTb7nllilbUGHLIHRRQzYoBAQgEB8C EkD1d6lQNh7JZNrS6ZH4AHtrpD4D22VhFzK8f3j52/+mFHIs9F1cBPRdULVOwpnRskCT5dxkd88p IUB3n+riju6suO222y4TwiejJNu5H/3RH7UjR46MH5Jpdzb+BhsQgEDsCCBgx27JGDAEIFDsBFTI TIKdirDpdn95Auc6Y7TYGTK/2RO4cOHChJMmyyCecFDohS64hOOmm24Kv5x0u7Gx0WSj8Yu/+Iv2 pS99yX7rt35rXHDVSWpXt6cGorAu7oTj05/+9GWCbPj9hdjOzB6eyiojLNJLqM3MFMo2Xv1NCERo vR9mm0qlLvOqlkekstj1d0MXCH71V3/VN6vMJ+1XVlQ4enp6wi/9j79sNiQTDprmRbggow79wAc+ MOUZusU3CF2sIxswoMEzBOJBoKKizBdRHC2QjUfCWQUk3d/DuIXqOiSShR23PMwr3EVlAgL5ICBb OFnGhe80UILOypUrx21Awv3qe54urAehItnTXQQPjtWz7gBUkkS4P/13VldXFz6MbQhAIIYEsBCJ 4aIxZAhAoDgJKENAxek+85nPmL5o6Ta4//Af/gPidXEud+RmlelfPBurjtdee83+6q/+anxOEmZV nDAcf/AHf2CqOH/99dfb933f94Xf8tsScu+55x5/18Fdd9014f1wdnfYpkIHhQXhCSe99UIZPMr0 /pVf+RXTGJ577rlsh81rX6aAPVWGdzgTSIKyxjddqMBlOMICtHwfw3HHHXeYvMiDi1533313+G1T VntmtLS0TNglr+zp4mtf+5q/M0QXHHTBLfPCQjijWj8mM4txhtvXxZPwOgZFmsLHsA0BCESbQFVl lZWVF+6n5YjLYpYQnExNLC4bbWpmA4NDNhwS6wox3nKXPV9VUVmIrumzBAjorq8gCSE83b/7u7/z GdbhfdoOW6TpdWYNEO2bLpS5HQ7E6zANtiEQXwKF+5YRX2aMHAIQgEDOCUi80a39Ep70xU2i0E// 9E/7DIKcd0aDEMhCILO431e+8pUsR12+SwVyVOE9HP/m3/ybyzJdZP2hon6vvPKKybM5fDtp+Fz9 yMgsHhgWaSWGhuMf//Efwy8v25bvs9qTfYbGlZkZfNkJc9iRaeExlX9zJufXX399yh6//vWv+wtb wUG6OBD+IajMpHDob0f4h5r8J3/qp35q/BDdmhvmqTf04zIQvPVafU5lA6ALbBLGJayr2Ka4Vla+ LX7oh2OYyYc+9CE1O2lkzmG6bO1JG+INCECgYASq3d8RCaGFjOHhhEsAGC7kEGbV98joqA268RZa dC+vKHd/w7kxe1aLx8GzIvCud73rMhsQXcD/m7/5m8vaybQQ03Hf+MY3Ljtush36jhP+DqNsbAIC ECgOAoX9llEcDJkFBCAAgXkRePbZZ714LRF706ZNFGqcF01OniuBzKxXWU088sgjUzYn6wlVkw8X EZTA+q/+1b+67LzMwm5TFfFR8Z9w6DbTIDLF0H/37/7dhNtEg+P0rCzh8Fg0tm3btoUPmfe2xNyw ACvv6czsoXAnmZz/43/8j+G3J2y3t7ebbr0Nx969eyeIxZk/6rIVhfyFX/iFcBP2X/7Lf5nwWi9+ /Md/fHyfLjI8+eST46/DG7pg8fM///MTMqY/8YlPmKxgglBBSGWXB5Et4z54T8+ZGez6O0jEk8B9 991nehClR6C62gnYBRaKJF73DwzGBr6yrxOJVNYs1IWaRLnLmq9wAnYhs+cXaq70U1gCsgHJ/Buh 5AZ5YodDFnb19fXhXaZkBSX5hIXpCQe89ULe2kqWCMfq1avDL9mGAARiTAABO8aLx9AhAIF4E+jt 7fV2IY899pifiH70y6s280tbvGfJ6ONCQBYPmeKu/NdlZaOCfGEvwa6uLp99q0KPmULnE088MSGb N5h/prB67733WrYsbwnCDzzwQHCaf/7hH/7h8dfveMc77Ad+4AfGX0ts1X87Oi+I4eFh27Nnz4RM Zb332c9+1pqamoLDcvIsH8dwTFf8UMWFwtnO8oVUdnjm7a66tVZCbri4omxZMi1Bwt7R4hLOhA7G dfPNN0/oUxcmBgYGgrf9s3zGwyGR+m//9m/Du+yb3/ym/diP/ZgvyBS8oXX9pV/6peClf84s4Did IK2M7yDEZrb+68G5PEMAAoUjUF1dWXDv+qFE0vr6Byw9A2umwpEyL8JJiGvv6HK2J8lCDsXXYagK 3UFT0MHQeVETkFVc5kV8TTibtVv4e14A5Y033vB3pB06dMiL2bKv6+josH/6p3/ymdyPP/64t6EL jtezCstmJj6E32cbAhCIFwHuFYrXejFaCECgSAhICNq3b59JxJalgIrYrV27tkhmxzTiSuB3f/d3 feaKPp9BSKAOROpAeA2LqsFxev793/99+/CHPxzeNb4tEVoe1/qBEYSq02/YsMH/uJDVhWxF/viP /3hC9q7ETx0XDmUhv+997xvfJRH4r//6r71gLSFYt6SGM4B14MMPP+wzh8dPytFGOPtaTU6XbSyB WV734Yxn+XOLixhp/BKAJWCHQxzERj/GgtAcJeAHke2Hod7Tj0ZdnPjUpz4VHGq60BDOzP6RH/kR Xyzzz/7sz/wxanvz5s3+YoFu5/32t799WbFI2bnoDpJw9rVODmfk63V4rfQ6HBJxlCkfRNgeJdjH MwQgEE0C+u9XD1lhjI6OTZsdme9Z6EJrv8tq7untt+VLm/Pd3bzal8je3tld8AKOi2yR+3fnoiWd f7gysTMzZOc1SU6GQAYB1UGRxUe4eLQKNup7wAc/+MHxo9evX++LP2favuk7ks7VQ4L2dKGkgrCt 2nTH8z4EIBBtAgjY0V4fRgcBCMSIwODg4LTZ0/px9aUvfcmeeeYZPzPdTicLBn4wxGihi3ioyk5W MUZl30qYzIzJhGtZc0gQnUy8DtpRsT9lzIQFzmPHjpke2ULFCmV3kfnfx3d913fZwYMH/X87wXka 25//+Z8HLyc8K/M6M0t4wgHzeJFp4TFdtrG6uu2223wxxfCYJIRniuHBsORh/Sd/8ieX/X0JX2jQ sVN5R8unPCxgi0lYwNb5ylrXrbxh8Vy34mbejqtj9aNQgnq2bOmw/7UytDMLhOr8IN58880JFxum uwAQnMczBCBQeAISrweHk3by9Bk7d74jEpnPAwNDdv5Ce6QFbHG70Nbp7EOSBRf9lQF+8kyr+zs8 YOuuXGPLl00s6lv4TxkjKDYCt956q+liuf47CEIXyfXdbsmSJcEufxdaWVmZr12SeZfa+EGTbOi8 G264wa677rpJjmA3BCAQRwJYiMRx1RgzBCAQOQIS/STOTRUXLlyw3/zN3/TitTIWf/3Xf91npGaK c1O1wXsQyDcBCZLKZtYtmrKsmCqUgft7v/d7pkKE04nXakdZMBI31bZ+qEwWEkeVZS1RPDO7Nzjn ox/9qL9tNNMjOnhfzxJtz549mzfxWn1kFkScal46PgjddaHMoqnGryzt//7f/7v9t//23y4Tr9WO vKbD8T3f8z3hlxO2r776alOWdRASv3UxIRzy7taFC2XSZxbLDI7Tfl2E+/u//3uT33e2CDP5wR/8 wWyHjO/LLGI5lQg/fhIbEIBAQQmMjIxaV3evvfzaG/aNo9+0s+faIyFeC4oym7tdBvbZ820FZTRV 5xLjzpy7YKn0yFSHLdh7Ws8Ot57fevW4feMfXrJWdwEglU4vWP90FB8Cmb9ZJBTPNmSVKAu6zMi0 LdP773//++3nfu7n/N2q2SzSMtvQHWdXXXWVP0fZ3gQEIFBcBBa5K19vX/oqrrkxGwhAAAILQkCF 1n7t137Ne/BKMMsm5KnwiCwCVABNGZry+J1MmFuQQdMJBGZIQLYesqnQ51yP6upqL27K8kZV5TN/ zMywWZ95o4s6J0+etBMnTnibi40bN86pzfPnz3uLCxVCVTa4Mm4krs7kx85Mx5vP48RV2UcS22UR Ip9vCc6ZxSzzOYbMtkecCCR/79OnT1tfX5/nKbsXeaUTEJiMQFDAMajtMNlx7F94AsnU/AVJLw73 9FlbR6d19/R7/+Z0RETYMFGJak2NDfbd7323VVdVTrBeCh9XiG3xEr9Xjn3HoshORR1r3L/zixvq bdnSJbasZYnV1dYWAlXJ9KnPKDEzAvo+ou96shCR1ZkEa30P1W8qXWAPrO5m1hpHQQACcSOAgB23 FWO8EIBA5Ah8+tOftldffdWPq9Z9yVeWtXytFbIVkde1rAEkpskDWAXVCAhAAAIQgECxEUDAju6K zlXAVq6TPK47u3qts7vHXdAacLYhw5bKgSCeT1ryc75q7Wq7ev0VkbmYqcxreXS//O3Xrbev313I zSeB+bUtUbCu9pKQ3bykyZY2N1lDfd38Gs1ytj5f8uBWxrcunOriQ2VlhVW4/ueS3RvuYsy1Peqy y1Ou3YuOfXlZuW9bIn24nkT4nEJsI2AXgjp9QgACcSSAB3YcV40xQwACkSEg6xCJ18HNLMPuR93n P/95+43f+A2fVfq5z33OZwkoK0B+t1deeWVkxs5AIAABCEAAAhCAQDYC+l6TduJfT0+vdfX2+cKI fc4nWXYTcQgJl63ORqSmptpWr1jm7h6qKviwk6mUtbV3OvF6INLitUD5gpjOT3xwKGF9/YPuMWBL GhdbixOyax3TeYvLTlDWZ0k2KspET0vAdhdKAgFbfdS4NZtrPyoqKt7DzqNddw4IuNqqcOJ4lXtI JK902btzbb/gHyYGAAEIQKAECSBgl+CiM2UIQCA3BGR9IG9aRTiTQ/t/53d+xwvYem/z5s127733 RiYDSGMiIAABCEAAAhCAQDYCyhQedgUGu51dyDnnh9zR1TN+oT7b8VHcp+TmRDJlp86c89m8ssOQ NUahQoKwhODzrnhjkPRQqLHMpl99FgZc1vjg0LD3PdfnYsXyFp+NrSzp2Ybmfkm4TnuBOZlU5vVo iIkTtV12v/otc5ZauvAQ/o49k/7Uh4TxgcFhXyhzwjnuMyHhurq60rdd5e6OVLa+Yrb9TGiXFxCA AAQgkHcCCNh5R0wHEIBAsRKQNYgyrvVFOfjSG2yfcJ6+8gr+2Mc+ZhQlK9ZPAPOCAAQgAAEIFB+B pBP5JFyfONUa+2J+El+/c+KMzyhevXK5z7wNvrMt1MopA7jfiddtHV3WPzC4UN3mtB99v5WI/fqb p9zFjWFbd+Vaa3Q+2TPNYNb5sgpRlvWQa2doOOHWZGzSMSpzWpYfypierVAu8TvhhHZ9jrOF1kMP 9VHrbFLqXYFpidiqR7jQn41s42MfBCAAAQhkJ4CAnZ0LeyEAAQhMSUCZ16dOnZogXuuE8Bdffal/ 97vfPWU7vAkBCEAAAhCAAASiQkBCY3tnt51uvRB78TpgOjA0ZCdOt/pM3yvWrPQi9kyF16CNuTyL 5agTUzscz5Onz1mXs2Mphjh7rt3ZiNQ6K45K55NdM+WUxEDhM7mdHcmAsyVRNvpMQhYgiUSlE5hr Jny/nupc9ZdIpLx4HfQ92fFaG2VpDzkhe/Hieqt3c5E/tiL8fX6y89kPAQhAAAILS+DSX+iF7ZPe IAABCMSagCxCDh8+7Ocw2RdcfWlWdvZnPvOZWM+VwUMAAhCAAAQgUDoElCHc5axDhl2GbDGFsoff OHnavvnKMV+QciHmJnH0ldfesFeOvWHdzke8mEIZ+j29/TOaUio14gqA9roCoP0zFq/VsLyxh9x3 6ZkK3jpHorRsTlQUcqYhcV1jU5FSWZoQEIAABCAQTQJkYEdzXRgVBCAQYQKyDplJSMRWgUcVevzw hz88k1M4BgIQgAAEIAABCBSMgAoMDsTU5mI6aPJaVha0BM7z7Y227oo1Vl9f66wqcpfT5e0r3rJg kd/1oMv+Vr/FFrIA0cWORLLJF1vMNj8Jz7Lp6Hc2LiPOsuOtZOxsh066TyK2Ckk2ugxpnT866trJ cnRFeYXLmjZvczIb8TpoSm3Le1u+7w3uM1Hnsr7L5+DxHbTHMwQgAAEI5J4AAnbumdIiBCBQxAQO HDjgrUNmM8U//dM/tfe85z22bt262ZzGsRCAAAQgAAEIQGBBCUiYVPHDYg35LssXW2Klnpctbbbl Lc1etKxwxf3mGhJN5XPd5TKNJZIPOZFcPszT2VjMtb9Cn6d56XOScjYfNa7QYmZIvNZnSVnoEqHn GlqvQdeG1kvC9cWLzjc7U8F2wvWiRWXmnry39VwvGEjElje2xqwuZF2CiD3XleM8CEAAArknMPd/ pXM/FlqEAAQgEGkCr7zyin31q1/1Y9QX92z2IcEPlcz3jhw5Ytu2bYv0/BgcBCAAAQhAAAKlTUAC 3ojLci32kOCc6kl7EbbXWWEsbqjzxfzk6VztBNlK5+9c6Qr7ZX6fExd911NBwuFEwou0EmpVmFCC uKxKlOFdCqHPyWRiccqJ1hLw5yNeBwxV+FGPhQpf4NGNvaKizHl81y5Ut/QDAQhAAALTEEDAngYQ b0MAAhAQgcHBQfv85z8/DkM/aAKxOtipfcEPnVr3hVdZ1x/4wAf88/Lly4PDeIYABCAAAQgUJYHH HnusKOdVepNSLmtmmmtxUpDXtx6yjqitqbZaJ2DX1FwSsCuchUTwvW7C7B2aMZcJLHsMeTRLwE66 bGT5L5dSuG+9LvU5+4xlGZKOsXWKMsglwtehX2dfYPZCAAIQKAABBOwCQKdLCEAgfgT+4i/+wjo6 OsZF67BYHczmqquu8oL1937v92IXEkDhGQIQgAAEIACB2BCoeivzOJkqLTFWWbfpgRHrK1L/73x8 ACsrK1yWemXWpuN++cMnqchThIAABCAAgcgQQMCOzFIwEAhAIKoEwtYh4UwcZVkHGdZ6rq+vj+oU GBcEIAABCEAAAhCYloAK2NXW1FjSeQ4TEJiMQJkrfFnnPifKVs8WKoypY1zZxWxvR36fxl7uLGQI CEAAAhCIDgEE7OisBSOBAAQiSCDTOuTd7373uGhNUcYILhhDggAEIAABCEBgzgSaGhd7P+ievv45 t8GJxU9gcX2dK3xZ5zKws8sJNVVVlqpUkcd4Xgipqqr0F3KKfyWZIQQgAIH4EMj+L058xs9IIQAB COSVgKxDJFrLFkTPZFnnFTeNQwACEIAABCBQQAIqYtjY2GC1XT0lU4ywgLhj2/Wypc22eHHdpOMv Ky/zxTCTKpaZildR0GqJ19XVpixyAgIQgAAEokNgkfN3wtwpOuvBSCAAAQhAAAIQgAAEIBBLAt/+ 9rd90btrr702luMv5kHPxhKkp7ffTpxutdbzbcWMhLnNkUBNdZVdf927bLkTsS/ZhGRvaHR07P+3 d+dPcpz1Hcef3Tn3PrSr07J8C58xOFAQYhsbDDFQ5kygqFQIP+Y/SFX+gfjn/JpCSXCoVOw4FhAg seOAgQRzBIzjC1/Ykm1pJa20972b5/OMnnFP78zO1T0zPfN+yuuZ6enj6Vf3rmY//ey3zeLSspmb Xyw/Q4dOHR0Zdn+FkLIhfCuaAnMaAggggEB1gdb8VK7eD+ZAAAEEEEAAAQQQQACBBAs8+OCD5q// +q8TvAfxdv2RRx4xb7zxRrwbiWDtqoM9MT5qy0NQAzgCzq5bxf6pSTM0OLBneK2d7u/vMzlbSiRn A++kNPU1l8u4vielz/QTAQQQ6BUBSoj0ypFmPxFAAAEEEEAAAQQQQKBtAi+88IJ59NFHzdTUlLnp ppvcPTV0E+hOa2lb13hkeNBMTIyZmXOzndY9+tNGgVQqZaZtgK1R2NWabnyeSttSInaE8draerXZ O+J99VUXboI3be+IjtEJBBBAAAFDgM1JgAACCCCAAAIIIIAAAgi0SOD8+fPmqaeecl/apEJsf5Po 6enpFvVi780MDQyYg9NTZvbinNnc3Np7Zt7tCQGFuiobMjI8ZHSRo1pTpdJtW0YkSefP5uam2bR9 TqV2CLGrHWDeRwABBFosUP1fnhZ3iM0hgAACCCCAAAIIIIAAAt0s4G9DpFDwF7/4hfv6xje+YY4d O+ZGZ991113uebsMsnYkqsqITIyNmvP2ho6+v+3qD9ttv4BGJ19x+KDJZmqr2awa2Ct25PXK6lr7 O19jD1ZW1214nTZpO9I8TQmdGtWYDQEEEGiNAAF2a5zZCgIIIIAAAggggAACCCDgwuBwiQIFxJqm Gtn6+t73vmcGBweLZUY0QntoaKhleuqLykRcc+wKM7ewaNbXN1q2bTbUeQIZO+J6et+k2TcxagPe 6rXRdT4ruF5eXknUxY9Cv1dteN1vhocGGYXdeaciPUIAgR4WIMDu4YPPriOAAAIIIIAAAggggEBr BDS6WnWwy7Vygfby8nJbS40oqBwfGzEHpvaZd2bO21IQm+W6zrQeEBgYyJnrrz1W9caNnkIXPFbX 1hJVPsT3XSVPNBI7Y0ea11Lr2y/HIwIIIIBAvAIE2PH6snYEEEAAAQQQQAABBBDoIoGFhQWzsrJi R5cuF7/Cr/VecNr8/LyZnS3cEDEcVpej8fP4kdmaR6VGBmxtagXhraqV3d/fb67VKOz5BbOwuGl2 ynWWaV0tMDSYt6VDDribMdayo9vbO2Z5ZTUxN24st08K4DV6nAC7nA7TEEAAgfYIEGC3x52tIoAA AggggAACCCCAQAsFtre3zdLSUjF0DofM5V6Hp62vrzfcYx9G+8dKKwq+ryBbofXdd99t7r///pYF 18G+5e3o2yOH9ps3Tr/jgsngezzvbgHVgh63ddAP7Z+uuZzGqq17vWYDYAXZSW36WaF9UBA/OJBP 6m7QbwQQQKCrBAiwu+pwsjMIIIAAAggggAACCHSngEYxhwNlvS43LTj62c+zsRFNHefR0VEXKqtG tb4UMOvLv/bT9Ki61XpveHjYPPnkk+Y73/lO2YOj0No3P/p6amrKfOELX3B1sFtZ/9r3Q4/qi74O 7J8yi0vLrozI+galRIJG3fq8z+6YwuvDB/ebnK2HXmtbi6F0SCaTdjeP1GN/v3qmL+Pqayts3tza Mhv2vNRX8HvJzdTg/7bsOlcIsBvUYzEEEEAgegEC7OhNWSMCCCCAAAIIIIAAAghcFlAQtLi4WFJS o1zoXG6aD6KjCJ9zuVzZkNmHz/7RB9H+tX9UiFzLDewqHfgjR47sesuHbT601gx33HGHG2190003 7Zq/XRM0CvXQgWlb13jDnJ+9GFlI2K79YbvVBUZGhs3BA1NmwobYtTSdy6ofrQscCpWbbfqeSKdT LjzPZTNGN5LUa39RRevXNrWtLYXY2rYdNb1m/0pCQXazI8C1vEZha11+u83uE8sjgAACCDQuQIDd uB1LIoAAAggggAACCCDQ1QIKjv0IZv/oQ+Xwa82rQOmv/uqvSsLqZm/+pzrMCo+DI5uDIbMPmMPv ++n+MRgSt+OgBetWyykYxKmP7SwTUovHxPiYWV5dczfnW1hcqmUR5kmogEZcH5ieNNOT4y681W7o nN2xoe66vZmnLkrZl6Fm37NhrwLfZpu+N7I2tNaFk4F81vahfGyh+XRRSV9Ze9NF9Tu7ljGr7jxd b/omkltb27b2+7K9oWPafb8G98tu2m6332TTGdNnR4W3++dLsG88RwABBLpRoPy/BN24p+xT4gR0 xZuGQJIENDqEhgACCCCAQKcIqF5zOGT2r/VYKYgOzqOgqp6mkOv1118vLpKxodLY2NiuMhs+VA6G zuWm6X2NnO6mFgy6OqFMSK22Cuv275twN+dbs3WO1yMqyVLr9pmvNQL9NpnVcZ62XwOX6z+78NoG 1is2GF6yNzBdsyPxNS2ulstlzPDQoL2JYu5yyZDatpSyF7sUeivMTqVWXPjczGhw7aNK55RrhZA9 bYYHVUKoUCc7+L1dbhmmIYAAAgg0LkCA3bgdSyKAAAIIIIAAAgggEIuA6siGA+ZyoXO5aX65esPn 8I7k83kXPvuQORgw+2l69M//5m/+xo1CfPDBB900jZrW6GnaboEbb7zR1bfupDIhu3u5e0o+nzP7 pyZtkLlq3n5nxmzHGGLu3jpTWiEwPDxorjh80IyOjJRsTnWmL80vutHXJW9E/EIXvRReN3PzRJX8 UKisEdSVAuhmu61wW0H++vqm2W9HYWezRCvNmrI8AgggsJcAP2X30uE9BBBAAAEEEEAAAQTqFFD4 HBzF7APleqY1M2pQoXEwWPYBc/Cx2vsKq+sdTejD6gMHDtQp1huzK9C/8847zRe/+EUTLCeStL0f HRkyVxw6YOuaL9tAcyFp3ae/ewioFMeNN1xjw2tdfCrcKFGz6+eRbmi4XedfZOyxqYpvadsD9kJJ sy1ry34MDeXdxRYF2XE1Bdm6oJNKDRbLrcS1LdaLAAII9LIAAXYvH332HQEEEEAAAQQQQKBEYNUG ET5oDgfP4deVRj83Ez5r9OGIHfkYHO0cfh58HQ6l9V63ldwoOUAJfnHs2DHzF3/xFwneg3e7Pjo6 bG649ph59sWXbbC59u4bTTxT4Di9b9JMToyZeVtj+41Tbzextu5cVKHy+OioufLoITO/sGjOzpw3 S8urkeys6jy78Hp4eNdfTiikVcmY+IqGFHZhcDBvb9aYimR/tBIF8kNDA2Z+Pt6a7Ztbm7GWVIkM hBUhgAACCRbos/8Yxf3vUIJ56Ho7Beqtga1TWSOF3AnNad3OQ9cF29aNWAo3q6ln9Bk1sLvg0LML CCCQaAEFzLWGzD6k9o9+uWY+Gis8DobL5Z6Xm+ZDaEpuJPr06+jO1/u5utrO6Ptkc3PLnJ+9ZJ7/ 7auuLna1ZSq9r3IPCq5108Cx0REbYKZdWHpu9qJ5/Xen3br5hdWYXDZrDh+cNkfs6HeNUFZouri0 Ys5fuGjOnps1y/bnX6NNn2EPH9xvrr36qPMPf/7dsDdunL0450pmNLqNWpbbZ28aqZs2+r/mqGWZ vebReaobS56dubDXbE2/p5rdE+OjrvZ2vSvj94d6xZgfAQR6VYAR2L165Ltov31w7cLry8F1+ENX F+0uu9ICAZ1TOpX8eeTPsRZsmk1nIx6KAABAAElEQVQggAACPSvgA+RwoOxf63GvefSefl430jRK TyGyyjoEA2YfLOvRP6/0vupF+383GukDyyCQJAGd6wqep2zgeM2xo+b1N0+bVXuDv3qaRvzuGx8z Ci0VXA/Zm+FpmlraPh6yQXbW1hY+9fYZM9eC2sv19L2V88p6dHjIBczTUxOuPrS2L6tsJmsD37zR iHgFzOfOz5pVe4PNepouGGjU+1Fb91o3Pyzb7I/Wzc34ynBom9offUX5c9Sdp/bmo6pPvWGD7Ab/ iShLEpyoEiVxrTu4HZ4jgAACvSxAgN3LR78L9t0Hi/4X1uAHHk0rfJBo7JfZLuBhF+oRsL8cqNKf ziF/HgXPK3+u1bNK5kUAAQR6QUA/H4PBcvB5udC53DSV7fA/c+s1U7kMhcrj43bknn30QbMPnYOv K72vsh00BBCoT8CFgzbEPnxgyoabG+Yte1PHZVsnuVpTqZAxWyZncmLUjVodHRl2pR785y8t328/ j2lk6sH9Uy4oVzCr0d61rL/a9pP0fj6XtUZj7saZuliQs6+DLWXD2WFbIkOjlkfsjQ9H7A0YZy/O m4uX5u3NBderlvzQRQiNHFZNc928sVLTz+dmbwpbad1+usJrHffgeeDfa+6xzwbjGfcXA43+O1Nt +67GduEXz2qz8j4CCCCAQIMCBNgNwrFY+wX0AUQfcMIfRLbsTUZ0l2zdaEQjQfTnjdv2qrimR/+B qP0O9KBxAZ07KXujq5T98K4P8PrTzHzO1t7LpOwvUv2XV1w4x/y5xjnUuDdLIoBA5wno52C5QLnc tHAw7efR9Eaafp5q1LIC5qmpqWL47ANnHzb7IDr4Ws/1NWxrtfJzuRF9lkEgGgF9/ylUveLwAfe9 eP7CJbOwtORGu4a3oNG9g3aU9bgdbT29b9yN+lWpiErfw5qeSvXZ0iL7zOBA3n7P5+0I44sV1x/e XpJfK8gdsTczVGi93+7/mA359yqrob8i0YWAYTtSWzWyZwYvuBtsLi4tG5WPCf++JBsdN4XXhw9M u1Hw7fbSPtjdjrxpnVq3HaZiv+IZ2CTfeNYcOQcrRAABBBIrQICd2EPX2x3XhwR9qPUfxvzz1dV1 +yeGC/ZO0GvFD8PuQ7Gdt/DBpbfd2PvyAho1oQsdOn8ubs/bX5JyZmxs1I380Ydee7q5c82fZ+6c Kr8qpiKAAAItE9C/gQqRg1+VQuZK82jkcyNN/6YqWNbNBg8cOOCe++C53GM4hPYBdCPbZhkEEOg8 AZWxOHb0sAtRz5674G4wqM9W/jO7BgqM6ueFrXM9YT9jabRtPW3EBrMKsEftRat3zp4zs3aE8era mmnmhqn1bL9V8+ozpgZUDNvR1EePHDD7bGmPrH1da1PwPT42Yq2HXIA9Y0euz80tuBBbVv54yH/S juw+aEfPq3yLlmtn09YLfYinH1p3PGtupxrbRgABBHpLgJs49tbxTtTeVrrZjP/gpUc1fdDTn7TN 2btLqz6e7s5dLmD0yyUKgc7GKlDpnND07e0d+wvAsPtFTKOxg+dbpeW4CUush4uVI9BVAvo5smRH KfpRzMGAudZpaza8aaT5khvhUDn4OjzaOfienlNyoxH57l/mxRdfdJ/Bjh8/3v07m7A9rPS5Oo7d 0OdyhcvzC0v2pn9rNoDNuUBVNx6MYkCJ9mXGhuS/O/W2+4vLrW0F5XHsSWvXqb8KzNpR0UfszRQV XutndRTB8oq9UDm/sOgG+OivUvWXhwqvNaq91uOxbs3PzMR3I0Tl5wreNUJfDlE2BfcqPVOoox5f He/99uKMSr7U2/j9oV4x5kcAgV4VqO/Sd68qsd8dI+CDw2CYqHIhs7Pz7s7b75Z92N3lcqH27rmY 0ksC5c4Jf47pT1b9B90JW6NRH6b1nn/fP/aSF/uKAALvCszNzbm6z+ERz/51+FEhzsLCQjGwbjR8 9kGyRj37Ucx+WrnQ2U/zjyq5QUMgLoEHH3zQrfrEiRNxbYL1JkBApS4GVebHjspWrqyRr+U+czW6 K6qhffjQflsfe5+ZsSVFTr31jpmzAa2rQ9zoStu4nMLbkSHdpHHaHLLlPLK29vde5ULq7WreBuEa 1e0y/ssHJIpgvN5+7DW/LkBs2nA9risRWnc3XOTYy5D3EEAAgW4XIMDu9iPcZfunD78KDtX0XFfU L9oblSzb+pv6oKe39CGQhkCjAv4XLJ1LOqdUO7DPjuqfsKNCCufYuyF2o9tgOQQQaJ+ASmb40c4K mX3QXG7Uc6X3Nzc3696BdDrtymwoSJ6YmCg+98FypRA6+L7qRdMQQACBThfwn6X8Y9T91Xo1Rrff /lzdPzXpRu6qhKBu8qibFy4tN1aXP+p+VlufRt5qJPS+yTFXtzpvR6irtEfUblpf1Oustm+NvK9/ W/3veY0sX2kZrXNjo3wd8ErLMB0BBBBAoPMECLA775jQowoCwQ80+hC2vbNt5heXbcC4Yv/8rTA6 NgkfzirsHpM7TEAXQnTOKbReWFi2o2HSbnSMO/fshRM1zrcOO2h0p6sF9P2okhvlAudy03wgHX4v +G9JrWAql+EDZt1s0D8PhsuVpmkejXqu9c+0a+0T8yGAAAK9LOA/gynw1ZduEDlif9YeOrBmL1Ku mEu27vO5C7NmfaP+C45xuqbt/QOmJifsvVbsDRdtnWuVVdHNFLPpjBswEee2m1m3vHWT842NrWZW s+ey6+sKsPecpaE3tcoNex408u9/rRuUjT8na12G+RBAAAEE6hMgwK7Pi7nbKKAPBRpx7UfB6oPI pUtzLhTQBxI+NLTx4HTppnVO6dxSXfXZ2TmTt39+qVGUfrp2m/OuSw8+uxWpgEY++VHPPlgu9+jn 8aFz8LHRkhs+fB4bGzOHDh0qjnz2gbMe9wqiFT7r3x0aAggggEDnCvgge3howGzamxLqpo/6XeH8 xUsddaPHnA2srz52xN2QUqG7PmMmotluFv4tjC/AVu30dft5QQOTovp3V787qn63bigaZ1N/NfiF hgACCCAQnwABdny2rDligWBIrecaWdHXx8jriJlZXUigEFZrYqEm9r7J8WKATXgdwuJlVwooRA4G yT5kLhdA+/n8PP61filtpGXtRSMFzPv27dszZPZhdDiIHrI1RaP6JbiR/rMMAggggEBrBfTZTGH2 8PCg/fdjwPTbwS7x3bav/n3L2BsoToyP1r9gm5ewRUjsv6cp24uNWHuysrpWGFEfwYVj/b6o2tfL y6ux9lkr119ZyYiGAAIIIBCfAAF2fLasOWKBwkjYQmCtq+j6MMKfZEeMzOrKChRGVPTZmoqr9pcO e/d2fUi9PDqbELssGRM7QEA/MxcXF3fdaNCHysGQOTgt+Fz1orWeRlrO3jRKgbJuNugD5mqjnf18 vuwG31+NyLMMAggggAAC0Qro3+NcLmNWbcDc6OeCWnq0trZu1u3nB5VaafYCtEZfq78KxeNuiRpN HzcG60cAAQRiEiDAjgmW1UYv4ANDfWhaWll1H2r0nIAjemvWuFvAf1hfWVkzQ/bPU3Xe6YMx599u K6Y0L7C+vl4sueEDZf8YHPnsnwff89O0jkabwmeFyZOTk+4xPLK5WhCtkc98bzSqz3IIIIAAAgh0 loBKneRtre5lO7o9znrSW3bE9Ir9PU9lRLS9Rj9LuPDahuG6oaf/DB+HqPqnsF3hfl8Eo8bj6CPr RAABBLpFgAC7W45kj+yHPiRs29BaowLVGv1Q0yNc7GaEAu7cs4G1PlQPDubdmjn/IgTuklXplyT9 fPIhsh79l0LmYNAcfO7n99MaLbkhxnw+724aWC5krjWI5tzukhOS3UAAAQQQQCACAX0uyNj7wEyM j5i5+UVbV7r8TRGjCItXbfCcsqVWFGJrm2q1fi7R9vV3Yxp1vbi47MJ2t4Im/1du+5qWtYH+xNiI SdvHcvM0uVkWRwABBBAICBBgBzB4mgyBPvvBZHOTka/JOFrd1Ut9MN1wtXxtlTv7PIoP6d0llOy9 0WidpaWliiGzD5f9ow+dwwF1MwoKmHWzQV9Kwz+Gg+fw62BYzS9QzRwBlkUAAQQQQACBSgIqlTFl 7wezaT8P63NT+LPwmr1h4tLSitFI6kab1qnwWTdf1E05B+1nI/uxu6a2ZfukZZftgJMobtyoz1Sq p57L2hHWgT5oukqcaPQ1n7tqOjTMhAACCDQtQIDdNCEraLmA/cCgD0xqfGBouX5Pb1Dnmy6eFD6s Bz7F9rRKZ+z82pqtcWhHOAfDZP/cB82V3vfTN+yd75tpCpV1s8FKoXMwZC43j5bnZ1ozR4BlEUAA AQQQQCAuAf8ZRY8Z++XukGHD5mBLp1Une72pANuvb8MG2HM2KFcgns/n7FfW3uAxY/rttoNNn8sV nKt0mkr9bWxu2t8VS/sVnL+e5ykbUo/aANvve3FZ2wf1Ytf04gw8QQABBBCIWoAAO2pR1tcSAQXY 3MCxJdRsJCCgD8g69/r6ovlQHFh1zz6VqQ+Yg4/lnvugWe8F39d0f1GrEUj98qGyG6Ojo4TPjQCy DAIIIIAAAgj0lIA+O7kYORAm6zNdOqXPVDkXYDdTDk2Y+rStkdz60ohvlQXRqGcF2P22vIi2r/e0 XY283r48n5aNomlb+YEcv3NGgck6EEAAgQgECLAjQGQVrRfganfrzdliYZRF4XN66ciPXrVRaKyS Gz5Q9qFyMGgOPi/3vq9n36ihfhYEy2kEn5cb8VxumpahIYAAAggggAACCDQu4H8/G7ABtsp/NBtg B3vig2w/TTeVVItqpLVfb/BRNbgHBwr3vQlO5zkCCCCAQHsECLDb485W2yigq/T6gKVHWu8J+GPv P2T3nkBhj1VywwfPwZDZP/ePPnQOzuvfa7bkho7B0NBQSQBdrrRGudDZTyN87tUzmP1GAAEEEEAA gU4U0I0NVTNanxMVPMfR4gyu1V+F17lc1u1HHP1nnQgggAAC9QsQYNdvxhIJFwgGmK4MiYJsBtQm /KhW6b6uVdiwVCNB/AWMKkt07NvqfzhUDr724bJ/DAbPwfmavYCjP6tU+OwDZx8oB1+XmxYcIa2y HTQEEEAAAQQQQKAXBAqDJ7r/lw7tZ96Gvxsbm+5mikk8ttls1o2+LhyzJO4BfUYAAQS6T4AAu/uO KXtURcAHmAoz5xcWbS01+0GSwdhV1BL+tj3EGqkxNDjg6tj5c6DVe6Vzzpfc8AGzf6wUNIff18jp ZlswfA4Gyj58rmVaLpdrthssjwACCCCAAAIIxCKgCs1pO4q2kwap2FzXjeyNZYc7bKUavay61bqh ooLsJLVMOm0GbP8VwtMQQAABBDpHgAC7c44FPWmRgMLLdCplFhYXzQu/fdX9edg25URapN+ezehm L2tr6+bm49fZG/WNmE37YbrVIyr0Z5Rf/epXmwbQXw1UG9lcLYgmfG76MLACBBBAAIEyAidOnCgz lUkItF5AYXEun23557299lQDCFReo1eaAuCtzS1zaWMxUbusGt76oiGAAAIIdJZA7/wL2lnu9KaN AgouFWLrQ6SCvKyt0abXtO4VKITV9o7l9pi3a/R1JpOxd2XPGz36gLmRIFp/0khDAAEEEEAAAQQQ qCygz3yTE+P2s9+pyjO1+J2s/Qw4bgdS9ErTMcjbIHjYjsReXFpJxG4PDw3az+l506/R+zQEEEAA gY4SIMDuqMNBZ1ol4Eff7uxsu0CTALtV8u3bjo61mj/27ejJ17/+9XZslm0igAACCCCAAAI9JaDP e4MDeTM2MmwubM65+6C0G0ADZ/btm2h3N1q2fR2DPluqUUF2UppG7rt+6wkNAQQQQKCjBJLzr0lH sdEZBBBAAAEEEEAAAQQQQACBThRQCJmywemxKw4ZjarV63Y29eHQ/ikXqrezH63ctgYIbW5smVVb xi8pbW19w9XtZnBTUo4Y/UQAgV4SIMDupaPNviKAAAIIIIAAAggggAACPSIwOTFmjhza70p3tGsk sMLrwwemzf7pSXcfnh6hdzdxVHi9bkPhpDTdcFJ93rC1u2kIIIAAAp0lQAmRzjoe9AYBBBBAAAEE EEAAgUQKvPjii26k6/HjxxPZfzrdfQK6+fVBO/I5k06b8xcumoWlJbO8suZu6B3n3mrEt0qYDA0O mqnJMTNlS4foda+0bTv6em1tw4bBa4naZY281o3fdb6kbR3sdl30SBQanUUAAQRaJECA3SJoNoMA AggggAACCCCAQDcLPPjgg273Tpw40c27yb4lTCCfy7pR2BqNPXtxzlyYvWSWllfM1va22b785Z/X WzrCVnm2IWehzrPCTn2lbPCZyaTN1MSEmZ4qBNe9FoRubmok85rRiOakNfV5bX3d5LIZk83yB+tJ O370FwEEuleAALt7jy17hgACCCCAAAIIIIAAAgggYAUG8jkXZB8+OG1HYG+ZldU1F7JqxK3CVpWO 0HRjdmr2Up3tbDZr8vYGjfm8HrMml8+bvA0/2113u+adiGFGBcAbG8kpHRImcCG2PR+y9jjSEEAA AQQ6Q4AAuzOOA71AAAEEEEAAAQQQQAABBBCIWUDBskZI62t0ZCjmrfXm6ne2d4ytxpHYppH5m9vU wU7sAaTjCCDQlQL8TUxXHlZ2CgEEEEAAAQQQQAABBBBAAIE2CNiLBMluKg6T9H1I9hGg9wgggEBY gAA7LMJrBBBAAAEEEEAAAQQQQAABBBBoSED1ozXCPaktk0m5kjBJ7T/9RgABBLpRILn/qnTj0WCf EEAAAQQQQAABBBBAAAEEEEiwQCadNoMDeXuTzB2jGuONNpV7yWa1rgGztVUo6bFpH7VejY/WDTRT qZRbveqRq6752vqGLV/SeP0S1b1W37MZ6l83etxYDgEEEIhDgAA7DlXWiQACCCCAAAIIIIAAAggg gEAPCvTbMFk3tFTInLIh88rqekOhcjrVb4YGB1yAvb2z7SQVZPt8WgF3ys6j1t/Xb/pSfWbL1q/W TRjrbeqzRo4rvM7ZG3LqNQ0BBBBAoHMECLA751jQEwQQQAABBBBAAAEEEEAAAQQSL6CR0fl8zo2Q Vhi8trZhNjZrD5YLo68zZiCXcyOt+01hpHX68ojrckB5O++63Y5Cbo3SrrWl7YhxBe5u5LUd8U14 Xasc8yGAAAKtEyDAbp01W0IAAQQQQAABBBBAAAEEEECgJwQUBKskhwLilZVVs7S8YjY3t9wo6WoA qqHtAvB0IbiuNr/eV7idt6OnFZQrMK/W1L+0Xb9GeQ+4sN2O4k78DSir7TXvI4AAAskUIMBO5nGj 1wgggAACCCCAAAIIIIAAAgh0tEChzEefGR4edKOcF22IrVrVCrIr1arWMhoRPZDP171vuWzWrGc3 zcb6ptn2tUZCa9H6FVxrG8NDAy5gJ7gOIfESAQQQ6DABAuwOOyB0BwEEEEAAAQQQQAABBBBAAIFu E0jZ0Hh0ZNiV6lheXTXLy6suyA7v54AdRa0R0Y0Mhtao6oGBnCsjsmTXH24KrvW+yoVk0pmGthFe J68RQAABBOIXIMCO35gtIIAAAggggAACCCCAAAIIINDTAhrlrFBa5UFGUoMupNYNF9fsTR43bN1q vadR0SodUgiXdRvI+pq2kclk7IjvIVd/e229cAPJdCptcrlMoaSJLTWioJtR1/XZMjcCCCDQTgEC 7Hbqs20EEEAAAQQQQAABBBBAAAEEekhAwbFu8lioQZ02WRs4u3IiNq9O9afse82Fy/0KsW3d7dSQ DcntaGtj7+dY2GY/wXUPnWfsKgIIdJcAAXZ3HU/2BgEEEEAAAQQQQAABBBBAAIGOF3ChssLsbH/k fe3v77NhdcrYGDvydbNCBBBAAIHWC0T/L0Xr94EtIoAAAggggAACCCCAAAIIIIAAAggggAACCHSh ACOwu/CgsksIIIAAAggggAACCLRa4MSJE63eJNtDAAEEEEAAAQQQ6AEBRmD3wEFmFxFAAAEEEEAA AQQQQAABBBBAAAEEEEAAgSQKEGAn8ajRZwQQQAABBBBAAAEEEEAAAQQQQAABBBBAoAcECLB74CCz iwgggAACCCCAAAIIIIAAAggggAACCCCAQBIFCLCTeNToMwIIIIAAAggggAACCCCAAAIIIIAAAggg 0AMCBNg9cJDZRQQQQAABBBBAAAEE4hZ47LHHzMmTJ+PeDOtHAAEEEEAAAQQQ6DGBdI/tL7uLAAII IIAAAggggAACMQj48Pozn/lMDGtnlQgggAACCCCAAAK9KsAI7F498uw3AggggAACCCCAAAIIIIAA AggggAACCCDQ4QIE2B1+gOgeAggggAACCCCAAAIIIIAAAggggAACCCDQqwIE2L165NlvBBBAAAEE EEAAAQQQQAABBBBAAAEEEECgwwUIsDv8ANE9BBBAAAEEEEAAAQQQQAABBBBAAAEEEECgVwW4iWOv Hnn2GwEEEEAAAQQQQAABBHpCIJfN9MR+spMIIIAAAggg0J0CjMDuzuPKXiGAAAIIIIAAAggggAAC CCCAAAIIIIAAAokXIMBO/CFkBxBAAAEEEEAAAQQQQAABBBBAAAEEEEAAge4UIMDuzuPKXiGAAAII IIAAAggggAACCCCAAAIIIIAAAokXIMBO/CFkBxBAAAEEEEAAAQQQQAABBBBAAAEEEEAAge4UIMDu zuPKXiGAAAIIIIAAAggggAACCCCAAAIIIIAAAokXIMBO/CFkBxBAAAEEEEAAAQQQQAABBBBAAAEE EEAAge4UIMDuzuPKXiGAAAIIIIAAAggggAACCCCAAAIIIIAAAokXIMBO/CFkBxBAAAEEEEAAAQQQ QAABBBBAAAEEEEAAge4USHfnbrFXCCCAAAIIIIAAAggg0EqB48ePm/5+xse00pxtIYAAAggggAAC vSBAgN0LR5l9RAABBBBAAAEEEEAgZoG//Mu/jHkLrB4BBBBAAAEEEECgFwUYItGLR519RgABBBBA AAEEEEAAAQQQQAABBBBAAAEEEiBAgJ2Ag0QXEUAAAQQQQAABBBBAAAEEEEAAAQQQQACBXhQgwO7F o84+I4AAAggggAACCCCAAAIIIIAAAggggAACCRAgwE7AQaKLCCCAAAIIIIAAAggggAACCCCAAAII IIBALwoQYPfiUWefEUAAAQQQQAABBBCIWOCxxx4zJ0+ejHitrA4BBBBAAAEEEECg1wXSvQ7A/iOA AAIIIIAAAggggEDzAj68/sxnPtP8ylgDAggggAACCCCAAAKXBRiBzamAAAIIIIAAAggggAACCCCA AAIIIIAAAggg0JECBNgdeVjoFAIIIIAAAggggAACCCCAAAIIIIAAAggggAABNucAAggggAACCCCA AAIIIIAAAggggAACCCCAQEcKEGB35GGhUwgggAACCCCAAAIIIIAAAggggAACCCCAAAIE2JwDCCCA AAIIIIAAAggggAACCCCAAAIIIIAAAh0pQIDdkYeFTiGAAAIIIIAAAggggAACCCCAAAIIIIAAAggQ YHMOIIAAAggggAACCCCAAAIIIIAAAggggAACCHSkAAF2Rx4WOoUAAggggAACCCCAAAIIIIAAAggg gAACCCBAgM05gAACCCCAAAIIIIAAAggggAACCCCAAAIIINCRAgTYHXlY6BQCCCCAAAIIIIAAAggg gAACCCCAAAIIIIAAATbnQE8K7Ozs9OR+s9PGcOw5CxBAAAEEEEAAAQQQQAABBBBAAIHkCKST01V6 ikA0Agow+/r6XJC5vb1ttu3rnW0C7Wh0O3MtffZSnY518NjrHKAhgAACCCCAAAIIIIAAAggggAAC CHS2AAF2Zx8feheDgA+v9ZjJZE0mnWJUbgzOnbRKd8y3s8ULF4TXnXR06AsCCCCAAAIIIIAAAggg gAACCCBQWYAAu7IN73SpgMLLLTsad2hw0Nx+y3vsXmr0NaNxu/RwX96twjF2I+7tsSfA7u6jzd4h gAACCLRH4Pjx46a/nwqF7dFnqwgggAACCCCAQPcK9Nk/qad2Qvce30Tv2dr6Rkn/ffkHhZBvnj7T 8C9Ifj2c+iW8PfPCjca+XEamkZ3etuVmrrzigDv//Lnk15PLZvxTHhFAAAEEEEAAAQQQQAABBBBA AAEEIhBgBHYEiKwiWQJ+9K1/TFbv6W0UAhz7KBRZBwIIIIAAAggggAACCCCAAAIIIBC/AH/jF78x W0AAAQQQQAABBBBAAAEEEEAAAQQQQAABBBBoQIAAuwE0FkEAAQQQQAABBBBAAAEEEEAAAQQQQAAB BBCIX4AAO35jtoAAAggggAACCCCAAAIIIIAAAggggAACCCDQgAABdgNoLIIAAggggAACCCCAAAII IIAAAggggAACCCAQvwABdvzGbAEBBBBAAAEEEEAAAQQQQAABBBBAAAEEEECgAQEC7AbQWAQBBBBA AAEEEEAAAQQQQAABBBBAAAEEEEAgfgEC7PiN2QICCCCAAAIIIIAAAggggAACCCCAAAIIIIBAAwIE 2A2gsQgCCCCAAAIIIIAAAggggAACCCCAAAIIIIBA/AIE2PEbswUEEEAAAQQQQAABBBBAAAEEEEAA AQQQQACBBgQIsBtAYxEEEEAAAQQQQAABBBBAAAEEEEAAAQQQQACB+AUIsOM3ZgsIIIAAAggggAAC CCCAAAIIIIAAAggggAACDQgQYDeAxiIIIIAAAggggAACCCCAAAIIIIAAAggggAAC8QsQYMdvzBYQ QAABBBBAAAEEEEAAAQQQQAABBBBAAAEEGhAgwG4AjUUQQAABBBBAAAEEEEAAAQQQQAABBBBAAAEE 4hcgwI7fmC0ggAACCCCAAAIIIIAAAggggAACCCCAAAIINCBAgN0AGosggAACCCCAAAIIIIAAAggg gAACCCCAAAIIxC9AgB2/MVtAAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQaECAALsBNBZBAAEEEEAA AQQQQAABBBBAAAEEEEAAAQQQiF+AADt+Y7YQg8DOzk4Ma2WVCFQRsKdd4dzj/KsixdsIIIAAAggg gAACCCCAAAIIIIBAJAIE2JEwspLWCuyY/r6+y0Fia7fM1npcoK9w7pmdvh6HYPcRQAABBBBAAAEE EEAAAQQQQACB1ggQYLfGma1EKLBjw8NUOmX6bIhNQ6ClAu7cS9v8mnOvpe5sDAEEEEAAAQQQQAAB BBBAAAEEelaAALtnD31yd1zBdSrVzwjs5B7CxPZc5UNSqT578WSH8y+xR5GOI4AAAggggAACCCCA AAIIIIBAkgQIsJN0tOirCw0VHmazWadBLWxOilYJuHPNnnu5XNrYB/4CoFXwbAcBBBBAAAEEEEAA AQQQQAABBHpagAC7pw9/snZeAWKhbEifGRzIm+3tbULEZB3CRPdW55495ey5N6D02l1M4QJKog8p nUcAAQQQQAABBBBAAAEEEEAAgQQIEGAn4CDRxYKAAkQfYucyaZOxX3pNiMgZEreAP89y2YzJZjLu wok/F+PeNutHAAEEEEAAAQQQQAABBBBAAAEEelmAALuXj37C9t0H2C447O83E+OjxVHYhNgJO5gJ 6q4Pqnd2ts34+HBh1L+9cKJW+IuABO0MXUUAAQQQQAABBBBAAAEEEEAAAQQSJkCAnbAD1svdfTdI LJQSGRjIlZQSIcTu5bMjnn3359zW1rYZGho0+Xy+ZPQ151w87qwVAQQQQAABBBBAAAEEEEAAAQQQ 8AIE2F6Cx44X0GhX/+WCRdNnJibGXCkRXw+bQLHjD2NiOujDa51buVzGjI+Nmv7LZWzsiVg8FxOz Q3QUAQQQQAABBBBAAAEEEEAAAQQQSKAAAXYCD1ovd9mHit4ga+tgT4ZCbL1HkO2FeKxXwJ87ulii kdcZW/N6ctJeKEmniueV3vPz1bt+5kcAAQQQQAABBBBAAAEEEEAAAQQQqF2AALt2K+bsAAEfHOpR TSHioC0lss+G2Llc1mxubrlp/v1glwkcgxo8l0C5c8KfYzqXVKZmnw2vB7LZ4rz+/XLnGKoIIIAA AggggAACCCCAAAIIIIAAAtEKpKNdHWtDIH6BYICoAHJ7e8cM5HMmlUqZ+YUls7yyajY2Nk1/f2mZ h24MHLX/5ULY6I+CLLvvpoXBc8Jb6nzKZdNmdHjQjIwMu5HX24GbNmq+4HLRW7NGBBBAAAEEEEAA AQQQQAABBBBAAAEv0GfDmB3/gkcEOklgbX1jz+74INGfwj5UXF5eNatr6zbE3jDrNshWDWN9FeYr jNzec8UJeFNhsvYnk06btP2Ku+mHxObmphvhXth23Fts1fp37IWOfnexQ4/ZbMaoLE3ejuYfsDds 1H4Hzy899+dZuR7m7PJxN53XZ86cMefOnXObOnjwoNGX+k9DAAEEEEAAAQQQQAABBBBAAAEEuk2A ALvbjmgX7U+1AFu76gNFHzJqmoI8XZZR0LdhQ1c3etaOqtXj5cojmi3RbWfb7meqz5yZOW8uzM5d dohnl2Sp0ezT+ybs16Qb8e4cu+BagN83hdI6bzI2vNZFATVd9PBN7/tzzU8r9xhXgH327Fnz9NNP m5mZmZJ+Bfug/h8+fNjce++9Jm/D973a17/+dVvfe8vNMj09bT772c8WZ7906ZJ55JFH3P5q4nXX XWfuueee4vtJerK0tGRWVlbM1NRUU90+ceKEu4CjleiC0de+9rWm1teOhaOyaEff2SYCCCCAAAII IIAAAggggEBvC8Q/dLO3fdn7mAXCwaJCRh88aiStCxQvp9ZdkLc6TVs0xO6jsaOFU+aZ514yM+dn 3ajguPZPo5B1RUAh9nuuv9rowkKqi0b7uv3TWGv7ny5y+PNHu+1HW9cSXmv+qNvy8rI5efKkWVhY qLpq9fv06dPmG9/4hrnqqqvMfffdV3EZjab3TQFvsK2vr5cYhN8PztvJz5966inz0ksvmQMHDpgH Hnigqa7Ky18kC9o1tdIWLhylRQu7zaYQQAABBBBAAAEEEEAAAQQQcAIE2JwIiRcIh4waVas00o28 LrxI/D4Gd8AHabMXl8zS0rKr0ZzqTyl/jaUpGNdo3bn5RTO/uORGKCss9e6xbLTNKy1c83h31HU7 9vW1114zTz75ZEmYXAuLzo/XX3/dfOc73zGf/vSna1mkq+ZRwPzQQw8ZBfG93rDo9TOA/UcAAQQQ QAABBBBAAAEEukOAALs7jiN7YQV8yOjDx25FUUCZTvebs7Z8yJYtjWL3/HJ5lHjGYLsLARZ1Y3PL lSy56orDl7f7rnm3WvtzqtX7d+rUKfPEE0/s2qxuVHrs2DE3qlgji3UuvPPOO0Zh9/nz50vmf/vt t82///u/m0984hMl07v9hYJrwuvCUcai28929g8BBBBAAAEEEEAAAQQQ6A0BAuzeOM7sZZcIKLDU V19fypw5d8HV5VXt4ziDVr9ujeacOTdrrr/6SrO5uu5qRncJa0fthka7P/7447v6dPPNN5sPf/jD u6YryL799tvN7Oyseeyxx4q1mjXjG2+8YRRkqzZ2rW3//v0u9NZ5pqbXNAQQQAABBBBAAAEEEEAA AQQQQKBdAv3t2jDbRQCB+gR8oKha1HNzC2ZpuVC72AfM9a2tvrm1DY3EXlhYMvO2bIn64PtT35qY u5qASn+E6yz/wR/8QdnwOriuyclJ8/nPf37XhYWf/OQnwdlqeq5R3lfZOtr6GhwcrGkZZkIAAQQQ QAABBBBAAAEEEEAAAQTiEGAEdhyqrBOBGARciGxrT6fTKXP2nC0fslWoQ10YkR1P+RC/G9pGf1+f WbejsFW65KqjtoyI3b5aKwJ0349uf1Rwffbs2ZLdvP76680tt9xSMq3Si/HxcfPe977X/PKXvyzO cvHiRTM/P29GR0eL0+J6cuHCBaPyJxMTE+bKK6+M5NzQyHKNJD906JA5ePBgXF2Pdb26Geerr75q hoaG3EUB/dVEvW1mZsacOXPGZDIZV0amFRcW1O8333zT6DGXy7ljoAslzbQoLLT9S5cuue8VrU9/ JaDzoxHXjY0N87vf/c6srq66YzMyMtLM7rEsAggggAACCCCAAAIIIIBADAIE2DGgskoE4hBQiFwI q/tdLWqFnXGXD/H74UPqzc0NMzNzwVx/jS0jsrnWUGDk18njboFf/OIXJRN1fO++++6SadVe3HHH HebXv/61u/Gm5s1ms64+dq0B9tzcnHn44YeLm7nuuuvMRz7ykeLr8JOf/exn5oUXXjBra2vht+zF lrQLFv/oj/6oYpj99NNPm2effdYtq3D2q1/9qnn55ZfNz3/+c3uT0qVdI/0VpKqUivoVbArtf/Wr X+2aX6Hv3/7t37pZp6amzGc/+9ngYpE8V8j+6KOPFtelkfDa9+9///v2rxYWisfCz6D3brjhBvOH f/iHflLZR+3Tc88958LV4Aw/+tGPnKeO7dVXX23uvPPOEt9GLVQz+z/+4z/c+aJgVz9vwk0/C6an p80nP/lJd26F34/LQtvRuvUXBTqm5fomD53/t956a7hbJa8XFxfNd7/73V3H5n/+53+c48DAgLnr rrvcRZiSBXmBAAIIIIAAAggggAACCCDQFgEC7Laws1EE6hPwYY0Czbm5ebO8UggLfbBc39oam1vb suWZXQmReVtKJGfDokKgHu/o78Z6m8ylXnnllZKONzqq9J577jEKIDV6u95RqQqit+1If980wrVc W1lZMd/+9rfdSNhy72uaLrJoRPbf//3fm/vvv9/dfDI8r9bvt6cA9Te/+Y356U9/Gp6t+Fr9e/LJ J92o7I9+9KPF6cH1FCdefuLXX2lfwvPX+1r99tvQsgpYFYaqnnm5Jpfnn3/e1Sf/3Oc+50ZVh+fT DTg18rxS0/eeLF588UV3E88vfelLRsGrWiMWunhS7gJAePvarkaD/8M//IO7sBG+kBCHhfpQ7bzQ PNq23GUrj3LtmWeeMbro4n+mhufRdPnp4sO1115rgudYeF5eI4AAAggggAACCCCAAAIItEag/r9j bk2/2AoCCAQEFB4rWEmlCuVDNm0w5qcFZov1qbav2tcbG7bMhb2BpK+DXSkIirUzXbpyhcLBppGu jbRrrrnGHD9+vO7wutZtKRz/5je/WTa8LheYK1g8efKkCz732obOpb3C6+CyKsmh8ha+6XujWivX t2rLNPL+j3/844rhdXB9KoPx1FNPBSe55xqVXi681j6W20/5KnD1rdw8/j3/GLTQRYb//d//3RXq 6meM1qXHcFNgr/2s1pq10Pr1FwWVzoty+6q/ItDFlXCTtWzDP7O0f0EPv5zOseDIej+dRwQQQAAB BBBAAAEEEEAAgdYKMAK7td5sDYGGBBS46KvPBshnbAmPDTuCM2VHY5cLlhraQA0L+W0pvJw5N2tu sGVElikjUoNc7bOEg7Urrrii9oVbOKdGB4dHF2u0t8qd+CBQZUAUGAbne+KJJ8xXvvKVmnqqkicq FSIDlY74v//7P/PSSy+VLKswUrW21XSjS31p9OxDDz1UnE91sx944IHi61Y+UUmUD3zgA65ciEZd ax80kjhoovrL4aZR1cGmixEqN+LDWn0PPv744+b06dPF2c6fP1/4GWHD2HotwuFwPp93x1I38/RN pVB0/M6dO+cnuRHPOs469tVaoxYaZV6utI7OjRtvvNFtVh4qffLWW28Vu/HOO++410eOHHHTVDYk 7Kr9/PjHP16sra6SNf/1X//lRsb7FclVx+iqq67yk3hEAAEEEEAAAQQQQAABBBBosQAjsFsMzua6 V8CHjz5s3t7esWUFIvpSeN3Xby5enDPLq2tG4yF9oNxKUW3TdsUsLC6ZS/NL6oQrnRDZflov76f9 8qat3Md2bUujRsNNJUQ6rSnQe/vtt0u69alPfcqobIkPr/WmQk2F1apL7JtCRIW41ZqC0y9/+cvm 6NGj7jzft2+fC1RV3zjYNIK5U5tusvi1r33N3Hzzza5EiMp7vP/97zef/vSnS753FWYHg2i9Vmjr m+p268KAD681XWFwuAa1vlc0irreptBWN/r0TdtR+Y1geK33dHNDlTvRsQi2cgF88H09b9RCy/7g Bz8oKc+i+uE6r3x4rXnkoXPw8OHDellswZuZ6qJLsOmGp3/2Z39WDK/1nm6yqePzvve9Lzir+eEP f1jymhcIIIAAAggggAACCCCAAAKtFSDAbq03W+tCAR+4FsJdf6PFPnsTt5TJ2C89Nv1lR1vnc1lz 7vysrSvc+vIh/rBpXzUKfF2jsM9fcH3SSPCm9y9gFXb0vr4P3fp44cKFkl1TkNiOixQlnSjzIhzm qU6wH+Uanl2h7b333lsyuVrIqv2+7777SpbxLxRgK6z0TedGp7aPfexjZbt24MABs3///pL3NMLc t3Cd7vBrP58eP/ShDxnd1HJsbMwdg3C4HJy30nN/A03/vm4KqXVWau95z3tK3lL5kmqtUQutVyOp g+33f//3XSAenOafazR1sPnR4ro4FPz+0oWWvUblaxsK7H3TBQWNNKchgAACCCCAAAIIIIAAAgi0 R4ASIu1xZ6tdIuACXTsKWW1ra9ukU/2m34axC4vLZn5h0Y0cjCKE1HYymbQ59c5Zd2M8BTBRrLfe w6Bt2jHYbl/fevusGbB/gq/SCFH0RfvY358yoyNDZnR40G1j05qmrKla0Lrefidh/uDoZfU3CtM4 9lulJILtzjvvDL7c9VwlPhQ6q8yDWrXAU3W/wxbBlWo0b3C0umox7zV/cNlWPdeoc5UuqdQmJyfN 2bNni297G01QcKoQ35cZUYCtGyYqvL/ppptKzguVFtFXM+2DH/yg0ZcCXt18Uhck9moKy4PN9zM4 Lfi8GQvte/B80Xl02223BVdf8lzbuvXWW90yulDgy8ucOnWqZD6Nalf5kL2aXIOlSxSk11IqZa91 8h4CCCCAAAIIIIAAAggggEBjAgTYjbmxFAJOQCGjglV9ZbNpM3tp3rz86huuxIYCbftOZFLa1tra ugvr2hluKsJWuzS/aH7z3G+j3Ue7bgXWoyPD5jpbY3tyfNTdNFL72859juwg7rEihWrBpmC2E1sw bFX/VOKhWguGnNqvvULncEAaXndwBLbeU3/2GjEcXr4Vr6uFo+H3gz7q38TEhFGpFt9WV1fNT37y E/elMhcqlaGgNnzO+PkbedTo7fAI7vn5eaPwd2ZmxpUZ0YWD8PGvtq3wvobnD78ftNB2g037Xq1p VHq4+ZHYfrpK2ahm9l4tGJxrvmCZlb2W4z0EEEAAAQQQQAABBBBAAIHoBQiwozdljT0ioNBaTWGc QrU3T58xL778mlleWS2MFtYoaft+FBG2W48boVwYed3O0cg+SFYfVuyf1ke6j/KynovLK+bS3Lx5 z/XXmKNHDroQ23K65rdfeNU9/x8eHi7ZmU4MsBVe+vPed7aWGsh+Xv+oGtqVblCp8HavloTjr1Hi e7VqI8Y/8YlPmEceeaSkFrZfn2pWq5yFvlQPWiO9ddNG1XRutmkE9n//93+7Ee71BtWVtt2MRXCk vdZfS4Bdrh/hWuka2V3veSt3GgIIIIAAAggggAACCCCAQHsEqIHdHne22gUCCtIUMuZtvdgzM+fN 8y+9YhaXVtyf/ytYUm1oBVV6bPbLredyTeR2htc6bNq+70Pk+2itnJ29YaUsZXr23HlXa1vWSQgv mzm1w8FmvSGb3/bKyor59a9/bcLlPvz7jT4q4IyiBUcXh9enutlJb8EbVzayLwpq//RP/7RqKK3y PboB5MMPP1zTzTEr9UXr+ad/+ifzrW99y438jiq81vaasQjX/64Whlfav/B6Ks231/TgjTX3mo/3 EEAAAQQQQAABBBBAAAEEohdgBHb0pqyxRwQU4qpW7bINC0/b0dcaNawbLdrJxYA3Dop2h7hxb9+H 4yrJsmRtT1nb8dFRVwPcvxeHayesU/WPg6NOX3zxRXPVVVfV3bWf/vSnboTuz372M3eOarSzRvU2 24I3ttO6dC6M2mNTb1MNaNreAvrZ8id/8idGo4d/+ctfmrfeesuolEi5pu8LjZzW+7oBYb3tn//5 n43KapRrOsYq0aK/EFDpEn19//vfLzdr5NPCI651YaaRFi47o/XqQlk9LXzu17Ms8yKAAAIIIIAA AggggAACCDQnUN9vcM1ti6UR6CoBhUa6seLZmQvm/KU5k7GBiKbZWK/rRwrHeSB9QC7LlL2p48X5 BVtve8Ec2j9l1jd0w8g4t97edV9zzTXmV7/6VbETunFcI+2NN94oLqaawpWCz+JMNT4Jl6lQCPil L32pxqWZrREBmX/0ox91i+pYPvfcc+bVV181s7OzxRs9+vXqgke9AfYPf/jDXeG1wlrdxPC6667b dYFC225VO3LkSMmmahlJrdHjuiGlbuLof5boIkuwjIhuhvne9763ZN28QAABBBBAAAEEEEAAAQQQ 6FwBAuzOPTb0rMMFFLD29/fZUhdL7kulRJRfd3PA2spDsrOjGzqmzJwNrxcWFs2Rg9PFCwSt7Ecr t3X77beXBNgK43Tzvg9/+MM1d0NlR8I3oPvgBz9Y8/LVZlRorZITauqfvg98UFhp2ddee82Firrp 4KFDh0z4xn2VluvV6SqxopsnKnS95557igz6frjtttvclyZqhL1KxfimgLeW4+Hn16PqkQfb0aNH zf333x+cVPI8fENEbS+uFr6pZC0B9re//e3iDTBVkueBBx5wN6d88803i93UhaFqAbZKhshWo7VV ZzzKG2YWO8ITBBBAAAEEEEAAAQQQQACBmgQIsGtiYiYEdgsotOuz2c329o6rhV0I8eILc3b3oLun 6EKATFX7ulD/Wq+721elDjRy9OzZs8WD+/zzz5trr73WhWjFiRWeqOb1E088UfKuwmKtM6qm9QXL TTz++OPm4x//eMXVK0z/z//8z8sXHwqzff7zn48tEAyH6XEGrBV3uok3/vVf/9UEQ+Jjx44Zjcwv 1z7wgQ+Y3/72tyYY7Gr0sQ9ba7EIHktt49577y23qeI0XYwINn1vxtkU2mvkuZr+kkDBvkL2Su3i xYvFt3Ts9+/f7y7oBP+ywZdj2etCyg9+8AMT/EsGjYRXSRcaAggggAACCCCAAAIIIIBA6wW4iWPr zdli1wjYmxnagFVlRBQ8Ji0oS8JhkKlKs2jUrx3na42T0Ovm+qha1cHgUQYaVfrSSy/tueKZmRnz L//yLy7sD8546623Bl82/fzmm28uWYdGfGvbldr3vve9ku8NhYY+YK20TDPTw6FklDckbKZftS4b Lpvx9NNPV1xU50b45oLBUcu1WATPNW1or0D63/7t30ouXlSbv2LH63gj7PGjH/2o4tJ6z4fdmmls bMzNqxrwwZtJyu273/1uxfXofA6O2NaMUX8fVdw4byCAAAIIIIAAAggggAACCOwSIMDeRcIEBGoT UIkLhT35fM4MDuRtSLddEtTVthbmqiSgkGl7e8uMDA+Z4aFBG0xtlwS7lZZL+nSFjrfcckvJbshC tYofeughV2JkyZatUVN4+fLLL5uTJ0+axx57bFfpEAV31UollGyohhe/93u/527oF5xV21Y5i2BT 3771rW+VjCbX++EAPLhMFM/DgaxqResmiAokVZqj09v73ve+ki5qVP2jjz5aMspaM+gcePjhh0sC W507wf0PPtcy5SzCIbdGgIdDf43wVnitkcvhFp43/H6zr++77z5bqundjyoaMa7vA/894Nf/4x// 2Lzwwgv+pXsMhs533313yXs6F775zW/uCuQ1ol3nrb7nfNMFtBtvvNG/5BEBBBBAAAEEEEAAAQQQ QKDFApQQaTE4m+seAZW42LA3FTwwPWXO2Bs5vvq7N22QPeBC7XBw1D173Zo9UXik0Gp5Zc1ceeSw mdo3Uay73JoetHcrH/rQh1yIqJvyBZuCxJ///OfuKzi93HOVPPjkJz9Z7q2mp33sYx9zgXlwRaoX /Mwzz5icrQWvVu7GkerTHXfcEVwsluc6d4IjiRVgq2kU7p//+Z+75536P4WlV199tXn99deLXVTY qtBW/deXQuPwyGvN/P73v7+4jH9SzULb0o0hfVNA/Hd/93du9LJ+jilA9zXP/TzBx3LHOfh+s89V QkQXTYIlQPR98I//+I/uL1/01y/qQ/B4a5sauR0MnbWfGp2uEiu+aV8VYstcrip3U25fg3XI/bI8 IoAAAggggAACCCCAAAIItE7g3WFNrdsmW0KgKwQU7ihoTaX6zVVHD5t9k+MuWNKNHX0LjuLz03gs LxC0StkAUiHdlDW98opDLszW+710YeCuu+5qOOzVTee++MUvloeOYKrqCmtkrIK/YNMxUphYLtQc Hh42f/zHfxycPbbnhw8fLrvu8M0ty87UARNlq7A/3NR/ha7h8FrfFxphHAxs/bLVLHSD0NHRUT+7 e9Rx1A0kVU86HOiq/ItubOib+hT3yHYF88HR1H7b+hmhMDscXmt/PvWpT/nZio+f+9znXLBdnHD5 ifZR6wnvq96+88473QWF8DK8RgABBBBAAAEEEEAAAQQQaJ0AAXbrrNlSlwkoNNKXaq5OjI+a2266 wYyODNvwbt3Ygs32PeOCVz3yVd1AI0UV/Ss8W7Eh6OjosLnt5uPOVsbeu8tOoz13R6OVNWL4+uuv 3xUWl1twcnLS3WjugQceKCm7UG5eP03uwRYOpcPv+3k1olV9U0CqY1OpaYSs9uMrX/lK2fk0wjbY wtsPvqfn4f6EX2sejTyvdONKBZVRt3Afwq/D2wvvY/i15tcNA2+77TZ7gazUJ7guufsLA8ePHw++ VXxei4W2pRuF7nUcB+xfl2gksm7AqdI0wfbss88WX4b3Pfy6OOPlJ+F9D7/28+uvEr7whS+YwcFB P2nXo6wUdn/5y1/e9Z4mqC8KtvUXBBpxvVebnp52x6DcRYG9luM9BBBAAAEEEEAAAQQQQACB6AX6 bFj0bqHH6NfPGhFoWGBtfaPhZVuxoL51FPj4byE9X7OjEd85c968cfpt+6f3i2bL1sjeKxRqRT+T sg05ajT76PCIG3V96OCUydmQKejrzTt1n3LZTKxdm5ubczdMVBkE1QDWuaXQWoFinDdGrGWnVGrC 39BRQaLKNRw6dKit/dKFj1deecWdQ6r1rFBbQWzSmkZDy1bHXfukY63A2d+ksJb9qcVCI5pPnTrl zrH5+Xk3MvvKK690Fylq2Uar5tHPgdOnT7u65rogoXNN/az3e0Ajt7UefWlkuzz11wW6KONL4bRq n9gOAggggAACCCCAAAIIIIBAZQEC7Mo2vNNmgU4PsMXjA1X/qEBRoYjCom1dG9LlocqDU9ss3GGb v2zVbw0VgGq0pFy9rX/ssF6XdCfuALtkY7xAAAEEEEAAAQQQQAABBBBAAAEEekCgtIBpD+wwu4hA lAIKrH2wGgxbVTaB1riALH1d26Bx42tkSQQQQAABBBBAAAEEEEAAAQQQQACBJAoQYCfxqNHnjhII Bqw+xNYjrXmBoG3za2MNCCCAAAIIIIAAAggggAACCCCAAAJJEyDATtoRo78dKaCgVc0/dmQnE9op TBN64Og2AggggAACCCCAAAIIIIAAAgggEIFAfwTrYBUIIIAAAggggAACCCCAAAIIIIAAAggggAAC CEQuQIAdOSkrRAABBBBAAAEEEEAAAQQQQAABBBBAAAEEEIhCgAA7CkXWgQACCCCAAAIIIIAAAggg gAACCCCAAAIIIBC5AAF25KSsEAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQQCAKgb4d26JYEetAAAEE EEAAAQQQQAABBBBAAAEEEEAAAQQQQCBKAUZgR6nJuhBAAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQi EyDAjoySFSGAAAIIIIAAAggggAACCCCAAAIIIIAAAghEKUCAHaUm60IAAQQQQAABBBBAAAEEEEAA 0QW4vgAAA25JREFUAQQQQAABBBCITIAAOzJKVoQAAggggAACCCCAAAIIIIAAAggggAACCCAQpQAB dpSarAsBBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAgMgEC7MgoWRECCCCAAAIIIIAAAggggAACCCCA AAIIIIBAlAIE2FFqsi4EEEAAAQQQQAABBBBAAAEEEEAAAQQQQACByAQIsCOjZEUIIIAAAggggAAC CCCAAAIIIIAAAggggAACUQoQYEepyboQQAABBBBAAAEEEEAAAQQQQAABBBBAAAEEIhMgwI6MkhUh gAACCCCAAAIIIIAAAggggAACCCCAAAIIRClAgB2lJutCAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQ iEyAADsySlaEAAIIIIAAAggggAACCCCAAAIIIIAAAgggEKUAAXaUmqwLAQQQQAABBBBAAAEEEEAA AQQQQAABBBBAIDIBAuzIKFkRAggggAACCCCAAAIIIIAAAggggAACCCCAQJQCBNhRarIuBBBAAAEE EEAAAQQQQAABBBBAAAEEEEAAgcgECLAjo2RFCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAlEKEGBH qcm6EEAAAQQQQAABBBBAAAEEEEAAAQQQQAABBCITIMCOjJIVIYAAAggggAACCCCAAAIIIIAAAggg gAACCEQpQIAdpSbrQgABBBBAAAEEEEAAAQQQQAABBBBAAAEEEIhMgAA7MkpWhAACCCCAAAIIIIAA AggggAACCCCAAAIIIBClAAF2lJqsCwEEEEAAAQQQQAABBBBAAAEEEEAAAQQQQCAyAQLsyChZEQII IIAAAggggAACCCCAAAIIIIAAAggggECUAgTYUWqyLgQQQAABBBBAAAEEEEAAAQQQQAABBBBAAIHI BAiwI6NkRQgggAACCCCAAAIIIIAAAggggAACCCCAAAJRChBgR6nJuhBAAAEEEEAAAQQQQAABBBBA AAEEEEAAAQQiEyDAjoySFSGAAAIIIIAAAggggAACCCCAAAIIIIAAAghEKUCAHaUm60IAAQQQQAAB BBBAAAEEEEAAAQQQQAABBBCITIAAOzJKVoQAAggggAACCCCAAAIIIIAAAggggAACCCAQpQABdpSa rAsBBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAgMoH/B8iKWm0KBM7WAAAAAElFTkSuQmCC --Apple-Mail=_E7A8E8C5-9820-41C8-A175-340A25AD0B61-- --Apple-Mail=_5F758942-3A18-489D-8070-0E450D7B1F13-- From nobody Mon Mar 22 11:14:45 2021 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 70CDA3A1022 for ; Mon, 22 Mar 2021 11:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 SCPJt55F7Kdy for ; Mon, 22 Mar 2021 11:14:39 -0700 (PDT) Received: from mail-ua1-f45.google.com (mail-ua1-f45.google.com [209.85.222.45]) (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 9A69B3A0FE5 for ; Mon, 22 Mar 2021 11:14:38 -0700 (PDT) Received: by mail-ua1-f45.google.com with SMTP id x8so5834681ual.6 for ; Mon, 22 Mar 2021 11:14:38 -0700 (PDT) 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=vSN82Pf8mKAECyaVO/xoIwJeVXxytroysqNc8F0imlQ=; b=GZDz7ZhN/8E4ow2O+vxWq2YKt7R5KBvyJVhit5Vmg2ToRjjUIuDAAScxAuBHvN8b4U lV1AmGbVtDvpUa/PZuAx9jEs+9WREZUICPenXpietOp4UxqXA3hkqkj15DNTfBO4R7mZ H498dJR5ta2I6h73YIIuRmUTJVNdlnQa5TXoD0RlTWAIhIni4kllmXRyg3MS8p5UHnsp Al6ba6AJe5nHr1zw3FCAGhVnYl2xRYyqLXItYHpZYlqJif9sC7FAw3K/RYIBTIy08xLE p1hzS7u+Y0DyRxfK+GUOOJ/jWHmSw2CtdhYHxild/RH8SPQPVak2+JAxZYR1f4+dkwDK 2P4g== X-Gm-Message-State: AOAM531S+V9DUcmB9upfk18ir7+TFHUkR6+TRBMsKSov8wMNxeiQglTi EGnQCpNHsOwz9+IV042CiQIGffEmOjymRH85XuJMx2ghhzQ= X-Google-Smtp-Source: ABdhPJzl4I25enFFJFEdkorJFR5Av6vNk5iom6XnrYvdXg5dDPaDKGis7Nno6bmIEp7w7RDlFmQqUVgCbH0kd9Lz8uY= X-Received: by 2002:ab0:5e5:: with SMTP id e92mr1050651uae.70.1616436877190; Mon, 22 Mar 2021 11:14:37 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> In-Reply-To: <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> From: Adrian Gropper Date: Mon, 22 Mar 2021 14:14:24 -0400 Message-ID: To: Justin Richer Cc: Benjamin Kaduk , Alan Karp , GNAP Mailing List , Mark Miller Content-Type: multipart/related; boundary="000000000000de671a05be240913" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2021 18:14:44 -0000 --000000000000de671a05be240913 Content-Type: multipart/alternative; boundary="000000000000de671805be240912" --000000000000de671805be240912 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm sorry, Justin. As a Resource Owner, I look at the RS trust boundary (the dotted line in the diagram) as being the RS. I don't expect any visibility into what's going on on the right. My problem with the framing you propose is that requests are going to the RS (or the AS-RS) and I don't want to share my policies with the AS-RS. I want to keep the RS and AS-RS as ignorant as possible. Adrian On Mon, Mar 22, 2021 at 1:48 PM Justin Richer wrote: > Adrian, > > What you=E2=80=99re discussing below, in terms of logging in to a site, i= s not > approaching the RS. You are in fact approaching the client, and identifyi= ng > both the AS and RS to the client. The client is a client *of your > identity* in this model, and the RS is part of the identity provider. > It=E2=80=99s really important that we don=E2=80=99t conflate the RS and c= lient in this way > as it leads to a lot of confusion downstream and a lot of broken trust > boundaries. > > With that model in mind, approaching the =E2=80=9CRS" and providing it yo= ur > identity is really just a case of the =E2=80=9Cfederated login to AS=E2= =80=9D pattern that > we discussed on the WG call. The user here approaches an RS, which has it= s > own AS. To share things from this RS, the RO has to authenticate to the > RS=E2=80=99s AS. This particular AS allows the RO to do so using an exter= nal > identity =E2=80=94 in which case, the AS is now a =E2=80=9Cclient=E2=80= =9D of a separate, > disconnected (but layered) delegation. The ultimate client that eventuall= y > calls the RS down the way may or may not know about these layers. > > This same AS, which is closely tied to the RS and trusted by the RS, migh= t > also take in FIDO credentials, or DIDs, or any number of other proof > mechanisms. The output of this is an access token the RS trusts, but the > input is up to the AS. The RS is not what you=E2=80=99re logging in to. > > =E2=80=94 Justin > > On Mar 22, 2021, at 1:28 PM, Adrian Gropper > wrote: > > I too am in favor of avoiding consolidation and correlation. Right now, > when I approach a service provider (RS) for the first time, I'm offered t= he > opportunity to identify my persona as: email, sign-in with Google, > Facebook, or Apple. I know there are people who try to create one-off ema= il > addresses but that is mostly a waste of time. > > So, along come FIDO2 and DID wallets to the rescue. Now, in theory, I hav= e > a way to start out my RS relationship pseudonymously. > > When I want my resource to be discovered or shared I will post that RS UR= L > including my pseudonym. If I then want to introduce a mediator in front o= f > my AS or messaging service endpoint, I have that option. If I want to kee= p > requests away from the mediator, I would publish an encryption key along > with my pseudonym. > > - Adrian > > > > On Mon, Mar 22, 2021 at 9:55 AM Justin Richer wrote: > >> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk wrote: >> > >> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote: >> >> @Alan Karp shared a talk about the Principle Of >> Least >> >> Authority (POLA) in a recent comment >> >> >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomme= nt-803099693 >> >> I recommend it. >> >> >> >> We might expect a protocol with authorization in the title to use >> authority >> >> as a core principle. I advocate for a GNAP design that maximizes the >> power >> >> of the RO, to be seen as a human rights issue when the RO is a human. >> This >> >> causes me to ask how to combine better security with better human >> rights in >> >> GNAP. >> >> >> >> Who should have the least authority in the GNAP design? >> >> >> >> The AS derives authority as a delegate of the RO. If we ask the RO to >> >> partition limited authority across dozens of different ASs by domain >> and >> >> function, then we are not using technology to empower the individual. >> >> Probably the opposite, as we introduce consent fatigue and burden >> normal >> >> people to partition their lives into non-overlapping domains. >> >> >> >> My experience says we should aim for one AS per persona because that >> maps >> >> into the way we manage our public and private identities. POLA would >> then >> >> teach care in keeping ASs and RSs related to work / public separate >> from >> >> ASs and RSs related to private life so that a policy vulnerability in >> our >> >> delegation to an AS would have the least likelihood of harm. >> > >> > Thinking about how least authority/least privilege would apply to GNAP >> > seems like a useful exercise. I do want to point out some potential >> > pitfalls with one-AS-per-persona that we can also be aware of. If >> > one-AS-per-persona becomes one-persona-per-AS as well, then the AS's >> > identity in effect also serves as a persona identity and there are >> privacy >> > considerations to that. If, on the other hand, the >> > multiple-personas-per-AS (presumably corresponding to multiple humans) >> > route is taken, we should consider whether that would lead to various >> > (e.g., market) forces driving consolidation to just a handful of >> > super-popular AS services. That topic is a current matter of concern = to >> > some IETF participants. >> > >> >> Hi Ben, big +1 to this. This is something that we discussed ages ago in >> the UMA working group, and it=E2=80=99s one of the biggest problems with= the >> personal AS (and personal data store) model. This kind of thing makes >> RS-first trust models really difficult in practice. >> >> As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wan= ts to access my >> medical information. It calls an RS and requests access, but it hasn=E2= =80=99t been >> granted anything yet. Now I as the RO have set up the RS so that it talk= s >> to my personal AS, that only I use. In addition to the RS having to be a= ble >> to figure out which medical records are being requested from the context= of >> the unauthenticated request (which means it needs identifiers in the URL= or >> something similar for the RS to be able to tell, assuming that it protec= ts >> data for more than one person). So this client software doesn=E2=80=99t = know who I >> am and doesn=E2=80=99t know my medical record information, makes a compl= etely >> unauthorized request to the RS, and the RS says =E2=80=9CGo to Justin=E2= =80=99s personal AS >> to get a token=E2=80=9D. The client can now make a direct correlation be= tween the >> data that=E2=80=99s being protected at the RS and the person running the= AS that >> protects it. Importantly, this client makes this call with no prior >> relationship to the RS and no really auditable way to track it down afte= r >> the fact. This is a design feature in the good case, and terrifying in t= he >> bad case. >> >> If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please ta= lk to the >> Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t exposed an= ything at all. And >> from the perspective of both the patient and the RS, this is more >> privacy-preserving, and it=E2=80=99s really the least surprising option.= Once the >> client gets to the AS, it can start a negotiation of figuring out who th= e >> RO is for the information being accessed. >> >> On top of this, the usability expectations of people managing their own >> AS, or set of AS=E2=80=99s for multiple personas to keep things separate= , is a huge >> burden. Even in the tech community, I know people who can=E2=80=99t reli= ably manage >> more than one email address for different purposes. I wouldn=E2=80=99t e= xpect my >> partner to do that =E2=80=94 they have trouble enough balancing all the = logins and >> sessions required for different kids remote schooling, I couldn=E2=80=99= t imagine >> them having to understand all the requirements for managing multiple >> authorization servers and associated policies. I also don=E2=80=99t expe= ct any >> person to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve been on t= he internet for decades and I can >> barely keep tabs on my GPG keys, and only use them when I am forced to. >> This is exactly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I thi= nk Ben mentions >> above, people will just want to outsource that to someone else, and the >> reality will be a few popular providers. >> >> In which case, we could end up doing a ton of work to allow an RS choice >> only to end up with a world where the RS ends up making a limited choice >> anyway. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80= =99s could allow >> arbitrary IdPs but they choose Google because it works and that=E2=80=99= s where the >> users are. (And that=E2=80=99s not to say anything of the proprietary OI= DC-like >> protocols, but that=E2=80=99s another discussion). >> >> For further reading on these topics, I recommend both =E2=80=9CWhy Johnn= y Can=E2=80=99t >> Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D. >> >> So what does this have to do with GNAP? I think we can be clear-eyed on >> what kinds of expectations we have for the participants. If we expect us= ers >> (RO=E2=80=99s) to have to set up the AS-RS relationship, or expect them = to carry >> their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve = lost the battle for >> relevance. >> >> =E2=80=94 Justin > > > --000000000000de671805be240912 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I'm sorry, Justin. As a Resource Owner, I look at the = RS trust boundary (the dotted line in the diagram) as being the RS. I don&#= 39;t expect any visibility into what's going on on the=C2=A0right.=C2= =A0

    My problem with the framing you propose is that requ= ests are going to the RS (or the AS-RS) and I don't want to share my po= licies with the AS-RS. I want to keep the RS and AS-RS as ignorant as possi= ble.

    Adrian

    On Mon, Mar 22, 2021 at 1:48 PM J= ustin Richer <jricher@mit.edu>= wrote:
    Adrian,

    What you=E2=80=99re disc= ussing below, in terms of logging in to a site, is not approaching the RS. = You are in fact approaching the client, and identifying both the AS and RS = to the client. The client is a client of your identity in this model= , and the RS is part of the identity provider. It=E2=80=99s really importan= t that we don=E2=80=99t conflate the RS and client in this way as it leads = to a lot of confusion downstream and a lot of broken trust boundaries.

    With that model in mind, approaching the =E2=80=9CRS&q= uot; and providing it your identity is really just a case of the =E2=80=9Cf= ederated login to AS=E2=80=9D pattern that we discussed on the WG call. The= user here approaches an RS, which has its own AS. To share things from thi= s RS, the RO has to authenticate to the RS=E2=80=99s AS. This particular AS= allows the RO to do so using an external identity =E2=80=94 in which case,= the AS is now a =E2=80=9Cclient=E2=80=9D of a separate, disconnected (but = layered) delegation. The ultimate client that eventually calls the RS down = the way may or may not know about these layers.=C2=A0

    <= div>
    This same AS, which is cl= osely tied to the RS and trusted by the RS, might also take in FIDO credent= ials, or DIDs, or any number of other proof mechanisms. The output of this = is an access token the RS trusts, but the input is up to the AS. The RS is = not what you=E2=80=99re logging in to.

    =C2=A0=E2= =80=94 Justin

    On Mar 22, 2021, a= t 1:28 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I too am in favor of avoiding consolidation and correlation. Right= now, when I approach a service provider (RS) for the first time, I'm o= ffered the opportunity to identify my persona as: email, sign-in with Googl= e, Facebook, or Apple. I know there are people who try to create one-off em= ail addresses but that is mostly a waste of time.=C2=A0

    = So, along come FIDO2 and DID wallets to the rescue. Now, in theory, I have = a way to start out my RS relationship pseudonymously.=C2=A0

    <= /div>
    When I want my resource to be discovered or shared I will post th= at RS URL including my pseudonym. If I then want to introduce a mediator=C2= =A0in front of my AS or messaging service=C2=A0endpoint, I have that option= . If I want to keep requests away from the mediator, I would publish an enc= ryption key along with my pseudonym.

    - Adrian



    On Mon, Mar 22, 2021 at 9:55 AM Justin Riche= r <jricher@mit.edu<= /a>> wrote:
    On Mar 21, 2021, at 1:18 PM, Benja= min Kaduk <kaduk@mit.= edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhkarp@gmail.com> shared a talk about the Principle Of Leas= t
    >> Authority (POLA) in a recent comment
    >> https:/= /github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-8030996= 93
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin

    --000000000000de671805be240912-- --000000000000de671a05be240913 Content-Type: image/png; name="PastedGraphic-1.png" Content-Disposition: inline; filename="PastedGraphic-1.png" Content-Transfer-Encoding: base64 Content-ID: <1785b1ec8115b206ef61> X-Attachment-Id: 1785b1ec8115b206ef61 iVBORw0KGgoAAAANSUhEUgAABbAAAAOOCAYAAADReDRcAAAK42lDQ1BJQ0MgUHJvZmlsZQAASImV lwdUU9kWhs+9N73QAhGQEnpHOgGkhB5AQTqISkhCEkoIKajYlcERHAsqIlhGdKQpODrUsSAWbINg 7wMyqKjjYMGGylzgEWbmrffeenutk/NlZ5999r7rnKz/AkBN4UgkWbAaANliuTQ6xJ+RmJTMwA8A BNABBbgBHIcrk7CioiIAapPz3+3dTQCNzdfsxnL9++//1TR4fBkXACgF5TSejJuNcjs6vnIlUjkA CMrAZKFcMsa/oawpRQtE+cMYC8YZQxnjtAlmjMfERgeg7AIAgcLhSAUAUPxQPyOPK0DzUFJRdhDz RGKUN6HswxVyeCh3o2ybnZ0zxp9RtkTjJQBQTVFmpv0lp+Bv+dOU+TkcgZIn+ho3QqBIJsniLP4/ H83/tuwsxeQe5uigCKWh0RMM3c7MCVeyOG125CSLeJPx0G2hIjRukrmygORJ5nECw5Vrs2ZHTHK6 KJitzCNnx04yXxYUM8nSnGjlXunSANYkc6RT+yoy45R+IZ+tzJ8vjE2Y5DxR/OxJlmXGhE/FBCj9 UkW0sn6+OMR/at9gZe/Zsr/0K2Ir18qFsaHK3jlT9fPFrKmcskRlbTx+YNBUTJwyXiL3V+4lyYpS xvOzQpR+WV6Mcq0cPZxTa6OUzzCDExY1ySAWCIECiAEP8IEUpIEckAXkgAECgQjIgAT9xgHocZLz F8nHmgvIkSyWigRCOYOF3kA+gy3m2tsynBycHAEYu88TR+QNffyeQvSLU77cdgA8ilCnYMrHMQGg 9TEAtHdTPpPXE3fleDdXIc2b8GHGPrCABFSBJtABBsAEWAI74IT+a3gBPxAEwkAk2kkSmA+4aD/Z aCcLwVKwChSCYrAJbAPlYA/YB6rBIXAENINj4BQ4By6BbnAD3AO9YAA8B0PgHRiBIAgPUSEapAMZ QmaQDeQEMSEfKAiKgKKhJCgVEkBiSAEthdZAxVAJVA7thWqgH6FW6BR0AeqB7kB90CD0GvoEIzAF 1oT1YXN4BsyEWXA4HAvPgwVwLpwPF8Ab4DK4Ej4IN8Gn4EvwDbgXfg4PIwAhI3TECLFDmEgAEokk I+mIFFmOFCGlSCVSj7Qhncg1pBd5gXzE4DA0DANjh/HChGLiMFxMLmY5Zj2mHFONacKcwVzD9GGG MF+xVKwe1gbriWVjE7EC7EJsIbYUewDbiD2LvYEdwL7D4XB0nAXOHReKS8Jl4Jbg1uN24Rpw7bge XD9uGI/H6+Bt8N74SDwHL8cX4nfgD+JP4q/iB/AfCGSCIcGJEExIJogJqwmlhFrCCcJVwhPCCFGN aEb0JEYSecTFxI3E/cQ24hXiAHGEpE6yIHmTYkkZpFWkMlI96SzpPukNmUw2JnuQ55BF5JXkMvJh 8nlyH/kjRYNiTQmgpFAUlA2UKko75Q7lDZVKNaf6UZOpcuoGag31NPUh9YMKTcVeha3CU1mhUqHS pHJV5aUqUdVMlaU6XzVftVT1qOoV1RdqRDVztQA1jtpytQq1VrVbasPqNHVH9Uj1bPX16rXqF9Sf auA1zDWCNHgaBRr7NE5r9NMQmgktgMalraHtp52lDWjiNC002ZoZmsWahzS7NIe0NLRctOK1FmlV aB3X6qUjdHM6m55F30g/Qr9J/zRNfxprGn/aumn1065Oe689XdtPm69dpN2gfUP7kw5DJ0gnU2ez TrPOA12MrrXuHN2Furt1z+q+mK453Ws6d3rR9CPT7+rBetZ60XpL9PbpXdYb1jfQD9GX6O/QP63/ woBu4GeQYbDV4ITBoCHN0MdQZLjV8KThM4YWg8XIYpQxzjCGjPSMQo0URnuNuoxGjC2M44xXGzcY PzAhmTBN0k22mnSYDJkams4yXWpaZ3rXjGjGNBOabTfrNHtvbmGeYL7WvNn8qYW2Bdsi36LO4r4l 1dLXMtey0vK6Fc6KaZVptcuq2xq2drUWWldYX7GBbdxsRDa7bHpssbYetmLbSttbdhQ7ll2eXZ1d nz3dPsJ+tX2z/csZpjOSZ2ye0Tnjq4OrQ5bDfod7jhqOYY6rHdscXztZO3GdKpyuO1Odg51XOLc4 v3KxceG77Ha57UpzneW61rXD9Yubu5vUrd5t0N3UPdV9p/stpiYzirmeed4D6+HvscLjmMdHTzdP uecRzz+87LwyvWq9ns60mMmfuX9mv7exN8d7r3evD8Mn1ed7n15fI1+Ob6XvIz8TP57fAb8nLCtW Busg66W/g7/Uv9H/fYBnwLKA9kAkMCSwKLArSCMoLqg86GGwcbAguC54KMQ1ZElIeyg2NDx0c+gt tj6by65hD4W5hy0LOxNOCY8JLw9/FGEdIY1omwXPCpu1Zdb92WazxbObI0EkO3JL5IMoi6jcqJ/n 4OZEzamY8zjaMXppdGcMLWZBTG3Mu1j/2I2x9+Is4xRxHfGq8SnxNfHvEwITShJ6E2ckLku8lKSb JEpqScYnxycfSB6eGzR329yBFNeUwpSb8yzmLZp3Yb7u/Kz5xxeoLuAsOJqKTU1IrU39zInkVHKG 09hpO9OGuAHc7dznPD/eVt4g35tfwn+S7p1ekv5U4C3YIhgU+gpLhS9EAaJy0auM0Iw9Ge8zIzOr MkezErIasgnZqdmtYg1xpvhMjkHOopweiY2kUNKb65m7LXdIGi49IINk82Qtck1UOF1WWCq+UfTl +eRV5H1YGL/w6CL1ReJFlxdbL163+El+cP4PSzBLuEs6lhotXbW0bxlr2d7l0PK05R0rTFYUrBhY GbKyehVpVeaqX1Y7rC5Z/XZNwpq2Av2ClQX934R8U1eoUigtvLXWa+2ebzHfir7tWue8bse6r0W8 oovFDsWlxZ/Xc9df/M7xu7LvRjekb+ja6LZx9ybcJvGmm5t9N1eXqJfkl/RvmbWlaStja9HWt9sW bLtQ6lK6Zztpu2J7b1lEWcsO0x2bdnwuF5bfqPCvaNipt3Pdzve7eLuu7vbbXb9Hf0/xnk/fi76/ vTdkb1OleWXpPty+vH2P98fv7/yB+UPNAd0DxQe+VImrequjq8/UuNfU1OrVbqyD6xR1gwdTDnYf CjzUUm9Xv7eB3lB8GBxWHH72Y+qPN4+EH+k4yjxa/5PZTzsbaY1FTVDT4qahZmFzb0tSS09rWGtH m1db48/2P1cdMzpWcVzr+MYTpBMFJ0ZP5p8cbpe0vzglONXfsaDj3unE09fPzDnTdTb87PlzwedO d7I6T573Pn/sgueF1ovMi82X3C41XXa93PiL6y+NXW5dTVfcr7R0e3S39czsOXHV9+qpa4HXzl1n X790Y/aNnptxN2/fSrnVe5t3++mdrDuv7ubdHbm38j72ftEDtQelD/UeVv5q9WtDr1vv8b7AvsuP Yh7d6+f2P/9N9tvngYLH1MelTwyf1Dx1enpsMHiw+9ncZwPPJc9HXhT+rv77zpeWL3/6w++Py0OJ QwOvpK9GX69/o/Om6q3L247hqOGH77Lfjbwv+qDzofoj82Pnp4RPT0YWfsZ/Lvti9aXta/jX+6PZ o6MSjpQzLgUQdMDp6QC8rkL1chKqHVAtTZo7obfHDZp4Rxgn8J94QpOPmxsAVX4AxK0EIALVKLvR YYYyBZ3HZFKsH4CdnZXjXyZLd3aayEVB1Sb2w+joG30A8G0AfJGOjo7sGh39sh8t9g4A7bkTOn/M cOjbT4mFNlm9+kpQLPinTbwD/KXHf85grAIX8M/5Ty3AIe1FGuUcAAAAVmVYSWZNTQAqAAAACAAB h2kABAAAAAEAAAAaAAAAAAADkoYABwAAABIAAABEoAIABAAAAAEAAAWwoAMABAAAAAEAAAOOAAAA AEFTQ0lJAAAAU2NyZWVuc2hvdKgXULYAAAHXaVRYdFhNTDpjb20uYWRvYmUueG1wAAAAAAA8eDp4 bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSJYTVAgQ29yZSA1LjQuMCI+ CiAgIDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYt c3ludGF4LW5zIyI+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAg ICAgIHhtbG5zOmV4aWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20vZXhpZi8xLjAvIj4KICAgICAgICAg PGV4aWY6UGl4ZWxYRGltZW5zaW9uPjE0NTY8L2V4aWY6UGl4ZWxYRGltZW5zaW9uPgogICAgICAg ICA8ZXhpZjpVc2VyQ29tbWVudD5TY3JlZW5zaG90PC9leGlmOlVzZXJDb21tZW50PgogICAgICAg ICA8ZXhpZjpQaXhlbFlEaW1lbnNpb24+OTEwPC9leGlmOlBpeGVsWURpbWVuc2lvbj4KICAgICAg PC9yZGY6RGVzY3JpcHRpb24+CiAgIDwvcmRmOlJERj4KPC94OnhtcG1ldGE+CothOfwAAEAASURB VHgB7J0FuBxF1oYrijtBgksWZ3F3d3dZ4MfdHRZYYHFYLDhhcVkcFlssuPsSJIQECwQInoSEzF9f Q9/t6dtV3T3TM7fn3vfkuZnu8nrbT5061a1ixSAQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAA gZIR6F6y9tAcCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgEBAAAU2JwIEIAABCEAAAhCAAAQg AAEIQAACEIAABCAAAQiUkgAK7FIeFhoFAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACKLA5ByAA AQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQKCUBFBgl/Kw0CgIQAACEIAABCAAAQhAAAIQgAAEIAAB CEAAAhBAgc05AAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAqUkgAK7lIeFRkEAAhCAAAQgAAEI QAACEIAABCAAAQhAAAIQgAAKbM4BCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQKCUBFNilPCw0 CgIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABFBgcw5AAAIQgAAEIAABCEAAAhCAAAQgAAEIQAAC EIBAKQmgwC7lYaFREIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQggAKbcwACEIAABCAAAQhAAAIQ gAAEIAABCEAAAhCAAARKSQAFdikPC42CAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABFNicAxCA AAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIFBKAiiwS3lYaBQEIAABCEAAAhCAAAQgAAEIQAACEIAA BCAAAQigwOYcgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAgVISQIFdysNCoyAAAQhAAAIQgAAE IAABCEAAAhCAAAQgAAEIQAAFNucABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIlJIACuxSHhYa BQEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAiiwOQcgAAEIQAACEIAABCAAAQhAAAIQgAAEIAAB CECglARQYJfysNAoCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQ6AkCCEAAAhCAQKMI/Prrr+br r78O/kaMGGG+//57M+mkk5o+ffqYaaed1kwzzTRm4oknblT1lAsBCEAAAhCAQCchwDtFJzmQdAMC EIAABCBQA4EOV2B/8cUX5oYbbqih6clZunXrZnr27Gl69+5tevXqZSaZZJJAQSIlSd++fc0MM8xg lAaBQGcgoBf5/v37m3HjxrXrziKLLGLWWGONduEEQKCRBKSkfvTRR829994b/P3444+ZqltmmWXM hhtuaNZZZx2jc7d7dyYIZQJXcKIXXnjBPPXUU4ml7rLLLsHzNDGyBQLffPNN8/DDDye2dNtttzUz zTRTYlyjAj/77DNz0003JRavQZ699torMY7AchP4/PPPzY033pjYyDXXXNP8+c9/TowjEALNInDn nXeawYMHO6vTs3ieeeZxxjczgneKZtKmLghAAAIQgEC5CXSrWOnIJj7wwANmvfXWa1oTJptsMrPJ JpsEir1VVlnFzDrrrE2rm4ogUDQBDQBpYCZJttxyS3PrrbcmRRHWYAJjxowxH330kZlvvvkaXFM5 iv/tt98CRdyll15qnnnmmbobNd1005nNNtvMHHrooWbuueeuuzwKyE7giCOOMGeddVZihieffNKs tNJKiXGtEHjGGWeYo446KrGpUujo3aCZcvfdd3vr7ODXs2ai6FR13XfffcFgXFKnTj75ZHPccccl RRHWYgTeeOMNs/DCC7ecUcwvv/wSGPP4Bpd33nlnM2DAgA47IrxTdBh6KoYABCAAAQiUmkCXM3HT C9t1111ndtppJzPbbLOZv/zlL+bDDz8s9UGicRCAQOsQkPWxPmq32GKL1ml0HS197LHHzGKLLWZ2 3HHHQpTXaspXX31lpAzv16+fOf74481PP/1URwvJCgEIQAACECiGgL4ZZHijmUJyj9Vqcs899xif 8lr9ueaaa8w333zTIV3jnaJDsFMpBCAAAQhAoCUIdDkFdvyoSJktJYmszpLcMMTTsw8BCEAgiYDc AWy99dbB7I73338/KUmnCtP9crfddjOrr766kWuGRskpp5xi5pprLnPXXXc1qgrKhQAEIAABCHgJ yHL5pJNOCr4ZNHu0VeWKK67I1PTrr78+U7qiEvFOURRJyoEABCAAAQh0XgJdXoEdHlpNmd5uu+2M pv4jEIAABLISGDt2rDn33HPNzDPP3GVctsj3+vbbb2+uuuqqrJjqSieL7E033dTcdtttdZVDZghA AAIQgEBeAnILI5/QJ554Yt6spUov63FZOGeRCy64wIwfPz5L0rrT8E5RN0IKgAAEIAABCHQJAiiw I4dZyhEpSeR7DYEABCCQhcASSywR+GrOkrYzpNH9cauttuoQZb3qlYsWBAIQgAAEINAMAocddljg 0/zTTz9tRnUNrcO1uGhSpVrH4/HHH0+KKjSMd4pCcVIYBCAAAQhAoFMT6Nmpe1dD5zQtUNPr9tpr rxpykwUCEOhqBBrpPqOMLPv372+0+FwW+dOf/mRWW201s9BCC5k555zTaBHdCSec0IwcOdJIGTBs 2DAzZMgQ88EHH2T2n73GGmuYV1991Sy66KJZmkAaCEAAAhCAQM0EOss6OXLRcfHFF+ficNlllwVu wnJlypmYd4qcwEgOAQhAAAIQ6MIESq/AHjp0qOnZM18z5QZE09H0q4VKpCCRT1q9iGkqeprsvffe ZoMNNghcAqSlJR4CEIBAVyEgH6DHHntsand33XVXc8ABBwSLWaYm/iOBBgLk7zqLm5D999/fPP30 01mLJh0EIAABCECgSxN44oknMn0DRSHpefz555+bvn37RoML2+adojCUFAQBCEAAAhDoEgTyaYY7 AIlemvIqsOPNXH755YOg4447ztxyyy1G0wHTFNnyc3fllVfGi2IfAhCAQJcloEWdNCjok6eeesqs sMIKviSJcQsvvHDglkSK7IMPPtjrp/OZZ54xAwcONCuttFJiWQTWTkADD2uttVZiAUsvvXRiOIEQ gMD/CKy66qrmkUce+V9AZGvBBReM7LEJgeYRGDBgQGJlmh0lw53DDz88MV75sgxcJ2ZOCeSdIgUQ 0RCAAAQgAAEIVBEovQK7qrV17vTu3dvsuOOOZqmllgoUHz4lthYn0wImE088cZ21kh0CEIBA6xPQ 9OOTTz7Z25F///vfNSmvo4VKkX3HHXcE92nNnHHJ6aefjgLbBaeOcC1Gqj8EAhCojcAkk0xi5OoI gUBZCHz99dfG5f9aM0433HBDpwJb30JHHnlk3cZEcRa8U8SJsA8BCEAAAhCAQBqBLrmIo1YSf/LJ J9PYGPnDRiAAAQhAwJh333038FvtYnHRRReZdddd1xWdK3yKKaYIlNi+TLo/v/32274kxEEAAhCA AAS6PIFbb73VyWCdddYx+i7SmhVJImOfRnwP8U6RRJswCEAAAhCAAAR8BLqkAltA5p13XnPEEUf4 2ATT2b0JiIQABCDQRQgMHjzY29M999zTG583coEFFjDXXXedN9tLL73kjScSAhCAAAQg0NUJaA0g l6y44opBlGaouuSSSy5xRdUczjtFzejICAEIQAACEOiyBLqsAltH/MADD/Qe+EGDBnnjiYQABCDQ VQh8+OGHzq7K8rretQqSCt9iiy2SgtvC3nnnnbZtNiAAAQhAAAIQqCbw2muvGa0tkSRrrrmmmXTS SYOobbbZJilJECYLbN87gDOjJ8JXHu8UHnBEQQACEIAABLowgS7lAzt+nLVApF7eXIvtDBkyJJ6l 5v3x48ebL774wqjM7t27Gy2aMsMMM9RcXjxjpVIx3333nZGfuxEjRphRo0aZqaaayvTp08dMO+20 ZqKJJopnafr+yJEjzSeffBK0b+qppzZzzDGHmXLKKZvejjKz+u2334IV34cOHWp0zsw444zBX/iB 0XRYsQrLzC7WVPPDDz8E19yXX34ZsNS1oL9pppnG9OjRI56c/RQCPmsp+a1uhEw44YRm/fXXN/ff f39i8Y1yIaJ71bfffhv8ff/998FaCOG9VO5NdA/vSPn111+D+8Rnn31mdM+YddZZA7/VjRhEaGQ/ dT/RoqDireeXfnXf09oT8iMs1rPMMovp1q1bI5tB2QUQ+Pnnn80333wT/OlY6h6re63eP/Tbkeem fO3qWhk2bFhwfundS386vzqbdPbnnu594b1C94uffvrJTDDBBMH9QvcMvTNNPvnkne2w1tWfa665 xpl/vfXWa4ube+65zTLLLGOef/75trDohtYGOu2006JBdW13pXeKukCRGQIQgAAEIACBNgJdWoEt Cnphcymw9WGtjzK9FCfJDTfcECg44nHbbrtt8NGm8F9++cVoBe+//e1vJr5o5GSTTRYseHbAAQeY tddeO/dHuj7GHn74YXPfffeZu+++O96Mqn0pzDfddNPAR+0KK6wQvPBXJSh4R4qJZ555xujFWdP8 XdYfYiDlV79+/cyyyy5r/vKXvxgprYqWsrISp8cee8xcfvnl5vXXXzeuReumm246s9tuuwWLkMr9 TTOlI9m98MIL5sUXX2zXXS3EuvTSS1eFjxkzJriW5XbC5+9RmTbffHOz8cYbB9eDFCxZRZZMTz/9 dKbk//3vf82FF17YLq0UOzqWWlQ2SfTx6HKN0atXryBvRyqDktqsgalGie6NLgW2jkcRIoWI7qNP PPGEuffee9vdq+N1aMErKda1UNtcc80Vjy58X4rBm266ydx+++2BFdynn36aWId8mIa+THfaaSez 0EILJabzBb7yyivm2WefTUyyww47BAOjiZEZAvU81DX91FNPmf/85z/Bb1o2PSNWWmkls9xyywUL e+r51YhnRFo7iK8mIKXwQw89ZB5//PHgvut6xoe5ll9++eCakdHAYost1tBBICk5b7nlluBPfnY/ +uijsBlVv3qubr/99marrbYKnifRgRL1J2mtFA0W6dnhk+HDh5vbbrstMckqq6ySel2W7bmX2JEm BcpKV89cHQstEhx/j05qht4pdb5JGav7ht7zs4oMQG6++eaq5LonuuTiiy8OBmji8Ztsskkw+BYP b/Z++A3iqje+2Oguu+ziVGCrryeccEJT7r+t/k7h4k04BCAAAQhAAAJ1ErAKtA4V+0JasV1w/o0d O7ah7Tv11FOddatd9iXKWb/9sE7Maz/MgzzWOqSy5JJLJqaJ99m+cFfEIot88MEHFfvBlanceD3a tx9tlWuvvbZiP0CzVJcrjbUAr9gVyytWkVJT+2aeeeaKVfhXijruZWWl/lkla8V+yOfmZAciKtaa Pzgun3/+uTP/lltumevYxROXgd1+++2X2D+Fh2ItNiv9+/evuK7HpGsgGnbKKadU7EBVWJz39/jj j09sT7S8LNt2UMBZz1577eWtQ9dYR8gZZ5zhbJeu20bcT9TPt956Kzi2uqdYX50Vnf977LFH5Zhj jqmcd955daGwiuDKkUce6exXlmOp9lhL8LrakZRZ5/XAgQMr1i9pze2zCueKruM8cvjhhzvrs0qk PEW1pbWWdhU7UOssNwvnMI2eX1aRkvmabWuE3Tj99NOdbbjzzjujSZuyfddddznbo/6WUazFa8Bf 13x4TPL+5nnfycPAzpYI7gk6R/K2Se9qVmndVt1JJ52UWIbaniZ2ECwxr9p08sknp2WvlO25l9rg ghPo/cgqkStinfc4JqXXu5A1EMjUSmvQUkiddsAxU32NTqT3zCQmCtN1oudMVKwC35leeYrsV2d8 p4iyZBsCEIAABCAAgeIJdPgXUkcrsA866CDvy5qU0C5xKcykwNaHVFbldfhyGVXKJdVpLSkqhxxy iLe9YVlZfvVx8PLLLydVVVOY+u1ikqU90TTWYryij/tapcys7FTmuj/MxFkfyY1QYJeJXdqHvPpv fSXWfU3oQy6qvHCdd11Zge37ENa1K+Vgq4g+2qUEjd5z6t3eddddK3b6fiEIpCTcbrvtCmufBkWk mMgiRSqwR48eXTn00EML60f0GOkZYdepyNKltjQosNtQ1LRhra0DpVf0ONSzrQEpO+uoprbEM1mr /kLeP+xsuYp1y1MpswK72c+9OOtG7tsZVxVd2/WcV668en7HFbbxvnQ2BbadweRkefDBB8e7H+xr UNbF0Fq2J+apJbAzvVPU0n/yQAACEIAABCCQn0DHOvK0b0gdLXLb4JNafSRaRbPTDYCrPrkecYmm kGvq7bnnnutKkjtcU2SXWGIJ5/T8rAXa086cffbZwXR6uV0pQjTlV1Mw77jjjtzFlZnVe++9F0xV Fvt6RJzlxsAq+esppl3eMrOLN1Z+whdZZBGjxYXqFU1L1pRjFgV0k5RrCp8cddRRgQsOX5oyxGmd ALkA2HfffQttjvyDyr2FXO7UI7r3adr7jTfeWE8xVXkvvfRSI1+nmk7eLNEUcPXjnHPOaUiV4mQH iY0dhG1I+RT6PwJyF3LssceaVVddNZMLh//l9G/Jlcziiy9e931D7n+sMjzwp+6vMT32r3/9q9l/ //1l3JGeuANSdObn3kUXXRS4CXK5fKkXt7V+N3KtVNZjW2//4vmH2DV35ObHJXIJlSRi5BK5Bqz3 /TUsu7O8U4T94RcCEIAABCAAgcYT6NIKbL3E+nzbWavM3H6pdcjkU1vKjDwiH9XyAZ0kegmVIkAv jo2QDTbYwFx55ZU1FW0t7IxWLrdWezXlT8skX8Uuf8BJecvMSv2QwsXlvzapP2lh++yzT1qSzPFl ZhfvhHwWSyGXxR9mPK9rX4MCG220kZH/VKQ9ATtjIzh/28f8L0QKrqOPPjpYqPV/oeXZ0oKM8qkt P9eNEH3Y6xqv1Te3/AlrUKYoBUG0j7r/yL+ptUCMBjdkWwtgyrfqq6++2pDyw0J1zcqHsfzfI40h oPckPWf+/ve/N6QCHUPdN6xbs5rKVz4N5hYp1iWVOfHEE4ssspCyOvNz75JLLgkGDgoB5SlEa2QU OTjoqarDo7ROj0vmn3/+wBd9Uvw666xj7Cy/pKggrNbvhXiBneGdIt4n9iEAAQhAAAIQaCyBno0t vtyl64NeH08ucSmUXenDcOvXLdzM/Gunnycqy2UxJwWza3G/eAV6IdQCSVKIq292inUmZc3uu+8e LKS48sorx4v07p955pmpC+aFBay22mrmz3/+c7DgjawgZe2qBet8x0B51X8dKy2e5JMys7KuaMzq q6+e2lf1T8dQ1sB9+vQx+mDVIlSuhUZ9PPLElZldUj+uv/76pOB2YboWNMiiBRWziCy/tKCmdV2S mNy1oGtiYk/gBBNM4Iktb5QGqrTgmU+smwajv5133jlQLsoysgz9HTVqVDCrI6tSVfcrfeRrkU/r GsRogMf6SfZ1PYjToIoUANZ3t9EgaFZRPlmGp90PVZ7K1QCO7olaFFQzOzSbKO08t1O2gwXN7NoP WZtVU7rjjjsu0zNL/VhwwQXNTDPNZPr27RvUJc7607MrCws9G2VhfuCBB9bUVjL5CWhA6oorrvAn +iNWzy4trjvDDDMY68fYWHdZgQVoloFGWX3OMcccgSV1pspsIllw+6xFo+XoPqTBoamnntpoppEG mRplFBCtt8jtjnruFdmHpLJ0vWcdjNczfZZZZgn+dCy16KKe29bXv3Oxznide++9d7Co+cQTTxyP Mklh7RJlCJh00kkzpGpcEusGx1x22WXOCvTO7xI9rxXvmvGpxan1DPEpuV1lx8Nb+Z0i3hf2IQAB CEAAAhBoAgFrXdOh0lE+sLVoW9pCg/KR6pNa/D2rzqR89gU8sSr7Eun0RWdPjyDOKgEqdgptRf5G k0T+uK3FRGK9YRn6VTn2QzOpiMQwLVwWze/aPuussyquhefk69XlazJanhY7TJMys5KvwWh/kra1 0JBVVid2U4s2Wouw1DKi5eZZxLGs7Fw+sKP9jG7rPLn77rsrup7kxzQUbduptJX1118/laGugzwL Ekbrj25b5WdYfa7fsi7iqE5Y6/TU+2aUQbgtf87//Oc/cy8omAtcSmKrtEg99ro3249zp79oO9BT sW6NMvlotQrwXIvRZlmscZVVVqlYpVvVuR3t9nPPPZdp7QU9L1xSrw9sO0CQylls5MM/7TrTugq6 psPzyPVrFaeu7lSF4wO7CkfqjhbSczGPhuv55losVPdenZc+X7xhWbr3yr9zFtFCfzruYV7X7xFH HFHRuhNJYt1x5F5XJMu51qhFHF197IjnXhLPWsN8PpfVZ92X5b/at6i66rYzP4LFfV2couF6T8gq dmDReZ7leWfOWl8R6R599FFnm8UhXAjcVVfafdwOarmy5gpv5XeKXB0lMQQgAAEIQAAChRDosos4 ZlGMWWs2L+QkRXT0BTncltJaCxJGP9a1oNY//vGPyswzz1yRUiJJbrvtNu8LqMqXssta6SZlbxcm JbLvRVzl6UMii6gvWswl7GPSr+KzfoxK4aiP16RywjDr7sXZtDKz0nkU9sH1K0VBFrFWncE54yon Gp5VgV1mdlmuU/VZ16K1nK66xlw87fTw1OMhhUtWiTKPbndGBbaYSFGV9d4X5RFu6zq3VpOVq6++ OliEL21RrazHwZcu7WNcbbNuCDIP4Gmw8Jhjjkk9j6QwzSIaXAn5uH4HDBiQugCZ6pLCMG2wS88B l9SrwJZy2tUHhWdlErZP/clyj3IpUMNy9IsCO0rDv63B5bRnshbbs+5u/AVFYtMWbdP5IUV3Fklb hFVt13WfRfRukdbX8JwukwK7I597WbhmSaPFN0O2Sb96R05Ttsbr0YBF2ruunSEUz+bc95VVVgW2 9W/t5KpnXRbxDRBluQ6y1KE0rfhOkbVvpIMABCAAAQhAoFgCXU6BLaud0047zfliF75A6yM8TbIo cezCixU7dd1ZlNojC+m46KM9zUI8q9IzWrasHaTYDPuZ9Jvlg1QW3Ul5wzB9hOoDOI/Yxbi8ZcqS KknKzirN8iyPJZD6L6sxfdSFrF2/WRTYZWeXRYGt6yTvR2Sa8kMKwKzi4l+rAlsf37KyTfqzrnSy Nquh6dQ2V7/zhus+av3oV6wbiIp1B1F4u6Ugt+4DvO2VQl334rwia21ff9U36wbDW6yeD2nXs89i Oqlw9dm6evG2TYOoSVKPAlvnro+HdZWVVGWmMOuuylu2de+SWg4K7FREbQnSZkZJgTV8+PC29Fk3 nn766dQBsLQBRN3vfe9fup4+/PDDrE0K0mkQPe061LmdRXHXDAvsjn7u5YLrSZz2jNegfS0ia2zf oESe53OrKbCtixzvvVKziLKIXVTTW07adZqljjBNK71ThG3mFwIQgAAEIACB5hPoMgps68O0Yhdv yTQdWR8pTz75ZOrR8H1AqQx9YKQpL1yVSGHhUwTksR6J15GmMMmiZFhmmWWc7dNHg16gaxGfYlzl JimZyswqzfra+oqtBVNgWeY7PxSXRYFdZnYCk/Zxq37WovTUeeSzLpLyL6u4jkOeD+SsdZUpne6R WRQ+Lj6ucN03jzzyyOAeHJ21Umvf0z6MdS9Luq9krc+n8FUfNdPGJ2nW13ZNBV92Z5yePbKQdXG2 /lET8/r6k/Zc9N2/9bx0ublKbEgsMG2qeZrLLxWHAjsG1bErF2uu80bhOpZ2MWJH7vRgn4JX5ftm CKh0XRO+9umar0WyzNQoiwK7o597tfCN59EAuk/JLAVqPaJ3ftd5onM4q7SaAluDwb5++4xqoky+ /PJLZzkqv57vkGg94XarvFOE7eUXAhCAAAQgAIHmEyi9Als+su0Cdrn+5K5DL676oN1///1TXV3E X/TkJzeLpCmw7YI7WYpJTOObhq0XfrsoYGK+rIFqW7zf0X2fZZXcgkTTxrfFv1YZM2aM17JKPlHj UmZWUl7F+YT7Uv5JUVCrSMkXlpX0m0WBXWZ24pKmwBaDWuXss8928pNSM6sksVdYZ1dgi49mj6T5 7HbxyRKua+Tkk0+u636X5n++FkVQ9NyQX2wda1d/XANvYRl6RrnyyrdtPcr1Cy64wFm2XDwlST0K bJ+P+Xqu1bCdvnNN50maoMBOI/R7vJ7hrnNS4TfeeGO2gjypNFDuq8O1HoSK9A2gH3rooZ5a06N0 HvnaVQYFdj3XUlHPvXSS6SlefPFFL2vX2inpJf+eYtiwYd7ys95bW02B7Vs34IADDsiKL0i3+eab exnWe4zijWmFd4p4m9mHAAQgAAEIQKB5BEqvwPZ9SDQiTsqGrO4IfApsxclirBZJUxDnnU6e1AZZ NvosUG+66aakbEGYfNe62Mvir16ftj6FU/zDreys5ELGxeqcc85xMs4SkTZNNE2BXXZ2YpCmwNa0 71rFZ5mr8ziruI5vV1Bgh4wef/zxyrrrrus8112MsobrfqpBybz3Ft3nfBZ+eT/mw/7GfzUl29cX ly9e9cfXPt99ON6GpH35jvW1K2kgtB4FtpSSLmV+2poSSe2Ph/nciPz1r3+NJ2+3jwK7HZLEAJ// 3KLua2nuZuSeJ0nS8im+HtFsPd81UwYFdhmee/UwDvM+8cQTwRowSfdAuZWqV3T/9x3LrAYEraTA fv311719zuuGLG22xHnnnVfvYUrMX9Z3isTGEggBCEAAAhCAQNMIdLcvd0iEgPWjafr06RMJqW1z jTXWML169aops7VK8eZba621vPFZInv06GG23357Z1Kr3HPGWZ/Nzrg999zTdOvWzRmfJcJ+PBtr eWms72hjldnmkksuMdby2ljfz+bUU0+tKqLMrKwlibGzB6raG92xbiqiu7m3p556amOtY3LnCzOU mV3YRt+vVaSYOeaYw5fEGzfffPM54+3gkzOOiPYE7EK0xs6WMYMGDTJ2cUNjBwDaJ6ojxLrDMDvu uKNZeeWVjfWJmrkkqzg2dkDSmd4qXJ1xeSI22GADY5UwzizPPvtsYtxrr73mbJ9V2puNNtooMV/W wBlmmCHgZpVuRvdVa11q7EJ6Rlysos5MOeWUWYvKlM66EDHvvPOOsa4BjFUkGj1H7GwfYxdYNb7r LVPhNpHveueazUrRn84q/YJj5kq1zz77uKJyhfft29f4noGPPfZYYnnW5U5iuALtItRG5dYjuu72 3nvveopoaN7O9NzT/dwqKo11VWGsMjm4d1gDDWNnT5pjjz22bo56z7UuqZzl6FzvbPLPf/7T2SWd O0sssYQzPilC7+G6JlxiB5qMHYh1RdccXtZ3ipo7REYIQAACEIAABAoh0LOQUjpBIVI+6MV5ySWX LKQ3yy23XM3luJQdKlAvdbUqxuMNWmSRReJBbfuuj0c75dL4FNh2dfO2MmrdsNMfzSeffJIpe5lZ DRw40NkHnWdS0tcr1krJ3H777TUVU2Z2WTpkXSBkSeZM4/soQxnmxOaNmGeeeYJBJg00SdEspfbD Dz9sXPcTb2EJkU899ZSRMla/K6ywQkKK6iDrhqA6ILKnj3mVVYTonmwXgjRnnXVWYnFS0uy7777t 4nwDXLqXTjzxxO3y5A249tpr82apO3337t0DRaKUifU8C+MNmWSSSeJBbftcs20o6trQQLFPfEpn X76kOA1KaUAlSTRorYEQKSGjYi1Co7tV25tssknVfq07W2yxRTBwXmv+RubrrM893et0T9ZfkTLF FFM4i9P7bGcS69vaaBDRJbvttpsryhmuZ5sGdOzsl8Q0djZAMAix+uqrJ8bXG1i2d4p6+0N+CEAA AhCAAATqI9C9vuydI7csDKRsKUp5LSpLL710zXCk7HDJiiuu6IrKHe5T3tjp3oGFXrzQESNGxIOq 9vv161e13+idMrP68MMPnd1ffPHFnXF5IqTsr1XKzC5LnxZddNEsyZxpevZ0j9/pQxCpj8BCCy1k rMsf8+ijjwbWdfq1bh5MvQoYtWq99dYLrIjTWvjee+85k6y00krOuFoifPd8KdyTxC6ElxQchNV7 fjsLbrGIjz/+2Nx2221G1vJbb721s/V23pozjojsBAYPHuxMrJkVRcxQCyvwWYNq1sWQIUPCpG2/ svB3iW9Q3pUnKbzM1169bevszz27JoHR4Lxd6NMsu+yyxrrMSDrEQVhnu2dowFjXjUt8909XHoVr 9o5P7ILAvujC4srwTlFYZygIAhCAAAQgAIGaCLg1ODUV11qZdt9998CyoN4PgqRezzbbbEnBmcI0 Dd8lN9xwg2mWpZmm3k8++eRVTbELtlTtR3fswkrG93EUTVvUdplZ+VwX6EW8CJl99tlrLqbM7LJ0 atppp82SzJtGMy98x8mbmcjMBGRdZxcMDf5OOumkQKEtFzbWB6p54IEHvEqGpEr0ka7ZKFJOyELL JT4L7KIGkcK6fc8R1zlmfVSH2dv9FqWMa1dwCQOkSJIbASmrNfCnAdQ333wzOL4udiXsRqdokl3U 1NkPPeOLFLm48d2Dv/3223bV+a6ZItzUqMKpppoqcIMk69KyCc+934+IFNWaqadjpHcZDWzIJZPc I3VVueqqq5xdtwvs1uxeR++rMpZwsdUAo11TpebynY32RHTUO4WnSURBAAIQgAAEINAEAl1GgS13 AbK4W2qppYIXMU1rlg/hRkmtvkU1ZdZnQaGXdVmWNEPkwzkuPgtsnyIpXk4R+2Vn5VO8+Hy55mGj qfpSKjz//PN5sgVTs8t8nmXpjM8FSJb8pOk4AnIFseqqqwZ/UmjbBUkDNyN33XWXufHGGzM1TOev LLyVxyU+a9Ki71dp17TaGz9nhw8f7mq6qWdwylloB0doZoNmO0lBLaWTlKWyktc+Ug4CSVbPYcuK du+gcjWQpEGsJIkrsKW0dD23pAgvyr2a2qLZZGVUYMfvIUncOlOYlNRvvPFGcL/QPUP3dN0vfO9X nan/Wfsi1z+u60hl6Lp2uQHJUodvtpDyDxgwoBC/5VnakpSmWe8USXUTBgEIQAACEIBA8wiUXoEt f4d5rXp79+4dWA7rRT/8m3TSSeteXDDPYan1I0MLa5VFRo4c2a4pPgV23Fq7XeaCA8rOymcpViSr WqZ0l51dllOlSIZZ6iNN4whMM800Zssttwz+LrroomARL31su5RVYUvkj//tt982Cy64YBhU9RtX gEUjfb5Ro+mybmvxWt33XW3+7rvv2imwffcIPbM6i8ja/pxzznH6O+4s/ewM/fjpp5+c3ZBlctHi uw51zUTF9/5RhGVytC5fu6Lpmr3dFZ57uodqMUIZa6QpTpvNv6z1pQ38SumvAd9GyQUXXBCUn/d7 rVHtadQ7RaPaS7kQgAAEIAABCGQjUHoF9jrrrJNbgZ2t641LJSWGlBm1SJLVcy3lFJEn/vGoMjXN 2yW1Ku1d5aWFtzKrIpVTtXxol51d2rFXfFk+lLK0lTTZCUhJdtxxx5n99tvPHHbYYcY3LVqlSjEq 668k8blbasT9SoNJLgW2rrlZZpmlqpk+C88i7xFVlTZpZ/z48YFFoJRQLh/gTWoK1eQg4PP/3wjl qW+2WvwdxGd1W/SgbCPuDzkOgzNpZ37uyQ3FJZdcYs4//3znfdQJpgtH6F7bv3//DiWga1M+uDfa aKMObUdS5UW+UySVTxgEIAABCEAAAs0jwCKODWA90UQT1Vyqz/qp5kJrzJi0QrtLOaMqZPneTCk7 K1/7fv7558JQ1aLo8rWtsIZlLCjpPMuYlWSdmIAUW1dccYWRixGfXHPNNc51AXxWmePGjfMVW3jc hBNOWFVmWv2trKiSZblcG22wwQYor6uOevl3fNdMXKFcRG/kBssl8WtGbsNcIhciRYqvriLroazf CWghwJlmmsmccsophSmviz4nynqsBg4cWApL9Y5WoqcdnyLeKdLqIB4CEIAABCAAgcYSKL0FdmO7 X77S61F+F92bJAWKzyqpSKVslr6UndX0008f+HhN6ksS26R0WcJqUQCXnV2WfpOmeQTke1YLuOpP llbh7xprrGEWXnjhhjVEM1n++te/mtdff93ceeedznqGDRtm5p577nbxo0ePbhcWBshqrWjxDQxp SnNU0u4BsoSNK/Ci+cu6/cEHHwSLdRYx9X/mmWc2OsdWX331oEwt0ialONI4Aj4LbC2cVrT4BsXj yvQ81tr1trNMs5Tq7UvZ8x9zzDHmtNNOK6SZa6+9ttEaN2uttVaw5s2SSy7pXHywkApLUIgGccsg Dz30ULAIb9KzON6+Vn2niPeDfQhAAAIQgAAEmksABXZzeafWluZjUquA+5TIqRXkSDDDDDO0S+1r n+9DtF1BBQT42qLiO5rVjDPO6OxlkaxqmTpddnZOcEQ0ncBZZ51ljjjiiMR6jzrqqIYqsMNKTz31 VK8C++OPP05UYEtp7HLTUeQ1GLbT5+IgydWPLARdeaQMT7tOw3rL8qsBg0022aQma8Dll1/eLLTQ QkYLBc4333xmkUUWMXEF5gsvvFCWrnbadvgWt26EUtdn1R0//j4Fts8/di0HqxF9raUdnT3PzTff XJPyes455zSLLrqoWWCBBYL7RfgbHxj0DWJ2BrZaq0b+wssicvmVNhjRyu8UZeFMOyAAAQhAAAJd lQAK7JId+TQfk5p2nsW6oVHdauYHZFofys5K02FdUuTH9jfffOOqxhlednbOhhPRdAI+10DPPPNM U9ojhaYUm1qIKkmGDBmSFNxOARpN5PPnH02Xddu3YKQU1UmuEjRI6FJgSzER95mdtS0dle7EE090 HqNom2S1v9lmmwUWkjqus846a6Z1I5IWFo6Wy3b9BHyDJsOHD6+/glgJQ4cOjYX8bzePAlsDUnqu 1rKo8f9q/N+WFodFGkvgs88+M3vssUemSrbZZhsj62ot2KvnwSSTTJIpn2YLuaRSqbiiWib89ttv 97ZVfGtxM+cqVOtKaKFll1x88cXmhBNO8M4eauV3Cle/CYcABCAAAQhAoDkEUGA3h3PmWmQ9Igtr l3Xgm2++aTQlsqPEp8DW9O6iRNP7ZTnjm7JcdlZJFuwhH7lE0AdZEVLLh3bZ2RXBhTKKIfCnP/3J WZAW55MLm169ejnTFBUxzzzzOJWjLivOuNuOaFt0v1p//fWjQXVt697sErnCSBKftauU9UW4Z5GS RvdSuSOpdXHhpLbHw6Rc1oKNPpEi/+677w78Y/vSueJ8gwSdQRnl6nczw30K7BdffLHQpshdie+6 iV+/Ood1Lbnc0+hZuOqqq9bdRg1uuQaW6i6cAtoIyO+16103TKTFfGWxW4s7Jd0TfMexM9wzLr/8 8hBVu189u8W4aHnjjTecaxvoeMrd17bbbuustpXfKZydIgICEIAABCAAgaYQcK+e05TqqSSJwLzz zpsUHITJLUZHyuyzz+6sXlP10z5GnJljEdtvv31gYSM/0iuttJLZZZddzMknn2yuv/76qjrKzMqn wH7ppZdiPa5tV4ul+T7QfKWWmZ2v3cQ1l4DvY1Mtuffee5vSIFl+ucRlqew7x19++WVXcTWF+wbw dB9LEh/bt956KylL7jC1SwOBsgDXNHu5+DjkkEOMLOWKdMlxyy23eNumgVe1RYs71io+BTaL7tVK tTqf75x84oknTJGc33nnnerKY3tJA+Y+BXVR70e+aznWRHZrJKCBzzTl6qWXXmouvPDCmpTXapZv TQLFN2IdBJXbLNHgj+9dcvfdd29IU9Ks5vVs8YnvHqN8ZX6n8PWLOAhAAAIQgAAEGk8ABXbjGeeu YbXVVnPm8b2sOjM5IvQh+q9//cvIB+Gzzz5rPvnkEyMXJT7RVG/fyu6vvPKKL3umuDFjxgRtUmIp Z2XlqUVqtJjbjjvuWPVRUmZWSy21lLO/jz32WFU/nAlTIur5YC8zu5RuE91EArPNNpu3tpNOOsk0 w5JNVl8ucblV0mJeLtE1qIWkipIHHnjAWdRcc82VGLfssssmhitQ970i5NFHH20rRlbdsoA+77zz jCwbb7jhhra4ejcefPBBZxGaVSTeffv2dabJEvHcc885kzXjHHRW3okiFl98cW9vinwH+c9//uOs S0qupBkDvmv6xhtvdJaXJyJtMCZPWaRNJqABOt/g+5lnnmn23HPP5MwZQ9Pej1r9niGDDp9stdVW vuia4zQI6hO5FvPNrGjldwpfv4mDAAQgAAEIQKDxBFBgN55x7hp8H2j6eHz++edzl5mUQYqMLbfc MpjqpwW0pJyWKwApW7SCu/wTJskaa6yRFByEFfHh55umLCu+6OKIZWYl60+fpckdd9zh5Jg1Iu0D xldOmdn52k1ccwnI3YzuDy7Rh+p9993nii4k/PHHH3e6DVAFLgXxEkss4aw/nOrsTJAjQrNPHnnk EWeODTfcMDFu6aWXTgxXoBTYw4YNc8ZnjfApljfYYIOsxaSm++CDD5xp9t9//7r9sMpFiSyAXZI2 +OrKR3g1AVnr+6zkr7766uoMNe7J+tVnqelSvq244orOGqWw9CnOnBkjEVq8UQPmSGMJyGDCJ2lW vr68YZzv3qc0rXzPkKGHLNRdIgMFvdM3QuRTe6+99vIWfcUVVzjjW/mdwtkpIiAAAQhAAAIQaAoB FNhNwZyvEt/Ho0qSVUq9L976eJTlZJJIGSNrR5eltU/xKYu+eq0aZannkvhHbdlZyRWKSy655JK6 LFe1OJGs52uVsrOrtV9lyVfvNVqWfqgdBx10kLc5Os/rVRy5KpCV3PHHH++KDu5TLr+9svz1rRmg xaiKsMLz+SFVG1ZZZZXE9suvt+JdctNNN7miMoVrCr3vfrryyitnKidLItcCm8qrRdfqlbvuustb hPx8I8UQcJ2vKl2KKd/CeFlb8NBDD3kHpVxWnnKD43t2aaZWPXL66afXk528GQm4/Jgru/ycTzHF FBlLSk6m+8Gtt96aHPlHqM8tVTRj0gK8YbxcoXSE/Pvf/65ypxdvw0477RQPKnQ/rXw9W30uBVv1 naJQiBQGAQhAAAIQgEBuAiiwcyNrfAYpjl0We6pdiiKf5UWWFt5///1ehdOhhx7qXJht0003dVah F9ZTTz3VGZ8WMXz4cHPOOec4k8W5lJ2V6yNcHZQlfT2WXj6lnhNgJKLs7CJNLfWmSwHpWliw1J1x NE7n8ZxzzumINcGH6gorrGDee+89Z5paIqRc1r1IU5JdcsQRR7iigvDddtvNGa9rMM0PqzPzHxHy l+tbvFCDbr17904sRooRX/t0L5Wf+1rFdy/dYYcdzAQTTFBr0bny6b5ej2g20IEHHugtIqsyylsI kQEBueryyb777uuLTo3Te4LPwlYKzMUWW8xZzgEHHOCM08yyWgd+dD9Age1E27QIKbfrHQA+8cQT jYwxfJJV+exbpFgLkXaEXHXVVd5qN954Y298vZEaRPLNMFT5vhmZrfxOUS878kMAAhCAAAQgUDsB FNi1s2tozsMPP9xbvqZku1x8eDPaSL3U+5Qmyv9///d/zmLkx3TnnXd2xv/97383tfjClrJK7XJZ behlWRaLcSkzq4UXXtj7ki+lzIcffhjvUur+ww8/XPcghiopM7tUCCVPIP+eWT+QS94Voym/xxxz jLeZum7lNkf+lYtQJsqCTooqlecSDR6k3cukqHUNMqjcvffe27z99tuuKrzhcjeg8n2yxRZb+KLN Pvvs44wXU93ra1lsTMo4KXFc4htcc+XxhfsGONSWWkVrNey6667O50JYbkcpksL6O9Pv/PPPb9Zf f31nl2TZWuvgq85lXdc+C1wp0JP8X4cN0iC6a4aY0my33XZGz8g8ooEouU5DmkPAd/zUAt+MjrQW yv2Sb1AxzJ/1nuEagFQ5X375ZVhc03517cgIxSU6/+u1YHeVHQ33PbuUTgtwuqSV3ylcfSIcAhCA AAQgAIHGE0CB3XjGNdUgP4++qe8qdKWVVsqt/Pz888/Nmmuu6V08R77tpp12Wm+7pVTxyaqrrmr0 QZhH+vfv730p33bbbROLKzsrn7W8FFTyL5xHiT1w4ECz9tprJ7LIG1h2dnn70xHp+/Tp46w2rxJF BV177bVGysWkv6233tpk/eh2NqrGCLkJSVM6qOhDDjkkcBkhlw+1uHWQ5Z0Y9OvXz2gask80DTnt Q10+fQ877DBfMUZukV5++WVvmnik3CjIz6hP0aIBLN9iqSpTC1D6rOVuv/32QMkuRW5WkfW/z32R yilaWafj5RL1wbdgnyvfN998E7CRu4k00WACUhwBzXzwyS677GLy+sPWtS3L6zTltwYsfDLhhBOm 3hv0jJSP7TRLXg2cy1JU7nRcg+e+thBXG4FZZpnFm1GD+2nHLqmA2267LXg3ToqLh8nFUhaZfPLJ nclk8d9sSVusNG1Qtaj2brPNNt6iNFvUN3jZqu8U3k4TCQEIQAACEIBAYwnYl/cOFevHrWJ76Pyz Fowd2j5f5daqL7HdVsnjy5Y57rnnnkssP8pLbRgwYEAljZO1eqrYhdYq1oo5tUz70pmpjfYl2VuW 2nbllVdW7EeItzw7vbxi/el5y7JTiitWmeEsp+ysrEW7t39i9a9//cvZP0WIo/0g95YTPTfsAp3e 8sLIMrPbb7/9nP194YUXwi7U/KtrNcos3NbxyCp2Km1iGWFZ1k95ZejQoRVdg1bJVtH57rte7QCS tzyrOM3atMLTWSWvt21hn6O/1oVGxU7pDxhY5Xu7NomLtWKrWCVnRX13HZNomdrWPWHEiBHtyksK +Pbbb4P08TLi++eee27FLo6VVERVmO6lqj+eP77/zjvvVOVz7eieG88b37cWsZXBgwe7imgLF8c0 hv/4xz/a0sc37KwMZ1uefPLJePK2/QsuuMCZT33RNfXuu++2pU/bsAN1mRiHnOxgQVqRFesewtnG O++8MzV/0QnsII+zPeqXHShu6J91v+O8F+m63Hzzzb3tUxt1zWa5Du0sh4r1rZ1a3j//+c/MmHVN hMff9WtdkVRUZvy++cMPP1SsJXmmNkXLznKe3Xvvvc52nXzyyan9a4XnXmonUhLYWTrBPSHKNr5t B1Gc52e8eD1b7YCmk3u8bO3rOGWR4447zluudfVU0b1ez3W7BkzFLlCZud1Z6o+msQOZFTvbxdke 3WfFtlmi98wktmGYna3pbUqrvlN4O0UkBCAAAQhAAAINI6AFrDpUUGD78Vsfpt6Xw/Al0U75rZx5 5pkVKUL0Ai3RB5pdjLEiBZq15s5UjsrIKvpg8L1Ih23TB5+UGx988EGgHNKHsV7wH3nkkcppp52W +hGjcl599dXUZpWZlT6e9WERMnH9WmvNirWuCRR64iSl9bBhwyrWiruiD3FXvqTwrApsgS0ru1b4 kLfTdXMdFx0ra5XkPJ/LrMBWo601bO7+Rs9PXQe6b0jJmqZojeaLbquMQYMGORkmRWT9UFbbpJDQ vfPnn38OipJC4OOPP67YBewyK7zswo5JzXCG6RqP9tG1rfNDx0BKed0j1MbXX389GCRYd911U8vQ +eqTWhXYQ4YMSa1bfbLTzoN7WlIbNEgpDnpmuPrvCtc5kSatpsB29bXIcGt17MQ2cuTITM94sT/4 4IMrGuBQHokUbdaNUkUDA2mD3WF/0s7NeEN1TaruMH/ar+43Sp9l8MlVFgrs+FGofT/tWadjIKOL O+64I1Epq/cjDcDvvvvumc+B6HG16x9karzu5dF8WbY1GNoI0cCer35dh82UtG84tTU+eBRvX6u+ U8T7wT4EIAABCEAAAo0ngAK7DsauDyd9JBUlUlBYf4/eF1bfy2yeuCOPPDJ3s7MqhfK0I57WuhPI 1K6ys7JTTZtyHEN+eRTYZWXXCgps6/M993H1WRmmfdSnfQxmuljqTKRrMjzPOuJXSota5JJLLmlK u/Nce2E/dA2mWbPVy1oDnXbafFhl4m+tCmwVZt3HZOar56cG5aR016/reZqnz2kW3iiw28928ymw dUw1eJznGNSaVgNHofJb9WYVDTQVce5kbbfO1TTBAjuN0O/x1pdzrnNLAw8a5NdfFuOJtGOadcDk 6aefztVO1ZtmeZyNUPtUabP5XnrppfaZGhgiq/O0gWi7jkVqC1r1nSK1YySAAAQgAAEIQKBQAvjA tm+aZRYtZGSn33sXTSyi/fJLaa2hcxe1+OKLmyeeeMK7SFruQiMZrALTaEGnLFJ2VhtttJGxVudZ upI5jf2IM/JjXa+UnV29/Wtkft9iZ656fX6TXXnKFK5r8rrrrmvYde/qq1VUBdeQddviSuINt4MD xlrTedPUG2ndMpgbbrghdzG6BuX72ypVcufNkkHs5K91kkkmyZK8pjR2qr130dpoofI3bJWj5oEH Hgh+s/gfHjBggLEuGKLFVG1rcUGkWAKLLrqosQNGDb3W5a9adUw55ZS5G28tomvyr+6qSNeJdRHk ijYTTTSRM46IfARmmmkmY62gM2fS4oWPPfZY8KfFyNNE6w/YmX/OZPIlbWcqOuPDCK1HY5W04W6m X/l/Llq0toHP77wWOl9iiSWKrtZbnhZj3HPPPb1ptJijHaD1pmnVdwpvp4iEAAQgAAEIQKBwAiiw C0dafIETTDBB8NJai4I5S2uspUiw2JEUKLWIFj+y/oiNtY6pJbszz957722sawtnfFJE2VmtscYa gbIm78dQUl/1oX3PPfeYGWaYISk6d1jZ2eXuUJMySIGixQTziPUHmyd5KdNqoSgpEez07aa0T8pn 6zLA6BqqR9ReLSio66dICa/HM844w/Tq1aumorU4nQYGjj766JryuzLpfvPggw8GC0a60hQRPtVU UxktXFrE/S3aHms5HiyWqWeV7/hbFy+aVRbNynYBBDRgJIWcjkPRogGJ+++/v65zZqmllgruDRtu uGFdzdNgsAZVFlhgAWc5ek4ixRGQ8cSJJ55YXIF/lHTKKacE9yItkmtneTjL1ztUmvTu3dv4FuNO yq/zKM/Cu0llxMOsK5V4UNW+tc6u2m/WTpqRid4TNPCQJq36TpHWL+IhAAEIQAACECiOAArs4lg2 tCQpl4866ihjpwcaWSsVIRtvvLF55ZVXjKzaZEVRj8w333zBB+4xxxxTTzFBXimCZCnYv39/ow+H vFJ2VrJoe/HFF41d3C5v19rS28WwAoWO70O7LXGOjbKzy9GVpia1PpNzWc7aae9NbV+jKpt22mkD i2ZZT8pKrRGiAYJnnnnGWPcfZuqppy6kitVXX91YH9rG+mMupDzr5im4/9WrQFNjunfvbqxbGvPo o48a666g7vbJolt9XW655eouK0sBs802W2D1ePzxx2dJ7k2jQVFZHFof30bPGIksDF2DD7LQ1GAq UjyB2WefPXj/OPvss53889Sq+4WUWrLa79GjR56siWl13kkZaRdDzn0v0oCL3oM0m0wKT7uQa2Id CsQC24mm5ogTTjjBWN/OhdzvpEzV/e7YY49tO69878zXX399pnbrHp/XoMKuX5Kp7KyJNEDnk623 3toX3bC4fv36pc4EzDrzqVXfKRoGl4IhAAEIQAACEKgmUKhDkhoK06I/tkXOPy3SUlZxLQQk33yN Fi3kYhWgNfl+lE9t+bVslGiBRq0Gbz8Kncc16ZiLmxbLCRdOK6p9ZWb1/vvvV9J8HkdZaUGjiy66 qGqFe5dPRGutWDfCjmYnv+zR/ke333rrrbr7J57RMsNtnbu1iBbgtANDiWWGZYe/8h2ZJIceeqg3 vxZPLat8+OGHwfm55pprevsQMnD9yleztaCrFHGM01hpcVktLJj3fqX7v/yfy49ro0QL4Vm3GIHP VxcrV/hOO+0ULESZt20nnXSS89hpzYM8MnTo0IpVKDnLc7V9+eWXr1x11VXBor9J9enZ58p78cUX J2UJwnTvdOXTQmLNFi1k7GpPs8LDRZ/z9F0CRVfPAABAAElEQVS+qq3ldEXXad527r///g19/wj7 oUVFtXi0/MrrfIq+r+ldww4CBwtPyr9x/D1T70eufmlByjSxinln/iz+gFvtuZfGI2u87ndWoZz7 Xqx7t96jXD7w9RxxHU87GBYsOJq1jXYwtbLrrrtmevdW2qJEvupdfVC4nT1QVFU1lWNnDnnbl5dz 2IhWfKcI284vBCAAAQhAAALFE+imIu3LD9KiBOyHV2BF/dRTT5nPPvvMfPXVV2b48OFGvvLkT1I+ 8eQneY455jCyoNKfLByaITq13nnnncCS0CoyzJdffhm0zS5CZ6aYYopgyrD98Ags6jR1V1YcjZQy s/riiy+C42hf1gPrRVkQ6RjOOOOMZpZZZgncs8iKqNn+DcPjUWZ2YRvL9Dtq1Cjz7LPPBtPa5ftR LiV0PcqiVH4/dd4XYXVYpj7H26LzVzM8Pv/88+DepPuTHdwK/uxCgqZv377GKvEDHmIy/fTTB+f7 sssu2/B7Qbyt2tf9Sq5dZIVplV/B/WrEiBHmm2++CY6d7qGy8tQ9dK655jJLL710U4+hfLWqbZqF E95Lda/XNHWx031d93rdS+XyoZG+rpP4+cJ0DmgaubgOHjw4uMeFvmnlAin8k1Wu2l+LL2Rf/cQ1 jkDol1h+/XVehn+yVA7fO2adddbg2rGK5FKdly4qsgzXLI0kkY97uQlCGkdAFvC6P+h+ofuG7hl2 sN/ofqx7g+4XuufpficXdgsuuKCp1QVerb3Qc/21114zVjlu9DybZpppgjbofU3PMz3faplBWGt7 ukK+Vnun6ArHhD5CAAIQgAAEmk0ABXaziVMfBCAAAQhAAAIQgEApCWgRVvnjTZJzzz3XHHzwwUlR hEEAAhCAAAQgAAEIQAACDSRQn+PjBjaMoiEAAQhAAAIQgAAEIBAlID/XsnqVv2pZ4WqmUpEWuFqw 0iWysEUgAAEIQAACEIAABCAAgeYTwAK7+cypEQIQgAAEIAABCECgBgJJymq5n9loo42CRSFrKLIt i9w/yT2F9TncFhbdkCuLRrs7i9bHNgQgAAEIQAACEIAABCDwOwEU2JwJEIAABCAAAQhAAAItQUAK Zq33kSR2UUoj/9u1yrXXXmvsAqjO7PI53717d2c8ERCAAAQgAAEIQAACEIBAYwjwFt4YrpQKAQhA AAIQgAAEIFAwAS3i5xItdFqrjBw50px66qnO7FtuuSXKaycdIiAAAQhAAAIQgAAEINBYAiiwG8uX 0iEAAQhAAAIQgAAECiKw/PLLO0vaY489zIgRI5zxrgi5DFlvvfWMXIS4ZMcdd3RFEQ4BCEAAAhCA AAQgAAEINJgACuwGA6Z4CEAAAhCAAAQgAIFiCKy//vrOgj799FOj+DfeeMOZJh7x2muvBXmef/75 eFTb/sILL2zWXnvttn02IAABCEAAAhCAAAQgAIHmEsAHdnN5UxsEIAABCEAAAhCAQI0E5Od6jjnm cPrBDouVIvuggw4y88wzj5lxxhlNz549g6jRo0ebL774wvz3v/81559/vnnkkUfCLM7ft99+2yyw wALOeCIgAAEIQAACEIAABCAAgcYSQIHdWL6UDgEIQAACEIAABCBQIIE77rjDbL755rlKnG666YL0 rgUgXYVdeOGFZr/99nNFEw4BCEAAAhCAAAQgAAEINIEACuwmQKYKCEAAAhCAAAQgAIHiCOy2227m qquuKq7AhJJ23XVXc/nll7N4YwIbgiAAAQhAAAIQgAAEINBMAvjAbiZt6oIABCAAAQhAAAIQqJuA FMtyEdIoufbaa82VV16J8rpRgCkXAhCAAAQgAAEIQAACOQhggZ0DFkkhAAEIQAACEIAABMpDYODA geb00083DzzwQCGN0oKNN998s5lvvvkKKY9CIAABCEAAAhCAAAQgAIH6CaDArp8hJUAAAhCAAAQg AAEIdCCBV1991Zxxxhnm1ltvzd2KySabzGy//fZmxx13NMsuu6zp1q1b7jLIAAEIQAACEIAABCAA AQg0jgAK7MaxpWQIQAACEIAABCAAgSYSGDJkiHnnnXfM0KFDg7+PPvrIKOyDDz4IWtGvXz8z00wz mZlnntn07dvXzD///Gbdddc1E000URNbSVUQgAAEIAABCEAAAhCAQB4CKLDz0CItBCAAAQhAAAIQ gAAEIAABCEAAAhCAAAQgAAEINI0Aizg2DTUVQQACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAQB4C KLDz0CItBCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEINI0ACuymoaYiCEAAAhCAAAQgAAEIQAAC EIAABCAAAQhAAAIQyEMABXYeWqSFAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIACBphFAgd001FQE AQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACeQigwM5Di7QQgAAEIAABCEAAAhCAAAQgAAEIQAAC EIAABCDQNAIosJuGmoogAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAgDwEU2HlokRYCEIAABCAA AQhAAAIQgAAEIAABCEAAAhCAAASaRgAFdtNQUxEEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQjk IYACOw8t0kIAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgEDTCKDAbhpqKoIABCAAAQhAAAIQgAAE IAABCEAAAhCAAAQgAIE8BFBg56FFWghAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEGgaARTYTUNN RRCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIJCHAArsPLRICwEIQAACEIAABCAAAQhAAAIQgAAE IAABCEAAAk0jgAK7aaipCAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABPIQQIGdhxZpIQABCEAA AhCAAAQgAAEIQAACEIAABCAAAQhAoGkEUGA3DTUVQQACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCA QB4CKLDz0CItBCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEINI0ACuymoaYiCEAAAhCAAAQgAAEI QAACEIAABCAAAQhAAAIQyEMABXYeWqSFAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIACBphFAgd00 1FQEAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACeQigwM5Di7QQgAAEIAABCEAAAhCAAAQgAAEI QAACEIAABCDQNAIosJuGmoogAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAgDwEU2HlokRYCEIAA BCAAAQhAAAIQgAAEIAABCEAAAhCAAASaRgAFdtNQUxEEIAABCEAAAhCAAAQgAAEIQAACEIAABCAA AQjkIYACOw8t0kIAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgEDTCKDAbhpqKoIABCAAAQhAAAIQ gAAEIAABCEAAAhCAAAQgAIE8BFBg56FFWghAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEGgaARTY TUNNRRCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIJCHAArsPLRICwEIQAACEIAABCAAAQhAAAIQ gAAEIAABCEAAAk0jgAK7aaipCAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABPIQQIGdhxZpIQAB CEAAAhCAAAQgAAEIQAACEIAABCAAAQhAoGkEUGA3DTUVQQACEIAABCAAAQhAAAIQgAAEIAABCEAA AhCAQB4CKLDz0CItBCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEINI0ACuymoaYiCEAAAhCAAAQg AAEIQAACEIAABCAAAQhAAAIQyEMABXYeWqSFAAQgAAEIQAACEIAABBIJ7LLLLkZ/CAQgAAEIQAAC EIAABIokgAK7SJqUBQEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAoURQIFdGEoKggAEIAABCEAA AhCAAAQgAAEIQAACEIAABCAAgSIJoMAukiZlQQACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAQGEE UGAXhpKCIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAoEgCKLCLpElZEIAABCAAAQhAAAIQgAAE IAABCEAAAhCAAAQgUBgBFNiFoaQgCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQKJIACuwiaVIW BCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIFEYABXZhKCkIAhCAAAQgAAEIQAACEIAABCAAAQhA AAIQgAAEiiSAArtImpQFAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAAChRFAgV0YSgqCAAQgAAEI QAACEIAABCAAAQhAAAIQgAAEIACBIgmgwC6SJmVBAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIBA YQRQYBeGkoIgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCECgSAIosIukSVkQgAAEIAABCEAAAhCA AAQgAAEIQAACEIAABCBQGAEU2IWhpCAIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhAokkC3ipUi C6QsCEAAAhCAAAQgAAEIQKDrERg0aJDp1q2bmWeeebpe5+kxBCAAAQhAAAIQgEDDCKDAbhhaCoYA BCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAIF6COBCpB565IUABCAAAQhAAAIQgAAEIAABCEAAAhCA AAQgAIGGEUCB3TC0FAwBCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAL1EECBXQ898kIAAhCAAAQg AAEIQAACEIAABCAAAQhAAAIQgEDDCKDAbhhaCoYABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAIF6 CKDAroceeSEAAQhAAAIQgAAEIACBgMAuu+xi9IdAAAIQgAAEIAABCECgSAIosIukSVkQgAAEIAAB CEAAAhCAAAQgAAEIQAACEIAABCBQGAEU2IWhpCAIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhAo kgAK7CJpUhYEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQgURgAFdmEoKQgCEIAABCAAAQhAAAIQ gAAEIAABCEAAAhCAAASKJIACu0ialAUBCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAKFEUCBXRhK CoIABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAIEiCaDALpImZUEAAhCAAAQgAAEIQAACEIAABCAA AQhAAAIQgEBhBFBgF4aSgiAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQKBIAiiwi6RJWRCAAAQg AAEIQAACEIAABCAAAQhAAAIQgAAEIFAYARTYhaGkIAhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAAC ECiSQM8iC6MsCEAAAhCAAAQgAAEIQAACECgXgTG/ji1Xg2gNBJpAoFu3bqZ3L1QeTUBNFRCAAAQa TgAL7IYjpgIIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCohQAK7FqokQcCEIAABCAAAQhAAAIQ gAAEIAABCEAAAhCAAAQaTgAFdsMRUwEEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQjUQqBbxUot GckDAQhAAAIQgAAEIAABCEAgJDBo0CAjn7PzzDNPGMRvSQjgA7skB4JmNJUAPrCbipvKIAABCDSU AArshuKlcAhAAAIQgAAEIAABCEAAAh1LAAV2x/Kn9o4hgAK7Y7hTKwQgAIFGEMCFSCOoUiYEIAAB CEAAAhCAAAQgAAEIQAACEIAABCAAAQjUTQAFdt0IKQACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCA AAQaQQAFdiOoUiYEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQjUTQAFdt0IKQACEIAABCAAAQhA AAIQgAAEIAABCEAAAhCAAAQaQQAFdiOoUiYEIAABCEAAAhCAAAS6GIFddtnF6A+BAAQgAAEIQAAC EIBAkQRQYBdJk7IgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCECgMAIosAtDSUEQgAAEIAABCEAA AhCAAAQgAAEIQAACEIAABCBQJAEU2EXSpCwIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhAojAAK 7MJQUhAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQgUSaBnkYVRFgQgAIE4gUqlEg9iv4UIdOvW rYVaS1MhAAEIQAACEIAABCAAAQhAAAIQ6GwEUGB3tiNKfyBQQgK/jh1XwlbRpCwEJujdK0sy0kAA AhCAAAQgAAEIQAACEIAABCAAgYYQQIHdEKwUCgEIQAACEIAABCAAAQhAoLUJaCbdr2PHmm+//d78 /MsoM2r0GDN23FhTpgl2mi3W2w64TzThBGaySSY2U045hendi8/c1j7zaD0EIAABCECgmgBP9moe 7EEAAhCAAAQgAAEIQAACEOjyBMaN+81898MP5osvvzY//vizGfPrr1aZPc789ttvpWPTs2cPq7Tu ZSa0Suwpv//RzDjdNGbyySY1uEIr3aGiQRCAAAQgAIGaCKDArgkbmSAAgaIJyMJHHxmhz+zAc3aZ zHuK7nCHlNfNMv6jYv3+4Z6cj7sOORhUCgEIQAACECgtgbHW6nrkdz+YYZ99YUZ8813b+1lZGyxl u/5+GTXa/PjTz+bXMb+a2Wbpaya1Ftk9enQva7NpFwQgAAEIQAACGQmgwM4IimQQgEBjCIQK61B5 rf3u3bubnj16mO5W2xooVyPK1sa0opOXGvCrmPGW7fjx463l1PhAeR0qrsPBg05Oge5BAAIQgAAE IJCBwG/2XeHHn34xQz+V8npkhhzlSjLWWol/Pvwr+z7Zzcwx28xm4okmxBK7XIeI1kAAAhCAAARy E0CBnRsZGSAAgSIIRBXXKk+KVVnI9OzR01rPjDHfjPzOjBkz1sgCCAVrfcTFr4cdEJhggt5mIvsR N8VkkwQfcmPH/hZYZIeDB6olVGrXVyO5IQABCEAAAhBoVQJjrPXy199+15LK65C5Bu0/+Xy4meoP f9i9rHsRBAIQgAAEIACB1iWAArt1jx0th0BLEwgVpaEiu1fPnuanX34xHw351Ppb/NH8PGqUVWD/ ahcKGocCu84j3abA7t078A05+aSTmJlm7GNmnL6PZWuNse1/0eMRbtdZLdkhAAEIQAACEGhBAj// /EtgSNCCTa9qst5xRnzzrfWFPYlBgV2Fhh0IQAACEIBAyxFAgd1yh4wGQ6D1CYQKU1ldy11IpTLe vDf4YzP0k8+tEntU0EG5EJHVcE+r2MaDSH3HPOQn3j/9/LP53g4QfDXiWzNsmuFmvn5zmikmn/R3 tyK2Gimvw+NTX63khgAEIAABCECgFQmMtgYEUmJ3BvnJ9kMuRRAIQAACEIAABFqbAArs1j5+tB4C LUcgVI6Gymv9vj3oQ/PxsM8C5akssbXQoKxmJEqvaaBYBf/Oo5b/Q35i2KObHRSwblrk3/KL4SMC H5eLLjSvmXbqqawS+zeU17UAJg8EIAABCECgExHQ+4BmwHUG0aKO42x/EAhAAAIQgAAEWpsACuzW Pn60HgItRyBq4Svl9H8HDQ6U17K2DpXU48dXK6zD8JbrbEkaHOVXMfIZYoIFMrtbf5C/WMuk194c ZJZYZAEz5RSTBb7Iw0GGkjSfZkAAAhCAQIsQGDBgQIu0lGb6CMiGIDQk8KVrhbhx434fnG+FttJG CEAAAhCAAATcBLq7o4iBAAQgUCwBKUbDv169egYuQz6ylteh8lpxkqjCtdgWUFq3wCHL75bt4i0X LXIr8tZ/3w+srcQ+PEbQggAEIAABCEAAAq1OIHy/bPV+0H4IQAACEIBAVyaAArsrH336DoEmEwiV o/J7/dPPo8ywz4ZbbTV+l5t8GILqdCz0J/ciWtjom+++D1yKKEwS/gY7/AcBCEAAAhCAAAQgAAEI QAACEIAABDqIAArsDgJPtRDoigRCC5iePXuYTz8fbr4d+Z31x9wDv8sdeDJIUa3j0sMOKgz++NPA D3YY1oHNomoIQAACEIAABCAAAQhAAAIQgAAEIBAQQIHNiQABCDSNgBSlsr4ePXqMGfndj21Wvlj7 Nu0QeCsaNWqU+Wbk98ExCnxle1MTCQEIQAACEIAABCAAAQhAAAIQgAAEGk8ABXbjGVMDBCDwBwEp qrt372ZGj/nV/PDjT4Hv69AqG0gdR0DHRX+/jR9vvrWuRGSNXan87kqk41pFzRCAAAQg0GoEBg0a ZN57771WazbthQAEIAABCEAAAhAoOYGeJW8fzYMABDoZAS0iOHbcuECJ3d0qTa3mtJP1sDW7Eyiw f/vNjBo1Ojgk3ay1fOCgvDW7Q6shAAEIQKADCJxxxhlBrQMGDOiA2qkSAhCAAAQgAAEIQKCzEsAC u7MeWfoFgZISCBSl434zv/46ps2FSEmb2qWaJUt4/Y0e/evvx6WbFNgIBCAAAQhAAAIQgAAEIAAB CEAAAhDoWAJYYHcsf2qHQJcjUJFi1FpdBwpTWV8Hlr5dDkPpOqyBBR0KHZ/f3YeU1zJ++PDhZuWV V66L4TzzzGPuueeeusooMvOdd95pjjrqqLYiH3vsMTPTTDO17XfWjc8//9wMHjzYrLjiiqXr4kor rWS+/PLLoF1bbbWVOfnkk2tq47nnnmsuu+yytrw33HCDWWKJJdr2O9PG0Ucfbe64446gSzPPPLN5 9NFHO1P36AsEIAABCEAAAhCAAAQg0EEEUGB3EHiqhUBXJdDtD9/KUpjKTQV2vuU5EzSeIBcv3Upu ff3aa6+Z999/vy5wUmCXSZ544omqPk0zzTRlal7hbRk7dqzp37+/Oeigg4yUnmVTYGuQ5Kmnnmrr 94QTTti2nXfjwQcfrDq20047bd4iWia9lNfhtdm3b9+WaTcNhQAEIAABCEAAAhCAAATKTQAFdrmP D62DQOcjEDXsxQK7pMc3epDK18SXX3657kYts8wydZdRZAHPPfdcW3FLLrmkqUdh2lZQSTc+/PBD s/HGG5v//ve/QQvV37KJBkmisvjii0d3M2//Zv3KP/LII23pJ5tsMjP77LO37Xemje+//75Nea1+ Lbvssp2pe/QFAhCAAAQgAAEIQAACEOhAAiiwOxA+VUMAAhCAQH4CL7zwQlWmU045xUw55ZRVYWk7 a621VlqSpsWPGjXKvPTSS231Lb/88m3bnXFDVrqh8lr9W3TRRUvXzfggyWKLLVZTG6Wsj8oqq6wS 3e1U24MGDarqTxkHJqoayA4EIAABCEAAAhCAAAQg0DIEUGC3zKGioRCAAAQgIN/pAwcObAMhi1a5 oOjevXXXJH7rrbfa+qONWq19qwop8c7zzz/f1rqyWiRHB0nky3m66aZra3OejVdffbUq+dJLL121 35l2dN7Kp3kondlVSthHfiEAAQhAAAIQgAAEIACB5hBAgd0cztQCAQhAAAIFEBgyZIj58ccf20pa brnlWlp5rY7ElZy1Wvu2QSn5xjPPPNPWwtVWW61tuywb8UGSFVZYoeamRS3rVUhnHpzo2bOnmXHG GWtmRUYIQAACEIAABCAAAQhAAAIuAiiwXWQIhwAEIACB0hGIK3sbZdEq38WyJv3ss89Mnz59Ar/F PXr0qJnHF198YYYOHWqmmmoqM+uss5qJJpqorayota8CsywwKSX+xx9/bMaMGWP69etnpphiirby at346aefzHvvvRdYG88yyyzOYsaNG2fUH7GZdNJJzWyzzWZkSZ1FPv30U/PVV1+1Jc1z/Irs8+jR o43ce8h9iyyso4rXjz76qGqQJE8b2zr2x0bUt7mCGuEu5csvvzQa2JlpppmCvmiB3FpE5/wnn3wS nPeyONd52rt371qKyp1nxIgRZtiwYcFg1Nxzz535fMpdERkgAAEIQAACEIAABCAAgZYk0LpzrlsS N42GAAQgAIF6CMR9Ey+xxBL1FNcu79NPP20222wzI2tSKfC0EJ0UatrX9sMPP9wujytACtczzzzT TD755KZv375B/nnnnddMPPHE5sgjjzS//PJLkPXZZ59tK0IWyS5F+ciRI80555xjpFxWmQsvvLCR n2H5/1bY/vvvb7777ru2spI2xo4da/785z+bBRZYIPiTEleL7x1yyCGB0lA81W+libJWvptvvtks tdRSplevXm1sFlpooaAtao/qj7qQiNYvpqozvrDfMccc09aWKIcwbxF9DsvSr9yXrLfeesEAgtqu /oTH5oknngiSxgdJarWa1uBC1F2KFOXTTz99UEc9/+lY/OMf/zAbbbRRUN4MM8wQcNVx00DGqquu apJYuurUObD33nsH5/gcc8xh5INdgyJyAXLUUUcZDWxITj311LZjdeihh1YVpwGN8JzS72233VYV L6ZhvM4t9UGW7uE5JYW5zj3NPtC5JB/1cZ/aVQWyAwEIQAACEIAABCAAAQh0KQJYYHepw01nIQAB CLQ2gbi1clEWrVI2b7/99ubee+91ApIycu211za77757oECUItolr7zySqBIVLlJIsX2448/bm69 9Vbz/vvvtyVxWfvef//9ZoMNNmhLF9+QZfNFF10UlHfTTTcZl2uOd99917z55ptt2WV1q7Rxpa3S yLJa8sEHH5h11lnHyDLZJeqn6tdf//79A4VomFZWznfeeWe42+43XNBx6qmnroorqs8qVFbjUrBf eumlVXWEOzq2UvzeeOON5vXXXw+Dg18pXGuRsF9h3npckYRlyNJ6u+22q1KMh3H61XGQIl5KaCmZ pXSeYIIJokmqtnW8xCVJVNYZZ5xhHnjgAfPggw+a++67r23xzfi5qPMn2l9Z5kdFluhhvBT5X3/9 tdl1112DsqPpwu1HHnkkGFyQElsDDAgEIAABCEAAAhCAAAQg0LUJYIHd4ON/9dVXB9PBNSU8/Hvt tdcaXGu24mUp99RTTyUmlhVi2F79Ri3xEjN0kkAfE01vjjK55557WqrXUiLdfffdLdVmGguBKAEp IUMrWYXLalPKsHpF1/0qq6zSTnn9pz/9yWy55ZZmxRVXrKriiiuuMH/729+qwqI7jz32WGBNGlde zznnnFWLAco/clxhLYvquEghHFcYymWHFM+bb755FQO551h99dWdltBRRbX47bjjju2U16p/r732 ClynSOEtxWtcea2+iMv8888fb67ZZ599qizVde9ME/VHvEMpss9yF7LVVlslKq/j7Zdy+JJLLgmb EfRPFsG1iAYxoiJr73pECmQp06NW3SpPx0L9k0V+VGStf/rpp0eDqrZldZ+kvNY5qHMjFA1m6DqI 1huf+RDva9yPe9QXuHiKhRTjoai+aJ0K1/Vz4oknhkn4hQAEIAABCEAAAhCAAAS6MAEU2A08+Jr6 fNBBBwXWdbKwC//efvvtBtaaXrSm7p5//vmBv8zoB2Q0pxbZCturX00l7syShYmU+FEmmrbfKqLj vOCCCwbWeK3SZtoJgTiBuEsBWZnWK+PHjw8sr6OKXSkCdQ+UP2hZSA8cODDwl7zMMsu0VSfL1Lfe eqttP9wYPny42WSTTcLd4HfnnXcOfEYPHjzYyF+xlPChsi7qD1qJ4xblSrvvvvtWlXf88ccH5T36 6KPmX//6V+Bb+8ILL6xKc/jhh1fthzsvvvhiuBn4og4Vi+uuu27gzkH9lVL7gAMOMLLO3mKLLap8 Vq+//vpGSm31RVzeeecdI//FUnhH5aqrrmrb1cCf3EWovKivbCmLFa6/H374oW0xzqL7LCvkqAW4 2iALX9331X65yIi2PzrwEHd50tapDBsh2zBpXOkbhmf51XkiXtG27bDDDsGx17G45ZZbzBtvvBFY SUcZSwGs4xUXDa6fd955VcHXXXddwELniM7TO+64o+14RRfeVKb4eRpVbie5SokOlssSWzMGJHIh o76pPl078Xri+0Em/oMABCAAAQhAAAIQgAAEuhwBXIg08JDrozn6sRlWpQ/mjhL5utx4443bpvIm WfupbdFp+voYnn322TuqyQ2vNyuTuDJikUUWaXjb6q1AVtdyixAqb+QzFYFAqxKIz17ReS3laB6R ZahcbIQiRZ4UpqFISS0L6ugii4qba665gusoutif/BBHFbVKd+CBB1bd9w8++GBz9tlntylnlWbl lVcOXDLErVTj91r5yJabhaioz3EFeffu3c1+++0XLKoYWtzKFcbJJ58cWOdG8ycpBE855RRz9NFH t7VR1rYSKUVDtw/al4W0wiaZZBLttokGOGXte8MNN7T1PckHs1yRRJ+JSRbJRfdZ1sPqXygaONDx lT/mUNQfWV1LiRreK8O4uIV8GJ7lVzOZolKrKxKVIUVvlJ2s3C+44IJ2/tI1wKBjJD/foWiw5Zpr rgl3g4GZ+HklJnKhEpVNN93UTDPNNMH5Gg3XearrIRQNAkX7GneV8u2337az4FcZTz75ZJUiXItP LrfccsE7SjhbKHr+hfXxCwEIQAACEIAABCAAAQh0PQJYYDfomOtDXR/0SdKRFtiyqIp+EMatqML2 RpUcmlrfmSUrE1m3haJp57VOKw/LaMav2hxVyNS6GFkz2kodEEgjELUeDtNGZ0Vk2ZayNxQpBOVG IRQpN3W9xJXXYbwWy9Pii6HELbB135QFcyiy5I4rr8M43Xvl9iEq8XutFORR1x1yWxJXXkfzR9um cFmQR0XK4aj/a8XJ0vrYY49tU15H08sHtRSNoWhhvrjyOoyTP/Bo+5Puj/EBiCSL5KL7fNhhh4VN DH4vv/zyKuV1NDLJLUx8kCGa3retcyv6rJXyP4mJr4wwTgPK0YESnTfyXe1a7FPW9FG3N/HB17/+ 9a9h0cGvBnTiyuswwUorrRS4qQn39SsFtZTNoegcjSrX4wMT8eOufHLD43r/iJ5jRbgICtvJLwQg AAEIQAACEIAABCDQugT+9yXfun0oZcvj07ejU92jitBmNz46zTdu7Re2RVN7o9Pa67FAC8ss828W Jmq/LBrlK9fnJ7ts/Yz7JUWBXbYjRHvyEEiy6s2TX2mjbkBk5RlVvGnROympfSJXPKFIMSjr01Cu v/76cDP4lQV0VGFeFWl34gq86L1W5UZ9Met+rfb5RG6Nogo/KfSjEldeq0yfj+Frr702cO0hVxvf f/99Ox/L0bK1HZ1d1K9fv3i0iStS4xbJRff5k08+CVyFhA3RgMKGG24Y7rb7nXfeeduFRY93u0hP QJx1VKHsyZYYFfdTrQGHqAI5KVO0PinS5T9e8sUXX1QNssh/ttzE+CRaltJFryHtxxXU8YGJ+HNo m222MVtvvbWyJkp0zY355psvMQ2B5SUwYMAAoz8EAhCAAAQgAAEIQAACRRLAhUiRNP8oS1Nxw+mv ClpzzTWDv9CqWQpi+fus1RqrniaHbVAZWgAsSeIfo51d6ZmFiThJOdRKfq/V5qgrGO1HF0nTPgKB ViEg6+Gon2pZS8ctSbP0RS4WQpGCNipyRxId0IrGhdtS5Eblm2++CRY7HDNmTOBCI4xLU5Yq3aST ThomD36jLp3UjtBPsCLl8iKuFK3K/MfO1FNP3ZZv6NChVUniisRzzz3XTDXVVFVpknZ69uwZtFU+ iqUA1fNLf+q7/F9rkUY996LW4lKMxiU6AKFZLPH+F91n+QePStqAgvoZFR2PCSaYIBqUeTt6ripT 3Co5a0HiHFX8r7322qkDCSp7lllmqapCA6+zzjqrkZ/rqMhqP97vaLy2o4Mi2o+/E0Tbp/j4wET8 mtLaIC5Rf6MDL/FBHlc+wiEAAQhAAAIQgAAEIACBzk2g+mutc/e1Kb2TlZN8nkZFFm7RD3vF6QMt bqUUzdOI7ayW1VHrJ7Uj/gEpf5ZqvywV9ZHsmsbs64OUHlKuSDkgS70JJ5zQlzxzXKhMkdXj3HPP XTX9PamQrEyS8qaF/fzzz+bjjz82+pUyp5aFMLW4mfoUKrKkgMhTTlQ5r4GUrMdKi61J4fHZZ58F yjn5QM+aN41LR8eLaWi9GP6626QF5n6PjeZzpyemUQTirpekyIsvbpinbinEtZBfVHzuOaLpotuh uwPdN6PW3H/5y1/azrNo+uh2/LkQ9av/0EMPRZMGivW8CwpG3X+osPiAVpb+yk+x/CfffvvtVf2r alzCTtwC+9dff60aHJBrirgU3ef4IsVRv9DxurWve21UojOnouFZtuNK21pdkcgdWVTk6zyLaLAh KuFgQfz5roUh00QDFVGJvxPEBybig/PR55AGnqIDNdFytR2foRavK56efQhAAAIQgAAEIAABCECg axDAhUjBx1nWTVErOVn7aVGiOeaYo6qmQYMGVe0n7ciCS1Z34V/0IzApvRaqCtNGFR2bbbZZEB4N U34tChWmj36ARpUcsryafvrpzZAhQwLFvNJrUSeVpT7Jcuuss84ysj5MEy2WKOW+Pm7Dj1hZKcrf rCwfzz//fCPFqU+iTGTlpantUizefPPNgYWbytXAgJQFqmettdYySazzMjnppJPaWMUXqIq297vv vjNnnnlmoNiXwkDTz+UWoE+fPkF75I9VFmZp8tRTTwW+bqWIF39ZvOlP5UjpqsUY49aUYZk6HuFx jSrIpKwLwy+88MIwedWvFuISGx1XKct1nDUQoH1tP/zww1XpW2FH50dUxE9hOtekVBttz91Ro0e3 +1P4r7+ODdIlKa/j5UbrYLt4AnGL1qi7jVpq0+BMESLfz5JwkCksM26FGoZHf6P3Jt1rdf8KRffc eiVansqKPkPkBiJtMEwW7vJrLQV2VDmfpV1xJWXUvYjyx+MVVnSfBw8erGIDkTI6zdI4er9Upril 8e8lZft/4MCBVQlrdUUStUZWgbJczyLxAZ/Q0j7KRMcgVGz7yoz6Utc51bdv37bkegZHz6v4e0Z8 kFiuQ3xudeLPNRTYbajZgAAEIAABCEAAAhCAQJcmgAV2gYdfismjjjqqqsRTTz012J9tttmqwt99 992q/aSd5557rmoRqPADNCmtwu6555629FIMS0aNGlW1iF8QGPkvXGRK084l8kEaVWZL+d6/f3+v peMRRxwRTCF3KUWl6NPU7RNOOCFSc/WmPtI1rViLhGkQIK7wD1NHmUjh8/XXX5tdd93VxC3twvRS 2mrqthRF4Ud3XiYqK8o2SfGiNLJQ3GWXXZyKHimAtLCn+vfoo48Gym3li4qstbfccktnf8K09957 r9HfzjvvbK688soq62iFh8c1TB/+huHxRerUtu233z4oM0wb/5VFoaxed999d6OF1kLFXTxdWfZD pXNoZT1+vLWmtv90jk84QW8z1eRTmikmn8wuSjeR6dWrV6DUDtuuPFJg//LLKPPDjz/bv5+sgnuM 6WYHFBTX3f6F5Yb1hHn5bQyB6MCaaqhHuaj88o8cFfnlnd3ONMgjUZdCmrEQlYUWWii6m7gdXQQy bpEcVaZKafh///d/iWX4AqPKRFnRRsvceOONfVmDe7bu21FRO9ZYY43AFZFm3+ieqj9x22GHHaru H+EzKMwfH4BIUkxG21dvn3VdRstLqi9sW/irQdao1HqORWfNqDw9M2qdZRQd5FBZGljMIlFXYJoB FN6vohbdaf7eVY84RhcmXXnllauqj7/LxAeWou1QxjQr+Oh1rhkEcUv+qsrZgQAEIAABCEAAAhCA AAS6DAEU2AUe6rPPPrtq8UMpF0MrvBlnnLGqprg1WlXkHztxv5I+/8WjrQVpNH049Vm+SdNEH4lh 2fq4jVra6cM1+vGqtFIuR63MVf5FF11k9t5773bWYbJw3W233dr53ZRyQh+6UibKUi2sU5ZcstCS ojrJZUW0j7KwlnI6avmociXRRShV9onWjcvll18exOVlEve9G1UKBQXa/+RLd6eddgp3235lLadj E1WkqG1KK4WwFKehaABkgw02MLK+jor6pI94Kd7jx0eWkVIk/e1vf2vLErWWawuMbUQVM1K8aWGz uIJJ54TOX01Fj7bpiiuuMBrwOP3002Ollmc3qlQOrfp79+5lpp1mKjPbzH3NpFZp3aN7D8u/pz3P uluFdPd2jde5Oc5aaY8bZ/9+G2d+/Oln89kXX5kRX39rxljLbCmElNeY3y26QwVRu4IIKIRAdGBN BcYVpHkrGTlyZFWWPfbYw6y66qpVYXl2vvzyy6rkmjnhkxdffLHq3hUfGIu6s9AMldNOO81XXGpc XJGo2Sku0cBg3L/4pZdeasQo6TyX66wnnniirTgt+te7d++2fW2ov1HRbJC4FNnn+EwXzV5Jk5tu uqkqSfhcrArMsBNnnfTMyFBMkCT6fNPzN82KXJnkJiT6zNGgQygavAyft/GBzDBN9FfP3Ggb4grq uMV03FVK3GVJmus0zQIKRQPoPmvtMB2/5SKgQRfdJ3TfQiAAAQhAAAIQgAAEIFAUgfZam6JK7mLl yNdx3Fotui9lbHTqb/yjLwlXVGmoBRd9H65xhXioDNEHhJR5UuLp4zcU+b1UuP70oR9+JMY/vMP0 mm4ua2a5yJCPSi1kJsvnqMQVoIqTkjO6aJTaIGWvFgKTVfN9990X+FmOlqUP5quvvjpadNt2lIms icMPa7lDkWJYSiQpXKNTmpU5up+XSVxZH7ING6U2xZXXxx9/fKAk0HHRlG2VET3+YhXlorKUJ9o/ KU/+85//BP3RR73OGSl4LrvssrDq4FfW0DqOoYiB9jfddNMwKDj24fHWb2iNKCWtLK+jx06KQfGS IlyDFxpgkGWizoFQzjjjDBO1Hg3Dy/Cr/nXv3s2Mt79SrE0y8UTmT3POZlZdfimzxJ/nN32sEnvi iSY0va3yWiIFtRTSY+xU+LY/uy/ltT7ClW4Sq/SZvs80ZrGF5zfLL7OYmXO2/2fvTMCkqs70//W+ rzRbA91NoGXTRIgmkEXhMc4o+EhQkjxkjPPIjBNcMkSJSyZ5ZuafmcngOErII4ZEB5OMyyRDXDKC kzgGjEYYo+KoLAIC3UA30E0v9Ebv//Oe4hSnLlXVVdW113v0crez/m511bnv/e73TZJsZcUNFyNI yId2mSJDAGKz7UoBn9HRvgHgdJ9hvkv8jeDf/u3f9NsoeLMGD4/sZN5iMceMSGj2netvf/vbHoec wp55YwSZAnkohf7DJzjeAsLbMOZtC9OI8zfHn4W4LSKiPFw0ff3rX/cqXuP8li1b3KIo9iFgO5Nd Jx6wOgVu5A/nmJ2uMfAg0V9C/zAOk/Cb6+0hqjnvb+1k7fzN8FfWeQ4uOkzCZwrfaSMlPGywE97q Mcn+HXJanJs89tr5IMN++Il89kNl7DtdpdgW1Xhryvl3hzIm4bfL/ju0f3NMHq7jnwDmB/H8gDv+ CbKHJEACJEACJEACJEAC3ghQwPZGJYRj3/nOdzxKwV0GbtbsZFsM4iats7PTPu2xjUCJtgXVSDdy zhtm502m03IXlsvekvNmFHkgNkC8hhWXEbph/Xz33Xd7VOEMGgUfnLbbEIjXEMi/9rWvuetBBTgO 62j7Jv+73/2uR93YcTLBMZSF+ApByVjYQUyE5Zb9irxTzEHZQJnY4i7K2RZmeDAA1yd2ghUfLKJt AQVi0ebNm+1sHjf+eADywx/+0OM8XJJcddVVHqIRgl7CChIW0yZB1PBmVW6L9hBjvCU8KLAtJ/E5 g2U4+Nlp2rRpF7iigXAebwkiMq5/f/+AZKqHRlOrJ8tnLr9U5syargSzTCUyu9zkDA4OaYHbiM4Q vNPUYNyL2kfCeQjhg0rohwsSCP4Qsz8xZ4bM/+QlMrlygn44hOMUsTWyiPzjDOxm3jAZTWO2WIp6 nJaizrrxfYa3SeBSCd9PTz/9tEcWuGmwk78HPHgw9bvf/c7O7n5bxxzEmxUm4eGc8/vVnDPre+65 R/cN4tFf//Vf64eN5hzWtpAIgdl++8POh237QRr2r732Wqy8JrwZYlxlmQz2dySOwTWS/R3stOI1 5cI5ZojPtgW183vctGnWTvdfI/3mmnLe1jZrnHfy8FbG1zGn+7GRRGd8f+NBi0n4jbTdfjiZOB9+ m3JYP//88+IMrGkHGkUe+3cGv+H4jTIJ34v2mxPwp+4vOa+R86GOv7I8RwIkQAIkQAIkQAIkQAIk kNwEKGCH4friBs0WM3DD6BR30cysWbM8WoOA6iu9++67HqdGupFzvp7tbMtpWe2rPueNN4Qi+Je2 xVjTMSNmm32nZdXq1avNKb2Gb2YIod4S6kKgRJMg2MDK207OMeAc3FkYa2I7L7YLCgrch5wPE3DC WZ8vJk62tgAAsdq+6b799tsFvnS9JVwTWxSxr/HWrVs9ArhB0Hdastl1Ol0dOK1R4d8XDE3yJhhB +LY/p3BV8txzz+mgmqacvYa/1Pvuu899yJ9A584UpQ0jRLvE637t2/qTytr60otnKt+zOdpSWknb qjcuK2nkQ8Laua2PnTunM1n/4Bza6lMCeanyn33ZpXNk7iWztKUmLCNNXVYRboaBgPMBna8HcME0 heCk9vcCHiA5/WKb+hDw8cYbbzS7eo03JuxUU1Nj7+qHWBDwnAkue2ApbSdYxeJ3w05OFx/+XIis W7dOW0mb8nhg5XwIZQuNznOmnFk7raNtK2CTB2tYNYOL88Gn87vLKZI6RVBTZ7jHbLswgBBrW4Gb NrEGP5sPjvn6PcC5kZLz4YT9mzFSWed5+zcD577//e87s7j38YaO/eAWJ/DAxX5Y4RzXl7/8ZeXr v9tdh9lAwF77LR4cxzhsv+94MGG/oeQMcBzoQ2LTpvPvfDTCv6mTaxIgARIgARIgARIgARIggeQg QAF7lNcRAoXTAheB+mCh7EzOm1h/r4U7rQFHupGzLeYgOts3rOiHU2AwvrntPsJftfMm/he/+MUF woopA4tEO9njO3z4sIeFIYL/2VZgdjmz7RTd4XrDTs6bWwjF8JftK9kMnXWjTCBMkM9m63TlAnco dvrWt75l716wjdexYR0H62qIJiZB+Mbr0/g8wV0CAiX6S7Y7BeRzPjxwivO2dbup94UXXvB47X/N mjUyUlAvW5gCP28Cnak/WmsIykY4hkX8pAnj5PK5l8iEseXKErtfC876YYvKBxtrk9es/fUTeezF COWoD65H0F71lEpZcPknpKSoMC54+BtPop5zPlgb6fswkHHiusKi2k5f/OIXBW9DmITrDTdHEBHt vznEN3C6ycDfhi2IQzCFNbQt/uI7Hw+T7LrQljeLcvjDtxME9vXr1+vPszkOq2yI4faDKJyzv1uw 73yg5RQxkcdOzt8HfDc4XVfgewrip7cAurYlNep1jhe/Nd5SOMeM+q+//nqPZlasWOFxffH3iwcR Tn4oFOpnDG/D2O5j8GAQb7nA6j7QxX7jAKK+ie2AfsH1FK6v87sXbaDP9oNL/O7CRZSdbr75ZrHf FoBlPD73eHgJARy/Hfi7QFlncj74sPuJvM43v5y/QyMxhfW4SRiz8y0Jc45rEiABEiABEiABEiAB EiCB1CPgcgKbeuMO24jhI9gWQiHi3nLLLV7rtwVeZLBfqXYWsK1+YZnnfI3Yzg9LZVsgcN5kIq/9 Gi+s/bxZVDut5CBOTJo0yW7KY9t582oH5YLwbSdY3Nk3p/Y5s20LPTgGIcC+4XWWdz44MPVgDb/e NhNvVtqBMIFIY7tysS2ZcQ6uVUyCW4+pU6eaXa9rf6/iowBENVi4oW5YfeLaYizwPQ5hAr7D0W9b VMf1RDk72eI9jnuzeHSK77BWdDK268S20yr+9OnTbtctzrxR2z83dAjKUyaNl08oq+t0xaNf7Rvx 2Ra50S+zbwRpfcx1Av968EQdJr/hjH2I2BCR8LkdU1Yq45SP7DMq0CNT+Am8+uqrHpV6eyDlkSHA HQiz+Dswf+N4mwJ/w/g7HTNmjA48aH+PoFr8nZuAsHYzubm58uCDDwpEUpPgmx+W0yiDNnz9fXl7 wITvAfi7h+9pk/CdB4tafA8h0KI38RhCpu2uCmWDFRLxhgd+d4wQ+7Of/UwH1l2+fLl+2wDfzTjm K5m/E3PeaeELgfThhx/WY8AYIaAihXPMqA8PGnBNzDWE6y5cXzwwwG8b+JkxIr9JI/3mmnze1vYb OTiP7+2rr77aW1afx/Cg9JVXXtHn8TAaDz1tt1EQ3J988kkddBTfQbi+uO52wm8n/LQ7rwVcfEAA ty218Ttm/5bZ9djb9u8fjjs/V04B254bIb/zwQiOmYTvVMRbMGmkB94mH9ckQAIkQAIkQAIkQAIk QAKpQYAC9iiuM27KnW4yYNkGy1ZvCaKknZwWzPY5W6D05b/Y5HfeRDrFEFi72cLJFVdcYYp6rJ31 INCjv2QLwLDoKikpcWeH1aKdYImIJZjkFNlt63BYZznHadftFNedAnaoTOw2na+JO1/1tvsTyDZ8 m0IYg3W2EdQCKWc/ODD57euNa+O00MZn1ylYGBHJ1BHI2nbTEkj+cOcxwjIsKadMmqDE6xlavIao k5aWrpbzYjXaNvmxDZ/WcCkCX7kQebBA+FahTWUY/q6VoIJ67TLYRkJecxz+s/cfPCyHjhz18O2u M/KfURPAQxvbqtTbGyahNoLvGFieLlmyxCN4nDdhGG3A/zzEP+cbLqZ9PPTDQ03UaRIEUqeLKdRh W3/bD+pMOazxJsa+ffs8LKohxhpB1s4L62+Iyt6EP/uBFsRZiLj+0vjx47VoivGYhDa9ua+AWyHU acctwPeX/b1kf2+a+swDXOd3U7jGjHYQ+Pjxxx/X19cWqu3fEuRDEGHEWDDXbSRfzSjjKznfFPKV z99x528JLNMRmPMb3/iGuxiEcqdYbk7CrQs+C76+n2GZjsCcYG1zMeWxxrwDD0cfeeQR92Hn59T5 ZkRtba07LzbsOYKvB+emAN7asvsSDjdBpm6uSYAESIAESIAESIAESIAEEp8AXYiM4hpChLCFFVQF oQJWat4Wp1sIp8hqugLLW7vekW7k7JtE1OEUa52W1d7EBJRzWks5/Vkij0kQ9mwB1ymK+/PvbeoY aW2CMiIfLOdsJnAdot1C+KjEKSKEysQWftCUXY/TxQlu0ENNEMxw8w9rwWDEa7S3YMECj2ZxbWxx 2pt7AnzGwpGcvrfDUWegdUBAdlla98v4ijEqsOJFlnitlGsI0ecEZ6yN4GyOZWVlqsCO2cr/a4+0 tZ+Rk02npe5Yoxw7flKaW9qlR/n3zVHns7OzdJdMeSNe42C6Esk/OnxM9uw/pFpzCds6M/8JGwHn 35m3z/NoGoO1MvzR33nnnT6rQZt4KwbWwv4+8/hOwgMoXwFOYfUKn8FOVz22ax67E/iswVIZwqqv 722Ix//wD/8gcE/i62EnRHCTIM6i3pHSl770Jdm2bZtHIES7DOoBk7Vr13q8KYM8cIdkJ3xvPvHE E17dUTmtxcM1ZtM+XL3g+jpFYZzHW1EQaCFy19XVmSJe87pPjrCxd+/eEXKMfNrbtcbnE79HtuW0 syZYaeOaIWCwL/HalMFvKLgg+Kdxh4OHILBah5sS+MB2ujlDMGI72XMLWJnjYaCd7PP+5hMo4wxO OZKbG7sdbpMACZBAMhLAfB5z1Na2M9J0ukXPU5tOt+r9LnV84JyRRSKPHWPEWFpa2+VUs2uMzWqM be0deux4u5KJBEiABEiABAwBWmAbEkGuEYjLtjgLsrjODqESlrBOQcRpVTXSjZwtVkLMcAZKdNZn i7B2v20hHJZWeIXeV3JaANo33AjsZYvNEH/MDbKv+rwdr6qqch92WocvXrzYfc7bhm0ZBiZOy7BA mThdudTU1Libg/9ZO4Xq1gB+UZ3jQZ/xUADCFjhAWMAr79h+6qmn5K677nI37Xyt2ykEeHsA4gxW B3/i9tjcJKIkAgAAQABJREFUlfvZsIN5+ckWkVNGTMbkvUgF65w1Y5pkKPFwUFteu6yp0bDJZ7ax n6lElj7l9qP+WIO6IWhVLlo6ZUCVg4/ffhWcEQJajhKtIW7n5+VKRXmZTFauSbIyM5RF9pC7TrR3 8PBR2b3/oH6YgnJ2exEZeApWCuELXCOZ8F0HC1e4+8CbMfj7wE0V3OpA5BxJDLT7hs8B3sy57bbb BGIm6sPfLf4O4b4BqUZ9jwQzJrwdgQUPBiHo4/sV/oHRP3w3oE1/CVbhoSSI1BAhYR0LMRMWsrCs xnedbYUOlysjjQfCKERT9B/fnWAODt7iRaCvox2zPV68hbJjxw7dLkRbuEKCqy3bV7fzoaddPpht iMeRSnDR8fzzz2tf1XgogQeRuPawqMfvvr/fbG99Apd/+Zd/8XZKz03suQV8Yufl5XnkHYkZ3F8F muDre6TPUKB1MR8JkAAJJCoB8z3Yq96e7ezsUQYVEKzbpavnrI69kqXeLMLctLSkSM1PS6WosEAb Wvgz6olHFpivwwVfZ2e3mou3yWk1zp7ePj33ylYGJgX5eToge3lZiY4xk5OTHY/DYJ9IgARIgASi TIACdojAEfjJThB8A7HAhXBqXp1GeQgSTr+QuMG2ky/BGXkgtGy3fF9C7HGKGbYIizL2q93YR+rs 7NSWga498foaujmHtfPG1fZ9CX/NdsKNKYIXjiY5LaFHEvVff/11d3MQKpwTu0CYoALblQvEHDs5 rZghBvhLuJmHKApfuXaCH147wdIO7lacDzZMHvt645jTv7VTnHe+9o0yTnc2cI0Av7eJkvAZH1aT X7jvuGhatZrIF0pfX7+HkIyx6HxK+xweHtICN9yC1B9vlIOHjkp3T48WstOUEA1LbuTV+ZUtdc/Z Xn2zcLq1TU6capYjR4/L9KlVMmniON0m9NT9Hx2RvQcOqzJwVULxOlE+O/76CZcisNT1Zq3rr5y3 c/hbx3e78/vdW95Aj+FBnPNhXKBlQ80HNxzhahcCKB7K+bI499bHcLWNumH5fs0113hrJqGO4e0k +w2lQDuP3xU8UJk4caKOq4EAoL4SHqzayVtQR/s8t0mABEiABEZHAOI1XODByOJQ3TFpPNms57Z2 rRC2sbSqNwcbGk8qA4sJMrlygha1MReN9+Qa47B0dnXJMdX/hsZTOmaN3e+zSsjGclpZZR9X56dU jpdpag6OOX8ijNEeC7dJgARIgATCS4ACdgg8IRBu2rTJoyT8XsMSbqSEV5VtVyKwonIKHLa1MXw9 +7tR/c53vuPRpDfhxRZzYQ0NYcWZ8Fq7nbxZ7drnne5G7FeLy8vL7awer2Z7nLB2ELzpmWeeEYwX loVwwWJbk9kW1eDs9JtqVaVfX4fLEZNCZeJ05eKsB1bSdrItEu3j2IYfX4wLCeVMEDNYUtrsYbUJ S1BfCZaLto91WL47hW7ntXF+vlC3k5/Ny1fbCCSGzz7GAWtwWFTGLKlJPqw3JqlJbfWUSm05jYcU RkhGv8w2Jss4d1ZN+P/vg/1ysvk0FG19LFsFSHPa9qrpsaSpSXI66lBW1/CVfaajU955f4+aTLfJ zOk1su/AEeVupEHXYdqJxKQafR+p3kDyxOw6sWESIIG4IYDAkLZVNQJOO38/0FkIKP/v//0/j37D pQwTCZAACZBA5Aj0KkMMuLM7XHdcCbi9+rvYX2u9/QNqLqreBlUT2WlTp+i4D/7yx8O5QeUS5GjD STl+4pQynurS8Wb89QtifX3DCcnITJeqyZXqbUhKF/548RwJkAAJJDsB/goEeYUhFn3zm9/0KPX3 f//3AYnXKOR0M2H7JjWV2n4jvYmPJh8C9cFXpZ1sS2gc71JPuG2Lb6e7CVPWabXrz+obZfA6tkmw 8LVvgiGQQ4g2bkTQT38iG9yo/Nmf/Zk7iBoE3hUrVpjq9QTOdm/itIR2Zzy34RyL01o7VCbOembO nOnR9OnTpz1Ed/vkj370I/cuXsM3vmrtYIvIgOBa/pLzdW+nqI6y9rWBf1lv7g+MmG7agoX71772 NbN7wRpWe3bQOfg7jaWADUvqnJwsuehjNTI06BJ5nUIyPnNYMjLSlQDdJW//31617nAFbVSCNhLE a3+fTVVcC8jw7Yp8dUcbBL75zp7tUyL3ecF8JJFZNxbCP2ZM/opGqm1/bfIcCZBA4hHA744tYCPm wt/93d95DATuYvBdb/+O4rs+kAf0HhVxhwRIgARIICACcIfXogwkYG3covxd441CzDkDSXB/16zK FhTkK0vs8YEUiUkePBhtbmmTo8dPSLty3denhGnM5QNJ4HG4vkHKS0uluKhQz+sDKcc8JEACJEAC yUfApeIk37giNiL4n7TdSkCovfvuuwNuzyl62mK1qcT2L+10fWHy4ObSm0WUU3h21u90N2Hqc7rU 8PeaOnxc21a+cNHhTAgmZRIEdAQh85Z6lYUBbo5tC+D77rvPwy8q3KxA9DVpJOtwp3sTpwuNQJk4 63GydTLy5WcWIjWCrJkEVzPG57XTahsTOl8JdSBwqJ2cDzgwkbVFcds3uV1u+vTpHoLED3/4Q+2O xs5jtmGJfuONN5pdvXa60PE4GeEdTOox5a1Qlv5lygfg4NCg29raCL46j8oH4bm7p1f+uGu3Fq9h uWHesDQ3ByMJwHY+XZ9yL6KMtLXbEZwbqfxocJj6EXAyUy1mbbbxOiXymD6Opi2WJQESSG4C1113 nccA8fAdPsjh5gsPT+FTHa6w7ADNeGDsKyipR2XcIQESIAESCJoA3vCDuxDEVEFcll7lOiPYOV1n V7cWh/uURXa8JcSOwRgPHKrXC0RsbV2u5q7BJIjYp5R1el+/7/ukYOpjXhIgARIggcQkQAE7iOsG 4fZb3/qWR4nvf//72iWEx0E/O3CLAdHbJKdIiuP2+d/85jdy5MgRk116lN/en/70pwJLa1v0NeWc lrW2GI48vgTSP/zhD+42YF3rSzhHpvfff9+dFxtOq28c++pXv4qVO0Gktm+KcQKuM+CP9D//8z/d +SDufuMb33DvY8N2qYJ9pyCNY3ayBVywDJWJXQ+sz5yuXOBv3HYjAuEdlsp22rZtmxYH7GP/+I// 6Obr9AV7zz33SEtLi51dBzn53ve+59WPeHV1tUde52cCDwi8JYiutkU18iBomv1ZwwT6xRdf1P6A 7c8RrmUoQTm99SPYY5juasFY9Q2vS8JqBfvoqxGSzT4+wwjEt+v9vdKh3kSA+Ouy9nD5CDT5R+qD yeeSzV3CNcrYbY5UR6jn0UZpcaEsuOwTMn/eJTL/k671ArX+tNovLy3RwSdNH0Nth+VIgASSnwB+ b5y/r3g4DKvs//qv/xL7ex40li5dKlu3bpWSkpLkh8MRkgAJkECUCGBuB0H2mHKlAfH6uFq3tXfo II2hdAEicY+6R+1RgR7jKXWr/jScPKXF+ePK33X7mQ49Lw+1j7BO749DkT7U8bAcCZAACZBA8AQo YAfB7NFHH5VDhw65S0Bs/fM//3P3fqAbtiUv6oMobacFCxbYuzJ16lS56qqr9AJXHfBbiQTx1H6t 98orr/Qohx2457ATREsEcRw/frzAmhypubnZY1ze3FLYddivFuO4NwEbryrbIjZukjEGiL7oP8YI 6+HtVgBKjAU30rAIs5Nt7Y3jTqtjOy8mhfCnbVKoTPCqm+225IorrjBVutd4GPHwww+79zFG+AL/ +te/LhCzYWUNDrb1OKyoly1b5i6DMcMvuUkQEGpqarRVP3yQrl69Wl9j52veJr9z7bzeTz75pEyb Nk0v9957r0d2BI+0A0/iuuKzhn7DnQjeFoAlvS2KY/8nP/mJRz3R3ElT1xfXprysWIrU65IQtJGM gIvrj8UcQ7DGpuYW7TMPvqxNPp0hyH/gG9tOo6nLrsffNsaCIHplJcXnliKPNSK1I080+uKvnzxH AiSQGATWr18vv/rVrzx+d5w9x+8SHppu3rxZEHiTiQRIgARIIDwEYFiBAIxHlEu6w/XHVaDw0zpw +Ghrh29piNjxkPrV26Cnz7kLqT/aKCdVMHQEZRxtQvB1iPVMJEACJEACqUuAPrADvPbw54zXbe30 0EMPhRQwA1ZQsKw26eDBg1r4NPsQOe1AfTjutF6Gb2O4rLCFVW+uNby5kDA+sU0gv3fffdc0rdfe BGk7g9PdiNOvt8n7yCOPSENDg4dIDUtv29rb5IVFLyzLndbSOG8LyXhoUFhYaIpdsIb/TlswDpVJ oG5LIMZDdLfdh/gSeGFd/d3vftejzxAef/aznwlcepiE/jtdheAcxGO0d8MNN5is8tFHH8kXvvAF 9z7EajzYsBmYhy6lynecncARrl2WLFniIVK/9NJLdjb39l/91V/pfjndnrgzRGEDvOAmpXLCePW3 l+GeyBoBF2sIurC+hiXKERVo0eW/+rzIHYVuhq0JMx5YmkO4N/tmDYtysx22RlkRCZBA0hLA9wV+ Q7BASDl69Ki2vG5vb9cxHPAbfNFFF7nfEkpaEBwYCZAACUSRAOZwff39OiZLgwpg2Hiy2W1wEY5u YD4I4ThWyRiPwD0IfFw3KH/ep1vbw9onuEgx7cRqnGyXBEiABEggtgRogR0g/x//+MceoiDcbMD9 RSgJFtB2amxstHe1mA3XE7Z1rMkAlxj//M//LBCRJ06c6A6UiPPOIIM4BmvvJ554wsPVBY4jQQRH glhrp5FcdBgBHGUgPMNC1FsqKyvT4i4CRdmW4nZeHP+P//gPefXVV72OF3ltn9Ww4PaX8DDATqEy MaKvqctbPTgHcfQXv/iFPP30014ZIw+ssBEk0RmAEeeQIDpDiL722mtdBxz/QrSHJfWvf/1rbcVu nz5xQkUft1JOTo789re/FZRxJtvy35zDZwAPMO68805z6II1LMTxecPfgB2s84KMUTgA22rYQSOI C0RqiDFYTMLEFgsCN+4/VKd8CZ49d97YapucF64jPSkOtX4zRl9rjMRmcOHIeIQESIAELiSA368a 9cYPfGAjpgZ+q/DmjT8XYhfWwiMk4EkAc04sTCRAAi53cwPKOrqzu0e7DPlg7wFpONEUdiFWz3/V m4axSGhbuzFRhiN1yuJ6z4eH5ITyVx1uQV2P0f3uZSxGyjZJgARIgARiTUC9ka9+dZjikgD8VUO8 hSiLJ/dTlXsHiJChWMDCTQlEUgiecH2Bm1YIzNFKsJqF72xYe505c0aL1bDyMlbg0eqH3U64meAa 1dfX62vW2tqqraoR6BG8A01w1/Hhhx9qy3UI2xCY/Vmc+6oXlnWwRkd/IDrDV/aECRP8Cp2dnZ3a hzeuEcojoBeuUUFBga9mAjqOrxgTWAbb8EWNVyZf2/GW5ObmBjyJR1kwLikukssvvViNK9dtlWw6 gvMQXzBpfn3nLuno7NKW2ua8rzXqhgiMdaSSrl9Vfl5ud7Vk2vbWLsYzrqJcPqX8XZt89hr+vRHR PTs722vfTV5vdXs71q+sg8aPq5Ar5n9SB9kBy5zsLG9ZeYwESIAESIAESCCBCPQqv8uBJri32Lv/ vNvEQMvFa755H58lE9T8JtoJ8+nGE81KvD4hLcp1SKRSQX6eTK2aJFWTJ0aqCZ/19ivLaLgM2XdA ucVUFtgRnErLpz95iYwp83yj1GfHzp3A/Bsu95hIgARIgAQSnwC/zeP4GkKUgmDtzXI22G7DjyVc lziDBgZbT6j5YaUdrrGE2gdnuXAzgdiHBwNYQk2wSPdlrR5MnbCsg1sS2zXJSOUhlMP/+Ug+0Eeq J1LnMQHFK5IFeblKBM9wC7ZGpMUa8nCGug4n1ES6Vz0AwjUx5/31y4jXWIc7ufrlqhU+vJVS7tGE aRtitTPhGBY99nNrMx6scQ43R1jsdlAPxh6J8Tj7yH0SIAESIAESIAESIAFPAm3KYOdI3XFB8EEE bUy2NKjmoAjMCEOKpuZWZTzSH1HxOtn4cTwkQAIkQALBE6CAHTwzliABEogBAei+EGxzcrK12xoI tlgg1CIZkRfuQ1rVzQKC2eSoh0CBJlhtz6qdKtOnVql2XJbYoxGAh4fPCc+qj++8t0cFsTnt9e0J M4a83By34G5E7mE1XhxHHtMXe52rzhWpBw+watc9Vvl0WbXuOQsrmPPlAuXAfCRAAiRAAiRAAiRA AsETGFbzx15lhXxM+YA+dbpFOru6VeyWweArivMSeMMRfrybT7dKl3KPEm53IXE+fHaPBEiABEgg RgQoYMcIPJslARIIjsDwsMvFR67y840AjrBmMWIuaoJYq/5VNthpbotknHcd99+WyQcxHC56hoZc NxtpaaGHCUC7ELELsnOUCH3e3YmzP/AbWFSQr92EFBUWCCxanOOChbU5Zq8/PnuGXDpnptsjIOrG eQjwL73ymg54afL7J8CzJEACJEACJEACJEACoRLo7e1T1tbtclL5f4YhBQIa6qlpqBXGWTnMMRFU HAYZTUq4blMuUc6qMTvntXHWbXaHBEiABEggiQhQwE6ii8mhkEAyE0hLc1lcQ7w2rkGM9TXGbcRb RHnHkh6geG2XRR0utx3GAvtCtx6BM3YJyaL6jb4oXd3rJB+nzE0BfMU7BWy0BxHajM9ea/chVofM OQjYZts6zU0SIAESIAESiCiBffv26d8sxNFgIoFUIABRFxbJzafbpLmlVbvVMG/yJcv4Md8809Gp hOs25S7EZVmO+SoTCZAACZAACUSTAAXsaNJmWyRAAqMgoGyrzwm5Rpw1a1SKc1hwI9GvXtd07UPI VQrxCAl5kUwd9v4IRX2eNn2D9Q22oWCjXte2ZzG7XbPtmcPVNxwbqW+u8ufzOevhPgmQAAmQAAlE isADDzygq37iiSci1QTrJYGYEzBzObira2vvkFNK1D3d0q7jr8S8c2HsAIw64JIO1tYYI3xdY57N lPwEuru75eTJk9Le3q7eeu0TxEoqLS2VcePGaVeOyU+AIyQBEohHAhSw4/GqsE8kQAJeCLisoiEE +0q4oYA/6GzlBgTbgYjXvuricRIgARIgARIgARIgARKwCWB+CRG3q6tHWSSf1r6gO9V2MiWMsb9/ QDqVf2tYXDecOKWF7GQaYzKM5dVXX5X9+/e7h4I3U2+66SYVLyjHfSyYDVjav/zyy9LY2Kiuv+/A o3l5eVJTUyOf+9zn3IY1wbTDvCRAAiQQKgEK2KGSYzkSIIGoEoAYDetiuAeB32hvCZYiuSrIY5Zy MzKkJt/Ij0n4iOlcHpfo7XK/MWIZK4NpB2uTsI3+YG3Oq86Y0x5rtOtyXTLkLmNnMC5TTD1mrfur MppWsY9zxoWIXQe3SYAESIAESIAESIAEQiNg5oi9KgYLrK4PHq5TAQzP6nlbaDXGZynMR/uUeI0A jccaTmq/3vHZU/bq0KFDHvc5EKDfeOMNWbRoUdBwTpw4IS+99JJf4dpU2tPTI3v37pUDBw7IFVdc IdOnTzenuCYBEiCBiBKggB1RvKycBEggXATgAxvi7Fn1uiZ8RRsRF2sk19olWOfmZktmRobHpM5f P4ZVHUb8RT2edfor6Tpnyto5zTGIyVhQJ9pxitjQtNPT05TwnqMsJrL1aWQzCUK8HbDS7hsszVHW JNSFsurew9XeOUHbnOeaBEiABEiABEiABEggeAIwQejo7JYj9cfluLJITtYEy/KDh+t1oEa6C4nf q3zkyBGvYvPhw4eDFrD/+Mc/yq5du4IeLO7Hfve732mXIjU1NUGXZwESIAESCJYABexgiTE/CZBA TAgYQbivTwU6VBbYcBWCZI6b9YDyfz2mvEzwehvEblgvG9HXV8fTzgm9sFzoVX7ehpXgjDRSObSJ oJIZ58RyO7/pT6+yGMeCc2jHVfP5nqB/iOK++8ODbtcn5izqKCrMl+opky4YJ84dqjuqIt136D5g 3yRsGutvc4xrEiABEiABEiABEiCB4AnA1/WJU8pdyIkmZXWdXO5CQANzSFiWH284ISebVJBG5f+Y 4nXwn5Nolnj77be9NgdRGZbRtbW1Xs87D3Z1dXkVr4uLi2XKlCna73VBQYG0trZKS0uL1NfXXyCc w+3ILbfcQt/YTrjcJwESCDsBCthhR8oKSYAEIkEALkQylNjb1tEhZ5XInJOdJYNqwm1EY9d6SBAV vaykWFkzZwlecTPn/fUJE/eszEw5ql6VxMQ9kIR6EdRkzszpMmXSBA8radSH8yYP/MhhW4vMam0n WFD3qlc1YdHjPD+kBPUJ48ZKTdVktyBt6sa6Qd1IHTnacM5y+7yAjfphnY02mUiABEiABEiABEiA BIInAMOGJuVK42TTaWlVgQx7enpdc7Xgq4rbEnjLr6XtjPZz3X5GzbGVUYWej8Ztj9kxfC4hJpuU n58vCLpoEsTtQAVs+NG2Ewxrrr/+eh2s0T5eY1lY79ixQ95//333aXxeXnvttaAtv90VcIMESIAE AiRAATtAUMxGAiQQWwLQYtPT0qWzq1tN0nqkpKjQPcE+L9S6RGJYRU8aP1bOnOn0kufCccC1B6Te XjVpP6uirQeSYOGcrVx+uNx+eIrH6A/OwzK7W/lH7O45q8V3045dPyZ96Sq/t4Aruo3sTD0GM0Z7 na2s0PNycyVbifnOmw3sYzH57Ta5TQIkQAIkQAIkQAIk4J0A5k8dnV1yUgUwPN3SJh0dXdKvLFuT KQ0ODepxQaBvVmNsV3NmzDuZ4p8AXH7Y8/4ZM2ZoQRnW10hnzpxRQUa7BJbTI6WmpiaPLPCfPW7c OI9jzp0FCxZoi+xjx465T9XV1bm3uUECJEACkSKQHqmKWS8JkAAJhJsAJmuwDGhpbVNuRAbPWzWf awhiLRa4EampmiTFRQVuy2V/fYF4beqG6DzSAoFcNSTjK8plTGmJbs8WilGX+l/3Fa+dwmJHuzLx 0glTzlXGJTp7bvt2ZQLZfHh4SPfds4xLUDd1e2mWh0iABEiABEiABEiABCwCiFkCC+TGk836Dbf6 Y406iGGyidcwrDipXKLgLb6jx08od3RnKF5bn4N439y/f79HFz/+8Y9LZWWlx7HXX3/dY9/XDt4S NQn3DdOmTTO7ftdXXXWVx3m8lcpEAiRAApEmQAE70oRZPwmQQNgIwIIZwRmPNZ7Uvvkw0cIC8RYJ a7OfqVyC1H6s2t22znMun/ugtYFyIyXTDnxww+q5evIkLUybdlEe22YfIjuswAcHEXRypNq9nzf1 +VqbNr2X5lESIAESIAESIAESIIGRCEDIgwuNBhWgEUEMjym3cngz74LgJSNVFKfnMY+EX+s25Qrl uJpHf3TkmBbqIdgzJQ6B5uZmHePH9BhvcGL51Kc+ZQ7ptW0d7XHCzw4+I729gb2JijZz1VugSDDS wX0XRWw/cHmKBEggLAToQiQsGFkJCZBANAhoDVgpwT09fXJK+aqeXDleW4xg4oRJlxGv0Re8Blmp 3IhMn1olHx48rHxmZ+t7EJMv2P6aclij7uoJlTKuoky/UmraxdoI4fBt3aPckeC1TEzqUE7ZUgfV rGnT1Gvqttcmj6v+oKpnZhIgARIgARIgARJIaQKY07n8QLdr8brpdNu5OVtyYMH8EAuClHd0dqsA 4Me0UA9jDKbEI/C///u/Hp2ePHmy3i8vL9eCMgLYI8GIBn6qL7nkEr3v659sdX9kyiDPc889J1/6 0pf026i+ypjjN998s9nkmgRIgASiQoACdlQwsxESIIFwEcAkHOLwIWU5UjlhrFu0tkVdtIV8mJrP rJ2qJ+116jVJBGo0+XDebI/UNzsvrFfGjx0jsy76mA4YCUnargd5dX5J1/4ET7e1q3Yz1DGI2yO1 dOF5Ux/WSPbatX3eAv3C0rE5cvvtt+tJdFlZmWBCjfWYMWP0GvtYSktLtcVGbHrIVkmABEiABEiA BFKVgJlLDam5FWKV1B1rUC41mtV88bw7hWRgg3FCoEfsGLgKqVOLGXsyjC8Vx9DY2Ogx7E9/+tPu fbj/2L17t3v/vffeG1HArqqqEtslCfxnb9q0SaZOnSqXXnqpVFRUuOvjBgmQAAnEmgAF7FhfAbZP AiQQFAEjFnd0dapXH5tkyqSJ4vTfhjxYMGnH+uOzZ2ix9HD9cR0wERbRJmEib+o0x8zanIOFNyxV 4ApkbMUY+cScGZKlAijiGMqafFibbQjdsHJRPVHVhSZeo10E1XnjzXfd9aJ+V33D0qVuSOyxmH7H co2gMW1tbboLJ06c8NkVcIOIbQRuI2wb0dvsewtu6bNSniABEiABEiABEiCBAAhgPnVU+biGsNul fEJjzphsyeXPu0m7DOnq6qF4neAXGOK0/TlFkMbCwkL3qOBGxBawMSdvaWnRc213JsfG5z73OTl0 6JCK53M+SCn+NnAMC+ICYb4OoXv27NkBBYZ0NMFdEiABEggbgfMqTtiqZEUkQAIkEFkCED8RqPGj I0eVoFymxOQsGVJisnElgtaRx+yrTZl7yUwpzM/TAWsQWd4EasQ5rQl76TLKY6IIgRwuSKqnTJYZ 0z+mtrO09TUswU0ywjXWKHdSuThpVcEmMzLOuzcxeQNdYwwIHNSirLi9JdcYzwvo3vJE+xgm0489 9piOTt7a2qonzmaNSTS2sbS3t7u3/fUxLy9PT7ydQre9X1xc7PMhhL+6eY4ESIAESIAESCC1CECo a2vvkMPKyKCjq1tbXWPulkwJc1e42juu/HnD53Vf/wDF6yS4wHAJYqeZM2fau/p+CGKzMSTByR07 dsiSJUs88tk7MIS5/vrr5fnnn/cQx00euCI5ffq0Xnbt2qUNZ/BWJcTs2tpak41rEiABEogKAQrY UcHMRkiABMJJADcamUoYRtT0/R/VycUzXRMoW0Q2NyMQebHdrybvF02vkXHK/Uf98UZpPNGkfAF2 uYVu5DMJr5TCYfaAsrguUKL3xHEVUjV5oipbriZ3rtcx08/Va8qYdsz6wEdHtMgNoTzUZMZj981Z l8njPB7LfYjYWIxfPm99wc0VJthOcdsWubHd09Mjx48f14u3enDMWIcYUdt2V2JbdONBBxMJkAAJ kAAJkEDqEcC8o1MJ1idOnZam0y3SqfxBD6pjyZQwJ8QYEYASxg+wusYbgUyJT6C7u1sFhj/jHgju DebNm+feNxuf+MQn5NVXXzW70tDQoO+D/N1LwE0I/Flv2bJFmpqa3GW9beAB0MmTJ/Xy2muvyYIF C2TWrFnesvIYCZAACYSdAAXssCNlhSRAApEmYCZh6ekZUne0UcpKSnRAR/P6G84bYdes0ScE6Sku KpDZF02TKuV6BC44WlSQxW4VbLFbCaXaJYiyni4uyJcM5be6vLRE5S9UInauivCdrcujbm/1ox0s cC2yb/9hfeNw3gL8vDgeDBszTn9lAsnjr3yszoGNcRMCn32+EgLLGFHb1xpCuLEO8VUPjkNUN20a sdvsG6G7qKjIXxU8RwIkQAIk4IfAjBkul11+svAUCUSdAIJqN55sllPNLdoiGfvJlDD/PHu2T44r 4bqpRb391tqu56zJZVeeTFcs+LE4gzfCWMPbPQC+g19//XV1T+N6cIHPxltvvSWXX36530YRzHHZ smXS0dEhb775pjYcsYM7eiuM+y6I2Pv27dNlveXhMRIgARIIJwEK2OGkybpIgASiRgATMrjwgEXN 3v0fKXEyTwnZxW4fbt5EZhyDSI0EYbq0uEgHZIQFDuqB1TVcVmcocVXNCnXwReRFGYjfKO+tXvQF ltnZ2Znasucj+L4+lxflmUInkJubK5WVlXrxVQv4Q8Q2Arcvq274AsRy9OhRX1Xp1y+NmO0Ut43o jfOjsaz32ThPkAAJkECCE7j//vsTfATsfjISaD7dpueH7Wc6RL9ll2SDhFu9FuWarallUFnpdurp bJINMeWHc+TIEQ8Gn/zkJz327Z2JEyfKsWPH3If27t07ooBtMsOQ46qrrtK7EKhR9vBhZZij3ors 6+sz2TzWsNr+9a9/rV2ReJzgDgmQAAmEmQAF7DADZXUkQALRIWCEZFjydqvgO2+9u1sunztHi9jw 9ack6AvEZvTMlINlAmwTsA/BOtNy9QFBFAk3BCYZa2rsmzrMGvmzsjKUO4wz8v6e/dpnNgROHEce psgSAGOIylj8pd7eXrfIbcRu5xpC+KlTp/Tir64SZfXvS+jGcVjGwH83EwmQAAmQAAmQQGwJwGVI Mqc+FasFVtdMyUmgrq7OI2A9Rvnb3/7W52DNfYzJAEtquP0YP368ORTQGv6xL7nkEr2gAObR8IN9 4MAB7eLPrgSB27FMmDDBPsxtEiABEggrAQrYYcXJykiABKJJwAjIEIu7lTuQt97dI5/8xCwpKy7R /qvRF5PHbJv+meNmkmfW5rxZm3xm3+Qzx7EP38pnOjrl/3Z/qAMCZasJHyx8kIcpfgjk5OQIrFKw +Eq4nvAxaKy4zdoI3WYfQSixOC1i7HrRntOK2yl6QwjHwxEmEiABEiABEiABEiABEnASePvtt52H tJHMBQf9HEAwxy9+8Yt+cox8CvPa+fPn62X37t3yhz/8waMQ2oAbEiYSIAESiBQBCtiRIst6SYAE okLACMlGxH7z7Q9k9oxpMmXSeO3WwwjOpjPYN8KyWZtzvtamDb3Gi5n4X9WDlKXE6hOnmmTvh4ek VUV6h5hN8doXyfg/jmsMURlLTU2Nzw73K2snI2YbcduszXGsGxtVwFC1+EpoDxHjjXsSp+Bt9nHT wEQCJEACJEACJEACJJA6BPDGKOK8jDbBzQfqsl3gPf/889oYA65CYExxyy23BNzMnDlztMX1Rx99 5C4D/9lMJEACJBBJAhSwI0mXdZMACUSFgBGYMfk6q15ve/eDD6W17YzMqK2RbCUoQ2w2i+mQLWSb Y97Wdj5smwT/24ODw3LgUJ3sP1SvX+2DeG3nN3m5Tj4CuNbjxo3Ti7/RebPmtgVubJvFXz1wR2LE bKcVt9kvLi52P5zxVxfPkQAJkAAJkAAJkAAJxD8BBGC07z8w/5w1a1ZAHX/vvffc+VDHzp075bOf /az7GOafMMhAgrj94YcfCoJABprgh9sWsE1dgZZnPhIgARIIlgAF7GCJMT8JkEBcEjAitvE9fbj+ mIo2f1pm1k6VcWPLJScrW/d7QE3QELDR5MdBs+1cm4HqAI9qBwJ5Rka69CtLhdPK3/W+/YeluaXt 3PEMnR11MJGAIQBRGUt1dbU5dMEali/erLfNMbM+fvy4jgp/QQXnDuCzb8Rsp0W3vQ+fhkwkQAIk EAkCsOjD7+DSpUsjUT3rJAESIIGUIrB//36P8U6bNk278PA46GMH80bbehu+q20BG8YRtugMtyDB CNgIjG4nzi9tGtwmARKIBAHexUaCKuskARKICQFbgNYuRc4FdywvLZGp1ZOVkFggJYWFkpmZoSwN hmRQCdmwSDACtbFwwBp1YUlXixHFO7u65UxnpxxrPCkNjU26LARt0y4GjW0mEgiGACb8gVhzd6rP nrHWhqhthG0cM9vNzc2CxV9ChHkjdGONgJP2PsTuQvV3wkQCJEACwRJ44YUXdBEK2MGSY34SIAES 8CSAuV1PT4/HwU996lMe+/52YCFtB3vs6+sTBIQ0RhWICYM3BU3C/LGhoUEqKyvNIb9rBHS0U35+ vr3LbRIgARIIOwEK2GFHygpJgARiScCIyVp8VhbTsJqGb+rmXe9LUVGhjK8ol6LCAikoyNPrvNwc 7cfa7RxEbUCDHhgYlJ6zvdKjXJJ0dHRJR2eXsrpul9MtrVqktq0MjOAdy3Gz7eQnAFEZy5QpU3wO Fq+AtrW1uQVtI3SbY0borq+vFyy+El5RNaK2N9clOIcFD3eYSIAESIAESIAESIAEwksALj/sBAOE 3Nxc+5Df7ZqaGmW0k6nuaQbc+f74xz+6BezPfe5zAgtvY8CDTFu2bJHLL79cLr30UncZ5wYMf158 8UXtA9s+9/GPf9ze5TYJkAAJhJ0ABeywI2WFJEACsSZgW0FjUgaRDRO4HmWRfeBwvWSq/VwVFC83 N1v7yDYW1jiOSRnE7CFlod2n/ML1qUkfyvUqqwUEbMzOVq5IVJ3IY4Rru71Yj53tpzYBfJZhUY3F X8Jrn7Y1t7HiNgI39hHw59SpU/6q0cEufQndOF5RURHUzZbfxniSBEiABEiABEiABFKEAKyh7TRz 5kx7N6BtWFvbfqoxz+tVxjkIDo45I1yG7Nu3z10X7m3efPNNgXU1XOCNHTtWqqqq9P3PsWPH9Nzw 5MmTHqI4CkNYD8b9iLtBbpAACZBAEAQoYAcBi1lJgAQSj4CxyEbPYY0N4RqTs96+fm1dPXxOsMZ5 OP/QltjqPMqlqfxYZ6h1npqYoZxZ9HmYajORQAISKCjAWwgFMnnyZJ+9x8McWG47xW1b5Mb2kSNH 9OKrItzU2D64vVl0l5SU6L81X3XwOAmQAAmQAAmQAAmkCoE9e/a4XRxizLjv8GcV7YvLggULPARs 5HvjjTdk0aJFusgVV1yh53onTpzwqAK+seE/G4stcHtkOreD+yu6jfJGhsdIgATCTYACdriJsj4S IIG4I4BJn0kQ5bCfnq4WUe4PlPWBOa30aS1iGyVbi9nnCppy2LXrM/VyTQLJRgA3JEZsRtAgX+ns 2bMeLkuM4G2vcWPktCSy60NbpaWl7vaMVbdZm37oNyDsgtwmARIgARIgARIggSQj8N5773mMCG/W hXL/Ab/UcD3S0dHhru/w4cNuARsHr7/+enn55ZcFx4NNMFK45ppr9Bt5wZZlfhIgARIIlgAF7GCJ MT8JkEBCE/A2+YNwDctqnINoPTzk2rYH6q2cfZ7bJJCqBHDzgoA//oL+4O+rvb39AmtuW+SGNffB gwf9YsSNmBGzbXEb2yYYJW7U+PfqFyNPkgAJkAAJkAAJxDEBW3BGN0OxvjbDu/jii2XHjh1mV7v/ gBuQ8ePHu49dffXV2hhh+/bteg3DHX8Jc7/a2lqBhTcTCZAACUSLAAXsaJFmOyRAAnFNwBa87O24 7jQ7RwIJQgB/U7CwxjJ16lSfve5TvubxuqpT2Lb3GxsbBX4YfSX4dHSK20b0xtqcswOx+qqLx0mA BEiABEiABEgg2gRuvfXWsDV5ySWXCJaREuZIN9xwg86GGCiYb8H4oLu7WxDcG2/BwS/29OnTtRu6 kerjeRIgARIINwEK2OEmyvpIgARIgARIgARCIoCbo4kTJ+rFVwWw5j5z5swFIrfTN/f+/ft9VaGP w1LbiNm2BbctchcWFvqtgydJgARIgARIgARIINkIjBs3TrAwkQAJkEA8EaCAHU9Xg30hARIgARIg ARLwSwDW3Aj6iKWmpsZnXgQgMpbbRtw2a3Mcfrnr6+t91gFB3Ra0nUI3zsGqHD68mUiABEiABEiA BEiABEiABEiABCJDgAJ2ZLiyVhJIWgJNTU3y1ltvCdY333xz0o6TAyMBEkhsAnjdNRALIviZNII2 1mbbiN1YIwilr2QEdWPNDVHbLPYx+ItkIgESIAESIAESIAESIAESIAESCJ4ABezgmbEECaQcASNa //73v5e6ujo9/vXr16ccBw6YBEgg+QjAlQiWqqoqn4MbHBx0++Y2ArdzDb/chw8f9lkHBGynNbdz n9bcPvHxBAmQAAmQAAmQAAmQAAmQQAoToICdwhefQycBfwS6uroEgrUtWpv8CPAxduxYs8s1CZAA CSQ1AQSGDMSaG9+btuW2LXKbbbgt8ZcgYnuz4IY1t3FhQmtufwR5jgRIgARIgARIgARIgARIINkI UMBOtivK8ZDAKAhAfHn77be1ixC4CbETAqfhVfmKigq59tpr7VPcJgESIAESUAQKCgr0MmXKFJ88 YM0NMdsI2k7BG8dhzX3o0CGfddCa2ycaniABEiABEiABEiABEiABEkhCAhSwk/CickgkEAwBX6I1 BGtvCX6vIdIwkQAJkAAJBE8A1tx4EIjFX8J3sxG5zdopdvuz5ja+uX1Zcxv3JXl5ef66wXMkQAIk QAIkQAIkQAIkQAIkEHMCFLBjfgnYARKIDQFYWGOBixA7GUtriB8mmWOzZs2Syy67zBzmmgRIgARI IEIEjDX35MmTfbYQDmvunJwc7ZrEKXTbASjpm9vnJeAJB4EZM2ZIenq64yh3SYAESIAESIAESIAE SGB0BChgj44fS5NAwhGAaL1x40bp7u52990I1DhgC9fYt8+tWrUKh5hIgARIgATigEA4rbn37Nnj c0TGmtsWtY1PbmPJjXV+fr7POngiNQjcf//9qTFQjpIESIAESIAESIAESCCqBChgRxU3GyOB2BOA BXV1dbXs3btXd8YWqL31zgjaDNzojQ6PkQAJkED8EwiXNffx48fl8OHDPgdMa26faHiCBEggCAIZ yoo/Py9XcnNzVKk0ZVwRRGGVFV7whoeHpOdsr/T0nJUhH27xgqv1wtx56g2W3LwcyczIDLqPqA1z 8L7+ftXHXr2+sIXRH8nKzJQ8xTEnJ/sCI5VAage6oaFBzbJbsWQiARIgARIggVgRoIAdK/JslwRi SODuu++Wb3/729Lc3BxQLxi4MSBMzEQCJEACCUuA1twJe+nYcRJIKgIZGelSqN7mKCstkYL8XDU2 CNjBKdgQhrF0qbcNT7e0S/dZJWIPDYWVE0ThspJiKSwsEIjEwfYRnUEfz/b2SvuZTrV0SP/AQFj7 iH4VFxVISVGR5CmhPS0tePc+6OOgErA7u7rP9bdPr8PaUVZGAiRAAiRAAgEQoIAdACRmIYFkIwBr vDVr1sj3vvc9ZfXR43V4mLAiYUIe1sCNrmpdbZ5rw7XDf0mABEiABOKdAK254/0KsX8kkNgEcpVV c3kZxOvQXRJh7oqlqLBQCdfDMnB6QAnFfWEDg7rHqD4Wqvl0phKJQ02oJy83FxK9Fthb2tpDrcpr uYKCPC2y56o2Qk3oIyzMiwuLZFixPNncIgNhFtpD7RvLkQAJkAAJpBaB0H9xU4sTR0sCSUcAbkQg TP/4xz/2OTZMWsMduHE4zWUVA4F8WNWvzDh8ts8T0SOgr4e6FK41r0n0yLMlEkg+ArTmTr5ryhGR QLQIQBCGqBuuVFSYL23tZ8IuYBfkFwi+68KRcnKytLV5uAXsnOxs5ToEblhGnzBlLykulObWNiVg j74+1kACJEACJEACwRKggB0sMeYngSQh0NHRIa+//roWLCFUI0G8xLZZ41i4AzemDbusYtKUf8M0 iNhohCn2BNR1x8cgPd11fdSHIPZ9Yg9IgASSmkA8WXOXlJSETYxK6os2wuCef/55PY9YunTpCDl5 mgS8E3DNRYJ3deG9NsxrlMiMSsOc3POlMNQL1x6huPcYqWnM6c0cf6S8I5131ZWhbMWZSIAESIAE SCA2BChgx4Y7WyWBmBJoaGiQtWvXah/YlZWVUl5eLrt373b3yUx2IxG4EeK4sa4ZHBzUbZr23B3g RtQJ4GFCug6alKeCHQ25rOOj3gs2SAIkQAKeBKJlzY1WIWKXlZXp30Szxu+j2cYaojuTbwIvvPCC PkkB2zcjniEBEiABEiABEiABEgieAAXs4JmxBAkkNIF33nlHNmzYoH1fz549WxDQEaLyP/zDP0h9 fb3b+jpSgRshjmZnZeiI6Gc6OmnxFiefJoQ2goBdkJ+nfRwqm5046Rm7QQIkQAIjEwiXNTce8B45 csRng9nqlXwjatvCNo7Zx8PlWsBnR3iCBEiABEiABEiABEiABFKIAAXsFLrYHGpqE4BI/dxzz8nm zZs1iCVLlsiKFSu0aIkDt912m0dQx7AGbjyHHn1AEPj8PBVUprRYWpQfPVhj4zhT7Aho/uoaZGRm yLiKchVtHnI2rglF7NhdFbZMAiQQbgLhtOY+ceKE3+7RmtsvHp4kARIgARIgARIgARIggaAIUMAO Chczk0BiEuju7tZW17t27ZKsrCzt13rBggUeg0FQR4jYDz/8cNgDN5qG4CoEYmmmEkorysvkWMMJ HXXdPm+2uY4WAZff8yElWo8pLZHCgny3FX60esB2SIAESCCeCNCaO56uBvtCAiRAAiRAAiRAAiRA AiIUsPkpIIEkJ9DU1KT9XTc2NgrcgqxZs0YgVntLl112mcDv9ZVXXunt9KiPuXxdD0t//6BUThir BeyGk03KpUgWrbBHTTf4CvAwwTxUgLH1tI9V6X2I2XAnwkQCJEACJOCdAK25vXPhURIgARIgARIg ARIgARKIBAEK2JGgyjpJIE4IIDDj+vXrpbOzU6ZPny733HOPFBUV+e3d8uXL/Z4fzUmXqxC4pXAF DJxWM0Va289IX1+/9oVtBNXRtMGygREwrJVRvOY/Y/pU7dYF4rURtV0PHAKrj7lIgARIgAQuJEBr 7guZ8AgJkAAJkAAJkAAJkAAJBEuAAnawxJifBBKEwNatW+Wpp57Sls0LFy6UlStXan/Tsey+EUSx HhgYlLHK3/Ils2rlvd37pX9gwO0P24irsexrcretHiCoawBP1/3q4UHVpIlS+7FqZYStXLxo39fK +zWUbSYSIAESIIGIE6A1d8QRswESIAESIAESIAESIIEEJ0ABO8EvILtPAk4CA0oIfvTRR2Xnzp3a qhnC9aJFi5zZYrZvrLAhkA4ODsrkyglaOH1/3wHp6u6RnOxs5b4CvrJNFxlM0JAIde18IJCWlq7c uAxosXpq1SSZddE05Rs9Q/kjd7kUCbUdliMBEiABEogcgWhZcyNWRllZmZSXl+vFbGNttnEOwjsT CZAACZAACZAACZAACUSDAAXsaFBmGyQQJQKtra2ybt06OXjwoBQWFmqXIbW1tVFqPbBmIFwbQRVr CO6TJo6TvLxcqTvWqP1i9ylxNVPdGCMvLYED4+ovl2EO3lgGhwZljBIiaqoqZfLE8ZqxEa9xHonc /RHlORIgARKITwLhtObet2+f30HCJRmEbFvUxoNp/H7U19frc5iLMJEACZAACZAACZAACZDAaAlQ wB4tQZYngTghcODAAS1et7W1SVVVlQ7WOHbs2DjpnWc3jKBqRNKBwSEpLyuW0pIi5c5ivDS3tOml u/us9Jw961mYe0ETgCSNBwIFBXlSXFgg48eOkfLSYsnPz9OuXCBaO69J0I2wAAmQAAmQQMIQCJc1 NwJE19XVeYwbvyn333+/PpZK1txvvfWWzJo1S/3WFnjw4A4JkAAJkAAJkAAJkMDoCVDAHj1D1kAC MSewbds22bRpk3bJMX/+fFm1apVkK1cc8ZxswVQZawlEbPhlrihXry2XlcjHqqfI0PCQDCu3Fkxh IKAYp6enSwYWJWZDYIAbEVwH+1qEoSVWQQIkQAIkkAQEQrHmfuihh5Q7qiFB7A28FdbS0qLXoVhz G8tus453a+7Nmzdry/MrrrhCbrzxRolXI4Ik+GhyCCRAAiRAAiRAAilIgAJ2Cl50Djl5COAm8fHH H5ft27drEfKmm26SxYsXJ8wAjXCKDkO8hqg6gNeP1X8ZGemSmUb/mmG9mIovHgfgFW+kNCVmK13b 7dJFH+Q/JEACJEACJBAEAduaGw9KsfzFX/yFRw343YGgbURtI2ybNY57s+a2K4l3a264TUH6/e9/ rxcK2fbV4zYJkAAJkAAJkAAJjI4ABezR8WNpEogZgY6ODlm/fr3s2bNH+Y/Ok7vvvlvmzJkTs/6E 2jBEbCTbjYWWWZXSimNMkSEA7OALwuYaRKYl1koCJEACJJDqBEKx5vYldsezNbeZt+B3lUJ2iJ/6 c/O/cM1NzDUJsTc+i2H+hLrD0U89H4vQlDecffQJgydIgARIgARIIAoEKGBHATKbIIFwE4C/Sbym 29zcLBMnTtT+risrK8PdTFTrMzcAZh3VxlO0sXPPDlJ09Bw2CZAACZBAvBGwrbl99S1a1txwXZKZ GditkvEDbuYwRjTFPoVsX1fS+3GwwxuGeOgRjjQwMBgRd3RD6q0CuGULR0IgbfN2XDjqM3WA47By x5cWpjca+8EyQkK76TPXJEACJEACJOCLQGCzMl+leZwESCDqBHbs2CEbN25U/ov7Ze7cuXLHHXeo YHz5Ue9HMA1mKncgTCRAAiRAAiRAAslNYMaMGdqFSCRHGW1rbuODG2uzXV5e7t4uKiqSrq4uPWRj 7UohO/RPQP/AgHSrAN6F1tzW8Ay0VvMAAfm7e3qUe7qBQIsGlA/1d3Z3S1FhoQ6SjULB9hFlTD/7 +vvkbG/4g5b39vWrevslL9c1Dx9NH9FXfM4HlSjORAIkQAIkQAKxIJCmfoz4HDUW5NkmCQRJAH+q Tz/9tGzZskWXXL58uSxbtiykCXOQTTM7CZAACZAACZAACSQlAbzN5stdiTne19fnd+wIMNnZ2enT pYS53bIFxMsuu0yuueYamT17tt+6w3USYmag6XD9cdm7/1Cg2cOeLy83VyaMq5Dc3GwVI0XF6wjy lTHwHhoaVOJ1r5w41STBjD3QwaBPE8ZWKBE7XzKzMnU/Ay1r8sFCuld9tlrbzkhre3vYrZvhpK+4 qFDGqADpOTlZymI8eKt2sBxUDwC6us9Kw8lTajt2AvanP3mJjCkrNfgCWuM6Zavrw0QCJEACJJD4 BChgJ/415AhSgEC3svLYsGGD7Nq1SxDEaPXq1TJv3rwUGDmHSAIkQAIkQAIkQAKxJQDLUyNmm7UJ QIk1AlD29vb6FLBN742QjX0jys6aNUtuvPHGiAvZwYi4sRawwSZLuW9JS0dY79ASTLSGlPuMgf4B He8jtFr8l8rMzHC5EVH9DaWfsCIbPuc+JFKWzQiqmqncsYyapRLbYR0fy0QBO5b02TYJkAAJxJ4A BezYXwP2gAT8EmhoaND+rnFzVFFRof1dV1dX+y3DkyRAAiRAAiRAAiRAAtEhsHnzZnn22WdHFLDR G28iNo5HWshOJAEbPJhIwEmAAraTCPdJgARIILUI8H2a1LreHG2CEXjnnXe05XWP8t+HV0xheQ1f i0wkQAIkQAIkQAIkQALxQWDv3r0+O2IEa2NxbdamAIwTIF5jnjd27FhzmGsSIAESIAESIAESIAGL AAVsCwY3SSCeCMCSBxY9SEuWLJEVK1ZEPDBSPI2ffSEBEiABEiABEiCBRCNgBGvTb3+CNUVrQ4lr EiABEiABEiABEvBPgAK2fz48SwJRJ4BAQRs3bpSdO3dKhvJZd/vtt8uCBQui3g82SAIkQAIkQAIk QALBEHj++ee1b+elS5cGUyzh8x45csQ9BgrWbhTcIAESIAESIAESIIGwEaCAHTaUrIgERk+gqalJ +7uur6+X0tJSueuuu6S2tnb0FbMGEiABEiABEiABEogwgRdeeEG3kGoCNly9IUG8tl2C0MJaY+E/ JEACJEACJEACJDBqAhSwR42QFZBAeAjs3r1b1q9fL52dnTJ9+nQtXpeVlYWnctZCAiRAAiRAAiRA AiQQEQKf//zntQ9rCtYRwctKSYAESIAESIAESEAoYPNDQAJxQGDbtm3y+OOP68j0CxculJUrV0pm Jv884+DSsAskQAIkQAIkQAIk4JfAbbfd5vc8T5IACZAACZAACZAACYyOABWy0fFjaRIYFYGBgQHZ tGmTbN++Xb92euutt8qiRYtGVScLkwAJkAAJkAAJkAAJkAAJkAAJkAAJkAAJkECyEKCAnSxXkuNI OAKtra2ybt06OXjwoBQWFsrq1atlzpw5CTcOdpgESIAESIAESIAESIAESIAESIAESIAESIAEIkWA AnakyLJeEvBD4MCBA1q8bmtrk6qqKlmzZo2MHTvWTwmeIgESIAESIAESIAESIAESIAESIAESIAES IIHUI0ABO/WuOUccYwI7duyQRx99VAYHB2X+/PmyatUqyc7OjnGvkqP5P/zhD7Jnzx73YGDR/pnP fMa9H8rGc889J83Nzboo/JLfcsstHtUcOnRIXnnlFY9jvnbS0tIkPT1dL+GRudwAAEAASURBVLjm U6dOlcsvv5z+zn0B43ESIAESIAESIAESIAESIAESIAESIIGUJ0ABO+U/AgQQLQJDQ0PyzDPPyJYt W3STy5cvlxtuuCFazadEO93d3ToQphks9kebzp49666zv7//gup6enrc5y846TgwPDws+Bwg9fX1 yfvvv6+XMWPGyNKlSylkO3hxlwRIgARIgARIgARIgARIgARIgARIgATSiYAESCDyBDo6OuT73/++ Fq/z8vLkW9/6FsXryGNPmBZOnz4tzz77bML0lx0lARIgARIgARIgARIgARIgARIgARIggWgRoAV2 tEiznZQlUFdXJw899JB2QzFx4kTt77qysjJleST7wOEipKSk5IJhwvoaC1zH9Pb2itOaG/7Qf/Ob 38if/umfXlCWB0iABEiABEiABEiABEiABEiABEiABEggVQlQwE7VK89xR4XAO++8I+vXr9di5dy5 c+WOO+6Q/Pz8qLTNRmJDoLi4WL70pS+N2Pibb74p7777rkc+POyAixGI4EwkQAIkQAIkQAIkQAIk QAIkQAIkQAIkQAIiFLD5KSCBCBCApS2C/23evFnXvmTJEvnqV78qCOLHRAIg8KlPfUqmTZsmv/rV rzyAfPTRR1JbW+txjDskQAIkQAIkQAIkQAIkQAIkQAIkQAIkkKoEKGCn6pXnuCNGAIEDN2zYILt2 7ZKsrCxZtWqVLFiwIGLtseLRE0BAxYaGBmltbZXq6mopLy8ffaUB1IDgjRUVFdq9jMl+5MgRCtgG BtckQAIkQAIkQAIkQAIkQAIkQAIkQAIpT4ACdsp/BAggnASamppk7dq10tjYqIXJNWvWaEE0nG2w rvAR2LNnj7z99tvS09PjrvSPf/yjduEBVyDXXXed+3ikNiBiNzc3u6tHQEcmEiABEiABEiABEiAB EiABEiABEiABEiABFwEK2PwkkECYCOzevVv7u+7s7JTp06fLPffcI0VFRWGqndWEm8DWrVvl2LFj XquFH2oEVXzmmWckMzOyX5O2eI7OZGdne+0TD5IACZAACZBAvBOYMWMG4zjE+0Vi/0iABEiABEiA BEggAQlEVplJQCDsMgmEQgBi6FNPPSXwfb1w4UJZuXJlxIXPUPrJMi4CvsRr+CjHNTRpcHBQsEQy 2dbXaAcW2UwkQAIkQAIkkIgE7r///kTsNvtMAiRAAiRAAiRAAiQQ5wQoYMf5BWL34psAfCdv3LhR du7cKRkZGVq4XrRoUXx3OsV7d+LEiQssr/Pz82Xx4sXa9zUE7A8++EBfU1vMjgQ2uCuBz3Q7VVZW 2rvcJgESIAESIAESIAESIAESIAESIAESIIGUJkABO6UvPwc/GgII+PfAAw9IfX29lJaWyl133cXg e6MBGqWyr776qkdLuHZf/vKX3cdghX3JJZfIpEmT5NlnnxW4Ewl3OnnypLz22mvS0tLiUTXch9TW 1noc4w4JkAAJkAAJkAAJkAAJkAAJkAAJkAAJpDIBCtipfPU59pAJHDhwQNatW6f9JFdVVcl9990n ZWVlIdfHgtEjcObMGY/G/uRP/sRj3+yUl5cLfHnu3bvXHApoDd/ZTzzxxAV5Yc0NMdyfIA73M0wk QAIkQAIkQAIkQAIkQALnCcDARAQLEwmQAAmQQKoSoICdqlee4w6ZwLZt22TTpk3aN/L8+fNl1apV DLwXMs3oFty/f7+Hj2tYX2PxlT772c/Kvn37PMr4ymsf7+/vt3cD2q6pqREsTCRAAiRAAiRAAiQQ SwIZ6emSqVzjDUQ4Dkgsx8i2E4tAdlampGsRO7H6zd6SAAmQAAmEjwAF7PCxZE1JTmBgYEAL19u3 bxdYAdx0003ab3KSDzuphnfq1CmP8YwUMDFd3cDBP3ZXV5dHuXDuwG3IpZdeqpdw1su6SIAESIAE SCDaBNauXSv47bz33nuj3TTbCyOBrKwsycvLkY5OzzgdYWyCVZFAUAQKCvJ0vKGgCjEzCZAACZBA UhGggJ1Ul5ODiRSBjo4OefDBB+XgwYNSWFgoq1evljlz5kSqOdYbIQJOIbq4uHjElvLy8oISsPFw A2W8JdzUZ2ZmCm4MKyoqZNq0acKgjd5I8RgJkAAJkEAiEvjwww8Tsdvss4NAvhKvi4sKKWA7uHA3 dgTGlJUKrLCZSIAESIAEUpcAfwVS99pz5AESqKurk4ceekiam5tl4sSJcv/998vYsWMDLM1s8USg t7fXozs5OTke+952YIEdTCopKfEIChlMWeYlARIgARIgARIggVgTyM/Pk4ryUmluaZPe3r5Yd4ft pzABGIbk5+XKuIpyycrOSmESHDoJkAAJkAAFbH4GSMAPgR07dsjGjRsFPo3nzp0rd9xxh3Yp4acI T8UxAbjrsFNf38g3ZXAdw0QCJEACJEACJEACqUIgS70tVlZaIlMqx0vd0QbpHxhMlaFznHFEQL/V mJsj06dOkQJlUALf7EwkQAIkQAKpS4ACdupee47cD4GhoSF55plnZMuWLTrX8uXLZdmyZdr3tZ9i PBXnBAoKCjx62NbW5rHvbae7m/4fvXHhMRIgARIgARIggeQlAKvXmimVKphjuuw/dFQwN2YigWgR gHhdWJAv02qmSOUEvvkaLe5shwRIgATimQAF7Hi+OuxbTAhAsHz44Ydlz5492pcxrK7nzZsXk76w 0fASgN9pO7W0tNi7XrcpYHvFwoMkQAIkQAIkQAJJTgAxO6ZMmiilyj3aiaZmOXOmU7q6e6S3rz/J R87hxYIAYsXk5mQra+s8KS8r0W5D8tSDFCYSIAESIAESAAEK2PwckIBFoKGhQfu7bmxs1EH24O+a QfYsQAm+OXPmTHn99ddleHhYjwQW2BCxy8vLvY7s8OHDEoibEa+FeZAESIAESIAESIAEEpgArGAR fLqkuFBylSsHuFUbHBySIT2Pcs2lEnh47HqcEUiTNIGInaGs/vHwBEEbsc9EAiRAAiRAAiBAAZuf AxI4R+Cdd96RDRs2SE9Pj8yePVtWr14tRUVF5JNEBHAjhiCLtuuQ//mf//EZdBFiNxMJkAAJkAAJ kAAJpCoBzJ0yMjJUIL2MVEXAcZMACZAACZAACcQBAT7SjIOLwC7ElgCscZ999ln513/9Vy1eL1my RP7mb/6G4nVsL0vEWl+4cKFH3RCz4e/ctrTu6uqSf//3f9efB4/M3CEBEiABEiABEiABEiABEiAB EiABEiABEogqAVpgRxU3G4s3AhAt169fL7t27dKvqq1atUoWLFgQb91kf8JIYNy4cTJ16lSBexCT Ojo65Kc//alkZ2frQ7aYbfJwTQIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkEH0CtMCOPnO2GCcEmpqa 5G//9m+1eF1aWirf+973KF7HybWJdDeuvvpqqaqquqAZCNdO8ZpuZC7AxAMkQAIkQAIkQAIkQAIk QAIkQAIkQAIkEDUCFLCjhpoNxROB3bt3y3e+8x2pr6+X6dOnyz/90z9JdXV1PHWRfQmBAHw02slf 4JdrrrlGPv3pT7utru1y2EZdixYtElhsmwQ/kM4UTJvOstwnARIgARIgARIgARIgARIgARIgARIg ARLwTyBN+f9lCGn/jHg2yQhs3bpVnnrqKcFHH/6QV65cqSOsJ9kwOZwgCBw/flyOHTsm7e3tUl5e LjNnzpTCwsIgamBWEiABEiABEiCBW265RUN44oknCCPOCPT29cdZj9gdEog8ARifZGfRa2rkSbMF EiABEog8AX6bR54xW4gTAgMDA/Loo4/Kzp07tXUthGtY2DKRwKRJkwQLEwmQAAmQAAmQAAmQAAmQ AAmQAAmQAAmQQHwRoIAdX9eDvYkQgdbWVlm3bp0cPHhQW9bec889UltbG6HWWC0JkAAJkAAJkAAJ kAAJkAAJkAAJkAAJkAAJkEA4CFDADgdF1hHXBA4cOKDF67a2Nh24b82aNTJ27Ni47jM7RwIkQAIk QAIkQAKJRmDp0qXiLV5Eoo2D/SUBEiABEiABEiABEogvAvSBHV/Xg70JM4Ft27bJpk2bZHBwUObP ny+rVq3yGbQvzE2zOhIgARIgARIgARIggRQkcOrUKXnjjTfki1/8YtyMnj6w4+ZSsCNRJEAf2FGE zaZIgARIIMIEaIEdYcCsPjYEhoaG5PHHH5ft27drS6CbbrpJFi9eHJvOsFUSIAESIAESIAESIIGU IIBYKz/+8Y+lt7dXv/k3b968lBg3B0kCJEACJEACJEACkSRAATuSdFl3TAh0dHTI+vXrZc+ePZKX lyd33323zJkzJyZ9YaMkQAIkQAIkQAIkQALJT+Ds2bPy2GOPyY4dO7TxxA033CCXXnpp8g+cIyQB EiABEiABEiCBKBCggB0FyGwiegTq6urkoYcekubmZpk4caLA33VlZWX0OsCWSIAESIAESIAESIAE UorAkSNH5Ac/+IHAdUhZWZmsXr1aLrroopRiwMGSAAmQAAmQAAmQQCQJ0Ad2JOmy7qgSgMXLxo0b pb+/X+bOnSt33HGH5OfnR7UPbIwESIAESIAESIAESCA1CMBl3ZYtW+SXv/yljrcCdyG33XabFBQU pAYAjpIESIAESIAESIAEokSAAnaUQLOZyBEYHh6Wp59+Wt9AoJXly5fLsmXL9OubkWuVNZMACZAA CZAACZAACdgE1q5dK+np6XLvvffah5Nyu6WlRbusO3DggOTk5Mgtt9wiV1xxRVKOlYMiARIgARIg ARIggVgToAuRWF8Btj8qAt3d3bJhwwbZtWuXZGVl6Vc2GSxnVEhZmARIgARIgARIgARCIvDhhx+G VC7RCr3zzjvy6KOPCuah1dXVctddd8m4ceMSbRjsLwmQAAmQAAmQAAkkDAEK2AlzqdhRJ4GGhgbt 77qxsVEqKiq0v2vcRDCRAAmQAAmQAAmQAAmQQLgJIFDjU089Ja+88oquevHixbJixQrJyMgId1Os jwRIgARIgARIgARIwCJAAduCwc3EIbB79255+OGHpaenR2bPnq0tr4uKihJnAOwpCZAACZAACZAA CZBAwhBwBmqEr+uLL744YfrPjpIACZAACZAACZBAIhOggJ3IVy9F+75161Zt/QLf1wsXLpS//Mu/ 1P4WUxQHh00CJEACJEACJEACJBAhAphvvvjiiwzUGCG+rJYESIAESIAESIAEAiFAATsQSswTFwT6 +vpk48aNsnPnTv2q5sqVK2XRokVx0Td2ggRIgARIgARIgARIILkItLe3yyOPPCJ48w+xVm6++Wa5 +uqrk2uQHA0JkAAJkAAJkAAJJAABCtgJcJHYRZGmpibt77q+vl5KS0t1sJza2lqiIQESIAESIAES IAESIIGwE0Cgxp/85Cdy5swZqays1HPPSZMmhb0dVkgCJEACJEACJEACJDAyAQrYIzNijhgTOHDg gDz44IPS2dkp06dP1zcQZWVlMe4VmycBEiABEiABEiABEkg2Av39/fLzn//cI1DjV77yFW2BnWxj 5XhIgARIgARIgARIIFEIUMBOlCuVov3ctm2bbNq0SQYHB2X+/Ply++23S2YmP7Yp+nHgsEmABEiA BEiABEggYgSOHz8u69atk4aGBikuLpY777yTgRojRpsVkwAJkAAJkAAJkEDgBKgEBs6KOaNIYGBg QAvX27dvl7S0NLnppptk8eLFUewBmyIBEiABEiABEiABEkgVAi+//LI8+eSTAgvsOXPmaPG6pKQk VYbPcZIACZAACZAACZBAXBOggB3Xlyc1O9fa2qqtXw4ePCiFhYWyevVqfSORmjQ4ahIgARIgARIg ARIggUgRQKDGxx57TODzOiMjQ1asWCHXXXedNqCIVJuslwRIgARIgARIgARIIDgCFLCD48XcESZQ V1cnDzzwgLS1tUlVVZWsWbNGxo4dG+FWWT0JkAAJkAAJkAAJkECqEfjggw/kkUcecQdqhMuQmpqa VMPA8ZIACZAACZAACZBA3BOggB33lyh1Orhjxw7ZuHGjfnVz7ty52vI6Ozs7dQBwpCRAAiRAAiRA AiRAAhEngNgqzzzzjGzdulW3ddVVV8nNN9/MQI0RJ88GSIAESIAESIAESCA0AhSwQ+PGUmEkMDQ0 pG8itmzZomtdvny5LFu2jK9uhpExqyIBEiABEiABEiABEhBBoEZYXeOtv/z8fB0gfN68eURDAiRA AiRAAiRAAiQQxwQoYMfxxUmFrnV0dMj69etlz549kpeXJ3fccYfwJiIVrjzHSAIkQAIkQAIkQALR JWAHaqytrdVv+5WXl0e3E2yNBEiABEiABEiABEggaAIUsINGxgLhItDQ0CBr166V5uZmmThxovZ3 XVlZGa7qWQ8JkAAJkAAJkAAJkEAUCSxdujQu36Dr6uqSH/3oRx6BGpcsWSLp6elRpMOmSIAESIAE SIAESIAEQiWQNqxSqIVZjgRCJYBI7xs2bJCenh6ZPXu23H333fo1zlDrYzkSIAESIAESIAESIAES cBLYv3+/ftuvtbVVxo0bJ9/85jcZqNEJifskQAIkQAIkQAIkEOcEaIEd5xco2bqH5yXPPfecbN68 WQ8N1i8rVqygBUyyXWiOhwRIgARIgARIgARiSACBGjHnxIL554IFC+TWW2+V3NzcGPaKTZMACZAA CZAACZAACYRCgAJ2KNRYJiQC3d3d2up6165dOsr7qlWr9M1ESJWxEAmQAAmQAAmQAAmQAAl4IXDq 1ClZt26dO1DjypUr5TOf+YyXnDxEAiRAAiRAAiRAAiSQCAQoYCfCVUqCPjY1NWl/142NjVJRUaH9 XVdXVyfByDgEEiABEiABEiABEiCBeCHwxhtvyGOPPSa9vb3CQI3xclXYD/hhr6ur064TSYMESIAE SIAESCB4AhSwg2fGEkES2L17t/Y92NnZKdOnT5d77rlHioqKgqyF2UmABEiABEiABEiABEjAOwEI hJs2bZIdO3boQJI33HCDYGGgRu+8eDS6BPbu3SsvvfQSBezoYmdrJEACJEACSUSAAnYSXcx4HMrW rVvlqaee0r4HFy5cKHiFMzOTH7t4vFbsEwmQAAmQAAmQAAmMhsDatWu1YHzvvfeOppqgy9qBGsvK ymT16tVy0UUXBV0PC5BApAgcOXJEIGLv2bOHInakILNeEiABEiCBpCZAJTGpL2/sBtfX1ycbN26U nTt3SkZGhhauFy1aFLsOsWUSIAESIAESIAESIIGIEvjwww8jWr+z8qGhIXn22Wc9AjXCWKKgoMCZ lfskEFMCEK+RcH/0wx/+MKZ9YeMkQAIkQAIkkIgEKGAn4lWL8z63trbKAw88IPX19VJaWip33XWX 9kEY591m90iABEiABEiABEiABBKEQEtLi3ZRd+DAAcnJyZFbb72VgRoT5NqlYjeNgN3c3Cyvvvqq XHnllamIgWMmARIgARIggZAJUMAOGR0LeiOAmwhEfW9ra5Oqqiq57777BK9yMpEACZAACZAACZAA CZBAOAggUCP8XXd3dwuCgsNYYty4ceGomnWQQNgJIHgj0vDwsPbP/qtf/YoCdtgps0ISIAESIIFk J0ABO9mvcBTHt23bNn0zMTg4KPPnz5dVq1ZJdnZ2FHvApkiABEiABEiABEiABJKVwNmzZ+Wxxx7T gRoxxsWLF8uKFSu0u7pkHTPHlfgE4PfaTrTCtmlwmwRIgARIgAQCI0ABOzBOzOWHwMDAgBaut2/f rq0KbrrpJn1D4acIT5EACZAACZAACZAACZBAwAQQBO8HP/iBnDp1Sr/dd9ttt8nFF18ccHlmJIFY EcBnFyktLc3DCvuyyy6jv3ZNhv+QAAmQAAmQwMgEKGCPzIg5/BDo6OiQBx98UA4ePCiFhYU66vuc OXP8lOApEiABEiABEiABEiABEgiMAAI1btmyRX75y18K3vKbN2+eQLxmoMbA+DFX7Ak4XYigR7DC fumll2T58uWx7yB7QAIkQAIkQAIJQIACdgJcpHjtIiZjDz30kJ6ATZw4Ue6//34ZO3ZsvHaX/SIB EiABEiABEiABEkggAnagxqysLLn55pvl6quvTqARsKupTqCrq0sHtgcHWGAjGV/Y//3f/y3XXnst H8ZoKvyHBEiABEiABPwToIDtnw/P+iCwY8cO2bhxo/T398vcuXPljjvukPz8fB+5eZgESIAESIAE SIAESIAEAifwzjvvyKOPPqoDNVZWVupAjZMmTQq8AuYkgTgg4M362rgSQRBSWmHHwUViF0iABEiA BBKCAAXshLhM8dNJWAw8/fTT+lVO9AqvvS1btsxtURA/PWVPSIAESIAESIAESIAEEo0AjCN+/vOf yyuvvKK7jkCNX/nKVwQW2EwkkGgETABHY33t7D+tsJ1EuE8CJEACJEAC3glQwPbOhUe9EICVwIYN G2TXrl36JmL16tXaD6GXrDxEAiRAAiRAAiRAAiRAAkERQLC7Rx55RBoaGqS4uFjuvPNOBmoMiiAz xxuBvXv36i4ZtyGmf7TCNiS4JgESIAESIIHACFDADoxTyufCjQT8XTc2NkpFRYWsWbNGqqurU54L AZAACZAACZAACZAACYyOAMS9F1980R2oEQHBIV6XlJSMrmKWJoEYE8BDGSRfFtg49+yzz8qVV17J WEKAwUQCJEACJEACPghQwPYBhofPE4APQlhe9/T0yOzZswWW10VFReczcIsESIAESIAESIAESIAE QiDQ3t6ura53796t3/BDoMYvfOELfgW/EJphERKIOoGmpiZ9/+S0vjYdMVbYWG/evFluu+02c4pr EiABEiABEiABBwEK2A4g3PUkAIsATKiQlixZIitWrJD09HTPTNwjARIgARIgARIgARIggSAJfPDB B1q8PnPmjDBQY5DwmD3uCRj/1yN1FAL3a6+9pmMLjR07dqTsPE8CJEACJEACKUmAAnZKXvaRB93X 1ycbN26UnTt3SkZGhtx+++2yYMGCkQsyBwmQAAmQAAmQAAmQAAn4IYBAjb/4xS9k69atOtdVV10l sLxmoEY/0Hgq4QjU1dW5+2yssLFGMtbXZhtrWmGDAhMJkAAJkAAJeCdAAds7l5Q+itfd4O+6vr5e SktL5a677pLa2tqUZsLBkwAJkAAJkAAJkAAJ+CewdOnSEV1/HD9+XNatW6cDNebn52sjiXnz5vmv mGdJIAEJGAts2/+1t23EF4LldUFBQQKOkl0mARIgARIggegQSFNPgV2PgaPTHluJcwLwP7h+/Xrp 7OyU6dOna/G6rKwsznvN7pEACZAACZAACZAACcQ7gZdfflmefPJJgQU2AjXC5295eXm8d5v9I4GQ CHz1q191l5s1a5bexlsG7733nnz+85+nyxA3HW6QAAmQAAmQwMgEaIE9MqOUybFt2zZ5/PHHBc80 Fi5cKCtXrpTMTH5EUuYDwIGSAAmQAAmQAAmQQAQIIFDjY489JggMDtd0iKly3XXXjWitHYGusEoS iAqBrq4u+e53vyvV1dUeltVvvfWWFrDRCfq7jsqlYCMkQAIkQAJJQoDqZJJcyNEMY2BgQDZt2iTb t2/XNxK33nqrLFq0aDRVsiwJkAAJkAAJkAAJkAAJiB2ocdy4cfLNb35TampqSIYEkpoA3IHMnj37 gjEa0bq5ufmCczxAAiRAAiRAAiTgmwAFbN9sUuJMa2ur9kN48OBBKSwslNWrV+tXOlNi8BwkCZAA CZAACZAACZBARAgMDg7KM8884w7UiGDgMJLIzc2NSHuslAQSgQAEbPjBRswhJhIgARL4/+ydB4BV xfn2X7YvK034K0UpIqggosQeRREwCgoRRYqIgiKCIBq/xJJoYjdqBCxYiKIGRBFBVLAisbFGDVaw IAoYqnS2N77zDM5xzuy5ZXfvvXvL8ybXe8qcOTO/uZfdfeY9z5AACZBA+AQoYIfPKulKrly5UonX O3bskLZt28o111zDR9mSbpTZIRIgARIgARIgARKILYHNmzer3zHXrFkjWKgRtnQnnnhibBvBu5FA HBLA96F58+aydetWqaqqkrS0tDhsJZtEAiRAAiRAAvFHgAJ2/I1JTFqUn58v06ZNE2THHH/88XL5 5ZdLVlZWTO7Nm5AACZAACZAACZAACSQfgVGjRqnfLeFzXVpaKp06dVJP93GhxuQba/ao9gSQhQ0L kY0bN0rr1q1rXxGvJAESIAESIIEUIkABO4UGG13FTD8e51y4cKHq+XnnnSeDBg1KMQrsLgmQAAmQ AAmQAAmQQCQJYNG68vJyJWAjQQK/X+LFDNNIUmZdyUCgRYsWqhvr16+ngJ0MA8o+kAAJkAAJxIQA BeyYYI6Pm+zevVumTp0qK1askNzcXLniiiukR48e8dE4toIESIAESIAESIAESCAhCXz33Xfqd0wk SsDf969//at07tw5IfvCRpNAtAnohRzpgx1t0qyfBEiABEggmQhQwE6m0QzSF3gQ/uMf/1CPq7Vq 1Ur5XfORtSDAeIoESIAESIAESIAESCAoAWRaz58/X7327Nmjsq0zMzMpXgelxpOpToACdqp/Ath/ EiABEiCB2hCggF0bagl2zbJly1RWDB7rPOqoo1TmNRYQYZAACZAACZAACZAACZBAbQiYCzVmZ2fL mDFjZPr06bWpiteQQEoR0ElEzMBOqWFnZ0mABEiABOpIgAJ2HQHG8+XIhEFWzNy5c1Uz+/fvL8OH D1ePdsZzu9k2EiABEiABEiABEiCB+CWwdOlSJVZjocZ27drJ1VdfLfvttx8F7PgdMrYsjghQwI6j wWBTSIAESIAEEoYABeyEGaqaNbSoqEgeeugh+fTTTwWPcl5++eVywgkn1KwSliYBEiABEiABEiAB EiCBXwiUlJQokTo/P18lRGCRxnPOOUfS09PJiARIIEwCeXl5aj0iZGDDN54LnYYJjsVIgARIgARS mgAF7CQcfqxoDb/rDRs2CFa5vuaaa1R2TBJ2lV0iARIgARIgARIgARKIAQEs1Dht2jSBdUizZs1k 0qRJ9LqOAXfeIjkJwAd77dq1snXrVtGe2MnZU/aKBEiABEiABCJDgAJ2ZDjGTS3Lly+X++67T4qL i6VLly7qj4tGjRrFTfvYEBIgARIgARIgARIggcQhgAzRefPmuQs19ujRQ8aNGyfIImWQAAnUjoAW sJGFTQG7dgx5FQmQAAmQQGoRoICdROO9aNEimTVrlsD7+tRTT5VLL72Uj6Ql0fiyKyRAAiRAAiRA AiQQSwLbtm1TC4GvXLlSWdKNGDFC+vbtG8sm8F4kkJQEtGjNhRyTcnjZKRIgARIggSgQoIAdBaix rrKsrEweeeQR+fDDD5UH4ejRo6VXr16xbgbvRwIkQAIkQAIkQAIkkCQEli1bpixDsK4KFmqcMGGC tGnTJkl6x26QQP0S4EKO9cufdycBEiABEkg8AhSwE2/MqrX4k08+UeJ106ZN1SrwnTp1qlaGB0iA BEiABEiABEiABEggFAEs1Ign+hYvXqyK9uvXT4YNG8aFGkOB43kSqAEBCtg1gMWiJEACJEACJOAQ oICdBB+DE088UbZs2SI9e/YUiNgMEiABEiABEiABEiABEqgpgdWrV8uUKVPUQo2NGzdWWdeHH354 TatheRIggRAEtIXI+vXrQ5TkaRIgARIgARIgARCggJ0kn4MBAwYkSU/YDRIgARIgARIgARIggVgS wPopr7zyisyZM0cqKyula9euSrxu0qRJLJvBe5FAyhBo3ry5NGjQQChgp8yQs6MkQAIkQAJ1JEAB u44AeTkJkAAJkAAJkAAJkAAJJCoBLNT48MMPy/Lly9VCjSNHjpQ+ffoocS1R+8R2k0C8E0hLSxOI 2HiKtrCwUPLy8uK9yWwfCZAACZAACdQrAQrY9YqfNycBEiABEiABEiABEiCB+iFgLtQIT96rr766 Tgs1XnvttRS+62coedcEJAAbEQjYeFHATsABZJNJgARIgARiSoACdkxx82YkQAIkQAIkQAIkQAIk UL8EysvL5emnn3YXauzdu7cg8zozM7NODTv00EPrdD0vJoFUIoBJo6+//lp+/vlnadeuXSp1nX0l ARIgARIggRoToIBdY2S8gARIgARIgARIgARIgAQSk8C6detk8uTJynsXCzVedtll0qNHj8TsDFtN AglMAAI2AgI2gwRIgARIgARIIDgBCtjB+fAsCZAACZAACZAACZAACSQ8ASzU+NZbb8nMmTMFGdhc qDHhh5QdSHACsBBBUMBO8IFk80mABEiABGJCgAJ2TDDzJiRAAiRAAiRAAiRAAiRQPwR27twpDz74 oFqoMT09XYYNGyZnnXUW/arrZzh4VxJQBLSAvX79ehIhARIgARIgARIIQYACdghAPE0CJEACJEAC JEACJEACiUrgq6++UuL1rl27ZL/99pOrrrpK2rdvn6jdYbtJIGkItGjRQvWFAnbSDCk7QgIkQAIk EEUCFLCjCJdVkwAJkAAJkAAJkAAJkEB9EIBNyHPPPSeLFi1St8dCjRdccIHk5ORErTmjRo1Sdc+Y MSNq92DFJJAsBPLy8iQ3N1e2bt0qVVVVkpaWlixdYz9IgARIgARIIOIEKGBHHCkrJAESIAESIAES IAESIIH6I2Au1NiwYUMZP348F2qsv+HgnUkgIAHYiKxdu1aJ2NpSJGBhniABEiABEiCBFCZAATuF B59dJwESIAESIAESIAESSC4Cb775prtQY6dOnWTSpEmy7777Jlcn2RsSSBICrVu3VgI2FnKkgJ0k g8pukAAJkAAJRIUABeyoYGWlJEACJEACJEACJEACJBA7AoWFhfLwww/LsmXL1OKMgwYNErxoSxC7 MeCdSKCmBCBgIyBgM0iABEiABEiABAIToIAdmA3PkAAJkAAJkAAJkAAJkEDcE8BCjRCvt2/frhZq hGVI586d477dbCAJpDoBnXXNhRxT/ZPA/pMACZAACYQiQAE7FCGeJwESIAESIAESIAESIIE4JFBZ WSmzZ892F2o84YQTZMyYMVFdqDEOMbBJJJCwBChgJ+zQseEkQAIkQAIxJkABO8bAeTsSIAESIAES IAESIAESqCuBzZs3y+TJk2XNmjWSnZ2thOsTTzyxrtXyehIggRgS0AI2LURiCJ23IgESIAESSEgC FLATctjYaBIgARIgARIgARIggVQlsHTpUpk+fbqUlpZKu3bt5Oqrr1bWIanKg/0mgUQl0Lx5c+VZ TwE7UUeQ7SYBEiABEogVAQrYsSLN+5AACZAACZAACZAACZBAHQhgocYnnnhC8vPz3YUazznnHElP T69DrbyUBEigvghgkdWWLVvKhg0bBN/vvLy8+moK70sCJEACJEACcU0gaQXsPXv2xDV4No4Eok2g QYMG0b4F6ycBEiABEiABEogRge+++06mTp2qFmps1qyZTJo0iQs1xog9b0MC0STQunVrJWBv2bKF AnY0QbNuEiABEiCBhCaQtAJ2RUWlVFHETugPJxtfNwLZWZl1q4BXkwAJkAAJkAAJ1DuBqqoqmTdv nsyfP1+QoNGjRw8ZN24cha56Hxk2gAQiQ0D7YK9bt05ZAkWmVtZCAiRAAiRAAslFIGkF7OQaJvaG BEiABEiABCJL4Pvvv5f+/fu7lQ4fPlz++te/uvvciDyBUaNGCbyLIxUYv/vuuy8i1VVUVEj37t0F 74jx48erDN+IVM5Kak0ACzU+9NBDsnLlSrVQIz5DPXv2rHV9vJAESCD+CGgBe/369fHXOLaIBEiA BEiABOKEAAXsOBkINoMESIAESIAEYkng448/FlgS6MjJydGbfI8CAWTRvvDCC7J79+6I1Q7v40jF ihUrBC8d9GHVJOrvHZMd8LsuKiqSDh06qKzrAw44oP4axDuTAAlEhYAWsLmQY1TwslISIAESIIEk IUABO0kGkt0gARIgARIggZoQgIBtxtFHH23ucjvCBFatWhVR8RrNi+SYLVu2zNPj3/zmN5597sSO QElJiUyfPl0t1Ii7ItN+6NChXKgxdkPAO5FATAloARse2AwSIAESIAESIAF/AhSw/bnwKAmQAAmQ AAkkNYH8/HxP/4466ijPPnciS6B58+by4IMPBqy0sLBQrr32Wvf8fvvtJzfddJO777dxyimn+B2u 1TF7QqNr1661qocX1Y3A6tWrZcqUKQLrkCZNmqis6yOOOKJulfJqEiCBuCYAARuLrzMDO66HiY0j ARIgARKoZwIUsOt5AHh7EiABEiABEog1gdLSUvnwww/d2x500EGy7777uvvciDwB8L3iiisCVvzR Rx95zp155plBy3sKR2DH/Dwcf/zxkpWVFYFaWUW4BGAxs3DhQpkzZ45UVlZKt27dlA85ROxECkzC QIhjkAAJhE+gYcOGgknOrVu3Cv4tSEtLC/9iliQBEiABEiCBFCFAATtFBprdJAESIAESIAFNYPny 5XpTvf/2t7/17HMn9gT++9//em56zDHHePajuQOPZdNC5IQTTojm7Vi3RWDbtm0ydepUtVBjZmam jBw5Uvr06ZOQQvChhx5q9Y67JEAC4RBAFjYsRDZu3CitW7cO5xKWIQESIAESIIGUIkABO6WGm50l ARIgARIgARFbLD3uuONCYsHig7A3KC4uFiwk17Jly1plieEPdNSDaN++vbRo0UJt1/d/kJW+du1a lQHXrl07adWqVUybZGdg18aDGmP07bffSqNGjaRjx46SkRHer3lffPGFp6/HHnusZ78uO/pzA76d OnVSthh1qU9fi3rXrFmjFjjE5wiWK4kYmDiYNm2a6ge+V1deeaX6fiViX9hmEiCB2hPQPwvXr19P Abv2GHklCZAACZBAEhPg80lJPLjsGgmQAAmQAAn4EbD9jgOJpRCr77nnHtl///2lcePGAi9eiN1t 2rRRC8r17NlT/v3vf/vdwnNsw4YNyssXdSDLDNnFeGEbx4YNG6ayTz0XGTsQ+eDJrF8ffPCBcbb6 5m233eaWDZZNXF5eLs8995xAsM3JyZHOnTsLyiP7De36/e9/rwTh6neI/JGlS5d6Kg3X9/jFF1+U Cy64QAnWaDO4IgsWmbzdu3eXJ598Uvbs2eOp296xJzQC+aG/9tprLlc9FrNmzbKrk+3bt8s//vEP OfDAA93PDdrVtGlTdWzixImyY8eOateZBzA2aL++j84Qh9XJeeedp+qFzQY+j/h8QrB/9dVXzSri ehv9e/zxx+Xee+9V4nXv3r3l9ttvp3gd16PGxpFA9Ajg5yGCPtjRY8yaSYAESIAEEptAA+ePmuB/ 1SRo/8rLK6QqObuWoCPCZseaQHZWZqxvyfuRAAkkCAGIgitWrHBbiwUE4cFpBrKRYS3yv//9zzzs uz106FCZOXOmErXtAhA94eccTtx///0CcdOOhx56SCZMmOAehgVKly5d3H17A4K0FukhBH/++ed2 ESWYn3HGGfLDDz9UO2cfCNQuu1xt9yH4mh7kgdps1l9QUCBXXXWVEkHN437b4P/Pf/4zYFbfxRdf LE899ZS6FNnbEJdtD1YI5eecc46n+uuvv14wWWCWhY/zWWed5Snnt4OM6dmzZ8tpp53md1qQFQ4B W8c333wjTzzxhNx99936kO87RGyMazwHnkDAgp7ItMzLy5OxY8fK0UcfHc9NZttIgASiTOCdd96R Rx99VP37BRshBgmQAAmQAAmQgJcAM7C9PLhHAiRAAiRAAklNYNeuXR7xGmKpLV7D7gFipS1en3rq qXL++eerTGUT0rPPPqsytc1j2F61apUqbx8fOHCg4GXbPsA+4f3337eLu2K0PoFM6UBRUlLiKe/n 741sZ2Sd2+I1soTRvx49eniqR7sgzEYrbIH9pJNOCnor2ISg/cjgNQPiM8bN7jNEXUwyYHEwv3jv vffcw1jA0RSkcQJCsy1eQ2i54447PGVhhWGL12gTROpzzz3Xk128efNmQdYxRFy/0BnX+tykSZM8 4jXqxeKjdowZM8Y+FDf7yBl5+eWX5cYbb1T9Rgb5XXfdRfE6bkaIDSGB+iOgfa+ZgV1/Y8A7kwAJ kAAJxDcBCtjxPT5sHQmQAAmQAAlElIAtltpiJ262ZMkSz6J+sDbAQnM4DssNZMM+//zznnYhG3fr 1q2eYxBY4VWsY8GCBQKBGdm8eP34449y00036dPq/YorrvDsY8cUWCGGBvN2theohChtBsQBZOia 7Ro8eLDyU4YPNfoHS4233nrLI7BffvnlyurBrCtS25988omnKrvN5kmI0Jdccol899137mFMQnz2 2Wcqc3revHlqEgBjhOM6wPDpp5/Wu+47xtUU8m3LFYzh8OHD3fLYWLRokVx22WWeY7CSsccOQi3s YxYvXixz585VjB944AHPdX/84x89+3rH9gR//fXX1SlMfKBvO3fuVBMkyGY2JzQw6RKPAhDaC8Ef kwEIML3uuuukefPmaj9Z/jNq1CjBi0ECJFAzAlrADjSpV7PaWJoESIAESIAEko8ABezkG9M69wgZ QvgDubISr0qpqKiU8ooKgS2LfpWVlYv7cnwc9XGUQ/kK5zpcj3pg5ZKkTjV1Zs0KSIAESCDWBGy/ Yz+xFEK1DmS53nDDDdKsWTN9SBo0aKB8iGGDYIZdtxYdUQYC8IABAyQ7O9u9BJnfN998s0BA1gHr CFNctgVWZAgHC7sNtr83bDfM+q+++mqZM2eOtG3b1lMtsoPhH60DwugLL7ygdyP6bou1dga4ebNn nnlGTA9w8IB4DLsNM3P6kEMOEdi3mHHttdeau2r7008/9RwzeUFsvvTSS93zyJgHX9sSpqioSInq bkFnY/78+XLLLbcoiwx9HO2DFQyEWx3ojymg6+NmH/WxGTNmqIkP9A2fQQQW3Bw/frwuot7jTQBC NjnYY3IFDMEFmeq6D57Gc4cESCAlCcBOKDc3VzZu3BjwaZmUBMNOkwAJkAAJkMAvBChgp/hHAcKy flVV7RWuIUKXlJZJobN4166CItm5a7ds275TtmzbIT9v3S6bf94mmzZvlY2/vDb/7Bzbsl22OmVQ bsfOXY44UCgFRcVSXFKqhG6I2BCz9b0oaKf4B4/dJwESqDcC//nPfzz3NgVLfQKLN+qAuAhR2S9g C2GGnd0Nn2YdyAw269XH8T5kyBBzVwl9+gAyi80I5RVsi8GHHXaYeznsSSCY6ujbt6/HlkIf1+8Q ak0x2fQN12Ui8Q7vUzPMNpvHkcV7zTXXuIcOOOAAefPNNz2TC+5JZ6NVq1ZqgkAfg23Hli1b9K56 t7O/dX/vvPNOgXWKDmQ547Ojz+vjeJ8yZYpHhIZAiwUwA4UtpMMSxQwI4vZnbty4cQKvbr+wLXCa NGniVyzmx8yFGmHdA2sYWIZ06NAh5m3hDUmABOKfABZyxN9I9tNM8d9ytpAESIAESIAEok+AAnb0 Gcf1HfBLEgTrwuIS2e4Iz5sccRoC9dZtO53Hc3crIbqwqERKS/dmWSO7uhJCtNGrvdnalUqoRrmi 4lLZ7Qjfu5TwvUt+dsTtTZu2KnF7d2GRlDrZ27iGQQIkQAIkEHsCtse0n1h68sknexrWv39/lflq /9vdsmVL+frrr2XdunUCsdq2g+jTp49bD8TTfv36iZ3xiwI4DlsIZJ5B5DazrAMJrG7F1oZpNwJ7 lMzMXxe0NTOqcRmE1mB2JChz1FFH4U0F+hrpQLYw2Oiw26yP4x0LGJplkcm8zz77mEWqbZsscdK0 HsG+OaGB7OA2bdooj2Zk3euA9/mHH34o7du314fcd3wmHn74YXcf3tSmyO6eMDaaNm3q8cO222SL 13gK4J577jFq8G5++eWXngPoQ30HvhOw1YF9CjIrkSWOV05OTn03jfcnARKIUwIQsBHxaIMUp8jY LBIgARIggRQikJFCfWVXDQIQokudLOtiZ6EuWIFAyEYGdiQzo50qndgrdStLkZIqJ7O73HnEuYEj GKQ7f8RlS47zKHlWJj+GxtBwkwRIgASiRgACsbkwYyCx9JRTTvG0AddgET9k4f75z39WGdPaCuTQ Qw/1lDV3zj77bMHCfjpgdYEM3t/97ndK7IafNWwU8Ng0bCH8wsyohjgKy4hAgQxlUww98cQT3aLI 6rUXPcRJCLPhxsqVK8MtGnY5W9A322xXgmxrHWBx0UUX6d2A79pXVRdYs2aNmPcwrTrgfw3xefLk ybq4eocdCERnvwA/8zPVtWvXatnTftftu+++7nVokxm2DQyyryECBwpzDPH5MictAl0TzeMYp5kz Zzr2auXqcw3blGTzuo4mP9ZNAqlKgAJ2qo48+00CJEACJBAOASqH4VBKgjIQpvFC9rP2rt6bTV2p hOtYdFG3AcnX8MfG/YudbG0I2FnZWZKTlan8O+kJGYvR4D1IgARSkUC4YikycfPz8+X000/3+EVD HIZoikzrv/zlLzJmzJigGaVYLBHZuRAgzYA3Nl5YZPC2224TCN2BwsyohuAdLOz+mf7eS5curXap vWBhtQLWAdMH3DpV611brDXbbFaKTOePP/7YPQRP8VDZ1yi8adMm9xpsmNdAeDYzurHIpl/AS3vo 0KF+p9Q4micgJteUK8R4M8yscBwP9vnAoqAml2OPPdasKqbbmECZPn26WgAVv8sMGjRIvUxv8pg2 iDcjARJIKAJ6wpEZ2Ak1bGwsCZAACZBAjAjQQiRGoOvrNhCNYfkBT+tdji+18qZ2bDzgTQ3rEGRd 10egXToLvNDxyka70D7Yj+A4zjNIgARIgAQiS8AWS/38r/UdYT0B0ddPNIboCX/kTp06qTL6Gr93 CK0vvviiwAbCDlhFYGFHLJhoZvHqcrBhMAXWUOKkLVKb9h8//fSTrrbW7xD2Ix1m9jDqNtts3svm 061bN/N0wG1Ys5gB2xcdWFwwnLAX6zSv+fHHH83dWm3bXM2scGT9B8rOx82wMKIZgSYAzDLR2P7q q6/UQo1giuzym266SS10SvE6GrRZJwkkJwEtYMfbQrTJSZu9IgESIAESSDQCzMBOtBGrQXuRrVVe 7izIWFamPKyReW37l9aguqgVhYiOtqGtWXh3srGznWzsrKwsSU/nHEvUwLNiEiCBlCNgi6V+C/KZ UA4//HDl4YuM2Pvvv9+zACLKQVSFDQkysyFmB4qBAwcKfLRfeuklue+++8QUKHHN22+/rWxF4HcN OxEdtsAaagFH22KjY8eOuipZu3atu42NP/3pT+qpH8/BEDvBBP8Ql/qexmSt6UmOTGSzzeZFpjUK jgcqZ16DbQirZmBhRx22v7g+jkxsZF1rb2uMFyYbkDFvBxb51AEhevTo0Xo37HczYxuLl5l12guF 2pXWZFLGvjYS+5WVlTJ79mxZtGiRqg4LNeIphWCWJ5G4L+sgARJIPgLaQoQCdvKNLXtEAiRAAiRQ dwIUsOvOMO5qcLObHTG4xMm0LnF8rusr07omcNBuZXHiCNmlWRnSMLdKCdmZv3hk01qkJjRZlgRI gAS8BPBv7LvvvuseDCaWuoV+2TjuuONk1qxZcvPNN6vF9B577DFPkcsuu0yWLFniOWbvYLFEbamA dqAuCNc6VqxYIffee69aQFAf++yzz/Smeg+UnYyTyLCGx7YOCInmzw0Io2bceuutaqLUPBbr7VWr VnksWuw2m+3ZsGGDuSvh2JlgQUyMmw5kwZsLHNoTGhCgFy5cKJgoQKa2FrBxPawxHnjgAV2V+24+ 6o5M6TvvvNM9V5sN2wYGn71gYXqko1yXLl2CFY/oOTwhgOx0eHjDE/6SSy4RjCGDBEiABGpDAF75 +Lll/rtam3p4DQmQAAmQAAkkIwGmtybZqEKohjVIgbNY1c5dBY4lR0lCiNfmMCgh21nsceeu3bKr oFDKnEWQcAwvBgmQAAmQQO0IwOph9+7d7sVYyM+0N0DGFzyvkWWM7N7nn3/eLas3Dj74YHn00Uc9 QjHOQTjGIomIN954Q3r16iXdu3eXAw88UIl76oTxn549e8pbb72lxHDjsJgZ1DhuipkQV3V2mnmN 3sbikmbAAsUM+1rbksMsi+0K52fpddddJ3/4wx+UsI72RjrM/qHuYGIt2mPG9u3bzV3f7RdeeMEz 5hdccIEr6iNz2OQNqw6IwTrLHXYtphgMoXbXrl3V7qMfeceJb7/9ttp5+wC4X3HFFYotBHFMXJhh Z1QHm7TAdaZHeqBFSc36I7UNdjfccIP6fHfo0EHuuusuiteRgst6SCBFCeBnMkRsTD4WFhamKAV2 mwRIgARIgAT8CVDA9ueSsEfhdb11207nD9YiZ6HEyoTtBxoOMb6oqEQ2/7xdCgqL49L+JKEBs/Ek QAIpRcAWS03bBoDAH84Q5WDbAQuHQPYSKHvKKaeobFNs69C2DxDJIWjDcgJipW1hocsjywzi8AEH HKAPiZ1xbfobQxAPFMgk/te//uU5bdt9mPdBQftenoudnSeeeEL+/ve/y+TJk9WilcF42NeGu2+L tVo89rvezJzGeVv4ta9Bxvn111/vOXzeeee5+99//727jQ14mrdr185zbPz48Z59WGXYgUkKHfAr 37hxo971fccCoNOmTVNscc8dO3Z4ypkLOOIpgbZt23rOmztYNNG0VsGkTLQDohKeFJgxY4ZjfVau rHFuueUW2X///aN9a9ZPAiSQAgT0ZOuWLVtSoLfsIgmQAAmQAAmET4ACdvis4rYkMpORdb11+07Z vmOn8pKO28bWomHo3y4nm3z7zl177VCYiV0LiryEBEgg1Ql8/PHHHgS2wAvLCAiGOl555ZWgGWCm lzKuadGihbrU9sKeP3++rrLaO0RzU1i26zTFSTNb3KwIgvvgwYPNQ2rbztw99dRTPWVuvPHGgBO9 sDgZO3asWx5cxo0b5+5HaiPYopP2PWy/cliwlJSU2MXUPiaw4cNsZpnD3sL0sLb9xW1eqGjo0KGe +uGDbgey9s0IZiGCyYBnn33WLY4FQm3R2fRH91tA1L3Y2fj888/NXYn2Ao74PMI7HeywUCMy9JHV np6e7mkHd0iABEigtgT0Uy20EaktQV5HAiRAAiSQrAQoYCf4yGJRxmLH53r79t3O42Ylzh/jVQne I//mVzmidUlJmezYWeBkYxdJRYJnl/v3kkdJgARIIHoEwhFLjzzySLcByPAdMGCAaw3innA2YNtw 2223uYdgNQEBHGEvLvj4449XywRGOfz8mjJlipg+zP369cMpN2AbouP111+X1atX6131iPWTTz6p LE9MoRYFcJ0WAfQFsHmAxYQO9G/UqFGe/uGxbVhlIMPcDAi3TZo0MQ/VeRuWIKb9hV+bzZtgguD8 8893D6HPY8aM8ViE4CSsYvr06aO8rHVh1H3PPffoXfVuT2j4ZbjjUfbhw4e714GZKTDjxFlnneWe xwZYTZ061WP7haxs2IYg494MCNpmwMccWdw6glmqoIydFe8nwuu66vKOCYG5c+cq33ZYtyBTHtn5 5oRAXerntSRAAiSgCeifXVzIURPhOwmQAAmQAAnsJcBFHBP4kwCxGgs0FhQUqcUPE7grYTUdliJl zsKUyg/b2c7Ly5UMZj2FxY6FSIAEUpuAn1hqW1KAEDyJTREbiyzm5eXJ7373O+VpnZOTI7B4gJhs xu233+7uojwW/IO4qgP+wLDkQBY0vJZhvfDyyy9Xs8G46qqr9CXqHTYnCxYscI9BhNZZueYCkMiQ hsCshWxbgNYVwLrCFGphO4K+oDwEdfh3mz7huA5tv/jii3UVEXv/+uuvPXUFarNZ6O6775ZXX33V bePMmTOVXQsmGvbZZx9ZuXKl2BnvYAOG9qKP+fn5btUQYjFufjF69Gh55pln3FOPPPKIZyKgadOm yhfdzFjHOII1BGg8Bo822wGbGVsAtm1uQmVU23Yj9uSJfc/a7ENQh9COhRozMzNlxIgR0rdv39pU xWtIgARIICQBbSGCRWIZJEACJEACJEB86d/gAABAAElEQVQCvxKggP0ri4TaqqioVOJ1oeMRXeqI uqkU5eUVUrin2OnyHsnNzZWsTH6MU2n82VcSIIGaE7DF0pNPPtm3Eoi78DkeNmyY5zxEXlu0RgGI oyjfv39/T/lLL71U2Tsgm1kHhMA5c+boXc87MrjnzZtXzYP51ltv9QjYuMgUrrEPERT1YmFIHViA 0C9Q1u4f2uW3YCWuRzbxxIkT/aqq8zHb/zqUWIsbwqMa1i7IetZCO0R7iMV+gckCiMcHHXSQ53Sp M/ltZr7bNh5mYUw6wOZFTw5ANIcHtOn5jMmKb775Rgm9+lrYbZgWMPo46nrqqaeqZbnjvJ1RbU6m 6OvNd4jgOk466SR3gUp9rK7veGoBkzHghXbDsxvvDBIgARKIFgEtYNMDO1qEWS8JkAAJkECiEqCF SAKOHDKvYRtSUFDs/FFVloA9qHuTIeBjYcdC2Ik428jKZpAACZAACfgTWLVqledEIIEXheB7DBuK YMItBFFkosKD2Bav9Y2QzQ27ibPPPlsfqvYOQRmL+n300UdyyCGHVDvfrVs3WbJkSTUBFgVhiwG/ ZVwL72zTeiLYYojoH9o9cODAavfTBy688EJB9lswBrpsbd+RLW1GsDab5SDUQxiGJzcmEPwCXJFd joU0bfEa5WHVYUawzwP8nW3/74ULF5qXK+H4vvvuU9nfgYR4tBUTEt9++62bRe+pxNmBCK4DQrH2 VdfHzPeCggLPmB9//PHm6TptY6FGfH4xAQPxGp9xPGVA8To01muvvVZ5g4cuyRIkQAJ+BPS/e/TA 9qPDYyRAAiRAAqlMoIEj/CWl8ldeXiHwTU6mUNYZTp8gXu/eXShlTh9TPRo0aCCNG+VJw4Y5yk4E +4y9BLKzMomCBEiABOpEAJ7Qa9euVfYJ8DGGhcfhhx9ezY4i1E127Nih6oEwDuHxsMMOE2Rdw5Ik nCgrK5Ply5fL999/r6w+0A74HcPSoS6BPkE0RXYxBNZDDz1UCb51rbcubarJtUVFRfLll18qsR3b bdu2Ve2HPUx9/jyEOI9JE0wqwM8VkxMQf+uzTeFyxeQAPLzhdQ1bGoj3mBBgkAAJkECsCGDRXSzS i4nIQAsYx6otvA8JkAAJkAAJxAsBCtjxMhIh2qHEa6cMMoGwkCEEesavBJo2bSQNc3MkPS0tIf5A /rXl0duigB09tqyZBEiABEgguQjAAx02NvAQx+9cyP4fP358xBfvTC5q7A0JkEA0CNx4441qEhCT adpSJBr3YZ0kQAIkQAIkkEgEaB6cQKOFRa+2bd8tlZWVCdTq2DR1pyPqpzVIc0TsbArYsUHOu5AA CZAACZBAUhDYtm2byrpG5jgsU4YMGaJsQxIhYzwpBoCdIAES8BDAkyt4imX9+vUUsD1kuEMCJEAC JJDKBChgJ8DoIxOo3PF53rGjgOJ1gPECo90FhUq8pogdABIPkwAJkAAJkAAJeAhgocYnnnhCYMEC mxNYhsCihkECJEAC9UVAZ11DwMbiygwSIAESIAESIAERCtgJ8CmocDKuC50/rMqcDGxGYAJYzLHI 8WtNT28gOdnZgQvyDAmQAAmQAAmQQEoTgL/s9OnTJT8/X3Ho3bu3jBw5ss6+6ikN1ek8POWRue63 KGuqs2H/SSBcAlrA5kKO4RJjORIgARIggVQgQAE7zkcZdiElJWVOZlCJ8mSM8+bWa/OQhV1aWqYW c8QjwJkZ/HjX64Dw5iRAAiRAAiQQhwRWr14tU6ZMUYtM5uXlydixY+Xoo4+Ow5YmXpP+/ve/q0bP mDEj8RrPFpNAnBCggB0nA8FmkAAJkAAJxBUBKnxxNRzexihBtqzCySoucaxDqrwnuedLoKpqjyP4 l0p6Rrqk56U7vtgNfMvxIAmQAAmQAAmQQGoRwEKNCxculDlz5ihLNmQJT5gwQZo3b55aINhbEiCB uCZAATuuh4eNIwESIAESqCcCFLDrCXw4t4V1SGlpqcoqDqc8y+wlAL/wkuJSycnKkqysTGIhARIg ARIgARJIcQL2Qo3Dhw+Xfv36SVpaWoqTYfdJgATijQAm1XJzc4UWIvE2MmwPCZAACZBAfRKggF2f 9IPcW9thwBKDUXMC5RV7M9czMjMEOdjwY2SQAAmQAAmQAAmkHoFly5bJtGnT1EKN++23n0yaNIkL Nabex4A9JoGEIYCJNWRhr127Vnbs2CFNmzZNmLazoSRAAiRAAiQQLQIUsKNFto71YkFCeF+XlVfU sabUvByWK8VOFnZubrZkZTILOzU/Bew1CZAACZBAKhModxa/fvrpp2Xx4sUKw0knnSSjR4+WnJyc VMbCvpMACSQAAS1gr1+/ngJ2AowXm0gCJEACJBB9AhSwo8+4VncodHyvS8vKa3UtL9pLABYsBYWF 0qxJE2Zg80NBAiRAAiRAAilEAAs1PvjggwLxJzs7Wy655BKBgM0gARIggUQgQB/sRBgltpEESIAE SCCWBChgx5J2mPeC/UVZWZlaYCjMS1jMhwBsWEpKyqU8r0JlYdNGxAcSD5EACZAACZBAEhHAz/5X XnnFs1Dj5ZdfLvvvv38S9ZJdIQESSHYCFLCTfYTZPxIgARIggZoSoIBdU2IxKF/sZF/DQoRRdwKw EiksKpb0RumSkZ5e9wpZAwmQAAmQAAmQQFwS2Llzp8q6Xr58uXryatCgQYIXF2qMy+Fio0iABIIQ oIAdBA5PkQAJkAAJpCQBCthxNOzIGqqqqlLe15WO/QUjMgTghd3Q8btMa5Dm/BHLxRwjQ5W1kAAJ kAAJkED8EMBCjY899pjs2rVL9t13X5k4caIccsgh8dNAtoQESIAEakCgdevWqvSWLVtqcBWLkgAJ kAAJkEDyEqCAHWdjW+b4XsNCxNGyGREigCxscM3IyHAEbGZhRwgrqyEBEiABEiCBeidgL9R49NFH y9ixYyUvL6/e28YGkAAJkEBtCbRs2VI9SQIffwYJkAAJkAAJkIAIBew4+RQg+xqvIsc+pKqK6nWk h6WktEyyc7IkfU8aF3SMNFzWRwIkQAIkQAL1QGDdunUyefJkd6HG0aNHy8knn1wPLeEtSYAESCCy BGB91Lx5c0EGdqGzKD0n5SLLl7WRAAmQAAkkHgEK2HE0ZrAPKXUyhSFkMyJLABnY8BXPysyMbMWs jQRIgARIgARIIOYE3nzzTZk5c6YgA7tDhw5y5ZVXcqHGmI8Cb0gCJBBNAvDBhoCNFwXsaJJm3SRA AiRAAolAgAJ2nIwSROuS0nKB3QUj8gSqHL5l5RWSlVUpmY6VCIMESIAESIAESCDxCGChxunTpws8 rxH9+/eXoUOHSjoXak68wWSLSYAEghJo0aKFOv/zzz9Lu3btgpblSRIgARIgARJIdgJU8uJkhGEb UlxSwuzrKI5HWVmZVGRnUcCOImNWTQIkQAIkQALRIvDVV1/Jgw8+qBZqbNKkiYwbN06OOOKIaN2O 9ZIACZBAvRJABjYCAjaDBEiABEiABFKdAAXsOPkEVO1x7EOcDGxG9AhUlFdKpWMjgmz3Bg0aRO9G rJkESIAESIAESCBiBCorK2X27NmyaNEiVScWarzkkksEIjaDBEiABJKVQOvWrVXXKGAn6wizXyRA AiRAAjUhQAG7JrSiVBbiNf44gwc2I3oEKh2+4LzHyXZvkE4BO3qkWTMJkAAJkAAJRIYAFmpE1vWa NWsk01nHYsSIEdK3b9/IVM5aIk5gxowZEa+TFZJAqhJo06aN6vr69etTFQH7TQLVCBQVFUl+fr46 npWVxcWbqxHiARJIXgIUsONgbGEfAn9mRvQJVDgCNl5Z6WnRvxnvQAIkQAIkQAIkUGsC5kKNBxxw gFqoEe8MEiABEkgFAtoDO1UF7CeffFLuvPNOd6jnzp0r3bp1c/drsnHBBRfIJ5984l7y7LPPylFH HeXuR2Jj2LBh7voMJ5xwgqD9Zlx//fUyb948dQg/yxYvXmyertE2JnVPP/1095p77rlHBgwY4O5H cwMcmzVrJh07dozmbQLWjUnta6+9Vp3HIs6Y3I5kvPTSS3LIIYdEssp6rasu44WFso888kipqIic VnXzzTertUsiAQVrotx7772qqgxnnbOPP/5YGjZsGImqWUecEqCAHQcDU+Us3FhWRvuQWAxFuWMh UlHpLOYokf1BF4u28x4kQAIkQAIkkAoECgsL5eGHH3aFgN69e8vIkSMj/kdqKrBkH0mABBKXQF5e nuTm5srWrVvVk7ppaamVgIP+f/fdd+4A/ve//62VgP3WW2/JM88849bTo0ePiK+fAKEPoriOk08+ WW+67xCvdX+0PYx7soYbYKHrwqUQlKMd27ZtkxtvvFGmTZsmr776ar0I2Nu3b5fbbrvN7SpE/Ecf fdTdj8TG/vvvH4lq6r2OSIzXihUrBK9IRqNGjSJWHRId9PcA9VK8jhjauK2IAnYcDE2V48lc4Qir jOgTgIVIpTNhwCABEiABEiABEog/AvhDZOrUqYI/UuFxDa9reF4zSIAESCAVCWAhx7Vr1yoRWy/q mCoc7EV6P/30U7n44otr1H387XfNNdd4rrn77rslPT3dc6yuO19//bWnimOOOcazv3PnTldowwlk aNclkGlqRvfu3c3diG8vXLhQkGG+e/duVTcmAeoj7r//frcNYAw7kUhG586dpWnTppGssl7qitR4 LVu2LOLtj+Rn55133nHbd9ppp7nb3EheAhSw63lssaAgXhRVYzMQYA2vcS7kGBvevAsJkAAJkAAJ hEMAIsP8+fPVCz+j8Zj4+PHjuVBjOPBYhgRIIGkJaAEbCzmmmoBtW1R89NFHNR5nZEV/8cUX7nVn nnmm4KmeSIct9P3mN7/x3OKbb77x7NsCt+dkGDsffvihW6pLly7SuHFjdz8aGw888IArHMP+ZL/9 9ovGbYLWuXnzZvnb3/7mlrnjjjuUtcVxxx3nHrM3HnvsMc/4X3755XL44Yfbxdz99u3bu9uJvBGp 8UICASxbAsW7774rc+bMcU9DRB40aJC7b2/A7qVVq1b24Vrtw1oJnwkdwT4HugzfE58ABew4GEMI qlzAMTYDAb9xvBgkQAIkQAIkQALxQQB/gEyePFkt1IisuCFDhkj//v2lQQMuuBwfIxR+KyDSYNyS yT80/N6zJAlEngCsJmAXAQE71QKetr/97W/lgw8+UF2HaAsvXhwPJ4qLi+W6667zFL3rrrs8+5Ha sTOibZEUgrbpZa79zWtzfzD497//7V5a12xut6IAG9Apli5d6p7t2bOnux3LjX/84x/u7U499VTp 06ePux9oA1Yn5gQGsvEPPvjgQMWT4ngkxwvJBMF850tKSjwC9oUXXljjpyRqCx1PZJhR10khsy5u xy+B8P71j9/2J3zL9kBQpaVFTMdRTRg4zNMzIvvoWEw7wZuRAAmQAAmQQBIQwB/FWISntLRUZXRN mjRJsCgTIzEJ/P3vf1cNnzFjRmJ2gK0mgTgjoL2STfEzzpoY1eYce+yxroCNG3377bfStWvXsO75 yCOPyP/+9z+3LCypbFsS92QdN8yMaAhpOTk5nhohukcq89TO5gajaMbKlSvd7GvcJ9r38+vLunXr BNYvOm6//Xa9GfAdT3MhQ1gHPJIPOuggvZu077Ecr//85z8ejpG0B/FU7LNjLsqK01hskpH8BChg 1/MYw/+aGcGxHQTwrnRmktOd/zFIgARIgARIgARiTwALNT7xxBOSn5+vbo5Hui+44IJqf/THvmW8 IwmQAAnEDwFtG5KqArYtSn355ZdhCdhYR+Gvf/2rZyBN+wnPiV924FP9008/SUFBgcAmA4JzOF7Z 8GE2LUQikRGNtnz//fdq8eK2bdt6fJnNe6Hptl2JX9+QjQ4RGE88wf7jwAMPlOzsbL+i1Y7Zma41 WZcCntmrV69Wk9SdOnWqtS0Y7EJ04AmtE088Ue8GfP/hhx88wjuuqe1CqPhMYPJEswt40wieKCsr U/73eszwOcjKygp5h7qMV8jKrQKmBzVOHXbYYVaJ4LtILMTnA0+YIDO+efPmwS8wzpriOSYm6vJU g1GtY+1bqZ6WwPcF//7CViacfwfMOvy20VfUiRcWXUW94X4H/epL1WNpqdrxeOm344AtjiNzvDQn JdoB2piRZZAACZAACZAACcSeABZq/NOf/qTE67y8PPnDH/6gFmu0M9Zi3zLekQRIgATii4AWsFPR QgQjYS9OaItzgUYLT4PoBQdR5sYbb1SitF0eIvHEiROVhzQW74NdAgRoCLzImoY4PG/evKB2n6ZF Beq3rQw2bNigRHdkjuP1/PPP281Q+xDOnnvuOVUGbYFQjP5D7IK11o8//qjK2XYlgTLSIeLfc889 qi8NGzYUCMiwZME7ft6ij/fdd5/vQog7duxw23zZZZd52guPY9wTbcNktB24L+w+UD+8uZH1Dibo E46BN+oPN1atWiXTpk1zi996663udrAN+7MSamKhvLxc9UmPEz4bmEjA7yjI3sZ4QERGv5H9i4kE XRbv2uomUJtuu+02t3ygtkCjwOcN9UHcNMcM+7Dnevzxx5WVjnmfuoyXWU9NtvG5Nj2o8dmCx3Wo 2LJli7L26dWrlxKG4XV//PHHKwF6//33V8kM5pMTfvVBDH7//ffdU4EmNDC5hMVHzXE66aSTBJMD dqA+fLbxvcc4Y4wgqmMf22+88YZ9SbV9PFGo73XppZeq82gD/j1q166dW++hhx6qvoP4LuD7wgif ADOww2cVlZLQUSmmRgVt4Eod6JSvA+PhGRIgARIgARKIBgH8wYE/zLBYI373wR9iEyZMqFHGTTTa xTpJgARIIF4JICMRvvKpKmDbfvrhLOS4du1aJRjpMYX4CO9jOyBqQ1QMFhApzz33XIE1AvyU/RYv hEe5GbaNAupYsWKFW2SfffZxt/UGxheZxbY4rc9joTzcHyKp6UftZ1eCa1566SUZOHCgvtz3HSIh uEBcw89lUwT87LPPPG02K4BoiRe4YhLajIULF8pZZ51lHvJs455YFBD9mT17tmDRv1BhjtH5558v Rx11VKhL1HnbYiJUpvrXX3/t8cvGhALaZ2e8Y8ICYiT6YI4rJhqCBcZEl/ezsoGo+vvf/16Nc6B6 kAAAYRQTD0uWLHE/j7Udr0D3Cee4zcX8/AS6/u2331aCsil8m2Vx/JlnnpGXX35Z7r///oB+2nZ2 vd8CjpjAGjBggMcvHk9WzJ0715PJjnJ4AhD3DBSwCPrd734nY8aMkSlTpggmhPzi9ddfd8cYgj6+ zyNGjBCMm1/gu4CJFnjaQyhnhCbADOzQjKJbAmIqVGxGzAiANpnHDDdvRAIkQAIkQAKybds2ufnm m5WADRzIcoF4UJPHRYmRBEiABFKNACwP8O8kLCD8sl2TnQcyhU1BGEIPJkODhW0dcuedd3qsK/B3 ILJqTWEU9UGQxb0gPNlCNcS68847T9kL2Pe2RefOnTt7ioQSuCG4IyvUrgdtMD2bIbT169fPI6ii rXa88MILvuJ1ly5d5OSTT/bUiWshGp5xxhnK2kDXhaznUGEvoogsaVu8BlOIwJgEgHioA/eEdVgo axwIvk8++aS+TP72t7+526E2TKEfZc3Pkd+1piAL9liQ0Dymr7n88suVtYQ9Xva46/J4x2KHZnm/ cbv22muridcYMwigdnlwufjii93vQm3Gy2xfbbbtz7X95IFdJ34HxJjb4jWusz8f+KyPGjVKIHj7 hX1ve2yR1Xz66acrYVhfjzIYA9PmBJ8/LAhqi9cYy8GDB6vvi74e78iwvuWWW8xDnu333nvP3Yc1 CvziTfEa32d8J8zApBSevGCER4ACdnicolYKucAUU6OG17di8A71i4/vhTxIAiRAAiRAAiRQYwL4 IxKWIVhYCH8U3nTTTUoIqK0XZY0bwAtIgARIIIEJ6IUc8eh9KobtuYzsy0Dx+eefewRPCEbImjQD 2caTJ082DwkWnkUWNIQxWAls2rRJ3nzzTY+QDXEKWbp2mKIVxDA7k9Jc4BEiLmwSdCDLd/jw4R6R C0IbBMqNGzcKhElYh2gB07ZWsLOKcR5CuxkQRtG35cuXq0UNUSfq13WiLARDU8TDgpf4m9kWcCHg 4TheeKJKByYWrrjiCr2r3jFJDZuJxYsXq6zXNWvWyAMPPOAp88c//tGzb++YgjUEW1N8tMua+xUV FWKOC3730N8js5y5bWb3Q2TVgvOZZ54pzz77rMq4hqh95ZVXqsvM+iHS2+Nu1g32ZthiLyxAkNmr A+IpeOG6f/3rX+ozic+mOaGBjPxFixapS2o6Xvo+dXk3P9eoJ1hm/FtvvVVt8uHee+9VyQ3gjqxo CL6YbDID311M3tmhx0YfN62G8FnH5IrZvrPPPlvg192yZUt9idKDkHltfsaRGQ9BGX7nyLDHIqCw koHFiQ48sQAvfju0x7w+jn8/EBCsn376aeWtj+8e/h23//2xBXldB9+rE6CAXZ1JTI84//ZTwI4p cd6MBEiABEiABEggFgSQcYQ/VvGIJDwAkWF21113KeuQWNyf9yABEiCBZCCghTcIJKkYtjBme06b TK6//npzV+6++26PXQCETbsMFhSGOGovqAYR7LrrrvPUB4HcDDxdZArqtrex7dWLn4Nm/POf//R4 JyNDGlmnEGphHYPAYm+wJoAIa4ctYJuLHaIsBFf83LUXuEP9pmCKsqaQh32E7SNtZ7qiDH6+Q0A1 A5MEyFQ1LUYwaQ3bMJMp7CJMfmYdaI/pFw5BPNywJxrANVT4eVgjS/+VV15RHuQQlSFEgp097qbA 6XcfW6C0x82+N8YGPsxmgD24mmEuZIjj4YyXeX1ttzGBYXpQQ6Q1xXWzXlij2JMbEOVhX2ParmCh RHw2MOGiA58Nv+xkU5yG6Kw/Zzqj2vwsjx8/Xk222NY9+N5j4kUHxhD12lYo8Oi2udvfHdRhs8cx TFQgeQPfQ91GLMSJNpmZ2BDvGeERoIAdHqeolcLPJf3DKWo3YcXVCez9faD6cR4hARIgARIgARKo MwH8Mo4/RPLz85UogF/W8eJCjXVGywpIgARSjIBeyDGU3UKyYjnyyCM9XYPfr18g0xdZqTogSMGu ygwIiRCxdSD7GVYFgcIWPrUIpcvbbfHLFkd2sw5YCugoKCgQ2FGYgUzfJk2amIfUNu4LCwY7TNsK CMnIMtXCGATFhx56yL7E3bdFVFvgQ0E70/Xwww93r9cbEPNMERrCNbycA4UpUKIMsl39Ak9r6YDw HUgg1WXMd1tM9PNINsuDnT0xgkzrP//5z+L3tFiocTfrxraZ3Y19O5McE/5mLFiwwNx1tyHWmmNu C+PhjJdbWR02MN7m5xoTM36ccAskMpg2GrCagS1KoDAnOFDGHhcI4qbgrwVnWPHg+4qnC3QgWxrf ATs7Hm2HjZAOTA5BpM7NzdWHPO/I3DY/t34Z2LbnOirABI35xIWuFCK2Gfvuu6+5y+0gBOgUHgRO LE5BvKaAHQvSv94DvNMacO7mVyLcIgESIAESIIHIEEC2GRZxwqOXeDS6Q4cO6nFbv1/gI3NH1kIC JEACyU1AC9h4ND4VAz7AZvgJRfjZA6sqM2BRYP+dDSFT+wVDQLazrs3rsQ37ADPsrFhbQLQzlG0h 1RS4kdlrBgQ1nW1vHtfb9sJ/sK1A1qoOLCynrSogiIJJoMXmcI2d0Y+FCe0wfaQxIWALb7jHww8/ 7F4G8dxvwUy3gLPRtGlT5Yet7VAgbsKmwwwIlPhdQoedNa+PB3q3hVxbrLevs0VS9MO0L7HL259B e9zt8qbdCKxbMjMzPUXszH1M+MM6AxMc9hjCmgIZ0OCoJyt0ZaHGS5er67uZ4Yy6Ak0Q4N+s//f/ /p97OwjFwSaMUBD9QuayHkNTkMZ5O7seZfE97dWrl+jPFMphMmjIkCHYrBaYIDAFeHxmTXuRahc4 B8zJG7QNn31TtDezwnH9o48+KgcffLBfVcoeyLx/oHK+F6f4QQrY9fwBcOTraj9Y67lJSX97Zr0n /RCzgyRAAiRAAvVAAI/UTp06VT0uCdEAmW/nnHOO5w/semgWb0kCJEACCU1AC9ip6oHduHFjlXWq szhN6wI9sJg0NUU1/OwxPZ51OfMdGcfIvEU2KRZ927Vrl+zcuVP5RUN4gzhtWgzgWlvANi0cICa2 b9/evIUrwumDplcvsjPNCCX82tmhwWwr8LRTeXm58lFGX9Av9G/r1q1qEb1vvvlG2ZKY97fbDoHf FHZtkRXXQrQzRcOuXbt6rjHrN7eRcaqvg9ezHX/5y1/cQ5iYCCbsuwWNDVPIxWHbhsYoqjbtiYj7 7rvPY29hlzczqjHufuK/vgbs9WcXx3TGsD6Pd/TPFG1xDJ8HiOjoP4RsbQNjfwZRFhHOeO0tWff/ 2rwCTRDY5dCncJ7EQ/KDFrD1pIxutV0nJlXwXTcXh8R9AonXqAdWMGYccsghHs9s85zexjiage+S /rcZYrb9mbvooovM4p5t83uFE926dfOc505gAhSwA7OJzZkGtBCJDWjzLpg2YJAACZAACZAACUSK AIQDPBYKMQB/mE6cOJFe15GCy3pIgARSmoAWrlI1AxuDD+sNLQIic/Gnn36SAw88UH0ukG1sLwZo LwZnfoAgVj/++OPywgsvhBStzOsgVOqx0MfNzFos4GiHKWohkxxiPAI2Juaiif379w8p0tpCr5nN re+LeuEZjJdZvz4f7N226LBFNtP+RNcDb24zIGj7Cd1mGXvbziLGgn/mxIGZwWtf67eP30PMyQz0 y/Ra9rvGnIjA+WAWKDhvjjsy4YOFnYUPodovMF6nn366ZwIAn3V4f+N19dVXKxuLQE+0hTNefvet zTHzc43rA2WgY6LEjEsvvdTcDbhtPh1g22toYVtfDH9pO2AHAv97M0Nal8HnQy+wqI+FGm9dznw3 7YTwVIeZUQ2LlGBPd9h9MCe2zHtwuzoB+ihUZxLTI5BS0yinxpg5Jw1iCpw3IwESIAESSFoCyPCC EIBHtfFHAf6ghucgslkYJEACJEACdScAoQS+yMj4Q6ZfKoadQWtmZeJRfZ3NCzbwSw70M+jHH3+U Qw89VAne9iP/objaAjVENjPr07ZRwM9H06vXFHY3bdrkuV2gDFazkG1nYjOB5US/fv2Uv3BNxWvc x/ZltjNd7fvhGvCsa5iLU8Ia44YbbnCrhO+3znJ1D4bYsP2JbR9zv8vNcUJmuz1RYV5jj7ufsG+W t8VeP44oD2F6yZIl1RbE1HVNnjxZ2Vw89thj+pDnPZzx8lxQyx1MkpgCPsYvUIa8afeBcrYY7dcE fAZMMV5PVOmyNk993HzHUxVYDNUvTHHc73y4x0xrF5t9KEHcnDABlwMOOCDc26Z8OWZg1/NHIM15 xDYtnfnAsRyGtLQGku6sgswgARIgARIgARKoPQEs1Pjggw8KFhaDnyMyTvr27Vv7CnklCZAACZCA LwEIRHiEfePGjQHFIt8Lk+SgnaH41VdfyRlnnKFsMZCdagYW3vMLLPLWs2dPj+iMcrAfQFYsrBkg JLVp00Zld2/YsMHj7WtbP9iZtbYIbYp3uI8pcKNuM0x/XfO4ua0z0HHMtispLS2Vc889t1pmKbK+ scAe7EEgBKJv+Cyhn+aijfjZbS90Z9tkdOrUyWyO2jYXb4QQN3r06GplQh0whX0I7zo7FX3EQoo1 DTP7GteGEpgxMWT2Y+DAgUFvadfvlwlvVmBm+6JPHTt2NE97tiHw/vOf/1QZ1/AWx5NtZmYvCo8d O1aN/7BhwzzXhjNengtquWN/rk855ZSANZkTTfZ3ONBFEJjNPpsCtm2TouuAhzoyrk0rjkceeUT6 9Omji7jveHrDjKFDh6rvh3ks1DZ8us2wPdH97qvLQ6A3nzAIZXWkr+P7XgIUsOv5k9AAYqqz+AK8 IvFhZkSfAB4lAXcGCZAACZAACZBAzQng9xUsPmUu1Dhu3DhmkNQcJa8gARIggbAI6IxQTBgGynYM q6IELWQKU+iCztB84IEHPGLXbbfdFnAxNqzRYGZqI6P6ySefDOhf/OKLL3pomQI0TthZl3ZmrX3e tFmw7WBCZRlD0MOidDrsbHBYebz66qv6tPp5DI/tQNnHtvgOkdsOU2SDeO9nx2D2A1nvwaxb7Prt fSz8bC7WiIkJWyi0r/HbN4VcnDe5+5W3WcDGI1h89tlnntP2uJsnIZaaHMHZXljULK+34al91113 KcsQCNnYNkVdiNgQbU0+5n0CjZeuvy7v9uc6kCUK7rFy5Ur3VmZb3YM+G88//7znKCaddOjvvd7H O37/vP/++9UEDKx49OKfsAjC993OboaFkBmXXXaZWgDSPFbTbfNpDkwa4YmZQIHkD3Msg3nZB6oj lY8zDbWeRx//gOGFrGBG9AmAM374+v0Ajv7deQcSIAESIAESSGwCyAC84447ZPbs2YI/NvHHwi23 3FLtD4TE7iVbTwIkQALxRUALnKZgGF8tjG5rkN2Ll47PP/9cLbwIyyodOH/VVVfp3Wrvr732mnus c+fOAq/lYIvvIYPTDDvDOj8/3z0Nkcz2JtaZxLqQmWVtezLDxztY2EK9LXqZ4iXqQdsCidc4/69/ /Qtvbtj1YcFQU+y3xXt9oTmZ8u233+rDAd9R5xVXXCHXXXedoE8rVqxwy0K41PsYy/Hjx7vnarJh W0wcccQRQS+3BVl7ssS+2BS80U793bTLYd9+GsDmfMEFFyjPcIj/f/jDH6pVgc8JLFVgi4LPrA4I oGY7wh0vfX1d3m1e9vciUN1YRDRU4PdKLKBpBmxxdNj3xvcfWer66QHbY/uJJ57Ql7rvejJQHzA/ 5/qY/Q6rPHxub7/9djXpZZ4vKyvzWAX5TQaZ5c1xw/Fw+Zl1pPI2M7DjYPQhYKenpzl/CKamp1ks h2CveM3Jglgy571IgARIgASSgwAe2YZlCP4IQXYJsl5C/WGYHD1nL8IlMGPGjHCLshwJkEANCGiR LFUFbKDCo/ZYnA2BTEz8PDIzGZH9ay6spgr+8h8IfFocxSHYbeAp6ECB7GuzPMRDvQAjroEXuSmU +olWpq8yslTNRd1s4RyCPCxR/AJtt4VQ27Zi8eLF7qW4l5116p50NpABCpsKM+yf5XaWcSCRzbR3 gB84LG5atmxpVu3ZxmKbZia5ZgS/cLOPN910U8Cx9FRo7SC71rRaQfa16VVsFVe7ph8xRH9YogWL cG0xkJVrTxTYHGE9odtrWrrY98fnBRnp5oKFmDDo1auXKhrueNn11mbf/Nzj+mAZ6FhAU/vEQ7iF f7YWm/3ubT8lMXjwYE82s5ldDzsWe4FPiN04rv9deOihh1RWvzmm5qQL2oAxMLna7cLvvqYwDrud iy++2C1mfh5wMJRljT2xFeoJAfdG3FAEmIEdBx8EZAUH+yLHQROTpgmYKAj2y0rSdJQdIQESIAES IIEIEcAfljNnzlSZ1xCvkZ2Ex1ntP3gjdDtWQwIkQAIkYBGggF3dCgIipw4IzCNHjtS71d5NAQsn 4RkdKJCZfc4553hO26IUPJO1SIaCdoZyYWGha3OC87bAbWdrI+sUQrUdyO70y0Q+8sgjPUVNcTxY 39asWaMys822Q/CzRWcI6mYEykq27TaCWYhgEUJTvD7ttNNE+4rjdwztQw3x/ZJLLjFvH/a2LeTa Gc9+FWkRHed0e/zK6WNacMZ+oKe64ZMN8dUOW+w1ueKaYFns5hMIqFf/m4DtcMcLZesSWKzb9ACH QG0/TWDWb9p/QMh++umnzdOebQjj11xzjefYrbfe6tk3nzTws0nJysryfF9wT1jemXHwwQd7Jnhg P2L7Yuvy8OPGZJcZtue+nVEdSpA27UZC8TPvy+29BChgx8EnAf/wZWUyGT4WQ5GRke5MFgSebY9F G3gPEiABEiABEkgUAvjlHZ6UixYtUllJo0aNUo/+BvP3S5S+sZ0kQAIkkCgEdNYgPLBTNWzR1uQA AThYQhh+ZkEs0oHytvCEc1hE0G8x4g4dOuhL1bttZWBn1tqCon0ef/8PHz7crRNCG7I8YdOlAxPG AwYMENsTGAKvLWaa9SM7/bHHHtPVuO8QRyGk25YJXbt2dcvoDXuhPgjpfnHWWWd5DkMMRBatubYX srJhv2BbZEDQRsA+BZYiOmBLlpOTo3dr9G6PSzB/ZlQM4VJnCGPfzmzHMTtM9vAeR0a7juLiYmUx gfGwOeM6/T3W5e1EAAi+33//vT7tvuN3sYkTJ7r72DAXvwx3vDwV1GIHViZmBLOpQTk7sxkWP5gg MgNPM8Dn217MEIkSsFbRgadPTKaBJifM7Ghci7rNgPuBmVGNc7///e8946jXesE9zAkL1G332c6o 9vs+6fsjA90U4U2BX5fhe3ACVE2D84nJWWRgZzoCNowtuIxjdJFnpGdIRjoF7OhSZu0kQAIkQALJ QODNN99UmdfIwMYfzFdeeaUnayUZ+sg+kAAJkEAiEMACaLm5ucqiAYJPoMzPROhLbdtoi326Hixo iPUYQgXEtJtvvtkthkzJiy66SPlgQ6DFRK3fInG4AKKXGbZQ2r17d/N0NXHcFJh1QWSXYqFFHQsW LFCL8p199tnKokQvRqfP63c/0eu8884T07Mbi/zNnTtXIOAi+xzWC+Yij7ouvPs9nYwMcjMOPfRQ 9dQVxGhk4LZp00adxufy0UcfFdxPB0RK+BIjKx1Z5X73hYinxxP+wlpExiSDLXrqesN5Ny0mUD5U Nqw9iRGqPOqEcIyx0oHJDWSTI95++219WFlZYOJEi66nnHKKe05vgNWsWbNckRQcOnXqpMYN/CB6 YyFE24rk6quv9ojh4Y6Xvm9t383sa9RhP5lg1wvfd9jG3HPPPeoUMv8xQYTvKz5TeFoAzEy7HhSE UGxPeNhj5fedwrWoF2K4zqzH77KYvDHFcGR6IxtcZ/2jXxhHLIzZvHlz9X0xhWvUi++l38SQaakC wRtZ4IHim2++8ZwKNcHiKcwdRYACdhx8EJxlHNUPDmQGl1dUxkGLkrMJ6b/Yh6TiL3zJOaLsFQmQ AAmQQDQIIANs+vTp7mOivXv3Vo9m249gR+PerJMESIAESMCfACwD1q5dK1u3bvXYB/iXTr6j8Fs2 /W11D7U4pvcDveNpInhomyL1U089Va047Ejg529mhNrCkyladenSxeOPjQpNX2XsQ5S0A2ItspAh RpqBLHAzIBDD61fbfviJXvg5PWHCBOULrq+FcIeXGeAH73CI2/o+Jg9dFn037T5wXJezF8EbM2aM gI/OqEZZiH+2AIjjmAwHcy3mFhQUqKe8cA6BRaKDZdLvLRX4v++8847nJMYmWMD/WAfY2Jn2+pz5 jokHU8DGOVO4xj7E+Tlz5og52eAn9sJXHXXhnB5fXI+sXjuzF8cRWEjQzFjHsZqMF8rXNmo6QYD7 oL0bNmxQCRH6vpicCTRBAxuaa6+9NuSkkW3HouvGOyZUtICNffxOe++992JTBfzG8W8BhHQ9wYAT fpMtOH7ZZZepz7f9ezA+v/p7gXJmVjz27QhXhLev4/6vBGgh8iuLetvCjG5aA8dGJMhsTb01Lolu jCz3DEfEZpAACZAACZAACfgTwGI1+MMB2ShYDAsZMPCitH9p97+aR1OdAESMYB6eqc6H/SeBuhDQ nrepupAj/ma2PYphwxGO7QO4wyf6/fffr5bZqccE2a7w1Yb9B+5jCsWwcDAjlGhlLuyGjFO/LGfU py0VTFsKfR+IklicEV7KprgZqL9TpkxRGaIQYu3AsREjRiihGV7hps0B6oa3sRmXX365LycwMf22 cQ3GBZYsEARNZmZ9uD+EX/x80NnKOI9Mbd03iM3IJK9toB6dyY06YPUQSgw3JyaQyW9n2vu1Bb7V S5Ys8VjS6HIYRwiwEHpbtWrlaU+gcUPGMERUTMT4jR3qxnGIrfg83HDDDdWewKjJeOm21ubd/Fzj ep1FH6wu/P6IDHII+oE+H7geXu8YD4jzfuNg/m4BzpgMCRS2h72dwY7r0HZ4pmPiJ1DgO4ixxCSS 32KgP/74o+fSYP1DQXtSx/RA91TEnYAEGjj+LknpWlFeXiFVCdQ1PApWXFIm27bv9HhGBRw5nqgx gcaN8pw/xhtKZop4YGdnBV9BucYAeQEJkAAJkEDSEqisrJTZs2erR6jRSfxSjYwTPErJIIFwCcAj HYHsRQYJkEBkCeCR99dee01lF+oM1sjeIXVq27ZtmxKT4DcMMQwWIPbCirGkAS0AdgYQxpHUBq9q 2HPUJiBGw3YCYhkEXAh1yPb2EwVD1b99+3ZZtWqV7NixQ9mGtGvXzlfIM+vBvXENxGR4PsO6AWKj 3/2RMa1tHGAJEY4gat6rPrdhOwNBF58hjB+yt5EVXJcJf3gkY7IEvtrw58bvYGCiLVtC9bc24xWq zkifx2cDwi+yspGBDm4dO3ZUSRORvle49SGTGgkcYI7fh/GZxZMYSORgxBcBCthxMh6YR6isrJLN P2+TCudLw4gsAfiM79usieTmZPv+8Izs3eKjNgrY8TEObAUJkAAJxDsB/JGJR3/XrFmjssSGDBmi Mn38/tiM976wffVLgAJ2/fLn3ZObAB5vRybhoEGD6pSpmtyU2DsSIAESIIFkJUAP7DgaWYisOTlZ ziM8JQmVPR5HCAM2JduZyebijQHx8AQJkAAJkECKEnj33XdVtiwW0kEW2qRJk8LygExRXOw2CZAA CdQbAWSzItavX19vbeCNSYAESIAESKC+CFDAri/y1n11llNubrayEnHSsa0S3K0LgezsLCerLC1l sq/rworXkgAJkAAJJD8BrFj/8MMPuws14nHl0aNHOxPpOcnfefaQBEiABBKQAAXsBBw0NpkESIAE SCBiBChgRwxlZCrKckzus5zFBkscH6UktSePDKga1JLheF7DTiMtjQs41gAbi5IACZAACSQpAfhi Tp06VeCVCH+/iy66SPltJml32S0SIAESSAoC8MNF0lOqLuKYFIPITpAACZAACdSaAAXsWqOL/IX4 hQQrFCMLu9wx8K+oYBZ2XSk3cCrIa5jjLGCRzuzrusLk9SRAAiRAAglNAAvTzJ8/X70wSY5FarD6 OhdqTOhhZeNJgARShACScfDv9ZYtWwRP0XCBsRQZeHaTBEiABEhAEaCAHYcfBPhgF5eUqhVQnb8v GXUggAmBhrk5zL6uA0NeSgIkQAIkkPgEzIUaMWGORcDw4tNJiT+27AEJkEDqEPi///s/JWBDxKaA nTrjzp6SAAmQAAmIUMCOw09BRnqGwLO5vJxZ2HUZHr0oZrrDU3uM16U+XhucwKZNm+Sll14KXijM s82aNYur1dU//PBD+fLLL93W9+/fX7QPoXswjA0surNw4UK3ZIsWLeScc85x98PZeO211+Snn35y i/72t7+VLl26uPvcIAESIAGbwNKlS2X69OmChRr33XdfmThxosq+tstxnwRIgARIIL4J4HdHBGxE 2rVrF9+NZetIgARIgARIIIIEKGBHEGYkq2qY49iIKAG7OJLVplRdmAhotE+eI16nVLfrrbMlJSUR 820vLo6vzz3aY3rSo6+1CZtRbfpZVFTkaUtt6qhN23kNCZBA4hHAvzkQrvPz81XjsVAj/K6ZtZd4 Y8kWkwAJkAAItGnTRoFAUgSDBEiABEiABFKJAAXsOB1tWF/k/JKFXVZWHqetjN9mpaenKS9xeF8z SIAESIAESCDVCGChxmnTpgmsQ7Kzs+WSSy7hQo2p9iFgf0mABJKOgH4CcN26dUnXN3aIBEiABEiA BIIRoIAdjE49noPlRXZWlpRlVziZ2OVOxmU9NiYBb52ZkSG5ThY7rUPqb/DAvmnTprVqwH777Ver 63gRCZAACaQ6gaqqKpk3b567UGOHDh3kyiuvlP333z/V0bD/JEACJJDwBOCBjYAHNoMESIAESIAE UokABew4Hm1kEassbCcDu6S0LI5bGl9Ny8x0xGtn4Ua8M+qPQMOGDWXw4MH11wDemQRIgARSjMC2 bdtk6tSpsnLlStVz+PUPHTpU8FQXgwRIgARIIPEJmB7Yid8b9oAESIAESIAEwidAhS98VjEviQzW rMxMadgwRyoqK6WiojLmbUi0GyrrECfzOicni9nXiTZ4bC8JkAAJkECtCWChxieeeELgk4+FGi+7 7DI54ogjal0fLyQBEiABEog/AljDIDc3V7Zu3Sp44iYtLS3+GskWkQAJkAAJkEAUCFDAjgLUSFap s7AhYBcUFDm/qNBLJBBfCP45js9nbm62wEKEkToEKp3vx/fffy94P+igg5wJjJwadx5/BGzcuFH5 xTZv3lwOPPDAGtcRrxdgITd4Je7atUvZCLRq1apOEzz4o+mnn36SZs2aSdu2betUV2lpqXzzzTfS uHFjxTyD3914/RixXXFKwF6o8eijj5axY8dyocY4HS82iwRIgATqSgA2ImvXrlUitrYUqWudvJ4E SIAESIAE4p0AVb54HyGnfXj0N69hrsrALi4udfywKWL7DVtWVqayDkHWOiP5CDz11FPKDx4969at mxx77LGycOFC+fnnn93jOPf++++rbBT4aJ911lkhM1MgWr/33nuyfft2XO4GJkSQ4XLSSSe5xxJp Y8eOHfLOO+8oQd7v3wz8u9KoUSPp2bOntGzZMmTXPvroI/n6668FgrMdEJ0hip9xxhkBxewPPvhA XY9rsxx/f9gavPDCC7J7925PdRi3AQMGhBw3z0XcIYEUJbB69WqZMmWK+p5nOj/7RowYIX379k1R Guw2CZAACaQGASzkCAF7/fr1QgE7NcacvSQBEiABEhChgJ0AnwIIaRmO2NSk8T6OUAcrkQqK2Na4 QYzbJy/XycDODCigWZdwN8EIlJWVuZ/7goICmTVrlnpU3q8bOpsaovfZZ58t2i/QLvvpp5/Kxx9/ bB9W+xB98Sj+G2+8obKDfQvF6UGI13PnzlWPlgZqIrLVUe6ll15SNgPHH3+8b9Hi4mJ5+eWXVVnf As5B/JuEjGzwPvPMM30XiwNLjAsCYzlnzhzf8cOEBP7NY5AACQQmgH+fXnnlFfU9wnf5gAMOUAs1 4p1BAvVJYMaMGfV5e96bBFKCAARsBATs7t27p0Sf2UkSIAESIAESoGlWgnwGtIi9b7NGXJzQGjOw adrE8YNzvK/pA2fBSdLdVatW+YqfdnfLy8uVAG0fx/6XX34ZULy2BVRYbyRKQMyaN2+eKxbrduO7 gUxpu284/8UXX0hhYaEu6r6D3zPPPOMrXvt91yBML1iwQGWDupX4bEDIhqDtF/Du9WujX1keI4FU JICFGu+44w6ZPXu2sk3CQo233367ErFTkQf7TAIkQAKpRkBnXWPSn0ECJEACJEACqUKAGdgJNtKw x2jcKE927S50shjLE6z1kW9uWhrE68ZO5jUXbYw83brVCJGyNsIv7CXC9bCG0NmlSxc56qij1DXw Ul62bJlHHEW2Njyb4WutA22DJYYZyOLv1auX8tDGcWS1IPsaomwiBRggI1pHtuML36dPH2nTpo0+ JD/88IMsWbJEiV/64Icffii9e/fWu+r99ddf95TBwU6dOskpp5ziThatXLlS3n33XU+5t956S4YP H+6pK9AORPUmTZqozwoEc4wlgwRIwJ8A/n2bNm2a+jcO35tx48ZxoUZ/VDxKAiRAAklLgAJ20g4t O0YCJEACJBCEAAXsIHDi7ZTOSoRYi8eHCwqKpTTBxLVIMlW2Ifs0VIs2pjlCpuYTyXuwrtoTgPXE s88+W+MKIF6PHDky5HUY7wsuuEAaNmzoloWY3blzZ5k5c6ZHeP7ss8884iz8mJGprAMiKjyZzbrw eOaFF16oshwDZQvr6+Pp/ccff/Q0Z/DgwZ5+4SQWuoSwD9FaB7wUzdiyZYsS8c1jyPQ0hXCcg6AN 24LnnnvOZY66v/rqKzn88MPNy6ttw3sbftc64K8NwZ1BAiTgJYDJnaeffloWL16sTmAdgPHjx6vJ H29J7pEACZAACSQ7AQrYyT7C7B8JkAAJkIAfAVqI+FGJ82N4dD/HEXkaNXLEW8c2IxUjMzPDyURv KHm5OZLu8KB4nTyfAr8FB/1617Vr12rCLMpBjD7yyCM9l9j2GGvWrPGchxhkitf6JCZJkL2cSIGJ AzM2bdpk7rrbRxxxhDRr1kz1Gx7hHTp0cM9hAwtAmtGxY8dq4rU+j8UuTzvtNL2r3pEpGizAFoK4 GRSvTRrcJoG9BLBQ4/XXX6/Ea3xv8HTDddddR/GaHxASIAESSFECeKoQf/vQQiRFPwDsNgmQAAmk KAFmYCfowKenQ8T+xTbD+QWmpKTUXeAuQbsUVrOdrkpWVqY0dASzhrnZgj/mGalJ4MQTTwzY8bZt 23osQsxsa704o74YE0LHHHOM3q32jizhRo0aye7du6udi8cDyIbevn2727Q333xTidPoY9OmTd3j 2EB2dqCw+3vyyScHKqqOg3mmY3GETFFEKOsV2B/w+6tQ8T8k4EvAb6FGWIbYk02+F/MgCdQTgRdf fFEJawMHDqynFvC2JJD8BPC7K34/3bBhg1qnxP79LvkJsIckQAIkQAKpSIACdgKPOn55yXbEXMzA O7qulJSWVVu4LYG7V63p8LveK17nqMxzil/VEMXVAWRCH3zwwTVuExbxCxX47AeLffbZx3Mantc6 THEXx5A9HCrwqKYt6Ia6pr7OI7MaC1SaAVsRvDAm4ItsatitBPsOaSFa1/Pvf/9bbwZ8NycKwByv QGPVuHHjgPXwBAmkOoGdO3fKgw8+KMuXL1co4E8PayVMEjFIIJ4JYCFfBAXseB4lti0ZCMDqDgI2 1myhgJ0MI8o+kAAJkAAJhCJAATsUoTg/r0Xs9Cb7SFpBkcrEhojkWGQnVcAmJCc3S/Icv2OI2PC8 ZsQ3AdhB9OzZMyqNhBAbLIKd37Fjh+fScARsZAtHImzB2BTWw63fFpZtgTgvL09giWKL2Kgfiztu 3rxZvfLz81Vm+SGHHCI9evTw3B73sK1cYGNQ08AfVcgI9wtzUU2/8zxGAqlKAP7xEK+xCC6+z2PH jpWjjz46VXGw3yRAAiRAAj4E6IPtA4WHSIAESIAEkppAcBUoqbuePJ1DBnYmMiubNpai4hLZ7QjZ ZWXVBahE7TEEusaN8xzLEMfvmpYhiTqMEW13XT4HdiZ1MLFbNzpSmS2wIjHDzFg2jwfbxkKHZvh5 d59wwgnKH3fp0qVBn8oAi08++US+++47Offcc93szo0bN5q3qPU2FoKkgF1rfLwwxQhg4giLoS5a tEj1HJNLEyZMEE72pNgHgd0lARIggTAIUMAOAxKLkAAJkAAJJBUBCthJNZyOHYKzqGOWs8BhQVGx FBWVOBmXlQnbQ1iG5Dj9adIoTwnXXKgxYYcyrhpuC77ISg4VdtZzqPKBztuZ3LURsO322nYp+t6w CMELmdgQqGGdEijjG5meM2fOlFGjRqnLbaEd373aWH4Es4OxM8d1u/lOAqlIYN26dTJ58mT1KDgm 6IYMGSL9+vULaMGTiozYZxIgARIggV8JUMD+lQW3SIAESIAEUoMABewkG2cITfjjt1FeQ8cfO0tl ZBc7WdlVVYnjKYI+ZGdnOnYhuaoPWLASQQE7yT6s9dQdO5uxuLg4ZEu2bdsWskw4BezMcYjRwXyi /eq0RW9bFLevgZ0IXghkREPQhlhWVFTkKQqRfs2aNdKuXbtqXorIUoegxiABEog8ASy0igkkfAf3 228/mTRpEhdqjDxm1kgCJEACSUVAC9j43Y5BAiRAAiRAAqlAgAJ2Eo6yFrGzlZi9d6HHkpKyuF/k ce8ijVmSk52lFqfMcDLJ4X3NIIFIEmjWrJmnupKSEs++34698KNfmXCPYRE2M6P722+/lcMOOyys y7/4hEY0FAAAQABJREFU4guPNzWymO0M7LKyMlm7dq3ABgRiWOfOnd26W7RoIb169VL7sA+ZP3++ 45v/a/+//vprJWCjAERrne2N9sITO9Qk0g8//CBbt24V3KdVq1bOExQ57r25QQIk4CWAhRqnT58u y5YtUydOOukkGT16NL83XkzcIwESIAES8CEAARu/l2G9EQYJkAAJkAAJpAIBCthJPMoQtzKdX2wy nIxsiGaw44C4Ver4Y0OYipeFHpFhneVki+c4WddoZ2ZGunpsOpRYlsRDx65FkQA+V7AR0RnIyGj+ +OOP5ZhjjvG9K8TbSHlC4waw1di0aZN7r48++ihsAfvTTz91r8MGFngzA2L0008/7R7CwoumgO2e cDZgE4JFNt944w33sLnAJcTngoIC9xyyRE8//XR3397Avy2LFy/2COyDBg1SYrZdlvskkOoEzIUa seDtJZdcIhCwGSRAAiRAAiQQDgH8LounCpGBXVhYWO13wnDqYBkSIAESIAESSCQCTG9NpNGqRVsh 1kHIzs7KlH3ycp1szYbSyHnlOb/0wKZD23PUouo6XbI32zrDaUeO0548t03IvobNAsXrOuHlxSEI tG/f3lMCmc324oi6gC3K6uO1fbcFZdz3+eefF9saxKwfIvrLL79crY0HHXSQWUxlbpqLUkKkh4gd KGxh3vQH79q1q+cy1LN582bPMXPn1Vdf9YjXEMCRic0gARL4lQC+57ALueOOOwTe81io8a677qJ4 /SsibpEACZAACYRJgDYiYYJiMRIgARIggaQgwAzspBjG8DuR5WQ441WRU+lkY5erbGy8w4dXv6KV mQ0hHa/09AZOlnWGI6D/YhXibDOSjwCygV977bVadwwZ0bZfda0rsy488cQT1cKG2iIDotKsWbOk f//+sv/++6vSsMyAaGyLvFZVNd6FXch///tfNwMcFcCiZMaMGdKmTRs5+OCDVZY2xGdkasOS46ef flLfT/NmyNo87rjjzENqu2XLlvK///3PPf7WW2/JCSecILYgDS9sCPdmQEzT0b17d1m+fLknC/vF F1+UI488Uo499lhdTInqr7/+uierHCft+7kXcIMEUpQAJoCwUCO85jFJe8455wieUsDPRQYJkAAJ kAAJ1JSAThT4+eefXQu4mtbB8iRAAiRAAiSQKASoHCbKSEW4nbAVychNl1zHVqTSEa9hK1KOV3mF VDhi3h5n0Uf1P7X2o7P1yxqQEPUChc6aboACzh/nzv+xod7hZZ3pZIFnOb7WWc57RnqG80e7KoBC jCQkAFEYXsy1Dfg3R0vAhmB08skny5IlS9zmQcxesGCB8n5GFrPpDe0WitDGGWecofynze8TJpAg VOMVKvBd6927t28x9Ou5555zBW/U+8EHH8iHH37oTBplq2uQ9W1nfCP72hSwUbBPnz4C0dqMzz77 TD7//HO3Lj9OTZs2ld/85jfmZdwmgZQmgCc5kHmN7x5shMaNG8dJnpT+RLDzJEACJFB3AjoDGwI2 gwRIgARIgASSnQAF7GQf4RD9gxCmxWxHzValyysqlUc2hOzKSicz23lXorajXWN/D7K1HSFbi28Q pxs4LwjSe+tzth2BHPYkyn/bEQMzHF9rLXCHaBJPk0BMCHTq1EmKi4uVsGveEEK2zszWx7HwYyQX ckTGzMCBA2XhwoWeBR31/YK9Q1wfMGBAQHsOeFvDq9rOfodgrX2/7frhPY9MUDswidC3b18l9JtM 8N33E65xPRaVHDx4sF0V90kgJQnAl/Thhx92F2o8+uijZezYsfQqTclPAztNAiRAApElQAE7sjxZ GwmQAAmQQHwToIAd3+NTL63LcITn9HTH3uOXbOu9b3szr9V/92562+YkU/+aT713Z+++zsT2Fude 8hGAd3kkw64PEyB60iTUZIh9PtAj+kcccYTKhnzvvfdk9+7d1ZqPeuBZDa9peDzrMH2m9bGavkMc vvDCCwX3hqUAFkEMFljotGPHjnL88cerxU6DlW3btq2cd9558vbbb8u2bdsCFkU/DjjgAJVpHYhR hw4d1GOpixYtkg0bNrhjYFcKERw8A2Ve2/VHgqHdBu6TQDwRWLFihTz00ENq8gtPP4wcOVJ69eoV T01kW0iABEiABBKYQOvWrVXr169fn8C9YNNJgARIgARIIDwCDRxByE+ODO/qOC4FKwxkCTNIIFUJ YOFORvgEIPRCSMY7xCYI1xCZYxU7duwQ/AGCTO+CggJlZQJbD9hx1MVORVu5rFu3Tq1Sj8UVDzzw QGnfvn2tvHch9K/+ZUFHTDLA5qVVq1YBM8JjxY/3IYF4IQDbnnnz5rk2Qe3atZOrr746pv+exAsL tiP1CIwaNUp1Gus6MEiABKJLAE/5jBkzRv0Odv/990f3ZqydBEiABEiABOqZADOw63kAeHsSIIH4 IABfWrzqKyBU4xXpgMiMLGq8IhGwKOnWrVskqmIdJJB0BLBQI7KuV65cqfrWr18/GTZsmPNUU2Sf UEk6cOwQCZAACZBAjQnk5eVJbm6uWvAbk6f20241rpAXkAAJkAAJkEAcE6CAHceDw6aRAAmQAAmQ AAkkBoGlS5fK9OnT1UKNjRs3lgkTJsjhhx+eGI1nK0kgQgSwGDBFtAjBZDUkEAYB+GBj0fStW7eK 9sQO4zIWIQESIAESIIGEI0ABO+GGjA0mARIgARIgARKIFwJY0BTCdX5+vmpSjx491CPdTZo0iZcm sh0kEDMC1113XczuxRuRAAmIEq0hYP/8888UsPmBIAESIAESSGoCFLCTenjZORIgARIgARIggWgR +O6772TatGkC6xAsZDpixAjp27dvtG7HekmABEiABEjAQ0BnXUPAZpAACZAACZBAMhOggJ3Mo8u+ kQAJkAAJkAAJRJyAvVBj69at1UKNbdq0ifi9WCEJkAAJkAAJBCKAnz8ILATOIAESIAESIIFkJkAB O5lHl30jARIgARIgARKIKIFt27bJ1KlTPQs1DhkyRGVgR/RGrIwESIAESIAEQhCggB0CEE+TAAmQ AAkkDQEK2EkzlOwICZAACZAACZBANAksW7ZMWYYUFRUJF2qMJmnWTQIkQAIkEA4BWoiEQ4llSIAE SIAEkoEABexkGEX2gQRIgARIgARIIGoEsFDjrFmzZPHixeoeXbt2lQkTJggXaowaclacoARefPFF adCggQwcODBBe8Bmk0BiEWjevLn6ztEDO7HGja0lARIgARKoOQEK2DVnVucrSkpLpaysXMorKqW8 3Hkvr5CKykqpdF5VVXvU+549e+p8H/wBkZWVKY33yZPGjfZR2zgWzwEWBYVFsmt3gRQ5gsEeh0ck Ij09XdLT0yQtLU0ynO2MzAzJyshwHvnGK1Oys7Mk3TnHIAESIAESIAGTwOrVq2XKlClqoUb8LDn/ /PPlrLPOUoKBWY7bJEACIgsWLFAYKGDz00ACsSGAv20gYm/ZskUKCwslLy8vNjfmXUiABEiABEgg xgQoYEcZeIUjUpeWlUlxCUTrMilzBNq92+VSUVGhxOvyCmw7AnaVI2BX7lFidqSale0I2I0a5UmT Ro1kn7xcyWvY0HnlSkZGelz88Q2hvsp5FRUVSyFehcWyq6BAdjoCdnGxI2BHRr9W4nSaI2BDpIYA sVe41iJ2puRkZyuBH7xycrLVK9MRuBkkQAIkQAKpSQA/n1555RWZM2eOmliGzyiyrtu3b5+aQNhr EiABEiCBuCQAGxEI2HhRwI7LIWKjSIAESIAEIkCACl0EINpVVFVVOaJ1uZQ6mdaFRSVKkN29u1CK HEEW4nUksqvtewbaV+3YukO2btspuTlZ0qxJE2natLHk5eaorOMsJ/sYYi5m72MV4APBvszJPkcm eklpmWzfsdN57ZJChxEy0SMdlc498SoPULHOVgeXRr9krEPoz3GYZWdlO3wa/H/2zgVOrvMs76/2 ftOudnWXbEuJY9mJFRJEgNrQEJBNiW0wNuBEtTHY/OQixSCL0iRQCqQpxeUSWakihai1QTgoFkWO iS0CtimkrZ2mrYDEl1iyY11X0t7vO5fdVb/nk8/67Gj2PrNzzsz/DcOcOXPOd/l/49XMc97zvJEQ /CcZPrshAAEIQCCHBHp7e23Pnj328ssv+1Y3b95s9957r79jJ4fd0BQEIAABCEBg3gR0gfXVV1+1 s2fP2rp16+bdHg1AAAIQgAAEokgAATtHqxJkEqedICuRuqu7x9qdcNw3MOgzrXPUzZyb0fiGhpPu 0WatF9qtzmUZNzUttiVNjU6wrXMibZXPyi5bdMlmIxBs52M5oj4DLhedeCx7FFmlSLiWTUhvb7/1 9A1Yv2Ok4woZ6j/phHQ9upyQrkzthvo6W7Z0iS1tabY6J2xL7JcNyXyYFHKO9A0BCEAAAtMTUKHG L3zhC9bX12d17q6l7du326ZNm6Y/kSMgAAEIQAACBSAgAVvR2tpagN7pEgIQgAAEILAwBBCwc8A5 8K0eHB62M60X7LwTiGUVEtWQWKtMZz1az7f77GKJtcrOrqurceJ2jcvWdpYa1RJsndWI+58P9zTR QVuv3hae/db4S+fl7UTrSxnWSWcHknLi+bD1ONFagnXa2adEOTR22ZjoceJ0q61cttTWrl5hTY2L Lwn9C5ixHmVOjA0CEIBAsRBQTYoDBw5MKNS4bds2a2lpKZYpMg8IQAACEChCArIQUVDIsQgXlylB AAIQgMA4AQTscRRz3+jr67fTZ89ba1uHKzroMo0LnE0825lIgO9zFicDA0NOoZZVhoTqRV7YrpQn tPOHrnSe2YF/dHmZCiKW+/c11zGXVT2iebvn0dFL9iDy/dZDr10e9lte1peeC51tPVs+msM5t7Zt nd22tLnJrly7ylYsQ9CYLUeOhwAEIBBVArrteteuXT57jUKNUV0lxgUBCEAAAtkIBAK2PLAJCEAA AhCAQLESQMCex8rKKqT1fJudd+KmChDmw7t5HsOb9aleeA+L786KOu28qoed9YhsMwJhW2nYPiv7 rQRsCdSX/u+tZ9eGROq4CflTAdN8VHSzo6vHF5fsdM/rr1rrxP0qz2aqc3kPAhCAAASiS+DZZ5+1 xx9/3BVVTtuKFSvsoYcesvXr10d3wIwMAhCAAAQgECKwbNky/4oM7BAUNiEAAQhAoOgIIGDPcUnb O7q8l7QKDy50YcY5DnlOp0m4jVvG9JwmOsOTdJGi3/l3qzimfLyvWLPS+WQ3uwx1/lOaIUIOgwAE IBAJAirUuH//fpPnteKGG26wrVu3uuK9NZEYH4OAAAQgAAEIzIRAfX291dbWWmdnp6s5NObuki2b yWkcAwEIQAACEIgVAVS3WSyXhFx5W8vj+kJ7l/U665CoeznPYnocOkMC+hzIHqWjK+XXf3AoYauW L/X+4XxhnCFEDoMABCBQQAIvvfSS7dmzZ7xQ4/3332833nhjAUdE1xCAAAQgAIG5E1AhxzfeeMPO nz9vQVHHubfGmRCAAAQgAIHoEUDAnuGaKPNWNiEX2jvtrLMNka0GmckzhFekhzkd2xelTCZTlnKP VSuXWePiBl/ksUinzLQgAAEIxJqA/i0/ePCgHTlyxM/jmmuusR07dlCoMdaryuAhAAEIQCAQsFtb WxGw+ThAAAIQgEBREkDAnsGy6gev7CJaXeb1ydPn/K1ZMziNQ0qEgCxkTp+7YOnREW8p0rR4MSJ2 iaw904QABOJDQIUalXV98uRJX7vgjjvusDvvvJNbreOzhIwUAhCAAAQmIRAUcsQHexJA7IYABCAA gdgTQMCeZgklXvf1D9rp1vN2pvXCNEfzdqkS0Oek9VybLwKm4o7NTY1WXl5eqjiYNwQgAIFIEcgs 1Lh9+3bbsGFDpMbIYCAAAQhAAAJzJYCAPVdynAcBCEAAAnEhgIA9zUp19/bZm6daTUUbCQhMRcA5 ilhbR7clk2m75up1tmJZy1SH8x4EIAABCOSZwODgoO3bt49CjXnmTPMQgAAEIFBYAgjYheVP7xCA AAQgkH8CCNhTMO7s7vGWIZ1dPVMcxVsQmEigb2DQjr9x0mVgl/lMbAo7TuTDKwhAAAILQeDYsWO2 e/du6+7uturqatu6dSuFGhcCPH1AAAIQgMCCEwgEbHlgExCAAAQgAIFiJICAPcmq9vT2XxKvnYg9 NjY2yVHshsDlBFTcs995pr/2+gl7z4arbXFDvRezLz+SPRCAAAQgkGsCsnR68skn/UN/j1Wo8WMf +5itWLEi113RHgQgkEHg2muvxVc+gwkvIbAQBJYuXWq1tbV2/vx5/9uVBJqFoE4fEIAABCCwkAQQ sDNo68duwhXlO3mm1ZSBPTIymnEELyEwPQFd9OjtG7DX3zxlG65ebw31tfygmx4bR0AAAhCYF4G2 tjbbtWvXeKFGFWmkUOO8kHIyBGZF4JOf/OSsjudgCEAgNwQkWCsL+9SpU9bZ2em3c9MyrUAAAhCA AASiQQABO7QOEq8lWJ86e97aO7tdQb6R0LtsQmB2BPR56nCfo/q6WrvqitVWV1tjixYtml0jHA0B CEAAAjMi8MILL9j+/ftdHYKkNTc3244dOyjUOCNyHAQBCEAAAsVAIBCw29vbEbCLYUGZAwQgAAEI TCCAgB3CIcG6o6vbzrResFQqHXqHTQjMjcCYE7HPXWj34vXK5UutpqZ6bg1xFgQgAAEIZCWQSCS8 cP3iiy/69zdt2mTbtm2z+vr6rMezEwIQgAAEIFCMBAIfbAnYBAQgAAEIQKDYCCBgv7Wi8sxU8b3v nDxryVSq2NaZ+RSQQCKZstbz7VZZUWErVy6zcneLHwEBCEAAAvMnoEKNe/fuNVmHqFDjfffdZx/8 4Afn3zAtQAACEIAABGJGAAE7ZgvGcCEAAQhAYFYEELAdLlk9DA0n7EJ7p/X1D8wKIAdDYCYEunv7 rK6uxhY3Ntji+rqZnMIxEIAABCAwCQHVGTh8+PB4ocZ169bZzp07KdQ4CS92QwACEIBA8RMIBOzW 1tbinywzhAAEIACBkiOAgO2WXAJ2T++Atw4puU8AE14wAp1dPd5KZPE71y1Yn3QEAQhAoNgIdHV1 2e7du+348eN+arfccott2bLFysvLi22qzAcCsSPw5S9/2df7uP3222M3dgYMgbgTWLNmjZ8CAnbc V5LxQwACEIBANgII2I5KT1+/877uMtmIEBDIF4Gk81Xv7umzru5ea2luylc3tAsBCECgaAkcPXrU W4YMDQ35Qo3yut64cWPRzpeJQSBuBJ566ik/ZATsuK0c4y0GAqtWrfIXkPDALobVZA4QgAAEIJBJ oOQFbInWPT391ulERQIC+SSgTP9+57N+vq3Dmpc0+i+Y+eyPtiEAAQgUCwEVavziF79ozz//vJ8S hRqLZWWZBwQgAAEI5IpAmauzs3TpUuvo6LDBwUGKGecKLO1AAAIQgEAkCJS8gN0/MOQzsFMuO5aA QL4J6HPW0zfghezGxQ357o72IQABCMSewIkTJ+yRRx7xhRorKyvtnnvusZtvvjn282ICEIAABCAA gVwTkA+2BGw96uvrc9087UEAAhCAAAQKRqCkBewxlxGrzGsKNxbs81dyHV90Mx52mYTn2zoNAbvk lp8JQwACsyCgu1aefvppO3TokLf4krenCjWuXbt2Fq1wKAQgAAEIQKB0CCxbtsxPVjYiKnBMQAAC EIAABIqFQEkL2IlE0nqd//WweyYgsFAElIXd3tFl669cY5WVFViJLBR4+oEABGJDoLe31/bs2WMv v/yyH7MKNX7kIx9xfzMrYzMHBgoBCEAAAhBYaALKwFZQyHGhydMfBCAAAQjkm0BJC9hd3T02ODRs yvIiILBQBPR500WTrp5eW7602crLyxeqa/qBAAQgEHkCKtT4hS98wfr6+qyxsdEefPBBCjVGftUY IAQgAAEIRIFAIGCfPXs2CsNhDBCAAAQgAIGcEShZAVsiYpezD5GdAwGBhSYwOjY6XsxRBVcWLVq0 0EOgPwhAAAKRIpBOp+3AgQPjhRqvv/56L143NTVFapwMBgIQgAAEIBBVArLbUsgDm4AABCAAAQgU E4GSFbCHh5M24LKvR0ZGi2k9mUtMCIyOjllbR7dd885Rq+KW+JisGsOEAATyRUCZYrt27fK3PAeF Gm+66SYu7uULOO1CAAIQgEBREggEbHlgExCAAAQgAIFiIlCyAnZnV7fJi5iAQKEIjIyMWE9vvxew 5YVNQAACECg1Arob6rnnnrPHH3/clIFNocZS+wQwXwhAAAIQyCWB+vp6q62ttc7OThsbGzPd6UlA AAIQgAAEioFAyapm3U44TKdHimENmUOMCfT2DVjzkkZfzDHG02DoEIAABGZNILNQ4+bNm+3ee++l UOOsSXICBCAAAQhA4G0C8sE+deqUF7EDT+y332ULAhCAAAQgEE8CJSdgK9tLj/6BQRsZxT4knh/b 4hl1X38/NjbFs5zMBAIQmCGBl156yfbs2eMLNdbV1dn27dtt06ZNMzybwyAAAQhAAAIQmIxAIGC3 trYaAvZklNgPAQhAAAJxI1CSAnYimbRkKuWF7LgtGOMtLgKD3oc97T+LFHIsrrVlNhCAwOUERt2F 44MHD9qRI0f8myrUuG3bNmtpabn8YPZAAAIQgAAEIDBrAoFoLQH7fe9736zP5wQIQAACEIBAFAmU nIA95rKvZdswNnYxiuvBmEqMQNL5sOtiyqjzqKsoLy+x2TNdCECglAioUKOyrk+ePGnl7u/dXXfd ZbfddhuFGkvpQ8BcIQABCEAg7wQo5Jh3xHQAAQhAAAIFIFByAvZFJ1wPDA7Z2MWxAuCmSwhcTmA4 kXQ2IiMI2JejYQ8EIFAkBJ599tnxQo0rVqywhx56yNavX18ks2MaEIAABCAAgegQQMCOzlowEghA AAIQyB2B0hOwXQb20HAC+5DcfYZoaZ4Eksn0JR/s6nk2xOkQgAAEIkZgcHDQ9u3bZ0ePHvUjU6HG u+++22pqaiI2UoYDAQjkgsC1115rZWVluWiKNiAAgTkSCCxE2tvb59gCp0EAAhCAAASiR6DkBGxZ iAwNOQEbC5HofRpLdESJpLMQoaBoia4+04ZA8RI4duyY7d6927q7u41CjcW7zswMAmECn/zkJ8Mv 2YYABApAYOnSpd6eCwG7APDpEgIQgAAE8kag5ATsi07AHnZFHC+6/xEQiAKBlPPAHkHAjsJSMAYI QCAHBHRB7sknn/QP/Zt7zTXX2I4dOyjUmAO2NAEBCEAAAhCYjoDugpCI3dHRYT09PbZkyZLpTuF9 CEAAAhCAQOQJlJyAbU64HhkZdRYikV8bBlgiBFLpERsbxZO9RJabaUKgqAm0tbXZrl27fKHGRYsW 2Z133ukfWAoU9bIzOQhAAAIQiBgB2YhIwG5tbUXAjtjaMBwIQAACEJgbgdITsJ1wfZECjnP7tHBW XgiogOPoGAJ2XuDSKAQgsGAEXnjhBdu/f78l3V1OKtS4fft227Bhw4L1T0cQgAAEIAABCFwioEKO r776qmEjwicCAhCAAASKhUDJCdhKvB5DLCyWz29RzEN3BIzhyV4Ua8kkIFCKBBKJhBeuX3zxRT/9 G264wbZu3UqhxlL8MDBnCEAAAhCIBAEJ2AoE7EgsB4OAAAQgAIEcECg5AVvMsA/JwSeHJnJGQP7X 3BWQM5w0BAEILCABFWrcu3evyTqkurraC9c33njjAo6AriAAgSgR+PKXv+yLx91+++1RGhZjgUDJ EZCFiAIBu+SWnglDAAIQKFoCJSlgF+1qMrFYElCRMy6qxHLpGDQESpaA7mQ6fPjwhEKNH/vYx7x1 SMlCYeIQgIA99dRTngICNh8GCBSWQCBgywebgAAEIAABCBQDAQTsYlhF5gABCEAAAhBYIAJdXV22 e/duO378uM+0pFDjAoGnGwhAAAIQgMAMCaxatcofqVo7BAQgAAEIQKAYCCBgF8MqMgcIQAACEIDA AhBQocZHH33UhoaGrLm52Xbs2EGhxgXgThcQgAAEIACB2RCQrZcuNgeZ2LM5l2MhAAEIQAACUSSA gB3FVWFMEIAABCAAgQgRyCzUuGnTJtu2bZvV19dHaJQMBQIQgAAEIACBgADidUCCZwhAAAIQKAYC CNjFsIrMAQIQgAAEIJAnAidOnLBHHnlkvFDjfffdZx/84Afz1BvNQgACEIAABCAAAQhAAAIQgAAE JhIoOQF7kZt/WVmZqQAVAYEoEChbtMj5yEZhJIwBAhCAwNsEVGD26aeftkOHDtno6KitW7fOdu7c SaHGtxGxBQEIQAACEIAABCAAAQhAAAILQKDkBGwphVVVlZZMJs39NicgUHAClZUV/qJKwQfCACAA AQi8RUCFGvft22cvv/yy33PLLbfYli1brLy8HEYQgAAEIAABCEAAAhCAAAQgAIEFJVByArYyXWuq Ky2VTNlF9z8CAoUmUOkuqCAKFXoV6B8CEAgIHD161Pbu3TteqFFe1xs3bgze5hkCEIAABCAAAQhA AAIQgAAEILCgBEpOwC5bVGYNdXXWPzBkNoqAvaCfNjrLSqDWVQmvqCCrMSscdkIAAgtGIJ1O24ED B+z555/3fVKoccHQ0xEEIAABCEAAAhCAAAQgAAEITEGg9ARs53/d0rzELnR0OU9PfLCn+Gzw1gIR aGpc7O4KqF6g3ugGAhCAwOUEzp49a7t27bLW1larrKy0e+65x26++ebLD2QPBCAAAQhAAAIQgAAE IAABCEBggQmUnoBdXmZLly6x8jfKLL3AsOkOApkEVMCxqbHBqquqMt/iNQQgAIG8E1Chxueee84e f/xxUwb2mjVrfKHGtWvX5r1vOoAABCAAAQhAAAIQgAAEIAABCMyEQMkJ2M4C26pddtnSliXW1t5l 6ZGRmXDiGAjkhcBSdzdAXU2NK+KoTyYBAQhAYOEI9Pb22p49eyYUavzIRz7iM7AXbhT0BAEIQAAC EIAABCAAAQhAAAIQmJpA6QnYLuN1kXusXb3S+WAPWrofAXvqjwjv5otAmbsbYM3qFVZTU+U/k/nq h3YhAAEIZBJ46aWXvHjd19dnjY2N9uCDD1KoMRMSryEAAQhAAAIQgAAEIAABCEAgEgRKTsAOqDc3 NdqylmZLpdKWSKaC3TxDYEEIlDkv9uVLW2xpc5Mr4Fiy/xkuCGs6gQAE3iYwOjpqBw8etCNHjvid 119/vRevm5qa3j6ILQhAAAIQgAAEIAABCEAAAhCAQIQIlKxyVu6yX9e67NdkKmUX2jttZGQ0QsvC UIqZgMTrxsX19q53XGlVVZVkXxfzYjM3CESIgAo1yjLk5MmT44Uab7rpJv4GRWiNGAoE4k7g9ttv 529K3BeR8UMAAhCAAAQgAIEIEljkCjhdjOC45j2kdHrExmYwtY7Objt55py1u+exsbF590sDEJiK gOxrJF5fve4KW7Vy+VSHzvu9aieOExCAAARE4Nlnn6VQIx8FCEAAAhCAAAQgAAEIQAACEIglgZLN wA5Wa9nS5kuZIk7svtDRFezmGQJ5IdDYUG/vuCr/4nVeBk+jEIBA7AgMDg7avn377OjRo37smzdv tnvvvZdCjbFbSQYMAQhAAAIQgAAEIAABCECgdAmUvICtpV/i/LCvfkeZs3OostOt50v308DM80ZA mdcrlrXYVVessuYleM3mDTQNQwAC4wRUqFHidXd3ty/U+MADD9imTZvG32cDAhCAAAQgAAEIQAAC EIAABCAQBwIlbyESLJIKWw0nktbXP2CtF9qts6vXtI+AwHwJqFDjqhXLnHDdaHW1NQtWtBELkfmu HOdDIJ4EKNQYz3Vj1BCAAAQgAAEIQAACEIAABCCQnQACdoiL7MBHR8es391yPTDgHoPD1u+eJWyn R0Zs1BV6HMUnO0SMzTCBMpdlXV5RbpUVFVZTXWUNzi6koa7OFjfUue06q6pc2IKNCNjh1WEbAqVB oK2tzXbt2uULNZaXl9tdd91lt912G0XVSmP5mSUEIAABCEAAAhCAAAQgAIGiJICAPcmyKoMtkUzZ 0PCwJd3zyFviNYUeJwHGbi8QSTCqcI8qV0CxrrbWamuqrby8rCDiEQI2H0oIlBaBF154wfbv3+/+ zUraihUr7KGHHrL169eXFgRmCwEIFJTAww8/bGVlZfbxj3+8oOOg88sJJFPpy3eyBwIQKDgBfrMV fAkYAAQgEBMCeGBPslASIuvrav1jkkPYDQEIQAACECg4ARVqfPTRR+3FF1/0Y1GhxrvvvttqamoK PjYGAAEIlBaB1157rbQmzGwhAAEIQAACEIAABBaEAAL2gmCmEwhAAAIQgEDuCRw7dsx2797tCzXW Ocui7du3U6gx95hpEQIQgAAEIAABCEAAAhCAAAQKSAABu4Dw6RoCEIAABCAwFwKyszp8+LA9+eST pvoN11xzje3YscNaWlrm0hznQAACEIAABCAAAQhAAAIQgAAEIksAATuyS8PAIAABCEAAApcT6Orq 8lnXx48fdx77lwo13nrrrd539vKj2QMBCEAAAhCAAAQgAAEIQAACEIg3AQTseK8fo4cABCAAgRIi oEKN8rseGhqiUGMJrTtThQAEIAABCEAAAhCAAAQgUMoEELBLefWZOwQgAAEIxIJAIpGw/fv3jxdq vOGGG2zr1q0UaozF6jFICEAAAhCAAAQgAAEIQAACEJgPAQTs+dDjXAhAAAIQgECeCZw4ccIeeeQR a2trs+rqai9c33jjjXnuleYhAAEIQAACEIAABCAAAQhAAALRIICAHY11YBQQgAAEIACBCQRUnPHp p5+2Q4cO2ejoqC/U+LGPfcxbh0w4kBcQgAAEIAABCEAAAhCAAAQgAIEiJoCAXcSLy9QgAAEIQCCe BFSocd++ffbyyy/bokWL7M477/SPsrKyeE6IUUMAAhCAAAQgAAEIQAACEIAABOZIAAF7juA4DQIQ gAAEIJAPAkePHrW9e/f6Qo3Nzc22Y8cO27BhQz66ok0IQAACEIAABCAAAQhAAAIQgEDkCSBgR36J GCAEIAABCJQCgXQ6bQcOHLDnn3/eT1eFGu+//36rr68vhekzRwhAAAIQgAAEIAABCEAAAhCAQFYC RStgV1YW7dSyLiQ7IQABCEAgvgTOnj1ru3btstbWVgo1xncZGTkEIAABCEAAAhCAAAQgAAEI5IEA Km8eoNIkBCAAAQhAYCYEVKjxueees8cff9yUgb1u3TrbuXMnhRpnAo9jIAABCEAAAhCAAAQgAAEI QKAkCCBgl8QyM0kIQAACEIgagd7eXtuzZ48v1Kix3XLLLbZlyxYrLy+P2lAZDwQgAAEIQAACEMg5 AV3IV+j50vYiV7zafAFrFbGeTwRtXuri4oQ259v2fMbFuRCAAAQgMDcCCNhz48ZZEIAABCAAgTkT eOmll7x43dfXZyrUuG3bNtu4ceOc2+NECEAAAlEgcPvtt3uRKApjYQwQgED0CUhkTo+MWDKZtkQy aeVlZVZbU+3s1KrmfUF/bGzMkqmUDQ8nbdRtV1dVubZrrLKSRIHofzIYIQQgAIHLCSxy/2hcuux5 +XvsgQAEIAABCEAghwRkE/LEE0/YkSNHfKubNm3y4jWFGnMImaYgAAEIQOAyAslU+rJ97IBAoQiM joxeEpcTSfectotjF23MyRLKuV5Utsjq62r9Y651rdLpERscGvYPtS3BQ1nXZa7tqqpKL5LX5EAk zwW/ajceAgIQgAAEpidABvb0jDgCAhCAAAQgMG8C4UKNlZWVds8999jNN98873ZpAAIQgAAEIAAB CMSBwMioE66TKUs44TrlROZR93rMCcxB+K3RizY0nHBic5lVVJTP+q4O5eclXB9qY3R0LGjaW5S4 RGwbc/skcA+7MdRWu2zvGpft7frCVmQcFRsQgAAEIkkAATuSy8KgIAABCECgmAg8++yzEwo1Pvjg g7Z27dpimiJzgQAEIAABCEAAAlkJKLs6EK6VcS0BeaobwUeUoe1EaGUny05kNqH2ZUeiNrKFxjLm +tf7vh93d1ydsy1RZrZEcwICEIAABKJJAAE7muvCqCAAAQhAoAgIDA4O2r59++zo0aN+NhRqLIJF ZQoQgAAEIAABCMyIgETqIOt6cChhKdmFuH0zCR0r/2rZiMxUWJbvdSJxqZ/p+tA41IfEdFma1DgR W7Yic8n6nq4v3ocABCAAgfkTQMCeP0NagAAEIAABCFxGQIUaJV53d3dbY2OjKeuaQo2XYWIHBCAA AQhAAAJFSEBictoJw8POykPitexCZhMqvKhM6upUlReWJThPJn1772zncS1BWgUhw9Yh0/WpdmUn knKZ2COjNb7QY9UsRPPp2ud9CEAAAhDIDQEE7NxwpBUIQAACEICAJ6AfaAcPHhwv1Hj99dd78bqp qQlCEIAABIqawMMPP+wzJT/+8Y8X9TyZHAQgMDUBn93sMpsHB4e9F7VezyWUvT0wOOQ9qkdGRnyh x2ztOAdrK68stwFXuDHtjptLSPQeGBh2tiJj1lBf60VzfLHnQpJzIAABCOSHAAJ2frjSKgQgAAEI lCCBtrY227Vrl508edLd8nqpUONNN91EYaAS/CwwZQiUIoHXXnutFKfNnCEAgQwCsuQYdlnXKqQ4 V/FaTarAo2xE9FiI8NnYbszK6K5wftiVzhebgAAEIACBaBBAwI7GOjAKCEAAAhCIOYEXXnjB9u/f 725dTdqaNWts586dFGqM+ZoyfAhAAAIQgAAEZk8gkUpZ0j3mI17PvtfcnZEecf7b7vscAnbumNIS BCAAgfkSQMCeL0HOhwAEIACBkiagQo2PPvqovfjii57D5s2b7d577/UZ2CUNhslDAAIQgAAEYkZA vs3yXr741rO2x5y1hGKRy8gtf+tRVrbIFfur4A6rSdZXHMfmaBsySZMLuluZ31p7AgIQgAAEokMA ATs6a8FIIAABCEAgZgSOHTtmu3fvHi/U+MADD9imTZtiNguGCwEIQAACECgNAqpTkUi67GD3UNE+ X/TPFf5LuWzhtPNslueysobl2Oyftf2WECs/ZP9w7/lnJ2KXLyqzKmczUeVsw/yztquqrNo919bW eMG7NMhOnOUlVhP3xemVxl/mHgQEIAABCESHAAJ2dNaCkUAAAhCAQEwIKLPo8OHD9uSTT/ofthRq jMnCMUwIQAACEChJAhKse/r6rbunz4YTSVeoz4nVzqd5ZPStZ799SbyeDSDvlewysSsqyq2i3D3c c7l7Xem2q2uqrGlxgzUvabI6J2aXUkjQV4Z6Oj0ay2lrHXUhgoAABCAAgegQQMCOzlowEghAAAIQ iAGBrq4un3V9/PhxK3c/UO+66y677bbbuI04BmvHECEAAQhAoPQIDAwOWXtnt11o77TevgFTFnau QpnaaSeG65EZyuJtbKj3hQxXLltqixfXl8x3hcrKCpeFXuUy20dyyjuTcT5el5eX+bEro56AAAQg AIHoEEDAjs5aMBIIQAACEIg4ARVqlN/10NCQrVixwh566CFbv359xEfN8CAAAQhAAAKlSSDhCvGd Pd9m5y902ODQ8IJCkPVIb/+AtyyRPclVZauswQnapRBlziu8prrK27IsNPf58q12466pqS5Z+5f5 8uN8CEAAAvkigICdL7K0CwEIQAACRUMgkUjY/v37JxRqvPvuu90PnNK6JbhoFpSJQAACEIBAURMI fKsvtHVZ67l2ZxuSKNh8k85fW9nfstS4urbW3b1VVrCxLGTHysKWiC3LFlmvxSFUpFOZ41Vu7AQE IAABCESLAH+Zo7UejAYCEIAABCJG4MSJE/bII49YW1ub1dXV2fbt2ynUGLE1YjgQgAAEIACBTAIq yHjy7DmXAZ3MfGvBX0vE7ezusZXLl1pTY8OC91+IDmWhUllV4fy/q21gcGGz3+c637q6Gi+6a+wE BCAAAQhEiwACdrTWg9FAAAIQgEBECChb6JlnnrFDhw55/8ZrrrnGduzYYS0tLREZIcOAAAQgAAEI QCAbAf0b3tXd6zyYU77YcrZjFnpfwonY7V3dJSNgi2/ZojIrc/VC4hKyPllUhngdl/VinBCAQGkR QMAurfVmthCAAAQgMAMCmYUat2zZYrfeeqvphw0BAQhAAAIQgEC0CYyNXbSBgSFnXaEyi9GIkZFR G3RjKpXQRYREMuXqhhTOvmW2rAfdWMucxUtdbQ0e2LOFx/EQgAAE8kwAATvPgGkeAhCAAATiReDo 0aO2d+9eCjXGa9kYLQQgAAEIQCBE4KIrIJg2l34d2lfYzVFnaSJBt1Qi5fjLe3xkZCQ2U9ZYh4cT VuFE7FrqnMRm3RgoBCBQGgQQsEtjnZklBCAAAQhMQ0A/dA8cOGDPP/+8P/KGG26wrVu3UqhxGm68 DQEIQAACEIgaAcnWEUq+9nhUWHJ0bDRqqPIynnRaQnDSkjEU7FMpJ7y7sZc765Oqysq88KFRCEAA AhCYPQEE7Nkz4wwIQAACECgyAirUuGfPHmttbfWFGu+//3678cYbi2yWTAcCEIAABCAAgUIRiE4u eH4JSKhXprkeUbJwmemsNWaNXQJ2ZUWFUdBxpuQ4DgIQgEB+CSBg55cvrUMAAhCAQIQJ6EfW008/ TaHGCK8RQ4MABOJD4Pbbb0fsic9yMVII5IXAyOiYz7xWFnZcQ37liUTKe2FXViKZxHUdGTcEIFBc BPhrXFzryWwgAAEIQGCGBHp7e33W9csvv+wFlzvvvNP0oFDjDAFyGAQgAIEMAj/5kz+ZsYeXEIBA qREYTiQtlWPxWlnQ7v/GL5CVlZX71/IVV8jqXEkJeuQqRkZHbND5YS+pbMhVk7QDAQhAAALzIICA PQ94nAoBCEAAAvEk8NJLL3nxuq+vz5qbm23Hjh22YcOGeE6GUUMAAhCAAAQgAIGIEEg6ATuXhRvL yhZZbW21VVdVWU11tbP2KBsXsiVYy/Ij6XyrE8mEK8CddK/HckJC7SSTSdcWAnZOgNIIBCAAgXkS QMCeJ0BOhwAEIACB+BBQocYnnnjCjhw54getQo3yu66vr4/PJBgpBCAAAQhAAAIQiBgBicnyjh55 Kyt6vsNT1nVNTZU11Ne6YopVEzKww21L4K6prrLq6kqrr6t1IrYTsl0RxiA7O3zsbLaVzD2SHjVl lFe79suUAk5AAAIQgEDBCCBgFww9HUMAAhCAwEISOHv2rO3atcsXaqx2GTxbt26lUONCLgB9QQAC EIAABCAQWwISqEedN/TA0LC3CLnMruOtbGhZb8w3KirKvf90XW2NaXsye7egwOIlbXmRlVVWWnlD mVW5bO0hN06Jz/OJUZeF3dPT7/r3/iUTmlKfla6/xU40L3djDMYy4SBeQAACEIBAzgggYOcMJQ1B AAIQgEBUCTz77LP2+OOPmzKw161bZzt37rQVK1ZEdbiMCwIQgAAEIAABCESGgMRqZVb39Q/6LOv5 ZjdPNTFZhNTX1VidE4YrymcnDEtErqioGBe8JUCnnL3IfCI9Mrkgr0KVEvUbG+ut0vWLiD0f0pwL AQhAYGoCCNhT8+FdCEAAAhCIMYHBwUHbt2+fHT161P+oUJHGO+64w/knlsd4VgwdAhCAQDQJPPzw w144+vjHPx7NATIqCEBgTgQkYEsIHk4kvOf0nBqZ4Um1NTXO87rGC8IzPOWyw5SxXeMsRcbGalzy wkhOizuGOxsdHfNZ3rI6KXeFJcvLsRkJ82EbAhCAQC4JIGDnkiZtQQACEIBAZAioUKPE6+7ubgo1 RmZVGAgEIFDMBF577bVinh5zixMB51+s7Fv3FKmQEKzigMrUjVO27pgbdzKZzrt4XVlZ4Qs2Kpt5 vqFkBXlXyxs7kUjNt7lJz9eaqoik+nJmJ5MexxsQgAAEIDA/AvP/l2F+/XM2BCAAAQhAIKcEdFvr wYMHxws1btq0ybZt20ahxpxSpjEIQAACEIBAtAhISFRGbCqVskHnfzw0PJy3zNu5znzE2U10dvda bU21VTufZvk7x0LIdmxz4W09HTd5XufSikMidn1tbV4FbM1pxNmM6PNHQAACEIBA/gggYOePLS1D AAIQgMACE2hra/OFGk+ePOkL69xzzz128803L/Ao6A4CEIAABCAAgYUicEm4HvVWEf0DQ3ahvdPa OrpcVmz+sm7nOjcJ6//wzVds2bJmW71iuTU21LuCg67woBNaJytUONe+cnmepNmxsfwKtCqKKGFf on6uotxZiSgzWkUY8zl+L17nF0+ukNAOBCAAgdgSQMCO7dIxcAhAAAIQCBN44YUXbP/+/e4W16Qv 1Pjggw/a2rVrw4ewDQEIQAACEIBAkRFIugLNF9o67Oy5NuvtG4h8JuyIyxI/f6HTPxrq62zl8hZb vdKJ2YsbIrsyEmjlJZ3PCITmXPchYVxty0YkX1nS6fRo3trONQ/agwAEIBBXAgjYcV05xg0BCEAA Ap6ACjU++uij9uKLL/rXt9xyi23ZsoVCjXw+IAABCEAAAkVKwHsyuwzrM2cvuGzrTmcXkrBRZ8+R L4EyXxiVkX3yzDmXNd5lS5sbbc3qldbc1Jiv7uberssuzjfbCvleS23Odbg21faiRem8zUFsSMDO 9cLRHgQgAIGJBBCwJ/LgFQQgAAEIxIjAsWPHbPfu3b5QY2NjoynreuPGjTGaAUOFAAQgAAEIFA+B gcFh6+ntcx7UQy7jNWnDyZTzeq40ZRovbWn2lhnzsYhQAUSJ1ecutFt7Z7fvQwX08i2u5muFNG75 Yg+ODnvv7h6XQd7kMrGvWLPSFjt7EVmLzDXEqn9wyLqc53b/wKC7Qy1lZYvKvE1HXV2NtTQ3WX1d nesjGoUHy5zQnAf52reptgkIQAACEIg3AQTseK8fo4cABCBQkgT0o+zw4cP25JNP+h+tKtS4detW a2pqKkkeTBoCEIAABCBQSAL6d1m+0x2dPdbXP+D9p9OusJ3E2Qonwvb1D3p7jyVNi12mcZO3y5it OJtwFmFd3X2uj27r7u11InmikFPOad8SslPOoiOVHhgX5ZcvbbZl7iFf6NkWehTvzu4edzGh3wac iC12Wgu1oyKJuqjQ7d6Tfckyd2FBPtyFDOnLlzzA8yM0a975abmQ1OgbAhCAQGkRQMAurfVmthCA AARiT0CFGj/3uc/Z8ePHKdQY+9VkAhCAAAQgUAwElOV7+ux5J4r2eaE0PKeR0VEbcVYZssuQuK1s 4GXNS2zJkkafmT2dODvqPKN1TmdXjxfJe10bEsyLNZRRrkKUyjQfdg8VfGxsaHDfeab+6S4mOlcZ 8LqQIAF72GXBh7PTta3ilnooO1t1Q7Rv5fJlOS2eOJe1yacJh+aIxcdcVoVzIAABCESHwNT/CkZn nIwEAhCAAAQgYOFCjWvWrLGdO3dSqJHPBQQgAAEIQKBABCQMBj7O2cTrzGElnI3FuQsdPvt31fKl PsN4cUOdywiueisD9+0z1LayhtWuLEM6nIAtG4xSCYn2ErAHnB2Lijw2L2ny2diZ8xentCtkKUG6 22Wot55vs0F3nvZPFXpfWdi6gFBVWWlLXbZ3oaw2NFStdT5kZlEY9Rc8puYxFavp3lMGOQEBCEAA AvklgICdX760DgEIQAACOSCQSCRs//7944UaN2/ebPfee6/PwM5B8zQBAQhAAAIQgMAsCUgATbmM 35OnW73PsgTImYb8sXWexOyrrlxly52NRV1drS+2JxF1bEyWGilvGfL6iVM26Ly1pxNkZ9p3nI5T 9roKPMpbXL7Ya5yQXeMsRYIYde/rokB3T6+dOdfmnvuCt2b0LKayGTnh1qK2tsZnxGc90Qm0Errz uQYjznImL+27OUrgl0ier5AdDiJ2vujSLgQgAIFLBBCw+SRAAAIQgECkCZw4ccIeeeQRk3WICjU+ 8MADJs9rAgIQgAAEIACBwhCQ0Jh2ns3yvT7TeuGtDNfZjUV6oqwsjr9xyi5c6LQr166yFctavB+z hPHT587bmyfPmixESj2U5f7GiTPeS/y6a9b7C/gXXVZxp6xbHH/5gs9V/FV2skTsN75z2ja+5xqX Ce/8ojPUWJ+lXVXhMuDTeVuKVMoJ2O7CheaR2f9cO1VbuhiSz3FrbCqEmasxz3WunAcBCECg2Akg YBf7CjM/CEAAAjElIC/HZ555xg4dOuR+vI7a9ddfbw8++CCFGmO6ngwbAhCAAASKh4D+XZa1x7eP vzkn8TqTRJ+zy3jVtXW+rcOWNC52tiRD1uZEWYmPxCUCylCWN7asRdauXuG9riU8q/jjXMXrgK0K brZ3dblM7DN21RVrfKHH4L2FetYcVGyyzInBKvyZi9DFD4n/+Q4v+ue7E9qHAAQgUOIEELBL/APA 9CEAAQhEkUCX+xG1e/duX6hRt2Vu2bLFbrvtNrJborhYjAkCEIAABEqKgC4wyzv59e+cMgmfuYqg XQm0o064Rry+nKwYSZA9ceqsjThxVhcSchUSwt881Wp1tXW2rGXJhKKRsnWRT3a+M5kHhxIuA78q JwK2BHHZ2gy5NvMdFeUV7jtqWb67oX0IQAACJU0AAbukl5/JQwACEIgegaNHj9revXvdD44hU6FG ZV2vX78+egNlRBCAAAQgAIESJNDbN+BtQ/oHB3M+ewm0KfcgJicgYTbpLFbyEbJuefPkGVdUs9Ka XCa8rDEUsseorq7yXuRjrv98hbLMh50/enlZ2QQBfS79yeJGBTDlI57vqHK8lIVNQAACEIBA/ggg YOePLS1DAAIQgMAsCKjAzoEDB+z555/3Z1GocRbwOBQCEIBABAh84hOf4E6ZCKxDPocwNDzsrD26 rLOrhwzpfIIuYNu9/e4CxbkLtsiJyM1Ni/1ILnlgV9rihjobGk7mNPM+PFVp48Ou/YqKcm8lIiF7 tiGBX+K1MtVVLDSfoXHW1dR4wR8P7HySpm0IQAACZgjYfAogAAEIQKDgBFSocc+ePdba6m5drauz 7du3U6ix4KvCACAAAQjMjsB11103uxM4OlYElB3b3tljbe1dznc5PxnAsQJSpIOVAKzinDXV1Vbj Motra2v8hSmJyQ31dS4ru9wJ2KPuAsboBO9t5WXLc1risdqYa+hzJtsPFamsdnYilZUVLrt5ZkK2 ClIqi1wiuMTrXNjQKLvaF2kMT8hlpItHRUWFE7CrvdiOgB0GxDYEIACB3BNAwM49U1qEAAQgAIEZ EtAPnKeffnq8UOM111xjO3bssJaWlhm2wGEQgAAEIAABCOSbgP69lu/1BVdkUR7VRHETkAjc1tHp ROwqW7Nqhc+IlkBb7jKOG1wWtj4PEoslMgchyVrCdm/vgPOenp83ejKZ8kJ4dXXaap1ALP9tLyI7 0VhGHYFYrHGo3zEnnMt+JukurAwPJ7yInQvxWn0q61wietggRH7XEtWxDQlWn2cIQAAC+SeAgJ1/ xvQAAQhAAAJZCPT29vqs65dfftln86hQ46233jrjLJssTbILAhCAAAQgAIE8EJCgeKb1vBOx+/LQ Ok1GkUBf/6BdaO/0WdfNSxrHRWONVQJyhcvEdl/gJgxdQvOwy55WcUmJy/MJCdKXMqlTTsSu8sUd g2xsFZVUyI/bC9dOcB9x4nXCfU5zIVyrbc2x0s2nvq5WLwkIQAACECgwAQTsAi8A3UMAAhAoRQIv vfSSF6/7+vpsxYoV9tBDD9n69etLEQVzhgAEIAABCESWQCBCnjl7wXpcBrYsIojSIdDV3euzjxc3 1Pvnmcy8prbae2TLSiQXoc+gfLf1CMJnYzuBecRlfOcrlGFd47K/CQhAAAIQiAYBBOxorAOjgAAE IFASBFSo8YknnrAjR474+d5www22detW9wOhpiTmzyQhAAEIQAACcSPQPzBkrW3tNpzngnhx41IK 45VNSG/fgJ270G5XXbF6RlOudd7Z8p/OlYCdrdOFuJCiAo31zv+bgPLCRAMAAEAASURBVAAEIACB aBBAwI7GOjAKCEAAAkVP4OzZs7Zr167xQo3333+/3XjjjUU/byYIAQhAoFQI3HfffX6qjz32WKlM uejnKaHw9TdPeUGy6CfLBLMSGE4krPV8uy1b2uKtPAL/6awHu53yhZZvtbKj5aUdx5BVSZ0Tr/G4 juPqMWYIQKBYCSBgF+vKMi8IQAACESLw7LPP2uOPP+6ycdJGocYILQxDgQAEIAABCExCQIX42ju7 rbun10acpzFRmgTkKT0wOGQnz7Tahnde5euWTEVCAreKP0rAlhf2QmRLTzWe2b4nexIJ8HpMJ9bP tm2OhwAEIACBuRNAwJ47O86EAAQgAIFpCKhQ4/79++3o0aP+R8Cdd95peshXkIAABCAAAQhAIJoE 5Dusgnhnzl2wVI68jKM5U0Y1EwJpdzGjraPTVq1Yao0NDU7Envp7XLkr7igRWzYiQ8OJmXQRmWOq qiqdtV2VyUKEgAAEIACB6BBAwI7OWjASCEAAAkVFIFyosbm52Xbs2GEbNmwoqjkyGQhAAAIQgEAx EpD1Q3dPn3V09lhQyLEY58mcZkZAn4HhIWclcq7NatdXOwF7+uKGsuGodQUdvZWIuwMvDiHxWtYh VZWVcRguY4QABCBQUgQQsEtquZksBCAAgfwT0O2iBw8enFCoUX7X9fX1+e+cHiAAAQhAAAIQmBcB iZWyjFDhPsTreaEsqpPH3OdCn4nVK5ebhN7p7qbT+1VVVS6b2Xlhx0TArnWZ19VuzNPNragWlslA AAIQiAkBBOyYLBTDhAAEIBAHAm1tbb5Q48mTJ63aVaHfunUrhRrjsHCMEQIQgAAEIPAWAV2I7h8Y tM7uXphAYAIB2cl0dPU4UbraZypPeDPjhS5+jI2NOf/0kYx3ovtyxBUt1ZgvXizD/zq6y8TIIACB EiWAgF2iC8+0IQABCOSawNe+9jV77LHHLJlM2rp162znzp22YsWKXHdDexCAAAQgAAEI5JFA/8CQ dff2kX2dR8ZxbvpCW7stbWmaVsDWHOWBPTycjM10h5xNSmVFhfO/rnACdmyGzUAhAAEIlAQBBOyS WGYmCQEIQCB/BAYHB23fvn0TCjXecccd01apz9+IaBkCEIAABCAAgbkQUNZsb18/2ddzgVci5ww4 kbe3b8Aa6urc3XZVk846mUw78ToRqwsh+vyreGml88CWnQgBAQhAAALRIYCAHZ21YCQQgAAEYkfg 2LFjtnv3buvu7jYKNcZu+RgwBCAAAQhAYAIBeV/39g9Y2hVxJCCQjYBEXtmINC5umFTAHnU2HIlU 0t2Vl8rWRKT3acyVFeWukGM5yRiRXikGBwEIlBoBBOxSW3HmCwEIQCAHBOQPePjwYXvyySd9Zs2m TZts27ZtFGrMAVuagAAEIAABCBSKQG//oC/geLFQA6DfWBBQlv6gu9jRsqQxa8HDVCplKZeBrcKP cQsJ9Cl3AUeZ2PV1tXEbPuOFAAQgULQEELCLdmmZGAQgAIH8EFChxs997nN2/Phxf4vlPffcYzff fHN+OqNVCEAAAhCAAAQWjMDg0LANJ+LjWZwPMOUu+7baWUiUlZX5R7l7XvSWIfLYxbFxcVMX80s1 vLe1q3mi52w2IiMjo65442hs8SiDPD0Sn+KTsQXNwCEAAQjMggAC9ixgcSgEIACBUifwwgsv2P79 +8cLNT744IO2du3aUsfC/CEAAQhAAAJFQSCdTpeccKeifdVVlVbl/Jyrq9zDPde45/LyskuPsnIn ZKui3yIbHRv1mblDzttZVhPKNE66bF1l7MZZsJ3Lh1fidXoknVXAVhZznMOPP95TiDN+xg4BCEAg KwEE7KxY2AkBCEAAAmECiUTCC9cvvvii333LLbfYli1b8AYMQ2IbAhCAAAQgUAQEJNWWgnYn0Vpi dWNDg/NzrrfF7lHvChPWTFGYMLy8ErHlGd4/MOgeQzY4NGSJhATt+Pk+h+c1022JvGNj2T8p5eWB 6D/T1qJ1nC5eVLhMfAICEIAABKJDAAE7OmvBSCAAAQhEksCJEyfskUceMVmHNDY2mrKuN27cGMmx MigIQAACEIAABOZOoKqywgl3FT6jeO6tRPdMWYFUOHG1yonXK5a12JpVK6yhvnZOF+TramtMD7Uj O5EBJ2Kfa+uw1vPtlkqnbHS0uC1GJFJPJvLq4kDKZbGn06O+Vsp8PhFaM58B77Ty7HK5cuNduP8n QX2+2d/qr8pZyMz0QsZ85sa5EIAABCAwcwII2DNnxZEQgAAESoqAfow988wzdujQIfcjbNRUqHHr 1q3W1NRUUhyYLAQgAAEIQKBUCDS4DOS6mpqiFbBra6rtijWr7Kq1K30dj8Dber7rK7/sxsYGa2io s7WrV9jrb56yto4ukxd0sYa3W3EidbbQRZCG+jonOC9ywv5gtkNmtE/CtS4SNLtikSPOsmRsEgnb uZRbhbv40uOKSw4NJeZ18aDOFW7U2DUHAgIQgAAEokOAv8rRWQtGAgEIQCAyBLq6umz37t3jhRrv vfdeCjVGZnUYCAQgAIFoEvjEJz4xXuwumiNkVNMRaG5usu7efuvtH5h3Jut0fS3k+8oUXukypa9c u9oWN9RPmjk83zFJEJfg+p4NV9vS5iX25qmz3mZkvu1G7fwlTYsdxzpf5HKysYl5ozum0j339Q/6 ZIjJjp1sv/zJdVFAIYF6uqivrbV0asT1NXsbF2WUa061tdU+S3+6vngfAhCAAAQWlsD0/wos7Hjo DQIQgAAECkzg6NGjtnfvXpfBMmRr1qyxnTt3UqixwGtC9xCAAATiQOC6666LwzAZ4xQEZP2wfFmz DQ4PWUdnzxRHxuetpUuabOWKZbZs6RJTBraEynyFBGxvQVFVZiuXL7VKx/P0mfPW2d3jbUby1e9C tlvuss1XO55LXMb5VBnsek9e0hL0JWIPuMzoYecbPlOLD1m9aL2UCT1VP+G5+4KcNVW+oOZMs9/V do3rR1YystBRNv1M+wv3zTYEIAABCOSXAAJ2fvnSOgQgAIHYEEin03bgwAF7/vnn/Zg3b95syryu dD6ABAQgAAEIQAACxU9A4t2SxsXOBmOlXXR+wp3dvbGe9LKWJc4uZLW3oJDv9UIKk+pvqctol+Bb WVluF9q75pSFHKUFkPh/hbNIWdbS7HzEs9uHhMcr3uXl8rCu8sKwBOJkMukKXaYnLQAZnC9+tU78 LnNtzDQWOcsRid4jznt7ZGR4ytNkT6I+aqqrfTHPSonXs+hrysZ5EwIQgAAEck4AATvnSGkQAhCA QPwIvPnmm7Zv3z47c+aML9T4wAMPeM/r+M2EEUMAAhCAAAQgMB8CgfAq2VAZtD29A64YX3oS9+H5 9JTfc5X1u9YVaWxpafJF+fLbW/bWlRHc4vyblXWsjOD2zu4ZZyBnb7Ewe/U5kC90c1OjL3xZV1cz q4sBErL1uSp3ayIxvyKRcoUu055JtmKXPpO6umpOVi/BuWo/7XyzM0PCtcRqFWqsdn3orgOyrjMp 8RoCEIBA9AggYEdvTRgRBCAAgQUjoB9UKtT4xBNP+Kyg66+/3h588EEKNS7YCtARBCAAAQhAIHoE lJUqCwxlwJ6/0OE9sQcHh73oOFMLiELOSoLrCud5vdw9JFQWMpS13OJsTMQtmUpZb99AIYczq74l 9Kqop3yolc0uprOx9MjsTNnota493d2niyKJpBOyk2kbdYXDx1zGvxKgdYwKKSqTei4Z8zqnprrS tVdrQ8PD7vutK/3o2Euk1sNndjubEWWQqy8CAhCAAATiQWCR+2N+MR5DZZQQgAAEIJBLAr29vd7r +lvf+pb3g7zrrrvstttum9OPhVyOi7YgAAEIQAACEMgtAVk2zCd6evvsnBOyu3p6nSiY8JmzUf0Z KQFT2cLf/d53O//lai9azmfuuTpXGcEdLgP7lde+4y8E5KrdXLejzHsJ18pObnJ2MqvchYwWJ17L kzrXMeaE65HRUUu5z6f4yMJD/eqiw3y9yiWKq11Zlkgc91nXLttaGdoSsqMSygAnZkZAFz0uXLhg 3d3dvlZPXV2dT7pZvny5u9hWO7NGOAoCEIgtAQTs2C4dA4cABCAwdwLf/OY3vWWIRGwValTW9fr1 6+feIGcWFYGRkRH7nu/5HkskEn5eysw/fPjwrOb427/923bw4MHxc/7yL//Srr322vHXcd3Qj6f3 v//9Try5/Lbkuc7pU5/6lH30ox+d6+kTzvuHf/iHCW099thjduONN044hhcQyBeB++67zzetzx0R LQLzFbCD2fT1D1jr+Xbn59xpwwkJg2PBW5F5VubuuivW2DvXXxGZMQUDSbqM4xOnz9qbp1ojyU7C bo3LTF69apkrfLnUGhsaIiX2BhyL6TlOAnZra6u/c3Om/HUxSQ9djFDmfmNjo1199dWm75Wzia9/ /et2/PhxVwR0cl9zZfWvXLnSPvShD7kM/rrZNM+xEIBATAhgIRKThWKYEIAABHJBQOLboUOHxr98 UqgxF1SLr41vf/vbposcQbz3ve8NNmf8/JWvfMWOHTs2fvyKFSvGt+O88corr5geuYzFixfnrLkX X3xxAveWlpactU1DEIAABBY31Ns176y1K9astPNtHXbqzHlnA5GMFBhZVKx1hQajGLKvuOqK1T6b XRcAopLFLl/oemfbceWaVV64Vgb0IidmKxubgEBAQIkNs/nMBseO+iz7lM+aPn/+vP2///f/7Kab bvJJNEHb2Z7V31NPPWVKuJku9BtHtXy++MUv2saNG+2GG26Y7hTehwAEYkYAATtmC8ZwIQABCMyV gL7Uffazn/Vf7pSZsH37dgo1zhVmkZ+nLN5wfN/3fV/45bTbQ0NDdvTo0fHjNmzYYM3NzeOv47wR nleu5rFp06ZcNWX/5//8nwltXXPNNRNe8wICEIDAfAgE2ZR1zhv7yrWrvCeyChO2nmuzQZcdKauG QobE66XO7kJCcVRD4vC6K9fYd06c8Z7YhRynPKBlE7LGCf4qNqmxyWpDobUmIJAPAhKmjxw5Yj/z Mz8zad0d/W756le/Ous7FSSayx5RovkP/uAP5mP4tAkBCBSIAAJ2gcDTLQQgAIGFJPDss8/a448/ 7gvm6La9bdu2OT9DMjMXcg3i1Nc3vvGNCcOVnchsIpy9rfOKycLiAx/4gO3Zs2dSHF/72tf8XQ7B AT/yIz9id955Z/Dysmfd8rp69erL9s91h/oP4uabb563h2jQFs8QgAAEwgRkNVHtrCYkeOohi4CT p1ttcGjyW/zD5+dru76uxovqURVfNS6xW+XsOc5faC94UUzZOixxArYKdsbJyiJfnx/anR0BfX7e 8Y53THqSsqIHBgZ85rWSG8Ih+yEVkv+X//JfhnePbz/33HOXidfVrrjs+vXrbcmSJV74HhwctK6u Ljt9+rTvZ/xkt6G75a644gp/fHg/2xCAQHwJIGDHd+0YOQQgAIFpCeiL3R/90R/Z//2//9f/uNyy ZQuFGqelxgEvvPDCBAjf/d3fPeH1dC90a2g4vvd7vzf8MtbbslOZylJFWUWy6QniZ3/2Z+3nf/7n g5d5fVZRo+985zvjffyzf/bPxrfZgAAEIJAPAhJka5zntMTPQhfGk5DeuLjBFXCMfjG3GifEtTQ3 eR/xhPPFLlRcvDjmrEJc4cQIZ6wXig39Tk+gxt3x8MM//MPTH+iOUPHFv/7rvx6vr6KTJG63tbVZ ps2crOxSqYn/XXz/93+/ve9975u0rxMnTpgSdgLbEh0oWzUJ3gQEIFAcBKJTfrc4eDILCEAAApEh oCzYT3ziE1681hfDT3/60/bjP/7j3BIamRWK5kBUICdsk/HOd75z1tn6//t//+8Jk8ulRcaEhiP4 opBzz7R+mW3mfARxMiQIQCAmBFSccHRstKCjrautNnl0Kxs8yiHRX4/ly1q8+F/IsY6MjPq78wo5 BvouDQIqsPjTP/3Tl13okt1HZrz++usTdl111VVTitc6WEJ1pu91f39/TotuTxgULyAAgQUnQAb2 giOnQwhAAAL5JSDPty996UsTCjXefffd7kdSTX47pvWiIJD5Q+IHfuAHZj2v//W//teEc77ru75r wuvMF/rMnjt3zvuz19fX+9tRGxoaMg+b0eukKyZ26tQp6+zstHXr1uXUnmMmA/j7v//7CYe9+93v nvB6Ji+UpfTmm2/a2rVr/e2vEjpmEpmZ77m8cNDe3m4nT5403b4rX+1c/T1Ru1ovZW6+613vslwW tJwJM46BAARyQyDhsiXHRsdy09gcW9HfpfoYZF8H02t0/87Vuuz1vv7By6wSgmPy/Tzm/IJH3L/B +nc46sJ/vlnQfv4JqAbP8uXLfTZ20Fu2Ao3KzA7HddddF3456baKN6oWiKxLgtB3DCVjEBCAQPwJ kIEd/zVkBhCAAATGCUj4+s3f/E0vXutL4q/+6q/aL/zCL+RMbBrviI2iJZApguqWzdmEvAjDNhYS UfVZzBbKGP6xH/sxk4filVde6TNnJHZLxFSmzq/92q+ZbDGmC/1QeeKJJ0zFJiVgqGiksnDWrFlj jY2N9pM/+ZP22muvTdfMvN+XCK9bYYOQ+C+P6+lC43/kkUfsJ37iJ/y8V61a5cevjKOmpiZ/e26m rUu2NsPZ37rrQkyzxe/8zu+YvPDDD3lFZoYyoHbu3OkZqj1ZwWh9amtr7dprr7Xdu3d70SPzvPBr ZfMH/ejWX81Vt/fqIpvWS+3KV1yfE63Vj/7oj5puHSYgAIF4EUgm0+7vQWEFbInBdTG6WF9RUW71 7t/H6uqqgi621i2ZelvwK+hg6LzoCWR+LxoZGZl2ztlE7slOkkCu0MV/fb/UnYUEBCBQHATIwC6O dWQWEIAABOx//s//af/1v/5XUwaqMiR37Ngxa+sHMEJgvgUcM20sJvNhlqWNLrZMFhKCH374Yfvc 5z7nK9VPVkn++PHjXgQPi+bhNnX76FNPPeUfn/3sZ+2XfumXwm/ndDtsvaKGZ1K8UpnWKmD09a9/ PetYNP6/+7u/M4nh//pf/2uT+Kws6GzxP/7H/xjfnS1zXsKxLgr8p//0n8aP08bhw4ftPe95z/g+ Haf1+a3f+q3xfZkbx44ds4ceesj+/M//3P70T/900iJO8p8MxHEVU+ro6PAX1f7qr/4qs0n/Wv6V ErYlYusCBAEBCMSDQCqVLFgWsQhVOqGqxgnBVTHzcq6vq7UaVwxzeDhRsIWW9Ut6RAI2d+oVbBFK qGPdeRUOXbzODCUy9PX1je9WLR9ZhOii/nRx2223TXcI70MAAjElQAZ2TBeOYUMAAhAICKhQ4969 e/1DBU/uvPNOLzy1tLQEh/AMgRkTyMz0nc7+I7Nh/cgIR7YCjk8++eRl4rUycSXk/ot/8S/Cp5sE 3J/6qZ+yzB88Okhjlc9zpnitPu+66y6f1Rtu7Jd/+ZfHrXXC+3O1nZm9nm3u4b6efvpp7+mYKV7r VleNP5P9H/7hH3pRP9xGsH327NkJ2d8SgcMxNjZmmn9YvNYPRAnMd9xxx/ih+hvycz/3c5eJ11of eejfeuutE2w+ZBfzkY98ZNJMbN3KG4R+pGpcYfFa7eoRDq35b//2b4d3sQ0BCEScgLJ4ZUdRqKh1 /teFzmSey9yjILq7Oo7ub3jh1m4u3DgnngT+8R//0SfahEevu84yI7N4uCxudKfdl7/8ZVOxRgIC EChNAgjYpbnuzBoCECgSArJFUKFGZV9LBFLGZLYCKUUyXaaRZwKy61BmbRASUCez/wiOyXwO21jo vWw+zL/7u787fprsPpS5fP78efviF79oX/3qV01irMTSIJSN/fu///vBS/8sQVv2IxI7g/iZn/kZ 79OsLHL90JGg/Nxzz00QSH/xF3/RhoaGglNy+pwpRGf+AAt3pjlJsA+P/5577vHjf+ONN/z4/+mf /skkcod9oSXsvvrqq+Gm/HZm9rdsOYLQ7blbt261PXv2BLu8H6TOycyQV9a7MqqDUN8HDhzwHuV/ +Zd/6cej9ZE1URASqR999NHg5YTncFa4MrHPnDnj3//1X/91L7jL9khrn+mbnvl6QqO8gAAEIkdg xAnYunujUFFZXmEVES/emI2NMsaVPV7I0LrpIicBgXwR0PeQZ555xjLv8pPvunyrM0N3YDU3N2fu 9t8b/uZv/sb279/vrcj0HUN3dhEQgEBpECjsv5alwZhZQgACEMg5Af3Q0G3/ymTVDw/5/UqgylVh tZwPmAZjQUCCaTiy2VCE38+2nSk8ZhYxlEgezsr91Kc+ZZlCr364SMyWrUUgeIaFUPUr+4qw+Cuv 5s985jOXDWnz5s32x3/8x3bLLbf499TeX/zFX9jP/uzPXnbsfHbov0NdSApCwu9URYMk4IbHv337 dpPFSWYRLWU8S4wPxq/2lUWtOYUjM/s7YKqMas310KFD44drXZXFtGzZsvF92njppZcmZF5rDrKE ufrqqyccp/1f+MIX7Jvf/Ob4Wv7Gb/yG/xsUPjDTD13v6VwVugzGp33yqZTdyu233+6tXrQvsB3R NgEBCESXgP72uf8rqHgtOuXOTzrz72d0qb09sqrKSufTW/72jgJsjbkU7EIX4CzAtOkyBwR0F+if /dmfZW1JfxuUOS3xejKfa11El091ttDdd2o7W9KB2pbFiB66qK9C0LrLS99X9P1CrwkIQKD4CPBf dvGtKTOCAASKnEBnZ6f3p5WAXeV8Ex988EHv64t4XeQLvwDTy7T/yLShmG4IEoenK2Ioj/Zw6HOc LSR0hq0tlN2sH0IKCcXhH0w333yz/d7v/V62Zvy+D3/4wxMywfMhjsrGJCxIy7N7sh9QylKXX30Q sgtRdvRk4ovG/8//+T8PDh8Xjcd3uI1w9reE86VLl1oikfBWJGHxWlnqyl7KFK/Vlnzzw/GVr3zl MvE6eF9z08WHILTumUWWMv3QdayypsLidXC+nuvr68dfyi+bgAAE4kFAAqiTsAs6WGVfl5XH76dt RWXFpH/7FwyoW7pLa7hgPdJRkRCQkDwwMJD1IXFb30MmE6+VpKAiz5OFvmfozjTdqacL3VOFEnt6 enr8nXf6fvW1r31tqsN5DwIQiCmB+P0rH1PQDBsCEIBALghIuPvkJz9psg5RoUZlYs6kUFwu+qaN 4ieQeWtnNvuPqShk2lhk+2zK6zCcmawigNu2bbPW1tbLmlaRx9dff93fHppOp8d/5GdmH//7f//v J83gCRoNi6bZLDiC4+b6nDn37//+75+0qcxCkv/23/7baX+chQVsCfDhH4T64Rb2LleGtX44/sRP /MR4RrMG8yu/8it28ODBrLYwKib5t3/7t+Njlhf5D/3QD42/zraRmV0v65NwZGaFf/SjH/V+2eFj wtvhCyiZbYePYxsCEIgWAYlYhY5FZYusbBqRq9BjzNa/xjydOJftvFzuczn0SqHPZZO0BYFJCSxZ ssTfVTZZce7MEz/0oQ/Z/fff7+uCKLlhuv9e9PdIhaD/5E/+xBVHHc5sjtcQgECMCWS/XyPGE2Lo EIAABIqRgDIY5DErAVtf3FSoUY/JMjyLkQFzyj8BWTuEY7YiogoChmOyIoYq+hf2wf785z9vejzw wAMmK5DrrrvON6Ms4cxMYd1KGs5eDvoLZyAH+yZ7Pn78+GRvzXl/plir4pLZQre7hi1UJBRnFmvM dt6VV145YbcE/6uuusrv03zC2d+6uKWs7bDtivpQEcjJQjYl4Xj/+98/Ias7/F6wrYsK4Th16tSE TPfMNZHty2QhLmH/9fAFh8nOYT8EIBANApeE46kzJPM9UolWURDSZzvPKIzbSejycprt0DkeAp5A +A5QXVDX3XLBHXNhRLozTPVNdPfobEN3qMluJKjbobve9J1B9VAmE6l1x5/uQJONGr+XZkuc4yEQ TQII2NFcF0YFAQhAYJyAMiN3797trRlU0ES3+et2OgICuSSgIjjT2X9M19/zzz8/4ZDJMriVMS27 kXCxQJ0oX2U95IWsY7IJu+FM46AzecDPJrIVBprN+dmOzRzXZHPPFM9lATSTUKHDcDQ0NIy/zLTq UOZ6Zsiv+uTJk7Zu3brMt/xrFYsMh+7u0GM2ER6Tzgv7oavI7GQXNHRspv86AraoxC9UVHi67Lj4 zYoRT0VA6y1xqdDyp4SzsRhmEadHnNjnxl7I8GtYVlgf7kLOn77nTkD/7qsgdWbI7lB3danuSRDa pxokW7ZsCXbN+Vl38gV38+ki0Msvv+y9sMP9qXGJ2Er++eAHPzjnvjgRAhCIDgEsRKKzFowEAhCA wAQC+kImUUlilIRFiXTy+UW8noCJFzkioAJ+4ZjKAiN8XLCdWZxRHsaZxf+CY1Ww57HHHvNZ2Lod NDOeeuope9/73me//Mu/fFlmzenTpzMPn/Vriam5DNl5hLOd1b4KUWaLcJax3pcH5Ewic33CInw4 o3uqtnQXx2SRKaxPdtxU+5cvXz7+dqYfurLup8qAysxgR8AeRxmrDd09ce2118ZqzAw2NwSm+u87 Nz1M3UraF4obnfqgCL6rfz+yZasu5FAlYBd6/RZyvvSVfwLKtlbNDdnGhUN3i2VeMA+/P5dtfX43 btzo+9PdqZlFITPtzebSB+dAAALRIEAGdjTWgVFAAAIQmEBAWQrKRP3Wt75l1dXV3iM4m5/whJN4 AYF5EDhx4sSEs9/73vdOeD3di0z7EfkvTxXK2JOf+/bt2+3AgQM+21eiZzj+83/+zz575o/+6I/G d8umIhwf//jHZ/3DezJ7j3C7s9nO9NSeyjtavozhCGxAwvuybYezrJV1pB9sQWRmf2u/jnnmmWfs 1ltvNd1qq9i1a5fJbzvz9l1ZFGVm34c9t/3JM/h/4bmEx6tTb7nllilbUGHLIHRRQzYoBAQgEB8C EkD1d6lQNh7JZNrS6ZH4AHtrpD4D22VhFzK8f3j52/+mFHIs9F1cBPRdULVOwpnRskCT5dxkd88p IUB3n+riju6suO222y4TwiejJNu5H/3RH7UjR46MH5Jpdzb+BhsQgEDsCCBgx27JGDAEIFDsBFTI TIKdirDpdn95Auc6Y7TYGTK/2RO4cOHChJMmyyCecFDohS64hOOmm24Kv5x0u7Gx0WSj8Yu/+Iv2 pS99yX7rt35rXHDVSWpXt6cGorAu7oTj05/+9GWCbPj9hdjOzB6eyiojLNJLqM3MFMo2Xv1NCERo vR9mm0qlLvOqlkekstj1d0MXCH71V3/VN6vMJ+1XVlQ4enp6wi/9j79sNiQTDprmRbggow79wAc+ MOUZusU3CF2sIxswoMEzBOJBoKKizBdRHC2QjUfCWQUk3d/DuIXqOiSShR23PMwr3EVlAgL5ICBb OFnGhe80UILOypUrx21Awv3qe54urAehItnTXQQPjtWz7gBUkkS4P/13VldXFz6MbQhAIIYEsBCJ 4aIxZAhAoDgJKENAxek+85nPmL5o6Ta4//Af/gPidXEud+RmlelfPBurjtdee83+6q/+anxOEmZV nDAcf/AHf2CqOH/99dfb933f94Xf8tsScu+55x5/18Fdd9014f1wdnfYpkIHhQXhCSe99UIZPMr0 /pVf+RXTGJ577rlsh81rX6aAPVWGdzgTSIKyxjddqMBlOMICtHwfw3HHHXeYvMiDi1533313+G1T VntmtLS0TNglr+zp4mtf+5q/M0QXHHTBLfPCQjijWj8mM4txhtvXxZPwOgZFmsLHsA0BCESbQFVl lZWVF+6n5YjLYpYQnExNLC4bbWpmA4NDNhwS6wox3nKXPV9VUVmIrumzBAjorq8gCSE83b/7u7/z GdbhfdoOW6TpdWYNEO2bLpS5HQ7E6zANtiEQXwKF+5YRX2aMHAIQgEDOCUi80a39Ep70xU2i0E// 9E/7DIKcd0aDEMhCILO431e+8pUsR12+SwVyVOE9HP/m3/ybyzJdZP2hon6vvPKKybM5fDtp+Fz9 yMgsHhgWaSWGhuMf//Efwy8v25bvs9qTfYbGlZkZfNkJc9iRaeExlX9zJufXX399yh6//vWv+wtb wUG6OBD+IajMpHDob0f4h5r8J3/qp35q/BDdmhvmqTf04zIQvPVafU5lA6ALbBLGJayr2Ka4Vla+ LX7oh2OYyYc+9CE1O2lkzmG6bO1JG+INCECgYASq3d8RCaGFjOHhhEsAGC7kEGbV98joqA268RZa dC+vKHd/w7kxe1aLx8GzIvCud73rMhsQXcD/m7/5m8vaybQQ03Hf+MY3Ljtush36jhP+DqNsbAIC ECgOAoX9llEcDJkFBCAAgXkRePbZZ714LRF706ZNFGqcF01OniuBzKxXWU088sgjUzYn6wlVkw8X EZTA+q/+1b+67LzMwm5TFfFR8Z9w6DbTIDLF0H/37/7dhNtEg+P0rCzh8Fg0tm3btoUPmfe2xNyw ACvv6czsoXAnmZz/43/8j+G3J2y3t7ebbr0Nx969eyeIxZk/6rIVhfyFX/iFcBP2X/7Lf5nwWi9+ /Md/fHyfLjI8+eST46/DG7pg8fM///MTMqY/8YlPmKxgglBBSGWXB5Et4z54T8+ZGez6O0jEk8B9 991nehClR6C62gnYBRaKJF73DwzGBr6yrxOJVNYs1IWaRLnLmq9wAnYhs+cXaq70U1gCsgHJ/Buh 5AZ5YodDFnb19fXhXaZkBSX5hIXpCQe89ULe2kqWCMfq1avDL9mGAARiTAABO8aLx9AhAIF4E+jt 7fV2IY899pifiH70y6s280tbvGfJ6ONCQBYPmeKu/NdlZaOCfGEvwa6uLp99q0KPmULnE088MSGb N5h/prB67733WrYsbwnCDzzwQHCaf/7hH/7h8dfveMc77Ad+4AfGX0ts1X87Oi+I4eFh27Nnz4RM Zb332c9+1pqamoLDcvIsH8dwTFf8UMWFwtnO8oVUdnjm7a66tVZCbri4omxZMi1Bwt7R4hLOhA7G dfPNN0/oUxcmBgYGgrf9s3zGwyGR+m//9m/Du+yb3/ym/diP/ZgvyBS8oXX9pV/6peClf84s4Did IK2M7yDEZrb+68G5PEMAAoUjUF1dWXDv+qFE0vr6Byw9A2umwpEyL8JJiGvv6HK2J8lCDsXXYagK 3UFT0MHQeVETkFVc5kV8TTibtVv4e14A5Y033vB3pB06dMiL2bKv6+josH/6p3/ymdyPP/64t6EL jtezCstmJj6E32cbAhCIFwHuFYrXejFaCECgSAhICNq3b59JxJalgIrYrV27tkhmxzTiSuB3f/d3 feaKPp9BSKAOROpAeA2LqsFxev793/99+/CHPxzeNb4tEVoe1/qBEYSq02/YsMH/uJDVhWxF/viP /3hC9q7ETx0XDmUhv+997xvfJRH4r//6r71gLSFYt6SGM4B14MMPP+wzh8dPytFGOPtaTU6XbSyB WV734Yxn+XOLixhp/BKAJWCHQxzERj/GgtAcJeAHke2Hod7Tj0ZdnPjUpz4VHGq60BDOzP6RH/kR Xyzzz/7sz/wxanvz5s3+YoFu5/32t799WbFI2bnoDpJw9rVODmfk63V4rfQ6HBJxlCkfRNgeJdjH MwQgEE0C+u9XD1lhjI6OTZsdme9Z6EJrv8tq7untt+VLm/Pd3bzal8je3tld8AKOi2yR+3fnoiWd f7gysTMzZOc1SU6GQAYB1UGRxUe4eLQKNup7wAc/+MHxo9evX++LP2favuk7ks7VQ4L2dKGkgrCt 2nTH8z4EIBBtAgjY0V4fRgcBCMSIwODg4LTZ0/px9aUvfcmeeeYZPzPdTicLBn4wxGihi3ioyk5W MUZl30qYzIzJhGtZc0gQnUy8DtpRsT9lzIQFzmPHjpke2ULFCmV3kfnfx3d913fZwYMH/X87wXka 25//+Z8HLyc8K/M6M0t4wgHzeJFp4TFdtrG6uu2223wxxfCYJIRniuHBsORh/Sd/8ieX/X0JX2jQ sVN5R8unPCxgi0lYwNb5ylrXrbxh8Vy34mbejqtj9aNQgnq2bOmw/7UytDMLhOr8IN58880JFxum uwAQnMczBCBQeAISrweHk3by9Bk7d74jEpnPAwNDdv5Ce6QFbHG70Nbp7EOSBRf9lQF+8kyr+zs8 YOuuXGPLl00s6lv4TxkjKDYCt956q+liuf47CEIXyfXdbsmSJcEufxdaWVmZr12SeZfa+EGTbOi8 G264wa677rpJjmA3BCAQRwJYiMRx1RgzBCAQOQIS/STOTRUXLlyw3/zN3/TitTIWf/3Xf91npGaK c1O1wXsQyDcBCZLKZtYtmrKsmCqUgft7v/d7pkKE04nXakdZMBI31bZ+qEwWEkeVZS1RPDO7Nzjn ox/9qL9tNNMjOnhfzxJtz549mzfxWn1kFkScal46PgjddaHMoqnGryzt//7f/7v9t//23y4Tr9WO vKbD8T3f8z3hlxO2r776alOWdRASv3UxIRzy7taFC2XSZxbLDI7Tfl2E+/u//3uT33e2CDP5wR/8 wWyHjO/LLGI5lQg/fhIbEIBAQQmMjIxaV3evvfzaG/aNo9+0s+faIyFeC4oym7tdBvbZ820FZTRV 5xLjzpy7YKn0yFSHLdh7Ws8Ot57fevW4feMfXrJWdwEglU4vWP90FB8Cmb9ZJBTPNmSVKAu6zMi0 LdP773//++3nfu7n/N2q2SzSMtvQHWdXXXWVP0fZ3gQEIFBcBBa5K19vX/oqrrkxGwhAAAILQkCF 1n7t137Ne/BKMMsm5KnwiCwCVABNGZry+J1MmFuQQdMJBGZIQLYesqnQ51yP6upqL27K8kZV5TN/ zMywWZ95o4s6J0+etBMnTnibi40bN86pzfPnz3uLCxVCVTa4Mm4krs7kx85Mx5vP48RV2UcS22UR Ip9vCc6ZxSzzOYbMtkecCCR/79OnT1tfX5/nKbsXeaUTEJiMQFDAMajtMNlx7F94AsnU/AVJLw73 9FlbR6d19/R7/+Z0RETYMFGJak2NDfbd7323VVdVTrBeCh9XiG3xEr9Xjn3HoshORR1r3L/zixvq bdnSJbasZYnV1dYWAlXJ9KnPKDEzAvo+ou96shCR1ZkEa30P1W8qXWAPrO5m1hpHQQACcSOAgB23 FWO8EIBA5Ah8+tOftldffdWPq9Z9yVeWtXytFbIVkde1rAEkpskDWAXVCAhAAAIQgECxEUDAju6K zlXAVq6TPK47u3qts7vHXdAacLYhw5bKgSCeT1ryc75q7Wq7ev0VkbmYqcxreXS//O3Xrbev313I zSeB+bUtUbCu9pKQ3bykyZY2N1lDfd38Gs1ytj5f8uBWxrcunOriQ2VlhVW4/ueS3RvuYsy1Peqy y1Ou3YuOfXlZuW9bIn24nkT4nEJsI2AXgjp9QgACcSSAB3YcV40xQwACkSEg6xCJ18HNLMPuR93n P/95+43f+A2fVfq5z33OZwkoK0B+t1deeWVkxs5AIAABCEAAAhCAQDYC+l6TduJfT0+vdfX2+cKI fc4nWXYTcQgJl63ORqSmptpWr1jm7h6qKviwk6mUtbV3OvF6INLitUD5gpjOT3xwKGF9/YPuMWBL GhdbixOyax3TeYvLTlDWZ0k2KspET0vAdhdKAgFbfdS4NZtrPyoqKt7DzqNddw4IuNqqcOJ4lXtI JK902btzbb/gHyYGAAEIQKAECSBgl+CiM2UIQCA3BGR9IG9aRTiTQ/t/53d+xwvYem/z5s127733 RiYDSGMiIAABCEAAAhCAQDYCyhQedgUGu51dyDnnh9zR1TN+oT7b8VHcp+TmRDJlp86c89m8ssOQ NUahQoKwhODzrnhjkPRQqLHMpl99FgZc1vjg0LD3PdfnYsXyFp+NrSzp2Ybmfkm4TnuBOZlU5vVo iIkTtV12v/otc5ZauvAQ/o49k/7Uh4TxgcFhXyhzwjnuMyHhurq60rdd5e6OVLa+Yrb9TGiXFxCA AAQgkHcCCNh5R0wHEIBAsRKQNYgyrvVFOfjSG2yfcJ6+8gr+2Mc+ZhQlK9ZPAPOCAAQgAAEIFB+B pBP5JFyfONUa+2J+El+/c+KMzyhevXK5z7wNvrMt1MopA7jfiddtHV3WPzC4UN3mtB99v5WI/fqb p9zFjWFbd+Vaa3Q+2TPNYNb5sgpRlvWQa2doOOHWZGzSMSpzWpYfypierVAu8TvhhHZ9jrOF1kMP 9VHrbFLqXYFpidiqR7jQn41s42MfBCAAAQhkJ4CAnZ0LeyEAAQhMSUCZ16dOnZogXuuE8Bdffal/ 97vfPWU7vAkBCEAAAhCAAASiQkBCY3tnt51uvRB78TpgOjA0ZCdOt/pM3yvWrPQi9kyF16CNuTyL 5agTUzscz5Onz1mXs2Mphjh7rt3ZiNQ6K45K55NdM+WUxEDhM7mdHcmAsyVRNvpMQhYgiUSlE5hr Jny/nupc9ZdIpLx4HfQ92fFaG2VpDzkhe/Hieqt3c5E/tiL8fX6y89kPAQhAAAILS+DSX+iF7ZPe IAABCMSagCxCDh8+7Ocw2RdcfWlWdvZnPvOZWM+VwUMAAhCAAAQgUDoElCHc5axDhl2GbDGFsoff OHnavvnKMV+QciHmJnH0ldfesFeOvWHdzke8mEIZ+j29/TOaUio14gqA9roCoP0zFq/VsLyxh9x3 6ZkK3jpHorRsTlQUcqYhcV1jU5FSWZoQEIAABCAQTQJkYEdzXRgVBCAQYQKyDplJSMRWgUcVevzw hz88k1M4BgIQgAAEIAABCBSMgAoMDsTU5mI6aPJaVha0BM7z7Y227oo1Vl9f66wqcpfT5e0r3rJg kd/1oMv+Vr/FFrIA0cWORLLJF1vMNj8Jz7Lp6Hc2LiPOsuOtZOxsh066TyK2Ckk2ugxpnT866trJ cnRFeYXLmjZvczIb8TpoSm3Le1u+7w3uM1Hnsr7L5+DxHbTHMwQgAAEI5J4AAnbumdIiBCBQxAQO HDjgrUNmM8U//dM/tfe85z22bt262ZzGsRCAAAQgAAEIQGBBCUiYVPHDYg35LssXW2Klnpctbbbl Lc1etKxwxf3mGhJN5XPd5TKNJZIPOZFcPszT2VjMtb9Cn6d56XOScjYfNa7QYmZIvNZnSVnoEqHn GlqvQdeG1kvC9cWLzjc7U8F2wvWiRWXmnry39VwvGEjElje2xqwuZF2CiD3XleM8CEAAArknMPd/ pXM/FlqEAAQgEGkCr7zyin31q1/1Y9QX92z2IcEPlcz3jhw5Ytu2bYv0/BgcBCAAAQhAAAKlTUAC 3ojLci32kOCc6kl7EbbXWWEsbqjzxfzk6VztBNlK5+9c6Qr7ZX6fExd911NBwuFEwou0EmpVmFCC uKxKlOFdCqHPyWRiccqJ1hLw5yNeBwxV+FGPhQpf4NGNvaKizHl81y5Ut/QDAQhAAALTEEDAngYQ b0MAAhAQgcHBQfv85z8/DkM/aAKxOtipfcEPnVr3hVdZ1x/4wAf88/Lly4PDeIYABCAAAQgUJYHH HnusKOdVepNSLmtmmmtxUpDXtx6yjqitqbZaJ2DX1FwSsCuchUTwvW7C7B2aMZcJLHsMeTRLwE66 bGT5L5dSuG+9LvU5+4xlGZKOsXWKMsglwtehX2dfYPZCAAIQKAABBOwCQKdLCEAgfgT+4i/+wjo6 OsZF67BYHczmqquu8oL1937v92IXEkDhGQIQgAAEIACB2BCoeivzOJkqLTFWWbfpgRHrK1L/73x8 ACsrK1yWemXWpuN++cMnqchThIAABCAAgcgQQMCOzFIwEAhAIKoEwtYh4UwcZVkHGdZ6rq+vj+oU GBcEIAABCEAAAhCYloAK2NXW1FjSeQ4TEJiMQJkrfFnnPifKVs8WKoypY1zZxWxvR36fxl7uLGQI CEAAAhCIDgEE7OisBSOBAAQiSCDTOuTd7373uGhNUcYILhhDggAEIAABCEBgzgSaGhd7P+ievv45 t8GJxU9gcX2dK3xZ5zKws8sJNVVVlqpUkcd4Xgipqqr0F3KKfyWZIQQgAIH4EMj+L058xs9IIQAB COSVgKxDJFrLFkTPZFnnFTeNQwACEIAABCBQQAIqYtjY2GC1XT0lU4ywgLhj2/Wypc22eHHdpOMv Ky/zxTCTKpaZildR0GqJ19XVpixyAgIQgAAEokNgkfN3wtwpOuvBSCAAAQhAAAIQgAAEIBBLAt/+ 9rd90btrr702luMv5kHPxhKkp7ffTpxutdbzbcWMhLnNkUBNdZVdf927bLkTsS/ZhGRvaHR07P+3 d+dPcpz1Hcef3Tn3PrSr07J8C58xOFAQYhsbDDFQ5kygqFQIP+Y/SFX+gfjn/JpCSXCoVOw4FhAg seOAgQRzBIzjC1/Ykm1pJa20972b5/OMnnFP78zO1T0zPfN+yuuZ6enj6Vf3rmY//ey3zeLSspmb Xyw/Q4dOHR0Zdn+FkLIhfCuaAnMaAggggEB1gdb8VK7eD+ZAAAEEEEAAAQQQQACBBAs8+OCD5q// +q8TvAfxdv2RRx4xb7zxRrwbiWDtqoM9MT5qy0NQAzgCzq5bxf6pSTM0OLBneK2d7u/vMzlbSiRn A++kNPU1l8u4vielz/QTAQQQ6BUBSoj0ypFmPxFAAAEEEEAAAQQQQKBtAi+88IJ59NFHzdTUlLnp ppvcPTV0E+hOa2lb13hkeNBMTIyZmXOzndY9+tNGgVQqZaZtgK1R2NWabnyeSttSInaE8draerXZ O+J99VUXboI3be+IjtEJBBBAAAFDgM1JgAACCCCAAAIIIIAAAgi0SOD8+fPmqaeecl/apEJsf5Po 6enpFvVi780MDQyYg9NTZvbinNnc3Np7Zt7tCQGFuiobMjI8ZHSRo1pTpdJtW0YkSefP5uam2bR9 TqV2CLGrHWDeRwABBFosUP1fnhZ3iM0hgAACCCCAAAIIIIAAAt0s4G9DpFDwF7/4hfv6xje+YY4d O+ZGZ991113uebsMsnYkqsqITIyNmvP2ho6+v+3qD9ttv4BGJ19x+KDJZmqr2awa2Ct25PXK6lr7 O19jD1ZW1214nTZpO9I8TQmdGtWYDQEEEGiNAAF2a5zZCgIIIIAAAggggAACCCDgwuBwiQIFxJqm Gtn6+t73vmcGBweLZUY0QntoaKhleuqLykRcc+wKM7ewaNbXN1q2bTbUeQIZO+J6et+k2TcxagPe 6rXRdT4ruF5eXknUxY9Cv1dteN1vhocGGYXdeaciPUIAgR4WIMDu4YPPriOAAAIIIIAAAggggEBr BDS6WnWwy7Vygfby8nJbS40oqBwfGzEHpvaZd2bO21IQm+W6zrQeEBgYyJnrrz1W9caNnkIXPFbX 1hJVPsT3XSVPNBI7Y0ea11Lr2y/HIwIIIIBAvAIE2PH6snYEEEAAAQQQQAABBBDoIoGFhQWzsrJi R5cuF7/Cr/VecNr8/LyZnS3cEDEcVpej8fP4kdmaR6VGBmxtagXhraqV3d/fb67VKOz5BbOwuGl2 ynWWaV0tMDSYt6VDDribMdayo9vbO2Z5ZTUxN24st08K4DV6nAC7nA7TEEAAgfYIEGC3x52tIoAA AggggAACCCCAQAsFtre3zdLSUjF0DofM5V6Hp62vrzfcYx9G+8dKKwq+ryBbofXdd99t7r///pYF 18G+5e3o2yOH9ps3Tr/jgsngezzvbgHVgh63ddAP7Z+uuZzGqq17vWYDYAXZSW36WaF9UBA/OJBP 6m7QbwQQQKCrBAiwu+pwsjMIIIAAAggggAACCHSngEYxhwNlvS43LTj62c+zsRFNHefR0VEXKqtG tb4UMOvLv/bT9Ki61XpveHjYPPnkk+Y73/lO2YOj0No3P/p6amrKfOELX3B1sFtZ/9r3Q4/qi74O 7J8yi0vLrozI+galRIJG3fq8z+6YwuvDB/ebnK2HXmtbi6F0SCaTdjeP1GN/v3qmL+Pqayts3tza Mhv2vNRX8HvJzdTg/7bsOlcIsBvUYzEEEEAgegEC7OhNWSMCCCCAAAIIIIAAAghcFlAQtLi4WFJS o1zoXG6aD6KjCJ9zuVzZkNmHz/7RB9H+tX9UiFzLDewqHfgjR47sesuHbT601gx33HGHG2190003 7Zq/XRM0CvXQgWlb13jDnJ+9GFlI2K79YbvVBUZGhs3BA1NmwobYtTSdy6ofrQscCpWbbfqeSKdT LjzPZTNGN5LUa39RRevXNrWtLYXY2rYdNb1m/0pCQXazI8C1vEZha11+u83uE8sjgAACCDQuQIDd uB1LIoAAAggggAACCCDQ1QIKjv0IZv/oQ+Xwa82rQOmv/uqvSsLqZm/+pzrMCo+DI5uDIbMPmMPv ++n+MRgSt+OgBetWyykYxKmP7SwTUovHxPiYWV5dczfnW1hcqmUR5kmogEZcH5ieNNOT4y681W7o nN2xoe66vZmnLkrZl6Fm37NhrwLfZpu+N7I2tNaFk4F81vahfGyh+XRRSV9Ze9NF9Tu7ljGr7jxd b/omkltb27b2+7K9oWPafb8G98tu2m6332TTGdNnR4W3++dLsG88RwABBLpRoPy/BN24p+xT4gR0 xZuGQJIENDqEhgACCCCAQKcIqF5zOGT2r/VYKYgOzqOgqp6mkOv1118vLpKxodLY2NiuMhs+VA6G zuWm6X2NnO6mFgy6OqFMSK22Cuv275twN+dbs3WO1yMqyVLr9pmvNQL9NpnVcZ62XwOX6z+78NoG 1is2GF6yNzBdsyPxNS2ulstlzPDQoL2JYu5yyZDatpSyF7sUeivMTqVWXPjczGhw7aNK55RrhZA9 bYYHVUKoUCc7+L1dbhmmIYAAAgg0LkCA3bgdSyKAAAIIIIAAAgggEIuA6siGA+ZyoXO5aX65esPn 8I7k83kXPvuQORgw+2l69M//5m/+xo1CfPDBB900jZrW6GnaboEbb7zR1bfupDIhu3u5e0o+nzP7 pyZtkLlq3n5nxmzHGGLu3jpTWiEwPDxorjh80IyOjJRsTnWmL80vutHXJW9E/EIXvRReN3PzRJX8 UKisEdSVAuhmu61wW0H++vqm2W9HYWezRCvNmrI8AgggsJcAP2X30uE9BBBAAAEEEEAAAQTqFFD4 HBzF7APleqY1M2pQoXEwWPYBc/Cx2vsKq+sdTejD6gMHDtQp1huzK9C/8847zRe/+EUTLCeStL0f HRkyVxw6YOuaL9tAcyFp3ae/ewioFMeNN1xjw2tdfCrcKFGz6+eRbmi4XedfZOyxqYpvadsD9kJJ sy1ry34MDeXdxRYF2XE1Bdm6oJNKDRbLrcS1LdaLAAII9LIAAXYvH332HQEEEEAAAQQQQKBEYNUG ET5oDgfP4deVRj83Ez5r9OGIHfkYHO0cfh58HQ6l9V63ldwoOUAJfnHs2DHzF3/xFwneg3e7Pjo6 bG649ph59sWXbbC59u4bTTxT4Di9b9JMToyZeVtj+41Tbzextu5cVKHy+OioufLoITO/sGjOzpw3 S8urkeys6jy78Hp4eNdfTiikVcmY+IqGFHZhcDBvb9aYimR/tBIF8kNDA2Z+Pt6a7Ztbm7GWVIkM hBUhgAACCRbos/8Yxf3vUIJ56Ho7Beqtga1TWSOF3AnNad3OQ9cF29aNWAo3q6ln9Bk1sLvg0LML CCCQaAEFzLWGzD6k9o9+uWY+Gis8DobL5Z6Xm+ZDaEpuJPr06+jO1/u5utrO6Ptkc3PLnJ+9ZJ7/ 7auuLna1ZSq9r3IPCq5108Cx0REbYKZdWHpu9qJ5/Xen3br5hdWYXDZrDh+cNkfs6HeNUFZouri0 Ys5fuGjOnps1y/bnX6NNn2EPH9xvrr36qPMPf/7dsDdunL0450pmNLqNWpbbZ28aqZs2+r/mqGWZ vebReaobS56dubDXbE2/p5rdE+OjrvZ2vSvj94d6xZgfAQR6VYAR2L165Ltov31w7cLry8F1+ENX F+0uu9ICAZ1TOpX8eeTPsRZsmk1nIx6KAABAAElEQVQggAACPSvgA+RwoOxf63GvefSefl430jRK TyGyyjoEA2YfLOvRP6/0vupF+383GukDyyCQJAGd6wqep2zgeM2xo+b1N0+bVXuDv3qaRvzuGx8z Ci0VXA/Zm+FpmlraPh6yQXbW1hY+9fYZM9eC2sv19L2V88p6dHjIBczTUxOuPrS2L6tsJmsD37zR iHgFzOfOz5pVe4PNepouGGjU+1Fb91o3Pyzb7I/Wzc34ynBom9offUX5c9Sdp/bmo6pPvWGD7Ab/ iShLEpyoEiVxrTu4HZ4jgAACvSxAgN3LR78L9t0Hi/4X1uAHHk0rfJBo7JfZLuBhF+oRsL8cqNKf ziF/HgXPK3+u1bNK5kUAAQR6QUA/H4PBcvB5udC53DSV7fA/c+s1U7kMhcrj43bknn30QbMPnYOv K72vsh00BBCoT8CFgzbEPnxgyoabG+Yte1PHZVsnuVpTqZAxWyZncmLUjVodHRl2pR785y8t328/ j2lk6sH9Uy4oVzCr0d61rL/a9pP0fj6XtUZj7saZuliQs6+DLWXD2WFbIkOjlkfsjQ9H7A0YZy/O m4uX5u3NBderlvzQRQiNHFZNc928sVLTz+dmbwpbad1+usJrHffgeeDfa+6xzwbjGfcXA43+O1Nt +67GduEXz2qz8j4CCCCAQIMCBNgNwrFY+wX0AUQfcMIfRLbsTUZ0l2zdaEQjQfTnjdv2qrimR/+B qP0O9KBxAZ07KXujq5T98K4P8PrTzHzO1t7LpOwvUv2XV1w4x/y5xjnUuDdLIoBA5wno52C5QLnc tHAw7efR9Eaafp5q1LIC5qmpqWL47ANnHzb7IDr4Ws/1NWxrtfJzuRF9lkEgGgF9/ylUveLwAfe9 eP7CJbOwtORGu4a3oNG9g3aU9bgdbT29b9yN+lWpiErfw5qeSvXZ0iL7zOBA3n7P5+0I44sV1x/e XpJfK8gdsTczVGi93+7/mA359yqrob8i0YWAYTtSWzWyZwYvuBtsLi4tG5WPCf++JBsdN4XXhw9M u1Hw7fbSPtjdjrxpnVq3HaZiv+IZ2CTfeNYcOQcrRAABBBIrQICd2EPX2x3XhwR9qPUfxvzz1dV1 +yeGC/ZO0GvFD8PuQ7Gdt/DBpbfd2PvyAho1oQsdOn8ubs/bX5JyZmxs1I380Ydee7q5c82fZ+6c Kr8qpiKAAAItE9C/gQqRg1+VQuZK82jkcyNN/6YqWNbNBg8cOOCe++C53GM4hPYBdCPbZhkEEOg8 AZWxOHb0sAtRz5674G4wqM9W/jO7BgqM6ueFrXM9YT9jabRtPW3EBrMKsEftRat3zp4zs3aE8era mmnmhqn1bL9V8+ozpgZUDNvR1EePHDD7bGmPrH1da1PwPT42Yq2HXIA9Y0euz80tuBBbVv54yH/S juw+aEfPq3yLlmtn09YLfYinH1p3PGtupxrbRgABBHpLgJs49tbxTtTeVrrZjP/gpUc1fdDTn7TN 2btLqz6e7s5dLmD0yyUKgc7GKlDpnND07e0d+wvAsPtFTKOxg+dbpeW4CUush4uVI9BVAvo5smRH KfpRzMGAudZpaza8aaT5khvhUDn4OjzaOfienlNyoxH57l/mxRdfdJ/Bjh8/3v07m7A9rPS5Oo7d 0OdyhcvzC0v2pn9rNoDNuUBVNx6MYkCJ9mXGhuS/O/W2+4vLrW0F5XHsSWvXqb8KzNpR0UfszRQV XutndRTB8oq9UDm/sOgG+OivUvWXhwqvNaq91uOxbs3PzMR3I0Tl5wreNUJfDlE2BfcqPVOoox5f He/99uKMSr7U2/j9oV4x5kcAgV4VqO/Sd68qsd8dI+CDw2CYqHIhs7Pz7s7b75Z92N3lcqH27rmY 0ksC5c4Jf47pT1b9B90JW6NRH6b1nn/fP/aSF/uKAALvCszNzbm6z+ERz/51+FEhzsLCQjGwbjR8 9kGyRj37Ucx+WrnQ2U/zjyq5QUMgLoEHH3zQrfrEiRNxbYL1JkBApS4GVebHjspWrqyRr+U+czW6 K6qhffjQflsfe5+ZsSVFTr31jpmzAa2rQ9zoStu4nMLbkSHdpHHaHLLlPLK29vde5ULq7WreBuEa 1e0y/ssHJIpgvN5+7DW/LkBs2nA9risRWnc3XOTYy5D3EEAAgW4XIMDu9iPcZfunD78KDtX0XFfU L9oblSzb+pv6oKe39CGQhkCjAv4XLJ1LOqdUO7DPjuqfsKNCCufYuyF2o9tgOQQQaJ+ASmb40c4K mX3QXG7Uc6X3Nzc3696BdDrtymwoSJ6YmCg+98FypRA6+L7qRdMQQACBThfwn6X8Y9T91Xo1Rrff /lzdPzXpRu6qhKBu8qibFy4tN1aXP+p+VlufRt5qJPS+yTFXtzpvR6irtEfUblpf1Oustm+NvK9/ W/3veY0sX2kZrXNjo3wd8ErLMB0BBBBAoPMECLA775jQowoCwQ80+hC2vbNt5heXbcC4Yv/8rTA6 NgkfzirsHpM7TEAXQnTOKbReWFi2o2HSbnSMO/fshRM1zrcOO2h0p6sF9P2okhvlAudy03wgHX4v +G9JrWAql+EDZt1s0D8PhsuVpmkejXqu9c+0a+0T8yGAAAK9LOA/gynw1ZduEDlif9YeOrBmL1Ku mEu27vO5C7NmfaP+C45xuqbt/QOmJifsvVbsDRdtnWuVVdHNFLPpjBswEee2m1m3vHWT842NrWZW s+ey6+sKsPecpaE3tcoNex408u9/rRuUjT8na12G+RBAAAEE6hMgwK7Pi7nbKKAPBRpx7UfB6oPI pUtzLhTQBxI+NLTx4HTppnVO6dxSXfXZ2TmTt39+qVGUfrp2m/OuSw8+uxWpgEY++VHPPlgu9+jn 8aFz8LHRkhs+fB4bGzOHDh0qjnz2gbMe9wqiFT7r3x0aAggggEDnCvgge3howGzamxLqpo/6XeH8 xUsddaPHnA2srz52xN2QUqG7PmMmotluFv4tjC/AVu30dft5QQOTovp3V787qn63bigaZ1N/NfiF hgACCCAQnwABdny2rDligWBIrecaWdHXx8jriJlZXUigEFZrYqEm9r7J8WKATXgdwuJlVwooRA4G yT5kLhdA+/n8PP61filtpGXtRSMFzPv27dszZPZhdDiIHrI1RaP6JbiR/rMMAggggEBrBfTZTGH2 8PCg/fdjwPTbwS7x3bav/n3L2BsoToyP1r9gm5ewRUjsv6cp24uNWHuysrpWGFEfwYVj/b6o2tfL y6ux9lkr119ZyYiGAAIIIBCfAAF2fLasOWKBwkjYQmCtq+j6MMKfZEeMzOrKChRGVPTZmoqr9pcO e/d2fUi9PDqbELssGRM7QEA/MxcXF3fdaNCHysGQOTgt+Fz1orWeRlrO3jRKgbJuNugD5mqjnf18 vuwG31+NyLMMAggggAAC0Qro3+NcLmNWbcDc6OeCWnq0trZu1u3nB5VaafYCtEZfq78KxeNuiRpN HzcG60cAAQRiEiDAjgmW1UYv4ANDfWhaWll1H2r0nIAjemvWuFvAf1hfWVkzQ/bPU3Xe6YMx599u K6Y0L7C+vl4sueEDZf8YHPnsnwff89O0jkabwmeFyZOTk+4xPLK5WhCtkc98bzSqz3IIIIAAAgh0 loBKneRtre5lO7o9znrSW3bE9Ir9PU9lRLS9Rj9LuPDahuG6oaf/DB+HqPqnsF3hfl8Eo8bj6CPr RAABBLpFgAC7W45kj+yHPiRs29BaowLVGv1Q0yNc7GaEAu7cs4G1PlQPDubdmjn/IgTuklXplyT9 fPIhsh79l0LmYNAcfO7n99MaLbkhxnw+724aWC5krjWI5tzukhOS3UAAAQQQQCACAX0uyNj7wEyM j5i5+UVbV7r8TRGjCItXbfCcsqVWFGJrm2q1fi7R9vV3Yxp1vbi47MJ2t4Im/1du+5qWtYH+xNiI SdvHcvM0uVkWRwABBBAICBBgBzB4mgyBPvvBZHOTka/JOFrd1Ut9MN1wtXxtlTv7PIoP6d0llOy9 0WidpaWliiGzD5f9ow+dwwF1MwoKmHWzQV9Kwz+Gg+fw62BYzS9QzRwBlkUAAQQQQACBSgIqlTFl 7wezaT8P63NT+LPwmr1h4tLSitFI6kab1qnwWTdf1E05B+1nI/uxu6a2ZfukZZftgJMobtyoz1Sq p57L2hHWgT5oukqcaPQ1n7tqOjTMhAACCDQtQIDdNCEraLmA/cCgD0xqfGBouX5Pb1Dnmy6eFD6s Bz7F9rRKZ+z82pqtcWhHOAfDZP/cB82V3vfTN+yd75tpCpV1s8FKoXMwZC43j5bnZ1ozR4BlEUAA AQQQQCAuAf8ZRY8Z++XukGHD5mBLp1Une72pANuvb8MG2HM2KFcgns/n7FfW3uAxY/rttoNNn8sV nKt0mkr9bWxu2t8VS/sVnL+e5ykbUo/aANvve3FZ2wf1Ytf04gw8QQABBBCIWoAAO2pR1tcSAQXY 3MCxJdRsJCCgD8g69/r6ovlQHFh1zz6VqQ+Yg4/lnvugWe8F39d0f1GrEUj98qGyG6Ojo4TPjQCy DAIIIIAAAgj0lIA+O7kYORAm6zNdOqXPVDkXYDdTDk2Y+rStkdz60ohvlQXRqGcF2P22vIi2r/e0 XY283r48n5aNomlb+YEcv3NGgck6EEAAgQgECLAjQGQVrRfganfrzdliYZRF4XN66ciPXrVRaKyS Gz5Q9qFyMGgOPi/3vq9n36ihfhYEy2kEn5cb8VxumpahIYAAAggggAACCDQu4H8/G7ABtsp/NBtg B3vig2w/TTeVVItqpLVfb/BRNbgHBwr3vQlO5zkCCCCAQHsECLDb485W2yigq/T6gKVHWu8J+GPv P2T3nkBhj1VywwfPwZDZP/ePPnQOzuvfa7bkho7B0NBQSQBdrrRGudDZTyN87tUzmP1GAAEEEEAA gU4U0I0NVTNanxMVPMfR4gyu1V+F17lc1u1HHP1nnQgggAAC9QsQYNdvxhIJFwgGmK4MiYJsBtQm /KhW6b6uVdiwVCNB/AWMKkt07NvqfzhUDr724bJ/DAbPwfmavYCjP6tU+OwDZx8oB1+XmxYcIa2y HTQEEEAAAQQQQKAXBAqDJ7r/lw7tZ96Gvxsbm+5mikk8ttls1o2+LhyzJO4BfUYAAQS6T4AAu/uO KXtURcAHmAoz5xcWbS01+0GSwdhV1BL+tj3EGqkxNDjg6tj5c6DVe6Vzzpfc8AGzf6wUNIff18jp ZlswfA4Gyj58rmVaLpdrthssjwACCCCAAAIIxCKgCs1pO4q2kwap2FzXjeyNZYc7bKUavay61bqh ooLsJLVMOm0GbP8VwtMQQAABBDpHgAC7c44FPWmRgMLLdCplFhYXzQu/fdX9edg25URapN+ezehm L2tr6+bm49fZG/WNmE37YbrVIyr0Z5Rf/epXmwbQXw1UG9lcLYgmfG76MLACBBBAAIEyAidOnCgz lUkItF5AYXEun23557299lQDCFReo1eaAuCtzS1zaWMxUbusGt76oiGAAAIIdJZA7/wL2lnu9KaN AgouFWLrQ6SCvKyt0abXtO4VKITV9o7l9pi3a/R1JpOxd2XPGz36gLmRIFp/0khDAAEEEEAAAQQQ qCygz3yTE+P2s9+pyjO1+J2s/Qw4bgdS9ErTMcjbIHjYjsReXFpJxG4PDw3az+l506/R+zQEEEAA gY4SIMDuqMNBZ1ol4Eff7uxsu0CTALtV8u3bjo61mj/27ejJ17/+9XZslm0igAACCCCAAAI9JaDP e4MDeTM2MmwubM65+6C0G0ADZ/btm2h3N1q2fR2DPluqUUF2UppG7rt+6wkNAQQQQKCjBJLzr0lH sdEZBBBAAAEEEEAAAQQQQACBThRQCJmywemxKw4ZjarV63Y29eHQ/ikXqrezH63ctgYIbW5smVVb xi8pbW19w9XtZnBTUo4Y/UQAgV4SIMDupaPNviKAAAIIIIAAAggggAACPSIwOTFmjhza70p3tGsk sMLrwwemzf7pSXcfnh6hdzdxVHi9bkPhpDTdcFJ93rC1u2kIIIAAAp0lQAmRzjoe9AYBBBBAAAEE EEAAgUQKvPjii26k6/HjxxPZfzrdfQK6+fVBO/I5k06b8xcumoWlJbO8suZu6B3n3mrEt0qYDA0O mqnJMTNlS4foda+0bTv6em1tw4bBa4naZY281o3fdb6kbR3sdl30SBQanUUAAQRaJECA3SJoNoMA AggggAACCCCAQDcLPPjgg273Tpw40c27yb4lTCCfy7pR2BqNPXtxzlyYvWSWllfM1va22b785Z/X WzrCVnm2IWehzrPCTn2lbPCZyaTN1MSEmZ4qBNe9FoRubmok85rRiOakNfV5bX3d5LIZk83yB+tJ O370FwEEuleAALt7jy17hgACCCCAAAIIIIAAAgggYAUG8jkXZB8+OG1HYG+ZldU1F7JqxK3CVpWO 0HRjdmr2Up3tbDZr8vYGjfm8HrMml8+bvA0/2113u+adiGFGBcAbG8kpHRImcCG2PR+y9jjSEEAA AQQ6Q4AAuzOOA71AAAEEEEAAAQQQQAABBBCIWUDBskZI62t0ZCjmrfXm6ne2d4ytxpHYppH5m9vU wU7sAaTjCCDQlQL8TUxXHlZ2CgEEEEAAAQQQQAABBBBAAIE2CNiLBMluKg6T9H1I9hGg9wgggEBY gAA7LMJrBBBAAAEEEEAAAQQQQAABBBBoSED1ozXCPaktk0m5kjBJ7T/9RgABBLpRILn/qnTj0WCf EEAAAQQQQAABBBBAAAEEEEiwQCadNoMDeXuTzB2jGuONNpV7yWa1rgGztVUo6bFpH7VejY/WDTRT qZRbveqRq6752vqGLV/SeP0S1b1W37MZ6l83etxYDgEEEIhDgAA7DlXWiQACCCCAAAIIIIAAAggg gEAPCvTbMFk3tFTInLIh88rqekOhcjrVb4YGB1yAvb2z7SQVZPt8WgF3ys6j1t/Xb/pSfWbL1q/W TRjrbeqzRo4rvM7ZG3LqNQ0BBBBAoHMECLA751jQEwQQQAABBBBAAAEEEEAAAQQSL6CR0fl8zo2Q Vhi8trZhNjZrD5YLo68zZiCXcyOt+01hpHX68ojrckB5O++63Y5Cbo3SrrWl7YhxBe5u5LUd8U14 Xasc8yGAAAKtEyDAbp01W0IAAQQQQAABBBBAAAEEEECgJwQUBKskhwLilZVVs7S8YjY3t9wo6WoA qqHtAvB0IbiuNr/eV7idt6OnFZQrMK/W1L+0Xb9GeQ+4sN2O4k78DSir7TXvI4AAAskUIMBO5nGj 1wgggAACCCCAAAIIIIAAAgh0tEChzEefGR4edKOcF22IrVrVCrIr1arWMhoRPZDP171vuWzWrGc3 zcb6ptn2tUZCa9H6FVxrG8NDAy5gJ7gOIfESAQQQ6DABAuwOOyB0BwEEEEAAAQQQQAABBBBAAIFu E0jZ0Hh0ZNiV6lheXTXLy6suyA7v54AdRa0R0Y0Mhtao6oGBnCsjsmTXH24KrvW+yoVk0pmGthFe J68RQAABBOIXIMCO35gtIIAAAggggAACCCCAAAIIINDTAhrlrFBa5UFGUoMupNYNF9fsTR43bN1q vadR0SodUgiXdRvI+pq2kclk7IjvIVd/e229cAPJdCptcrlMoaSJLTWioJtR1/XZMjcCCCDQTgEC 7Hbqs20EEEAAAQQQQAABBBBAAAEEekhAwbFu8lioQZ02WRs4u3IiNq9O9afse82Fy/0KsW3d7dSQ DcntaGtj7+dY2GY/wXUPnWfsKgIIdJcAAXZ3HU/2BgEEEEAAAQQQQAABBBBAAIGOF3ChssLsbH/k fe3v77NhdcrYGDvydbNCBBBAAIHWC0T/L0Xr94EtIoAAAggggAACCCCAAAIIIIAAAggggAACCHSh ACOwu/CgsksIIIAAAggggAACCLRa4MSJE63eJNtDAAEEEEAAAQQQ6AEBRmD3wEFmFxFAAAEEEEAA AQQQQAABBBBAAAEEEEAAgSQKEGAn8ajRZwQQQAABBBBAAAEEEEAAAQQQQAABBBBAoAcECLB74CCz iwgggAACCCCAAAIIIIAAAggggAACCCCAQBIFCLCTeNToMwIIIIAAAggggAACCCCAAAIIIIAAAggg 0AMCBNg9cJDZRQQQQAABBBBAAAEE4hZ47LHHzMmTJ+PeDOtHAAEEEEAAAQQQ6DGBdI/tL7uLAAII IIAAAggggAACMQj48Pozn/lMDGtnlQgggAACCCCAAAK9KsAI7F498uw3AggggAACCCCAAAIIIIAA AggggAACCCDQ4QIE2B1+gOgeAggggAACCCCAAAIIIIAAAggggAACCCDQqwIE2L165NlvBBBAAAEE EEAAAQQQQAABBBBAAAEEEECgwwUIsDv8ANE9BBBAAAEEEEAAAQQQQAABBBBAAAEEEECgVwW4iWOv Hnn2GwEEEEAAAQQQQAABBHpCIJfN9MR+spMIIIAAAggg0J0CjMDuzuPKXiGAAAIIIIAAAggggAAC CCCAAAIIIIAAAokXIMBO/CFkBxBAAAEEEEAAAQQQQAABBBBAAAEEEEAAge4UIMDuzuPKXiGAAAII IIAAAggggAACCCCAAAIIIIAAAokXIMBO/CFkBxBAAAEEEEAAAQQQQAABBBBAAAEEEEAAge4UIMDu zuPKXiGAAAIIIIAAAggggAACCCCAAAIIIIAAAokXIMBO/CFkBxBAAAEEEEAAAQQQQAABBBBAAAEE EEAAge4UIMDuzuPKXiGAAAIIIIAAAggggAACCCCAAAIIIIAAAokXIMBO/CFkBxBAAAEEEEAAAQQQ QAABBBBAAAEEEEAAge4USHfnbrFXCCCAAAIIIIAAAggg0EqB48ePm/5+xse00pxtIYAAAggggAAC vSBAgN0LR5l9RAABBBBAAAEEEEAgZoG//Mu/jHkLrB4BBBBAAAEEEECgFwUYItGLR519RgABBBBA AAEEEEAAAQQQQAABBBBAAAEEEiBAgJ2Ag0QXEUAAAQQQQAABBBBAAAEEEEAAAQQQQACBXhQgwO7F o84+I4AAAggggAACCCCAAAIIIIAAAggggAACCRAgwE7AQaKLCCCAAAIIIIAAAggggAACCCCAAAII IIBALwoQYPfiUWefEUAAAQQQQAABBBCIWOCxxx4zJ0+ejHitrA4BBBBAAAEEEECg1wXSvQ7A/iOA AAIIIIAAAggggEDzAj68/sxnPtP8ylgDAggggAACCCCAAAKXBRiBzamAAAIIIIAAAggggAACCCCA AAIIIIAAAggg0JECBNgdeVjoFAIIIIAAAggggAACCCCAAAIIIIAAAggggAABNucAAggggAACCCCA AAIIIIAAAggggAACCCCAQEcKEGB35GGhUwgggAACCCCAAAIIIIAAAggggAACCCCAAAIE2JwDCCCA AAIIIIAAAggggAACCCCAAAIIIIAAAh0pQIDdkYeFTiGAAAIIIIAAAggggAACCCCAAAIIIIAAAggQ YHMOIIAAAggggAACCCCAAAIIIIAAAggggAACCHSkAAF2Rx4WOoUAAggggAACCCCAAAIIIIAAAggg gAACCCBAgM05gAACCCCAAAIIIIAAAggggAACCCCAAAIIINCRAgTYHXlY6BQCCCCAAAIIIIAAAggg gAACCCCAAAIIIIAAATbnQE8K7Ozs9OR+s9PGcOw5CxBAAAEEEEAAAQQQQAABBBBAAIHkCKST01V6 ikA0Agow+/r6XJC5vb1ttu3rnW0C7Wh0O3MtffZSnY518NjrHKAhgAACCCCAAAIIIIAAAggggAAC CHS2AAF2Zx8feheDgA+v9ZjJZE0mnWJUbgzOnbRKd8y3s8ULF4TXnXR06AsCCCCAAAIIIIAAAggg gAACCCBQWYAAu7IN73SpgMLLLTsad2hw0Nx+y3vsXmr0NaNxu/RwX96twjF2I+7tsSfA7u6jzd4h gAACCLRH4Pjx46a/nwqF7dFnqwgggAACCCCAQPcK9Nk/qad2Qvce30Tv2dr6Rkn/ffkHhZBvnj7T 8C9Ifj2c+iW8PfPCjca+XEamkZ3etuVmrrzigDv//Lnk15PLZvxTHhFAAAEEEEAAAQQQQAABBBBA AAEEIhBgBHYEiKwiWQJ+9K1/TFbv6W0UAhz7KBRZBwIIIIAAAggggAACCCCAAAIIIBC/AH/jF78x W0AAAQQQQAABBBBAAAEEEEAAAQQQQAABBBBoQIAAuwE0FkEAAQQQQAABBBBAAAEEEEAAAQQQQAAB BBCIX4AAO35jtoAAAggggAACCCCAAAIIIIAAAggggAACCCDQgAABdgNoLIIAAggggAACCCCAAAII IIAAAggggAACCCAQvwABdvzGbAEBBBBAAAEEEEAAAQQQQAABBBBAAAEEEECgAQEC7AbQWAQBBBBA AAEEEEAAAQQQQAABBBBAAAEEEEAgfgEC7PiN2QICCCCAAAIIIIAAAggggAACCCCAAAIIIIBAAwIE 2A2gsQgCCCCAAAIIIIAAAggggAACCCCAAAIIIIBA/AIE2PEbswUEEEAAAQQQQAABBBBAAAEEEEAA AQQQQACBBgQIsBtAYxEEEEAAAQQQQAABBBBAAAEEEEAAAQQQQACB+AUIsOM3ZgsIIIAAAggggAAC CCCAAAIIIIAAAggggAACDQgQYDeAxiIIIIAAAggggAACCCCAAAIIIIAAAggggAAC8QsQYMdvzBYQ QAABBBBAAAEEEEAAAQQQQAABBBBAAAEEGhAgwG4AjUUQQAABBBBAAAEEEEAAAQQQQAABBBBAAAEE 4hcgwI7fmC0ggAACCCCAAAIIIIAAAggggAACCCCAAAIINCBAgN0AGosggAACCCCAAAIIIIAAAggg gAACCCCAAAIIxC9AgB2/MVtAAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQaECAALsBNBZBAAEEEEAA AQQQQAABBBBAAAEEEEAAAQQQiF+AADt+Y7YQg8DOzk4Ma2WVCFQRsKdd4dzj/KsixdsIIIAAAggg gAACCCCAAAIIIIBAJAIE2JEwspLWCuyY/r6+y0Fia7fM1npcoK9w7pmdvh6HYPcRQAABBBBAAAEE EEAAAQQQQACB1ggQYLfGma1EKLBjw8NUOmX6bIhNQ6ClAu7cS9v8mnOvpe5sDAEEEEAAAQQQQAAB BBBAAAEEelaAALtnD31yd1zBdSrVzwjs5B7CxPZc5UNSqT578WSH8y+xR5GOI4AAAggggAACCCCA AAIIIIBAkgQIsJN0tOirCw0VHmazWadBLWxOilYJuHPNnnu5XNrYB/4CoFXwbAcBBBBAAAEEEEAA AQQQQAABBHpagAC7pw9/snZeAWKhbEifGRzIm+3tbULEZB3CRPdW55495ey5N6D02l1M4QJKog8p nUcAAQQQQAABBBBAAAEEEEAAgQQIEGAn4CDRxYKAAkQfYucyaZOxX3pNiMgZEreAP89y2YzJZjLu wok/F+PeNutHAAEEEEAAAQQQQAABBBBAAAEEelmAALuXj37C9t0H2C447O83E+OjxVHYhNgJO5gJ 6q4Pqnd2ts34+HBh1L+9cKJW+IuABO0MXUUAAQQQQAABBBBAAAEEEEAAAQQSJkCAnbAD1svdfTdI LJQSGRjIlZQSIcTu5bMjnn3359zW1rYZGho0+Xy+ZPQ151w87qwVAQQQQAABBBBAAAEEEEAAAQQQ 8AIE2F6Cx44X0GhX/+WCRdNnJibGXCkRXw+bQLHjD2NiOujDa51buVzGjI+Nmv7LZWzsiVg8FxOz Q3QUAQQQQAABBBBAAAEEEEAAAQQQSKAAAXYCD1ovd9mHit4ga+tgT4ZCbL1HkO2FeKxXwJ87ulii kdcZW/N6ctJeKEmniueV3vPz1bt+5kcAAQQQQAABBBBAAAEEEEAAAQQQqF2AALt2K+bsAAEfHOpR TSHioC0lss+G2Llc1mxubrlp/v1glwkcgxo8l0C5c8KfYzqXVKZmnw2vB7LZ4rz+/XLnGKoIIIAA AggggAACCCCAAAIIIIAAAtEKpKNdHWtDIH6BYICoAHJ7e8cM5HMmlUqZ+YUls7yyajY2Nk1/f2mZ h24MHLX/5ULY6I+CLLvvpoXBc8Jb6nzKZdNmdHjQjIwMu5HX24GbNmq+4HLRW7NGBBBAAAEEEEAA AQQQQAABBBBAAAEv0GfDmB3/gkcEOklgbX1jz+74INGfwj5UXF5eNatr6zbE3jDrNshWDWN9FeYr jNzec8UJeFNhsvYnk06btP2Ku+mHxObmphvhXth23Fts1fp37IWOfnexQ4/ZbMaoLE3ejuYfsDds 1H4Hzy899+dZuR7m7PJxN53XZ86cMefOnXObOnjwoNGX+k9DAAEEEEAAAQQQQAABBBBAAAEEuk2A ALvbjmgX7U+1AFu76gNFHzJqmoI8XZZR0LdhQ1c3etaOqtXj5cojmi3RbWfb7meqz5yZOW8uzM5d dohnl2Sp0ezT+ybs16Qb8e4cu+BagN83hdI6bzI2vNZFATVd9PBN7/tzzU8r9xhXgH327Fnz9NNP m5mZmZJ+Bfug/h8+fNjce++9Jm/D973a17/+dVvfe8vNMj09bT772c8WZ7906ZJ55JFH3P5q4nXX XWfuueee4vtJerK0tGRWVlbM1NRUU90+ceKEu4CjleiC0de+9rWm1teOhaOyaEff2SYCCCCAAAII IIAAAggggEBvC8Q/dLO3fdn7mAXCwaJCRh88aiStCxQvp9ZdkLc6TVs0xO6jsaOFU+aZ514yM+dn 3ajguPZPo5B1RUAh9nuuv9rowkKqi0b7uv3TWGv7ny5y+PNHu+1HW9cSXmv+qNvy8rI5efKkWVhY qLpq9fv06dPmG9/4hrnqqqvMfffdV3EZjab3TQFvsK2vr5cYhN8PztvJz5966inz0ksvmQMHDpgH Hnigqa7Ky18kC9o1tdIWLhylRQu7zaYQQAABBBBAAAEEEEAAAQQQcAIE2JwIiRcIh4waVas00o28 LrxI/D4Gd8AHabMXl8zS0rKr0ZzqTyl/jaUpGNdo3bn5RTO/uORGKCss9e6xbLTNKy1c83h31HU7 9vW1114zTz75ZEmYXAuLzo/XX3/dfOc73zGf/vSna1mkq+ZRwPzQQw8ZBfG93rDo9TOA/UcAAQQQ QAABBBBAAAEEukOAALs7jiN7YQV8yOjDx25FUUCZTvebs7Z8yJYtjWL3/HJ5lHjGYLsLARZ1Y3PL lSy56orDl7f7rnm3WvtzqtX7d+rUKfPEE0/s2qxuVHrs2DE3qlgji3UuvPPOO0Zh9/nz50vmf/vt t82///u/m0984hMl07v9hYJrwuvCUcai28929g8BBBBAAAEEEEAAAQQQ6A0BAuzeOM7sZZcIKLDU V19fypw5d8HV5VXt4ziDVr9ujeacOTdrrr/6SrO5uu5qRncJa0fthka7P/7447v6dPPNN5sPf/jD u6YryL799tvN7Oyseeyxx4q1mjXjG2+8YRRkqzZ2rW3//v0u9NZ5pqbXNAQQQAABBBBAAAEEEEAA AQQQQKBdAv3t2jDbRQCB+gR8oKha1HNzC2ZpuVC72AfM9a2tvrm1DY3EXlhYMvO2bIn64PtT35qY u5qASn+E6yz/wR/8QdnwOriuyclJ8/nPf37XhYWf/OQnwdlqeq5R3lfZOtr6GhwcrGkZZkIAAQQQ QAABBBBAAAEEEEAAAQTiEGAEdhyqrBOBGARciGxrT6fTKXP2nC0fslWoQ10YkR1P+RC/G9pGf1+f WbejsFW65KqjtoyI3b5aKwJ0349uf1Rwffbs2ZLdvP76680tt9xSMq3Si/HxcfPe977X/PKXvyzO cvHiRTM/P29GR0eL0+J6cuHCBaPyJxMTE+bKK6+M5NzQyHKNJD906JA5ePBgXF2Pdb26Geerr75q hoaG3EUB/dVEvW1mZsacOXPGZDIZV0amFRcW1O8333zT6DGXy7ljoAslzbQoLLT9S5cuue8VrU9/ JaDzoxHXjY0N87vf/c6srq66YzMyMtLM7rEsAggggAACCCCAAAIIIIBADAIE2DGgskoE4hBQiFwI q/tdLWqFnXGXD/H74UPqzc0NMzNzwVx/jS0jsrnWUGDk18njboFf/OIXJRN1fO++++6SadVe3HHH HebXv/61u/Gm5s1ms64+dq0B9tzcnHn44YeLm7nuuuvMRz7ykeLr8JOf/exn5oUXXjBra2vht+zF lrQLFv/oj/6oYpj99NNPm2effdYtq3D2q1/9qnn55ZfNz3/+c3uT0qVdI/0VpKqUivoVbArtf/Wr X+2aX6Hv3/7t37pZp6amzGc/+9ngYpE8V8j+6KOPFtelkfDa9+9///v2rxYWisfCz6D3brjhBvOH f/iHflLZR+3Tc88958LV4Aw/+tGPnKeO7dVXX23uvPPOEt9GLVQz+z/+4z/c+aJgVz9vwk0/C6an p80nP/lJd26F34/LQtvRuvUXBTqm5fomD53/t956a7hbJa8XFxfNd7/73V3H5n/+53+c48DAgLnr rrvcRZiSBXmBAAIIIIAAAggggAACCCDQFgEC7Laws1EE6hPwYY0Czbm5ebO8UggLfbBc39oam1vb suWZXQmReVtKJGfDokKgHu/o78Z6m8ylXnnllZKONzqq9J577jEKIDV6u95RqQqit+1If980wrVc W1lZMd/+9rfdSNhy72uaLrJoRPbf//3fm/vvv9/dfDI8r9bvt6cA9Te/+Y356U9/Gp6t+Fr9e/LJ J92o7I9+9KPF6cH1FCdefuLXX2lfwvPX+1r99tvQsgpYFYaqnnm5Jpfnn3/e1Sf/3Oc+50ZVh+fT DTg18rxS0/eeLF588UV3E88vfelLRsGrWiMWunhS7gJAePvarkaD/8M//IO7sBG+kBCHhfpQ7bzQ PNq23GUrj3LtmWeeMbro4n+mhufRdPnp4sO1115rgudYeF5eI4AAAggggAACCCCAAAIItEag/r9j bk2/2AoCCAQEFB4rWEmlCuVDNm0w5qcFZov1qbav2tcbG7bMhb2BpK+DXSkIirUzXbpyhcLBppGu jbRrrrnGHD9+vO7wutZtKRz/5je/WTa8LheYK1g8efKkCz732obOpb3C6+CyKsmh8ha+6XujWivX t2rLNPL+j3/844rhdXB9KoPx1FNPBSe55xqVXi681j6W20/5KnD1rdw8/j3/GLTQRYb//d//3RXq 6meM1qXHcFNgr/2s1pq10Pr1FwWVzoty+6q/ItDFlXCTtWzDP7O0f0EPv5zOseDIej+dRwQQQAAB BBBAAAEEEEAAgdYKMAK7td5sDYGGBBS46KvPBshnbAmPDTuCM2VHY5cLlhraQA0L+W0pvJw5N2tu sGVElikjUoNc7bOEg7Urrrii9oVbOKdGB4dHF2u0t8qd+CBQZUAUGAbne+KJJ8xXvvKVmnqqkicq FSIDlY74v//7P/PSSy+VLKswUrW21XSjS31p9OxDDz1UnE91sx944IHi61Y+UUmUD3zgA65ciEZd ax80kjhoovrL4aZR1cGmixEqN+LDWn0PPv744+b06dPF2c6fP1/4GWHD2HotwuFwPp93x1I38/RN pVB0/M6dO+cnuRHPOs469tVaoxYaZV6utI7OjRtvvNFtVh4qffLWW28Vu/HOO++410eOHHHTVDYk 7Kr9/PjHP16sra6SNf/1X//lRsb7FclVx+iqq67yk3hEAAEEEEAAAQQQQAABBBBosQAjsFsMzua6 V8CHjz5s3t7esWUFIvpSeN3Xby5enDPLq2tG4yF9oNxKUW3TdsUsLC6ZS/NL6oQrnRDZflov76f9 8qat3Md2bUujRsNNJUQ6rSnQe/vtt0u69alPfcqobIkPr/WmQk2F1apL7JtCRIW41ZqC0y9/+cvm 6NGj7jzft2+fC1RV3zjYNIK5U5tusvi1r33N3Hzzza5EiMp7vP/97zef/vSnS753FWYHg2i9Vmjr m+p268KAD681XWFwuAa1vlc0irreptBWN/r0TdtR+Y1geK33dHNDlTvRsQi2cgF88H09b9RCy/7g Bz8oKc+i+uE6r3x4rXnkoXPw8OHDellswZuZ6qJLsOmGp3/2Z39WDK/1nm6yqePzvve9Lzir+eEP f1jymhcIIIAAAggggAACCCCAAAKtFSDAbq03W+tCAR+4FsJdf6PFPnsTt5TJ2C89Nv1lR1vnc1lz 7vysrSvc+vIh/rBpXzUKfF2jsM9fcH3SSPCm9y9gFXb0vr4P3fp44cKFkl1TkNiOixQlnSjzIhzm qU6wH+Uanl2h7b333lsyuVrIqv2+7777SpbxLxRgK6z0TedGp7aPfexjZbt24MABs3///pL3NMLc t3Cd7vBrP58eP/ShDxnd1HJsbMwdg3C4HJy30nN/A03/vm4KqXVWau95z3tK3lL5kmqtUQutVyOp g+33f//3XSAenOafazR1sPnR4ro4FPz+0oWWvUblaxsK7H3TBQWNNKchgAACCCCAAAIIIIAAAgi0 R4ASIu1xZ6tdIuACXTsKWW1ra9ukU/2m34axC4vLZn5h0Y0cjCKE1HYymbQ59c5Zd2M8BTBRrLfe w6Bt2jHYbl/fevusGbB/gq/SCFH0RfvY358yoyNDZnR40G1j05qmrKla0Lrefidh/uDoZfU3CtM4 9lulJILtzjvvDL7c9VwlPhQ6q8yDWrXAU3W/wxbBlWo0b3C0umox7zV/cNlWPdeoc5UuqdQmJyfN 2bNni297G01QcKoQ35cZUYCtGyYqvL/ppptKzguVFtFXM+2DH/yg0ZcCXt18Uhck9moKy4PN9zM4 Lfi8GQvte/B80Xl02223BVdf8lzbuvXWW90yulDgy8ucOnWqZD6Nalf5kL2aXIOlSxSk11IqZa91 8h4CCCCAAAIIIIAAAggggEBjAgTYjbmxFAJOQCGjglV9ZbNpM3tp3rz86huuxIYCbftOZFLa1tra ugvr2hluKsJWuzS/aH7z3G+j3Ue7bgXWoyPD5jpbY3tyfNTdNFL72859juwg7rEihWrBpmC2E1sw bFX/VOKhWguGnNqvvULncEAaXndwBLbeU3/2GjEcXr4Vr6uFo+H3gz7q38TEhFGpFt9WV1fNT37y E/elMhcqlaGgNnzO+PkbedTo7fAI7vn5eaPwd2ZmxpUZ0YWD8PGvtq3wvobnD78ftNB2g037Xq1p VHq4+ZHYfrpK2ahm9l4tGJxrvmCZlb2W4z0EEEAAAQQQQAABBBBAAIHoBQiwozdljT0ioNBaTWGc QrU3T58xL778mlleWS2MFtYoaft+FBG2W48boVwYed3O0cg+SFYfVuyf1ke6j/KynovLK+bS3Lx5 z/XXmKNHDroQ23K65rdfeNU9/x8eHi7ZmU4MsBVe+vPed7aWGsh+Xv+oGtqVblCp8HavloTjr1Hi e7VqI8Y/8YlPmEceeaSkFrZfn2pWq5yFvlQPWiO9ddNG1XRutmkE9n//93+7Ee71BtWVtt2MRXCk vdZfS4Bdrh/hWuka2V3veSt3GgIIIIAAAggggAACCCCAQHsEqIHdHne22gUCCtIUMuZtvdgzM+fN 8y+9YhaXVtyf/ytYUm1oBVV6bPbLredyTeR2htc6bNq+70Pk+2itnJ29YaUsZXr23HlXa1vWSQgv mzm1w8FmvSGb3/bKyor59a9/bcLlPvz7jT4q4IyiBUcXh9enutlJb8EbVzayLwpq//RP/7RqKK3y PboB5MMPP1zTzTEr9UXr+ad/+ifzrW99y438jiq81vaasQjX/64Whlfav/B6Ks231/TgjTX3mo/3 EEAAAQQQQAABBBBAAAEEohdgBHb0pqyxRwQU4qpW7bINC0/b0dcaNawbLdrJxYA3Dop2h7hxb9+H 4yrJsmRtT1nb8dFRVwPcvxeHayesU/WPg6NOX3zxRXPVVVfV3bWf/vSnboTuz372M3eOarSzRvU2 24I3ttO6dC6M2mNTb1MNaNreAvrZ8id/8idGo4d/+ctfmrfeesuolEi5pu8LjZzW+7oBYb3tn//5 n43KapRrOsYq0aK/EFDpEn19//vfLzdr5NPCI651YaaRFi47o/XqQlk9LXzu17Ms8yKAAAIIIIAA AggggAACCDQnUN9vcM1ti6UR6CoBhUa6seLZmQvm/KU5k7GBiKbZWK/rRwrHeSB9QC7LlL2p48X5 BVtve8Ec2j9l1jd0w8g4t97edV9zzTXmV7/6VbETunFcI+2NN94oLqaawpWCz+JMNT4Jl6lQCPil L32pxqWZrREBmX/0ox91i+pYPvfcc+bVV181s7OzxRs9+vXqgke9AfYPf/jDXeG1wlrdxPC6667b dYFC225VO3LkSMmmahlJrdHjuiGlbuLof5boIkuwjIhuhvne9763ZN28QAABBBBAAAEEEEAAAQQQ 6FwBAuzOPTb0rMMFFLD29/fZUhdL7kulRJRfd3PA2spDsrOjGzqmzJwNrxcWFs2Rg9PFCwSt7Ecr t3X77beXBNgK43Tzvg9/+MM1d0NlR8I3oPvgBz9Y8/LVZlRorZITauqfvg98UFhp2ddee82Firrp 4KFDh0z4xn2VluvV6SqxopsnKnS95557igz6frjtttvclyZqhL1KxfimgLeW4+Hn16PqkQfb0aNH zf333x+cVPI8fENEbS+uFr6pZC0B9re//e3iDTBVkueBBx5wN6d88803i93UhaFqAbZKhshWo7VV ZzzKG2YWO8ITBBBAAAEEEEAAAQQQQACBmgQIsGtiYiYEdgsotOuz2c329o6rhV0I8eILc3b3oLun 6EKATFX7ulD/Wq+721elDjRy9OzZs8WD+/zzz5trr73WhWjFiRWeqOb1E088UfKuwmKtM6qm9QXL TTz++OPm4x//eMXVK0z/z//8z8sXHwqzff7zn48tEAyH6XEGrBV3uok3/vVf/9UEQ+Jjx44Zjcwv 1z7wgQ+Y3/72tyYY7Gr0sQ9ba7EIHktt49577y23qeI0XYwINn1vxtkU2mvkuZr+kkDBvkL2Su3i xYvFt3Ts9+/f7y7oBP+ywZdj2etCyg9+8AMT/EsGjYRXSRcaAggggAACCCCAAAIIIIBA6wW4iWPr zdli1wjYmxnagFVlRBQ8Ji0oS8JhkKlKs2jUrx3na42T0Ovm+qha1cHgUQYaVfrSSy/tueKZmRnz L//yLy7sD8546623Bl82/fzmm28uWYdGfGvbldr3vve9ku8NhYY+YK20TDPTw6FklDckbKZftS4b Lpvx9NNPV1xU50b45oLBUcu1WATPNW1or0D63/7t30ouXlSbv2LH63gj7PGjH/2o4tJ6z4fdmmls bMzNqxrwwZtJyu273/1uxfXofA6O2NaMUX8fVdw4byCAAAIIIIAAAggggAACCOwSIMDeRcIEBGoT UIkLhT35fM4MDuRtSLddEtTVthbmqiSgkGl7e8uMDA+Z4aFBG0xtlwS7lZZL+nSFjrfcckvJbshC tYofeughV2JkyZatUVN4+fLLL5uTJ0+axx57bFfpEAV31UollGyohhe/93u/527oF5xV21Y5i2BT 3771rW+VjCbX++EAPLhMFM/DgaxqResmiAokVZqj09v73ve+ki5qVP2jjz5aMspaM+gcePjhh0sC W507wf0PPtcy5SzCIbdGgIdDf43wVnitkcvhFp43/H6zr++77z5bqundjyoaMa7vA/894Nf/4x// 2Lzwwgv+pXsMhs533313yXs6F775zW/uCuQ1ol3nrb7nfNMFtBtvvNG/5BEBBBBAAAEEEEAAAQQQ QKDFApQQaTE4m+seAZW42LA3FTwwPWXO2Bs5vvq7N22QPeBC7XBw1D173Zo9UXik0Gp5Zc1ceeSw mdo3Uay73JoetHcrH/rQh1yIqJvyBZuCxJ///OfuKzi93HOVPPjkJz9Z7q2mp33sYx9zgXlwRaoX /Mwzz5icrQWvVu7GkerTHXfcEVwsluc6d4IjiRVgq2kU7p//+Z+75536P4WlV199tXn99deLXVTY qtBW/deXQuPwyGvN/P73v7+4jH9SzULb0o0hfVNA/Hd/93du9LJ+jilA9zXP/TzBx3LHOfh+s89V QkQXTYIlQPR98I//+I/uL1/01y/qQ/B4a5sauR0MnbWfGp2uEiu+aV8VYstcrip3U25fg3XI/bI8 IoAAAggggAACCCCAAAIItE7g3WFNrdsmW0KgKwQU7ihoTaX6zVVHD5t9k+MuWNKNHX0LjuLz03gs LxC0StkAUiHdlDW98opDLszW+710YeCuu+5qOOzVTee++MUvloeOYKrqCmtkrIK/YNMxUphYLtQc Hh42f/zHfxycPbbnhw8fLrvu8M0ty87UARNlq7A/3NR/ha7h8FrfFxphHAxs/bLVLHSD0NHRUT+7 e9Rx1A0kVU86HOiq/ItubOib+hT3yHYF88HR1H7b+hmhMDscXmt/PvWpT/nZio+f+9znXLBdnHD5 ifZR6wnvq96+88473QWF8DK8RgABBBBAAAEEEEAAAQQQaJ0AAXbrrNlSlwkoNNKXaq5OjI+a2266 wYyODNvwbt3Ygs32PeOCVz3yVd1AI0UV/Ss8W7Eh6OjosLnt5uPOVsbeu8tOoz13R6OVNWL4+uuv 3xUWl1twcnLS3WjugQceKCm7UG5eP03uwRYOpcPv+3k1olV9U0CqY1OpaYSs9uMrX/lK2fk0wjbY wtsPvqfn4f6EX2sejTyvdONKBZVRt3Afwq/D2wvvY/i15tcNA2+77TZ7gazUJ7guufsLA8ePHw++ VXxei4W2pRuF7nUcB+xfl2gksm7AqdI0wfbss88WX4b3Pfy6OOPlJ+F9D7/28+uvEr7whS+YwcFB P2nXo6wUdn/5y1/e9Z4mqC8KtvUXBBpxvVebnp52x6DcRYG9luM9BBBAAAEEEEAAAQQQQACB6AX6 bFj0bqHH6NfPGhFoWGBtfaPhZVuxoL51FPj4byE9X7OjEd85c968cfpt+6f3i2bL1sjeKxRqRT+T sg05ajT76PCIG3V96OCUydmQKejrzTt1n3LZTKxdm5ubczdMVBkE1QDWuaXQWoFinDdGrGWnVGrC 39BRQaLKNRw6dKit/dKFj1deecWdQ6r1rFBbQWzSmkZDy1bHXfukY63A2d+ksJb9qcVCI5pPnTrl zrH5+Xk3MvvKK690Fylq2Uar5tHPgdOnT7u65rogoXNN/az3e0Ajt7UefWlkuzz11wW6KONL4bRq n9gOAggggAACCCCAAAIIIIBAZQEC7Mo2vNNmgU4PsMXjA1X/qEBRoYjCom1dG9LlocqDU9ss3GGb v2zVbw0VgGq0pFy9rX/ssF6XdCfuALtkY7xAAAEEEEAAAQQQQAABBBBAAAEEekCgtIBpD+wwu4hA lAIKrH2wGgxbVTaB1riALH1d26Bx42tkSQQQQAABBBBAAAEEEEAAAQQQQACBJAoQYCfxqNHnjhII Bqw+xNYjrXmBoG3za2MNCCCAAAIIIIAAAggggAACCCCAAAJJEyDATtoRo78dKaCgVc0/dmQnE9op TBN64Og2AggggAACCCCAAAIIIIAAAgggEIFAfwTrYBUIIIAAAggggAACCCCAAAIIIIAAAggggAAC CEQuQIAdOSkrRAABBBBAAAEEEEAAAQQQQAABBBBAAAEEEIhCgAA7CkXWgQACCCCAAAIIIIAAAggg gAACCCCAAAIIIBC5AAF25KSsEAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQQCAKgb4d26JYEetAAAEE EEAAAQQQQAABBBBAAAEEEEAAAQQQQCBKAUZgR6nJuhBAAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQi EyDAjoySFSGAAAIIIIAAAggggAACCCCAAAIIIIAAAghEKUCAHaUm60IAAQQQQAABBBBAAAEEEEAA 0QW4vgAAA25JREFUAQQQQAABBBCITIAAOzJKVoQAAggggAACCCCAAAIIIIAAAggggAACCCAQpQAB dpSarAsBBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAgMgEC7MgoWRECCCCAAAIIIIAAAggggAACCCCA AAIIIIBAlAIE2FFqsi4EEEAAAQQQQAABBBBAAAEEEEAAAQQQQACByAQIsCOjZEUIIIAAAggggAAC CCCAAAIIIIAAAggggAACUQoQYEepyboQQAABBBBAAAEEEEAAAQQQQAABBBBAAAEEIhMgwI6MkhUh gAACCCCAAAIIIIAAAggggAACCCCAAAIIRClAgB2lJutCAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQ iEyAADsySlaEAAIIIIAAAggggAACCCCAAAIIIIAAAgggEKUAAXaUmqwLAQQQQAABBBBAAAEEEEAA AQQQQAABBBBAIDIBAuzIKFkRAggggAACCCCAAAIIIIAAAggggAACCCCAQJQCBNhRarIuBBBAAAEE EEAAAQQQQAABBBBAAAEEEEAAgcgECLAjo2RFCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAlEKEGBH qcm6EEAAAQQQQAABBBBAAAEEEEAAAQQQQAABBCITIMCOjJIVIYAAAggggAACCCCAAAIIIIAAAggg gAACCEQpQIAdpSbrQgABBBBAAAEEEEAAAQQQQAABBBBAAAEEEIhMgAA7MkpWhAACCCCAAAIIIIAA AggggAACCCCAAAIIIBClAAF2lJqsCwEEEEAAAQQQQAABBBBAAAEEEEAAAQQQQCAyAQLsyChZEQII IIAAAggggAACCCCAAAIIIIAAAggggECUAgTYUWqyLgQQQAABBBBAAAEEEEAAAQQQQAABBBBAAIHI BAiwI6NkRQgggAACCCCAAAIIIIAAAggggAACCCCAAAJRChBgR6nJuhBAAAEEEEAAAQQQQAABBBBA AAEEEEAAAQQiEyDAjoySFSGAAAIIIIAAAggggAACCCCAAAIIIIAAAghEKUCAHaUm60IAAQQQQAAB BBBAAAEEEEAAAQQQQAABBBCITIAAOzJKVoQAAggggAACCCCAAAIIIIAAAggggAACCCAQpQABdpSa rAsBBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAgMoH/B8iKWm0KBM7WAAAAAElFTkSuQmCC --000000000000de671a05be240913-- From nobody Mon Mar 22 11:40:31 2021 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 4E1B13A0887 for ; Mon, 22 Mar 2021 11:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.405 X-Spam-Level: X-Spam-Status: No, score=0.405 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 tHXFV3ojo9PB for ; Mon, 22 Mar 2021 11:40: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 03EE33A0868 for ; Mon, 22 Mar 2021 11:40:23 -0700 (PDT) Received: from [192.168.1.22] (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 12MIeHx6000349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 Mar 2021 14:40:19 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8DE128E8-DAFB-4353-936C-4C3597298BF6" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 22 Mar 2021 14:40:17 -0400 In-Reply-To: Cc: Benjamin Kaduk , Alan Karp , GNAP Mailing List , Mark Miller To: Adrian Gropper References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2021 18:40:29 -0000 --Apple-Mail=_8DE128E8-DAFB-4353-936C-4C3597298BF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Adrian, I think this shows the problem with the terminology as it=E2=80=99s been = applied in this conversation, which I=E2=80=99ve tried to shine light on = before. What you and others are calling the =E2=80=9CRS=E2=80=9D is = really the =E2=80=9CAS and RS working together=E2=80=9D =E2=80=94 = everything to the right of the line. When Denis had brought up = =E2=80=9Celiminating the AS=E2=80=9D in another thread, what he=E2=80=99d = really done is labeled everything to the right of the line as the = =E2=80=9CRS=E2=80=9D. Of course, the irony here is that everything to = the right of the line used all be called the =E2=80=9CAS=E2=80=9D or = simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say below, I = don=E2=80=99t want the client to have visibility on what happens on that = side.=20 Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the diagram = is not the AS, as far as GNAP is concerned. It does not issue an access = token that the RS will accept. The elements to the left of the line = could be a lot of things, but they are NOT the AS =E2=80=94 by = definition. The client lives over on the left, but so do any external = inputs to the AS. These could be policy inputs on behalf of the RO, they = could be presentation artifacts, they could be federated logins, they = could be the output of policy decisions. How the AS comes to trust those = things is up to the AS=E2=80=99s implementation. It=E2=80=99s something = we can talk about, but ultimately GNAP won=E2=80=99t be in any position = to dictate because in practice some AS=E2=80=99s are simply going to = internalize all policies and we will never successfully force those = open.=20 But with all that in mind, I think the key here is going to be looking = at what the inputs to the AS are, and how those can be defined in an = interoperable way for AS=E2=80=99s that can accept them. I think = there=E2=80=99s a lot of room for innovation and flexibility here that = doesn=E2=80=99t break the trust model or core use cases. If I have an = AS-RS set that won=E2=80=99t accept my favorite flavor of policy engine = inputs, then I can decide not to use that one. But this is a very = different question than saying the RS itself needs to accept my own AS = =E2=80=94 and we can=E2=80=99t keep conflating these two models. So to me, GNAP can support a Zero Trust Architecture by LEVERAGING the = AS, not by subsuming or eliminating it. It is in fact the AS, not the = client and not the RS, that will request and consume the results of a = privacy-preserving zero-trust policy query thing. Anything that happens = downstream from that is of little concern to the zero-trust components = because, as you point out, it=E2=80=99s on the =E2=80=9Cother side=E2=80=9D= of the line.=20 I think we got this basic component model pretty right in OAuth: the AS = and RS and client working together. Where OAuth misses the mark is the = assumption that the user has to log in to the AS through a webpage and = interact directly, thereby proving they=E2=80=99re the RO. It=E2=80=99s = this latter space where I think we can both push innovation and also = address the important and compelling use cases like the ones you=E2=80=99r= e bringing. =E2=80=94 Justin > On Mar 22, 2021, at 2:14 PM, Adrian Gropper = wrote: >=20 > I'm sorry, Justin. As a Resource Owner, I look at the RS trust = boundary (the dotted line in the diagram) as being the RS. I don't = expect any visibility into what's going on on the right.=20 >=20 > My problem with the framing you propose is that requests are going to = the RS (or the AS-RS) and I don't want to share my policies with the = AS-RS. I want to keep the RS and AS-RS as ignorant as possible. >=20 > Adrian >=20 > On Mon, Mar 22, 2021 at 1:48 PM Justin Richer > wrote: > Adrian, >=20 > What you=E2=80=99re discussing below, in terms of logging in to a = site, is not approaching the RS. You are in fact approaching the client, = and identifying both the AS and RS to the client. The client is a client = of your identity in this model, and the RS is part of the identity = provider. It=E2=80=99s really important that we don=E2=80=99t conflate = the RS and client in this way as it leads to a lot of confusion = downstream and a lot of broken trust boundaries. >=20 > With that model in mind, approaching the =E2=80=9CRS" and providing it = your identity is really just a case of the =E2=80=9Cfederated login to = AS=E2=80=9D pattern that we discussed on the WG call. The user here = approaches an RS, which has its own AS. To share things from this RS, = the RO has to authenticate to the RS=E2=80=99s AS. This particular AS = allows the RO to do so using an external identity =E2=80=94 in which = case, the AS is now a =E2=80=9Cclient=E2=80=9D of a separate, = disconnected (but layered) delegation. The ultimate client that = eventually calls the RS down the way may or may not know about these = layers.=20 >=20 > > This same AS, which is closely tied to the RS and trusted by the RS, = might also take in FIDO credentials, or DIDs, or any number of other = proof mechanisms. The output of this is an access token the RS trusts, = but the input is up to the AS. The RS is not what you=E2=80=99re logging = in to. >=20 > =E2=80=94 Justin >=20 >> On Mar 22, 2021, at 1:28 PM, Adrian Gropper > wrote: >>=20 >> I too am in favor of avoiding consolidation and correlation. Right = now, when I approach a service provider (RS) for the first time, I'm = offered the opportunity to identify my persona as: email, sign-in with = Google, Facebook, or Apple. I know there are people who try to create = one-off email addresses but that is mostly a waste of time.=20 >>=20 >> So, along come FIDO2 and DID wallets to the rescue. Now, in theory, I = have a way to start out my RS relationship pseudonymously.=20 >>=20 >> When I want my resource to be discovered or shared I will post that = RS URL including my pseudonym. If I then want to introduce a mediator in = front of my AS or messaging service endpoint, I have that option. If I = want to keep requests away from the mediator, I would publish an = encryption key along with my pseudonym. >>=20 >> - Adrian >>=20 >>=20 >>=20 >> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer > wrote: >> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk > wrote: >> >=20 >> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote: >> >> @Alan Karp > = shared a talk about the Principle Of Least >> >> Authority (POLA) in a recent comment >> >> = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment= -803099693 = >> >> I recommend it. >> >>=20 >> >> We might expect a protocol with authorization in the title to use = authority >> >> as a core principle. I advocate for a GNAP design that maximizes = the power >> >> of the RO, to be seen as a human rights issue when the RO is a = human. This >> >> causes me to ask how to combine better security with better human = rights in >> >> GNAP. >> >>=20 >> >> Who should have the least authority in the GNAP design? >> >>=20 >> >> The AS derives authority as a delegate of the RO. If we ask the RO = to >> >> partition limited authority across dozens of different ASs by = domain and >> >> function, then we are not using technology to empower the = individual. >> >> Probably the opposite, as we introduce consent fatigue and burden = normal >> >> people to partition their lives into non-overlapping domains. >> >>=20 >> >> My experience says we should aim for one AS per persona because = that maps >> >> into the way we manage our public and private identities. POLA = would then >> >> teach care in keeping ASs and RSs related to work / public = separate from >> >> ASs and RSs related to private life so that a policy vulnerability = in our >> >> delegation to an AS would have the least likelihood of harm. >> >=20 >> > Thinking about how least authority/least privilege would apply to = GNAP >> > seems like a useful exercise. I do want to point out some = potential >> > pitfalls with one-AS-per-persona that we can also be aware of. If >> > one-AS-per-persona becomes one-persona-per-AS as well, then the = AS's >> > identity in effect also serves as a persona identity and there are = privacy >> > considerations to that. If, on the other hand, the >> > multiple-personas-per-AS (presumably corresponding to multiple = humans) >> > route is taken, we should consider whether that would lead to = various >> > (e.g., market) forces driving consolidation to just a handful of >> > super-popular AS services. That topic is a current matter of = concern to >> > some IETF participants. >> >=20 >>=20 >> Hi Ben, big +1 to this. This is something that we discussed ages ago = in the UMA working group, and it=E2=80=99s one of the biggest problems = with the personal AS (and personal data store) model. This kind of thing = makes RS-first trust models really difficult in practice. >>=20 >> As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that = wants to access my medical information. It calls an RS and requests = access, but it hasn=E2=80=99t been granted anything yet. Now I as the RO = have set up the RS so that it talks to my personal AS, that only I use. = In addition to the RS having to be able to figure out which medical = records are being requested from the context of the unauthenticated = request (which means it needs identifiers in the URL or something = similar for the RS to be able to tell, assuming that it protects data = for more than one person). So this client software doesn=E2=80=99t know = who I am and doesn=E2=80=99t know my medical record information, makes a = completely unauthorized request to the RS, and the RS says =E2=80=9CGo = to Justin=E2=80=99s personal AS to get a token=E2=80=9D. The client can = now make a direct correlation between the data that=E2=80=99s being = protected at the RS and the person running the AS that protects it. = Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This = is a design feature in the good case, and terrifying in the bad case. >>=20 >> If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please = talk to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t = exposed anything at all. And from the perspective of both the patient = and the RS, this is more privacy-preserving, and it=E2=80=99s really the = least surprising option. Once the client gets to the AS, it can start a = negotiation of figuring out who the RO is for the information being = accessed. >>=20 >> On top of this, the usability expectations of people managing their = own AS, or set of AS=E2=80=99s for multiple personas to keep things = separate, is a huge burden. Even in the tech community, I know people = who can=E2=80=99t reliably manage more than one email address for = different purposes. I wouldn=E2=80=99t expect my partner to do that =E2=80= =94 they have trouble enough balancing all the logins and sessions = required for different kids remote schooling, I couldn=E2=80=99t imagine = them having to understand all the requirements for managing multiple = authorization servers and associated policies. I also don=E2=80=99t = expect any person to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve = been on the internet for decades and I can barely keep tabs on my GPG = keys, and only use them when I am forced to. This is exactly the kind of = =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions above, = people will just want to outsource that to someone else, and the reality = will be a few popular providers. >>=20 >> In which case, we could end up doing a ton of work to allow an RS = choice only to end up with a world where the RS ends up making a limited = choice anyway. We see how that plays out with OpenID Connect =E2=80=94 = RP=E2=80=99s could allow arbitrary IdPs but they choose Google because = it works and that=E2=80=99s where the users are. (And that=E2=80=99s not = to say anything of the proprietary OIDC-like protocols, but that=E2=80=99s= another discussion). >>=20 >> For further reading on these topics, I recommend both =E2=80=9CWhy = Johnny Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems = Fail=E2=80=9D. >>=20 >> So what does this have to do with GNAP? I think we can be clear-eyed = on what kinds of expectations we have for the participants. If we expect = users (RO=E2=80=99s) to have to set up the AS-RS relationship, or expect = them to carry their AS, or manage their personal keys =E2=80=94 I think = we=E2=80=99ve lost the battle for relevance. >>=20 >> =E2=80=94 Justin >=20 --Apple-Mail=_8DE128E8-DAFB-4353-936C-4C3597298BF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Adrian,

    I = think this shows the problem with the terminology as it=E2=80=99s been = applied in this conversation, which I=E2=80=99ve tried to shine light on = before. What you and others are calling the =E2=80=9CRS=E2=80=9D is = really the =E2=80=9CAS and RS working together=E2=80=9D =E2=80=94 = everything to the right of the line. When Denis had brought up = =E2=80=9Celiminating the AS=E2=80=9D in another thread, what he=E2=80=99d = really done is labeled everything to the right of the line as the = =E2=80=9CRS=E2=80=9D. Of course, the irony here is that everything to = the right of the line used all be called the =E2=80=9CAS=E2=80=9D or = simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say below, I = don=E2=80=99t want the client to have visibility on what happens on that = side. 

    Note= well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the diagram is = not the AS, as far as GNAP is concerned. It does not issue an access = token that the RS will accept. The elements to the left of the line = could be a lot of things, but they are NOT the AS =E2=80=94 by = definition. The client lives over on the left, but so do any external = inputs to the AS. These could be policy inputs on behalf of the RO, they = could be presentation artifacts, they could be federated logins, they = could be the output of policy decisions. How the AS comes to trust those = things is up to the AS=E2=80=99s implementation. It=E2=80=99s something = we can talk about, but ultimately GNAP won=E2=80=99t be in any position = to dictate because in practice some AS=E2=80=99s are simply going to = internalize all policies and we will never successfully force those = open. 

    But = with all that in mind, I think the key here is going to be looking at = what the inputs to the AS are, and how those can be defined in an = interoperable way for AS=E2=80=99s that can accept them. I think = there=E2=80=99s a lot of room for innovation and flexibility here that = doesn=E2=80=99t break the trust model or core use cases. If I have an = AS-RS set that won=E2=80=99t accept my favorite flavor of policy engine = inputs, then I can decide not to use that one. But this is a very = different question than saying the RS itself needs to accept my own AS = =E2=80=94 and we can=E2=80=99t keep conflating these two = models.

    So to = me, GNAP can support a Zero Trust Architecture by LEVERAGING the AS, not = by subsuming or eliminating it. It is in fact the AS, not the client and = not the RS, that will request and consume the results of a = privacy-preserving zero-trust policy query thing. Anything that happens = downstream from that is of little concern to the zero-trust components = because, as you point out, it=E2=80=99s on the =E2=80=9Cother side=E2=80=9D= of the line. 

    I think we got this basic component model pretty right in = OAuth: the AS and RS and client working together. Where OAuth misses the = mark is the assumption that the user has to log in to the AS through a = webpage and interact directly, thereby proving they=E2=80=99re the RO. = It=E2=80=99s this latter space where I think we can both push innovation = and also address the important and compelling use cases like the ones = you=E2=80=99re bringing.

     =E2=80=94 Justin

    On Mar = 22, 2021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I'm sorry, Justin. As a Resource = Owner, I look at the RS trust boundary (the dotted line in the diagram) = as being the RS. I don't expect any visibility into what's going on on = the right. 

    My problem with the framing you propose is that requests are = going to the RS (or the AS-RS) and I don't want to share my policies = with the AS-RS. I want to keep the RS and AS-RS as ignorant as = possible.

    Adrian

    On Mon, Mar = 22, 2021 at 1:48 PM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    What you=E2=80=99re discussing below, in terms of logging in = to a site, is not approaching the RS. You are in fact approaching the = client, and identifying both the AS and RS to the client. The client is = a client of your identity in this model, and the RS is = part of the identity provider. It=E2=80=99s really important that we = don=E2=80=99t conflate the RS and client in this way as it leads to a = lot of confusion downstream and a lot of broken trust = boundaries.

    With= that model in mind, approaching the =E2=80=9CRS" and providing it your = identity is really just a case of the =E2=80=9Cfederated login to AS=E2=80= =9D pattern that we discussed on the WG call. The user here approaches = an RS, which has its own AS. To share things from this RS, the RO has to = authenticate to the RS=E2=80=99s AS. This particular AS allows the RO to = do so using an external identity =E2=80=94 in which case, the AS is now = a =E2=80=9Cclient=E2=80=9D of a separate, disconnected (but layered) = delegation. The ultimate client that eventually calls the RS down the = way may or may not know about these layers. 
    <PastedGraphic-1.png>
    This same AS, which is closely tied to the RS and trusted = by the RS, might also take in FIDO credentials, or DIDs, or any number = of other proof mechanisms. The output of this is an access token the RS = trusts, but the input is up to the AS. The RS is not what you=E2=80=99re = logging in to.

     =E2=80=94 Justin

    On Mar = 22, 2021, at 1:28 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I too am in favor of avoiding = consolidation and correlation. Right now, when I approach a service = provider (RS) for the first time, I'm offered the opportunity to = identify my persona as: email, sign-in with Google, Facebook, or Apple. = I know there are people who try to create one-off email addresses but = that is mostly a waste of time. 

    So, along come FIDO2 and DID wallets to = the rescue. Now, in theory, I have a way to start out my RS relationship = pseudonymously. 

    When I want my resource to be discovered or shared I will = post that RS URL including my pseudonym. If I then want to introduce a = mediator in front of my AS or messaging service endpoint, I = have that option. If I want to keep requests away from the mediator, I = would publish an encryption key along with my pseudonym.

    - Adrian



    On Mon, Mar 22, 2021 at 9:55 AM Justin = Richer <jricher@mit.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin = Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhkarp@gmail.com> shared a talk = about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#i= ssuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to = use authority
    >> as a core principle. I advocate for a GNAP design that = maximizes the power
    >> of the RO, to be seen as a human rights issue when the RO is a = human. This
    >> causes me to ask how to combine better security with better = human rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the = RO to
    >> partition limited authority across dozens of different ASs by = domain and
    >> function, then we are not using technology to empower the = individual.
    >> Probably the opposite, as we introduce consent fatigue and = burden normal
    >> people to partition their lives into non-overlapping = domains.
    >>
    >> My experience says we should aim for one AS per persona because = that maps
    >> into the way we manage our public and private identities. POLA = would then
    >> teach care in keeping ASs and RSs related to work / public = separate from
    >> ASs and RSs related to private life so that a policy = vulnerability in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to = GNAP
    > seems like a useful exercise.  I do want to point out some = potential
    > pitfalls with one-AS-per-persona that we can also be aware = of.  If
    > one-AS-per-persona becomes one-persona-per-AS as well, then the = AS's
    > identity in effect also serves as a persona identity and there are = privacy
    > considerations to that.  If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple = humans)
    > route is taken, we should consider whether that would lead to = various
    > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.  That topic is a current matter of = concern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in = the UMA working group, and it=E2=80=99s one of the biggest problems with = the personal AS (and personal data store) model. This kind of thing = makes RS-first trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that = wants to access my medical information. It calls an RS and requests = access, but it hasn=E2=80=99t been granted anything yet. Now I as the RO = have set up the RS so that it talks to my personal AS, that only I use. = In addition to the RS having to be able to figure out which medical = records are being requested from the context of the unauthenticated = request (which means it needs identifiers in the URL or something = similar for the RS to be able to tell, assuming that it protects data = for more than one person). So this client software doesn=E2=80=99t know = who I am and doesn=E2=80=99t know my medical record information, makes a = completely unauthorized request to the RS, and the RS says =E2=80=9CGo = to Justin=E2=80=99s personal AS to get a token=E2=80=9D. The client can = now make a direct correlation between the data that=E2=80=99s being = protected at the RS and the person running the AS that protects it. = Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This = is a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please = talk to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t = exposed anything at all. And from the perspective of both the patient = and the RS, this is more privacy-preserving, and it=E2=80=99s really the = least surprising option. Once the client gets to the AS, it can start a = negotiation of figuring out who the RO is for the information being = accessed.

    On top of this, the usability expectations of people managing their own = AS, or set of AS=E2=80=99s for multiple personas to keep things = separate, is a huge burden. Even in the tech community, I know people = who can=E2=80=99t reliably manage more than one email address for = different purposes. I wouldn=E2=80=99t expect my partner to do that =E2=80= =94 they have trouble enough balancing all the logins and sessions = required for different kids remote schooling, I couldn=E2=80=99t imagine = them having to understand all the requirements for managing multiple = authorization servers and associated policies. I also don=E2=80=99t = expect any person to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve = been on the internet for decades and I can barely keep tabs on my GPG = keys, and only use them when I am forced to. This is exactly the kind of = =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions above, = people will just want to outsource that to someone else, and the reality = will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice = only to end up with a world where the RS ends up making a limited choice = anyway. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99= s could allow arbitrary IdPs but they choose Google because it works and = that=E2=80=99s where the users are. (And that=E2=80=99s not to say = anything of the proprietary OIDC-like protocols, but that=E2=80=99s = another discussion).

    For further reading on these topics, I recommend both =E2=80=9CWhy = Johnny Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems = Fail=E2=80=9D.

    So what does this have to do with GNAP? I think we can be clear-eyed on = what kinds of expectations we have for the participants. If we expect = users (RO=E2=80=99s) to have to set up the AS-RS relationship, or expect = them to carry their AS, or manage their personal keys =E2=80=94 I think = we=E2=80=99ve lost the battle for relevance.

     =E2=80=94 Justin


    = --Apple-Mail=_8DE128E8-DAFB-4353-936C-4C3597298BF6-- From nobody Mon Mar 22 13:13:26 2021 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 3A3783A0E19 for ; Mon, 22 Mar 2021 13:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 MT2IyFMg80iy for ; Mon, 22 Mar 2021 13:13:20 -0700 (PDT) Received: from mail-vs1-f54.google.com (mail-vs1-f54.google.com [209.85.217.54]) (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 7E0BE3A0E12 for ; Mon, 22 Mar 2021 13:13:20 -0700 (PDT) Received: by mail-vs1-f54.google.com with SMTP id l22so8161178vsr.13 for ; Mon, 22 Mar 2021 13:13:20 -0700 (PDT) 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=mZw/Xx3txfMy5bDN/GhRs6+CVIfomJvOq0ytxE+fgzk=; b=gjifvmxJQYLO8H0tW7u2b1CjOsIUJ+oJhCozvmwn4Wxl95CkWuiXtQH5KzeasyTdas tD4mmEKgMym2hwnZwbMcRRuhuHL2PMFbQUBVDI8JvEjax36kTZZlp9fesKg94iZ5oTfi KRlB+ONnedfvgh+N3v1Z865HpufvRYszhoVNqMp3Ykzu4ue2laVkRgRTLytXNuXihwpI Pms9s6dlFRZsahyh5+HwAcQai7FIwKZrA4XlaX50+yXvRGNYhDmeyN0tftDTYLb+VkCf xG4jrj0hXnUQ4kuAEnrOdVoiOXbb3sGoO3JeX21DXw9SuNSAe2qv6tZ/CVO8rUkLQc+I augw== X-Gm-Message-State: AOAM5324VU6ZM6QmECTUx2pWej/PbehQuaSCyKs85cgtjDqTqZ+QPFx/ Q1NnpGLHLHDBcj+QeQULAMDJF/Uzw96gbLJlmrg= X-Google-Smtp-Source: ABdhPJy68yQqoDNp0GD5K0Br2+3U9mzxAnlzpQ4pgwy7KamJQPlatFH0ndDwttTh7RWd+Wi2n9hXpJVimzab+8R3wvA= X-Received: by 2002:a05:6102:24a:: with SMTP id a10mr1418897vsq.39.1616443999391; Mon, 22 Mar 2021 13:13:19 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> In-Reply-To: From: Adrian Gropper Date: Mon, 22 Mar 2021 16:13:07 -0400 Message-ID: To: Justin Richer Cc: Benjamin Kaduk , Alan Karp , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="0000000000006215d905be25b262" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2021 20:13:25 -0000 --0000000000006215d905be25b262 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Justin, Indeed, we do have a problem with the way terminology is being used in this conversation. To help with that, you asked me to provide a use-case rather than arguing over terminology. I did that with the HIPAA API Task Force use-case in the thread you started that has gone silent since I tried to summarize the discussion here: FPIrji3uAQDLkGtqVvC-PreMWbI In another approach, Alan Karp has tried to find a consensus around using AS-RS and AS-RO terminology. That seems to have gone quiet as well. As far as I can tell, Justin, you are insisting that the RO share authorization policies with an RS (or AS-RS) that the RO does not control in the sense that you expect requesting parties to present their claims and purposes to the AS-RS and then have some expectation that the AS-RS can convey the request to a separate policy decision point that is controlled by the RO. I would call that PDP the AS-RO but other names are certainly possible. Please, how do I as an RO keep the RS (or AS-RS) as ignorant as possible of the request content and my RO policies? Adrian On Mon, Mar 22, 2021 at 2:40 PM Justin Richer wrote: > Adrian, > > I think this shows the problem with the terminology as it=E2=80=99s been = applied > in this conversation, which I=E2=80=99ve tried to shine light on before. = What you > and others are calling the =E2=80=9CRS=E2=80=9D is really the =E2=80=9CAS= and RS working together=E2=80=9D > =E2=80=94 everything to the right of the line. When Denis had brought up > =E2=80=9Celiminating the AS=E2=80=9D in another thread, what he=E2=80=99d= really done is labeled > everything to the right of the line as the =E2=80=9CRS=E2=80=9D. Of cours= e, the irony here > is that everything to the right of the line used all be called the =E2=80= =9CAS=E2=80=9D or > simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say below, I = don=E2=80=99t want the > client to have visibility on what happens on that side. > > Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the diagram = is not the AS, as > far as GNAP is concerned. It does not issue an access token that the RS > will accept. The elements to the left of the line could be a lot of thing= s, > but they are NOT the AS =E2=80=94 by definition. The client lives over on= the left, > but so do any external inputs to the AS. These could be policy inputs on > behalf of the RO, they could be presentation artifacts, they could be > federated logins, they could be the output of policy decisions. How the A= S > comes to trust those things is up to the AS=E2=80=99s implementation. It= =E2=80=99s > something we can talk about, but ultimately GNAP won=E2=80=99t be in any = position > to dictate because in practice some AS=E2=80=99s are simply going to inte= rnalize > all policies and we will never successfully force those open. > > But with all that in mind, I think the key here is going to be looking at > what the inputs to the AS are, and how those can be defined in an > interoperable way for AS=E2=80=99s that can accept them. I think there=E2= =80=99s a lot of > room for innovation and flexibility here that doesn=E2=80=99t break the t= rust model > or core use cases. If I have an AS-RS set that won=E2=80=99t accept my fa= vorite > flavor of policy engine inputs, then I can decide not to use that one. Bu= t > this is a very different question than saying the RS itself needs to acce= pt > my own AS =E2=80=94 and we can=E2=80=99t keep conflating these two models= . > > So to me, GNAP can support a Zero Trust Architecture by LEVERAGING the AS= , > not by subsuming or eliminating it. It is in fact the AS, not the client > and not the RS, that will request and consume the results of a > privacy-preserving zero-trust policy query thing. Anything that happens > downstream from that is of little concern to the zero-trust components > because, as you point out, it=E2=80=99s on the =E2=80=9Cother side=E2=80= =9D of the line. > > I think we got this basic component model pretty right in OAuth: the AS > and RS and client working together. Where OAuth misses the mark is the > assumption that the user has to log in to the AS through a webpage and > interact directly, thereby proving they=E2=80=99re the RO. It=E2=80=99s t= his latter space > where I think we can both push innovation and also address the important > and compelling use cases like the ones you=E2=80=99re bringing. > > =E2=80=94 Justin > > On Mar 22, 2021, at 2:14 PM, Adrian Gropper > wrote: > > I'm sorry, Justin. As a Resource Owner, I look at the RS trust boundary > (the dotted line in the diagram) as being the RS. I don't expect any > visibility into what's going on on the right. > > My problem with the framing you propose is that requests are going to the > RS (or the AS-RS) and I don't want to share my policies with the AS-RS. I > want to keep the RS and AS-RS as ignorant as possible. > > Adrian > > On Mon, Mar 22, 2021 at 1:48 PM Justin Richer wrote: > >> Adrian, >> >> What you=E2=80=99re discussing below, in terms of logging in to a site, = is not >> approaching the RS. You are in fact approaching the client, and identify= ing >> both the AS and RS to the client. The client is a client *of your >> identity* in this model, and the RS is part of the identity provider. >> It=E2=80=99s really important that we don=E2=80=99t conflate the RS and = client in this way >> as it leads to a lot of confusion downstream and a lot of broken trust >> boundaries. >> >> With that model in mind, approaching the =E2=80=9CRS" and providing it y= our >> identity is really just a case of the =E2=80=9Cfederated login to AS=E2= =80=9D pattern that >> we discussed on the WG call. The user here approaches an RS, which has i= ts >> own AS. To share things from this RS, the RO has to authenticate to the >> RS=E2=80=99s AS. This particular AS allows the RO to do so using an exte= rnal >> identity =E2=80=94 in which case, the AS is now a =E2=80=9Cclient=E2=80= =9D of a separate, >> disconnected (but layered) delegation. The ultimate client that eventual= ly >> calls the RS down the way may or may not know about these layers. >> >> >> This same AS, which is closely tied to the RS and trusted by the RS, >> might also take in FIDO credentials, or DIDs, or any number of other pro= of >> mechanisms. The output of this is an access token the RS trusts, but the >> input is up to the AS. The RS is not what you=E2=80=99re logging in to. >> >> =E2=80=94 Justin >> >> On Mar 22, 2021, at 1:28 PM, Adrian Gropper >> wrote: >> >> I too am in favor of avoiding consolidation and correlation. Right now, >> when I approach a service provider (RS) for the first time, I'm offered = the >> opportunity to identify my persona as: email, sign-in with Google, >> Facebook, or Apple. I know there are people who try to create one-off em= ail >> addresses but that is mostly a waste of time. >> >> So, along come FIDO2 and DID wallets to the rescue. Now, in theory, I >> have a way to start out my RS relationship pseudonymously. >> >> When I want my resource to be discovered or shared I will post that RS >> URL including my pseudonym. If I then want to introduce a mediator in fr= ont >> of my AS or messaging service endpoint, I have that option. If I want to >> keep requests away from the mediator, I would publish an encryption key >> along with my pseudonym. >> >> - Adrian >> >> >> >> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer wrote: >> >>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk wrote: >>> > >>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote: >>> >> @Alan Karp shared a talk about the Principle >>> Of Least >>> >> Authority (POLA) in a recent comment >>> >> >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomm= ent-803099693 >>> >> I recommend it. >>> >> >>> >> We might expect a protocol with authorization in the title to use >>> authority >>> >> as a core principle. I advocate for a GNAP design that maximizes the >>> power >>> >> of the RO, to be seen as a human rights issue when the RO is a human= . >>> This >>> >> causes me to ask how to combine better security with better human >>> rights in >>> >> GNAP. >>> >> >>> >> Who should have the least authority in the GNAP design? >>> >> >>> >> The AS derives authority as a delegate of the RO. If we ask the RO t= o >>> >> partition limited authority across dozens of different ASs by domain >>> and >>> >> function, then we are not using technology to empower the individual= . >>> >> Probably the opposite, as we introduce consent fatigue and burden >>> normal >>> >> people to partition their lives into non-overlapping domains. >>> >> >>> >> My experience says we should aim for one AS per persona because that >>> maps >>> >> into the way we manage our public and private identities. POLA would >>> then >>> >> teach care in keeping ASs and RSs related to work / public separate >>> from >>> >> ASs and RSs related to private life so that a policy vulnerability i= n >>> our >>> >> delegation to an AS would have the least likelihood of harm. >>> > >>> > Thinking about how least authority/least privilege would apply to GNA= P >>> > seems like a useful exercise. I do want to point out some potential >>> > pitfalls with one-AS-per-persona that we can also be aware of. If >>> > one-AS-per-persona becomes one-persona-per-AS as well, then the AS's >>> > identity in effect also serves as a persona identity and there are >>> privacy >>> > considerations to that. If, on the other hand, the >>> > multiple-personas-per-AS (presumably corresponding to multiple humans= ) >>> > route is taken, we should consider whether that would lead to various >>> > (e.g., market) forces driving consolidation to just a handful of >>> > super-popular AS services. That topic is a current matter of concern >>> to >>> > some IETF participants. >>> > >>> >>> Hi Ben, big +1 to this. This is something that we discussed ages ago in >>> the UMA working group, and it=E2=80=99s one of the biggest problems wit= h the >>> personal AS (and personal data store) model. This kind of thing makes >>> RS-first trust models really difficult in practice. >>> >>> As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wa= nts to access my >>> medical information. It calls an RS and requests access, but it hasn=E2= =80=99t been >>> granted anything yet. Now I as the RO have set up the RS so that it tal= ks >>> to my personal AS, that only I use. In addition to the RS having to be = able >>> to figure out which medical records are being requested from the contex= t of >>> the unauthenticated request (which means it needs identifiers in the UR= L or >>> something similar for the RS to be able to tell, assuming that it prote= cts >>> data for more than one person). So this client software doesn=E2=80=99t= know who I >>> am and doesn=E2=80=99t know my medical record information, makes a comp= letely >>> unauthorized request to the RS, and the RS says =E2=80=9CGo to Justin= =E2=80=99s personal AS >>> to get a token=E2=80=9D. The client can now make a direct correlation b= etween the >>> data that=E2=80=99s being protected at the RS and the person running th= e AS that >>> protects it. Importantly, this client makes this call with no prior >>> relationship to the RS and no really auditable way to track it down aft= er >>> the fact. This is a design feature in the good case, and terrifying in = the >>> bad case. >>> >>> If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please t= alk to >>> the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expos= ed anything at all. >>> And from the perspective of both the patient and the RS, this is more >>> privacy-preserving, and it=E2=80=99s really the least surprising option= . Once the >>> client gets to the AS, it can start a negotiation of figuring out who t= he >>> RO is for the information being accessed. >>> >>> On top of this, the usability expectations of people managing their own >>> AS, or set of AS=E2=80=99s for multiple personas to keep things separat= e, is a huge >>> burden. Even in the tech community, I know people who can=E2=80=99t rel= iably manage >>> more than one email address for different purposes. I wouldn=E2=80=99t = expect my >>> partner to do that =E2=80=94 they have trouble enough balancing all the= logins and >>> sessions required for different kids remote schooling, I couldn=E2=80= =99t imagine >>> them having to understand all the requirements for managing multiple >>> authorization servers and associated policies. I also don=E2=80=99t exp= ect any >>> person to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve been on = the internet for decades and I can >>> barely keep tabs on my GPG keys, and only use them when I am forced to. >>> This is exactly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I th= ink Ben mentions >>> above, people will just want to outsource that to someone else, and the >>> reality will be a few popular providers. >>> >>> In which case, we could end up doing a ton of work to allow an RS choic= e >>> only to end up with a world where the RS ends up making a limited choic= e >>> anyway. We see how that plays out with OpenID Connect =E2=80=94 RP=E2= =80=99s could allow >>> arbitrary IdPs but they choose Google because it works and that=E2=80= =99s where the >>> users are. (And that=E2=80=99s not to say anything of the proprietary O= IDC-like >>> protocols, but that=E2=80=99s another discussion). >>> >>> For further reading on these topics, I recommend both =E2=80=9CWhy John= ny Can=E2=80=99t >>> Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D. >>> >>> So what does this have to do with GNAP? I think we can be clear-eyed on >>> what kinds of expectations we have for the participants. If we expect u= sers >>> (RO=E2=80=99s) to have to set up the AS-RS relationship, or expect them= to carry >>> their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for >>> relevance. >>> >>> =E2=80=94 Justin >> >> >> > --0000000000006215d905be25b262 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Justin,

    Indeed, we do = have a problem with the way terminology is being used in this conversation.= To help with that, you asked me to provide a use-case rather than arguing = over terminology. I did that with the HIPAA API Task Force use-case in the = thread you started that has gone silent since I tried to summarize the disc= ussion here:=C2=A0FPIrji3uAQDLkGtqVvC-PreMWbI

    =
    In another approach, Alan Karp has tried to find a consensus aro= und using AS-RS and AS-RO terminology. That seems to have gone quiet as wel= l.

    As far as I can tell, Justin, you are insisting= =C2=A0that the RO share authorization policies with an RS (or AS-RS) that t= he RO does not control in the sense that you expect requesting parties=C2= =A0to present their claims and purposes to the AS-RS and then have some exp= ectation that the AS-RS can convey the request to a separate policy decisio= n point that is controlled by the RO. I would call that PDP the AS-RO but o= ther names are certainly possible.=C2=A0

    Please, h= ow do I as an RO keep the RS (or AS-RS) as ignorant as possible of the requ= est content and my RO policies?

    Adrian
    =

    = On Mon, Mar 22, 2021 at 2:40 PM Justin Richer <jricher@mit.edu> wrote:
    = Adrian,

    I think this shows the problem with the terminol= ogy as it=E2=80=99s been applied in this conversation, which I=E2=80=99ve t= ried to shine light on before. What you and others are calling the =E2=80= =9CRS=E2=80=9D is really the =E2=80=9CAS and RS working together=E2=80=9D = =E2=80=94 everything to the right of the line. When Denis had brought up = =E2=80=9Celiminating the AS=E2=80=9D in another thread, what he=E2=80=99d r= eally done is labeled everything to the right of the line as the =E2=80=9CR= S=E2=80=9D. Of course, the irony here is that everything to the right of th= e line used all be called the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserve= r=E2=80=9D in the OAuth 1 days. As you say below, I don=E2=80=99t want the = client to have visibility on what happens on that side.=C2=A0
    Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in th= e diagram is not the AS, as far as GNAP is concerned. It does not issue an = access token that the RS will accept. The elements to the left of the line = could be a lot of things, but they are NOT the AS =E2=80=94 by definition. = The client lives over on the left, but so do any external inputs to the AS.= These could be policy inputs on behalf of the RO, they could be presentati= on artifacts, they could be federated logins, they could be the output of p= olicy decisions. How the AS comes to trust those things is up to the AS=E2= =80=99s implementation. It=E2=80=99s something we can talk about, but ultim= ately GNAP won=E2=80=99t be in any position to dictate because in practice = some AS=E2=80=99s are simply going to internalize all policies and we will = never successfully force those open.=C2=A0

    But wit= h all that in mind, I think the key here is going to be looking at what the= inputs to the AS are, and how those can be defined in an interoperable way= for AS=E2=80=99s that can accept them. I think there=E2=80=99s a lot of ro= om for innovation and flexibility here that doesn=E2=80=99t break the trust= model or core use cases. If I have an AS-RS set that won=E2=80=99t accept = my favorite flavor of policy engine inputs, then I can decide not to use th= at one. But this is a very different question than saying the RS itself nee= ds to accept my own AS =E2=80=94 and we can=E2=80=99t keep conflating these= two models.

    So to me, GNAP can support a Zero Tru= st Architecture by LEVERAGING the AS, not by subsuming or eliminating it. I= t is in fact the AS, not the client and not the RS, that will request and c= onsume the results of a privacy-preserving zero-trust policy query thing. A= nything that happens downstream from that is of little concern to the zero-= trust components because, as you point out, it=E2=80=99s on the =E2=80=9Cot= her side=E2=80=9D of the line.=C2=A0

    I think we go= t this basic component model pretty right in OAuth: the AS and RS and clien= t working together. Where OAuth misses the mark is the assumption that the = user has to log in to the AS through a webpage and interact directly, there= by proving they=E2=80=99re the RO. It=E2=80=99s this latter space where I t= hink we can both push innovation and also address the important and compell= ing use cases like the ones you=E2=80=99re bringing.

    =C2=A0=E2=80=94 Justin

    On Mar= 22, 2021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    <= div>
    I'm sorry, Justin. As a Resource Owner, I look at = the RS trust boundary (the dotted line in the diagram) as being the RS. I d= on't expect any visibility into what's going on on the=C2=A0right.= =C2=A0

    My problem with the framing you propose is that r= equests are going to the RS (or the AS-RS) and I don't want to share my= policies with the AS-RS. I want to keep the RS and AS-RS as ignorant as po= ssible.

    Adrian

    On Mon, Mar 22, 2021 at 1:48 P= M Justin Richer <jr= icher@mit.edu> wrote:
    Adrian,

    Wha= t you=E2=80=99re discussing below, in terms of logging in to a site, is not= approaching the RS. You are in fact approaching the client, and identifyin= g both the AS and RS to the client. The client is a client of your ident= ity in this model, and the RS is part of the identity provider. It=E2= =80=99s really important that we don=E2=80=99t conflate the RS and client i= n this way as it leads to a lot of confusion downstream and a lot of broken= trust boundaries.

    With that model in mind, approa= ching the =E2=80=9CRS" and providing it your identity is really just a= case of the =E2=80=9Cfederated login to AS=E2=80=9D pattern that we discus= sed on the WG call. The user here approaches an RS, which has its own AS. T= o share things from this RS, the RO has to authenticate to the RS=E2=80=99s= AS. This particular AS allows the RO to do so using an external identity = =E2=80=94 in which case, the AS is now a =E2=80=9Cclient=E2=80=9D of a sepa= rate, disconnected (but layered) delegation. The ultimate client that event= ually calls the RS down the way may or may not know about these layers.=C2= =A0

    <PastedGraphic-1.png><= /span>
    This same AS, which is closely tied to the RS and trusted = by the RS, might also take in FIDO credentials, or DIDs, or any number of o= ther proof mechanisms. The output of this is an access token the RS trusts,= but the input is up to the AS. The RS is not what you=E2=80=99re logging i= n to.

    =C2=A0=E2=80=94 Justin

    On Mar 22, 2021, at 1:28 PM, Adrian Gropper <agropper@healthurl.c= om> wrote:

    I too am in favor of avoid= ing consolidation and correlation. Right now, when I approach a service pro= vider (RS) for the first time, I'm offered the opportunity to identify = my persona as: email, sign-in with Google, Facebook, or Apple. I know there= are people who try to create one-off email addresses but that is mostly a = waste of time.=C2=A0

    So, along come FIDO2 and DID wallet= s to the rescue. Now, in theory, I have a way to start out my RS relationsh= ip pseudonymously.=C2=A0

    When I want my resource t= o be discovered or shared I will post that RS URL including my pseudonym. I= f I then want to introduce a mediator=C2=A0in front of my AS or messaging s= ervice=C2=A0endpoint, I have that option. If I want to keep requests away f= rom the mediator, I would publish an encryption key along with my pseudonym= .

    - Adrian



    On M= on, Mar 22, 2021 at 9:55 AM Justin Richer <jricher@mit.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhkarp@gmail.com> shared a talk about the Principle Of Leas= t
    >> Authority (POLA) in a recent comment
    >> https:/= /github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-8030996= 93
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --0000000000006215d905be25b262-- From nobody Mon Mar 22 13:26:01 2021 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 882D63A0E7E for ; Mon, 22 Mar 2021 13:25:59 -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=[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 9Dq88h_A2j5r for ; Mon, 22 Mar 2021 13:25:54 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 9E6D03A0E7F for ; Mon, 22 Mar 2021 13:25:54 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id z10so12025695qkz.13 for ; Mon, 22 Mar 2021 13:25: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=r5gAd2TyHtxzT8kMYV3Y/bQiMYOCOc4UCUiFvZYTYDs=; b=pCfNlhoabXwo5F3UhX5a+xeP63HbT9HsBa8KUZOQwxQiJsu2OcVlDgW8nt/AnyLbji xYLhUD0c8e49Lz+rdmztG9WZNasqxygPrOhyCP9uLUmX7FZjRUQmG7X0Si4pWfjTYJhP GSgytMZdBCFdHZRRGy/M6BUsgXmMWUyV8N89fYx1o7sUQ1KsJ5lQjtVD7ch9rUnb+Eg8 lGGJXqOxozaUW6wGgsB1zP7jinTwfegkAEoTSZ5LDjfbKrBCDF423OD8Ov2Tvy58qmFo NtgQWKaLPshYmjM4pwj9zvjrKkoirZPQybN9z5iWCvEdmccsVasDoTObXz6axM9VDudt E02Q== 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=r5gAd2TyHtxzT8kMYV3Y/bQiMYOCOc4UCUiFvZYTYDs=; b=RiTCla+AYH2CZtD/qENKqEe0nGW+eeTHboIjwMqCVe1krCU7iI5C2mRjcz01VNuK3l NrYmbQcm98cfegmetkgcPBqN08J+Ft7rOyvNNMGWUT/c8D6gOPep0M/brf6j5ClZALD8 fGxGlzQQKx2ZVLIQuOfylMpTkqseIhz2ls2cu2E3KXdFLzX5+8nys2gCaEzEfa0Zez+r 5GGk7Y5BJowZezW5JIH+REdxysBwSYoWu7rJdpVDsXb/OC2VxECh23yGS13l8wu2927G Qs0q9howFoCaaMG4VqXY2U1udTuO3DM6uRcUKXiNVUBThmMiBu8Q4H4cxMyjV5dPtwQO xR/g== X-Gm-Message-State: AOAM5331XiaSoAw8IZswD0ma0IyB34ZYwmhjLvf9z5pMvYmjUEUSDCbg RA1L/HQ8kN6DrVQIdwAO4M/mO9hJhXOTzL7nn5A= X-Google-Smtp-Source: ABdhPJyXVAr5/W9weHtyYs5ipamU/M4i44xscfPd8jKsgzX9cR1PGwI+ZMuwf0Fb/xrxH0i440DPetcXvZTpIEazcIw= X-Received: by 2002:a37:3c8:: with SMTP id 191mr1958562qkd.90.1616444752736; Mon, 22 Mar 2021 13:25:52 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> In-Reply-To: From: Alan Karp Date: Mon, 22 Mar 2021 13:25:41 -0700 Message-ID: To: Justin Richer Cc: Adrian Gropper , Benjamin Kaduk , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="00000000000049352d05be25dfad" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2021 20:26:00 -0000 --00000000000049352d05be25dfad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Justin Richer wrote: > > But with all that in mind, I think the key here is going to be looking at > what the inputs to the AS are, and how those can be defined in an > interoperable way for AS=E2=80=99s that can accept them. I think there=E2= =80=99s a lot of > room for innovation and flexibility here that doesn=E2=80=99t break the t= rust model > or core use cases. If I have an AS-RS set that won=E2=80=99t accept my fa= vorite > flavor of policy engine inputs, then I can decide not to use that one. Bu= t > this is a very different question than saying the RS itself needs to acce= pt > my own AS =E2=80=94 and we can=E2=80=99t keep conflating these two models= . > > I agree. The point of having an AS-RO is to allow RO to specify a policy for which of RO's access tokens should be delegated under what conditions. AS-RS should not need to understand those policies. The flow would be - RO contacts AS-RS and gets one or more access tokens. - RO delegates one or more of those tokens, potentially sub-scoped, to AS-RO. - A different user contacts AS-RO to get a potentially sub-scoped access token from AS-RO. - That user presents the access token delegated by AS-RO when invoking the resource. AS-RS only needs to verify that the delegation chain is legitimate, e.g., no increase in scope, and that it grants permission for the request being made. AS-RS does not need to understand the policy behind granting the delegation by AS-RO. -------------- Alan Karp On Mon, Mar 22, 2021 at 11:40 AM Justin Richer wrote: > Adrian, > > I think this shows the problem with the terminology as it=E2=80=99s been = applied > in this conversation, which I=E2=80=99ve tried to shine light on before. = What you > and others are calling the =E2=80=9CRS=E2=80=9D is really the =E2=80=9CAS= and RS working together=E2=80=9D > =E2=80=94 everything to the right of the line. When Denis had brought up > =E2=80=9Celiminating the AS=E2=80=9D in another thread, what he=E2=80=99d= really done is labeled > everything to the right of the line as the =E2=80=9CRS=E2=80=9D. Of cours= e, the irony here > is that everything to the right of the line used all be called the =E2=80= =9CAS=E2=80=9D or > simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say below, I = don=E2=80=99t want the > client to have visibility on what happens on that side. > > Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the diagram = is not the AS, as > far as GNAP is concerned. It does not issue an access token that the RS > will accept. The elements to the left of the line could be a lot of thing= s, > but they are NOT the AS =E2=80=94 by definition. The client lives over on= the left, > but so do any external inputs to the AS. These could be policy inputs on > behalf of the RO, they could be presentation artifacts, they could be > federated logins, they could be the output of policy decisions. How the A= S > comes to trust those things is up to the AS=E2=80=99s implementation. It= =E2=80=99s > something we can talk about, but ultimately GNAP won=E2=80=99t be in any = position > to dictate because in practice some AS=E2=80=99s are simply going to inte= rnalize > all policies and we will never successfully force those open. > > But with all that in mind, I think the key here is going to be looking at > what the inputs to the AS are, and how those can be defined in an > interoperable way for AS=E2=80=99s that can accept them. I think there=E2= =80=99s a lot of > room for innovation and flexibility here that doesn=E2=80=99t break the t= rust model > or core use cases. If I have an AS-RS set that won=E2=80=99t accept my fa= vorite > flavor of policy engine inputs, then I can decide not to use that one. Bu= t > this is a very different question than saying the RS itself needs to acce= pt > my own AS =E2=80=94 and we can=E2=80=99t keep conflating these two models= . > > So to me, GNAP can support a Zero Trust Architecture by LEVERAGING the AS= , > not by subsuming or eliminating it. It is in fact the AS, not the client > and not the RS, that will request and consume the results of a > privacy-preserving zero-trust policy query thing. Anything that happens > downstream from that is of little concern to the zero-trust components > because, as you point out, it=E2=80=99s on the =E2=80=9Cother side=E2=80= =9D of the line. > > I think we got this basic component model pretty right in OAuth: the AS > and RS and client working together. Where OAuth misses the mark is the > assumption that the user has to log in to the AS through a webpage and > interact directly, thereby proving they=E2=80=99re the RO. It=E2=80=99s t= his latter space > where I think we can both push innovation and also address the important > and compelling use cases like the ones you=E2=80=99re bringing. > > =E2=80=94 Justin > > On Mar 22, 2021, at 2:14 PM, Adrian Gropper > wrote: > > I'm sorry, Justin. As a Resource Owner, I look at the RS trust boundary > (the dotted line in the diagram) as being the RS. I don't expect any > visibility into what's going on on the right. > > My problem with the framing you propose is that requests are going to the > RS (or the AS-RS) and I don't want to share my policies with the AS-RS. I > want to keep the RS and AS-RS as ignorant as possible. > > Adrian > > On Mon, Mar 22, 2021 at 1:48 PM Justin Richer wrote: > >> Adrian, >> >> What you=E2=80=99re discussing below, in terms of logging in to a site, = is not >> approaching the RS. You are in fact approaching the client, and identify= ing >> both the AS and RS to the client. The client is a client *of your >> identity* in this model, and the RS is part of the identity provider. >> It=E2=80=99s really important that we don=E2=80=99t conflate the RS and = client in this way >> as it leads to a lot of confusion downstream and a lot of broken trust >> boundaries. >> >> With that model in mind, approaching the =E2=80=9CRS" and providing it y= our >> identity is really just a case of the =E2=80=9Cfederated login to AS=E2= =80=9D pattern that >> we discussed on the WG call. The user here approaches an RS, which has i= ts >> own AS. To share things from this RS, the RO has to authenticate to the >> RS=E2=80=99s AS. This particular AS allows the RO to do so using an exte= rnal >> identity =E2=80=94 in which case, the AS is now a =E2=80=9Cclient=E2=80= =9D of a separate, >> disconnected (but layered) delegation. The ultimate client that eventual= ly >> calls the RS down the way may or may not know about these layers. >> >> >> This same AS, which is closely tied to the RS and trusted by the RS, >> might also take in FIDO credentials, or DIDs, or any number of other pro= of >> mechanisms. The output of this is an access token the RS trusts, but the >> input is up to the AS. The RS is not what you=E2=80=99re logging in to. >> >> =E2=80=94 Justin >> >> On Mar 22, 2021, at 1:28 PM, Adrian Gropper >> wrote: >> >> I too am in favor of avoiding consolidation and correlation. Right now, >> when I approach a service provider (RS) for the first time, I'm offered = the >> opportunity to identify my persona as: email, sign-in with Google, >> Facebook, or Apple. I know there are people who try to create one-off em= ail >> addresses but that is mostly a waste of time. >> >> So, along come FIDO2 and DID wallets to the rescue. Now, in theory, I >> have a way to start out my RS relationship pseudonymously. >> >> When I want my resource to be discovered or shared I will post that RS >> URL including my pseudonym. If I then want to introduce a mediator in fr= ont >> of my AS or messaging service endpoint, I have that option. If I want to >> keep requests away from the mediator, I would publish an encryption key >> along with my pseudonym. >> >> - Adrian >> >> >> >> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer wrote: >> >>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk wrote: >>> > >>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote: >>> >> @Alan Karp shared a talk about the Principle >>> Of Least >>> >> Authority (POLA) in a recent comment >>> >> >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomm= ent-803099693 >>> >> I recommend it. >>> >> >>> >> We might expect a protocol with authorization in the title to use >>> authority >>> >> as a core principle. I advocate for a GNAP design that maximizes the >>> power >>> >> of the RO, to be seen as a human rights issue when the RO is a human= . >>> This >>> >> causes me to ask how to combine better security with better human >>> rights in >>> >> GNAP. >>> >> >>> >> Who should have the least authority in the GNAP design? >>> >> >>> >> The AS derives authority as a delegate of the RO. If we ask the RO t= o >>> >> partition limited authority across dozens of different ASs by domain >>> and >>> >> function, then we are not using technology to empower the individual= . >>> >> Probably the opposite, as we introduce consent fatigue and burden >>> normal >>> >> people to partition their lives into non-overlapping domains. >>> >> >>> >> My experience says we should aim for one AS per persona because that >>> maps >>> >> into the way we manage our public and private identities. POLA would >>> then >>> >> teach care in keeping ASs and RSs related to work / public separate >>> from >>> >> ASs and RSs related to private life so that a policy vulnerability i= n >>> our >>> >> delegation to an AS would have the least likelihood of harm. >>> > >>> > Thinking about how least authority/least privilege would apply to GNA= P >>> > seems like a useful exercise. I do want to point out some potential >>> > pitfalls with one-AS-per-persona that we can also be aware of. If >>> > one-AS-per-persona becomes one-persona-per-AS as well, then the AS's >>> > identity in effect also serves as a persona identity and there are >>> privacy >>> > considerations to that. If, on the other hand, the >>> > multiple-personas-per-AS (presumably corresponding to multiple humans= ) >>> > route is taken, we should consider whether that would lead to various >>> > (e.g., market) forces driving consolidation to just a handful of >>> > super-popular AS services. That topic is a current matter of concern >>> to >>> > some IETF participants. >>> > >>> >>> Hi Ben, big +1 to this. This is something that we discussed ages ago in >>> the UMA working group, and it=E2=80=99s one of the biggest problems wit= h the >>> personal AS (and personal data store) model. This kind of thing makes >>> RS-first trust models really difficult in practice. >>> >>> As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wa= nts to access my >>> medical information. It calls an RS and requests access, but it hasn=E2= =80=99t been >>> granted anything yet. Now I as the RO have set up the RS so that it tal= ks >>> to my personal AS, that only I use. In addition to the RS having to be = able >>> to figure out which medical records are being requested from the contex= t of >>> the unauthenticated request (which means it needs identifiers in the UR= L or >>> something similar for the RS to be able to tell, assuming that it prote= cts >>> data for more than one person). So this client software doesn=E2=80=99t= know who I >>> am and doesn=E2=80=99t know my medical record information, makes a comp= letely >>> unauthorized request to the RS, and the RS says =E2=80=9CGo to Justin= =E2=80=99s personal AS >>> to get a token=E2=80=9D. The client can now make a direct correlation b= etween the >>> data that=E2=80=99s being protected at the RS and the person running th= e AS that >>> protects it. Importantly, this client makes this call with no prior >>> relationship to the RS and no really auditable way to track it down aft= er >>> the fact. This is a design feature in the good case, and terrifying in = the >>> bad case. >>> >>> If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please t= alk to >>> the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expos= ed anything at all. >>> And from the perspective of both the patient and the RS, this is more >>> privacy-preserving, and it=E2=80=99s really the least surprising option= . Once the >>> client gets to the AS, it can start a negotiation of figuring out who t= he >>> RO is for the information being accessed. >>> >>> On top of this, the usability expectations of people managing their own >>> AS, or set of AS=E2=80=99s for multiple personas to keep things separat= e, is a huge >>> burden. Even in the tech community, I know people who can=E2=80=99t rel= iably manage >>> more than one email address for different purposes. I wouldn=E2=80=99t = expect my >>> partner to do that =E2=80=94 they have trouble enough balancing all the= logins and >>> sessions required for different kids remote schooling, I couldn=E2=80= =99t imagine >>> them having to understand all the requirements for managing multiple >>> authorization servers and associated policies. I also don=E2=80=99t exp= ect any >>> person to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve been on = the internet for decades and I can >>> barely keep tabs on my GPG keys, and only use them when I am forced to. >>> This is exactly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I th= ink Ben mentions >>> above, people will just want to outsource that to someone else, and the >>> reality will be a few popular providers. >>> >>> In which case, we could end up doing a ton of work to allow an RS choic= e >>> only to end up with a world where the RS ends up making a limited choic= e >>> anyway. We see how that plays out with OpenID Connect =E2=80=94 RP=E2= =80=99s could allow >>> arbitrary IdPs but they choose Google because it works and that=E2=80= =99s where the >>> users are. (And that=E2=80=99s not to say anything of the proprietary O= IDC-like >>> protocols, but that=E2=80=99s another discussion). >>> >>> For further reading on these topics, I recommend both =E2=80=9CWhy John= ny Can=E2=80=99t >>> Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D. >>> >>> So what does this have to do with GNAP? I think we can be clear-eyed on >>> what kinds of expectations we have for the participants. If we expect u= sers >>> (RO=E2=80=99s) to have to set up the AS-RS relationship, or expect them= to carry >>> their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for >>> relevance. >>> >>> =E2=80=94 Justin >> >> >> > --00000000000049352d05be25dfad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Jus= tin Richer <jricher@mit.edu> w= rote:

    But with all that in mi= nd, I think the key here is going to be looking at what the inputs to the A= S are, and how those can be defined in an interoperable way for AS=E2=80=99= s that can accept them. I think there=E2=80=99s a lot of room for innovatio= n and flexibility here that doesn=E2=80=99t break the trust model or core u= se cases. If I have an AS-RS set that won=E2=80=99t accept my favorite flav= or of policy engine inputs, then I can decide not to use that one. But this= is a very different question than saying the RS itself needs to accept my = own AS =E2=80=94 and we can=E2=80=99t keep conflating these two models.

    I agree.=C2=A0 The point of having= an AS-RO is to allow RO to specify a policy for which of RO's access t= okens should be delegated under what conditions.=C2=A0 AS-RS should not nee= d to understand those policies.=C2=A0 The flow would be
    • R= O contacts AS-RS and gets one or more access tokens.
    • RO delegates o= ne or more of those tokens, potentially sub-scoped, to AS-RO.
    • A dif= ferent user contacts AS-RO to get a potentially sub-scoped access token fro= m AS-RO.
    • That user presents the access token delegated by AS-RO whe= n invoking the resource.
    AS-RS only needs to verify that the del= egation chain is legitimate, e.g., no increase in scope, and that it grants= permission for the request being made.=C2=A0 AS-RS does not need to unders= tand the policy behind granting the delegation by AS-RO.

    ------= --------
    Alan Karp


    <= div dir=3D"ltr" class=3D"gmail_attr">On Mon, Mar 22, 2021 at 11:40 AM Justi= n Richer <jricher@mit.edu> wro= te:
    Adrian,

    I think this sho= ws the problem with the terminology as it=E2=80=99s been applied in this co= nversation, which I=E2=80=99ve tried to shine light on before. What you and= others are calling the =E2=80=9CRS=E2=80=9D is really the =E2=80=9CAS and = RS working together=E2=80=9D =E2=80=94 everything to the right of the line.= When Denis had brought up =E2=80=9Celiminating the AS=E2=80=9D in another = thread, what he=E2=80=99d really done is labeled everything to the right of= the line as the =E2=80=9CRS=E2=80=9D. Of course, the irony here is that ev= erything to the right of the line used all be called the =E2=80=9CAS=E2=80= =9D or simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say belo= w, I don=E2=80=99t want the client to have visibility on what happens on th= at side.=C2=A0

    Note well: The Google+ logo labeled= =E2=80=9CIdP=E2=80=9D in the diagram is not the AS, as far as GNAP is conc= erned. It does not issue an access token that the RS will accept. The eleme= nts to the left of the line could be a lot of things, but they are NOT the = AS =E2=80=94 by definition. The client lives over on the left, but so do an= y external inputs to the AS. These could be policy inputs on behalf of the = RO, they could be presentation artifacts, they could be federated logins, t= hey could be the output of policy decisions. How the AS comes to trust thos= e things is up to the AS=E2=80=99s implementation. It=E2=80=99s something w= e can talk about, but ultimately GNAP won=E2=80=99t be in any position to d= ictate because in practice some AS=E2=80=99s are simply going to internaliz= e all policies and we will never successfully force those open.=C2=A0
    =

    But with all that in mind, I think the key here is goin= g to be looking at what the inputs to the AS are, and how those can be defi= ned in an interoperable way for AS=E2=80=99s that can accept them. I think = there=E2=80=99s a lot of room for innovation and flexibility here that does= n=E2=80=99t break the trust model or core use cases. If I have an AS-RS set= that won=E2=80=99t accept my favorite flavor of policy engine inputs, then= I can decide not to use that one. But this is a very different question th= an saying the RS itself needs to accept my own AS =E2=80=94 and we can=E2= =80=99t keep conflating these two models.

    So to me= , GNAP can support a Zero Trust Architecture by LEVERAGING the AS, not by s= ubsuming or eliminating it. It is in fact the AS, not the client and not th= e RS, that will request and consume the results of a privacy-preserving zer= o-trust policy query thing. Anything that happens downstream from that is o= f little concern to the zero-trust components because, as you point out, it= =E2=80=99s on the =E2=80=9Cother side=E2=80=9D of the line.=C2=A0

    I think we got this basic component model pretty right in O= Auth: the AS and RS and client working together. Where OAuth misses the mar= k is the assumption that the user has to log in to the AS through a webpage= and interact directly, thereby proving they=E2=80=99re the RO. It=E2=80=99= s this latter space where I think we can both push innovation and also addr= ess the important and compelling use cases like the ones you=E2=80=99re bri= nging.

    =C2=A0=E2=80=94 Justin

    On Mar 22, 2021, at 2:14 PM, Adrian Gropper <agropper@healthurl.= com> wrote:

    I'm sorry, Justin. As= a Resource Owner, I look at the RS trust boundary (the dotted line in the = diagram) as being the RS. I don't expect any visibility into what's= going on on the=C2=A0right.=C2=A0

    My problem with the f= raming you propose is that requests are going to the RS (or the AS-RS) and = I don't want to share my policies with the AS-RS. I want to keep the RS= and AS-RS as ignorant as possible.

    Adrian

    On= Mon, Mar 22, 2021 at 1:48 PM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    What you=E2=80=99re discussing below, in= terms of logging in to a site, is not approaching the RS. You are in fact = approaching the client, and identifying both the AS and RS to the client. T= he client is a client of your identity in this model, and the RS is = part of the identity provider. It=E2=80=99s really important that we don=E2= =80=99t conflate the RS and client in this way as it leads to a lot of conf= usion downstream and a lot of broken trust boundaries.

    =
    With that model in mind, approaching the =E2=80=9CRS" and providi= ng it your identity is really just a case of the =E2=80=9Cfederated login t= o AS=E2=80=9D pattern that we discussed on the WG call. The user here appro= aches an RS, which has its own AS. To share things from this RS, the RO has= to authenticate to the RS=E2=80=99s AS. This particular AS allows the RO t= o do so using an external identity =E2=80=94 in which case, the AS is now a= =E2=80=9Cclient=E2=80=9D of a separate, disconnected (but layered) delegat= ion. The ultimate client that eventually calls the RS down the way may or m= ay not know about these layers.=C2=A0

    <PastedGraphic-1.pn= g>
    This same AS, which is closely tied to the RS and tr= usted by the RS, might also take in FIDO credentials, or DIDs, or any numbe= r of other proof mechanisms. The output of this is an access token the RS t= rusts, but the input is up to the AS. The RS is not what you=E2=80=99re log= ging in to.

    =C2=A0=E2=80=94 Justin

    On Mar 22, 2021, at 1:28 PM, Adrian Gropper <= ;agropper@healt= hurl.com> wrote:

    I too am in favor of= avoiding consolidation and correlation. Right now, when I approach a servi= ce provider (RS) for the first time, I'm offered the opportunity to ide= ntify my persona as: email, sign-in with Google, Facebook, or Apple. I know= there are people who try to create one-off email addresses but that is mos= tly a waste of time.=C2=A0

    So, along come FIDO2 and DID = wallets to the rescue. Now, in theory, I have a way to start out my RS rela= tionship pseudonymously.=C2=A0

    When I want my reso= urce to be discovered or shared I will post that RS URL including my pseudo= nym. If I then want to introduce a mediator=C2=A0in front of my AS or messa= ging service=C2=A0endpoint, I have that option. If I want to keep requests = away from the mediator, I would publish an encryption key along with my pse= udonym.

    - Adrian



    On Mon, Mar 22, 2021 at 9:55 AM Justin Richer <jricher@mit.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, B= enjamin Kaduk <kaduk@= mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhkarp@gmail.com> shared a talk about the Principle Of Leas= t
    >> Authority (POLA) in a recent comment
    >> https:/= /github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-8030996= 93
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --00000000000049352d05be25dfad-- From nobody Tue Mar 23 04:12:42 2021 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 D888A3A0E0B for ; Tue, 23 Mar 2021 04:12:40 -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 3-4o1thUVXh2 for ; Tue, 23 Mar 2021 04:12:36 -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 452103A0E0F for ; Tue, 23 Mar 2021 04:12:36 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id d2so17732456ilm.10 for ; Tue, 23 Mar 2021 04:12: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=jHzDkjEVj+7fnmAHG1vStvZ0i+n5l1zZdYwu34wE/CE=; b=B4QN0LjoEE4YtNvhvjxIP6jX5A5NWX3C0MYO0ifsfjQOB1HoeFNMC+etj/g24uI5hU IrJ1g6xNR4cPhCl9EDbnkI7EhfzxtBSkp+OS0+COgkUYZvXLQByml2ClGAHIUbdlXR1r IrXbJgZvoqFoYmcDJgwtaFKGaGJZun2460ALK4tHv6opCUce0oaXqYH+hH6ZxqFsTXOx /vl6QZ0M57UMyhldaSb12Z2Bax6eIResK4PvewXdvDLkwvV7PZWeN+NFgU9+pBpBSKOw VeIC0HhUd0UGqUCWFHSjMNRu/Fi6LyyQYd/auxK+Dgo/XymgVMrqCF50jZ0LdjoDHQRt TJmQ== 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=jHzDkjEVj+7fnmAHG1vStvZ0i+n5l1zZdYwu34wE/CE=; b=XRthk1kPh3qiN+uI66vEorAdley8ISTt+j4wcIzCYozJqpa0CMzS7zhy83FIb343SP Ur7fPu24R1BxMqmXlG8CysqKAG8urnthS19hjD6h0hdPiFVbWW1Oz7UW+fYglDLeH/dL 6dFyHD+YD3FOeelg5JyTyJHBZafNwMMhAhpJB2xc7aFkTiSrJ/uLcP9p9wj4bhZj9MwP cHC4Y66n7vdtnXYJCbQzgakvHjp7Jj0JE+cJPkCQJujKMZbEDN5mShsqTjYtYszrTGqt xwiv4/CcpGDrh/glkogNYyKX6jiefm/ZLcfMWqvaEo8WcZq7TICclLqxxaVR+1jpkWRq 7btQ== X-Gm-Message-State: AOAM533U5PWu/BZD/E3bM7sd7zPzU4jZH0zldvtbOGwDDkqZ5gVkjt0n UglQYHU1nbiaRdJtNMBlquUlyl4tbE8YKDOm/L0= X-Google-Smtp-Source: ABdhPJzaDScneNMUd7o5FkpSo6bqe2xVNs/AuX7OnvxgGys0jgD7zn7Yne8K/i0JCPl1pGYWJdn4FdiCvZKyoJDMaUM= X-Received: by 2002:a92:1a11:: with SMTP id a17mr4515623ila.188.1616497954660; Tue, 23 Mar 2021 04:12:34 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> In-Reply-To: From: Fabien Imbault Date: Tue, 23 Mar 2021 12:12:23 +0100 Message-ID: To: Alan Karp Cc: Justin Richer , Adrian Gropper , Benjamin Kaduk , Mark Miller , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000005e24c205be3242d8" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2021 11:12:41 -0000 --0000000000005e24c205be3242d8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alan, Yes, but in that flow, the token relationship between AS-RS and AS-RO is only secure if the tokens issued by AS-RS are cryptographically attenuable in the first place. Fabien On Mon, Mar 22, 2021 at 9:26 PM Alan Karp wrote: > Justin Richer wrote: > >> >> But with all that in mind, I think the key here is going to be looking a= t >> what the inputs to the AS are, and how those can be defined in an >> interoperable way for AS=E2=80=99s that can accept them. I think there= =E2=80=99s a lot of >> room for innovation and flexibility here that doesn=E2=80=99t break the = trust model >> or core use cases. If I have an AS-RS set that won=E2=80=99t accept my f= avorite >> flavor of policy engine inputs, then I can decide not to use that one. B= ut >> this is a very different question than saying the RS itself needs to acc= ept >> my own AS =E2=80=94 and we can=E2=80=99t keep conflating these two model= s. >> >> I agree. The point of having an AS-RO is to allow RO to specify a polic= y > for which of RO's access tokens should be delegated under what conditions= . > AS-RS should not need to understand those policies. The flow would be > > - RO contacts AS-RS and gets one or more access tokens. > - RO delegates one or more of those tokens, potentially sub-scoped, to > AS-RO. > - A different user contacts AS-RO to get a potentially sub-scoped > access token from AS-RO. > - That user presents the access token delegated by AS-RO when invoking > the resource. > > AS-RS only needs to verify that the delegation chain is legitimate, e.g., > no increase in scope, and that it grants permission for the request being > made. AS-RS does not need to understand the policy behind granting the > delegation by AS-RO. > > -------------- > Alan Karp > > > On Mon, Mar 22, 2021 at 11:40 AM Justin Richer wrote: > >> Adrian, >> >> I think this shows the problem with the terminology as it=E2=80=99s been= applied >> in this conversation, which I=E2=80=99ve tried to shine light on before.= What you >> and others are calling the =E2=80=9CRS=E2=80=9D is really the =E2=80=9CA= S and RS working together=E2=80=9D >> =E2=80=94 everything to the right of the line. When Denis had brought up >> =E2=80=9Celiminating the AS=E2=80=9D in another thread, what he=E2=80=99= d really done is labeled >> everything to the right of the line as the =E2=80=9CRS=E2=80=9D. Of cour= se, the irony here >> is that everything to the right of the line used all be called the =E2= =80=9CAS=E2=80=9D or >> simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say below, I= don=E2=80=99t want the >> client to have visibility on what happens on that side. >> >> Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the diagram= is not the AS, >> as far as GNAP is concerned. It does not issue an access token that the = RS >> will accept. The elements to the left of the line could be a lot of thin= gs, >> but they are NOT the AS =E2=80=94 by definition. The client lives over o= n the left, >> but so do any external inputs to the AS. These could be policy inputs on >> behalf of the RO, they could be presentation artifacts, they could be >> federated logins, they could be the output of policy decisions. How the = AS >> comes to trust those things is up to the AS=E2=80=99s implementation. It= =E2=80=99s >> something we can talk about, but ultimately GNAP won=E2=80=99t be in any= position >> to dictate because in practice some AS=E2=80=99s are simply going to int= ernalize >> all policies and we will never successfully force those open. >> >> But with all that in mind, I think the key here is going to be looking a= t >> what the inputs to the AS are, and how those can be defined in an >> interoperable way for AS=E2=80=99s that can accept them. I think there= =E2=80=99s a lot of >> room for innovation and flexibility here that doesn=E2=80=99t break the = trust model >> or core use cases. If I have an AS-RS set that won=E2=80=99t accept my f= avorite >> flavor of policy engine inputs, then I can decide not to use that one. B= ut >> this is a very different question than saying the RS itself needs to acc= ept >> my own AS =E2=80=94 and we can=E2=80=99t keep conflating these two model= s. >> >> So to me, GNAP can support a Zero Trust Architecture by LEVERAGING the >> AS, not by subsuming or eliminating it. It is in fact the AS, not the >> client and not the RS, that will request and consume the results of a >> privacy-preserving zero-trust policy query thing. Anything that happens >> downstream from that is of little concern to the zero-trust components >> because, as you point out, it=E2=80=99s on the =E2=80=9Cother side=E2=80= =9D of the line. >> >> I think we got this basic component model pretty right in OAuth: the AS >> and RS and client working together. Where OAuth misses the mark is the >> assumption that the user has to log in to the AS through a webpage and >> interact directly, thereby proving they=E2=80=99re the RO. It=E2=80=99s = this latter space >> where I think we can both push innovation and also address the important >> and compelling use cases like the ones you=E2=80=99re bringing. >> >> =E2=80=94 Justin >> >> On Mar 22, 2021, at 2:14 PM, Adrian Gropper >> wrote: >> >> I'm sorry, Justin. As a Resource Owner, I look at the RS trust boundary >> (the dotted line in the diagram) as being the RS. I don't expect any >> visibility into what's going on on the right. >> >> My problem with the framing you propose is that requests are going to th= e >> RS (or the AS-RS) and I don't want to share my policies with the AS-RS. = I >> want to keep the RS and AS-RS as ignorant as possible. >> >> Adrian >> >> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer wrote: >> >>> Adrian, >>> >>> What you=E2=80=99re discussing below, in terms of logging in to a site,= is not >>> approaching the RS. You are in fact approaching the client, and identif= ying >>> both the AS and RS to the client. The client is a client *of your >>> identity* in this model, and the RS is part of the identity provider. >>> It=E2=80=99s really important that we don=E2=80=99t conflate the RS and= client in this way >>> as it leads to a lot of confusion downstream and a lot of broken trust >>> boundaries. >>> >>> With that model in mind, approaching the =E2=80=9CRS" and providing it = your >>> identity is really just a case of the =E2=80=9Cfederated login to AS=E2= =80=9D pattern that >>> we discussed on the WG call. The user here approaches an RS, which has = its >>> own AS. To share things from this RS, the RO has to authenticate to the >>> RS=E2=80=99s AS. This particular AS allows the RO to do so using an ext= ernal >>> identity =E2=80=94 in which case, the AS is now a =E2=80=9Cclient=E2=80= =9D of a separate, >>> disconnected (but layered) delegation. The ultimate client that eventua= lly >>> calls the RS down the way may or may not know about these layers. >>> >>> >>> This same AS, which is closely tied to the RS and trusted by the RS, >>> might also take in FIDO credentials, or DIDs, or any number of other pr= oof >>> mechanisms. The output of this is an access token the RS trusts, but th= e >>> input is up to the AS. The RS is not what you=E2=80=99re logging in to. >>> >>> =E2=80=94 Justin >>> >>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper >>> wrote: >>> >>> I too am in favor of avoiding consolidation and correlation. Right now, >>> when I approach a service provider (RS) for the first time, I'm offered= the >>> opportunity to identify my persona as: email, sign-in with Google, >>> Facebook, or Apple. I know there are people who try to create one-off e= mail >>> addresses but that is mostly a waste of time. >>> >>> So, along come FIDO2 and DID wallets to the rescue. Now, in theory, I >>> have a way to start out my RS relationship pseudonymously. >>> >>> When I want my resource to be discovered or shared I will post that RS >>> URL including my pseudonym. If I then want to introduce a mediator in f= ront >>> of my AS or messaging service endpoint, I have that option. If I want t= o >>> keep requests away from the mediator, I would publish an encryption key >>> along with my pseudonym. >>> >>> - Adrian >>> >>> >>> >>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer wrote: >>> >>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk wrote: >>>> > >>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote: >>>> >> @Alan Karp shared a talk about the Principle >>>> Of Least >>>> >> Authority (POLA) in a recent comment >>>> >> >>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecom= ment-803099693 >>>> >> I recommend it. >>>> >> >>>> >> We might expect a protocol with authorization in the title to use >>>> authority >>>> >> as a core principle. I advocate for a GNAP design that maximizes th= e >>>> power >>>> >> of the RO, to be seen as a human rights issue when the RO is a >>>> human. This >>>> >> causes me to ask how to combine better security with better human >>>> rights in >>>> >> GNAP. >>>> >> >>>> >> Who should have the least authority in the GNAP design? >>>> >> >>>> >> The AS derives authority as a delegate of the RO. If we ask the RO = to >>>> >> partition limited authority across dozens of different ASs by domai= n >>>> and >>>> >> function, then we are not using technology to empower the individua= l. >>>> >> Probably the opposite, as we introduce consent fatigue and burden >>>> normal >>>> >> people to partition their lives into non-overlapping domains. >>>> >> >>>> >> My experience says we should aim for one AS per persona because tha= t >>>> maps >>>> >> into the way we manage our public and private identities. POLA woul= d >>>> then >>>> >> teach care in keeping ASs and RSs related to work / public separate >>>> from >>>> >> ASs and RSs related to private life so that a policy vulnerability >>>> in our >>>> >> delegation to an AS would have the least likelihood of harm. >>>> > >>>> > Thinking about how least authority/least privilege would apply to GN= AP >>>> > seems like a useful exercise. I do want to point out some potential >>>> > pitfalls with one-AS-per-persona that we can also be aware of. If >>>> > one-AS-per-persona becomes one-persona-per-AS as well, then the AS's >>>> > identity in effect also serves as a persona identity and there are >>>> privacy >>>> > considerations to that. If, on the other hand, the >>>> > multiple-personas-per-AS (presumably corresponding to multiple human= s) >>>> > route is taken, we should consider whether that would lead to variou= s >>>> > (e.g., market) forces driving consolidation to just a handful of >>>> > super-popular AS services. That topic is a current matter of concer= n >>>> to >>>> > some IETF participants. >>>> > >>>> >>>> Hi Ben, big +1 to this. This is something that we discussed ages ago i= n >>>> the UMA working group, and it=E2=80=99s one of the biggest problems wi= th the >>>> personal AS (and personal data store) model. This kind of thing makes >>>> RS-first trust models really difficult in practice. >>>> >>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that w= ants to access my >>>> medical information. It calls an RS and requests access, but it hasn= =E2=80=99t been >>>> granted anything yet. Now I as the RO have set up the RS so that it ta= lks >>>> to my personal AS, that only I use. In addition to the RS having to be= able >>>> to figure out which medical records are being requested from the conte= xt of >>>> the unauthenticated request (which means it needs identifiers in the U= RL or >>>> something similar for the RS to be able to tell, assuming that it prot= ects >>>> data for more than one person). So this client software doesn=E2=80=99= t know who I >>>> am and doesn=E2=80=99t know my medical record information, makes a com= pletely >>>> unauthorized request to the RS, and the RS says =E2=80=9CGo to Justin= =E2=80=99s personal AS >>>> to get a token=E2=80=9D. The client can now make a direct correlation = between the >>>> data that=E2=80=99s being protected at the RS and the person running t= he AS that >>>> protects it. Importantly, this client makes this call with no prior >>>> relationship to the RS and no really auditable way to track it down af= ter >>>> the fact. This is a design feature in the good case, and terrifying in= the >>>> bad case. >>>> >>>> If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please = talk to >>>> the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expo= sed anything at all. >>>> And from the perspective of both the patient and the RS, this is more >>>> privacy-preserving, and it=E2=80=99s really the least surprising optio= n. Once the >>>> client gets to the AS, it can start a negotiation of figuring out who = the >>>> RO is for the information being accessed. >>>> >>>> On top of this, the usability expectations of people managing their ow= n >>>> AS, or set of AS=E2=80=99s for multiple personas to keep things separa= te, is a huge >>>> burden. Even in the tech community, I know people who can=E2=80=99t re= liably manage >>>> more than one email address for different purposes. I wouldn=E2=80=99t= expect my >>>> partner to do that =E2=80=94 they have trouble enough balancing all th= e logins and >>>> sessions required for different kids remote schooling, I couldn=E2=80= =99t imagine >>>> them having to understand all the requirements for managing multiple >>>> authorization servers and associated policies. I also don=E2=80=99t ex= pect any >>>> person to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve been on= the internet for decades and I can >>>> barely keep tabs on my GPG keys, and only use them when I am forced to= . >>>> This is exactly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I t= hink Ben mentions >>>> above, people will just want to outsource that to someone else, and th= e >>>> reality will be a few popular providers. >>>> >>>> In which case, we could end up doing a ton of work to allow an RS >>>> choice only to end up with a world where the RS ends up making a limit= ed >>>> choice anyway. We see how that plays out with OpenID Connect =E2=80=94= RP=E2=80=99s could >>>> allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s >>>> where the users are. (And that=E2=80=99s not to say anything of the pr= oprietary >>>> OIDC-like protocols, but that=E2=80=99s another discussion). >>>> >>>> For further reading on these topics, I recommend both =E2=80=9CWhy Joh= nny Can=E2=80=99t >>>> Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D. >>>> >>>> So what does this have to do with GNAP? I think we can be clear-eyed o= n >>>> what kinds of expectations we have for the participants. If we expect = users >>>> (RO=E2=80=99s) to have to set up the AS-RS relationship, or expect the= m to carry >>>> their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99v= e lost the battle for >>>> relevance. >>>> >>>> =E2=80=94 Justin >>> >>> >>> >> -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000005e24c205be3242d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Alan,=C2=A0

    Yes, but in that flow, t= he token relationship between AS-RS and AS-RO is only secure if the tokens = issued by AS-RS are cryptographically attenuable in the first place.=C2=A0<= /div>

    Fabien

    <= div dir=3D"ltr" class=3D"gmail_attr">On Mon, Mar 22, 2021 at 9:26 PM Alan K= arp <alanhkarp@gmail.com> = wrote:
    Justin Rich= er <jricher@mit.edu= > wrote:
    =

    But with all that in mind, I think the key here is= going to be looking at what the inputs to the AS are, and how those can be= defined in an interoperable way for AS=E2=80=99s that can accept them. I t= hink there=E2=80=99s a lot of room for innovation and flexibility here that= doesn=E2=80=99t break the trust model or core use cases. If I have an AS-R= S set that won=E2=80=99t accept my favorite flavor of policy engine inputs,= then I can decide not to use that one. But this is a very different questi= on than saying the RS itself needs to accept my own AS =E2=80=94 and we can= =E2=80=99t keep conflating these two models.

    I agree.=C2=A0 The point of having an AS-RO is to allow RO to= specify a policy for which of RO's access tokens should be delegated u= nder what conditions.=C2=A0 AS-RS should not need to understand those polic= ies.=C2=A0 The flow would be
    • RO contacts AS-RS and gets o= ne or more access tokens.
    • RO delegates one or more of those tokens,= potentially sub-scoped, to AS-RO.
    • A different user contacts AS-RO = to get a potentially sub-scoped access token from AS-RO.
    • That user = presents the access token delegated by AS-RO when invoking the resource.
    AS-RS only needs to verify that the delegation chain= is legitimate, e.g., no increase in scope, and that it grants permission f= or the request being made.=C2=A0 AS-RS does not need to understand the poli= cy behind granting the delegation by AS-RO.

    -----= ---------
    Alan Karp


    =
    On Mon, Mar 22, 2021 at 11:40 AM Just= in Richer <jricher@= mit.edu> wrote:
    Adrian,

    I think this shows the problem with = the terminology as it=E2=80=99s been applied in this conversation, which I= =E2=80=99ve tried to shine light on before. What you and others are calling= the =E2=80=9CRS=E2=80=9D is really the =E2=80=9CAS and RS working together= =E2=80=9D =E2=80=94 everything to the right of the line. When Denis had bro= ught up =E2=80=9Celiminating the AS=E2=80=9D in another thread, what he=E2= =80=99d really done is labeled everything to the right of the line as the = =E2=80=9CRS=E2=80=9D. Of course, the irony here is that everything to the r= ight of the line used all be called the =E2=80=9CAS=E2=80=9D or simply =E2= =80=9Cserver=E2=80=9D in the OAuth 1 days. As you say below, I don=E2=80=99= t want the client to have visibility on what happens on that side.=C2=A0

    Note well: The Google+ logo labeled =E2=80=9CIdP=E2= =80=9D in the diagram is not the AS, as far as GNAP is concerned. It does n= ot issue an access token that the RS will accept. The elements to the left = of the line could be a lot of things, but they are NOT the AS =E2=80=94 by = definition. The client lives over on the left, but so do any external input= s to the AS. These could be policy inputs on behalf of the RO, they could b= e presentation artifacts, they could be federated logins, they could be the= output of policy decisions. How the AS comes to trust those things is up t= o the AS=E2=80=99s implementation. It=E2=80=99s something we can talk about= , but ultimately GNAP won=E2=80=99t be in any position to dictate because i= n practice some AS=E2=80=99s are simply going to internalize all policies a= nd we will never successfully force those open.=C2=A0

    <= div>But with all that in mind, I think the key here is going to be looking = at what the inputs to the AS are, and how those can be defined in an intero= perable way for AS=E2=80=99s that can accept them. I think there=E2=80=99s = a lot of room for innovation and flexibility here that doesn=E2=80=99t brea= k the trust model or core use cases. If I have an AS-RS set that won=E2=80= =99t accept my favorite flavor of policy engine inputs, then I can decide n= ot to use that one. But this is a very different question than saying the R= S itself needs to accept my own AS =E2=80=94 and we can=E2=80=99t keep conf= lating these two models.

    So to me, GNAP can suppor= t a Zero Trust Architecture by LEVERAGING the AS, not by subsuming or elimi= nating it. It is in fact the AS, not the client and not the RS, that will r= equest and consume the results of a privacy-preserving zero-trust policy qu= ery thing. Anything that happens downstream from that is of little concern = to the zero-trust components because, as you point out, it=E2=80=99s on the= =E2=80=9Cother side=E2=80=9D of the line.=C2=A0

    I= think we got this basic component model pretty right in OAuth: the AS and = RS and client working together. Where OAuth misses the mark is the assumpti= on that the user has to log in to the AS through a webpage and interact dir= ectly, thereby proving they=E2=80=99re the RO. It=E2=80=99s this latter spa= ce where I think we can both push innovation and also address the important= and compelling use cases like the ones you=E2=80=99re bringing.
    =
    =C2=A0=E2=80=94 Justin

    On Mar 22, 2021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> wrote= :

    I'm sorry, Justin. As a Resource Owner= , I look at the RS trust boundary (the dotted line in the diagram) as being= the RS. I don't expect any visibility into what's going on on the= =C2=A0right.=C2=A0

    My problem with the framing you propo= se is that requests are going to the RS (or the AS-RS) and I don't want= to share my policies with the AS-RS. I want to keep the RS and AS-RS as ig= norant as possible.

    Adrian

    On Mon, Mar 22, 20= 21 at 1:48 PM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    What you=E2=80= =99re discussing below, in terms of logging in to a site, is not approachin= g the RS. You are in fact approaching the client, and identifying both the = AS and RS to the client. The client is a client of your identity in = this model, and the RS is part of the identity provider. It=E2=80=99s reall= y important that we don=E2=80=99t conflate the RS and client in this way as= it leads to a lot of confusion downstream and a lot of broken trust bounda= ries.

    With that model in mind, approaching the =E2= =80=9CRS" and providing it your identity is really just a case of the = =E2=80=9Cfederated login to AS=E2=80=9D pattern that we discussed on the WG= call. The user here approaches an RS, which has its own AS. To share thing= s from this RS, the RO has to authenticate to the RS=E2=80=99s AS. This par= ticular AS allows the RO to do so using an external identity =E2=80=94 in w= hich case, the AS is now a =E2=80=9Cclient=E2=80=9D of a separate, disconne= cted (but layered) delegation. The ultimate client that eventually calls th= e RS down the way may or may not know about these layers.=C2=A0
    <= br>
    <PastedGraphic-1.png>
    = This same AS, which is closely tied to the RS and trusted by the RS, might = also take in FIDO credentials, or DIDs, or any number of other proof mechan= isms. The output of this is an access token the RS trusts, but the input is= up to the AS. The RS is not what you=E2=80=99re logging in to.
    <= br>
    =C2=A0=E2=80=94 Justin

    =
    On Mar 22, 2021, at 1:28 PM, Adrian Gropper <agropper@healthurl.com> wrote:=

    I too am in favor of avoiding consolidation= and correlation. Right now, when I approach a service provider (RS) for th= e first time, I'm offered the opportunity to identify my persona as: em= ail, sign-in with Google, Facebook, or Apple. I know there are people who t= ry to create one-off email addresses but that is mostly a waste of time.=C2= =A0

    So, along come FIDO2 and DID wallets to the rescue. = Now, in theory, I have a way to start out my RS relationship pseudonymously= .=C2=A0

    When I want my resource to be discovered o= r shared I will post that RS URL including my pseudonym. If I then want to = introduce a mediator=C2=A0in front of my AS or messaging service=C2=A0endpo= int, I have that option. If I want to keep requests away from the mediator,= I would publish an encryption key along with my pseudonym.

    <= /div>
    - Adrian



    On Mon, Mar 22, 2021= at 9:55 AM Justin Richer <jricher@mit.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:=
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhkarp@gmail.com> shared a talk about the Principle Of Leas= t
    >> Authority (POLA) in a recent comment
    >> https:/= /github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-8030996= 93
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --0000000000005e24c205be3242d8-- From nobody Tue Mar 23 08:15:39 2021 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 829E43A11DE for ; Tue, 23 Mar 2021 08:15:36 -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 O2x7h2LWqmkX for ; Tue, 23 Mar 2021 08:15:32 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 106CA3A11DD for ; Tue, 23 Mar 2021 08:15:32 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id y18so14665862qky.11 for ; Tue, 23 Mar 2021 08:15:32 -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=tbDhQjIIit6gYv35LmLI39+BmksslvFwjOkN/MobPSE=; b=V1ijQkQNb4g7khJsJz/GTL9LDhufAx6prTVxTMYXgXSWxNFZ95FmO2g4XMPEvHFNQe PX3NinopQWKLBcniI4+DbTX348h5+VnWvIh1sDjafcno2xhjUWEOTpJRUpMTVLyyRTWu 9rsD9d+nWjuZfWoyCKSSYEaxBVmocwCKtOIo4vwJenEurIw6pUUHSftwY+sA5MAbeAQx xD1XKaAK1tWIVhNAnKBeoYjAsxlRr+klKOEM/A3M9akWkWQVHGcGqSS3EqqfnyTd2Uh4 C31CbBhs4vvvRvJclN0LqVLgMvX65xRQ2CRqPgs+/gdpiJYZBmVAhuwJYHtIGF4nSdaj wMHQ== 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=tbDhQjIIit6gYv35LmLI39+BmksslvFwjOkN/MobPSE=; b=pfJ5qUolfudmTYeGhJ8Kv1xe9N8Q3PPAQuvGF9Tc6Cg1ku3Z6aiWZmHhhkCssi8jYY fl2ILrryuGr7e0Yu6JSSjH8f4NzX3OlHFuJQ5UpOlKIf7oa0LtdEBFibFlofm7FDGrKU n4g/e5SWyFwrDk9X9vNNNTLTRM2ET7jlc2m8XWLKiGx2SAfSNqKwj3X9Mmz81OcGfAsC V0OX1yBAoTfdRMQkYAErtUkWM0t/FWsMh9bVy9IMygkjO+yMq/g7pqI2IM3YoCF5kvza Wu6XqDekOrw4yfbQJnnqZAJ0J2/EQvStrJMEXFO582P7xLhjhH5hWgiFpiRmEd7wb/ov 3JMw== X-Gm-Message-State: AOAM530VRTPfM/0zHuvkTtO+b5IDK6f6Zrslk+o6lXODNsvoPUSzPjZd GvwNUudcKRSUc2ryuzxgHvzHOknF4+4mry9ujDI= X-Google-Smtp-Source: ABdhPJzehTOd7AJirGv3c2wACV7zde6Va9HlCFyk42k5PPNh35ws/Pn9AFkUBEqF3YMwIjG9l6Cure81d1e5lLl8Zpw= X-Received: by 2002:a37:3c8:: with SMTP id 191mr5824708qkd.90.1616512528792; Tue, 23 Mar 2021 08:15:28 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> In-Reply-To: From: Alan Karp Date: Tue, 23 Mar 2021 08:15:17 -0700 Message-ID: To: Fabien Imbault Cc: Justin Richer , Adrian Gropper , Benjamin Kaduk , Mark Miller , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000000dc22105be35a768" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2021 15:15:37 -0000 --0000000000000dc22105be35a768 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Fabien Imbault wrote: > Hi Alan, > > Yes, but in that flow, the token relationship between AS-RS and AS-RO is > only secure if the tokens issued by AS-RS are cryptographically attenuabl= e > in the first place. > Attenuated delegation is a requirement, but that doesn't have to be done cryptographically. Token exchange works just fine. SPKI and zcap-ld are examples of the crypto approach, and we used token exchange in the system for HP. -------------- Alan Karp On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault wrote: > Hi Alan, > > Yes, but in that flow, the token relationship between AS-RS and AS-RO is > only secure if the tokens issued by AS-RS are cryptographically attenuabl= e > in the first place. > > Fabien > > On Mon, Mar 22, 2021 at 9:26 PM Alan Karp wrote: > >> Justin Richer wrote: >> >>> >>> But with all that in mind, I think the key here is going to be looking >>> at what the inputs to the AS are, and how those can be defined in an >>> interoperable way for AS=E2=80=99s that can accept them. I think there= =E2=80=99s a lot of >>> room for innovation and flexibility here that doesn=E2=80=99t break the= trust model >>> or core use cases. If I have an AS-RS set that won=E2=80=99t accept my = favorite >>> flavor of policy engine inputs, then I can decide not to use that one. = But >>> this is a very different question than saying the RS itself needs to ac= cept >>> my own AS =E2=80=94 and we can=E2=80=99t keep conflating these two mode= ls. >>> >>> I agree. The point of having an AS-RO is to allow RO to specify a >> policy for which of RO's access tokens should be delegated under what >> conditions. AS-RS should not need to understand those policies. The fl= ow >> would be >> >> - RO contacts AS-RS and gets one or more access tokens. >> - RO delegates one or more of those tokens, potentially sub-scoped, >> to AS-RO. >> - A different user contacts AS-RO to get a potentially sub-scoped >> access token from AS-RO. >> - That user presents the access token delegated by AS-RO when >> invoking the resource. >> >> AS-RS only needs to verify that the delegation chain is legitimate, e.g.= , >> no increase in scope, and that it grants permission for the request bein= g >> made. AS-RS does not need to understand the policy behind granting the >> delegation by AS-RO. >> >> -------------- >> Alan Karp >> >> >> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer wrote: >> >>> Adrian, >>> >>> I think this shows the problem with the terminology as it=E2=80=99s bee= n applied >>> in this conversation, which I=E2=80=99ve tried to shine light on before= . What you >>> and others are calling the =E2=80=9CRS=E2=80=9D is really the =E2=80=9C= AS and RS working together=E2=80=9D >>> =E2=80=94 everything to the right of the line. When Denis had brought u= p >>> =E2=80=9Celiminating the AS=E2=80=9D in another thread, what he=E2=80= =99d really done is labeled >>> everything to the right of the line as the =E2=80=9CRS=E2=80=9D. Of cou= rse, the irony here >>> is that everything to the right of the line used all be called the =E2= =80=9CAS=E2=80=9D or >>> simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say below, = I don=E2=80=99t want the >>> client to have visibility on what happens on that side. >>> >>> Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the diagra= m is not the AS, >>> as far as GNAP is concerned. It does not issue an access token that the= RS >>> will accept. The elements to the left of the line could be a lot of thi= ngs, >>> but they are NOT the AS =E2=80=94 by definition. The client lives over = on the left, >>> but so do any external inputs to the AS. These could be policy inputs o= n >>> behalf of the RO, they could be presentation artifacts, they could be >>> federated logins, they could be the output of policy decisions. How the= AS >>> comes to trust those things is up to the AS=E2=80=99s implementation. I= t=E2=80=99s >>> something we can talk about, but ultimately GNAP won=E2=80=99t be in an= y position >>> to dictate because in practice some AS=E2=80=99s are simply going to in= ternalize >>> all policies and we will never successfully force those open. >>> >>> But with all that in mind, I think the key here is going to be looking >>> at what the inputs to the AS are, and how those can be defined in an >>> interoperable way for AS=E2=80=99s that can accept them. I think there= =E2=80=99s a lot of >>> room for innovation and flexibility here that doesn=E2=80=99t break the= trust model >>> or core use cases. If I have an AS-RS set that won=E2=80=99t accept my = favorite >>> flavor of policy engine inputs, then I can decide not to use that one. = But >>> this is a very different question than saying the RS itself needs to ac= cept >>> my own AS =E2=80=94 and we can=E2=80=99t keep conflating these two mode= ls. >>> >>> So to me, GNAP can support a Zero Trust Architecture by LEVERAGING the >>> AS, not by subsuming or eliminating it. It is in fact the AS, not the >>> client and not the RS, that will request and consume the results of a >>> privacy-preserving zero-trust policy query thing. Anything that happens >>> downstream from that is of little concern to the zero-trust components >>> because, as you point out, it=E2=80=99s on the =E2=80=9Cother side=E2= =80=9D of the line. >>> >>> I think we got this basic component model pretty right in OAuth: the AS >>> and RS and client working together. Where OAuth misses the mark is the >>> assumption that the user has to log in to the AS through a webpage and >>> interact directly, thereby proving they=E2=80=99re the RO. It=E2=80=99s= this latter space >>> where I think we can both push innovation and also address the importan= t >>> and compelling use cases like the ones you=E2=80=99re bringing. >>> >>> =E2=80=94 Justin >>> >>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper >>> wrote: >>> >>> I'm sorry, Justin. As a Resource Owner, I look at the RS trust boundary >>> (the dotted line in the diagram) as being the RS. I don't expect any >>> visibility into what's going on on the right. >>> >>> My problem with the framing you propose is that requests are going to >>> the RS (or the AS-RS) and I don't want to share my policies with the AS= -RS. >>> I want to keep the RS and AS-RS as ignorant as possible. >>> >>> Adrian >>> >>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer wrote: >>> >>>> Adrian, >>>> >>>> What you=E2=80=99re discussing below, in terms of logging in to a site= , is not >>>> approaching the RS. You are in fact approaching the client, and identi= fying >>>> both the AS and RS to the client. The client is a client *of your >>>> identity* in this model, and the RS is part of the identity provider. >>>> It=E2=80=99s really important that we don=E2=80=99t conflate the RS an= d client in this way >>>> as it leads to a lot of confusion downstream and a lot of broken trust >>>> boundaries. >>>> >>>> With that model in mind, approaching the =E2=80=9CRS" and providing it= your >>>> identity is really just a case of the =E2=80=9Cfederated login to AS= =E2=80=9D pattern that >>>> we discussed on the WG call. The user here approaches an RS, which has= its >>>> own AS. To share things from this RS, the RO has to authenticate to th= e >>>> RS=E2=80=99s AS. This particular AS allows the RO to do so using an ex= ternal >>>> identity =E2=80=94 in which case, the AS is now a =E2=80=9Cclient=E2= =80=9D of a separate, >>>> disconnected (but layered) delegation. The ultimate client that eventu= ally >>>> calls the RS down the way may or may not know about these layers. >>>> >>>> >>>> This same AS, which is closely tied to the RS and trusted by the RS, >>>> might also take in FIDO credentials, or DIDs, or any number of other p= roof >>>> mechanisms. The output of this is an access token the RS trusts, but t= he >>>> input is up to the AS. The RS is not what you=E2=80=99re logging in to= . >>>> >>>> =E2=80=94 Justin >>>> >>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper >>>> wrote: >>>> >>>> I too am in favor of avoiding consolidation and correlation. Right now= , >>>> when I approach a service provider (RS) for the first time, I'm offere= d the >>>> opportunity to identify my persona as: email, sign-in with Google, >>>> Facebook, or Apple. I know there are people who try to create one-off = email >>>> addresses but that is mostly a waste of time. >>>> >>>> So, along come FIDO2 and DID wallets to the rescue. Now, in theory, I >>>> have a way to start out my RS relationship pseudonymously. >>>> >>>> When I want my resource to be discovered or shared I will post that RS >>>> URL including my pseudonym. If I then want to introduce a mediator in = front >>>> of my AS or messaging service endpoint, I have that option. If I want = to >>>> keep requests away from the mediator, I would publish an encryption ke= y >>>> along with my pseudonym. >>>> >>>> - Adrian >>>> >>>> >>>> >>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer wrote: >>>> >>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk wrote: >>>>> > >>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote: >>>>> >> @Alan Karp shared a talk about the Principle >>>>> Of Least >>>>> >> Authority (POLA) in a recent comment >>>>> >> >>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issueco= mment-803099693 >>>>> >> I recommend it. >>>>> >> >>>>> >> We might expect a protocol with authorization in the title to use >>>>> authority >>>>> >> as a core principle. I advocate for a GNAP design that maximizes >>>>> the power >>>>> >> of the RO, to be seen as a human rights issue when the RO is a >>>>> human. This >>>>> >> causes me to ask how to combine better security with better human >>>>> rights in >>>>> >> GNAP. >>>>> >> >>>>> >> Who should have the least authority in the GNAP design? >>>>> >> >>>>> >> The AS derives authority as a delegate of the RO. If we ask the RO >>>>> to >>>>> >> partition limited authority across dozens of different ASs by >>>>> domain and >>>>> >> function, then we are not using technology to empower the >>>>> individual. >>>>> >> Probably the opposite, as we introduce consent fatigue and burden >>>>> normal >>>>> >> people to partition their lives into non-overlapping domains. >>>>> >> >>>>> >> My experience says we should aim for one AS per persona because >>>>> that maps >>>>> >> into the way we manage our public and private identities. POLA >>>>> would then >>>>> >> teach care in keeping ASs and RSs related to work / public separat= e >>>>> from >>>>> >> ASs and RSs related to private life so that a policy vulnerability >>>>> in our >>>>> >> delegation to an AS would have the least likelihood of harm. >>>>> > >>>>> > Thinking about how least authority/least privilege would apply to >>>>> GNAP >>>>> > seems like a useful exercise. I do want to point out some potentia= l >>>>> > pitfalls with one-AS-per-persona that we can also be aware of. If >>>>> > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= s >>>>> > identity in effect also serves as a persona identity and there are >>>>> privacy >>>>> > considerations to that. If, on the other hand, the >>>>> > multiple-personas-per-AS (presumably corresponding to multiple >>>>> humans) >>>>> > route is taken, we should consider whether that would lead to vario= us >>>>> > (e.g., market) forces driving consolidation to just a handful of >>>>> > super-popular AS services. That topic is a current matter of >>>>> concern to >>>>> > some IETF participants. >>>>> > >>>>> >>>>> Hi Ben, big +1 to this. This is something that we discussed ages ago >>>>> in the UMA working group, and it=E2=80=99s one of the biggest problem= s with the >>>>> personal AS (and personal data store) model. This kind of thing makes >>>>> RS-first trust models really difficult in practice. >>>>> >>>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that = wants to access >>>>> my medical information. It calls an RS and requests access, but it ha= sn=E2=80=99t >>>>> been granted anything yet. Now I as the RO have set up the RS so that= it >>>>> talks to my personal AS, that only I use. In addition to the RS havin= g to >>>>> be able to figure out which medical records are being requested from = the >>>>> context of the unauthenticated request (which means it needs identifi= ers in >>>>> the URL or something similar for the RS to be able to tell, assuming = that >>>>> it protects data for more than one person). So this client software d= oesn=E2=80=99t >>>>> know who I am and doesn=E2=80=99t know my medical record information,= makes a >>>>> completely unauthorized request to the RS, and the RS says =E2=80=9CG= o to Justin=E2=80=99s >>>>> personal AS to get a token=E2=80=9D. The client can now make a direct= correlation >>>>> between the data that=E2=80=99s being protected at the RS and the per= son running >>>>> the AS that protects it. Importantly, this client makes this call wit= h no >>>>> prior relationship to the RS and no really auditable way to track it = down >>>>> after the fact. This is a design feature in the good case, and terrif= ying >>>>> in the bad case. >>>>> >>>>> If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please= talk to >>>>> the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t exp= osed anything at all. >>>>> And from the perspective of both the patient and the RS, this is more >>>>> privacy-preserving, and it=E2=80=99s really the least surprising opti= on. Once the >>>>> client gets to the AS, it can start a negotiation of figuring out who= the >>>>> RO is for the information being accessed. >>>>> >>>>> On top of this, the usability expectations of people managing their >>>>> own AS, or set of AS=E2=80=99s for multiple personas to keep things s= eparate, is a >>>>> huge burden. Even in the tech community, I know people who can=E2=80= =99t reliably >>>>> manage more than one email address for different purposes. I wouldn= =E2=80=99t >>>>> expect my partner to do that =E2=80=94 they have trouble enough balan= cing all the >>>>> logins and sessions required for different kids remote schooling, I >>>>> couldn=E2=80=99t imagine them having to understand all the requiremen= ts for >>>>> managing multiple authorization servers and associated policies. I al= so >>>>> don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D =E2= =80=94 I=E2=80=99ve been on the internet for >>>>> decades and I can barely keep tabs on my GPG keys, and only use them = when I >>>>> am forced to. This is exactly the kind of =E2=80=9Cmarket pressure=E2= =80=9D that I think >>>>> Ben mentions above, people will just want to outsource that to someon= e >>>>> else, and the reality will be a few popular providers. >>>>> >>>>> In which case, we could end up doing a ton of work to allow an RS >>>>> choice only to end up with a world where the RS ends up making a limi= ted >>>>> choice anyway. We see how that plays out with OpenID Connect =E2=80= =94 RP=E2=80=99s could >>>>> allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s >>>>> where the users are. (And that=E2=80=99s not to say anything of the p= roprietary >>>>> OIDC-like protocols, but that=E2=80=99s another discussion). >>>>> >>>>> For further reading on these topics, I recommend both =E2=80=9CWhy Jo= hnny >>>>> Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2= =80=9D. >>>>> >>>>> So what does this have to do with GNAP? I think we can be clear-eyed >>>>> on what kinds of expectations we have for the participants. If we exp= ect >>>>> users (RO=E2=80=99s) to have to set up the AS-RS relationship, or exp= ect them to >>>>> carry their AS, or manage their personal keys =E2=80=94 I think we=E2= =80=99ve lost the >>>>> battle for relevance. >>>>> >>>>> =E2=80=94 Justin >>>> >>>> >>>> >>> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --0000000000000dc22105be35a768 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan,=C2=A0<= div>
    Yes, but in that flow, the token relationship between AS= -RS and AS-RO is only secure if the tokens issued by AS-RS are cryptographi= cally attenuable in the first place.=C2=A0
    =C2= =A0
    Attenuated delegat= ion is a requirement, but that doesn't have to be done cryptographicall= y.=C2=A0 Token exchange works just fine.=C2=A0 SPKI and zcap-ld are example= s of the crypto approach, and we used token exchange in the system for HP.<= br>

    --------------
    A= lan Karp


    On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault <= fabien.imbault@gmail.com>= ; wrote:
    Hi Alan,=C2=A0

    Yes, but in that flow, the toke= n relationship between AS-RS and AS-RO is only secure if the tokens issued = by AS-RS are cryptographically attenuable in the first place.=C2=A0

    Fabien

    On Mon, Mar 22, 2021 at 9:26 PM Alan Karp <= ;alanhkarp@gmail.c= om> wrote:
    J= ustin Richer <jrich= er@mit.edu> wrote:

    But with all that in mind, I think the = key here is going to be looking at what the inputs to the AS are, and how t= hose can be defined in an interoperable way for AS=E2=80=99s that can accep= t them. I think there=E2=80=99s a lot of room for innovation and flexibilit= y here that doesn=E2=80=99t break the trust model or core use cases. If I h= ave an AS-RS set that won=E2=80=99t accept my favorite flavor of policy eng= ine inputs, then I can decide not to use that one. But this is a very diffe= rent question than saying the RS itself needs to accept my own AS =E2=80=94= and we can=E2=80=99t keep conflating these two models.

    I agree.=C2=A0 The point of having an AS-RO is to = allow RO to specify a policy for which of RO's access tokens should be = delegated under what conditions.=C2=A0 AS-RS should not need to understand = those policies.=C2=A0 The flow would be
    • RO contacts AS-RS= and gets one or more access tokens.
    • RO delegates one or more of th= ose tokens, potentially sub-scoped, to AS-RO.
    • A different user cont= acts AS-RO to get a potentially sub-scoped access token from AS-RO.
      • That user presents the access token delegated by AS-RO when invoking the r= esource.
    AS-RS only needs to verify that the deleg= ation chain is legitimate, e.g., no increase in scope, and that it grants p= ermission for the request being made.=C2=A0 AS-RS does not need to understa= nd the policy behind granting the delegation by AS-RO.

    --------------
    Alan Karp


    On Mon, Mar 22, 2021 at 11= :40 AM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    I think this shows the pr= oblem with the terminology as it=E2=80=99s been applied in this conversatio= n, which I=E2=80=99ve tried to shine light on before. What you and others a= re calling the =E2=80=9CRS=E2=80=9D is really the =E2=80=9CAS and RS workin= g together=E2=80=9D =E2=80=94 everything to the right of the line. When Den= is had brought up =E2=80=9Celiminating the AS=E2=80=9D in another thread, w= hat he=E2=80=99d really done is labeled everything to the right of the line= as the =E2=80=9CRS=E2=80=9D. Of course, the irony here is that everything = to the right of the line used all be called the =E2=80=9CAS=E2=80=9D or sim= ply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say below, I don= =E2=80=99t want the client to have visibility on what happens on that side.= =C2=A0

    Note well: The Google+ logo labeled =E2=80= =9CIdP=E2=80=9D in the diagram is not the AS, as far as GNAP is concerned. = It does not issue an access token that the RS will accept. The elements to = the left of the line could be a lot of things, but they are NOT the AS =E2= =80=94 by definition. The client lives over on the left, but so do any exte= rnal inputs to the AS. These could be policy inputs on behalf of the RO, th= ey could be presentation artifacts, they could be federated logins, they co= uld be the output of policy decisions. How the AS comes to trust those thin= gs is up to the AS=E2=80=99s implementation. It=E2=80=99s something we can = talk about, but ultimately GNAP won=E2=80=99t be in any position to dictate= because in practice some AS=E2=80=99s are simply going to internalize all = policies and we will never successfully force those open.=C2=A0
    <= br>
    But with all that in mind, I think the key here is going to b= e looking at what the inputs to the AS are, and how those can be defined in= an interoperable way for AS=E2=80=99s that can accept them. I think there= =E2=80=99s a lot of room for innovation and flexibility here that doesn=E2= =80=99t break the trust model or core use cases. If I have an AS-RS set tha= t won=E2=80=99t accept my favorite flavor of policy engine inputs, then I c= an decide not to use that one. But this is a very different question than s= aying the RS itself needs to accept my own AS =E2=80=94 and we can=E2=80=99= t keep conflating these two models.

    So to me, GNAP= can support a Zero Trust Architecture by LEVERAGING the AS, not by subsumi= ng or eliminating it. It is in fact the AS, not the client and not the RS, = that will request and consume the results of a privacy-preserving zero-trus= t policy query thing. Anything that happens downstream from that is of litt= le concern to the zero-trust components because, as you point out, it=E2=80= =99s on the =E2=80=9Cother side=E2=80=9D of the line.=C2=A0

    <= /div>
    I think we got this basic component model pretty right in OAuth: = the AS and RS and client working together. Where OAuth misses the mark is t= he assumption that the user has to log in to the AS through a webpage and i= nteract directly, thereby proving they=E2=80=99re the RO. It=E2=80=99s this= latter space where I think we can both push innovation and also address th= e important and compelling use cases like the ones you=E2=80=99re bringing.=

    =C2=A0=E2=80=94 Justin

    On Mar 22, 2021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I'm sorry, Justin. As a Res= ource Owner, I look at the RS trust boundary (the dotted line in the diagra= m) as being the RS. I don't expect any visibility into what's going= on on the=C2=A0right.=C2=A0

    My problem with the framing= you propose is that requests are going to the RS (or the AS-RS) and I don&= #39;t want to share my policies with the AS-RS. I want to keep the RS and A= S-RS as ignorant as possible.

    Adrian
    On Mon, = Mar 22, 2021 at 1:48 PM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    What you= =E2=80=99re discussing below, in terms of logging in to a site, is not appr= oaching the RS. You are in fact approaching the client, and identifying bot= h the AS and RS to the client. The client is a client of your identity in this model, and the RS is part of the identity provider. It=E2=80=99s= really important that we don=E2=80=99t conflate the RS and client in this = way as it leads to a lot of confusion downstream and a lot of broken trust = boundaries.

    With that model in mind, approaching t= he =E2=80=9CRS" and providing it your identity is really just a case o= f the =E2=80=9Cfederated login to AS=E2=80=9D pattern that we discussed on = the WG call. The user here approaches an RS, which has its own AS. To share= things from this RS, the RO has to authenticate to the RS=E2=80=99s AS. Th= is particular AS allows the RO to do so using an external identity =E2=80= =94 in which case, the AS is now a =E2=80=9Cclient=E2=80=9D of a separate, = disconnected (but layered) delegation. The ultimate client that eventually = calls the RS down the way may or may not know about these layers.=C2=A0

    <Paste= dGraphic-1.png>
    This same AS, which is closely tied to = the RS and trusted by the RS, might also take in FIDO credentials, or DIDs,= or any number of other proof mechanisms. The output of this is an access t= oken the RS trusts, but the input is up to the AS. The RS is not what you= =E2=80=99re logging in to.

    =C2=A0=E2=80=94 Justin<= br>

    On Mar 22, 2021, at 1:28 PM, Adr= ian Gropper <agropper@healthurl.com> wrote:

    I too= am in favor of avoiding consolidation and correlation. Right now, when I a= pproach a service provider (RS) for the first time, I'm offered the opp= ortunity to identify my persona as: email, sign-in with Google, Facebook, o= r Apple. I know there are people who try to create one-off email addresses = but that is mostly a waste of time.=C2=A0

    So, along come= FIDO2 and DID wallets to the rescue. Now, in theory, I have a way to start= out my RS relationship pseudonymously.=C2=A0

    When= I want my resource to be discovered or shared I will post that RS URL incl= uding my pseudonym. If I then want to introduce a mediator=C2=A0in front of= my AS or messaging service=C2=A0endpoint, I have that option. If I want to= keep requests away from the mediator, I would publish an encryption key al= ong with my pseudonym.

    - Adrian



    On Mon, Mar 22, 2021 at 9:55 AM Justin Richer <jricher@mit.edu> wrote= :
    On Mar 21, 202= 1, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhkarp@gmail.com> shared a talk about the Principle Of Leas= t
    >> Authority (POLA) in a recent comment
    >> https:/= /github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-8030996= 93
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --0000000000000dc22105be35a768-- From nobody Wed Mar 24 09:36:54 2021 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 CAAB63A3060 for ; Wed, 24 Mar 2021 09:36:52 -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 Opj-FcFxxxbN for ; Wed, 24 Mar 2021 09:36:48 -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 D4A073A305F for ; Wed, 24 Mar 2021 09:36:47 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id k8so22156282iop.12 for ; Wed, 24 Mar 2021 09:36:47 -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=6QFG6OnjlGFY2PbA8td9cPxk5YxhUxKLIvbTGztFK2k=; b=BQ+5HUX355M/vdXbiwYBM4N0imsKirmYcAzAEGOGfFgcmDK1jpQrXV1o1ebHNtvkOO o5e/mLl2uFx1GHITpGltjgo76l8yPZygCSj92oMEVE2SMLTaiEjVFQ4a7LIy/AH4XT0o o8dgZsMZTc0Z+zaQDCrYR2KdunoVif9jZVOmDkpC1LxxoNbgOSkeZ77MMzmJbVpIc3Oa ZRh8tm845b/8FetBgls/pVsVMt4WP+kT7P575o50qoWjKLQpDQAUWMA6rMldb0OtLhEc hG4SyVP56MbMp3QDSFwvwUTXQ0YI8kesJuNMEZyx4WbGLiJ+5BHSiVDaniHPS6St/Q5U 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=6QFG6OnjlGFY2PbA8td9cPxk5YxhUxKLIvbTGztFK2k=; b=jI8pqX35PLjIn7OWT+LY47gRvoxKoSdN55duM6HZfhVFtLv2reAzY1kpM5pDecLWYO M4iGnrGM4gT4aZmPVRDPF/Vtck5pr7FjxE/UxQ38jfaPzOfdJArwBXLolkq/GKDHPZR3 FA7zWn8JbjL+/Cq117M8DsfL1pw4Fn7mnLna73ITV9+CnsTl7G7ERB9//Q3JDf/QV++s RTZN1ufg+Zv1KsICIcd9kyQaHS9/k4R5xpoB9UDYng+Og/RS09dYcUziEuWnycAQ8p3+ Dl+jhPLH8MM7NyOQhKE9JOmgh/p9UlMUDSANGSPecrNoTgMc7WgwTjEgCGeBytnNjpOK 3EgA== X-Gm-Message-State: AOAM533zbx9OwTfGwJTfCDoWoi2LflhCiNdeSYUkGBI58T6BUu6fJQF4 FPXffmaVZNBaEl5zsEyb3YX+443KMOt1Sa5lZkQ= X-Google-Smtp-Source: ABdhPJzcIVfj1+2qZ7Pr/AP52KW+zl1wQg7BekebehyB/cTzeq8FY3Jekd+tP1k3nPnhKPjrjttky9Y1YwG4WcjXay4= X-Received: by 2002:a05:6602:228f:: with SMTP id d15mr2963603iod.141.1616603806221; Wed, 24 Mar 2021 09:36:46 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> In-Reply-To: From: Fabien Imbault Date: Wed, 24 Mar 2021 17:36:34 +0100 Message-ID: To: Alan Karp Cc: Justin Richer , Adrian Gropper , Benjamin Kaduk , Mark Miller , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000009cc85705be4ae7aa" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2021 16:36:53 -0000 --0000000000009cc85705be4ae7aa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alan and Adrian, I've created issue AS-RO policy delegation ( https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to capture your input. A first question that arises: can we give a definition to AS-RO? Thanks Fabien On Tue, Mar 23, 2021 at 4:15 PM Alan Karp wrote: > Fabien Imbault wrote: > >> Hi Alan, >> >> Yes, but in that flow, the token relationship between AS-RS and AS-RO is >> only secure if the tokens issued by AS-RS are cryptographically attenuab= le >> in the first place. >> > > Attenuated delegation is a requirement, but that doesn't have to be done > cryptographically. Token exchange works just fine. SPKI and zcap-ld are > examples of the crypto approach, and we used token exchange in the system > for HP. > > -------------- > Alan Karp > > > On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault > wrote: > >> Hi Alan, >> >> Yes, but in that flow, the token relationship between AS-RS and AS-RO is >> only secure if the tokens issued by AS-RS are cryptographically attenuab= le >> in the first place. >> >> Fabien >> >> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp wrote: >> >>> Justin Richer wrote: >>> >>>> >>>> But with all that in mind, I think the key here is going to be looking >>>> at what the inputs to the AS are, and how those can be defined in an >>>> interoperable way for AS=E2=80=99s that can accept them. I think there= =E2=80=99s a lot of >>>> room for innovation and flexibility here that doesn=E2=80=99t break th= e trust model >>>> or core use cases. If I have an AS-RS set that won=E2=80=99t accept my= favorite >>>> flavor of policy engine inputs, then I can decide not to use that one.= But >>>> this is a very different question than saying the RS itself needs to a= ccept >>>> my own AS =E2=80=94 and we can=E2=80=99t keep conflating these two mod= els. >>>> >>>> I agree. The point of having an AS-RO is to allow RO to specify a >>> policy for which of RO's access tokens should be delegated under what >>> conditions. AS-RS should not need to understand those policies. The f= low >>> would be >>> >>> - RO contacts AS-RS and gets one or more access tokens. >>> - RO delegates one or more of those tokens, potentially sub-scoped, >>> to AS-RO. >>> - A different user contacts AS-RO to get a potentially sub-scoped >>> access token from AS-RO. >>> - That user presents the access token delegated by AS-RO when >>> invoking the resource. >>> >>> AS-RS only needs to verify that the delegation chain is legitimate, >>> e.g., no increase in scope, and that it grants permission for the reque= st >>> being made. AS-RS does not need to understand the policy behind granti= ng >>> the delegation by AS-RO. >>> >>> -------------- >>> Alan Karp >>> >>> >>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer wrote: >>> >>>> Adrian, >>>> >>>> I think this shows the problem with the terminology as it=E2=80=99s be= en >>>> applied in this conversation, which I=E2=80=99ve tried to shine light = on before. >>>> What you and others are calling the =E2=80=9CRS=E2=80=9D is really the= =E2=80=9CAS and RS working >>>> together=E2=80=9D =E2=80=94 everything to the right of the line. When = Denis had brought up >>>> =E2=80=9Celiminating the AS=E2=80=9D in another thread, what he=E2=80= =99d really done is labeled >>>> everything to the right of the line as the =E2=80=9CRS=E2=80=9D. Of co= urse, the irony here >>>> is that everything to the right of the line used all be called the =E2= =80=9CAS=E2=80=9D or >>>> simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say below,= I don=E2=80=99t want the >>>> client to have visibility on what happens on that side. >>>> >>>> Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the diagr= am is not the AS, >>>> as far as GNAP is concerned. It does not issue an access token that th= e RS >>>> will accept. The elements to the left of the line could be a lot of th= ings, >>>> but they are NOT the AS =E2=80=94 by definition. The client lives over= on the left, >>>> but so do any external inputs to the AS. These could be policy inputs = on >>>> behalf of the RO, they could be presentation artifacts, they could be >>>> federated logins, they could be the output of policy decisions. How th= e AS >>>> comes to trust those things is up to the AS=E2=80=99s implementation. = It=E2=80=99s >>>> something we can talk about, but ultimately GNAP won=E2=80=99t be in a= ny position >>>> to dictate because in practice some AS=E2=80=99s are simply going to i= nternalize >>>> all policies and we will never successfully force those open. >>>> >>>> But with all that in mind, I think the key here is going to be looking >>>> at what the inputs to the AS are, and how those can be defined in an >>>> interoperable way for AS=E2=80=99s that can accept them. I think there= =E2=80=99s a lot of >>>> room for innovation and flexibility here that doesn=E2=80=99t break th= e trust model >>>> or core use cases. If I have an AS-RS set that won=E2=80=99t accept my= favorite >>>> flavor of policy engine inputs, then I can decide not to use that one.= But >>>> this is a very different question than saying the RS itself needs to a= ccept >>>> my own AS =E2=80=94 and we can=E2=80=99t keep conflating these two mod= els. >>>> >>>> So to me, GNAP can support a Zero Trust Architecture by LEVERAGING the >>>> AS, not by subsuming or eliminating it. It is in fact the AS, not the >>>> client and not the RS, that will request and consume the results of a >>>> privacy-preserving zero-trust policy query thing. Anything that happen= s >>>> downstream from that is of little concern to the zero-trust components >>>> because, as you point out, it=E2=80=99s on the =E2=80=9Cother side=E2= =80=9D of the line. >>>> >>>> I think we got this basic component model pretty right in OAuth: the A= S >>>> and RS and client working together. Where OAuth misses the mark is the >>>> assumption that the user has to log in to the AS through a webpage and >>>> interact directly, thereby proving they=E2=80=99re the RO. It=E2=80=99= s this latter space >>>> where I think we can both push innovation and also address the importa= nt >>>> and compelling use cases like the ones you=E2=80=99re bringing. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper >>>> wrote: >>>> >>>> I'm sorry, Justin. As a Resource Owner, I look at the RS trust boundar= y >>>> (the dotted line in the diagram) as being the RS. I don't expect any >>>> visibility into what's going on on the right. >>>> >>>> My problem with the framing you propose is that requests are going to >>>> the RS (or the AS-RS) and I don't want to share my policies with the A= S-RS. >>>> I want to keep the RS and AS-RS as ignorant as possible. >>>> >>>> Adrian >>>> >>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer wrote: >>>> >>>>> Adrian, >>>>> >>>>> What you=E2=80=99re discussing below, in terms of logging in to a sit= e, is not >>>>> approaching the RS. You are in fact approaching the client, and ident= ifying >>>>> both the AS and RS to the client. The client is a client *of your >>>>> identity* in this model, and the RS is part of the identity provider. >>>>> It=E2=80=99s really important that we don=E2=80=99t conflate the RS a= nd client in this way >>>>> as it leads to a lot of confusion downstream and a lot of broken trus= t >>>>> boundaries. >>>>> >>>>> With that model in mind, approaching the =E2=80=9CRS" and providing i= t your >>>>> identity is really just a case of the =E2=80=9Cfederated login to AS= =E2=80=9D pattern that >>>>> we discussed on the WG call. The user here approaches an RS, which ha= s its >>>>> own AS. To share things from this RS, the RO has to authenticate to t= he >>>>> RS=E2=80=99s AS. This particular AS allows the RO to do so using an e= xternal >>>>> identity =E2=80=94 in which case, the AS is now a =E2=80=9Cclient=E2= =80=9D of a separate, >>>>> disconnected (but layered) delegation. The ultimate client that event= ually >>>>> calls the RS down the way may or may not know about these layers. >>>>> >>>>> >>>>> This same AS, which is closely tied to the RS and trusted by the RS, >>>>> might also take in FIDO credentials, or DIDs, or any number of other = proof >>>>> mechanisms. The output of this is an access token the RS trusts, but = the >>>>> input is up to the AS. The RS is not what you=E2=80=99re logging in t= o. >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper >>>>> wrote: >>>>> >>>>> I too am in favor of avoiding consolidation and correlation. Right >>>>> now, when I approach a service provider (RS) for the first time, I'm >>>>> offered the opportunity to identify my persona as: email, sign-in wit= h >>>>> Google, Facebook, or Apple. I know there are people who try to create >>>>> one-off email addresses but that is mostly a waste of time. >>>>> >>>>> So, along come FIDO2 and DID wallets to the rescue. Now, in theory, I >>>>> have a way to start out my RS relationship pseudonymously. >>>>> >>>>> When I want my resource to be discovered or shared I will post that R= S >>>>> URL including my pseudonym. If I then want to introduce a mediator in= front >>>>> of my AS or messaging service endpoint, I have that option. If I want= to >>>>> keep requests away from the mediator, I would publish an encryption k= ey >>>>> along with my pseudonym. >>>>> >>>>> - Adrian >>>>> >>>>> >>>>> >>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer wrote= : >>>>> >>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk wrote: >>>>>> > >>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote: >>>>>> >> @Alan Karp shared a talk about the >>>>>> Principle Of Least >>>>>> >> Authority (POLA) in a recent comment >>>>>> >> >>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuec= omment-803099693 >>>>>> >> I recommend it. >>>>>> >> >>>>>> >> We might expect a protocol with authorization in the title to use >>>>>> authority >>>>>> >> as a core principle. I advocate for a GNAP design that maximizes >>>>>> the power >>>>>> >> of the RO, to be seen as a human rights issue when the RO is a >>>>>> human. This >>>>>> >> causes me to ask how to combine better security with better human >>>>>> rights in >>>>>> >> GNAP. >>>>>> >> >>>>>> >> Who should have the least authority in the GNAP design? >>>>>> >> >>>>>> >> The AS derives authority as a delegate of the RO. If we ask the R= O >>>>>> to >>>>>> >> partition limited authority across dozens of different ASs by >>>>>> domain and >>>>>> >> function, then we are not using technology to empower the >>>>>> individual. >>>>>> >> Probably the opposite, as we introduce consent fatigue and burden >>>>>> normal >>>>>> >> people to partition their lives into non-overlapping domains. >>>>>> >> >>>>>> >> My experience says we should aim for one AS per persona because >>>>>> that maps >>>>>> >> into the way we manage our public and private identities. POLA >>>>>> would then >>>>>> >> teach care in keeping ASs and RSs related to work / public >>>>>> separate from >>>>>> >> ASs and RSs related to private life so that a policy vulnerabilit= y >>>>>> in our >>>>>> >> delegation to an AS would have the least likelihood of harm. >>>>>> > >>>>>> > Thinking about how least authority/least privilege would apply to >>>>>> GNAP >>>>>> > seems like a useful exercise. I do want to point out some potenti= al >>>>>> > pitfalls with one-AS-per-persona that we can also be aware of. If >>>>>> > one-AS-per-persona becomes one-persona-per-AS as well, then the AS= 's >>>>>> > identity in effect also serves as a persona identity and there are >>>>>> privacy >>>>>> > considerations to that. If, on the other hand, the >>>>>> > multiple-personas-per-AS (presumably corresponding to multiple >>>>>> humans) >>>>>> > route is taken, we should consider whether that would lead to >>>>>> various >>>>>> > (e.g., market) forces driving consolidation to just a handful of >>>>>> > super-popular AS services. That topic is a current matter of >>>>>> concern to >>>>>> > some IETF participants. >>>>>> > >>>>>> >>>>>> Hi Ben, big +1 to this. This is something that we discussed ages ago >>>>>> in the UMA working group, and it=E2=80=99s one of the biggest proble= ms with the >>>>>> personal AS (and personal data store) model. This kind of thing make= s >>>>>> RS-first trust models really difficult in practice. >>>>>> >>>>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that= wants to access >>>>>> my medical information. It calls an RS and requests access, but it h= asn=E2=80=99t >>>>>> been granted anything yet. Now I as the RO have set up the RS so tha= t it >>>>>> talks to my personal AS, that only I use. In addition to the RS havi= ng to >>>>>> be able to figure out which medical records are being requested from= the >>>>>> context of the unauthenticated request (which means it needs identif= iers in >>>>>> the URL or something similar for the RS to be able to tell, assuming= that >>>>>> it protects data for more than one person). So this client software = doesn=E2=80=99t >>>>>> know who I am and doesn=E2=80=99t know my medical record information= , makes a >>>>>> completely unauthorized request to the RS, and the RS says =E2=80=9C= Go to Justin=E2=80=99s >>>>>> personal AS to get a token=E2=80=9D. The client can now make a direc= t correlation >>>>>> between the data that=E2=80=99s being protected at the RS and the pe= rson running >>>>>> the AS that protects it. Importantly, this client makes this call wi= th no >>>>>> prior relationship to the RS and no really auditable way to track it= down >>>>>> after the fact. This is a design feature in the good case, and terri= fying >>>>>> in the bad case. >>>>>> >>>>>> If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, pleas= e talk to >>>>>> the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t ex= posed anything at all. >>>>>> And from the perspective of both the patient and the RS, this is mor= e >>>>>> privacy-preserving, and it=E2=80=99s really the least surprising opt= ion. Once the >>>>>> client gets to the AS, it can start a negotiation of figuring out wh= o the >>>>>> RO is for the information being accessed. >>>>>> >>>>>> On top of this, the usability expectations of people managing their >>>>>> own AS, or set of AS=E2=80=99s for multiple personas to keep things = separate, is a >>>>>> huge burden. Even in the tech community, I know people who can=E2=80= =99t reliably >>>>>> manage more than one email address for different purposes. I wouldn= =E2=80=99t >>>>>> expect my partner to do that =E2=80=94 they have trouble enough bala= ncing all the >>>>>> logins and sessions required for different kids remote schooling, I >>>>>> couldn=E2=80=99t imagine them having to understand all the requireme= nts for >>>>>> managing multiple authorization servers and associated policies. I a= lso >>>>>> don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D =E2= =80=94 I=E2=80=99ve been on the internet for >>>>>> decades and I can barely keep tabs on my GPG keys, and only use them= when I >>>>>> am forced to. This is exactly the kind of =E2=80=9Cmarket pressure= =E2=80=9D that I think >>>>>> Ben mentions above, people will just want to outsource that to someo= ne >>>>>> else, and the reality will be a few popular providers. >>>>>> >>>>>> In which case, we could end up doing a ton of work to allow an RS >>>>>> choice only to end up with a world where the RS ends up making a lim= ited >>>>>> choice anyway. We see how that plays out with OpenID Connect =E2=80= =94 RP=E2=80=99s could >>>>>> allow arbitrary IdPs but they choose Google because it works and tha= t=E2=80=99s >>>>>> where the users are. (And that=E2=80=99s not to say anything of the = proprietary >>>>>> OIDC-like protocols, but that=E2=80=99s another discussion). >>>>>> >>>>>> For further reading on these topics, I recommend both =E2=80=9CWhy J= ohnny >>>>>> Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2= =80=9D. >>>>>> >>>>>> So what does this have to do with GNAP? I think we can be clear-eyed >>>>>> on what kinds of expectations we have for the participants. If we ex= pect >>>>>> users (RO=E2=80=99s) to have to set up the AS-RS relationship, or ex= pect them to >>>>>> carry their AS, or manage their personal keys =E2=80=94 I think we= =E2=80=99ve lost the >>>>>> battle for relevance. >>>>>> >>>>>> =E2=80=94 Justin >>>>> >>>>> >>>>> >>>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> --0000000000009cc85705be4ae7aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Alan and Adrian,

    I've created is= sue AS-RO policy delegation (https://github.com/ietf-wg-gnap/gnap-core-proto= col/issues/223) to capture your input.=C2=A0
    A first question= that arises: can we give a definition to AS-RO?

    T= hanks
    Fabien

    On Tue, Mar 23, 2021 at 4:15 PM Alan Karp <= ;alanhkarp@gmail.com> wrote:<= br>
    Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan,=C2= =A0

    Yes, but in that flow, the token relationship betwee= n AS-RS and AS-RO is only secure if the tokens issued by AS-RS are cryptogr= aphically attenuable in the first place.=C2=A0
    =C2=A0
    Attenuated delegation is a requirement, = but that doesn't have to be done cryptographically.=C2=A0 Token exchang= e works just fine.=C2=A0 SPKI and zcap-ld are examples of the crypto approa= ch, and we used token exchange in the system for HP.

    --------------
    Alan Karp


    On Tue, Mar 23, 2021 at = 4:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan,=C2=A0
    <= br>
    Yes, but in that flow, the token relationship between AS-RS a= nd AS-RO is only secure if the tokens issued by AS-RS are cryptographically= attenuable in the first place.=C2=A0

    Fabien
    =

    = On Mon, Mar 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin Richer <jricher@mit.edu> wrote:
    <= /div>

    =
    But with all that in mind, I think the key here is going to be looking= at what the inputs to the AS are, and how those can be defined in an inter= operable way for AS=E2=80=99s that can accept them. I think there=E2=80=99s= a lot of room for innovation and flexibility here that doesn=E2=80=99t bre= ak the trust model or core use cases. If I have an AS-RS set that won=E2=80= =99t accept my favorite flavor of policy engine inputs, then I can decide n= ot to use that one. But this is a very different question than saying the R= S itself needs to accept my own AS =E2=80=94 and we can=E2=80=99t keep conf= lating these two models.

    I agre= e.=C2=A0 The point of having an AS-RO is to allow RO to specify a policy fo= r which of RO's access tokens should be delegated under what conditions= .=C2=A0 AS-RS should not need to understand those policies.=C2=A0 The flow = would be
    • RO contacts AS-RS and gets one or more access to= kens.
    • RO delegates one or more of those tokens, potentially sub-sco= ped, to AS-RO.
    • A different user contacts AS-RO to get a potentially= sub-scoped access token from AS-RO.
    • That user presents the access = token delegated by AS-RO when invoking the resource.
    AS-RS only needs to verify that the delegation chain is legitimate, e.g.= , no increase in scope, and that it grants permission for the request being= made.=C2=A0 AS-RS does not need to understand the policy behind granting t= he delegation by AS-RO.

    --------------
    Alan Ka= rp


    On Mon, Mar 22, 2021 at 11:40 AM Justin Richer <jricher@mit.edu> wrot= e:
    Adrian,<= div>
    I think this shows the problem with the terminology as i= t=E2=80=99s been applied in this conversation, which I=E2=80=99ve tried to = shine light on before. What you and others are calling the =E2=80=9CRS=E2= =80=9D is really the =E2=80=9CAS and RS working together=E2=80=9D =E2=80=94= everything to the right of the line. When Denis had brought up =E2=80=9Cel= iminating the AS=E2=80=9D in another thread, what he=E2=80=99d really done = is labeled everything to the right of the line as the =E2=80=9CRS=E2=80=9D.= Of course, the irony here is that everything to the right of the line used= all be called the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80=9D = in the OAuth 1 days. As you say below, I don=E2=80=99t want the client to h= ave visibility on what happens on that side.=C2=A0

    Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the diagram i= s not the AS, as far as GNAP is concerned. It does not issue an access toke= n that the RS will accept. The elements to the left of the line could be a = lot of things, but they are NOT the AS =E2=80=94 by definition. The client = lives over on the left, but so do any external inputs to the AS. These coul= d be policy inputs on behalf of the RO, they could be presentation artifact= s, they could be federated logins, they could be the output of policy decis= ions. How the AS comes to trust those things is up to the AS=E2=80=99s impl= ementation. It=E2=80=99s something we can talk about, but ultimately GNAP w= on=E2=80=99t be in any position to dictate because in practice some AS=E2= =80=99s are simply going to internalize all policies and we will never succ= essfully force those open.=C2=A0

    But with all that= in mind, I think the key here is going to be looking at what the inputs to= the AS are, and how those can be defined in an interoperable way for AS=E2= =80=99s that can accept them. I think there=E2=80=99s a lot of room for inn= ovation and flexibility here that doesn=E2=80=99t break the trust model or = core use cases. If I have an AS-RS set that won=E2=80=99t accept my favorit= e flavor of policy engine inputs, then I can decide not to use that one. Bu= t this is a very different question than saying the RS itself needs to acce= pt my own AS =E2=80=94 and we can=E2=80=99t keep conflating these two model= s.

    So to me, GNAP can support a Zero Trust Archite= cture by LEVERAGING the AS, not by subsuming or eliminating it. It is in fa= ct the AS, not the client and not the RS, that will request and consume the= results of a privacy-preserving zero-trust policy query thing. Anything th= at happens downstream from that is of little concern to the zero-trust comp= onents because, as you point out, it=E2=80=99s on the =E2=80=9Cother side= =E2=80=9D of the line.=C2=A0

    I think we got this b= asic component model pretty right in OAuth: the AS and RS and client workin= g together. Where OAuth misses the mark is the assumption that the user has= to log in to the AS through a webpage and interact directly, thereby provi= ng they=E2=80=99re the RO. It=E2=80=99s this latter space where I think we = can both push innovation and also address the important and compelling use = cases like the ones you=E2=80=99re bringing.

    =C2= =A0=E2=80=94 Justin

    On Mar 22, 2= 021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I'm sorry, Justin. As a Resource Owner, I look at the RS= trust boundary (the dotted line in the diagram) as being the RS. I don'= ;t expect any visibility into what's going on on the=C2=A0right.=C2=A0<= div>
    My problem with the framing you propose is that requests= are going to the RS (or the AS-RS) and I don't want to share my polici= es with the AS-RS. I want to keep the RS and AS-RS as ignorant as possible.=

    Adrian

    =
    On Mon, Mar 22, 2021 at 1:48 PM Justi= n Richer <jricher@m= it.edu> wrote:
    Adrian,

    What you=E2=80=99re discussing below,= in terms of logging in to a site, is not approaching the RS. You are in fa= ct approaching the client, and identifying both the AS and RS to the client= . The client is a client of your identity in this model, and the RS = is part of the identity provider. It=E2=80=99s really important that we don= =E2=80=99t conflate the RS and client in this way as it leads to a lot of c= onfusion downstream and a lot of broken trust boundaries.

    With that model in mind, approaching the =E2=80=9CRS" and prov= iding it your identity is really just a case of the =E2=80=9Cfederated logi= n to AS=E2=80=9D pattern that we discussed on the WG call. The user here ap= proaches an RS, which has its own AS. To share things from this RS, the RO = has to authenticate to the RS=E2=80=99s AS. This particular AS allows the R= O to do so using an external identity =E2=80=94 in which case, the AS is no= w a =E2=80=9Cclient=E2=80=9D of a separate, disconnected (but layered) dele= gation. The ultimate client that eventually calls the RS down the way may o= r may not know about these layers.=C2=A0

    <PastedG= raphic-1.png>
    This same AS, which is closely tied to th= e RS and trusted by the RS, might also take in FIDO credentials, or DIDs, o= r any number of other proof mechanisms. The output of this is an access tok= en the RS trusts, but the input is up to the AS. The RS is not what you=E2= =80=99re logging in to.

    =C2=A0=E2=80=94 Justin
    =

    On Mar 22, 2021, at 1:28 PM, Adrian= Gropper <ag= ropper@healthurl.com> wrote:

    I too am= in favor of avoiding consolidation and correlation. Right now, when I appr= oach a service provider (RS) for the first time, I'm offered the opport= unity to identify my persona as: email, sign-in with Google, Facebook, or A= pple. I know there are people who try to create one-off email addresses but= that is mostly a waste of time.=C2=A0

    So, along come FI= DO2 and DID wallets to the rescue. Now, in theory, I have a way to start ou= t my RS relationship pseudonymously.=C2=A0

    When I = want my resource to be discovered or shared I will post that RS URL includi= ng my pseudonym. If I then want to introduce a mediator=C2=A0in front of my= AS or messaging service=C2=A0endpoint, I have that option. If I want to ke= ep requests away from the mediator, I would publish an encryption key along= with my pseudonym.

    - Adrian

    <= div>

    On Mon, Mar 22, 2021 at 9:55 AM Justin Richer <jricher@mit.edu> wrote= :
    On Mar 21, 202= 1, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhkarp@gmail.com> shared a talk about the Principle Of Leas= t
    >> Authority (POLA) in a recent comment
    >> https:/= /github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-8030996= 93
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --0000000000009cc85705be4ae7aa-- From nobody Wed Mar 24 12:17:47 2021 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 148123A33A3 for ; Wed, 24 Mar 2021 12:17:45 -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 6etEjwnak_XM for ; Wed, 24 Mar 2021 12:17:40 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 2C57C3A33A0 for ; Wed, 24 Mar 2021 12:17:40 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id i9so19195510qka.2 for ; Wed, 24 Mar 2021 12:17:40 -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=jNsByZLSZ0ldM3b2f99i5+VJR1JmY8imVZoGPSeJk8o=; b=cS3mPU9eGCGP5gAm8eUEO7H3/P5dwrHJFBBhD43DfpWqgyrd0WEXpmMwSzT1bmz4j2 aEyIp+sV1DlICC8UYIdb4OYT7uls7KxPCPe3nqwD4besliOP1jG/k7qlxlNWXuZzYiNV uVs8RgjbWIWzTSWnmNrkafnqsRc8/fi84y7Uatccm9+guwImbsDmfcMxcKsvTL8pNDf2 o+ZLvJkE+EKp68vxWXndQ4ySHYk7JeDg7VPQca1mQxt1aObqguV4nMZoQSSBicNGrkxj VBL6Hx3hZ4Pd0CFlqkfOpT/iv+nT3wI+TuuvYf657IK3ZiM5HHKbL4GtPWbg+m13Main bgjg== 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=jNsByZLSZ0ldM3b2f99i5+VJR1JmY8imVZoGPSeJk8o=; b=Tj24zxyUj91DalnEWXSKie/DvAT4ugpXqfaWNtd5EDYOm38sHtrQMamXxz1uXPhkNB wrlI1EW/WhzDwDpCJPr9NnSjWhZGmq3AGDe0bdbzS7HD7TpNriMMsrordgBwy+M9mfmC UJ8z6qv2PEkLpOA6e5MbkDxmKTPmFDWY+bkTpDhwvxRGIbxJSfXwiw7+K7LCQZmjiVAk 2zcRpm5p7APiy0QBBE77DaCCXlNUlxh9VPCSObH8+3XaQ5ih6XfI/Ih2wBFsk5dQwtS/ DXNklcSk318PW5xsTXDpvPwMC7429XmIoKZN1A2QA66XQ23sUz5b1zID08vAvapleT+m mOVg== X-Gm-Message-State: AOAM533o9EzvjKxYwhWM8LMOJpQ5DOF21qiOzV0sJpQ7w/Wqi6e+t43+ NZlJbhoa5i4yIyQQCCwFTtjP059mwq0Hw8V80ausyZ0L0SA= X-Google-Smtp-Source: ABdhPJxTef9+tICeqFfHSALSZYwPfv0k6zJqhP1wvE2mxXhYlhNUEzSk6Z4XwDOZfFiBw2pd6bBs/GDtMv3np18As5c= X-Received: by 2002:a37:a845:: with SMTP id r66mr4556849qke.89.1616613459112; Wed, 24 Mar 2021 12:17:39 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> In-Reply-To: From: Alan Karp Date: Wed, 24 Mar 2021 12:17:27 -0700 Message-ID: To: Fabien Imbault Cc: Justin Richer , Adrian Gropper , Benjamin Kaduk , Mark Miller , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000f837ea05be4d2663" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2021 19:17:45 -0000 --000000000000f837ea05be4d2663 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable AS-RO is an AS that RO trusts to delegate RO's access tokens according to RO's policies. -------------- Alan Karp On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault wrote: > Hi Alan and Adrian, > > I've created issue AS-RO policy delegation ( > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to capture > your input. > A first question that arises: can we give a definition to AS-RO? > > Thanks > Fabien > > On Tue, Mar 23, 2021 at 4:15 PM Alan Karp wrote: > >> Fabien Imbault wrote: >> >>> Hi Alan, >>> >>> Yes, but in that flow, the token relationship between AS-RS and AS-RO i= s >>> only secure if the tokens issued by AS-RS are cryptographically attenua= ble >>> in the first place. >>> >> >> Attenuated delegation is a requirement, but that doesn't have to be done >> cryptographically. Token exchange works just fine. SPKI and zcap-ld ar= e >> examples of the crypto approach, and we used token exchange in the syste= m >> for HP. >> >> -------------- >> Alan Karp >> >> >> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault >> wrote: >> >>> Hi Alan, >>> >>> Yes, but in that flow, the token relationship between AS-RS and AS-RO i= s >>> only secure if the tokens issued by AS-RS are cryptographically attenua= ble >>> in the first place. >>> >>> Fabien >>> >>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp wrote: >>> >>>> Justin Richer wrote: >>>> >>>>> >>>>> But with all that in mind, I think the key here is going to be lookin= g >>>>> at what the inputs to the AS are, and how those can be defined in an >>>>> interoperable way for AS=E2=80=99s that can accept them. I think ther= e=E2=80=99s a lot of >>>>> room for innovation and flexibility here that doesn=E2=80=99t break t= he trust model >>>>> or core use cases. If I have an AS-RS set that won=E2=80=99t accept m= y favorite >>>>> flavor of policy engine inputs, then I can decide not to use that one= . But >>>>> this is a very different question than saying the RS itself needs to = accept >>>>> my own AS =E2=80=94 and we can=E2=80=99t keep conflating these two mo= dels. >>>>> >>>>> I agree. The point of having an AS-RO is to allow RO to specify a >>>> policy for which of RO's access tokens should be delegated under what >>>> conditions. AS-RS should not need to understand those policies. The = flow >>>> would be >>>> >>>> - RO contacts AS-RS and gets one or more access tokens. >>>> - RO delegates one or more of those tokens, potentially sub-scoped, >>>> to AS-RO. >>>> - A different user contacts AS-RO to get a potentially sub-scoped >>>> access token from AS-RO. >>>> - That user presents the access token delegated by AS-RO when >>>> invoking the resource. >>>> >>>> AS-RS only needs to verify that the delegation chain is legitimate, >>>> e.g., no increase in scope, and that it grants permission for the requ= est >>>> being made. AS-RS does not need to understand the policy behind grant= ing >>>> the delegation by AS-RO. >>>> >>>> -------------- >>>> Alan Karp >>>> >>>> >>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer wrote= : >>>> >>>>> Adrian, >>>>> >>>>> I think this shows the problem with the terminology as it=E2=80=99s b= een >>>>> applied in this conversation, which I=E2=80=99ve tried to shine light= on before. >>>>> What you and others are calling the =E2=80=9CRS=E2=80=9D is really th= e =E2=80=9CAS and RS working >>>>> together=E2=80=9D =E2=80=94 everything to the right of the line. When= Denis had brought up >>>>> =E2=80=9Celiminating the AS=E2=80=9D in another thread, what he=E2=80= =99d really done is labeled >>>>> everything to the right of the line as the =E2=80=9CRS=E2=80=9D. Of c= ourse, the irony here >>>>> is that everything to the right of the line used all be called the = =E2=80=9CAS=E2=80=9D or >>>>> simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say below= , I don=E2=80=99t want the >>>>> client to have visibility on what happens on that side. >>>>> >>>>> Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the diag= ram is not the >>>>> AS, as far as GNAP is concerned. It does not issue an access token th= at the >>>>> RS will accept. The elements to the left of the line could be a lot o= f >>>>> things, but they are NOT the AS =E2=80=94 by definition. The client l= ives over on >>>>> the left, but so do any external inputs to the AS. These could be pol= icy >>>>> inputs on behalf of the RO, they could be presentation artifacts, the= y >>>>> could be federated logins, they could be the output of policy decisio= ns. >>>>> How the AS comes to trust those things is up to the AS=E2=80=99s impl= ementation. >>>>> It=E2=80=99s something we can talk about, but ultimately GNAP won=E2= =80=99t be in any >>>>> position to dictate because in practice some AS=E2=80=99s are simply = going to >>>>> internalize all policies and we will never successfully force those o= pen. >>>>> >>>>> But with all that in mind, I think the key here is going to be lookin= g >>>>> at what the inputs to the AS are, and how those can be defined in an >>>>> interoperable way for AS=E2=80=99s that can accept them. I think ther= e=E2=80=99s a lot of >>>>> room for innovation and flexibility here that doesn=E2=80=99t break t= he trust model >>>>> or core use cases. If I have an AS-RS set that won=E2=80=99t accept m= y favorite >>>>> flavor of policy engine inputs, then I can decide not to use that one= . But >>>>> this is a very different question than saying the RS itself needs to = accept >>>>> my own AS =E2=80=94 and we can=E2=80=99t keep conflating these two mo= dels. >>>>> >>>>> So to me, GNAP can support a Zero Trust Architecture by LEVERAGING th= e >>>>> AS, not by subsuming or eliminating it. It is in fact the AS, not the >>>>> client and not the RS, that will request and consume the results of a >>>>> privacy-preserving zero-trust policy query thing. Anything that happe= ns >>>>> downstream from that is of little concern to the zero-trust component= s >>>>> because, as you point out, it=E2=80=99s on the =E2=80=9Cother side=E2= =80=9D of the line. >>>>> >>>>> I think we got this basic component model pretty right in OAuth: the >>>>> AS and RS and client working together. Where OAuth misses the mark is= the >>>>> assumption that the user has to log in to the AS through a webpage an= d >>>>> interact directly, thereby proving they=E2=80=99re the RO. It=E2=80= =99s this latter space >>>>> where I think we can both push innovation and also address the import= ant >>>>> and compelling use cases like the ones you=E2=80=99re bringing. >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper >>>>> wrote: >>>>> >>>>> I'm sorry, Justin. As a Resource Owner, I look at the RS trust >>>>> boundary (the dotted line in the diagram) as being the RS. I don't ex= pect >>>>> any visibility into what's going on on the right. >>>>> >>>>> My problem with the framing you propose is that requests are going to >>>>> the RS (or the AS-RS) and I don't want to share my policies with the = AS-RS. >>>>> I want to keep the RS and AS-RS as ignorant as possible. >>>>> >>>>> Adrian >>>>> >>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer wrote= : >>>>> >>>>>> Adrian, >>>>>> >>>>>> What you=E2=80=99re discussing below, in terms of logging in to a si= te, is >>>>>> not approaching the RS. You are in fact approaching the client, and >>>>>> identifying both the AS and RS to the client. The client is a client= *of >>>>>> your identity* in this model, and the RS is part of the identity >>>>>> provider. It=E2=80=99s really important that we don=E2=80=99t confla= te the RS and client in >>>>>> this way as it leads to a lot of confusion downstream and a lot of b= roken >>>>>> trust boundaries. >>>>>> >>>>>> With that model in mind, approaching the =E2=80=9CRS" and providing = it your >>>>>> identity is really just a case of the =E2=80=9Cfederated login to AS= =E2=80=9D pattern that >>>>>> we discussed on the WG call. The user here approaches an RS, which h= as its >>>>>> own AS. To share things from this RS, the RO has to authenticate to = the >>>>>> RS=E2=80=99s AS. This particular AS allows the RO to do so using an = external >>>>>> identity =E2=80=94 in which case, the AS is now a =E2=80=9Cclient=E2= =80=9D of a separate, >>>>>> disconnected (but layered) delegation. The ultimate client that even= tually >>>>>> calls the RS down the way may or may not know about these layers. >>>>>> >>>>>> >>>>>> This same AS, which is closely tied to the RS and trusted by the RS, >>>>>> might also take in FIDO credentials, or DIDs, or any number of other= proof >>>>>> mechanisms. The output of this is an access token the RS trusts, but= the >>>>>> input is up to the AS. The RS is not what you=E2=80=99re logging in = to. >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper >>>>>> wrote: >>>>>> >>>>>> I too am in favor of avoiding consolidation and correlation. Right >>>>>> now, when I approach a service provider (RS) for the first time, I'm >>>>>> offered the opportunity to identify my persona as: email, sign-in wi= th >>>>>> Google, Facebook, or Apple. I know there are people who try to creat= e >>>>>> one-off email addresses but that is mostly a waste of time. >>>>>> >>>>>> So, along come FIDO2 and DID wallets to the rescue. Now, in theory, = I >>>>>> have a way to start out my RS relationship pseudonymously. >>>>>> >>>>>> When I want my resource to be discovered or shared I will post that >>>>>> RS URL including my pseudonym. If I then want to introduce a mediato= r in >>>>>> front of my AS or messaging service endpoint, I have that option. If= I want >>>>>> to keep requests away from the mediator, I would publish an encrypti= on key >>>>>> along with my pseudonym. >>>>>> >>>>>> - Adrian >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer >>>>>> wrote: >>>>>> >>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk wrote: >>>>>>> > >>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote: >>>>>>> >> @Alan Karp shared a talk about the >>>>>>> Principle Of Least >>>>>>> >> Authority (POLA) in a recent comment >>>>>>> >> >>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issue= comment-803099693 >>>>>>> >> I recommend it. >>>>>>> >> >>>>>>> >> We might expect a protocol with authorization in the title to us= e >>>>>>> authority >>>>>>> >> as a core principle. I advocate for a GNAP design that maximizes >>>>>>> the power >>>>>>> >> of the RO, to be seen as a human rights issue when the RO is a >>>>>>> human. This >>>>>>> >> causes me to ask how to combine better security with better huma= n >>>>>>> rights in >>>>>>> >> GNAP. >>>>>>> >> >>>>>>> >> Who should have the least authority in the GNAP design? >>>>>>> >> >>>>>>> >> The AS derives authority as a delegate of the RO. If we ask the >>>>>>> RO to >>>>>>> >> partition limited authority across dozens of different ASs by >>>>>>> domain and >>>>>>> >> function, then we are not using technology to empower the >>>>>>> individual. >>>>>>> >> Probably the opposite, as we introduce consent fatigue and burde= n >>>>>>> normal >>>>>>> >> people to partition their lives into non-overlapping domains. >>>>>>> >> >>>>>>> >> My experience says we should aim for one AS per persona because >>>>>>> that maps >>>>>>> >> into the way we manage our public and private identities. POLA >>>>>>> would then >>>>>>> >> teach care in keeping ASs and RSs related to work / public >>>>>>> separate from >>>>>>> >> ASs and RSs related to private life so that a policy >>>>>>> vulnerability in our >>>>>>> >> delegation to an AS would have the least likelihood of harm. >>>>>>> > >>>>>>> > Thinking about how least authority/least privilege would apply to >>>>>>> GNAP >>>>>>> > seems like a useful exercise. I do want to point out some >>>>>>> potential >>>>>>> > pitfalls with one-AS-per-persona that we can also be aware of. I= f >>>>>>> > one-AS-per-persona becomes one-persona-per-AS as well, then the >>>>>>> AS's >>>>>>> > identity in effect also serves as a persona identity and there ar= e >>>>>>> privacy >>>>>>> > considerations to that. If, on the other hand, the >>>>>>> > multiple-personas-per-AS (presumably corresponding to multiple >>>>>>> humans) >>>>>>> > route is taken, we should consider whether that would lead to >>>>>>> various >>>>>>> > (e.g., market) forces driving consolidation to just a handful of >>>>>>> > super-popular AS services. That topic is a current matter of >>>>>>> concern to >>>>>>> > some IETF participants. >>>>>>> > >>>>>>> >>>>>>> Hi Ben, big +1 to this. This is something that we discussed ages ag= o >>>>>>> in the UMA working group, and it=E2=80=99s one of the biggest probl= ems with the >>>>>>> personal AS (and personal data store) model. This kind of thing mak= es >>>>>>> RS-first trust models really difficult in practice. >>>>>>> >>>>>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve got software tha= t wants to access >>>>>>> my medical information. It calls an RS and requests access, but it = hasn=E2=80=99t >>>>>>> been granted anything yet. Now I as the RO have set up the RS so th= at it >>>>>>> talks to my personal AS, that only I use. In addition to the RS hav= ing to >>>>>>> be able to figure out which medical records are being requested fro= m the >>>>>>> context of the unauthenticated request (which means it needs identi= fiers in >>>>>>> the URL or something similar for the RS to be able to tell, assumin= g that >>>>>>> it protects data for more than one person). So this client software= doesn=E2=80=99t >>>>>>> know who I am and doesn=E2=80=99t know my medical record informatio= n, makes a >>>>>>> completely unauthorized request to the RS, and the RS says =E2=80= =9CGo to Justin=E2=80=99s >>>>>>> personal AS to get a token=E2=80=9D. The client can now make a dire= ct correlation >>>>>>> between the data that=E2=80=99s being protected at the RS and the p= erson running >>>>>>> the AS that protects it. Importantly, this client makes this call w= ith no >>>>>>> prior relationship to the RS and no really auditable way to track i= t down >>>>>>> after the fact. This is a design feature in the good case, and terr= ifying >>>>>>> in the bad case. >>>>>>> >>>>>>> If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, plea= se talk >>>>>>> to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99= t exposed anything at >>>>>>> all. And from the perspective of both the patient and the RS, this = is more >>>>>>> privacy-preserving, and it=E2=80=99s really the least surprising op= tion. Once the >>>>>>> client gets to the AS, it can start a negotiation of figuring out w= ho the >>>>>>> RO is for the information being accessed. >>>>>>> >>>>>>> On top of this, the usability expectations of people managing their >>>>>>> own AS, or set of AS=E2=80=99s for multiple personas to keep things= separate, is a >>>>>>> huge burden. Even in the tech community, I know people who can=E2= =80=99t reliably >>>>>>> manage more than one email address for different purposes. I wouldn= =E2=80=99t >>>>>>> expect my partner to do that =E2=80=94 they have trouble enough bal= ancing all the >>>>>>> logins and sessions required for different kids remote schooling, I >>>>>>> couldn=E2=80=99t imagine them having to understand all the requirem= ents for >>>>>>> managing multiple authorization servers and associated policies. I = also >>>>>>> don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for >>>>>>> decades and I can barely keep tabs on my GPG keys, and only use the= m when I >>>>>>> am forced to. This is exactly the kind of =E2=80=9Cmarket pressure= =E2=80=9D that I think >>>>>>> Ben mentions above, people will just want to outsource that to some= one >>>>>>> else, and the reality will be a few popular providers. >>>>>>> >>>>>>> In which case, we could end up doing a ton of work to allow an RS >>>>>>> choice only to end up with a world where the RS ends up making a li= mited >>>>>>> choice anyway. We see how that plays out with OpenID Connect =E2=80= =94 RP=E2=80=99s could >>>>>>> allow arbitrary IdPs but they choose Google because it works and th= at=E2=80=99s >>>>>>> where the users are. (And that=E2=80=99s not to say anything of the= proprietary >>>>>>> OIDC-like protocols, but that=E2=80=99s another discussion). >>>>>>> >>>>>>> For further reading on these topics, I recommend both =E2=80=9CWhy = Johnny >>>>>>> Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail= =E2=80=9D. >>>>>>> >>>>>>> So what does this have to do with GNAP? I think we can be clear-eye= d >>>>>>> on what kinds of expectations we have for the participants. If we e= xpect >>>>>>> users (RO=E2=80=99s) to have to set up the AS-RS relationship, or e= xpect them to >>>>>>> carry their AS, or manage their personal keys =E2=80=94 I think we= =E2=80=99ve lost the >>>>>>> battle for relevance. >>>>>>> >>>>>>> =E2=80=94 Justin >>>>>> >>>>>> >>>>>> >>>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> --000000000000f837ea05be4d2663 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    AS-RO is an AS that RO trusts to delegate= RO's access tokens according to RO's policies.=C2=A0=C2=A0

    --------------
    Alan Karp


    =
    On Wed, Ma= r 24, 2021 at 9:36 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan and Adrian,
    =
    I've created issue AS-RO policy delegation (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to = capture your input.=C2=A0
    A first question that arises: can we gi= ve a definition to AS-RO?

    Thanks
    Fabien<= /div>

    On Tue, Mar 23, 2021 at 4:15 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan,=C2=A0
    <= br>
    Yes, but in that flow, the token relationship between AS-RS a= nd AS-RO is only secure if the tokens issued by AS-RS are cryptographically= attenuable in the first place.=C2=A0
    =C2=A0
    Attenuated delegation is a requirement, but that = doesn't have to be done cryptographically.=C2=A0 Token exchange works j= ust fine.=C2=A0 SPKI and zcap-ld are examples of the crypto approach, and w= e used token exchange in the system for HP.

    -= -------------
    Alan Karp


    On Tue, Mar 23, 2021 at 4:12 AM F= abien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan,=C2=A0

    =
    Yes, but in that flow, the token relationship between AS-RS and AS-RO = is only secure if the tokens issued by AS-RS are cryptographically attenuab= le in the first place.=C2=A0

    Fabien
    On Mon, M= ar 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin Richer <jricher@mit.edu> wrote:

    But = with all that in mind, I think the key here is going to be looking at what = the inputs to the AS are, and how those can be defined in an interoperable = way for AS=E2=80=99s that can accept them. I think there=E2=80=99s a lot of= room for innovation and flexibility here that doesn=E2=80=99t break the tr= ust model or core use cases. If I have an AS-RS set that won=E2=80=99t acce= pt my favorite flavor of policy engine inputs, then I can decide not to use= that one. But this is a very different question than saying the RS itself = needs to accept my own AS =E2=80=94 and we can=E2=80=99t keep conflating th= ese two models.

    I agree.=C2=A0 = The point of having an AS-RO is to allow RO to specify a policy for which o= f RO's access tokens should be delegated under what conditions.=C2=A0 A= S-RS should not need to understand those policies.=C2=A0 The flow would be<= /div>
    • RO contacts AS-RS and gets one or more access tokens.
    • RO delegates one or more of those tokens, potentially sub-scoped, to A= S-RO.
    • A different user contacts AS-RO to get a potentially sub-scop= ed access token from AS-RO.
    • That user presents the access token del= egated by AS-RO when invoking the resource.
    AS-RS = only needs to verify that the delegation chain is legitimate, e.g., no incr= ease in scope, and that it grants permission for the request being made.=C2= =A0 AS-RS does not need to understand the policy behind granting the delega= tion by AS-RO.

    --------------
    Alan Karp
    <= /div>

    On Mon, Mar 22, 2021 at 11:40 AM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    <= /div>
    I think this shows the problem with the terminology as it=E2=80= =99s been applied in this conversation, which I=E2=80=99ve tried to shine l= ight on before. What you and others are calling the =E2=80=9CRS=E2=80=9D is= really the =E2=80=9CAS and RS working together=E2=80=9D =E2=80=94 everythi= ng to the right of the line. When Denis had brought up =E2=80=9Celiminating= the AS=E2=80=9D in another thread, what he=E2=80=99d really done is labele= d everything to the right of the line as the =E2=80=9CRS=E2=80=9D. Of cours= e, the irony here is that everything to the right of the line used all be c= alled the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80=9D in the OA= uth 1 days. As you say below, I don=E2=80=99t want the client to have visib= ility on what happens on that side.=C2=A0

    Note wel= l: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the diagram is not the= AS, as far as GNAP is concerned. It does not issue an access token that th= e RS will accept. The elements to the left of the line could be a lot of th= ings, but they are NOT the AS =E2=80=94 by definition. The client lives ove= r on the left, but so do any external inputs to the AS. These could be poli= cy inputs on behalf of the RO, they could be presentation artifacts, they c= ould be federated logins, they could be the output of policy decisions. How= the AS comes to trust those things is up to the AS=E2=80=99s implementatio= n. It=E2=80=99s something we can talk about, but ultimately GNAP won=E2=80= =99t be in any position to dictate because in practice some AS=E2=80=99s ar= e simply going to internalize all policies and we will never successfully f= orce those open.=C2=A0

    But with all that in mind, = I think the key here is going to be looking at what the inputs to the AS ar= e, and how those can be defined in an interoperable way for AS=E2=80=99s th= at can accept them. I think there=E2=80=99s a lot of room for innovation an= d flexibility here that doesn=E2=80=99t break the trust model or core use c= ases. If I have an AS-RS set that won=E2=80=99t accept my favorite flavor o= f policy engine inputs, then I can decide not to use that one. But this is = a very different question than saying the RS itself needs to accept my own = AS =E2=80=94 and we can=E2=80=99t keep conflating these two models.

    So to me, GNAP can support a Zero Trust Architecture by L= EVERAGING the AS, not by subsuming or eliminating it. It is in fact the AS,= not the client and not the RS, that will request and consume the results o= f a privacy-preserving zero-trust policy query thing. Anything that happens= downstream from that is of little concern to the zero-trust components bec= ause, as you point out, it=E2=80=99s on the =E2=80=9Cother side=E2=80=9D of= the line.=C2=A0

    I think we got this basic compone= nt model pretty right in OAuth: the AS and RS and client working together. = Where OAuth misses the mark is the assumption that the user has to log in t= o the AS through a webpage and interact directly, thereby proving they=E2= =80=99re the RO. It=E2=80=99s this latter space where I think we can both p= ush innovation and also address the important and compelling use cases like= the ones you=E2=80=99re bringing.

    =C2=A0=E2=80=94= Justin

    On Mar 22, 2021, at 2:14= PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I'm sorry, Justin. As a Resource Owner, I look at the RS trust bound= ary (the dotted line in the diagram) as being the RS. I don't expect an= y visibility into what's going on on the=C2=A0right.=C2=A0

    My problem with the framing you propose is that requests are going t= o the RS (or the AS-RS) and I don't want to share my policies with the = AS-RS. I want to keep the RS and AS-RS as ignorant as possible.
    <= br>
    Adrian

    On Mon, Mar 22, 2021 at 1:48 PM Justin Richer <= ;jricher@mit.edu&g= t; wrote:
    A= drian,

    What you=E2=80=99re discussing below, in terms of= logging in to a site, is not approaching the RS. You are in fact approachi= ng the client, and identifying both the AS and RS to the client. The client= is a client of your identity in this model, and the RS is part of t= he identity provider. It=E2=80=99s really important that we don=E2=80=99t c= onflate the RS and client in this way as it leads to a lot of confusion dow= nstream and a lot of broken trust boundaries.

    With= that model in mind, approaching the =E2=80=9CRS" and providing it you= r identity is really just a case of the =E2=80=9Cfederated login to AS=E2= =80=9D pattern that we discussed on the WG call. The user here approaches a= n RS, which has its own AS. To share things from this RS, the RO has to aut= henticate to the RS=E2=80=99s AS. This particular AS allows the RO to do so= using an external identity =E2=80=94 in which case, the AS is now a =E2=80= =9Cclient=E2=80=9D of a separate, disconnected (but layered) delegation. Th= e ultimate client that eventually calls the RS down the way may or may not = know about these layers.=C2=A0

    <PastedGraphic-1.png>
    This same AS, which is cl= osely tied to the RS and trusted by the RS, might also take in FIDO credent= ials, or DIDs, or any number of other proof mechanisms. The output of this = is an access token the RS trusts, but the input is up to the AS. The RS is = not what you=E2=80=99re logging in to.

    =C2=A0=E2= =80=94 Justin

    On Mar 22, 2021, a= t 1:28 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I too am in favor of avoiding consolidation and correlation. Right= now, when I approach a service provider (RS) for the first time, I'm o= ffered the opportunity to identify my persona as: email, sign-in with Googl= e, Facebook, or Apple. I know there are people who try to create one-off em= ail addresses but that is mostly a waste of time.=C2=A0

    = So, along come FIDO2 and DID wallets to the rescue. Now, in theory, I have = a way to start out my RS relationship pseudonymously.=C2=A0

    <= /div>
    When I want my resource to be discovered or shared I will post th= at RS URL including my pseudonym. If I then want to introduce a mediator=C2= =A0in front of my AS or messaging service=C2=A0endpoint, I have that option= . If I want to keep requests away from the mediator, I would publish an enc= ryption key along with my pseudonym.

    - Adrian



    On Mon, Mar 22, 2021 at 9:55 AM Justin Riche= r <jricher@mit.edu<= /a>> wrote:
    O= n Mar 21, 2021, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhkarp@gmail.com> shared a talk about the Principle Of Leas= t
    >> Authority (POLA) in a recent comment
    >> https:/= /github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-8030996= 93
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --000000000000f837ea05be4d2663-- From nobody Wed Mar 24 14:21:00 2021 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 4C5D03A0B8C for ; Wed, 24 Mar 2021 14:20:58 -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 QR1U_JmRyO4D for ; Wed, 24 Mar 2021 14:20:53 -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 7F47E3A0B8A for ; Wed, 24 Mar 2021 14:20:44 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id u10so394030ilb.0 for ; Wed, 24 Mar 2021 14:20: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=bBDzr7azpSL7d0T/FrRBGfxvTZ/lW+3qrY68hgndwys=; b=A+b9TTNU+QjrJ/S+W8oOxqzGR+8cVdngkAkSi8c+fUb+tIJcgAqJ+spgRiyrRgaiIb ihntoQhk8BErFYAg5yJ+rKCgNnAE9eJhucFjLStF9xICVZAjDBFnkfFxKtuAXH5YiGN7 JcSqEzJ/1bjkaHOsMbDwmA9Q2LYCPPYkDhsknpMJp6T4HC3NuYORlOJ1+lPOBXhFfR7f 8JfLhrkRWr0n8ef6xAaR5g4rLYl/kk6oo0EJd8Dm3FS5iAL20aiUMnBGAqCyq5Wgtwga UylciegwpaaYfAWRcHzEPGIhchXpQgcuybbGUttdfcMJod0JE/wLF7Z0W162FQgRyNaD mtVg== 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=bBDzr7azpSL7d0T/FrRBGfxvTZ/lW+3qrY68hgndwys=; b=HFsSckRerilDMA8/NZSwUegGEIK3LDuOfikdhNZ/gzEA8rJ+pGIvy9uWY5ZBHPnsF9 epZgIjslY4vneor53RcDs2hp9cXbnrG2PBDuE5o5dThPptpW4mnAGpsRbmudNGFJlv+b yyW590AojG5yMNsovElwN4x3gPbDPByf39e1amtgbJPyXAJRxSSZ2cNkkgM6WmLbnz/L 0Ieg7V+Io5yUwOo1yFEaXvIudQCdvBfQlCeXhxAH6tMlo13RxihufxHXh9pon3BWhMsP hDT+l3TtfsgTlX4mPWc/o2N8eIOgZ8q3DOHllDpB3e8fO3G42ebfYdvMUrXZxF4Pl61b 3JPg== X-Gm-Message-State: AOAM532ubnZKv+iU2J38ydVUx6pe9nEc3IBS2g5TWimBH7Wilm+Cgoky oKw5XPM2Pg/3ZNC8CST0lZwxqYAlzLqsNrP7k5GOo2AKIIA= X-Google-Smtp-Source: ABdhPJylaux+3jmY6AFDNxZosKO52X590CJ+UgKMCnBVZFPGUARFgnzOhsT8M3GSsthJeZn1pLy9bqhj6QvmoXbqFmA= X-Received: by 2002:a92:4b05:: with SMTP id m5mr3732055ilg.188.1616620842751; Wed, 24 Mar 2021 14:20:42 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> In-Reply-To: From: Fabien Imbault Date: Wed, 24 Mar 2021 22:20:29 +0100 Message-ID: To: Alan Karp Cc: Justin Richer , Adrian Gropper , Benjamin Kaduk , Mark Miller , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000001198af05be4edfbd" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2021 21:20:58 -0000 --0000000000001198af05be4edfbd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Isn't that what the AS is supposed to be, only with the caveat that the policy is defined locally? Fabien Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp a =C3=A9= crit : > AS-RO is an AS that RO trusts to delegate RO's access tokens according to > RO's policies. > > -------------- > Alan Karp > > > On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault > wrote: > >> Hi Alan and Adrian, >> >> I've created issue AS-RO policy delegation ( >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to >> capture your input. >> A first question that arises: can we give a definition to AS-RO? >> >> Thanks >> Fabien >> >> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp wrote: >> >>> Fabien Imbault wrote: >>> >>>> Hi Alan, >>>> >>>> Yes, but in that flow, the token relationship between AS-RS and AS-RO >>>> is only secure if the tokens issued by AS-RS are cryptographically >>>> attenuable in the first place. >>>> >>> >>> Attenuated delegation is a requirement, but that doesn't have to be don= e >>> cryptographically. Token exchange works just fine. SPKI and zcap-ld a= re >>> examples of the crypto approach, and we used token exchange in the syst= em >>> for HP. >>> >>> -------------- >>> Alan Karp >>> >>> >>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault >>> wrote: >>> >>>> Hi Alan, >>>> >>>> Yes, but in that flow, the token relationship between AS-RS and AS-RO >>>> is only secure if the tokens issued by AS-RS are cryptographically >>>> attenuable in the first place. >>>> >>>> Fabien >>>> >>>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp wrote: >>>> >>>>> Justin Richer wrote: >>>>> >>>>>> >>>>>> But with all that in mind, I think the key here is going to be >>>>>> looking at what the inputs to the AS are, and how those can be defin= ed in >>>>>> an interoperable way for AS=E2=80=99s that can accept them. I think = there=E2=80=99s a lot >>>>>> of room for innovation and flexibility here that doesn=E2=80=99t bre= ak the trust >>>>>> model or core use cases. If I have an AS-RS set that won=E2=80=99t a= ccept my >>>>>> favorite flavor of policy engine inputs, then I can decide not to us= e that >>>>>> one. But this is a very different question than saying the RS itself= needs >>>>>> to accept my own AS =E2=80=94 and we can=E2=80=99t keep conflating t= hese two models. >>>>>> >>>>>> I agree. The point of having an AS-RO is to allow RO to specify a >>>>> policy for which of RO's access tokens should be delegated under what >>>>> conditions. AS-RS should not need to understand those policies. The= flow >>>>> would be >>>>> >>>>> - RO contacts AS-RS and gets one or more access tokens. >>>>> - RO delegates one or more of those tokens, potentially >>>>> sub-scoped, to AS-RO. >>>>> - A different user contacts AS-RO to get a potentially sub-scoped >>>>> access token from AS-RO. >>>>> - That user presents the access token delegated by AS-RO when >>>>> invoking the resource. >>>>> >>>>> AS-RS only needs to verify that the delegation chain is legitimate, >>>>> e.g., no increase in scope, and that it grants permission for the req= uest >>>>> being made. AS-RS does not need to understand the policy behind gran= ting >>>>> the delegation by AS-RO. >>>>> >>>>> -------------- >>>>> Alan Karp >>>>> >>>>> >>>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer >>>>> wrote: >>>>> >>>>>> Adrian, >>>>>> >>>>>> I think this shows the problem with the terminology as it=E2=80=99s = been >>>>>> applied in this conversation, which I=E2=80=99ve tried to shine ligh= t on before. >>>>>> What you and others are calling the =E2=80=9CRS=E2=80=9D is really t= he =E2=80=9CAS and RS working >>>>>> together=E2=80=9D =E2=80=94 everything to the right of the line. Whe= n Denis had brought up >>>>>> =E2=80=9Celiminating the AS=E2=80=9D in another thread, what he=E2= =80=99d really done is labeled >>>>>> everything to the right of the line as the =E2=80=9CRS=E2=80=9D. Of = course, the irony here >>>>>> is that everything to the right of the line used all be called the = =E2=80=9CAS=E2=80=9D or >>>>>> simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say belo= w, I don=E2=80=99t want the >>>>>> client to have visibility on what happens on that side. >>>>>> >>>>>> Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the dia= gram is not the >>>>>> AS, as far as GNAP is concerned. It does not issue an access token t= hat the >>>>>> RS will accept. The elements to the left of the line could be a lot = of >>>>>> things, but they are NOT the AS =E2=80=94 by definition. The client = lives over on >>>>>> the left, but so do any external inputs to the AS. These could be po= licy >>>>>> inputs on behalf of the RO, they could be presentation artifacts, th= ey >>>>>> could be federated logins, they could be the output of policy decisi= ons. >>>>>> How the AS comes to trust those things is up to the AS=E2=80=99s imp= lementation. >>>>>> It=E2=80=99s something we can talk about, but ultimately GNAP won=E2= =80=99t be in any >>>>>> position to dictate because in practice some AS=E2=80=99s are simply= going to >>>>>> internalize all policies and we will never successfully force those = open. >>>>>> >>>>>> But with all that in mind, I think the key here is going to be >>>>>> looking at what the inputs to the AS are, and how those can be defin= ed in >>>>>> an interoperable way for AS=E2=80=99s that can accept them. I think = there=E2=80=99s a lot >>>>>> of room for innovation and flexibility here that doesn=E2=80=99t bre= ak the trust >>>>>> model or core use cases. If I have an AS-RS set that won=E2=80=99t a= ccept my >>>>>> favorite flavor of policy engine inputs, then I can decide not to us= e that >>>>>> one. But this is a very different question than saying the RS itself= needs >>>>>> to accept my own AS =E2=80=94 and we can=E2=80=99t keep conflating t= hese two models. >>>>>> >>>>>> So to me, GNAP can support a Zero Trust Architecture by LEVERAGING >>>>>> the AS, not by subsuming or eliminating it. It is in fact the AS, no= t the >>>>>> client and not the RS, that will request and consume the results of = a >>>>>> privacy-preserving zero-trust policy query thing. Anything that happ= ens >>>>>> downstream from that is of little concern to the zero-trust componen= ts >>>>>> because, as you point out, it=E2=80=99s on the =E2=80=9Cother side= =E2=80=9D of the line. >>>>>> >>>>>> I think we got this basic component model pretty right in OAuth: the >>>>>> AS and RS and client working together. Where OAuth misses the mark i= s the >>>>>> assumption that the user has to log in to the AS through a webpage a= nd >>>>>> interact directly, thereby proving they=E2=80=99re the RO. It=E2=80= =99s this latter space >>>>>> where I think we can both push innovation and also address the impor= tant >>>>>> and compelling use cases like the ones you=E2=80=99re bringing. >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper >>>>>> wrote: >>>>>> >>>>>> I'm sorry, Justin. As a Resource Owner, I look at the RS trust >>>>>> boundary (the dotted line in the diagram) as being the RS. I don't e= xpect >>>>>> any visibility into what's going on on the right. >>>>>> >>>>>> My problem with the framing you propose is that requests are going t= o >>>>>> the RS (or the AS-RS) and I don't want to share my policies with the= AS-RS. >>>>>> I want to keep the RS and AS-RS as ignorant as possible. >>>>>> >>>>>> Adrian >>>>>> >>>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer >>>>>> wrote: >>>>>> >>>>>>> Adrian, >>>>>>> >>>>>>> What you=E2=80=99re discussing below, in terms of logging in to a s= ite, is >>>>>>> not approaching the RS. You are in fact approaching the client, and >>>>>>> identifying both the AS and RS to the client. The client is a clien= t *of >>>>>>> your identity* in this model, and the RS is part of the identity >>>>>>> provider. It=E2=80=99s really important that we don=E2=80=99t confl= ate the RS and client in >>>>>>> this way as it leads to a lot of confusion downstream and a lot of = broken >>>>>>> trust boundaries. >>>>>>> >>>>>>> With that model in mind, approaching the =E2=80=9CRS" and providing= it your >>>>>>> identity is really just a case of the =E2=80=9Cfederated login to A= S=E2=80=9D pattern that >>>>>>> we discussed on the WG call. The user here approaches an RS, which = has its >>>>>>> own AS. To share things from this RS, the RO has to authenticate to= the >>>>>>> RS=E2=80=99s AS. This particular AS allows the RO to do so using an= external >>>>>>> identity =E2=80=94 in which case, the AS is now a =E2=80=9Cclient= =E2=80=9D of a separate, >>>>>>> disconnected (but layered) delegation. The ultimate client that eve= ntually >>>>>>> calls the RS down the way may or may not know about these layers. >>>>>>> >>>>>>> >>>>>>> This same AS, which is closely tied to the RS and trusted by the RS= , >>>>>>> might also take in FIDO credentials, or DIDs, or any number of othe= r proof >>>>>>> mechanisms. The output of this is an access token the RS trusts, bu= t the >>>>>>> input is up to the AS. The RS is not what you=E2=80=99re logging in= to. >>>>>>> >>>>>>> =E2=80=94 Justin >>>>>>> >>>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper >>>>>>> wrote: >>>>>>> >>>>>>> I too am in favor of avoiding consolidation and correlation. Right >>>>>>> now, when I approach a service provider (RS) for the first time, I'= m >>>>>>> offered the opportunity to identify my persona as: email, sign-in w= ith >>>>>>> Google, Facebook, or Apple. I know there are people who try to crea= te >>>>>>> one-off email addresses but that is mostly a waste of time. >>>>>>> >>>>>>> So, along come FIDO2 and DID wallets to the rescue. Now, in theory, >>>>>>> I have a way to start out my RS relationship pseudonymously. >>>>>>> >>>>>>> When I want my resource to be discovered or shared I will post that >>>>>>> RS URL including my pseudonym. If I then want to introduce a mediat= or in >>>>>>> front of my AS or messaging service endpoint, I have that option. I= f I want >>>>>>> to keep requests away from the mediator, I would publish an encrypt= ion key >>>>>>> along with my pseudonym. >>>>>>> >>>>>>> - Adrian >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer >>>>>>> wrote: >>>>>>> >>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk wrote: >>>>>>>> > >>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote: >>>>>>>> >> @Alan Karp shared a talk about the >>>>>>>> Principle Of Least >>>>>>>> >> Authority (POLA) in a recent comment >>>>>>>> >> >>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issu= ecomment-803099693 >>>>>>>> >> I recommend it. >>>>>>>> >> >>>>>>>> >> We might expect a protocol with authorization in the title to >>>>>>>> use authority >>>>>>>> >> as a core principle. I advocate for a GNAP design that maximize= s >>>>>>>> the power >>>>>>>> >> of the RO, to be seen as a human rights issue when the RO is a >>>>>>>> human. This >>>>>>>> >> causes me to ask how to combine better security with better >>>>>>>> human rights in >>>>>>>> >> GNAP. >>>>>>>> >> >>>>>>>> >> Who should have the least authority in the GNAP design? >>>>>>>> >> >>>>>>>> >> The AS derives authority as a delegate of the RO. If we ask the >>>>>>>> RO to >>>>>>>> >> partition limited authority across dozens of different ASs by >>>>>>>> domain and >>>>>>>> >> function, then we are not using technology to empower the >>>>>>>> individual. >>>>>>>> >> Probably the opposite, as we introduce consent fatigue and >>>>>>>> burden normal >>>>>>>> >> people to partition their lives into non-overlapping domains. >>>>>>>> >> >>>>>>>> >> My experience says we should aim for one AS per persona because >>>>>>>> that maps >>>>>>>> >> into the way we manage our public and private identities. POLA >>>>>>>> would then >>>>>>>> >> teach care in keeping ASs and RSs related to work / public >>>>>>>> separate from >>>>>>>> >> ASs and RSs related to private life so that a policy >>>>>>>> vulnerability in our >>>>>>>> >> delegation to an AS would have the least likelihood of harm. >>>>>>>> > >>>>>>>> > Thinking about how least authority/least privilege would apply t= o >>>>>>>> GNAP >>>>>>>> > seems like a useful exercise. I do want to point out some >>>>>>>> potential >>>>>>>> > pitfalls with one-AS-per-persona that we can also be aware of. = If >>>>>>>> > one-AS-per-persona becomes one-persona-per-AS as well, then the >>>>>>>> AS's >>>>>>>> > identity in effect also serves as a persona identity and there >>>>>>>> are privacy >>>>>>>> > considerations to that. If, on the other hand, the >>>>>>>> > multiple-personas-per-AS (presumably corresponding to multiple >>>>>>>> humans) >>>>>>>> > route is taken, we should consider whether that would lead to >>>>>>>> various >>>>>>>> > (e.g., market) forces driving consolidation to just a handful of >>>>>>>> > super-popular AS services. That topic is a current matter of >>>>>>>> concern to >>>>>>>> > some IETF participants. >>>>>>>> > >>>>>>>> >>>>>>>> Hi Ben, big +1 to this. This is something that we discussed ages >>>>>>>> ago in the UMA working group, and it=E2=80=99s one of the biggest = problems with the >>>>>>>> personal AS (and personal data store) model. This kind of thing ma= kes >>>>>>>> RS-first trust models really difficult in practice. >>>>>>>> >>>>>>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve got software th= at wants to >>>>>>>> access my medical information. It calls an RS and requests access,= but it >>>>>>>> hasn=E2=80=99t been granted anything yet. Now I as the RO have set= up the RS so >>>>>>>> that it talks to my personal AS, that only I use. In addition to t= he RS >>>>>>>> having to be able to figure out which medical records are being re= quested >>>>>>>> from the context of the unauthenticated request (which means it ne= eds >>>>>>>> identifiers in the URL or something similar for the RS to be able = to tell, >>>>>>>> assuming that it protects data for more than one person). So this = client >>>>>>>> software doesn=E2=80=99t know who I am and doesn=E2=80=99t know my= medical record >>>>>>>> information, makes a completely unauthorized request to the RS, an= d the RS >>>>>>>> says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2= =80=9D. The client can now make a >>>>>>>> direct correlation between the data that=E2=80=99s being protected= at the RS and >>>>>>>> the person running the AS that protects it. Importantly, this clie= nt makes >>>>>>>> this call with no prior relationship to the RS and no really audit= able way >>>>>>>> to track it down after the fact. This is a design feature in the g= ood case, >>>>>>>> and terrifying in the bad case. >>>>>>>> >>>>>>>> If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, ple= ase talk >>>>>>>> to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80= =99t exposed anything at >>>>>>>> all. And from the perspective of both the patient and the RS, this= is more >>>>>>>> privacy-preserving, and it=E2=80=99s really the least surprising o= ption. Once the >>>>>>>> client gets to the AS, it can start a negotiation of figuring out = who the >>>>>>>> RO is for the information being accessed. >>>>>>>> >>>>>>>> On top of this, the usability expectations of people managing thei= r >>>>>>>> own AS, or set of AS=E2=80=99s for multiple personas to keep thing= s separate, is a >>>>>>>> huge burden. Even in the tech community, I know people who can=E2= =80=99t reliably >>>>>>>> manage more than one email address for different purposes. I would= n=E2=80=99t >>>>>>>> expect my partner to do that =E2=80=94 they have trouble enough ba= lancing all the >>>>>>>> logins and sessions required for different kids remote schooling, = I >>>>>>>> couldn=E2=80=99t imagine them having to understand all the require= ments for >>>>>>>> managing multiple authorization servers and associated policies. I= also >>>>>>>> don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for >>>>>>>> decades and I can barely keep tabs on my GPG keys, and only use th= em when I >>>>>>>> am forced to. This is exactly the kind of =E2=80=9Cmarket pressure= =E2=80=9D that I think >>>>>>>> Ben mentions above, people will just want to outsource that to som= eone >>>>>>>> else, and the reality will be a few popular providers. >>>>>>>> >>>>>>>> In which case, we could end up doing a ton of work to allow an RS >>>>>>>> choice only to end up with a world where the RS ends up making a l= imited >>>>>>>> choice anyway. We see how that plays out with OpenID Connect =E2= =80=94 RP=E2=80=99s could >>>>>>>> allow arbitrary IdPs but they choose Google because it works and t= hat=E2=80=99s >>>>>>>> where the users are. (And that=E2=80=99s not to say anything of th= e proprietary >>>>>>>> OIDC-like protocols, but that=E2=80=99s another discussion). >>>>>>>> >>>>>>>> For further reading on these topics, I recommend both =E2=80=9CWhy= Johnny >>>>>>>> Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail= =E2=80=9D. >>>>>>>> >>>>>>>> So what does this have to do with GNAP? I think we can be >>>>>>>> clear-eyed on what kinds of expectations we have for the participa= nts. If >>>>>>>> we expect users (RO=E2=80=99s) to have to set up the AS-RS relatio= nship, or expect >>>>>>>> them to carry their AS, or manage their personal keys =E2=80=94 I = think we=E2=80=99ve lost >>>>>>>> the battle for relevance. >>>>>>>> >>>>>>>> =E2=80=94 Justin >>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> --0000000000001198af05be4edfbd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Isn't that what the AS is supposed to be, only w= ith the caveat that the policy is defined locally?=C2=A0
    <= br>
    Fabien=C2=A0


    Le mer. 24 mars 2021 =C3=A0 20:1= 7, Alan Karp <alanhkarp@gmail.com= > a =C3=A9crit=C2=A0:
    AS-RO is an AS that RO trusts to delegate RO= 9;s access tokens according to RO's policies.=C2=A0=C2=A0

    ----------= ----
    Alan Karp


    On Wed, Mar 24, 2021 at 9:36 AM Fabien Imb= ault <fabien.imbault@gmail.com> wrote:
    Hi Alan and Adrian= ,

    I've created issue AS-RO policy delegation (https://github.com/ietf-wg-gnap/gnap-core-pr= otocol/issues/223) to capture your input.=C2=A0
    A first quest= ion that arises: can we give a definition to AS-RO?

    Thanks
    Fabien

    On Tue, Mar 23, 2021 at 4:15 PM Alan Karp &l= t;alanhkarp@gmail.com> wrote:
    Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan,=C2=A0

    Yes, but in that flow, the token relationship between AS-RS and AS-RO is= only secure if the tokens issued by AS-RS are cryptographically attenuable= in the first place.=C2=A0
    =C2=A0
    Attenuated delegation is a requirement, but that doesn't= have to be done cryptographically.=C2=A0 Token exchange works just fine.= =C2=A0 SPKI and zcap-ld are examples of the crypto approach, and we used to= ken exchange in the system for HP.

    ----------= ----
    Alan Karp


    On Tue, Mar 23, 2021 at 4:12 AM Fabien Imb= ault <fabien.imbault@gmail.com> wrote:
    Hi Alan,=C2=A0
    Yes, but in that flow, the token relationship between AS-RS= and AS-RO is only secure if the tokens issued by AS-RS are cryptographical= ly attenuable in the first place.=C2=A0

    Fabien

    On Mon, Mar 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com>= ; wrote:
    Justin Ric= her <jricher@mit.edu> wrote:

    But with all that in mind, I t= hink the key here is going to be looking at what the inputs to the AS are, = and how those can be defined in an interoperable way for AS=E2=80=99s that = can accept them. I think there=E2=80=99s a lot of room for innovation and f= lexibility here that doesn=E2=80=99t break the trust model or core use case= s. If I have an AS-RS set that won=E2=80=99t accept my favorite flavor of p= olicy engine inputs, then I can decide not to use that one. But this is a v= ery different question than saying the RS itself needs to accept my own AS = =E2=80=94 and we can=E2=80=99t keep conflating these two models.
    =
    I agree.=C2=A0 The point of having an AS-= RO is to allow RO to specify a policy for which of RO's access tokens s= hould be delegated under what conditions.=C2=A0 AS-RS should not need to un= derstand those policies.=C2=A0 The flow would be
    • RO conta= cts AS-RS and gets one or more access tokens.
    • RO delegates one or m= ore of those tokens, potentially sub-scoped, to AS-RO.
    • A different = user contacts AS-RO to get a potentially sub-scoped access token from AS-RO= .
    • That user presents the access token delegated by AS-RO when invok= ing the resource.
    AS-RS only needs to verify that = the delegation chain is legitimate, e.g., no increase in scope, and that it= grants permission for the request being made.=C2=A0 AS-RS does not need to= understand the policy behind granting the delegation by AS-RO.

    --------------
    Alan Karp


    On Mon, Mar 22, 2= 021 at 11:40 AM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    I think this shows the problem with the terminology as it=E2=80=99s been= applied in this conversation, which I=E2=80=99ve tried to shine light on b= efore. What you and others are calling the =E2=80=9CRS=E2=80=9D is really t= he =E2=80=9CAS and RS working together=E2=80=9D =E2=80=94 everything to the= right of the line. When Denis had brought up =E2=80=9Celiminating the AS= =E2=80=9D in another thread, what he=E2=80=99d really done is labeled every= thing to the right of the line as the =E2=80=9CRS=E2=80=9D. Of course, the = irony here is that everything to the right of the line used all be called t= he =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 d= ays. As you say below, I don=E2=80=99t want the client to have visibility o= n what happens on that side.=C2=A0

    Note well: The = Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the diagram is not the AS, as= far as GNAP is concerned. It does not issue an access token that the RS wi= ll accept. The elements to the left of the line could be a lot of things, b= ut they are NOT the AS =E2=80=94 by definition. The client lives over on th= e left, but so do any external inputs to the AS. These could be policy inpu= ts on behalf of the RO, they could be presentation artifacts, they could be= federated logins, they could be the output of policy decisions. How the AS= comes to trust those things is up to the AS=E2=80=99s implementation. It= =E2=80=99s something we can talk about, but ultimately GNAP won=E2=80=99t b= e in any position to dictate because in practice some AS=E2=80=99s are simp= ly going to internalize all policies and we will never successfully force t= hose open.=C2=A0

    But with all that in mind, I thin= k the key here is going to be looking at what the inputs to the AS are, and= how those can be defined in an interoperable way for AS=E2=80=99s that can= accept them. I think there=E2=80=99s a lot of room for innovation and flex= ibility here that doesn=E2=80=99t break the trust model or core use cases. = If I have an AS-RS set that won=E2=80=99t accept my favorite flavor of poli= cy engine inputs, then I can decide not to use that one. But this is a very= different question than saying the RS itself needs to accept my own AS =E2= =80=94 and we can=E2=80=99t keep conflating these two models.
    So to me, GNAP can support a Zero Trust Architecture by LEVERAG= ING the AS, not by subsuming or eliminating it. It is in fact the AS, not t= he client and not the RS, that will request and consume the results of a pr= ivacy-preserving zero-trust policy query thing. Anything that happens downs= tream from that is of little concern to the zero-trust components because, = as you point out, it=E2=80=99s on the =E2=80=9Cother side=E2=80=9D of the l= ine.=C2=A0

    I think we got this basic component mod= el pretty right in OAuth: the AS and RS and client working together. Where = OAuth misses the mark is the assumption that the user has to log in to the = AS through a webpage and interact directly, thereby proving they=E2=80=99re= the RO. It=E2=80=99s this latter space where I think we can both push inno= vation and also address the important and compelling use cases like the one= s you=E2=80=99re bringing.

    =C2=A0=E2=80=94 Justin<= br>

    On Mar 22, 2021, at 2:14 PM, Adr= ian Gropper <agropper@healthurl.com> wrote:

    I'm sorry, Justin. As a Resource Owner, I look at the RS = trust boundary (the dotted line in the diagram) as being the RS. I don'= t expect any visibility into what's going on on the=C2=A0right.=C2=A0
    My problem with the framing you propose is that requests = are going to the RS (or the AS-RS) and I don't want to share my policie= s with the AS-RS. I want to keep the RS and AS-RS as ignorant as possible.<= /div>

    Adrian

    <= div dir=3D"ltr" class=3D"gmail_attr">On Mon, Mar 22, 2021 at 1:48 PM Justin= Richer <jricher@mit.edu> wrote:
    Adrian,

    What you=E2=80=99re= discussing below, in terms of logging in to a site, is not approaching the= RS. You are in fact approaching the client, and identifying both the AS an= d RS to the client. The client is a client of your identity in this = model, and the RS is part of the identity provider. It=E2=80=99s really imp= ortant that we don=E2=80=99t conflate the RS and client in this way as it l= eads to a lot of confusion downstream and a lot of broken trust boundaries.=

    With that model in mind, approaching the =E2=80= =9CRS" and providing it your identity is really just a case of the =E2= =80=9Cfederated login to AS=E2=80=9D pattern that we discussed on the WG ca= ll. The user here approaches an RS, which has its own AS. To share things f= rom this RS, the RO has to authenticate to the RS=E2=80=99s AS. This partic= ular AS allows the RO to do so using an external identity =E2=80=94 in whic= h case, the AS is now a =E2=80=9Cclient=E2=80=9D of a separate, disconnecte= d (but layered) delegation. The ultimate client that eventually calls the R= S down the way may or may not know about these layers.=C2=A0

    =
    <PastedGraphic-= 1.png>
    This same AS, which is closely tied to the RS an= d trusted by the RS, might also take in FIDO credentials, or DIDs, or any n= umber of other proof mechanisms. The output of this is an access token the = RS trusts, but the input is up to the AS. The RS is not what you=E2=80=99re= logging in to.

    =C2=A0=E2=80=94 Justin
    On Mar 22, 2021, at 1:28 PM, Adrian Gropper= <agropper@healthurl.com> wrote:

    I too am in favor of avoiding consolidation and correlation. Right now, = when I approach a service provider (RS) for the first time, I'm offered= the opportunity to identify my persona as: email, sign-in with Google, Fac= ebook, or Apple. I know there are people who try to create one-off email ad= dresses but that is mostly a waste of time.=C2=A0

    So, al= ong come FIDO2 and DID wallets to the rescue. Now, in theory, I have a way = to start out my RS relationship pseudonymously.=C2=A0

    <= div>When I want my resource to be discovered or shared I will post that RS = URL including my pseudonym. If I then want to introduce a mediator=C2=A0in = front of my AS or messaging service=C2=A0endpoint, I have that option. If I= want to keep requests away from the mediator, I would publish an encryptio= n key along with my pseudonym.

    - Adrian
    =


    On Mon, Mar 22, 2021 at 9:55 AM Justin Richer <= jri= cher@mit.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu>= ; wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhkarp@gmail.com> shared a talk about th= e Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomm= ent-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --
    TXAuth mailing list
    TXA= uth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= /a>
    --0000000000001198af05be4edfbd-- From nobody Wed Mar 24 19:41:21 2021 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 E37483A1754 for ; Wed, 24 Mar 2021 19:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 rDNnzb2QT6B1 for ; Wed, 24 Mar 2021 19:41:15 -0700 (PDT) Received: from mail-vs1-f54.google.com (mail-vs1-f54.google.com [209.85.217.54]) (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 25E6F3A1752 for ; Wed, 24 Mar 2021 19:41:15 -0700 (PDT) Received: by mail-vs1-f54.google.com with SMTP id i126so116265vsi.3 for ; Wed, 24 Mar 2021 19:41:15 -0700 (PDT) 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=8dOPFt84CeGJ9qBpUCLyulYHbLKyQuJ+32NMWByFmos=; b=aA7874IE0PUfq+rqq5fGLbe95wbP7N8FHWN7L5sIYqMi9Qovv/vPfKJl9lH5+Hhn/p bIO5azAsnuxgvOFBTIPQx3Uq6x5MNKFCoMRg4LeUJCRno6W9VbSk2azOBlBfpjkiDGkK ZlGUM5akedwp5IC/B2egZFq5jiT0brWh0uts/6YE0HMb4ZcQn2g1KrhQBwJNNZdOkCfn eL+KA3e/yhGlIjtwABSoa9is5SRTuHSfXEF5N4/ILZx9RQpsUQrLZC+nBbTOg16iqUCT KCY3wuzxyyh8abPqGO8zf4ai6Dun4Lyz8AZic5YpSLCmgX1KZvk+nA39734NzRQhdlxg rvYw== X-Gm-Message-State: AOAM532VvhX5jai5b8JOauggwbej2Twq1fpl7DogQAgGFGziPIctLFaQ r5AchxeH7gtaRuPd1akU29vGFHLaJX7A3EIPwNFRlg+pgUFoNw== X-Google-Smtp-Source: ABdhPJw4l+4P9/nPs6eGYyF8LmJKELm5DgNKNDlvUV8icad0ovr0OrIXlgboZTGlSd8l+P4PoepWl0ssNgkB4Zbikmc= X-Received: by 2002:a05:6102:24a:: with SMTP id a10mr3829235vsq.39.1616640073973; Wed, 24 Mar 2021 19:41:13 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> In-Reply-To: From: Adrian Gropper Date: Wed, 24 Mar 2021 22:41:02 -0400 Message-ID: To: Fabien Imbault Cc: Alan Karp , Mark Miller , Benjamin Kaduk , Justin Richer , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000056c28a05be535968" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 02:41:20 -0000 --00000000000056c28a05be535968 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you for creating the issue. My definition of AS is independent of AS-RO or AS-RS. https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomment-= 806280421 I also agree with Alan's definition based on delegation. An AS-RS would be a delegate of the RS. Based on that, I see it as obvious that the policy has to be accessible (defined locally?) in order for it to be run as the code that turns a request into an access token. The only other possibility is that the request is packaged by the AS and sent elsewhere (an agent) for evaluation against policy and a proto-token returned. In that case the AS is acting as a proxy and the PDP is elsewhere. I can imagine that an AS-RS would behave this way so that the proto-token could be turned into an access token by the AS-RS. Isn't this what Justin is proposing? In this design, the AS is the AS-RS and the agent is the AS-RO. By my definition, this model has two ASs since both are processing requests into tokens. The problem with this is complexity and privacy. The RO may not want to share the request information with the AS-RS. Adrian On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault wrote: > Isn't that what the AS is supposed to be, only with the caveat that the > policy is defined locally? > > Fabien > > > Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp a =C3= =A9crit : > >> AS-RO is an AS that RO trusts to delegate RO's access tokens according t= o >> RO's policies. >> >> -------------- >> Alan Karp >> >> >> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault >> wrote: >> >>> Hi Alan and Adrian, >>> >>> I've created issue AS-RO policy delegation ( >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to >>> capture your input. >>> A first question that arises: can we give a definition to AS-RO? >>> >>> Thanks >>> Fabien >>> >>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp wrote: >>> >>>> Fabien Imbault wrote: >>>> >>>>> Hi Alan, >>>>> >>>>> Yes, but in that flow, the token relationship between AS-RS and AS-RO >>>>> is only secure if the tokens issued by AS-RS are cryptographically >>>>> attenuable in the first place. >>>>> >>>> >>>> Attenuated delegation is a requirement, but that doesn't have to be >>>> done cryptographically. Token exchange works just fine. SPKI and zca= p-ld >>>> are examples of the crypto approach, and we used token exchange in the >>>> system for HP. >>>> >>>> -------------- >>>> Alan Karp >>>> >>>> >>>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Hi Alan, >>>>> >>>>> Yes, but in that flow, the token relationship between AS-RS and AS-RO >>>>> is only secure if the tokens issued by AS-RS are cryptographically >>>>> attenuable in the first place. >>>>> >>>>> Fabien >>>>> >>>>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp wrote= : >>>>> >>>>>> Justin Richer wrote: >>>>>> >>>>>>> >>>>>>> But with all that in mind, I think the key here is going to be >>>>>>> looking at what the inputs to the AS are, and how those can be defi= ned in >>>>>>> an interoperable way for AS=E2=80=99s that can accept them. I think= there=E2=80=99s a lot >>>>>>> of room for innovation and flexibility here that doesn=E2=80=99t br= eak the trust >>>>>>> model or core use cases. If I have an AS-RS set that won=E2=80=99t = accept my >>>>>>> favorite flavor of policy engine inputs, then I can decide not to u= se that >>>>>>> one. But this is a very different question than saying the RS itsel= f needs >>>>>>> to accept my own AS =E2=80=94 and we can=E2=80=99t keep conflating = these two models. >>>>>>> >>>>>>> I agree. The point of having an AS-RO is to allow RO to specify a >>>>>> policy for which of RO's access tokens should be delegated under wha= t >>>>>> conditions. AS-RS should not need to understand those policies. Th= e flow >>>>>> would be >>>>>> >>>>>> - RO contacts AS-RS and gets one or more access tokens. >>>>>> - RO delegates one or more of those tokens, potentially >>>>>> sub-scoped, to AS-RO. >>>>>> - A different user contacts AS-RO to get a potentially sub-scoped >>>>>> access token from AS-RO. >>>>>> - That user presents the access token delegated by AS-RO when >>>>>> invoking the resource. >>>>>> >>>>>> AS-RS only needs to verify that the delegation chain is legitimate, >>>>>> e.g., no increase in scope, and that it grants permission for the re= quest >>>>>> being made. AS-RS does not need to understand the policy behind gra= nting >>>>>> the delegation by AS-RO. >>>>>> >>>>>> -------------- >>>>>> Alan Karp >>>>>> >>>>>> >>>>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer >>>>>> wrote: >>>>>> >>>>>>> Adrian, >>>>>>> >>>>>>> I think this shows the problem with the terminology as it=E2=80=99s= been >>>>>>> applied in this conversation, which I=E2=80=99ve tried to shine lig= ht on before. >>>>>>> What you and others are calling the =E2=80=9CRS=E2=80=9D is really = the =E2=80=9CAS and RS working >>>>>>> together=E2=80=9D =E2=80=94 everything to the right of the line. Wh= en Denis had brought up >>>>>>> =E2=80=9Celiminating the AS=E2=80=9D in another thread, what he=E2= =80=99d really done is labeled >>>>>>> everything to the right of the line as the =E2=80=9CRS=E2=80=9D. Of= course, the irony here >>>>>>> is that everything to the right of the line used all be called the = =E2=80=9CAS=E2=80=9D or >>>>>>> simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say bel= ow, I don=E2=80=99t want the >>>>>>> client to have visibility on what happens on that side. >>>>>>> >>>>>>> Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the di= agram is not the >>>>>>> AS, as far as GNAP is concerned. It does not issue an access token = that the >>>>>>> RS will accept. The elements to the left of the line could be a lot= of >>>>>>> things, but they are NOT the AS =E2=80=94 by definition. The client= lives over on >>>>>>> the left, but so do any external inputs to the AS. These could be p= olicy >>>>>>> inputs on behalf of the RO, they could be presentation artifacts, t= hey >>>>>>> could be federated logins, they could be the output of policy decis= ions. >>>>>>> How the AS comes to trust those things is up to the AS=E2=80=99s im= plementation. >>>>>>> It=E2=80=99s something we can talk about, but ultimately GNAP won= =E2=80=99t be in any >>>>>>> position to dictate because in practice some AS=E2=80=99s are simpl= y going to >>>>>>> internalize all policies and we will never successfully force those= open. >>>>>>> >>>>>>> But with all that in mind, I think the key here is going to be >>>>>>> looking at what the inputs to the AS are, and how those can be defi= ned in >>>>>>> an interoperable way for AS=E2=80=99s that can accept them. I think= there=E2=80=99s a lot >>>>>>> of room for innovation and flexibility here that doesn=E2=80=99t br= eak the trust >>>>>>> model or core use cases. If I have an AS-RS set that won=E2=80=99t = accept my >>>>>>> favorite flavor of policy engine inputs, then I can decide not to u= se that >>>>>>> one. But this is a very different question than saying the RS itsel= f needs >>>>>>> to accept my own AS =E2=80=94 and we can=E2=80=99t keep conflating = these two models. >>>>>>> >>>>>>> So to me, GNAP can support a Zero Trust Architecture by LEVERAGING >>>>>>> the AS, not by subsuming or eliminating it. It is in fact the AS, n= ot the >>>>>>> client and not the RS, that will request and consume the results of= a >>>>>>> privacy-preserving zero-trust policy query thing. Anything that hap= pens >>>>>>> downstream from that is of little concern to the zero-trust compone= nts >>>>>>> because, as you point out, it=E2=80=99s on the =E2=80=9Cother side= =E2=80=9D of the line. >>>>>>> >>>>>>> I think we got this basic component model pretty right in OAuth: th= e >>>>>>> AS and RS and client working together. Where OAuth misses the mark = is the >>>>>>> assumption that the user has to log in to the AS through a webpage = and >>>>>>> interact directly, thereby proving they=E2=80=99re the RO. It=E2=80= =99s this latter space >>>>>>> where I think we can both push innovation and also address the impo= rtant >>>>>>> and compelling use cases like the ones you=E2=80=99re bringing. >>>>>>> >>>>>>> =E2=80=94 Justin >>>>>>> >>>>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper >>>>>>> wrote: >>>>>>> >>>>>>> I'm sorry, Justin. As a Resource Owner, I look at the RS trust >>>>>>> boundary (the dotted line in the diagram) as being the RS. I don't = expect >>>>>>> any visibility into what's going on on the right. >>>>>>> >>>>>>> My problem with the framing you propose is that requests are going >>>>>>> to the RS (or the AS-RS) and I don't want to share my policies with= the >>>>>>> AS-RS. I want to keep the RS and AS-RS as ignorant as possible. >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer >>>>>>> wrote: >>>>>>> >>>>>>>> Adrian, >>>>>>>> >>>>>>>> What you=E2=80=99re discussing below, in terms of logging in to a = site, is >>>>>>>> not approaching the RS. You are in fact approaching the client, an= d >>>>>>>> identifying both the AS and RS to the client. The client is a clie= nt *of >>>>>>>> your identity* in this model, and the RS is part of the identity >>>>>>>> provider. It=E2=80=99s really important that we don=E2=80=99t conf= late the RS and client in >>>>>>>> this way as it leads to a lot of confusion downstream and a lot of= broken >>>>>>>> trust boundaries. >>>>>>>> >>>>>>>> With that model in mind, approaching the =E2=80=9CRS" and providin= g it your >>>>>>>> identity is really just a case of the =E2=80=9Cfederated login to = AS=E2=80=9D pattern that >>>>>>>> we discussed on the WG call. The user here approaches an RS, which= has its >>>>>>>> own AS. To share things from this RS, the RO has to authenticate t= o the >>>>>>>> RS=E2=80=99s AS. This particular AS allows the RO to do so using a= n external >>>>>>>> identity =E2=80=94 in which case, the AS is now a =E2=80=9Cclient= =E2=80=9D of a separate, >>>>>>>> disconnected (but layered) delegation. The ultimate client that ev= entually >>>>>>>> calls the RS down the way may or may not know about these layers. >>>>>>>> >>>>>>>> >>>>>>>> This same AS, which is closely tied to the RS and trusted by the >>>>>>>> RS, might also take in FIDO credentials, or DIDs, or any number of= other >>>>>>>> proof mechanisms. The output of this is an access token the RS tru= sts, but >>>>>>>> the input is up to the AS. The RS is not what you=E2=80=99re loggi= ng in to. >>>>>>>> >>>>>>>> =E2=80=94 Justin >>>>>>>> >>>>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper >>>>>>>> wrote: >>>>>>>> >>>>>>>> I too am in favor of avoiding consolidation and correlation. Right >>>>>>>> now, when I approach a service provider (RS) for the first time, I= 'm >>>>>>>> offered the opportunity to identify my persona as: email, sign-in = with >>>>>>>> Google, Facebook, or Apple. I know there are people who try to cre= ate >>>>>>>> one-off email addresses but that is mostly a waste of time. >>>>>>>> >>>>>>>> So, along come FIDO2 and DID wallets to the rescue. Now, in theory= , >>>>>>>> I have a way to start out my RS relationship pseudonymously. >>>>>>>> >>>>>>>> When I want my resource to be discovered or shared I will post tha= t >>>>>>>> RS URL including my pseudonym. If I then want to introduce a media= tor in >>>>>>>> front of my AS or messaging service endpoint, I have that option. = If I want >>>>>>>> to keep requests away from the mediator, I would publish an encryp= tion key >>>>>>>> along with my pseudonym. >>>>>>>> >>>>>>>> - Adrian >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk wrote= : >>>>>>>>> > >>>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote: >>>>>>>>> >> @Alan Karp shared a talk about the >>>>>>>>> Principle Of Least >>>>>>>>> >> Authority (POLA) in a recent comment >>>>>>>>> >> >>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#iss= uecomment-803099693 >>>>>>>>> >> I recommend it. >>>>>>>>> >> >>>>>>>>> >> We might expect a protocol with authorization in the title to >>>>>>>>> use authority >>>>>>>>> >> as a core principle. I advocate for a GNAP design that >>>>>>>>> maximizes the power >>>>>>>>> >> of the RO, to be seen as a human rights issue when the RO is a >>>>>>>>> human. This >>>>>>>>> >> causes me to ask how to combine better security with better >>>>>>>>> human rights in >>>>>>>>> >> GNAP. >>>>>>>>> >> >>>>>>>>> >> Who should have the least authority in the GNAP design? >>>>>>>>> >> >>>>>>>>> >> The AS derives authority as a delegate of the RO. If we ask th= e >>>>>>>>> RO to >>>>>>>>> >> partition limited authority across dozens of different ASs by >>>>>>>>> domain and >>>>>>>>> >> function, then we are not using technology to empower the >>>>>>>>> individual. >>>>>>>>> >> Probably the opposite, as we introduce consent fatigue and >>>>>>>>> burden normal >>>>>>>>> >> people to partition their lives into non-overlapping domains. >>>>>>>>> >> >>>>>>>>> >> My experience says we should aim for one AS per persona becaus= e >>>>>>>>> that maps >>>>>>>>> >> into the way we manage our public and private identities. POLA >>>>>>>>> would then >>>>>>>>> >> teach care in keeping ASs and RSs related to work / public >>>>>>>>> separate from >>>>>>>>> >> ASs and RSs related to private life so that a policy >>>>>>>>> vulnerability in our >>>>>>>>> >> delegation to an AS would have the least likelihood of harm. >>>>>>>>> > >>>>>>>>> > Thinking about how least authority/least privilege would apply >>>>>>>>> to GNAP >>>>>>>>> > seems like a useful exercise. I do want to point out some >>>>>>>>> potential >>>>>>>>> > pitfalls with one-AS-per-persona that we can also be aware of. >>>>>>>>> If >>>>>>>>> > one-AS-per-persona becomes one-persona-per-AS as well, then the >>>>>>>>> AS's >>>>>>>>> > identity in effect also serves as a persona identity and there >>>>>>>>> are privacy >>>>>>>>> > considerations to that. If, on the other hand, the >>>>>>>>> > multiple-personas-per-AS (presumably corresponding to multiple >>>>>>>>> humans) >>>>>>>>> > route is taken, we should consider whether that would lead to >>>>>>>>> various >>>>>>>>> > (e.g., market) forces driving consolidation to just a handful o= f >>>>>>>>> > super-popular AS services. That topic is a current matter of >>>>>>>>> concern to >>>>>>>>> > some IETF participants. >>>>>>>>> > >>>>>>>>> >>>>>>>>> Hi Ben, big +1 to this. This is something that we discussed ages >>>>>>>>> ago in the UMA working group, and it=E2=80=99s one of the biggest= problems with the >>>>>>>>> personal AS (and personal data store) model. This kind of thing m= akes >>>>>>>>> RS-first trust models really difficult in practice. >>>>>>>>> >>>>>>>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve got software t= hat wants to >>>>>>>>> access my medical information. It calls an RS and requests access= , but it >>>>>>>>> hasn=E2=80=99t been granted anything yet. Now I as the RO have se= t up the RS so >>>>>>>>> that it talks to my personal AS, that only I use. In addition to = the RS >>>>>>>>> having to be able to figure out which medical records are being r= equested >>>>>>>>> from the context of the unauthenticated request (which means it n= eeds >>>>>>>>> identifiers in the URL or something similar for the RS to be able= to tell, >>>>>>>>> assuming that it protects data for more than one person). So this= client >>>>>>>>> software doesn=E2=80=99t know who I am and doesn=E2=80=99t know m= y medical record >>>>>>>>> information, makes a completely unauthorized request to the RS, a= nd the RS >>>>>>>>> says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token= =E2=80=9D. The client can now make a >>>>>>>>> direct correlation between the data that=E2=80=99s being protecte= d at the RS and >>>>>>>>> the person running the AS that protects it. Importantly, this cli= ent makes >>>>>>>>> this call with no prior relationship to the RS and no really audi= table way >>>>>>>>> to track it down after the fact. This is a design feature in the = good case, >>>>>>>>> and terrifying in the bad case. >>>>>>>>> >>>>>>>>> If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, pl= ease talk >>>>>>>>> to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80= =99t exposed anything at >>>>>>>>> all. And from the perspective of both the patient and the RS, thi= s is more >>>>>>>>> privacy-preserving, and it=E2=80=99s really the least surprising = option. Once the >>>>>>>>> client gets to the AS, it can start a negotiation of figuring out= who the >>>>>>>>> RO is for the information being accessed. >>>>>>>>> >>>>>>>>> On top of this, the usability expectations of people managing >>>>>>>>> their own AS, or set of AS=E2=80=99s for multiple personas to kee= p things separate, >>>>>>>>> is a huge burden. Even in the tech community, I know people who c= an=E2=80=99t >>>>>>>>> reliably manage more than one email address for different purpose= s. I >>>>>>>>> wouldn=E2=80=99t expect my partner to do that =E2=80=94 they have= trouble enough balancing >>>>>>>>> all the logins and sessions required for different kids remote sc= hooling, I >>>>>>>>> couldn=E2=80=99t imagine them having to understand all the requir= ements for >>>>>>>>> managing multiple authorization servers and associated policies. = I also >>>>>>>>> don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for >>>>>>>>> decades and I can barely keep tabs on my GPG keys, and only use t= hem when I >>>>>>>>> am forced to. This is exactly the kind of =E2=80=9Cmarket pressur= e=E2=80=9D that I think >>>>>>>>> Ben mentions above, people will just want to outsource that to so= meone >>>>>>>>> else, and the reality will be a few popular providers. >>>>>>>>> >>>>>>>>> In which case, we could end up doing a ton of work to allow an RS >>>>>>>>> choice only to end up with a world where the RS ends up making a = limited >>>>>>>>> choice anyway. We see how that plays out with OpenID Connect =E2= =80=94 RP=E2=80=99s could >>>>>>>>> allow arbitrary IdPs but they choose Google because it works and = that=E2=80=99s >>>>>>>>> where the users are. (And that=E2=80=99s not to say anything of t= he proprietary >>>>>>>>> OIDC-like protocols, but that=E2=80=99s another discussion). >>>>>>>>> >>>>>>>>> For further reading on these topics, I recommend both =E2=80=9CWh= y Johnny >>>>>>>>> Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail= =E2=80=9D. >>>>>>>>> >>>>>>>>> So what does this have to do with GNAP? I think we can be >>>>>>>>> clear-eyed on what kinds of expectations we have for the particip= ants. If >>>>>>>>> we expect users (RO=E2=80=99s) to have to set up the AS-RS relati= onship, or expect >>>>>>>>> them to carry their AS, or manage their personal keys =E2=80=94 I= think we=E2=80=99ve lost >>>>>>>>> the battle for relevance. >>>>>>>>> >>>>>>>>> =E2=80=94 Justin >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>> 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 > --00000000000056c28a05be535968 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    Based on that, I see it as obvious=C2=A0that the policy has to be ac= cessible (defined locally?) in order for it to be run as the code that turn= s a request into an access token.=C2=A0

    The only o= ther possibility is that the request is packaged by the AS and sent elsewhe= re (an agent) for evaluation against policy and a proto-token returned. In = that case the AS is acting as a proxy and the PDP is elsewhere. I can imagi= ne that an AS-RS would behave this way so that the proto-token could be tur= ned into an access token by the AS-RS. Isn't this what Justin is propos= ing? In this design, the AS is the AS-RS and the agent is the AS-RO. By my = definition, this model has two ASs since both are processing requests into = tokens. The problem with this is complexity and privacy. The RO may not wan= t to share the request information with the AS-RS.

    Adrian

    On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Isn't that what the AS i= s supposed to be, only with the caveat that the policy is defined locally?= =C2=A0

    Fabien=C2=A0

    <= br>
    Le mer.= 24 mars 2021 =C3=A0 20:17, Alan Karp <alanhkarp@gmail.com> a =C3=A9crit=C2=A0:
    =
    AS-RO is an AS tha= t RO trusts to delegate RO's access tokens according to RO's polici= es.=C2=A0=C2=A0

    --------------Alan Karp


    On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault &= lt;fabien.imbault@gmail.com> wrote:
    =
    Hi Alan and Adrian,

    I've created is= sue AS-RO policy delegation (https://gi= thub.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to capture your in= put.=C2=A0
    A first question that arises: can we give a definition= to AS-RO?

    Thanks
    Fabien

    =
    On Tue, Ma= r 23, 2021 at 4:15 PM Alan Karp <alanhkarp@gmail.com> wrote:
    =
    <= div dir=3D"ltr">
    Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan,=C2=A0

    Yes, but in that flow, the to= ken relationship between AS-RS and AS-RO is only secure if the tokens issue= d by AS-RS are cryptographically attenuable in the first place.=C2=A0
    =
    =C2=A0
    Attenuated delega= tion is a requirement, but that doesn't have to be done cryptographical= ly.=C2=A0 Token exchange works just fine.=C2=A0 SPKI and zcap-ld are exampl= es of the crypto approach, and we used token exchange in the system for HP.=

    --------------
    Alan Karp

    <= /div>
    O= n Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault <fabien.imbault@gmai= l.com> wrote:
    Hi Alan,=C2= =A0

    Yes, but in that flow, the token relationship betwee= n AS-RS and AS-RO is only secure if the tokens issued by AS-RS are cryptogr= aphically attenuable in the first place.=C2=A0

    Fab= ien

    On Mon, Mar 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com= > wrote:
    Justin Richer <jricher@mit.edu&g= t; wrote:

    But with all t= hat in mind, I think the key here is going to be looking at what the inputs= to the AS are, and how those can be defined in an interoperable way for AS= =E2=80=99s that can accept them. I think there=E2=80=99s a lot of room for = innovation and flexibility here that doesn=E2=80=99t break the trust model = or core use cases. If I have an AS-RS set that won=E2=80=99t accept my favo= rite flavor of policy engine inputs, then I can decide not to use that one.= But this is a very different question than saying the RS itself needs to a= ccept my own AS =E2=80=94 and we can=E2=80=99t keep conflating these two mo= dels.

    I agree.=C2=A0 The point = of having an AS-RO is to allow RO to specify a policy for which of RO's= access tokens should be delegated under what conditions.=C2=A0 AS-RS shoul= d not need to understand those policies.=C2=A0 The flow would be
    =
    • RO contacts AS-RS and gets one or more access tokens.
    • RO de= legates one or more of those tokens, potentially sub-scoped, to AS-RO.
      • =
    • A different user contacts AS-RO to get a potentially sub-scoped access = token from AS-RO.
    • That user presents the access token delegated by = AS-RO when invoking the resource.
    AS-RS only needs= to verify that the delegation chain is legitimate, e.g., no increase in sc= ope, and that it grants permission for the request being made.=C2=A0 AS-RS = does not need to understand the policy behind granting the delegation by AS= -RO.

    --------------
    Alan Karp

    <= /div>
    O= n Mon, Mar 22, 2021 at 11:40 AM Justin Richer <jricher@mit.edu> wrot= e:
    Adrian,

    I think this s= hows the problem with the terminology as it=E2=80=99s been applied in this = conversation, which I=E2=80=99ve tried to shine light on before. What you a= nd others are calling the =E2=80=9CRS=E2=80=9D is really the =E2=80=9CAS an= d RS working together=E2=80=9D =E2=80=94 everything to the right of the lin= e. When Denis had brought up =E2=80=9Celiminating the AS=E2=80=9D in anothe= r thread, what he=E2=80=99d really done is labeled everything to the right = of the line as the =E2=80=9CRS=E2=80=9D. Of course, the irony here is that = everything to the right of the line used all be called the =E2=80=9CAS=E2= =80=9D or simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say b= elow, I don=E2=80=99t want the client to have visibility on what happens on= that side.=C2=A0

    Note well: The Google+ logo labe= led =E2=80=9CIdP=E2=80=9D in the diagram is not the AS, as far as GNAP is c= oncerned. It does not issue an access token that the RS will accept. The el= ements to the left of the line could be a lot of things, but they are NOT t= he AS =E2=80=94 by definition. The client lives over on the left, but so do= any external inputs to the AS. These could be policy inputs on behalf of t= he RO, they could be presentation artifacts, they could be federated logins= , they could be the output of policy decisions. How the AS comes to trust t= hose things is up to the AS=E2=80=99s implementation. It=E2=80=99s somethin= g we can talk about, but ultimately GNAP won=E2=80=99t be in any position t= o dictate because in practice some AS=E2=80=99s are simply going to interna= lize all policies and we will never successfully force those open.=C2=A0

    But with all that in mind, I think the key here is g= oing to be looking at what the inputs to the AS are, and how those can be d= efined in an interoperable way for AS=E2=80=99s that can accept them. I thi= nk there=E2=80=99s a lot of room for innovation and flexibility here that d= oesn=E2=80=99t break the trust model or core use cases. If I have an AS-RS = set that won=E2=80=99t accept my favorite flavor of policy engine inputs, t= hen I can decide not to use that one. But this is a very different question= than saying the RS itself needs to accept my own AS =E2=80=94 and we can= =E2=80=99t keep conflating these two models.

    So to= me, GNAP can support a Zero Trust Architecture by LEVERAGING the AS, not b= y subsuming or eliminating it. It is in fact the AS, not the client and not= the RS, that will request and consume the results of a privacy-preserving = zero-trust policy query thing. Anything that happens downstream from that i= s of little concern to the zero-trust components because, as you point out,= it=E2=80=99s on the =E2=80=9Cother side=E2=80=9D of the line.=C2=A0
    <= div>
    I think we got this basic component model pretty right i= n OAuth: the AS and RS and client working together. Where OAuth misses the = mark is the assumption that the user has to log in to the AS through a webp= age and interact directly, thereby proving they=E2=80=99re the RO. It=E2=80= =99s this latter space where I think we can both push innovation and also a= ddress the important and compelling use cases like the ones you=E2=80=99re = bringing.

    =C2=A0=E2=80=94 Justin

    On Mar 22, 2021, at 2:14 PM, Adrian Gropper <<= a href=3D"mailto:agropper@healthurl.com" rel=3D"noreferrer" target=3D"_blan= k">agropper@healthurl.com> wrote:

    I&#= 39;m sorry, Justin. As a Resource Owner, I look at the RS trust boundary (t= he dotted line in the diagram) as being the RS. I don't expect any visi= bility into what's going on on the=C2=A0right.=C2=A0

    My problem with the framing you propose is that requests are going to the = RS (or the AS-RS) and I don't want to share my policies with the AS-RS.= I want to keep the RS and AS-RS as ignorant as possible.

    Adrian

    On Mon, Mar 22, 2021 at 1:48 PM Justin Richer <jricher@= mit.edu> wrote:
    Adrian,

    What you=E2=80=99re discussing below, in terms of logging in to a sit= e, is not approaching the RS. You are in fact approaching the client, and i= dentifying both the AS and RS to the client. The client is a client of y= our identity in this model, and the RS is part of the identity provider= . It=E2=80=99s really important that we don=E2=80=99t conflate the RS and c= lient in this way as it leads to a lot of confusion downstream and a lot of= broken trust boundaries.

    With that model in mind,= approaching the =E2=80=9CRS" and providing it your identity is really= just a case of the =E2=80=9Cfederated login to AS=E2=80=9D pattern that we= discussed on the WG call. The user here approaches an RS, which has its ow= n AS. To share things from this RS, the RO has to authenticate to the RS=E2= =80=99s AS. This particular AS allows the RO to do so using an external ide= ntity =E2=80=94 in which case, the AS is now a =E2=80=9Cclient=E2=80=9D of = a separate, disconnected (but layered) delegation. The ultimate client that= eventually calls the RS down the way may or may not know about these layer= s.=C2=A0

    <PastedGraphic-1.png>
    This same AS, which is closely tied to the RS and trusted by the RS, migh= t also take in FIDO credentials, or DIDs, or any number of other proof mech= anisms. The output of this is an access token the RS trusts, but the input = is up to the AS. The RS is not what you=E2=80=99re logging in to.

    =C2=A0=E2=80=94 Justin

    On Mar 22, 2021, at 1:28 PM, Adrian Gropper <agropper@healthu= rl.com> wrote:

    I too am in favor of a= voiding consolidation and correlation. Right now, when I approach a service= provider (RS) for the first time, I'm offered the opportunity to ident= ify my persona as: email, sign-in with Google, Facebook, or Apple. I know t= here are people who try to create one-off email addresses but that is mostl= y a waste of time.=C2=A0

    So, along come FIDO2 and DID wa= llets to the rescue. Now, in theory, I have a way to start out my RS relati= onship pseudonymously.=C2=A0

    When I want my resour= ce to be discovered or shared I will post that RS URL including my pseudony= m. If I then want to introduce a mediator=C2=A0in front of my AS or messagi= ng service=C2=A0endpoint, I have that option. If I want to keep requests aw= ay from the mediator, I would publish an encryption key along with my pseud= onym.

    - Adrian


    =

    = On Mon, Mar 22, 2021 at 9:55 AM Justin Richer <jricher@mit.edu> wrot= e:
    On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk &l= t;kad= uk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhkarp@gmail.com> shared a talk about th= e Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomm= ent-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --
    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
    --00000000000056c28a05be535968-- From nobody Wed Mar 24 20:22:21 2021 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 AB6F03A1AA8 for ; Wed, 24 Mar 2021 20:22:19 -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 tzDHyl_rv9yg for ; Wed, 24 Mar 2021 20:22:14 -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 A1FC03A1AA6 for ; Wed, 24 Mar 2021 20:22:14 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id g24so736441qts.6 for ; Wed, 24 Mar 2021 20:22: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=+Z6KOfSb2AdY0EFGiFUUgIn/XF9DvmAi0KlvDJrEdcI=; b=JksUAKAS3ZjfeRGyHOW+pdj6OwIORaCt8f/S7ssnwZoTImMFiWCTKeg7Z4MwRWDYkZ UnuDPwZk2lJu7nbAznb0Ul367bVBQ4pS0eqpElogN6Qj/XlbsZQ+QZmoAhhvpAU66vDk AAm85LyFNsxDraAhabpF/qdifF076zRDCmlG4JXAwIInFJt7oZ9tZXTa2jrxD1vPXlmD 11iTOQfnlSZlv1qFzWeQJcG1klm9qdLjM337PxrRh2s+/Vlc8DQO49QOvlj64sKdQn0A KmLLLeUrxsO938CNSE6jLc+Wn5vSOJZVRKprVVnEVZtHt2upmV+GLesBYHxbF4O8luBY NBFg== 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=+Z6KOfSb2AdY0EFGiFUUgIn/XF9DvmAi0KlvDJrEdcI=; b=nZ4qNapxOzV+hRUsZwmSydHymATQ1r4o9fz544qeNUWCeopqnHWuEcz7KLE4+7ycjp zhrhQYVpf0+cHfpNXqeohHNI6bsTW4PkJH0YhwQaZO/Vfk+6dBZhQiUfptzIiWSiwpwL pFi4rOCWfvDicQz5cOohxtx29/Id3rT1h3JoQt2/Gtf0Vxm9aLFxMAXaFiMgt7IdwnNO 6y3GMyqexra7snF+5lZys/8ckuoGlk9uB/SDb70JfTDhWpUACzEgbg42tAGXyvIKgfCt iFqFs2N0Xcu3SRtwJKSvOkRvUx9RX7J3dNCotQwkUJQZMUP8wQ/jtn8NEZ71ONngOaYg qS+Q== X-Gm-Message-State: AOAM531cHbeVcDBv6g6e+Uo74gnjJ7DzDxUEENMx1YlvtX52P1A7NDCA qeYY+NjkehI06tJIPkFQ7g8S6I4uxThioXq8yio= X-Google-Smtp-Source: ABdhPJx9ti6Uar8LQPyxWWB5JYxhQRQQJI3D+O/QtKnFkl4m1m4538dNZ84Agy8WSFTEhfkE7yayQCC+TjAiqalhkeA= X-Received: by 2002:ac8:7c8d:: with SMTP id y13mr5804016qtv.294.1616642532745; Wed, 24 Mar 2021 20:22:12 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> In-Reply-To: From: Alan Karp Date: Wed, 24 Mar 2021 20:22:00 -0700 Message-ID: To: Adrian Gropper Cc: Fabien Imbault , Mark Miller , Benjamin Kaduk , Justin Richer , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000e4a50705be53ebc9" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 03:22:20 -0000 --000000000000e4a50705be53ebc9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Adrian Gropper wrote: > > In this design, the AS is the AS-RS and the agent is the AS-RO. By my > definition, this model has two ASs since both are processing requests int= o > tokens. The problem with this is complexity and privacy. The RO may not > want to share the request information with the AS-RS. > More precisely, RO has no choice but to present the required information to AS-RS if RO wants an access token. However, RO does not want AS-RS to know the policy by which RO delegates tokens. That's why RO uses AS-RO for those delegations. -------------- Alan Karp On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper wrote: > Thank you for creating the issue. My definition of AS is independent of > AS-RO or AS-RS. > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecommen= t-806280421 > I also agree with Alan's definition based on delegation. An AS-RS would b= e > a delegate of the RS. > > Based on that, I see it as obvious that the policy has to be accessible > (defined locally?) in order for it to be run as the code that turns a > request into an access token. > > The only other possibility is that the request is packaged by the AS and > sent elsewhere (an agent) for evaluation against policy and a proto-token > returned. In that case the AS is acting as a proxy and the PDP is > elsewhere. I can imagine that an AS-RS would behave this way so that the > proto-token could be turned into an access token by the AS-RS. Isn't this > what Justin is proposing? In this design, the AS is the AS-RS and the age= nt > is the AS-RO. By my definition, this model has two ASs since both are > processing requests into tokens. The problem with this is complexity and > privacy. The RO may not want to share the request information with the > AS-RS. > > Adrian > > On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault > wrote: > >> Isn't that what the AS is supposed to be, only with the caveat that the >> policy is defined locally? >> >> Fabien >> >> >> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp a =C3= =A9crit : >> >>> AS-RO is an AS that RO trusts to delegate RO's access tokens according >>> to RO's policies. >>> >>> -------------- >>> Alan Karp >>> >>> >>> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault >>> wrote: >>> >>>> Hi Alan and Adrian, >>>> >>>> I've created issue AS-RO policy delegation ( >>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to >>>> capture your input. >>>> A first question that arises: can we give a definition to AS-RO? >>>> >>>> Thanks >>>> Fabien >>>> >>>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp wrote: >>>> >>>>> Fabien Imbault wrote: >>>>> >>>>>> Hi Alan, >>>>>> >>>>>> Yes, but in that flow, the token relationship between AS-RS and AS-R= O >>>>>> is only secure if the tokens issued by AS-RS are cryptographically >>>>>> attenuable in the first place. >>>>>> >>>>> >>>>> Attenuated delegation is a requirement, but that doesn't have to be >>>>> done cryptographically. Token exchange works just fine. SPKI and zc= ap-ld >>>>> are examples of the crypto approach, and we used token exchange in th= e >>>>> system for HP. >>>>> >>>>> -------------- >>>>> Alan Karp >>>>> >>>>> >>>>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Hi Alan, >>>>>> >>>>>> Yes, but in that flow, the token relationship between AS-RS and AS-R= O >>>>>> is only secure if the tokens issued by AS-RS are cryptographically >>>>>> attenuable in the first place. >>>>>> >>>>>> Fabien >>>>>> >>>>>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp >>>>>> wrote: >>>>>> >>>>>>> Justin Richer wrote: >>>>>>> >>>>>>>> >>>>>>>> But with all that in mind, I think the key here is going to be >>>>>>>> looking at what the inputs to the AS are, and how those can be def= ined in >>>>>>>> an interoperable way for AS=E2=80=99s that can accept them. I thin= k there=E2=80=99s a lot >>>>>>>> of room for innovation and flexibility here that doesn=E2=80=99t b= reak the trust >>>>>>>> model or core use cases. If I have an AS-RS set that won=E2=80=99t= accept my >>>>>>>> favorite flavor of policy engine inputs, then I can decide not to = use that >>>>>>>> one. But this is a very different question than saying the RS itse= lf needs >>>>>>>> to accept my own AS =E2=80=94 and we can=E2=80=99t keep conflating= these two models. >>>>>>>> >>>>>>>> I agree. The point of having an AS-RO is to allow RO to specify a >>>>>>> policy for which of RO's access tokens should be delegated under wh= at >>>>>>> conditions. AS-RS should not need to understand those policies. T= he flow >>>>>>> would be >>>>>>> >>>>>>> - RO contacts AS-RS and gets one or more access tokens. >>>>>>> - RO delegates one or more of those tokens, potentially >>>>>>> sub-scoped, to AS-RO. >>>>>>> - A different user contacts AS-RO to get a potentially >>>>>>> sub-scoped access token from AS-RO. >>>>>>> - That user presents the access token delegated by AS-RO when >>>>>>> invoking the resource. >>>>>>> >>>>>>> AS-RS only needs to verify that the delegation chain is legitimate, >>>>>>> e.g., no increase in scope, and that it grants permission for the r= equest >>>>>>> being made. AS-RS does not need to understand the policy behind gr= anting >>>>>>> the delegation by AS-RO. >>>>>>> >>>>>>> -------------- >>>>>>> Alan Karp >>>>>>> >>>>>>> >>>>>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer >>>>>>> wrote: >>>>>>> >>>>>>>> Adrian, >>>>>>>> >>>>>>>> I think this shows the problem with the terminology as it=E2=80=99= s been >>>>>>>> applied in this conversation, which I=E2=80=99ve tried to shine li= ght on before. >>>>>>>> What you and others are calling the =E2=80=9CRS=E2=80=9D is really= the =E2=80=9CAS and RS working >>>>>>>> together=E2=80=9D =E2=80=94 everything to the right of the line. W= hen Denis had brought up >>>>>>>> =E2=80=9Celiminating the AS=E2=80=9D in another thread, what he=E2= =80=99d really done is labeled >>>>>>>> everything to the right of the line as the =E2=80=9CRS=E2=80=9D. O= f course, the irony here >>>>>>>> is that everything to the right of the line used all be called the= =E2=80=9CAS=E2=80=9D or >>>>>>>> simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say be= low, I don=E2=80=99t want the >>>>>>>> client to have visibility on what happens on that side. >>>>>>>> >>>>>>>> Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the d= iagram is not the >>>>>>>> AS, as far as GNAP is concerned. It does not issue an access token= that the >>>>>>>> RS will accept. The elements to the left of the line could be a lo= t of >>>>>>>> things, but they are NOT the AS =E2=80=94 by definition. The clien= t lives over on >>>>>>>> the left, but so do any external inputs to the AS. These could be = policy >>>>>>>> inputs on behalf of the RO, they could be presentation artifacts, = they >>>>>>>> could be federated logins, they could be the output of policy deci= sions. >>>>>>>> How the AS comes to trust those things is up to the AS=E2=80=99s i= mplementation. >>>>>>>> It=E2=80=99s something we can talk about, but ultimately GNAP won= =E2=80=99t be in any >>>>>>>> position to dictate because in practice some AS=E2=80=99s are simp= ly going to >>>>>>>> internalize all policies and we will never successfully force thos= e open. >>>>>>>> >>>>>>>> But with all that in mind, I think the key here is going to be >>>>>>>> looking at what the inputs to the AS are, and how those can be def= ined in >>>>>>>> an interoperable way for AS=E2=80=99s that can accept them. I thin= k there=E2=80=99s a lot >>>>>>>> of room for innovation and flexibility here that doesn=E2=80=99t b= reak the trust >>>>>>>> model or core use cases. If I have an AS-RS set that won=E2=80=99t= accept my >>>>>>>> favorite flavor of policy engine inputs, then I can decide not to = use that >>>>>>>> one. But this is a very different question than saying the RS itse= lf needs >>>>>>>> to accept my own AS =E2=80=94 and we can=E2=80=99t keep conflating= these two models. >>>>>>>> >>>>>>>> So to me, GNAP can support a Zero Trust Architecture by LEVERAGING >>>>>>>> the AS, not by subsuming or eliminating it. It is in fact the AS, = not the >>>>>>>> client and not the RS, that will request and consume the results o= f a >>>>>>>> privacy-preserving zero-trust policy query thing. Anything that ha= ppens >>>>>>>> downstream from that is of little concern to the zero-trust compon= ents >>>>>>>> because, as you point out, it=E2=80=99s on the =E2=80=9Cother side= =E2=80=9D of the line. >>>>>>>> >>>>>>>> I think we got this basic component model pretty right in OAuth: >>>>>>>> the AS and RS and client working together. Where OAuth misses the = mark is >>>>>>>> the assumption that the user has to log in to the AS through a web= page and >>>>>>>> interact directly, thereby proving they=E2=80=99re the RO. It=E2= =80=99s this latter space >>>>>>>> where I think we can both push innovation and also address the imp= ortant >>>>>>>> and compelling use cases like the ones you=E2=80=99re bringing. >>>>>>>> >>>>>>>> =E2=80=94 Justin >>>>>>>> >>>>>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper >>>>>>>> wrote: >>>>>>>> >>>>>>>> I'm sorry, Justin. As a Resource Owner, I look at the RS trust >>>>>>>> boundary (the dotted line in the diagram) as being the RS. I don't= expect >>>>>>>> any visibility into what's going on on the right. >>>>>>>> >>>>>>>> My problem with the framing you propose is that requests are going >>>>>>>> to the RS (or the AS-RS) and I don't want to share my policies wit= h the >>>>>>>> AS-RS. I want to keep the RS and AS-RS as ignorant as possible. >>>>>>>> >>>>>>>> Adrian >>>>>>>> >>>>>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Adrian, >>>>>>>>> >>>>>>>>> What you=E2=80=99re discussing below, in terms of logging in to a= site, is >>>>>>>>> not approaching the RS. You are in fact approaching the client, a= nd >>>>>>>>> identifying both the AS and RS to the client. The client is a cli= ent *of >>>>>>>>> your identity* in this model, and the RS is part of the identity >>>>>>>>> provider. It=E2=80=99s really important that we don=E2=80=99t con= flate the RS and client in >>>>>>>>> this way as it leads to a lot of confusion downstream and a lot o= f broken >>>>>>>>> trust boundaries. >>>>>>>>> >>>>>>>>> With that model in mind, approaching the =E2=80=9CRS" and providi= ng it >>>>>>>>> your identity is really just a case of the =E2=80=9Cfederated log= in to AS=E2=80=9D pattern >>>>>>>>> that we discussed on the WG call. The user here approaches an RS,= which has >>>>>>>>> its own AS. To share things from this RS, the RO has to authentic= ate to the >>>>>>>>> RS=E2=80=99s AS. This particular AS allows the RO to do so using = an external >>>>>>>>> identity =E2=80=94 in which case, the AS is now a =E2=80=9Cclient= =E2=80=9D of a separate, >>>>>>>>> disconnected (but layered) delegation. The ultimate client that e= ventually >>>>>>>>> calls the RS down the way may or may not know about these layers. >>>>>>>>> >>>>>>>>> >>>>>>>>> This same AS, which is closely tied to the RS and trusted by the >>>>>>>>> RS, might also take in FIDO credentials, or DIDs, or any number o= f other >>>>>>>>> proof mechanisms. The output of this is an access token the RS tr= usts, but >>>>>>>>> the input is up to the AS. The RS is not what you=E2=80=99re logg= ing in to. >>>>>>>>> >>>>>>>>> =E2=80=94 Justin >>>>>>>>> >>>>>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper < >>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>> >>>>>>>>> I too am in favor of avoiding consolidation and correlation. Righ= t >>>>>>>>> now, when I approach a service provider (RS) for the first time, = I'm >>>>>>>>> offered the opportunity to identify my persona as: email, sign-in= with >>>>>>>>> Google, Facebook, or Apple. I know there are people who try to cr= eate >>>>>>>>> one-off email addresses but that is mostly a waste of time. >>>>>>>>> >>>>>>>>> So, along come FIDO2 and DID wallets to the rescue. Now, in >>>>>>>>> theory, I have a way to start out my RS relationship pseudonymous= ly. >>>>>>>>> >>>>>>>>> When I want my resource to be discovered or shared I will post >>>>>>>>> that RS URL including my pseudonym. If I then want to introduce a >>>>>>>>> mediator in front of my AS or messaging service endpoint, I have = that >>>>>>>>> option. If I want to keep requests away from the mediator, I woul= d publish >>>>>>>>> an encryption key along with my pseudonym. >>>>>>>>> >>>>>>>>> - Adrian >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk >>>>>>>>>> wrote: >>>>>>>>>> > >>>>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote= : >>>>>>>>>> >> @Alan Karp shared a talk about the >>>>>>>>>> Principle Of Least >>>>>>>>>> >> Authority (POLA) in a recent comment >>>>>>>>>> >> >>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#is= suecomment-803099693 >>>>>>>>>> >> I recommend it. >>>>>>>>>> >> >>>>>>>>>> >> We might expect a protocol with authorization in the title to >>>>>>>>>> use authority >>>>>>>>>> >> as a core principle. I advocate for a GNAP design that >>>>>>>>>> maximizes the power >>>>>>>>>> >> of the RO, to be seen as a human rights issue when the RO is = a >>>>>>>>>> human. This >>>>>>>>>> >> causes me to ask how to combine better security with better >>>>>>>>>> human rights in >>>>>>>>>> >> GNAP. >>>>>>>>>> >> >>>>>>>>>> >> Who should have the least authority in the GNAP design? >>>>>>>>>> >> >>>>>>>>>> >> The AS derives authority as a delegate of the RO. If we ask >>>>>>>>>> the RO to >>>>>>>>>> >> partition limited authority across dozens of different ASs by >>>>>>>>>> domain and >>>>>>>>>> >> function, then we are not using technology to empower the >>>>>>>>>> individual. >>>>>>>>>> >> Probably the opposite, as we introduce consent fatigue and >>>>>>>>>> burden normal >>>>>>>>>> >> people to partition their lives into non-overlapping domains. >>>>>>>>>> >> >>>>>>>>>> >> My experience says we should aim for one AS per persona >>>>>>>>>> because that maps >>>>>>>>>> >> into the way we manage our public and private identities. POL= A >>>>>>>>>> would then >>>>>>>>>> >> teach care in keeping ASs and RSs related to work / public >>>>>>>>>> separate from >>>>>>>>>> >> ASs and RSs related to private life so that a policy >>>>>>>>>> vulnerability in our >>>>>>>>>> >> delegation to an AS would have the least likelihood of harm. >>>>>>>>>> > >>>>>>>>>> > Thinking about how least authority/least privilege would apply >>>>>>>>>> to GNAP >>>>>>>>>> > seems like a useful exercise. I do want to point out some >>>>>>>>>> potential >>>>>>>>>> > pitfalls with one-AS-per-persona that we can also be aware of. >>>>>>>>>> If >>>>>>>>>> > one-AS-per-persona becomes one-persona-per-AS as well, then th= e >>>>>>>>>> AS's >>>>>>>>>> > identity in effect also serves as a persona identity and there >>>>>>>>>> are privacy >>>>>>>>>> > considerations to that. If, on the other hand, the >>>>>>>>>> > multiple-personas-per-AS (presumably corresponding to multiple >>>>>>>>>> humans) >>>>>>>>>> > route is taken, we should consider whether that would lead to >>>>>>>>>> various >>>>>>>>>> > (e.g., market) forces driving consolidation to just a handful = of >>>>>>>>>> > super-popular AS services. That topic is a current matter of >>>>>>>>>> concern to >>>>>>>>>> > some IETF participants. >>>>>>>>>> > >>>>>>>>>> >>>>>>>>>> Hi Ben, big +1 to this. This is something that we discussed ages >>>>>>>>>> ago in the UMA working group, and it=E2=80=99s one of the bigges= t problems with the >>>>>>>>>> personal AS (and personal data store) model. This kind of thing = makes >>>>>>>>>> RS-first trust models really difficult in practice. >>>>>>>>>> >>>>>>>>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve got software = that wants to >>>>>>>>>> access my medical information. It calls an RS and requests acces= s, but it >>>>>>>>>> hasn=E2=80=99t been granted anything yet. Now I as the RO have s= et up the RS so >>>>>>>>>> that it talks to my personal AS, that only I use. In addition to= the RS >>>>>>>>>> having to be able to figure out which medical records are being = requested >>>>>>>>>> from the context of the unauthenticated request (which means it = needs >>>>>>>>>> identifiers in the URL or something similar for the RS to be abl= e to tell, >>>>>>>>>> assuming that it protects data for more than one person). So thi= s client >>>>>>>>>> software doesn=E2=80=99t know who I am and doesn=E2=80=99t know = my medical record >>>>>>>>>> information, makes a completely unauthorized request to the RS, = and the RS >>>>>>>>>> says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token= =E2=80=9D. The client can now make a >>>>>>>>>> direct correlation between the data that=E2=80=99s being protect= ed at the RS and >>>>>>>>>> the person running the AS that protects it. Importantly, this cl= ient makes >>>>>>>>>> this call with no prior relationship to the RS and no really aud= itable way >>>>>>>>>> to track it down after the fact. This is a design feature in the= good case, >>>>>>>>>> and terrifying in the bad case. >>>>>>>>>> >>>>>>>>>> If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, p= lease >>>>>>>>>> talk to the Medicine Doctor AS to get access=E2=80=9D, we haven= =E2=80=99t exposed anything >>>>>>>>>> at all. And from the perspective of both the patient and the RS,= this is >>>>>>>>>> more privacy-preserving, and it=E2=80=99s really the least surpr= ising option. Once >>>>>>>>>> the client gets to the AS, it can start a negotiation of figurin= g out who >>>>>>>>>> the RO is for the information being accessed. >>>>>>>>>> >>>>>>>>>> On top of this, the usability expectations of people managing >>>>>>>>>> their own AS, or set of AS=E2=80=99s for multiple personas to ke= ep things separate, >>>>>>>>>> is a huge burden. Even in the tech community, I know people who = can=E2=80=99t >>>>>>>>>> reliably manage more than one email address for different purpos= es. I >>>>>>>>>> wouldn=E2=80=99t expect my partner to do that =E2=80=94 they hav= e trouble enough balancing >>>>>>>>>> all the logins and sessions required for different kids remote s= chooling, I >>>>>>>>>> couldn=E2=80=99t imagine them having to understand all the requi= rements for >>>>>>>>>> managing multiple authorization servers and associated policies.= I also >>>>>>>>>> don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D= =E2=80=94 I=E2=80=99ve been on the internet for >>>>>>>>>> decades and I can barely keep tabs on my GPG keys, and only use = them when I >>>>>>>>>> am forced to. This is exactly the kind of =E2=80=9Cmarket pressu= re=E2=80=9D that I think >>>>>>>>>> Ben mentions above, people will just want to outsource that to s= omeone >>>>>>>>>> else, and the reality will be a few popular providers. >>>>>>>>>> >>>>>>>>>> In which case, we could end up doing a ton of work to allow an R= S >>>>>>>>>> choice only to end up with a world where the RS ends up making a= limited >>>>>>>>>> choice anyway. We see how that plays out with OpenID Connect =E2= =80=94 RP=E2=80=99s could >>>>>>>>>> allow arbitrary IdPs but they choose Google because it works and= that=E2=80=99s >>>>>>>>>> where the users are. (And that=E2=80=99s not to say anything of = the proprietary >>>>>>>>>> OIDC-like protocols, but that=E2=80=99s another discussion). >>>>>>>>>> >>>>>>>>>> For further reading on these topics, I recommend both =E2=80=9CW= hy Johnny >>>>>>>>>> Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fai= l=E2=80=9D. >>>>>>>>>> >>>>>>>>>> So what does this have to do with GNAP? I think we can be >>>>>>>>>> clear-eyed on what kinds of expectations we have for the partici= pants. If >>>>>>>>>> we expect users (RO=E2=80=99s) to have to set up the AS-RS relat= ionship, or expect >>>>>>>>>> them to carry their AS, or manage their personal keys =E2=80=94 = I think we=E2=80=99ve lost >>>>>>>>>> the battle for relevance. >>>>>>>>>> >>>>>>>>>> =E2=80=94 Justin >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>> 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 >> > --000000000000e4a50705be53ebc9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Adr= ian Gropper <agropper@healthur= l.com> wrote:

    In this design, the A= S is the AS-RS and the agent is the AS-RO. By my definition, this model has= two ASs since both are processing requests into tokens. The problem with t= his is complexity and privacy. The RO may not want to share the request inf= ormation with the AS-RS.

    <= /div>
    More= precisely, RO has no choice but to present the required information to AS-= RS if RO wants an access token.=C2=A0 However, RO does not want AS-RS to kn= ow the policy by which RO delegates tokens.=C2=A0 That's why RO uses AS= -RO for those delegations.

    --------------
    Alan Karp


    On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper <agropper@healthurl.com> wrote:




    On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault <fabien.imbault@gmail.com> w= rote:
    Isn't that what the AS is supposed to be, only with the = caveat that the policy is defined locally?=C2=A0

    Fabien=C2=A0


    Le mer. 24 mars 2021 =C3=A0 20:17, Alan = Karp <alanhkarp= @gmail.com> a =C3=A9crit=C2=A0:
    AS-RO is an AS tha= t RO trusts to delegate RO's access tokens according to RO's polici= es.=C2=A0=C2=A0

    --------------Alan Karp


    On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault &= lt;fabien.imbault@gmail.com> wrote:
    Hi Alan and Adrian,
    <= br>
    I've created issue AS-RO policy delegation (https://github.com/ietf-wg-gnap/gnap-core-protocol/i= ssues/223) to capture your input.=C2=A0
    A first question that= arises: can we give a definition to AS-RO?

    Thanks=
    Fabien

    On Tue, Mar 23, 2021 at 4:15 PM Alan Karp <alanh= karp@gmail.com> wrote:
    Fabien Imbault <f= abien.imbault@gmail.com> wrote:
    Hi Alan,=C2=A0

    Y= es, but in that flow, the token relationship between AS-RS and AS-RO is onl= y secure if the tokens issued by AS-RS are cryptographically attenuable in = the first place.=C2=A0
    =C2=A0
    Attenuated delegation is a requirement, but that doesn't hav= e to be done cryptographically.=C2=A0 Token exchange works just fine.=C2=A0= SPKI and zcap-ld are examples of the crypto approach, and we used token ex= change in the system for HP.

    --------------Alan Karp


    On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault &= lt;fabien.imbault@gmail.com> wrote:
    Hi Alan,=C2=A0

    Yes, but in that flow, the token relationship between AS-RS and AS= -RO is only secure if the tokens issued by AS-RS are cryptographically atte= nuable in the first place.=C2=A0

    Fabien

    On Mo= n, Mar 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com> wrote= :
    Justin Richer <= ;jr= icher@mit.edu> wrote:

    But with all that in mind, I think th= e key here is going to be looking at what the inputs to the AS are, and how= those can be defined in an interoperable way for AS=E2=80=99s that can acc= ept them. I think there=E2=80=99s a lot of room for innovation and flexibil= ity here that doesn=E2=80=99t break the trust model or core use cases. If I= have an AS-RS set that won=E2=80=99t accept my favorite flavor of policy e= ngine inputs, then I can decide not to use that one. But this is a very dif= ferent question than saying the RS itself needs to accept my own AS =E2=80= =94 and we can=E2=80=99t keep conflating these two models.

    I agree.=C2=A0 The point of having an AS-RO is = to allow RO to specify a policy for which of RO's access tokens should = be delegated under what conditions.=C2=A0 AS-RS should not need to understa= nd those policies.=C2=A0 The flow would be
    • RO contacts AS= -RS and gets one or more access tokens.
    • RO delegates one or more of= those tokens, potentially sub-scoped, to AS-RO.
    • A different user c= ontacts AS-RO to get a potentially sub-scoped access token from AS-RO.
      • =
    • That user presents the access token delegated by AS-RO when invoking th= e resource.
    AS-RS only needs to verify that the de= legation chain is legitimate, e.g., no increase in scope, and that it grant= s permission for the request being made.=C2=A0 AS-RS does not need to under= stand the policy behind granting the delegation by AS-RO.

    --------------
    Alan Karp


    On Mon, Mar 22, 2021 at= 11:40 AM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    I t= hink this shows the problem with the terminology as it=E2=80=99s been appli= ed in this conversation, which I=E2=80=99ve tried to shine light on before.= What you and others are calling the =E2=80=9CRS=E2=80=9D is really the =E2= =80=9CAS and RS working together=E2=80=9D =E2=80=94 everything to the right= of the line. When Denis had brought up =E2=80=9Celiminating the AS=E2=80= =9D in another thread, what he=E2=80=99d really done is labeled everything = to the right of the line as the =E2=80=9CRS=E2=80=9D. Of course, the irony = here is that everything to the right of the line used all be called the =E2= =80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. A= s you say below, I don=E2=80=99t want the client to have visibility on what= happens on that side.=C2=A0

    Note well: The Google= + logo labeled =E2=80=9CIdP=E2=80=9D in the diagram is not the AS, as far a= s GNAP is concerned. It does not issue an access token that the RS will acc= ept. The elements to the left of the line could be a lot of things, but the= y are NOT the AS =E2=80=94 by definition. The client lives over on the left= , but so do any external inputs to the AS. These could be policy inputs on = behalf of the RO, they could be presentation artifacts, they could be feder= ated logins, they could be the output of policy decisions. How the AS comes= to trust those things is up to the AS=E2=80=99s implementation. It=E2=80= =99s something we can talk about, but ultimately GNAP won=E2=80=99t be in a= ny position to dictate because in practice some AS=E2=80=99s are simply goi= ng to internalize all policies and we will never successfully force those o= pen.=C2=A0

    But with all that in mind, I think the = key here is going to be looking at what the inputs to the AS are, and how t= hose can be defined in an interoperable way for AS=E2=80=99s that can accep= t them. I think there=E2=80=99s a lot of room for innovation and flexibilit= y here that doesn=E2=80=99t break the trust model or core use cases. If I h= ave an AS-RS set that won=E2=80=99t accept my favorite flavor of policy eng= ine inputs, then I can decide not to use that one. But this is a very diffe= rent question than saying the RS itself needs to accept my own AS =E2=80=94= and we can=E2=80=99t keep conflating these two models.

    So to me, GNAP can support a Zero Trust Architecture by LEVERAGING th= e AS, not by subsuming or eliminating it. It is in fact the AS, not the cli= ent and not the RS, that will request and consume the results of a privacy-= preserving zero-trust policy query thing. Anything that happens downstream = from that is of little concern to the zero-trust components because, as you= point out, it=E2=80=99s on the =E2=80=9Cother side=E2=80=9D of the line.= =C2=A0

    I think we got this basic component model p= retty right in OAuth: the AS and RS and client working together. Where OAut= h misses the mark is the assumption that the user has to log in to the AS t= hrough a webpage and interact directly, thereby proving they=E2=80=99re the= RO. It=E2=80=99s this latter space where I think we can both push innovati= on and also address the important and compelling use cases like the ones yo= u=E2=80=99re bringing.

    =C2=A0=E2=80=94 Justin
    <= div>
    On Mar 22, 2021, at 2:14 PM, Adrian = Gropper <agropper@healthurl.com> wrote:

    I'm sorry, Justin. As a Resource Owner, I look at the RS trus= t boundary (the dotted line in the diagram) as being the RS. I don't ex= pect any visibility into what's going on on the=C2=A0right.=C2=A0
    <= br>
    My problem with the framing you propose is that requests are = going to the RS (or the AS-RS) and I don't want to share my policies wi= th the AS-RS. I want to keep the RS and AS-RS as ignorant as possible.

    Adrian

    On Mon, Mar 22, 2021 at 1:48 PM Justin Ric= her <jricher@mit.edu> wrote:
    Adrian,

    What you=E2=80=99re dis= cussing below, in terms of logging in to a site, is not approaching the RS.= You are in fact approaching the client, and identifying both the AS and RS= to the client. The client is a client of your identity in this mode= l, and the RS is part of the identity provider. It=E2=80=99s really importa= nt that we don=E2=80=99t conflate the RS and client in this way as it leads= to a lot of confusion downstream and a lot of broken trust boundaries.

    With that model in mind, approaching the =E2=80=9CRS&= quot; and providing it your identity is really just a case of the =E2=80=9C= federated login to AS=E2=80=9D pattern that we discussed on the WG call. Th= e user here approaches an RS, which has its own AS. To share things from th= is RS, the RO has to authenticate to the RS=E2=80=99s AS. This particular A= S allows the RO to do so using an external identity =E2=80=94 in which case= , the AS is now a =E2=80=9Cclient=E2=80=9D of a separate, disconnected (but= layered) delegation. The ultimate client that eventually calls the RS down= the way may or may not know about these layers.=C2=A0

    =
    <PastedGraphic-1.png>
    This same AS, which is closely tied to the RS and trusted by the RS, might= also take in FIDO credentials, or DIDs, or any number of other proof mecha= nisms. The output of this is an access token the RS trusts, but the input i= s up to the AS. The RS is not what you=E2=80=99re logging in to.
    =
    =C2=A0=E2=80=94 Justin

    On Mar 22, 2021, at 1:28 PM, Adrian Gropper <agropper@healthur= l.com> wrote:

    I too am in favor of av= oiding consolidation and correlation. Right now, when I approach a service = provider (RS) for the first time, I'm offered the opportunity to identi= fy my persona as: email, sign-in with Google, Facebook, or Apple. I know th= ere are people who try to create one-off email addresses but that is mostly= a waste of time.=C2=A0

    So, along come FIDO2 and DID wal= lets to the rescue. Now, in theory, I have a way to start out my RS relatio= nship pseudonymously.=C2=A0

    When I want my resourc= e to be discovered or shared I will post that RS URL including my pseudonym= . If I then want to introduce a mediator=C2=A0in front of my AS or messagin= g service=C2=A0endpoint, I have that option. If I want to keep requests awa= y from the mediator, I would publish an encryption key along with my pseudo= nym.

    - Adrian


    <= /div>
    O= n Mon, Mar 22, 2021 at 9:55 AM Justin Richer <jricher@mit.edu> wrote= :
    On Mar 21, 202= 1, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhkarp@gmail.com> shared a talk about th= e Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomm= ent-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --
    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
    --000000000000e4a50705be53ebc9-- From nobody Wed Mar 24 20:27:01 2021 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 136963A1B5B for ; Wed, 24 Mar 2021 20:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 WjY-tyOZk5mr for ; Wed, 24 Mar 2021 20:26:55 -0700 (PDT) Received: from mail-ua1-f46.google.com (mail-ua1-f46.google.com [209.85.222.46]) (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 ACC653A1B5A for ; Wed, 24 Mar 2021 20:26:55 -0700 (PDT) Received: by mail-ua1-f46.google.com with SMTP id e1so96349uaa.4 for ; Wed, 24 Mar 2021 20:26:55 -0700 (PDT) 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=4U7ozUglXreIIMD9xsGmicxB6GopmT3JYC5Eli2wsV4=; b=Uvwt8zPPS9IidlsK1CcFNVbdd5b20v6iR/BUHmUtnzmS7tWJ71yUtvOo96j0r/B8XH ra3ARCJQ0BCxeMllykQP9YxyiNj0xiy0ucMCHkRRQnZAC/wWjFboc29PlHYYlBcfXILb DZxqw/h/4jnWkJx6Pv+hMcM1xHIeYvdqmLqKdz2SjtjHB2MVpjcBp9E29TN8f78GCGC9 E6nflcyg3M6XNAT6/j2QybfdzUW/83+STd18NQPQ43kjF5TqlyNx976Xb0SHp2cxPZdy ClKP3hd/Lpodq/z5VQSk7jXAfg5cDv1yYkRLZrtDJguDSj70UP2A6LcLFQY4G3irMkyx LBuA== X-Gm-Message-State: AOAM531YL98j5Qe9el2P7p3roes+1xDhFXUNGWuIHoeA0jV8HuywrxOi j3BzbMX/hN71bXzTg+NVws2fvghJCOEs5XuPcnM= X-Google-Smtp-Source: ABdhPJwFAug8hhu3HbvTQiYKQj95perTTkF5xlREcYRrDcww5UMTulxby6kHza/IAUc42hVGkqPvvERqElxTrmvXbE4= X-Received: by 2002:ab0:30a3:: with SMTP id b3mr3648679uam.0.1616642814595; Wed, 24 Mar 2021 20:26:54 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> In-Reply-To: From: Adrian Gropper Date: Wed, 24 Mar 2021 23:26:43 -0400 Message-ID: To: Alan Karp Cc: Benjamin Kaduk , Fabien Imbault , GNAP Mailing List , Justin Richer , Mark Miller Content-Type: multipart/alternative; boundary="000000000000b1574305be53fcb6" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 03:27:00 -0000 --000000000000b1574305be53fcb6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, but I would say it=E2=80=99s not the RO that wants the access token. I= t=E2=80=99s the RO that wants the client making the request to get an access token. Adrian On Wed, Mar 24, 2021 at 11:22 PM Alan Karp wrote: > Adrian Gropper wrote: > >> >> In this design, the AS is the AS-RS and the agent is the AS-RO. By my >> definition, this model has two ASs since both are processing requests in= to >> tokens. The problem with this is complexity and privacy. The RO may not >> want to share the request information with the AS-RS. >> > > More precisely, RO has no choice but to present the required information > to AS-RS if RO wants an access token. However, RO does not want AS-RS to > know the policy by which RO delegates tokens. That's why RO uses AS-RO f= or > those delegations. > > -------------- > Alan Karp > > > On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper > wrote: > >> Thank you for creating the issue. My definition of AS is independent of >> AS-RO or AS-RS. >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomme= nt-806280421 >> I also agree with Alan's definition based on delegation. An AS-RS would = be >> a delegate of the RS. >> >> Based on that, I see it as obvious that the policy has to be accessible >> (defined locally?) in order for it to be run as the code that turns a >> request into an access token. >> >> The only other possibility is that the request is packaged by the AS and >> sent elsewhere (an agent) for evaluation against policy and a proto-toke= n >> returned. In that case the AS is acting as a proxy and the PDP is >> elsewhere. I can imagine that an AS-RS would behave this way so that the >> proto-token could be turned into an access token by the AS-RS. Isn't thi= s >> what Justin is proposing? In this design, the AS is the AS-RS and the ag= ent >> is the AS-RO. By my definition, this model has two ASs since both are >> processing requests into tokens. The problem with this is complexity and >> privacy. The RO may not want to share the request information with the >> AS-RS. >> >> Adrian >> >> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault >> wrote: >> >>> Isn't that what the AS is supposed to be, only with the caveat that the >>> policy is defined locally? >>> >>> Fabien >>> >>> >>> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp a = =C3=A9crit : >>> >>>> AS-RO is an AS that RO trusts to delegate RO's access tokens according >>>> to RO's policies. >>>> >>>> -------------- >>>> Alan Karp >>>> >>>> >>>> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Hi Alan and Adrian, >>>>> >>>>> I've created issue AS-RO policy delegation ( >>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to >>>>> capture your input. >>>>> A first question that arises: can we give a definition to AS-RO? >>>>> >>>>> Thanks >>>>> Fabien >>>>> >>>>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp wrote= : >>>>> >>>>>> Fabien Imbault wrote: >>>>>> >>>>>>> Hi Alan, >>>>>>> >>>>>>> Yes, but in that flow, the token relationship between AS-RS and >>>>>>> AS-RO is only secure if the tokens issued by AS-RS are cryptographi= cally >>>>>>> attenuable in the first place. >>>>>>> >>>>>> >>>>>> Attenuated delegation is a requirement, but that doesn't have to be >>>>>> done cryptographically. Token exchange works just fine. SPKI and z= cap-ld >>>>>> are examples of the crypto approach, and we used token exchange in t= he >>>>>> system for HP. >>>>>> >>>>>> -------------- >>>>>> Alan Karp >>>>>> >>>>>> >>>>>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>>> Hi Alan, >>>>>>> >>>>>>> Yes, but in that flow, the token relationship between AS-RS and >>>>>>> AS-RO is only secure if the tokens issued by AS-RS are cryptographi= cally >>>>>>> attenuable in the first place. >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp >>>>>>> wrote: >>>>>>> >>>>>>>> Justin Richer wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> But with all that in mind, I think the key here is going to be >>>>>>>>> looking at what the inputs to the AS are, and how those can be de= fined in >>>>>>>>> an interoperable way for AS=E2=80=99s that can accept them. I thi= nk there=E2=80=99s a lot >>>>>>>>> of room for innovation and flexibility here that doesn=E2=80=99t = break the trust >>>>>>>>> model or core use cases. If I have an AS-RS set that won=E2=80=99= t accept my >>>>>>>>> favorite flavor of policy engine inputs, then I can decide not to= use that >>>>>>>>> one. But this is a very different question than saying the RS its= elf needs >>>>>>>>> to accept my own AS =E2=80=94 and we can=E2=80=99t keep conflatin= g these two models. >>>>>>>>> >>>>>>>>> I agree. The point of having an AS-RO is to allow RO to specify = a >>>>>>>> policy for which of RO's access tokens should be delegated under w= hat >>>>>>>> conditions. AS-RS should not need to understand those policies. = The flow >>>>>>>> would be >>>>>>>> >>>>>>>> - RO contacts AS-RS and gets one or more access tokens. >>>>>>>> - RO delegates one or more of those tokens, potentially >>>>>>>> sub-scoped, to AS-RO. >>>>>>>> - A different user contacts AS-RO to get a potentially >>>>>>>> sub-scoped access token from AS-RO. >>>>>>>> - That user presents the access token delegated by AS-RO when >>>>>>>> invoking the resource. >>>>>>>> >>>>>>>> AS-RS only needs to verify that the delegation chain is legitimate= , >>>>>>>> e.g., no increase in scope, and that it grants permission for the = request >>>>>>>> being made. AS-RS does not need to understand the policy behind g= ranting >>>>>>>> the delegation by AS-RO. >>>>>>>> >>>>>>>> -------------- >>>>>>>> Alan Karp >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Adrian, >>>>>>>>> >>>>>>>>> I think this shows the problem with the terminology as it=E2=80= =99s been >>>>>>>>> applied in this conversation, which I=E2=80=99ve tried to shine l= ight on before. >>>>>>>>> What you and others are calling the =E2=80=9CRS=E2=80=9D is reall= y the =E2=80=9CAS and RS working >>>>>>>>> together=E2=80=9D =E2=80=94 everything to the right of the line. = When Denis had brought up >>>>>>>>> =E2=80=9Celiminating the AS=E2=80=9D in another thread, what he= =E2=80=99d really done is labeled >>>>>>>>> everything to the right of the line as the =E2=80=9CRS=E2=80=9D. = Of course, the irony here >>>>>>>>> is that everything to the right of the line used all be called th= e =E2=80=9CAS=E2=80=9D or >>>>>>>>> simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say b= elow, I don=E2=80=99t want the >>>>>>>>> client to have visibility on what happens on that side. >>>>>>>>> >>>>>>>>> Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the = diagram is not >>>>>>>>> the AS, as far as GNAP is concerned. It does not issue an access = token that >>>>>>>>> the RS will accept. The elements to the left of the line could be= a lot of >>>>>>>>> things, but they are NOT the AS =E2=80=94 by definition. The clie= nt lives over on >>>>>>>>> the left, but so do any external inputs to the AS. These could be= policy >>>>>>>>> inputs on behalf of the RO, they could be presentation artifacts,= they >>>>>>>>> could be federated logins, they could be the output of policy dec= isions. >>>>>>>>> How the AS comes to trust those things is up to the AS=E2=80=99s = implementation. >>>>>>>>> It=E2=80=99s something we can talk about, but ultimately GNAP won= =E2=80=99t be in any >>>>>>>>> position to dictate because in practice some AS=E2=80=99s are sim= ply going to >>>>>>>>> internalize all policies and we will never successfully force tho= se open. >>>>>>>>> >>>>>>>>> But with all that in mind, I think the key here is going to be >>>>>>>>> looking at what the inputs to the AS are, and how those can be de= fined in >>>>>>>>> an interoperable way for AS=E2=80=99s that can accept them. I thi= nk there=E2=80=99s a lot >>>>>>>>> of room for innovation and flexibility here that doesn=E2=80=99t = break the trust >>>>>>>>> model or core use cases. If I have an AS-RS set that won=E2=80=99= t accept my >>>>>>>>> favorite flavor of policy engine inputs, then I can decide not to= use that >>>>>>>>> one. But this is a very different question than saying the RS its= elf needs >>>>>>>>> to accept my own AS =E2=80=94 and we can=E2=80=99t keep conflatin= g these two models. >>>>>>>>> >>>>>>>>> So to me, GNAP can support a Zero Trust Architecture by LEVERAGIN= G >>>>>>>>> the AS, not by subsuming or eliminating it. It is in fact the AS,= not the >>>>>>>>> client and not the RS, that will request and consume the results = of a >>>>>>>>> privacy-preserving zero-trust policy query thing. Anything that h= appens >>>>>>>>> downstream from that is of little concern to the zero-trust compo= nents >>>>>>>>> because, as you point out, it=E2=80=99s on the =E2=80=9Cother sid= e=E2=80=9D of the line. >>>>>>>>> >>>>>>>>> I think we got this basic component model pretty right in OAuth: >>>>>>>>> the AS and RS and client working together. Where OAuth misses the= mark is >>>>>>>>> the assumption that the user has to log in to the AS through a we= bpage and >>>>>>>>> interact directly, thereby proving they=E2=80=99re the RO. It=E2= =80=99s this latter space >>>>>>>>> where I think we can both push innovation and also address the im= portant >>>>>>>>> and compelling use cases like the ones you=E2=80=99re bringing. >>>>>>>>> >>>>>>>>> =E2=80=94 Justin >>>>>>>>> >>>>>>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper < >>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>> >>>>>>>>> I'm sorry, Justin. As a Resource Owner, I look at the RS trust >>>>>>>>> boundary (the dotted line in the diagram) as being the RS. I don'= t expect >>>>>>>>> any visibility into what's going on on the right. >>>>>>>>> >>>>>>>>> My problem with the framing you propose is that requests are goin= g >>>>>>>>> to the RS (or the AS-RS) and I don't want to share my policies wi= th the >>>>>>>>> AS-RS. I want to keep the RS and AS-RS as ignorant as possible. >>>>>>>>> >>>>>>>>> Adrian >>>>>>>>> >>>>>>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Adrian, >>>>>>>>>> >>>>>>>>>> What you=E2=80=99re discussing below, in terms of logging in to = a site, >>>>>>>>>> is not approaching the RS. You are in fact approaching the clien= t, and >>>>>>>>>> identifying both the AS and RS to the client. The client is a cl= ient *of >>>>>>>>>> your identity* in this model, and the RS is part of the identity >>>>>>>>>> provider. It=E2=80=99s really important that we don=E2=80=99t co= nflate the RS and client in >>>>>>>>>> this way as it leads to a lot of confusion downstream and a lot = of broken >>>>>>>>>> trust boundaries. >>>>>>>>>> >>>>>>>>>> With that model in mind, approaching the =E2=80=9CRS" and provid= ing it >>>>>>>>>> your identity is really just a case of the =E2=80=9Cfederated lo= gin to AS=E2=80=9D pattern >>>>>>>>>> that we discussed on the WG call. The user here approaches an RS= , which has >>>>>>>>>> its own AS. To share things from this RS, the RO has to authenti= cate to the >>>>>>>>>> RS=E2=80=99s AS. This particular AS allows the RO to do so using= an external >>>>>>>>>> identity =E2=80=94 in which case, the AS is now a =E2=80=9Cclien= t=E2=80=9D of a separate, >>>>>>>>>> disconnected (but layered) delegation. The ultimate client that = eventually >>>>>>>>>> calls the RS down the way may or may not know about these layers= . >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This same AS, which is closely tied to the RS and trusted by the >>>>>>>>>> RS, might also take in FIDO credentials, or DIDs, or any number = of other >>>>>>>>>> proof mechanisms. The output of this is an access token the RS t= rusts, but >>>>>>>>>> the input is up to the AS. The RS is not what you=E2=80=99re log= ging in to. >>>>>>>>>> >>>>>>>>>> =E2=80=94 Justin >>>>>>>>>> >>>>>>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper < >>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>> >>>>>>>>>> I too am in favor of avoiding consolidation and correlation. >>>>>>>>>> Right now, when I approach a service provider (RS) for the first= time, I'm >>>>>>>>>> offered the opportunity to identify my persona as: email, sign-i= n with >>>>>>>>>> Google, Facebook, or Apple. I know there are people who try to c= reate >>>>>>>>>> one-off email addresses but that is mostly a waste of time. >>>>>>>>>> >>>>>>>>>> So, along come FIDO2 and DID wallets to the rescue. Now, in >>>>>>>>>> theory, I have a way to start out my RS relationship pseudonymou= sly. >>>>>>>>>> >>>>>>>>>> When I want my resource to be discovered or shared I will post >>>>>>>>>> that RS URL including my pseudonym. If I then want to introduce = a >>>>>>>>>> mediator in front of my AS or messaging service endpoint, I have= that >>>>>>>>>> option. If I want to keep requests away from the mediator, I wou= ld publish >>>>>>>>>> an encryption key along with my pseudonym. >>>>>>>>>> >>>>>>>>>> - Adrian >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk >>>>>>>>>>> wrote: >>>>>>>>>>> > >>>>>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrot= e: >>>>>>>>>>> >> @Alan Karp shared a talk about the >>>>>>>>>>> Principle Of Least >>>>>>>>>>> >> Authority (POLA) in a recent comment >>>>>>>>>>> >> >>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#i= ssuecomment-803099693 >>>>>>>>>>> >> I recommend it. >>>>>>>>>>> >> >>>>>>>>>>> >> We might expect a protocol with authorization in the title t= o >>>>>>>>>>> use authority >>>>>>>>>>> >> as a core principle. I advocate for a GNAP design that >>>>>>>>>>> maximizes the power >>>>>>>>>>> >> of the RO, to be seen as a human rights issue when the RO is >>>>>>>>>>> a human. This >>>>>>>>>>> >> causes me to ask how to combine better security with better >>>>>>>>>>> human rights in >>>>>>>>>>> >> GNAP. >>>>>>>>>>> >> >>>>>>>>>>> >> Who should have the least authority in the GNAP design? >>>>>>>>>>> >> >>>>>>>>>>> >> The AS derives authority as a delegate of the RO. If we ask >>>>>>>>>>> the RO to >>>>>>>>>>> >> partition limited authority across dozens of different ASs b= y >>>>>>>>>>> domain and >>>>>>>>>>> >> function, then we are not using technology to empower the >>>>>>>>>>> individual. >>>>>>>>>>> >> Probably the opposite, as we introduce consent fatigue and >>>>>>>>>>> burden normal >>>>>>>>>>> >> people to partition their lives into non-overlapping domains= . >>>>>>>>>>> >> >>>>>>>>>>> >> My experience says we should aim for one AS per persona >>>>>>>>>>> because that maps >>>>>>>>>>> >> into the way we manage our public and private identities. >>>>>>>>>>> POLA would then >>>>>>>>>>> >> teach care in keeping ASs and RSs related to work / public >>>>>>>>>>> separate from >>>>>>>>>>> >> ASs and RSs related to private life so that a policy >>>>>>>>>>> vulnerability in our >>>>>>>>>>> >> delegation to an AS would have the least likelihood of harm. >>>>>>>>>>> > >>>>>>>>>>> > Thinking about how least authority/least privilege would appl= y >>>>>>>>>>> to GNAP >>>>>>>>>>> > seems like a useful exercise. I do want to point out some >>>>>>>>>>> potential >>>>>>>>>>> > pitfalls with one-AS-per-persona that we can also be aware >>>>>>>>>>> of. If >>>>>>>>>>> > one-AS-per-persona becomes one-persona-per-AS as well, then >>>>>>>>>>> the AS's >>>>>>>>>>> > identity in effect also serves as a persona identity and ther= e >>>>>>>>>>> are privacy >>>>>>>>>>> > considerations to that. If, on the other hand, the >>>>>>>>>>> > multiple-personas-per-AS (presumably corresponding to multipl= e >>>>>>>>>>> humans) >>>>>>>>>>> > route is taken, we should consider whether that would lead to >>>>>>>>>>> various >>>>>>>>>>> > (e.g., market) forces driving consolidation to just a handful >>>>>>>>>>> of >>>>>>>>>>> > super-popular AS services. That topic is a current matter of >>>>>>>>>>> concern to >>>>>>>>>>> > some IETF participants. >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> Hi Ben, big +1 to this. This is something that we discussed age= s >>>>>>>>>>> ago in the UMA working group, and it=E2=80=99s one of the bigge= st problems with the >>>>>>>>>>> personal AS (and personal data store) model. This kind of thing= makes >>>>>>>>>>> RS-first trust models really difficult in practice. >>>>>>>>>>> >>>>>>>>>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve got software= that wants to >>>>>>>>>>> access my medical information. It calls an RS and requests acce= ss, but it >>>>>>>>>>> hasn=E2=80=99t been granted anything yet. Now I as the RO have = set up the RS so >>>>>>>>>>> that it talks to my personal AS, that only I use. In addition t= o the RS >>>>>>>>>>> having to be able to figure out which medical records are being= requested >>>>>>>>>>> from the context of the unauthenticated request (which means it= needs >>>>>>>>>>> identifiers in the URL or something similar for the RS to be ab= le to tell, >>>>>>>>>>> assuming that it protects data for more than one person). So th= is client >>>>>>>>>>> software doesn=E2=80=99t know who I am and doesn=E2=80=99t know= my medical record >>>>>>>>>>> information, makes a completely unauthorized request to the RS,= and the RS >>>>>>>>>>> says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token= =E2=80=9D. The client can now make a >>>>>>>>>>> direct correlation between the data that=E2=80=99s being protec= ted at the RS and >>>>>>>>>>> the person running the AS that protects it. Importantly, this c= lient makes >>>>>>>>>>> this call with no prior relationship to the RS and no really au= ditable way >>>>>>>>>>> to track it down after the fact. This is a design feature in th= e good case, >>>>>>>>>>> and terrifying in the bad case. >>>>>>>>>>> >>>>>>>>>>> If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, = please >>>>>>>>>>> talk to the Medicine Doctor AS to get access=E2=80=9D, we haven= =E2=80=99t exposed anything >>>>>>>>>>> at all. And from the perspective of both the patient and the RS= , this is >>>>>>>>>>> more privacy-preserving, and it=E2=80=99s really the least surp= rising option. Once >>>>>>>>>>> the client gets to the AS, it can start a negotiation of figuri= ng out who >>>>>>>>>>> the RO is for the information being accessed. >>>>>>>>>>> >>>>>>>>>>> On top of this, the usability expectations of people managing >>>>>>>>>>> their own AS, or set of AS=E2=80=99s for multiple personas to k= eep things separate, >>>>>>>>>>> is a huge burden. Even in the tech community, I know people who= can=E2=80=99t >>>>>>>>>>> reliably manage more than one email address for different purpo= ses. I >>>>>>>>>>> wouldn=E2=80=99t expect my partner to do that =E2=80=94 they ha= ve trouble enough balancing >>>>>>>>>>> all the logins and sessions required for different kids remote = schooling, I >>>>>>>>>>> couldn=E2=80=99t imagine them having to understand all the requ= irements for >>>>>>>>>>> managing multiple authorization servers and associated policies= . I also >>>>>>>>>>> don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80= =9D =E2=80=94 I=E2=80=99ve been on the internet for >>>>>>>>>>> decades and I can barely keep tabs on my GPG keys, and only use= them when I >>>>>>>>>>> am forced to. This is exactly the kind of =E2=80=9Cmarket press= ure=E2=80=9D that I think >>>>>>>>>>> Ben mentions above, people will just want to outsource that to = someone >>>>>>>>>>> else, and the reality will be a few popular providers. >>>>>>>>>>> >>>>>>>>>>> In which case, we could end up doing a ton of work to allow an >>>>>>>>>>> RS choice only to end up with a world where the RS ends up maki= ng a limited >>>>>>>>>>> choice anyway. We see how that plays out with OpenID Connect = =E2=80=94 RP=E2=80=99s could >>>>>>>>>>> allow arbitrary IdPs but they choose Google because it works an= d that=E2=80=99s >>>>>>>>>>> where the users are. (And that=E2=80=99s not to say anything of= the proprietary >>>>>>>>>>> OIDC-like protocols, but that=E2=80=99s another discussion). >>>>>>>>>>> >>>>>>>>>>> For further reading on these topics, I recommend both =E2=80=9C= Why >>>>>>>>>>> Johnny Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Sys= tems Fail=E2=80=9D. >>>>>>>>>>> >>>>>>>>>>> So what does this have to do with GNAP? I think we can be >>>>>>>>>>> clear-eyed on what kinds of expectations we have for the partic= ipants. If >>>>>>>>>>> we expect users (RO=E2=80=99s) to have to set up the AS-RS rela= tionship, or expect >>>>>>>>>>> them to carry their AS, or manage their personal keys =E2=80=94= I think we=E2=80=99ve lost >>>>>>>>>>> the battle for relevance. >>>>>>>>>>> >>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> -- >>>>>>>> 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 > --000000000000b1574305be53fcb6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Yes, but I would say it=E2=80=99s not the RO that wants t= he access token. It=E2=80=99s the RO that wants the client making the reque= st to get an access token.=C2=A0

    Adrian

    On Wed, Mar 24, 2021 at 11:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Adrian Gropper <agropper@healthurl.com> wrote:
    =

    In this design, the AS is the AS-RS and the a= gent is the AS-RO. By my definition, this model has two ASs since both are = processing requests into tokens. The problem with this is complexity and pr= ivacy. The RO may not want to share the request information with the AS-RS.=

    More pr= ecisely, RO has no choice but to present the required information to AS-RS = if RO wants an access token.=C2=A0 However, RO does not want AS-RS to know = the policy by which RO delegates tokens.=C2=A0 That's why RO uses AS-RO= for those delegations.

    --------------
    Alan Karp


    On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper <agropper@healthurl.com> wrote= :
    Thank you for creating the issue. My definition of AS i= s independent of AS-RO or AS-RS.=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomme= nt-806280421 I also agree with Alan's definition based on delegatio= n. An AS-RS would be a delegate of the RS.=C2=A0

    =
    Based on that, I see it as obvious=C2=A0that the policy has to b= e accessible (defined locally?) in order for it to be run as the code that = turns a request into an access token.=C2=A0

    The on= ly other possibility is that the request is packaged by the AS and sent els= ewhere (an agent) for evaluation against policy and a proto-token returned.= In that case the AS is acting as a proxy and the PDP is elsewhere. I can i= magine that an AS-RS would behave this way so that the proto-token could be= turned into an access token by the AS-RS. Isn't this what Justin is pr= oposing? In this design, the AS is the AS-RS and the agent is the AS-RO. By= my definition, this model has two ASs since both are processing requests i= nto tokens. The problem with this is complexity and privacy. The RO may not= want to share the request information with the AS-RS.

    =
    Adrian

    On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault <fabien.imbault@gmail= .com> wrote:
    Isn't that what the AS is supposed to be, on= ly with the caveat that the policy is defined locally?=C2=A0

    Fabien=C2=A0


    Le mer. 24 mars 2021 =C3=A0 = 20:17, Alan Karp <alanhkarp@gmail.com> a =C3=A9crit=C2=A0:
    AS-RO = is an AS that RO trusts to delegate RO's access tokens according to RO&= #39;s policies.=C2=A0=C2=A0

    ----= ----------
    Alan Karp


    On Wed, Mar 24, 2021 at 9:36 AM Fabi= en Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan and A= drian,

    I've created issue AS-RO policy delegation (<= a href=3D"https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223" re= l=3D"noreferrer" target=3D"_blank">https://github.com/ietf-wg-gnap/gnap-cor= e-protocol/issues/223) to capture your input.=C2=A0
    A first q= uestion that arises: can we give a definition to AS-RO?

    Thanks
    Fabien

    On Tue, Mar 23, 2021 at 4:15 PM Alan Kar= p <alanhkarp@gmail.com> wrote:
    Fabien Imbault <= ;fabien.imbault@gmail.com> wrote:
    Hi Alan,=C2=A0

    Yes, but in that flow, the token relationship between AS-RS and AS= -RO is only secure if the tokens issued by AS-RS are cryptographically atte= nuable in the first place.=C2=A0
    =C2=A0
    <= div>
    Attenuated delegation is a requirement, but that doesn= 't have to be done cryptographically.=C2=A0 Token exchange works just f= ine.=C2=A0 SPKI and zcap-ld are examples of the crypto approach, and we use= d token exchange in the system for HP.

    ------= --------
    Alan Karp


    <= div dir=3D"ltr" class=3D"gmail_attr">On Tue, Mar 23, 2021 at 4:12 AM Fabien= Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan,=C2=A0<= div>
    Yes, but in that flow, the token relationship between AS= -RS and AS-RO is only secure if the tokens issued by AS-RS are cryptographi= cally attenuable in the first place.=C2=A0

    Fabien<= /div>

    On Mon, Mar 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com= > wrote:
    Justin = Richer <jricher@mit.edu> wrote:

    But with all that in mind, = I think the key here is going to be looking at what the inputs to the AS ar= e, and how those can be defined in an interoperable way for AS=E2=80=99s th= at can accept them. I think there=E2=80=99s a lot of room for innovation an= d flexibility here that doesn=E2=80=99t break the trust model or core use c= ases. If I have an AS-RS set that won=E2=80=99t accept my favorite flavor o= f policy engine inputs, then I can decide not to use that one. But this is = a very different question than saying the RS itself needs to accept my own = AS =E2=80=94 and we can=E2=80=99t keep conflating these two models.

    I agree.=C2=A0 The point of having an = AS-RO is to allow RO to specify a policy for which of RO's access token= s should be delegated under what conditions.=C2=A0 AS-RS should not need to= understand those policies.=C2=A0 The flow would be
    • RO co= ntacts AS-RS and gets one or more access tokens.
    • RO delegates one o= r more of those tokens, potentially sub-scoped, to AS-RO.
    • A differe= nt user contacts AS-RO to get a potentially sub-scoped access token from AS= -RO.
    • That user presents the access token delegated by AS-RO when in= voking the resource.
    AS-RS only needs to verify th= at the delegation chain is legitimate, e.g., no increase in scope, and that= it grants permission for the request being made.=C2=A0 AS-RS does not need= to understand the policy behind granting the delegation by AS-RO.

    --------------
    Alan Karp


    On Mon, Mar 22= , 2021 at 11:40 AM Justin Richer <jricher@mit.edu> 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">
    Adrian,

    I think this shows the problem with the terminology as it=E2=80=99s b= een applied in this conversation, which I=E2=80=99ve tried to shine light o= n before. What you and others are calling the =E2=80=9CRS=E2=80=9D is reall= y the =E2=80=9CAS and RS working together=E2=80=9D =E2=80=94 everything to = the right of the line. When Denis had brought up =E2=80=9Celiminating the A= S=E2=80=9D in another thread, what he=E2=80=99d really done is labeled ever= ything to the right of the line as the =E2=80=9CRS=E2=80=9D. Of course, the= irony here is that everything to the right of the line used all be called = the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 = days. As you say below, I don=E2=80=99t want the client to have visibility = on what happens on that side.=C2=A0

    Note well: The= Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the diagram is not the AS, a= s far as GNAP is concerned. It does not issue an access token that the RS w= ill accept. The elements to the left of the line could be a lot of things, = but they are NOT the AS =E2=80=94 by definition. The client lives over on t= he left, but so do any external inputs to the AS. These could be policy inp= uts on behalf of the RO, they could be presentation artifacts, they could b= e federated logins, they could be the output of policy decisions. How the A= S comes to trust those things is up to the AS=E2=80=99s implementation. It= =E2=80=99s something we can talk about, but ultimately GNAP won=E2=80=99t b= e in any position to dictate because in practice some AS=E2=80=99s are simp= ly going to internalize all policies and we will never successfully force t= hose open.=C2=A0

    But with all that in mind, I thin= k the key here is going to be looking at what the inputs to the AS are, and= how those can be defined in an interoperable way for AS=E2=80=99s that can= accept them. I think there=E2=80=99s a lot of room for innovation and flex= ibility here that doesn=E2=80=99t break the trust model or core use cases. = If I have an AS-RS set that won=E2=80=99t accept my favorite flavor of poli= cy engine inputs, then I can decide not to use that one. But this is a very= different question than saying the RS itself needs to accept my own AS =E2= =80=94 and we can=E2=80=99t keep conflating these two models.
    So to me, GNAP can support a Zero Trust Architecture by LEVERAG= ING the AS, not by subsuming or eliminating it. It is in fact the AS, not t= he client and not the RS, that will request and consume the results of a pr= ivacy-preserving zero-trust policy query thing. Anything that happens downs= tream from that is of little concern to the zero-trust components because, = as you point out, it=E2=80=99s on the =E2=80=9Cother side=E2=80=9D of the l= ine.=C2=A0

    I think we got this basic component mod= el pretty right in OAuth: the AS and RS and client working together. Where = OAuth misses the mark is the assumption that the user has to log in to the = AS through a webpage and interact directly, thereby proving they=E2=80=99re= the RO. It=E2=80=99s this latter space where I think we can both push inno= vation and also address the important and compelling use cases like the one= s you=E2=80=99re bringing.

    =C2=A0=E2=80=94 Justin<= br>

    On Mar 22, 2021, at 2:14 PM, Adr= ian Gropper <agropper@healthurl.com> wrote:

    I'm sorry, Justin. As a Resource Owner, I look at the RS = trust boundary (the dotted line in the diagram) as being the RS. I don'= t expect any visibility into what's going on on the=C2=A0right.=C2=A0
    My problem with the framing you propose is that requests = are going to the RS (or the AS-RS) and I don't want to share my policie= s with the AS-RS. I want to keep the RS and AS-RS as ignorant as possible.<= /div>

    Adrian

    <= div dir=3D"ltr" class=3D"gmail_attr">On Mon, Mar 22, 2021 at 1:48 PM Justin= Richer <jricher@mit.edu> wrote:
    Adrian,

    What you=E2=80=99re= discussing below, in terms of logging in to a site, is not approaching the= RS. You are in fact approaching the client, and identifying both the AS an= d RS to the client. The client is a client of your identity in this = model, and the RS is part of the identity provider. It=E2=80=99s really imp= ortant that we don=E2=80=99t conflate the RS and client in this way as it l= eads to a lot of confusion downstream and a lot of broken trust boundaries.=

    With that model in mind, approaching the =E2=80= =9CRS" and providing it your identity is really just a case of the =E2= =80=9Cfederated login to AS=E2=80=9D pattern that we discussed on the WG ca= ll. The user here approaches an RS, which has its own AS. To share things f= rom this RS, the RO has to authenticate to the RS=E2=80=99s AS. This partic= ular AS allows the RO to do so using an external identity =E2=80=94 in whic= h case, the AS is now a =E2=80=9Cclient=E2=80=9D of a separate, disconnecte= d (but layered) delegation. The ultimate client that eventually calls the R= S down the way may or may not know about these layers.=C2=A0

    =
    <PastedGraphic= -1.png>
    This same AS, which is closely tied to the RS a= nd trusted by the RS, might also take in FIDO credentials, or DIDs, or any = number of other proof mechanisms. The output of this is an access token the= RS trusts, but the input is up to the AS. The RS is not what you=E2=80=99r= e logging in to.

    =C2=A0=E2=80=94 Justin
    On Mar 22, 2021, at 1:28 PM, Adrian Groppe= r <agropper@healthurl.com> wrote:

    I too am in favor of avoiding consolidation and correlation. Right no= w, when I approach a service provider (RS) for the first time, I'm offe= red the opportunity to identify my persona as: email, sign-in with Google, = Facebook, or Apple. I know there are people who try to create one-off email= addresses but that is mostly a waste of time.=C2=A0

    So,= along come FIDO2 and DID wallets to the rescue. Now, in theory, I have a w= ay to start out my RS relationship pseudonymously.=C2=A0

    When I want my resource to be discovered or shared I will post that = RS URL including my pseudonym. If I then want to introduce a mediator=C2=A0= in front of my AS or messaging service=C2=A0endpoint, I have that option. I= f I want to keep requests away from the mediator, I would publish an encryp= tion key along with my pseudonym.

    - Adrian



    On Mon, Mar 22, 2021 at 9:55 AM Justin Richer= <jricher@mit.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <    alanhkarp@gmail.com> shared a talk about th= e Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomm= ent-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --
    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
    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --000000000000b1574305be53fcb6-- From nobody Wed Mar 24 23:59:30 2021 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 6B2B53A12CD for ; Wed, 24 Mar 2021 23:59: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, 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 XjfalVEOOw6l for ; Wed, 24 Mar 2021 23:59:24 -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 894013A12CC for ; Wed, 24 Mar 2021 23:59:24 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id x17so903554iog.2 for ; Wed, 24 Mar 2021 23:59:24 -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=7vBv73g9x0Vt3yMlKNkcNmSmYZSGEqp9Q+EP9rUgUks=; b=GagxdhvV/oO5d+UqqKZvrSkp+ekUa5cROXvR3tDaRGEM2s6yN+mdi9T3nu0wffzOSL QProRbUNChLY6sHhTohg3BxJ1hDTk/V/bW6R7zMVCtrxnKjGt98smxZkcbBpmA5Wohu8 KusVRKU9bFevGr8vBwMGpXPTYzPac6iI1VpNjce74FEmZSwzLuZjPfumMAVAPUoZvKnY OCWpYLLr8QT+ZtGz8ti5a3tDy3kkt28Rt1ikBmtc80uz1UqpiXFUu1Yl0915LEzBTlYb iY4buhEead/cgjHw0nfjazey7LQO1R1WA6Yvr6MUKtnFrBZdoArQa+VuwiMfyJBVbsEA lu7Q== 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=7vBv73g9x0Vt3yMlKNkcNmSmYZSGEqp9Q+EP9rUgUks=; b=kqwVmS9Fi4Xg9sfB+DNEoQJNQRiGqAytE9xFeffS7H+BmdcsDWCm5ZVrYQfJZLXTBy AUwjEzkCpGlNwIJl38HdLUkW2EeA2IAoG64cTJO6XbDOV6uR39LzCQaQ9jzO9HEJU9j0 jH/vXSC1cKX2k1jFqLDy7KFSPrKNkO8hRT5+u1QqUE9uearqawPH5EROu1OvA0+G4SwC 5ltZLqP4Or3P1SRK2bYACOGDUGqaRH4sRATVw8isIvtIutWNvOsMnFnflfcLXFrsQhm9 ZhHTu2/RGXYxKzqqSb7UsprJHD874+EjwNxlIJbqNTKtDIqpxcliycZZjy8QNg8rORJl 874A== X-Gm-Message-State: AOAM530F9Aojh5RVYbzpoZGe8KCvaPZk4IEjHmg/y16+IJVCcgxw6S0E dvzE9l1u8uelOa9MKdgs8abRKyyUeQfKplQJNgQ= X-Google-Smtp-Source: ABdhPJwPrG5xrKPQ64SLgo3Hd2Da5BLdOHw2TIMpAw8Q6b9g5SLyLRE5cHY73c0G1UX2SIdlRXbjoQ5GabRHU6ngz78= X-Received: by 2002:a6b:5818:: with SMTP id m24mr5089005iob.144.1616655562659; Wed, 24 Mar 2021 23:59:22 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> In-Reply-To: From: Fabien Imbault Date: Thu, 25 Mar 2021 07:59:09 +0100 Message-ID: To: Adrian Gropper Cc: Alan Karp , Benjamin Kaduk , GNAP Mailing List , Justin Richer , Mark Miller Content-Type: multipart/alternative; boundary="000000000000895d2505be56f4b0" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 06:59:30 -0000 --000000000000895d2505be56f4b0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Isn't the AS-RO a component of the AS? Same idea as the interact component, it functionnally belongs to the AS role but could be deployed either as a monolith or as a separate component? Fabien Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper = a =C3=A9crit : > Yes, but I would say it=E2=80=99s not the RO that wants the access token.= It=E2=80=99s the > RO that wants the client making the request to get an access token. > > Adrian > > On Wed, Mar 24, 2021 at 11:22 PM Alan Karp wrote: > >> Adrian Gropper wrote: >> >>> >>> In this design, the AS is the AS-RS and the agent is the AS-RO. By my >>> definition, this model has two ASs since both are processing requests i= nto >>> tokens. The problem with this is complexity and privacy. The RO may not >>> want to share the request information with the AS-RS. >>> >> >> More precisely, RO has no choice but to present the required information >> to AS-RS if RO wants an access token. However, RO does not want AS-RS t= o >> know the policy by which RO delegates tokens. That's why RO uses AS-RO = for >> those delegations. >> >> -------------- >> Alan Karp >> >> >> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper >> wrote: >> >>> Thank you for creating the issue. My definition of AS is independent of >>> AS-RO or AS-RS. >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomm= ent-806280421 >>> I also agree with Alan's definition based on delegation. An AS-RS would= be >>> a delegate of the RS. >>> >>> Based on that, I see it as obvious that the policy has to be accessible >>> (defined locally?) in order for it to be run as the code that turns a >>> request into an access token. >>> >>> The only other possibility is that the request is packaged by the AS an= d >>> sent elsewhere (an agent) for evaluation against policy and a proto-tok= en >>> returned. In that case the AS is acting as a proxy and the PDP is >>> elsewhere. I can imagine that an AS-RS would behave this way so that th= e >>> proto-token could be turned into an access token by the AS-RS. Isn't th= is >>> what Justin is proposing? In this design, the AS is the AS-RS and the a= gent >>> is the AS-RO. By my definition, this model has two ASs since both are >>> processing requests into tokens. The problem with this is complexity an= d >>> privacy. The RO may not want to share the request information with the >>> AS-RS. >>> >>> Adrian >>> >>> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault >>> wrote: >>> >>>> Isn't that what the AS is supposed to be, only with the caveat that th= e >>>> policy is defined locally? >>>> >>>> Fabien >>>> >>>> >>>> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp a = =C3=A9crit : >>>> >>>>> AS-RO is an AS that RO trusts to delegate RO's access tokens accordin= g >>>>> to RO's policies. >>>>> >>>>> -------------- >>>>> Alan Karp >>>>> >>>>> >>>>> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Hi Alan and Adrian, >>>>>> >>>>>> I've created issue AS-RO policy delegation ( >>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to >>>>>> capture your input. >>>>>> A first question that arises: can we give a definition to AS-RO? >>>>>> >>>>>> Thanks >>>>>> Fabien >>>>>> >>>>>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp >>>>>> wrote: >>>>>> >>>>>>> Fabien Imbault wrote: >>>>>>> >>>>>>>> Hi Alan, >>>>>>>> >>>>>>>> Yes, but in that flow, the token relationship between AS-RS and >>>>>>>> AS-RO is only secure if the tokens issued by AS-RS are cryptograph= ically >>>>>>>> attenuable in the first place. >>>>>>>> >>>>>>> >>>>>>> Attenuated delegation is a requirement, but that doesn't have to be >>>>>>> done cryptographically. Token exchange works just fine. SPKI and = zcap-ld >>>>>>> are examples of the crypto approach, and we used token exchange in = the >>>>>>> system for HP. >>>>>>> >>>>>>> -------------- >>>>>>> Alan Karp >>>>>>> >>>>>>> >>>>>>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>> >>>>>>>> Hi Alan, >>>>>>>> >>>>>>>> Yes, but in that flow, the token relationship between AS-RS and >>>>>>>> AS-RO is only secure if the tokens issued by AS-RS are cryptograph= ically >>>>>>>> attenuable in the first place. >>>>>>>> >>>>>>>> Fabien >>>>>>>> >>>>>>>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Justin Richer wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> But with all that in mind, I think the key here is going to be >>>>>>>>>> looking at what the inputs to the AS are, and how those can be d= efined in >>>>>>>>>> an interoperable way for AS=E2=80=99s that can accept them. I th= ink there=E2=80=99s a lot >>>>>>>>>> of room for innovation and flexibility here that doesn=E2=80=99t= break the trust >>>>>>>>>> model or core use cases. If I have an AS-RS set that won=E2=80= =99t accept my >>>>>>>>>> favorite flavor of policy engine inputs, then I can decide not t= o use that >>>>>>>>>> one. But this is a very different question than saying the RS it= self needs >>>>>>>>>> to accept my own AS =E2=80=94 and we can=E2=80=99t keep conflati= ng these two models. >>>>>>>>>> >>>>>>>>>> I agree. The point of having an AS-RO is to allow RO to specify >>>>>>>>> a policy for which of RO's access tokens should be delegated unde= r what >>>>>>>>> conditions. AS-RS should not need to understand those policies. = The flow >>>>>>>>> would be >>>>>>>>> >>>>>>>>> - RO contacts AS-RS and gets one or more access tokens. >>>>>>>>> - RO delegates one or more of those tokens, potentially >>>>>>>>> sub-scoped, to AS-RO. >>>>>>>>> - A different user contacts AS-RO to get a potentially >>>>>>>>> sub-scoped access token from AS-RO. >>>>>>>>> - That user presents the access token delegated by AS-RO when >>>>>>>>> invoking the resource. >>>>>>>>> >>>>>>>>> AS-RS only needs to verify that the delegation chain is >>>>>>>>> legitimate, e.g., no increase in scope, and that it grants permis= sion for >>>>>>>>> the request being made. AS-RS does not need to understand the po= licy >>>>>>>>> behind granting the delegation by AS-RO. >>>>>>>>> >>>>>>>>> -------------- >>>>>>>>> Alan Karp >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Adrian, >>>>>>>>>> >>>>>>>>>> I think this shows the problem with the terminology as it=E2=80= =99s been >>>>>>>>>> applied in this conversation, which I=E2=80=99ve tried to shine = light on before. >>>>>>>>>> What you and others are calling the =E2=80=9CRS=E2=80=9D is real= ly the =E2=80=9CAS and RS working >>>>>>>>>> together=E2=80=9D =E2=80=94 everything to the right of the line.= When Denis had brought up >>>>>>>>>> =E2=80=9Celiminating the AS=E2=80=9D in another thread, what he= =E2=80=99d really done is labeled >>>>>>>>>> everything to the right of the line as the =E2=80=9CRS=E2=80=9D.= Of course, the irony here >>>>>>>>>> is that everything to the right of the line used all be called t= he =E2=80=9CAS=E2=80=9D or >>>>>>>>>> simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say = below, I don=E2=80=99t want the >>>>>>>>>> client to have visibility on what happens on that side. >>>>>>>>>> >>>>>>>>>> Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the= diagram is not >>>>>>>>>> the AS, as far as GNAP is concerned. It does not issue an access= token that >>>>>>>>>> the RS will accept. The elements to the left of the line could b= e a lot of >>>>>>>>>> things, but they are NOT the AS =E2=80=94 by definition. The cli= ent lives over on >>>>>>>>>> the left, but so do any external inputs to the AS. These could b= e policy >>>>>>>>>> inputs on behalf of the RO, they could be presentation artifacts= , they >>>>>>>>>> could be federated logins, they could be the output of policy de= cisions. >>>>>>>>>> How the AS comes to trust those things is up to the AS=E2=80=99s= implementation. >>>>>>>>>> It=E2=80=99s something we can talk about, but ultimately GNAP wo= n=E2=80=99t be in any >>>>>>>>>> position to dictate because in practice some AS=E2=80=99s are si= mply going to >>>>>>>>>> internalize all policies and we will never successfully force th= ose open. >>>>>>>>>> >>>>>>>>>> But with all that in mind, I think the key here is going to be >>>>>>>>>> looking at what the inputs to the AS are, and how those can be d= efined in >>>>>>>>>> an interoperable way for AS=E2=80=99s that can accept them. I th= ink there=E2=80=99s a lot >>>>>>>>>> of room for innovation and flexibility here that doesn=E2=80=99t= break the trust >>>>>>>>>> model or core use cases. If I have an AS-RS set that won=E2=80= =99t accept my >>>>>>>>>> favorite flavor of policy engine inputs, then I can decide not t= o use that >>>>>>>>>> one. But this is a very different question than saying the RS it= self needs >>>>>>>>>> to accept my own AS =E2=80=94 and we can=E2=80=99t keep conflati= ng these two models. >>>>>>>>>> >>>>>>>>>> So to me, GNAP can support a Zero Trust Architecture by >>>>>>>>>> LEVERAGING the AS, not by subsuming or eliminating it. It is in = fact the >>>>>>>>>> AS, not the client and not the RS, that will request and consume= the >>>>>>>>>> results of a privacy-preserving zero-trust policy query thing. A= nything >>>>>>>>>> that happens downstream from that is of little concern to the ze= ro-trust >>>>>>>>>> components because, as you point out, it=E2=80=99s on the =E2=80= =9Cother side=E2=80=9D of the line. >>>>>>>>>> >>>>>>>>>> I think we got this basic component model pretty right in OAuth: >>>>>>>>>> the AS and RS and client working together. Where OAuth misses th= e mark is >>>>>>>>>> the assumption that the user has to log in to the AS through a w= ebpage and >>>>>>>>>> interact directly, thereby proving they=E2=80=99re the RO. It=E2= =80=99s this latter space >>>>>>>>>> where I think we can both push innovation and also address the i= mportant >>>>>>>>>> and compelling use cases like the ones you=E2=80=99re bringing. >>>>>>>>>> >>>>>>>>>> =E2=80=94 Justin >>>>>>>>>> >>>>>>>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper < >>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>> >>>>>>>>>> I'm sorry, Justin. As a Resource Owner, I look at the RS trust >>>>>>>>>> boundary (the dotted line in the diagram) as being the RS. I don= 't expect >>>>>>>>>> any visibility into what's going on on the right. >>>>>>>>>> >>>>>>>>>> My problem with the framing you propose is that requests are >>>>>>>>>> going to the RS (or the AS-RS) and I don't want to share my poli= cies with >>>>>>>>>> the AS-RS. I want to keep the RS and AS-RS as ignorant as possib= le. >>>>>>>>>> >>>>>>>>>> Adrian >>>>>>>>>> >>>>>>>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Adrian, >>>>>>>>>>> >>>>>>>>>>> What you=E2=80=99re discussing below, in terms of logging in to= a site, >>>>>>>>>>> is not approaching the RS. You are in fact approaching the clie= nt, and >>>>>>>>>>> identifying both the AS and RS to the client. The client is a c= lient *of >>>>>>>>>>> your identity* in this model, and the RS is part of the >>>>>>>>>>> identity provider. It=E2=80=99s really important that we don=E2= =80=99t conflate the RS and >>>>>>>>>>> client in this way as it leads to a lot of confusion downstream= and a lot >>>>>>>>>>> of broken trust boundaries. >>>>>>>>>>> >>>>>>>>>>> With that model in mind, approaching the =E2=80=9CRS" and provi= ding it >>>>>>>>>>> your identity is really just a case of the =E2=80=9Cfederated l= ogin to AS=E2=80=9D pattern >>>>>>>>>>> that we discussed on the WG call. The user here approaches an R= S, which has >>>>>>>>>>> its own AS. To share things from this RS, the RO has to authent= icate to the >>>>>>>>>>> RS=E2=80=99s AS. This particular AS allows the RO to do so usin= g an external >>>>>>>>>>> identity =E2=80=94 in which case, the AS is now a =E2=80=9Cclie= nt=E2=80=9D of a separate, >>>>>>>>>>> disconnected (but layered) delegation. The ultimate client that= eventually >>>>>>>>>>> calls the RS down the way may or may not know about these layer= s. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This same AS, which is closely tied to the RS and trusted by th= e >>>>>>>>>>> RS, might also take in FIDO credentials, or DIDs, or any number= of other >>>>>>>>>>> proof mechanisms. The output of this is an access token the RS = trusts, but >>>>>>>>>>> the input is up to the AS. The RS is not what you=E2=80=99re lo= gging in to. >>>>>>>>>>> >>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>> >>>>>>>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper < >>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>> >>>>>>>>>>> I too am in favor of avoiding consolidation and correlation. >>>>>>>>>>> Right now, when I approach a service provider (RS) for the firs= t time, I'm >>>>>>>>>>> offered the opportunity to identify my persona as: email, sign-= in with >>>>>>>>>>> Google, Facebook, or Apple. I know there are people who try to = create >>>>>>>>>>> one-off email addresses but that is mostly a waste of time. >>>>>>>>>>> >>>>>>>>>>> So, along come FIDO2 and DID wallets to the rescue. Now, in >>>>>>>>>>> theory, I have a way to start out my RS relationship pseudonymo= usly. >>>>>>>>>>> >>>>>>>>>>> When I want my resource to be discovered or shared I will post >>>>>>>>>>> that RS URL including my pseudonym. If I then want to introduce= a >>>>>>>>>>> mediator in front of my AS or messaging service endpoint, I hav= e that >>>>>>>>>>> option. If I want to keep requests away from the mediator, I wo= uld publish >>>>>>>>>>> an encryption key along with my pseudonym. >>>>>>>>>>> >>>>>>>>>>> - Adrian >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk >>>>>>>>>>>> wrote: >>>>>>>>>>>> > >>>>>>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper >>>>>>>>>>>> wrote: >>>>>>>>>>>> >> @Alan Karp shared a talk about the >>>>>>>>>>>> Principle Of Least >>>>>>>>>>>> >> Authority (POLA) in a recent comment >>>>>>>>>>>> >> >>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#= issuecomment-803099693 >>>>>>>>>>>> >> I recommend it. >>>>>>>>>>>> >> >>>>>>>>>>>> >> We might expect a protocol with authorization in the title >>>>>>>>>>>> to use authority >>>>>>>>>>>> >> as a core principle. I advocate for a GNAP design that >>>>>>>>>>>> maximizes the power >>>>>>>>>>>> >> of the RO, to be seen as a human rights issue when the RO i= s >>>>>>>>>>>> a human. This >>>>>>>>>>>> >> causes me to ask how to combine better security with better >>>>>>>>>>>> human rights in >>>>>>>>>>>> >> GNAP. >>>>>>>>>>>> >> >>>>>>>>>>>> >> Who should have the least authority in the GNAP design? >>>>>>>>>>>> >> >>>>>>>>>>>> >> The AS derives authority as a delegate of the RO. If we ask >>>>>>>>>>>> the RO to >>>>>>>>>>>> >> partition limited authority across dozens of different ASs >>>>>>>>>>>> by domain and >>>>>>>>>>>> >> function, then we are not using technology to empower the >>>>>>>>>>>> individual. >>>>>>>>>>>> >> Probably the opposite, as we introduce consent fatigue and >>>>>>>>>>>> burden normal >>>>>>>>>>>> >> people to partition their lives into non-overlapping domain= s. >>>>>>>>>>>> >> >>>>>>>>>>>> >> My experience says we should aim for one AS per persona >>>>>>>>>>>> because that maps >>>>>>>>>>>> >> into the way we manage our public and private identities. >>>>>>>>>>>> POLA would then >>>>>>>>>>>> >> teach care in keeping ASs and RSs related to work / public >>>>>>>>>>>> separate from >>>>>>>>>>>> >> ASs and RSs related to private life so that a policy >>>>>>>>>>>> vulnerability in our >>>>>>>>>>>> >> delegation to an AS would have the least likelihood of harm= . >>>>>>>>>>>> > >>>>>>>>>>>> > Thinking about how least authority/least privilege would >>>>>>>>>>>> apply to GNAP >>>>>>>>>>>> > seems like a useful exercise. I do want to point out some >>>>>>>>>>>> potential >>>>>>>>>>>> > pitfalls with one-AS-per-persona that we can also be aware >>>>>>>>>>>> of. If >>>>>>>>>>>> > one-AS-per-persona becomes one-persona-per-AS as well, then >>>>>>>>>>>> the AS's >>>>>>>>>>>> > identity in effect also serves as a persona identity and >>>>>>>>>>>> there are privacy >>>>>>>>>>>> > considerations to that. If, on the other hand, the >>>>>>>>>>>> > multiple-personas-per-AS (presumably corresponding to >>>>>>>>>>>> multiple humans) >>>>>>>>>>>> > route is taken, we should consider whether that would lead t= o >>>>>>>>>>>> various >>>>>>>>>>>> > (e.g., market) forces driving consolidation to just a handfu= l >>>>>>>>>>>> of >>>>>>>>>>>> > super-popular AS services. That topic is a current matter o= f >>>>>>>>>>>> concern to >>>>>>>>>>>> > some IETF participants. >>>>>>>>>>>> > >>>>>>>>>>>> >>>>>>>>>>>> Hi Ben, big +1 to this. This is something that we discussed >>>>>>>>>>>> ages ago in the UMA working group, and it=E2=80=99s one of the= biggest problems >>>>>>>>>>>> with the personal AS (and personal data store) model. This kin= d of thing >>>>>>>>>>>> makes RS-first trust models really difficult in practice. >>>>>>>>>>>> >>>>>>>>>>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve got softwar= e that wants to >>>>>>>>>>>> access my medical information. It calls an RS and requests acc= ess, but it >>>>>>>>>>>> hasn=E2=80=99t been granted anything yet. Now I as the RO have= set up the RS so >>>>>>>>>>>> that it talks to my personal AS, that only I use. In addition = to the RS >>>>>>>>>>>> having to be able to figure out which medical records are bein= g requested >>>>>>>>>>>> from the context of the unauthenticated request (which means i= t needs >>>>>>>>>>>> identifiers in the URL or something similar for the RS to be a= ble to tell, >>>>>>>>>>>> assuming that it protects data for more than one person). So t= his client >>>>>>>>>>>> software doesn=E2=80=99t know who I am and doesn=E2=80=99t kno= w my medical record >>>>>>>>>>>> information, makes a completely unauthorized request to the RS= , and the RS >>>>>>>>>>>> says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a toke= n=E2=80=9D. The client can now make a >>>>>>>>>>>> direct correlation between the data that=E2=80=99s being prote= cted at the RS and >>>>>>>>>>>> the person running the AS that protects it. Importantly, this = client makes >>>>>>>>>>>> this call with no prior relationship to the RS and no really a= uditable way >>>>>>>>>>>> to track it down after the fact. This is a design feature in t= he good case, >>>>>>>>>>>> and terrifying in the bad case. >>>>>>>>>>>> >>>>>>>>>>>> If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS,= please >>>>>>>>>>>> talk to the Medicine Doctor AS to get access=E2=80=9D, we have= n=E2=80=99t exposed anything >>>>>>>>>>>> at all. And from the perspective of both the patient and the R= S, this is >>>>>>>>>>>> more privacy-preserving, and it=E2=80=99s really the least sur= prising option. Once >>>>>>>>>>>> the client gets to the AS, it can start a negotiation of figur= ing out who >>>>>>>>>>>> the RO is for the information being accessed. >>>>>>>>>>>> >>>>>>>>>>>> On top of this, the usability expectations of people managing >>>>>>>>>>>> their own AS, or set of AS=E2=80=99s for multiple personas to = keep things separate, >>>>>>>>>>>> is a huge burden. Even in the tech community, I know people wh= o can=E2=80=99t >>>>>>>>>>>> reliably manage more than one email address for different purp= oses. I >>>>>>>>>>>> wouldn=E2=80=99t expect my partner to do that =E2=80=94 they h= ave trouble enough balancing >>>>>>>>>>>> all the logins and sessions required for different kids remote= schooling, I >>>>>>>>>>>> couldn=E2=80=99t imagine them having to understand all the req= uirements for >>>>>>>>>>>> managing multiple authorization servers and associated policie= s. I also >>>>>>>>>>>> don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80= =9D =E2=80=94 I=E2=80=99ve been on the internet for >>>>>>>>>>>> decades and I can barely keep tabs on my GPG keys, and only us= e them when I >>>>>>>>>>>> am forced to. This is exactly the kind of =E2=80=9Cmarket pres= sure=E2=80=9D that I think >>>>>>>>>>>> Ben mentions above, people will just want to outsource that to= someone >>>>>>>>>>>> else, and the reality will be a few popular providers. >>>>>>>>>>>> >>>>>>>>>>>> In which case, we could end up doing a ton of work to allow an >>>>>>>>>>>> RS choice only to end up with a world where the RS ends up mak= ing a limited >>>>>>>>>>>> choice anyway. We see how that plays out with OpenID Connect = =E2=80=94 RP=E2=80=99s could >>>>>>>>>>>> allow arbitrary IdPs but they choose Google because it works a= nd that=E2=80=99s >>>>>>>>>>>> where the users are. (And that=E2=80=99s not to say anything o= f the proprietary >>>>>>>>>>>> OIDC-like protocols, but that=E2=80=99s another discussion). >>>>>>>>>>>> >>>>>>>>>>>> For further reading on these topics, I recommend both =E2=80= =9CWhy >>>>>>>>>>>> Johnny Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Sy= stems Fail=E2=80=9D. >>>>>>>>>>>> >>>>>>>>>>>> So what does this have to do with GNAP? I think we can be >>>>>>>>>>>> clear-eyed on what kinds of expectations we have for the parti= cipants. If >>>>>>>>>>>> we expect users (RO=E2=80=99s) to have to set up the AS-RS rel= ationship, or expect >>>>>>>>>>>> them to carry their AS, or manage their personal keys =E2=80= =94 I think we=E2=80=99ve lost >>>>>>>>>>>> the battle for relevance. >>>>>>>>>>>> >>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>> 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 >> > --000000000000895d2505be56f4b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Isn't the AS-RO a component of the AS? Same idea as t= he interact component, it functionnally belongs to the AS role but could be= deployed either as a monolith or as a separate component?

    Fabien

    Le jeu. 25 mars 2021 =C3=A0 04:26,= Adrian Gropper <agropper@heal= thurl.com> a =C3=A9crit=C2=A0:
    Yes, but I would say it=E2=80=99s not the RO that want= s the access token. It=E2=80=99s the RO that wants the client making the re= quest to get an access token.=C2=A0

    Adrian

    On Wed, Mar 24, 2021 at 11:22 PM Alan Karp <alan= hkarp@gmail.com> wrote:
    Adrian = Gropper <agropper@healthurl.com> wrote:
    In this design, the AS is the AS-RS and the agent is the AS-RO.= By my definition, this model has two ASs since both are processing request= s into tokens. The problem with this is complexity and privacy. The RO may = not want to share the request information with the AS-RS.
    <= /div>
    =
    More precisely, RO has no= choice but to present the required information to AS-RS if RO wants an acc= ess token.=C2=A0 However, RO does not want AS-RS to know the policy by whic= h RO delegates tokens.=C2=A0 That's why RO uses AS-RO for those delegat= ions.

    --------= ------
    Alan Karp


    On Wed, Mar 24, 2= 021 at 7:41 PM Adrian Gropper <agropper@healthurl.com> wrote:=
    Thank you for creating the issue. My definition of AS is= independent of AS-RO or AS-RS.=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/iss= ues/223#issuecomment-806280421 I also agree with Alan's definition = based on delegation. An AS-RS would be a delegate of the RS.=C2=A0

    Based on that, I see it as obvious=C2=A0that t= he policy has to be accessible (defined locally?) in order for it to be run= as the code that turns a request into an access token.=C2=A0
    The only other possibility is that the request is packaged by t= he AS and sent elsewhere (an agent) for evaluation against policy and a pro= to-token returned. In that case the AS is acting as a proxy and the PDP is = elsewhere. I can imagine that an AS-RS would behave this way so that the pr= oto-token could be turned into an access token by the AS-RS. Isn't this= what Justin is proposing? In this design, the AS is the AS-RS and the agen= t is the AS-RO. By my definition, this model has two ASs since both are pro= cessing requests into tokens. The problem with this is complexity and priva= cy. The RO may not want to share the request information with the AS-RS.

    Adrian

    On Wed, Mar 24, 2021 at 5:21 PM Fabien I= mbault <fabien.imbault@gmail.com> wrote:
    Isn't t= hat what the AS is supposed to be, only with the caveat that the policy is = defined locally?=C2=A0

    Fabien= =C2=A0


    Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp <alanhkarp@gmail= .com> a =C3=A9crit=C2=A0:
    AS-RO is an AS that RO t= rusts to delegate RO's access tokens according to RO's policies.=C2= =A0=C2=A0

    --------------
    Alan= Karp


    On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan and Adrian,<= div>
    I've created issue AS-RO policy delegation (https://github.com/ietf-wg-gnap/gna= p-core-protocol/issues/223) to capture your input.=C2=A0
    A fi= rst question that arises: can we give a definition to AS-RO?

    =
    Thanks
    Fabien

    On Tue, Mar 23, 2021 at 4:15 PM Ala= n Karp <alanhkarp@gmail.com> wrote:
    Fa= bien Imbault <fabien.imbault@gmail.com> wrote:
    = Hi Alan,=C2=A0

    Yes, but in that flow, the token relation= ship between AS-RS and AS-RO is only secure if the tokens issued by AS-RS a= re cryptographically attenuable in the first place.=C2=A0
    =C2=A0
    Attenuated delegation is a re= quirement, but that doesn't have to be done cryptographically.=C2=A0 To= ken exchange works just fine.=C2=A0 SPKI and zcap-ld are examples of the cr= ypto approach, and we used token exchange in the system for HP.

    --------------
    Alan Karp


    On Tue, Mar 2= 3, 2021 at 4:12 AM Fabien Imbault <fabien.imbault@gmail= .com> wrote:
    Hi Alan,=C2=A0

    Yes, but in that flo= w, the token relationship between AS-RS and AS-RO is only secure if the tok= ens issued by AS-RS are cryptographically attenuable in the first place.=C2= =A0

    Fabien

    On Mon, Mar 22, 2021 at 9:26 PM Al= an Karp <alanhkarp@gmail.com> wrote:
    Justin Richer <jricher@m= it.edu> wrote:

    But with all that in mind, I think the key h= ere is going to be looking at what the inputs to the AS are, and how those = can be defined in an interoperable way for AS=E2=80=99s that can accept the= m. I think there=E2=80=99s a lot of room for innovation and flexibility her= e that doesn=E2=80=99t break the trust model or core use cases. If I have a= n AS-RS set that won=E2=80=99t accept my favorite flavor of policy engine i= nputs, then I can decide not to use that one. But this is a very different = question than saying the RS itself needs to accept my own AS =E2=80=94 and = we can=E2=80=99t keep conflating these two models.

    I agree.=C2=A0 The point of having an AS-RO is to allow= RO to specify a policy for which of RO's access tokens should be deleg= ated under what conditions.=C2=A0 AS-RS should not need to understand those= policies.=C2=A0 The flow would be
    • RO contacts AS-RS and = gets one or more access tokens.
    • RO delegates one or more of those t= okens, potentially sub-scoped, to AS-RO.
    • A different user contacts = AS-RO to get a potentially sub-scoped access token from AS-RO.
    • That= user presents the access token delegated by AS-RO when invoking the resour= ce.
    AS-RS only needs to verify that the delegation= chain is legitimate, e.g., no increase in scope, and that it grants permis= sion for the request being made.=C2=A0 AS-RS does not need to understand th= e policy behind granting the delegation by AS-RO.
    --------------
    Alan Karp


    On Mon, Mar 22, 2021 at 11:40 A= M Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    = I think this shows the problem with the terminology as it=E2=80=99s been ap= plied in this conversation, which I=E2=80=99ve tried to shine light on befo= re. What you and others are calling the =E2=80=9CRS=E2=80=9D is really the = =E2=80=9CAS and RS working together=E2=80=9D =E2=80=94 everything to the ri= ght of the line. When Denis had brought up =E2=80=9Celiminating the AS=E2= =80=9D in another thread, what he=E2=80=99d really done is labeled everythi= ng to the right of the line as the =E2=80=9CRS=E2=80=9D. Of course, the iro= ny here is that everything to the right of the line used all be called the = =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days= . As you say below, I don=E2=80=99t want the client to have visibility on w= hat happens on that side.=C2=A0

    Note well: The Goo= gle+ logo labeled =E2=80=9CIdP=E2=80=9D in the diagram is not the AS, as fa= r as GNAP is concerned. It does not issue an access token that the RS will = accept. The elements to the left of the line could be a lot of things, but = they are NOT the AS =E2=80=94 by definition. The client lives over on the l= eft, but so do any external inputs to the AS. These could be policy inputs = on behalf of the RO, they could be presentation artifacts, they could be fe= derated logins, they could be the output of policy decisions. How the AS co= mes to trust those things is up to the AS=E2=80=99s implementation. It=E2= =80=99s something we can talk about, but ultimately GNAP won=E2=80=99t be i= n any position to dictate because in practice some AS=E2=80=99s are simply = going to internalize all policies and we will never successfully force thos= e open.=C2=A0

    But with all that in mind, I think t= he key here is going to be looking at what the inputs to the AS are, and ho= w those can be defined in an interoperable way for AS=E2=80=99s that can ac= cept them. I think there=E2=80=99s a lot of room for innovation and flexibi= lity here that doesn=E2=80=99t break the trust model or core use cases. If = I have an AS-RS set that won=E2=80=99t accept my favorite flavor of policy = engine inputs, then I can decide not to use that one. But this is a very di= fferent question than saying the RS itself needs to accept my own AS =E2=80= =94 and we can=E2=80=99t keep conflating these two models.

    So to me, GNAP can support a Zero Trust Architecture by LEVERAGING= the AS, not by subsuming or eliminating it. It is in fact the AS, not the = client and not the RS, that will request and consume the results of a priva= cy-preserving zero-trust policy query thing. Anything that happens downstre= am from that is of little concern to the zero-trust components because, as = you point out, it=E2=80=99s on the =E2=80=9Cother side=E2=80=9D of the line= .=C2=A0

    I think we got this basic component model = pretty right in OAuth: the AS and RS and client working together. Where OAu= th misses the mark is the assumption that the user has to log in to the AS = through a webpage and interact directly, thereby proving they=E2=80=99re th= e RO. It=E2=80=99s this latter space where I think we can both push innovat= ion and also address the important and compelling use cases like the ones y= ou=E2=80=99re bringing.

    =C2=A0=E2=80=94 Justin
    =

    On Mar 22, 2021, at 2:14 PM, Adrian= Gropper <agropper@healthurl.com> wrote:

    =
    I'm sorry, Justin. As a Resource Owner, I look at= the RS trust boundary (the dotted line in the diagram) as being the RS. I = don't expect any visibility into what's going on on the=C2=A0right.= =C2=A0

    My problem with the framing you propose is that r= equests are going to the RS (or the AS-RS) and I don't want to share my= policies with the AS-RS. I want to keep the RS and AS-RS as ignorant as po= ssible.

    Adrian

    On Mon, Mar 22, 2021 at 1:48 P= M Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    = What you=E2=80=99re discussing below, in terms of logging in to a site, is = not approaching the RS. You are in fact approaching the client, and identif= ying both the AS and RS to the client. The client is a client of your id= entity in this model, and the RS is part of the identity provider. It= =E2=80=99s really important that we don=E2=80=99t conflate the RS and clien= t in this way as it leads to a lot of confusion downstream and a lot of bro= ken trust boundaries.

    With that model in mind, app= roaching the =E2=80=9CRS" and providing it your identity is really jus= t a case of the =E2=80=9Cfederated login to AS=E2=80=9D pattern that we dis= cussed on the WG call. The user here approaches an RS, which has its own AS= . To share things from this RS, the RO has to authenticate to the RS=E2=80= =99s AS. This particular AS allows the RO to do so using an external identi= ty =E2=80=94 in which case, the AS is now a =E2=80=9Cclient=E2=80=9D of a s= eparate, disconnected (but layered) delegation. The ultimate client that ev= entually calls the RS down the way may or may not know about these layers.= =C2=A0

    <PastedGraphic-1.png>
    This= same AS, which is closely tied to the RS and trusted by the RS, might also= take in FIDO credentials, or DIDs, or any number of other proof mechanisms= . The output of this is an access token the RS trusts, but the input is up = to the AS. The RS is not what you=E2=80=99re logging in to.

    <= /div>
    =C2=A0=E2=80=94 Justin

    On Mar 22, 2021, at 1:28 PM, Adrian Gropper <agropper@he= althurl.com> wrote:

    I too am in favor= of avoiding consolidation and correlation. Right now, when I approach a se= rvice provider (RS) for the first time, I'm offered the opportunity to = identify my persona as: email, sign-in with Google, Facebook, or Apple. I k= now there are people who try to create one-off email addresses but that is = mostly a waste of time.=C2=A0

    So, along come FIDO2 and D= ID wallets to the rescue. Now, in theory, I have a way to start out my RS r= elationship pseudonymously.=C2=A0

    When I want my r= esource to be discovered or shared I will post that RS URL including my pse= udonym. If I then want to introduce a mediator=C2=A0in front of my AS or me= ssaging service=C2=A0endpoint, I have that option. If I want to keep reques= ts away from the mediator, I would publish an encryption key along with my = pseudonym.

    - Adrian


    <= /div>

    On Mon, Mar 22, 2021 at 9:55 AM Justin Richer <jricher@mit.= edu> wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu&= gt; wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhkarp@gmail.com> shared a ta= lk about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/14= 5#issuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listi= nfo/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>
    --000000000000895d2505be56f4b0-- From nobody Thu Mar 25 00:04:49 2021 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 ACCE33A1308 for ; Thu, 25 Mar 2021 00:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 34Vok2c1hc0t for ; Thu, 25 Mar 2021 00:04:41 -0700 (PDT) Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43]) (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 A5DA23A130F for ; Thu, 25 Mar 2021 00:04:41 -0700 (PDT) Received: by mail-ua1-f43.google.com with SMTP id v23so208199uaq.13 for ; Thu, 25 Mar 2021 00:04:41 -0700 (PDT) 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=xrxAzAqRt1fInSSEpnER+Mb3FlJ71aMhZbpd/+AjZ4s=; b=O5ZbA7H85oicHdSQpGgMdYEjVfMK928dEI3PZ52Yq0DRa0YOoCaokp9NLn0sr9kWFD MMLMMUIR69DU+mf+N4qtziqN6x2qg3EosH+jMUwLGsmBqzaYMVwMg0YE661TolBd5QFv vkLAPvGCul6Jc96U6bOM0PdBeS5zd9HoLiAjDav/J3r6IFQhQ335riGs9+oMQ/catIhF SzKfIJTpQEImnseyddu02OpsrRPkNjgxr4Cuj6fHf2Tm5RgFZ6UM09a47x0v8j66B7Rn QuVqfqXTn6/73U2tdXkF8X4OMBiqoQdRr8OEnJ0X26auBHtoppe+58ZxWhCzUCniNllC +Iqw== X-Gm-Message-State: AOAM533UtQ+AQ1N4wlVaBvA8ROjLuAilIdRubcur1ptLlu+In5ma6UbM S6qaOWd6yDOVDI3FTE0UIeppqtJdut1JK2lNhQY= X-Google-Smtp-Source: ABdhPJxBC2R3lFKbJN+zM5blk5niMQCZ7XBADm+K1rkjkIlkayuX+s5VP7kfpUkuK5QhaRzNB+5v9he9UobIV798DiU= X-Received: by 2002:ab0:7115:: with SMTP id x21mr3767589uan.39.1616655880018; Thu, 25 Mar 2021 00:04:40 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> In-Reply-To: From: Adrian Gropper Date: Thu, 25 Mar 2021 03:04:28 -0400 Message-ID: To: Fabien Imbault Cc: Alan Karp , Benjamin Kaduk , GNAP Mailing List , Justin Richer , Mark Miller Content-Type: multipart/alternative; boundary="00000000000073de3605be570771" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 07:04:47 -0000 --00000000000073de3605be570771 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What purpose would be served by GNAP splitting the AS into two components? Adrian On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault wrote: > Isn't the AS-RO a component of the AS? Same idea as the interact > component, it functionnally belongs to the AS role but could be deployed > either as a monolith or as a separate component? > > Fabien > > Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper a > =C3=A9crit : > >> Yes, but I would say it=E2=80=99s not the RO that wants the access token= . It=E2=80=99s >> the RO that wants the client making the request to get an access token. >> >> Adrian >> >> On Wed, Mar 24, 2021 at 11:22 PM Alan Karp wrote: >> >>> Adrian Gropper wrote: >>> >>>> >>>> In this design, the AS is the AS-RS and the agent is the AS-RO. By my >>>> definition, this model has two ASs since both are processing requests = into >>>> tokens. The problem with this is complexity and privacy. The RO may no= t >>>> want to share the request information with the AS-RS. >>>> >>> >>> More precisely, RO has no choice but to present the required informatio= n >>> to AS-RS if RO wants an access token. However, RO does not want AS-RS = to >>> know the policy by which RO delegates tokens. That's why RO uses AS-RO= for >>> those delegations. >>> >>> -------------- >>> Alan Karp >>> >>> >>> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper >>> wrote: >>> >>>> Thank you for creating the issue. My definition of AS is independent o= f >>>> AS-RO or AS-RS. >>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecom= ment-806280421 >>>> I also agree with Alan's definition based on delegation. An AS-RS woul= d be >>>> a delegate of the RS. >>>> >>>> Based on that, I see it as obvious that the policy has to be accessibl= e >>>> (defined locally?) in order for it to be run as the code that turns a >>>> request into an access token. >>>> >>>> The only other possibility is that the request is packaged by the AS >>>> and sent elsewhere (an agent) for evaluation against policy and a >>>> proto-token returned. In that case the AS is acting as a proxy and the= PDP >>>> is elsewhere. I can imagine that an AS-RS would behave this way so tha= t the >>>> proto-token could be turned into an access token by the AS-RS. Isn't t= his >>>> what Justin is proposing? In this design, the AS is the AS-RS and the = agent >>>> is the AS-RO. By my definition, this model has two ASs since both are >>>> processing requests into tokens. The problem with this is complexity a= nd >>>> privacy. The RO may not want to share the request information with the >>>> AS-RS. >>>> >>>> Adrian >>>> >>>> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Isn't that what the AS is supposed to be, only with the caveat that >>>>> the policy is defined locally? >>>>> >>>>> Fabien >>>>> >>>>> >>>>> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp a >>>>> =C3=A9crit : >>>>> >>>>>> AS-RO is an AS that RO trusts to delegate RO's access tokens >>>>>> according to RO's policies. >>>>>> >>>>>> -------------- >>>>>> Alan Karp >>>>>> >>>>>> >>>>>> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>>> Hi Alan and Adrian, >>>>>>> >>>>>>> I've created issue AS-RO policy delegation ( >>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to >>>>>>> capture your input. >>>>>>> A first question that arises: can we give a definition to AS-RO? >>>>>>> >>>>>>> Thanks >>>>>>> Fabien >>>>>>> >>>>>>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp >>>>>>> wrote: >>>>>>> >>>>>>>> Fabien Imbault wrote: >>>>>>>> >>>>>>>>> Hi Alan, >>>>>>>>> >>>>>>>>> Yes, but in that flow, the token relationship between AS-RS and >>>>>>>>> AS-RO is only secure if the tokens issued by AS-RS are cryptograp= hically >>>>>>>>> attenuable in the first place. >>>>>>>>> >>>>>>>> >>>>>>>> Attenuated delegation is a requirement, but that doesn't have to b= e >>>>>>>> done cryptographically. Token exchange works just fine. SPKI and= zcap-ld >>>>>>>> are examples of the crypto approach, and we used token exchange in= the >>>>>>>> system for HP. >>>>>>>> >>>>>>>> -------------- >>>>>>>> Alan Karp >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi Alan, >>>>>>>>> >>>>>>>>> Yes, but in that flow, the token relationship between AS-RS and >>>>>>>>> AS-RO is only secure if the tokens issued by AS-RS are cryptograp= hically >>>>>>>>> attenuable in the first place. >>>>>>>>> >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Justin Richer wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> But with all that in mind, I think the key here is going to be >>>>>>>>>>> looking at what the inputs to the AS are, and how those can be = defined in >>>>>>>>>>> an interoperable way for AS=E2=80=99s that can accept them. I t= hink there=E2=80=99s a lot >>>>>>>>>>> of room for innovation and flexibility here that doesn=E2=80=99= t break the trust >>>>>>>>>>> model or core use cases. If I have an AS-RS set that won=E2=80= =99t accept my >>>>>>>>>>> favorite flavor of policy engine inputs, then I can decide not = to use that >>>>>>>>>>> one. But this is a very different question than saying the RS i= tself needs >>>>>>>>>>> to accept my own AS =E2=80=94 and we can=E2=80=99t keep conflat= ing these two models. >>>>>>>>>>> >>>>>>>>>>> I agree. The point of having an AS-RO is to allow RO to specif= y >>>>>>>>>> a policy for which of RO's access tokens should be delegated und= er what >>>>>>>>>> conditions. AS-RS should not need to understand those policies.= The flow >>>>>>>>>> would be >>>>>>>>>> >>>>>>>>>> - RO contacts AS-RS and gets one or more access tokens. >>>>>>>>>> - RO delegates one or more of those tokens, potentially >>>>>>>>>> sub-scoped, to AS-RO. >>>>>>>>>> - A different user contacts AS-RO to get a potentially >>>>>>>>>> sub-scoped access token from AS-RO. >>>>>>>>>> - That user presents the access token delegated by AS-RO when >>>>>>>>>> invoking the resource. >>>>>>>>>> >>>>>>>>>> AS-RS only needs to verify that the delegation chain is >>>>>>>>>> legitimate, e.g., no increase in scope, and that it grants permi= ssion for >>>>>>>>>> the request being made. AS-RS does not need to understand the p= olicy >>>>>>>>>> behind granting the delegation by AS-RO. >>>>>>>>>> >>>>>>>>>> -------------- >>>>>>>>>> Alan Karp >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Adrian, >>>>>>>>>>> >>>>>>>>>>> I think this shows the problem with the terminology as it=E2=80= =99s been >>>>>>>>>>> applied in this conversation, which I=E2=80=99ve tried to shine= light on before. >>>>>>>>>>> What you and others are calling the =E2=80=9CRS=E2=80=9D is rea= lly the =E2=80=9CAS and RS working >>>>>>>>>>> together=E2=80=9D =E2=80=94 everything to the right of the line= . When Denis had brought up >>>>>>>>>>> =E2=80=9Celiminating the AS=E2=80=9D in another thread, what he= =E2=80=99d really done is labeled >>>>>>>>>>> everything to the right of the line as the =E2=80=9CRS=E2=80=9D= . Of course, the irony here >>>>>>>>>>> is that everything to the right of the line used all be called = the =E2=80=9CAS=E2=80=9D or >>>>>>>>>>> simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say= below, I don=E2=80=99t want the >>>>>>>>>>> client to have visibility on what happens on that side. >>>>>>>>>>> >>>>>>>>>>> Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in th= e diagram is not >>>>>>>>>>> the AS, as far as GNAP is concerned. It does not issue an acces= s token that >>>>>>>>>>> the RS will accept. The elements to the left of the line could = be a lot of >>>>>>>>>>> things, but they are NOT the AS =E2=80=94 by definition. The cl= ient lives over on >>>>>>>>>>> the left, but so do any external inputs to the AS. These could = be policy >>>>>>>>>>> inputs on behalf of the RO, they could be presentation artifact= s, they >>>>>>>>>>> could be federated logins, they could be the output of policy d= ecisions. >>>>>>>>>>> How the AS comes to trust those things is up to the AS=E2=80=99= s implementation. >>>>>>>>>>> It=E2=80=99s something we can talk about, but ultimately GNAP w= on=E2=80=99t be in any >>>>>>>>>>> position to dictate because in practice some AS=E2=80=99s are s= imply going to >>>>>>>>>>> internalize all policies and we will never successfully force t= hose open. >>>>>>>>>>> >>>>>>>>>>> But with all that in mind, I think the key here is going to be >>>>>>>>>>> looking at what the inputs to the AS are, and how those can be = defined in >>>>>>>>>>> an interoperable way for AS=E2=80=99s that can accept them. I t= hink there=E2=80=99s a lot >>>>>>>>>>> of room for innovation and flexibility here that doesn=E2=80=99= t break the trust >>>>>>>>>>> model or core use cases. If I have an AS-RS set that won=E2=80= =99t accept my >>>>>>>>>>> favorite flavor of policy engine inputs, then I can decide not = to use that >>>>>>>>>>> one. But this is a very different question than saying the RS i= tself needs >>>>>>>>>>> to accept my own AS =E2=80=94 and we can=E2=80=99t keep conflat= ing these two models. >>>>>>>>>>> >>>>>>>>>>> So to me, GNAP can support a Zero Trust Architecture by >>>>>>>>>>> LEVERAGING the AS, not by subsuming or eliminating it. It is in= fact the >>>>>>>>>>> AS, not the client and not the RS, that will request and consum= e the >>>>>>>>>>> results of a privacy-preserving zero-trust policy query thing. = Anything >>>>>>>>>>> that happens downstream from that is of little concern to the z= ero-trust >>>>>>>>>>> components because, as you point out, it=E2=80=99s on the =E2= =80=9Cother side=E2=80=9D of the line. >>>>>>>>>>> >>>>>>>>>>> I think we got this basic component model pretty right in OAuth= : >>>>>>>>>>> the AS and RS and client working together. Where OAuth misses t= he mark is >>>>>>>>>>> the assumption that the user has to log in to the AS through a = webpage and >>>>>>>>>>> interact directly, thereby proving they=E2=80=99re the RO. It= =E2=80=99s this latter space >>>>>>>>>>> where I think we can both push innovation and also address the = important >>>>>>>>>>> and compelling use cases like the ones you=E2=80=99re bringing. >>>>>>>>>>> >>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>> >>>>>>>>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper < >>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>> >>>>>>>>>>> I'm sorry, Justin. As a Resource Owner, I look at the RS trust >>>>>>>>>>> boundary (the dotted line in the diagram) as being the RS. I do= n't expect >>>>>>>>>>> any visibility into what's going on on the right. >>>>>>>>>>> >>>>>>>>>>> My problem with the framing you propose is that requests are >>>>>>>>>>> going to the RS (or the AS-RS) and I don't want to share my pol= icies with >>>>>>>>>>> the AS-RS. I want to keep the RS and AS-RS as ignorant as possi= ble. >>>>>>>>>>> >>>>>>>>>>> Adrian >>>>>>>>>>> >>>>>>>>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Adrian, >>>>>>>>>>>> >>>>>>>>>>>> What you=E2=80=99re discussing below, in terms of logging in t= o a site, >>>>>>>>>>>> is not approaching the RS. You are in fact approaching the cli= ent, and >>>>>>>>>>>> identifying both the AS and RS to the client. The client is a = client *of >>>>>>>>>>>> your identity* in this model, and the RS is part of the >>>>>>>>>>>> identity provider. It=E2=80=99s really important that we don= =E2=80=99t conflate the RS and >>>>>>>>>>>> client in this way as it leads to a lot of confusion downstrea= m and a lot >>>>>>>>>>>> of broken trust boundaries. >>>>>>>>>>>> >>>>>>>>>>>> With that model in mind, approaching the =E2=80=9CRS" and prov= iding it >>>>>>>>>>>> your identity is really just a case of the =E2=80=9Cfederated = login to AS=E2=80=9D pattern >>>>>>>>>>>> that we discussed on the WG call. The user here approaches an = RS, which has >>>>>>>>>>>> its own AS. To share things from this RS, the RO has to authen= ticate to the >>>>>>>>>>>> RS=E2=80=99s AS. This particular AS allows the RO to do so usi= ng an external >>>>>>>>>>>> identity =E2=80=94 in which case, the AS is now a =E2=80=9Ccli= ent=E2=80=9D of a separate, >>>>>>>>>>>> disconnected (but layered) delegation. The ultimate client tha= t eventually >>>>>>>>>>>> calls the RS down the way may or may not know about these laye= rs. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> This same AS, which is closely tied to the RS and trusted by >>>>>>>>>>>> the RS, might also take in FIDO credentials, or DIDs, or any n= umber of >>>>>>>>>>>> other proof mechanisms. The output of this is an access token = the RS >>>>>>>>>>>> trusts, but the input is up to the AS. The RS is not what you= =E2=80=99re logging in >>>>>>>>>>>> to. >>>>>>>>>>>> >>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>> >>>>>>>>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper < >>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> I too am in favor of avoiding consolidation and correlation. >>>>>>>>>>>> Right now, when I approach a service provider (RS) for the fir= st time, I'm >>>>>>>>>>>> offered the opportunity to identify my persona as: email, sign= -in with >>>>>>>>>>>> Google, Facebook, or Apple. I know there are people who try to= create >>>>>>>>>>>> one-off email addresses but that is mostly a waste of time. >>>>>>>>>>>> >>>>>>>>>>>> So, along come FIDO2 and DID wallets to the rescue. Now, in >>>>>>>>>>>> theory, I have a way to start out my RS relationship pseudonym= ously. >>>>>>>>>>>> >>>>>>>>>>>> When I want my resource to be discovered or shared I will post >>>>>>>>>>>> that RS URL including my pseudonym. If I then want to introduc= e a >>>>>>>>>>>> mediator in front of my AS or messaging service endpoint, I ha= ve that >>>>>>>>>>>> option. If I want to keep requests away from the mediator, I w= ould publish >>>>>>>>>>>> an encryption key along with my pseudonym. >>>>>>>>>>>> >>>>>>>>>>>> - Adrian >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> > >>>>>>>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >> @Alan Karp shared a talk about the >>>>>>>>>>>>> Principle Of Least >>>>>>>>>>>>> >> Authority (POLA) in a recent comment >>>>>>>>>>>>> >> >>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145= #issuecomment-803099693 >>>>>>>>>>>>> >> I recommend it. >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> We might expect a protocol with authorization in the title >>>>>>>>>>>>> to use authority >>>>>>>>>>>>> >> as a core principle. I advocate for a GNAP design that >>>>>>>>>>>>> maximizes the power >>>>>>>>>>>>> >> of the RO, to be seen as a human rights issue when the RO >>>>>>>>>>>>> is a human. This >>>>>>>>>>>>> >> causes me to ask how to combine better security with bette= r >>>>>>>>>>>>> human rights in >>>>>>>>>>>>> >> GNAP. >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> Who should have the least authority in the GNAP design? >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> The AS derives authority as a delegate of the RO. If we as= k >>>>>>>>>>>>> the RO to >>>>>>>>>>>>> >> partition limited authority across dozens of different ASs >>>>>>>>>>>>> by domain and >>>>>>>>>>>>> >> function, then we are not using technology to empower the >>>>>>>>>>>>> individual. >>>>>>>>>>>>> >> Probably the opposite, as we introduce consent fatigue and >>>>>>>>>>>>> burden normal >>>>>>>>>>>>> >> people to partition their lives into non-overlapping >>>>>>>>>>>>> domains. >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> My experience says we should aim for one AS per persona >>>>>>>>>>>>> because that maps >>>>>>>>>>>>> >> into the way we manage our public and private identities. >>>>>>>>>>>>> POLA would then >>>>>>>>>>>>> >> teach care in keeping ASs and RSs related to work / public >>>>>>>>>>>>> separate from >>>>>>>>>>>>> >> ASs and RSs related to private life so that a policy >>>>>>>>>>>>> vulnerability in our >>>>>>>>>>>>> >> delegation to an AS would have the least likelihood of har= m. >>>>>>>>>>>>> > >>>>>>>>>>>>> > Thinking about how least authority/least privilege would >>>>>>>>>>>>> apply to GNAP >>>>>>>>>>>>> > seems like a useful exercise. I do want to point out some >>>>>>>>>>>>> potential >>>>>>>>>>>>> > pitfalls with one-AS-per-persona that we can also be aware >>>>>>>>>>>>> of. If >>>>>>>>>>>>> > one-AS-per-persona becomes one-persona-per-AS as well, then >>>>>>>>>>>>> the AS's >>>>>>>>>>>>> > identity in effect also serves as a persona identity and >>>>>>>>>>>>> there are privacy >>>>>>>>>>>>> > considerations to that. If, on the other hand, the >>>>>>>>>>>>> > multiple-personas-per-AS (presumably corresponding to >>>>>>>>>>>>> multiple humans) >>>>>>>>>>>>> > route is taken, we should consider whether that would lead >>>>>>>>>>>>> to various >>>>>>>>>>>>> > (e.g., market) forces driving consolidation to just a >>>>>>>>>>>>> handful of >>>>>>>>>>>>> > super-popular AS services. That topic is a current matter >>>>>>>>>>>>> of concern to >>>>>>>>>>>>> > some IETF participants. >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Ben, big +1 to this. This is something that we discussed >>>>>>>>>>>>> ages ago in the UMA working group, and it=E2=80=99s one of th= e biggest problems >>>>>>>>>>>>> with the personal AS (and personal data store) model. This ki= nd of thing >>>>>>>>>>>>> makes RS-first trust models really difficult in practice. >>>>>>>>>>>>> >>>>>>>>>>>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve got softwa= re that wants to >>>>>>>>>>>>> access my medical information. It calls an RS and requests ac= cess, but it >>>>>>>>>>>>> hasn=E2=80=99t been granted anything yet. Now I as the RO hav= e set up the RS so >>>>>>>>>>>>> that it talks to my personal AS, that only I use. In addition= to the RS >>>>>>>>>>>>> having to be able to figure out which medical records are bei= ng requested >>>>>>>>>>>>> from the context of the unauthenticated request (which means = it needs >>>>>>>>>>>>> identifiers in the URL or something similar for the RS to be = able to tell, >>>>>>>>>>>>> assuming that it protects data for more than one person). So = this client >>>>>>>>>>>>> software doesn=E2=80=99t know who I am and doesn=E2=80=99t kn= ow my medical record >>>>>>>>>>>>> information, makes a completely unauthorized request to the R= S, and the RS >>>>>>>>>>>>> says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a tok= en=E2=80=9D. The client can now make a >>>>>>>>>>>>> direct correlation between the data that=E2=80=99s being prot= ected at the RS and >>>>>>>>>>>>> the person running the AS that protects it. Importantly, this= client makes >>>>>>>>>>>>> this call with no prior relationship to the RS and no really = auditable way >>>>>>>>>>>>> to track it down after the fact. This is a design feature in = the good case, >>>>>>>>>>>>> and terrifying in the bad case. >>>>>>>>>>>>> >>>>>>>>>>>>> If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS= , please >>>>>>>>>>>>> talk to the Medicine Doctor AS to get access=E2=80=9D, we hav= en=E2=80=99t exposed anything >>>>>>>>>>>>> at all. And from the perspective of both the patient and the = RS, this is >>>>>>>>>>>>> more privacy-preserving, and it=E2=80=99s really the least su= rprising option. Once >>>>>>>>>>>>> the client gets to the AS, it can start a negotiation of figu= ring out who >>>>>>>>>>>>> the RO is for the information being accessed. >>>>>>>>>>>>> >>>>>>>>>>>>> On top of this, the usability expectations of people managing >>>>>>>>>>>>> their own AS, or set of AS=E2=80=99s for multiple personas to= keep things separate, >>>>>>>>>>>>> is a huge burden. Even in the tech community, I know people w= ho can=E2=80=99t >>>>>>>>>>>>> reliably manage more than one email address for different pur= poses. I >>>>>>>>>>>>> wouldn=E2=80=99t expect my partner to do that =E2=80=94 they = have trouble enough balancing >>>>>>>>>>>>> all the logins and sessions required for different kids remot= e schooling, I >>>>>>>>>>>>> couldn=E2=80=99t imagine them having to understand all the re= quirements for >>>>>>>>>>>>> managing multiple authorization servers and associated polici= es. I also >>>>>>>>>>>>> don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80= =9D =E2=80=94 I=E2=80=99ve been on the internet for >>>>>>>>>>>>> decades and I can barely keep tabs on my GPG keys, and only u= se them when I >>>>>>>>>>>>> am forced to. This is exactly the kind of =E2=80=9Cmarket pre= ssure=E2=80=9D that I think >>>>>>>>>>>>> Ben mentions above, people will just want to outsource that t= o someone >>>>>>>>>>>>> else, and the reality will be a few popular providers. >>>>>>>>>>>>> >>>>>>>>>>>>> In which case, we could end up doing a ton of work to allow a= n >>>>>>>>>>>>> RS choice only to end up with a world where the RS ends up ma= king a limited >>>>>>>>>>>>> choice anyway. We see how that plays out with OpenID Connect = =E2=80=94 RP=E2=80=99s could >>>>>>>>>>>>> allow arbitrary IdPs but they choose Google because it works = and that=E2=80=99s >>>>>>>>>>>>> where the users are. (And that=E2=80=99s not to say anything = of the proprietary >>>>>>>>>>>>> OIDC-like protocols, but that=E2=80=99s another discussion). >>>>>>>>>>>>> >>>>>>>>>>>>> For further reading on these topics, I recommend both =E2=80= =9CWhy >>>>>>>>>>>>> Johnny Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW S= ystems Fail=E2=80=9D. >>>>>>>>>>>>> >>>>>>>>>>>>> So what does this have to do with GNAP? I think we can be >>>>>>>>>>>>> clear-eyed on what kinds of expectations we have for the part= icipants. If >>>>>>>>>>>>> we expect users (RO=E2=80=99s) to have to set up the AS-RS re= lationship, or expect >>>>>>>>>>>>> them to carry their AS, or manage their personal keys =E2=80= =94 I think we=E2=80=99ve lost >>>>>>>>>>>>> the battle for relevance. >>>>>>>>>>>>> >>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>> 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 >>> >> --00000000000073de3605be570771 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    What purpose would be served by GNAP splitting the AS int= o two components?

    Adrian= =C2=A0

    <= div dir=3D"ltr" class=3D"gmail_attr">On Thu, Mar 25, 2021 at 2:59 AM Fabien= Imbault <fabien.imbault@gma= il.com> wrote:
    Isn't the AS-RO a component of the AS? Same idea as the interact c= omponent, it functionnally belongs to the AS role but could be deployed eit= her as a monolith or as a separate component?

    Fabien

    Le jeu. 25 mars 2021 = =C3=A0 04:26, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    Yes, but I would say it= =E2=80=99s not the RO that wants the access token. It=E2=80=99s the RO that= wants the client making the request to get an access token.=C2=A0

    Adrian

    On Wed, Mar 24, 2021= at 11:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Adrian Gropper <agropper@healthurl.com&= gt; wrote:

    In this design, the AS is the A= S-RS and the agent is the AS-RO. By my definition, this model has two ASs s= ince both are processing requests into tokens. The problem with this is com= plexity and privacy. The RO may not want to share the request information w= ith the AS-RS.

    More precisely, RO has no choice but to present the required informa= tion to AS-RS if RO wants an access token.=C2=A0 However, RO does not want = AS-RS to know the policy by which RO delegates tokens.=C2=A0 That's why= RO uses AS-RO for those delegations.

    --------------
    Alan Karp

    <= /div>

    On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper <agr= opper@healthurl.com> wrote:
    Thank you for creating= the issue. My definition of AS is independent of AS-RO or AS-RS.=C2=A0https://github.com/i= etf-wg-gnap/gnap-core-protocol/issues/223#issuecomment-806280421 I also= agree with Alan's definition based on delegation. An AS-RS would be a = delegate of the RS.=C2=A0

    Based on tha= t, I see it as obvious=C2=A0that the policy has to be accessible (defined l= ocally?) in order for it to be run as the code that turns a request into an= access token.=C2=A0

    The only other possibility is= that the request is packaged by the AS and sent elsewhere (an agent) for e= valuation against policy and a proto-token returned. In that case the AS is= acting as a proxy and the PDP is elsewhere. I can imagine that an AS-RS wo= uld behave this way so that the proto-token could be turned into an access = token by the AS-RS. Isn't this what Justin is proposing? In this design= , the AS is the AS-RS and the agent is the AS-RO. By my definition, this mo= del has two ASs since both are processing requests into tokens. The problem= with this is complexity and privacy. The RO may not want to share the requ= est information with the AS-RS.

    Adrian
    =
    On Wed= , Mar 24, 2021 at 5:21 PM Fabien Imbault <fabien.imbault@gmail.com= > wrote:
    =
    Isn't that what the AS is supposed to be, only w= ith the caveat that the policy is defined locally?=C2=A0
    <= br>
    Fabien=C2=A0


    Le mer. 24 mars 2021 =C3=A0 20:1= 7, Alan Karp <alanhkarp@gmail.com> a =C3=A9crit=C2=A0:
    =
    AS-RO is an AS that RO trusts to delegate RO's access tokens a= ccording to RO's policies.=C2=A0=C2=A0

    --------------
    Alan Karp


    On Wed, Mar 24, 202= 1 at 9:36 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan and Adrian,

    A first question that arises: can we give a d= efinition to AS-RO?

    Thanks
    Fabien
    <= /div>
    O= n Tue, Mar 23, 2021 at 4:15 PM Alan Karp <alanhkarp@gmail.co= m> wrote:
    Fabien Imbault <fabien.= imbault@gmail.com> wrote:
    Hi Alan,=C2=A0

    Yes, bu= t in that flow, the token relationship between AS-RS and AS-RO is only secu= re if the tokens issued by AS-RS are cryptographically attenuable in the fi= rst place.=C2=A0
    =C2=A0
    Attenuated delegation is a requirement, but that doesn't have to b= e done cryptographically.=C2=A0 Token exchange works just fine.=C2=A0 SPKI = and zcap-ld are examples of the crypto approach, and we used token exchange= in the system for HP.

    --------------
    Alan= Karp


    On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan,=C2=A0
    <= br>
    Yes, but in that flow, the token relationship between AS-RS a= nd AS-RO is only secure if the tokens issued by AS-RS are cryptographically= attenuable in the first place.=C2=A0

    Fabien
    =

    = On Mon, Mar 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.c= om> wrote:
    J= ustin Richer <jricher@mit.edu> wrote:

    But with a= ll that in mind, I think the key here is going to be looking at what the in= puts to the AS are, and how those can be defined in an interoperable way fo= r AS=E2=80=99s that can accept them. I think there=E2=80=99s a lot of room = for innovation and flexibility here that doesn=E2=80=99t break the trust mo= del or core use cases. If I have an AS-RS set that won=E2=80=99t accept my = favorite flavor of policy engine inputs, then I can decide not to use that = one. But this is a very different question than saying the RS itself needs = to accept my own AS =E2=80=94 and we can=E2=80=99t keep conflating these tw= o models.

    I agree.=C2=A0 The po= int of having an AS-RO is to allow RO to specify a policy for which of RO&#= 39;s access tokens should be delegated under what conditions.=C2=A0 AS-RS s= hould not need to understand those policies.=C2=A0 The flow would be
    <= div>
    • RO contacts AS-RS and gets one or more access tokens.
    • R= O delegates one or more of those tokens, potentially sub-scoped, to AS-RO.<= /li>
    • A different user contacts AS-RO to get a potentially sub-scoped acc= ess token from AS-RO.
    • That user presents the access token delegated= by AS-RO when invoking the resource.
    AS-RS only n= eeds to verify that the delegation chain is legitimate, e.g., no increase i= n scope, and that it grants permission for the request being made.=C2=A0 AS= -RS does not need to understand the policy behind granting the delegation b= y AS-RO.

    --------------
    Alan Karp
    <= br>

    On Mon, Mar 22, 2021 at 11:40 AM Justin Richer <jricher@mit.e= du> wrote:
    On Mar 22, 2021, at 2:14 PM, Adrian Gropper <agropper@h= ealthurl.com> wrote:

    I'm sorry, J= ustin. As a Resource Owner, I look at the RS trust boundary (the dotted lin= e in the diagram) as being the RS. I don't expect any visibility into w= hat's going on on the=C2=A0right.=C2=A0

    My problem w= ith the framing you propose is that requests are going to the RS (or the AS= -RS) and I don't want to share my policies with the AS-RS. I want to ke= ep the RS and AS-RS as ignorant as possible.

    Adria= n

    On Mon, Mar 22, 2021 at 1:48 PM Justin Richer <jricher@mi= t.edu> wrote:
    Adrian,

    What you=E2=80=99re discussing below, = in terms of logging in to a site, is not approaching the RS. You are in fac= t approaching the client, and identifying both the AS and RS to the client.= The client is a client of your identity in this model, and the RS i= s part of the identity provider. It=E2=80=99s really important that we don= =E2=80=99t conflate the RS and client in this way as it leads to a lot of c= onfusion downstream and a lot of broken trust boundaries.

    With that model in mind, approaching the =E2=80=9CRS" and prov= iding it your identity is really just a case of the =E2=80=9Cfederated logi= n to AS=E2=80=9D pattern that we discussed on the WG call. The user here ap= proaches an RS, which has its own AS. To share things from this RS, the RO = has to authenticate to the RS=E2=80=99s AS. This particular AS allows the R= O to do so using an external identity =E2=80=94 in which case, the AS is no= w a =E2=80=9Cclient=E2=80=9D of a separate, disconnected (but layered) dele= gation. The ultimate client that eventually calls the RS down the way may o= r may not know about these layers.=C2=A0

    <PastedGraphic-1.png>
    This same AS, which is= closely tied to the RS and trusted by the RS, might also take in FIDO cred= entials, or DIDs, or any number of other proof mechanisms. The output of th= is is an access token the RS trusts, but the input is up to the AS. The RS = is not what you=E2=80=99re logging in to.

    =C2=A0= =E2=80=94 Justin

    On Mar 22, 2021= , at 1:28 PM, Adrian Gropper <agropper@healthurl.com&= gt; wrote:

    I too am in favor of avoiding con= solidation and correlation. Right now, when I approach a service provider (= RS) for the first time, I'm offered the opportunity to identify my pers= ona as: email, sign-in with Google, Facebook, or Apple. I know there are pe= ople who try to create one-off email addresses but that is mostly a waste o= f time.=C2=A0

    So, along come FIDO2 and DID wallets to th= e rescue. Now, in theory, I have a way to start out my RS relationship pseu= donymously.=C2=A0

    When I want my resource to be di= scovered or shared I will post that RS URL including my pseudonym. If I the= n want to introduce a mediator=C2=A0in front of my AS or messaging service= =C2=A0endpoint, I have that option. If I want to keep requests away from th= e mediator, I would publish an encryption key along with my pseudonym.

    - Adrian



    =
    On Mon, Ma= r 22, 2021 at 9:55 AM Justin Richer <jricher@mit.edu> wro= te:
    On Mar 21, 2= 021, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhkarp@gmail.com> shared a ta= lk about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/14= 5#issuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listi= nfo/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>
    --00000000000073de3605be570771-- From nobody Thu Mar 25 00:08:08 2021 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 792A53A132E for ; Thu, 25 Mar 2021 00:08:05 -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 0ZT7gioYfC_B for ; Thu, 25 Mar 2021 00:08:00 -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 E98BB3A132A for ; Thu, 25 Mar 2021 00:07:59 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id 19so1320658ilj.2 for ; Thu, 25 Mar 2021 00:07: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=SBPIdSwW3VJJmhdA1ogDltBtDjHpUkQh+9oRsqAqhcw=; b=ObJr6axEdszneVN9Kh0PVCH1K2UcZDMYivnLHzbd0XHY4W0IlJJaonZ78fdqt3Q4da zrZclVH83dEvk05gTt3r47HbZw2N0koCL3KpRFJTwRVTRUG0LG/xG5KgKW8vFF0uW47h rJZra5g9iMbro4LuQLEci6liD+WLeyogmcH5UHB3RJWj19bJhHB16Nb7iujhX6tprY6Y xUPjfx40ZQp3AyC/Ngpi9EXl032+hHdXWQA8YGK96ccjSYBf7WFmM8PSlAK07gPs9MQ3 nbyuhHx6zllkEtt9vV8wZX/PqkhE4hBgkrSXEa7SLvHI3FmwsUn2S+AXqSe8sAy6LAon cl+w== 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=SBPIdSwW3VJJmhdA1ogDltBtDjHpUkQh+9oRsqAqhcw=; b=MULzJZ3plxI1ZDtF7z4vLaqwkwSbDQ4hAogYIas7ZU5fWN0WBrsqaJojgLfsXu52QR o/9GDvUd4tZw/R6Z0wGRaQR+ynEsBFDYrWYYhLg8GfTkQDl74HJ/BfHT/krvshYy8CBu eJKLcYMFUQQuExlboEu/x00UUg0DThCcFb4D2K4m2W1F0e5nNkNLM5abFbGM5vLa9GVv 4Lhd3fEbubM+JBDVfGgvfd2nOJITjEI6WHCcsc6HXEWkYK5wAKewe0JIprqhiEFJc0/d WqbeanS2EYcbVX4ll9yEFNfxt7YaDemrl2gYu5gYFOy6LNQ/mkY1dCfjpxKgUyVjTTMY lYVg== X-Gm-Message-State: AOAM531zuw+x0sZ3+AXYW/HLksobM6Vxk5T7nkFEI8zEGFFgYOC+KSRV mkq0bs7Jub40WfM3jg2v9o2hdehzusdGNTVspiGu9180uSk= X-Google-Smtp-Source: ABdhPJxajLLLWWMj6/Saut0/MxbAaO0CyUgJgjqjp05it134YADFfTFZH0lUUiQswEH141dFYntKwMTTCdoNp7oT/T0= X-Received: by 2002:a92:c6d0:: with SMTP id v16mr5343883ilm.289.1616656077882; Thu, 25 Mar 2021 00:07:57 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> In-Reply-To: From: Fabien Imbault Date: Thu, 25 Mar 2021 08:07:43 +0100 Message-ID: To: Adrian Gropper Cc: Alan Karp , Benjamin Kaduk , GNAP Mailing List , Justin Richer , Mark Miller Content-Type: multipart/alternative; boundary="0000000000003f0a0c05be57139a" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 07:08:06 -0000 --0000000000003f0a0c05be57139a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The purpose of either handling policies locally or delegating them to the RO agent. Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper = a =C3=A9crit : > What purpose would be served by GNAP splitting the AS into two components= ? > > Adrian > > On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault > wrote: > >> Isn't the AS-RO a component of the AS? Same idea as the interact >> component, it functionnally belongs to the AS role but could be deployed >> either as a monolith or as a separate component? >> >> Fabien >> >> Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper a >> =C3=A9crit : >> >>> Yes, but I would say it=E2=80=99s not the RO that wants the access toke= n. It=E2=80=99s >>> the RO that wants the client making the request to get an access token. >>> >>> Adrian >>> >>> On Wed, Mar 24, 2021 at 11:22 PM Alan Karp wrote: >>> >>>> Adrian Gropper wrote: >>>> >>>>> >>>>> In this design, the AS is the AS-RS and the agent is the AS-RO. By my >>>>> definition, this model has two ASs since both are processing requests= into >>>>> tokens. The problem with this is complexity and privacy. The RO may n= ot >>>>> want to share the request information with the AS-RS. >>>>> >>>> >>>> More precisely, RO has no choice but to present the required >>>> information to AS-RS if RO wants an access token. However, RO does no= t >>>> want AS-RS to know the policy by which RO delegates tokens. That's wh= y RO >>>> uses AS-RO for those delegations. >>>> >>>> -------------- >>>> Alan Karp >>>> >>>> >>>> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper >>>> wrote: >>>> >>>>> Thank you for creating the issue. My definition of AS is independent >>>>> of AS-RO or AS-RS. >>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issueco= mment-806280421 >>>>> I also agree with Alan's definition based on delegation. An AS-RS wou= ld be >>>>> a delegate of the RS. >>>>> >>>>> Based on that, I see it as obvious that the policy has to be >>>>> accessible (defined locally?) in order for it to be run as the code t= hat >>>>> turns a request into an access token. >>>>> >>>>> The only other possibility is that the request is packaged by the AS >>>>> and sent elsewhere (an agent) for evaluation against policy and a >>>>> proto-token returned. In that case the AS is acting as a proxy and th= e PDP >>>>> is elsewhere. I can imagine that an AS-RS would behave this way so th= at the >>>>> proto-token could be turned into an access token by the AS-RS. Isn't = this >>>>> what Justin is proposing? In this design, the AS is the AS-RS and the= agent >>>>> is the AS-RO. By my definition, this model has two ASs since both are >>>>> processing requests into tokens. The problem with this is complexity = and >>>>> privacy. The RO may not want to share the request information with th= e >>>>> AS-RS. >>>>> >>>>> Adrian >>>>> >>>>> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Isn't that what the AS is supposed to be, only with the caveat that >>>>>> the policy is defined locally? >>>>>> >>>>>> Fabien >>>>>> >>>>>> >>>>>> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp a >>>>>> =C3=A9crit : >>>>>> >>>>>>> AS-RO is an AS that RO trusts to delegate RO's access tokens >>>>>>> according to RO's policies. >>>>>>> >>>>>>> -------------- >>>>>>> Alan Karp >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>> >>>>>>>> Hi Alan and Adrian, >>>>>>>> >>>>>>>> I've created issue AS-RO policy delegation ( >>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to >>>>>>>> capture your input. >>>>>>>> A first question that arises: can we give a definition to AS-RO? >>>>>>>> >>>>>>>> Thanks >>>>>>>> Fabien >>>>>>>> >>>>>>>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Fabien Imbault wrote: >>>>>>>>> >>>>>>>>>> Hi Alan, >>>>>>>>>> >>>>>>>>>> Yes, but in that flow, the token relationship between AS-RS and >>>>>>>>>> AS-RO is only secure if the tokens issued by AS-RS are cryptogra= phically >>>>>>>>>> attenuable in the first place. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Attenuated delegation is a requirement, but that doesn't have to >>>>>>>>> be done cryptographically. Token exchange works just fine. SPKI= and >>>>>>>>> zcap-ld are examples of the crypto approach, and we used token ex= change in >>>>>>>>> the system for HP. >>>>>>>>> >>>>>>>>> -------------- >>>>>>>>> Alan Karp >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault < >>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hi Alan, >>>>>>>>>> >>>>>>>>>> Yes, but in that flow, the token relationship between AS-RS and >>>>>>>>>> AS-RO is only secure if the tokens issued by AS-RS are cryptogra= phically >>>>>>>>>> attenuable in the first place. >>>>>>>>>> >>>>>>>>>> Fabien >>>>>>>>>> >>>>>>>>>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Justin Richer wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> But with all that in mind, I think the key here is going to be >>>>>>>>>>>> looking at what the inputs to the AS are, and how those can be= defined in >>>>>>>>>>>> an interoperable way for AS=E2=80=99s that can accept them. I = think there=E2=80=99s a lot >>>>>>>>>>>> of room for innovation and flexibility here that doesn=E2=80= =99t break the trust >>>>>>>>>>>> model or core use cases. If I have an AS-RS set that won=E2=80= =99t accept my >>>>>>>>>>>> favorite flavor of policy engine inputs, then I can decide not= to use that >>>>>>>>>>>> one. But this is a very different question than saying the RS = itself needs >>>>>>>>>>>> to accept my own AS =E2=80=94 and we can=E2=80=99t keep confla= ting these two models. >>>>>>>>>>>> >>>>>>>>>>>> I agree. The point of having an AS-RO is to allow RO to >>>>>>>>>>> specify a policy for which of RO's access tokens should be dele= gated under >>>>>>>>>>> what conditions. AS-RS should not need to understand those pol= icies. The >>>>>>>>>>> flow would be >>>>>>>>>>> >>>>>>>>>>> - RO contacts AS-RS and gets one or more access tokens. >>>>>>>>>>> - RO delegates one or more of those tokens, potentially >>>>>>>>>>> sub-scoped, to AS-RO. >>>>>>>>>>> - A different user contacts AS-RO to get a potentially >>>>>>>>>>> sub-scoped access token from AS-RO. >>>>>>>>>>> - That user presents the access token delegated by AS-RO >>>>>>>>>>> when invoking the resource. >>>>>>>>>>> >>>>>>>>>>> AS-RS only needs to verify that the delegation chain is >>>>>>>>>>> legitimate, e.g., no increase in scope, and that it grants perm= ission for >>>>>>>>>>> the request being made. AS-RS does not need to understand the = policy >>>>>>>>>>> behind granting the delegation by AS-RO. >>>>>>>>>>> >>>>>>>>>>> -------------- >>>>>>>>>>> Alan Karp >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Adrian, >>>>>>>>>>>> >>>>>>>>>>>> I think this shows the problem with the terminology as it=E2= =80=99s >>>>>>>>>>>> been applied in this conversation, which I=E2=80=99ve tried to= shine light on >>>>>>>>>>>> before. What you and others are calling the =E2=80=9CRS=E2=80= =9D is really the =E2=80=9CAS and RS >>>>>>>>>>>> working together=E2=80=9D =E2=80=94 everything to the right of= the line. When Denis had >>>>>>>>>>>> brought up =E2=80=9Celiminating the AS=E2=80=9D in another thr= ead, what he=E2=80=99d really done is >>>>>>>>>>>> labeled everything to the right of the line as the =E2=80=9CRS= =E2=80=9D. Of course, the >>>>>>>>>>>> irony here is that everything to the right of the line used al= l be called >>>>>>>>>>>> the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80=9D in= the OAuth 1 days. As you say below, I don=E2=80=99t >>>>>>>>>>>> want the client to have visibility on what happens on that sid= e. >>>>>>>>>>>> >>>>>>>>>>>> Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in t= he diagram is not >>>>>>>>>>>> the AS, as far as GNAP is concerned. It does not issue an acce= ss token that >>>>>>>>>>>> the RS will accept. The elements to the left of the line could= be a lot of >>>>>>>>>>>> things, but they are NOT the AS =E2=80=94 by definition. The c= lient lives over on >>>>>>>>>>>> the left, but so do any external inputs to the AS. These could= be policy >>>>>>>>>>>> inputs on behalf of the RO, they could be presentation artifac= ts, they >>>>>>>>>>>> could be federated logins, they could be the output of policy = decisions. >>>>>>>>>>>> How the AS comes to trust those things is up to the AS=E2=80= =99s implementation. >>>>>>>>>>>> It=E2=80=99s something we can talk about, but ultimately GNAP = won=E2=80=99t be in any >>>>>>>>>>>> position to dictate because in practice some AS=E2=80=99s are = simply going to >>>>>>>>>>>> internalize all policies and we will never successfully force = those open. >>>>>>>>>>>> >>>>>>>>>>>> But with all that in mind, I think the key here is going to be >>>>>>>>>>>> looking at what the inputs to the AS are, and how those can be= defined in >>>>>>>>>>>> an interoperable way for AS=E2=80=99s that can accept them. I = think there=E2=80=99s a lot >>>>>>>>>>>> of room for innovation and flexibility here that doesn=E2=80= =99t break the trust >>>>>>>>>>>> model or core use cases. If I have an AS-RS set that won=E2=80= =99t accept my >>>>>>>>>>>> favorite flavor of policy engine inputs, then I can decide not= to use that >>>>>>>>>>>> one. But this is a very different question than saying the RS = itself needs >>>>>>>>>>>> to accept my own AS =E2=80=94 and we can=E2=80=99t keep confla= ting these two models. >>>>>>>>>>>> >>>>>>>>>>>> So to me, GNAP can support a Zero Trust Architecture by >>>>>>>>>>>> LEVERAGING the AS, not by subsuming or eliminating it. It is i= n fact the >>>>>>>>>>>> AS, not the client and not the RS, that will request and consu= me the >>>>>>>>>>>> results of a privacy-preserving zero-trust policy query thing.= Anything >>>>>>>>>>>> that happens downstream from that is of little concern to the = zero-trust >>>>>>>>>>>> components because, as you point out, it=E2=80=99s on the =E2= =80=9Cother side=E2=80=9D of the line. >>>>>>>>>>>> >>>>>>>>>>>> I think we got this basic component model pretty right in >>>>>>>>>>>> OAuth: the AS and RS and client working together. Where OAuth = misses the >>>>>>>>>>>> mark is the assumption that the user has to log in to the AS t= hrough a >>>>>>>>>>>> webpage and interact directly, thereby proving they=E2=80=99re= the RO. It=E2=80=99s this >>>>>>>>>>>> latter space where I think we can both push innovation and als= o address the >>>>>>>>>>>> important and compelling use cases like the ones you=E2=80=99r= e bringing. >>>>>>>>>>>> >>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>> >>>>>>>>>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper < >>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> I'm sorry, Justin. As a Resource Owner, I look at the RS trust >>>>>>>>>>>> boundary (the dotted line in the diagram) as being the RS. I d= on't expect >>>>>>>>>>>> any visibility into what's going on on the right. >>>>>>>>>>>> >>>>>>>>>>>> My problem with the framing you propose is that requests are >>>>>>>>>>>> going to the RS (or the AS-RS) and I don't want to share my po= licies with >>>>>>>>>>>> the AS-RS. I want to keep the RS and AS-RS as ignorant as poss= ible. >>>>>>>>>>>> >>>>>>>>>>>> Adrian >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Adrian, >>>>>>>>>>>>> >>>>>>>>>>>>> What you=E2=80=99re discussing below, in terms of logging in = to a >>>>>>>>>>>>> site, is not approaching the RS. You are in fact approaching = the client, >>>>>>>>>>>>> and identifying both the AS and RS to the client. The client = is a client *of >>>>>>>>>>>>> your identity* in this model, and the RS is part of the >>>>>>>>>>>>> identity provider. It=E2=80=99s really important that we don= =E2=80=99t conflate the RS and >>>>>>>>>>>>> client in this way as it leads to a lot of confusion downstre= am and a lot >>>>>>>>>>>>> of broken trust boundaries. >>>>>>>>>>>>> >>>>>>>>>>>>> With that model in mind, approaching the =E2=80=9CRS" and pro= viding it >>>>>>>>>>>>> your identity is really just a case of the =E2=80=9Cfederated= login to AS=E2=80=9D pattern >>>>>>>>>>>>> that we discussed on the WG call. The user here approaches an= RS, which has >>>>>>>>>>>>> its own AS. To share things from this RS, the RO has to authe= nticate to the >>>>>>>>>>>>> RS=E2=80=99s AS. This particular AS allows the RO to do so us= ing an external >>>>>>>>>>>>> identity =E2=80=94 in which case, the AS is now a =E2=80=9Ccl= ient=E2=80=9D of a separate, >>>>>>>>>>>>> disconnected (but layered) delegation. The ultimate client th= at eventually >>>>>>>>>>>>> calls the RS down the way may or may not know about these lay= ers. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> This same AS, which is closely tied to the RS and trusted by >>>>>>>>>>>>> the RS, might also take in FIDO credentials, or DIDs, or any = number of >>>>>>>>>>>>> other proof mechanisms. The output of this is an access token= the RS >>>>>>>>>>>>> trusts, but the input is up to the AS. The RS is not what you= =E2=80=99re logging in >>>>>>>>>>>>> to. >>>>>>>>>>>>> >>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>> >>>>>>>>>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper < >>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> I too am in favor of avoiding consolidation and correlation. >>>>>>>>>>>>> Right now, when I approach a service provider (RS) for the fi= rst time, I'm >>>>>>>>>>>>> offered the opportunity to identify my persona as: email, sig= n-in with >>>>>>>>>>>>> Google, Facebook, or Apple. I know there are people who try t= o create >>>>>>>>>>>>> one-off email addresses but that is mostly a waste of time. >>>>>>>>>>>>> >>>>>>>>>>>>> So, along come FIDO2 and DID wallets to the rescue. Now, in >>>>>>>>>>>>> theory, I have a way to start out my RS relationship pseudony= mously. >>>>>>>>>>>>> >>>>>>>>>>>>> When I want my resource to be discovered or shared I will pos= t >>>>>>>>>>>>> that RS URL including my pseudonym. If I then want to introdu= ce a >>>>>>>>>>>>> mediator in front of my AS or messaging service endpoint, I h= ave that >>>>>>>>>>>>> option. If I want to keep requests away from the mediator, I = would publish >>>>>>>>>>>>> an encryption key along with my pseudonym. >>>>>>>>>>>>> >>>>>>>>>>>>> - Adrian >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >> @Alan Karp shared a talk about the >>>>>>>>>>>>>> Principle Of Least >>>>>>>>>>>>>> >> Authority (POLA) in a recent comment >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/14= 5#issuecomment-803099693 >>>>>>>>>>>>>> >> I recommend it. >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> We might expect a protocol with authorization in the titl= e >>>>>>>>>>>>>> to use authority >>>>>>>>>>>>>> >> as a core principle. I advocate for a GNAP design that >>>>>>>>>>>>>> maximizes the power >>>>>>>>>>>>>> >> of the RO, to be seen as a human rights issue when the RO >>>>>>>>>>>>>> is a human. This >>>>>>>>>>>>>> >> causes me to ask how to combine better security with >>>>>>>>>>>>>> better human rights in >>>>>>>>>>>>>> >> GNAP. >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> Who should have the least authority in the GNAP design? >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> The AS derives authority as a delegate of the RO. If we >>>>>>>>>>>>>> ask the RO to >>>>>>>>>>>>>> >> partition limited authority across dozens of different AS= s >>>>>>>>>>>>>> by domain and >>>>>>>>>>>>>> >> function, then we are not using technology to empower the >>>>>>>>>>>>>> individual. >>>>>>>>>>>>>> >> Probably the opposite, as we introduce consent fatigue an= d >>>>>>>>>>>>>> burden normal >>>>>>>>>>>>>> >> people to partition their lives into non-overlapping >>>>>>>>>>>>>> domains. >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> My experience says we should aim for one AS per persona >>>>>>>>>>>>>> because that maps >>>>>>>>>>>>>> >> into the way we manage our public and private identities. >>>>>>>>>>>>>> POLA would then >>>>>>>>>>>>>> >> teach care in keeping ASs and RSs related to work / publi= c >>>>>>>>>>>>>> separate from >>>>>>>>>>>>>> >> ASs and RSs related to private life so that a policy >>>>>>>>>>>>>> vulnerability in our >>>>>>>>>>>>>> >> delegation to an AS would have the least likelihood of >>>>>>>>>>>>>> harm. >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Thinking about how least authority/least privilege would >>>>>>>>>>>>>> apply to GNAP >>>>>>>>>>>>>> > seems like a useful exercise. I do want to point out some >>>>>>>>>>>>>> potential >>>>>>>>>>>>>> > pitfalls with one-AS-per-persona that we can also be aware >>>>>>>>>>>>>> of. If >>>>>>>>>>>>>> > one-AS-per-persona becomes one-persona-per-AS as well, the= n >>>>>>>>>>>>>> the AS's >>>>>>>>>>>>>> > identity in effect also serves as a persona identity and >>>>>>>>>>>>>> there are privacy >>>>>>>>>>>>>> > considerations to that. If, on the other hand, the >>>>>>>>>>>>>> > multiple-personas-per-AS (presumably corresponding to >>>>>>>>>>>>>> multiple humans) >>>>>>>>>>>>>> > route is taken, we should consider whether that would lead >>>>>>>>>>>>>> to various >>>>>>>>>>>>>> > (e.g., market) forces driving consolidation to just a >>>>>>>>>>>>>> handful of >>>>>>>>>>>>>> > super-popular AS services. That topic is a current matter >>>>>>>>>>>>>> of concern to >>>>>>>>>>>>>> > some IETF participants. >>>>>>>>>>>>>> > >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Ben, big +1 to this. This is something that we discussed >>>>>>>>>>>>>> ages ago in the UMA working group, and it=E2=80=99s one of t= he biggest problems >>>>>>>>>>>>>> with the personal AS (and personal data store) model. This k= ind of thing >>>>>>>>>>>>>> makes RS-first trust models really difficult in practice. >>>>>>>>>>>>>> >>>>>>>>>>>>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve got softw= are that wants to >>>>>>>>>>>>>> access my medical information. It calls an RS and requests a= ccess, but it >>>>>>>>>>>>>> hasn=E2=80=99t been granted anything yet. Now I as the RO ha= ve set up the RS so >>>>>>>>>>>>>> that it talks to my personal AS, that only I use. In additio= n to the RS >>>>>>>>>>>>>> having to be able to figure out which medical records are be= ing requested >>>>>>>>>>>>>> from the context of the unauthenticated request (which means= it needs >>>>>>>>>>>>>> identifiers in the URL or something similar for the RS to be= able to tell, >>>>>>>>>>>>>> assuming that it protects data for more than one person). So= this client >>>>>>>>>>>>>> software doesn=E2=80=99t know who I am and doesn=E2=80=99t k= now my medical record >>>>>>>>>>>>>> information, makes a completely unauthorized request to the = RS, and the RS >>>>>>>>>>>>>> says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a to= ken=E2=80=9D. The client can now make a >>>>>>>>>>>>>> direct correlation between the data that=E2=80=99s being pro= tected at the RS and >>>>>>>>>>>>>> the person running the AS that protects it. Importantly, thi= s client makes >>>>>>>>>>>>>> this call with no prior relationship to the RS and no really= auditable way >>>>>>>>>>>>>> to track it down after the fact. This is a design feature in= the good case, >>>>>>>>>>>>>> and terrifying in the bad case. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If the RS instead says =E2=80=9Cwelcome to Medicine Doctor R= S, please >>>>>>>>>>>>>> talk to the Medicine Doctor AS to get access=E2=80=9D, we ha= ven=E2=80=99t exposed anything >>>>>>>>>>>>>> at all. And from the perspective of both the patient and the= RS, this is >>>>>>>>>>>>>> more privacy-preserving, and it=E2=80=99s really the least s= urprising option. Once >>>>>>>>>>>>>> the client gets to the AS, it can start a negotiation of fig= uring out who >>>>>>>>>>>>>> the RO is for the information being accessed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On top of this, the usability expectations of people managin= g >>>>>>>>>>>>>> their own AS, or set of AS=E2=80=99s for multiple personas t= o keep things separate, >>>>>>>>>>>>>> is a huge burden. Even in the tech community, I know people = who can=E2=80=99t >>>>>>>>>>>>>> reliably manage more than one email address for different pu= rposes. I >>>>>>>>>>>>>> wouldn=E2=80=99t expect my partner to do that =E2=80=94 they= have trouble enough balancing >>>>>>>>>>>>>> all the logins and sessions required for different kids remo= te schooling, I >>>>>>>>>>>>>> couldn=E2=80=99t imagine them having to understand all the r= equirements for >>>>>>>>>>>>>> managing multiple authorization servers and associated polic= ies. I also >>>>>>>>>>>>>> don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2= =80=9D =E2=80=94 I=E2=80=99ve been on the internet for >>>>>>>>>>>>>> decades and I can barely keep tabs on my GPG keys, and only = use them when I >>>>>>>>>>>>>> am forced to. This is exactly the kind of =E2=80=9Cmarket pr= essure=E2=80=9D that I think >>>>>>>>>>>>>> Ben mentions above, people will just want to outsource that = to someone >>>>>>>>>>>>>> else, and the reality will be a few popular providers. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In which case, we could end up doing a ton of work to allow >>>>>>>>>>>>>> an RS choice only to end up with a world where the RS ends u= p making a >>>>>>>>>>>>>> limited choice anyway. We see how that plays out with OpenID= Connect =E2=80=94 RP=E2=80=99s >>>>>>>>>>>>>> could allow arbitrary IdPs but they choose Google because it= works and >>>>>>>>>>>>>> that=E2=80=99s where the users are. (And that=E2=80=99s not = to say anything of the >>>>>>>>>>>>>> proprietary OIDC-like protocols, but that=E2=80=99s another = discussion). >>>>>>>>>>>>>> >>>>>>>>>>>>>> For further reading on these topics, I recommend both =E2=80= =9CWhy >>>>>>>>>>>>>> Johnny Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW = Systems Fail=E2=80=9D. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So what does this have to do with GNAP? I think we can be >>>>>>>>>>>>>> clear-eyed on what kinds of expectations we have for the par= ticipants. If >>>>>>>>>>>>>> we expect users (RO=E2=80=99s) to have to set up the AS-RS r= elationship, or expect >>>>>>>>>>>>>> them to carry their AS, or manage their personal keys =E2=80= =94 I think we=E2=80=99ve lost >>>>>>>>>>>>>> the battle for relevance. >>>>>>>>>>>>>> >>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>> 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 >>>> >>> --0000000000003f0a0c05be57139a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    The purpose of either handling policies locally or delega= ting them to the RO agent.=C2=A0

    Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian G= ropper <agropper@healthurl.com= > a =C3=A9crit=C2=A0:
    What purpose would be served by GNAP splitting the AS into two = components?

    Adrian=C2=A0=

    On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbau= lt <fabien.imbault@gmail.com> wrote:
    Isn't the AS-RO a component of the = AS? Same idea as the interact component, it functionnally belongs to the AS= role but could be deployed either as a monolith or as a separate component= ?

    Fabi= en

    Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper <agropper@= healthurl.com> a =C3=A9crit=C2=A0:
    Yes, but I would say it=E2=80=99s not the RO that = wants the access token. It=E2=80=99s the RO that wants the client making th= e request to get an access token.=C2=A0

    Adrian

    On Wed, Mar 24, 2021 at 11:22 PM Alan Karp <<= a href=3D"mailto:alanhkarp@gmail.com" rel=3D"noreferrer noreferrer" target= =3D"_blank">alanhkarp@gmail.com> wrote:
    Adrian Gropper <agropper@healthurl.com>= wrote:

    In this design, the AS is the AS-R= S and the agent is the AS-RO. By my definition, this model has two ASs sinc= e both are processing requests into tokens. The problem with this is comple= xity and privacy. The RO may not want to share the request information with= the AS-RS.

    More precisely, RO has no choice but to present the required informatio= n to AS-RS if RO wants an access token.=C2=A0 However, RO does not want AS-= RS to know the policy by which RO delegates tokens.=C2=A0 That's why RO= uses AS-RO for those delegations.

    --------------
    Alan Karp


    On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Thank you for cr= eating the issue. My definition of AS is independent of AS-RO or AS-RS.=C2= =A0ht= tps://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomment-80= 6280421 I also agree with Alan's definition based on delegation. An= AS-RS would be a delegate of the RS.=C2=A0

    Based on that, I see it as obvious=C2=A0that the policy has to be acc= essible (defined locally?) in order for it to be run as the code that turns= a request into an access token.=C2=A0

    The only ot= her possibility is that the request is packaged by the AS and sent elsewher= e (an agent) for evaluation against policy and a proto-token returned. In t= hat case the AS is acting as a proxy and the PDP is elsewhere. I can imagin= e that an AS-RS would behave this way so that the proto-token could be turn= ed into an access token by the AS-RS. Isn't this what Justin is proposi= ng? In this design, the AS is the AS-RS and the agent is the AS-RO. By my d= efinition, this model has two ASs since both are processing requests into t= okens. The problem with this is complexity and privacy. The RO may not want= to share the request information with the AS-RS.

    = Adrian

    On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Isn't that what the= AS is supposed to be, only with the caveat that the policy is defined loca= lly?=C2=A0

    Fabien=C2=A0
    <= br>
    Le = mer. 24 mars 2021 =C3=A0 20:17, Alan Karp <alanhkarp@gmail.c= om> a =C3=A9crit=C2=A0:
    AS-RO is an AS that RO tru= sts to delegate RO's access tokens according to RO's policies.=C2= =A0=C2=A0

    --------------
    Alan= Karp


    On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault <fabien.imbault@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 Alan a= nd Adrian,

    I've created issue AS-RO policy delegatio= n (https://github= .com/ietf-wg-gnap/gnap-core-protocol/issues/223) to capture your input.= =C2=A0
    A first question that arises: can we give a definition to = AS-RO?

    Thanks
    Fabien

    On Tue, Mar 23= , 2021 at 4:15 PM Alan Karp <alanhkarp@gmail.com= > wrote:
    =
    Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan,=C2=A0

    Yes, but in that flow, the token relationship between AS-RS and AS-RO is= only secure if the tokens issued by AS-RS are cryptographically attenuable= in the first place.=C2=A0
    =C2=A0
    Attenuated delegation is a requirement, but that doesn't= have to be done cryptographically.=C2=A0 Token exchange works just fine.= =C2=A0 SPKI and zcap-ld are examples of the crypto approach, and we used to= ken exchange in the system for HP.

    ----------= ----
    Alan Karp


    On Tue, Mar 23, 2021 at 4:12 AM Fabien Imb= ault <fabien.imbault@gmail.com> wrote= :
    Hi Alan,=C2=A0

    Yes, but in that flow, the token relat= ionship between AS-RS and AS-RO is only secure if the tokens issued by AS-R= S are cryptographically attenuable in the first place.=C2=A0

    =
    Fabien

    On Mon, Mar 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin Richer <jrich= er@mit.edu> wrote:

    But with all that in mind, I think the = key here is going to be looking at what the inputs to the AS are, and how t= hose can be defined in an interoperable way for AS=E2=80=99s that can accep= t them. I think there=E2=80=99s a lot of room for innovation and flexibilit= y here that doesn=E2=80=99t break the trust model or core use cases. If I h= ave an AS-RS set that won=E2=80=99t accept my favorite flavor of policy eng= ine inputs, then I can decide not to use that one. But this is a very diffe= rent question than saying the RS itself needs to accept my own AS =E2=80=94= and we can=E2=80=99t keep conflating these two models.

    I agree.=C2=A0 The point of having an AS-RO is to = allow RO to specify a policy for which of RO's access tokens should be = delegated under what conditions.=C2=A0 AS-RS should not need to understand = those policies.=C2=A0 The flow would be
    • RO contacts AS-RS= and gets one or more access tokens.
    • RO delegates one or more of th= ose tokens, potentially sub-scoped, to AS-RO.
    • A different user cont= acts AS-RO to get a potentially sub-scoped access token from AS-RO.
      • That user presents the access token delegated by AS-RO when invoking the r= esource.
    AS-RS only needs to verify that the deleg= ation chain is legitimate, e.g., no increase in scope, and that it grants p= ermission for the request being made.=C2=A0 AS-RS does not need to understa= nd the policy behind granting the delegation by AS-RO.

    --------------
    Alan Karp


    On Mon, Mar 22, 2021 at 11= :40 AM Justin Richer <jricher@mit.edu> wrote:<= br>
    Adrian,
    I think this shows the problem with the terminology as it= =E2=80=99s been applied in this conversation, which I=E2=80=99ve tried to s= hine light on before. What you and others are calling the =E2=80=9CRS=E2=80= =9D is really the =E2=80=9CAS and RS working together=E2=80=9D =E2=80=94 ev= erything to the right of the line. When Denis had brought up =E2=80=9Celimi= nating the AS=E2=80=9D in another thread, what he=E2=80=99d really done is = labeled everything to the right of the line as the =E2=80=9CRS=E2=80=9D. Of= course, the irony here is that everything to the right of the line used al= l be called the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80=9D in = the OAuth 1 days. As you say below, I don=E2=80=99t want the client to have= visibility on what happens on that side.=C2=A0

    No= te well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the diagram is n= ot the AS, as far as GNAP is concerned. It does not issue an access token t= hat the RS will accept. The elements to the left of the line could be a lot= of things, but they are NOT the AS =E2=80=94 by definition. The client liv= es over on the left, but so do any external inputs to the AS. These could b= e policy inputs on behalf of the RO, they could be presentation artifacts, = they could be federated logins, they could be the output of policy decision= s. How the AS comes to trust those things is up to the AS=E2=80=99s impleme= ntation. It=E2=80=99s something we can talk about, but ultimately GNAP won= =E2=80=99t be in any position to dictate because in practice some AS=E2=80= =99s are simply going to internalize all policies and we will never success= fully force those open.=C2=A0

    But with all that in= mind, I think the key here is going to be looking at what the inputs to th= e AS are, and how those can be defined in an interoperable way for AS=E2=80= =99s that can accept them. I think there=E2=80=99s a lot of room for innova= tion and flexibility here that doesn=E2=80=99t break the trust model or cor= e use cases. If I have an AS-RS set that won=E2=80=99t accept my favorite f= lavor of policy engine inputs, then I can decide not to use that one. But t= his is a very different question than saying the RS itself needs to accept = my own AS =E2=80=94 and we can=E2=80=99t keep conflating these two models.<= /div>

    So to me, GNAP can support a Zero Trust Architectu= re by LEVERAGING the AS, not by subsuming or eliminating it. It is in fact = the AS, not the client and not the RS, that will request and consume the re= sults of a privacy-preserving zero-trust policy query thing. Anything that = happens downstream from that is of little concern to the zero-trust compone= nts because, as you point out, it=E2=80=99s on the =E2=80=9Cother side=E2= =80=9D of the line.=C2=A0

    I think we got this basi= c component model pretty right in OAuth: the AS and RS and client working t= ogether. Where OAuth misses the mark is the assumption that the user has to= log in to the AS through a webpage and interact directly, thereby proving = they=E2=80=99re the RO. It=E2=80=99s this latter space where I think we can= both push innovation and also address the important and compelling use cas= es like the ones you=E2=80=99re bringing.

    =C2=A0= =E2=80=94 Justin

    On Mar 22, 2021= , at 2:14 PM, Adrian Gropper <agropper@healthu= rl.com> wrote:

    I'm sorry, Justin.= As a Resource Owner, I look at the RS trust boundary (the dotted line in t= he diagram) as being the RS. I don't expect any visibility into what= 9;s going on on the=C2=A0right.=C2=A0

    My problem with th= e framing you propose is that requests are going to the RS (or the AS-RS) a= nd I don't want to share my policies with the AS-RS. I want to keep the= RS and AS-RS as ignorant as possible.

    Adrian

    On Mon, Mar 22, 2021 at 1:48 PM Justin Richer <jrich= er@mit.edu> wrote:
    Adrian,

    What you=E2=80=99re discussing b= elow, in terms of logging in to a site, is not approaching the RS. You are = in fact approaching the client, and identifying both the AS and RS to the c= lient. The client is a client of your identity in this model, and th= e RS is part of the identity provider. It=E2=80=99s really important that w= e don=E2=80=99t conflate the RS and client in this way as it leads to a lot= of confusion downstream and a lot of broken trust boundaries.
    With that model in mind, approaching the =E2=80=9CRS" and= providing it your identity is really just a case of the =E2=80=9Cfederated= login to AS=E2=80=9D pattern that we discussed on the WG call. The user he= re approaches an RS, which has its own AS. To share things from this RS, th= e RO has to authenticate to the RS=E2=80=99s AS. This particular AS allows = the RO to do so using an external identity =E2=80=94 in which case, the AS = is now a =E2=80=9Cclient=E2=80=9D of a separate, disconnected (but layered)= delegation. The ultimate client that eventually calls the RS down the way = may or may not know about these layers.=C2=A0

    <PastedGraphic-1.png>
    <= div>This same AS, which is closely tied to the RS and trusted by the RS, mi= ght also take in FIDO credentials, or DIDs, or any number of other proof me= chanisms. The output of this is an access token the RS trusts, but the inpu= t is up to the AS. The RS is not what you=E2=80=99re logging in to.

    =C2=A0=E2=80=94 Justin

    On Mar 22, 2021, at 1:28 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I too am in favor of avoiding consolidation and correlation. Right now, w= hen I approach a service provider (RS) for the first time, I'm offered = the opportunity to identify my persona as: email, sign-in with Google, Face= book, or Apple. I know there are people who try to create one-off email add= resses but that is mostly a waste of time.=C2=A0

    So, alo= ng come FIDO2 and DID wallets to the rescue. Now, in theory, I have a way t= o start out my RS relationship pseudonymously.=C2=A0

    When I want my resource to be discovered or shared I will post that RS U= RL including my pseudonym. If I then want to introduce a mediator=C2=A0in f= ront of my AS or messaging service=C2=A0endpoint, I have that option. If I = want to keep requests away from the mediator, I would publish an encryption= key along with my pseudonym.

    - Adrian
    <= br>


    On Mon, Mar 22, 2021 at 9:55 AM Justin Richer <<= a href=3D"mailto:jricher@mit.edu" rel=3D"noreferrer noreferrer noreferrer" = target=3D"_blank">jricher@mit.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin Kadu= k <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhkarp@gmail.com> = shared a talk about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-gnap/gnap-core-protoco= l/issues/145#issuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/ma= ilman/listinfo/txauth
    --
    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/listi= nfo/txauth
    --0000000000003f0a0c05be57139a-- From nobody Thu Mar 25 00:11:09 2021 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 0E29E3A1347 for ; Thu, 25 Mar 2021 00:11:07 -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, 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 15B_OucYcL-v for ; Thu, 25 Mar 2021 00:11:01 -0700 (PDT) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 50D623A1345 for ; Thu, 25 Mar 2021 00:11:01 -0700 (PDT) Received: by mail-il1-x135.google.com with SMTP id l5so1287458ilv.9 for ; Thu, 25 Mar 2021 00:11: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=/t3M+hIU4of0ZCsgTsjbXorVsAejfD1/yXCBVewozIc=; b=LXdjaTu9wRJTIM+mrxfeUhC/CVdf6ONyLIxdzBntp8UKp0lIW5tOBJrGZKlWflu6C8 YnNGUz1Q6ZF/okFS9PyeSq/VF58D+OVsg+OvCbE1ePivpENctjoean74n81s8TQ4fItx +5BQzrqAIv6Qn0VVWVWm5gBo52w0D5/HedB+BpdBIPSvGJlHRp9ueUO5IKYyIiI92EGl ELmijotpVgdpQKh9ffA7cBht44yCpOnwSYliQdYsFXISqhQtJnUpwQZ2rwhkzeqDaLVL byv7RjbzXXxYuPwzfhMa84whGEdnCrRbqqi4gHYB8OpPXtnEzhWVuIuYoakKB6qfG8F0 JCQA== 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=/t3M+hIU4of0ZCsgTsjbXorVsAejfD1/yXCBVewozIc=; b=S7JPHzzpT4LFuoDvAJ9syj5h3yqEM+oczRCCLtJxPNaXSmFqake1MCGteOmfyeXpNG S187Yn5ntIIR9P3FKpUG0QLKQaUanmcTX4CnL9kXfFkP+fjV15pL3sAq1tL+gv3/PEgj DUA0gcr/0G1Dcg76UNJgDrz3pbc/mltdkqba0Q+IgdO9z8YJ6Lthu7/DwWznkbemo6om E84pBbzYsLBu+VQYWtPYLW4YSimq23h6jz7/2ZUysOoBlOap7go/9kwsWIkCGMSRFW6B kbQQT5JNRsxxB/Kr5pPgmMqVeTuZsiZajHubaPETHs6C2nIwBAoadkiacoVgwVQzu8ne gXWQ== X-Gm-Message-State: AOAM531qkT0wrdPe4wlR3RJhye2k1oFnqVU8ytf29aYGpBJRlGEUAQfg NnVJ+O9ITYI7omfO7O6w74Ux5ZqXSkQAt2CwJ0k= X-Google-Smtp-Source: ABdhPJx/gLl/58FiCahyI2+AcGuoyLN/rbYIS0H9IHOy4en4CmQmJdql7CCm0Izfi0XoJ7xS5Ampa5nlk+U6hdFwHpE= X-Received: by 2002:a92:c6d0:: with SMTP id v16mr5350272ilm.289.1616656259209; Thu, 25 Mar 2021 00:10:59 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> In-Reply-To: From: Fabien Imbault Date: Thu, 25 Mar 2021 08:10:46 +0100 Message-ID: To: Adrian Gropper Cc: Alan Karp , Benjamin Kaduk , GNAP Mailing List , Justin Richer , Mark Miller Content-Type: multipart/alternative; boundary="0000000000000ddef305be571ef1" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 07:11:07 -0000 --0000000000000ddef305be571ef1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Note : I'm not sure that's a good idea, but having 2 types of ASs is not that easy to grasp. Fabien Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault a =C3=A9crit : > The purpose of either handling policies locally or delegating them to the > RO agent. > > Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper a > =C3=A9crit : > >> What purpose would be served by GNAP splitting the AS into two component= s? >> >> Adrian >> >> On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault >> wrote: >> >>> Isn't the AS-RO a component of the AS? Same idea as the interact >>> component, it functionnally belongs to the AS role but could be deploye= d >>> either as a monolith or as a separate component? >>> >>> Fabien >>> >>> Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper a >>> =C3=A9crit : >>> >>>> Yes, but I would say it=E2=80=99s not the RO that wants the access tok= en. It=E2=80=99s >>>> the RO that wants the client making the request to get an access token= . >>>> >>>> Adrian >>>> >>>> On Wed, Mar 24, 2021 at 11:22 PM Alan Karp wrote= : >>>> >>>>> Adrian Gropper wrote: >>>>> >>>>>> >>>>>> In this design, the AS is the AS-RS and the agent is the AS-RO. By m= y >>>>>> definition, this model has two ASs since both are processing request= s into >>>>>> tokens. The problem with this is complexity and privacy. The RO may = not >>>>>> want to share the request information with the AS-RS. >>>>>> >>>>> >>>>> More precisely, RO has no choice but to present the required >>>>> information to AS-RS if RO wants an access token. However, RO does n= ot >>>>> want AS-RS to know the policy by which RO delegates tokens. That's w= hy RO >>>>> uses AS-RO for those delegations. >>>>> >>>>> -------------- >>>>> Alan Karp >>>>> >>>>> >>>>> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper >>>>> wrote: >>>>> >>>>>> Thank you for creating the issue. My definition of AS is independent >>>>>> of AS-RO or AS-RS. >>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuec= omment-806280421 >>>>>> I also agree with Alan's definition based on delegation. An AS-RS wo= uld be >>>>>> a delegate of the RS. >>>>>> >>>>>> Based on that, I see it as obvious that the policy has to be >>>>>> accessible (defined locally?) in order for it to be run as the code = that >>>>>> turns a request into an access token. >>>>>> >>>>>> The only other possibility is that the request is packaged by the AS >>>>>> and sent elsewhere (an agent) for evaluation against policy and a >>>>>> proto-token returned. In that case the AS is acting as a proxy and t= he PDP >>>>>> is elsewhere. I can imagine that an AS-RS would behave this way so t= hat the >>>>>> proto-token could be turned into an access token by the AS-RS. Isn't= this >>>>>> what Justin is proposing? In this design, the AS is the AS-RS and th= e agent >>>>>> is the AS-RO. By my definition, this model has two ASs since both ar= e >>>>>> processing requests into tokens. The problem with this is complexity= and >>>>>> privacy. The RO may not want to share the request information with t= he >>>>>> AS-RS. >>>>>> >>>>>> Adrian >>>>>> >>>>>> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>>> Isn't that what the AS is supposed to be, only with the caveat that >>>>>>> the policy is defined locally? >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> >>>>>>> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp = a >>>>>>> =C3=A9crit : >>>>>>> >>>>>>>> AS-RO is an AS that RO trusts to delegate RO's access tokens >>>>>>>> according to RO's policies. >>>>>>>> >>>>>>>> -------------- >>>>>>>> Alan Karp >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi Alan and Adrian, >>>>>>>>> >>>>>>>>> I've created issue AS-RO policy delegation ( >>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to >>>>>>>>> capture your input. >>>>>>>>> A first question that arises: can we give a definition to AS-RO? >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Fabien Imbault wrote: >>>>>>>>>> >>>>>>>>>>> Hi Alan, >>>>>>>>>>> >>>>>>>>>>> Yes, but in that flow, the token relationship between AS-RS and >>>>>>>>>>> AS-RO is only secure if the tokens issued by AS-RS are cryptogr= aphically >>>>>>>>>>> attenuable in the first place. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Attenuated delegation is a requirement, but that doesn't have to >>>>>>>>>> be done cryptographically. Token exchange works just fine. SPK= I and >>>>>>>>>> zcap-ld are examples of the crypto approach, and we used token e= xchange in >>>>>>>>>> the system for HP. >>>>>>>>>> >>>>>>>>>> -------------- >>>>>>>>>> Alan Karp >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault < >>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Alan, >>>>>>>>>>> >>>>>>>>>>> Yes, but in that flow, the token relationship between AS-RS and >>>>>>>>>>> AS-RO is only secure if the tokens issued by AS-RS are cryptogr= aphically >>>>>>>>>>> attenuable in the first place. >>>>>>>>>>> >>>>>>>>>>> Fabien >>>>>>>>>>> >>>>>>>>>>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Justin Richer wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> But with all that in mind, I think the key here is going to b= e >>>>>>>>>>>>> looking at what the inputs to the AS are, and how those can b= e defined in >>>>>>>>>>>>> an interoperable way for AS=E2=80=99s that can accept them. I= think there=E2=80=99s a lot >>>>>>>>>>>>> of room for innovation and flexibility here that doesn=E2=80= =99t break the trust >>>>>>>>>>>>> model or core use cases. If I have an AS-RS set that won=E2= =80=99t accept my >>>>>>>>>>>>> favorite flavor of policy engine inputs, then I can decide no= t to use that >>>>>>>>>>>>> one. But this is a very different question than saying the RS= itself needs >>>>>>>>>>>>> to accept my own AS =E2=80=94 and we can=E2=80=99t keep confl= ating these two models. >>>>>>>>>>>>> >>>>>>>>>>>>> I agree. The point of having an AS-RO is to allow RO to >>>>>>>>>>>> specify a policy for which of RO's access tokens should be del= egated under >>>>>>>>>>>> what conditions. AS-RS should not need to understand those po= licies. The >>>>>>>>>>>> flow would be >>>>>>>>>>>> >>>>>>>>>>>> - RO contacts AS-RS and gets one or more access tokens. >>>>>>>>>>>> - RO delegates one or more of those tokens, potentially >>>>>>>>>>>> sub-scoped, to AS-RO. >>>>>>>>>>>> - A different user contacts AS-RO to get a potentially >>>>>>>>>>>> sub-scoped access token from AS-RO. >>>>>>>>>>>> - That user presents the access token delegated by AS-RO >>>>>>>>>>>> when invoking the resource. >>>>>>>>>>>> >>>>>>>>>>>> AS-RS only needs to verify that the delegation chain is >>>>>>>>>>>> legitimate, e.g., no increase in scope, and that it grants per= mission for >>>>>>>>>>>> the request being made. AS-RS does not need to understand the= policy >>>>>>>>>>>> behind granting the delegation by AS-RO. >>>>>>>>>>>> >>>>>>>>>>>> -------------- >>>>>>>>>>>> Alan Karp >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Adrian, >>>>>>>>>>>>> >>>>>>>>>>>>> I think this shows the problem with the terminology as it=E2= =80=99s >>>>>>>>>>>>> been applied in this conversation, which I=E2=80=99ve tried t= o shine light on >>>>>>>>>>>>> before. What you and others are calling the =E2=80=9CRS=E2=80= =9D is really the =E2=80=9CAS and RS >>>>>>>>>>>>> working together=E2=80=9D =E2=80=94 everything to the right o= f the line. When Denis had >>>>>>>>>>>>> brought up =E2=80=9Celiminating the AS=E2=80=9D in another th= read, what he=E2=80=99d really done is >>>>>>>>>>>>> labeled everything to the right of the line as the =E2=80=9CR= S=E2=80=9D. Of course, the >>>>>>>>>>>>> irony here is that everything to the right of the line used a= ll be called >>>>>>>>>>>>> the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80=9D i= n the OAuth 1 days. As you say below, I don=E2=80=99t >>>>>>>>>>>>> want the client to have visibility on what happens on that si= de. >>>>>>>>>>>>> >>>>>>>>>>>>> Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in = the diagram is >>>>>>>>>>>>> not the AS, as far as GNAP is concerned. It does not issue an= access token >>>>>>>>>>>>> that the RS will accept. The elements to the left of the line= could be a >>>>>>>>>>>>> lot of things, but they are NOT the AS =E2=80=94 by definitio= n. The client lives >>>>>>>>>>>>> over on the left, but so do any external inputs to the AS. Th= ese could be >>>>>>>>>>>>> policy inputs on behalf of the RO, they could be presentation= artifacts, >>>>>>>>>>>>> they could be federated logins, they could be the output of p= olicy >>>>>>>>>>>>> decisions. How the AS comes to trust those things is up to th= e AS=E2=80=99s >>>>>>>>>>>>> implementation. It=E2=80=99s something we can talk about, but= ultimately GNAP won=E2=80=99t >>>>>>>>>>>>> be in any position to dictate because in practice some AS=E2= =80=99s are simply >>>>>>>>>>>>> going to internalize all policies and we will never successfu= lly force >>>>>>>>>>>>> those open. >>>>>>>>>>>>> >>>>>>>>>>>>> But with all that in mind, I think the key here is going to b= e >>>>>>>>>>>>> looking at what the inputs to the AS are, and how those can b= e defined in >>>>>>>>>>>>> an interoperable way for AS=E2=80=99s that can accept them. I= think there=E2=80=99s a lot >>>>>>>>>>>>> of room for innovation and flexibility here that doesn=E2=80= =99t break the trust >>>>>>>>>>>>> model or core use cases. If I have an AS-RS set that won=E2= =80=99t accept my >>>>>>>>>>>>> favorite flavor of policy engine inputs, then I can decide no= t to use that >>>>>>>>>>>>> one. But this is a very different question than saying the RS= itself needs >>>>>>>>>>>>> to accept my own AS =E2=80=94 and we can=E2=80=99t keep confl= ating these two models. >>>>>>>>>>>>> >>>>>>>>>>>>> So to me, GNAP can support a Zero Trust Architecture by >>>>>>>>>>>>> LEVERAGING the AS, not by subsuming or eliminating it. It is = in fact the >>>>>>>>>>>>> AS, not the client and not the RS, that will request and cons= ume the >>>>>>>>>>>>> results of a privacy-preserving zero-trust policy query thing= . Anything >>>>>>>>>>>>> that happens downstream from that is of little concern to the= zero-trust >>>>>>>>>>>>> components because, as you point out, it=E2=80=99s on the =E2= =80=9Cother side=E2=80=9D of the line. >>>>>>>>>>>>> >>>>>>>>>>>>> I think we got this basic component model pretty right in >>>>>>>>>>>>> OAuth: the AS and RS and client working together. Where OAuth= misses the >>>>>>>>>>>>> mark is the assumption that the user has to log in to the AS = through a >>>>>>>>>>>>> webpage and interact directly, thereby proving they=E2=80=99r= e the RO. It=E2=80=99s this >>>>>>>>>>>>> latter space where I think we can both push innovation and al= so address the >>>>>>>>>>>>> important and compelling use cases like the ones you=E2=80=99= re bringing. >>>>>>>>>>>>> >>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>> >>>>>>>>>>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper < >>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> I'm sorry, Justin. As a Resource Owner, I look at the RS trus= t >>>>>>>>>>>>> boundary (the dotted line in the diagram) as being the RS. I = don't expect >>>>>>>>>>>>> any visibility into what's going on on the right. >>>>>>>>>>>>> >>>>>>>>>>>>> My problem with the framing you propose is that requests are >>>>>>>>>>>>> going to the RS (or the AS-RS) and I don't want to share my p= olicies with >>>>>>>>>>>>> the AS-RS. I want to keep the RS and AS-RS as ignorant as pos= sible. >>>>>>>>>>>>> >>>>>>>>>>>>> Adrian >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>> >>>>>>>>>>>>>> What you=E2=80=99re discussing below, in terms of logging in= to a >>>>>>>>>>>>>> site, is not approaching the RS. You are in fact approaching= the client, >>>>>>>>>>>>>> and identifying both the AS and RS to the client. The client= is a client *of >>>>>>>>>>>>>> your identity* in this model, and the RS is part of the >>>>>>>>>>>>>> identity provider. It=E2=80=99s really important that we don= =E2=80=99t conflate the RS and >>>>>>>>>>>>>> client in this way as it leads to a lot of confusion downstr= eam and a lot >>>>>>>>>>>>>> of broken trust boundaries. >>>>>>>>>>>>>> >>>>>>>>>>>>>> With that model in mind, approaching the =E2=80=9CRS" and pr= oviding >>>>>>>>>>>>>> it your identity is really just a case of the =E2=80=9Cfeder= ated login to AS=E2=80=9D >>>>>>>>>>>>>> pattern that we discussed on the WG call. The user here appr= oaches an RS, >>>>>>>>>>>>>> which has its own AS. To share things from this RS, the RO h= as to >>>>>>>>>>>>>> authenticate to the RS=E2=80=99s AS. This particular AS allo= ws the RO to do so >>>>>>>>>>>>>> using an external identity =E2=80=94 in which case, the AS i= s now a =E2=80=9Cclient=E2=80=9D of a >>>>>>>>>>>>>> separate, disconnected (but layered) delegation. The ultimat= e client that >>>>>>>>>>>>>> eventually calls the RS down the way may or may not know abo= ut these >>>>>>>>>>>>>> layers. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> This same AS, which is closely tied to the RS and trusted by >>>>>>>>>>>>>> the RS, might also take in FIDO credentials, or DIDs, or any= number of >>>>>>>>>>>>>> other proof mechanisms. The output of this is an access toke= n the RS >>>>>>>>>>>>>> trusts, but the input is up to the AS. The RS is not what yo= u=E2=80=99re logging in >>>>>>>>>>>>>> to. >>>>>>>>>>>>>> >>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper < >>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> I too am in favor of avoiding consolidation and correlation. >>>>>>>>>>>>>> Right now, when I approach a service provider (RS) for the f= irst time, I'm >>>>>>>>>>>>>> offered the opportunity to identify my persona as: email, si= gn-in with >>>>>>>>>>>>>> Google, Facebook, or Apple. I know there are people who try = to create >>>>>>>>>>>>>> one-off email addresses but that is mostly a waste of time. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So, along come FIDO2 and DID wallets to the rescue. Now, in >>>>>>>>>>>>>> theory, I have a way to start out my RS relationship pseudon= ymously. >>>>>>>>>>>>>> >>>>>>>>>>>>>> When I want my resource to be discovered or shared I will >>>>>>>>>>>>>> post that RS URL including my pseudonym. If I then want to i= ntroduce a >>>>>>>>>>>>>> mediator in front of my AS or messaging service endpoint, I = have that >>>>>>>>>>>>>> option. If I want to keep requests away from the mediator, I= would publish >>>>>>>>>>>>>> an encryption key along with my pseudonym. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - Adrian >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer < >>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >> @Alan Karp shared a talk about the >>>>>>>>>>>>>>> Principle Of Least >>>>>>>>>>>>>>> >> Authority (POLA) in a recent comment >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/1= 45#issuecomment-803099693 >>>>>>>>>>>>>>> >> I recommend it. >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> We might expect a protocol with authorization in the >>>>>>>>>>>>>>> title to use authority >>>>>>>>>>>>>>> >> as a core principle. I advocate for a GNAP design that >>>>>>>>>>>>>>> maximizes the power >>>>>>>>>>>>>>> >> of the RO, to be seen as a human rights issue when the R= O >>>>>>>>>>>>>>> is a human. This >>>>>>>>>>>>>>> >> causes me to ask how to combine better security with >>>>>>>>>>>>>>> better human rights in >>>>>>>>>>>>>>> >> GNAP. >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> Who should have the least authority in the GNAP design? >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> The AS derives authority as a delegate of the RO. If we >>>>>>>>>>>>>>> ask the RO to >>>>>>>>>>>>>>> >> partition limited authority across dozens of different >>>>>>>>>>>>>>> ASs by domain and >>>>>>>>>>>>>>> >> function, then we are not using technology to empower th= e >>>>>>>>>>>>>>> individual. >>>>>>>>>>>>>>> >> Probably the opposite, as we introduce consent fatigue >>>>>>>>>>>>>>> and burden normal >>>>>>>>>>>>>>> >> people to partition their lives into non-overlapping >>>>>>>>>>>>>>> domains. >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> My experience says we should aim for one AS per persona >>>>>>>>>>>>>>> because that maps >>>>>>>>>>>>>>> >> into the way we manage our public and private identities= . >>>>>>>>>>>>>>> POLA would then >>>>>>>>>>>>>>> >> teach care in keeping ASs and RSs related to work / >>>>>>>>>>>>>>> public separate from >>>>>>>>>>>>>>> >> ASs and RSs related to private life so that a policy >>>>>>>>>>>>>>> vulnerability in our >>>>>>>>>>>>>>> >> delegation to an AS would have the least likelihood of >>>>>>>>>>>>>>> harm. >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > Thinking about how least authority/least privilege would >>>>>>>>>>>>>>> apply to GNAP >>>>>>>>>>>>>>> > seems like a useful exercise. I do want to point out som= e >>>>>>>>>>>>>>> potential >>>>>>>>>>>>>>> > pitfalls with one-AS-per-persona that we can also be awar= e >>>>>>>>>>>>>>> of. If >>>>>>>>>>>>>>> > one-AS-per-persona becomes one-persona-per-AS as well, >>>>>>>>>>>>>>> then the AS's >>>>>>>>>>>>>>> > identity in effect also serves as a persona identity and >>>>>>>>>>>>>>> there are privacy >>>>>>>>>>>>>>> > considerations to that. If, on the other hand, the >>>>>>>>>>>>>>> > multiple-personas-per-AS (presumably corresponding to >>>>>>>>>>>>>>> multiple humans) >>>>>>>>>>>>>>> > route is taken, we should consider whether that would lea= d >>>>>>>>>>>>>>> to various >>>>>>>>>>>>>>> > (e.g., market) forces driving consolidation to just a >>>>>>>>>>>>>>> handful of >>>>>>>>>>>>>>> > super-popular AS services. That topic is a current matte= r >>>>>>>>>>>>>>> of concern to >>>>>>>>>>>>>>> > some IETF participants. >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Ben, big +1 to this. This is something that we discussed >>>>>>>>>>>>>>> ages ago in the UMA working group, and it=E2=80=99s one of = the biggest problems >>>>>>>>>>>>>>> with the personal AS (and personal data store) model. This = kind of thing >>>>>>>>>>>>>>> makes RS-first trust models really difficult in practice. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve got soft= ware that wants >>>>>>>>>>>>>>> to access my medical information. It calls an RS and reques= ts access, but >>>>>>>>>>>>>>> it hasn=E2=80=99t been granted anything yet. Now I as the R= O have set up the RS so >>>>>>>>>>>>>>> that it talks to my personal AS, that only I use. In additi= on to the RS >>>>>>>>>>>>>>> having to be able to figure out which medical records are b= eing requested >>>>>>>>>>>>>>> from the context of the unauthenticated request (which mean= s it needs >>>>>>>>>>>>>>> identifiers in the URL or something similar for the RS to b= e able to tell, >>>>>>>>>>>>>>> assuming that it protects data for more than one person). S= o this client >>>>>>>>>>>>>>> software doesn=E2=80=99t know who I am and doesn=E2=80=99t = know my medical record >>>>>>>>>>>>>>> information, makes a completely unauthorized request to the= RS, and the RS >>>>>>>>>>>>>>> says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a t= oken=E2=80=9D. The client can now make a >>>>>>>>>>>>>>> direct correlation between the data that=E2=80=99s being pr= otected at the RS and >>>>>>>>>>>>>>> the person running the AS that protects it. Importantly, th= is client makes >>>>>>>>>>>>>>> this call with no prior relationship to the RS and no reall= y auditable way >>>>>>>>>>>>>>> to track it down after the fact. This is a design feature i= n the good case, >>>>>>>>>>>>>>> and terrifying in the bad case. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If the RS instead says =E2=80=9Cwelcome to Medicine Doctor = RS, >>>>>>>>>>>>>>> please talk to the Medicine Doctor AS to get access=E2=80= =9D, we haven=E2=80=99t exposed >>>>>>>>>>>>>>> anything at all. And from the perspective of both the patie= nt and the RS, >>>>>>>>>>>>>>> this is more privacy-preserving, and it=E2=80=99s really th= e least surprising >>>>>>>>>>>>>>> option. Once the client gets to the AS, it can start a nego= tiation of >>>>>>>>>>>>>>> figuring out who the RO is for the information being access= ed. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On top of this, the usability expectations of people >>>>>>>>>>>>>>> managing their own AS, or set of AS=E2=80=99s for multiple = personas to keep things >>>>>>>>>>>>>>> separate, is a huge burden. Even in the tech community, I k= now people who >>>>>>>>>>>>>>> can=E2=80=99t reliably manage more than one email address f= or different purposes. I >>>>>>>>>>>>>>> wouldn=E2=80=99t expect my partner to do that =E2=80=94 the= y have trouble enough balancing >>>>>>>>>>>>>>> all the logins and sessions required for different kids rem= ote schooling, I >>>>>>>>>>>>>>> couldn=E2=80=99t imagine them having to understand all the = requirements for >>>>>>>>>>>>>>> managing multiple authorization servers and associated poli= cies. I also >>>>>>>>>>>>>>> don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2= =80=9D =E2=80=94 I=E2=80=99ve been on the internet for >>>>>>>>>>>>>>> decades and I can barely keep tabs on my GPG keys, and only= use them when I >>>>>>>>>>>>>>> am forced to. This is exactly the kind of =E2=80=9Cmarket p= ressure=E2=80=9D that I think >>>>>>>>>>>>>>> Ben mentions above, people will just want to outsource that= to someone >>>>>>>>>>>>>>> else, and the reality will be a few popular providers. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In which case, we could end up doing a ton of work to allow >>>>>>>>>>>>>>> an RS choice only to end up with a world where the RS ends = up making a >>>>>>>>>>>>>>> limited choice anyway. We see how that plays out with OpenI= D Connect =E2=80=94 RP=E2=80=99s >>>>>>>>>>>>>>> could allow arbitrary IdPs but they choose Google because i= t works and >>>>>>>>>>>>>>> that=E2=80=99s where the users are. (And that=E2=80=99s not= to say anything of the >>>>>>>>>>>>>>> proprietary OIDC-like protocols, but that=E2=80=99s another= discussion). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For further reading on these topics, I recommend both =E2= =80=9CWhy >>>>>>>>>>>>>>> Johnny Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW= Systems Fail=E2=80=9D. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So what does this have to do with GNAP? I think we can be >>>>>>>>>>>>>>> clear-eyed on what kinds of expectations we have for the pa= rticipants. If >>>>>>>>>>>>>>> we expect users (RO=E2=80=99s) to have to set up the AS-RS = relationship, or expect >>>>>>>>>>>>>>> them to carry their AS, or manage their personal keys =E2= =80=94 I think we=E2=80=99ve lost >>>>>>>>>>>>>>> the battle for relevance. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>> 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 >>>>> >>>> --0000000000000ddef305be571ef1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Note : I'm not sure that's a good idea, but havin= g 2 types of ASs is not that easy to grasp.

    Fabien=C2=A0

    Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien I= mbault <fabien.imbault@gmail= .com> a =C3=A9crit=C2=A0:
    The purpose of either handling policies locally or delegati= ng them to the RO agent.=C2=A0

    Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gro= pper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    What purpose would be served= by GNAP splitting the AS into two components?

    <= /div>
    Adrian=C2=A0

    On Thu,= Mar 25, 2021 at 2:59 AM Fabien Imbault <fabien.imbault= @gmail.com> wrote:
    Isn't the AS-RO a component of the AS? Same idea as the inter= act component, it functionnally belongs to the AS role but could be deploye= d either as a monolith or as a separate component?
    <= div dir=3D"auto">
    Fabien

    Le jeu. 25 mars 20= 21 =C3=A0 04:26, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:


    On Wed, Mar 24, 2021 at 11:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Adrian Gropper <agropper@healthurl.com= > wrote:

    In this design, the AS is the = AS-RS and the agent is the AS-RO. By my definition, this model has two ASs = since both are processing requests into tokens. The problem with this is co= mplexity and privacy. The RO may not want to share the request information = with the AS-RS.

    More precisely, RO has no choice but to present the required inform= ation to AS-RS if RO wants an access token.=C2=A0 However, RO does not want= AS-RS to know the policy by which RO delegates tokens.=C2=A0 That's wh= y RO uses AS-RO for those delegations.

    --------------
    Alan Karp

    <= /div>

    On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper <agropper@healthurl.com> wrote:
    = Thank you for creating the issue. My definition of AS is independent of AS-= RO or AS-RS.=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/= issues/223#issuecomment-806280421 I also agree with Alan's definiti= on based on delegation. An AS-RS would be a delegate of the RS.=C2=A0
    =

    Based on that, I see it as obvious=C2=A0tha= t the policy has to be accessible (defined locally?) in order for it to be = run as the code that turns a request into an access token.=C2=A0
    =
    The only other possibility is that the request is packaged b= y the AS and sent elsewhere (an agent) for evaluation against policy and a = proto-token returned. In that case the AS is acting as a proxy and the PDP = is elsewhere. I can imagine that an AS-RS would behave this way so that the= proto-token could be turned into an access token by the AS-RS. Isn't t= his what Justin is proposing? In this design, the AS is the AS-RS and the a= gent is the AS-RO. By my definition, this model has two ASs since both are = processing requests into tokens. The problem with this is complexity and pr= ivacy. The RO may not want to share the request information with the AS-RS.=

    Adrian

    =
    On Wed, Mar 24, 2021 at 5:21 PM Fabie= n Imbault <fabien.imbault@gmail.com> = wrote:
    Isn't that what the AS is supposed to be, only with the = caveat that the policy is defined locally?=C2=A0

    Fabien=C2=A0


    Le mer. 24 mars 2021 =C3=A0 20:17, Alan = Karp <alanhkarp@gmail.com> a =C3=A9crit=C2= =A0:
    AS-RO is an AS that RO trusts to delegate RO's a= ccess tokens according to RO's policies.=C2=A0=C2=A0
    <= div>

    --------------
    Alan Karp

    <= br>
    On Wed,= Mar 24, 2021 at 9:36 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan and Adrian,
    <= br>
    I've created issue AS-RO policy delegation (https://github.com/= ietf-wg-gnap/gnap-core-protocol/issues/223) to capture your input.=C2= =A0
    A first question that arises: can we give a definition to AS-= RO?

    Thanks
    Fabien

    On Tue, Mar 23, 2= 021 at 4:15 PM Alan Karp <alanhkarp@gm= ail.com> wrote:
    =
    Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan,=C2= =A0

    Yes, but in that flow, the token relationship betwee= n AS-RS and AS-RO is only secure if the tokens issued by AS-RS are cryptogr= aphically attenuable in the first place.=C2=A0
    =C2=A0
    Attenuated delegation is a requirement, = but that doesn't have to be done cryptographically.=C2=A0 Token exchang= e works just fine.=C2=A0 SPKI and zcap-ld are examples of the crypto approa= ch, and we used token exchange in the system for HP.

    --------------
    Alan Karp


    On Tue, Mar 23, 2021 at = 4:12 AM Fabien Imbault <fabien.i= mbault@gmail.com> wrote:
    Hi Alan,=C2=A0

    Yes, but= in that flow, the token relationship between AS-RS and AS-RO is only secur= e if the tokens issued by AS-RS are cryptographically attenuable in the fir= st place.=C2=A0

    Fabien

    On Mon, Mar 22, 2021= at 9:26 PM Alan Karp <alanhkarp@gmail= .com> wrote:
    Justin Richer <jricher@mit.edu> wr= ote:
    <= br>
    But with all that in mind, I think the key here is going to b= e looking at what the inputs to the AS are, and how those can be defined in= an interoperable way for AS=E2=80=99s that can accept them. I think there= =E2=80=99s a lot of room for innovation and flexibility here that doesn=E2= =80=99t break the trust model or core use cases. If I have an AS-RS set tha= t won=E2=80=99t accept my favorite flavor of policy engine inputs, then I c= an decide not to use that one. But this is a very different question than s= aying the RS itself needs to accept my own AS =E2=80=94 and we can=E2=80=99= t keep conflating these two models.

    =
    I agree.=C2=A0 The point of having an AS-RO is to allow RO to specify = a policy for which of RO's access tokens should be delegated under what= conditions.=C2=A0 AS-RS should not need to understand those policies.=C2= =A0 The flow would be
    • RO contacts AS-RS and gets one or m= ore access tokens.
    • RO delegates one or more of those tokens, potent= ially sub-scoped, to AS-RO.
    • A different user contacts AS-RO to get = a potentially sub-scoped access token from AS-RO.
    • That user present= s the access token delegated by AS-RO when invoking the resource.
    =
    AS-RS only needs to verify that the delegation chain is leg= itimate, e.g., no increase in scope, and that it grants permission for the = request being made.=C2=A0 AS-RS does not need to understand the policy behi= nd granting the delegation by AS-RO.

    ------------= --
    Alan Karp


    On Mon, Mar 22, 2021 at 11:40 AM Justin Rich= er <jricher@mit.edu> wrote:
    Adrian,

    I think this shows the problem with the terminology as it=E2=80=99= s been applied in this conversation, which I=E2=80=99ve tried to shine ligh= t on before. What you and others are calling the =E2=80=9CRS=E2=80=9D is re= ally the =E2=80=9CAS and RS working together=E2=80=9D =E2=80=94 everything = to the right of the line. When Denis had brought up =E2=80=9Celiminating th= e AS=E2=80=9D in another thread, what he=E2=80=99d really done is labeled e= verything to the right of the line as the =E2=80=9CRS=E2=80=9D. Of course, = the irony here is that everything to the right of the line used all be call= ed the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80=9D in the OAuth= 1 days. As you say below, I don=E2=80=99t want the client to have visibili= ty on what happens on that side.=C2=A0

    Note well: = The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the diagram is not the AS= , as far as GNAP is concerned. It does not issue an access token that the R= S will accept. The elements to the left of the line could be a lot of thing= s, but they are NOT the AS =E2=80=94 by definition. The client lives over o= n the left, but so do any external inputs to the AS. These could be policy = inputs on behalf of the RO, they could be presentation artifacts, they coul= d be federated logins, they could be the output of policy decisions. How th= e AS comes to trust those things is up to the AS=E2=80=99s implementation. = It=E2=80=99s something we can talk about, but ultimately GNAP won=E2=80=99t= be in any position to dictate because in practice some AS=E2=80=99s are si= mply going to internalize all policies and we will never successfully force= those open.=C2=A0

    But with all that in mind, I th= ink the key here is going to be looking at what the inputs to the AS are, a= nd how those can be defined in an interoperable way for AS=E2=80=99s that c= an accept them. I think there=E2=80=99s a lot of room for innovation and fl= exibility here that doesn=E2=80=99t break the trust model or core use cases= . If I have an AS-RS set that won=E2=80=99t accept my favorite flavor of po= licy engine inputs, then I can decide not to use that one. But this is a ve= ry different question than saying the RS itself needs to accept my own AS = =E2=80=94 and we can=E2=80=99t keep conflating these two models.
    =
    So to me, GNAP can support a Zero Trust Architecture by LEVE= RAGING the AS, not by subsuming or eliminating it. It is in fact the AS, no= t the client and not the RS, that will request and consume the results of a= privacy-preserving zero-trust policy query thing. Anything that happens do= wnstream from that is of little concern to the zero-trust components becaus= e, as you point out, it=E2=80=99s on the =E2=80=9Cother side=E2=80=9D of th= e line.=C2=A0

    I think we got this basic component = model pretty right in OAuth: the AS and RS and client working together. Whe= re OAuth misses the mark is the assumption that the user has to log in to t= he AS through a webpage and interact directly, thereby proving they=E2=80= =99re the RO. It=E2=80=99s this latter space where I think we can both push= innovation and also address the important and compelling use cases like th= e ones you=E2=80=99re bringing.

    =C2=A0=E2=80=94 Ju= stin

    On Mar 22, 2021, at 2:14 PM= , Adrian Gropper <agropper@healthur= l.com> wrote:

    I'm sorry, Justin. = As a Resource Owner, I look at the RS trust boundary (the dotted line in th= e diagram) as being the RS. I don't expect any visibility into what'= ;s going on on the=C2=A0right.=C2=A0

    My problem with the= framing you propose is that requests are going to the RS (or the AS-RS) an= d I don't want to share my policies with the AS-RS. I want to keep the = RS and AS-RS as ignorant as possible.

    Adrian
    =

    = On Mon, Mar 22, 2021 at 1:48 PM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    What you=E2=80=99re dis= cussing below, in terms of logging in to a site, is not approaching the RS.= You are in fact approaching the client, and identifying both the AS and RS= to the client. The client is a client of your identity in this mode= l, and the RS is part of the identity provider. It=E2=80=99s really importa= nt that we don=E2=80=99t conflate the RS and client in this way as it leads= to a lot of confusion downstream and a lot of broken trust boundaries.

    With that model in mind, approaching the =E2=80=9CRS&= quot; and providing it your identity is really just a case of the =E2=80=9C= federated login to AS=E2=80=9D pattern that we discussed on the WG call. Th= e user here approaches an RS, which has its own AS. To share things from th= is RS, the RO has to authenticate to the RS=E2=80=99s AS. This particular A= S allows the RO to do so using an external identity =E2=80=94 in which case= , the AS is now a =E2=80=9Cclient=E2=80=9D of a separate, disconnected (but= layered) delegation. The ultimate client that eventually calls the RS down= the way may or may not know about these layers.=C2=A0

    =
    <Pasted= Graphic-1.png>
    This same AS, which is closely tied to t= he RS and trusted by the RS, might also take in FIDO credentials, or DIDs, = or any number of other proof mechanisms. The output of this is an access to= ken the RS trusts, but the input is up to the AS. The RS is not what you=E2= =80=99re logging in to.

    =C2=A0=E2=80=94 Justin
    =

    On Mar 22, 2021, at 1:28 PM, Adrian= Gropper <agropper@healthurl.com> wrote:

    I too am in favor of avoiding c= onsolidation and correlation. Right now, when I approach a service provider= (RS) for the first time, I'm offered the opportunity to identify my pe= rsona as: email, sign-in with Google, Facebook, or Apple. I know there are = people who try to create one-off email addresses but that is mostly a waste= of time.=C2=A0

    So, along come FIDO2 and DID wallets to = the rescue. Now, in theory, I have a way to start out my RS relationship ps= eudonymously.=C2=A0

    When I want my resource to be = discovered or shared I will post that RS URL including my pseudonym. If I t= hen want to introduce a mediator=C2=A0in front of my AS or messaging servic= e=C2=A0endpoint, I have that option. If I want to keep requests away from t= he mediator, I would publish an encryption key along with my pseudonym.

    - Adrian


    On Mon, M= ar 22, 2021 at 9:55 AM Justin Richer <jric= her@mit.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhkarp@gmail.c= om> shared a talk about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-gnap/gnap-c= ore-protocol/issues/145#issuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.= ietf.org/mailman/listinfo/txauth
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/ma= ilman/listinfo/txauth
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/ma= ilman/listinfo/txauth
    --0000000000000ddef305be571ef1-- From nobody Thu Mar 25 00:16:55 2021 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 0661A3A136F for ; Thu, 25 Mar 2021 00:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 Dnzl1VsqhAIQ for ; Thu, 25 Mar 2021 00:16:49 -0700 (PDT) Received: from mail-vk1-f169.google.com (mail-vk1-f169.google.com [209.85.221.169]) (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 23DC73A136E for ; Thu, 25 Mar 2021 00:16:49 -0700 (PDT) Received: by mail-vk1-f169.google.com with SMTP id k27so183911vki.2 for ; Thu, 25 Mar 2021 00:16:49 -0700 (PDT) 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=LZEkL5gQ3UISMppn4BPUYMZcHtRHkApQf6CkOn7ugl4=; b=Cv5LCTl5hEucXUqE2YEaWm5iWX4ZDG3RTdxHm6BRmAsJMbg745c0OYJIpiDbpNzRSU OKIkTnuGZRFxg9l3Q1RerDDGXCmUbGjD/Uj5zOa0b3GFd57JPlBLIrWo3a9jI6WOK8P2 fHn3NHPIvSPFz1C5yQcIYRxS/oZodae+Ps80Po1od+mvYrF4DGTxu+8uUGPzuGGj69R5 T/+BNflNpL7uZo6iflp0uiiRavzjt327Ulshkq8/WNwQtWl5V3kunEvpJlRTLkEMD2jB KoqYMStNM8eJFfNelH5rJoPQY76/reR2S5PoakN5Ust6VvxoEOkL4pWstYgBFmlYLPTn 3yUw== X-Gm-Message-State: AOAM530lU/iSrcsXpffDplDrfy9fD9fqMH/6j76vmDDETz+NVn4Cs2/+ qZMJyHonKHaamZC+xKh2LqVrHEFdlNPuDcLGr6E= X-Google-Smtp-Source: ABdhPJx83s+Pt8eBVKVWLqbFFAHVJZ5Fat/MHuzvvYQtln7cKDKzh/gHuC5WMYcvV5y3y4ryFIwMLNYY2frYBxKWlHQ= X-Received: by 2002:a1f:3250:: with SMTP id y77mr3804684vky.20.1616656607862; Thu, 25 Mar 2021 00:16:47 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> In-Reply-To: From: Adrian Gropper Date: Thu, 25 Mar 2021 03:16:36 -0400 Message-ID: To: Fabien Imbault Cc: Alan Karp , Benjamin Kaduk , GNAP Mailing List , Justin Richer , Mark Miller Content-Type: multipart/alternative; boundary="000000000000d5e1b205be573244" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 07:16:54 -0000 --000000000000d5e1b205be573244 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There=E2=80=99s no obvious reason to have two types of ASs. Any AS that is executing the policies of the RS can look to GNAP like the RS itself. Why would GNAP expose that interface to anyone? Adrian On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault wrote: > Note : I'm not sure that's a good idea, but having 2 types of ASs is not > that easy to grasp. > > Fabien > > Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault a > =C3=A9crit : > >> The purpose of either handling policies locally or delegating them to th= e >> RO agent. >> >> Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper a >> =C3=A9crit : >> >>> What purpose would be served by GNAP splitting the AS into two >>> components? >>> >>> Adrian >>> >>> On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault >>> wrote: >>> >>>> Isn't the AS-RO a component of the AS? Same idea as the interact >>>> component, it functionnally belongs to the AS role but could be deploy= ed >>>> either as a monolith or as a separate component? >>>> >>>> Fabien >>>> >>>> Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper >>>> a =C3=A9crit : >>>> >>>>> Yes, but I would say it=E2=80=99s not the RO that wants the access to= ken. It=E2=80=99s >>>>> the RO that wants the client making the request to get an access toke= n. >>>>> >>>>> Adrian >>>>> >>>>> On Wed, Mar 24, 2021 at 11:22 PM Alan Karp >>>>> wrote: >>>>> >>>>>> Adrian Gropper wrote: >>>>>> >>>>>>> >>>>>>> In this design, the AS is the AS-RS and the agent is the AS-RO. By >>>>>>> my definition, this model has two ASs since both are processing req= uests >>>>>>> into tokens. The problem with this is complexity and privacy. The R= O may >>>>>>> not want to share the request information with the AS-RS. >>>>>>> >>>>>> >>>>>> More precisely, RO has no choice but to present the required >>>>>> information to AS-RS if RO wants an access token. However, RO does = not >>>>>> want AS-RS to know the policy by which RO delegates tokens. That's = why RO >>>>>> uses AS-RO for those delegations. >>>>>> >>>>>> -------------- >>>>>> Alan Karp >>>>>> >>>>>> >>>>>> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper < >>>>>> agropper@healthurl.com> wrote: >>>>>> >>>>>>> Thank you for creating the issue. My definition of AS is independen= t >>>>>>> of AS-RO or AS-RS. >>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issue= comment-806280421 >>>>>>> I also agree with Alan's definition based on delegation. An AS-RS w= ould be >>>>>>> a delegate of the RS. >>>>>>> >>>>>>> Based on that, I see it as obvious that the policy has to be >>>>>>> accessible (defined locally?) in order for it to be run as the code= that >>>>>>> turns a request into an access token. >>>>>>> >>>>>>> The only other possibility is that the request is packaged by the A= S >>>>>>> and sent elsewhere (an agent) for evaluation against policy and a >>>>>>> proto-token returned. In that case the AS is acting as a proxy and = the PDP >>>>>>> is elsewhere. I can imagine that an AS-RS would behave this way so = that the >>>>>>> proto-token could be turned into an access token by the AS-RS. Isn'= t this >>>>>>> what Justin is proposing? In this design, the AS is the AS-RS and t= he agent >>>>>>> is the AS-RO. By my definition, this model has two ASs since both a= re >>>>>>> processing requests into tokens. The problem with this is complexit= y and >>>>>>> privacy. The RO may not want to share the request information with = the >>>>>>> AS-RS. >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>> >>>>>>>> Isn't that what the AS is supposed to be, only with the caveat tha= t >>>>>>>> the policy is defined locally? >>>>>>>> >>>>>>>> Fabien >>>>>>>> >>>>>>>> >>>>>>>> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp = a >>>>>>>> =C3=A9crit : >>>>>>>> >>>>>>>>> AS-RO is an AS that RO trusts to delegate RO's access tokens >>>>>>>>> according to RO's policies. >>>>>>>>> >>>>>>>>> -------------- >>>>>>>>> Alan Karp >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault < >>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hi Alan and Adrian, >>>>>>>>>> >>>>>>>>>> I've created issue AS-RO policy delegation ( >>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) >>>>>>>>>> to capture your input. >>>>>>>>>> A first question that arises: can we give a definition to AS-RO? >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Fabien >>>>>>>>>> >>>>>>>>>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Fabien Imbault wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Alan, >>>>>>>>>>>> >>>>>>>>>>>> Yes, but in that flow, the token relationship between AS-RS an= d >>>>>>>>>>>> AS-RO is only secure if the tokens issued by AS-RS are cryptog= raphically >>>>>>>>>>>> attenuable in the first place. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Attenuated delegation is a requirement, but that doesn't have t= o >>>>>>>>>>> be done cryptographically. Token exchange works just fine. SP= KI and >>>>>>>>>>> zcap-ld are examples of the crypto approach, and we used token = exchange in >>>>>>>>>>> the system for HP. >>>>>>>>>>> >>>>>>>>>>> -------------- >>>>>>>>>>> Alan Karp >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault < >>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Alan, >>>>>>>>>>>> >>>>>>>>>>>> Yes, but in that flow, the token relationship between AS-RS an= d >>>>>>>>>>>> AS-RO is only secure if the tokens issued by AS-RS are cryptog= raphically >>>>>>>>>>>> attenuable in the first place. >>>>>>>>>>>> >>>>>>>>>>>> Fabien >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Justin Richer wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> But with all that in mind, I think the key here is going to >>>>>>>>>>>>>> be looking at what the inputs to the AS are, and how those c= an be defined >>>>>>>>>>>>>> in an interoperable way for AS=E2=80=99s that can accept the= m. I think there=E2=80=99s a >>>>>>>>>>>>>> lot of room for innovation and flexibility here that doesn= =E2=80=99t break the >>>>>>>>>>>>>> trust model or core use cases. If I have an AS-RS set that w= on=E2=80=99t accept my >>>>>>>>>>>>>> favorite flavor of policy engine inputs, then I can decide n= ot to use that >>>>>>>>>>>>>> one. But this is a very different question than saying the R= S itself needs >>>>>>>>>>>>>> to accept my own AS =E2=80=94 and we can=E2=80=99t keep conf= lating these two models. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I agree. The point of having an AS-RO is to allow RO to >>>>>>>>>>>>> specify a policy for which of RO's access tokens should be de= legated under >>>>>>>>>>>>> what conditions. AS-RS should not need to understand those p= olicies. The >>>>>>>>>>>>> flow would be >>>>>>>>>>>>> >>>>>>>>>>>>> - RO contacts AS-RS and gets one or more access tokens. >>>>>>>>>>>>> - RO delegates one or more of those tokens, potentially >>>>>>>>>>>>> sub-scoped, to AS-RO. >>>>>>>>>>>>> - A different user contacts AS-RO to get a potentially >>>>>>>>>>>>> sub-scoped access token from AS-RO. >>>>>>>>>>>>> - That user presents the access token delegated by AS-RO >>>>>>>>>>>>> when invoking the resource. >>>>>>>>>>>>> >>>>>>>>>>>>> AS-RS only needs to verify that the delegation chain is >>>>>>>>>>>>> legitimate, e.g., no increase in scope, and that it grants pe= rmission for >>>>>>>>>>>>> the request being made. AS-RS does not need to understand th= e policy >>>>>>>>>>>>> behind granting the delegation by AS-RO. >>>>>>>>>>>>> >>>>>>>>>>>>> -------------- >>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer < >>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think this shows the problem with the terminology as it=E2= =80=99s >>>>>>>>>>>>>> been applied in this conversation, which I=E2=80=99ve tried = to shine light on >>>>>>>>>>>>>> before. What you and others are calling the =E2=80=9CRS=E2= =80=9D is really the =E2=80=9CAS and RS >>>>>>>>>>>>>> working together=E2=80=9D =E2=80=94 everything to the right = of the line. When Denis had >>>>>>>>>>>>>> brought up =E2=80=9Celiminating the AS=E2=80=9D in another t= hread, what he=E2=80=99d really done is >>>>>>>>>>>>>> labeled everything to the right of the line as the =E2=80=9C= RS=E2=80=9D. Of course, the >>>>>>>>>>>>>> irony here is that everything to the right of the line used = all be called >>>>>>>>>>>>>> the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80=9D = in the OAuth 1 days. As you say below, I don=E2=80=99t >>>>>>>>>>>>>> want the client to have visibility on what happens on that s= ide. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in= the diagram is >>>>>>>>>>>>>> not the AS, as far as GNAP is concerned. It does not issue a= n access token >>>>>>>>>>>>>> that the RS will accept. The elements to the left of the lin= e could be a >>>>>>>>>>>>>> lot of things, but they are NOT the AS =E2=80=94 by definiti= on. The client lives >>>>>>>>>>>>>> over on the left, but so do any external inputs to the AS. T= hese could be >>>>>>>>>>>>>> policy inputs on behalf of the RO, they could be presentatio= n artifacts, >>>>>>>>>>>>>> they could be federated logins, they could be the output of = policy >>>>>>>>>>>>>> decisions. How the AS comes to trust those things is up to t= he AS=E2=80=99s >>>>>>>>>>>>>> implementation. It=E2=80=99s something we can talk about, bu= t ultimately GNAP won=E2=80=99t >>>>>>>>>>>>>> be in any position to dictate because in practice some AS=E2= =80=99s are simply >>>>>>>>>>>>>> going to internalize all policies and we will never successf= ully force >>>>>>>>>>>>>> those open. >>>>>>>>>>>>>> >>>>>>>>>>>>>> But with all that in mind, I think the key here is going to >>>>>>>>>>>>>> be looking at what the inputs to the AS are, and how those c= an be defined >>>>>>>>>>>>>> in an interoperable way for AS=E2=80=99s that can accept the= m. I think there=E2=80=99s a >>>>>>>>>>>>>> lot of room for innovation and flexibility here that doesn= =E2=80=99t break the >>>>>>>>>>>>>> trust model or core use cases. If I have an AS-RS set that w= on=E2=80=99t accept my >>>>>>>>>>>>>> favorite flavor of policy engine inputs, then I can decide n= ot to use that >>>>>>>>>>>>>> one. But this is a very different question than saying the R= S itself needs >>>>>>>>>>>>>> to accept my own AS =E2=80=94 and we can=E2=80=99t keep conf= lating these two models. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So to me, GNAP can support a Zero Trust Architecture by >>>>>>>>>>>>>> LEVERAGING the AS, not by subsuming or eliminating it. It is= in fact the >>>>>>>>>>>>>> AS, not the client and not the RS, that will request and con= sume the >>>>>>>>>>>>>> results of a privacy-preserving zero-trust policy query thin= g. Anything >>>>>>>>>>>>>> that happens downstream from that is of little concern to th= e zero-trust >>>>>>>>>>>>>> components because, as you point out, it=E2=80=99s on the = =E2=80=9Cother side=E2=80=9D of the line. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think we got this basic component model pretty right in >>>>>>>>>>>>>> OAuth: the AS and RS and client working together. Where OAut= h misses the >>>>>>>>>>>>>> mark is the assumption that the user has to log in to the AS= through a >>>>>>>>>>>>>> webpage and interact directly, thereby proving they=E2=80=99= re the RO. It=E2=80=99s this >>>>>>>>>>>>>> latter space where I think we can both push innovation and a= lso address the >>>>>>>>>>>>>> important and compelling use cases like the ones you=E2=80= =99re bringing. >>>>>>>>>>>>>> >>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper < >>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm sorry, Justin. As a Resource Owner, I look at the RS >>>>>>>>>>>>>> trust boundary (the dotted line in the diagram) as being the= RS. I don't >>>>>>>>>>>>>> expect any visibility into what's going on on the right. >>>>>>>>>>>>>> >>>>>>>>>>>>>> My problem with the framing you propose is that requests are >>>>>>>>>>>>>> going to the RS (or the AS-RS) and I don't want to share my = policies with >>>>>>>>>>>>>> the AS-RS. I want to keep the RS and AS-RS as ignorant as po= ssible. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer < >>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> What you=E2=80=99re discussing below, in terms of logging i= n to a >>>>>>>>>>>>>>> site, is not approaching the RS. You are in fact approachin= g the client, >>>>>>>>>>>>>>> and identifying both the AS and RS to the client. The clien= t is a client *of >>>>>>>>>>>>>>> your identity* in this model, and the RS is part of the >>>>>>>>>>>>>>> identity provider. It=E2=80=99s really important that we do= n=E2=80=99t conflate the RS and >>>>>>>>>>>>>>> client in this way as it leads to a lot of confusion downst= ream and a lot >>>>>>>>>>>>>>> of broken trust boundaries. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> With that model in mind, approaching the =E2=80=9CRS" and p= roviding >>>>>>>>>>>>>>> it your identity is really just a case of the =E2=80=9Cfede= rated login to AS=E2=80=9D >>>>>>>>>>>>>>> pattern that we discussed on the WG call. The user here app= roaches an RS, >>>>>>>>>>>>>>> which has its own AS. To share things from this RS, the RO = has to >>>>>>>>>>>>>>> authenticate to the RS=E2=80=99s AS. This particular AS all= ows the RO to do so >>>>>>>>>>>>>>> using an external identity =E2=80=94 in which case, the AS = is now a =E2=80=9Cclient=E2=80=9D of a >>>>>>>>>>>>>>> separate, disconnected (but layered) delegation. The ultima= te client that >>>>>>>>>>>>>>> eventually calls the RS down the way may or may not know ab= out these >>>>>>>>>>>>>>> layers. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This same AS, which is closely tied to the RS and trusted b= y >>>>>>>>>>>>>>> the RS, might also take in FIDO credentials, or DIDs, or an= y number of >>>>>>>>>>>>>>> other proof mechanisms. The output of this is an access tok= en the RS >>>>>>>>>>>>>>> trusts, but the input is up to the AS. The RS is not what y= ou=E2=80=99re logging in >>>>>>>>>>>>>>> to. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper < >>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I too am in favor of avoiding consolidation and correlation= . >>>>>>>>>>>>>>> Right now, when I approach a service provider (RS) for the = first time, I'm >>>>>>>>>>>>>>> offered the opportunity to identify my persona as: email, s= ign-in with >>>>>>>>>>>>>>> Google, Facebook, or Apple. I know there are people who try= to create >>>>>>>>>>>>>>> one-off email addresses but that is mostly a waste of time. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So, along come FIDO2 and DID wallets to the rescue. Now, in >>>>>>>>>>>>>>> theory, I have a way to start out my RS relationship pseudo= nymously. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> When I want my resource to be discovered or shared I will >>>>>>>>>>>>>>> post that RS URL including my pseudonym. If I then want to = introduce a >>>>>>>>>>>>>>> mediator in front of my AS or messaging service endpoint, I= have that >>>>>>>>>>>>>>> option. If I want to keep requests away from the mediator, = I would publish >>>>>>>>>>>>>>> an encryption key along with my pseudonym. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Adrian >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer < >>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >> @Alan Karp shared a talk about >>>>>>>>>>>>>>>> the Principle Of Least >>>>>>>>>>>>>>>> >> Authority (POLA) in a recent comment >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/= 145#issuecomment-803099693 >>>>>>>>>>>>>>>> >> I recommend it. >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> We might expect a protocol with authorization in the >>>>>>>>>>>>>>>> title to use authority >>>>>>>>>>>>>>>> >> as a core principle. I advocate for a GNAP design that >>>>>>>>>>>>>>>> maximizes the power >>>>>>>>>>>>>>>> >> of the RO, to be seen as a human rights issue when the >>>>>>>>>>>>>>>> RO is a human. This >>>>>>>>>>>>>>>> >> causes me to ask how to combine better security with >>>>>>>>>>>>>>>> better human rights in >>>>>>>>>>>>>>>> >> GNAP. >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> Who should have the least authority in the GNAP design? >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> The AS derives authority as a delegate of the RO. If we >>>>>>>>>>>>>>>> ask the RO to >>>>>>>>>>>>>>>> >> partition limited authority across dozens of different >>>>>>>>>>>>>>>> ASs by domain and >>>>>>>>>>>>>>>> >> function, then we are not using technology to empower >>>>>>>>>>>>>>>> the individual. >>>>>>>>>>>>>>>> >> Probably the opposite, as we introduce consent fatigue >>>>>>>>>>>>>>>> and burden normal >>>>>>>>>>>>>>>> >> people to partition their lives into non-overlapping >>>>>>>>>>>>>>>> domains. >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> My experience says we should aim for one AS per persona >>>>>>>>>>>>>>>> because that maps >>>>>>>>>>>>>>>> >> into the way we manage our public and private >>>>>>>>>>>>>>>> identities. POLA would then >>>>>>>>>>>>>>>> >> teach care in keeping ASs and RSs related to work / >>>>>>>>>>>>>>>> public separate from >>>>>>>>>>>>>>>> >> ASs and RSs related to private life so that a policy >>>>>>>>>>>>>>>> vulnerability in our >>>>>>>>>>>>>>>> >> delegation to an AS would have the least likelihood of >>>>>>>>>>>>>>>> harm. >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > Thinking about how least authority/least privilege would >>>>>>>>>>>>>>>> apply to GNAP >>>>>>>>>>>>>>>> > seems like a useful exercise. I do want to point out >>>>>>>>>>>>>>>> some potential >>>>>>>>>>>>>>>> > pitfalls with one-AS-per-persona that we can also be >>>>>>>>>>>>>>>> aware of. If >>>>>>>>>>>>>>>> > one-AS-per-persona becomes one-persona-per-AS as well, >>>>>>>>>>>>>>>> then the AS's >>>>>>>>>>>>>>>> > identity in effect also serves as a persona identity and >>>>>>>>>>>>>>>> there are privacy >>>>>>>>>>>>>>>> > considerations to that. If, on the other hand, the >>>>>>>>>>>>>>>> > multiple-personas-per-AS (presumably corresponding to >>>>>>>>>>>>>>>> multiple humans) >>>>>>>>>>>>>>>> > route is taken, we should consider whether that would >>>>>>>>>>>>>>>> lead to various >>>>>>>>>>>>>>>> > (e.g., market) forces driving consolidation to just a >>>>>>>>>>>>>>>> handful of >>>>>>>>>>>>>>>> > super-popular AS services. That topic is a current >>>>>>>>>>>>>>>> matter of concern to >>>>>>>>>>>>>>>> > some IETF participants. >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Ben, big +1 to this. This is something that we discusse= d >>>>>>>>>>>>>>>> ages ago in the UMA working group, and it=E2=80=99s one of= the biggest problems >>>>>>>>>>>>>>>> with the personal AS (and personal data store) model. This= kind of thing >>>>>>>>>>>>>>>> makes RS-first trust models really difficult in practice. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve got sof= tware that wants >>>>>>>>>>>>>>>> to access my medical information. It calls an RS and reque= sts access, but >>>>>>>>>>>>>>>> it hasn=E2=80=99t been granted anything yet. Now I as the = RO have set up the RS so >>>>>>>>>>>>>>>> that it talks to my personal AS, that only I use. In addit= ion to the RS >>>>>>>>>>>>>>>> having to be able to figure out which medical records are = being requested >>>>>>>>>>>>>>>> from the context of the unauthenticated request (which mea= ns it needs >>>>>>>>>>>>>>>> identifiers in the URL or something similar for the RS to = be able to tell, >>>>>>>>>>>>>>>> assuming that it protects data for more than one person). = So this client >>>>>>>>>>>>>>>> software doesn=E2=80=99t know who I am and doesn=E2=80=99t= know my medical record >>>>>>>>>>>>>>>> information, makes a completely unauthorized request to th= e RS, and the RS >>>>>>>>>>>>>>>> says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a = token=E2=80=9D. The client can now make a >>>>>>>>>>>>>>>> direct correlation between the data that=E2=80=99s being p= rotected at the RS and >>>>>>>>>>>>>>>> the person running the AS that protects it. Importantly, t= his client makes >>>>>>>>>>>>>>>> this call with no prior relationship to the RS and no real= ly auditable way >>>>>>>>>>>>>>>> to track it down after the fact. This is a design feature = in the good case, >>>>>>>>>>>>>>>> and terrifying in the bad case. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If the RS instead says =E2=80=9Cwelcome to Medicine Doctor= RS, >>>>>>>>>>>>>>>> please talk to the Medicine Doctor AS to get access=E2=80= =9D, we haven=E2=80=99t exposed >>>>>>>>>>>>>>>> anything at all. And from the perspective of both the pati= ent and the RS, >>>>>>>>>>>>>>>> this is more privacy-preserving, and it=E2=80=99s really t= he least surprising >>>>>>>>>>>>>>>> option. Once the client gets to the AS, it can start a neg= otiation of >>>>>>>>>>>>>>>> figuring out who the RO is for the information being acces= sed. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On top of this, the usability expectations of people >>>>>>>>>>>>>>>> managing their own AS, or set of AS=E2=80=99s for multiple= personas to keep things >>>>>>>>>>>>>>>> separate, is a huge burden. Even in the tech community, I = know people who >>>>>>>>>>>>>>>> can=E2=80=99t reliably manage more than one email address = for different purposes. I >>>>>>>>>>>>>>>> wouldn=E2=80=99t expect my partner to do that =E2=80=94 th= ey have trouble enough balancing >>>>>>>>>>>>>>>> all the logins and sessions required for different kids re= mote schooling, I >>>>>>>>>>>>>>>> couldn=E2=80=99t imagine them having to understand all the= requirements for >>>>>>>>>>>>>>>> managing multiple authorization servers and associated pol= icies. I also >>>>>>>>>>>>>>>> don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2= =80=9D =E2=80=94 I=E2=80=99ve been on the internet for >>>>>>>>>>>>>>>> decades and I can barely keep tabs on my GPG keys, and onl= y use them when I >>>>>>>>>>>>>>>> am forced to. This is exactly the kind of =E2=80=9Cmarket = pressure=E2=80=9D that I think >>>>>>>>>>>>>>>> Ben mentions above, people will just want to outsource tha= t to someone >>>>>>>>>>>>>>>> else, and the reality will be a few popular providers. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In which case, we could end up doing a ton of work to allo= w >>>>>>>>>>>>>>>> an RS choice only to end up with a world where the RS ends= up making a >>>>>>>>>>>>>>>> limited choice anyway. We see how that plays out with Open= ID Connect =E2=80=94 RP=E2=80=99s >>>>>>>>>>>>>>>> could allow arbitrary IdPs but they choose Google because = it works and >>>>>>>>>>>>>>>> that=E2=80=99s where the users are. (And that=E2=80=99s no= t to say anything of the >>>>>>>>>>>>>>>> proprietary OIDC-like protocols, but that=E2=80=99s anothe= r discussion). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> For further reading on these topics, I recommend both =E2= =80=9CWhy >>>>>>>>>>>>>>>> Johnny Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSC= W Systems Fail=E2=80=9D. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So what does this have to do with GNAP? I think we can be >>>>>>>>>>>>>>>> clear-eyed on what kinds of expectations we have for the p= articipants. If >>>>>>>>>>>>>>>> we expect users (RO=E2=80=99s) to have to set up the AS-RS= relationship, or expect >>>>>>>>>>>>>>>> them to carry their AS, or manage their personal keys =E2= =80=94 I think we=E2=80=99ve lost >>>>>>>>>>>>>>>> the battle for relevance. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>> 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 >>>>>> >>>>> --000000000000d5e1b205be573244 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    There=E2=80=99s no obvious reason to have two types of AS= s. Any AS that is executing the policies of the RS can look to GNAP like th= e RS itself. Why would GNAP expose that interface to anyone?=C2=A0

    Adrian

    On Thu, Mar 25, 2021= at 3:11 AM Fabien Imbault <= fabien.imbault@gmail.com> wrote:
    Note : I'm not sure that's a good idea, but = having 2 types of ASs is not that easy to grasp.

    Fabien=C2=A0

    Le jeu. 25 mar= s 2021 =C3=A0 08:07, Fabien Imbault <fabien.imbault@gmail.com> a =C3=A9crit=C2= =A0:
    The purpose = of either handling policies locally or delegating them to the RO agent.=C2= =A0

    Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper <agropper@healt= hurl.com> a =C3=A9crit=C2=A0:
    What purpose would be served by GNAP splitting the AS i= nto two components?

    Adri= an=C2=A0

    On Thu, Mar 25, 2021 at 2:59 AM Fabi= en Imbault <fabien.imbault@gmail.com> wrote:
    =
    Isn't the AS-RO = a component of the AS? Same idea as the interact component, it functionnall= y belongs to the AS role but could be deployed either as a monolith or as a= separate component?

    Fabien

    Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Groppe= r <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    =
    Yes, but I would say= it=E2=80=99s not the RO that wants the access token. It=E2=80=99s the RO t= hat wants the client making the request to get an access token.=C2=A0
    =

    Adrian

    On Wed, Mar 24, 20= 21 at 11:22 PM Alan Karp <alanhkarp@gmail.com= > wrote:
    Adrian Gropper <agropper@healthurl.com> wrote:
    =
    In this design, the AS is the AS-RS and the agent is the AS-= RO. By my definition, this model has two ASs since both are processing requ= ests into tokens. The problem with this is complexity and privacy. The RO m= ay not want to share the request information with the AS-RS.

    More precisely, RO has= no choice but to present the required information to AS-RS if RO wants an = access token.=C2=A0 However, RO does not want AS-RS to know the policy by w= hich RO delegates tokens.=C2=A0 That's why RO uses AS-RO for those dele= gations.

    -----= ---------
    Alan Karp


    On Wed, Mar 24= , 2021 at 7:41 PM Adrian Gropper <agropper@hea= lthurl.com> wrote:
    Thank you for creating the iss= ue. My definition of AS is independent of AS-RO or AS-RS.=C2=A0https:= //github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomment-806280= 421 I also agree with Alan's definition based on delegation. An AS-= RS would be a delegate of the RS.=C2=A0

    Based on that, I see it as obvious=C2=A0that the policy has to be accessi= ble (defined locally?) in order for it to be run as the code that turns a r= equest into an access token.=C2=A0

    The only other = possibility is that the request is packaged by the AS and sent elsewhere (a= n agent) for evaluation against policy and a proto-token returned. In that = case the AS is acting as a proxy and the PDP is elsewhere. I can imagine th= at an AS-RS would behave this way so that the proto-token could be turned i= nto an access token by the AS-RS. Isn't this what Justin is proposing? = In this design, the AS is the AS-RS and the agent is the AS-RO. By my defin= ition, this model has two ASs since both are processing requests into token= s. The problem with this is complexity and privacy. The RO may not want to = share the request information with the AS-RS.

    Adri= an

    On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Isn't that w= hat the AS is supposed to be, only with the caveat that the policy is defin= ed locally?=C2=A0

    Fabien=C2=A0=


    Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp <alanhkarp@gmail.com> a =C3=A9crit=C2=A0:
    AS-RO is= an AS that RO trusts to delegate RO's access tokens according to RO= 9;s policies.=C2=A0=C2=A0

    ------= --------
    Alan Karp


    <= div dir=3D"ltr" class=3D"gmail_attr">On Wed, Mar 24, 2021 at 9:36 AM Fabien= Imbault <fabien.imbault@gmail.co= m> wrote:
    Hi Alan and Adrian,

    I've created i= ssue AS-RO policy delegation (https://github.com/ietf-wg-gnap/gnap-core-protocol/= issues/223) to capture your input.=C2=A0
    A first question tha= t arises: can we give a definition to AS-RO?

    Thank= s
    Fabien

    On Tue, Mar 23, 2021 at 4:15 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Fabien Imbault <fabien.imba= ult@gmail.com> wrote:
    Hi Alan,=C2=A0

    Yes, but in= that flow, the token relationship between AS-RS and AS-RO is only secure i= f the tokens issued by AS-RS are cryptographically attenuable in the first = place.=C2=A0
    =C2=A0
    Attenuated delegation is a requirement, but that doesn't have to be do= ne cryptographically.=C2=A0 Token exchange works just fine.=C2=A0 SPKI and = zcap-ld are examples of the crypto approach, and we used token exchange in = the system for HP.

    --------------
    Alan Kar= p


    On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    =
    Hi= Alan,=C2=A0

    Yes, but in that flow, the token relationsh= ip between AS-RS and AS-RO is only secure if the tokens issued by AS-RS are= cryptographically attenuable in the first place.=C2=A0

    Fabien

    On Mon, Mar 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin Richer <jricher@mit.edu> wrote:

    But with all that in mi= nd, I think the key here is going to be looking at what the inputs to the A= S are, and how those can be defined in an interoperable way for AS=E2=80=99= s that can accept them. I think there=E2=80=99s a lot of room for innovatio= n and flexibility here that doesn=E2=80=99t break the trust model or core u= se cases. If I have an AS-RS set that won=E2=80=99t accept my favorite flav= or of policy engine inputs, then I can decide not to use that one. But this= is a very different question than saying the RS itself needs to accept my = own AS =E2=80=94 and we can=E2=80=99t keep conflating these two models.

    I agree.=C2=A0 The point of having= an AS-RO is to allow RO to specify a policy for which of RO's access t= okens should be delegated under what conditions.=C2=A0 AS-RS should not nee= d to understand those policies.=C2=A0 The flow would be
    • R= O contacts AS-RS and gets one or more access tokens.
    • RO delegates o= ne or more of those tokens, potentially sub-scoped, to AS-RO.
    • A dif= ferent user contacts AS-RO to get a potentially sub-scoped access token fro= m AS-RO.
    • That user presents the access token delegated by AS-RO whe= n invoking the resource.
    AS-RS only needs to verif= y that the delegation chain is legitimate, e.g., no increase in scope, and = that it grants permission for the request being made.=C2=A0 AS-RS does not = need to understand the policy behind granting the delegation by AS-RO.

    --------------
    Alan Karp


    =
    On Mon, Ma= r 22, 2021 at 11:40 AM Justin Richer <jric= her@mit.edu> wrote:
    Adrian,

    I think this shows the problem w= ith the terminology as it=E2=80=99s been applied in this conversation, whic= h I=E2=80=99ve tried to shine light on before. What you and others are call= ing the =E2=80=9CRS=E2=80=9D is really the =E2=80=9CAS and RS working toget= her=E2=80=9D =E2=80=94 everything to the right of the line. When Denis had = brought up =E2=80=9Celiminating the AS=E2=80=9D in another thread, what he= =E2=80=99d really done is labeled everything to the right of the line as th= e =E2=80=9CRS=E2=80=9D. Of course, the irony here is that everything to the= right of the line used all be called the =E2=80=9CAS=E2=80=9D or simply = =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say below, I don=E2=80= =99t want the client to have visibility on what happens on that side.=C2=A0=

    Note well: The Google+ logo labeled =E2=80=9CIdP= =E2=80=9D in the diagram is not the AS, as far as GNAP is concerned. It doe= s not issue an access token that the RS will accept. The elements to the le= ft of the line could be a lot of things, but they are NOT the AS =E2=80=94 = by definition. The client lives over on the left, but so do any external in= puts to the AS. These could be policy inputs on behalf of the RO, they coul= d be presentation artifacts, they could be federated logins, they could be = the output of policy decisions. How the AS comes to trust those things is u= p to the AS=E2=80=99s implementation. It=E2=80=99s something we can talk ab= out, but ultimately GNAP won=E2=80=99t be in any position to dictate becaus= e in practice some AS=E2=80=99s are simply going to internalize all policie= s and we will never successfully force those open.=C2=A0

    But with all that in mind, I think the key here is going to be looki= ng at what the inputs to the AS are, and how those can be defined in an int= eroperable way for AS=E2=80=99s that can accept them. I think there=E2=80= =99s a lot of room for innovation and flexibility here that doesn=E2=80=99t= break the trust model or core use cases. If I have an AS-RS set that won= =E2=80=99t accept my favorite flavor of policy engine inputs, then I can de= cide not to use that one. But this is a very different question than saying= the RS itself needs to accept my own AS =E2=80=94 and we can=E2=80=99t kee= p conflating these two models.

    So to me, GNAP can = support a Zero Trust Architecture by LEVERAGING the AS, not by subsuming or= eliminating it. It is in fact the AS, not the client and not the RS, that = will request and consume the results of a privacy-preserving zero-trust pol= icy query thing. Anything that happens downstream from that is of little co= ncern to the zero-trust components because, as you point out, it=E2=80=99s = on the =E2=80=9Cother side=E2=80=9D of the line.=C2=A0

    =
    I think we got this basic component model pretty right in OAuth: the A= S and RS and client working together. Where OAuth misses the mark is the as= sumption that the user has to log in to the AS through a webpage and intera= ct directly, thereby proving they=E2=80=99re the RO. It=E2=80=99s this latt= er space where I think we can both push innovation and also address the imp= ortant and compelling use cases like the ones you=E2=80=99re bringing.

    =C2=A0=E2=80=94 Justin

    On Mar 22, 2021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    <= div dir=3D"ltr">I'm sorry, Justin. As a Resource Owner, I look at the R= S trust boundary (the dotted line in the diagram) as being the RS. I don= 9;t expect any visibility into what's going on on the=C2=A0right.=C2=A0=

    My problem with the framing you propose is that request= s are going to the RS (or the AS-RS) and I don't want to share my polic= ies with the AS-RS. I want to keep the RS and AS-RS as ignorant as possible= .

    Adrian

    On Mon, Mar 22, 2021 at 1:48 PM Just= in Richer <jricher@mit.edu> wrote:<= br>
    Adrian,
    What you=E2=80=99re discussing below, in terms of logging i= n to a site, is not approaching the RS. You are in fact approaching the cli= ent, and identifying both the AS and RS to the client. The client is a clie= nt of your identity in this model, and the RS is part of the identit= y provider. It=E2=80=99s really important that we don=E2=80=99t conflate th= e RS and client in this way as it leads to a lot of confusion downstream an= d a lot of broken trust boundaries.

    With that mode= l in mind, approaching the =E2=80=9CRS" and providing it your identity= is really just a case of the =E2=80=9Cfederated login to AS=E2=80=9D patte= rn that we discussed on the WG call. The user here approaches an RS, which = has its own AS. To share things from this RS, the RO has to authenticate to= the RS=E2=80=99s AS. This particular AS allows the RO to do so using an ex= ternal identity =E2=80=94 in which case, the AS is now a =E2=80=9Cclient=E2= =80=9D of a separate, disconnected (but layered) delegation. The ultimate c= lient that eventually calls the RS down the way may or may not know about t= hese layers.=C2=A0

    <PastedGraphic-1.png&g= t;
    This same AS, which is closely tied to the RS and trust= ed by the RS, might also take in FIDO credentials, or DIDs, or any number o= f other proof mechanisms. The output of this is an access token the RS trus= ts, but the input is up to the AS. The RS is not what you=E2=80=99re loggin= g in to.

    =C2=A0=E2=80=94 Justin

    On Mar 22, 2021, at 1:28 PM, Adrian Gropper <agropper@healthurl.com> wrote:
    I too am in favor of avoiding consolidation an= d correlation. Right now, when I approach a service provider (RS) for the f= irst time, I'm offered the opportunity to identify my persona as: email= , sign-in with Google, Facebook, or Apple. I know there are people who try = to create one-off email addresses but that is mostly a waste of time.=C2=A0=

    So, along come FIDO2 and DID wallets to the rescue. Now= , in theory, I have a way to start out my RS relationship pseudonymously.= =C2=A0

    When I want my resource to be discovered or= shared I will post that RS URL including my pseudonym. If I then want to i= ntroduce a mediator=C2=A0in front of my AS or messaging service=C2=A0endpoi= nt, I have that option. If I want to keep requests away from the mediator, = I would publish an encryption key along with my pseudonym.

    - Adrian



    On Mon, Mar 22, 2021= at 9:55 AM Justin Richer <jricher@mit.edu= > wrote:
    = On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhkarp@gmail.c= om> shared a talk about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-gnap/gnap-c= ore-protocol/issues/145#issuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.= ietf.org/mailman/listinfo/txauth
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/ma= ilman/listinfo/txauth
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/ma= ilman/listinfo/txauth
    --000000000000d5e1b205be573244-- From nobody Thu Mar 25 00:24:30 2021 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 C5CD93A1395 for ; Thu, 25 Mar 2021 00:24: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_MESSAGE=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 W-TxBlC6V7Ux for ; Thu, 25 Mar 2021 00:24:23 -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 9E57A3A1393 for ; Thu, 25 Mar 2021 00:24:23 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id e8so937528iok.5 for ; Thu, 25 Mar 2021 00:24:23 -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=lUtxWIt06dK6iiIqc2upGoh79zy9IG3WNGAuVVMop8Q=; b=mRuZm0uvSfoLA2M0ZreBlI+IjnRw5oA+xtLl3sN5wMsUFoM3mP7E+ZF4InRXeXDtwn t2YWOAAtJJb/YCJG54idKsuHgcjsX8hGtZ7e/2QE3CIoYgAx3yYVVWPkIuqcC7fMsppk LYh4qZKu5adBbLdSr3iPh2iY57ouvvsxB2/xGJQw0yqDXnOURyLa3zy/LgEvRWwupdCf +QV5EOJD4Ga1ny5T9VEHknwo30BsVfRXzl4pg+yuicCB9LsY/scQjWB3R4Emhi2p2C8T xPt1EsUtY+yk18HW+t4OTQosF5cF2NUu30thkj7H5xBHhAdUFd6aesW4Iwo+5ppN10LI sWKQ== 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=lUtxWIt06dK6iiIqc2upGoh79zy9IG3WNGAuVVMop8Q=; b=ZczXkynaeFSP/hl4jAc8Fbr2AfptIcijT2nP3AIHfAFxuoyGyQOAIsU/hu2TTdKolT uqvpmiAiuDIk0IU1Y8T5L8XzK45INvxEghziydlFW1esvecB5TtpEMRtdG0FVuT5wiDf 6w+aZFES/B5bu+2Gu3lbIX/6KoP/r9MLS3TV2LK3trGEKAlhG12E5rd4bb/21fC+lBJ0 62a7wfZqTcsaIikgUAaSnWkL09hyXm7RD2GF3HmshsOmF6qzKe+xzomrLraHPGS7kcE+ qje12EF3Giq6kmOgKrImMIgLiTno6ctWydfL8GjBI5WBFZ6WTW/Y55eaYPDKzYSVJYId Ufiw== X-Gm-Message-State: AOAM533c1WIRvfVvmsRkNrb5mblPb97rA5ZovUPeHy3tFkFJOPQ5ZkBN x/HZe+vXpbD2F1/e3P0hYHf2zl/ftIR4sIxlVaQwIqr108Y= X-Google-Smtp-Source: ABdhPJzPVWNxCwYqvlnQPOaMLFjFVbVDUDQs36DFomilRLElGRxTbYYDppBPfSBQy1HTfB0JcZkXshXGqn4AeOuzzbI= X-Received: by 2002:a05:6602:3314:: with SMTP id b20mr5461772ioz.78.1616657062202; Thu, 25 Mar 2021 00:24:22 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> In-Reply-To: From: Fabien Imbault Date: Thu, 25 Mar 2021 08:24:08 +0100 Message-ID: To: Adrian Gropper Cc: Alan Karp , Benjamin Kaduk , GNAP Mailing List , Justin Richer , Mark Miller Content-Type: multipart/alternative; boundary="000000000000ea921505be574da9" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 07:24:29 -0000 --000000000000ea921505be574da9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I was referring to "By my definition, this model has two ASs since both are processing requests into tokens". If there's no reason to have 2 types of ASs, that's fine then. But I'm a bit lost in where we stand with the idea. Could you recap? Fabien Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper = a =C3=A9crit : > There=E2=80=99s no obvious reason to have two types of ASs. Any AS that i= s > executing the policies of the RS can look to GNAP like the RS itself. Why > would GNAP expose that interface to anyone? > > Adrian > > On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault > wrote: > >> Note : I'm not sure that's a good idea, but having 2 types of ASs is not >> that easy to grasp. >> >> Fabien >> >> Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault >> a =C3=A9crit : >> >>> The purpose of either handling policies locally or delegating them to >>> the RO agent. >>> >>> Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper a >>> =C3=A9crit : >>> >>>> What purpose would be served by GNAP splitting the AS into two >>>> components? >>>> >>>> Adrian >>>> >>>> On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Isn't the AS-RO a component of the AS? Same idea as the interact >>>>> component, it functionnally belongs to the AS role but could be deplo= yed >>>>> either as a monolith or as a separate component? >>>>> >>>>> Fabien >>>>> >>>>> Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper >>>>> a =C3=A9crit : >>>>> >>>>>> Yes, but I would say it=E2=80=99s not the RO that wants the access t= oken. >>>>>> It=E2=80=99s the RO that wants the client making the request to get = an access >>>>>> token. >>>>>> >>>>>> Adrian >>>>>> >>>>>> On Wed, Mar 24, 2021 at 11:22 PM Alan Karp >>>>>> wrote: >>>>>> >>>>>>> Adrian Gropper wrote: >>>>>>> >>>>>>>> >>>>>>>> In this design, the AS is the AS-RS and the agent is the AS-RO. By >>>>>>>> my definition, this model has two ASs since both are processing re= quests >>>>>>>> into tokens. The problem with this is complexity and privacy. The = RO may >>>>>>>> not want to share the request information with the AS-RS. >>>>>>>> >>>>>>> >>>>>>> More precisely, RO has no choice but to present the required >>>>>>> information to AS-RS if RO wants an access token. However, RO does= not >>>>>>> want AS-RS to know the policy by which RO delegates tokens. That's= why RO >>>>>>> uses AS-RO for those delegations. >>>>>>> >>>>>>> -------------- >>>>>>> Alan Karp >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper < >>>>>>> agropper@healthurl.com> wrote: >>>>>>> >>>>>>>> Thank you for creating the issue. My definition of AS is >>>>>>>> independent of AS-RO or AS-RS. >>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issu= ecomment-806280421 >>>>>>>> I also agree with Alan's definition based on delegation. An AS-RS = would be >>>>>>>> a delegate of the RS. >>>>>>>> >>>>>>>> Based on that, I see it as obvious that the policy has to be >>>>>>>> accessible (defined locally?) in order for it to be run as the cod= e that >>>>>>>> turns a request into an access token. >>>>>>>> >>>>>>>> The only other possibility is that the request is packaged by the >>>>>>>> AS and sent elsewhere (an agent) for evaluation against policy and= a >>>>>>>> proto-token returned. In that case the AS is acting as a proxy and= the PDP >>>>>>>> is elsewhere. I can imagine that an AS-RS would behave this way so= that the >>>>>>>> proto-token could be turned into an access token by the AS-RS. Isn= 't this >>>>>>>> what Justin is proposing? In this design, the AS is the AS-RS and = the agent >>>>>>>> is the AS-RO. By my definition, this model has two ASs since both = are >>>>>>>> processing requests into tokens. The problem with this is complexi= ty and >>>>>>>> privacy. The RO may not want to share the request information with= the >>>>>>>> AS-RS. >>>>>>>> >>>>>>>> Adrian >>>>>>>> >>>>>>>> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>> >>>>>>>>> Isn't that what the AS is supposed to be, only with the caveat >>>>>>>>> that the policy is defined locally? >>>>>>>>> >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> >>>>>>>>> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp a >>>>>>>>> =C3=A9crit : >>>>>>>>> >>>>>>>>>> AS-RO is an AS that RO trusts to delegate RO's access tokens >>>>>>>>>> according to RO's policies. >>>>>>>>>> >>>>>>>>>> -------------- >>>>>>>>>> Alan Karp >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault < >>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Alan and Adrian, >>>>>>>>>>> >>>>>>>>>>> I've created issue AS-RO policy delegation ( >>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) >>>>>>>>>>> to capture your input. >>>>>>>>>>> A first question that arises: can we give a definition to AS-RO= ? >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Fabien >>>>>>>>>>> >>>>>>>>>>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Fabien Imbault wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, but in that flow, the token relationship between AS-RS >>>>>>>>>>>>> and AS-RO is only secure if the tokens issued by AS-RS are >>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Attenuated delegation is a requirement, but that doesn't have >>>>>>>>>>>> to be done cryptographically. Token exchange works just fine.= SPKI and >>>>>>>>>>>> zcap-ld are examples of the crypto approach, and we used token= exchange in >>>>>>>>>>>> the system for HP. >>>>>>>>>>>> >>>>>>>>>>>> -------------- >>>>>>>>>>>> Alan Karp >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault < >>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, but in that flow, the token relationship between AS-RS >>>>>>>>>>>>> and AS-RO is only secure if the tokens issued by AS-RS are >>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>> >>>>>>>>>>>>> Fabien >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Justin Richer wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> But with all that in mind, I think the key here is going to >>>>>>>>>>>>>>> be looking at what the inputs to the AS are, and how those = can be defined >>>>>>>>>>>>>>> in an interoperable way for AS=E2=80=99s that can accept th= em. I think there=E2=80=99s a >>>>>>>>>>>>>>> lot of room for innovation and flexibility here that doesn= =E2=80=99t break the >>>>>>>>>>>>>>> trust model or core use cases. If I have an AS-RS set that = won=E2=80=99t accept my >>>>>>>>>>>>>>> favorite flavor of policy engine inputs, then I can decide = not to use that >>>>>>>>>>>>>>> one. But this is a very different question than saying the = RS itself needs >>>>>>>>>>>>>>> to accept my own AS =E2=80=94 and we can=E2=80=99t keep con= flating these two models. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I agree. The point of having an AS-RO is to allow RO to >>>>>>>>>>>>>> specify a policy for which of RO's access tokens should be d= elegated under >>>>>>>>>>>>>> what conditions. AS-RS should not need to understand those = policies. The >>>>>>>>>>>>>> flow would be >>>>>>>>>>>>>> >>>>>>>>>>>>>> - RO contacts AS-RS and gets one or more access tokens. >>>>>>>>>>>>>> - RO delegates one or more of those tokens, potentially >>>>>>>>>>>>>> sub-scoped, to AS-RO. >>>>>>>>>>>>>> - A different user contacts AS-RO to get a potentially >>>>>>>>>>>>>> sub-scoped access token from AS-RO. >>>>>>>>>>>>>> - That user presents the access token delegated by AS-RO >>>>>>>>>>>>>> when invoking the resource. >>>>>>>>>>>>>> >>>>>>>>>>>>>> AS-RS only needs to verify that the delegation chain is >>>>>>>>>>>>>> legitimate, e.g., no increase in scope, and that it grants p= ermission for >>>>>>>>>>>>>> the request being made. AS-RS does not need to understand t= he policy >>>>>>>>>>>>>> behind granting the delegation by AS-RO. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer < >>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think this shows the problem with the terminology as it= =E2=80=99s >>>>>>>>>>>>>>> been applied in this conversation, which I=E2=80=99ve tried= to shine light on >>>>>>>>>>>>>>> before. What you and others are calling the =E2=80=9CRS=E2= =80=9D is really the =E2=80=9CAS and RS >>>>>>>>>>>>>>> working together=E2=80=9D =E2=80=94 everything to the right= of the line. When Denis had >>>>>>>>>>>>>>> brought up =E2=80=9Celiminating the AS=E2=80=9D in another = thread, what he=E2=80=99d really done is >>>>>>>>>>>>>>> labeled everything to the right of the line as the =E2=80= =9CRS=E2=80=9D. Of course, the >>>>>>>>>>>>>>> irony here is that everything to the right of the line used= all be called >>>>>>>>>>>>>>> the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80=9D= in the OAuth 1 days. As you say below, I don=E2=80=99t >>>>>>>>>>>>>>> want the client to have visibility on what happens on that = side. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D i= n the diagram is >>>>>>>>>>>>>>> not the AS, as far as GNAP is concerned. It does not issue = an access token >>>>>>>>>>>>>>> that the RS will accept. The elements to the left of the li= ne could be a >>>>>>>>>>>>>>> lot of things, but they are NOT the AS =E2=80=94 by definit= ion. The client lives >>>>>>>>>>>>>>> over on the left, but so do any external inputs to the AS. = These could be >>>>>>>>>>>>>>> policy inputs on behalf of the RO, they could be presentati= on artifacts, >>>>>>>>>>>>>>> they could be federated logins, they could be the output of= policy >>>>>>>>>>>>>>> decisions. How the AS comes to trust those things is up to = the AS=E2=80=99s >>>>>>>>>>>>>>> implementation. It=E2=80=99s something we can talk about, b= ut ultimately GNAP won=E2=80=99t >>>>>>>>>>>>>>> be in any position to dictate because in practice some AS= =E2=80=99s are simply >>>>>>>>>>>>>>> going to internalize all policies and we will never success= fully force >>>>>>>>>>>>>>> those open. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> But with all that in mind, I think the key here is going to >>>>>>>>>>>>>>> be looking at what the inputs to the AS are, and how those = can be defined >>>>>>>>>>>>>>> in an interoperable way for AS=E2=80=99s that can accept th= em. I think there=E2=80=99s a >>>>>>>>>>>>>>> lot of room for innovation and flexibility here that doesn= =E2=80=99t break the >>>>>>>>>>>>>>> trust model or core use cases. If I have an AS-RS set that = won=E2=80=99t accept my >>>>>>>>>>>>>>> favorite flavor of policy engine inputs, then I can decide = not to use that >>>>>>>>>>>>>>> one. But this is a very different question than saying the = RS itself needs >>>>>>>>>>>>>>> to accept my own AS =E2=80=94 and we can=E2=80=99t keep con= flating these two models. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So to me, GNAP can support a Zero Trust Architecture by >>>>>>>>>>>>>>> LEVERAGING the AS, not by subsuming or eliminating it. It i= s in fact the >>>>>>>>>>>>>>> AS, not the client and not the RS, that will request and co= nsume the >>>>>>>>>>>>>>> results of a privacy-preserving zero-trust policy query thi= ng. Anything >>>>>>>>>>>>>>> that happens downstream from that is of little concern to t= he zero-trust >>>>>>>>>>>>>>> components because, as you point out, it=E2=80=99s on the = =E2=80=9Cother side=E2=80=9D of the line. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think we got this basic component model pretty right in >>>>>>>>>>>>>>> OAuth: the AS and RS and client working together. Where OAu= th misses the >>>>>>>>>>>>>>> mark is the assumption that the user has to log in to the A= S through a >>>>>>>>>>>>>>> webpage and interact directly, thereby proving they=E2=80= =99re the RO. It=E2=80=99s this >>>>>>>>>>>>>>> latter space where I think we can both push innovation and = also address the >>>>>>>>>>>>>>> important and compelling use cases like the ones you=E2=80= =99re bringing. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper < >>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm sorry, Justin. As a Resource Owner, I look at the RS >>>>>>>>>>>>>>> trust boundary (the dotted line in the diagram) as being th= e RS. I don't >>>>>>>>>>>>>>> expect any visibility into what's going on on the right. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> My problem with the framing you propose is that requests ar= e >>>>>>>>>>>>>>> going to the RS (or the AS-RS) and I don't want to share my= policies with >>>>>>>>>>>>>>> the AS-RS. I want to keep the RS and AS-RS as ignorant as p= ossible. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer < >>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> What you=E2=80=99re discussing below, in terms of logging = in to a >>>>>>>>>>>>>>>> site, is not approaching the RS. You are in fact approachi= ng the client, >>>>>>>>>>>>>>>> and identifying both the AS and RS to the client. The clie= nt is a client *of >>>>>>>>>>>>>>>> your identity* in this model, and the RS is part of the >>>>>>>>>>>>>>>> identity provider. It=E2=80=99s really important that we d= on=E2=80=99t conflate the RS and >>>>>>>>>>>>>>>> client in this way as it leads to a lot of confusion downs= tream and a lot >>>>>>>>>>>>>>>> of broken trust boundaries. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> With that model in mind, approaching the =E2=80=9CRS" and = providing >>>>>>>>>>>>>>>> it your identity is really just a case of the =E2=80=9Cfed= erated login to AS=E2=80=9D >>>>>>>>>>>>>>>> pattern that we discussed on the WG call. The user here ap= proaches an RS, >>>>>>>>>>>>>>>> which has its own AS. To share things from this RS, the RO= has to >>>>>>>>>>>>>>>> authenticate to the RS=E2=80=99s AS. This particular AS al= lows the RO to do so >>>>>>>>>>>>>>>> using an external identity =E2=80=94 in which case, the AS= is now a =E2=80=9Cclient=E2=80=9D of a >>>>>>>>>>>>>>>> separate, disconnected (but layered) delegation. The ultim= ate client that >>>>>>>>>>>>>>>> eventually calls the RS down the way may or may not know a= bout these >>>>>>>>>>>>>>>> layers. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This same AS, which is closely tied to the RS and trusted >>>>>>>>>>>>>>>> by the RS, might also take in FIDO credentials, or DIDs, o= r any number of >>>>>>>>>>>>>>>> other proof mechanisms. The output of this is an access to= ken the RS >>>>>>>>>>>>>>>> trusts, but the input is up to the AS. The RS is not what = you=E2=80=99re logging in >>>>>>>>>>>>>>>> to. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper < >>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I too am in favor of avoiding consolidation and >>>>>>>>>>>>>>>> correlation. Right now, when I approach a service provider= (RS) for the >>>>>>>>>>>>>>>> first time, I'm offered the opportunity to identify my per= sona as: email, >>>>>>>>>>>>>>>> sign-in with Google, Facebook, or Apple. I know there are = people who try to >>>>>>>>>>>>>>>> create one-off email addresses but that is mostly a waste = of time. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So, along come FIDO2 and DID wallets to the rescue. Now, i= n >>>>>>>>>>>>>>>> theory, I have a way to start out my RS relationship pseud= onymously. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> When I want my resource to be discovered or shared I will >>>>>>>>>>>>>>>> post that RS URL including my pseudonym. If I then want to= introduce a >>>>>>>>>>>>>>>> mediator in front of my AS or messaging service endpoint, = I have that >>>>>>>>>>>>>>>> option. If I want to keep requests away from the mediator,= I would publish >>>>>>>>>>>>>>>> an encryption key along with my pseudonym. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - Adrian >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer < >>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Groppe= r >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >> @Alan Karp shared a talk about >>>>>>>>>>>>>>>>> the Principle Of Least >>>>>>>>>>>>>>>>> >> Authority (POLA) in a recent comment >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues= /145#issuecomment-803099693 >>>>>>>>>>>>>>>>> >> I recommend it. >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> We might expect a protocol with authorization in the >>>>>>>>>>>>>>>>> title to use authority >>>>>>>>>>>>>>>>> >> as a core principle. I advocate for a GNAP design that >>>>>>>>>>>>>>>>> maximizes the power >>>>>>>>>>>>>>>>> >> of the RO, to be seen as a human rights issue when the >>>>>>>>>>>>>>>>> RO is a human. This >>>>>>>>>>>>>>>>> >> causes me to ask how to combine better security with >>>>>>>>>>>>>>>>> better human rights in >>>>>>>>>>>>>>>>> >> GNAP. >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> Who should have the least authority in the GNAP design= ? >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> The AS derives authority as a delegate of the RO. If w= e >>>>>>>>>>>>>>>>> ask the RO to >>>>>>>>>>>>>>>>> >> partition limited authority across dozens of different >>>>>>>>>>>>>>>>> ASs by domain and >>>>>>>>>>>>>>>>> >> function, then we are not using technology to empower >>>>>>>>>>>>>>>>> the individual. >>>>>>>>>>>>>>>>> >> Probably the opposite, as we introduce consent fatigue >>>>>>>>>>>>>>>>> and burden normal >>>>>>>>>>>>>>>>> >> people to partition their lives into non-overlapping >>>>>>>>>>>>>>>>> domains. >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> My experience says we should aim for one AS per person= a >>>>>>>>>>>>>>>>> because that maps >>>>>>>>>>>>>>>>> >> into the way we manage our public and private >>>>>>>>>>>>>>>>> identities. POLA would then >>>>>>>>>>>>>>>>> >> teach care in keeping ASs and RSs related to work / >>>>>>>>>>>>>>>>> public separate from >>>>>>>>>>>>>>>>> >> ASs and RSs related to private life so that a policy >>>>>>>>>>>>>>>>> vulnerability in our >>>>>>>>>>>>>>>>> >> delegation to an AS would have the least likelihood of >>>>>>>>>>>>>>>>> harm. >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > Thinking about how least authority/least privilege woul= d >>>>>>>>>>>>>>>>> apply to GNAP >>>>>>>>>>>>>>>>> > seems like a useful exercise. I do want to point out >>>>>>>>>>>>>>>>> some potential >>>>>>>>>>>>>>>>> > pitfalls with one-AS-per-persona that we can also be >>>>>>>>>>>>>>>>> aware of. If >>>>>>>>>>>>>>>>> > one-AS-per-persona becomes one-persona-per-AS as well, >>>>>>>>>>>>>>>>> then the AS's >>>>>>>>>>>>>>>>> > identity in effect also serves as a persona identity an= d >>>>>>>>>>>>>>>>> there are privacy >>>>>>>>>>>>>>>>> > considerations to that. If, on the other hand, the >>>>>>>>>>>>>>>>> > multiple-personas-per-AS (presumably corresponding to >>>>>>>>>>>>>>>>> multiple humans) >>>>>>>>>>>>>>>>> > route is taken, we should consider whether that would >>>>>>>>>>>>>>>>> lead to various >>>>>>>>>>>>>>>>> > (e.g., market) forces driving consolidation to just a >>>>>>>>>>>>>>>>> handful of >>>>>>>>>>>>>>>>> > super-popular AS services. That topic is a current >>>>>>>>>>>>>>>>> matter of concern to >>>>>>>>>>>>>>>>> > some IETF participants. >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Ben, big +1 to this. This is something that we >>>>>>>>>>>>>>>>> discussed ages ago in the UMA working group, and it=E2=80= =99s one of the biggest >>>>>>>>>>>>>>>>> problems with the personal AS (and personal data store) m= odel. This kind of >>>>>>>>>>>>>>>>> thing makes RS-first trust models really difficult in pra= ctice. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve got so= ftware that wants >>>>>>>>>>>>>>>>> to access my medical information. It calls an RS and requ= ests access, but >>>>>>>>>>>>>>>>> it hasn=E2=80=99t been granted anything yet. Now I as the= RO have set up the RS so >>>>>>>>>>>>>>>>> that it talks to my personal AS, that only I use. In addi= tion to the RS >>>>>>>>>>>>>>>>> having to be able to figure out which medical records are= being requested >>>>>>>>>>>>>>>>> from the context of the unauthenticated request (which me= ans it needs >>>>>>>>>>>>>>>>> identifiers in the URL or something similar for the RS to= be able to tell, >>>>>>>>>>>>>>>>> assuming that it protects data for more than one person).= So this client >>>>>>>>>>>>>>>>> software doesn=E2=80=99t know who I am and doesn=E2=80=99= t know my medical record >>>>>>>>>>>>>>>>> information, makes a completely unauthorized request to t= he RS, and the RS >>>>>>>>>>>>>>>>> says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a= token=E2=80=9D. The client can now make a >>>>>>>>>>>>>>>>> direct correlation between the data that=E2=80=99s being = protected at the RS and >>>>>>>>>>>>>>>>> the person running the AS that protects it. Importantly, = this client makes >>>>>>>>>>>>>>>>> this call with no prior relationship to the RS and no rea= lly auditable way >>>>>>>>>>>>>>>>> to track it down after the fact. This is a design feature= in the good case, >>>>>>>>>>>>>>>>> and terrifying in the bad case. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> If the RS instead says =E2=80=9Cwelcome to Medicine Docto= r RS, >>>>>>>>>>>>>>>>> please talk to the Medicine Doctor AS to get access=E2=80= =9D, we haven=E2=80=99t exposed >>>>>>>>>>>>>>>>> anything at all. And from the perspective of both the pat= ient and the RS, >>>>>>>>>>>>>>>>> this is more privacy-preserving, and it=E2=80=99s really = the least surprising >>>>>>>>>>>>>>>>> option. Once the client gets to the AS, it can start a ne= gotiation of >>>>>>>>>>>>>>>>> figuring out who the RO is for the information being acce= ssed. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On top of this, the usability expectations of people >>>>>>>>>>>>>>>>> managing their own AS, or set of AS=E2=80=99s for multipl= e personas to keep things >>>>>>>>>>>>>>>>> separate, is a huge burden. Even in the tech community, I= know people who >>>>>>>>>>>>>>>>> can=E2=80=99t reliably manage more than one email address= for different purposes. I >>>>>>>>>>>>>>>>> wouldn=E2=80=99t expect my partner to do that =E2=80=94 t= hey have trouble enough balancing >>>>>>>>>>>>>>>>> all the logins and sessions required for different kids r= emote schooling, I >>>>>>>>>>>>>>>>> couldn=E2=80=99t imagine them having to understand all th= e requirements for >>>>>>>>>>>>>>>>> managing multiple authorization servers and associated po= licies. I also >>>>>>>>>>>>>>>>> don=E2=80=99t expect any person to =E2=80=9Cmanage keys= =E2=80=9D =E2=80=94 I=E2=80=99ve been on the internet for >>>>>>>>>>>>>>>>> decades and I can barely keep tabs on my GPG keys, and on= ly use them when I >>>>>>>>>>>>>>>>> am forced to. This is exactly the kind of =E2=80=9Cmarket= pressure=E2=80=9D that I think >>>>>>>>>>>>>>>>> Ben mentions above, people will just want to outsource th= at to someone >>>>>>>>>>>>>>>>> else, and the reality will be a few popular providers. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In which case, we could end up doing a ton of work to >>>>>>>>>>>>>>>>> allow an RS choice only to end up with a world where the = RS ends up making >>>>>>>>>>>>>>>>> a limited choice anyway. We see how that plays out with O= penID Connect =E2=80=94 >>>>>>>>>>>>>>>>> RP=E2=80=99s could allow arbitrary IdPs but they choose G= oogle because it works and >>>>>>>>>>>>>>>>> that=E2=80=99s where the users are. (And that=E2=80=99s n= ot to say anything of the >>>>>>>>>>>>>>>>> proprietary OIDC-like protocols, but that=E2=80=99s anoth= er discussion). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> For further reading on these topics, I recommend both =E2= =80=9CWhy >>>>>>>>>>>>>>>>> Johnny Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CS= CW Systems Fail=E2=80=9D. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> So what does this have to do with GNAP? I think we can be >>>>>>>>>>>>>>>>> clear-eyed on what kinds of expectations we have for the = participants. If >>>>>>>>>>>>>>>>> we expect users (RO=E2=80=99s) to have to set up the AS-R= S relationship, or expect >>>>>>>>>>>>>>>>> them to carry their AS, or manage their personal keys =E2= =80=94 I think we=E2=80=99ve lost >>>>>>>>>>>>>>>>> the battle for relevance. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>> 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 >>>>>>> >>>>>> --000000000000ea921505be574da9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I was referring to "By my definition, this model has two ASs since both are process= ing requests into tokens". If there's no reason to have 2 types of= ASs, that's fine then.=C2=A0
    But I'm a bit lost in where we stand with the idea.=C2= =A0

    Could you recap?=C2=A0=

    Fabien=C2=A0

    Le jeu.= 25 mars 2021 =C3=A0 08:16, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    <= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
    There=E2=80=99s no obvious = reason to have two types of ASs. Any AS that is executing the policies of t= he RS can look to GNAP like the RS itself. Why would GNAP expose that inter= face to anyone?=C2=A0

    Ad= rian

    On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault <fabien.im= bault@gmail.com> wrote:
    Note : I'm not sure that's a good idea, but having 2 = types of ASs is not that easy to grasp.

    Fabien=C2=A0

    Le jeu. 25 mars 2021 = =C3=A0 08:07, Fabien Imbault <fabien.imbault@gmail.com> a = =C3=A9crit=C2=A0:
    The purpose of either handling policies locally or delegating them to the = RO agent.=C2=A0

    Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    What purpose would be served = by GNAP splitting the AS into two components?

    Adrian=C2=A0

    On Thu, Ma= r 25, 2021 at 2:59 AM Fabien Imbault <fabien= .imbault@gmail.com> wrote:
    <= div dir=3D"auto">Isn't the AS-RO a component of the AS? Same idea as th= e interact component, it functionnally belongs to the AS role but could be = deployed either as a monolith or as a separate component?

    Fabien

    <= div class=3D"gmail_quote">
    Le jeu. 25 = mars 2021 =C3=A0 04:26, Adrian Gropper <agropp= er@healthurl.com> a =C3=A9crit=C2=A0:
    Yes, but I would say it=E2=80=99s not the RO th= at wants the access token. It=E2=80=99s the RO that wants the client making= the request to get an access token.=C2=A0

    Adrian

    On Wed, Mar 24, 2021 at 11:22 PM Alan Karp &l= t;alanhkarp@gmail.com> wrote:
    <= /div>
    Adrian Gropper <agropper@healthurl.com> wrote:

    <= /div>
    In this design, the AS is the AS-RS and the agent is the AS-RO. B= y my definition, this model has two ASs since both are processing requests = into tokens. The problem with this is complexity and privacy. The RO may no= t want to share the request information with the AS-RS.
    More precisely, RO has no c= hoice but to present the required information to AS-RS if RO wants an acces= s token.=C2=A0 However, RO does not want AS-RS to know the policy by which = RO delegates tokens.=C2=A0 That's why RO uses AS-RO for those delegatio= ns.

    ----------= ----
    Alan Karp


    On Wed, Mar 24, 202= 1 at 7:41 PM Adrian Gropper <agropp= er@healthurl.com> wrote:
    Thank you for creating th= e issue. My definition of AS is independent of AS-RO or AS-RS.=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#i= ssuecomment-806280421 I also agree with Alan's definition based on = delegation. An AS-RS would be a delegate of the RS.=C2=A0

    Based on that, I see it as obvious=C2=A0that the policy= has to be accessible (defined locally?) in order for it to be run as the c= ode that turns a request into an access token.=C2=A0

    The only other possibility is that the request is packaged by the AS and= sent elsewhere (an agent) for evaluation against policy and a proto-token = returned. In that case the AS is acting as a proxy and the PDP is elsewhere= . I can imagine that an AS-RS would behave this way so that the proto-token= could be turned into an access token by the AS-RS. Isn't this what Jus= tin is proposing? In this design, the AS is the AS-RS and the agent is the = AS-RO. By my definition, this model has two ASs since both are processing r= equests into tokens. The problem with this is complexity and privacy. The R= O may not want to share the request information with the AS-RS.
    <= br>
    Adrian

    On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault &l= t;fabien.imbault@gmail.com> w= rote:
    Isn't that what the AS is supposed to be, only with the = caveat that the policy is defined locally?=C2=A0

    Fabien=C2=A0


    Le mer. 24 mars 2021 =C3=A0 20:17, Alan = Karp <alanhkarp@gmail.com> a = =C3=A9crit=C2=A0:
    AS-RO is an AS that RO trusts to delega= te RO's access tokens according to RO's policies.=C2=A0=C2=A0

    --------------
    Alan Karp


    On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    =
    Hi= Alan and Adrian,

    I've created issue AS-RO policy de= legation (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/22= 3) to capture your input.=C2=A0
    A first question that arises:= can we give a definition to AS-RO?

    Thanks
    Fabien

    On Tue, Mar 23, 2021 at 4:15 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan,=C2=A0

    Yes, but in that flow, the token relationship between AS-RS and AS-RO is= only secure if the tokens issued by AS-RS are cryptographically attenuable= in the first place.=C2=A0
    =C2=A0
    Attenuated delegation is a requirement, but that doesn't= have to be done cryptographically.=C2=A0 Token exchange works just fine.= =C2=A0 SPKI and zcap-ld are examples of the crypto approach, and we used to= ken exchange in the system for HP.

    ----------= ----
    Alan Karp


    On Tue, Mar 23, 2021 at 4:12 AM Fabien Imb= ault <fabien.imbault@g= mail.com> wrote:
    Hi Alan,=C2=A0

    Yes, but in that= flow, the token relationship between AS-RS and AS-RO is only secure if the= tokens issued by AS-RS are cryptographically attenuable in the first place= .=C2=A0

    Fabien

    On Mon, Mar 22, 2021 at 9:26 P= M Alan Karp <alanhkarp@gmai= l.com> wrote:
    Justin Richer <jricher@mit.ed= u> wrote:

    But with all that in mind, I think the key here i= s going to be looking at what the inputs to the AS are, and how those can b= e defined in an interoperable way for AS=E2=80=99s that can accept them. I = think there=E2=80=99s a lot of room for innovation and flexibility here tha= t doesn=E2=80=99t break the trust model or core use cases. If I have an AS-= RS set that won=E2=80=99t accept my favorite flavor of policy engine inputs= , then I can decide not to use that one. But this is a very different quest= ion than saying the RS itself needs to accept my own AS =E2=80=94 and we ca= n=E2=80=99t keep conflating these two models.

    I agree.=C2=A0 The point of having an AS-RO is to allow RO t= o specify a policy for which of RO's access tokens should be delegated = under what conditions.=C2=A0 AS-RS should not need to understand those poli= cies.=C2=A0 The flow would be
    • RO contacts AS-RS and gets = one or more access tokens.
    • RO delegates one or more of those tokens= , potentially sub-scoped, to AS-RO.
    • A different user contacts AS-RO= to get a potentially sub-scoped access token from AS-RO.
    • That user= presents the access token delegated by AS-RO when invoking the resource.
    AS-RS only needs to verify that the delegation chai= n is legitimate, e.g., no increase in scope, and that it grants permission = for the request being made.=C2=A0 AS-RS does not need to understand the pol= icy behind granting the delegation by AS-RO.

    ----= ----------
    Alan Karp


    On Mon, Mar 22, 2021 at 11:40 AM Jus= tin Richer <jricher@mit.edu= > wrote:
    Adrian,

    I think this shows the problem with the termino= logy as it=E2=80=99s been applied in this conversation, which I=E2=80=99ve = tried to shine light on before. What you and others are calling the =E2=80= =9CRS=E2=80=9D is really the =E2=80=9CAS and RS working together=E2=80=9D = =E2=80=94 everything to the right of the line. When Denis had brought up = =E2=80=9Celiminating the AS=E2=80=9D in another thread, what he=E2=80=99d r= eally done is labeled everything to the right of the line as the =E2=80=9CR= S=E2=80=9D. Of course, the irony here is that everything to the right of th= e line used all be called the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserve= r=E2=80=9D in the OAuth 1 days. As you say below, I don=E2=80=99t want the = client to have visibility on what happens on that side.=C2=A0
    Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in th= e diagram is not the AS, as far as GNAP is concerned. It does not issue an = access token that the RS will accept. The elements to the left of the line = could be a lot of things, but they are NOT the AS =E2=80=94 by definition. = The client lives over on the left, but so do any external inputs to the AS.= These could be policy inputs on behalf of the RO, they could be presentati= on artifacts, they could be federated logins, they could be the output of p= olicy decisions. How the AS comes to trust those things is up to the AS=E2= =80=99s implementation. It=E2=80=99s something we can talk about, but ultim= ately GNAP won=E2=80=99t be in any position to dictate because in practice = some AS=E2=80=99s are simply going to internalize all policies and we will = never successfully force those open.=C2=A0

    But wit= h all that in mind, I think the key here is going to be looking at what the= inputs to the AS are, and how those can be defined in an interoperable way= for AS=E2=80=99s that can accept them. I think there=E2=80=99s a lot of ro= om for innovation and flexibility here that doesn=E2=80=99t break the trust= model or core use cases. If I have an AS-RS set that won=E2=80=99t accept = my favorite flavor of policy engine inputs, then I can decide not to use th= at one. But this is a very different question than saying the RS itself nee= ds to accept my own AS =E2=80=94 and we can=E2=80=99t keep conflating these= two models.

    So to me, GNAP can support a Zero Tru= st Architecture by LEVERAGING the AS, not by subsuming or eliminating it. I= t is in fact the AS, not the client and not the RS, that will request and c= onsume the results of a privacy-preserving zero-trust policy query thing. A= nything that happens downstream from that is of little concern to the zero-= trust components because, as you point out, it=E2=80=99s on the =E2=80=9Cot= her side=E2=80=9D of the line.=C2=A0

    I think we go= t this basic component model pretty right in OAuth: the AS and RS and clien= t working together. Where OAuth misses the mark is the assumption that the = user has to log in to the AS through a webpage and interact directly, there= by proving they=E2=80=99re the RO. It=E2=80=99s this latter space where I t= hink we can both push innovation and also address the important and compell= ing use cases like the ones you=E2=80=99re bringing.

    =C2=A0=E2=80=94 Justin

    On Mar= 22, 2021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I'm sorry, Justin. As a Resource Owner, I look at the RS trust= boundary (the dotted line in the diagram) as being the RS. I don't exp= ect any visibility into what's going on on the=C2=A0right.=C2=A0
    My problem with the framing you propose is that requests are g= oing to the RS (or the AS-RS) and I don't want to share my policies wit= h the AS-RS. I want to keep the RS and AS-RS as ignorant as possible.
    =

    Adrian

    On Mon, Mar 22, 2021 at 1:48 PM Justin Rich= er <jricher@mit.edu> wro= te:
    Adrian,=

    What you=E2=80=99re discussing below, in terms of loggi= ng in to a site, is not approaching the RS. You are in fact approaching the= client, and identifying both the AS and RS to the client. The client is a = client of your identity in this model, and the RS is part of the ide= ntity provider. It=E2=80=99s really important that we don=E2=80=99t conflat= e the RS and client in this way as it leads to a lot of confusion downstrea= m and a lot of broken trust boundaries.

    With that = model in mind, approaching the =E2=80=9CRS" and providing it your iden= tity is really just a case of the =E2=80=9Cfederated login to AS=E2=80=9D p= attern that we discussed on the WG call. The user here approaches an RS, wh= ich has its own AS. To share things from this RS, the RO has to authenticat= e to the RS=E2=80=99s AS. This particular AS allows the RO to do so using a= n external identity =E2=80=94 in which case, the AS is now a =E2=80=9Cclien= t=E2=80=9D of a separate, disconnected (but layered) delegation. The ultima= te client that eventually calls the RS down the way may or may not know abo= ut these layers.=C2=A0

    = <PastedGraphic-1.png>
    This same AS, which is closely= tied to the RS and trusted by the RS, might also take in FIDO credentials,= or DIDs, or any number of other proof mechanisms. The output of this is an= access token the RS trusts, but the input is up to the AS. The RS is not w= hat you=E2=80=99re logging in to.

    =C2=A0=E2=80=94 = Justin

    On Mar 22, 2021, at 1:28 = PM, Adrian Gropper <agro= pper@healthurl.com> wrote:

    I too am i= n favor of avoiding consolidation and correlation. Right now, when I approa= ch a service provider (RS) for the first time, I'm offered the opportun= ity to identify my persona as: email, sign-in with Google, Facebook, or App= le. I know there are people who try to create one-off email addresses but t= hat is mostly a waste of time.=C2=A0

    So, along come FIDO= 2 and DID wallets to the rescue. Now, in theory, I have a way to start out = my RS relationship pseudonymously.=C2=A0

    When I wa= nt my resource to be discovered or shared I will post that RS URL including= my pseudonym. If I then want to introduce a mediator=C2=A0in front of my A= S or messaging service=C2=A0endpoint, I have that option. If I want to keep= requests away from the mediator, I would publish an encryption key along w= ith my pseudonym.

    - Adrian



    On Mon, Mar 22, 2021 at 9:55 AM Justin Richer <jricher@mit.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, Ben= jamin Kaduk <kaduk@mit.edu>= ; wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhk= arp@gmail.com> shared a talk about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-= gnap/gnap-core-protocol/issues/145#issuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --
    TXAuth 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
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.= ietf.org/mailman/listinfo/txauth
    --000000000000ea921505be574da9-- From nobody Thu Mar 25 00:48:42 2021 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 308B93A1449 for ; Thu, 25 Mar 2021 00:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 OwU4-WGIOUC9 for ; Thu, 25 Mar 2021 00:48:35 -0700 (PDT) Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) (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 67AFA3A1447 for ; Thu, 25 Mar 2021 00:48:35 -0700 (PDT) Received: by mail-vs1-f52.google.com with SMTP id e13so399857vsl.5 for ; Thu, 25 Mar 2021 00:48:35 -0700 (PDT) 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=/E2Ilf2cp98W8pYLsxGL5mDh1N9rEiBGGbSsX3PSYpw=; b=oFpFMFUZcNbG6HmXSkm3HX8wmpiEtQoaqu0P8g/GO3XjDp/qQDzupmrawufz/Cgtqc wZEupmjEspHKtAOsfmFkWl2vqWMQTJ7TE1a7BhEnm8f4IIZlxfSFWBCPZPMOFY7PznI7 EoE1KzJXAVwclKkPIeUN/umiSOWGrIVBhMIFc8awLOCBFD/AdgfWSQD1FU4PN+XFoWzQ +gHRf9nAVxmvY1su70+3fQXmJJxhPUSFJndeoeXxv0AArxiHxQIF90Rkqs5dDKRcTIDz l/9DWBsDmEnXcw1m/xczkWnVzI72CbDUmChtz+6o4LNPsxvv6Lom8hUESvaoKNHci7M1 fWig== X-Gm-Message-State: AOAM530NnuHPFT2pAngAoVpcxjdxFPNgH0xnnD6n+i8cURGggt4DPQi2 4R93vhbaIxB4t5yhd21dpjIcnLjcsC0vXAadfAfREhhn0OY= X-Google-Smtp-Source: ABdhPJwWkYD+BudznlVIihLRz8GSfkKAcbbGZqWhdZM958F0uPvf+gPyl26xkqeounseH65pHD5kGxKOb9u/4tETBmA= X-Received: by 2002:a05:6102:24a:: with SMTP id a10mr4135567vsq.39.1616658514041; Thu, 25 Mar 2021 00:48:34 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> In-Reply-To: From: Adrian Gropper Date: Thu, 25 Mar 2021 03:48:22 -0400 Message-ID: To: Fabien Imbault Cc: Alan Karp , Benjamin Kaduk , GNAP Mailing List , Justin Richer , Mark Miller Content-Type: multipart/alternative; boundary="00000000000073df8505be57a456" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 07:48:40 -0000 --00000000000073df8505be57a456 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Recap: 1 - Justin (I think) introduced the idea of an AS on the RS trust boundary side. 2 - I said the RO should not have to share policies with the RS. 3 - Alan invented the concept of AS-RO and AS-RS to separate two kinds of PDPs. The thing is that step 2 is not symmetrical. The RO has a legitimate privacy interest in keeping their policies private and minimizing the leakage of information about requests that are posed against those policies. The RS, on the other hand, should be publishing its policies (e.g. what it=E2=80=99s selling or what jurisdiction it=E2=80=99s in or what tokens or= scopes it supports). The RS has no obvious privacy interest in GNAP. It=E2=80=99s jus= t an enforcer. There is one other privacy interest to consider around the RS and that is the requesting party (the end-user that is not the RO :-) might prefer to share attributes with the RS instead of the RO or something controlled by the RO. This case could be an =E2=80=9Cextension=E2=80=9D to GNAP and might= result in a split AS as a solution. This problem was introduced when the editors decided to replace RQ with end-user. Obviously, the RO end-user has no privacy interests relative to itself. Adrian On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault wrote: > I was referring to "By my definition, this model has two ASs since both > are processing requests into tokens". If there's no reason to have 2 type= s > of ASs, that's fine then. > But I'm a bit lost in where we stand with the idea. > > Could you recap? > > Fabien > > Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper a > =C3=A9crit : > >> There=E2=80=99s no obvious reason to have two types of ASs. Any AS that = is >> executing the policies of the RS can look to GNAP like the RS itself. Wh= y >> would GNAP expose that interface to anyone? >> >> Adrian >> >> On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault >> wrote: >> >>> Note : I'm not sure that's a good idea, but having 2 types of ASs is no= t >>> that easy to grasp. >>> >>> Fabien >>> >>> Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault >>> a =C3=A9crit : >>> >>>> The purpose of either handling policies locally or delegating them to >>>> the RO agent. >>>> >>>> Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper >>>> a =C3=A9crit : >>>> >>>>> What purpose would be served by GNAP splitting the AS into two >>>>> components? >>>>> >>>>> Adrian >>>>> >>>>> On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Isn't the AS-RO a component of the AS? Same idea as the interact >>>>>> component, it functionnally belongs to the AS role but could be depl= oyed >>>>>> either as a monolith or as a separate component? >>>>>> >>>>>> Fabien >>>>>> >>>>>> Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper >>>>>> a =C3=A9crit : >>>>>> >>>>>>> Yes, but I would say it=E2=80=99s not the RO that wants the access = token. >>>>>>> It=E2=80=99s the RO that wants the client making the request to get= an access >>>>>>> token. >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>> On Wed, Mar 24, 2021 at 11:22 PM Alan Karp >>>>>>> wrote: >>>>>>> >>>>>>>> Adrian Gropper wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> In this design, the AS is the AS-RS and the agent is the AS-RO. B= y >>>>>>>>> my definition, this model has two ASs since both are processing r= equests >>>>>>>>> into tokens. The problem with this is complexity and privacy. The= RO may >>>>>>>>> not want to share the request information with the AS-RS. >>>>>>>>> >>>>>>>> >>>>>>>> More precisely, RO has no choice but to present the required >>>>>>>> information to AS-RS if RO wants an access token. However, RO doe= s not >>>>>>>> want AS-RS to know the policy by which RO delegates tokens. That'= s why RO >>>>>>>> uses AS-RO for those delegations. >>>>>>>> >>>>>>>> -------------- >>>>>>>> Alan Karp >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper < >>>>>>>> agropper@healthurl.com> wrote: >>>>>>>> >>>>>>>>> Thank you for creating the issue. My definition of AS is >>>>>>>>> independent of AS-RO or AS-RS. >>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#iss= uecomment-806280421 >>>>>>>>> I also agree with Alan's definition based on delegation. An AS-RS= would be >>>>>>>>> a delegate of the RS. >>>>>>>>> >>>>>>>>> Based on that, I see it as obvious that the policy has to be >>>>>>>>> accessible (defined locally?) in order for it to be run as the co= de that >>>>>>>>> turns a request into an access token. >>>>>>>>> >>>>>>>>> The only other possibility is that the request is packaged by the >>>>>>>>> AS and sent elsewhere (an agent) for evaluation against policy an= d a >>>>>>>>> proto-token returned. In that case the AS is acting as a proxy an= d the PDP >>>>>>>>> is elsewhere. I can imagine that an AS-RS would behave this way s= o that the >>>>>>>>> proto-token could be turned into an access token by the AS-RS. Is= n't this >>>>>>>>> what Justin is proposing? In this design, the AS is the AS-RS and= the agent >>>>>>>>> is the AS-RO. By my definition, this model has two ASs since both= are >>>>>>>>> processing requests into tokens. The problem with this is complex= ity and >>>>>>>>> privacy. The RO may not want to share the request information wit= h the >>>>>>>>> AS-RS. >>>>>>>>> >>>>>>>>> Adrian >>>>>>>>> >>>>>>>>> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault < >>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Isn't that what the AS is supposed to be, only with the caveat >>>>>>>>>> that the policy is defined locally? >>>>>>>>>> >>>>>>>>>> Fabien >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp a >>>>>>>>>> =C3=A9crit : >>>>>>>>>> >>>>>>>>>>> AS-RO is an AS that RO trusts to delegate RO's access tokens >>>>>>>>>>> according to RO's policies. >>>>>>>>>>> >>>>>>>>>>> -------------- >>>>>>>>>>> Alan Karp >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault < >>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Alan and Adrian, >>>>>>>>>>>> >>>>>>>>>>>> I've created issue AS-RO policy delegation ( >>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) >>>>>>>>>>>> to capture your input. >>>>>>>>>>>> A first question that arises: can we give a definition to AS-R= O? >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Fabien >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Fabien Imbault wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yes, but in that flow, the token relationship between AS-RS >>>>>>>>>>>>>> and AS-RO is only secure if the tokens issued by AS-RS are >>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Attenuated delegation is a requirement, but that doesn't have >>>>>>>>>>>>> to be done cryptographically. Token exchange works just fine= . SPKI and >>>>>>>>>>>>> zcap-ld are examples of the crypto approach, and we used toke= n exchange in >>>>>>>>>>>>> the system for HP. >>>>>>>>>>>>> >>>>>>>>>>>>> -------------- >>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault < >>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yes, but in that flow, the token relationship between AS-RS >>>>>>>>>>>>>> and AS-RO is only secure if the tokens issued by AS-RS are >>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp < >>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Justin Richer wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> But with all that in mind, I think the key here is going t= o >>>>>>>>>>>>>>>> be looking at what the inputs to the AS are, and how those= can be defined >>>>>>>>>>>>>>>> in an interoperable way for AS=E2=80=99s that can accept t= hem. I think there=E2=80=99s a >>>>>>>>>>>>>>>> lot of room for innovation and flexibility here that doesn= =E2=80=99t break the >>>>>>>>>>>>>>>> trust model or core use cases. If I have an AS-RS set that= won=E2=80=99t accept my >>>>>>>>>>>>>>>> favorite flavor of policy engine inputs, then I can decide= not to use that >>>>>>>>>>>>>>>> one. But this is a very different question than saying the= RS itself needs >>>>>>>>>>>>>>>> to accept my own AS =E2=80=94 and we can=E2=80=99t keep co= nflating these two models. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I agree. The point of having an AS-RO is to allow RO to >>>>>>>>>>>>>>> specify a policy for which of RO's access tokens should be = delegated under >>>>>>>>>>>>>>> what conditions. AS-RS should not need to understand those= policies. The >>>>>>>>>>>>>>> flow would be >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - RO contacts AS-RS and gets one or more access tokens. >>>>>>>>>>>>>>> - RO delegates one or more of those tokens, potentially >>>>>>>>>>>>>>> sub-scoped, to AS-RO. >>>>>>>>>>>>>>> - A different user contacts AS-RO to get a potentially >>>>>>>>>>>>>>> sub-scoped access token from AS-RO. >>>>>>>>>>>>>>> - That user presents the access token delegated by AS-RO >>>>>>>>>>>>>>> when invoking the resource. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> AS-RS only needs to verify that the delegation chain is >>>>>>>>>>>>>>> legitimate, e.g., no increase in scope, and that it grants = permission for >>>>>>>>>>>>>>> the request being made. AS-RS does not need to understand = the policy >>>>>>>>>>>>>>> behind granting the delegation by AS-RO. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer < >>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I think this shows the problem with the terminology as it= =E2=80=99s >>>>>>>>>>>>>>>> been applied in this conversation, which I=E2=80=99ve trie= d to shine light on >>>>>>>>>>>>>>>> before. What you and others are calling the =E2=80=9CRS=E2= =80=9D is really the =E2=80=9CAS and RS >>>>>>>>>>>>>>>> working together=E2=80=9D =E2=80=94 everything to the righ= t of the line. When Denis had >>>>>>>>>>>>>>>> brought up =E2=80=9Celiminating the AS=E2=80=9D in another= thread, what he=E2=80=99d really done is >>>>>>>>>>>>>>>> labeled everything to the right of the line as the =E2=80= =9CRS=E2=80=9D. Of course, the >>>>>>>>>>>>>>>> irony here is that everything to the right of the line use= d all be called >>>>>>>>>>>>>>>> the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80= =9D in the OAuth 1 days. As you say below, I don=E2=80=99t >>>>>>>>>>>>>>>> want the client to have visibility on what happens on that= side. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D = in the diagram is >>>>>>>>>>>>>>>> not the AS, as far as GNAP is concerned. It does not issue= an access token >>>>>>>>>>>>>>>> that the RS will accept. The elements to the left of the l= ine could be a >>>>>>>>>>>>>>>> lot of things, but they are NOT the AS =E2=80=94 by defini= tion. The client lives >>>>>>>>>>>>>>>> over on the left, but so do any external inputs to the AS.= These could be >>>>>>>>>>>>>>>> policy inputs on behalf of the RO, they could be presentat= ion artifacts, >>>>>>>>>>>>>>>> they could be federated logins, they could be the output o= f policy >>>>>>>>>>>>>>>> decisions. How the AS comes to trust those things is up to= the AS=E2=80=99s >>>>>>>>>>>>>>>> implementation. It=E2=80=99s something we can talk about, = but ultimately GNAP won=E2=80=99t >>>>>>>>>>>>>>>> be in any position to dictate because in practice some AS= =E2=80=99s are simply >>>>>>>>>>>>>>>> going to internalize all policies and we will never succes= sfully force >>>>>>>>>>>>>>>> those open. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> But with all that in mind, I think the key here is going t= o >>>>>>>>>>>>>>>> be looking at what the inputs to the AS are, and how those= can be defined >>>>>>>>>>>>>>>> in an interoperable way for AS=E2=80=99s that can accept t= hem. I think there=E2=80=99s a >>>>>>>>>>>>>>>> lot of room for innovation and flexibility here that doesn= =E2=80=99t break the >>>>>>>>>>>>>>>> trust model or core use cases. If I have an AS-RS set that= won=E2=80=99t accept my >>>>>>>>>>>>>>>> favorite flavor of policy engine inputs, then I can decide= not to use that >>>>>>>>>>>>>>>> one. But this is a very different question than saying the= RS itself needs >>>>>>>>>>>>>>>> to accept my own AS =E2=80=94 and we can=E2=80=99t keep co= nflating these two models. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So to me, GNAP can support a Zero Trust Architecture by >>>>>>>>>>>>>>>> LEVERAGING the AS, not by subsuming or eliminating it. It = is in fact the >>>>>>>>>>>>>>>> AS, not the client and not the RS, that will request and c= onsume the >>>>>>>>>>>>>>>> results of a privacy-preserving zero-trust policy query th= ing. Anything >>>>>>>>>>>>>>>> that happens downstream from that is of little concern to = the zero-trust >>>>>>>>>>>>>>>> components because, as you point out, it=E2=80=99s on the = =E2=80=9Cother side=E2=80=9D of the line. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I think we got this basic component model pretty right in >>>>>>>>>>>>>>>> OAuth: the AS and RS and client working together. Where OA= uth misses the >>>>>>>>>>>>>>>> mark is the assumption that the user has to log in to the = AS through a >>>>>>>>>>>>>>>> webpage and interact directly, thereby proving they=E2=80= =99re the RO. It=E2=80=99s this >>>>>>>>>>>>>>>> latter space where I think we can both push innovation and= also address the >>>>>>>>>>>>>>>> important and compelling use cases like the ones you=E2=80= =99re bringing. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper < >>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm sorry, Justin. As a Resource Owner, I look at the RS >>>>>>>>>>>>>>>> trust boundary (the dotted line in the diagram) as being t= he RS. I don't >>>>>>>>>>>>>>>> expect any visibility into what's going on on the right. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> My problem with the framing you propose is that requests >>>>>>>>>>>>>>>> are going to the RS (or the AS-RS) and I don't want to sha= re my policies >>>>>>>>>>>>>>>> with the AS-RS. I want to keep the RS and AS-RS as ignoran= t as possible. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer < >>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> What you=E2=80=99re discussing below, in terms of logging= in to a >>>>>>>>>>>>>>>>> site, is not approaching the RS. You are in fact approach= ing the client, >>>>>>>>>>>>>>>>> and identifying both the AS and RS to the client. The cli= ent is a client *of >>>>>>>>>>>>>>>>> your identity* in this model, and the RS is part of the >>>>>>>>>>>>>>>>> identity provider. It=E2=80=99s really important that we = don=E2=80=99t conflate the RS and >>>>>>>>>>>>>>>>> client in this way as it leads to a lot of confusion down= stream and a lot >>>>>>>>>>>>>>>>> of broken trust boundaries. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> With that model in mind, approaching the =E2=80=9CRS" and >>>>>>>>>>>>>>>>> providing it your identity is really just a case of the = =E2=80=9Cfederated login to >>>>>>>>>>>>>>>>> AS=E2=80=9D pattern that we discussed on the WG call. The= user here approaches an >>>>>>>>>>>>>>>>> RS, which has its own AS. To share things from this RS, t= he RO has to >>>>>>>>>>>>>>>>> authenticate to the RS=E2=80=99s AS. This particular AS a= llows the RO to do so >>>>>>>>>>>>>>>>> using an external identity =E2=80=94 in which case, the A= S is now a =E2=80=9Cclient=E2=80=9D of a >>>>>>>>>>>>>>>>> separate, disconnected (but layered) delegation. The ulti= mate client that >>>>>>>>>>>>>>>>> eventually calls the RS down the way may or may not know = about these >>>>>>>>>>>>>>>>> layers. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This same AS, which is closely tied to the RS and trusted >>>>>>>>>>>>>>>>> by the RS, might also take in FIDO credentials, or DIDs, = or any number of >>>>>>>>>>>>>>>>> other proof mechanisms. The output of this is an access t= oken the RS >>>>>>>>>>>>>>>>> trusts, but the input is up to the AS. The RS is not what= you=E2=80=99re logging in >>>>>>>>>>>>>>>>> to. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper < >>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I too am in favor of avoiding consolidation and >>>>>>>>>>>>>>>>> correlation. Right now, when I approach a service provide= r (RS) for the >>>>>>>>>>>>>>>>> first time, I'm offered the opportunity to identify my pe= rsona as: email, >>>>>>>>>>>>>>>>> sign-in with Google, Facebook, or Apple. I know there are= people who try to >>>>>>>>>>>>>>>>> create one-off email addresses but that is mostly a waste= of time. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> So, along come FIDO2 and DID wallets to the rescue. Now, >>>>>>>>>>>>>>>>> in theory, I have a way to start out my RS relationship p= seudonymously. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> When I want my resource to be discovered or shared I will >>>>>>>>>>>>>>>>> post that RS URL including my pseudonym. If I then want t= o introduce a >>>>>>>>>>>>>>>>> mediator in front of my AS or messaging service endpoint,= I have that >>>>>>>>>>>>>>>>> option. If I want to keep requests away from the mediator= , I would publish >>>>>>>>>>>>>>>>> an encryption key along with my pseudonym. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - Adrian >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer < >>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk < >>>>>>>>>>>>>>>>>> kaduk@mit.edu> wrote: >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian >>>>>>>>>>>>>>>>>> Gropper wrote: >>>>>>>>>>>>>>>>>> >> @Alan Karp shared a talk about >>>>>>>>>>>>>>>>>> the Principle Of Least >>>>>>>>>>>>>>>>>> >> Authority (POLA) in a recent comment >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issue= s/145#issuecomment-803099693 >>>>>>>>>>>>>>>>>> >> I recommend it. >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> We might expect a protocol with authorization in the >>>>>>>>>>>>>>>>>> title to use authority >>>>>>>>>>>>>>>>>> >> as a core principle. I advocate for a GNAP design tha= t >>>>>>>>>>>>>>>>>> maximizes the power >>>>>>>>>>>>>>>>>> >> of the RO, to be seen as a human rights issue when th= e >>>>>>>>>>>>>>>>>> RO is a human. This >>>>>>>>>>>>>>>>>> >> causes me to ask how to combine better security with >>>>>>>>>>>>>>>>>> better human rights in >>>>>>>>>>>>>>>>>> >> GNAP. >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> Who should have the least authority in the GNAP desig= n? >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> The AS derives authority as a delegate of the RO. If >>>>>>>>>>>>>>>>>> we ask the RO to >>>>>>>>>>>>>>>>>> >> partition limited authority across dozens of differen= t >>>>>>>>>>>>>>>>>> ASs by domain and >>>>>>>>>>>>>>>>>> >> function, then we are not using technology to empower >>>>>>>>>>>>>>>>>> the individual. >>>>>>>>>>>>>>>>>> >> Probably the opposite, as we introduce consent fatigu= e >>>>>>>>>>>>>>>>>> and burden normal >>>>>>>>>>>>>>>>>> >> people to partition their lives into non-overlapping >>>>>>>>>>>>>>>>>> domains. >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> My experience says we should aim for one AS per >>>>>>>>>>>>>>>>>> persona because that maps >>>>>>>>>>>>>>>>>> >> into the way we manage our public and private >>>>>>>>>>>>>>>>>> identities. POLA would then >>>>>>>>>>>>>>>>>> >> teach care in keeping ASs and RSs related to work / >>>>>>>>>>>>>>>>>> public separate from >>>>>>>>>>>>>>>>>> >> ASs and RSs related to private life so that a policy >>>>>>>>>>>>>>>>>> vulnerability in our >>>>>>>>>>>>>>>>>> >> delegation to an AS would have the least likelihood o= f >>>>>>>>>>>>>>>>>> harm. >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > Thinking about how least authority/least privilege >>>>>>>>>>>>>>>>>> would apply to GNAP >>>>>>>>>>>>>>>>>> > seems like a useful exercise. I do want to point out >>>>>>>>>>>>>>>>>> some potential >>>>>>>>>>>>>>>>>> > pitfalls with one-AS-per-persona that we can also be >>>>>>>>>>>>>>>>>> aware of. If >>>>>>>>>>>>>>>>>> > one-AS-per-persona becomes one-persona-per-AS as well, >>>>>>>>>>>>>>>>>> then the AS's >>>>>>>>>>>>>>>>>> > identity in effect also serves as a persona identity >>>>>>>>>>>>>>>>>> and there are privacy >>>>>>>>>>>>>>>>>> > considerations to that. If, on the other hand, the >>>>>>>>>>>>>>>>>> > multiple-personas-per-AS (presumably corresponding to >>>>>>>>>>>>>>>>>> multiple humans) >>>>>>>>>>>>>>>>>> > route is taken, we should consider whether that would >>>>>>>>>>>>>>>>>> lead to various >>>>>>>>>>>>>>>>>> > (e.g., market) forces driving consolidation to just a >>>>>>>>>>>>>>>>>> handful of >>>>>>>>>>>>>>>>>> > super-popular AS services. That topic is a current >>>>>>>>>>>>>>>>>> matter of concern to >>>>>>>>>>>>>>>>>> > some IETF participants. >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi Ben, big +1 to this. This is something that we >>>>>>>>>>>>>>>>>> discussed ages ago in the UMA working group, and it=E2= =80=99s one of the biggest >>>>>>>>>>>>>>>>>> problems with the personal AS (and personal data store) = model. This kind of >>>>>>>>>>>>>>>>>> thing makes RS-first trust models really difficult in pr= actice. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve got s= oftware that >>>>>>>>>>>>>>>>>> wants to access my medical information. It calls an RS a= nd requests access, >>>>>>>>>>>>>>>>>> but it hasn=E2=80=99t been granted anything yet. Now I a= s the RO have set up the RS >>>>>>>>>>>>>>>>>> so that it talks to my personal AS, that only I use. In = addition to the RS >>>>>>>>>>>>>>>>>> having to be able to figure out which medical records ar= e being requested >>>>>>>>>>>>>>>>>> from the context of the unauthenticated request (which m= eans it needs >>>>>>>>>>>>>>>>>> identifiers in the URL or something similar for the RS t= o be able to tell, >>>>>>>>>>>>>>>>>> assuming that it protects data for more than one person)= . So this client >>>>>>>>>>>>>>>>>> software doesn=E2=80=99t know who I am and doesn=E2=80= =99t know my medical record >>>>>>>>>>>>>>>>>> information, makes a completely unauthorized request to = the RS, and the RS >>>>>>>>>>>>>>>>>> says =E2=80=9CGo to Justin=E2=80=99s personal AS to get = a token=E2=80=9D. The client can now make a >>>>>>>>>>>>>>>>>> direct correlation between the data that=E2=80=99s being= protected at the RS and >>>>>>>>>>>>>>>>>> the person running the AS that protects it. Importantly,= this client makes >>>>>>>>>>>>>>>>>> this call with no prior relationship to the RS and no re= ally auditable way >>>>>>>>>>>>>>>>>> to track it down after the fact. This is a design featur= e in the good case, >>>>>>>>>>>>>>>>>> and terrifying in the bad case. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> If the RS instead says =E2=80=9Cwelcome to Medicine Doct= or RS, >>>>>>>>>>>>>>>>>> please talk to the Medicine Doctor AS to get access=E2= =80=9D, we haven=E2=80=99t exposed >>>>>>>>>>>>>>>>>> anything at all. And from the perspective of both the pa= tient and the RS, >>>>>>>>>>>>>>>>>> this is more privacy-preserving, and it=E2=80=99s really= the least surprising >>>>>>>>>>>>>>>>>> option. Once the client gets to the AS, it can start a n= egotiation of >>>>>>>>>>>>>>>>>> figuring out who the RO is for the information being acc= essed. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On top of this, the usability expectations of people >>>>>>>>>>>>>>>>>> managing their own AS, or set of AS=E2=80=99s for multip= le personas to keep things >>>>>>>>>>>>>>>>>> separate, is a huge burden. Even in the tech community, = I know people who >>>>>>>>>>>>>>>>>> can=E2=80=99t reliably manage more than one email addres= s for different purposes. I >>>>>>>>>>>>>>>>>> wouldn=E2=80=99t expect my partner to do that =E2=80=94 = they have trouble enough balancing >>>>>>>>>>>>>>>>>> all the logins and sessions required for different kids = remote schooling, I >>>>>>>>>>>>>>>>>> couldn=E2=80=99t imagine them having to understand all t= he requirements for >>>>>>>>>>>>>>>>>> managing multiple authorization servers and associated p= olicies. I also >>>>>>>>>>>>>>>>>> don=E2=80=99t expect any person to =E2=80=9Cmanage keys= =E2=80=9D =E2=80=94 I=E2=80=99ve been on the internet for >>>>>>>>>>>>>>>>>> decades and I can barely keep tabs on my GPG keys, and o= nly use them when I >>>>>>>>>>>>>>>>>> am forced to. This is exactly the kind of =E2=80=9Cmarke= t pressure=E2=80=9D that I think >>>>>>>>>>>>>>>>>> Ben mentions above, people will just want to outsource t= hat to someone >>>>>>>>>>>>>>>>>> else, and the reality will be a few popular providers. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> In which case, we could end up doing a ton of work to >>>>>>>>>>>>>>>>>> allow an RS choice only to end up with a world where the= RS ends up making >>>>>>>>>>>>>>>>>> a limited choice anyway. We see how that plays out with = OpenID Connect =E2=80=94 >>>>>>>>>>>>>>>>>> RP=E2=80=99s could allow arbitrary IdPs but they choose = Google because it works and >>>>>>>>>>>>>>>>>> that=E2=80=99s where the users are. (And that=E2=80=99s = not to say anything of the >>>>>>>>>>>>>>>>>> proprietary OIDC-like protocols, but that=E2=80=99s anot= her discussion). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> For further reading on these topics, I recommend both >>>>>>>>>>>>>>>>>> =E2=80=9CWhy Johnny Can=E2=80=99t Encrypt=E2=80=9D and = =E2=80=9CWhy CSCW Systems Fail=E2=80=9D. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> So what does this have to do with GNAP? I think we can b= e >>>>>>>>>>>>>>>>>> clear-eyed on what kinds of expectations we have for the= participants. If >>>>>>>>>>>>>>>>>> we expect users (RO=E2=80=99s) to have to set up the AS-= RS relationship, or expect >>>>>>>>>>>>>>>>>> them to carry their AS, or manage their personal keys = =E2=80=94 I think we=E2=80=99ve lost >>>>>>>>>>>>>>>>>> the battle for relevance. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> 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 >>>>>>>> >>>>>>> --00000000000073df8505be57a456 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Recap:
    1 - Justin (I think) introd= uced the idea of an AS on the RS trust boundary side.
    2 - I said the RO should not have to share policies with the RS.
    3 - Alan invented the concept of AS-RO and AS-RS to separate= two kinds of PDPs.=C2=A0

    The thing is that step 2 is not symmetrical. The RO has a legitimate priv= acy interest in keeping their policies private and minimizing the leakage o= f information about requests that are posed against those policies.=C2=A0

    The RS, on the other hand= , should be publishing its policies (e.g. what it=E2=80=99s selling or what= jurisdiction it=E2=80=99s in or what tokens or scopes it supports). The RS= has no obvious privacy interest in GNAP. It=E2=80=99s just an enforcer.

    There is one other privacy= interest to consider around the RS and that is the requesting party (the e= nd-user that is not the RO :-) might prefer to share attributes with the RS= instead of the RO or something controlled by the RO. This case could be an= =E2=80=9Cextension=E2=80=9D to GNAP and might result in a split AS as a so= lution. This problem was introduced when the editors decided to replace RQ = with end-user. Obviously, the RO end-user has no privacy interests relative= to itself.

    Adrian
    =


    <= br>

    On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    I was referring to = "By my definition, this model h= as two ASs since both are processing requests into tokens". If there&#= 39;s no reason to have 2 types of ASs, that's fine then.=C2=A0
    But I'm a bit lost in w= here we stand with the idea.=C2=A0

    Could you recap?=C2=A0

    Fabien=C2=A0

    Le jeu. 25 mars 2021 =C3=A0= 08:16, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    There=E2=80=99s no obvious re= ason to have two types of ASs. Any AS that is executing the policies of the= RS can look to GNAP like the RS itself. Why would GNAP expose that interfa= ce to anyone?=C2=A0

    Adri= an

    On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault <fabien.imba= ult@gmail.com> wrote:
    Note : I'm not sure that's a good idea, but having 2 ty= pes of ASs is not that easy to grasp.

    Fabien=C2=A0

    Le jeu. 25 mars 2021 =C3= =A0 08:07, Fabien Imbault <fabien.imbault@gmail.com> a =C3= =A9crit=C2=A0:
    Th= e purpose of either handling policies locally or delegating them to the RO = agent.=C2=A0

    Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    What purpose would be served by G= NAP splitting the AS into two components?

    =
    Adrian=C2=A0

    On Thu, Mar 25= , 2021 at 2:59 AM Fabien Imbault <fabien.imb= ault@gmail.com> wrote:
    Isn't the AS-RO a component of the AS? Same idea as the in= teract component, it functionnally belongs to the AS role but could be depl= oyed either as a monolith or as a separate component?

    Fabien

    Le jeu. 25 mars= 2021 =C3=A0 04:26, Adrian Gropper <agropper@h= ealthurl.com> a =C3=A9crit=C2=A0:
    Yes, but I would say it=E2=80=99s not the RO that w= ants the access token. It=E2=80=99s the RO that wants the client making the= request to get an access token.=C2=A0

    Adrian

    On Wed, Mar 24, 2021 at 11:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Adrian Gropper <agropper@healthurl.com> wrote:

    In this design, the AS is the AS-RS and the agent is the AS-RO. By = my definition, this model has two ASs since both are processing requests in= to tokens. The problem with this is complexity and privacy. The RO may not = want to share the request information with the AS-RS.

    =
    More precisely, RO has no cho= ice but to present the required information to AS-RS if RO wants an access = token.=C2=A0 However, RO does not want AS-RS to know the policy by which RO= delegates tokens.=C2=A0 That's why RO uses AS-RO for those delegations= .

    ------------= --
    Alan Karp


    On Wed, Mar 24, 2021= at 7:41 PM Adrian Gropper <agroppe= r@healthurl.com> wrote:
    Thank you for creating the= issue. My definition of AS is independent of AS-RO or AS-RS.=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#i= ssuecomment-806280421 I also agree with Alan's definition based on = delegation. An AS-RS would be a delegate of the RS.=C2=A0

    Based on that, I see it as obvious=C2=A0that the policy= has to be accessible (defined locally?) in order for it to be run as the c= ode that turns a request into an access token.=C2=A0

    The only other possibility is that the request is packaged by the AS and= sent elsewhere (an agent) for evaluation against policy and a proto-token = returned. In that case the AS is acting as a proxy and the PDP is elsewhere= . I can imagine that an AS-RS would behave this way so that the proto-token= could be turned into an access token by the AS-RS. Isn't this what Jus= tin is proposing? In this design, the AS is the AS-RS and the agent is the = AS-RO. By my definition, this model has two ASs since both are processing r= equests into tokens. The problem with this is complexity and privacy. The R= O may not want to share the request information with the AS-RS.
    <= br>
    Adrian

    On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault &l= t;fabien.imbault@gmail.com> w= rote:
    Isn't that what the AS is supposed to be, only with the = caveat that the policy is defined locally?=C2=A0

    Fabien=C2=A0


    Le mer. 24 mars 2021 =C3=A0 20:17, Alan = Karp <alanhkarp@gmail.com> a = =C3=A9crit=C2=A0:
    AS-RO is an AS that RO trusts to delega= te RO's access tokens according to RO's policies.=C2=A0=C2=A0

    --------------
    Alan Karp


    On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    =
    Hi= Alan and Adrian,

    I've created issue AS-RO policy de= legation (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/22= 3) to capture your input.=C2=A0
    A first question that arises:= can we give a definition to AS-RO?

    Thanks
    Fabien

    On Tue, Mar 23, 2021 at 4:15 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan,=C2=A0

    Yes, but in that flow, the token relationship between AS-RS and AS-RO is= only secure if the tokens issued by AS-RS are cryptographically attenuable= in the first place.=C2=A0
    =C2=A0
    Attenuated delegation is a requirement, but that doesn't= have to be done cryptographically.=C2=A0 Token exchange works just fine.= =C2=A0 SPKI and zcap-ld are examples of the crypto approach, and we used to= ken exchange in the system for HP.

    ----------= ----
    Alan Karp


    On Tue, Mar 23, 2021 at 4:12 AM Fabien Imb= ault <fabien.imbault@g= mail.com> wrote:
    Hi Alan,=C2=A0

    Yes, but in that= flow, the token relationship between AS-RS and AS-RO is only secure if the= tokens issued by AS-RS are cryptographically attenuable in the first place= .=C2=A0

    Fabien

    On Mon, Mar 22, 2021 at 9:26 P= M Alan Karp <alanhkarp@gmai= l.com> wrote:
    Justin Richer <jricher@mit.ed= u> wrote:

    But with all that in mind, I think the key here i= s going to be looking at what the inputs to the AS are, and how those can b= e defined in an interoperable way for AS=E2=80=99s that can accept them. I = think there=E2=80=99s a lot of room for innovation and flexibility here tha= t doesn=E2=80=99t break the trust model or core use cases. If I have an AS-= RS set that won=E2=80=99t accept my favorite flavor of policy engine inputs= , then I can decide not to use that one. But this is a very different quest= ion than saying the RS itself needs to accept my own AS =E2=80=94 and we ca= n=E2=80=99t keep conflating these two models.

    I agree.=C2=A0 The point of having an AS-RO is to allow RO t= o specify a policy for which of RO's access tokens should be delegated = under what conditions.=C2=A0 AS-RS should not need to understand those poli= cies.=C2=A0 The flow would be
    • RO contacts AS-RS and gets = one or more access tokens.
    • RO delegates one or more of those tokens= , potentially sub-scoped, to AS-RO.
    • A different user contacts AS-RO= to get a potentially sub-scoped access token from AS-RO.
    • That user= presents the access token delegated by AS-RO when invoking the resource.
    AS-RS only needs to verify that the delegation chai= n is legitimate, e.g., no increase in scope, and that it grants permission = for the request being made.=C2=A0 AS-RS does not need to understand the pol= icy behind granting the delegation by AS-RO.

    ----= ----------
    Alan Karp


    On Mon, Mar 22, 2021 at 11:40 AM Jus= tin Richer <jricher@mit.edu= > wrote:
    Adrian,

    I think this shows the problem with the termino= logy as it=E2=80=99s been applied in this conversation, which I=E2=80=99ve = tried to shine light on before. What you and others are calling the =E2=80= =9CRS=E2=80=9D is really the =E2=80=9CAS and RS working together=E2=80=9D = =E2=80=94 everything to the right of the line. When Denis had brought up = =E2=80=9Celiminating the AS=E2=80=9D in another thread, what he=E2=80=99d r= eally done is labeled everything to the right of the line as the =E2=80=9CR= S=E2=80=9D. Of course, the irony here is that everything to the right of th= e line used all be called the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserve= r=E2=80=9D in the OAuth 1 days. As you say below, I don=E2=80=99t want the = client to have visibility on what happens on that side.=C2=A0
    Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in th= e diagram is not the AS, as far as GNAP is concerned. It does not issue an = access token that the RS will accept. The elements to the left of the line = could be a lot of things, but they are NOT the AS =E2=80=94 by definition. = The client lives over on the left, but so do any external inputs to the AS.= These could be policy inputs on behalf of the RO, they could be presentati= on artifacts, they could be federated logins, they could be the output of p= olicy decisions. How the AS comes to trust those things is up to the AS=E2= =80=99s implementation. It=E2=80=99s something we can talk about, but ultim= ately GNAP won=E2=80=99t be in any position to dictate because in practice = some AS=E2=80=99s are simply going to internalize all policies and we will = never successfully force those open.=C2=A0

    But wit= h all that in mind, I think the key here is going to be looking at what the= inputs to the AS are, and how those can be defined in an interoperable way= for AS=E2=80=99s that can accept them. I think there=E2=80=99s a lot of ro= om for innovation and flexibility here that doesn=E2=80=99t break the trust= model or core use cases. If I have an AS-RS set that won=E2=80=99t accept = my favorite flavor of policy engine inputs, then I can decide not to use th= at one. But this is a very different question than saying the RS itself nee= ds to accept my own AS =E2=80=94 and we can=E2=80=99t keep conflating these= two models.

    So to me, GNAP can support a Zero Tru= st Architecture by LEVERAGING the AS, not by subsuming or eliminating it. I= t is in fact the AS, not the client and not the RS, that will request and c= onsume the results of a privacy-preserving zero-trust policy query thing. A= nything that happens downstream from that is of little concern to the zero-= trust components because, as you point out, it=E2=80=99s on the =E2=80=9Cot= her side=E2=80=9D of the line.=C2=A0

    I think we go= t this basic component model pretty right in OAuth: the AS and RS and clien= t working together. Where OAuth misses the mark is the assumption that the = user has to log in to the AS through a webpage and interact directly, there= by proving they=E2=80=99re the RO. It=E2=80=99s this latter space where I t= hink we can both push innovation and also address the important and compell= ing use cases like the ones you=E2=80=99re bringing.

    =C2=A0=E2=80=94 Justin

    On Mar= 22, 2021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I'm sorry, Justin. As a Resource Owner, I look at the RS trust= boundary (the dotted line in the diagram) as being the RS. I don't exp= ect any visibility into what's going on on the=C2=A0right.=C2=A0
    My problem with the framing you propose is that requests are g= oing to the RS (or the AS-RS) and I don't want to share my policies wit= h the AS-RS. I want to keep the RS and AS-RS as ignorant as possible.
    =

    Adrian

    On Mon, Mar 22, 2021 at 1:48 PM Justin Rich= er <jricher@mit.edu> wro= te:
    Adrian,=

    What you=E2=80=99re discussing below, in terms of loggi= ng in to a site, is not approaching the RS. You are in fact approaching the= client, and identifying both the AS and RS to the client. The client is a = client of your identity in this model, and the RS is part of the ide= ntity provider. It=E2=80=99s really important that we don=E2=80=99t conflat= e the RS and client in this way as it leads to a lot of confusion downstrea= m and a lot of broken trust boundaries.

    With that = model in mind, approaching the =E2=80=9CRS" and providing it your iden= tity is really just a case of the =E2=80=9Cfederated login to AS=E2=80=9D p= attern that we discussed on the WG call. The user here approaches an RS, wh= ich has its own AS. To share things from this RS, the RO has to authenticat= e to the RS=E2=80=99s AS. This particular AS allows the RO to do so using a= n external identity =E2=80=94 in which case, the AS is now a =E2=80=9Cclien= t=E2=80=9D of a separate, disconnected (but layered) delegation. The ultima= te client that eventually calls the RS down the way may or may not know abo= ut these layers.=C2=A0

    <PastedGraphic-1.png>
    This sam= e AS, which is closely tied to the RS and trusted by the RS, might also tak= e in FIDO credentials, or DIDs, or any number of other proof mechanisms. Th= e output of this is an access token the RS trusts, but the input is up to t= he AS. The RS is not what you=E2=80=99re logging in to.

    =C2=A0=E2=80=94 Justin

    On = Mar 22, 2021, at 1:28 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I too am in favor of avoiding consolidation and correlation. Ri= ght now, when I approach a service provider (RS) for the first time, I'= m offered the opportunity to identify my persona as: email, sign-in with Go= ogle, Facebook, or Apple. I know there are people who try to create one-off= email addresses but that is mostly a waste of time.=C2=A0

    So, along come FIDO2 and DID wallets to the rescue. Now, in theory, I ha= ve a way to start out my RS relationship pseudonymously.=C2=A0
    When I want my resource to be discovered or shared I will post= that RS URL including my pseudonym. If I then want to introduce a mediator= =C2=A0in front of my AS or messaging service=C2=A0endpoint, I have that opt= ion. If I want to keep requests away from the mediator, I would publish an = encryption key along with my pseudonym.

    - Adrian



    On Mon, Mar 22, 2021 at 9:55 AM Justin Ri= cher <jricher@mit.edu> w= rote:
    On Mar 21,= 2021, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhk= arp@gmail.com> shared a talk about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-= gnap/gnap-core-protocol/issues/145#issuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --
    TXAuth 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
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.= ietf.org/mailman/listinfo/txauth
    --00000000000073df8505be57a456-- From nobody Thu Mar 25 01:15:21 2021 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 AEF1C3A1552 for ; Thu, 25 Mar 2021 01:15:19 -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 0Xh4ZWfjj1rZ for ; Thu, 25 Mar 2021 01:15:14 -0700 (PDT) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0: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 5A8743A1556 for ; Thu, 25 Mar 2021 01:15:14 -0700 (PDT) Received: by mail-il1-x132.google.com with SMTP id d2so1395450ilm.10 for ; Thu, 25 Mar 2021 01:15: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=ARqx907y29yyApNoTiVwOViORG0h5YgGFQgty5RDtDY=; b=oiGzIpiOUY6Zm2Y7LYElTK9nj9d5dJhhrtQAkIBeBzkfCO5rLI1kqZdYyPw/2TAl3p Bph70xUnNJhLtFUclY8oIHSAPvISb+tMesbHTt83t+/A+mlAFpz/1TZ7DjHZP+61rbH6 KXt2VQslri+YB/9oZLWL3zxreQ7bgkjLUNtyPXHHy2ogLB/Y1Dr2puoCTsXK3vOm33Jq ximdHg6TpLWRNWujrgqaQko0qfHHMh/sZZFU5mFGvqH+eWoIkXXNJ+o7ABsU7zc9qT5M Ho7fygAmwNk0p0Ov3gs1ny9PmZb5wMmWxBaqrWs95E2WwfzQdOdNhifnVACan9q0P30p 9unw== 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=ARqx907y29yyApNoTiVwOViORG0h5YgGFQgty5RDtDY=; b=RDx7lfZseDIt6j0A7KUyfqjUz04loim6lzVkXrnIlpGwchLcekMfW9DN2CZvupvptD 1KQV4eL7FfxuGKNXCxT4dVqOdfnS6Pv/zTAoFVvNcpBPp59lztIgtGDveitp4quPO9p7 oUP9DRrQFTXZEV0nqfuTtOZpWrg16mHT503pM070kACvwJ7mEvRrgNZRXwR4SwQzifgu VjEztxgXmnz5BIC1+7wIWf0RGgg3X5JybF9HEsuNOL7yxPMsqDZgr8HohSfWB5W0pGe2 nShWjbUdy34fAyvZ/ax1/QNSpnTtEvPyhxEcw86ExWbkzi1yT2hJZ+HYCZ3/ixdW7gn9 iTTQ== X-Gm-Message-State: AOAM533kyVp1jadG5g2adw+segrlOShZd9V3nY/s6WAlktaHHVnprNKi cfiQQhV3GUEnRpF6qd1OJmuTtjMgyVYj7APUdcU= X-Google-Smtp-Source: ABdhPJyIgWgzHs/KTOQeiHMz/C2DOUGKA/g0tTeTt63yJgi8lsoZ6WfNwB+Q0ZVzbGlZ5TZqc+yaOPmfVkqa1N0kxoA= X-Received: by 2002:a92:4b05:: with SMTP id m5mr5351507ilg.188.1616660112771; Thu, 25 Mar 2021 01:15:12 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> In-Reply-To: From: Fabien Imbault Date: Thu, 25 Mar 2021 09:15:01 +0100 Message-ID: To: Adrian Gropper Cc: Alan Karp , Benjamin Kaduk , GNAP Mailing List , Justin Richer , Mark Miller Content-Type: multipart/alternative; boundary="000000000000be927705be5803eb" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 08:15:20 -0000 --000000000000be927705be5803eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks. The general problem statement is clear. The proposed solution a bit less (to me). I understood that from point 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obvious reason to have = two types of ASs". Do you see an alternative ? Regarding the last item, I don't think that naming RQ by end-user created the problem. It might just highlight the asymmetry, which fundamentally exists. Fabien On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper wrote: > Recap: > 1 - Justin (I think) introduced the idea of an AS on the RS trust boundar= y > side. > 2 - I said the RO should not have to share policies with the RS. > 3 - Alan invented the concept of AS-RO and AS-RS to separate two kinds of > PDPs. > > The thing is that step 2 is not symmetrical. The RO has a legitimate > privacy interest in keeping their policies private and minimizing the > leakage of information about requests that are posed against those > policies. > > The RS, on the other hand, should be publishing its policies (e.g. what > it=E2=80=99s selling or what jurisdiction it=E2=80=99s in or what tokens = or scopes it > supports). The RS has no obvious privacy interest in GNAP. It=E2=80=99s j= ust an > enforcer. > > There is one other privacy interest to consider around the RS and that is > the requesting party (the end-user that is not the RO :-) might prefer to > share attributes with the RS instead of the RO or something controlled by > the RO. This case could be an =E2=80=9Cextension=E2=80=9D to GNAP and mig= ht result in a > split AS as a solution. This problem was introduced when the editors > decided to replace RQ with end-user. Obviously, the RO end-user has no > privacy interests relative to itself. > > Adrian > > > > > On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault > wrote: > >> I was referring to "By my definition, this model has two ASs since both >> are processing requests into tokens". If there's no reason to have 2 typ= es >> of ASs, that's fine then. >> But I'm a bit lost in where we stand with the idea. >> >> Could you recap? >> >> Fabien >> >> Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper a >> =C3=A9crit : >> >>> There=E2=80=99s no obvious reason to have two types of ASs. Any AS that= is >>> executing the policies of the RS can look to GNAP like the RS itself. W= hy >>> would GNAP expose that interface to anyone? >>> >>> Adrian >>> >>> On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault >>> wrote: >>> >>>> Note : I'm not sure that's a good idea, but having 2 types of ASs is >>>> not that easy to grasp. >>>> >>>> Fabien >>>> >>>> Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault >>>> a =C3=A9crit : >>>> >>>>> The purpose of either handling policies locally or delegating them to >>>>> the RO agent. >>>>> >>>>> Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper >>>>> a =C3=A9crit : >>>>> >>>>>> What purpose would be served by GNAP splitting the AS into two >>>>>> components? >>>>>> >>>>>> Adrian >>>>>> >>>>>> On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>>> Isn't the AS-RO a component of the AS? Same idea as the interact >>>>>>> component, it functionnally belongs to the AS role but could be dep= loyed >>>>>>> either as a monolith or as a separate component? >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper >>>>>>> a =C3=A9crit : >>>>>>> >>>>>>>> Yes, but I would say it=E2=80=99s not the RO that wants the access= token. >>>>>>>> It=E2=80=99s the RO that wants the client making the request to ge= t an access >>>>>>>> token. >>>>>>>> >>>>>>>> Adrian >>>>>>>> >>>>>>>> On Wed, Mar 24, 2021 at 11:22 PM Alan Karp >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Adrian Gropper wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> In this design, the AS is the AS-RS and the agent is the AS-RO. >>>>>>>>>> By my definition, this model has two ASs since both are processi= ng requests >>>>>>>>>> into tokens. The problem with this is complexity and privacy. Th= e RO may >>>>>>>>>> not want to share the request information with the AS-RS. >>>>>>>>>> >>>>>>>>> >>>>>>>>> More precisely, RO has no choice but to present the required >>>>>>>>> information to AS-RS if RO wants an access token. However, RO do= es not >>>>>>>>> want AS-RS to know the policy by which RO delegates tokens. That= 's why RO >>>>>>>>> uses AS-RO for those delegations. >>>>>>>>> >>>>>>>>> -------------- >>>>>>>>> Alan Karp >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper < >>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>> >>>>>>>>>> Thank you for creating the issue. My definition of AS is >>>>>>>>>> independent of AS-RO or AS-RS. >>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#is= suecomment-806280421 >>>>>>>>>> I also agree with Alan's definition based on delegation. An AS-R= S would be >>>>>>>>>> a delegate of the RS. >>>>>>>>>> >>>>>>>>>> Based on that, I see it as obvious that the policy has to be >>>>>>>>>> accessible (defined locally?) in order for it to be run as the c= ode that >>>>>>>>>> turns a request into an access token. >>>>>>>>>> >>>>>>>>>> The only other possibility is that the request is packaged by th= e >>>>>>>>>> AS and sent elsewhere (an agent) for evaluation against policy a= nd a >>>>>>>>>> proto-token returned. In that case the AS is acting as a proxy a= nd the PDP >>>>>>>>>> is elsewhere. I can imagine that an AS-RS would behave this way = so that the >>>>>>>>>> proto-token could be turned into an access token by the AS-RS. I= sn't this >>>>>>>>>> what Justin is proposing? In this design, the AS is the AS-RS an= d the agent >>>>>>>>>> is the AS-RO. By my definition, this model has two ASs since bot= h are >>>>>>>>>> processing requests into tokens. The problem with this is comple= xity and >>>>>>>>>> privacy. The RO may not want to share the request information wi= th the >>>>>>>>>> AS-RS. >>>>>>>>>> >>>>>>>>>> Adrian >>>>>>>>>> >>>>>>>>>> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault < >>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Isn't that what the AS is supposed to be, only with the caveat >>>>>>>>>>> that the policy is defined locally? >>>>>>>>>>> >>>>>>>>>>> Fabien >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp a >>>>>>>>>>> =C3=A9crit : >>>>>>>>>>> >>>>>>>>>>>> AS-RO is an AS that RO trusts to delegate RO's access tokens >>>>>>>>>>>> according to RO's policies. >>>>>>>>>>>> >>>>>>>>>>>> -------------- >>>>>>>>>>>> Alan Karp >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault < >>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Alan and Adrian, >>>>>>>>>>>>> >>>>>>>>>>>>> I've created issue AS-RO policy delegation ( >>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223= ) >>>>>>>>>>>>> to capture your input. >>>>>>>>>>>>> A first question that arises: can we give a definition to >>>>>>>>>>>>> AS-RO? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> Fabien >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Fabien Imbault wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, but in that flow, the token relationship between AS-RS >>>>>>>>>>>>>>> and AS-RO is only secure if the tokens issued by AS-RS are >>>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Attenuated delegation is a requirement, but that doesn't hav= e >>>>>>>>>>>>>> to be done cryptographically. Token exchange works just fin= e. SPKI and >>>>>>>>>>>>>> zcap-ld are examples of the crypto approach, and we used tok= en exchange in >>>>>>>>>>>>>> the system for HP. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault < >>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, but in that flow, the token relationship between AS-RS >>>>>>>>>>>>>>> and AS-RO is only secure if the tokens issued by AS-RS are >>>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp < >>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Justin Richer wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> But with all that in mind, I think the key here is going >>>>>>>>>>>>>>>>> to be looking at what the inputs to the AS are, and how t= hose can be >>>>>>>>>>>>>>>>> defined in an interoperable way for AS=E2=80=99s that can= accept them. I think >>>>>>>>>>>>>>>>> there=E2=80=99s a lot of room for innovation and flexibil= ity here that doesn=E2=80=99t >>>>>>>>>>>>>>>>> break the trust model or core use cases. If I have an AS-= RS set that won=E2=80=99t >>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine inputs, then I= can decide not to >>>>>>>>>>>>>>>>> use that one. But this is a very different question than = saying the RS >>>>>>>>>>>>>>>>> itself needs to accept my own AS =E2=80=94 and we can=E2= =80=99t keep conflating these two >>>>>>>>>>>>>>>>> models. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I agree. The point of having an AS-RO is to allow RO to >>>>>>>>>>>>>>>> specify a policy for which of RO's access tokens should be= delegated under >>>>>>>>>>>>>>>> what conditions. AS-RS should not need to understand thos= e policies. The >>>>>>>>>>>>>>>> flow would be >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - RO contacts AS-RS and gets one or more access tokens. >>>>>>>>>>>>>>>> - RO delegates one or more of those tokens, potentially >>>>>>>>>>>>>>>> sub-scoped, to AS-RO. >>>>>>>>>>>>>>>> - A different user contacts AS-RO to get a potentially >>>>>>>>>>>>>>>> sub-scoped access token from AS-RO. >>>>>>>>>>>>>>>> - That user presents the access token delegated by >>>>>>>>>>>>>>>> AS-RO when invoking the resource. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> AS-RS only needs to verify that the delegation chain is >>>>>>>>>>>>>>>> legitimate, e.g., no increase in scope, and that it grants= permission for >>>>>>>>>>>>>>>> the request being made. AS-RS does not need to understand= the policy >>>>>>>>>>>>>>>> behind granting the delegation by AS-RO. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer < >>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I think this shows the problem with the terminology as >>>>>>>>>>>>>>>>> it=E2=80=99s been applied in this conversation, which I= =E2=80=99ve tried to shine light on >>>>>>>>>>>>>>>>> before. What you and others are calling the =E2=80=9CRS= =E2=80=9D is really the =E2=80=9CAS and RS >>>>>>>>>>>>>>>>> working together=E2=80=9D =E2=80=94 everything to the rig= ht of the line. When Denis had >>>>>>>>>>>>>>>>> brought up =E2=80=9Celiminating the AS=E2=80=9D in anothe= r thread, what he=E2=80=99d really done is >>>>>>>>>>>>>>>>> labeled everything to the right of the line as the =E2=80= =9CRS=E2=80=9D. Of course, the >>>>>>>>>>>>>>>>> irony here is that everything to the right of the line us= ed all be called >>>>>>>>>>>>>>>>> the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80= =9D in the OAuth 1 days. As you say below, I don=E2=80=99t >>>>>>>>>>>>>>>>> want the client to have visibility on what happens on tha= t side. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D= in the diagram >>>>>>>>>>>>>>>>> is not the AS, as far as GNAP is concerned. It does not i= ssue an access >>>>>>>>>>>>>>>>> token that the RS will accept. The elements to the left o= f the line could >>>>>>>>>>>>>>>>> be a lot of things, but they are NOT the AS =E2=80=94 by = definition. The client >>>>>>>>>>>>>>>>> lives over on the left, but so do any external inputs to = the AS. These >>>>>>>>>>>>>>>>> could be policy inputs on behalf of the RO, they could be= presentation >>>>>>>>>>>>>>>>> artifacts, they could be federated logins, they could be = the output of >>>>>>>>>>>>>>>>> policy decisions. How the AS comes to trust those things = is up to the AS=E2=80=99s >>>>>>>>>>>>>>>>> implementation. It=E2=80=99s something we can talk about,= but ultimately GNAP won=E2=80=99t >>>>>>>>>>>>>>>>> be in any position to dictate because in practice some AS= =E2=80=99s are simply >>>>>>>>>>>>>>>>> going to internalize all policies and we will never succe= ssfully force >>>>>>>>>>>>>>>>> those open. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> But with all that in mind, I think the key here is going >>>>>>>>>>>>>>>>> to be looking at what the inputs to the AS are, and how t= hose can be >>>>>>>>>>>>>>>>> defined in an interoperable way for AS=E2=80=99s that can= accept them. I think >>>>>>>>>>>>>>>>> there=E2=80=99s a lot of room for innovation and flexibil= ity here that doesn=E2=80=99t >>>>>>>>>>>>>>>>> break the trust model or core use cases. If I have an AS-= RS set that won=E2=80=99t >>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine inputs, then I= can decide not to >>>>>>>>>>>>>>>>> use that one. But this is a very different question than = saying the RS >>>>>>>>>>>>>>>>> itself needs to accept my own AS =E2=80=94 and we can=E2= =80=99t keep conflating these two >>>>>>>>>>>>>>>>> models. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> So to me, GNAP can support a Zero Trust Architecture by >>>>>>>>>>>>>>>>> LEVERAGING the AS, not by subsuming or eliminating it. It= is in fact the >>>>>>>>>>>>>>>>> AS, not the client and not the RS, that will request and = consume the >>>>>>>>>>>>>>>>> results of a privacy-preserving zero-trust policy query t= hing. Anything >>>>>>>>>>>>>>>>> that happens downstream from that is of little concern to= the zero-trust >>>>>>>>>>>>>>>>> components because, as you point out, it=E2=80=99s on the= =E2=80=9Cother side=E2=80=9D of the line. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I think we got this basic component model pretty right in >>>>>>>>>>>>>>>>> OAuth: the AS and RS and client working together. Where O= Auth misses the >>>>>>>>>>>>>>>>> mark is the assumption that the user has to log in to the= AS through a >>>>>>>>>>>>>>>>> webpage and interact directly, thereby proving they=E2=80= =99re the RO. It=E2=80=99s this >>>>>>>>>>>>>>>>> latter space where I think we can both push innovation an= d also address the >>>>>>>>>>>>>>>>> important and compelling use cases like the ones you=E2= =80=99re bringing. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper < >>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'm sorry, Justin. As a Resource Owner, I look at the RS >>>>>>>>>>>>>>>>> trust boundary (the dotted line in the diagram) as being = the RS. I don't >>>>>>>>>>>>>>>>> expect any visibility into what's going on on the right. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> My problem with the framing you propose is that requests >>>>>>>>>>>>>>>>> are going to the RS (or the AS-RS) and I don't want to sh= are my policies >>>>>>>>>>>>>>>>> with the AS-RS. I want to keep the RS and AS-RS as ignora= nt as possible. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer < >>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> What you=E2=80=99re discussing below, in terms of loggin= g in to a >>>>>>>>>>>>>>>>>> site, is not approaching the RS. You are in fact approac= hing the client, >>>>>>>>>>>>>>>>>> and identifying both the AS and RS to the client. The cl= ient is a client *of >>>>>>>>>>>>>>>>>> your identity* in this model, and the RS is part of the >>>>>>>>>>>>>>>>>> identity provider. It=E2=80=99s really important that we= don=E2=80=99t conflate the RS and >>>>>>>>>>>>>>>>>> client in this way as it leads to a lot of confusion dow= nstream and a lot >>>>>>>>>>>>>>>>>> of broken trust boundaries. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> With that model in mind, approaching the =E2=80=9CRS" an= d >>>>>>>>>>>>>>>>>> providing it your identity is really just a case of the = =E2=80=9Cfederated login to >>>>>>>>>>>>>>>>>> AS=E2=80=9D pattern that we discussed on the WG call. Th= e user here approaches an >>>>>>>>>>>>>>>>>> RS, which has its own AS. To share things from this RS, = the RO has to >>>>>>>>>>>>>>>>>> authenticate to the RS=E2=80=99s AS. This particular AS = allows the RO to do so >>>>>>>>>>>>>>>>>> using an external identity =E2=80=94 in which case, the = AS is now a =E2=80=9Cclient=E2=80=9D of a >>>>>>>>>>>>>>>>>> separate, disconnected (but layered) delegation. The ult= imate client that >>>>>>>>>>>>>>>>>> eventually calls the RS down the way may or may not know= about these >>>>>>>>>>>>>>>>>> layers. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> This same AS, which is closely tied to the RS and truste= d >>>>>>>>>>>>>>>>>> by the RS, might also take in FIDO credentials, or DIDs,= or any number of >>>>>>>>>>>>>>>>>> other proof mechanisms. The output of this is an access = token the RS >>>>>>>>>>>>>>>>>> trusts, but the input is up to the AS. The RS is not wha= t you=E2=80=99re logging in >>>>>>>>>>>>>>>>>> to. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper < >>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I too am in favor of avoiding consolidation and >>>>>>>>>>>>>>>>>> correlation. Right now, when I approach a service provid= er (RS) for the >>>>>>>>>>>>>>>>>> first time, I'm offered the opportunity to identify my p= ersona as: email, >>>>>>>>>>>>>>>>>> sign-in with Google, Facebook, or Apple. I know there ar= e people who try to >>>>>>>>>>>>>>>>>> create one-off email addresses but that is mostly a wast= e of time. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> So, along come FIDO2 and DID wallets to the rescue. Now, >>>>>>>>>>>>>>>>>> in theory, I have a way to start out my RS relationship = pseudonymously. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> When I want my resource to be discovered or shared I wil= l >>>>>>>>>>>>>>>>>> post that RS URL including my pseudonym. If I then want = to introduce a >>>>>>>>>>>>>>>>>> mediator in front of my AS or messaging service endpoint= , I have that >>>>>>>>>>>>>>>>>> option. If I want to keep requests away from the mediato= r, I would publish >>>>>>>>>>>>>>>>>> an encryption key along with my pseudonym. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> - Adrian >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer < >>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk < >>>>>>>>>>>>>>>>>>> kaduk@mit.edu> wrote: >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian >>>>>>>>>>>>>>>>>>> Gropper wrote: >>>>>>>>>>>>>>>>>>> >> @Alan Karp shared a talk about >>>>>>>>>>>>>>>>>>> the Principle Of Least >>>>>>>>>>>>>>>>>>> >> Authority (POLA) in a recent comment >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issu= es/145#issuecomment-803099693 >>>>>>>>>>>>>>>>>>> >> I recommend it. >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> We might expect a protocol with authorization in the >>>>>>>>>>>>>>>>>>> title to use authority >>>>>>>>>>>>>>>>>>> >> as a core principle. I advocate for a GNAP design >>>>>>>>>>>>>>>>>>> that maximizes the power >>>>>>>>>>>>>>>>>>> >> of the RO, to be seen as a human rights issue when >>>>>>>>>>>>>>>>>>> the RO is a human. This >>>>>>>>>>>>>>>>>>> >> causes me to ask how to combine better security with >>>>>>>>>>>>>>>>>>> better human rights in >>>>>>>>>>>>>>>>>>> >> GNAP. >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> Who should have the least authority in the GNAP >>>>>>>>>>>>>>>>>>> design? >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> The AS derives authority as a delegate of the RO. If >>>>>>>>>>>>>>>>>>> we ask the RO to >>>>>>>>>>>>>>>>>>> >> partition limited authority across dozens of >>>>>>>>>>>>>>>>>>> different ASs by domain and >>>>>>>>>>>>>>>>>>> >> function, then we are not using technology to empowe= r >>>>>>>>>>>>>>>>>>> the individual. >>>>>>>>>>>>>>>>>>> >> Probably the opposite, as we introduce consent >>>>>>>>>>>>>>>>>>> fatigue and burden normal >>>>>>>>>>>>>>>>>>> >> people to partition their lives into non-overlapping >>>>>>>>>>>>>>>>>>> domains. >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> My experience says we should aim for one AS per >>>>>>>>>>>>>>>>>>> persona because that maps >>>>>>>>>>>>>>>>>>> >> into the way we manage our public and private >>>>>>>>>>>>>>>>>>> identities. POLA would then >>>>>>>>>>>>>>>>>>> >> teach care in keeping ASs and RSs related to work / >>>>>>>>>>>>>>>>>>> public separate from >>>>>>>>>>>>>>>>>>> >> ASs and RSs related to private life so that a policy >>>>>>>>>>>>>>>>>>> vulnerability in our >>>>>>>>>>>>>>>>>>> >> delegation to an AS would have the least likelihood >>>>>>>>>>>>>>>>>>> of harm. >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > Thinking about how least authority/least privilege >>>>>>>>>>>>>>>>>>> would apply to GNAP >>>>>>>>>>>>>>>>>>> > seems like a useful exercise. I do want to point out >>>>>>>>>>>>>>>>>>> some potential >>>>>>>>>>>>>>>>>>> > pitfalls with one-AS-per-persona that we can also be >>>>>>>>>>>>>>>>>>> aware of. If >>>>>>>>>>>>>>>>>>> > one-AS-per-persona becomes one-persona-per-AS as well= , >>>>>>>>>>>>>>>>>>> then the AS's >>>>>>>>>>>>>>>>>>> > identity in effect also serves as a persona identity >>>>>>>>>>>>>>>>>>> and there are privacy >>>>>>>>>>>>>>>>>>> > considerations to that. If, on the other hand, the >>>>>>>>>>>>>>>>>>> > multiple-personas-per-AS (presumably corresponding to >>>>>>>>>>>>>>>>>>> multiple humans) >>>>>>>>>>>>>>>>>>> > route is taken, we should consider whether that would >>>>>>>>>>>>>>>>>>> lead to various >>>>>>>>>>>>>>>>>>> > (e.g., market) forces driving consolidation to just a >>>>>>>>>>>>>>>>>>> handful of >>>>>>>>>>>>>>>>>>> > super-popular AS services. That topic is a current >>>>>>>>>>>>>>>>>>> matter of concern to >>>>>>>>>>>>>>>>>>> > some IETF participants. >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi Ben, big +1 to this. This is something that we >>>>>>>>>>>>>>>>>>> discussed ages ago in the UMA working group, and it=E2= =80=99s one of the biggest >>>>>>>>>>>>>>>>>>> problems with the personal AS (and personal data store)= model. This kind of >>>>>>>>>>>>>>>>>>> thing makes RS-first trust models really difficult in p= ractice. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve got = software that >>>>>>>>>>>>>>>>>>> wants to access my medical information. It calls an RS = and requests access, >>>>>>>>>>>>>>>>>>> but it hasn=E2=80=99t been granted anything yet. Now I = as the RO have set up the RS >>>>>>>>>>>>>>>>>>> so that it talks to my personal AS, that only I use. In= addition to the RS >>>>>>>>>>>>>>>>>>> having to be able to figure out which medical records a= re being requested >>>>>>>>>>>>>>>>>>> from the context of the unauthenticated request (which = means it needs >>>>>>>>>>>>>>>>>>> identifiers in the URL or something similar for the RS = to be able to tell, >>>>>>>>>>>>>>>>>>> assuming that it protects data for more than one person= ). So this client >>>>>>>>>>>>>>>>>>> software doesn=E2=80=99t know who I am and doesn=E2=80= =99t know my medical record >>>>>>>>>>>>>>>>>>> information, makes a completely unauthorized request to= the RS, and the RS >>>>>>>>>>>>>>>>>>> says =E2=80=9CGo to Justin=E2=80=99s personal AS to get= a token=E2=80=9D. The client can now make a >>>>>>>>>>>>>>>>>>> direct correlation between the data that=E2=80=99s bein= g protected at the RS and >>>>>>>>>>>>>>>>>>> the person running the AS that protects it. Importantly= , this client makes >>>>>>>>>>>>>>>>>>> this call with no prior relationship to the RS and no r= eally auditable way >>>>>>>>>>>>>>>>>>> to track it down after the fact. This is a design featu= re in the good case, >>>>>>>>>>>>>>>>>>> and terrifying in the bad case. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> If the RS instead says =E2=80=9Cwelcome to Medicine Doc= tor RS, >>>>>>>>>>>>>>>>>>> please talk to the Medicine Doctor AS to get access=E2= =80=9D, we haven=E2=80=99t exposed >>>>>>>>>>>>>>>>>>> anything at all. And from the perspective of both the p= atient and the RS, >>>>>>>>>>>>>>>>>>> this is more privacy-preserving, and it=E2=80=99s reall= y the least surprising >>>>>>>>>>>>>>>>>>> option. Once the client gets to the AS, it can start a = negotiation of >>>>>>>>>>>>>>>>>>> figuring out who the RO is for the information being ac= cessed. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On top of this, the usability expectations of people >>>>>>>>>>>>>>>>>>> managing their own AS, or set of AS=E2=80=99s for multi= ple personas to keep things >>>>>>>>>>>>>>>>>>> separate, is a huge burden. Even in the tech community,= I know people who >>>>>>>>>>>>>>>>>>> can=E2=80=99t reliably manage more than one email addre= ss for different purposes. I >>>>>>>>>>>>>>>>>>> wouldn=E2=80=99t expect my partner to do that =E2=80=94= they have trouble enough balancing >>>>>>>>>>>>>>>>>>> all the logins and sessions required for different kids= remote schooling, I >>>>>>>>>>>>>>>>>>> couldn=E2=80=99t imagine them having to understand all = the requirements for >>>>>>>>>>>>>>>>>>> managing multiple authorization servers and associated = policies. I also >>>>>>>>>>>>>>>>>>> don=E2=80=99t expect any person to =E2=80=9Cmanage keys= =E2=80=9D =E2=80=94 I=E2=80=99ve been on the internet for >>>>>>>>>>>>>>>>>>> decades and I can barely keep tabs on my GPG keys, and = only use them when I >>>>>>>>>>>>>>>>>>> am forced to. This is exactly the kind of =E2=80=9Cmark= et pressure=E2=80=9D that I think >>>>>>>>>>>>>>>>>>> Ben mentions above, people will just want to outsource = that to someone >>>>>>>>>>>>>>>>>>> else, and the reality will be a few popular providers. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> In which case, we could end up doing a ton of work to >>>>>>>>>>>>>>>>>>> allow an RS choice only to end up with a world where th= e RS ends up making >>>>>>>>>>>>>>>>>>> a limited choice anyway. We see how that plays out with= OpenID Connect =E2=80=94 >>>>>>>>>>>>>>>>>>> RP=E2=80=99s could allow arbitrary IdPs but they choose= Google because it works and >>>>>>>>>>>>>>>>>>> that=E2=80=99s where the users are. (And that=E2=80=99s= not to say anything of the >>>>>>>>>>>>>>>>>>> proprietary OIDC-like protocols, but that=E2=80=99s ano= ther discussion). >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> For further reading on these topics, I recommend both >>>>>>>>>>>>>>>>>>> =E2=80=9CWhy Johnny Can=E2=80=99t Encrypt=E2=80=9D and = =E2=80=9CWhy CSCW Systems Fail=E2=80=9D. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> So what does this have to do with GNAP? I think we can >>>>>>>>>>>>>>>>>>> be clear-eyed on what kinds of expectations we have for= the participants. >>>>>>>>>>>>>>>>>>> If we expect users (RO=E2=80=99s) to have to set up the= AS-RS relationship, or >>>>>>>>>>>>>>>>>>> expect them to carry their AS, or manage their personal= keys =E2=80=94 I think >>>>>>>>>>>>>>>>>>> we=E2=80=99ve lost the battle for relevance. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> 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 >>>>>>>>> >>>>>>>> --000000000000be927705be5803eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Thanks. The general problem statement is clear.

    The=C2=A0proposed solution a bit less (to me). I understood that f= rom point 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obvious reason to have two types of ASs"= .=C2=A0Do you see an alternative ?

    Regarding the last item, I don't think that naming RQ b= y end-user created the problem. It might just highlight the asymmetry,=C2= =A0which fundamentally exists.=C2=A0

    Fabien

    On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper <agropper@healthurl.com> wrote:
    Recap:
    1 - Justin (I think) introduced the idea of an AS on t= he RS trust boundary side.
    2 - I said the RO should = not have to share policies with the RS.
    3 - Alan inv= ented the concept of AS-RO and AS-RS to separate two kinds of PDPs.=C2=A0

    The thing is that step 2 = is not symmetrical. The RO has a legitimate privacy interest in keeping the= ir policies private and minimizing the leakage of information about request= s that are posed against those policies.=C2=A0

    <= /div>
    The RS, on the other hand, should be publishing its = policies (e.g. what it=E2=80=99s selling or what jurisdiction it=E2=80=99s = in or what tokens or scopes it supports). The RS has no obvious privacy int= erest in GNAP. It=E2=80=99s just an enforcer.

    There is one other privacy interest to consider aroun= d the RS and that is the requesting party (the end-user that is not the RO = :-) might prefer to share attributes with the RS instead of the RO or somet= hing controlled by the RO. This case could be an =E2=80=9Cextension=E2=80= =9D to GNAP and might result in a split AS as a solution. This problem was = introduced when the editors decided to replace RQ with end-user. Obviously,= the RO end-user has no privacy interests relative to itself.

    Adrian




    On Thu, Mar 25, 2= 021 at 3:24 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    I was r= eferring to "By my definition, = this model has two ASs since both are processing requests into tokens"= . If there's no reason to have 2 types of ASs, that's fine then.=C2= =A0
    But I'm a b= it lost in where we stand with the idea.=C2=A0

    Could you recap?=C2=A0
    =

    Fabien=C2=A0

    Le jeu. 25 mars= 2021 =C3=A0 08:16, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:<= br>
    There=E2=80=99s no obvious reason to have two types of ASs. Any AS that i= s executing the policies of the RS can look to GNAP like the RS itself. Why= would GNAP expose that interface to anyone?=C2=A0
    <= br>
    Adrian

    =
    On Thu, Mar 25, 2021 at 3:11 AM Fabie= n Imbault <fabien.imbault@gmail.com> wrote:
    Note : I'= m not sure that's a good idea, but having 2 types of ASs is not that ea= sy to grasp.

    Fabien=C2=A0

    Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault = <fabien.imbault@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">
    The purp= ose of either handling policies locally or delegating them to the RO agent.= =C2=A0

    Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper <= agropper@healthurl.com> a =C3=A9crit=C2=A0:
    What purpose would be = served by GNAP splitting the AS into two components?

    Adrian=C2=A0

    On = Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Isn't the AS-RO a component = of the AS? Same idea as the interact component, it functionnally belongs to= the AS role but could be deployed either as a monolith or as a separate co= mponent?

    Fabien

    Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    =
    Y= es, but I would say it=E2=80=99s not the RO that wants the access token. It= =E2=80=99s the RO that wants the client making the request to get an access= token.=C2=A0

    Adrian

    On Wed, Mar 24, 2021 at 11:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Adrian Gropper <agropper@healthurl.com> wrote:

    = In this design, the AS is the AS-RS and the agent is the AS-RO. By my defin= ition, this model has two ASs since both are processing requests into token= s. The problem with this is complexity and privacy. The RO may not want to = share the request information with the AS-RS.

    More precisely, RO has no choice= but to present the required information to AS-RS if RO wants an access tok= en.=C2=A0 However, RO does not want AS-RS to know the policy by which RO de= legates tokens.=C2=A0 That's why RO uses AS-RO for those delegations.

    --------------
    Alan Karp

    <= /div>

    On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Thank you for creating the issue. My definition of AS is indepen= dent of AS-RO or AS-RS.=C2=A0https://github.com/ietf-wg-gn= ap/gnap-core-protocol/issues/223#issuecomment-806280421 I also agree wi= th Alan's definition based on delegation. An AS-RS would be a delegate = of the RS.=C2=A0

    Based on that, I see = it as obvious=C2=A0that the policy has to be accessible (defined locally?) = in order for it to be run as the code that turns a request into an access t= oken.=C2=A0

    The only other possibility is that the= request is packaged by the AS and sent elsewhere (an agent) for evaluation= against policy and a proto-token returned. In that case the AS is acting a= s a proxy and the PDP is elsewhere. I can imagine that an AS-RS would behav= e this way so that the proto-token could be turned into an access token by = the AS-RS. Isn't this what Justin is proposing? In this design, the AS = is the AS-RS and the agent is the AS-RO. By my definition, this model has t= wo ASs since both are processing requests into tokens. The problem with thi= s is complexity and privacy. The RO may not want to share the request infor= mation with the AS-RS.

    Adrian

    On Wed, Mar 24,= 2021 at 5:21 PM Fabien Imbault <= fabien.imbault@gmail.com> wrote:
    Isn't that what the AS i= s supposed to be, only with the caveat that the policy is defined locally?= =C2=A0

    Fabien=C2=A0

    <= br>
    Le mer.= 24 mars 2021 =C3=A0 20:17, Alan Karp <alanhkarp@gmail.com> a =C3=A9crit=C2=A0:
    AS-RO is= an AS that RO trusts to delegate RO's access tokens according to RO= 9;s policies.=C2=A0=C2=A0

    ------= --------
    Alan Karp


    <= div dir=3D"ltr" class=3D"gmail_attr">On Wed, Mar 24, 2021 at 9:36 AM Fabien= Imbault <fabien.imbau= lt@gmail.com> wrote:
    Hi Alan and Adrian,

    I'v= e created issue AS-RO policy delegation (https://github.com/ietf-wg-gn= ap/gnap-core-protocol/issues/223) to capture your input.=C2=A0
    A first question that arises: can we give a definition to AS-RO?

    Thanks
    Fabien

    On Tue, Mar 23, 2021 at 4:15 = PM Alan Karp <alanhkarp@gma= il.com> wrote:
    <= div dir=3D"ltr" class=3D"gmail_attr">Fabien Imbault <fabien.imbault@gmail.com> wrote:
    <= /div>
    Hi = Alan,=C2=A0

    Yes, but in that flow, the token relationshi= p between AS-RS and AS-RO is only secure if the tokens issued by AS-RS are = cryptographically attenuable in the first place.=C2=A0
    =C2=A0
    Attenuated delegation is a requi= rement, but that doesn't have to be done cryptographically.=C2=A0 Token= exchange works just fine.=C2=A0 SPKI and zcap-ld are examples of the crypt= o approach, and we used token exchange in the system for HP.

    --------------
    Alan Karp


    On Tue, Mar 23, = 2021 at 4:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan,=C2=A0
    Yes, but in that flow, the token relationship between AS-RS and= AS-RO is only secure if the tokens issued by AS-RS are cryptographically a= ttenuable in the first place.=C2=A0

    Fabien

    On= Mon, Mar 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin Richer <jricher@mit.edu> wrote:

    But with all that in = mind, I think the key here is going to be looking at what the inputs to the= AS are, and how those can be defined in an interoperable way for AS=E2=80= =99s that can accept them. I think there=E2=80=99s a lot of room for innova= tion and flexibility here that doesn=E2=80=99t break the trust model or cor= e use cases. If I have an AS-RS set that won=E2=80=99t accept my favorite f= lavor of policy engine inputs, then I can decide not to use that one. But t= his is a very different question than saying the RS itself needs to accept = my own AS =E2=80=94 and we can=E2=80=99t keep conflating these two models.<= /div>

    I agree.=C2=A0 The point of hav= ing an AS-RO is to allow RO to specify a policy for which of RO's acces= s tokens should be delegated under what conditions.=C2=A0 AS-RS should not = need to understand those policies.=C2=A0 The flow would be
      RO contacts AS-RS and gets one or more access tokens.
    • RO delegate= s one or more of those tokens, potentially sub-scoped, to AS-RO.
    • A = different user contacts AS-RO to get a potentially sub-scoped access token = from AS-RO.
    • That user presents the access token delegated by AS-RO = when invoking the resource.
    AS-RS only needs to ve= rify that the delegation chain is legitimate, e.g., no increase in scope, a= nd that it grants permission for the request being made.=C2=A0 AS-RS does n= ot need to understand the policy behind granting the delegation by AS-RO.

    --------------
    Alan Karp

    <= br>
    On Mon,= Mar 22, 2021 at 11:40 AM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    I think this sho= ws the problem with the terminology as it=E2=80=99s been applied in this co= nversation, which I=E2=80=99ve tried to shine light on before. What you and= others are calling the =E2=80=9CRS=E2=80=9D is really the =E2=80=9CAS and = RS working together=E2=80=9D =E2=80=94 everything to the right of the line.= When Denis had brought up =E2=80=9Celiminating the AS=E2=80=9D in another = thread, what he=E2=80=99d really done is labeled everything to the right of= the line as the =E2=80=9CRS=E2=80=9D. Of course, the irony here is that ev= erything to the right of the line used all be called the =E2=80=9CAS=E2=80= =9D or simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say belo= w, I don=E2=80=99t want the client to have visibility on what happens on th= at side.=C2=A0

    Note well: The Google+ logo labeled= =E2=80=9CIdP=E2=80=9D in the diagram is not the AS, as far as GNAP is conc= erned. It does not issue an access token that the RS will accept. The eleme= nts to the left of the line could be a lot of things, but they are NOT the = AS =E2=80=94 by definition. The client lives over on the left, but so do an= y external inputs to the AS. These could be policy inputs on behalf of the = RO, they could be presentation artifacts, they could be federated logins, t= hey could be the output of policy decisions. How the AS comes to trust thos= e things is up to the AS=E2=80=99s implementation. It=E2=80=99s something w= e can talk about, but ultimately GNAP won=E2=80=99t be in any position to d= ictate because in practice some AS=E2=80=99s are simply going to internaliz= e all policies and we will never successfully force those open.=C2=A0
    =

    But with all that in mind, I think the key here is goin= g to be looking at what the inputs to the AS are, and how those can be defi= ned in an interoperable way for AS=E2=80=99s that can accept them. I think = there=E2=80=99s a lot of room for innovation and flexibility here that does= n=E2=80=99t break the trust model or core use cases. If I have an AS-RS set= that won=E2=80=99t accept my favorite flavor of policy engine inputs, then= I can decide not to use that one. But this is a very different question th= an saying the RS itself needs to accept my own AS =E2=80=94 and we can=E2= =80=99t keep conflating these two models.

    So to me= , GNAP can support a Zero Trust Architecture by LEVERAGING the AS, not by s= ubsuming or eliminating it. It is in fact the AS, not the client and not th= e RS, that will request and consume the results of a privacy-preserving zer= o-trust policy query thing. Anything that happens downstream from that is o= f little concern to the zero-trust components because, as you point out, it= =E2=80=99s on the =E2=80=9Cother side=E2=80=9D of the line.=C2=A0

    I think we got this basic component model pretty right in O= Auth: the AS and RS and client working together. Where OAuth misses the mar= k is the assumption that the user has to log in to the AS through a webpage= and interact directly, thereby proving they=E2=80=99re the RO. It=E2=80=99= s this latter space where I think we can both push innovation and also addr= ess the important and compelling use cases like the ones you=E2=80=99re bri= nging.

    =C2=A0=E2=80=94 Justin

    On Mar 22, 2021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> = wrote:

    I'm sorry, Justin. As a Resource = Owner, I look at the RS trust boundary (the dotted line in the diagram) as = being the RS. I don't expect any visibility into what's going on on= the=C2=A0right.=C2=A0

    My problem with the framing you p= ropose is that requests are going to the RS (or the AS-RS) and I don't = want to share my policies with the AS-RS. I want to keep the RS and AS-RS a= s ignorant as possible.

    Adrian

    On Mon, Mar 22= , 2021 at 1:48 PM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    What you=E2=80=99re discu= ssing below, in terms of logging in to a site, is not approaching the RS. Y= ou are in fact approaching the client, and identifying both the AS and RS t= o the client. The client is a client of your identity in this model,= and the RS is part of the identity provider. It=E2=80=99s really important= that we don=E2=80=99t conflate the RS and client in this way as it leads t= o a lot of confusion downstream and a lot of broken trust boundaries.
    =

    With that model in mind, approaching the =E2=80=9CRS&qu= ot; and providing it your identity is really just a case of the =E2=80=9Cfe= derated login to AS=E2=80=9D pattern that we discussed on the WG call. The = user here approaches an RS, which has its own AS. To share things from this= RS, the RO has to authenticate to the RS=E2=80=99s AS. This particular AS = allows the RO to do so using an external identity =E2=80=94 in which case, = the AS is now a =E2=80=9Cclient=E2=80=9D of a separate, disconnected (but l= ayered) delegation. The ultimate client that eventually calls the RS down t= he way may or may not know about these layers.=C2=A0

    <PastedGraphic-1.png>
    This same AS, which is cl= osely tied to the RS and trusted by the RS, might also take in FIDO credent= ials, or DIDs, or any number of other proof mechanisms. The output of this = is an access token the RS trusts, but the input is up to the AS. The RS is = not what you=E2=80=99re logging in to.

    =C2=A0=E2= =80=94 Justin

    On Mar 22, 2021, a= t 1:28 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I t= oo am in favor of avoiding consolidation and correlation. Right now, when I= approach a service provider (RS) for the first time, I'm offered the o= pportunity to identify my persona as: email, sign-in with Google, Facebook,= or Apple. I know there are people who try to create one-off email addresse= s but that is mostly a waste of time.=C2=A0

    So, along co= me FIDO2 and DID wallets to the rescue. Now, in theory, I have a way to sta= rt out my RS relationship pseudonymously.=C2=A0

    Wh= en I want my resource to be discovered or shared I will post that RS URL in= cluding my pseudonym. If I then want to introduce a mediator=C2=A0in front = of my AS or messaging service=C2=A0endpoint, I have that option. If I want = to keep requests away from the mediator, I would publish an encryption key = along with my pseudonym.

    - Adrian



    On Mon, Mar 22, 2021 at 9:55 AM Justin Richer <jricher@mit.edu> wrote:
    =
    On Mar 21, 2021, at 1:18 = PM, Benjamin Kaduk <kaduk@mit.edu= > wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhk= arp@gmail.com> shared a talk about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-= gnap/gnap-core-protocol/issues/145#issuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --
    TXAuth 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
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.= ietf.org/mailman/listinfo/txauth
    --000000000000be927705be5803eb-- From nobody Thu Mar 25 01:19:33 2021 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 C2BDE3A157E for ; Thu, 25 Mar 2021 01:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.72 X-Spam-Level: X-Spam-Status: No, score=-0.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 FR46dVxoPh1o for ; Thu, 25 Mar 2021 01:19:27 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 608A53A157A for ; Thu, 25 Mar 2021 01:19:24 -0700 (PDT) Received: from [192.168.1.11] ([90.79.53.231]) by mwinf5d29 with ME id kYKL2400X4zJUWJ03YKMUH; Thu, 25 Mar 2021 09:19:22 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Thu, 25 Mar 2021 09:19:22 +0100 X-ME-IP: 90.79.53.231 To: txauth@ietf.org References: From: Denis Message-ID: <650a3e87-701f-f5b0-6b9f-5c591169fea4@free.fr> Date: Thu, 25 Mar 2021 09:19:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6AB2240A9C01BEB7B36CFD0C" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 08:19:33 -0000 This is a multi-part message in MIME format. --------------6AB2240A9C01BEB7B36CFD0C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I am full  lost in where we stand with all these ideas which look like a Brownian motion. Which entity is trusting which other entity and for which purpose(s) ? Denis > Thanks. The general problem statement is clear. > > The proposed solution a bit less (to me). I understood that from point > 2, Alan involves 2 ASs. You said : "There’s no obvious reason to have > two types of ASs". Do you see an alternative ? > > Regarding the last item, I don't think that naming RQ by end-user > created the problem. It might just highlight the asymmetry, which > fundamentally exists. > > Fabien > > > On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper > wrote: > > Recap: > 1 - Justin (I think) introduced the idea of an AS on the RS trust > boundary side. > 2 - I said the RO should not have to share policies with the RS. > 3 - Alan invented the concept of AS-RO and AS-RS to separate two > kinds of PDPs. > > The thing is that step 2 is not symmetrical. The RO has a > legitimate privacy interest in keeping their policies private and > minimizing the leakage of information about requests that are > posed against those policies. > > The RS, on the other hand, should be publishing its policies (e.g. > what it’s selling or what jurisdiction it’s in or what tokens or > scopes it supports). The RS has no obvious privacy interest in > GNAP. It’s just an enforcer. > > There is one other privacy interest to consider around the RS and > that is the requesting party (the end-user that is not the RO :-) > might prefer to share attributes with the RS instead of the RO or > something controlled by the RO. This case could be an “extension” > to GNAP and might result in a split AS as a solution. This problem > was introduced when the editors decided to replace RQ with > end-user. Obviously, the RO end-user has no privacy interests > relative to itself. > > Adrian > > > > > On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault > > wrote: > > I was referring to "By my definition, this model has two ASs > since both are processing requests into tokens". If there's no > reason to have 2 types of ASs, that's fine then. > But I'm a bit lost in where we stand with the idea. > > Could you recap? > > Fabien > > Le jeu. 25 mars 2021 à 08:16, Adrian Gropper > > a écrit : > > There’s no obvious reason to have two types of ASs. Any AS > that is executing the policies of the RS can look to GNAP > like the RS itself. Why would GNAP expose that interface > to anyone? > > Adrian > > On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault > > wrote: > > Note : I'm not sure that's a good idea, but having 2 > types of ASs is not that easy to grasp. > > Fabien > > Le jeu. 25 mars 2021 à 08:07, Fabien Imbault > > a écrit : > > The purpose of either handling policies locally or > delegating them to the RO agent. > > Le jeu. 25 mars 2021 à 08:04, Adrian Gropper > > a écrit : > > What purpose would be served by GNAP splitting > the AS into two components? > > Adrian > > On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault > > wrote: > > Isn't the AS-RO a component of the AS? > Same idea as the interact component, it > functionnally belongs to the AS role but > could be deployed either as a monolith or > as a separate component? > > Fabien > > Le jeu. 25 mars 2021 à 04:26, Adrian > Gropper > a écrit : > > Yes, but I would say it’s not the RO > that wants the access token. It’s the > RO that wants the client making the > request to get an access token. > > Adrian > > On Wed, Mar 24, 2021 at 11:22 PM Alan > Karp > wrote: > > Adrian Gropper > > > wrote: > > > In this design, the AS is the > AS-RS and the agent is the > AS-RO. By my definition, this > model has two ASs since both > are processing requests into > tokens. The problem with this > is complexity and privacy. The > RO may not want to share the > request information with the > AS-RS. > > > More precisely, RO has no choice > but to present the required > information to AS-RS if RO wants > an access token. However, RO does > not want AS-RS to know the policy > by which RO delegates tokens. > That's why RO uses AS-RO for those > delegations. > > -------------- > Alan Karp > > > On Wed, Mar 24, 2021 at 7:41 PM > Adrian Gropper > > > wrote: > > Thank you for creating the > issue. My definition of AS is > independent of AS-RO or AS-RS. > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomment-806280421 > > I also agree with Alan's > definition based on > delegation. An AS-RS would be > a delegate of the RS. > > Based on that, I see it as > obvious that the policy has to > be accessible (defined > locally?) in order for it to > be run as the code that turns > a request into an access token. > > The only other possibility is > that the request is packaged > by the AS and sent elsewhere > (an agent) for evaluation > against policy and a > proto-token returned. In that > case the AS is acting as a > proxy and the PDP is > elsewhere. I can imagine that > an AS-RS would behave this way > so that the proto-token could > be turned into an access token > by the AS-RS. Isn't this what > Justin is proposing? In this > design, the AS is the AS-RS > and the agent is the AS-RO. By > my definition, this model has > two ASs since both are > processing requests into > tokens. The problem with this > is complexity and privacy. The > RO may not want to share the > request information with the > AS-RS. > > Adrian > > On Wed, Mar 24, 2021 at 5:21 > PM Fabien Imbault > > > wrote: > > Isn't that what the AS is > supposed to be, only with > the caveat that the policy > is defined locally? > > Fabien > > > Le mer. 24 mars 2021 à > 20:17, Alan Karp > > > a écrit : > > AS-RO is an AS that RO > trusts to delegate > RO's access tokens > according to RO's > policies. > > -------------- > Alan Karp > > > On Wed, Mar 24, 2021 > at 9:36 AM Fabien > Imbault > > > wrote: > > Hi Alan and Adrian, > > I've created issue > AS-RO policy > delegation > (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223 > ) > to capture your > input. > A first question > that arises: can > we give a > definition to AS-RO? > > Thanks > Fabien > > On Tue, Mar 23, > 2021 at 4:15 PM > Alan Karp > > > wrote: > > Fabien Imbault > > > wrote: > > Hi Alan, > > Yes, but > in that > flow, the > token > relationship > between > AS-RS and > AS-RO is > only > secure if > the tokens > issued by > AS-RS are > cryptographically > attenuable > in the > first place. > > Attenuated > delegation is > a requirement, > but that > doesn't have > to be done > cryptographically. > Token exchange > works just > fine.  SPKI > and zcap-ld > are examples > of the crypto > approach, and > we used token > exchange in > the system for HP. > > -------------- > Alan Karp > > > On Tue, Mar > 23, 2021 at > 4:12 AM Fabien > Imbault > > > wrote: > > Hi Alan, > > Yes, but > in that > flow, the > token > relationship > between > AS-RS and > AS-RO is > only > secure if > the tokens > issued by > AS-RS are > cryptographically > attenuable > in the > first place. > > Fabien > > On Mon, > Mar 22, > 2021 at > 9:26 PM > Alan Karp > > > wrote: > > Justin > Richer > > > wrote: > > > But > with > all > that > in > mind, > I > think > the > key > here > is > going > to > be > looking > at > what > the > inputs > to > the > AS > are, > and > how > those > can > be > defined > in > an > interoperable > way > for > AS’s > that > can > accept > them. > I > think > there’s > a > lot > of > room > for > innovation > and > flexibility > here > that > doesn’t > break > the > trust > model > or > core > use > cases. > If > I > have > an > AS-RS > set > that > won’t > accept > my > favorite > flavor > of > policy > engine > inputs, > then > I > can > decide > not > to > use > that > one. > But > this > is > a > very > different > question > than > saying > the > RS > itself > needs > to > accept > my > own > AS > — > and > we > can’t > keep > conflating > these > two > models. > > I > agree. > The > point > of > having > an > AS-RO > is to > allow > RO to > specify > a > policy > for > which > of > RO's > access > tokens > should > be > delegated > under > what > conditions. > AS-RS > should > not > need > to > understand > those > policies.  > The > flow > would be > > * RO > contacts > AS-RS > and > gets > one > or > more > access > tokens. > * RO > delegates > one > or > more > of > those > tokens, > potentially > sub-scoped, > to > AS-RO. > * A > different > user > contacts > AS-RO > to > get > a > potentially > sub-scoped > access > token > from > AS-RO. > * That > user > presents > the > access > token > delegated > by > AS-RO > when > invoking > the > resource. > > AS-RS > only > needs > to > verify > that > the > delegation > chain > is > legitimate, > e.g., > no > increase > in > scope, > and > that > it > grants > permission > for > the > request > being > made. > AS-RS > does > not > need > to > understand > the > policy > behind > granting > the > delegation > by AS-RO. > > -------------- > Alan Karp > > > On > Mon, > Mar > 22, > 2021 > at > 11:40 > AM > Justin > Richer > > > wrote: > > Adrian, > > > I > think > this > shows > the > problem > with > the > terminology > as > it’s > been > applied > in > this > conversation, > which > I’ve > tried > to > shine > light > on > before. > What > you > and > others > are > calling > the > “RS” > is > really > the > “AS > and > RS > working > together” > — > everything > to > the > right > of > the > line. > When > Denis > had > brought > up > “eliminating > the > AS” > in > another > thread, > what > he’d > really > done > is > labeled > everything > to > the > right > of > the > line > as > the > “RS”. > Of > course, > the > irony > here > is > that > everything > to > the > right > of > the > line > used > all > be > called > the > “AS” > or > simply > “server” > in > the > OAuth > 1 > days. > As > you > say > below, > I > don’t > want > the > client > to > have > visibility > on > what > happens > on > that > side. > > Note > well: > The > Google+ > logo > labeled > “IdP” > in > the > diagram > is > not > the > AS, > as > far > as > GNAP > is > concerned. > It > does > not > issue > an > access > token > that > the > RS > will > accept. > The > elements > to > the > left > of > the > line > could > be > a > lot > of > things, > but > they > are > NOT > the > AS > — > by > definition. > The > client > lives > over > on > the > left, > but > so > do > any > external > inputs > to > the > AS. > These > could > be > policy > inputs > on > behalf > of > the > RO, > they > could > be > presentation > artifacts, > they > could > be > federated > logins, > they > could > be > the > output > of > policy > decisions. > How > the > AS > comes > to > trust > those > things > is > up > to > the > AS’s > implementation. > It’s > something > we > can > talk > about, > but > ultimately > GNAP > won’t > be > in > any > position > to > dictate > because > in > practice > some > AS’s > are > simply > going > to > internalize > all > policies > and > we > will > never > successfully > force > those > open. > > But > with > all > that > in > mind, > I > think > the > key > here > is > going > to > be > looking > at > what > the > inputs > to > the > AS > are, > and > how > those > can > be > defined > in > an > interoperable > way > for > AS’s > that > can > accept > them. > I > think > there’s > a > lot > of > room > for > innovation > and > flexibility > here > that > doesn’t > break > the > trust > model > or > core > use > cases. > If > I > have > an > AS-RS > set > that > won’t > accept > my > favorite > flavor > of > policy > engine > inputs, > then > I > can > decide > not > to > use > that > one. > But > this > is > a > very > different > question > than > saying > the > RS > itself > needs > to > accept > my > own > AS > — > and > we > can’t > keep > conflating > these > two > models. > > So > to > me, > GNAP > can > support > a > Zero > Trust > Architecture > by > LEVERAGING > the > AS, > not > by > subsuming > or > eliminating > it. > It > is > in > fact > the > AS, > not > the > client > and > not > the > RS, > that > will > request > and > consume > the > results > of > a > privacy-preserving > zero-trust > policy > query > thing. > Anything > that > happens > downstream > from > that > is > of > little > concern > to > the > zero-trust > components > because, > as > you > point > out, > it’s > on > the > “other > side” > of > the > line. > > I > think > we > got > this > basic > component > model > pretty > right > in > OAuth: > the > AS > and > RS > and > client > working > together. > Where > OAuth > misses > the > mark > is > the > assumption > that > the > user > has > to > log > in > to > the > AS > through > a > webpage > and > interact > directly, > thereby > proving > they’re > the > RO. > It’s > this > latter > space > where > I > think > we > can > both > push > innovation > and > also > address > the > important > and > compelling > use > cases > like > the > ones > you’re > bringing. > >  — > Justin > >> On >> Mar >> 22, >> 2021, >> at >> 2:14 >> PM, >> Adrian >> Gropper >> > > >> wrote: >> >> I'm >> sorry, >> Justin. >> As >> a >> Resource >> Owner, >> I >> look >> at >> the >> RS >> trust >> boundary >> (the >> dotted >> line >> in >> the >> diagram) >> as >> being >> the >> RS. >> I >> don't >> expect >> any >> visibility >> into >> what's >> going >> on >> on >> the right. >> >> >> My >> problem >> with >> the >> framing >> you >> propose >> is >> that >> requests >> are >> going >> to >> the >> RS >> (or >> the >> AS-RS) >> and >> I >> don't >> want >> to >> share >> my >> policies >> with >> the >> AS-RS. >> I >> want >> to >> keep >> the >> RS >> and >> AS-RS >> as >> ignorant >> as >> possible. >> >> Adrian >> >> On >> Mon, >> Mar >> 22, >> 2021 >> at >> 1:48 >> PM >> Justin >> Richer >> > > >> wrote: >> >> Adrian, >> >> >> What >> you’re >> discussing >> below, >> in >> terms >> of >> logging >> in >> to >> a >> site, >> is >> not >> approaching >> the >> RS. >> You >> are >> in >> fact >> approaching >> the >> client, >> and >> identifying >> both >> the >> AS >> and >> RS >> to >> the >> client. >> The >> client >> is >> a >> client >> /of >> your >> identity/ >> in >> this >> model, >> and >> the >> RS >> is >> part >> of >> the >> identity >> provider. >> It’s >> really >> important >> that >> we >> don’t >> conflate >> the >> RS >> and >> client >> in >> this >> way >> as >> it >> leads >> to >> a >> lot >> of >> confusion >> downstream >> and >> a >> lot >> of >> broken >> trust >> boundaries. >> >> With >> that >> model >> in >> mind, >> approaching >> the >> “RS" >> and >> providing >> it >> your >> identity >> is >> really >> just >> a >> case >> of >> the >> “federated >> login >> to >> AS” >> pattern >> that >> we >> discussed >> on >> the >> WG >> call. >> The >> user >> here >> approaches >> an >> RS, >> which >> has >> its >> own >> AS. >> To >> share >> things >> from >> this >> RS, >> the >> RO >> has >> to >> authenticate >> to >> the >> RS’s >> AS. >> This >> particular >> AS >> allows >> the >> RO >> to >> do >> so >> using >> an >> external >> identity >> — >> in >> which >> case, >> the >> AS >> is >> now >> a >> “client” >> of >> a >> separate, >> disconnected >> (but >> layered) >> delegation. >> The >> ultimate >> client >> that >> eventually >> calls >> the >> RS >> down >> the >> way >> may >> or >> may >> not >> know >> about >> these >> layers. >> >> >> >> This >> same >> AS, >> which >> is >> closely >> tied >> to >> the >> RS >> and >> trusted >> by >> the >> RS, >> might >> also >> take >> in >> FIDO >> credentials, >> or >> DIDs, >> or >> any >> number >> of >> other >> proof >> mechanisms. >> The >> output >> of >> this >> is >> an >> access >> token >> the >> RS >> trusts, >> but >> the >> input >> is >> up >> to >> the >> AS. >> The >> RS >> is >> not >> what >> you’re >> logging >> in >> to. >> >>  — >> Justin >> >>> On >>> Mar >>> 22, >>> 2021, >>> at >>> 1:28 >>> PM, >>> Adrian >>> Gropper >>> >> > >>> wrote: >>> >>> I >>> too >>> am >>> in >>> favor >>> of >>> avoiding >>> consolidation >>> and >>> correlation. >>> Right >>> now, >>> when >>> I >>> approach >>> a >>> service >>> provider >>> (RS) >>> for >>> the >>> first >>> time, >>> I'm >>> offered >>> the >>> opportunity >>> to >>> identify >>> my >>> persona >>> as: >>> email, >>> sign-in >>> with >>> Google, >>> Facebook, >>> or >>> Apple. >>> I >>> know >>> there >>> are >>> people >>> who >>> try >>> to >>> create >>> one-off >>> email >>> addresses >>> but >>> that >>> is >>> mostly >>> a >>> waste >>> of >>> time. >>> >>> >>> So, >>> along >>> come >>> FIDO2 >>> and >>> DID >>> wallets >>> to >>> the >>> rescue. >>> Now, >>> in >>> theory, >>> I >>> have >>> a >>> way >>> to >>> start >>> out >>> my >>> RS >>> relationship >>> pseudonymously. >>> >>> >>> When >>> I >>> want >>> my >>> resource >>> to >>> be >>> discovered >>> or >>> shared >>> I >>> will >>> post >>> that >>> RS >>> URL >>> including >>> my >>> pseudonym. >>> If >>> I >>> then >>> want >>> to >>> introduce >>> a >>> mediator in >>> front >>> of >>> my >>> AS >>> or >>> messaging >>> service endpoint, >>> I >>> have >>> that >>> option. >>> If >>> I >>> want >>> to >>> keep >>> requests >>> away >>> from >>> the >>> mediator, >>> I >>> would >>> publish >>> an >>> encryption >>> key >>> along >>> with >>> my >>> pseudonym. >>> >>> - >>> Adrian >>> >>> >>> >>> On >>> Mon, >>> Mar >>> 22, >>> 2021 >>> at >>> 9:55 >>> AM >>> Justin >>> Richer >>> >> > >>> wrote: >>> >>> On >>> Mar >>> 21, >>> 2021, >>> at >>> 1:18 >>> PM, >>> Benjamin >>> Kaduk >>> >> > >>> wrote: >>> > >>> >>> > >>> On >>> Sat, >>> Mar >>> 20, >>> 2021 >>> at >>> 01:07:42AM >>> -0400, >>> Adrian >>> Gropper >>> wrote: >>> >> >>> @Alan >>> Karp >>> >> > >>> shared >>> a >>> talk >>> about >>> the >>> Principle >>> Of >>> Least >>> >> >>> Authority >>> (POLA) >>> in >>> a >>> recent >>> comment >>> >> >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-803099693 >>> >>> >> >>> I >>> recommend >>> it. >>> >> >>> >>> >> >>> We >>> might >>> expect >>> a >>> protocol >>> with >>> authorization >>> in >>> the >>> title >>> to >>> use >>> authority >>> >> >>> as >>> a >>> core >>> principle. >>> I >>> advocate >>> for >>> a >>> GNAP >>> design >>> that >>> maximizes >>> the >>> power >>> >> >>> of >>> the >>> RO, >>> to >>> be >>> seen >>> as >>> a >>> human >>> rights >>> issue >>> when >>> the >>> RO >>> is >>> a >>> human. >>> This >>> >> >>> causes >>> me >>> to >>> ask >>> how >>> to >>> combine >>> better >>> security >>> with >>> better >>> human >>> rights >>> in >>> >> >>> GNAP. >>> >> >>> >>> >> >>> Who >>> should >>> have >>> the >>> least >>> authority >>> in >>> the >>> GNAP >>> design? >>> >> >>> >>> >> >>> The >>> AS >>> derives >>> authority >>> as >>> a >>> delegate >>> of >>> the >>> RO. >>> If >>> we >>> ask >>> the >>> RO >>> to >>> >> >>> partition >>> limited >>> authority >>> across >>> dozens >>> of >>> different >>> ASs >>> by >>> domain >>> and >>> >> >>> function, >>> then >>> we >>> are >>> not >>> using >>> technology >>> to >>> empower >>> the >>> individual. >>> >> >>> Probably >>> the >>> opposite, >>> as >>> we >>> introduce >>> consent >>> fatigue >>> and >>> burden >>> normal >>> >> >>> people >>> to >>> partition >>> their >>> lives >>> into >>> non-overlapping >>> domains. >>> >> >>> >>> >> >>> My >>> experience >>> says >>> we >>> should >>> aim >>> for >>> one >>> AS >>> per >>> persona >>> because >>> that >>> maps >>> >> >>> into >>> the >>> way >>> we >>> manage >>> our >>> public >>> and >>> private >>> identities. >>> POLA >>> would >>> then >>> >> >>> teach >>> care >>> in >>> keeping >>> ASs >>> and >>> RSs >>> related >>> to >>> work >>> / >>> public >>> separate >>> from >>> >> >>> ASs >>> and >>> RSs >>> related >>> to >>> private >>> life >>> so >>> that >>> a >>> policy >>> vulnerability >>> in >>> our >>> >> >>> delegation >>> to >>> an >>> AS >>> would >>> have >>> the >>> least >>> likelihood >>> of >>> harm. >>> > >>> >>> > >>> Thinking >>> about >>> how >>> least >>> authority/least >>> privilege >>> would >>> apply >>> to >>> GNAP >>> > >>> seems >>> like >>> a >>> useful >>> exercise.  >>> I >>> do >>> want >>> to >>> point >>> out >>> some >>> potential >>> > >>> pitfalls >>> with >>> one-AS-per-persona >>> that >>> we >>> can >>> also >>> be >>> aware >>> of.  >>> If >>> > >>> one-AS-per-persona >>> becomes >>> one-persona-per-AS >>> as >>> well, >>> then >>> the >>> AS's >>> > >>> identity >>> in >>> effect >>> also >>> serves >>> as >>> a >>> persona >>> identity >>> and >>> there >>> are >>> privacy >>> > >>> considerations >>> to >>> that.  >>> If, >>> on >>> the >>> other >>> hand, >>> the >>> > >>> multiple-personas-per-AS >>> (presumably >>> corresponding >>> to >>> multiple >>> humans) >>> > >>> route >>> is >>> taken, >>> we >>> should >>> consider >>> whether >>> that >>> would >>> lead >>> to >>> various >>> > >>> (e.g., >>> market) >>> forces >>> driving >>> consolidation >>> to >>> just >>> a >>> handful >>> of >>> > >>> super-popular >>> AS >>> services. >>> That >>> topic >>> is >>> a >>> current >>> matter >>> of >>> concern >>> to >>> > >>> some >>> IETF >>> participants. >>> > >>> >>> >>> Hi >>> Ben, >>> big >>> +1 >>> to >>> this. >>> This >>> is >>> something >>> that >>> we >>> discussed >>> ages >>> ago >>> in >>> the >>> UMA >>> working >>> group, >>> and >>> it’s >>> one >>> of >>> the >>> biggest >>> problems >>> with >>> the >>> personal >>> AS >>> (and >>> personal >>> data >>> store) >>> model. >>> This >>> kind >>> of >>> thing >>> makes >>> RS-first >>> trust >>> models >>> really >>> difficult >>> in >>> practice. >>> >>> As >>> a >>> strawman, >>> let’s >>> say >>> that >>> I’ve >>> got >>> software >>> that >>> wants >>> to >>> access >>> my >>> medical >>> information. >>> It >>> calls >>> an >>> RS >>> and >>> requests >>> access, >>> but >>> it >>> hasn’t >>> been >>> granted >>> anything >>> yet. >>> Now >>> I >>> as >>> the >>> RO >>> have >>> set >>> up >>> the >>> RS >>> so >>> that >>> it >>> talks >>> to >>> my >>> personal >>> AS, >>> that >>> only >>> I >>> use. >>> In >>> addition >>> to >>> the >>> RS >>> having >>> to >>> be >>> able >>> to >>> figure >>> out >>> which >>> medical >>> records >>> are >>> being >>> requested >>> from >>> the >>> context >>> of >>> the >>> unauthenticated >>> request >>> (which >>> means >>> it >>> needs >>> identifiers >>> in >>> the >>> URL >>> or >>> something >>> similar >>> for >>> the >>> RS >>> to >>> be >>> able >>> to >>> tell, >>> assuming >>> that >>> it >>> protects >>> data >>> for >>> more >>> than >>> one >>> person). >>> So >>> this >>> client >>> software >>> doesn’t >>> know >>> who >>> I >>> am >>> and >>> doesn’t >>> know >>> my >>> medical >>> record >>> information, >>> makes >>> a >>> completely >>> unauthorized >>> request >>> to >>> the >>> RS, >>> and >>> the >>> RS >>> says >>> “Go >>> to >>> Justin’s >>> personal >>> AS >>> to >>> get >>> a >>> token”. >>> The >>> client >>> can >>> now >>> make >>> a >>> direct >>> correlation >>> between >>> the >>> data >>> that’s >>> being >>> protected >>> at >>> the >>> RS >>> and >>> the >>> person >>> running >>> the >>> AS >>> that >>> protects >>> it. >>> Importantly, >>> this >>> client >>> makes >>> this >>> call >>> with >>> no >>> prior >>> relationship >>> to >>> the >>> RS >>> and >>> no >>> really >>> auditable >>> way >>> to >>> track >>> it >>> down >>> after >>> the >>> fact. >>> This >>> is >>> a >>> design >>> feature >>> in >>> the >>> good >>> case, >>> and >>> terrifying >>> in >>> the >>> bad >>> case. >>> >>> If >>> the >>> RS >>> instead >>> says >>> “welcome >>> to >>> Medicine >>> Doctor >>> RS, >>> please >>> talk >>> to >>> the >>> Medicine >>> Doctor >>> AS >>> to >>> get >>> access”, >>> we >>> haven’t >>> exposed >>> anything >>> at >>> all. >>> And >>> from >>> the >>> perspective >>> of >>> both >>> the >>> patient >>> and >>> the >>> RS, >>> this >>> is >>> more >>> privacy-preserving, >>> and >>> it’s >>> really >>> the >>> least >>> surprising >>> option. >>> Once >>> the >>> client >>> gets >>> to >>> the >>> AS, >>> it >>> can >>> start >>> a >>> negotiation >>> of >>> figuring >>> out >>> who >>> the >>> RO >>> is >>> for >>> the >>> information >>> being >>> accessed. >>> >>> On >>> top >>> of >>> this, >>> the >>> usability >>> expectations >>> of >>> people >>> managing >>> their >>> own >>> AS, >>> or >>> set >>> of >>> AS’s >>> for >>> multiple >>> personas >>> to >>> keep >>> things >>> separate, >>> is >>> a >>> huge >>> burden. >>> Even >>> in >>> the >>> tech >>> community, >>> I >>> know >>> people >>> who >>> can’t >>> reliably >>> manage >>> more >>> than >>> one >>> email >>> address >>> for >>> different >>> purposes. >>> I >>> wouldn’t >>> expect >>> my >>> partner >>> to >>> do >>> that >>> — >>> they >>> have >>> trouble >>> enough >>> balancing >>> all >>> the >>> logins >>> and >>> sessions >>> required >>> for >>> different >>> kids >>> remote >>> schooling, >>> I >>> couldn’t >>> imagine >>> them >>> having >>> to >>> understand >>> all >>> the >>> requirements >>> for >>> managing >>> multiple >>> authorization >>> servers >>> and >>> associated >>> policies. >>> I >>> also >>> don’t >>> expect >>> any >>> person >>> to >>> “manage >>> keys” >>> — >>> I’ve >>> been >>> on >>> the >>> internet >>> for >>> decades >>> and >>> I >>> can >>> barely >>> keep >>> tabs >>> on >>> my >>> GPG >>> keys, >>> and >>> only >>> use >>> them >>> when >>> I >>> am >>> forced >>> to. >>> This >>> is >>> exactly >>> the >>> kind >>> of >>> “market >>> pressure” >>> that >>> I >>> think >>> Ben >>> mentions >>> above, >>> people >>> will >>> just >>> want >>> to >>> outsource >>> that >>> to >>> someone >>> else, >>> and >>> the >>> reality >>> will >>> be >>> a >>> few >>> popular >>> providers. >>> >>> In >>> which >>> case, >>> we >>> could >>> end >>> up >>> doing >>> a >>> ton >>> of >>> work >>> to >>> allow >>> an >>> RS >>> choice >>> only >>> to >>> end >>> up >>> with >>> a >>> world >>> where >>> the >>> RS >>> ends >>> up >>> making >>> a >>> limited >>> choice >>> anyway. >>> We >>> see >>> how >>> that >>> plays >>> out >>> with >>> OpenID >>> Connect >>> — >>> RP’s >>> could >>> allow >>> arbitrary >>> IdPs >>> but >>> they >>> choose >>> Google >>> because >>> it >>> works >>> and >>> that’s >>> where >>> the >>> users >>> are. >>> (And >>> that’s >>> not >>> to >>> say >>> anything >>> of >>> the >>> proprietary >>> OIDC-like >>> protocols, >>> but >>> that’s >>> another >>> discussion). >>> >>> For >>> further >>> reading >>> on >>> these >>> topics, >>> I >>> recommend >>> both >>> “Why >>> Johnny >>> Can’t >>> Encrypt” >>> and >>> “Why >>> CSCW >>> Systems >>> Fail”. >>> >>> So >>> what >>> does >>> this >>> have >>> to >>> do >>> with >>> GNAP? >>> I >>> think >>> we >>> can >>> be >>> clear-eyed >>> on >>> what >>> kinds >>> of >>> expectations >>> we >>> have >>> for >>> the >>> participants. >>> If >>> we >>> expect >>> users >>> (RO’s) >>> to >>> have >>> to >>> set >>> up >>> the >>> AS-RS >>> relationship, >>> or >>> expect >>> them >>> to >>> carry >>> their >>> AS, >>> or >>> manage >>> their >>> personal >>> keys >>> — >>> I >>> think >>> we’ve >>> lost >>> the >>> battle >>> for >>> relevance. >>> >>>  — >>> Justin >>> >> > > -- > 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 > > > --------------6AB2240A9C01BEB7B36CFD0C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

    I am full  lost in where we stand with all these ideas which look like a Brownian motion.

    Which entity is trusting which other entity and for which purpose(s) ?

    Denis


    Thanks. The general problem statement is clear.

    The proposed solution a bit less (to me). I understood that from point 2, Alan involves 2 ASs. You said : "There’s no obvious reason to have two types of ASs". Do you see an alternative ?

    Regarding the last item, I don't think that naming RQ by end-user created the problem. It might just highlight the asymmetry, which fundamentally exists. 

    Fabien


    On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper <agropper@healthurl.com> wrote:
    Recap:
    1 - Justin (I think) introduced the idea of an AS on the RS trust boundary side.
    2 - I said the RO should not have to share policies with the RS.
    3 - Alan invented the concept of AS-RO and AS-RS to separate two kinds of PDPs. 

    The thing is that step 2 is not symmetrical. The RO has a legitimate privacy interest in keeping their policies private and minimizing the leakage of information about requests that are posed against those policies. 

    The RS, on the other hand, should be publishing its policies (e.g. what it’s selling or what jurisdiction it’s in or what tokens or scopes it supports). The RS has no obvious privacy interest in GNAP. It’s just an enforcer.

    There is one other privacy interest to consider around the RS and that is the requesting party (the end-user that is not the RO :-) might prefer to share attributes with the RS instead of the RO or something controlled by the RO. This case could be an “extension” to GNAP and might result in a split AS as a solution. This problem was introduced when the editors decided to replace RQ with end-user. Obviously, the RO end-user has no privacy interests relative to itself.

    Adrian




    On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    I was referring to "By my definition, this model has two ASs since both are processing requests into tokens". If there's no reason to have 2 types of ASs, that's fine then. 
    But I'm a bit lost in where we stand with the idea. 

    Could you recap? 

    Fabien 

    Le jeu. 25 mars 2021 à 08:16, Adrian Gropper <agropper@healthurl.com> a écrit :
    There’s no obvious reason to have two types of ASs. Any AS that is executing the policies of the RS can look to GNAP like the RS itself. Why would GNAP expose that interface to anyone? 

    Adrian

    On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Note : I'm not sure that's a good idea, but having 2 types of ASs is not that easy to grasp.

    Fabien 

    Le jeu. 25 mars 2021 à 08:07, Fabien Imbault <fabien.imbault@gmail.com> a écrit :
    The purpose of either handling policies locally or delegating them to the RO agent. 

    Le jeu. 25 mars 2021 à 08:04, Adrian Gropper <agropper@healthurl.com> a écrit :
    What purpose would be served by GNAP splitting the AS into two components?

    Adrian 

    On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Isn't the AS-RO a component of the AS? Same idea as the interact component, it functionnally belongs to the AS role but could be deployed either as a monolith or as a separate component?

    Fabien

    Le jeu. 25 mars 2021 à 04:26, Adrian Gropper <agropper@healthurl.com> a écrit :
    Yes, but I would say it’s not the RO that wants the access token. It’s the RO that wants the client making the request to get an access token. 

    Adrian

    On Wed, Mar 24, 2021 at 11:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Adrian Gropper <agropper@healthurl.com> wrote:

    In this design, the AS is the AS-RS and the agent is the AS-RO. By my definition, this model has two ASs since both are processing requests into tokens. The problem with this is complexity and privacy. The RO may not want to share the request information with the AS-RS.

    More precisely, RO has no choice but to present the required information to AS-RS if RO wants an access token.  However, RO does not want AS-RS to know the policy by which RO delegates tokens.  That's why RO uses AS-RO for those delegations.

    --------------
    Alan Karp


    On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Thank you for creating the issue. My definition of AS is independent of AS-RO or AS-RS. https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomment-806280421 I also agree with Alan's definition based on delegation. An AS-RS would be a delegate of the RS. 

    Based on that, I see it as obvious that the policy has to be accessible (defined locally?) in order for it to be run as the code that turns a request into an access token. 

    The only other possibility is that the request is packaged by the AS and sent elsewhere (an agent) for evaluation against policy and a proto-token returned. In that case the AS is acting as a proxy and the PDP is elsewhere. I can imagine that an AS-RS would behave this way so that the proto-token could be turned into an access token by the AS-RS. Isn't this what Justin is proposing? In this design, the AS is the AS-RS and the agent is the AS-RO. By my definition, this model has two ASs since both are processing requests into tokens. The problem with this is complexity and privacy. The RO may not want to share the request information with the AS-RS.

    Adrian

    On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Isn't that what the AS is supposed to be, only with the caveat that the policy is defined locally? 

    Fabien 


    Le mer. 24 mars 2021 à 20:17, Alan Karp <alanhkarp@gmail.com> a écrit :
    AS-RO is an AS that RO trusts to delegate RO's access tokens according to RO's policies.  

    --------------
    Alan Karp


    On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan and Adrian,

    I've created issue AS-RO policy delegation (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to capture your input. 
    A first question that arises: can we give a definition to AS-RO?

    Thanks
    Fabien

    On Tue, Mar 23, 2021 at 4:15 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan, 

    Yes, but in that flow, the token relationship between AS-RS and AS-RO is only secure if the tokens issued by AS-RS are cryptographically attenuable in the first place. 
     
    Attenuated delegation is a requirement, but that doesn't have to be done cryptographically.  Token exchange works just fine.  SPKI and zcap-ld are examples of the crypto approach, and we used token exchange in the system for HP.

    --------------
    Alan Karp


    On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan, 

    Yes, but in that flow, the token relationship between AS-RS and AS-RO is only secure if the tokens issued by AS-RS are cryptographically attenuable in the first place. 

    Fabien

    On Mon, Mar 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin Richer <jricher@mit.edu> wrote:

    But with all that in mind, I think the key here is going to be looking at what the inputs to the AS are, and how those can be defined in an interoperable way for AS’s that can accept them. I think there’s a lot of room for innovation and flexibility here that doesn’t break the trust model or core use cases. If I have an AS-RS set that won’t accept my favorite flavor of policy engine inputs, then I can decide not to use that one. But this is a very different question than saying the RS itself needs to accept my own AS — and we can’t keep conflating these two models.

    I agree.  The point of having an AS-RO is to allow RO to specify a policy for which of RO's access tokens should be delegated under what conditions.  AS-RS should not need to understand those policies.  The flow would be
    • RO contacts AS-RS and gets one or more access tokens.
    • RO delegates one or more of those tokens, potentially sub-scoped, to AS-RO.
    • A different user contacts AS-RO to get a potentially sub-scoped access token from AS-RO.
    • That user presents the access token delegated by AS-RO when invoking the resource.
    AS-RS only needs to verify that the delegation chain is legitimate, e.g., no increase in scope, and that it grants permission for the request being made.  AS-RS does not need to understand the policy behind granting the delegation by AS-RO.

    --------------
    Alan Karp


    On Mon, Mar 22, 2021 at 11:40 AM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    I think this shows the problem with the terminology as it’s been applied in this conversation, which I’ve tried to shine light on before. What you and others are calling the “RS” is really the “AS and RS working together” — everything to the right of the line. When Denis had brought up “eliminating the AS” in another thread, what he’d really done is labeled everything to the right of the line as the “RS”. Of course, the irony here is that everything to the right of the line used all be called the “AS” or simply “server” in the OAuth 1 days. As you say below, I don’t want the client to have visibility on what happens on that side. 

    Note well: The Google+ logo labeled “IdP” in the diagram is not the AS, as far as GNAP is concerned. It does not issue an access token that the RS will accept. The elements to the left of the line could be a lot of things, but they are NOT the AS — by definition. The client lives over on the left, but so do any external inputs to the AS. These could be policy inputs on behalf of the RO, they could be presentation artifacts, they could be federated logins, they could be the output of policy decisions. How the AS comes to trust those things is up to the AS’s implementation. It’s something we can talk about, but ultimately GNAP won’t be in any position to dictate because in practice some AS’s are simply going to internalize all policies and we will never successfully force those open. 

    But with all that in mind, I think the key here is going to be looking at what the inputs to the AS are, and how those can be defined in an interoperable way for AS’s that can accept them. I think there’s a lot of room for innovation and flexibility here that doesn’t break the trust model or core use cases. If I have an AS-RS set that won’t accept my favorite flavor of policy engine inputs, then I can decide not to use that one. But this is a very different question than saying the RS itself needs to accept my own AS — and we can’t keep conflating these two models.

    So to me, GNAP can support a Zero Trust Architecture by LEVERAGING the AS, not by subsuming or eliminating it. It is in fact the AS, not the client and not the RS, that will request and consume the results of a privacy-preserving zero-trust policy query thing. Anything that happens downstream from that is of little concern to the zero-trust components because, as you point out, it’s on the “other side” of the line. 

    I think we got this basic component model pretty right in OAuth: the AS and RS and client working together. Where OAuth misses the mark is the assumption that the user has to log in to the AS through a webpage and interact directly, thereby proving they’re the RO. It’s this latter space where I think we can both push innovation and also address the important and compelling use cases like the ones you’re bringing.

     — Justin

    On Mar 22, 2021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I'm sorry, Justin. As a Resource Owner, I look at the RS trust boundary (the dotted line in the diagram) as being the RS. I don't expect any visibility into what's going on on the right. 

    My problem with the framing you propose is that requests are going to the RS (or the AS-RS) and I don't want to share my policies with the AS-RS. I want to keep the RS and AS-RS as ignorant as possible.

    Adrian

    On Mon, Mar 22, 2021 at 1:48 PM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    What you’re discussing below, in terms of logging in to a site, is not approaching the RS. You are in fact approaching the client, and identifying both the AS and RS to the client. The client is a client of your identity in this model, and the RS is part of the identity provider. It’s really important that we don’t conflate the RS and client in this way as it leads to a lot of confusion downstream and a lot of broken trust boundaries.

    With that model in mind, approaching the “RS" and providing it your identity is really just a case of the “federated login to AS” pattern that we discussed on the WG call. The user here approaches an RS, which has its own AS. To share things from this RS, the RO has to authenticate to the RS’s AS. This particular AS allows the RO to do so using an external identity — in which case, the AS is now a “client” of a separate, disconnected (but layered) delegation. The ultimate client that eventually calls the RS down the way may or may not know about these layers. 

    <PastedGraphic-1.png>
    This same AS, which is closely tied to the RS and trusted by the RS, might also take in FIDO credentials, or DIDs, or any number of other proof mechanisms. The output of this is an access token the RS trusts, but the input is up to the AS. The RS is not what you’re logging in to.

     — Justin

    On Mar 22, 2021, at 1:28 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I too am in favor of avoiding consolidation and correlation. Right now, when I approach a service provider (RS) for the first time, I'm offered the opportunity to identify my persona as: email, sign-in with Google, Facebook, or Apple. I know there are people who try to create one-off email addresses but that is mostly a waste of time. 

    So, along come FIDO2 and DID wallets to the rescue. Now, in theory, I have a way to start out my RS relationship pseudonymously. 

    When I want my resource to be discovered or shared I will post that RS URL including my pseudonym. If I then want to introduce a mediator in front of my AS or messaging service endpoint, I have that option. If I want to keep requests away from the mediator, I would publish an encryption key along with my pseudonym.

    - Adrian



    On Mon, Mar 22, 2021 at 9:55 AM Justin Richer <jricher@mit.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhkarp@gmail.com> shared a talk about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use authority
    >> as a core principle. I advocate for a GNAP design that maximizes the power
    >> of the RO, to be seen as a human rights issue when the RO is a human. This
    >> causes me to ask how to combine better security with better human rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO to
    >> partition limited authority across dozens of different ASs by domain and
    >> function, then we are not using technology to empower the individual.
    >> Probably the opposite, as we introduce consent fatigue and burden normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because that maps
    >> into the way we manage our public and private identities. POLA would then
    >> teach care in keeping ASs and RSs related to work / public separate from
    >> ASs and RSs related to private life so that a policy vulnerability in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP
    > seems like a useful exercise.  I do want to point out some potential
    > pitfalls with one-AS-per-persona that we can also be aware of.  If
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS's
    > identity in effect also serves as a persona identity and there are privacy
    > considerations to that.  If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)
    > route is taken, we should consider whether that would lead to various
    > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.  That topic is a current matter of concern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the UMA working group, and it’s one of the biggest problems with the personal AS (and personal data store) model. This kind of thing makes RS-first trust models really difficult in practice.

    As a strawman, let’s say that I’ve got software that wants to access my medical information. It calls an RS and requests access, but it hasn’t been granted anything yet. Now I as the RO have set up the RS so that it talks to my personal AS, that only I use. In addition to the RS having to be able to figure out which medical records are being requested from the context of the unauthenticated request (which means it needs identifiers in the URL or something similar for the RS to be able to tell, assuming that it protects data for more than one person). So this client software doesn’t know who I am and doesn’t know my medical record information, makes a completely unauthorized request to the RS, and the RS says “Go to Justin’s personal AS to get a token”. The client can now make a direct correlation between the data that’s being protected at the RS and the person running the AS that protects it. Importantly, this client makes this call with no prior relationship to the RS and no really auditable way to track it down after the fact. This is a design feature in the good case, and terrifying in the bad case.

    If the RS instead says “welcome to Medicine Doctor RS, please talk to the Medicine Doctor AS to get access”, we haven’t exposed anything at all. And from the perspective of both the patient and the RS, this is more privacy-preserving, and it’s really the least surprising option. Once the client gets to the AS, it can start a negotiation of figuring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS, or set of AS’s for multiple personas to keep things separate, is a huge burden. Even in the tech community, I know people who can’t reliably manage more than one email address for different purposes. I wouldn’t expect my partner to do that — they have trouble enough balancing all the logins and sessions required for different kids remote schooling, I couldn’t imagine them having to understand all the requirements for managing multiple authorization servers and associated policies. I also don’t expect any person to “manage keys” — I’ve been on the internet for decades and I can barely keep tabs on my GPG keys, and only use them when I am forced to. This is exactly the kind of “market pressure” that I think Ben mentions above, people will just want to outsource that to someone else, and the reality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice only to end up with a world where the RS ends up making a limited choice anyway. We see how that plays out with OpenID Connect — RP’s could allow arbitrary IdPs but they choose Google because it works and that’s where the users are. (And that’s not to say anything of the proprietary OIDC-like protocols, but that’s another discussion).

    For further reading on these topics, I recommend both “Why Johnny Can’t Encrypt” and “Why CSCW Systems Fail”.

    So what does this have to do with GNAP? I think we can be clear-eyed on what kinds of expectations we have for the participants. If we expect users (RO’s) to have to set up the AS-RS relationship, or expect them to carry their AS, or manage their personal keys — I think we’ve lost the battle for relevance.

     — Justin


    --
    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


    --------------6AB2240A9C01BEB7B36CFD0C-- From nobody Thu Mar 25 01:26:28 2021 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 56EE63A15B3 for ; Thu, 25 Mar 2021 01:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 XioQo1TacOra for ; Thu, 25 Mar 2021 01:26:22 -0700 (PDT) Received: from mail-ua1-f54.google.com (mail-ua1-f54.google.com [209.85.222.54]) (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 78E0E3A15A1 for ; Thu, 25 Mar 2021 01:26:22 -0700 (PDT) Received: by mail-ua1-f54.google.com with SMTP id j4so271183uan.1 for ; Thu, 25 Mar 2021 01:26:22 -0700 (PDT) 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=L6sVlvcIHh7oAPjpEK8Ih8CySAkogFZOoZvkzV0vU3U=; b=gSbCPSssj8kx2efJLNaeBi06n1tvUaUKW+Cqol/19wGjJfwIBoCod0LJEjwL4kVAPF NA4DIO2aJQxPHZWwN7uGDXjoBN9d1SLU2IN6bZlH6jTatQ91mrgfErVI1CzuAG/nQOXg 4RTAbfV2/toIR9gEObjca0XGuaS88abpcr9AobXasU+fNKAl5d/rxgsX6ULf8JBWai27 4DLKHqgtZm7M8KTy0wI1E7DRqq2JTxJItUTuk7ubr5sBfiU6tyO3cLIzhi2USkkfCSIk CUY98w6cq5NS2IJve6fcmVVnEaBwPvocFTOnT8K6/A1WPceyK6cIVRaoBP6HirsBf0Cz 5pcA== X-Gm-Message-State: AOAM530uTu+476LoMBU3fW82SrqypopRS3guXS1MP7l2BjVh0i40Lk5W pVc5ZVZ+VoFS4OY1pxvm/HUn2D1bBijhA5Bi51g= X-Google-Smtp-Source: ABdhPJwNuaKccsGmpG1Hj3yaf/KW0D90PU/MMTxTH10sZReHKTKIo//lB4AcXI9Xx2mDD2BR9qxduNwqHdLFqEqE+Rs= X-Received: by 2002:a9f:3766:: with SMTP id a35mr4016105uae.128.1616660781126; Thu, 25 Mar 2021 01:26:21 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> In-Reply-To: From: Adrian Gropper Date: Thu, 25 Mar 2021 04:26:09 -0400 Message-ID: To: Fabien Imbault Cc: Alan Karp , Benjamin Kaduk , GNAP Mailing List , Justin Richer , Mark Miller Content-Type: multipart/alternative; boundary="00000000000094d60205be582b08" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 08:26:27 -0000 --00000000000094d60205be582b08 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I believe there are alternatives to having two kinds of ASs. The problem may be a side-effect of deciding to switch away form treating the RO as different from the RQ. That leads to downstream privacy issues. Our desire for architectural simplicity is admirable but that may have been a step too far. There may also be solutions based on different types of tokens, as in different capabilities (tokens signed by the RS) vs. tokens signed by the AS. I=E2=80=99m not sure about that but Alan might have more to say. Adrian On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault wrote: > Thanks. The general problem statement is clear. > > The proposed solution a bit less (to me). I understood that from point 2, > Alan involves 2 ASs. You said : "There=E2=80=99s no obvious reason to hav= e two > types of ASs". Do you see an alternative ? > > Regarding the last item, I don't think that naming RQ by end-user created > the problem. It might just highlight the asymmetry, which fundamentally > exists. > > Fabien > > > On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper > wrote: > >> Recap: >> 1 - Justin (I think) introduced the idea of an AS on the RS trust >> boundary side. >> 2 - I said the RO should not have to share policies with the RS. >> 3 - Alan invented the concept of AS-RO and AS-RS to separate two kinds o= f >> PDPs. >> >> The thing is that step 2 is not symmetrical. The RO has a legitimate >> privacy interest in keeping their policies private and minimizing the >> leakage of information about requests that are posed against those >> policies. >> >> The RS, on the other hand, should be publishing its policies (e.g. what >> it=E2=80=99s selling or what jurisdiction it=E2=80=99s in or what tokens= or scopes it >> supports). The RS has no obvious privacy interest in GNAP. It=E2=80=99s = just an >> enforcer. >> >> There is one other privacy interest to consider around the RS and that i= s >> the requesting party (the end-user that is not the RO :-) might prefer t= o >> share attributes with the RS instead of the RO or something controlled b= y >> the RO. This case could be an =E2=80=9Cextension=E2=80=9D to GNAP and mi= ght result in a >> split AS as a solution. This problem was introduced when the editors >> decided to replace RQ with end-user. Obviously, the RO end-user has no >> privacy interests relative to itself. >> >> Adrian >> >> >> >> >> On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault >> wrote: >> >>> I was referring to "By my definition, this model has two ASs since both >>> are processing requests into tokens". If there's no reason to have 2 ty= pes >>> of ASs, that's fine then. >>> But I'm a bit lost in where we stand with the idea. >>> >>> Could you recap? >>> >>> Fabien >>> >>> Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper a >>> =C3=A9crit : >>> >>>> There=E2=80=99s no obvious reason to have two types of ASs. Any AS tha= t is >>>> executing the policies of the RS can look to GNAP like the RS itself. = Why >>>> would GNAP expose that interface to anyone? >>>> >>>> Adrian >>>> >>>> On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Note : I'm not sure that's a good idea, but having 2 types of ASs is >>>>> not that easy to grasp. >>>>> >>>>> Fabien >>>>> >>>>> Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault >>>>> a =C3=A9crit : >>>>> >>>>>> The purpose of either handling policies locally or delegating them t= o >>>>>> the RO agent. >>>>>> >>>>>> Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper >>>>>> a =C3=A9crit : >>>>>> >>>>>>> What purpose would be served by GNAP splitting the AS into two >>>>>>> components? >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>> On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>> >>>>>>>> Isn't the AS-RO a component of the AS? Same idea as the interact >>>>>>>> component, it functionnally belongs to the AS role but could be de= ployed >>>>>>>> either as a monolith or as a separate component? >>>>>>>> >>>>>>>> Fabien >>>>>>>> >>>>>>>> Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper < >>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>> >>>>>>>>> Yes, but I would say it=E2=80=99s not the RO that wants the acces= s token. >>>>>>>>> It=E2=80=99s the RO that wants the client making the request to g= et an access >>>>>>>>> token. >>>>>>>>> >>>>>>>>> Adrian >>>>>>>>> >>>>>>>>> On Wed, Mar 24, 2021 at 11:22 PM Alan Karp >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Adrian Gropper wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> In this design, the AS is the AS-RS and the agent is the AS-RO. >>>>>>>>>>> By my definition, this model has two ASs since both are process= ing requests >>>>>>>>>>> into tokens. The problem with this is complexity and privacy. T= he RO may >>>>>>>>>>> not want to share the request information with the AS-RS. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> More precisely, RO has no choice but to present the required >>>>>>>>>> information to AS-RS if RO wants an access token. However, RO d= oes not >>>>>>>>>> want AS-RS to know the policy by which RO delegates tokens. Tha= t's why RO >>>>>>>>>> uses AS-RO for those delegations. >>>>>>>>>> >>>>>>>>>> -------------- >>>>>>>>>> Alan Karp >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper < >>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>> >>>>>>>>>>> Thank you for creating the issue. My definition of AS is >>>>>>>>>>> independent of AS-RO or AS-RS. >>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#i= ssuecomment-806280421 >>>>>>>>>>> I also agree with Alan's definition based on delegation. An AS-= RS would be >>>>>>>>>>> a delegate of the RS. >>>>>>>>>>> >>>>>>>>>>> Based on that, I see it as obvious that the policy has to be >>>>>>>>>>> accessible (defined locally?) in order for it to be run as the = code that >>>>>>>>>>> turns a request into an access token. >>>>>>>>>>> >>>>>>>>>>> The only other possibility is that the request is packaged by >>>>>>>>>>> the AS and sent elsewhere (an agent) for evaluation against pol= icy and a >>>>>>>>>>> proto-token returned. In that case the AS is acting as a proxy = and the PDP >>>>>>>>>>> is elsewhere. I can imagine that an AS-RS would behave this way= so that the >>>>>>>>>>> proto-token could be turned into an access token by the AS-RS. = Isn't this >>>>>>>>>>> what Justin is proposing? In this design, the AS is the AS-RS a= nd the agent >>>>>>>>>>> is the AS-RO. By my definition, this model has two ASs since bo= th are >>>>>>>>>>> processing requests into tokens. The problem with this is compl= exity and >>>>>>>>>>> privacy. The RO may not want to share the request information w= ith the >>>>>>>>>>> AS-RS. >>>>>>>>>>> >>>>>>>>>>> Adrian >>>>>>>>>>> >>>>>>>>>>> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault < >>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Isn't that what the AS is supposed to be, only with the caveat >>>>>>>>>>>> that the policy is defined locally? >>>>>>>>>>>> >>>>>>>>>>>> Fabien >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp >>>>>>>>>>>> a =C3=A9crit : >>>>>>>>>>>> >>>>>>>>>>>>> AS-RO is an AS that RO trusts to delegate RO's access tokens >>>>>>>>>>>>> according to RO's policies. >>>>>>>>>>>>> >>>>>>>>>>>>> -------------- >>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault < >>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Alan and Adrian, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I've created issue AS-RO policy delegation ( >>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/22= 3) >>>>>>>>>>>>>> to capture your input. >>>>>>>>>>>>>> A first question that arises: can we give a definition to >>>>>>>>>>>>>> AS-RO? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp < >>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Fabien Imbault wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yes, but in that flow, the token relationship between AS-R= S >>>>>>>>>>>>>>>> and AS-RO is only secure if the tokens issued by AS-RS are >>>>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Attenuated delegation is a requirement, but that doesn't >>>>>>>>>>>>>>> have to be done cryptographically. Token exchange works ju= st fine. SPKI >>>>>>>>>>>>>>> and zcap-ld are examples of the crypto approach, and we use= d token exchange >>>>>>>>>>>>>>> in the system for HP. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault < >>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yes, but in that flow, the token relationship between AS-R= S >>>>>>>>>>>>>>>> and AS-RO is only secure if the tokens issued by AS-RS are >>>>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp < >>>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Justin Richer wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> But with all that in mind, I think the key here is going >>>>>>>>>>>>>>>>>> to be looking at what the inputs to the AS are, and how = those can be >>>>>>>>>>>>>>>>>> defined in an interoperable way for AS=E2=80=99s that ca= n accept them. I think >>>>>>>>>>>>>>>>>> there=E2=80=99s a lot of room for innovation and flexibi= lity here that doesn=E2=80=99t >>>>>>>>>>>>>>>>>> break the trust model or core use cases. If I have an AS= -RS set that won=E2=80=99t >>>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine inputs, then = I can decide not to >>>>>>>>>>>>>>>>>> use that one. But this is a very different question than= saying the RS >>>>>>>>>>>>>>>>>> itself needs to accept my own AS =E2=80=94 and we can=E2= =80=99t keep conflating these two >>>>>>>>>>>>>>>>>> models. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I agree. The point of having an AS-RO is to allow RO to >>>>>>>>>>>>>>>>> specify a policy for which of RO's access tokens should b= e delegated under >>>>>>>>>>>>>>>>> what conditions. AS-RS should not need to understand tho= se policies. The >>>>>>>>>>>>>>>>> flow would be >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - RO contacts AS-RS and gets one or more access tokens= . >>>>>>>>>>>>>>>>> - RO delegates one or more of those tokens, >>>>>>>>>>>>>>>>> potentially sub-scoped, to AS-RO. >>>>>>>>>>>>>>>>> - A different user contacts AS-RO to get a potentially >>>>>>>>>>>>>>>>> sub-scoped access token from AS-RO. >>>>>>>>>>>>>>>>> - That user presents the access token delegated by >>>>>>>>>>>>>>>>> AS-RO when invoking the resource. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> AS-RS only needs to verify that the delegation chain is >>>>>>>>>>>>>>>>> legitimate, e.g., no increase in scope, and that it grant= s permission for >>>>>>>>>>>>>>>>> the request being made. AS-RS does not need to understan= d the policy >>>>>>>>>>>>>>>>> behind granting the delegation by AS-RO. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer < >>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I think this shows the problem with the terminology as >>>>>>>>>>>>>>>>>> it=E2=80=99s been applied in this conversation, which I= =E2=80=99ve tried to shine light on >>>>>>>>>>>>>>>>>> before. What you and others are calling the =E2=80=9CRS= =E2=80=9D is really the =E2=80=9CAS and RS >>>>>>>>>>>>>>>>>> working together=E2=80=9D =E2=80=94 everything to the ri= ght of the line. When Denis had >>>>>>>>>>>>>>>>>> brought up =E2=80=9Celiminating the AS=E2=80=9D in anoth= er thread, what he=E2=80=99d really done is >>>>>>>>>>>>>>>>>> labeled everything to the right of the line as the =E2= =80=9CRS=E2=80=9D. Of course, the >>>>>>>>>>>>>>>>>> irony here is that everything to the right of the line u= sed all be called >>>>>>>>>>>>>>>>>> the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80= =9D in the OAuth 1 days. As you say below, I don=E2=80=99t >>>>>>>>>>>>>>>>>> want the client to have visibility on what happens on th= at side. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80= =9D in the diagram >>>>>>>>>>>>>>>>>> is not the AS, as far as GNAP is concerned. It does not = issue an access >>>>>>>>>>>>>>>>>> token that the RS will accept. The elements to the left = of the line could >>>>>>>>>>>>>>>>>> be a lot of things, but they are NOT the AS =E2=80=94 by= definition. The client >>>>>>>>>>>>>>>>>> lives over on the left, but so do any external inputs to= the AS. These >>>>>>>>>>>>>>>>>> could be policy inputs on behalf of the RO, they could b= e presentation >>>>>>>>>>>>>>>>>> artifacts, they could be federated logins, they could be= the output of >>>>>>>>>>>>>>>>>> policy decisions. How the AS comes to trust those things= is up to the AS=E2=80=99s >>>>>>>>>>>>>>>>>> implementation. It=E2=80=99s something we can talk about= , but ultimately GNAP won=E2=80=99t >>>>>>>>>>>>>>>>>> be in any position to dictate because in practice some A= S=E2=80=99s are simply >>>>>>>>>>>>>>>>>> going to internalize all policies and we will never succ= essfully force >>>>>>>>>>>>>>>>>> those open. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> But with all that in mind, I think the key here is going >>>>>>>>>>>>>>>>>> to be looking at what the inputs to the AS are, and how = those can be >>>>>>>>>>>>>>>>>> defined in an interoperable way for AS=E2=80=99s that ca= n accept them. I think >>>>>>>>>>>>>>>>>> there=E2=80=99s a lot of room for innovation and flexibi= lity here that doesn=E2=80=99t >>>>>>>>>>>>>>>>>> break the trust model or core use cases. If I have an AS= -RS set that won=E2=80=99t >>>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine inputs, then = I can decide not to >>>>>>>>>>>>>>>>>> use that one. But this is a very different question than= saying the RS >>>>>>>>>>>>>>>>>> itself needs to accept my own AS =E2=80=94 and we can=E2= =80=99t keep conflating these two >>>>>>>>>>>>>>>>>> models. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> So to me, GNAP can support a Zero Trust Architecture by >>>>>>>>>>>>>>>>>> LEVERAGING the AS, not by subsuming or eliminating it. I= t is in fact the >>>>>>>>>>>>>>>>>> AS, not the client and not the RS, that will request and= consume the >>>>>>>>>>>>>>>>>> results of a privacy-preserving zero-trust policy query = thing. Anything >>>>>>>>>>>>>>>>>> that happens downstream from that is of little concern t= o the zero-trust >>>>>>>>>>>>>>>>>> components because, as you point out, it=E2=80=99s on th= e =E2=80=9Cother side=E2=80=9D of the line. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I think we got this basic component model pretty right i= n >>>>>>>>>>>>>>>>>> OAuth: the AS and RS and client working together. Where = OAuth misses the >>>>>>>>>>>>>>>>>> mark is the assumption that the user has to log in to th= e AS through a >>>>>>>>>>>>>>>>>> webpage and interact directly, thereby proving they=E2= =80=99re the RO. It=E2=80=99s this >>>>>>>>>>>>>>>>>> latter space where I think we can both push innovation a= nd also address the >>>>>>>>>>>>>>>>>> important and compelling use cases like the ones you=E2= =80=99re bringing. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper < >>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I'm sorry, Justin. As a Resource Owner, I look at the RS >>>>>>>>>>>>>>>>>> trust boundary (the dotted line in the diagram) as being= the RS. I don't >>>>>>>>>>>>>>>>>> expect any visibility into what's going on on the right. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> My problem with the framing you propose is that requests >>>>>>>>>>>>>>>>>> are going to the RS (or the AS-RS) and I don't want to s= hare my policies >>>>>>>>>>>>>>>>>> with the AS-RS. I want to keep the RS and AS-RS as ignor= ant as possible. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer < >>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> What you=E2=80=99re discussing below, in terms of loggi= ng in to >>>>>>>>>>>>>>>>>>> a site, is not approaching the RS. You are in fact appr= oaching the client, >>>>>>>>>>>>>>>>>>> and identifying both the AS and RS to the client. The c= lient is a client *of >>>>>>>>>>>>>>>>>>> your identity* in this model, and the RS is part of the >>>>>>>>>>>>>>>>>>> identity provider. It=E2=80=99s really important that w= e don=E2=80=99t conflate the RS and >>>>>>>>>>>>>>>>>>> client in this way as it leads to a lot of confusion do= wnstream and a lot >>>>>>>>>>>>>>>>>>> of broken trust boundaries. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> With that model in mind, approaching the =E2=80=9CRS" a= nd >>>>>>>>>>>>>>>>>>> providing it your identity is really just a case of the= =E2=80=9Cfederated login to >>>>>>>>>>>>>>>>>>> AS=E2=80=9D pattern that we discussed on the WG call. T= he user here approaches an >>>>>>>>>>>>>>>>>>> RS, which has its own AS. To share things from this RS,= the RO has to >>>>>>>>>>>>>>>>>>> authenticate to the RS=E2=80=99s AS. This particular AS= allows the RO to do so >>>>>>>>>>>>>>>>>>> using an external identity =E2=80=94 in which case, the= AS is now a =E2=80=9Cclient=E2=80=9D of a >>>>>>>>>>>>>>>>>>> separate, disconnected (but layered) delegation. The ul= timate client that >>>>>>>>>>>>>>>>>>> eventually calls the RS down the way may or may not kno= w about these >>>>>>>>>>>>>>>>>>> layers. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> This same AS, which is closely tied to the RS and >>>>>>>>>>>>>>>>>>> trusted by the RS, might also take in FIDO credentials,= or DIDs, or any >>>>>>>>>>>>>>>>>>> number of other proof mechanisms. The output of this is= an access token the >>>>>>>>>>>>>>>>>>> RS trusts, but the input is up to the AS. The RS is not= what you=E2=80=99re logging >>>>>>>>>>>>>>>>>>> in to. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper < >>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I too am in favor of avoiding consolidation and >>>>>>>>>>>>>>>>>>> correlation. Right now, when I approach a service provi= der (RS) for the >>>>>>>>>>>>>>>>>>> first time, I'm offered the opportunity to identify my = persona as: email, >>>>>>>>>>>>>>>>>>> sign-in with Google, Facebook, or Apple. I know there a= re people who try to >>>>>>>>>>>>>>>>>>> create one-off email addresses but that is mostly a was= te of time. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> So, along come FIDO2 and DID wallets to the rescue. Now= , >>>>>>>>>>>>>>>>>>> in theory, I have a way to start out my RS relationship= pseudonymously. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> When I want my resource to be discovered or shared I >>>>>>>>>>>>>>>>>>> will post that RS URL including my pseudonym. If I then= want to introduce a >>>>>>>>>>>>>>>>>>> mediator in front of my AS or messaging service endpoin= t, I have that >>>>>>>>>>>>>>>>>>> option. If I want to keep requests away from the mediat= or, I would publish >>>>>>>>>>>>>>>>>>> an encryption key along with my pseudonym. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> - Adrian >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer < >>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk < >>>>>>>>>>>>>>>>>>>> kaduk@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian >>>>>>>>>>>>>>>>>>>> Gropper wrote: >>>>>>>>>>>>>>>>>>>> >> @Alan Karp shared a talk >>>>>>>>>>>>>>>>>>>> about the Principle Of Least >>>>>>>>>>>>>>>>>>>> >> Authority (POLA) in a recent comment >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/iss= ues/145#issuecomment-803099693 >>>>>>>>>>>>>>>>>>>> >> I recommend it. >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> We might expect a protocol with authorization in th= e >>>>>>>>>>>>>>>>>>>> title to use authority >>>>>>>>>>>>>>>>>>>> >> as a core principle. I advocate for a GNAP design >>>>>>>>>>>>>>>>>>>> that maximizes the power >>>>>>>>>>>>>>>>>>>> >> of the RO, to be seen as a human rights issue when >>>>>>>>>>>>>>>>>>>> the RO is a human. This >>>>>>>>>>>>>>>>>>>> >> causes me to ask how to combine better security wit= h >>>>>>>>>>>>>>>>>>>> better human rights in >>>>>>>>>>>>>>>>>>>> >> GNAP. >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> Who should have the least authority in the GNAP >>>>>>>>>>>>>>>>>>>> design? >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> The AS derives authority as a delegate of the RO. I= f >>>>>>>>>>>>>>>>>>>> we ask the RO to >>>>>>>>>>>>>>>>>>>> >> partition limited authority across dozens of >>>>>>>>>>>>>>>>>>>> different ASs by domain and >>>>>>>>>>>>>>>>>>>> >> function, then we are not using technology to >>>>>>>>>>>>>>>>>>>> empower the individual. >>>>>>>>>>>>>>>>>>>> >> Probably the opposite, as we introduce consent >>>>>>>>>>>>>>>>>>>> fatigue and burden normal >>>>>>>>>>>>>>>>>>>> >> people to partition their lives into non-overlappin= g >>>>>>>>>>>>>>>>>>>> domains. >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> My experience says we should aim for one AS per >>>>>>>>>>>>>>>>>>>> persona because that maps >>>>>>>>>>>>>>>>>>>> >> into the way we manage our public and private >>>>>>>>>>>>>>>>>>>> identities. POLA would then >>>>>>>>>>>>>>>>>>>> >> teach care in keeping ASs and RSs related to work / >>>>>>>>>>>>>>>>>>>> public separate from >>>>>>>>>>>>>>>>>>>> >> ASs and RSs related to private life so that a polic= y >>>>>>>>>>>>>>>>>>>> vulnerability in our >>>>>>>>>>>>>>>>>>>> >> delegation to an AS would have the least likelihood >>>>>>>>>>>>>>>>>>>> of harm. >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > Thinking about how least authority/least privilege >>>>>>>>>>>>>>>>>>>> would apply to GNAP >>>>>>>>>>>>>>>>>>>> > seems like a useful exercise. I do want to point ou= t >>>>>>>>>>>>>>>>>>>> some potential >>>>>>>>>>>>>>>>>>>> > pitfalls with one-AS-per-persona that we can also be >>>>>>>>>>>>>>>>>>>> aware of. If >>>>>>>>>>>>>>>>>>>> > one-AS-per-persona becomes one-persona-per-AS as >>>>>>>>>>>>>>>>>>>> well, then the AS's >>>>>>>>>>>>>>>>>>>> > identity in effect also serves as a persona identity >>>>>>>>>>>>>>>>>>>> and there are privacy >>>>>>>>>>>>>>>>>>>> > considerations to that. If, on the other hand, the >>>>>>>>>>>>>>>>>>>> > multiple-personas-per-AS (presumably corresponding t= o >>>>>>>>>>>>>>>>>>>> multiple humans) >>>>>>>>>>>>>>>>>>>> > route is taken, we should consider whether that woul= d >>>>>>>>>>>>>>>>>>>> lead to various >>>>>>>>>>>>>>>>>>>> > (e.g., market) forces driving consolidation to just = a >>>>>>>>>>>>>>>>>>>> handful of >>>>>>>>>>>>>>>>>>>> > super-popular AS services. That topic is a current >>>>>>>>>>>>>>>>>>>> matter of concern to >>>>>>>>>>>>>>>>>>>> > some IETF participants. >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hi Ben, big +1 to this. This is something that we >>>>>>>>>>>>>>>>>>>> discussed ages ago in the UMA working group, and it=E2= =80=99s one of the biggest >>>>>>>>>>>>>>>>>>>> problems with the personal AS (and personal data store= ) model. This kind of >>>>>>>>>>>>>>>>>>>> thing makes RS-first trust models really difficult in = practice. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve got= software that >>>>>>>>>>>>>>>>>>>> wants to access my medical information. It calls an RS= and requests access, >>>>>>>>>>>>>>>>>>>> but it hasn=E2=80=99t been granted anything yet. Now I= as the RO have set up the RS >>>>>>>>>>>>>>>>>>>> so that it talks to my personal AS, that only I use. I= n addition to the RS >>>>>>>>>>>>>>>>>>>> having to be able to figure out which medical records = are being requested >>>>>>>>>>>>>>>>>>>> from the context of the unauthenticated request (which= means it needs >>>>>>>>>>>>>>>>>>>> identifiers in the URL or something similar for the RS= to be able to tell, >>>>>>>>>>>>>>>>>>>> assuming that it protects data for more than one perso= n). So this client >>>>>>>>>>>>>>>>>>>> software doesn=E2=80=99t know who I am and doesn=E2=80= =99t know my medical record >>>>>>>>>>>>>>>>>>>> information, makes a completely unauthorized request t= o the RS, and the RS >>>>>>>>>>>>>>>>>>>> says =E2=80=9CGo to Justin=E2=80=99s personal AS to ge= t a token=E2=80=9D. The client can now make a >>>>>>>>>>>>>>>>>>>> direct correlation between the data that=E2=80=99s bei= ng protected at the RS and >>>>>>>>>>>>>>>>>>>> the person running the AS that protects it. Importantl= y, this client makes >>>>>>>>>>>>>>>>>>>> this call with no prior relationship to the RS and no = really auditable way >>>>>>>>>>>>>>>>>>>> to track it down after the fact. This is a design feat= ure in the good case, >>>>>>>>>>>>>>>>>>>> and terrifying in the bad case. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> If the RS instead says =E2=80=9Cwelcome to Medicine Do= ctor RS, >>>>>>>>>>>>>>>>>>>> please talk to the Medicine Doctor AS to get access=E2= =80=9D, we haven=E2=80=99t exposed >>>>>>>>>>>>>>>>>>>> anything at all. And from the perspective of both the = patient and the RS, >>>>>>>>>>>>>>>>>>>> this is more privacy-preserving, and it=E2=80=99s real= ly the least surprising >>>>>>>>>>>>>>>>>>>> option. Once the client gets to the AS, it can start a= negotiation of >>>>>>>>>>>>>>>>>>>> figuring out who the RO is for the information being a= ccessed. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On top of this, the usability expectations of people >>>>>>>>>>>>>>>>>>>> managing their own AS, or set of AS=E2=80=99s for mult= iple personas to keep things >>>>>>>>>>>>>>>>>>>> separate, is a huge burden. Even in the tech community= , I know people who >>>>>>>>>>>>>>>>>>>> can=E2=80=99t reliably manage more than one email addr= ess for different purposes. I >>>>>>>>>>>>>>>>>>>> wouldn=E2=80=99t expect my partner to do that =E2=80= =94 they have trouble enough balancing >>>>>>>>>>>>>>>>>>>> all the logins and sessions required for different kid= s remote schooling, I >>>>>>>>>>>>>>>>>>>> couldn=E2=80=99t imagine them having to understand all= the requirements for >>>>>>>>>>>>>>>>>>>> managing multiple authorization servers and associated= policies. I also >>>>>>>>>>>>>>>>>>>> don=E2=80=99t expect any person to =E2=80=9Cmanage key= s=E2=80=9D =E2=80=94 I=E2=80=99ve been on the internet for >>>>>>>>>>>>>>>>>>>> decades and I can barely keep tabs on my GPG keys, and= only use them when I >>>>>>>>>>>>>>>>>>>> am forced to. This is exactly the kind of =E2=80=9Cmar= ket pressure=E2=80=9D that I think >>>>>>>>>>>>>>>>>>>> Ben mentions above, people will just want to outsource= that to someone >>>>>>>>>>>>>>>>>>>> else, and the reality will be a few popular providers. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> In which case, we could end up doing a ton of work to >>>>>>>>>>>>>>>>>>>> allow an RS choice only to end up with a world where t= he RS ends up making >>>>>>>>>>>>>>>>>>>> a limited choice anyway. We see how that plays out wit= h OpenID Connect =E2=80=94 >>>>>>>>>>>>>>>>>>>> RP=E2=80=99s could allow arbitrary IdPs but they choos= e Google because it works and >>>>>>>>>>>>>>>>>>>> that=E2=80=99s where the users are. (And that=E2=80=99= s not to say anything of the >>>>>>>>>>>>>>>>>>>> proprietary OIDC-like protocols, but that=E2=80=99s an= other discussion). >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> For further reading on these topics, I recommend both >>>>>>>>>>>>>>>>>>>> =E2=80=9CWhy Johnny Can=E2=80=99t Encrypt=E2=80=9D and= =E2=80=9CWhy CSCW Systems Fail=E2=80=9D. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> So what does this have to do with GNAP? I think we can >>>>>>>>>>>>>>>>>>>> be clear-eyed on what kinds of expectations we have fo= r the participants. >>>>>>>>>>>>>>>>>>>> If we expect users (RO=E2=80=99s) to have to set up th= e AS-RS relationship, or >>>>>>>>>>>>>>>>>>>> expect them to carry their AS, or manage their persona= l keys =E2=80=94 I think >>>>>>>>>>>>>>>>>>>> we=E2=80=99ve lost the battle for relevance. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>> --00000000000094d60205be582b08 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I believe there are alternatives to having two kinds of A= Ss. The problem may be a side-effect of deciding to switch away form treati= ng the RO as different from the RQ. That leads to downstream privacy issues= . Our desire for architectural simplicity is admirable but that may have be= en a step too far.

    There= may also be solutions based on different types of tokens, as in different = capabilities (tokens signed by the RS) vs. tokens signed by the AS. I=E2=80= =99m not sure about that but Alan might have more to say.

    Adrian
     --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.= ietf.org/mailman/listinfo/txauth
    --00000000000094d60205be582b08-- From nobody Thu Mar 25 01:44:57 2021 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 2D10F3A163B for ; Thu, 25 Mar 2021 01:44: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, 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 RgNQuQkdPvuD for ; Thu, 25 Mar 2021 01:44:52 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 ED8453A1637 for ; Thu, 25 Mar 2021 01:44:51 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id b10so1124161iot.4 for ; Thu, 25 Mar 2021 01:44: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=u9urjCOroQgbaeTBqCUjxPUajZ1eFRAv31NBPBcvq5Y=; b=B5bwTnrXigLcjytk+ia5uKwkRxUhlgkvVZX7u/Dya3/9+YzUs7qjOf3rabptCrfkUz sbs7Jw26bdOKTyvSdiQh4Lek8592k9kLRlsJmsL83Yh/+HSnS2ETS/tHNz6pOxcIlJ1T ZuUpphXY7CRRkXny2MPr7+E7dxJYKtWBikRL8fWYYFXqdGX9GUtPtRLIM9Y1UkXAj8ar QMWzhuiFE+onUyitnS1Ite/YPOFbH/mcf5XGS8CdixNkjivENxcp+j74cNUeEYkfewMD vSYIiT4lkilQY7AmUCXQIKeo5KYvLQXMoDx598vS2VlgTljF45Ih0aMTVDc2OQs/9phv nmSg== 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=u9urjCOroQgbaeTBqCUjxPUajZ1eFRAv31NBPBcvq5Y=; b=mNZhRq56bN3gl9WsCl0kilz9tSGL1SPFwfmgciGqxloBoXfLixYDmKueIe6kD1Nt3a gyo9zpYpTO/J4OwaF+VI8Iv0tScoW2llaWrelOiZTG7/LuUrNeguqkSDUmBAM+bMI1tO 6qep2xF1a4ugZSAAu31aUwHdScmg90gpjW5h2PGBruN+ZeInqVt3qCYugfcIwW2V69S6 BzgDWclu4YSijXeB2EH8xm8oS2oU9/CeQNZv0LzrynjdQ7lN3IK8hcj/PBUP+Mj59Tmk HZKZ6Cg9kY7ZI5O4kIgGZZKnDbiakOMmlt1hD4qaVunxj/tLtAzHIV5Z8kxOejOz1SEv 6pVg== X-Gm-Message-State: AOAM531bcoDsTYFlgHhf+IgpSjgTnABMPNDZ3fsSZla6GEIehIrOwDEp 2lhftIdD2qEUcgJyDMC8Sa1/6IUHg9WVpMd2p1w= X-Google-Smtp-Source: ABdhPJwXYVVx0Usfu8TzXEDur3mkqJcjMkNNFd74ckFBBwj47sdfywPYXCBgwt5OGjwkML+G5a54/yZ4EbGDaipvvdM= X-Received: by 2002:a05:6602:228f:: with SMTP id d15mr5234640iod.141.1616661889930; Thu, 25 Mar 2021 01:44:49 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> In-Reply-To: From: Fabien Imbault Date: Thu, 25 Mar 2021 09:44:38 +0100 Message-ID: To: Adrian Gropper Cc: Alan Karp , Benjamin Kaduk , GNAP Mailing List , Justin Richer , Mark Miller Content-Type: multipart/alternative; boundary="000000000000abda6b05be586dca" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 08:44:57 -0000 --000000000000abda6b05be586dca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ok so I get you correctly: - what matters is the RQ (could be a RO or a end-user or both : we don't really care at a high-level, they're all treated as entities that make a request) - the policy is able to handle those different cases, based on its own internal delegation protocol - currently that requires AS-RS and AS-RO, but maybe it can be simplified To answer to Denis, here's what I understood: - RO trusts AS-RS (and then handles its own policies within AS-RO) - end-user trusts AS-RO (through its client) Could probably work but that's a fairly different model compared to OAuth2 (and of today's GNAP), with different frontiers between the AS and the RS. Please do not hesitate to correct me if I'm wrong. Fabien On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper wrote: > I believe there are alternatives to having two kinds of ASs. The problem > may be a side-effect of deciding to switch away form treating the RO as > different from the RQ. That leads to downstream privacy issues. Our desir= e > for architectural simplicity is admirable but that may have been a step t= oo > far. > > There may also be solutions based on different types of tokens, as in > different capabilities (tokens signed by the RS) vs. tokens signed by the > AS. I=E2=80=99m not sure about that but Alan might have more to say. > > Adrian > > On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault > wrote: > >> Thanks. The general problem statement is clear. >> >> The proposed solution a bit less (to me). I understood that from point 2= , >> Alan involves 2 ASs. You said : "There=E2=80=99s no obvious reason to ha= ve two >> types of ASs". Do you see an alternative ? >> >> Regarding the last item, I don't think that naming RQ by end-user create= d >> the problem. It might just highlight the asymmetry, which fundamentally >> exists. >> >> Fabien >> >> >> On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper >> wrote: >> >>> Recap: >>> 1 - Justin (I think) introduced the idea of an AS on the RS trust >>> boundary side. >>> 2 - I said the RO should not have to share policies with the RS. >>> 3 - Alan invented the concept of AS-RO and AS-RS to separate two kinds >>> of PDPs. >>> >>> The thing is that step 2 is not symmetrical. The RO has a legitimate >>> privacy interest in keeping their policies private and minimizing the >>> leakage of information about requests that are posed against those >>> policies. >>> >>> The RS, on the other hand, should be publishing its policies (e.g. what >>> it=E2=80=99s selling or what jurisdiction it=E2=80=99s in or what token= s or scopes it >>> supports). The RS has no obvious privacy interest in GNAP. It=E2=80=99s= just an >>> enforcer. >>> >>> There is one other privacy interest to consider around the RS and that >>> is the requesting party (the end-user that is not the RO :-) might pref= er >>> to share attributes with the RS instead of the RO or something controll= ed >>> by the RO. This case could be an =E2=80=9Cextension=E2=80=9D to GNAP an= d might result in a >>> split AS as a solution. This problem was introduced when the editors >>> decided to replace RQ with end-user. Obviously, the RO end-user has no >>> privacy interests relative to itself. >>> >>> Adrian >>> >>> >>> >>> >>> On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault >>> wrote: >>> >>>> I was referring to "By my definition, this model has two ASs since >>>> both are processing requests into tokens". If there's no reason to hav= e 2 >>>> types of ASs, that's fine then. >>>> But I'm a bit lost in where we stand with the idea. >>>> >>>> Could you recap? >>>> >>>> Fabien >>>> >>>> Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper >>>> a =C3=A9crit : >>>> >>>>> There=E2=80=99s no obvious reason to have two types of ASs. Any AS th= at is >>>>> executing the policies of the RS can look to GNAP like the RS itself.= Why >>>>> would GNAP expose that interface to anyone? >>>>> >>>>> Adrian >>>>> >>>>> On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Note : I'm not sure that's a good idea, but having 2 types of ASs is >>>>>> not that easy to grasp. >>>>>> >>>>>> Fabien >>>>>> >>>>>> Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault < >>>>>> fabien.imbault@gmail.com> a =C3=A9crit : >>>>>> >>>>>>> The purpose of either handling policies locally or delegating them >>>>>>> to the RO agent. >>>>>>> >>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper >>>>>>> a =C3=A9crit : >>>>>>> >>>>>>>> What purpose would be served by GNAP splitting the AS into two >>>>>>>> components? >>>>>>>> >>>>>>>> Adrian >>>>>>>> >>>>>>>> On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>> >>>>>>>>> Isn't the AS-RO a component of the AS? Same idea as the interact >>>>>>>>> component, it functionnally belongs to the AS role but could be d= eployed >>>>>>>>> either as a monolith or as a separate component? >>>>>>>>> >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper < >>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>> >>>>>>>>>> Yes, but I would say it=E2=80=99s not the RO that wants the acce= ss token. >>>>>>>>>> It=E2=80=99s the RO that wants the client making the request to = get an access >>>>>>>>>> token. >>>>>>>>>> >>>>>>>>>> Adrian >>>>>>>>>> >>>>>>>>>> On Wed, Mar 24, 2021 at 11:22 PM Alan Karp >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Adrian Gropper wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> In this design, the AS is the AS-RS and the agent is the AS-RO= . >>>>>>>>>>>> By my definition, this model has two ASs since both are proces= sing requests >>>>>>>>>>>> into tokens. The problem with this is complexity and privacy. = The RO may >>>>>>>>>>>> not want to share the request information with the AS-RS. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> More precisely, RO has no choice but to present the required >>>>>>>>>>> information to AS-RS if RO wants an access token. However, RO = does not >>>>>>>>>>> want AS-RS to know the policy by which RO delegates tokens. Th= at's why RO >>>>>>>>>>> uses AS-RO for those delegations. >>>>>>>>>>> >>>>>>>>>>> -------------- >>>>>>>>>>> Alan Karp >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper < >>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Thank you for creating the issue. My definition of AS is >>>>>>>>>>>> independent of AS-RO or AS-RS. >>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#= issuecomment-806280421 >>>>>>>>>>>> I also agree with Alan's definition based on delegation. An AS= -RS would be >>>>>>>>>>>> a delegate of the RS. >>>>>>>>>>>> >>>>>>>>>>>> Based on that, I see it as obvious that the policy has to be >>>>>>>>>>>> accessible (defined locally?) in order for it to be run as the= code that >>>>>>>>>>>> turns a request into an access token. >>>>>>>>>>>> >>>>>>>>>>>> The only other possibility is that the request is packaged by >>>>>>>>>>>> the AS and sent elsewhere (an agent) for evaluation against po= licy and a >>>>>>>>>>>> proto-token returned. In that case the AS is acting as a proxy= and the PDP >>>>>>>>>>>> is elsewhere. I can imagine that an AS-RS would behave this wa= y so that the >>>>>>>>>>>> proto-token could be turned into an access token by the AS-RS.= Isn't this >>>>>>>>>>>> what Justin is proposing? In this design, the AS is the AS-RS = and the agent >>>>>>>>>>>> is the AS-RO. By my definition, this model has two ASs since b= oth are >>>>>>>>>>>> processing requests into tokens. The problem with this is comp= lexity and >>>>>>>>>>>> privacy. The RO may not want to share the request information = with the >>>>>>>>>>>> AS-RS. >>>>>>>>>>>> >>>>>>>>>>>> Adrian >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault < >>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Isn't that what the AS is supposed to be, only with the cavea= t >>>>>>>>>>>>> that the policy is defined locally? >>>>>>>>>>>>> >>>>>>>>>>>>> Fabien >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp >>>>>>>>>>>>> a =C3=A9crit : >>>>>>>>>>>>> >>>>>>>>>>>>>> AS-RO is an AS that RO trusts to delegate RO's access tokens >>>>>>>>>>>>>> according to RO's policies. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault < >>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Alan and Adrian, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've created issue AS-RO policy delegation ( >>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/2= 23) >>>>>>>>>>>>>>> to capture your input. >>>>>>>>>>>>>>> A first question that arises: can we give a definition to >>>>>>>>>>>>>>> AS-RO? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp < >>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Fabien Imbault wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yes, but in that flow, the token relationship between >>>>>>>>>>>>>>>>> AS-RS and AS-RO is only secure if the tokens issued by AS= -RS are >>>>>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Attenuated delegation is a requirement, but that doesn't >>>>>>>>>>>>>>>> have to be done cryptographically. Token exchange works j= ust fine. SPKI >>>>>>>>>>>>>>>> and zcap-ld are examples of the crypto approach, and we us= ed token exchange >>>>>>>>>>>>>>>> in the system for HP. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault < >>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yes, but in that flow, the token relationship between >>>>>>>>>>>>>>>>> AS-RS and AS-RO is only secure if the tokens issued by AS= -RS are >>>>>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp < >>>>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Justin Richer wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> But with all that in mind, I think the key here is goin= g >>>>>>>>>>>>>>>>>>> to be looking at what the inputs to the AS are, and how= those can be >>>>>>>>>>>>>>>>>>> defined in an interoperable way for AS=E2=80=99s that c= an accept them. I think >>>>>>>>>>>>>>>>>>> there=E2=80=99s a lot of room for innovation and flexib= ility here that doesn=E2=80=99t >>>>>>>>>>>>>>>>>>> break the trust model or core use cases. If I have an A= S-RS set that won=E2=80=99t >>>>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine inputs, then= I can decide not to >>>>>>>>>>>>>>>>>>> use that one. But this is a very different question tha= n saying the RS >>>>>>>>>>>>>>>>>>> itself needs to accept my own AS =E2=80=94 and we can= =E2=80=99t keep conflating these two >>>>>>>>>>>>>>>>>>> models. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I agree. The point of having an AS-RO is to allow RO t= o >>>>>>>>>>>>>>>>>> specify a policy for which of RO's access tokens should = be delegated under >>>>>>>>>>>>>>>>>> what conditions. AS-RS should not need to understand th= ose policies. The >>>>>>>>>>>>>>>>>> flow would be >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> - RO contacts AS-RS and gets one or more access >>>>>>>>>>>>>>>>>> tokens. >>>>>>>>>>>>>>>>>> - RO delegates one or more of those tokens, >>>>>>>>>>>>>>>>>> potentially sub-scoped, to AS-RO. >>>>>>>>>>>>>>>>>> - A different user contacts AS-RO to get a >>>>>>>>>>>>>>>>>> potentially sub-scoped access token from AS-RO. >>>>>>>>>>>>>>>>>> - That user presents the access token delegated by >>>>>>>>>>>>>>>>>> AS-RO when invoking the resource. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> AS-RS only needs to verify that the delegation chain is >>>>>>>>>>>>>>>>>> legitimate, e.g., no increase in scope, and that it gran= ts permission for >>>>>>>>>>>>>>>>>> the request being made. AS-RS does not need to understa= nd the policy >>>>>>>>>>>>>>>>>> behind granting the delegation by AS-RO. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer < >>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I think this shows the problem with the terminology as >>>>>>>>>>>>>>>>>>> it=E2=80=99s been applied in this conversation, which I= =E2=80=99ve tried to shine light on >>>>>>>>>>>>>>>>>>> before. What you and others are calling the =E2=80=9CRS= =E2=80=9D is really the =E2=80=9CAS and RS >>>>>>>>>>>>>>>>>>> working together=E2=80=9D =E2=80=94 everything to the r= ight of the line. When Denis had >>>>>>>>>>>>>>>>>>> brought up =E2=80=9Celiminating the AS=E2=80=9D in anot= her thread, what he=E2=80=99d really done is >>>>>>>>>>>>>>>>>>> labeled everything to the right of the line as the =E2= =80=9CRS=E2=80=9D. Of course, the >>>>>>>>>>>>>>>>>>> irony here is that everything to the right of the line = used all be called >>>>>>>>>>>>>>>>>>> the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2= =80=9D in the OAuth 1 days. As you say below, I don=E2=80=99t >>>>>>>>>>>>>>>>>>> want the client to have visibility on what happens on t= hat side. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80= =9D in the diagram >>>>>>>>>>>>>>>>>>> is not the AS, as far as GNAP is concerned. It does not= issue an access >>>>>>>>>>>>>>>>>>> token that the RS will accept. The elements to the left= of the line could >>>>>>>>>>>>>>>>>>> be a lot of things, but they are NOT the AS =E2=80=94 b= y definition. The client >>>>>>>>>>>>>>>>>>> lives over on the left, but so do any external inputs t= o the AS. These >>>>>>>>>>>>>>>>>>> could be policy inputs on behalf of the RO, they could = be presentation >>>>>>>>>>>>>>>>>>> artifacts, they could be federated logins, they could b= e the output of >>>>>>>>>>>>>>>>>>> policy decisions. How the AS comes to trust those thing= s is up to the AS=E2=80=99s >>>>>>>>>>>>>>>>>>> implementation. It=E2=80=99s something we can talk abou= t, but ultimately GNAP won=E2=80=99t >>>>>>>>>>>>>>>>>>> be in any position to dictate because in practice some = AS=E2=80=99s are simply >>>>>>>>>>>>>>>>>>> going to internalize all policies and we will never suc= cessfully force >>>>>>>>>>>>>>>>>>> those open. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> But with all that in mind, I think the key here is goin= g >>>>>>>>>>>>>>>>>>> to be looking at what the inputs to the AS are, and how= those can be >>>>>>>>>>>>>>>>>>> defined in an interoperable way for AS=E2=80=99s that c= an accept them. I think >>>>>>>>>>>>>>>>>>> there=E2=80=99s a lot of room for innovation and flexib= ility here that doesn=E2=80=99t >>>>>>>>>>>>>>>>>>> break the trust model or core use cases. If I have an A= S-RS set that won=E2=80=99t >>>>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine inputs, then= I can decide not to >>>>>>>>>>>>>>>>>>> use that one. But this is a very different question tha= n saying the RS >>>>>>>>>>>>>>>>>>> itself needs to accept my own AS =E2=80=94 and we can= =E2=80=99t keep conflating these two >>>>>>>>>>>>>>>>>>> models. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> So to me, GNAP can support a Zero Trust Architecture by >>>>>>>>>>>>>>>>>>> LEVERAGING the AS, not by subsuming or eliminating it. = It is in fact the >>>>>>>>>>>>>>>>>>> AS, not the client and not the RS, that will request an= d consume the >>>>>>>>>>>>>>>>>>> results of a privacy-preserving zero-trust policy query= thing. Anything >>>>>>>>>>>>>>>>>>> that happens downstream from that is of little concern = to the zero-trust >>>>>>>>>>>>>>>>>>> components because, as you point out, it=E2=80=99s on t= he =E2=80=9Cother side=E2=80=9D of the line. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I think we got this basic component model pretty right >>>>>>>>>>>>>>>>>>> in OAuth: the AS and RS and client working together. Wh= ere OAuth misses the >>>>>>>>>>>>>>>>>>> mark is the assumption that the user has to log in to t= he AS through a >>>>>>>>>>>>>>>>>>> webpage and interact directly, thereby proving they=E2= =80=99re the RO. It=E2=80=99s this >>>>>>>>>>>>>>>>>>> latter space where I think we can both push innovation = and also address the >>>>>>>>>>>>>>>>>>> important and compelling use cases like the ones you=E2= =80=99re bringing. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper < >>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I'm sorry, Justin. As a Resource Owner, I look at the R= S >>>>>>>>>>>>>>>>>>> trust boundary (the dotted line in the diagram) as bein= g the RS. I don't >>>>>>>>>>>>>>>>>>> expect any visibility into what's going on on the right= . >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> My problem with the framing you propose is that request= s >>>>>>>>>>>>>>>>>>> are going to the RS (or the AS-RS) and I don't want to = share my policies >>>>>>>>>>>>>>>>>>> with the AS-RS. I want to keep the RS and AS-RS as igno= rant as possible. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer < >>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> What you=E2=80=99re discussing below, in terms of logg= ing in to >>>>>>>>>>>>>>>>>>>> a site, is not approaching the RS. You are in fact app= roaching the client, >>>>>>>>>>>>>>>>>>>> and identifying both the AS and RS to the client. The = client is a client *of >>>>>>>>>>>>>>>>>>>> your identity* in this model, and the RS is part of >>>>>>>>>>>>>>>>>>>> the identity provider. It=E2=80=99s really important t= hat we don=E2=80=99t conflate the RS >>>>>>>>>>>>>>>>>>>> and client in this way as it leads to a lot of confusi= on downstream and a >>>>>>>>>>>>>>>>>>>> lot of broken trust boundaries. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> With that model in mind, approaching the =E2=80=9CRS" = and >>>>>>>>>>>>>>>>>>>> providing it your identity is really just a case of th= e =E2=80=9Cfederated login to >>>>>>>>>>>>>>>>>>>> AS=E2=80=9D pattern that we discussed on the WG call. = The user here approaches an >>>>>>>>>>>>>>>>>>>> RS, which has its own AS. To share things from this RS= , the RO has to >>>>>>>>>>>>>>>>>>>> authenticate to the RS=E2=80=99s AS. This particular A= S allows the RO to do so >>>>>>>>>>>>>>>>>>>> using an external identity =E2=80=94 in which case, th= e AS is now a =E2=80=9Cclient=E2=80=9D of a >>>>>>>>>>>>>>>>>>>> separate, disconnected (but layered) delegation. The u= ltimate client that >>>>>>>>>>>>>>>>>>>> eventually calls the RS down the way may or may not kn= ow about these >>>>>>>>>>>>>>>>>>>> layers. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> This same AS, which is closely tied to the RS and >>>>>>>>>>>>>>>>>>>> trusted by the RS, might also take in FIDO credentials= , or DIDs, or any >>>>>>>>>>>>>>>>>>>> number of other proof mechanisms. The output of this i= s an access token the >>>>>>>>>>>>>>>>>>>> RS trusts, but the input is up to the AS. The RS is no= t what you=E2=80=99re logging >>>>>>>>>>>>>>>>>>>> in to. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper < >>>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I too am in favor of avoiding consolidation and >>>>>>>>>>>>>>>>>>>> correlation. Right now, when I approach a service prov= ider (RS) for the >>>>>>>>>>>>>>>>>>>> first time, I'm offered the opportunity to identify my= persona as: email, >>>>>>>>>>>>>>>>>>>> sign-in with Google, Facebook, or Apple. I know there = are people who try to >>>>>>>>>>>>>>>>>>>> create one-off email addresses but that is mostly a wa= ste of time. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> So, along come FIDO2 and DID wallets to the rescue. >>>>>>>>>>>>>>>>>>>> Now, in theory, I have a way to start out my RS relati= onship >>>>>>>>>>>>>>>>>>>> pseudonymously. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> When I want my resource to be discovered or shared I >>>>>>>>>>>>>>>>>>>> will post that RS URL including my pseudonym. If I the= n want to introduce a >>>>>>>>>>>>>>>>>>>> mediator in front of my AS or messaging service endpoi= nt, I have that >>>>>>>>>>>>>>>>>>>> option. If I want to keep requests away from the media= tor, I would publish >>>>>>>>>>>>>>>>>>>> an encryption key along with my pseudonym. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> - Adrian >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer < >>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk < >>>>>>>>>>>>>>>>>>>>> kaduk@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian >>>>>>>>>>>>>>>>>>>>> Gropper wrote: >>>>>>>>>>>>>>>>>>>>> >> @Alan Karp shared a talk >>>>>>>>>>>>>>>>>>>>> about the Principle Of Least >>>>>>>>>>>>>>>>>>>>> >> Authority (POLA) in a recent comment >>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/is= sues/145#issuecomment-803099693 >>>>>>>>>>>>>>>>>>>>> >> I recommend it. >>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>> >> We might expect a protocol with authorization in >>>>>>>>>>>>>>>>>>>>> the title to use authority >>>>>>>>>>>>>>>>>>>>> >> as a core principle. I advocate for a GNAP design >>>>>>>>>>>>>>>>>>>>> that maximizes the power >>>>>>>>>>>>>>>>>>>>> >> of the RO, to be seen as a human rights issue when >>>>>>>>>>>>>>>>>>>>> the RO is a human. This >>>>>>>>>>>>>>>>>>>>> >> causes me to ask how to combine better security >>>>>>>>>>>>>>>>>>>>> with better human rights in >>>>>>>>>>>>>>>>>>>>> >> GNAP. >>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>> >> Who should have the least authority in the GNAP >>>>>>>>>>>>>>>>>>>>> design? >>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>> >> The AS derives authority as a delegate of the RO. >>>>>>>>>>>>>>>>>>>>> If we ask the RO to >>>>>>>>>>>>>>>>>>>>> >> partition limited authority across dozens of >>>>>>>>>>>>>>>>>>>>> different ASs by domain and >>>>>>>>>>>>>>>>>>>>> >> function, then we are not using technology to >>>>>>>>>>>>>>>>>>>>> empower the individual. >>>>>>>>>>>>>>>>>>>>> >> Probably the opposite, as we introduce consent >>>>>>>>>>>>>>>>>>>>> fatigue and burden normal >>>>>>>>>>>>>>>>>>>>> >> people to partition their lives into >>>>>>>>>>>>>>>>>>>>> non-overlapping domains. >>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>> >> My experience says we should aim for one AS per >>>>>>>>>>>>>>>>>>>>> persona because that maps >>>>>>>>>>>>>>>>>>>>> >> into the way we manage our public and private >>>>>>>>>>>>>>>>>>>>> identities. POLA would then >>>>>>>>>>>>>>>>>>>>> >> teach care in keeping ASs and RSs related to work = / >>>>>>>>>>>>>>>>>>>>> public separate from >>>>>>>>>>>>>>>>>>>>> >> ASs and RSs related to private life so that a >>>>>>>>>>>>>>>>>>>>> policy vulnerability in our >>>>>>>>>>>>>>>>>>>>> >> delegation to an AS would have the least likelihoo= d >>>>>>>>>>>>>>>>>>>>> of harm. >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > Thinking about how least authority/least privilege >>>>>>>>>>>>>>>>>>>>> would apply to GNAP >>>>>>>>>>>>>>>>>>>>> > seems like a useful exercise. I do want to point >>>>>>>>>>>>>>>>>>>>> out some potential >>>>>>>>>>>>>>>>>>>>> > pitfalls with one-AS-per-persona that we can also b= e >>>>>>>>>>>>>>>>>>>>> aware of. If >>>>>>>>>>>>>>>>>>>>> > one-AS-per-persona becomes one-persona-per-AS as >>>>>>>>>>>>>>>>>>>>> well, then the AS's >>>>>>>>>>>>>>>>>>>>> > identity in effect also serves as a persona identit= y >>>>>>>>>>>>>>>>>>>>> and there are privacy >>>>>>>>>>>>>>>>>>>>> > considerations to that. If, on the other hand, the >>>>>>>>>>>>>>>>>>>>> > multiple-personas-per-AS (presumably corresponding >>>>>>>>>>>>>>>>>>>>> to multiple humans) >>>>>>>>>>>>>>>>>>>>> > route is taken, we should consider whether that >>>>>>>>>>>>>>>>>>>>> would lead to various >>>>>>>>>>>>>>>>>>>>> > (e.g., market) forces driving consolidation to just >>>>>>>>>>>>>>>>>>>>> a handful of >>>>>>>>>>>>>>>>>>>>> > super-popular AS services. That topic is a current >>>>>>>>>>>>>>>>>>>>> matter of concern to >>>>>>>>>>>>>>>>>>>>> > some IETF participants. >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hi Ben, big +1 to this. This is something that we >>>>>>>>>>>>>>>>>>>>> discussed ages ago in the UMA working group, and it= =E2=80=99s one of the biggest >>>>>>>>>>>>>>>>>>>>> problems with the personal AS (and personal data stor= e) model. This kind of >>>>>>>>>>>>>>>>>>>>> thing makes RS-first trust models really difficult in= practice. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve go= t software that >>>>>>>>>>>>>>>>>>>>> wants to access my medical information. It calls an R= S and requests access, >>>>>>>>>>>>>>>>>>>>> but it hasn=E2=80=99t been granted anything yet. Now = I as the RO have set up the RS >>>>>>>>>>>>>>>>>>>>> so that it talks to my personal AS, that only I use. = In addition to the RS >>>>>>>>>>>>>>>>>>>>> having to be able to figure out which medical records= are being requested >>>>>>>>>>>>>>>>>>>>> from the context of the unauthenticated request (whic= h means it needs >>>>>>>>>>>>>>>>>>>>> identifiers in the URL or something similar for the R= S to be able to tell, >>>>>>>>>>>>>>>>>>>>> assuming that it protects data for more than one pers= on). So this client >>>>>>>>>>>>>>>>>>>>> software doesn=E2=80=99t know who I am and doesn=E2= =80=99t know my medical record >>>>>>>>>>>>>>>>>>>>> information, makes a completely unauthorized request = to the RS, and the RS >>>>>>>>>>>>>>>>>>>>> says =E2=80=9CGo to Justin=E2=80=99s personal AS to g= et a token=E2=80=9D. The client can now make a >>>>>>>>>>>>>>>>>>>>> direct correlation between the data that=E2=80=99s be= ing protected at the RS and >>>>>>>>>>>>>>>>>>>>> the person running the AS that protects it. Important= ly, this client makes >>>>>>>>>>>>>>>>>>>>> this call with no prior relationship to the RS and no= really auditable way >>>>>>>>>>>>>>>>>>>>> to track it down after the fact. This is a design fea= ture in the good case, >>>>>>>>>>>>>>>>>>>>> and terrifying in the bad case. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> If the RS instead says =E2=80=9Cwelcome to Medicine D= octor RS, >>>>>>>>>>>>>>>>>>>>> please talk to the Medicine Doctor AS to get access= =E2=80=9D, we haven=E2=80=99t exposed >>>>>>>>>>>>>>>>>>>>> anything at all. And from the perspective of both the= patient and the RS, >>>>>>>>>>>>>>>>>>>>> this is more privacy-preserving, and it=E2=80=99s rea= lly the least surprising >>>>>>>>>>>>>>>>>>>>> option. Once the client gets to the AS, it can start = a negotiation of >>>>>>>>>>>>>>>>>>>>> figuring out who the RO is for the information being = accessed. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On top of this, the usability expectations of people >>>>>>>>>>>>>>>>>>>>> managing their own AS, or set of AS=E2=80=99s for mul= tiple personas to keep things >>>>>>>>>>>>>>>>>>>>> separate, is a huge burden. Even in the tech communit= y, I know people who >>>>>>>>>>>>>>>>>>>>> can=E2=80=99t reliably manage more than one email add= ress for different purposes. I >>>>>>>>>>>>>>>>>>>>> wouldn=E2=80=99t expect my partner to do that =E2=80= =94 they have trouble enough balancing >>>>>>>>>>>>>>>>>>>>> all the logins and sessions required for different ki= ds remote schooling, I >>>>>>>>>>>>>>>>>>>>> couldn=E2=80=99t imagine them having to understand al= l the requirements for >>>>>>>>>>>>>>>>>>>>> managing multiple authorization servers and associate= d policies. I also >>>>>>>>>>>>>>>>>>>>> don=E2=80=99t expect any person to =E2=80=9Cmanage ke= ys=E2=80=9D =E2=80=94 I=E2=80=99ve been on the internet for >>>>>>>>>>>>>>>>>>>>> decades and I can barely keep tabs on my GPG keys, an= d only use them when I >>>>>>>>>>>>>>>>>>>>> am forced to. This is exactly the kind of =E2=80=9Cma= rket pressure=E2=80=9D that I think >>>>>>>>>>>>>>>>>>>>> Ben mentions above, people will just want to outsourc= e that to someone >>>>>>>>>>>>>>>>>>>>> else, and the reality will be a few popular providers= . >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> In which case, we could end up doing a ton of work to >>>>>>>>>>>>>>>>>>>>> allow an RS choice only to end up with a world where = the RS ends up making >>>>>>>>>>>>>>>>>>>>> a limited choice anyway. We see how that plays out wi= th OpenID Connect =E2=80=94 >>>>>>>>>>>>>>>>>>>>> RP=E2=80=99s could allow arbitrary IdPs but they choo= se Google because it works and >>>>>>>>>>>>>>>>>>>>> that=E2=80=99s where the users are. (And that=E2=80= =99s not to say anything of the >>>>>>>>>>>>>>>>>>>>> proprietary OIDC-like protocols, but that=E2=80=99s a= nother discussion). >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> For further reading on these topics, I recommend both >>>>>>>>>>>>>>>>>>>>> =E2=80=9CWhy Johnny Can=E2=80=99t Encrypt=E2=80=9D an= d =E2=80=9CWhy CSCW Systems Fail=E2=80=9D. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> So what does this have to do with GNAP? I think we ca= n >>>>>>>>>>>>>>>>>>>>> be clear-eyed on what kinds of expectations we have f= or the participants. >>>>>>>>>>>>>>>>>>>>> If we expect users (RO=E2=80=99s) to have to set up t= he AS-RS relationship, or >>>>>>>>>>>>>>>>>>>>> expect them to carry their AS, or manage their person= al keys =E2=80=94 I think >>>>>>>>>>>>>>>>>>>>> we=E2=80=99ve lost the battle for relevance. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>> --000000000000abda6b05be586dca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Ok so I get you correctly:=C2=A0
    - what matters is the= RQ (could be a RO or a end-user or both : we don't really care at a hi= gh-level, they're all treated as entities that make a request)
    - the policy is able to handle those different cases, based on its own in= ternal delegation protocol
    - currently that requires AS-RS and AS= -RO, but maybe it can be simplified

    To answer to D= enis, here's what I understood:
    - RO trusts AS-RS (and then h= andles its own policies within AS-RO)
    - end-user trusts AS-RO= (through its client)

    Could probably work but that= 's a fairly different model compared to OAuth2 (and of today's GNAP= ), with different frontiers between the AS and the RS.=C2=A0

    =
    Please do not hesitate to correct me if I'm wrong.

    Fabien=C2=A0

    On Thu, Mar 25, 2021 at 9:26 AM Adrian Gr= opper <agropper@healthurl.com<= /a>> wrote:
    <= div dir=3D"auto">I believe there are alternatives to having two kinds of AS= s. The problem may be a side-effect of deciding to switch away form treatin= g the RO as different from the RQ. That leads to downstream privacy issues.= Our desire for architectural simplicity is admirable but that may have bee= n a step too far.

    There = may also be solutions based on different types of tokens, as in different c= apabilities (tokens signed by the RS) vs. tokens signed by the AS. I=E2=80= =99m not sure about that but Alan might have more to say.

    Adrian

    On Thu, Mar 25, 2021 at 4:15 A= M Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks. The general probl= em statement is clear.

    The=C2=A0proposed solution a bit = less (to me). I understood that from point 2, Alan involves 2 ASs. You said= : "There=E2=80=99s no obvious reas= on to have two types of ASs".=C2=A0Do you see an alternative ?<= /div>

    Regarding the last item, I= don't think that naming RQ by end-user created the problem. It might j= ust highlight the asymmetry,=C2=A0which fundamentally exists.=C2=A0<= /div>

    <= div>Fabien


    On Thu, Mar 2= 5, 2021 at 8:48 AM Adrian Gropper <agropper@healthurl.com> wrote:
    Recap:
    =
    1 - Justin (I think) introduced the idea of an AS on the = RS trust boundary side.
    2 - I said the RO should not= have to share policies with the RS.
    3 - Alan invent= ed the concept of AS-RO and AS-RS to separate two kinds of PDPs.=C2=A0

    The thing is that step 2 is = not symmetrical. The RO has a legitimate privacy interest in keeping their = policies private and minimizing the leakage of information about requests t= hat are posed against those policies.=C2=A0

    The RS, on the other hand, should be publishing its pol= icies (e.g. what it=E2=80=99s selling or what jurisdiction it=E2=80=99s in = or what tokens or scopes it supports). The RS has no obvious privacy intere= st in GNAP. It=E2=80=99s just an enforcer.

    There is one other privacy interest to consider around t= he RS and that is the requesting party (the end-user that is not the RO :-)= might prefer to share attributes with the RS instead of the RO or somethin= g controlled by the RO. This case could be an =E2=80=9Cextension=E2=80=9D t= o GNAP and might result in a split AS as a solution. This problem was intro= duced when the editors decided to replace RQ with end-user. Obviously, the = RO end-user has no privacy interests relative to itself.

    Adrian




    On Thu, Mar 25, 2021= at 3:24 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    I was refe= rring to "By my definition, thi= s model has two ASs since both are processing requests into tokens". I= f there's no reason to have 2 types of ASs, that's fine then.=C2=A0=
    But I'm a bit = lost in where we stand with the idea.=C2=A0
    <= font face=3D"sans-serif">
    Could you recap?=C2=A0

    <= font face=3D"sans-serif">Fabien=C2=A0

    Le jeu. 25 mars 2021= =C3=A0 08:16, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    The= re=E2=80=99s no obvious reason to have two types of ASs. Any AS that is exe= cuting the policies of the RS can look to GNAP like the RS itself. Why woul= d GNAP expose that interface to anyone?=C2=A0

    Adrian

    On Thu, Mar 25, 2021 at 3:11 AM Fabien Imb= ault <fabien.imbault@gmail.com> wrote:
    Note : I'm not= sure that's a good idea, but having 2 types of ASs is not that easy to= grasp.

    Fabien=C2=A0

    Le jeu. 25 mars 2021 =C3=A0 08:07, 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:
    The purpose of = either handling policies locally or delegating them to the RO agent.=C2=A0<= /div>
    L= e jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper <agroppe= r@healthurl.com> a =C3=A9crit=C2=A0:
    What purpose would be served = by GNAP splitting the AS into two components?

    Adrian=C2=A0

    On Thu, Ma= r 25, 2021 at 2:59 AM Fabien Imbault <fabien= .imbault@gmail.com> wrote:
    Isn't the AS-RO a component of the = AS? Same idea as the interact component, it functionnally belongs to the AS= role but could be deployed either as a monolith or as a separate component= ?

    Fabi= en

    Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    Yes, but = I would say it=E2=80=99s not the RO that wants the access token. It=E2=80= =99s the RO that wants the client making the request to get an access token= .=C2=A0

    Adrian

    On We= d, Mar 24, 2021 at 11:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Adrian Gropper <ag= ropper@healthurl.com> wrote:

    In thi= s design, the AS is the AS-RS and the agent is the AS-RO. By my definition,= this model has two ASs since both are processing requests into tokens. The= problem with this is complexity and privacy. The RO may not want to share = the request information with the AS-RS.
    =

    More precisely, RO has no choice but t= o present the required information to AS-RS if RO wants an access token.=C2= =A0 However, RO does not want AS-RS to know the policy by which RO delegate= s tokens.=C2=A0 That's why RO uses AS-RO for those delegations.

    --------------
    Alan Karp

    <= div dir=3D"ltr">
    On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Thank you for creating the issue. My definition of AS is independent of= AS-RO or AS-RS.=C2=A0https://github.com/ietf-wg-gnap/gnap= -core-protocol/issues/223#issuecomment-806280421 I also agree with Alan= 's definition based on delegation. An AS-RS would be a delegate of the = RS.=C2=A0

    Based on that, I see it as o= bvious=C2=A0that the policy has to be accessible (defined locally?) in orde= r for it to be run as the code that turns a request into an access token.= =C2=A0

    The only other possibility is that the requ= est is packaged by the AS and sent elsewhere (an agent) for evaluation agai= nst policy and a proto-token returned. In that case the AS is acting as a p= roxy and the PDP is elsewhere. I can imagine that an AS-RS would behave thi= s way so that the proto-token could be turned into an access token by the A= S-RS. Isn't this what Justin is proposing? In this design, the AS is th= e AS-RS and the agent is the AS-RO. By my definition, this model has two AS= s since both are processing requests into tokens. The problem with this is = complexity and privacy. The RO may not want to share the request informatio= n with the AS-RS.

    Adrian

    On Wed, Mar 24, 2021= at 5:21 PM Fabien Imbault <fabie= n.imbault@gmail.com> wrote:
    Isn't that what the AS is sup= posed to be, only with the caveat that the policy is defined locally?=C2=A0=

    Fabien=C2=A0


    Le mer. 24 ma= rs 2021 =C3=A0 20:17, Alan Karp <alanh= karp@gmail.com> a =C3=A9crit=C2=A0:
    AS-RO is an AS= that RO trusts to delegate RO's access tokens according to RO's po= licies.=C2=A0=C2=A0

    ------------= --
    Alan Karp


    On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbau= lt <fabien.imbault@gma= il.com> wrote:
    Hi Alan and Adrian,

    I've crea= ted issue AS-RO policy delegation (https://github.com/ietf-wg-gnap/gna= p-core-protocol/issues/223) to capture your input.=C2=A0
    A fi= rst question that arises: can we give a definition to AS-RO?

    =
    Thanks
    Fabien

    On Tue, Mar 23, 2021 at 4:15 PM Ala= n Karp <alanhkarp@gmail.com= > wrote:
    =
    Fabien Imbault <fabien.imbault@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 Alan,= =C2=A0

    Yes, but in that flow, the token relationship bet= ween AS-RS and AS-RO is only secure if the tokens issued by AS-RS are crypt= ographically attenuable in the first place.=C2=A0
    <= div>=C2=A0
    Attenuated delegation is a requiremen= t, but that doesn't have to be done cryptographically.=C2=A0 Token exch= ange works just fine.=C2=A0 SPKI and zcap-ld are examples of the crypto app= roach, and we used token exchange in the system for HP.

    --------------
    Alan Karp


    On Tue, Mar 23, 202= 1 at 4:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan,=C2=A0

    Yes, but in that flow, the token relationship between AS-RS and AS= -RO is only secure if the tokens issued by AS-RS are cryptographically atte= nuable in the first place.=C2=A0

    Fabien

    On Mo= n, Mar 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin Richer <jricher@mit.edu> wrote:

    But with all that in = mind, I think the key here is going to be looking at what the inputs to the= AS are, and how those can be defined in an interoperable way for AS=E2=80= =99s that can accept them. I think there=E2=80=99s a lot of room for innova= tion and flexibility here that doesn=E2=80=99t break the trust model or cor= e use cases. If I have an AS-RS set that won=E2=80=99t accept my favorite f= lavor of policy engine inputs, then I can decide not to use that one. But t= his is a very different question than saying the RS itself needs to accept = my own AS =E2=80=94 and we can=E2=80=99t keep conflating these two models.<= /div>

    I agree.=C2=A0 The point of hav= ing an AS-RO is to allow RO to specify a policy for which of RO's acces= s tokens should be delegated under what conditions.=C2=A0 AS-RS should not = need to understand those policies.=C2=A0 The flow would be
      RO contacts AS-RS and gets one or more access tokens.
    • RO delegate= s one or more of those tokens, potentially sub-scoped, to AS-RO.
    • A = different user contacts AS-RO to get a potentially sub-scoped access token = from AS-RO.
    • That user presents the access token delegated by AS-RO = when invoking the resource.
    AS-RS only needs to ve= rify that the delegation chain is legitimate, e.g., no increase in scope, a= nd that it grants permission for the request being made.=C2=A0 AS-RS does n= ot need to understand the policy behind granting the delegation by AS-RO.

    --------------
    Alan Karp

    <= br>
    On Mon,= Mar 22, 2021 at 11:40 AM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    I think this sho= ws the problem with the terminology as it=E2=80=99s been applied in this co= nversation, which I=E2=80=99ve tried to shine light on before. What you and= others are calling the =E2=80=9CRS=E2=80=9D is really the =E2=80=9CAS and = RS working together=E2=80=9D =E2=80=94 everything to the right of the line.= When Denis had brought up =E2=80=9Celiminating the AS=E2=80=9D in another = thread, what he=E2=80=99d really done is labeled everything to the right of= the line as the =E2=80=9CRS=E2=80=9D. Of course, the irony here is that ev= erything to the right of the line used all be called the =E2=80=9CAS=E2=80= =9D or simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say belo= w, I don=E2=80=99t want the client to have visibility on what happens on th= at side.=C2=A0

    Note well: The Google+ logo labeled= =E2=80=9CIdP=E2=80=9D in the diagram is not the AS, as far as GNAP is conc= erned. It does not issue an access token that the RS will accept. The eleme= nts to the left of the line could be a lot of things, but they are NOT the = AS =E2=80=94 by definition. The client lives over on the left, but so do an= y external inputs to the AS. These could be policy inputs on behalf of the = RO, they could be presentation artifacts, they could be federated logins, t= hey could be the output of policy decisions. How the AS comes to trust thos= e things is up to the AS=E2=80=99s implementation. It=E2=80=99s something w= e can talk about, but ultimately GNAP won=E2=80=99t be in any position to d= ictate because in practice some AS=E2=80=99s are simply going to internaliz= e all policies and we will never successfully force those open.=C2=A0
    =

    But with all that in mind, I think the key here is goin= g to be looking at what the inputs to the AS are, and how those can be defi= ned in an interoperable way for AS=E2=80=99s that can accept them. I think = there=E2=80=99s a lot of room for innovation and flexibility here that does= n=E2=80=99t break the trust model or core use cases. If I have an AS-RS set= that won=E2=80=99t accept my favorite flavor of policy engine inputs, then= I can decide not to use that one. But this is a very different question th= an saying the RS itself needs to accept my own AS =E2=80=94 and we can=E2= =80=99t keep conflating these two models.

    So to me= , GNAP can support a Zero Trust Architecture by LEVERAGING the AS, not by s= ubsuming or eliminating it. It is in fact the AS, not the client and not th= e RS, that will request and consume the results of a privacy-preserving zer= o-trust policy query thing. Anything that happens downstream from that is o= f little concern to the zero-trust components because, as you point out, it= =E2=80=99s on the =E2=80=9Cother side=E2=80=9D of the line.=C2=A0

    I think we got this basic component model pretty right in O= Auth: the AS and RS and client working together. Where OAuth misses the mar= k is the assumption that the user has to log in to the AS through a webpage= and interact directly, thereby proving they=E2=80=99re the RO. It=E2=80=99= s this latter space where I think we can both push innovation and also addr= ess the important and compelling use cases like the ones you=E2=80=99re bri= nging.

    =C2=A0=E2=80=94 Justin

    On Mar 22, 2021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> = wrote:

    I'm sorry, Justin. As a Resource = Owner, I look at the RS trust boundary (the dotted line in the diagram) as = being the RS. I don't expect any visibility into what's going on on= the=C2=A0right.=C2=A0

    My problem with the framing you p= ropose is that requests are going to the RS (or the AS-RS) and I don't = want to share my policies with the AS-RS. I want to keep the RS and AS-RS a= s ignorant as possible.

    Adrian

    On Mon, Mar 22= , 2021 at 1:48 PM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    What you=E2=80=99re discu= ssing below, in terms of logging in to a site, is not approaching the RS. Y= ou are in fact approaching the client, and identifying both the AS and RS t= o the client. The client is a client of your identity in this model,= and the RS is part of the identity provider. It=E2=80=99s really important= that we don=E2=80=99t conflate the RS and client in this way as it leads t= o a lot of confusion downstream and a lot of broken trust boundaries.
    =

    With that model in mind, approaching the =E2=80=9CRS&qu= ot; and providing it your identity is really just a case of the =E2=80=9Cfe= derated login to AS=E2=80=9D pattern that we discussed on the WG call. The = user here approaches an RS, which has its own AS. To share things from this= RS, the RO has to authenticate to the RS=E2=80=99s AS. This particular AS = allows the RO to do so using an external identity =E2=80=94 in which case, = the AS is now a =E2=80=9Cclient=E2=80=9D of a separate, disconnected (but l= ayered) delegation. The ultimate client that eventually calls the RS down t= he way may or may not know about these layers.=C2=A0

    <PastedGraphic-1.p= ng>
    This same AS, which is closely tied to the RS and t= rusted by the RS, might also take in FIDO credentials, or DIDs, or any numb= er of other proof mechanisms. The output of this is an access token the RS = trusts, but the input is up to the AS. The RS is not what you=E2=80=99re lo= gging in to.

    =C2=A0=E2=80=94 Justin

    On Mar 22, 2021, at 1:28 PM, Adrian Gropper &l= t;agropper@healthurl.com> wrote:

    I too am in favor of avoiding c= onsolidation and correlation. Right now, when I approach a service provider= (RS) for the first time, I'm offered the opportunity to identify my pe= rsona as: email, sign-in with Google, Facebook, or Apple. I know there are = people who try to create one-off email addresses but that is mostly a waste= of time.=C2=A0

    So, along come FIDO2 and DID wallets to = the rescue. Now, in theory, I have a way to start out my RS relationship ps= eudonymously.=C2=A0

    When I want my resource to be = discovered or shared I will post that RS URL including my pseudonym. If I t= hen want to introduce a mediator=C2=A0in front of my AS or messaging servic= e=C2=A0endpoint, I have that option. If I want to keep requests away from t= he mediator, I would publish an encryption key along with my pseudonym.

    - Adrian


    On Mon, M= ar 22, 2021 at 9:55 AM Justin Richer <jricher@mit.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhk= arp@gmail.com> shared a talk about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-= gnap/gnap-core-protocol/issues/145#issuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --
    TXAuth 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
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.= ietf.org/mailman/listinfo/txauth
    --000000000000abda6b05be586dca-- From nobody Thu Mar 25 03:41:11 2021 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 D747C3A1D27 for ; Thu, 25 Mar 2021 03:41:10 -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 nv0wjivRUSRN for ; Thu, 25 Mar 2021 03:41:05 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 B28AA3A1D26 for ; Thu, 25 Mar 2021 03:41:05 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id e8so1416515iok.5 for ; Thu, 25 Mar 2021 03:41: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=sUESc7pL8ZXU1j3ysHyfSxtcksFrvT0Y8KEdo5TF6ek=; b=OisIJC60W31OtP+z3pfZFmZ/f9G3Be0MbWL0tHpEXDwBsbZ+xJnftxPmV64RlrXtEH S6I3E7/K43lm79jXxtGhm2YfXpIGGaRGXWFUy0Zmd/AcG3beUih+XkokJSdunS8ZSZe6 +bh2UTg0KYS+gOzw5GzcNVqvGXgtplo0olwMMauMb/TXUaQ2dntp5FsxOiaLDR1UHC2y USx2Dt9k0u9S113oK9Zg5XP9xbklvlAZwZbydM7q+RYI/0L/jMwGsu0tuD/KFwjQ5AQt faJ/XdAkHKcotTywJTTeMuAkgX0Sdol9ervTfjt1B+s/BowweAlgKdKDaNMdndqKYkdB PmXQ== 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=sUESc7pL8ZXU1j3ysHyfSxtcksFrvT0Y8KEdo5TF6ek=; b=qF5/34DaW165OH2NK67gLPj2i88TkSVP57bz22bVx+Bc86OTTAHvVmaSELHd7FE8F2 ly3rwtS/K7Bma+5cBL7vKvgbuQW9NpgYW4iuj0TUSA8StpmAElCsqKbY8KoTvFLouBd/ ELeRfxZRNMfwoeymOzz3bX+KJyNyy7FqP2K41xxafTo6gk+Uh38rIyB9RXBgzJdwgYvD alD3BlELvyj8f3sYKxK19+dwlituVxb8Y+jXGNqAxSwOdMu4KYq8xo/qwleIYyJYGrcn kRv1AtVp72PdCq2Cz1hdoOY+Oal7tSwvzvSWNj/uXXzy+EqApDEHd7D8CqKQv4TiRWaG sEZg== X-Gm-Message-State: AOAM533VRQkZYvFeYhdTziQIEyis5uNWwDITZhJ9CmTqLiMqhaPQClSv ENFxOIP5q8ePXe0BWPtEhNOYVEvL0T9ZsxaKmJI= X-Google-Smtp-Source: ABdhPJx7ktIXPCezmdwwfVEjNImhG9XP4Etns5+Ima+GS8ChQ5I6661wHOnUwdr0Cn5xJb6I8ayi+tI5F/RG3FEP8cI= X-Received: by 2002:a02:c6b4:: with SMTP id o20mr6929655jan.124.1616668863777; Thu, 25 Mar 2021 03:41:03 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> In-Reply-To: From: Fabien Imbault Date: Thu, 25 Mar 2021 11:40:52 +0100 Message-ID: To: Adrian Gropper Cc: Alan Karp , Benjamin Kaduk , GNAP Mailing List , Justin Richer , Mark Miller Content-Type: multipart/alternative; boundary="00000000000058511305be5a0dee" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 10:41:11 -0000 --00000000000058511305be5a0dee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To reframe it closer to GNAP: - AS =3D AS-RO, that's where you find the RO policies. The AS issues access tokens to the client. - the RO policies could be a) defined locally or b) in relationship with the RS There have been several ideas related to the AS-RS relationship b: b1) the RS issues capabilities (which can be further attenuated by the RO) b2) Adrian also discussed a DID based solution b3) there was also an alternative ACL proposal from Denis (+ preflight) Fabien On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault wrote: > Ok so I get you correctly: > - what matters is the RQ (could be a RO or a end-user or both : we don't > really care at a high-level, they're all treated as entities that make a > request) > - the policy is able to handle those different cases, based on its own > internal delegation protocol > - currently that requires AS-RS and AS-RO, but maybe it can be simplified > > To answer to Denis, here's what I understood: > - RO trusts AS-RS (and then handles its own policies within AS-RO) > - end-user trusts AS-RO (through its client) > > Could probably work but that's a fairly different model compared to OAuth= 2 > (and of today's GNAP), with different frontiers between the AS and the RS= . > > Please do not hesitate to correct me if I'm wrong. > > Fabien > > On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper > wrote: > >> I believe there are alternatives to having two kinds of ASs. The problem >> may be a side-effect of deciding to switch away form treating the RO as >> different from the RQ. That leads to downstream privacy issues. Our desi= re >> for architectural simplicity is admirable but that may have been a step = too >> far. >> >> There may also be solutions based on different types of tokens, as in >> different capabilities (tokens signed by the RS) vs. tokens signed by th= e >> AS. I=E2=80=99m not sure about that but Alan might have more to say. >> >> Adrian >> >> On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault >> wrote: >> >>> Thanks. The general problem statement is clear. >>> >>> The proposed solution a bit less (to me). I understood that from point >>> 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obvious reason t= o have >>> two types of ASs". Do you see an alternative ? >>> >>> Regarding the last item, I don't think that naming RQ by end-user >>> created the problem. It might just highlight the asymmetry, which >>> fundamentally exists. >>> >>> Fabien >>> >>> >>> On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper >>> wrote: >>> >>>> Recap: >>>> 1 - Justin (I think) introduced the idea of an AS on the RS trust >>>> boundary side. >>>> 2 - I said the RO should not have to share policies with the RS. >>>> 3 - Alan invented the concept of AS-RO and AS-RS to separate two kinds >>>> of PDPs. >>>> >>>> The thing is that step 2 is not symmetrical. The RO has a legitimate >>>> privacy interest in keeping their policies private and minimizing the >>>> leakage of information about requests that are posed against those >>>> policies. >>>> >>>> The RS, on the other hand, should be publishing its policies (e.g. wha= t >>>> it=E2=80=99s selling or what jurisdiction it=E2=80=99s in or what toke= ns or scopes it >>>> supports). The RS has no obvious privacy interest in GNAP. It=E2=80=99= s just an >>>> enforcer. >>>> >>>> There is one other privacy interest to consider around the RS and that >>>> is the requesting party (the end-user that is not the RO :-) might pre= fer >>>> to share attributes with the RS instead of the RO or something control= led >>>> by the RO. This case could be an =E2=80=9Cextension=E2=80=9D to GNAP a= nd might result in a >>>> split AS as a solution. This problem was introduced when the editors >>>> decided to replace RQ with end-user. Obviously, the RO end-user has no >>>> privacy interests relative to itself. >>>> >>>> Adrian >>>> >>>> >>>> >>>> >>>> On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> I was referring to "By my definition, this model has two ASs since >>>>> both are processing requests into tokens". If there's no reason to ha= ve 2 >>>>> types of ASs, that's fine then. >>>>> But I'm a bit lost in where we stand with the idea. >>>>> >>>>> Could you recap? >>>>> >>>>> Fabien >>>>> >>>>> Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper >>>>> a =C3=A9crit : >>>>> >>>>>> There=E2=80=99s no obvious reason to have two types of ASs. Any AS t= hat is >>>>>> executing the policies of the RS can look to GNAP like the RS itself= . Why >>>>>> would GNAP expose that interface to anyone? >>>>>> >>>>>> Adrian >>>>>> >>>>>> On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>>> Note : I'm not sure that's a good idea, but having 2 types of ASs i= s >>>>>>> not that easy to grasp. >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> a =C3=A9crit : >>>>>>> >>>>>>>> The purpose of either handling policies locally or delegating them >>>>>>>> to the RO agent. >>>>>>>> >>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper < >>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>> >>>>>>>>> What purpose would be served by GNAP splitting the AS into two >>>>>>>>> components? >>>>>>>>> >>>>>>>>> Adrian >>>>>>>>> >>>>>>>>> On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault < >>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Isn't the AS-RO a component of the AS? Same idea as the interact >>>>>>>>>> component, it functionnally belongs to the AS role but could be = deployed >>>>>>>>>> either as a monolith or as a separate component? >>>>>>>>>> >>>>>>>>>> Fabien >>>>>>>>>> >>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper < >>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>> >>>>>>>>>>> Yes, but I would say it=E2=80=99s not the RO that wants the acc= ess >>>>>>>>>>> token. It=E2=80=99s the RO that wants the client making the req= uest to get an >>>>>>>>>>> access token. >>>>>>>>>>> >>>>>>>>>>> Adrian >>>>>>>>>>> >>>>>>>>>>> On Wed, Mar 24, 2021 at 11:22 PM Alan Karp >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Adrian Gropper wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> In this design, the AS is the AS-RS and the agent is the >>>>>>>>>>>>> AS-RO. By my definition, this model has two ASs since both ar= e processing >>>>>>>>>>>>> requests into tokens. The problem with this is complexity and= privacy. The >>>>>>>>>>>>> RO may not want to share the request information with the AS-= RS. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> More precisely, RO has no choice but to present the required >>>>>>>>>>>> information to AS-RS if RO wants an access token. However, RO= does not >>>>>>>>>>>> want AS-RS to know the policy by which RO delegates tokens. T= hat's why RO >>>>>>>>>>>> uses AS-RO for those delegations. >>>>>>>>>>>> >>>>>>>>>>>> -------------- >>>>>>>>>>>> Alan Karp >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper < >>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Thank you for creating the issue. My definition of AS is >>>>>>>>>>>>> independent of AS-RO or AS-RS. >>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223= #issuecomment-806280421 >>>>>>>>>>>>> I also agree with Alan's definition based on delegation. An A= S-RS would be >>>>>>>>>>>>> a delegate of the RS. >>>>>>>>>>>>> >>>>>>>>>>>>> Based on that, I see it as obvious that the policy has to be >>>>>>>>>>>>> accessible (defined locally?) in order for it to be run as th= e code that >>>>>>>>>>>>> turns a request into an access token. >>>>>>>>>>>>> >>>>>>>>>>>>> The only other possibility is that the request is packaged by >>>>>>>>>>>>> the AS and sent elsewhere (an agent) for evaluation against p= olicy and a >>>>>>>>>>>>> proto-token returned. In that case the AS is acting as a prox= y and the PDP >>>>>>>>>>>>> is elsewhere. I can imagine that an AS-RS would behave this w= ay so that the >>>>>>>>>>>>> proto-token could be turned into an access token by the AS-RS= . Isn't this >>>>>>>>>>>>> what Justin is proposing? In this design, the AS is the AS-RS= and the agent >>>>>>>>>>>>> is the AS-RO. By my definition, this model has two ASs since = both are >>>>>>>>>>>>> processing requests into tokens. The problem with this is com= plexity and >>>>>>>>>>>>> privacy. The RO may not want to share the request information= with the >>>>>>>>>>>>> AS-RS. >>>>>>>>>>>>> >>>>>>>>>>>>> Adrian >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault < >>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Isn't that what the AS is supposed to be, only with the >>>>>>>>>>>>>> caveat that the policy is defined locally? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp >>>>>>>>>>>>>> a =C3=A9crit : >>>>>>>>>>>>>> >>>>>>>>>>>>>>> AS-RO is an AS that RO trusts to delegate RO's access token= s >>>>>>>>>>>>>>> according to RO's policies. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault < >>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Alan and Adrian, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I've created issue AS-RO policy delegation ( >>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/= 223) >>>>>>>>>>>>>>>> to capture your input. >>>>>>>>>>>>>>>> A first question that arises: can we give a definition to >>>>>>>>>>>>>>>> AS-RO? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp < >>>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Fabien Imbault wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Yes, but in that flow, the token relationship between >>>>>>>>>>>>>>>>>> AS-RS and AS-RO is only secure if the tokens issued by A= S-RS are >>>>>>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Attenuated delegation is a requirement, but that doesn't >>>>>>>>>>>>>>>>> have to be done cryptographically. Token exchange works = just fine. SPKI >>>>>>>>>>>>>>>>> and zcap-ld are examples of the crypto approach, and we u= sed token exchange >>>>>>>>>>>>>>>>> in the system for HP. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault < >>>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Yes, but in that flow, the token relationship between >>>>>>>>>>>>>>>>>> AS-RS and AS-RO is only secure if the tokens issued by A= S-RS are >>>>>>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp < >>>>>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Justin Richer wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> But with all that in mind, I think the key here is >>>>>>>>>>>>>>>>>>>> going to be looking at what the inputs to the AS are, = and how those can be >>>>>>>>>>>>>>>>>>>> defined in an interoperable way for AS=E2=80=99s that = can accept them. I think >>>>>>>>>>>>>>>>>>>> there=E2=80=99s a lot of room for innovation and flexi= bility here that doesn=E2=80=99t >>>>>>>>>>>>>>>>>>>> break the trust model or core use cases. If I have an = AS-RS set that won=E2=80=99t >>>>>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine inputs, the= n I can decide not to >>>>>>>>>>>>>>>>>>>> use that one. But this is a very different question th= an saying the RS >>>>>>>>>>>>>>>>>>>> itself needs to accept my own AS =E2=80=94 and we can= =E2=80=99t keep conflating these two >>>>>>>>>>>>>>>>>>>> models. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I agree. The point of having an AS-RO is to allow RO >>>>>>>>>>>>>>>>>>> to specify a policy for which of RO's access tokens sho= uld be delegated >>>>>>>>>>>>>>>>>>> under what conditions. AS-RS should not need to unders= tand those >>>>>>>>>>>>>>>>>>> policies. The flow would be >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> - RO contacts AS-RS and gets one or more access >>>>>>>>>>>>>>>>>>> tokens. >>>>>>>>>>>>>>>>>>> - RO delegates one or more of those tokens, >>>>>>>>>>>>>>>>>>> potentially sub-scoped, to AS-RO. >>>>>>>>>>>>>>>>>>> - A different user contacts AS-RO to get a >>>>>>>>>>>>>>>>>>> potentially sub-scoped access token from AS-RO. >>>>>>>>>>>>>>>>>>> - That user presents the access token delegated by >>>>>>>>>>>>>>>>>>> AS-RO when invoking the resource. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> AS-RS only needs to verify that the delegation chain is >>>>>>>>>>>>>>>>>>> legitimate, e.g., no increase in scope, and that it gra= nts permission for >>>>>>>>>>>>>>>>>>> the request being made. AS-RS does not need to underst= and the policy >>>>>>>>>>>>>>>>>>> behind granting the delegation by AS-RO. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer < >>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I think this shows the problem with the terminology as >>>>>>>>>>>>>>>>>>>> it=E2=80=99s been applied in this conversation, which = I=E2=80=99ve tried to shine light on >>>>>>>>>>>>>>>>>>>> before. What you and others are calling the =E2=80=9CR= S=E2=80=9D is really the =E2=80=9CAS and RS >>>>>>>>>>>>>>>>>>>> working together=E2=80=9D =E2=80=94 everything to the = right of the line. When Denis had >>>>>>>>>>>>>>>>>>>> brought up =E2=80=9Celiminating the AS=E2=80=9D in ano= ther thread, what he=E2=80=99d really done is >>>>>>>>>>>>>>>>>>>> labeled everything to the right of the line as the =E2= =80=9CRS=E2=80=9D. Of course, the >>>>>>>>>>>>>>>>>>>> irony here is that everything to the right of the line= used all be called >>>>>>>>>>>>>>>>>>>> the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2= =80=9D in the OAuth 1 days. As you say below, I don=E2=80=99t >>>>>>>>>>>>>>>>>>>> want the client to have visibility on what happens on = that side. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80= =9D in the >>>>>>>>>>>>>>>>>>>> diagram is not the AS, as far as GNAP is concerned. It= does not issue an >>>>>>>>>>>>>>>>>>>> access token that the RS will accept. The elements to = the left of the line >>>>>>>>>>>>>>>>>>>> could be a lot of things, but they are NOT the AS =E2= =80=94 by definition. The >>>>>>>>>>>>>>>>>>>> client lives over on the left, but so do any external = inputs to the AS. >>>>>>>>>>>>>>>>>>>> These could be policy inputs on behalf of the RO, they= could be >>>>>>>>>>>>>>>>>>>> presentation artifacts, they could be federated logins= , they could be the >>>>>>>>>>>>>>>>>>>> output of policy decisions. How the AS comes to trust = those things is up to >>>>>>>>>>>>>>>>>>>> the AS=E2=80=99s implementation. It=E2=80=99s somethin= g we can talk about, but ultimately >>>>>>>>>>>>>>>>>>>> GNAP won=E2=80=99t be in any position to dictate becau= se in practice some AS=E2=80=99s are >>>>>>>>>>>>>>>>>>>> simply going to internalize all policies and we will n= ever successfully >>>>>>>>>>>>>>>>>>>> force those open. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> But with all that in mind, I think the key here is >>>>>>>>>>>>>>>>>>>> going to be looking at what the inputs to the AS are, = and how those can be >>>>>>>>>>>>>>>>>>>> defined in an interoperable way for AS=E2=80=99s that = can accept them. I think >>>>>>>>>>>>>>>>>>>> there=E2=80=99s a lot of room for innovation and flexi= bility here that doesn=E2=80=99t >>>>>>>>>>>>>>>>>>>> break the trust model or core use cases. If I have an = AS-RS set that won=E2=80=99t >>>>>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine inputs, the= n I can decide not to >>>>>>>>>>>>>>>>>>>> use that one. But this is a very different question th= an saying the RS >>>>>>>>>>>>>>>>>>>> itself needs to accept my own AS =E2=80=94 and we can= =E2=80=99t keep conflating these two >>>>>>>>>>>>>>>>>>>> models. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> So to me, GNAP can support a Zero Trust Architecture b= y >>>>>>>>>>>>>>>>>>>> LEVERAGING the AS, not by subsuming or eliminating it.= It is in fact the >>>>>>>>>>>>>>>>>>>> AS, not the client and not the RS, that will request a= nd consume the >>>>>>>>>>>>>>>>>>>> results of a privacy-preserving zero-trust policy quer= y thing. Anything >>>>>>>>>>>>>>>>>>>> that happens downstream from that is of little concern= to the zero-trust >>>>>>>>>>>>>>>>>>>> components because, as you point out, it=E2=80=99s on = the =E2=80=9Cother side=E2=80=9D of the line. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I think we got this basic component model pretty right >>>>>>>>>>>>>>>>>>>> in OAuth: the AS and RS and client working together. W= here OAuth misses the >>>>>>>>>>>>>>>>>>>> mark is the assumption that the user has to log in to = the AS through a >>>>>>>>>>>>>>>>>>>> webpage and interact directly, thereby proving they=E2= =80=99re the RO. It=E2=80=99s this >>>>>>>>>>>>>>>>>>>> latter space where I think we can both push innovation= and also address the >>>>>>>>>>>>>>>>>>>> important and compelling use cases like the ones you= =E2=80=99re bringing. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper < >>>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I'm sorry, Justin. As a Resource Owner, I look at the >>>>>>>>>>>>>>>>>>>> RS trust boundary (the dotted line in the diagram) as = being the RS. I don't >>>>>>>>>>>>>>>>>>>> expect any visibility into what's going on on the righ= t. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> My problem with the framing you propose is that >>>>>>>>>>>>>>>>>>>> requests are going to the RS (or the AS-RS) and I don'= t want to share my >>>>>>>>>>>>>>>>>>>> policies with the AS-RS. I want to keep the RS and AS-= RS as ignorant as >>>>>>>>>>>>>>>>>>>> possible. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer < >>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> What you=E2=80=99re discussing below, in terms of log= ging in >>>>>>>>>>>>>>>>>>>>> to a site, is not approaching the RS. You are in fact= approaching the >>>>>>>>>>>>>>>>>>>>> client, and identifying both the AS and RS to the cli= ent. The client is a >>>>>>>>>>>>>>>>>>>>> client *of your identity* in this model, and the RS >>>>>>>>>>>>>>>>>>>>> is part of the identity provider. It=E2=80=99s really= important that we don=E2=80=99t >>>>>>>>>>>>>>>>>>>>> conflate the RS and client in this way as it leads to= a lot of confusion >>>>>>>>>>>>>>>>>>>>> downstream and a lot of broken trust boundaries. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> With that model in mind, approaching the =E2=80=9CRS"= and >>>>>>>>>>>>>>>>>>>>> providing it your identity is really just a case of t= he =E2=80=9Cfederated login to >>>>>>>>>>>>>>>>>>>>> AS=E2=80=9D pattern that we discussed on the WG call.= The user here approaches an >>>>>>>>>>>>>>>>>>>>> RS, which has its own AS. To share things from this R= S, the RO has to >>>>>>>>>>>>>>>>>>>>> authenticate to the RS=E2=80=99s AS. This particular = AS allows the RO to do so >>>>>>>>>>>>>>>>>>>>> using an external identity =E2=80=94 in which case, t= he AS is now a =E2=80=9Cclient=E2=80=9D of a >>>>>>>>>>>>>>>>>>>>> separate, disconnected (but layered) delegation. The = ultimate client that >>>>>>>>>>>>>>>>>>>>> eventually calls the RS down the way may or may not k= now about these >>>>>>>>>>>>>>>>>>>>> layers. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> This same AS, which is closely tied to the RS and >>>>>>>>>>>>>>>>>>>>> trusted by the RS, might also take in FIDO credential= s, or DIDs, or any >>>>>>>>>>>>>>>>>>>>> number of other proof mechanisms. The output of this = is an access token the >>>>>>>>>>>>>>>>>>>>> RS trusts, but the input is up to the AS. The RS is n= ot what you=E2=80=99re logging >>>>>>>>>>>>>>>>>>>>> in to. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper < >>>>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I too am in favor of avoiding consolidation and >>>>>>>>>>>>>>>>>>>>> correlation. Right now, when I approach a service pro= vider (RS) for the >>>>>>>>>>>>>>>>>>>>> first time, I'm offered the opportunity to identify m= y persona as: email, >>>>>>>>>>>>>>>>>>>>> sign-in with Google, Facebook, or Apple. I know there= are people who try to >>>>>>>>>>>>>>>>>>>>> create one-off email addresses but that is mostly a w= aste of time. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> So, along come FIDO2 and DID wallets to the rescue. >>>>>>>>>>>>>>>>>>>>> Now, in theory, I have a way to start out my RS relat= ionship >>>>>>>>>>>>>>>>>>>>> pseudonymously. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> When I want my resource to be discovered or shared I >>>>>>>>>>>>>>>>>>>>> will post that RS URL including my pseudonym. If I th= en want to introduce a >>>>>>>>>>>>>>>>>>>>> mediator in front of my AS or messaging service endpo= int, I have that >>>>>>>>>>>>>>>>>>>>> option. If I want to keep requests away from the medi= ator, I would publish >>>>>>>>>>>>>>>>>>>>> an encryption key along with my pseudonym. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> - Adrian >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer < >>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk < >>>>>>>>>>>>>>>>>>>>>> kaduk@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian >>>>>>>>>>>>>>>>>>>>>> Gropper wrote: >>>>>>>>>>>>>>>>>>>>>> >> @Alan Karp shared a talk >>>>>>>>>>>>>>>>>>>>>> about the Principle Of Least >>>>>>>>>>>>>>>>>>>>>> >> Authority (POLA) in a recent comment >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/i= ssues/145#issuecomment-803099693 >>>>>>>>>>>>>>>>>>>>>> >> I recommend it. >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> >> We might expect a protocol with authorization in >>>>>>>>>>>>>>>>>>>>>> the title to use authority >>>>>>>>>>>>>>>>>>>>>> >> as a core principle. I advocate for a GNAP design >>>>>>>>>>>>>>>>>>>>>> that maximizes the power >>>>>>>>>>>>>>>>>>>>>> >> of the RO, to be seen as a human rights issue whe= n >>>>>>>>>>>>>>>>>>>>>> the RO is a human. This >>>>>>>>>>>>>>>>>>>>>> >> causes me to ask how to combine better security >>>>>>>>>>>>>>>>>>>>>> with better human rights in >>>>>>>>>>>>>>>>>>>>>> >> GNAP. >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> >> Who should have the least authority in the GNAP >>>>>>>>>>>>>>>>>>>>>> design? >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> >> The AS derives authority as a delegate of the RO. >>>>>>>>>>>>>>>>>>>>>> If we ask the RO to >>>>>>>>>>>>>>>>>>>>>> >> partition limited authority across dozens of >>>>>>>>>>>>>>>>>>>>>> different ASs by domain and >>>>>>>>>>>>>>>>>>>>>> >> function, then we are not using technology to >>>>>>>>>>>>>>>>>>>>>> empower the individual. >>>>>>>>>>>>>>>>>>>>>> >> Probably the opposite, as we introduce consent >>>>>>>>>>>>>>>>>>>>>> fatigue and burden normal >>>>>>>>>>>>>>>>>>>>>> >> people to partition their lives into >>>>>>>>>>>>>>>>>>>>>> non-overlapping domains. >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> >> My experience says we should aim for one AS per >>>>>>>>>>>>>>>>>>>>>> persona because that maps >>>>>>>>>>>>>>>>>>>>>> >> into the way we manage our public and private >>>>>>>>>>>>>>>>>>>>>> identities. POLA would then >>>>>>>>>>>>>>>>>>>>>> >> teach care in keeping ASs and RSs related to work >>>>>>>>>>>>>>>>>>>>>> / public separate from >>>>>>>>>>>>>>>>>>>>>> >> ASs and RSs related to private life so that a >>>>>>>>>>>>>>>>>>>>>> policy vulnerability in our >>>>>>>>>>>>>>>>>>>>>> >> delegation to an AS would have the least >>>>>>>>>>>>>>>>>>>>>> likelihood of harm. >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > Thinking about how least authority/least privilege >>>>>>>>>>>>>>>>>>>>>> would apply to GNAP >>>>>>>>>>>>>>>>>>>>>> > seems like a useful exercise. I do want to point >>>>>>>>>>>>>>>>>>>>>> out some potential >>>>>>>>>>>>>>>>>>>>>> > pitfalls with one-AS-per-persona that we can also >>>>>>>>>>>>>>>>>>>>>> be aware of. If >>>>>>>>>>>>>>>>>>>>>> > one-AS-per-persona becomes one-persona-per-AS as >>>>>>>>>>>>>>>>>>>>>> well, then the AS's >>>>>>>>>>>>>>>>>>>>>> > identity in effect also serves as a persona >>>>>>>>>>>>>>>>>>>>>> identity and there are privacy >>>>>>>>>>>>>>>>>>>>>> > considerations to that. If, on the other hand, th= e >>>>>>>>>>>>>>>>>>>>>> > multiple-personas-per-AS (presumably corresponding >>>>>>>>>>>>>>>>>>>>>> to multiple humans) >>>>>>>>>>>>>>>>>>>>>> > route is taken, we should consider whether that >>>>>>>>>>>>>>>>>>>>>> would lead to various >>>>>>>>>>>>>>>>>>>>>> > (e.g., market) forces driving consolidation to jus= t >>>>>>>>>>>>>>>>>>>>>> a handful of >>>>>>>>>>>>>>>>>>>>>> > super-popular AS services. That topic is a curren= t >>>>>>>>>>>>>>>>>>>>>> matter of concern to >>>>>>>>>>>>>>>>>>>>>> > some IETF participants. >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Hi Ben, big +1 to this. This is something that we >>>>>>>>>>>>>>>>>>>>>> discussed ages ago in the UMA working group, and it= =E2=80=99s one of the biggest >>>>>>>>>>>>>>>>>>>>>> problems with the personal AS (and personal data sto= re) model. This kind of >>>>>>>>>>>>>>>>>>>>>> thing makes RS-first trust models really difficult i= n practice. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve g= ot software that >>>>>>>>>>>>>>>>>>>>>> wants to access my medical information. It calls an = RS and requests access, >>>>>>>>>>>>>>>>>>>>>> but it hasn=E2=80=99t been granted anything yet. Now= I as the RO have set up the RS >>>>>>>>>>>>>>>>>>>>>> so that it talks to my personal AS, that only I use.= In addition to the RS >>>>>>>>>>>>>>>>>>>>>> having to be able to figure out which medical record= s are being requested >>>>>>>>>>>>>>>>>>>>>> from the context of the unauthenticated request (whi= ch means it needs >>>>>>>>>>>>>>>>>>>>>> identifiers in the URL or something similar for the = RS to be able to tell, >>>>>>>>>>>>>>>>>>>>>> assuming that it protects data for more than one per= son). So this client >>>>>>>>>>>>>>>>>>>>>> software doesn=E2=80=99t know who I am and doesn=E2= =80=99t know my medical record >>>>>>>>>>>>>>>>>>>>>> information, makes a completely unauthorized request= to the RS, and the RS >>>>>>>>>>>>>>>>>>>>>> says =E2=80=9CGo to Justin=E2=80=99s personal AS to = get a token=E2=80=9D. The client can now make a >>>>>>>>>>>>>>>>>>>>>> direct correlation between the data that=E2=80=99s b= eing protected at the RS and >>>>>>>>>>>>>>>>>>>>>> the person running the AS that protects it. Importan= tly, this client makes >>>>>>>>>>>>>>>>>>>>>> this call with no prior relationship to the RS and n= o really auditable way >>>>>>>>>>>>>>>>>>>>>> to track it down after the fact. This is a design fe= ature in the good case, >>>>>>>>>>>>>>>>>>>>>> and terrifying in the bad case. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> If the RS instead says =E2=80=9Cwelcome to Medicine = Doctor >>>>>>>>>>>>>>>>>>>>>> RS, please talk to the Medicine Doctor AS to get acc= ess=E2=80=9D, we haven=E2=80=99t >>>>>>>>>>>>>>>>>>>>>> exposed anything at all. And from the perspective of= both the patient and >>>>>>>>>>>>>>>>>>>>>> the RS, this is more privacy-preserving, and it=E2= =80=99s really the least >>>>>>>>>>>>>>>>>>>>>> surprising option. Once the client gets to the AS, i= t can start a >>>>>>>>>>>>>>>>>>>>>> negotiation of figuring out who the RO is for the in= formation being >>>>>>>>>>>>>>>>>>>>>> accessed. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On top of this, the usability expectations of people >>>>>>>>>>>>>>>>>>>>>> managing their own AS, or set of AS=E2=80=99s for mu= ltiple personas to keep things >>>>>>>>>>>>>>>>>>>>>> separate, is a huge burden. Even in the tech communi= ty, I know people who >>>>>>>>>>>>>>>>>>>>>> can=E2=80=99t reliably manage more than one email ad= dress for different purposes. I >>>>>>>>>>>>>>>>>>>>>> wouldn=E2=80=99t expect my partner to do that =E2=80= =94 they have trouble enough balancing >>>>>>>>>>>>>>>>>>>>>> all the logins and sessions required for different k= ids remote schooling, I >>>>>>>>>>>>>>>>>>>>>> couldn=E2=80=99t imagine them having to understand a= ll the requirements for >>>>>>>>>>>>>>>>>>>>>> managing multiple authorization servers and associat= ed policies. I also >>>>>>>>>>>>>>>>>>>>>> don=E2=80=99t expect any person to =E2=80=9Cmanage k= eys=E2=80=9D =E2=80=94 I=E2=80=99ve been on the internet for >>>>>>>>>>>>>>>>>>>>>> decades and I can barely keep tabs on my GPG keys, a= nd only use them when I >>>>>>>>>>>>>>>>>>>>>> am forced to. This is exactly the kind of =E2=80=9Cm= arket pressure=E2=80=9D that I think >>>>>>>>>>>>>>>>>>>>>> Ben mentions above, people will just want to outsour= ce that to someone >>>>>>>>>>>>>>>>>>>>>> else, and the reality will be a few popular provider= s. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> In which case, we could end up doing a ton of work t= o >>>>>>>>>>>>>>>>>>>>>> allow an RS choice only to end up with a world where= the RS ends up making >>>>>>>>>>>>>>>>>>>>>> a limited choice anyway. We see how that plays out w= ith OpenID Connect =E2=80=94 >>>>>>>>>>>>>>>>>>>>>> RP=E2=80=99s could allow arbitrary IdPs but they cho= ose Google because it works and >>>>>>>>>>>>>>>>>>>>>> that=E2=80=99s where the users are. (And that=E2=80= =99s not to say anything of the >>>>>>>>>>>>>>>>>>>>>> proprietary OIDC-like protocols, but that=E2=80=99s = another discussion). >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> For further reading on these topics, I recommend bot= h >>>>>>>>>>>>>>>>>>>>>> =E2=80=9CWhy Johnny Can=E2=80=99t Encrypt=E2=80=9D a= nd =E2=80=9CWhy CSCW Systems Fail=E2=80=9D. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> So what does this have to do with GNAP? I think we >>>>>>>>>>>>>>>>>>>>>> can be clear-eyed on what kinds of expectations we h= ave for the >>>>>>>>>>>>>>>>>>>>>> participants. If we expect users (RO=E2=80=99s) to h= ave to set up the AS-RS >>>>>>>>>>>>>>>>>>>>>> relationship, or expect them to carry their AS, or m= anage their personal >>>>>>>>>>>>>>>>>>>>>> keys =E2=80=94 I think we=E2=80=99ve lost the battle= for relevance. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>> --00000000000058511305be5a0dee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    To reframe it closer to GNAP:
    - AS =3D AS-RO, that'= ;s where you find the RO policies. The AS issues access tokens to the clien= t.
    - the RO policies could be a) defined locally or b) in relatio= nship with the RS

    There have been several ideas re= lated to the AS-RS relationship b:
    b1) the RS issues capabili= ties (which can be further attenuated by the RO)
    b2) Adrian also = discussed a DID based solution
    b3) there was also an alternative = ACL proposal from Denis (+ preflight)

    Fabien
    =


    On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault <fabien.imbault@gmail= .com> wrote:
    Ok so I get you correctly:=C2=A0
    - what matters is= the RQ (could be a RO or a end-user or both : we don't really care at = a high-level, they're all treated as entities that make a request)
    - the policy is able to handle those different cases, based on its ow= n internal delegation protocol
    - currently that requires AS-RS an= d AS-RO, but maybe it can be simplified

    To answer = to Denis, here's what I understood:
    - RO trusts AS-RS (and th= en handles its own policies within AS-RO)
    - end-user trusts A= S-RO (through its client)

    Could probably work but = that's a fairly different model compared to OAuth2 (and of today's = GNAP), with different frontiers between the AS and the RS.=C2=A0
    =
    Please do not hesitate to correct me if I'm wrong.
    =

    Fabien=C2=A0

    =
    On Thu, Mar 25, 2021 at 9:26 AM Adria= n Gropper <a= gropper@healthurl.com> wrote:
    I believe there are alternatives to = having two kinds of ASs. The problem may be a side-effect of deciding to sw= itch away form treating the RO as different from the RQ. That leads to down= stream privacy issues. Our desire for architectural simplicity is admirable= but that may have been a step too far.

    There may also be solutions based on different types of tok= ens, as in different capabilities (tokens signed by the RS) vs. tokens sign= ed by the AS. I=E2=80=99m not sure about that but Alan might have more to s= ay.

    Adrian
    On Thu, M= ar 25, 2021 at 4:15 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thank= s. The general problem statement is clear.

    The=C2=A0prop= osed solution a bit less (to me). I understood that from point 2, Alan invo= lves 2 ASs. You said : "There=E2=80= =99s no obvious reason to have two types of ASs".=C2=A0Do you s= ee an alternative ?

    Regard= ing the last item, I don't think that naming RQ by end-user created the= problem. It might just highlight the asymmetry,=C2=A0which fundamentally e= xists.=C2=A0

    Fabien

    On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper <agropper@healthurl.com> w= rote:
    Recap:
    1 - Justin (I think) introduced the= idea of an AS on the RS trust boundary side.
    2 - I = said the RO should not have to share policies with the RS.
    3 - Alan invented the concept of AS-RO and AS-RS to separate two kin= ds of PDPs.=C2=A0

    The th= ing is that step 2 is not symmetrical. The RO has a legitimate privacy inte= rest in keeping their policies private and minimizing the leakage of inform= ation about requests that are posed against those policies.=C2=A0

    The RS, on the other hand, should= be publishing its policies (e.g. what it=E2=80=99s selling or what jurisdi= ction it=E2=80=99s in or what tokens or scopes it supports). The RS has no = obvious privacy interest in GNAP. It=E2=80=99s just an enforcer.

    There is one other privacy interes= t to consider around the RS and that is the requesting party (the end-user = that is not the RO :-) might prefer to share attributes with the RS instead= of the RO or something controlled by the RO. This case could be an =E2=80= =9Cextension=E2=80=9D to GNAP and might result in a split AS as a solution.= This problem was introduced when the editors decided to replace RQ with en= d-user. Obviously, the RO end-user has no privacy interests relative to its= elf.

    Adrian




    On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault <fabien.imbault@gmail.com> wro= te:
    I was referring to "= By my definition, this model has two ASs since both are processing requests= into tokens". If there's no reason to have 2 types of ASs, that&#= 39;s fine then.=C2=A0
    But I'm a bit lost in where we stand with the idea.=C2=A0

    Could you recap?=C2=A0

    Fabien=C2=A0

    Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper <agropper@healthurl.com> a = =C3=A9crit=C2=A0:
    There=E2=80=99s no obvious reason to have two types of = ASs. Any AS that is executing the policies of the RS can look to GNAP like = the RS itself. Why would GNAP expose that interface to anyone?=C2=A0
    <= div dir=3D"auto">
    Adrian

    On Thu, Mar 25, 202= 1 at 3:11 AM Fabien Imbault <fabien.imbault@gmail.com> wrot= e:
    Note : I'm not sure that's a good idea, but having 2 types of = ASs is not that easy to grasp.
    Fabien=C2=A0

    Le jeu. 25 mars 2021 =C3=A0 08:0= 7, Fabien Imbault <fabien.imbault@gmail.com> a =C3=A9crit= =C2=A0:
    The purpose of either handling policies locally or delegating the= m to the RO agent.=C2=A0

    Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper &= lt;agropper@healthurl.com> a =C3=A9crit=C2=A0:
    What= purpose would be served by GNAP splitting the AS into two components?

    Adrian=C2=A0

    On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Isn't th= e AS-RO a component of the AS? Same idea as the interact component, it func= tionnally belongs to the AS role but could be deployed either as a monolith= or as a separate component?

    <= /div>
    Fabien

    Le jeu. 25 mars 2021 =C3=A0 04:26, Adria= n Gropper <agropper@healthurl.com> a = =C3=A9crit=C2=A0:
    Yes, but I would say it=E2=80=99s not the RO that wants= the access token. It=E2=80=99s the RO that wants the client making the req= uest to get an access token.=C2=A0

    Adrian

    On Wed, Mar 24, 2021 at 11:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Adrian Gropper <agropper@healthurl.com> wrote:

    In this design, the AS is the AS-RS and the agent is t= he AS-RO. By my definition, this model has two ASs since both are processin= g requests into tokens. The problem with this is complexity and privacy. Th= e RO may not want to share the request information with the AS-RS.

    More precis= ely, RO has no choice but to present the required information to AS-RS if R= O wants an access token.=C2=A0 However, RO does not want AS-RS to know the = policy by which RO delegates tokens.=C2=A0 That's why RO uses AS-RO for= those delegations.

    --------------
    Alan Karp


    <= div dir=3D"ltr" class=3D"gmail_attr">On Wed, Mar 24, 2021 at 7:41 PM Adrian= Gropper <agropper@healthurl.com> wrote:

    = Based on that, I see it as obvious=C2=A0that the policy has to be accessibl= e (defined locally?) in order for it to be run as the code that turns a req= uest into an access token.=C2=A0

    The only other po= ssibility is that the request is packaged by the AS and sent elsewhere (an = agent) for evaluation against policy and a proto-token returned. In that ca= se the AS is acting as a proxy and the PDP is elsewhere. I can imagine that= an AS-RS would behave this way so that the proto-token could be turned int= o an access token by the AS-RS. Isn't this what Justin is proposing? In= this design, the AS is the AS-RS and the agent is the AS-RO. By my definit= ion, this model has two ASs since both are processing requests into tokens.= The problem with this is complexity and privacy. The RO may not want to sh= are the request information with the AS-RS.

    Adrian=

    On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Isn'= ;t that what the AS is supposed to be, only with the caveat that the policy= is defined locally?=C2=A0

    Fab= ien=C2=A0


    Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp <alanhkarp@gmail.com> a =C3=A9crit=C2=A0:
    AS-RO is an AS that RO trusts to delegate RO's access token= s according to RO's policies.=C2=A0=C2=A0

    --------------
    Alan Karp


    On Wed, Mar 24, 20= 21 at 9:36 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan and Adrian,
    <= br>
    I've created issue AS-RO policy delegation (https://= github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to capture your = input.=C2=A0
    A first question that arises: can we give a definiti= on to AS-RO?

    Thanks
    Fabien
    On Tue, = Mar 23, 2021 at 4:15 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Fabien Imbault &l= t;fabien.imbault@gmail.co= m> wrote:
    Hi Alan,=C2=A0

    Yes, but in that flow, = the token relationship between AS-RS and AS-RO is only secure if the tokens= issued by AS-RS are cryptographically attenuable in the first place.=C2=A0=
    =C2=A0
    Attenuated = delegation is a requirement, but that doesn't have to be done cryptogra= phically.=C2=A0 Token exchange works just fine.=C2=A0 SPKI and zcap-ld are = examples of the crypto approach, and we used token exchange in the system f= or HP.

    --------------
    Alan Karp


    On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    <= /div>
    Hi = Alan,=C2=A0

    Yes, but in that flow, the token relationshi= p between AS-RS and AS-RO is only secure if the tokens issued by AS-RS are = cryptographically attenuable in the first place.=C2=A0

    =
    Fabien

    On Mon, Mar 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin Richer <jricher@mit.edu> 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">

    B= ut with all that in mind, I think the key here is going to be looking at wh= at the inputs to the AS are, and how those can be defined in an interoperab= le way for AS=E2=80=99s that can accept them. I think there=E2=80=99s a lot= of room for innovation and flexibility here that doesn=E2=80=99t break the= trust model or core use cases. If I have an AS-RS set that won=E2=80=99t a= ccept my favorite flavor of policy engine inputs, then I can decide not to = use that one. But this is a very different question than saying the RS itse= lf needs to accept my own AS =E2=80=94 and we can=E2=80=99t keep conflating= these two models.

    I agree.=C2= =A0 The point of having an AS-RO is to allow RO to specify a policy for whi= ch of RO's access tokens should be delegated under what conditions.=C2= =A0 AS-RS should not need to understand those policies.=C2=A0 The flow woul= d be
    • RO contacts AS-RS and gets one or more access tokens= .
    • RO delegates one or more of those tokens, potentially sub-scoped,= to AS-RO.
    • A different user contacts AS-RO to get a potentially sub= -scoped access token from AS-RO.
    • That user presents the access toke= n delegated by AS-RO when invoking the resource.
    A= S-RS only needs to verify that the delegation chain is legitimate, e.g., no= increase in scope, and that it grants permission for the request being mad= e.=C2=A0 AS-RS does not need to understand the policy behind granting the d= elegation by AS-RO.

    --------------
    Alan Karp


    On Mon, Mar 22, 2021 at 11:40 AM Justin Richer <jricher@mit.edu> 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">
    Adrian,

    I think this shows the problem with the terminology as it=E2=80=99s b= een applied in this conversation, which I=E2=80=99ve tried to shine light o= n before. What you and others are calling the =E2=80=9CRS=E2=80=9D is reall= y the =E2=80=9CAS and RS working together=E2=80=9D =E2=80=94 everything to = the right of the line. When Denis had brought up =E2=80=9Celiminating the A= S=E2=80=9D in another thread, what he=E2=80=99d really done is labeled ever= ything to the right of the line as the =E2=80=9CRS=E2=80=9D. Of course, the= irony here is that everything to the right of the line used all be called = the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 = days. As you say below, I don=E2=80=99t want the client to have visibility = on what happens on that side.=C2=A0

    Note well: The= Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the diagram is not the AS, a= s far as GNAP is concerned. It does not issue an access token that the RS w= ill accept. The elements to the left of the line could be a lot of things, = but they are NOT the AS =E2=80=94 by definition. The client lives over on t= he left, but so do any external inputs to the AS. These could be policy inp= uts on behalf of the RO, they could be presentation artifacts, they could b= e federated logins, they could be the output of policy decisions. How the A= S comes to trust those things is up to the AS=E2=80=99s implementation. It= =E2=80=99s something we can talk about, but ultimately GNAP won=E2=80=99t b= e in any position to dictate because in practice some AS=E2=80=99s are simp= ly going to internalize all policies and we will never successfully force t= hose open.=C2=A0

    But with all that in mind, I thin= k the key here is going to be looking at what the inputs to the AS are, and= how those can be defined in an interoperable way for AS=E2=80=99s that can= accept them. I think there=E2=80=99s a lot of room for innovation and flex= ibility here that doesn=E2=80=99t break the trust model or core use cases. = If I have an AS-RS set that won=E2=80=99t accept my favorite flavor of poli= cy engine inputs, then I can decide not to use that one. But this is a very= different question than saying the RS itself needs to accept my own AS =E2= =80=94 and we can=E2=80=99t keep conflating these two models.
    So to me, GNAP can support a Zero Trust Architecture by LEVERAG= ING the AS, not by subsuming or eliminating it. It is in fact the AS, not t= he client and not the RS, that will request and consume the results of a pr= ivacy-preserving zero-trust policy query thing. Anything that happens downs= tream from that is of little concern to the zero-trust components because, = as you point out, it=E2=80=99s on the =E2=80=9Cother side=E2=80=9D of the l= ine.=C2=A0

    I think we got this basic component mod= el pretty right in OAuth: the AS and RS and client working together. Where = OAuth misses the mark is the assumption that the user has to log in to the = AS through a webpage and interact directly, thereby proving they=E2=80=99re= the RO. It=E2=80=99s this latter space where I think we can both push inno= vation and also address the important and compelling use cases like the one= s you=E2=80=99re bringing.

    =C2=A0=E2=80=94 Justin<= br>

    On Mar 22, 2021, at 2:14 PM, Adr= ian Gropper <agropper@he= althurl.com> wrote:

    I'm sorry, Ju= stin. As a Resource Owner, I look at the RS trust boundary (the dotted line= in the diagram) as being the RS. I don't expect any visibility into wh= at's going on on the=C2=A0right.=C2=A0

    My problem wi= th the framing you propose is that requests are going to the RS (or the AS-= RS) and I don't want to share my policies with the AS-RS. I want to kee= p the RS and AS-RS as ignorant as possible.

    Adrian=

    On Mon, Mar 22, 2021 at 1:48 PM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    What y= ou=E2=80=99re discussing below, in terms of logging in to a site, is not ap= proaching the RS. You are in fact approaching the client, and identifying b= oth the AS and RS to the client. The client is a client of your identity= in this model, and the RS is part of the identity provider. It=E2=80= =99s really important that we don=E2=80=99t conflate the RS and client in t= his way as it leads to a lot of confusion downstream and a lot of broken tr= ust boundaries.

    With that model in mind, approachi= ng the =E2=80=9CRS" and providing it your identity is really just a ca= se of the =E2=80=9Cfederated login to AS=E2=80=9D pattern that we discussed= on the WG call. The user here approaches an RS, which has its own AS. To s= hare things from this RS, the RO has to authenticate to the RS=E2=80=99s AS= . This particular AS allows the RO to do so using an external identity =E2= =80=94 in which case, the AS is now a =E2=80=9Cclient=E2=80=9D of a separat= e, disconnected (but layered) delegation. The ultimate client that eventual= ly calls the RS down the way may or may not know about these layers.=C2=A0<= /div>

    <PastedGraphic-1.png>
    <= div>This same AS, which is closely tied to the RS and trusted by the RS, mi= ght also take in FIDO credentials, or DIDs, or any number of other proof me= chanisms. The output of this is an access token the RS trusts, but the inpu= t is up to the AS. The RS is not what you=E2=80=99re logging in to.

    =C2=A0=E2=80=94 Justin

    On Mar 22, 2021, at 1:28 PM, Adrian Gropper <agropper@healthurl.com> wrote:
    I too am in favor of avoiding consolidation and cor= relation. Right now, when I approach a service provider (RS) for the first = time, I'm offered the opportunity to identify my persona as: email, sig= n-in with Google, Facebook, or Apple. I know there are people who try to cr= eate one-off email addresses but that is mostly a waste of time.=C2=A0
    =
    So, along come FIDO2 and DID wallets to the rescue. Now, in = theory, I have a way to start out my RS relationship pseudonymously.=C2=A0<= /div>

    When I want my resource to be discovered or shared= I will post that RS URL including my pseudonym. If I then want to introduc= e a mediator=C2=A0in front of my AS or messaging service=C2=A0endpoint, I h= ave that option. If I want to keep requests away from the mediator, I would= publish an encryption key along with my pseudonym.

    - Adrian



    On Mon, Mar 22, 2021 at 9:55 = AM Justin Richer <jricher@mit.e= du> wrote:
    kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhk= arp@gmail.com> shared a talk about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-= gnap/gnap-core-protocol/issues/145#issuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --
    TXAuth 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
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.= ietf.org/mailman/listinfo/txauth
    --00000000000058511305be5a0dee-- From nobody Thu Mar 25 05:46:09 2021 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 8865C3A203B for ; Thu, 25 Mar 2021 05:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 dujKhxmO5xTT for ; Thu, 25 Mar 2021 05:46:02 -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 BB4323A2035 for ; Thu, 25 Mar 2021 05:46:01 -0700 (PDT) Received: from [192.168.1.22] (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 12PCjts8013023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 25 Mar 2021 08:45:56 -0400 From: Justin Richer Message-Id: <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_5BD6AFF7-7CE2-4340-A9F8-4DD1B99A2432" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 25 Mar 2021 08:45:55 -0400 In-Reply-To: Cc: Adrian Gropper , Alan Karp , Benjamin Kaduk , GNAP Mailing List , Mark Miller To: Fabien Imbault References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 12:46:08 -0000 --Apple-Mail=_5BD6AFF7-7CE2-4340-A9F8-4DD1B99A2432 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The way I=E2=80=99m thinking about Adrian=E2=80=99s use case is that = what we=E2=80=99re calling the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an = =E2=80=9CAS=E2=80=9D in the traditional OAuth/GNAP sense, at least not = exactly. This is the agent that the RO can use to set policies and = manage consent on their behalf, and I=E2=80=99ve been arguing that it = fits better into this vaguely-defined =E2=80=9Cinteraction component=E2=80= =9D aspect of the current AS definition, and it=E2=80=99s not currently = separated from the AS definition. The =E2=80=9CAS-RS=E2=80=9D maps to = what we=E2=80=99d call the =E2=80=9CAS=E2=80=9D in OAuth/GNAP = traditionally, it=E2=80=99s what the RS trusts to issue tokens. In = traditional OAuth the AS-RO and AS-RS are always the same thing, from a = functional protocol perspective. An important point here is that from a = client=E2=80=99s perspective, they=E2=80=99re only talking to the AS-RS = since that=E2=80=99s where the client gets its tokens, because at the = end of the day the client just wants to call the API at the RS and = doesn=E2=80=99t care how that happens (from a protocol standpoint).=20 Note well: Even thought I don=E2=80=99t believe that =E2=80=9CAS-RO=E2=80=9D= is an authorization server at all, I=E2=80=99m going to keep using that = term below for consistency with previous discussion. So we have these fundamental relationships around getting the client to = access the RS: 1. RS trusts AS-RS to issue tokens that RS will accept, validate, and = process for requests from client 2. Client trusts AS-RS to issue tokens that client can use at RS 3. RO trusts RS to protect RO=E2=80=99s api through delegated access On top of that, we=E2=80=99ve got some additional aspects that we=E2=80=99= re discussing: 4. RO trusts AS-RO to manage RO=E2=80=99s policies at runtime 5. AS-RS trusts AS-RO to assert RO=E2=80=99s policies for access to RS 6. Client trusts whatever AS-RS sends client to deal with, including = possibly RO-AS at runtime, because of (2) What I have been saying is that 4/5/6 are optional details of how RS-AS = runs things, and I think this also maps with Adrian=E2=80=99s view of = choice, since if my RS=E2=80=99s AS-RS doesn=E2=80=99t allow me to plug = in my own AS-RO then I would be motivated to pick a different RS who=E2=80= =99s AS-RS lets me do just that. The same way I=E2=80=99d pick a = different RS if their surrounding services didn=E2=80=99t accept my = preferred federation login and I didn=E2=80=99t want to make another = account. Of course, market forces being as they are, I might not have = much of an actionable choice in RS, but GNAP can=E2=80=99t change that.=20= What we can do is make it possible for AS-RS to talk to AS-RO, both in = philosophy of the protocol design and in concrete hooks to support (6) = above.=20 Separately, we can approach the issue of making 1/2 above more dynamic. = This was UMA2=E2=80=99s =E2=80=9Cfederated authorization=E2=80=9D = approach, and is behind a lot of the =E2=80=9Cbring your own AS=E2=80=9D = models out there. The problem with these is that we know from many years = of experience that most RS=E2=80=99s aren=E2=80=99t interested in doing = anything of the sort. So with GNAP we can instead allow 4/5/6 to vary in a predictable and = consistent way, letting the RS keep control over 1/2, thereby enabling = choice in (3). We don=E2=80=99t have to be the ones who define the all = of the details of every permutation of (5) to enable this, though. Some = of this is going to be configuration out of band, some of it=E2=80=99s = going to be communication at runtime. This is where VC=E2=80=99s, ZCAPs, = CHAPI, DIDComm, FIDO, and a whole swath of other tech can come in and = help out. I don=E2=80=99t think we need to put all the details for using = these into core, nor do I think we=E2=80=99ll pull of The Great And = Ultimate Abstraction for using these and other approaches. But we can at = least start talking about =E2=80=9CAS-RS=E2=80=9D in such a way that it = no longer assumes it=E2=80=99s always the same party dealing with the RO = directly. =E2=80=94 Justin > On Mar 25, 2021, at 6:40 AM, Fabien Imbault = wrote: >=20 > To reframe it closer to GNAP: > - AS =3D AS-RO, that's where you find the RO policies. The AS issues = access tokens to the client. > - the RO policies could be a) defined locally or b) in relationship = with the RS >=20 > There have been several ideas related to the AS-RS relationship b: > b1) the RS issues capabilities (which can be further attenuated by the = RO) > b2) Adrian also discussed a DID based solution > b3) there was also an alternative ACL proposal from Denis (+ = preflight) >=20 > Fabien >=20 >=20 > On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault = > wrote: > Ok so I get you correctly:=20 > - what matters is the RQ (could be a RO or a end-user or both : we = don't really care at a high-level, they're all treated as entities that = make a request) > - the policy is able to handle those different cases, based on its own = internal delegation protocol > - currently that requires AS-RS and AS-RO, but maybe it can be = simplified >=20 > To answer to Denis, here's what I understood: > - RO trusts AS-RS (and then handles its own policies within AS-RO) > - end-user trusts AS-RO (through its client) >=20 > Could probably work but that's a fairly different model compared to = OAuth2 (and of today's GNAP), with different frontiers between the AS = and the RS.=20 >=20 > Please do not hesitate to correct me if I'm wrong. >=20 > Fabien=20 >=20 > On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper > wrote: > I believe there are alternatives to having two kinds of ASs. The = problem may be a side-effect of deciding to switch away form treating = the RO as different from the RQ. That leads to downstream privacy = issues. Our desire for architectural simplicity is admirable but that = may have been a step too far. >=20 > There may also be solutions based on different types of tokens, as in = different capabilities (tokens signed by the RS) vs. tokens signed by = the AS. I=E2=80=99m not sure about that but Alan might have more to say. >=20 > Adrian >=20 > On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault = > wrote: > Thanks. The general problem statement is clear. >=20 > The proposed solution a bit less (to me). I understood that from point = 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obvious reason to = have two types of ASs". Do you see an alternative ? >=20 > Regarding the last item, I don't think that naming RQ by end-user = created the problem. It might just highlight the asymmetry, which = fundamentally exists.=20 >=20 > Fabien >=20 >=20 > On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper > wrote: > Recap: > 1 - Justin (I think) introduced the idea of an AS on the RS trust = boundary side. > 2 - I said the RO should not have to share policies with the RS. > 3 - Alan invented the concept of AS-RO and AS-RS to separate two kinds = of PDPs.=20 >=20 > The thing is that step 2 is not symmetrical. The RO has a legitimate = privacy interest in keeping their policies private and minimizing the = leakage of information about requests that are posed against those = policies.=20 >=20 > The RS, on the other hand, should be publishing its policies (e.g. = what it=E2=80=99s selling or what jurisdiction it=E2=80=99s in or what = tokens or scopes it supports). The RS has no obvious privacy interest in = GNAP. It=E2=80=99s just an enforcer. >=20 > There is one other privacy interest to consider around the RS and that = is the requesting party (the end-user that is not the RO :-) might = prefer to share attributes with the RS instead of the RO or something = controlled by the RO. This case could be an =E2=80=9Cextension=E2=80=9D = to GNAP and might result in a split AS as a solution. This problem was = introduced when the editors decided to replace RQ with end-user. = Obviously, the RO end-user has no privacy interests relative to itself. >=20 > Adrian >=20 >=20 >=20 >=20 > On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault = > wrote: > I was referring to "By my definition, this model has two ASs since = both are processing requests into tokens". If there's no reason to have = 2 types of ASs, that's fine then.=20 > But I'm a bit lost in where we stand with the idea.=20 >=20 > Could you recap?=20 >=20 > Fabien=20 >=20 > Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper = > a =C3=A9crit : > There=E2=80=99s no obvious reason to have two types of ASs. Any AS = that is executing the policies of the RS can look to GNAP like the RS = itself. Why would GNAP expose that interface to anyone?=20 >=20 > Adrian >=20 > On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault = > wrote: > Note : I'm not sure that's a good idea, but having 2 types of ASs is = not that easy to grasp. >=20 > Fabien=20 >=20 > Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault = > a =C3=A9crit = : > The purpose of either handling policies locally or delegating them to = the RO agent.=20 >=20 > Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper = > a =C3=A9crit : > What purpose would be served by GNAP splitting the AS into two = components? >=20 > Adrian=20 >=20 > On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault = > wrote: > Isn't the AS-RO a component of the AS? Same idea as the interact = component, it functionnally belongs to the AS role but could be deployed = either as a monolith or as a separate component? >=20 > Fabien >=20 > Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper = > a =C3=A9crit : > Yes, but I would say it=E2=80=99s not the RO that wants the access = token. It=E2=80=99s the RO that wants the client making the request to = get an access token.=20 >=20 > Adrian >=20 > On Wed, Mar 24, 2021 at 11:22 PM Alan Karp > wrote: > Adrian Gropper > wrote: >=20 > In this design, the AS is the AS-RS and the agent is the AS-RO. By my = definition, this model has two ASs since both are processing requests = into tokens. The problem with this is complexity and privacy. The RO may = not want to share the request information with the AS-RS. >=20 > More precisely, RO has no choice but to present the required = information to AS-RS if RO wants an access token. However, RO does not = want AS-RS to know the policy by which RO delegates tokens. That's why = RO uses AS-RO for those delegations. >=20 > -------------- > Alan Karp >=20 >=20 > On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper > wrote: > Thank you for creating the issue. My definition of AS is independent = of AS-RO or AS-RS. = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomment= -806280421 = I also agree with Alan's definition based on delegation. An = AS-RS would be a delegate of the RS.=20 >=20 > Based on that, I see it as obvious that the policy has to be = accessible (defined locally?) in order for it to be run as the code that = turns a request into an access token.=20 >=20 > The only other possibility is that the request is packaged by the AS = and sent elsewhere (an agent) for evaluation against policy and a = proto-token returned. In that case the AS is acting as a proxy and the = PDP is elsewhere. I can imagine that an AS-RS would behave this way so = that the proto-token could be turned into an access token by the AS-RS. = Isn't this what Justin is proposing? In this design, the AS is the AS-RS = and the agent is the AS-RO. By my definition, this model has two ASs = since both are processing requests into tokens. The problem with this is = complexity and privacy. The RO may not want to share the request = information with the AS-RS. >=20 > Adrian >=20 > On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault = > wrote: > Isn't that what the AS is supposed to be, only with the caveat that = the policy is defined locally?=20 >=20 > Fabien=20 >=20 >=20 > Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp > a =C3=A9crit : > AS-RO is an AS that RO trusts to delegate RO's access tokens according = to RO's policies. =20 >=20 > -------------- > Alan Karp >=20 >=20 > On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault = > wrote: > Hi Alan and Adrian, >=20 > I've created issue AS-RO policy delegation = (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223 = ) to = capture your input.=20 > A first question that arises: can we give a definition to AS-RO? >=20 > Thanks > Fabien >=20 > On Tue, Mar 23, 2021 at 4:15 PM Alan Karp > wrote: > Fabien Imbault > wrote: > Hi Alan,=20 >=20 > Yes, but in that flow, the token relationship between AS-RS and AS-RO = is only secure if the tokens issued by AS-RS are cryptographically = attenuable in the first place.=20 > =20 > Attenuated delegation is a requirement, but that doesn't have to be = done cryptographically. Token exchange works just fine. SPKI and = zcap-ld are examples of the crypto approach, and we used token exchange = in the system for HP. >=20 > -------------- > Alan Karp >=20 >=20 > On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault = > wrote: > Hi Alan,=20 >=20 > Yes, but in that flow, the token relationship between AS-RS and AS-RO = is only secure if the tokens issued by AS-RS are cryptographically = attenuable in the first place.=20 >=20 > Fabien >=20 > On Mon, Mar 22, 2021 at 9:26 PM Alan Karp > wrote: > Justin Richer > wrote: >=20 > But with all that in mind, I think the key here is going to be looking = at what the inputs to the AS are, and how those can be defined in an = interoperable way for AS=E2=80=99s that can accept them. I think = there=E2=80=99s a lot of room for innovation and flexibility here that = doesn=E2=80=99t break the trust model or core use cases. If I have an = AS-RS set that won=E2=80=99t accept my favorite flavor of policy engine = inputs, then I can decide not to use that one. But this is a very = different question than saying the RS itself needs to accept my own AS = =E2=80=94 and we can=E2=80=99t keep conflating these two models. >=20 > I agree. The point of having an AS-RO is to allow RO to specify a = policy for which of RO's access tokens should be delegated under what = conditions. AS-RS should not need to understand those policies. The = flow would be > RO contacts AS-RS and gets one or more access tokens. > RO delegates one or more of those tokens, potentially sub-scoped, to = AS-RO. > A different user contacts AS-RO to get a potentially sub-scoped access = token from AS-RO. > That user presents the access token delegated by AS-RO when invoking = the resource. > AS-RS only needs to verify that the delegation chain is legitimate, = e.g., no increase in scope, and that it grants permission for the = request being made. AS-RS does not need to understand the policy behind = granting the delegation by AS-RO. >=20 > -------------- > Alan Karp >=20 >=20 > On Mon, Mar 22, 2021 at 11:40 AM Justin Richer > wrote: > Adrian, >=20 > I think this shows the problem with the terminology as it=E2=80=99s = been applied in this conversation, which I=E2=80=99ve tried to shine = light on before. What you and others are calling the =E2=80=9CRS=E2=80=9D = is really the =E2=80=9CAS and RS working together=E2=80=9D =E2=80=94 = everything to the right of the line. When Denis had brought up = =E2=80=9Celiminating the AS=E2=80=9D in another thread, what he=E2=80=99d = really done is labeled everything to the right of the line as the = =E2=80=9CRS=E2=80=9D. Of course, the irony here is that everything to = the right of the line used all be called the =E2=80=9CAS=E2=80=9D or = simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say below, I = don=E2=80=99t want the client to have visibility on what happens on that = side.=20 >=20 > Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the = diagram is not the AS, as far as GNAP is concerned. It does not issue an = access token that the RS will accept. The elements to the left of the = line could be a lot of things, but they are NOT the AS =E2=80=94 by = definition. The client lives over on the left, but so do any external = inputs to the AS. These could be policy inputs on behalf of the RO, they = could be presentation artifacts, they could be federated logins, they = could be the output of policy decisions. How the AS comes to trust those = things is up to the AS=E2=80=99s implementation. It=E2=80=99s something = we can talk about, but ultimately GNAP won=E2=80=99t be in any position = to dictate because in practice some AS=E2=80=99s are simply going to = internalize all policies and we will never successfully force those = open.=20 >=20 > But with all that in mind, I think the key here is going to be looking = at what the inputs to the AS are, and how those can be defined in an = interoperable way for AS=E2=80=99s that can accept them. I think = there=E2=80=99s a lot of room for innovation and flexibility here that = doesn=E2=80=99t break the trust model or core use cases. If I have an = AS-RS set that won=E2=80=99t accept my favorite flavor of policy engine = inputs, then I can decide not to use that one. But this is a very = different question than saying the RS itself needs to accept my own AS = =E2=80=94 and we can=E2=80=99t keep conflating these two models. >=20 > So to me, GNAP can support a Zero Trust Architecture by LEVERAGING the = AS, not by subsuming or eliminating it. It is in fact the AS, not the = client and not the RS, that will request and consume the results of a = privacy-preserving zero-trust policy query thing. Anything that happens = downstream from that is of little concern to the zero-trust components = because, as you point out, it=E2=80=99s on the =E2=80=9Cother side=E2=80=9D= of the line.=20 >=20 > I think we got this basic component model pretty right in OAuth: the = AS and RS and client working together. Where OAuth misses the mark is = the assumption that the user has to log in to the AS through a webpage = and interact directly, thereby proving they=E2=80=99re the RO. It=E2=80=99= s this latter space where I think we can both push innovation and also = address the important and compelling use cases like the ones you=E2=80=99r= e bringing. >=20 > =E2=80=94 Justin >=20 >> On Mar 22, 2021, at 2:14 PM, Adrian Gropper > wrote: >>=20 >> I'm sorry, Justin. As a Resource Owner, I look at the RS trust = boundary (the dotted line in the diagram) as being the RS. I don't = expect any visibility into what's going on on the right.=20 >>=20 >> My problem with the framing you propose is that requests are going to = the RS (or the AS-RS) and I don't want to share my policies with the = AS-RS. I want to keep the RS and AS-RS as ignorant as possible. >>=20 >> Adrian >>=20 >> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer > wrote: >> Adrian, >>=20 >> What you=E2=80=99re discussing below, in terms of logging in to a = site, is not approaching the RS. You are in fact approaching the client, = and identifying both the AS and RS to the client. The client is a client = of your identity in this model, and the RS is part of the identity = provider. It=E2=80=99s really important that we don=E2=80=99t conflate = the RS and client in this way as it leads to a lot of confusion = downstream and a lot of broken trust boundaries. >>=20 >> With that model in mind, approaching the =E2=80=9CRS" and providing = it your identity is really just a case of the =E2=80=9Cfederated login = to AS=E2=80=9D pattern that we discussed on the WG call. The user here = approaches an RS, which has its own AS. To share things from this RS, = the RO has to authenticate to the RS=E2=80=99s AS. This particular AS = allows the RO to do so using an external identity =E2=80=94 in which = case, the AS is now a =E2=80=9Cclient=E2=80=9D of a separate, = disconnected (but layered) delegation. The ultimate client that = eventually calls the RS down the way may or may not know about these = layers.=20 >>=20 >> >> This same AS, which is closely tied to the RS and trusted by the RS, = might also take in FIDO credentials, or DIDs, or any number of other = proof mechanisms. The output of this is an access token the RS trusts, = but the input is up to the AS. The RS is not what you=E2=80=99re logging = in to. >>=20 >> =E2=80=94 Justin >>=20 >>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper > wrote: >>>=20 >>> I too am in favor of avoiding consolidation and correlation. Right = now, when I approach a service provider (RS) for the first time, I'm = offered the opportunity to identify my persona as: email, sign-in with = Google, Facebook, or Apple. I know there are people who try to create = one-off email addresses but that is mostly a waste of time.=20 >>>=20 >>> So, along come FIDO2 and DID wallets to the rescue. Now, in theory, = I have a way to start out my RS relationship pseudonymously.=20 >>>=20 >>> When I want my resource to be discovered or shared I will post that = RS URL including my pseudonym. If I then want to introduce a mediator in = front of my AS or messaging service endpoint, I have that option. If I = want to keep requests away from the mediator, I would publish an = encryption key along with my pseudonym. >>>=20 >>> - Adrian >>>=20 >>>=20 >>>=20 >>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer > wrote: >>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk > wrote: >>> >=20 >>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote: >>> >> @Alan Karp > = shared a talk about the Principle Of Least >>> >> Authority (POLA) in a recent comment >>> >> = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment= -803099693 = >>> >> I recommend it. >>> >>=20 >>> >> We might expect a protocol with authorization in the title to use = authority >>> >> as a core principle. I advocate for a GNAP design that maximizes = the power >>> >> of the RO, to be seen as a human rights issue when the RO is a = human. This >>> >> causes me to ask how to combine better security with better human = rights in >>> >> GNAP. >>> >>=20 >>> >> Who should have the least authority in the GNAP design? >>> >>=20 >>> >> The AS derives authority as a delegate of the RO. If we ask the = RO to >>> >> partition limited authority across dozens of different ASs by = domain and >>> >> function, then we are not using technology to empower the = individual. >>> >> Probably the opposite, as we introduce consent fatigue and burden = normal >>> >> people to partition their lives into non-overlapping domains. >>> >>=20 >>> >> My experience says we should aim for one AS per persona because = that maps >>> >> into the way we manage our public and private identities. POLA = would then >>> >> teach care in keeping ASs and RSs related to work / public = separate from >>> >> ASs and RSs related to private life so that a policy = vulnerability in our >>> >> delegation to an AS would have the least likelihood of harm. >>> >=20 >>> > Thinking about how least authority/least privilege would apply to = GNAP >>> > seems like a useful exercise. I do want to point out some = potential >>> > pitfalls with one-AS-per-persona that we can also be aware of. If >>> > one-AS-per-persona becomes one-persona-per-AS as well, then the = AS's >>> > identity in effect also serves as a persona identity and there are = privacy >>> > considerations to that. If, on the other hand, the >>> > multiple-personas-per-AS (presumably corresponding to multiple = humans) >>> > route is taken, we should consider whether that would lead to = various >>> > (e.g., market) forces driving consolidation to just a handful of >>> > super-popular AS services. That topic is a current matter of = concern to >>> > some IETF participants. >>> >=20 >>>=20 >>> Hi Ben, big +1 to this. This is something that we discussed ages ago = in the UMA working group, and it=E2=80=99s one of the biggest problems = with the personal AS (and personal data store) model. This kind of thing = makes RS-first trust models really difficult in practice. >>>=20 >>> As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that = wants to access my medical information. It calls an RS and requests = access, but it hasn=E2=80=99t been granted anything yet. Now I as the RO = have set up the RS so that it talks to my personal AS, that only I use. = In addition to the RS having to be able to figure out which medical = records are being requested from the context of the unauthenticated = request (which means it needs identifiers in the URL or something = similar for the RS to be able to tell, assuming that it protects data = for more than one person). So this client software doesn=E2=80=99t know = who I am and doesn=E2=80=99t know my medical record information, makes a = completely unauthorized request to the RS, and the RS says =E2=80=9CGo = to Justin=E2=80=99s personal AS to get a token=E2=80=9D. The client can = now make a direct correlation between the data that=E2=80=99s being = protected at the RS and the person running the AS that protects it. = Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This = is a design feature in the good case, and terrifying in the bad case. >>>=20 >>> If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, = please talk to the Medicine Doctor AS to get access=E2=80=9D, we = haven=E2=80=99t exposed anything at all. And from the perspective of = both the patient and the RS, this is more privacy-preserving, and it=E2=80= =99s really the least surprising option. Once the client gets to the AS, = it can start a negotiation of figuring out who the RO is for the = information being accessed. >>>=20 >>> On top of this, the usability expectations of people managing their = own AS, or set of AS=E2=80=99s for multiple personas to keep things = separate, is a huge burden. Even in the tech community, I know people = who can=E2=80=99t reliably manage more than one email address for = different purposes. I wouldn=E2=80=99t expect my partner to do that =E2=80= =94 they have trouble enough balancing all the logins and sessions = required for different kids remote schooling, I couldn=E2=80=99t imagine = them having to understand all the requirements for managing multiple = authorization servers and associated policies. I also don=E2=80=99t = expect any person to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve = been on the internet for decades and I can barely keep tabs on my GPG = keys, and only use them when I am forced to. This is exactly the kind of = =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions above, = people will just want to outsource that to someone else, and the reality = will be a few popular providers. >>>=20 >>> In which case, we could end up doing a ton of work to allow an RS = choice only to end up with a world where the RS ends up making a limited = choice anyway. We see how that plays out with OpenID Connect =E2=80=94 = RP=E2=80=99s could allow arbitrary IdPs but they choose Google because = it works and that=E2=80=99s where the users are. (And that=E2=80=99s not = to say anything of the proprietary OIDC-like protocols, but that=E2=80=99s= another discussion). >>>=20 >>> For further reading on these topics, I recommend both =E2=80=9CWhy = Johnny Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems = Fail=E2=80=9D. >>>=20 >>> So what does this have to do with GNAP? I think we can be clear-eyed = on what kinds of expectations we have for the participants. If we expect = users (RO=E2=80=99s) to have to set up the AS-RS relationship, or expect = them to carry their AS, or manage their personal keys =E2=80=94 I think = we=E2=80=99ve lost the battle for relevance. >>>=20 >>> =E2=80=94 Justin >>=20 >=20 > --=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 = > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_5BD6AFF7-7CE2-4340-A9F8-4DD1B99A2432 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = way I=E2=80=99m thinking about Adrian=E2=80=99s use case is that what = we=E2=80=99re calling the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an = =E2=80=9CAS=E2=80=9D in the traditional OAuth/GNAP sense, at least not = exactly. This is the agent that the RO can use to set policies and = manage consent on their behalf, and I=E2=80=99ve been arguing that it = fits better into this vaguely-defined =E2=80=9Cinteraction component=E2=80= =9D aspect of the current AS definition, and it=E2=80=99s not currently = separated from the AS definition. The =E2=80=9CAS-RS=E2=80=9D maps to = what we=E2=80=99d call the =E2=80=9CAS=E2=80=9D in OAuth/GNAP = traditionally, it=E2=80=99s what the RS trusts to issue tokens. In = traditional OAuth the AS-RO and AS-RS are always the same thing, from a = functional protocol perspective. An important point here is that from a = client=E2=80=99s perspective, they=E2=80=99re only talking to the AS-RS = since that=E2=80=99s where the client gets its tokens, because at the = end of the day the client just wants to call the API at the RS and = doesn=E2=80=99t care how that happens (from a protocol = standpoint). 

    Note well: Even thought I don=E2=80=99t believe that = =E2=80=9CAS-RO=E2=80=9D is an authorization server at all, I=E2=80=99m = going to keep using that term below for consistency with previous = discussion.

    So = we have these fundamental relationships around getting the client to = access the RS:

    1. RS trusts AS-RS to issue tokens that RS will = accept, validate, and process for requests from client
    2. Client trusts AS-RS to issue tokens that client = can use at RS
    3. RO trusts RS to protect RO=E2=80=99s= api through delegated access

    On top of that, we=E2=80=99ve got some = additional aspects that we=E2=80=99re discussing:
    4. RO trusts AS-RO to manage = RO=E2=80=99s policies at runtime
    5. AS-RS trusts AS-RO to assert RO=E2=80=99= s policies for access to RS
    6. Client trusts = whatever AS-RS sends client to deal with, including possibly = RO-AS at runtime, because of (2)

    What I have been saying is that 4/5/6 = are optional details of how RS-AS runs things, and I think this also = maps with Adrian=E2=80=99s view of choice, since if my RS=E2=80=99s = AS-RS doesn=E2=80=99t allow me to plug in my own AS-RO then I would be = motivated to pick a different RS who=E2=80=99s AS-RS lets me do just = that. The same way I=E2=80=99d pick a different RS if their surrounding = services didn=E2=80=99t accept my preferred federation login and I = didn=E2=80=99t want to make another account. Of course, market forces = being as they are, I might not have much of an actionable choice in RS, = but GNAP can=E2=80=99t change that. 

    What we can do is make it possible for = AS-RS to talk to AS-RO, both in philosophy of the protocol design and in = concrete hooks to support (6) above. 

    Separately, we can approach the issue = of making 1/2 above more dynamic. This was UMA2=E2=80=99s =E2=80=9Cfederat= ed authorization=E2=80=9D approach, and is behind a lot of the =E2=80=9Cbr= ing your own AS=E2=80=9D models out there. The problem with these is = that we know from many years of experience that most RS=E2=80=99s = aren=E2=80=99t interested in doing anything of the sort.

    So with GNAP we can = instead allow 4/5/6 to vary in a predictable and consistent way, letting = the RS keep control over 1/2, thereby enabling choice in (3). We don=E2=80= =99t have to be the ones who define the all of the details of every = permutation of (5) to enable this, though. Some of this is going to be = configuration out of band, some of it=E2=80=99s going to be = communication at runtime. This is where VC=E2=80=99s, ZCAPs, CHAPI, = DIDComm, FIDO, and a whole swath of other tech can come in and help out. = I don=E2=80=99t think we need to put all the details for using these = into core, nor do I think we=E2=80=99ll pull of The Great And Ultimate = Abstraction for using these and other approaches. But we can at least = start talking about =E2=80=9CAS-RS=E2=80=9D in such a way that it no = longer assumes it=E2=80=99s always the same party dealing with the RO = directly.

     =E2=80=94 Justin

    On Mar = 25, 2021, at 6:40 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    To reframe it closer to GNAP:
    - AS =3D AS-RO, that's where you find the RO policies. The AS = issues access tokens to the client.
    - the RO = policies could be a) defined locally or b) in relationship with the = RS

    There have = been several ideas related to the AS-RS relationship b:
    b1) the RS issues capabilities (which = can be further attenuated by the RO)
    b2) Adrian = also discussed a DID based solution
    b3) there was = also an alternative ACL proposal from Denis (+ preflight)

    Fabien


    On Thu, Mar = 25, 2021 at 9:44 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Ok so I = get you correctly: 
    - what matters is the RQ (could = be a RO or a end-user or both : we don't really care at a high-level, = they're all treated as entities that make a request)
    - the policy is able to handle those different cases, based = on its own internal delegation protocol
    - currently = that requires AS-RS and AS-RO, but maybe it can be simplified

    To answer to Denis, = here's what I understood:
    - RO trusts AS-RS (and = then handles its own policies within AS-RO)
    - end-user trusts AS-RO (through its client)

    Could probably work but = that's a fairly different model compared to OAuth2 (and of today's = GNAP), with different frontiers between the AS and the = RS. 

    Please= do not hesitate to correct me if I'm wrong.

    Fabien 

    On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper = <agropper@healthurl.com> wrote:
    I = believe there are alternatives to having two kinds of ASs. The problem = may be a side-effect of deciding to switch away form treating the RO as = different from the RQ. That leads to downstream privacy issues. Our = desire for architectural simplicity is admirable but that may have been = a step too far.

    There may also be = solutions based on different types of tokens, as in different = capabilities (tokens signed by the RS) vs. tokens signed by the AS. = I=E2=80=99m not sure about that but Alan might have more to = say.

    Adrian

    On Thu, Mar = 25, 2021 at 4:15 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks. = The general problem statement is clear.

    The proposed solution a bit less = (to me). I understood that from point 2, Alan involves 2 ASs. You said : = "There=E2=80=99s no = obvious reason to have two types of ASs". Do you see an = alternative ?

    Regarding the last item, I don't think that = naming RQ by end-user created the problem. It might just highlight the = asymmetry, which fundamentally exists. 

    Fabien


    On Thu, Mar 25, 2021 at 8:48 AM Adrian = Gropper <agropper@healthurl.com> wrote:
    Recap:
    1 - Justin (I think) = introduced the idea of an AS on the RS trust boundary side.
    2 - I said the RO should not have to share = policies with the RS.
    3 - Alan = invented the concept of AS-RO and AS-RS to separate two kinds of = PDPs. 

    The thing is that step 2 is not symmetrical. The = RO has a legitimate privacy interest in keeping their policies private = and minimizing the leakage of information about requests that are posed = against those policies. 

    The RS, on the other hand, = should be publishing its policies (e.g. what it=E2=80=99s selling or = what jurisdiction it=E2=80=99s in or what tokens or scopes it supports). = The RS has no obvious privacy interest in GNAP. It=E2=80=99s just an = enforcer.

    There is one other privacy interest to consider = around the RS and that is the requesting party (the end-user that is not = the RO :-) might prefer to share attributes with the RS instead of the = RO or something controlled by the RO. This case could be an = =E2=80=9Cextension=E2=80=9D to GNAP and might result in a split AS as a = solution. This problem was introduced when the editors decided to = replace RQ with end-user. Obviously, the RO end-user has no privacy = interests relative to itself.

    Adrian




    On Thu, Mar = 25, 2021 at 3:24 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    I was referring to "By my definition, this model has two ASs since both are = processing requests into tokens". If there's no reason to have 2 types = of ASs, that's fine then. 
    But I'm a bit lost in = where we stand with the idea. 

    Could you = recap? 

    Fabien 

    Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper = <agropper@healthurl.com> a =C3=A9crit :
    There=E2=80= =99s no obvious reason to have two types of ASs. Any AS that is = executing the policies of the RS can look to GNAP like the RS itself. = Why would GNAP expose that interface to anyone? 

    Adrian

    On Thu, Mar = 25, 2021 at 3:11 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Note : = I'm not sure that's a good idea, but having 2 types of ASs is not that = easy to grasp.

    Fabien 

    Le jeu. 25 = mars 2021 =C3=A0 08:07, Fabien Imbault <fabien.imbault@gmail.com> a = =C3=A9crit :
    The = purpose of either handling policies locally or delegating them to the RO = agent. 

    Le jeu. 25 mars 2021 =C3=A0 08:04, = Adrian Gropper <agropper@healthurl.com> a =C3=A9crit :
    What = purpose would be served by GNAP splitting the AS into two = components?

    Adrian 
    On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Isn't = the AS-RO a component of the AS? Same idea as the interact component, it = functionnally belongs to the AS role but could be deployed either as a = monolith or as a separate component?

    Fabien

    Le jeu. 25 = mars 2021 =C3=A0 04:26, Adrian Gropper <agropper@healthurl.com> = a =C3=A9crit :
    Yes, but = I would say it=E2=80=99s not the RO that wants the access token. It=E2=80=99= s the RO that wants the client making the request to get an access = token. 

    Adrian

    On Wed, Mar = 24, 2021 at 11:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Adrian = Gropper <agropper@healthurl.com> wrote:

    In this = design, the AS is the AS-RS and the agent is the AS-RO. By my = definition, this model has two ASs since both are processing requests = into tokens. The problem with this is complexity and privacy. The RO may = not want to share the request information with the AS-RS.

    More precisely, RO has = no choice but to present the required information to AS-RS if RO wants = an access token.  However, RO does not want AS-RS to know the = policy by which RO delegates tokens.  That's why RO uses AS-RO for = those delegations.

    --------------
    Alan Karp


    On Wed, Mar = 24, 2021 at 7:41 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Thank you for creating the issue. My definition = of AS is independent of AS-RO or AS-RS. https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#i= ssuecomment-806280421 I also agree with Alan's definition based on = delegation. An AS-RS would be a delegate of the RS. 

    Based on = that, I see it as obvious that the policy has to be accessible = (defined locally?) in order for it to be run as the code that turns a = request into an access token. 

    The only other possibility is that the = request is packaged by the AS and sent elsewhere (an agent) for = evaluation against policy and a proto-token returned. In that case the = AS is acting as a proxy and the PDP is elsewhere. I can imagine that an = AS-RS would behave this way so that the proto-token could be turned into = an access token by the AS-RS. Isn't this what Justin is proposing? In = this design, the AS is the AS-RS and the agent is the AS-RO. By my = definition, this model has two ASs since both are processing requests = into tokens. The problem with this is complexity and privacy. The RO may = not want to share the request information with the AS-RS.

    Adrian

    On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Isn't that what the AS is supposed to be, only with the = caveat that the policy is defined locally? 

    Fabien 


    Le mer. 24 = mars 2021 =C3=A0 20:17, Alan Karp <alanhkarp@gmail.com> a =C3=A9crit :
    AS-RO is an AS that RO trusts to delegate RO's = access tokens according to RO's policies.  

    --------------
    Alan Karp


    On Wed, Mar 24, 2021 at 9:36 AM Fabien = Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan = and Adrian,

    I've = created issue AS-RO policy delegation (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to capture your input. 
    A first question = that arises: can we give a definition to AS-RO?

    Thanks
    Fabien

    On Tue, Mar = 23, 2021 at 4:15 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi = Alan, 

    Yes, but = in that flow, the token relationship between AS-RS and AS-RO is only = secure if the tokens issued by AS-RS are cryptographically attenuable in = the first place. 
     
    Attenuated delegation is a requirement, but that doesn't have = to be done cryptographically.  Token exchange works just = fine.  SPKI and zcap-ld are examples of the crypto approach, and we = used token exchange in the system for HP.

    --------------
    Alan = Karp


    On Tue, Mar = 23, 2021 at 4:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi = Alan, 

    Yes, but = in that flow, the token relationship between AS-RS and AS-RO is only = secure if the tokens issued by AS-RS are cryptographically attenuable in = the first place. 

    Fabien

    On Mon, Mar = 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin = Richer <jricher@mit.edu> wrote:

    But with all that in = mind, I think the key here is going to be looking at what the inputs to = the AS are, and how those can be defined in an interoperable way for = AS=E2=80=99s that can accept them. I think there=E2=80=99s a lot of room = for innovation and flexibility here that doesn=E2=80=99t break the trust = model or core use cases. If I have an AS-RS set that won=E2=80=99t = accept my favorite flavor of policy engine inputs, then I can decide not = to use that one. But this is a very different question than saying the = RS itself needs to accept my own AS =E2=80=94 and we can=E2=80=99t keep = conflating these two models.

    I agree.  The = point of having an AS-RO is to allow RO to specify a policy for which of = RO's access tokens should be delegated under what conditions.  = AS-RS should not need to understand those policies.  The flow would = be
    • RO contacts AS-RS = and gets one or more access tokens.
    • RO delegates one = or more of those tokens, potentially sub-scoped, to AS-RO.
    • A different user contacts AS-RO to get a potentially = sub-scoped access token from AS-RO.
    • That user = presents the access token delegated by AS-RO when invoking the = resource.
    AS-RS only = needs to verify that the delegation chain is legitimate, e.g., no = increase in scope, and that it grants permission for the request being = made.  AS-RS does not need to understand the policy behind granting = the delegation by AS-RO.

    --------------
    Alan Karp


    On Mon, Mar 22, 2021 at 11:40 AM Justin = Richer <jricher@mit.edu> wrote:
    Adrian,

    I think this shows the = problem with the terminology as it=E2=80=99s been applied in this = conversation, which I=E2=80=99ve tried to shine light on before. What = you and others are calling the =E2=80=9CRS=E2=80=9D is really the =E2=80=9C= AS and RS working together=E2=80=9D =E2=80=94 everything to the right of = the line. When Denis had brought up =E2=80=9Celiminating the AS=E2=80=9D = in another thread, what he=E2=80=99d really done is labeled everything = to the right of the line as the =E2=80=9CRS=E2=80=9D. Of course, the = irony here is that everything to the right of the line used all be = called the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80=9D in = the OAuth 1 days. As you say below, I don=E2=80=99t want the client to = have visibility on what happens on that side. 

    Note well: The Google+ = logo labeled =E2=80=9CIdP=E2=80=9D in the diagram is not the AS, as far = as GNAP is concerned. It does not issue an access token that the RS will = accept. The elements to the left of the line could be a lot of things, = but they are NOT the AS =E2=80=94 by definition. The client lives over = on the left, but so do any external inputs to the AS. These could be = policy inputs on behalf of the RO, they could be presentation artifacts, = they could be federated logins, they could be the output of policy = decisions. How the AS comes to trust those things is up to the AS=E2=80=99= s implementation. It=E2=80=99s something we can talk about, but = ultimately GNAP won=E2=80=99t be in any position to dictate because in = practice some AS=E2=80=99s are simply going to internalize all policies = and we will never successfully force those open. 

    But with all that in = mind, I think the key here is going to be looking at what the inputs to = the AS are, and how those can be defined in an interoperable way for = AS=E2=80=99s that can accept them. I think there=E2=80=99s a lot of room = for innovation and flexibility here that doesn=E2=80=99t break the trust = model or core use cases. If I have an AS-RS set that won=E2=80=99t = accept my favorite flavor of policy engine inputs, then I can decide not = to use that one. But this is a very different question than saying the = RS itself needs to accept my own AS =E2=80=94 and we can=E2=80=99t keep = conflating these two models.

    So to me, GNAP can support a Zero Trust = Architecture by LEVERAGING the AS, not by subsuming or eliminating it. = It is in fact the AS, not the client and not the RS, that will request = and consume the results of a privacy-preserving zero-trust policy query = thing. Anything that happens downstream from that is of little concern = to the zero-trust components because, as you point out, it=E2=80=99s on = the =E2=80=9Cother side=E2=80=9D of the line. 

    I think we got this = basic component model pretty right in OAuth: the AS and RS and client = working together. Where OAuth misses the mark is the assumption that the = user has to log in to the AS through a webpage and interact directly, = thereby proving they=E2=80=99re the RO. It=E2=80=99s this latter space = where I think we can both push innovation and also address the important = and compelling use cases like the ones you=E2=80=99re = bringing.

     =E2=80=94 Justin

    On Mar = 22, 2021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I'm sorry, Justin. As a Resource = Owner, I look at the RS trust boundary (the dotted line in the diagram) = as being the RS. I don't expect any visibility into what's going on on = the right. 

    My problem with the framing you propose is that requests are = going to the RS (or the AS-RS) and I don't want to share my policies = with the AS-RS. I want to keep the RS and AS-RS as ignorant as = possible.

    Adrian

    On Mon, Mar = 22, 2021 at 1:48 PM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    What you=E2=80=99re = discussing below, in terms of logging in to a site, is not approaching = the RS. You are in fact approaching the client, and identifying both the = AS and RS to the client. The client is a client of your = identity in this model, and the RS is part of the identity provider. = It=E2=80=99s really important that we don=E2=80=99t conflate the RS and = client in this way as it leads to a lot of confusion downstream and a = lot of broken trust boundaries.

    With that model in mind, approaching = the =E2=80=9CRS" and providing it your identity is really just a case of = the =E2=80=9Cfederated login to AS=E2=80=9D pattern that we discussed on = the WG call. The user here approaches an RS, which has its own AS. To = share things from this RS, the RO has to authenticate to the RS=E2=80=99s = AS. This particular AS allows the RO to do so using an external identity = =E2=80=94 in which case, the AS is now a =E2=80=9Cclient=E2=80=9D of a = separate, disconnected (but layered) delegation. The ultimate client = that eventually calls the RS down the way may or may not know about = these layers. 

    <PastedGraphic-1.png>
    This same AS, which is closely tied to the RS and trusted by = the RS, might also take in FIDO credentials, or DIDs, or any number of = other proof mechanisms. The output of this is an access token the RS = trusts, but the input is up to the AS. The RS is not what you=E2=80=99re = logging in to.

     =E2=80=94 Justin

    On Mar = 22, 2021, at 1:28 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I too am in favor of avoiding = consolidation and correlation. Right now, when I approach a service = provider (RS) for the first time, I'm offered the opportunity to = identify my persona as: email, sign-in with Google, Facebook, or Apple. = I know there are people who try to create one-off email addresses but = that is mostly a waste of time. 

    So, along come FIDO2 and DID wallets to = the rescue. Now, in theory, I have a way to start out my RS relationship = pseudonymously. 

    When I want my resource to be discovered or shared I will = post that RS URL including my pseudonym. If I then want to introduce a = mediator in front of my AS or messaging service endpoint, I = have that option. If I want to keep requests away from the mediator, I = would publish an encryption key along with my pseudonym.

    - Adrian



    On Mon, Mar 22, 2021 at 9:55 AM Justin = Richer <jricher@mit.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, = Benjamin Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhkarp@gmail.com> shared a talk = about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#i= ssuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to = use authority
    >> as a core principle. I advocate for a GNAP design that = maximizes the power
    >> of the RO, to be seen as a human rights issue when the RO is a = human. This
    >> causes me to ask how to combine better security with better = human rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the = RO to
    >> partition limited authority across dozens of different ASs by = domain and
    >> function, then we are not using technology to empower the = individual.
    >> Probably the opposite, as we introduce consent fatigue and = burden normal
    >> people to partition their lives into non-overlapping = domains.
    >>
    >> My experience says we should aim for one AS per persona because = that maps
    >> into the way we manage our public and private identities. POLA = would then
    >> teach care in keeping ASs and RSs related to work / public = separate from
    >> ASs and RSs related to private life so that a policy = vulnerability in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to = GNAP
    > seems like a useful exercise.  I do want to point out some = potential
    > pitfalls with one-AS-per-persona that we can also be aware = of.  If
    > one-AS-per-persona becomes one-persona-per-AS as well, then the = AS's
    > identity in effect also serves as a persona identity and there are = privacy
    > considerations to that.  If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple = humans)
    > route is taken, we should consider whether that would lead to = various
    > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.  That topic is a current matter of = concern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in = the UMA working group, and it=E2=80=99s one of the biggest problems with = the personal AS (and personal data store) model. This kind of thing = makes RS-first trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that = wants to access my medical information. It calls an RS and requests = access, but it hasn=E2=80=99t been granted anything yet. Now I as the RO = have set up the RS so that it talks to my personal AS, that only I use. = In addition to the RS having to be able to figure out which medical = records are being requested from the context of the unauthenticated = request (which means it needs identifiers in the URL or something = similar for the RS to be able to tell, assuming that it protects data = for more than one person). So this client software doesn=E2=80=99t know = who I am and doesn=E2=80=99t know my medical record information, makes a = completely unauthorized request to the RS, and the RS says =E2=80=9CGo = to Justin=E2=80=99s personal AS to get a token=E2=80=9D. The client can = now make a direct correlation between the data that=E2=80=99s being = protected at the RS and the person running the AS that protects it. = Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This = is a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please = talk to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t = exposed anything at all. And from the perspective of both the patient = and the RS, this is more privacy-preserving, and it=E2=80=99s really the = least surprising option. Once the client gets to the AS, it can start a = negotiation of figuring out who the RO is for the information being = accessed.

    On top of this, the usability expectations of people managing their own = AS, or set of AS=E2=80=99s for multiple personas to keep things = separate, is a huge burden. Even in the tech community, I know people = who can=E2=80=99t reliably manage more than one email address for = different purposes. I wouldn=E2=80=99t expect my partner to do that =E2=80= =94 they have trouble enough balancing all the logins and sessions = required for different kids remote schooling, I couldn=E2=80=99t imagine = them having to understand all the requirements for managing multiple = authorization servers and associated policies. I also don=E2=80=99t = expect any person to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve = been on the internet for decades and I can barely keep tabs on my GPG = keys, and only use them when I am forced to. This is exactly the kind of = =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions above, = people will just want to outsource that to someone else, and the reality = will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice = only to end up with a world where the RS ends up making a limited choice = anyway. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99= s could allow arbitrary IdPs but they choose Google because it works and = that=E2=80=99s where the users are. (And that=E2=80=99s not to say = anything of the proprietary OIDC-like protocols, but that=E2=80=99s = another discussion).

    For further reading on these topics, I recommend both =E2=80=9CWhy = Johnny Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems = Fail=E2=80=9D.

    So what does this have to do with GNAP? I think we can be clear-eyed on = what kinds of expectations we have for the participants. If we expect = users (RO=E2=80=99s) to have to set up the AS-RS relationship, or expect = them to carry their AS, or manage their personal keys =E2=80=94 I think = we=E2=80=99ve lost the battle for relevance.

     =E2=80=94 Justin


    --
    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
    =

    = --Apple-Mail=_5BD6AFF7-7CE2-4340-A9F8-4DD1B99A2432-- From nobody Thu Mar 25 06:13:47 2021 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 F3B363A20D2 for ; Thu, 25 Mar 2021 06:13:45 -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 a9zX2Nvf6igv for ; Thu, 25 Mar 2021 06:13:40 -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 F087F3A20D1 for ; Thu, 25 Mar 2021 06:13:39 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id d10so2071740ils.5 for ; Thu, 25 Mar 2021 06:13: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=qLTpshBwS1qQytt54UCxIrHEeIip6CTAiItQbiZLRiw=; b=MMyfWXzMcdLXwOpOmmgKSKW3GtQ/4bIfKvSlEDCXFHu0R2w+0DCgVnjPN/QC30sbEJ MZNRWgFAZp8Qpqkmwhlh53YFbUSKkK335mOuhu+yeqSIkmG3ZJHLF/Z6n5fHaUjpaXy8 DmCDxOeK49Y6o/mXv9Ik5pr9IdjMY+KYYtPZghNA6+SHY5+AhcrFk32kQiHdgf8SPlYl a9dl7SGzYj3FuWBlaUV3yaxd+LTSXCho2q/SVwQBVAf29W1AYRmNF4N3z/8WJfuQ1/0z d/xMgPM9mSJATo2vpBzVjvUbs55mCPL/0NNakg2eOG9apmqOyc88KuiJtYQiP39Jck99 WqwQ== 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=qLTpshBwS1qQytt54UCxIrHEeIip6CTAiItQbiZLRiw=; b=eO/aHql8GLUrS9asRpnkHOhltXMIQ8iOOZZQNBKkrPvbGwJZD+LQO9alpLdTRsiO2q dd6D0oXRBoD7kKY4+giIKfYt4xe31kCTcJYez7YHJ7wls0RRdrrYsQuGUV8tx0H0SMZ3 JdY2DhiW8L8MfOZeRQt47lSVCJyKLstqs72sQej8ejrQJeTbqRwXKOWyqWhMVbY43Fuu 5jSxD/nYaWzsmuEzbzLFUW2zqPrFQVJqcB4mZRvh3w5NPKfweRWFwCqhi0bBrbLE9RmH t1yTVU/uT/w7+5cFSmzJPu2IFle1hsV+fRQ3ffk7AK8sB4cbwkh9Syq6mfZjW7/hSxji uZig== X-Gm-Message-State: AOAM531EOr/t20MTtNzUFDy1BT5EmL3jrW67lTt6WAM76gH8/djWDdMI rPi3fKKVXBE7q/6hoa9+4DNRGbZ+1I4EHByCH+k= X-Google-Smtp-Source: ABdhPJydwd53hPFB++VJwznhfLjanJJpNAqJQeX4RZEh3caFJWTaeBxEXconwHrwGeUwApWX72onQekVozmGjGVEWks= X-Received: by 2002:a05:6e02:1ca7:: with SMTP id x7mr6641783ill.68.1616678017870; Thu, 25 Mar 2021 06:13:37 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> In-Reply-To: <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> From: Fabien Imbault Date: Thu, 25 Mar 2021 14:13:26 +0100 Message-ID: To: Justin Richer Cc: Adrian Gropper , Alan Karp , Benjamin Kaduk , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="000000000000f8afc705be5c2e5f" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 13:13:46 -0000 --000000000000f8afc705be5c2e5f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Great analysis Justin. I also don't think we need (and most probably don't want and anyway can't take into account) all those variations in the core. We "just" need to make sure it is possible to extend. We'd have to see how such a thing as an "AS-RO" or "RO agent" fits in the interaction component model, as it currently remains fairly abstract. Fabien On Thu, Mar 25, 2021 at 1:45 PM Justin Richer wrote: > The way I=E2=80=99m thinking about Adrian=E2=80=99s use case is that what= we=E2=80=99re calling > the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an =E2=80=9CAS=E2=80=9D in the = traditional OAuth/GNAP sense, at least not > exactly. This is the agent that the RO can use to set policies and manage > consent on their behalf, and I=E2=80=99ve been arguing that it fits bette= r into > this vaguely-defined =E2=80=9Cinteraction component=E2=80=9D aspect of th= e current AS > definition, and it=E2=80=99s not currently separated from the AS definiti= on. The > =E2=80=9CAS-RS=E2=80=9D maps to what we=E2=80=99d call the =E2=80=9CAS=E2= =80=9D in OAuth/GNAP traditionally, it=E2=80=99s > what the RS trusts to issue tokens. In traditional OAuth the AS-RO and > AS-RS are always the same thing, from a functional protocol perspective. = An > important point here is that from a client=E2=80=99s perspective, they=E2= =80=99re only > talking to the AS-RS since that=E2=80=99s where the client gets its token= s, because > at the end of the day the client just wants to call the API at the RS and > doesn=E2=80=99t care how that happens (from a protocol standpoint). > > Note well: Even thought I don=E2=80=99t believe that =E2=80=9CAS-RO=E2=80= =9D is an authorization > server at all, I=E2=80=99m going to keep using that term below for consis= tency with > previous discussion. > > So we have these fundamental relationships around getting the client to > access the RS: > > 1. RS trusts AS-RS to issue tokens that RS will accept, validate, and > process for requests from client > 2. Client trusts AS-RS to issue tokens that client can use at RS > 3. RO trusts RS to protect RO=E2=80=99s api through delegated access > > On top of that, we=E2=80=99ve got some additional aspects that we=E2=80= =99re discussing: > > 4. RO trusts AS-RO to manage RO=E2=80=99s policies at runtime > 5. AS-RS trusts AS-RO to assert RO=E2=80=99s policies for access to RS > 6. Client trusts whatever AS-RS sends client to deal with, including > possibly RO-AS at runtime, because of (2) > > What I have been saying is that 4/5/6 are optional details of how RS-AS > runs things, and I think this also maps with Adrian=E2=80=99s view of cho= ice, since > if my RS=E2=80=99s AS-RS doesn=E2=80=99t allow me to plug in my own AS-RO= then I would be > motivated to pick a different RS who=E2=80=99s AS-RS lets me do just that= . The same > way I=E2=80=99d pick a different RS if their surrounding services didn=E2= =80=99t accept my > preferred federation login and I didn=E2=80=99t want to make another acco= unt. Of > course, market forces being as they are, I might not have much of an > actionable choice in RS, but GNAP can=E2=80=99t change that. > > What we can do is make it possible for AS-RS to talk to AS-RO, both in > philosophy of the protocol design and in concrete hooks to support (6) > above. > > Separately, we can approach the issue of making 1/2 above more dynamic. > This was UMA2=E2=80=99s =E2=80=9Cfederated authorization=E2=80=9D approac= h, and is behind a lot of > the =E2=80=9Cbring your own AS=E2=80=9D models out there. The problem wit= h these is that we > know from many years of experience that most RS=E2=80=99s aren=E2=80=99t = interested in > doing anything of the sort. > > So with GNAP we can instead allow 4/5/6 to vary in a predictable and > consistent way, letting the RS keep control over 1/2, thereby enabling > choice in (3). We don=E2=80=99t have to be the ones who define the all of= the > details of every permutation of (5) to enable this, though. Some of this = is > going to be configuration out of band, some of it=E2=80=99s going to be > communication at runtime. This is where VC=E2=80=99s, ZCAPs, CHAPI, DIDCo= mm, FIDO, > and a whole swath of other tech can come in and help out. I don=E2=80=99t= think we > need to put all the details for using these into core, nor do I think we= =E2=80=99ll > pull of The Great And Ultimate Abstraction for using these and other > approaches. But we can at least start talking about =E2=80=9CAS-RS=E2=80= =9D in such a way > that it no longer assumes it=E2=80=99s always the same party dealing with= the RO > directly. > > =E2=80=94 Justin > > On Mar 25, 2021, at 6:40 AM, Fabien Imbault > wrote: > > To reframe it closer to GNAP: > - AS =3D AS-RO, that's where you find the RO policies. The AS issues acce= ss > tokens to the client. > - the RO policies could be a) defined locally or b) in relationship with > the RS > > There have been several ideas related to the AS-RS relationship b: > b1) the RS issues capabilities (which can be further attenuated by the RO= ) > b2) Adrian also discussed a DID based solution > b3) there was also an alternative ACL proposal from Denis (+ preflight) > > Fabien > > > On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault > wrote: > >> Ok so I get you correctly: >> - what matters is the RQ (could be a RO or a end-user or both : we don't >> really care at a high-level, they're all treated as entities that make a >> request) >> - the policy is able to handle those different cases, based on its own >> internal delegation protocol >> - currently that requires AS-RS and AS-RO, but maybe it can be simplifie= d >> >> To answer to Denis, here's what I understood: >> - RO trusts AS-RS (and then handles its own policies within AS-RO) >> - end-user trusts AS-RO (through its client) >> >> Could probably work but that's a fairly different model compared to >> OAuth2 (and of today's GNAP), with different frontiers between the AS an= d >> the RS. >> >> Please do not hesitate to correct me if I'm wrong. >> >> Fabien >> >> On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper >> wrote: >> >>> I believe there are alternatives to having two kinds of ASs. The proble= m >>> may be a side-effect of deciding to switch away form treating the RO as >>> different from the RQ. That leads to downstream privacy issues. Our des= ire >>> for architectural simplicity is admirable but that may have been a step= too >>> far. >>> >>> There may also be solutions based on different types of tokens, as in >>> different capabilities (tokens signed by the RS) vs. tokens signed by t= he >>> AS. I=E2=80=99m not sure about that but Alan might have more to say. >>> >>> Adrian >>> >>> On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault >>> wrote: >>> >>>> Thanks. The general problem statement is clear. >>>> >>>> The proposed solution a bit less (to me). I understood that from point >>>> 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obvious reason = to have >>>> two types of ASs". Do you see an alternative ? >>>> >>>> Regarding the last item, I don't think that naming RQ by end-user >>>> created the problem. It might just highlight the asymmetry, which >>>> fundamentally exists. >>>> >>>> Fabien >>>> >>>> >>>> On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper >>>> wrote: >>>> >>>>> Recap: >>>>> 1 - Justin (I think) introduced the idea of an AS on the RS trust >>>>> boundary side. >>>>> 2 - I said the RO should not have to share policies with the RS. >>>>> 3 - Alan invented the concept of AS-RO and AS-RS to separate two kind= s >>>>> of PDPs. >>>>> >>>>> The thing is that step 2 is not symmetrical. The RO has a legitimate >>>>> privacy interest in keeping their policies private and minimizing the >>>>> leakage of information about requests that are posed against those >>>>> policies. >>>>> >>>>> The RS, on the other hand, should be publishing its policies (e.g. >>>>> what it=E2=80=99s selling or what jurisdiction it=E2=80=99s in or wha= t tokens or scopes it >>>>> supports). The RS has no obvious privacy interest in GNAP. It=E2=80= =99s just an >>>>> enforcer. >>>>> >>>>> There is one other privacy interest to consider around the RS and tha= t >>>>> is the requesting party (the end-user that is not the RO :-) might pr= efer >>>>> to share attributes with the RS instead of the RO or something contro= lled >>>>> by the RO. This case could be an =E2=80=9Cextension=E2=80=9D to GNAP = and might result in a >>>>> split AS as a solution. This problem was introduced when the editors >>>>> decided to replace RQ with end-user. Obviously, the RO end-user has n= o >>>>> privacy interests relative to itself. >>>>> >>>>> Adrian >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> I was referring to "By my definition, this model has two ASs since >>>>>> both are processing requests into tokens". If there's no reason to h= ave 2 >>>>>> types of ASs, that's fine then. >>>>>> But I'm a bit lost in where we stand with the idea. >>>>>> >>>>>> Could you recap? >>>>>> >>>>>> Fabien >>>>>> >>>>>> Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper >>>>>> a =C3=A9crit : >>>>>> >>>>>>> There=E2=80=99s no obvious reason to have two types of ASs. Any AS = that is >>>>>>> executing the policies of the RS can look to GNAP like the RS itsel= f. Why >>>>>>> would GNAP expose that interface to anyone? >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>> On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>> >>>>>>>> Note : I'm not sure that's a good idea, but having 2 types of ASs >>>>>>>> is not that easy to grasp. >>>>>>>> >>>>>>>> Fabien >>>>>>>> >>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com> a =C3=A9crit : >>>>>>>> >>>>>>>>> The purpose of either handling policies locally or delegating the= m >>>>>>>>> to the RO agent. >>>>>>>>> >>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper < >>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>> >>>>>>>>>> What purpose would be served by GNAP splitting the AS into two >>>>>>>>>> components? >>>>>>>>>> >>>>>>>>>> Adrian >>>>>>>>>> >>>>>>>>>> On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault < >>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Isn't the AS-RO a component of the AS? Same idea as the interac= t >>>>>>>>>>> component, it functionnally belongs to the AS role but could be= deployed >>>>>>>>>>> either as a monolith or as a separate component? >>>>>>>>>>> >>>>>>>>>>> Fabien >>>>>>>>>>> >>>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper < >>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>> >>>>>>>>>>>> Yes, but I would say it=E2=80=99s not the RO that wants the ac= cess >>>>>>>>>>>> token. It=E2=80=99s the RO that wants the client making the re= quest to get an >>>>>>>>>>>> access token. >>>>>>>>>>>> >>>>>>>>>>>> Adrian >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Mar 24, 2021 at 11:22 PM Alan Karp >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Adrian Gropper wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> In this design, the AS is the AS-RS and the agent is the >>>>>>>>>>>>>> AS-RO. By my definition, this model has two ASs since both a= re processing >>>>>>>>>>>>>> requests into tokens. The problem with this is complexity an= d privacy. The >>>>>>>>>>>>>> RO may not want to share the request information with the AS= -RS. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> More precisely, RO has no choice but to present the required >>>>>>>>>>>>> information to AS-RS if RO wants an access token. However, R= O does not >>>>>>>>>>>>> want AS-RS to know the policy by which RO delegates tokens. = That's why RO >>>>>>>>>>>>> uses AS-RO for those delegations. >>>>>>>>>>>>> >>>>>>>>>>>>> -------------- >>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper < >>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you for creating the issue. My definition of AS is >>>>>>>>>>>>>> independent of AS-RO or AS-RS. >>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/22= 3#issuecomment-806280421 >>>>>>>>>>>>>> I also agree with Alan's definition based on delegation. An = AS-RS would be >>>>>>>>>>>>>> a delegate of the RS. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Based on that, I see it as obvious that the policy has to be >>>>>>>>>>>>>> accessible (defined locally?) in order for it to be run as t= he code that >>>>>>>>>>>>>> turns a request into an access token. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The only other possibility is that the request is packaged b= y >>>>>>>>>>>>>> the AS and sent elsewhere (an agent) for evaluation against = policy and a >>>>>>>>>>>>>> proto-token returned. In that case the AS is acting as a pro= xy and the PDP >>>>>>>>>>>>>> is elsewhere. I can imagine that an AS-RS would behave this = way so that the >>>>>>>>>>>>>> proto-token could be turned into an access token by the AS-R= S. Isn't this >>>>>>>>>>>>>> what Justin is proposing? In this design, the AS is the AS-R= S and the agent >>>>>>>>>>>>>> is the AS-RO. By my definition, this model has two ASs since= both are >>>>>>>>>>>>>> processing requests into tokens. The problem with this is co= mplexity and >>>>>>>>>>>>>> privacy. The RO may not want to share the request informatio= n with the >>>>>>>>>>>>>> AS-RS. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault < >>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Isn't that what the AS is supposed to be, only with the >>>>>>>>>>>>>>> caveat that the policy is defined locally? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp >>>>>>>>>>>>>>> a =C3=A9crit : >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> AS-RO is an AS that RO trusts to delegate RO's access >>>>>>>>>>>>>>>> tokens according to RO's policies. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault < >>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Alan and Adrian, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I've created issue AS-RO policy delegation ( >>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues= /223) >>>>>>>>>>>>>>>>> to capture your input. >>>>>>>>>>>>>>>>> A first question that arises: can we give a definition to >>>>>>>>>>>>>>>>> AS-RO? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp < >>>>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Fabien Imbault wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Yes, but in that flow, the token relationship between >>>>>>>>>>>>>>>>>>> AS-RS and AS-RO is only secure if the tokens issued by = AS-RS are >>>>>>>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Attenuated delegation is a requirement, but that doesn't >>>>>>>>>>>>>>>>>> have to be done cryptographically. Token exchange works= just fine. SPKI >>>>>>>>>>>>>>>>>> and zcap-ld are examples of the crypto approach, and we = used token exchange >>>>>>>>>>>>>>>>>> in the system for HP. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault < >>>>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Yes, but in that flow, the token relationship between >>>>>>>>>>>>>>>>>>> AS-RS and AS-RO is only secure if the tokens issued by = AS-RS are >>>>>>>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp < >>>>>>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Justin Richer wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> But with all that in mind, I think the key here is >>>>>>>>>>>>>>>>>>>>> going to be looking at what the inputs to the AS are,= and how those can be >>>>>>>>>>>>>>>>>>>>> defined in an interoperable way for AS=E2=80=99s that= can accept them. I think >>>>>>>>>>>>>>>>>>>>> there=E2=80=99s a lot of room for innovation and flex= ibility here that doesn=E2=80=99t >>>>>>>>>>>>>>>>>>>>> break the trust model or core use cases. If I have an= AS-RS set that won=E2=80=99t >>>>>>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine inputs, th= en I can decide not to >>>>>>>>>>>>>>>>>>>>> use that one. But this is a very different question t= han saying the RS >>>>>>>>>>>>>>>>>>>>> itself needs to accept my own AS =E2=80=94 and we can= =E2=80=99t keep conflating these two >>>>>>>>>>>>>>>>>>>>> models. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I agree. The point of having an AS-RO is to allow RO >>>>>>>>>>>>>>>>>>>> to specify a policy for which of RO's access tokens sh= ould be delegated >>>>>>>>>>>>>>>>>>>> under what conditions. AS-RS should not need to under= stand those >>>>>>>>>>>>>>>>>>>> policies. The flow would be >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> - RO contacts AS-RS and gets one or more access >>>>>>>>>>>>>>>>>>>> tokens. >>>>>>>>>>>>>>>>>>>> - RO delegates one or more of those tokens, >>>>>>>>>>>>>>>>>>>> potentially sub-scoped, to AS-RO. >>>>>>>>>>>>>>>>>>>> - A different user contacts AS-RO to get a >>>>>>>>>>>>>>>>>>>> potentially sub-scoped access token from AS-RO. >>>>>>>>>>>>>>>>>>>> - That user presents the access token delegated by >>>>>>>>>>>>>>>>>>>> AS-RO when invoking the resource. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> AS-RS only needs to verify that the delegation chain i= s >>>>>>>>>>>>>>>>>>>> legitimate, e.g., no increase in scope, and that it gr= ants permission for >>>>>>>>>>>>>>>>>>>> the request being made. AS-RS does not need to unders= tand the policy >>>>>>>>>>>>>>>>>>>> behind granting the delegation by AS-RO. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer < >>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I think this shows the problem with the terminology a= s >>>>>>>>>>>>>>>>>>>>> it=E2=80=99s been applied in this conversation, which= I=E2=80=99ve tried to shine light on >>>>>>>>>>>>>>>>>>>>> before. What you and others are calling the =E2=80=9C= RS=E2=80=9D is really the =E2=80=9CAS and RS >>>>>>>>>>>>>>>>>>>>> working together=E2=80=9D =E2=80=94 everything to the= right of the line. When Denis had >>>>>>>>>>>>>>>>>>>>> brought up =E2=80=9Celiminating the AS=E2=80=9D in an= other thread, what he=E2=80=99d really done is >>>>>>>>>>>>>>>>>>>>> labeled everything to the right of the line as the = =E2=80=9CRS=E2=80=9D. Of course, the >>>>>>>>>>>>>>>>>>>>> irony here is that everything to the right of the lin= e used all be called >>>>>>>>>>>>>>>>>>>>> the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2= =80=9D in the OAuth 1 days. As you say below, I don=E2=80=99t >>>>>>>>>>>>>>>>>>>>> want the client to have visibility on what happens on= that side. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Note well: The Google+ logo labeled =E2=80=9CIdP=E2= =80=9D in the >>>>>>>>>>>>>>>>>>>>> diagram is not the AS, as far as GNAP is concerned. I= t does not issue an >>>>>>>>>>>>>>>>>>>>> access token that the RS will accept. The elements to= the left of the line >>>>>>>>>>>>>>>>>>>>> could be a lot of things, but they are NOT the AS =E2= =80=94 by definition. The >>>>>>>>>>>>>>>>>>>>> client lives over on the left, but so do any external= inputs to the AS. >>>>>>>>>>>>>>>>>>>>> These could be policy inputs on behalf of the RO, the= y could be >>>>>>>>>>>>>>>>>>>>> presentation artifacts, they could be federated login= s, they could be the >>>>>>>>>>>>>>>>>>>>> output of policy decisions. How the AS comes to trust= those things is up to >>>>>>>>>>>>>>>>>>>>> the AS=E2=80=99s implementation. It=E2=80=99s somethi= ng we can talk about, but ultimately >>>>>>>>>>>>>>>>>>>>> GNAP won=E2=80=99t be in any position to dictate beca= use in practice some AS=E2=80=99s are >>>>>>>>>>>>>>>>>>>>> simply going to internalize all policies and we will = never successfully >>>>>>>>>>>>>>>>>>>>> force those open. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> But with all that in mind, I think the key here is >>>>>>>>>>>>>>>>>>>>> going to be looking at what the inputs to the AS are,= and how those can be >>>>>>>>>>>>>>>>>>>>> defined in an interoperable way for AS=E2=80=99s that= can accept them. I think >>>>>>>>>>>>>>>>>>>>> there=E2=80=99s a lot of room for innovation and flex= ibility here that doesn=E2=80=99t >>>>>>>>>>>>>>>>>>>>> break the trust model or core use cases. If I have an= AS-RS set that won=E2=80=99t >>>>>>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine inputs, th= en I can decide not to >>>>>>>>>>>>>>>>>>>>> use that one. But this is a very different question t= han saying the RS >>>>>>>>>>>>>>>>>>>>> itself needs to accept my own AS =E2=80=94 and we can= =E2=80=99t keep conflating these two >>>>>>>>>>>>>>>>>>>>> models. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> So to me, GNAP can support a Zero Trust Architecture >>>>>>>>>>>>>>>>>>>>> by LEVERAGING the AS, not by subsuming or eliminating= it. It is in fact the >>>>>>>>>>>>>>>>>>>>> AS, not the client and not the RS, that will request = and consume the >>>>>>>>>>>>>>>>>>>>> results of a privacy-preserving zero-trust policy que= ry thing. Anything >>>>>>>>>>>>>>>>>>>>> that happens downstream from that is of little concer= n to the zero-trust >>>>>>>>>>>>>>>>>>>>> components because, as you point out, it=E2=80=99s on= the =E2=80=9Cother side=E2=80=9D of the line. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I think we got this basic component model pretty righ= t >>>>>>>>>>>>>>>>>>>>> in OAuth: the AS and RS and client working together. = Where OAuth misses the >>>>>>>>>>>>>>>>>>>>> mark is the assumption that the user has to log in to= the AS through a >>>>>>>>>>>>>>>>>>>>> webpage and interact directly, thereby proving they= =E2=80=99re the RO. It=E2=80=99s this >>>>>>>>>>>>>>>>>>>>> latter space where I think we can both push innovatio= n and also address the >>>>>>>>>>>>>>>>>>>>> important and compelling use cases like the ones you= =E2=80=99re bringing. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper < >>>>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I'm sorry, Justin. As a Resource Owner, I look at the >>>>>>>>>>>>>>>>>>>>> RS trust boundary (the dotted line in the diagram) as= being the RS. I don't >>>>>>>>>>>>>>>>>>>>> expect any visibility into what's going on on the rig= ht. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> My problem with the framing you propose is that >>>>>>>>>>>>>>>>>>>>> requests are going to the RS (or the AS-RS) and I don= 't want to share my >>>>>>>>>>>>>>>>>>>>> policies with the AS-RS. I want to keep the RS and AS= -RS as ignorant as >>>>>>>>>>>>>>>>>>>>> possible. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer < >>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> What you=E2=80=99re discussing below, in terms of lo= gging in >>>>>>>>>>>>>>>>>>>>>> to a site, is not approaching the RS. You are in fac= t approaching the >>>>>>>>>>>>>>>>>>>>>> client, and identifying both the AS and RS to the cl= ient. The client is a >>>>>>>>>>>>>>>>>>>>>> client *of your identity* in this model, and the RS >>>>>>>>>>>>>>>>>>>>>> is part of the identity provider. It=E2=80=99s reall= y important that we don=E2=80=99t >>>>>>>>>>>>>>>>>>>>>> conflate the RS and client in this way as it leads t= o a lot of confusion >>>>>>>>>>>>>>>>>>>>>> downstream and a lot of broken trust boundaries. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> With that model in mind, approaching the =E2=80=9CRS= " and >>>>>>>>>>>>>>>>>>>>>> providing it your identity is really just a case of = the =E2=80=9Cfederated login to >>>>>>>>>>>>>>>>>>>>>> AS=E2=80=9D pattern that we discussed on the WG call= . The user here approaches an >>>>>>>>>>>>>>>>>>>>>> RS, which has its own AS. To share things from this = RS, the RO has to >>>>>>>>>>>>>>>>>>>>>> authenticate to the RS=E2=80=99s AS. This particular= AS allows the RO to do so >>>>>>>>>>>>>>>>>>>>>> using an external identity =E2=80=94 in which case, = the AS is now a =E2=80=9Cclient=E2=80=9D of a >>>>>>>>>>>>>>>>>>>>>> separate, disconnected (but layered) delegation. The= ultimate client that >>>>>>>>>>>>>>>>>>>>>> eventually calls the RS down the way may or may not = know about these >>>>>>>>>>>>>>>>>>>>>> layers. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> This same AS, which is closely tied to the RS and >>>>>>>>>>>>>>>>>>>>>> trusted by the RS, might also take in FIDO credentia= ls, or DIDs, or any >>>>>>>>>>>>>>>>>>>>>> number of other proof mechanisms. The output of this= is an access token the >>>>>>>>>>>>>>>>>>>>>> RS trusts, but the input is up to the AS. The RS is = not what you=E2=80=99re logging >>>>>>>>>>>>>>>>>>>>>> in to. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper < >>>>>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I too am in favor of avoiding consolidation and >>>>>>>>>>>>>>>>>>>>>> correlation. Right now, when I approach a service pr= ovider (RS) for the >>>>>>>>>>>>>>>>>>>>>> first time, I'm offered the opportunity to identify = my persona as: email, >>>>>>>>>>>>>>>>>>>>>> sign-in with Google, Facebook, or Apple. I know ther= e are people who try to >>>>>>>>>>>>>>>>>>>>>> create one-off email addresses but that is mostly a = waste of time. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> So, along come FIDO2 and DID wallets to the rescue. >>>>>>>>>>>>>>>>>>>>>> Now, in theory, I have a way to start out my RS rela= tionship >>>>>>>>>>>>>>>>>>>>>> pseudonymously. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> When I want my resource to be discovered or shared I >>>>>>>>>>>>>>>>>>>>>> will post that RS URL including my pseudonym. If I t= hen want to introduce a >>>>>>>>>>>>>>>>>>>>>> mediator in front of my AS or messaging service endp= oint, I have that >>>>>>>>>>>>>>>>>>>>>> option. If I want to keep requests away from the med= iator, I would publish >>>>>>>>>>>>>>>>>>>>>> an encryption key along with my pseudonym. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> - Adrian >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer < >>>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk < >>>>>>>>>>>>>>>>>>>>>>> kaduk@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian >>>>>>>>>>>>>>>>>>>>>>> Gropper wrote: >>>>>>>>>>>>>>>>>>>>>>> >> @Alan Karp shared a talk >>>>>>>>>>>>>>>>>>>>>>> about the Principle Of Least >>>>>>>>>>>>>>>>>>>>>>> >> Authority (POLA) in a recent comment >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/= issues/145#issuecomment-803099693 >>>>>>>>>>>>>>>>>>>>>>> >> I recommend it. >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> We might expect a protocol with authorization in >>>>>>>>>>>>>>>>>>>>>>> the title to use authority >>>>>>>>>>>>>>>>>>>>>>> >> as a core principle. I advocate for a GNAP desig= n >>>>>>>>>>>>>>>>>>>>>>> that maximizes the power >>>>>>>>>>>>>>>>>>>>>>> >> of the RO, to be seen as a human rights issue >>>>>>>>>>>>>>>>>>>>>>> when the RO is a human. This >>>>>>>>>>>>>>>>>>>>>>> >> causes me to ask how to combine better security >>>>>>>>>>>>>>>>>>>>>>> with better human rights in >>>>>>>>>>>>>>>>>>>>>>> >> GNAP. >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> Who should have the least authority in the GNAP >>>>>>>>>>>>>>>>>>>>>>> design? >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> The AS derives authority as a delegate of the RO= . >>>>>>>>>>>>>>>>>>>>>>> If we ask the RO to >>>>>>>>>>>>>>>>>>>>>>> >> partition limited authority across dozens of >>>>>>>>>>>>>>>>>>>>>>> different ASs by domain and >>>>>>>>>>>>>>>>>>>>>>> >> function, then we are not using technology to >>>>>>>>>>>>>>>>>>>>>>> empower the individual. >>>>>>>>>>>>>>>>>>>>>>> >> Probably the opposite, as we introduce consent >>>>>>>>>>>>>>>>>>>>>>> fatigue and burden normal >>>>>>>>>>>>>>>>>>>>>>> >> people to partition their lives into >>>>>>>>>>>>>>>>>>>>>>> non-overlapping domains. >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> My experience says we should aim for one AS per >>>>>>>>>>>>>>>>>>>>>>> persona because that maps >>>>>>>>>>>>>>>>>>>>>>> >> into the way we manage our public and private >>>>>>>>>>>>>>>>>>>>>>> identities. POLA would then >>>>>>>>>>>>>>>>>>>>>>> >> teach care in keeping ASs and RSs related to wor= k >>>>>>>>>>>>>>>>>>>>>>> / public separate from >>>>>>>>>>>>>>>>>>>>>>> >> ASs and RSs related to private life so that a >>>>>>>>>>>>>>>>>>>>>>> policy vulnerability in our >>>>>>>>>>>>>>>>>>>>>>> >> delegation to an AS would have the least >>>>>>>>>>>>>>>>>>>>>>> likelihood of harm. >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > Thinking about how least authority/least privileg= e >>>>>>>>>>>>>>>>>>>>>>> would apply to GNAP >>>>>>>>>>>>>>>>>>>>>>> > seems like a useful exercise. I do want to point >>>>>>>>>>>>>>>>>>>>>>> out some potential >>>>>>>>>>>>>>>>>>>>>>> > pitfalls with one-AS-per-persona that we can also >>>>>>>>>>>>>>>>>>>>>>> be aware of. If >>>>>>>>>>>>>>>>>>>>>>> > one-AS-per-persona becomes one-persona-per-AS as >>>>>>>>>>>>>>>>>>>>>>> well, then the AS's >>>>>>>>>>>>>>>>>>>>>>> > identity in effect also serves as a persona >>>>>>>>>>>>>>>>>>>>>>> identity and there are privacy >>>>>>>>>>>>>>>>>>>>>>> > considerations to that. If, on the other hand, t= he >>>>>>>>>>>>>>>>>>>>>>> > multiple-personas-per-AS (presumably correspondin= g >>>>>>>>>>>>>>>>>>>>>>> to multiple humans) >>>>>>>>>>>>>>>>>>>>>>> > route is taken, we should consider whether that >>>>>>>>>>>>>>>>>>>>>>> would lead to various >>>>>>>>>>>>>>>>>>>>>>> > (e.g., market) forces driving consolidation to >>>>>>>>>>>>>>>>>>>>>>> just a handful of >>>>>>>>>>>>>>>>>>>>>>> > super-popular AS services. That topic is a >>>>>>>>>>>>>>>>>>>>>>> current matter of concern to >>>>>>>>>>>>>>>>>>>>>>> > some IETF participants. >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Hi Ben, big +1 to this. This is something that we >>>>>>>>>>>>>>>>>>>>>>> discussed ages ago in the UMA working group, and it= =E2=80=99s one of the biggest >>>>>>>>>>>>>>>>>>>>>>> problems with the personal AS (and personal data st= ore) model. This kind of >>>>>>>>>>>>>>>>>>>>>>> thing makes RS-first trust models really difficult = in practice. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve = got software that >>>>>>>>>>>>>>>>>>>>>>> wants to access my medical information. It calls an= RS and requests access, >>>>>>>>>>>>>>>>>>>>>>> but it hasn=E2=80=99t been granted anything yet. No= w I as the RO have set up the RS >>>>>>>>>>>>>>>>>>>>>>> so that it talks to my personal AS, that only I use= . In addition to the RS >>>>>>>>>>>>>>>>>>>>>>> having to be able to figure out which medical recor= ds are being requested >>>>>>>>>>>>>>>>>>>>>>> from the context of the unauthenticated request (wh= ich means it needs >>>>>>>>>>>>>>>>>>>>>>> identifiers in the URL or something similar for the= RS to be able to tell, >>>>>>>>>>>>>>>>>>>>>>> assuming that it protects data for more than one pe= rson). So this client >>>>>>>>>>>>>>>>>>>>>>> software doesn=E2=80=99t know who I am and doesn=E2= =80=99t know my medical record >>>>>>>>>>>>>>>>>>>>>>> information, makes a completely unauthorized reques= t to the RS, and the RS >>>>>>>>>>>>>>>>>>>>>>> says =E2=80=9CGo to Justin=E2=80=99s personal AS to= get a token=E2=80=9D. The client can now make a >>>>>>>>>>>>>>>>>>>>>>> direct correlation between the data that=E2=80=99s = being protected at the RS and >>>>>>>>>>>>>>>>>>>>>>> the person running the AS that protects it. Importa= ntly, this client makes >>>>>>>>>>>>>>>>>>>>>>> this call with no prior relationship to the RS and = no really auditable way >>>>>>>>>>>>>>>>>>>>>>> to track it down after the fact. This is a design f= eature in the good case, >>>>>>>>>>>>>>>>>>>>>>> and terrifying in the bad case. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> If the RS instead says =E2=80=9Cwelcome to Medicine= Doctor >>>>>>>>>>>>>>>>>>>>>>> RS, please talk to the Medicine Doctor AS to get ac= cess=E2=80=9D, we haven=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>> exposed anything at all. And from the perspective o= f both the patient and >>>>>>>>>>>>>>>>>>>>>>> the RS, this is more privacy-preserving, and it=E2= =80=99s really the least >>>>>>>>>>>>>>>>>>>>>>> surprising option. Once the client gets to the AS, = it can start a >>>>>>>>>>>>>>>>>>>>>>> negotiation of figuring out who the RO is for the i= nformation being >>>>>>>>>>>>>>>>>>>>>>> accessed. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On top of this, the usability expectations of peopl= e >>>>>>>>>>>>>>>>>>>>>>> managing their own AS, or set of AS=E2=80=99s for m= ultiple personas to keep things >>>>>>>>>>>>>>>>>>>>>>> separate, is a huge burden. Even in the tech commun= ity, I know people who >>>>>>>>>>>>>>>>>>>>>>> can=E2=80=99t reliably manage more than one email a= ddress for different purposes. I >>>>>>>>>>>>>>>>>>>>>>> wouldn=E2=80=99t expect my partner to do that =E2= =80=94 they have trouble enough balancing >>>>>>>>>>>>>>>>>>>>>>> all the logins and sessions required for different = kids remote schooling, I >>>>>>>>>>>>>>>>>>>>>>> couldn=E2=80=99t imagine them having to understand = all the requirements for >>>>>>>>>>>>>>>>>>>>>>> managing multiple authorization servers and associa= ted policies. I also >>>>>>>>>>>>>>>>>>>>>>> don=E2=80=99t expect any person to =E2=80=9Cmanage = keys=E2=80=9D =E2=80=94 I=E2=80=99ve been on the internet for >>>>>>>>>>>>>>>>>>>>>>> decades and I can barely keep tabs on my GPG keys, = and only use them when I >>>>>>>>>>>>>>>>>>>>>>> am forced to. This is exactly the kind of =E2=80=9C= market pressure=E2=80=9D that I think >>>>>>>>>>>>>>>>>>>>>>> Ben mentions above, people will just want to outsou= rce that to someone >>>>>>>>>>>>>>>>>>>>>>> else, and the reality will be a few popular provide= rs. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> In which case, we could end up doing a ton of work >>>>>>>>>>>>>>>>>>>>>>> to allow an RS choice only to end up with a world w= here the RS ends up >>>>>>>>>>>>>>>>>>>>>>> making a limited choice anyway. We see how that pla= ys out with OpenID >>>>>>>>>>>>>>>>>>>>>>> Connect =E2=80=94 RP=E2=80=99s could allow arbitrar= y IdPs but they choose Google because it >>>>>>>>>>>>>>>>>>>>>>> works and that=E2=80=99s where the users are. (And = that=E2=80=99s not to say anything of >>>>>>>>>>>>>>>>>>>>>>> the proprietary OIDC-like protocols, but that=E2=80= =99s another discussion). >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> For further reading on these topics, I recommend >>>>>>>>>>>>>>>>>>>>>>> both =E2=80=9CWhy Johnny Can=E2=80=99t Encrypt=E2= =80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> So what does this have to do with GNAP? I think we >>>>>>>>>>>>>>>>>>>>>>> can be clear-eyed on what kinds of expectations we = have for the >>>>>>>>>>>>>>>>>>>>>>> participants. If we expect users (RO=E2=80=99s) to = have to set up the AS-RS >>>>>>>>>>>>>>>>>>>>>>> relationship, or expect them to carry their AS, or = manage their personal >>>>>>>>>>>>>>>>>>>>>>> keys =E2=80=94 I think we=E2=80=99ve lost the battl= e for relevance. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>> > --000000000000f8afc705be5c2e5f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Great analysis Justin.=C2=A0
    I also don't think we= need (and most probably don't want and anyway can't take into acco= unt) all those variations in the core. We "just" need to make sur= e it is possible to extend.

    We'd have to see h= ow such a thing as an "AS-RO" or "RO agent" fits in the= interaction component model, as it currently remains fairly abstract.

    Fabien


    On Thu, Mar = 25, 2021 at 1:45 PM Justin Richer <jr= icher@mit.edu> wrote:
    The way I=E2=80=99m = thinking about Adrian=E2=80=99s use case is that what we=E2=80=99re calling= the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an =E2=80=9CAS=E2=80=9D in the t= raditional OAuth/GNAP sense, at least not exactly. This is the agent that t= he RO can use to set policies and manage consent on their behalf, and I=E2= =80=99ve been arguing that it fits better into this vaguely-defined =E2=80= =9Cinteraction component=E2=80=9D aspect of the current AS definition, and = it=E2=80=99s not currently separated from the AS definition. The =E2=80=9CA= S-RS=E2=80=9D maps to what we=E2=80=99d call the =E2=80=9CAS=E2=80=9D in OA= uth/GNAP traditionally, it=E2=80=99s what the RS trusts to issue tokens. In= traditional OAuth the AS-RO and AS-RS are always the same thing, from a fu= nctional protocol perspective. An important point here is that from a clien= t=E2=80=99s perspective, they=E2=80=99re only talking to the AS-RS since th= at=E2=80=99s where the client gets its tokens, because at the end of the da= y the client just wants to call the API at the RS and doesn=E2=80=99t care = how that happens (from a protocol standpoint).=C2=A0

    Not= e well: Even thought I don=E2=80=99t believe that =E2=80=9CAS-RO=E2=80=9D i= s an authorization server at all, I=E2=80=99m going to keep using that term= below for consistency with previous discussion.

    S= o we have these fundamental relationships around getting the client to acce= ss the RS:

    1. RS trusts=C2=A0AS-RS=C2=A0to issue t= okens that RS will accept, validate, and process for requests from client
    2. Client trusts=C2=A0AS-RS=C2=A0to issue tokens that client can u= se at RS
    3. RO trusts RS to protect RO=E2=80=99s api through dele= gated access

    On top of that, we=E2=80=99ve got som= e additional aspects that we=E2=80=99re discussing:

    4. RO trusts=C2=A0AS-RO=C2=A0to manage RO=E2=80=99s policies at runtime
    5.=C2=A0AS-RS=C2=A0trusts=C2=A0AS-RO=C2=A0to assert RO=E2=80=99s p= olicies for access to RS
    6. Client trusts whatever=C2=A0AS-RS=C2= =A0sends client to deal with, including possibly RO-AS at runtime, because = of (2)

    What I have been saying is that 4/5/6 are o= ptional details of how RS-AS runs things, and I think this also maps with A= drian=E2=80=99s view of choice, since if my RS=E2=80=99s AS-RS doesn=E2=80= =99t allow me to plug in my own AS-RO then I would be motivated to pick a d= ifferent RS who=E2=80=99s AS-RS lets me do just that. The same way I=E2=80= =99d pick a different RS if their surrounding services didn=E2=80=99t accep= t my preferred federation login and I didn=E2=80=99t want to make another a= ccount. Of course, market forces being as they are, I might not have much o= f an actionable choice in RS, but GNAP can=E2=80=99t change that.=C2=A0

    What we can do is make it possible for AS-RS to talk = to AS-RO, both in philosophy of the protocol design and in concrete hooks t= o support (6) above.=C2=A0

    Separately, we can appr= oach the issue of making 1/2 above more dynamic. This was UMA2=E2=80=99s = =E2=80=9Cfederated authorization=E2=80=9D approach, and is behind a lot of = the =E2=80=9Cbring your own AS=E2=80=9D models out there. The problem with = these is that we know from many years of experience that most RS=E2=80=99s = aren=E2=80=99t interested in doing anything of the sort.

    So with GNAP we can instead allow 4/5/6 to vary in a predictable and= consistent way, letting the RS keep control over 1/2, thereby enabling cho= ice in (3). We don=E2=80=99t have to be the ones who define the all of the = details of every permutation of (5) to enable this, though. Some of this is= going to be configuration out of band, some of it=E2=80=99s going to be co= mmunication at runtime. This is where VC=E2=80=99s, ZCAPs, CHAPI, DIDComm, = FIDO, and a whole swath of other tech can come in and help out. I don=E2=80= =99t think we need to put all the details for using these into core, nor do= I think we=E2=80=99ll pull of The Great And Ultimate Abstraction for using= these and other approaches. But we can at least start talking about =E2=80= =9CAS-RS=E2=80=9D in such a way that it no longer assumes it=E2=80=99s alwa= ys the same party dealing with the RO directly.

    =C2= =A0=E2=80=94 Justin

    On Mar 25, 2= 021, at 6:40 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    To reframe it closer to GNAP:
    - AS =3D AS-RO, that&#= 39;s where you find the RO policies. The AS issues access tokens to the cli= ent.
    - the RO policies could be a) defined locally or b) in relat= ionship with the RS

    There have been several ideas = related to the AS-RS relationship b:
    b1) the RS issues capabi= lities (which can be further attenuated by the RO)
    b2) Adrian als= o discussed a DID based solution
    b3) there was also an alternativ= e ACL proposal from Denis (+ preflight)

    Fabien


    On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault <fabien.imbault@gmail= .com> wrote:
    Ok so I get you correctly:=C2=A0
    - what matters is= the RQ (could be a RO or a end-user or both : we don't really care at = a high-level, they're all treated as entities that make a request)
    - the policy is able to handle those different cases, based on its ow= n internal delegation protocol
    - currently that requires AS-RS an= d AS-RO, but maybe it can be simplified

    To answer = to Denis, here's what I understood:
    - RO trusts AS-RS (and th= en handles its own policies within AS-RO)
    - end-user trusts A= S-RO (through its client)

    Could probably work but = that's a fairly different model compared to OAuth2 (and of today's = GNAP), with different frontiers between the AS and the RS.=C2=A0
    =
    Please do not hesitate to correct me if I'm wrong.
    =

    Fabien=C2=A0

    =
    On Thu, Mar 25, 2021 at 9:26 AM Adria= n Gropper <a= gropper@healthurl.com> wrote:
    I believe there are alternatives to = having two kinds of ASs. The problem may be a side-effect of deciding to sw= itch away form treating the RO as different from the RQ. That leads to down= stream privacy issues. Our desire for architectural simplicity is admirable= but that may have been a step too far.

    There may also be solutions based on different types of tok= ens, as in different capabilities (tokens signed by the RS) vs. tokens sign= ed by the AS. I=E2=80=99m not sure about that but Alan might have more to s= ay.

    Adrian
    On Thu, M= ar 25, 2021 at 4:15 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thank= s. The general problem statement is clear.

    The=C2=A0prop= osed solution a bit less (to me). I understood that from point 2, Alan invo= lves 2 ASs. You said : "There=E2=80= =99s no obvious reason to have two types of ASs".=C2=A0Do you s= ee an alternative ?

    Regarding the last item,= I don't think that naming RQ by end-user created the problem. It might= just highlight the asymmetry,=C2=A0which fundamentally exists.=C2=A0

    Fabien=


    On Thu, Mar 25, 2021 at 8:48 AM Adrian Groppe= r <agropper@= healthurl.com> wrote:
    Recap:
    1 - Justin (I = think) introduced the idea of an AS on the RS trust boundary side.
    2 - I said the RO should not have to share policies with the= RS.
    3 - Alan invented the concept of AS-RO and AS-R= S to separate two kinds of PDPs.=C2=A0

    The thing is that step 2 is not symmetrical. The RO has a le= gitimate privacy interest in keeping their policies private and minimizing = the leakage of information about requests that are posed against those poli= cies.=C2=A0

    The RS, on t= he other hand, should be publishing its policies (e.g. what it=E2=80=99s se= lling or what jurisdiction it=E2=80=99s in or what tokens or scopes it supp= orts). The RS has no obvious privacy interest in GNAP. It=E2=80=99s just an= enforcer.

    There is one = other privacy interest to consider around the RS and that is the requesting= party (the end-user that is not the RO :-) might prefer to share attribute= s with the RS instead of the RO or something controlled by the RO. This cas= e could be an =E2=80=9Cextension=E2=80=9D to GNAP and might result in a spl= it AS as a solution. This problem was introduced when the editors decided t= o replace RQ with end-user. Obviously, the RO end-user has no privacy inter= ests relative to itself.

    Adrian




    On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault <fabien.imbault@g= mail.com> wrote:
    I was referring to "By my definition, this model has two ASs since both are= processing requests into tokens". If there's no reason to have 2 = types of ASs, that's fine then.=C2=A0
    But I'm a bit lost in where we stand with the id= ea.=C2=A0

    Could you recap?=C2=A0<= /font>

    Fabien=C2= =A0

    Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper <= agropper@health= url.com> a =C3=A9crit=C2=A0:
    There=E2=80=99s no obvious reason to = have two types of ASs. Any AS that is executing the policies of the RS can = look to GNAP like the RS itself. Why would GNAP expose that interface to an= yone?=C2=A0

    Adrian
    =

    O= n Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault <fabien.imbault@gmai= l.com> wrote:
    Note : I'm not sure that's a good idea, but = having 2 types of ASs is not that easy to grasp.

    Fabien=C2=A0

    Le jeu. 25 mar= s 2021 =C3=A0 08:07, Fabien Imbault <fabien.imbault@gmail.com&= gt; a =C3=A9crit=C2=A0:
    The purpose of either handling policies locally o= r delegating them to the RO agent.=C2=A0

    Le jeu. 25 mars 2021 =C3=A0 08:04, = Adrian Gropper <agropper@healthurl.com> a =C3=A9cr= it=C2=A0:
    What purpose would be served by GNAP splitting the AS into two = components?

    Adrian=C2=A0=

    On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbau= lt <fabien.imbault@gmail.com> wrote:<= br>
    Isn't the AS-RO a component of the AS? Same idea as the interact comp= onent, it functionnally belongs to the AS role but could be deployed either= as a monolith or as a separate component?

    Fabien

    Le jeu. 25 mars 2021 =C3= =A0 04:26, Adrian Gropper <agropper@healthurl.= com> a =C3=A9crit=C2=A0:
    Yes, but I would say it=E2=80=99s not the= RO that wants the access token. It=E2=80=99s the RO that wants the client = making the request to get an access token.=C2=A0
    Adrian

    On Wed, Mar 24, 2021 at 11:22 PM Alan K= arp <alanhkarp@gmail.com> wrote= :
    Adrian Gropper &l= t;agropper@healthurl.com> wrote= :

    In this design, the AS is the AS-RS and = the agent is the AS-RO. By my definition, this model has two ASs since both= are processing requests into tokens. The problem with this is complexity a= nd privacy. The RO may not want to share the request information with the A= S-RS.

    More precisely, RO has no choice but to present the required information= to AS-RS if RO wants an access token.=C2=A0 However, RO does not want AS-R= S to know the policy by which RO delegates tokens.=C2=A0 That's why RO = uses AS-RO for those delegations.

    --------------<= br>Alan Karp


    On Wed, Mar 24, 2021 at = 7:41 PM Adrian Gropper <agropper@he= althurl.com> wrote:
    Thank you for creating the iss= ue. My definition of AS is independent of AS-RO or AS-RS.=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecom= ment-806280421 I also agree with Alan's definition based on delegat= ion. An AS-RS would be a delegate of the RS.=C2=A0
    Based on that, I see it as obvious=C2=A0that the policy has to= be accessible (defined locally?) in order for it to be run as the code tha= t turns a request into an access token.=C2=A0

    The = only other possibility is that the request is packaged by the AS and sent e= lsewhere (an agent) for evaluation against policy and a proto-token returne= d. In that case the AS is acting as a proxy and the PDP is elsewhere. I can= imagine that an AS-RS would behave this way so that the proto-token could = be turned into an access token by the AS-RS. Isn't this what Justin is = proposing? In this design, the AS is the AS-RS and the agent is the AS-RO. = By my definition, this model has two ASs since both are processing requests= into tokens. The problem with this is complexity and privacy. The RO may n= ot want to share the request information with the AS-RS.

    Adrian

    On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Isn't that what the AS is supposed to be, only with the caveat th= at the policy is defined locally?=C2=A0

    Fabien=C2=A0


    Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp <= alanhkarp@gmail.com> a =C3=A9crit= =C2=A0:
    AS-RO is an AS that RO trusts to delegate RO'= s access tokens according to RO's policies.=C2=A0=C2=A0

    --------------
    Alan Karp


    On W= ed, Mar 24, 2021 at 9:36 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan and = Adrian,

    I've created issue AS-RO policy delegation (= https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to = capture your input.=C2=A0
    A first question that arises: can we gi= ve a definition to AS-RO?

    Thanks
    Fabien<= /div>

    On Tue, Mar 23, 2021 at 4:15 PM Alan Karp <alanhkarp@gmail.com> wrote:
    <= div dir=3D"ltr">
    Fabi= en Imbault <fabien.imb= ault@gmail.com> wrote:
    Hi Alan,=C2=A0

    Yes, but i= n that flow, the token relationship between AS-RS and AS-RO is only secure = if the tokens issued by AS-RS are cryptographically attenuable in the first= place.=C2=A0
    =C2=A0
    Attenuated delegation is a requirement, but that doesn't have to be d= one cryptographically.=C2=A0 Token exchange works just fine.=C2=A0 SPKI and= zcap-ld are examples of the crypto approach, and we used token exchange in= the system for HP.

    --------------
    Alan Ka= rp


    On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault <fabien.imbault@gmail.com>= ; wrote:
    Hi Alan,=C2=A0

    Yes, but in that flow, the toke= n relationship between AS-RS and AS-RO is only secure if the tokens issued = by AS-RS are cryptographically attenuable in the first place.=C2=A0

    Fabien

    On Mon, Mar 22, 2021 at 9:26 PM Alan Karp <= ;alanhkarp@gmail.com> w= rote:
    Justin Rich= er <jricher@mit.edu> wro= te:
    But with all that in mind, I think the key here is going to be= looking at what the inputs to the AS are, and how those can be defined in = an interoperable way for AS=E2=80=99s that can accept them. I think there= =E2=80=99s a lot of room for innovation and flexibility here that doesn=E2= =80=99t break the trust model or core use cases. If I have an AS-RS set tha= t won=E2=80=99t accept my favorite flavor of policy engine inputs, then I c= an decide not to use that one. But this is a very different question than s= aying the RS itself needs to accept my own AS =E2=80=94 and we can=E2=80=99= t keep conflating these two models.

    =
    I agree.=C2=A0 The point of having an AS-RO is to allow RO to specify = a policy for which of RO's access tokens should be delegated under what= conditions.=C2=A0 AS-RS should not need to understand those policies.=C2= =A0 The flow would be
    • RO contacts AS-RS and gets one or m= ore access tokens.
    • RO delegates one or more of those tokens, potent= ially sub-scoped, to AS-RO.
    • A different user contacts AS-RO to get = a potentially sub-scoped access token from AS-RO.
    • That user present= s the access token delegated by AS-RO when invoking the resource.
    =
    AS-RS only needs to verify that the delegation chain is leg= itimate, e.g., no increase in scope, and that it grants permission for the = request being made.=C2=A0 AS-RS does not need to understand the policy behi= nd granting the delegation by AS-RO.

    ------------= --
    Alan Karp


    On Mon, Mar 22, 2021 at 11:40 AM Justin Rich= er <jricher@mit.edu> wro= te:
    Adrian,=

    I think this shows the problem with the terminology as = it=E2=80=99s been applied in this conversation, which I=E2=80=99ve tried to= shine light on before. What you and others are calling the =E2=80=9CRS=E2= =80=9D is really the =E2=80=9CAS and RS working together=E2=80=9D =E2=80=94= everything to the right of the line. When Denis had brought up =E2=80=9Cel= iminating the AS=E2=80=9D in another thread, what he=E2=80=99d really done = is labeled everything to the right of the line as the =E2=80=9CRS=E2=80=9D.= Of course, the irony here is that everything to the right of the line used= all be called the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80=9D = in the OAuth 1 days. As you say below, I don=E2=80=99t want the client to h= ave visibility on what happens on that side.=C2=A0

    Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the diagram i= s not the AS, as far as GNAP is concerned. It does not issue an access toke= n that the RS will accept. The elements to the left of the line could be a = lot of things, but they are NOT the AS =E2=80=94 by definition. The client = lives over on the left, but so do any external inputs to the AS. These coul= d be policy inputs on behalf of the RO, they could be presentation artifact= s, they could be federated logins, they could be the output of policy decis= ions. How the AS comes to trust those things is up to the AS=E2=80=99s impl= ementation. It=E2=80=99s something we can talk about, but ultimately GNAP w= on=E2=80=99t be in any position to dictate because in practice some AS=E2= =80=99s are simply going to internalize all policies and we will never succ= essfully force those open.=C2=A0

    But with all that= in mind, I think the key here is going to be looking at what the inputs to= the AS are, and how those can be defined in an interoperable way for AS=E2= =80=99s that can accept them. I think there=E2=80=99s a lot of room for inn= ovation and flexibility here that doesn=E2=80=99t break the trust model or = core use cases. If I have an AS-RS set that won=E2=80=99t accept my favorit= e flavor of policy engine inputs, then I can decide not to use that one. Bu= t this is a very different question than saying the RS itself needs to acce= pt my own AS =E2=80=94 and we can=E2=80=99t keep conflating these two model= s.

    So to me, GNAP can support a Zero Trust Archite= cture by LEVERAGING the AS, not by subsuming or eliminating it. It is in fa= ct the AS, not the client and not the RS, that will request and consume the= results of a privacy-preserving zero-trust policy query thing. Anything th= at happens downstream from that is of little concern to the zero-trust comp= onents because, as you point out, it=E2=80=99s on the =E2=80=9Cother side= =E2=80=9D of the line.=C2=A0

    I think we got this b= asic component model pretty right in OAuth: the AS and RS and client workin= g together. Where OAuth misses the mark is the assumption that the user has= to log in to the AS through a webpage and interact directly, thereby provi= ng they=E2=80=99re the RO. It=E2=80=99s this latter space where I think we = can both push innovation and also address the important and compelling use = cases like the ones you=E2=80=99re bringing.

    =C2= =A0=E2=80=94 Justin

    On Mar 22, 2= 021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I'm sorry, Justin. As a Resource Owner, I look at the RS trust bound= ary (the dotted line in the diagram) as being the RS. I don't expect an= y visibility into what's going on on the=C2=A0right.=C2=A0

    My problem with the framing you propose is that requests are going t= o the RS (or the AS-RS) and I don't want to share my policies with the = AS-RS. I want to keep the RS and AS-RS as ignorant as possible.
    <= br>
    Adrian

    On Mon, Mar 22, 2021 at 1:48 PM Justin Richer <= ;jricher@mit.edu> wrote:
    Adrian,
    <= br>
    What you=E2=80=99re discussing below, in terms of logging in = to a site, is not approaching the RS. You are in fact approaching the clien= t, and identifying both the AS and RS to the client. The client is a client= of your identity in this model, and the RS is part of the identity = provider. It=E2=80=99s really important that we don=E2=80=99t conflate the = RS and client in this way as it leads to a lot of confusion downstream and = a lot of broken trust boundaries.

    With that model = in mind, approaching the =E2=80=9CRS" and providing it your identity i= s really just a case of the =E2=80=9Cfederated login to AS=E2=80=9D pattern= that we discussed on the WG call. The user here approaches an RS, which ha= s its own AS. To share things from this RS, the RO has to authenticate to t= he RS=E2=80=99s AS. This particular AS allows the RO to do so using an exte= rnal identity =E2=80=94 in which case, the AS is now a =E2=80=9Cclient=E2= =80=9D of a separate, disconnected (but layered) delegation. The ultimate c= lient that eventually calls the RS down the way may or may not know about t= hese layers.=C2=A0

    <PastedGraphic-1.png>
    This same AS, which is c= losely tied to the RS and trusted by the RS, might also take in FIDO creden= tials, or DIDs, or any number of other proof mechanisms. The output of this= is an access token the RS trusts, but the input is up to the AS. The RS is= not what you=E2=80=99re logging in to.

    =C2=A0=E2= =80=94 Justin

    On Mar 22, 2021, a= t 1:28 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I t= oo am in favor of avoiding consolidation and correlation. Right now, when I= approach a service provider (RS) for the first time, I'm offered the o= pportunity to identify my persona as: email, sign-in with Google, Facebook,= or Apple. I know there are people who try to create one-off email addresse= s but that is mostly a waste of time.=C2=A0

    So, along co= me FIDO2 and DID wallets to the rescue. Now, in theory, I have a way to sta= rt out my RS relationship pseudonymously.=C2=A0

    Wh= en I want my resource to be discovered or shared I will post that RS URL in= cluding my pseudonym. If I then want to introduce a mediator=C2=A0in front = of my AS or messaging service=C2=A0endpoint, I have that option. If I want = to keep requests away from the mediator, I would publish an encryption key = along with my pseudonym.

    - Adrian



    On Mon, Mar 22, 2021 at 9:55 AM Justin Richer <jricher@mit.edu> wrote:
    =
    On Mar 21, 2021, at 1:18 = PM, Benjamin Kaduk <kaduk@mit.edu= > wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhk= arp@gmail.com> shared a talk about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-= gnap/gnap-core-protocol/issues/145#issuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --
    TXAuth 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
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.= ietf.org/mailman/listinfo/txauth

    --000000000000f8afc705be5c2e5f-- From nobody Thu Mar 25 06:23:29 2021 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 D4D713A210A for ; Thu, 25 Mar 2021 06:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 o-mmrk6Jwikx for ; Thu, 25 Mar 2021 06:23:22 -0700 (PDT) Received: from mail-ua1-f48.google.com (mail-ua1-f48.google.com [209.85.222.48]) (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 5B04E3A2108 for ; Thu, 25 Mar 2021 06:23:22 -0700 (PDT) Received: by mail-ua1-f48.google.com with SMTP id h5so512495uaw.0 for ; Thu, 25 Mar 2021 06:23:22 -0700 (PDT) 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=lP8kwobpv6jjlrWGLjtRdnxo+Uu1ibgK8SO9uUzkkoM=; b=ptPFPJozMqH2wx5PDOpJGWNuSvI9DAa5RKZ4moyq//bDN8m/7ivbVtIMRxUzYUMWMZ HDVtwBsrFFePfbHnvgNqPsp6XA7glffciGQyOnK4aWX+U2fl6WC3Xh9D0A7wC4sHaC8z 6GsebCKR/WDmlf90MyrLQ4uX28OVyowg7RyraPfyAsjyChhd/FfjmfO1X2Dq2cRCHZJz It0e7wMXxtRhCrhNf/ZUiItkb1kxbq9XOB7v/BS66v46gQZUdzDv8sbNu4ECtCifhMH+ c3QYWn7/lq2RJiQP2yXq4oeR7adHQklhpg8rO+Flx00wAujJGypT/Hts4rsmawKj29+B pdYA== X-Gm-Message-State: AOAM532iSjGHx5NOlLSU9Ev/Ahf6MHnxAvt9X4e1fHepITOGcjrZfiL9 IPIuqtfgvSHiklL2cWfCUVDCBE7vQoB3QQCVx9Y= X-Google-Smtp-Source: ABdhPJzisAOvlmzTSrKQe+z+v7GwBoxjciad1drvLGDZzjezmPhPjw6V/uZdmTzu6mpmMthj6la6XWwzYMZ2Di65ro0= X-Received: by 2002:ab0:30a3:: with SMTP id b3mr4509783uam.0.1616678601023; Thu, 25 Mar 2021 06:23:21 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> In-Reply-To: <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> From: Adrian Gropper Date: Thu, 25 Mar 2021 09:23:09 -0400 Message-ID: To: Justin Richer Cc: Fabien Imbault , Alan Karp , Benjamin Kaduk , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="000000000000bae5ce05be5c5134" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 13:23:28 -0000 --000000000000bae5ce05be5c5134 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the summary Justin. You very clearly articulated what I would call the "regulatory capture" aspects of the problem. The RS will do everything they can to avoid ceding power to the RO. By avoiding standards that shift power to the RO, the platforms, IdP's, and most other service providers delay regulation that would promote agent-based delegated access to an API as a human right. It's only recently, with GDPR, that lawmakers have started to consider human rights outside of healthcare and are now introducing concepts such as the separation of controller from processor in order to enable a new generation of regulation. My perspective on GNAP is not arbitrary. It is honed by years of experience in healthcare as everyone struggles with OAuth and OpenID Connect, HEART, and now UDAP, to avoid doing in standards what seems obvious from a human rights perspective. What's interesting is that the "regulatory capture" standards game is now playing out in a new arena. The recent transition of DID to W3C Candidate Recommendation, together with Verifiable Credentials before that, means that every regulator (e.g. US Health and Human Services, Scotland, EU...) and some legislatures (e.g. Wyoming) are having to deal with the concept of Self-Sovereign Identity. It's not fun for the community that has worked so hard on SSI to now have to dance-around the actual impact of the SSI standards. With VC and DID, W3C seems to have broken through a "regulatory capture" barrier and that community is moving on to standardize protocols like DIDcomm and Encrypted Data Vaults that may avoid delegated authorization as a human right. In my opinion, GNAP, and IETF, is facing the same "regulatory capture" barrier. Justin says: "Of course, market forces being as they are, I might not have much of an actionable choice in RS, but GNAP can=E2=80=99t change that." Wh= at GNAP makes core can change the choices the market offers by making GNAP an interoperability badge that stands for Human-Centered Protocol. If GNAP moves the human-centered part to an extension, then we're no better than another "profile" on top of OAuth. Adrian On Thu, Mar 25, 2021 at 8:46 AM Justin Richer wrote: > The way I=E2=80=99m thinking about Adrian=E2=80=99s use case is that what= we=E2=80=99re calling > the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an =E2=80=9CAS=E2=80=9D in the = traditional OAuth/GNAP sense, at least not > exactly. This is the agent that the RO can use to set policies and manage > consent on their behalf, and I=E2=80=99ve been arguing that it fits bette= r into > this vaguely-defined =E2=80=9Cinteraction component=E2=80=9D aspect of th= e current AS > definition, and it=E2=80=99s not currently separated from the AS definiti= on. The > =E2=80=9CAS-RS=E2=80=9D maps to what we=E2=80=99d call the =E2=80=9CAS=E2= =80=9D in OAuth/GNAP traditionally, it=E2=80=99s > what the RS trusts to issue tokens. In traditional OAuth the AS-RO and > AS-RS are always the same thing, from a functional protocol perspective. = An > important point here is that from a client=E2=80=99s perspective, they=E2= =80=99re only > talking to the AS-RS since that=E2=80=99s where the client gets its token= s, because > at the end of the day the client just wants to call the API at the RS and > doesn=E2=80=99t care how that happens (from a protocol standpoint). > > Note well: Even thought I don=E2=80=99t believe that =E2=80=9CAS-RO=E2=80= =9D is an authorization > server at all, I=E2=80=99m going to keep using that term below for consis= tency with > previous discussion. > > So we have these fundamental relationships around getting the client to > access the RS: > > 1. RS trusts AS-RS to issue tokens that RS will accept, validate, and > process for requests from client > 2. Client trusts AS-RS to issue tokens that client can use at RS > 3. RO trusts RS to protect RO=E2=80=99s api through delegated access > > On top of that, we=E2=80=99ve got some additional aspects that we=E2=80= =99re discussing: > > 4. RO trusts AS-RO to manage RO=E2=80=99s policies at runtime > 5. AS-RS trusts AS-RO to assert RO=E2=80=99s policies for access to RS > 6. Client trusts whatever AS-RS sends client to deal with, including > possibly RO-AS at runtime, because of (2) > > What I have been saying is that 4/5/6 are optional details of how RS-AS > runs things, and I think this also maps with Adrian=E2=80=99s view of cho= ice, since > if my RS=E2=80=99s AS-RS doesn=E2=80=99t allow me to plug in my own AS-RO= then I would be > motivated to pick a different RS who=E2=80=99s AS-RS lets me do just that= . The same > way I=E2=80=99d pick a different RS if their surrounding services didn=E2= =80=99t accept my > preferred federation login and I didn=E2=80=99t want to make another acco= unt. Of > course, market forces being as they are, I might not have much of an > actionable choice in RS, but GNAP can=E2=80=99t change that. > > What we can do is make it possible for AS-RS to talk to AS-RO, both in > philosophy of the protocol design and in concrete hooks to support (6) > above. > > Separately, we can approach the issue of making 1/2 above more dynamic. > This was UMA2=E2=80=99s =E2=80=9Cfederated authorization=E2=80=9D approac= h, and is behind a lot of > the =E2=80=9Cbring your own AS=E2=80=9D models out there. The problem wit= h these is that we > know from many years of experience that most RS=E2=80=99s aren=E2=80=99t = interested in > doing anything of the sort. > > So with GNAP we can instead allow 4/5/6 to vary in a predictable and > consistent way, letting the RS keep control over 1/2, thereby enabling > choice in (3). We don=E2=80=99t have to be the ones who define the all of= the > details of every permutation of (5) to enable this, though. Some of this = is > going to be configuration out of band, some of it=E2=80=99s going to be > communication at runtime. This is where VC=E2=80=99s, ZCAPs, CHAPI, DIDCo= mm, FIDO, > and a whole swath of other tech can come in and help out. I don=E2=80=99t= think we > need to put all the details for using these into core, nor do I think we= =E2=80=99ll > pull of The Great And Ultimate Abstraction for using these and other > approaches. But we can at least start talking about =E2=80=9CAS-RS=E2=80= =9D in such a way > that it no longer assumes it=E2=80=99s always the same party dealing with= the RO > directly. > > =E2=80=94 Justin > > On Mar 25, 2021, at 6:40 AM, Fabien Imbault > wrote: > > To reframe it closer to GNAP: > - AS =3D AS-RO, that's where you find the RO policies. The AS issues acce= ss > tokens to the client. > - the RO policies could be a) defined locally or b) in relationship with > the RS > > There have been several ideas related to the AS-RS relationship b: > b1) the RS issues capabilities (which can be further attenuated by the RO= ) > b2) Adrian also discussed a DID based solution > b3) there was also an alternative ACL proposal from Denis (+ preflight) > > Fabien > > > On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault > wrote: > >> Ok so I get you correctly: >> - what matters is the RQ (could be a RO or a end-user or both : we don't >> really care at a high-level, they're all treated as entities that make a >> request) >> - the policy is able to handle those different cases, based on its own >> internal delegation protocol >> - currently that requires AS-RS and AS-RO, but maybe it can be simplifie= d >> >> To answer to Denis, here's what I understood: >> - RO trusts AS-RS (and then handles its own policies within AS-RO) >> - end-user trusts AS-RO (through its client) >> >> Could probably work but that's a fairly different model compared to >> OAuth2 (and of today's GNAP), with different frontiers between the AS an= d >> the RS. >> >> Please do not hesitate to correct me if I'm wrong. >> >> Fabien >> >> On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper >> wrote: >> >>> I believe there are alternatives to having two kinds of ASs. The proble= m >>> may be a side-effect of deciding to switch away form treating the RO as >>> different from the RQ. That leads to downstream privacy issues. Our des= ire >>> for architectural simplicity is admirable but that may have been a step= too >>> far. >>> >>> There may also be solutions based on different types of tokens, as in >>> different capabilities (tokens signed by the RS) vs. tokens signed by t= he >>> AS. I=E2=80=99m not sure about that but Alan might have more to say. >>> >>> Adrian >>> >>> On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault >>> wrote: >>> >>>> Thanks. The general problem statement is clear. >>>> >>>> The proposed solution a bit less (to me). I understood that from point >>>> 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obvious reason = to have >>>> two types of ASs". Do you see an alternative ? >>>> >>>> Regarding the last item, I don't think that naming RQ by end-user >>>> created the problem. It might just highlight the asymmetry, which >>>> fundamentally exists. >>>> >>>> Fabien >>>> >>>> >>>> On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper >>>> wrote: >>>> >>>>> Recap: >>>>> 1 - Justin (I think) introduced the idea of an AS on the RS trust >>>>> boundary side. >>>>> 2 - I said the RO should not have to share policies with the RS. >>>>> 3 - Alan invented the concept of AS-RO and AS-RS to separate two kind= s >>>>> of PDPs. >>>>> >>>>> The thing is that step 2 is not symmetrical. The RO has a legitimate >>>>> privacy interest in keeping their policies private and minimizing the >>>>> leakage of information about requests that are posed against those >>>>> policies. >>>>> >>>>> The RS, on the other hand, should be publishing its policies (e.g. >>>>> what it=E2=80=99s selling or what jurisdiction it=E2=80=99s in or wha= t tokens or scopes it >>>>> supports). The RS has no obvious privacy interest in GNAP. It=E2=80= =99s just an >>>>> enforcer. >>>>> >>>>> There is one other privacy interest to consider around the RS and tha= t >>>>> is the requesting party (the end-user that is not the RO :-) might pr= efer >>>>> to share attributes with the RS instead of the RO or something contro= lled >>>>> by the RO. This case could be an =E2=80=9Cextension=E2=80=9D to GNAP = and might result in a >>>>> split AS as a solution. This problem was introduced when the editors >>>>> decided to replace RQ with end-user. Obviously, the RO end-user has n= o >>>>> privacy interests relative to itself. >>>>> >>>>> Adrian >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> I was referring to "By my definition, this model has two ASs since >>>>>> both are processing requests into tokens". If there's no reason to h= ave 2 >>>>>> types of ASs, that's fine then. >>>>>> But I'm a bit lost in where we stand with the idea. >>>>>> >>>>>> Could you recap? >>>>>> >>>>>> Fabien >>>>>> >>>>>> Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper >>>>>> a =C3=A9crit : >>>>>> >>>>>>> There=E2=80=99s no obvious reason to have two types of ASs. Any AS = that is >>>>>>> executing the policies of the RS can look to GNAP like the RS itsel= f. Why >>>>>>> would GNAP expose that interface to anyone? >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>> On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>> >>>>>>>> Note : I'm not sure that's a good idea, but having 2 types of ASs >>>>>>>> is not that easy to grasp. >>>>>>>> >>>>>>>> Fabien >>>>>>>> >>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com> a =C3=A9crit : >>>>>>>> >>>>>>>>> The purpose of either handling policies locally or delegating the= m >>>>>>>>> to the RO agent. >>>>>>>>> >>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper < >>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>> >>>>>>>>>> What purpose would be served by GNAP splitting the AS into two >>>>>>>>>> components? >>>>>>>>>> >>>>>>>>>> Adrian >>>>>>>>>> >>>>>>>>>> On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault < >>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Isn't the AS-RO a component of the AS? Same idea as the interac= t >>>>>>>>>>> component, it functionnally belongs to the AS role but could be= deployed >>>>>>>>>>> either as a monolith or as a separate component? >>>>>>>>>>> >>>>>>>>>>> Fabien >>>>>>>>>>> >>>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper < >>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>> >>>>>>>>>>>> Yes, but I would say it=E2=80=99s not the RO that wants the ac= cess >>>>>>>>>>>> token. It=E2=80=99s the RO that wants the client making the re= quest to get an >>>>>>>>>>>> access token. >>>>>>>>>>>> >>>>>>>>>>>> Adrian >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Mar 24, 2021 at 11:22 PM Alan Karp >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Adrian Gropper wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> In this design, the AS is the AS-RS and the agent is the >>>>>>>>>>>>>> AS-RO. By my definition, this model has two ASs since both a= re processing >>>>>>>>>>>>>> requests into tokens. The problem with this is complexity an= d privacy. The >>>>>>>>>>>>>> RO may not want to share the request information with the AS= -RS. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> More precisely, RO has no choice but to present the required >>>>>>>>>>>>> information to AS-RS if RO wants an access token. However, R= O does not >>>>>>>>>>>>> want AS-RS to know the policy by which RO delegates tokens. = That's why RO >>>>>>>>>>>>> uses AS-RO for those delegations. >>>>>>>>>>>>> >>>>>>>>>>>>> -------------- >>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper < >>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you for creating the issue. My definition of AS is >>>>>>>>>>>>>> independent of AS-RO or AS-RS. >>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/22= 3#issuecomment-806280421 >>>>>>>>>>>>>> I also agree with Alan's definition based on delegation. An = AS-RS would be >>>>>>>>>>>>>> a delegate of the RS. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Based on that, I see it as obvious that the policy has to be >>>>>>>>>>>>>> accessible (defined locally?) in order for it to be run as t= he code that >>>>>>>>>>>>>> turns a request into an access token. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The only other possibility is that the request is packaged b= y >>>>>>>>>>>>>> the AS and sent elsewhere (an agent) for evaluation against = policy and a >>>>>>>>>>>>>> proto-token returned. In that case the AS is acting as a pro= xy and the PDP >>>>>>>>>>>>>> is elsewhere. I can imagine that an AS-RS would behave this = way so that the >>>>>>>>>>>>>> proto-token could be turned into an access token by the AS-R= S. Isn't this >>>>>>>>>>>>>> what Justin is proposing? In this design, the AS is the AS-R= S and the agent >>>>>>>>>>>>>> is the AS-RO. By my definition, this model has two ASs since= both are >>>>>>>>>>>>>> processing requests into tokens. The problem with this is co= mplexity and >>>>>>>>>>>>>> privacy. The RO may not want to share the request informatio= n with the >>>>>>>>>>>>>> AS-RS. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault < >>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Isn't that what the AS is supposed to be, only with the >>>>>>>>>>>>>>> caveat that the policy is defined locally? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp >>>>>>>>>>>>>>> a =C3=A9crit : >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> AS-RO is an AS that RO trusts to delegate RO's access >>>>>>>>>>>>>>>> tokens according to RO's policies. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault < >>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Alan and Adrian, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I've created issue AS-RO policy delegation ( >>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues= /223) >>>>>>>>>>>>>>>>> to capture your input. >>>>>>>>>>>>>>>>> A first question that arises: can we give a definition to >>>>>>>>>>>>>>>>> AS-RO? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp < >>>>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Fabien Imbault wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Yes, but in that flow, the token relationship between >>>>>>>>>>>>>>>>>>> AS-RS and AS-RO is only secure if the tokens issued by = AS-RS are >>>>>>>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Attenuated delegation is a requirement, but that doesn't >>>>>>>>>>>>>>>>>> have to be done cryptographically. Token exchange works= just fine. SPKI >>>>>>>>>>>>>>>>>> and zcap-ld are examples of the crypto approach, and we = used token exchange >>>>>>>>>>>>>>>>>> in the system for HP. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault < >>>>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Yes, but in that flow, the token relationship between >>>>>>>>>>>>>>>>>>> AS-RS and AS-RO is only secure if the tokens issued by = AS-RS are >>>>>>>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp < >>>>>>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Justin Richer wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> But with all that in mind, I think the key here is >>>>>>>>>>>>>>>>>>>>> going to be looking at what the inputs to the AS are,= and how those can be >>>>>>>>>>>>>>>>>>>>> defined in an interoperable way for AS=E2=80=99s that= can accept them. I think >>>>>>>>>>>>>>>>>>>>> there=E2=80=99s a lot of room for innovation and flex= ibility here that doesn=E2=80=99t >>>>>>>>>>>>>>>>>>>>> break the trust model or core use cases. If I have an= AS-RS set that won=E2=80=99t >>>>>>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine inputs, th= en I can decide not to >>>>>>>>>>>>>>>>>>>>> use that one. But this is a very different question t= han saying the RS >>>>>>>>>>>>>>>>>>>>> itself needs to accept my own AS =E2=80=94 and we can= =E2=80=99t keep conflating these two >>>>>>>>>>>>>>>>>>>>> models. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I agree. The point of having an AS-RO is to allow RO >>>>>>>>>>>>>>>>>>>> to specify a policy for which of RO's access tokens sh= ould be delegated >>>>>>>>>>>>>>>>>>>> under what conditions. AS-RS should not need to under= stand those >>>>>>>>>>>>>>>>>>>> policies. The flow would be >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> - RO contacts AS-RS and gets one or more access >>>>>>>>>>>>>>>>>>>> tokens. >>>>>>>>>>>>>>>>>>>> - RO delegates one or more of those tokens, >>>>>>>>>>>>>>>>>>>> potentially sub-scoped, to AS-RO. >>>>>>>>>>>>>>>>>>>> - A different user contacts AS-RO to get a >>>>>>>>>>>>>>>>>>>> potentially sub-scoped access token from AS-RO. >>>>>>>>>>>>>>>>>>>> - That user presents the access token delegated by >>>>>>>>>>>>>>>>>>>> AS-RO when invoking the resource. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> AS-RS only needs to verify that the delegation chain i= s >>>>>>>>>>>>>>>>>>>> legitimate, e.g., no increase in scope, and that it gr= ants permission for >>>>>>>>>>>>>>>>>>>> the request being made. AS-RS does not need to unders= tand the policy >>>>>>>>>>>>>>>>>>>> behind granting the delegation by AS-RO. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer < >>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I think this shows the problem with the terminology a= s >>>>>>>>>>>>>>>>>>>>> it=E2=80=99s been applied in this conversation, which= I=E2=80=99ve tried to shine light on >>>>>>>>>>>>>>>>>>>>> before. What you and others are calling the =E2=80=9C= RS=E2=80=9D is really the =E2=80=9CAS and RS >>>>>>>>>>>>>>>>>>>>> working together=E2=80=9D =E2=80=94 everything to the= right of the line. When Denis had >>>>>>>>>>>>>>>>>>>>> brought up =E2=80=9Celiminating the AS=E2=80=9D in an= other thread, what he=E2=80=99d really done is >>>>>>>>>>>>>>>>>>>>> labeled everything to the right of the line as the = =E2=80=9CRS=E2=80=9D. Of course, the >>>>>>>>>>>>>>>>>>>>> irony here is that everything to the right of the lin= e used all be called >>>>>>>>>>>>>>>>>>>>> the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2= =80=9D in the OAuth 1 days. As you say below, I don=E2=80=99t >>>>>>>>>>>>>>>>>>>>> want the client to have visibility on what happens on= that side. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Note well: The Google+ logo labeled =E2=80=9CIdP=E2= =80=9D in the >>>>>>>>>>>>>>>>>>>>> diagram is not the AS, as far as GNAP is concerned. I= t does not issue an >>>>>>>>>>>>>>>>>>>>> access token that the RS will accept. The elements to= the left of the line >>>>>>>>>>>>>>>>>>>>> could be a lot of things, but they are NOT the AS =E2= =80=94 by definition. The >>>>>>>>>>>>>>>>>>>>> client lives over on the left, but so do any external= inputs to the AS. >>>>>>>>>>>>>>>>>>>>> These could be policy inputs on behalf of the RO, the= y could be >>>>>>>>>>>>>>>>>>>>> presentation artifacts, they could be federated login= s, they could be the >>>>>>>>>>>>>>>>>>>>> output of policy decisions. How the AS comes to trust= those things is up to >>>>>>>>>>>>>>>>>>>>> the AS=E2=80=99s implementation. It=E2=80=99s somethi= ng we can talk about, but ultimately >>>>>>>>>>>>>>>>>>>>> GNAP won=E2=80=99t be in any position to dictate beca= use in practice some AS=E2=80=99s are >>>>>>>>>>>>>>>>>>>>> simply going to internalize all policies and we will = never successfully >>>>>>>>>>>>>>>>>>>>> force those open. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> But with all that in mind, I think the key here is >>>>>>>>>>>>>>>>>>>>> going to be looking at what the inputs to the AS are,= and how those can be >>>>>>>>>>>>>>>>>>>>> defined in an interoperable way for AS=E2=80=99s that= can accept them. I think >>>>>>>>>>>>>>>>>>>>> there=E2=80=99s a lot of room for innovation and flex= ibility here that doesn=E2=80=99t >>>>>>>>>>>>>>>>>>>>> break the trust model or core use cases. If I have an= AS-RS set that won=E2=80=99t >>>>>>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine inputs, th= en I can decide not to >>>>>>>>>>>>>>>>>>>>> use that one. But this is a very different question t= han saying the RS >>>>>>>>>>>>>>>>>>>>> itself needs to accept my own AS =E2=80=94 and we can= =E2=80=99t keep conflating these two >>>>>>>>>>>>>>>>>>>>> models. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> So to me, GNAP can support a Zero Trust Architecture >>>>>>>>>>>>>>>>>>>>> by LEVERAGING the AS, not by subsuming or eliminating= it. It is in fact the >>>>>>>>>>>>>>>>>>>>> AS, not the client and not the RS, that will request = and consume the >>>>>>>>>>>>>>>>>>>>> results of a privacy-preserving zero-trust policy que= ry thing. Anything >>>>>>>>>>>>>>>>>>>>> that happens downstream from that is of little concer= n to the zero-trust >>>>>>>>>>>>>>>>>>>>> components because, as you point out, it=E2=80=99s on= the =E2=80=9Cother side=E2=80=9D of the line. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I think we got this basic component model pretty righ= t >>>>>>>>>>>>>>>>>>>>> in OAuth: the AS and RS and client working together. = Where OAuth misses the >>>>>>>>>>>>>>>>>>>>> mark is the assumption that the user has to log in to= the AS through a >>>>>>>>>>>>>>>>>>>>> webpage and interact directly, thereby proving they= =E2=80=99re the RO. It=E2=80=99s this >>>>>>>>>>>>>>>>>>>>> latter space where I think we can both push innovatio= n and also address the >>>>>>>>>>>>>>>>>>>>> important and compelling use cases like the ones you= =E2=80=99re bringing. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper < >>>>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I'm sorry, Justin. As a Resource Owner, I look at the >>>>>>>>>>>>>>>>>>>>> RS trust boundary (the dotted line in the diagram) as= being the RS. I don't >>>>>>>>>>>>>>>>>>>>> expect any visibility into what's going on on the rig= ht. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> My problem with the framing you propose is that >>>>>>>>>>>>>>>>>>>>> requests are going to the RS (or the AS-RS) and I don= 't want to share my >>>>>>>>>>>>>>>>>>>>> policies with the AS-RS. I want to keep the RS and AS= -RS as ignorant as >>>>>>>>>>>>>>>>>>>>> possible. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer < >>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> What you=E2=80=99re discussing below, in terms of lo= gging in >>>>>>>>>>>>>>>>>>>>>> to a site, is not approaching the RS. You are in fac= t approaching the >>>>>>>>>>>>>>>>>>>>>> client, and identifying both the AS and RS to the cl= ient. The client is a >>>>>>>>>>>>>>>>>>>>>> client *of your identity* in this model, and the RS >>>>>>>>>>>>>>>>>>>>>> is part of the identity provider. It=E2=80=99s reall= y important that we don=E2=80=99t >>>>>>>>>>>>>>>>>>>>>> conflate the RS and client in this way as it leads t= o a lot of confusion >>>>>>>>>>>>>>>>>>>>>> downstream and a lot of broken trust boundaries. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> With that model in mind, approaching the =E2=80=9CRS= " and >>>>>>>>>>>>>>>>>>>>>> providing it your identity is really just a case of = the =E2=80=9Cfederated login to >>>>>>>>>>>>>>>>>>>>>> AS=E2=80=9D pattern that we discussed on the WG call= . The user here approaches an >>>>>>>>>>>>>>>>>>>>>> RS, which has its own AS. To share things from this = RS, the RO has to >>>>>>>>>>>>>>>>>>>>>> authenticate to the RS=E2=80=99s AS. This particular= AS allows the RO to do so >>>>>>>>>>>>>>>>>>>>>> using an external identity =E2=80=94 in which case, = the AS is now a =E2=80=9Cclient=E2=80=9D of a >>>>>>>>>>>>>>>>>>>>>> separate, disconnected (but layered) delegation. The= ultimate client that >>>>>>>>>>>>>>>>>>>>>> eventually calls the RS down the way may or may not = know about these >>>>>>>>>>>>>>>>>>>>>> layers. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> This same AS, which is closely tied to the RS and >>>>>>>>>>>>>>>>>>>>>> trusted by the RS, might also take in FIDO credentia= ls, or DIDs, or any >>>>>>>>>>>>>>>>>>>>>> number of other proof mechanisms. The output of this= is an access token the >>>>>>>>>>>>>>>>>>>>>> RS trusts, but the input is up to the AS. The RS is = not what you=E2=80=99re logging >>>>>>>>>>>>>>>>>>>>>> in to. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper < >>>>>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I too am in favor of avoiding consolidation and >>>>>>>>>>>>>>>>>>>>>> correlation. Right now, when I approach a service pr= ovider (RS) for the >>>>>>>>>>>>>>>>>>>>>> first time, I'm offered the opportunity to identify = my persona as: email, >>>>>>>>>>>>>>>>>>>>>> sign-in with Google, Facebook, or Apple. I know ther= e are people who try to >>>>>>>>>>>>>>>>>>>>>> create one-off email addresses but that is mostly a = waste of time. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> So, along come FIDO2 and DID wallets to the rescue. >>>>>>>>>>>>>>>>>>>>>> Now, in theory, I have a way to start out my RS rela= tionship >>>>>>>>>>>>>>>>>>>>>> pseudonymously. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> When I want my resource to be discovered or shared I >>>>>>>>>>>>>>>>>>>>>> will post that RS URL including my pseudonym. If I t= hen want to introduce a >>>>>>>>>>>>>>>>>>>>>> mediator in front of my AS or messaging service endp= oint, I have that >>>>>>>>>>>>>>>>>>>>>> option. If I want to keep requests away from the med= iator, I would publish >>>>>>>>>>>>>>>>>>>>>> an encryption key along with my pseudonym. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> - Adrian >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer < >>>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk < >>>>>>>>>>>>>>>>>>>>>>> kaduk@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian >>>>>>>>>>>>>>>>>>>>>>> Gropper wrote: >>>>>>>>>>>>>>>>>>>>>>> >> @Alan Karp shared a talk >>>>>>>>>>>>>>>>>>>>>>> about the Principle Of Least >>>>>>>>>>>>>>>>>>>>>>> >> Authority (POLA) in a recent comment >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/= issues/145#issuecomment-803099693 >>>>>>>>>>>>>>>>>>>>>>> >> I recommend it. >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> We might expect a protocol with authorization in >>>>>>>>>>>>>>>>>>>>>>> the title to use authority >>>>>>>>>>>>>>>>>>>>>>> >> as a core principle. I advocate for a GNAP desig= n >>>>>>>>>>>>>>>>>>>>>>> that maximizes the power >>>>>>>>>>>>>>>>>>>>>>> >> of the RO, to be seen as a human rights issue >>>>>>>>>>>>>>>>>>>>>>> when the RO is a human. This >>>>>>>>>>>>>>>>>>>>>>> >> causes me to ask how to combine better security >>>>>>>>>>>>>>>>>>>>>>> with better human rights in >>>>>>>>>>>>>>>>>>>>>>> >> GNAP. >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> Who should have the least authority in the GNAP >>>>>>>>>>>>>>>>>>>>>>> design? >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> The AS derives authority as a delegate of the RO= . >>>>>>>>>>>>>>>>>>>>>>> If we ask the RO to >>>>>>>>>>>>>>>>>>>>>>> >> partition limited authority across dozens of >>>>>>>>>>>>>>>>>>>>>>> different ASs by domain and >>>>>>>>>>>>>>>>>>>>>>> >> function, then we are not using technology to >>>>>>>>>>>>>>>>>>>>>>> empower the individual. >>>>>>>>>>>>>>>>>>>>>>> >> Probably the opposite, as we introduce consent >>>>>>>>>>>>>>>>>>>>>>> fatigue and burden normal >>>>>>>>>>>>>>>>>>>>>>> >> people to partition their lives into >>>>>>>>>>>>>>>>>>>>>>> non-overlapping domains. >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> My experience says we should aim for one AS per >>>>>>>>>>>>>>>>>>>>>>> persona because that maps >>>>>>>>>>>>>>>>>>>>>>> >> into the way we manage our public and private >>>>>>>>>>>>>>>>>>>>>>> identities. POLA would then >>>>>>>>>>>>>>>>>>>>>>> >> teach care in keeping ASs and RSs related to wor= k >>>>>>>>>>>>>>>>>>>>>>> / public separate from >>>>>>>>>>>>>>>>>>>>>>> >> ASs and RSs related to private life so that a >>>>>>>>>>>>>>>>>>>>>>> policy vulnerability in our >>>>>>>>>>>>>>>>>>>>>>> >> delegation to an AS would have the least >>>>>>>>>>>>>>>>>>>>>>> likelihood of harm. >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > Thinking about how least authority/least privileg= e >>>>>>>>>>>>>>>>>>>>>>> would apply to GNAP >>>>>>>>>>>>>>>>>>>>>>> > seems like a useful exercise. I do want to point >>>>>>>>>>>>>>>>>>>>>>> out some potential >>>>>>>>>>>>>>>>>>>>>>> > pitfalls with one-AS-per-persona that we can also >>>>>>>>>>>>>>>>>>>>>>> be aware of. If >>>>>>>>>>>>>>>>>>>>>>> > one-AS-per-persona becomes one-persona-per-AS as >>>>>>>>>>>>>>>>>>>>>>> well, then the AS's >>>>>>>>>>>>>>>>>>>>>>> > identity in effect also serves as a persona >>>>>>>>>>>>>>>>>>>>>>> identity and there are privacy >>>>>>>>>>>>>>>>>>>>>>> > considerations to that. If, on the other hand, t= he >>>>>>>>>>>>>>>>>>>>>>> > multiple-personas-per-AS (presumably correspondin= g >>>>>>>>>>>>>>>>>>>>>>> to multiple humans) >>>>>>>>>>>>>>>>>>>>>>> > route is taken, we should consider whether that >>>>>>>>>>>>>>>>>>>>>>> would lead to various >>>>>>>>>>>>>>>>>>>>>>> > (e.g., market) forces driving consolidation to >>>>>>>>>>>>>>>>>>>>>>> just a handful of >>>>>>>>>>>>>>>>>>>>>>> > super-popular AS services. That topic is a >>>>>>>>>>>>>>>>>>>>>>> current matter of concern to >>>>>>>>>>>>>>>>>>>>>>> > some IETF participants. >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Hi Ben, big +1 to this. This is something that we >>>>>>>>>>>>>>>>>>>>>>> discussed ages ago in the UMA working group, and it= =E2=80=99s one of the biggest >>>>>>>>>>>>>>>>>>>>>>> problems with the personal AS (and personal data st= ore) model. This kind of >>>>>>>>>>>>>>>>>>>>>>> thing makes RS-first trust models really difficult = in practice. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve = got software that >>>>>>>>>>>>>>>>>>>>>>> wants to access my medical information. It calls an= RS and requests access, >>>>>>>>>>>>>>>>>>>>>>> but it hasn=E2=80=99t been granted anything yet. No= w I as the RO have set up the RS >>>>>>>>>>>>>>>>>>>>>>> so that it talks to my personal AS, that only I use= . In addition to the RS >>>>>>>>>>>>>>>>>>>>>>> having to be able to figure out which medical recor= ds are being requested >>>>>>>>>>>>>>>>>>>>>>> from the context of the unauthenticated request (wh= ich means it needs >>>>>>>>>>>>>>>>>>>>>>> identifiers in the URL or something similar for the= RS to be able to tell, >>>>>>>>>>>>>>>>>>>>>>> assuming that it protects data for more than one pe= rson). So this client >>>>>>>>>>>>>>>>>>>>>>> software doesn=E2=80=99t know who I am and doesn=E2= =80=99t know my medical record >>>>>>>>>>>>>>>>>>>>>>> information, makes a completely unauthorized reques= t to the RS, and the RS >>>>>>>>>>>>>>>>>>>>>>> says =E2=80=9CGo to Justin=E2=80=99s personal AS to= get a token=E2=80=9D. The client can now make a >>>>>>>>>>>>>>>>>>>>>>> direct correlation between the data that=E2=80=99s = being protected at the RS and >>>>>>>>>>>>>>>>>>>>>>> the person running the AS that protects it. Importa= ntly, this client makes >>>>>>>>>>>>>>>>>>>>>>> this call with no prior relationship to the RS and = no really auditable way >>>>>>>>>>>>>>>>>>>>>>> to track it down after the fact. This is a design f= eature in the good case, >>>>>>>>>>>>>>>>>>>>>>> and terrifying in the bad case. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> If the RS instead says =E2=80=9Cwelcome to Medicine= Doctor >>>>>>>>>>>>>>>>>>>>>>> RS, please talk to the Medicine Doctor AS to get ac= cess=E2=80=9D, we haven=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>> exposed anything at all. And from the perspective o= f both the patient and >>>>>>>>>>>>>>>>>>>>>>> the RS, this is more privacy-preserving, and it=E2= =80=99s really the least >>>>>>>>>>>>>>>>>>>>>>> surprising option. Once the client gets to the AS, = it can start a >>>>>>>>>>>>>>>>>>>>>>> negotiation of figuring out who the RO is for the i= nformation being >>>>>>>>>>>>>>>>>>>>>>> accessed. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On top of this, the usability expectations of peopl= e >>>>>>>>>>>>>>>>>>>>>>> managing their own AS, or set of AS=E2=80=99s for m= ultiple personas to keep things >>>>>>>>>>>>>>>>>>>>>>> separate, is a huge burden. Even in the tech commun= ity, I know people who >>>>>>>>>>>>>>>>>>>>>>> can=E2=80=99t reliably manage more than one email a= ddress for different purposes. I >>>>>>>>>>>>>>>>>>>>>>> wouldn=E2=80=99t expect my partner to do that =E2= =80=94 they have trouble enough balancing >>>>>>>>>>>>>>>>>>>>>>> all the logins and sessions required for different = kids remote schooling, I >>>>>>>>>>>>>>>>>>>>>>> couldn=E2=80=99t imagine them having to understand = all the requirements for >>>>>>>>>>>>>>>>>>>>>>> managing multiple authorization servers and associa= ted policies. I also >>>>>>>>>>>>>>>>>>>>>>> don=E2=80=99t expect any person to =E2=80=9Cmanage = keys=E2=80=9D =E2=80=94 I=E2=80=99ve been on the internet for >>>>>>>>>>>>>>>>>>>>>>> decades and I can barely keep tabs on my GPG keys, = and only use them when I >>>>>>>>>>>>>>>>>>>>>>> am forced to. This is exactly the kind of =E2=80=9C= market pressure=E2=80=9D that I think >>>>>>>>>>>>>>>>>>>>>>> Ben mentions above, people will just want to outsou= rce that to someone >>>>>>>>>>>>>>>>>>>>>>> else, and the reality will be a few popular provide= rs. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> In which case, we could end up doing a ton of work >>>>>>>>>>>>>>>>>>>>>>> to allow an RS choice only to end up with a world w= here the RS ends up >>>>>>>>>>>>>>>>>>>>>>> making a limited choice anyway. We see how that pla= ys out with OpenID >>>>>>>>>>>>>>>>>>>>>>> Connect =E2=80=94 RP=E2=80=99s could allow arbitrar= y IdPs but they choose Google because it >>>>>>>>>>>>>>>>>>>>>>> works and that=E2=80=99s where the users are. (And = that=E2=80=99s not to say anything of >>>>>>>>>>>>>>>>>>>>>>> the proprietary OIDC-like protocols, but that=E2=80= =99s another discussion). >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> For further reading on these topics, I recommend >>>>>>>>>>>>>>>>>>>>>>> both =E2=80=9CWhy Johnny Can=E2=80=99t Encrypt=E2= =80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> So what does this have to do with GNAP? I think we >>>>>>>>>>>>>>>>>>>>>>> can be clear-eyed on what kinds of expectations we = have for the >>>>>>>>>>>>>>>>>>>>>>> participants. If we expect users (RO=E2=80=99s) to = have to set up the AS-RS >>>>>>>>>>>>>>>>>>>>>>> relationship, or expect them to carry their AS, or = manage their personal >>>>>>>>>>>>>>>>>>>>>>> keys =E2=80=94 I think we=E2=80=99ve lost the battl= e for relevance. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>> > --000000000000bae5ce05be5c5134 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Thanks for the summary Justin. You very c= learly articulated what I would call the "regulatory capture" asp= ects of the problem. The RS will do everything they can to avoid ceding pow= er to the RO. By avoiding standards that shift power to the RO, the platfor= ms, IdP's, and most other service providers delay regulation that would= promote agent-based delegated access to an API as a human right.=C2=A0
    It's only recently, with GDPR, that lawmakers=C2=A0have= =C2=A0started to consider human rights outside of healthcare and are now in= troducing concepts such as the separation of controller=C2=A0from processor= in order to enable a new generation of regulation. My perspective on GNAP = is not arbitrary. It is honed by years of experience=C2=A0in healthcare as = everyone struggles with OAuth and OpenID Connect, HEART, and now UDAP, to a= void doing in standards what seems obvious from a human rights perspective.=

    What's interesting is that the "regulato= ry capture" standards game is now playing out in a new arena. The rece= nt transition of DID to W3C Candidate Recommendation, together with Verifia= ble Credentials before that, means that every regulator (e.g. US Health and= Human Services, Scotland, EU...) and some legislatures (e.g. Wyoming) are = having to deal with the concept of Self-Sovereign Identity. It's not fu= n for the community that has worked so hard on SSI to now have to dance-aro= und the actual impact of the SSI standards.

    With V= C and DID, W3C seems to have broken through a "regulatory capture"= ; barrier and that community is moving on to standardize protocols like DID= comm and Encrypted Data Vaults that may avoid delegated authorization as a = human right. In my opinion, GNAP, and IETF, is facing the same "regula= tory capture" barrier.=C2=A0

    Justin says: &qu= ot;Of course, market forces being as they are, I might not have much of an = actionable choice in RS, but GNAP can=E2=80=99t change that." What GNA= P makes core can change the choices the market offers by making GNAP an int= eroperability badge that stands for Human-Centered Protocol. If GNAP moves = the human-centered part to an extension, then we're no better than anot= her "profile" on top of OAuth.

    Adrian

    On Thu, Mar 25, 2021 at 8:46 AM Justin Richer <jricher@mit.edu> wrote:
    The way I= =E2=80=99m thinking about Adrian=E2=80=99s use case is that what we=E2=80= =99re calling the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an =E2=80=9CAS=E2= =80=9D in the traditional OAuth/GNAP sense, at least not exactly. This is t= he agent that the RO can use to set policies and manage consent on their be= half, and I=E2=80=99ve been arguing that it fits better into this vaguely-d= efined =E2=80=9Cinteraction component=E2=80=9D aspect of the current AS def= inition, and it=E2=80=99s not currently separated from the AS definition. T= he =E2=80=9CAS-RS=E2=80=9D maps to what we=E2=80=99d call the =E2=80=9CAS= =E2=80=9D in OAuth/GNAP traditionally, it=E2=80=99s what the RS trusts to i= ssue tokens. In traditional OAuth the AS-RO and AS-RS are always the same t= hing, from a functional protocol perspective. An important point here is th= at from a client=E2=80=99s perspective, they=E2=80=99re only talking to the= AS-RS since that=E2=80=99s where the client gets its tokens, because at th= e end of the day the client just wants to call the API at the RS and doesn= =E2=80=99t care how that happens (from a protocol standpoint).=C2=A0
    Note well: Even thought I don=E2=80=99t believe that =E2=80=9C= AS-RO=E2=80=9D is an authorization server at all, I=E2=80=99m going to keep= using that term below for consistency with previous discussion.
    =
    So we have these fundamental relationships around getting th= e client to access the RS:

    1. RS trusts=C2=A0AS-RS= =C2=A0to issue tokens that RS will accept, validate, and process for reques= ts from client
    2. Client trusts=C2=A0AS-RS=C2=A0to issue tokens t= hat client can use at RS
    3. RO trusts RS to protect RO=E2=80=99s = api through delegated access

    On top of that, we=E2= =80=99ve got some additional aspects that we=E2=80=99re discussing:

    4. RO trusts=C2=A0AS-RO=C2=A0to manage RO=E2=80=99s polic= ies at runtime
    5.=C2=A0AS-RS=C2=A0trusts=C2=A0AS-RO=C2=A0to asser= t RO=E2=80=99s policies for access to RS
    6. Client trusts whateve= r=C2=A0AS-RS=C2=A0sends client to deal with, including possibly RO-AS at ru= ntime, because of (2)

    What I have been saying is t= hat 4/5/6 are optional details of how RS-AS runs things, and I think this a= lso maps with Adrian=E2=80=99s view of choice, since if my RS=E2=80=99s AS-= RS doesn=E2=80=99t allow me to plug in my own AS-RO then I would be motivat= ed to pick a different RS who=E2=80=99s AS-RS lets me do just that. The sam= e way I=E2=80=99d pick a different RS if their surrounding services didn=E2= =80=99t accept my preferred federation login and I didn=E2=80=99t want to m= ake another account. Of course, market forces being as they are, I might no= t have much of an actionable choice in RS, but GNAP can=E2=80=99t change th= at.=C2=A0

    What we can do is make it possible for A= S-RS to talk to AS-RO, both in philosophy of the protocol design and in con= crete hooks to support (6) above.=C2=A0

    Separately= , we can approach the issue of making 1/2 above more dynamic. This was UMA2= =E2=80=99s =E2=80=9Cfederated authorization=E2=80=9D approach, and is behin= d a lot of the =E2=80=9Cbring your own AS=E2=80=9D models out there. The pr= oblem with these is that we know from many years of experience that most RS= =E2=80=99s aren=E2=80=99t interested in doing anything of the sort.

    So with GNAP we can instead allow 4/5/6 to vary in a pred= ictable and consistent way, letting the RS keep control over 1/2, thereby e= nabling choice in (3). We don=E2=80=99t have to be the ones who define the = all of the details of every permutation of (5) to enable this, though. Some= of this is going to be configuration out of band, some of it=E2=80=99s goi= ng to be communication at runtime. This is where VC=E2=80=99s, ZCAPs, CHAPI= , DIDComm, FIDO, and a whole swath of other tech can come in and help out. = I don=E2=80=99t think we need to put all the details for using these into c= ore, nor do I think we=E2=80=99ll pull of The Great And Ultimate Abstractio= n for using these and other approaches. But we can at least start talking a= bout =E2=80=9CAS-RS=E2=80=9D in such a way that it no longer assumes it=E2= =80=99s always the same party dealing with the RO directly.

    =C2=A0=E2=80=94 Justin

    O= n Mar 25, 2021, at 6:40 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    To reframe it closer to GNAP:
    - AS =3D AS= -RO, that's where you find the RO policies. The AS issues access tokens= to the client.
    - the RO policies could be a) defined locally or = b) in relationship with the RS

    There have been sev= eral ideas related to the AS-RS relationship b:
    b1) the RS is= sues capabilities (which can be further attenuated by the RO)
    b2)= Adrian also discussed a DID based solution
    b3) there was also an= alternative ACL proposal from Denis (+ preflight)

    Fabien


    On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbaul= t <fabien.= imbault@gmail.com> wrote:
    Ok so I get you correctly:=C2=A0
    - what matters is the RQ (could be a = RO or a end-user or both : we don't really care at a high-level, they&#= 39;re all treated as entities that make a request)
    - the policy i= s able to handle those different cases, based on its own internal delegatio= n protocol
    - currently that requires AS-RS and AS-RO, but maybe i= t can be simplified

    To answer to Denis, here's= what I understood:
    - RO trusts AS-RS (and then handles its own p= olicies within AS-RO)
    - end-user trusts AS-RO (through its cl= ient)

    Could probably work but that's a fairly = different model compared to OAuth2 (and of today's GNAP), with differen= t frontiers between the AS and the RS.=C2=A0

    Pleas= e do not hesitate to correct me if I'm wrong.

    = Fabien=C2=A0

    On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper <agropper@healthurl.co= m> wrote:
    I believe ther= e are alternatives to having two kinds of ASs. The problem may be a side-ef= fect of deciding to switch away form treating the RO as different from the = RQ. That leads to downstream privacy issues. Our desire for architectural s= implicity is admirable but that may have been a step too far.

    There may also be solutions based on = different types of tokens, as in different capabilities (tokens signed by t= he RS) vs. tokens signed by the AS. I=E2=80=99m not sure about that but Ala= n might have more to say.

    Adrian

    On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault <fabien.imbault@gmail.com= > wrote:
    Thanks. The gene= ral problem statement is clear.

    The=C2=A0proposed soluti= on a bit less (to me). I understood that from point 2, Alan involves 2 ASs.= You said : "There=E2=80=99s no obv= ious reason to have two types of ASs".=C2=A0Do you see an alter= native ?

    Regarding the last item, I don'= t think that naming RQ by end-user created the problem. It might just highl= ight the asymmetry,=C2=A0which fundamentally exists.=C2=A0

    Fabien


    On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper <agropper@healthurl.com= > wrote:
    Recap:
    1 - Justin (I think) introduced the idea of an AS on the RS = trust boundary side.
    2 - I said the RO should not ha= ve to share policies with the RS.
    3 - Alan invented = the concept of AS-RO and AS-RS to separate two kinds of PDPs.=C2=A0

    The thing is that step 2 is not= symmetrical. The RO has a legitimate privacy interest in keeping their pol= icies private and minimizing the leakage of information about requests that= are posed against those policies.=C2=A0

    <= div dir=3D"auto">The RS, on the other hand, should be publishing its polici= es (e.g. what it=E2=80=99s selling or what jurisdiction it=E2=80=99s in or = what tokens or scopes it supports). The RS has no obvious privacy interest = in GNAP. It=E2=80=99s just an enforcer.

    There is one other privacy interest to consider around the = RS and that is the requesting party (the end-user that is not the RO :-) mi= ght prefer to share attributes with the RS instead of the RO or something c= ontrolled by the RO. This case could be an =E2=80=9Cextension=E2=80=9D to G= NAP and might result in a split AS as a solution. This problem was introduc= ed when the editors decided to replace RQ with end-user. Obviously, the RO = end-user has no privacy interests relative to itself.

    Adrian




    On Thu, Mar 25, 2021 at 3= :24 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    I was referring to "By my definition, this model has two ASs since both are pro= cessing requests into tokens". If there's no reason to have 2 type= s of ASs, that's fine then.=C2=A0
    But I'm a bit lost in where we stand with the idea.= =C2=A0

    <= /div>
    Could you recap?=C2=A0

    Fabien=C2=A0=

    Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper <agropper@healthurl= .com> a =C3=A9crit=C2=A0:
    There=E2=80=99s no obvious reason to have two types of ASs. Any AS that i= s executing the policies of the RS can look to GNAP like the RS itself. Why= would GNAP expose that interface to anyone?=C2=A0
    <= br>
    Adrian

    =
    On Thu, Mar 25, 2021 at 3:11 AM Fabie= n Imbault <fabien.imbault@gmail.com> wrote:
    Note : I'm not sure that's a good idea= , but having 2 types of ASs is not that easy to grasp.

    Fabien=C2=A0
    Le jeu. = 25 mars 2021 =C3=A0 08:07, Fabien Imbault <fabien.imbault@gmail.co= m> a =C3=A9crit=C2=A0:
    T= he purpose of either handling policies locally or delegating them to the RO= agent.=C2=A0

    Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    What purpose would be served by GNAP splitting = the AS into two components?

    Adrian=C2=A0

    On Thu, Mar 25, 2021 at 2:5= 9 AM Fabien Imbault <fabien.imbault@gmail.co= m> wrote:
    Isn't the = AS-RO a component of the AS? Same idea as the interact component, it functi= onnally belongs to the AS role but could be deployed either as a monolith o= r as a separate component?

    Fabien

    Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian = Gropper <agropper@healthurl.com> a =C3= =A9crit=C2=A0:
    Yes, but I would= say it=E2=80=99s not the RO that wants the access token. It=E2=80=99s the = RO that wants the client making the request to get an access token.=C2=A0

    Adrian

    On Wed, Mar 24= , 2021 at 11:22 PM Alan Karp <alanhkar= p@gmail.com> wrote:
    Adrian Gropper <agropper@healthurl.com> wrote:

    In thi= s design, the AS is the AS-RS and the agent is the AS-RO. By my definition,= this model has two ASs since both are processing requests into tokens. The= problem with this is complexity and privacy. The RO may not want to share = the request information with the AS-RS.
    =

    More precisely, RO has no choice but t= o present the required information to AS-RS if RO wants an access token.=C2= =A0 However, RO does not want AS-RS to know the policy by which RO delegate= s tokens.=C2=A0 That's why RO uses AS-RO for those delegations.

    --------------
    Alan Karp

    <= div dir=3D"ltr">
    On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Thank you for creating the is= sue. My definition of AS is independent of AS-RO or AS-RS.=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issueco= mment-806280421 I also agree with Alan's definition based on delega= tion. An AS-RS would be a delegate of the RS.=C2=A0
    <= br>
    Based on that, I see it as obvious=C2=A0that the policy has t= o be accessible (defined locally?) in order for it to be run as the code th= at turns a request into an access token.=C2=A0

    The= only other possibility is that the request is packaged by the AS and sent = elsewhere (an agent) for evaluation against policy and a proto-token return= ed. In that case the AS is acting as a proxy and the PDP is elsewhere. I ca= n imagine that an AS-RS would behave this way so that the proto-token could= be turned into an access token by the AS-RS. Isn't this what Justin is= proposing? In this design, the AS is the AS-RS and the agent is the AS-RO.= By my definition, this model has two ASs since both are processing request= s into tokens. The problem with this is complexity and privacy. The RO may = not want to share the request information with the AS-RS.

    Adrian

    On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:<= br>
    Isn't that what the AS= is supposed to be, only with the caveat that the policy is defined locally= ?=C2=A0

    Fabien=C2=A0

    =
    Le mer= . 24 mars 2021 =C3=A0 20:17, Alan Karp <alanhkarp@gmail.com> a =C3=A9crit=C2=A0:
    AS-RO is an AS that RO trusts to delegat= e RO's access tokens according to RO's policies.=C2=A0=C2=A0

    --------------
    Alan Karp


    On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    <= /div>
    Hi Alan and Adrian,

    I've created issue AS-RO policy delegation (https://github.com/= ietf-wg-gnap/gnap-core-protocol/issues/223) to capture your input.=C2= =A0
    A first question that arises: can we give a definition to AS-= RO?

    Thanks
    Fabien

    On Tue, Mar 23, 2= 021 at 4:15 PM Alan Karp <a= lanhkarp@gmail.com> wrote:
    Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan,=C2=A0

    Yes, but in that flow= , the token relationship between AS-RS and AS-RO is only secure if the toke= ns issued by AS-RS are cryptographically attenuable in the first place.=C2= =A0
    =C2=A0
    Attenuat= ed delegation is a requirement, but that doesn't have to be done crypto= graphically.=C2=A0 Token exchange works just fine.=C2=A0 SPKI and zcap-ld a= re examples of the crypto approach, and we used token exchange in the syste= m for HP.

    --------------
    Alan Karp


    On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan,=C2=A0

    Yes, but in that flow, the token relationship between AS-RS and AS-RO is o= nly secure if the tokens issued by AS-RS are cryptographically attenuable i= n the first place.=C2=A0

    Fabien

    On Mon, Mar 2= 2, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin Richer = <jricher@mit.edu> wrote:=

    But with all that in mi= nd, I think the key here is going to be looking at what the inputs to the A= S are, and how those can be defined in an interoperable way for AS=E2=80=99= s that can accept them. I think there=E2=80=99s a lot of room for innovatio= n and flexibility here that doesn=E2=80=99t break the trust model or core u= se cases. If I have an AS-RS set that won=E2=80=99t accept my favorite flav= or of policy engine inputs, then I can decide not to use that one. But this= is a very different question than saying the RS itself needs to accept my = own AS =E2=80=94 and we can=E2=80=99t keep conflating these two models.

    I agree.=C2=A0 The point of having= an AS-RO is to allow RO to specify a policy for which of RO's access t= okens should be delegated under what conditions.=C2=A0 AS-RS should not nee= d to understand those policies.=C2=A0 The flow would be
    • R= O contacts AS-RS and gets one or more access tokens.
    • RO delegates o= ne or more of those tokens, potentially sub-scoped, to AS-RO.
    • A dif= ferent user contacts AS-RO to get a potentially sub-scoped access token fro= m AS-RO.
    • That user presents the access token delegated by AS-RO whe= n invoking the resource.
    AS-RS only needs to verif= y that the delegation chain is legitimate, e.g., no increase in scope, and = that it grants permission for the request being made.=C2=A0 AS-RS does not = need to understand the policy behind granting the delegation by AS-RO.

    --------------
    Alan Karp


    =
    On Mon, Ma= r 22, 2021 at 11:40 AM Justin Richer <jricher@mit.edu> wrote:
    Adrian= ,

    I think this shows the problem with the terminology as= it=E2=80=99s been applied in this conversation, which I=E2=80=99ve tried t= o shine light on before. What you and others are calling the =E2=80=9CRS=E2= =80=9D is really the =E2=80=9CAS and RS working together=E2=80=9D =E2=80=94= everything to the right of the line. When Denis had brought up =E2=80=9Cel= iminating the AS=E2=80=9D in another thread, what he=E2=80=99d really done = is labeled everything to the right of the line as the =E2=80=9CRS=E2=80=9D.= Of course, the irony here is that everything to the right of the line used= all be called the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80=9D = in the OAuth 1 days. As you say below, I don=E2=80=99t want the client to h= ave visibility on what happens on that side.=C2=A0

    Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the diagram i= s not the AS, as far as GNAP is concerned. It does not issue an access toke= n that the RS will accept. The elements to the left of the line could be a = lot of things, but they are NOT the AS =E2=80=94 by definition. The client = lives over on the left, but so do any external inputs to the AS. These coul= d be policy inputs on behalf of the RO, they could be presentation artifact= s, they could be federated logins, they could be the output of policy decis= ions. How the AS comes to trust those things is up to the AS=E2=80=99s impl= ementation. It=E2=80=99s something we can talk about, but ultimately GNAP w= on=E2=80=99t be in any position to dictate because in practice some AS=E2= =80=99s are simply going to internalize all policies and we will never succ= essfully force those open.=C2=A0

    But with all that= in mind, I think the key here is going to be looking at what the inputs to= the AS are, and how those can be defined in an interoperable way for AS=E2= =80=99s that can accept them. I think there=E2=80=99s a lot of room for inn= ovation and flexibility here that doesn=E2=80=99t break the trust model or = core use cases. If I have an AS-RS set that won=E2=80=99t accept my favorit= e flavor of policy engine inputs, then I can decide not to use that one. Bu= t this is a very different question than saying the RS itself needs to acce= pt my own AS =E2=80=94 and we can=E2=80=99t keep conflating these two model= s.

    So to me, GNAP can support a Zero Trust Archite= cture by LEVERAGING the AS, not by subsuming or eliminating it. It is in fa= ct the AS, not the client and not the RS, that will request and consume the= results of a privacy-preserving zero-trust policy query thing. Anything th= at happens downstream from that is of little concern to the zero-trust comp= onents because, as you point out, it=E2=80=99s on the =E2=80=9Cother side= =E2=80=9D of the line.=C2=A0

    I think we got this b= asic component model pretty right in OAuth: the AS and RS and client workin= g together. Where OAuth misses the mark is the assumption that the user has= to log in to the AS through a webpage and interact directly, thereby provi= ng they=E2=80=99re the RO. It=E2=80=99s this latter space where I think we = can both push innovation and also address the important and compelling use = cases like the ones you=E2=80=99re bringing.

    =C2= =A0=E2=80=94 Justin

    On Mar 22, 2= 021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I'm sorry, Justin. As a Resource Owner, I look at the RS trust bound= ary (the dotted line in the diagram) as being the RS. I don't expect an= y visibility into what's going on on the=C2=A0right.=C2=A0

    My problem with the framing you propose is that requests are going t= o the RS (or the AS-RS) and I don't want to share my policies with the = AS-RS. I want to keep the RS and AS-RS as ignorant as possible.
    <= br>
    Adrian

    On Mon, Mar 22, 2021 at 1:48 PM Justin Richer <= ;jricher@mit.edu> wrote:
    Adrian,

    What you=E2=80=99re= discussing below, in terms of logging in to a site, is not approaching the= RS. You are in fact approaching the client, and identifying both the AS an= d RS to the client. The client is a client of your identity in this = model, and the RS is part of the identity provider. It=E2=80=99s really imp= ortant that we don=E2=80=99t conflate the RS and client in this way as it l= eads to a lot of confusion downstream and a lot of broken trust boundaries.=

    With that model in mind, approaching the =E2=80= =9CRS" and providing it your identity is really just a case of the =E2= =80=9Cfederated login to AS=E2=80=9D pattern that we discussed on the WG ca= ll. The user here approaches an RS, which has its own AS. To share things f= rom this RS, the RO has to authenticate to the RS=E2=80=99s AS. This partic= ular AS allows the RO to do so using an external identity =E2=80=94 in whic= h case, the AS is now a =E2=80=9Cclient=E2=80=9D of a separate, disconnecte= d (but layered) delegation. The ultimate client that eventually calls the R= S down the way may or may not know about these layers.=C2=A0

    =
    <PastedGraphic-1.png><= /span>
    This same AS, which is closely tied to the RS and trusted = by the RS, might also take in FIDO credentials, or DIDs, or any number of o= ther proof mechanisms. The output of this is an access token the RS trusts,= but the input is up to the AS. The RS is not what you=E2=80=99re logging i= n to.

    =C2=A0=E2=80=94 Justin

    On Mar 22, 2021, at 1:28 PM, Adrian Gropper <agropper@healthurl.com> w= rote:

    I too am in favor of avoiding consolid= ation and correlation. Right now, when I approach a service provider (RS) f= or the first time, I'm offered the opportunity to identify my persona a= s: email, sign-in with Google, Facebook, or Apple. I know there are people = who try to create one-off email addresses but that is mostly a waste of tim= e.=C2=A0

    So, along come FIDO2 and DID wallets to the res= cue. Now, in theory, I have a way to start out my RS relationship pseudonym= ously.=C2=A0

    When I want my resource to be discove= red or shared I will post that RS URL including my pseudonym. If I then wan= t to introduce a mediator=C2=A0in front of my AS or messaging service=C2=A0= endpoint, I have that option. If I want to keep requests away from the medi= ator, I would publish an encryption key along with my pseudonym.
    =
    - Adrian



    On Mon, Mar 22, = 2021 at 9:55 AM Justin Richer <= jricher@mit.edu> wrote:
    On Mar 21, 2021, a= t 1:18 PM, Benjamin Kaduk <kaduk@= mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhk= arp@gmail.com> shared a talk about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-= gnap/gnap-core-protocol/issues/145#issuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --
    TXAuth 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
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.= ietf.org/mailman/listinfo/txauth

    --000000000000bae5ce05be5c5134-- From nobody Thu Mar 25 08:34:52 2021 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 A2E463A2598 for ; Thu, 25 Mar 2021 08:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 C14GKmYqwkdy for ; Thu, 25 Mar 2021 08:34:43 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FF773A25E4 for ; Thu, 25 Mar 2021 08:34:38 -0700 (PDT) Received: from [192.168.1.11] ([90.79.53.231]) by mwinf5d39 with ME id kfaW2400H4zJUWJ03faWmn; Thu, 25 Mar 2021 16:34:34 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Thu, 25 Mar 2021 16:34:34 +0100 X-ME-IP: 90.79.53.231 To: Adrian Gropper , Justin Richer Cc: Alan Karp , Fabien Imbault , Benjamin Kaduk , Mark Miller , GNAP Mailing List References: <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> From: Denis Message-ID: <1d9d5bed-32ff-a864-85a5-a16ee6063802@free.fr> Date: Thu, 25 Mar 2021 16:34:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CAA159ACB28604E87B5096F3" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 15:34:51 -0000 This is a multi-part message in MIME format. --------------CAA159ACB28604E87B5096F3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Since there is still no definition to explain what mean the acronyms AS-RO and AS-RS, I have created my own terminology */RO-AS/* and */RO-RS/* and wrote a full story including the definitions of a RO-AS and RO-RS. See the issue #223 https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223 Denis > Thanks for the summary Justin. You very clearly articulated what I > would call the "regulatory capture" aspects of the problem. The RS > will do everything they can to avoid ceding power to the RO. By > avoiding standards that shift power to the RO, the platforms, IdP's, > and most other service providers delay regulation that would promote > agent-based delegated access to an API as a human right. > > It's only recently, with GDPR, that lawmakers have started to consider > human rights outside of healthcare and are now introducing concepts > such as the separation of controller from processor in order to enable > a new generation of regulation. My perspective on GNAP is not > arbitrary. It is honed by years of experience in healthcare as > everyone struggles with OAuth and OpenID Connect, HEART, and now UDAP, > to avoid doing in standards what seems obvious from a human rights > perspective. > > What's interesting is that the "regulatory capture" standards game is > now playing out in a new arena. The recent transition of DID to W3C > Candidate Recommendation, together with Verifiable Credentials before > that, means that every regulator (e.g. US Health and Human Services, > Scotland, EU...) and some legislatures (e.g. Wyoming) are having to > deal with the concept of Self-Sovereign Identity. It's not fun for the > community that has worked so hard on SSI to now have to dance-around > the actual impact of the SSI standards. > > With VC and DID, W3C seems to have broken through a "regulatory > capture" barrier and that community is moving on to standardize > protocols like DIDcomm and Encrypted Data Vaults that may avoid > delegated authorization as a human right. In my opinion, GNAP, and > IETF, is facing the same "regulatory capture" barrier. > > Justin says: "Of course, market forces being as they are, I might not > have much of an actionable choice in RS, but GNAP can’t change that." > What GNAP makes core can change the choices the market offers by > making GNAP an interoperability badge that stands for Human-Centered > Protocol. If GNAP moves the human-centered part to an extension, then > we're no better than another "profile" on top of OAuth. > > Adrian > > On Thu, Mar 25, 2021 at 8:46 AM Justin Richer > wrote: > > The way I’m thinking about Adrian’s use case is that what we’re > calling the “AS-RO” isn’t an “AS” in the traditional OAuth/GNAP > sense, at least not exactly. This is the agent that the RO can use > to set policies and manage consent on their behalf, and I’ve been > arguing that it fits better into this vaguely-defined “interaction > component” aspect of the current AS definition, and it’s not > currently separated from the AS definition. The “AS-RS” maps to > what we’d call the “AS” in OAuth/GNAP traditionally, it’s what the > RS trusts to issue tokens. In traditional OAuth the AS-RO and > AS-RS are always the same thing, from a functional protocol > perspective. An important point here is that from a client’s > perspective, they’re only talking to the AS-RS since that’s where > the client gets its tokens, because at the end of the day the > client just wants to call the API at the RS and doesn’t care how > that happens (from a protocol standpoint). > > Note well: Even thought I don’t believe that “AS-RO” is an > authorization server at all, I’m going to keep using that term > below for consistency with previous discussion. > > So we have these fundamental relationships around getting the > client to access the RS: > > 1. RS trusts AS-RS to issue tokens that RS will accept, validate, > and process for requests from client > 2. Client trusts AS-RS to issue tokens that client can use at RS > 3. RO trusts RS to protect RO’s api through delegated access > > On top of that, we’ve got some additional aspects that we’re > discussing: > > 4. RO trusts AS-RO to manage RO’s policies at runtime > 5. AS-RS trusts AS-RO to assert RO’s policies for access to RS > 6. Client trusts whatever AS-RS sends client to deal with, > including possibly RO-AS at runtime, because of (2) > > What I have been saying is that 4/5/6 are optional details of how > RS-AS runs things, and I think this also maps with Adrian’s view > of choice, since if my RS’s AS-RS doesn’t allow me to plug in my > own AS-RO then I would be motivated to pick a different RS who’s > AS-RS lets me do just that. The same way I’d pick a different RS > if their surrounding services didn’t accept my preferred > federation login and I didn’t want to make another account. Of > course, market forces being as they are, I might not have much of > an actionable choice in RS, but GNAP can’t change that. > > What we can do is make it possible for AS-RS to talk to AS-RO, > both in philosophy of the protocol design and in concrete hooks to > support (6) above. > > Separately, we can approach the issue of making 1/2 above more > dynamic. This was UMA2’s “federated authorization” approach, and > is behind a lot of the “bring your own AS” models out there. The > problem with these is that we know from many years of experience > that most RS’s aren’t interested in doing anything of the sort. > > So with GNAP we can instead allow 4/5/6 to vary in a predictable > and consistent way, letting the RS keep control over 1/2, thereby > enabling choice in (3). We don’t have to be the ones who define > the all of the details of every permutation of (5) to enable this, > though. Some of this is going to be configuration out of band, > some of it’s going to be communication at runtime. This is where > VC’s, ZCAPs, CHAPI, DIDComm, FIDO, and a whole swath of other tech > can come in and help out. I don’t think we need to put all the > details for using these into core, nor do I think we’ll pull of > The Great And Ultimate Abstraction for using these and other > approaches. But we can at least start talking about “AS-RS” in > such a way that it no longer assumes it’s always the same party > dealing with the RO directly. > >  — Justin > >> On Mar 25, 2021, at 6:40 AM, Fabien Imbault >> > wrote: >> >> To reframe it closer to GNAP: >> - AS = AS-RO, that's where you find the RO policies. The AS >> issues access tokens to the client. >> - the RO policies could be a) defined locally or b) in >> relationship with the RS >> >> There have been several ideas related to the AS-RS relationship b: >> b1) the RS issues capabilities (which can be further attenuated >> by the RO) >> b2) Adrian also discussed a DID based solution >> b3) there was also an alternative ACL proposal from Denis (+ >> preflight) >> >> Fabien >> >> >> On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault >> > wrote: >> >> Ok so I get you correctly: >> - what matters is the RQ (could be a RO or a end-user or both >> : we don't really care at a high-level, they're all treated >> as entities that make a request) >> - the policy is able to handle those different cases, based >> on its own internal delegation protocol >> - currently that requires AS-RS and AS-RO, but maybe it can >> be simplified >> >> To answer to Denis, here's what I understood: >> - RO trusts AS-RS (and then handles its own policies within >> AS-RO) >> - end-user trusts AS-RO (through its client) >> >> Could probably work but that's a fairly different model >> compared to OAuth2 (and of today's GNAP), with different >> frontiers between the AS and the RS. >> >> Please do not hesitate to correct me if I'm wrong. >> >> Fabien >> >> On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper >> > wrote: >> >> I believe there are alternatives to having two kinds of >> ASs. The problem may be a side-effect of deciding to >> switch away form treating the RO as different from the >> RQ. That leads to downstream privacy issues. Our desire >> for architectural simplicity is admirable but that may >> have been a step too far. >> >> There may also be solutions based on different types of >> tokens, as in different capabilities (tokens signed by >> the RS) vs. tokens signed by the AS. I’m not sure about >> that but Alan might have more to say. >> >> Adrian >> >> On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault >> > > wrote: >> >> Thanks. The general problem statement is clear. >> >> The proposed solution a bit less (to me). I >> understood that from point 2, Alan involves 2 ASs. >> You said : "There’s no obvious reason to have two >> types of ASs". Do you see an alternative ? >> >> Regarding the last item, I don't think that naming RQ >> by end-user created the problem. It might just >> highlight the asymmetry, which fundamentally exists. >> >> Fabien >> >> >> On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper >> > > wrote: >> >> Recap: >> 1 - Justin (I think) introduced the idea of an AS >> on the RS trust boundary side. >> 2 - I said the RO should not have to share >> policies with the RS. >> 3 - Alan invented the concept of AS-RO and AS-RS >> to separate two kinds of PDPs. >> >> The thing is that step 2 is not symmetrical. The >> RO has a legitimate privacy interest in keeping >> their policies private and minimizing the leakage >> of information about requests that are posed >> against those policies. >> >> The RS, on the other hand, should be publishing >> its policies (e.g. what it’s selling or what >> jurisdiction it’s in or what tokens or scopes it >> supports). The RS has no obvious privacy interest >> in GNAP. It’s just an enforcer. >> >> There is one other privacy interest to consider >> around the RS and that is the requesting party >> (the end-user that is not the RO :-) might prefer >> to share attributes with the RS instead of the RO >> or something controlled by the RO. This case >> could be an “extension” to GNAP and might result >> in a split AS as a solution. This problem was >> introduced when the editors decided to replace RQ >> with end-user. Obviously, the RO end-user has no >> privacy interests relative to itself. >> >> Adrian >> >> >> >> >> On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault >> > > wrote: >> >> I was referring to "By my definition, this >> model has two ASs since both are processing >> requests into tokens". If there's no reason >> to have 2 types of ASs, that's fine then. >> But I'm a bit lost in where we stand with the >> idea. >> >> Could you recap? >> >> Fabien >> >> Le jeu. 25 mars 2021 à 08:16, Adrian Gropper >> > > a écrit : >> >> There’s no obvious reason to have two >> types of ASs. Any AS that is executing >> the policies of the RS can look to GNAP >> like the RS itself. Why would GNAP expose >> that interface to anyone? >> >> Adrian >> >> On Thu, Mar 25, 2021 at 3:11 AM Fabien >> Imbault > > wrote: >> >> Note : I'm not sure that's a good >> idea, but having 2 types of ASs is >> not that easy to grasp. >> >> Fabien >> >> Le jeu. 25 mars 2021 à 08:07, Fabien >> Imbault > > a >> écrit : >> >> The purpose of either handling >> policies locally or delegating >> them to the RO agent. >> >> Le jeu. 25 mars 2021 à 08:04, >> Adrian Gropper >> > > >> a écrit : >> >> What purpose would be served >> by GNAP splitting the AS into >> two components? >> >> Adrian >> >> On Thu, Mar 25, 2021 at 2:59 >> AM Fabien Imbault >> > > >> wrote: >> >> Isn't the AS-RO a >> component of the AS? Same >> idea as the interact >> component, it >> functionnally belongs to >> the AS role but could be >> deployed either as a >> monolith or as a separate >> component? >> >> Fabien >> >> Le jeu. 25 mars 2021 à >> 04:26, Adrian Gropper >> > > >> a écrit : >> >> Yes, but I would say >> it’s not the RO that >> wants the access >> token. It’s the RO >> that wants the client >> making the request to >> get an access token. >> >> Adrian >> >> On Wed, Mar 24, 2021 >> at 11:22 PM Alan Karp >> > > >> wrote: >> >> Adrian Gropper >> > > >> wrote: >> >> >> In this >> design, the >> AS is the >> AS-RS and the >> agent is the >> AS-RO. By my >> definition, >> this model >> has two ASs >> since both >> are >> processing >> requests into >> tokens. The >> problem with >> this is >> complexity >> and privacy. >> The RO may >> not want to >> share the >> request >> information >> with the AS-RS. >> >> >> More precisely, >> RO has no choice >> but to present >> the required >> information to >> AS-RS if RO wants >> an access token. >> However, RO does >> not want AS-RS to >> know the policy >> by which RO >> delegates tokens. >> That's why RO >> uses AS-RO for >> those delegations. >> >> -------------- >> Alan Karp >> >> >> On Wed, Mar 24, >> 2021 at 7:41 PM >> Adrian Gropper >> > > >> wrote: >> >> Thank you for >> creating the >> issue. My >> definition of >> AS is >> independent >> of AS-RO or >> AS-RS. >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomment-806280421 >> >> I also agree >> with Alan's >> definition >> based on >> delegation. >> An AS-RS >> would be a >> delegate of >> the RS. >> >> Based on >> that, I see >> it as >> obvious that >> the policy >> has to be >> accessible >> (defined >> locally?) in >> order for it >> to be run as >> the code that >> turns a >> request into >> an access token. >> >> The only >> other >> possibility >> is that the >> request is >> packaged by >> the AS and >> sent >> elsewhere (an >> agent) for >> evaluation >> against >> policy and a >> proto-token >> returned. In >> that case the >> AS is acting >> as a proxy >> and the PDP >> is elsewhere. >> I can imagine >> that an AS-RS >> would behave >> this way so >> that the >> proto-token >> could be >> turned into >> an access >> token by the >> AS-RS. Isn't >> this what >> Justin is >> proposing? In >> this design, >> the AS is the >> AS-RS and the >> agent is the >> AS-RO. By my >> definition, >> this model >> has two ASs >> since both >> are >> processing >> requests into >> tokens. The >> problem with >> this is >> complexity >> and privacy. >> The RO may >> not want to >> share the >> request >> information >> with the AS-RS. >> >> Adrian >> >> On Wed, Mar >> 24, 2021 at >> 5:21 PM >> Fabien >> Imbault >> > > >> wrote: >> >> Isn't >> that what >> the AS is >> supposed >> to be, >> only with >> the >> caveat >> that the >> policy is >> defined >> locally? >> >> Fabien >> >> >> Le mer. >> 24 mars >> 2021 à >> 20:17, >> Alan Karp >> > > >> a écrit : >> >> AS-RO >> is an >> AS >> that >> RO >> trusts >> to >> delegate >> RO's >> access >> tokens >> according >> to >> RO's >> policies. >> >> >> -------------- >> Alan Karp >> >> >> On >> Wed, >> Mar >> 24, >> 2021 >> at >> 9:36 >> AM >> Fabien >> Imbault >> > > >> wrote: >> >> Hi >> Alan >> and >> Adrian, >> >> >> I've >> created >> issue >> AS-RO >> policy >> delegation >> (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223 >> ) >> to >> capture >> your >> input. >> >> A >> first >> question >> that >> arises: >> can >> we >> give >> a >> definition >> to >> AS-RO? >> >> Thanks >> Fabien >> >> On >> Tue, >> Mar >> 23, >> 2021 >> at >> 4:15 >> PM >> Alan >> Karp >> > > >> wrote: >> >> Fabien >> Imbault >> > > >> wrote: >> >> Hi >> Alan, >> >> >> Yes, >> but >> in >> that >> flow, >> the >> token >> relationship >> between >> AS-RS >> and >> AS-RO >> is >> only >> secure >> if >> the >> tokens >> issued >> by >> AS-RS >> are >> cryptographically >> attenuable >> in >> the >> first >> place. >> >> >> Attenuated >> delegation >> is >> a >> requirement, >> but >> that >> doesn't >> have >> to >> be >> done >> cryptographically. >> Token >> exchange >> works >> just >> fine.  >> SPKI >> and >> zcap-ld >> are >> examples >> of >> the >> crypto >> approach, >> and >> we >> used >> token >> exchange >> in >> the >> system >> for >> HP. >> >> -------------- >> Alan >> Karp >> >> >> On >> Tue, >> Mar >> 23, >> 2021 >> at >> 4:12 >> AM >> Fabien >> Imbault >> > > >> wrote: >> >> Hi >> Alan, >> >> >> Yes, >> but >> in >> that >> flow, >> the >> token >> relationship >> between >> AS-RS >> and >> AS-RO >> is >> only >> secure >> if >> the >> tokens >> issued >> by >> AS-RS >> are >> cryptographically >> attenuable >> in >> the >> first >> place. >> >> >> Fabien >> >> On >> Mon, >> Mar >> 22, >> 2021 >> at >> 9:26 >> PM >> Alan >> Karp >> > > >> wrote: >> >> Justin >> Richer >> > > >> wrote: >> >> >> But >> with >> all >> that >> in >> mind, >> I >> think >> the >> key >> here >> is >> going >> to >> be >> looking >> at >> what >> the >> inputs >> to >> the >> AS >> are, >> and >> how >> those >> can >> be >> defined >> in >> an >> interoperable >> way >> for >> AS’s >> that >> can >> accept >> them. >> I >> think >> there’s >> a >> lot >> of >> room >> for >> innovation >> and >> flexibility >> here >> that >> doesn’t >> break >> the >> trust >> model >> or >> core >> use >> cases. >> If >> I >> have >> an >> AS-RS >> set >> that >> won’t >> accept >> my >> favorite >> flavor >> of >> policy >> engine >> inputs, >> then >> I >> can >> decide >> not >> to >> use >> that >> one. >> But >> this >> is >> a >> very >> different >> question >> than >> saying >> the >> RS >> itself >> needs >> to >> accept >> my >> own >> AS >> — >> and >> we >> can’t >> keep >> conflating >> these >> two >> models. >> >> I >> agree. >> The >> point >> of >> having >> an >> AS-RO >> is >> to >> allow >> RO >> to >> specify >> a >> policy >> for >> which >> of >> RO's >> access >> tokens >> should >> be >> delegated >> under >> what >> conditions. >> AS-RS >> should >> not >> need >> to >> understand >> those >> policies.  >> The >> flow >> would >> be >> >> * RO >> contacts >> AS-RS >> and >> gets >> one >> or >> more >> access >> tokens. >> * RO >> delegates >> one >> or >> more >> of >> those >> tokens, >> potentially >> sub-scoped, >> to >> AS-RO. >> * A >> different >> user >> contacts >> AS-RO >> to >> get >> a >> potentially >> sub-scoped >> access >> token >> from >> AS-RO. >> * That >> user >> presents >> the >> access >> token >> delegated >> by >> AS-RO >> when >> invoking >> the >> resource. >> >> AS-RS >> only >> needs >> to >> verify >> that >> the >> delegation >> chain >> is >> legitimate, >> e.g., >> no >> increase >> in >> scope, >> and >> that >> it >> grants >> permission >> for >> the >> request >> being >> made. >> AS-RS >> does >> not >> need >> to >> understand >> the >> policy >> behind >> granting >> the >> delegation >> by >> AS-RO. >> >> -------------- >> Alan >> Karp >> >> >> On >> Mon, >> Mar >> 22, >> 2021 >> at >> 11:40 >> AM >> Justin >> Richer >> > > >> wrote: >> >> Adrian, >> >> >> I >> think >> this >> shows >> the >> problem >> with >> the >> terminology >> as >> it’s >> been >> applied >> in >> this >> conversation, >> which >> I’ve >> tried >> to >> shine >> light >> on >> before. >> What >> you >> and >> others >> are >> calling >> the >> “RS” >> is >> really >> the >> “AS >> and >> RS >> working >> together” >> — >> everything >> to >> the >> right >> of >> the >> line. >> When >> Denis >> had >> brought >> up >> “eliminating >> the >> AS” >> in >> another >> thread, >> what >> he’d >> really >> done >> is >> labeled >> everything >> to >> the >> right >> of >> the >> line >> as >> the >> “RS”. >> Of >> course, >> the >> irony >> here >> is >> that >> everything >> to >> the >> right >> of >> the >> line >> used >> all >> be >> called >> the >> “AS” >> or >> simply >> “server” >> in >> the >> OAuth >> 1 >> days. >> As >> you >> say >> below, >> I >> don’t >> want >> the >> client >> to >> have >> visibility >> on >> what >> happens >> on >> that >> side. >> >> >> Note >> well: >> The >> Google+ >> logo >> labeled >> “IdP” >> in >> the >> diagram >> is >> not >> the >> AS, >> as >> far >> as >> GNAP >> is >> concerned. >> It >> does >> not >> issue >> an >> access >> token >> that >> the >> RS >> will >> accept. >> The >> elements >> to >> the >> left >> of >> the >> line >> could >> be >> a >> lot >> of >> things, >> but >> they >> are >> NOT >> the >> AS >> — >> by >> definition. >> The >> client >> lives >> over >> on >> the >> left, >> but >> so >> do >> any >> external >> inputs >> to >> the >> AS. >> These >> could >> be >> policy >> inputs >> on >> behalf >> of >> the >> RO, >> they >> could >> be >> presentation >> artifacts, >> they >> could >> be >> federated >> logins, >> they >> could >> be >> the >> output >> of >> policy >> decisions. >> How >> the >> AS >> comes >> to >> trust >> those >> things >> is >> up >> to >> the >> AS’s >> implementation. >> It’s >> something >> we >> can >> talk >> about, >> but >> ultimately >> GNAP >> won’t >> be >> in >> any >> position >> to >> dictate >> because >> in >> practice >> some >> AS’s >> are >> simply >> going >> to >> internalize >> all >> policies >> and >> we >> will >> never >> successfully >> force >> those >> open. >> >> >> But >> with >> all >> that >> in >> mind, >> I >> think >> the >> key >> here >> is >> going >> to >> be >> looking >> at >> what >> the >> inputs >> to >> the >> AS >> are, >> and >> how >> those >> can >> be >> defined >> in >> an >> interoperable >> way >> for >> AS’s >> that >> can >> accept >> them. >> I >> think >> there’s >> a >> lot >> of >> room >> for >> innovation >> and >> flexibility >> here >> that >> doesn’t >> break >> the >> trust >> model >> or >> core >> use >> cases. >> If >> I >> have >> an >> AS-RS >> set >> that >> won’t >> accept >> my >> favorite >> flavor >> of >> policy >> engine >> inputs, >> then >> I >> can >> decide >> not >> to >> use >> that >> one. >> But >> this >> is >> a >> very >> different >> question >> than >> saying >> the >> RS >> itself >> needs >> to >> accept >> my >> own >> AS >> — >> and >> we >> can’t >> keep >> conflating >> these >> two >> models. >> >> So >> to >> me, >> GNAP >> can >> support >> a >> Zero >> Trust >> Architecture >> by >> LEVERAGING >> the >> AS, >> not >> by >> subsuming >> or >> eliminating >> it. >> It >> is >> in >> fact >> the >> AS, >> not >> the >> client >> and >> not >> the >> RS, >> that >> will >> request >> and >> consume >> the >> results >> of >> a >> privacy-preserving >> zero-trust >> policy >> query >> thing. >> Anything >> that >> happens >> downstream >> from >> that >> is >> of >> little >> concern >> to >> the >> zero-trust >> components >> because, >> as >> you >> point >> out, >> it’s >> on >> the >> “other >> side” >> of >> the >> line. >> >> >> I >> think >> we >> got >> this >> basic >> component >> model >> pretty >> right >> in >> OAuth: >> the >> AS >> and >> RS >> and >> client >> working >> together. >> Where >> OAuth >> misses >> the >> mark >> is >> the >> assumption >> that >> the >> user >> has >> to >> log >> in >> to >> the >> AS >> through >> a >> webpage >> and >> interact >> directly, >> thereby >> proving >> they’re >> the >> RO. >> It’s >> this >> latter >> space >> where >> I >> think >> we >> can >> both >> push >> innovation >> and >> also >> address >> the >> important >> and >> compelling >> use >> cases >> like >> the >> ones >> you’re >> bringing. >> >>  — >> Justin >> >>> On >>> Mar >>> 22, >>> 2021, >>> at >>> 2:14 >>> PM, >>> Adrian >>> Gropper >>> >> > >>> wrote: >>> >>> I'm >>> sorry, >>> Justin. >>> As >>> a >>> Resource >>> Owner, >>> I >>> look >>> at >>> the >>> RS >>> trust >>> boundary >>> (the >>> dotted >>> line >>> in >>> the >>> diagram) >>> as >>> being >>> the >>> RS. >>> I >>> don't >>> expect >>> any >>> visibility >>> into >>> what's >>> going >>> on >>> on >>> the right. >>> >>> >>> My >>> problem >>> with >>> the >>> framing >>> you >>> propose >>> is >>> that >>> requests >>> are >>> going >>> to >>> the >>> RS >>> (or >>> the >>> AS-RS) >>> and >>> I >>> don't >>> want >>> to >>> share >>> my >>> policies >>> with >>> the >>> AS-RS. >>> I >>> want >>> to >>> keep >>> the >>> RS >>> and >>> AS-RS >>> as >>> ignorant >>> as >>> possible. >>> >>> Adrian >>> >>> On >>> Mon, >>> Mar >>> 22, >>> 2021 >>> at >>> 1:48 >>> PM >>> Justin >>> Richer >>> >> > >>> wrote: >>> >>> Adrian, >>> >>> >>> What >>> you’re >>> discussing >>> below, >>> in >>> terms >>> of >>> logging >>> in >>> to >>> a >>> site, >>> is >>> not >>> approaching >>> the >>> RS. >>> You >>> are >>> in >>> fact >>> approaching >>> the >>> client, >>> and >>> identifying >>> both >>> the >>> AS >>> and >>> RS >>> to >>> the >>> client. >>> The >>> client >>> is >>> a >>> client >>> /of >>> your >>> identity/ >>> in >>> this >>> model, >>> and >>> the >>> RS >>> is >>> part >>> of >>> the >>> identity >>> provider. >>> It’s >>> really >>> important >>> that >>> we >>> don’t >>> conflate >>> the >>> RS >>> and >>> client >>> in >>> this >>> way >>> as >>> it >>> leads >>> to >>> a >>> lot >>> of >>> confusion >>> downstream >>> and >>> a >>> lot >>> of >>> broken >>> trust >>> boundaries. >>> >>> With >>> that >>> model >>> in >>> mind, >>> approaching >>> the >>> “RS" >>> and >>> providing >>> it >>> your >>> identity >>> is >>> really >>> just >>> a >>> case >>> of >>> the >>> “federated >>> login >>> to >>> AS” >>> pattern >>> that >>> we >>> discussed >>> on >>> the >>> WG >>> call. >>> The >>> user >>> here >>> approaches >>> an >>> RS, >>> which >>> has >>> its >>> own >>> AS. >>> To >>> share >>> things >>> from >>> this >>> RS, >>> the >>> RO >>> has >>> to >>> authenticate >>> to >>> the >>> RS’s >>> AS. >>> This >>> particular >>> AS >>> allows >>> the >>> RO >>> to >>> do >>> so >>> using >>> an >>> external >>> identity >>> — >>> in >>> which >>> case, >>> the >>> AS >>> is >>> now >>> a >>> “client” >>> of >>> a >>> separate, >>> disconnected >>> (but >>> layered) >>> delegation. >>> The >>> ultimate >>> client >>> that >>> eventually >>> calls >>> the >>> RS >>> down >>> the >>> way >>> may >>> or >>> may >>> not >>> know >>> about >>> these >>> layers. >>> >>> >>> >>> This >>> same >>> AS, >>> which >>> is >>> closely >>> tied >>> to >>> the >>> RS >>> and >>> trusted >>> by >>> the >>> RS, >>> might >>> also >>> take >>> in >>> FIDO >>> credentials, >>> or >>> DIDs, >>> or >>> any >>> number >>> of >>> other >>> proof >>> mechanisms. >>> The >>> output >>> of >>> this >>> is >>> an >>> access >>> token >>> the >>> RS >>> trusts, >>> but >>> the >>> input >>> is >>> up >>> to >>> the >>> AS. >>> The >>> RS >>> is >>> not >>> what >>> you’re >>> logging >>> in >>> to. >>> >>>  — >>> Justin >>> >>>> On >>>> Mar >>>> 22, >>>> 2021, >>>> at >>>> 1:28 >>>> PM, >>>> Adrian >>>> Gropper >>>> >>> > >>>> wrote: >>>> >>>> I >>>> too >>>> am >>>> in >>>> favor >>>> of >>>> avoiding >>>> consolidation >>>> and >>>> correlation. >>>> Right >>>> now, >>>> when >>>> I >>>> approach >>>> a >>>> service >>>> provider >>>> (RS) >>>> for >>>> the >>>> first >>>> time, >>>> I'm >>>> offered >>>> the >>>> opportunity >>>> to >>>> identify >>>> my >>>> persona >>>> as: >>>> email, >>>> sign-in >>>> with >>>> Google, >>>> Facebook, >>>> or >>>> Apple. >>>> I >>>> know >>>> there >>>> are >>>> people >>>> who >>>> try >>>> to >>>> create >>>> one-off >>>> email >>>> addresses >>>> but >>>> that >>>> is >>>> mostly >>>> a >>>> waste >>>> of >>>> time. >>>> >>>> >>>> So, >>>> along >>>> come >>>> FIDO2 >>>> and >>>> DID >>>> wallets >>>> to >>>> the >>>> rescue. >>>> Now, >>>> in >>>> theory, >>>> I >>>> have >>>> a >>>> way >>>> to >>>> start >>>> out >>>> my >>>> RS >>>> relationship >>>> pseudonymously. >>>> >>>> >>>> When >>>> I >>>> want >>>> my >>>> resource >>>> to >>>> be >>>> discovered >>>> or >>>> shared >>>> I >>>> will >>>> post >>>> that >>>> RS >>>> URL >>>> including >>>> my >>>> pseudonym. >>>> If >>>> I >>>> then >>>> want >>>> to >>>> introduce >>>> a >>>> mediator in >>>> front >>>> of >>>> my >>>> AS >>>> or >>>> messaging >>>> service endpoint, >>>> I >>>> have >>>> that >>>> option. >>>> If >>>> I >>>> want >>>> to >>>> keep >>>> requests >>>> away >>>> from >>>> the >>>> mediator, >>>> I >>>> would >>>> publish >>>> an >>>> encryption >>>> key >>>> along >>>> with >>>> my >>>> pseudonym. >>>> >>>> - >>>> Adrian >>>> >>>> >>>> >>>> On >>>> Mon, >>>> Mar >>>> 22, >>>> 2021 >>>> at >>>> 9:55 >>>> AM >>>> Justin >>>> Richer >>>> >>> > >>>> wrote: >>>> >>>> On >>>> Mar >>>> 21, >>>> 2021, >>>> at >>>> 1:18 >>>> PM, >>>> Benjamin >>>> Kaduk >>>> >>> > >>>> wrote: >>>> > >>>> >>>> > >>>> On >>>> Sat, >>>> Mar >>>> 20, >>>> 2021 >>>> at >>>> 01:07:42AM >>>> -0400, >>>> Adrian >>>> Gropper >>>> wrote: >>>> >> >>>> @Alan >>>> Karp >>>> >>> > >>>> shared >>>> a >>>> talk >>>> about >>>> the >>>> Principle >>>> Of >>>> Least >>>> >> >>>> Authority >>>> (POLA) >>>> in >>>> a >>>> recent >>>> comment >>>> >> >>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-803099693 >>>> >>>> >> >>>> I >>>> recommend >>>> it. >>>> >> >>>> >>>> >> >>>> We >>>> might >>>> expect >>>> a >>>> protocol >>>> with >>>> authorization >>>> in >>>> the >>>> title >>>> to >>>> use >>>> authority >>>> >> >>>> as >>>> a >>>> core >>>> principle. >>>> I >>>> advocate >>>> for >>>> a >>>> GNAP >>>> design >>>> that >>>> maximizes >>>> the >>>> power >>>> >> >>>> of >>>> the >>>> RO, >>>> to >>>> be >>>> seen >>>> as >>>> a >>>> human >>>> rights >>>> issue >>>> when >>>> the >>>> RO >>>> is >>>> a >>>> human. >>>> This >>>> >> >>>> causes >>>> me >>>> to >>>> ask >>>> how >>>> to >>>> combine >>>> better >>>> security >>>> with >>>> better >>>> human >>>> rights >>>> in >>>> >> >>>> GNAP. >>>> >> >>>> >>>> >> >>>> Who >>>> should >>>> have >>>> the >>>> least >>>> authority >>>> in >>>> the >>>> GNAP >>>> design? >>>> >> >>>> >>>> >> >>>> The >>>> AS >>>> derives >>>> authority >>>> as >>>> a >>>> delegate >>>> of >>>> the >>>> RO. >>>> If >>>> we >>>> ask >>>> the >>>> RO >>>> to >>>> >> >>>> partition >>>> limited >>>> authority >>>> across >>>> dozens >>>> of >>>> different >>>> ASs >>>> by >>>> domain >>>> and >>>> >> >>>> function, >>>> then >>>> we >>>> are >>>> not >>>> using >>>> technology >>>> to >>>> empower >>>> the >>>> individual. >>>> >> >>>> Probably >>>> the >>>> opposite, >>>> as >>>> we >>>> introduce >>>> consent >>>> fatigue >>>> and >>>> burden >>>> normal >>>> >> >>>> people >>>> to >>>> partition >>>> their >>>> lives >>>> into >>>> non-overlapping >>>> domains. >>>> >> >>>> >>>> >> >>>> My >>>> experience >>>> says >>>> we >>>> should >>>> aim >>>> for >>>> one >>>> AS >>>> per >>>> persona >>>> because >>>> that >>>> maps >>>> >> >>>> into >>>> the >>>> way >>>> we >>>> manage >>>> our >>>> public >>>> and >>>> private >>>> identities. >>>> POLA >>>> would >>>> then >>>> >> >>>> teach >>>> care >>>> in >>>> keeping >>>> ASs >>>> and >>>> RSs >>>> related >>>> to >>>> work >>>> / >>>> public >>>> separate >>>> from >>>> >> >>>> ASs >>>> and >>>> RSs >>>> related >>>> to >>>> private >>>> life >>>> so >>>> that >>>> a >>>> policy >>>> vulnerability >>>> in >>>> our >>>> >> >>>> delegation >>>> to >>>> an >>>> AS >>>> would >>>> have >>>> the >>>> least >>>> likelihood >>>> of >>>> harm. >>>> > >>>> >>>> > >>>> Thinking >>>> about >>>> how >>>> least >>>> authority/least >>>> privilege >>>> would >>>> apply >>>> to >>>> GNAP >>>> > >>>> seems >>>> like >>>> a >>>> useful >>>> exercise.  >>>> I >>>> do >>>> want >>>> to >>>> point >>>> out >>>> some >>>> potential >>>> > >>>> pitfalls >>>> with >>>> one-AS-per-persona >>>> that >>>> we >>>> can >>>> also >>>> be >>>> aware >>>> of.  >>>> If >>>> > >>>> one-AS-per-persona >>>> becomes >>>> one-persona-per-AS >>>> as >>>> well, >>>> then >>>> the >>>> AS's >>>> > >>>> identity >>>> in >>>> effect >>>> also >>>> serves >>>> as >>>> a >>>> persona >>>> identity >>>> and >>>> there >>>> are >>>> privacy >>>> > >>>> considerations >>>> to >>>> that.  >>>> If, >>>> on >>>> the >>>> other >>>> hand, >>>> the >>>> > >>>> multiple-personas-per-AS >>>> (presumably >>>> corresponding >>>> to >>>> multiple >>>> humans) >>>> > >>>> route >>>> is >>>> taken, >>>> we >>>> should >>>> consider >>>> whether >>>> that >>>> would >>>> lead >>>> to >>>> various >>>> > >>>> (e.g., >>>> market) >>>> forces >>>> driving >>>> consolidation >>>> to >>>> just >>>> a >>>> handful >>>> of >>>> > >>>> super-popular >>>> AS >>>> services. >>>> That >>>> topic >>>> is >>>> a >>>> current >>>> matter >>>> of >>>> concern >>>> to >>>> > >>>> some >>>> IETF >>>> participants. >>>> > >>>> >>>> >>>> Hi >>>> Ben, >>>> big >>>> +1 >>>> to >>>> this. >>>> This >>>> is >>>> something >>>> that >>>> we >>>> discussed >>>> ages >>>> ago >>>> in >>>> the >>>> UMA >>>> working >>>> group, >>>> and >>>> it’s >>>> one >>>> of >>>> the >>>> biggest >>>> problems >>>> with >>>> the >>>> personal >>>> AS >>>> (and >>>> personal >>>> data >>>> store) >>>> model. >>>> This >>>> kind >>>> of >>>> thing >>>> makes >>>> RS-first >>>> trust >>>> models >>>> really >>>> difficult >>>> in >>>> practice. >>>> >>>> As >>>> a >>>> strawman, >>>> let’s >>>> say >>>> that >>>> I’ve >>>> got >>>> software >>>> that >>>> wants >>>> to >>>> access >>>> my >>>> medical >>>> information. >>>> It >>>> calls >>>> an >>>> RS >>>> and >>>> requests >>>> access, >>>> but >>>> it >>>> hasn’t >>>> been >>>> granted >>>> anything >>>> yet. >>>> Now >>>> I >>>> as >>>> the >>>> RO >>>> have >>>> set >>>> up >>>> the >>>> RS >>>> so >>>> that >>>> it >>>> talks >>>> to >>>> my >>>> personal >>>> AS, >>>> that >>>> only >>>> I >>>> use. >>>> In >>>> addition >>>> to >>>> the >>>> RS >>>> having >>>> to >>>> be >>>> able >>>> to >>>> figure >>>> out >>>> which >>>> medical >>>> records >>>> are >>>> being >>>> requested >>>> from >>>> the >>>> context >>>> of >>>> the >>>> unauthenticated >>>> request >>>> (which >>>> means >>>> it >>>> needs >>>> identifiers >>>> in >>>> the >>>> URL >>>> or >>>> something >>>> similar >>>> for >>>> the >>>> RS >>>> to >>>> be >>>> able >>>> to >>>> tell, >>>> assuming >>>> that >>>> it >>>> protects >>>> data >>>> for >>>> more >>>> than >>>> one >>>> person). >>>> So >>>> this >>>> client >>>> software >>>> doesn’t >>>> know >>>> who >>>> I >>>> am >>>> and >>>> doesn’t >>>> know >>>> my >>>> medical >>>> record >>>> information, >>>> makes >>>> a >>>> completely >>>> unauthorized >>>> request >>>> to >>>> the >>>> RS, >>>> and >>>> the >>>> RS >>>> says >>>> “Go >>>> to >>>> Justin’s >>>> personal >>>> AS >>>> to >>>> get >>>> a >>>> token”. >>>> The >>>> client >>>> can >>>> now >>>> make >>>> a >>>> direct >>>> correlation >>>> between >>>> the >>>> data >>>> that’s >>>> being >>>> protected >>>> at >>>> the >>>> RS >>>> and >>>> the >>>> person >>>> running >>>> the >>>> AS >>>> that >>>> protects >>>> it. >>>> Importantly, >>>> this >>>> client >>>> makes >>>> this >>>> call >>>> with >>>> no >>>> prior >>>> relationship >>>> to >>>> the >>>> RS >>>> and >>>> no >>>> really >>>> auditable >>>> way >>>> to >>>> track >>>> it >>>> down >>>> after >>>> the >>>> fact. >>>> This >>>> is >>>> a >>>> design >>>> feature >>>> in >>>> the >>>> good >>>> case, >>>> and >>>> terrifying >>>> in >>>> the >>>> bad >>>> case. >>>> >>>> If >>>> the >>>> RS >>>> instead >>>> says >>>> “welcome >>>> to >>>> Medicine >>>> Doctor >>>> RS, >>>> please >>>> talk >>>> to >>>> the >>>> Medicine >>>> Doctor >>>> AS >>>> to >>>> get >>>> access”, >>>> we >>>> haven’t >>>> exposed >>>> anything >>>> at >>>> all. >>>> And >>>> from >>>> the >>>> perspective >>>> of >>>> both >>>> the >>>> patient >>>> and >>>> the >>>> RS, >>>> this >>>> is >>>> more >>>> privacy-preserving, >>>> and >>>> it’s >>>> really >>>> the >>>> least >>>> surprising >>>> option. >>>> Once >>>> the >>>> client >>>> gets >>>> to >>>> the >>>> AS, >>>> it >>>> can >>>> start >>>> a >>>> negotiation >>>> of >>>> figuring >>>> out >>>> who >>>> the >>>> RO >>>> is >>>> for >>>> the >>>> information >>>> being >>>> accessed. >>>> >>>> On >>>> top >>>> of >>>> this, >>>> the >>>> usability >>>> expectations >>>> of >>>> people >>>> managing >>>> their >>>> own >>>> AS, >>>> or >>>> set >>>> of >>>> AS’s >>>> for >>>> multiple >>>> personas >>>> to >>>> keep >>>> things >>>> separate, >>>> is >>>> a >>>> huge >>>> burden. >>>> Even >>>> in >>>> the >>>> tech >>>> community, >>>> I >>>> know >>>> people >>>> who >>>> can’t >>>> reliably >>>> manage >>>> more >>>> than >>>> one >>>> email >>>> address >>>> for >>>> different >>>> purposes. >>>> I >>>> wouldn’t >>>> expect >>>> my >>>> partner >>>> to >>>> do >>>> that >>>> — >>>> they >>>> have >>>> trouble >>>> enough >>>> balancing >>>> all >>>> the >>>> logins >>>> and >>>> sessions >>>> required >>>> for >>>> different >>>> kids >>>> remote >>>> schooling, >>>> I >>>> couldn’t >>>> imagine >>>> them >>>> having >>>> to >>>> understand >>>> all >>>> the >>>> requirements >>>> for >>>> managing >>>> multiple >>>> authorization >>>> servers >>>> and >>>> associated >>>> policies. >>>> I >>>> also >>>> don’t >>>> expect >>>> any >>>> person >>>> to >>>> “manage >>>> keys” >>>> — >>>> I’ve >>>> been >>>> on >>>> the >>>> internet >>>> for >>>> decades >>>> and >>>> I >>>> can >>>> barely >>>> keep >>>> tabs >>>> on >>>> my >>>> GPG >>>> keys, >>>> and >>>> only >>>> use >>>> them >>>> when >>>> I >>>> am >>>> forced >>>> to. >>>> This >>>> is >>>> exactly >>>> the >>>> kind >>>> of >>>> “market >>>> pressure” >>>> that >>>> I >>>> think >>>> Ben >>>> mentions >>>> above, >>>> people >>>> will >>>> just >>>> want >>>> to >>>> outsource >>>> that >>>> to >>>> someone >>>> else, >>>> and >>>> the >>>> reality >>>> will >>>> be >>>> a >>>> few >>>> popular >>>> providers. >>>> >>>> In >>>> which >>>> case, >>>> we >>>> could >>>> end >>>> up >>>> doing >>>> a >>>> ton >>>> of >>>> work >>>> to >>>> allow >>>> an >>>> RS >>>> choice >>>> only >>>> to >>>> end >>>> up >>>> with >>>> a >>>> world >>>> where >>>> the >>>> RS >>>> ends >>>> up >>>> making >>>> a >>>> limited >>>> choice >>>> anyway. >>>> We >>>> see >>>> how >>>> that >>>> plays >>>> out >>>> with >>>> OpenID >>>> Connect >>>> — >>>> RP’s >>>> could >>>> allow >>>> arbitrary >>>> IdPs >>>> but >>>> they >>>> choose >>>> Google >>>> because >>>> it >>>> works >>>> and >>>> that’s >>>> where >>>> the >>>> users >>>> are. >>>> (And >>>> that’s >>>> not >>>> to >>>> say >>>> anything >>>> of >>>> the >>>> proprietary >>>> OIDC-like >>>> protocols, >>>> but >>>> that’s >>>> another >>>> discussion). >>>> >>>> For >>>> further >>>> reading >>>> on >>>> these >>>> topics, >>>> I >>>> recommend >>>> both >>>> “Why >>>> Johnny >>>> Can’t >>>> Encrypt” >>>> and >>>> “Why >>>> CSCW >>>> Systems >>>> Fail”. >>>> >>>> So >>>> what >>>> does >>>> this >>>> have >>>> to >>>> do >>>> with >>>> GNAP? >>>> I >>>> think >>>> we >>>> can >>>> be >>>> clear-eyed >>>> on >>>> what >>>> kinds >>>> of >>>> expectations >>>> we >>>> have >>>> for >>>> the >>>> participants. >>>> If >>>> we >>>> expect >>>> users >>>> (RO’s) >>>> to >>>> have >>>> to >>>> set >>>> up >>>> the >>>> AS-RS >>>> relationship, >>>> or >>>> expect >>>> them >>>> to >>>> carry >>>> their >>>> AS, >>>> or >>>> manage >>>> their >>>> personal >>>> keys >>>> — >>>> I >>>> think >>>> we’ve >>>> lost >>>> the >>>> battle >>>> for >>>> relevance. >>>> >>>>  — >>>> Justin >>>> >>> >> >> -- >> >> 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 >> >> > > --------------CAA159ACB28604E87B5096F3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
    Since there is still no definition to explain what mean the acronyms AS-RO and AS-RS,
    I have created my own terminology RO-AS and RO-RS and wrote a full story including
    the definitions of a RO-AS and RO-RS. See the issue #223

    https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223

    Denis

    Thanks for the summary Justin. You very clearly articulated what I would call the "regulatory capture" aspects of the problem. The RS will do everything they can to avoid ceding power to the RO. By avoiding standards that shift power to the RO, the platforms, IdP's, and most other service providers delay regulation that would promote agent-based delegated access to an API as a human right. 

    It's only recently, with GDPR, that lawmakers have started to consider human rights outside of healthcare and are now introducing concepts such as the separation of controller from processor in order to enable a new generation of regulation. My perspective on GNAP is not arbitrary. It is honed by years of experience in healthcare as everyone struggles with OAuth and OpenID Connect, HEART, and now UDAP, to avoid doing in standards what seems obvious from a human rights perspective.

    What's interesting is that the "regulatory capture" standards game is now playing out in a new arena. The recent transition of DID to W3C Candidate Recommendation, together with Verifiable Credentials before that, means that every regulator (e.g. US Health and Human Services, Scotland, EU...) and some legislatures (e.g. Wyoming) are having to deal with the concept of Self-Sovereign Identity. It's not fun for the community that has worked so hard on SSI to now have to dance-around the actual impact of the SSI standards.

    With VC and DID, W3C seems to have broken through a "regulatory capture" barrier and that community is moving on to standardize protocols like DIDcomm and Encrypted Data Vaults that may avoid delegated authorization as a human right. In my opinion, GNAP, and IETF, is facing the same "regulatory capture" barrier. 

    Justin says: "Of course, market forces being as they are, I might not have much of an actionable choice in RS, but GNAP can’t change that." What GNAP makes core can change the choices the market offers by making GNAP an interoperability badge that stands for Human-Centered Protocol. If GNAP moves the human-centered part to an extension, then we're no better than another "profile" on top of OAuth.

    Adrian

    On Thu, Mar 25, 2021 at 8:46 AM Justin Richer <jricher@mit.edu> wrote:
    The way I’m thinking about Adrian’s use case is that what we’re calling the “AS-RO” isn’t an “AS” in the traditional OAuth/GNAP sense, at least not exactly. This is the agent that the RO can use to set policies and manage consent on their behalf, and I’ve been arguing that it fits better into this vaguely-defined “interaction component” aspect of the current AS definition, and it’s not currently separated from the AS definition. The “AS-RS” maps to what we’d call the “AS” in OAuth/GNAP traditionally, it’s what the RS trusts to issue tokens. In traditional OAuth the AS-RO and AS-RS are always the same thing, from a functional protocol perspective. An important point here is that from a client’s perspective, they’re only talking to the AS-RS since that’s where the client gets its tokens, because at the end of the day the client just wants to call the API at the RS and doesn’t care how that happens (from a protocol standpoint). 

    Note well: Even thought I don’t believe that “AS-RO” is an authorization server at all, I’m going to keep using that term below for consistency with previous discussion.

    So we have these fundamental relationships around getting the client to access the RS:

    1. RS trusts AS-RS to issue tokens that RS will accept, validate, and process for requests from client
    2. Client trusts AS-RS to issue tokens that client can use at RS
    3. RO trusts RS to protect RO’s api through delegated access

    On top of that, we’ve got some additional aspects that we’re discussing:

    4. RO trusts AS-RO to manage RO’s policies at runtime
    5. AS-RS trusts AS-RO to assert RO’s policies for access to RS
    6. Client trusts whatever AS-RS sends client to deal with, including possibly RO-AS at runtime, because of (2)

    What I have been saying is that 4/5/6 are optional details of how RS-AS runs things, and I think this also maps with Adrian’s view of choice, since if my RS’s AS-RS doesn’t allow me to plug in my own AS-RO then I would be motivated to pick a different RS who’s AS-RS lets me do just that. The same way I’d pick a different RS if their surrounding services didn’t accept my preferred federation login and I didn’t want to make another account. Of course, market forces being as they are, I might not have much of an actionable choice in RS, but GNAP can’t change that. 

    What we can do is make it possible for AS-RS to talk to AS-RO, both in philosophy of the protocol design and in concrete hooks to support (6) above. 

    Separately, we can approach the issue of making 1/2 above more dynamic. This was UMA2’s “federated authorization” approach, and is behind a lot of the “bring your own AS” models out there. The problem with these is that we know from many years of experience that most RS’s aren’t interested in doing anything of the sort.

    So with GNAP we can instead allow 4/5/6 to vary in a predictable and consistent way, letting the RS keep control over 1/2, thereby enabling choice in (3). We don’t have to be the ones who define the all of the details of every permutation of (5) to enable this, though. Some of this is going to be configuration out of band, some of it’s going to be communication at runtime. This is where VC’s, ZCAPs, CHAPI, DIDComm, FIDO, and a whole swath of other tech can come in and help out. I don’t think we need to put all the details for using these into core, nor do I think we’ll pull of The Great And Ultimate Abstraction for using these and other approaches. But we can at least start talking about “AS-RS” in such a way that it no longer assumes it’s always the same party dealing with the RO directly.

     — Justin

    On Mar 25, 2021, at 6:40 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    To reframe it closer to GNAP:
    - AS = AS-RO, that's where you find the RO policies. The AS issues access tokens to the client.
    - the RO policies could be a) defined locally or b) in relationship with the RS

    There have been several ideas related to the AS-RS relationship b:
    b1) the RS issues capabilities (which can be further attenuated by the RO)
    b2) Adrian also discussed a DID based solution
    b3) there was also an alternative ACL proposal from Denis (+ preflight)

    Fabien


    On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Ok so I get you correctly: 
    - what matters is the RQ (could be a RO or a end-user or both : we don't really care at a high-level, they're all treated as entities that make a request)
    - the policy is able to handle those different cases, based on its own internal delegation protocol
    - currently that requires AS-RS and AS-RO, but maybe it can be simplified

    To answer to Denis, here's what I understood:
    - RO trusts AS-RS (and then handles its own policies within AS-RO)
    - end-user trusts AS-RO (through its client)

    Could probably work but that's a fairly different model compared to OAuth2 (and of today's GNAP), with different frontiers between the AS and the RS. 

    Please do not hesitate to correct me if I'm wrong.

    Fabien 

    On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper <agropper@healthurl.com> wrote:
    I believe there are alternatives to having two kinds of ASs. The problem may be a side-effect of deciding to switch away form treating the RO as different from the RQ. That leads to downstream privacy issues. Our desire for architectural simplicity is admirable but that may have been a step too far.

    There may also be solutions based on different types of tokens, as in different capabilities (tokens signed by the RS) vs. tokens signed by the AS. I’m not sure about that but Alan might have more to say.

    Adrian

    On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks. The general problem statement is clear.

    The proposed solution a bit less (to me). I understood that from point 2, Alan involves 2 ASs. You said : "There’s no obvious reason to have two types of ASs". Do you see an alternative ?

    Regarding the last item, I don't think that naming RQ by end-user created the problem. It might just highlight the asymmetry, which fundamentally exists. 

    Fabien


    On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper <agropper@healthurl.com> wrote:
    Recap:
    1 - Justin (I think) introduced the idea of an AS on the RS trust boundary side.
    2 - I said the RO should not have to share policies with the RS.
    3 - Alan invented the concept of AS-RO and AS-RS to separate two kinds of PDPs. 

    The thing is that step 2 is not symmetrical. The RO has a legitimate privacy interest in keeping their policies private and minimizing the leakage of information about requests that are posed against those policies. 

    The RS, on the other hand, should be publishing its policies (e.g. what it’s selling or what jurisdiction it’s in or what tokens or scopes it supports). The RS has no obvious privacy interest in GNAP. It’s just an enforcer.

    There is one other privacy interest to consider around the RS and that is the requesting party (the end-user that is not the RO :-) might prefer to share attributes with the RS instead of the RO or something controlled by the RO. This case could be an “extension” to GNAP and might result in a split AS as a solution. This problem was introduced when the editors decided to replace RQ with end-user. Obviously, the RO end-user has no privacy interests relative to itself.

    Adrian




    On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    I was referring to "By my definition, this model has two ASs since both are processing requests into tokens". If there's no reason to have 2 types of ASs, that's fine then. 
    But I'm a bit lost in where we stand with the idea. 

    Could you recap? 

    Fabien 

    Le jeu. 25 mars 2021 à 08:16, Adrian Gropper <agropper@healthurl.com> a écrit :
    There’s no obvious reason to have two types of ASs. Any AS that is executing the policies of the RS can look to GNAP like the RS itself. Why would GNAP expose that interface to anyone? 

    Adrian

    On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Note : I'm not sure that's a good idea, but having 2 types of ASs is not that easy to grasp.

    Fabien 

    Le jeu. 25 mars 2021 à 08:07, Fabien Imbault <fabien.imbault@gmail.com> a écrit :
    The purpose of either handling policies locally or delegating them to the RO agent. 

    Le jeu. 25 mars 2021 à 08:04, Adrian Gropper <agropper@healthurl.com> a écrit :
    What purpose would be served by GNAP splitting the AS into two components?

    Adrian 

    On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Isn't the AS-RO a component of the AS? Same idea as the interact component, it functionnally belongs to the AS role but could be deployed either as a monolith or as a separate component?

    Fabien

    Le jeu. 25 mars 2021 à 04:26, Adrian Gropper <agropper@healthurl.com> a écrit :
    Yes, but I would say it’s not the RO that wants the access token. It’s the RO that wants the client making the request to get an access token. 

    Adrian

    On Wed, Mar 24, 2021 at 11:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Adrian Gropper <agropper@healthurl.com> wrote:

    In this design, the AS is the AS-RS and the agent is the AS-RO. By my definition, this model has two ASs since both are processing requests into tokens. The problem with this is complexity and privacy. The RO may not want to share the request information with the AS-RS.

    More precisely, RO has no choice but to present the required information to AS-RS if RO wants an access token.  However, RO does not want AS-RS to know the policy by which RO delegates tokens.  That's why RO uses AS-RO for those delegations.

    --------------
    Alan Karp


    On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Thank you for creating the issue. My definition of AS is independent of AS-RO or AS-RS. https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomment-806280421 I also agree with Alan's definition based on delegation. An AS-RS would be a delegate of the RS. 

    Based on that, I see it as obvious that the policy has to be accessible (defined locally?) in order for it to be run as the code that turns a request into an access token. 

    The only other possibility is that the request is packaged by the AS and sent elsewhere (an agent) for evaluation against policy and a proto-token returned. In that case the AS is acting as a proxy and the PDP is elsewhere. I can imagine that an AS-RS would behave this way so that the proto-token could be turned into an access token by the AS-RS. Isn't this what Justin is proposing? In this design, the AS is the AS-RS and the agent is the AS-RO. By my definition, this model has two ASs since both are processing requests into tokens. The problem with this is complexity and privacy. The RO may not want to share the request information with the AS-RS.

    Adrian

    On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Isn't that what the AS is supposed to be, only with the caveat that the policy is defined locally? 

    Fabien 


    Le mer. 24 mars 2021 à 20:17, Alan Karp <alanhkarp@gmail.com> a écrit :
    AS-RO is an AS that RO trusts to delegate RO's access tokens according to RO's policies.  

    --------------
    Alan Karp


    On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan and Adrian,

    I've created issue AS-RO policy delegation (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to capture your input. 
    A first question that arises: can we give a definition to AS-RO?

    Thanks
    Fabien

    On Tue, Mar 23, 2021 at 4:15 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan, 

    Yes, but in that flow, the token relationship between AS-RS and AS-RO is only secure if the tokens issued by AS-RS are cryptographically attenuable in the first place. 
     
    Attenuated delegation is a requirement, but that doesn't have to be done cryptographically.  Token exchange works just fine.  SPKI and zcap-ld are examples of the crypto approach, and we used token exchange in the system for HP.

    --------------
    Alan Karp


    On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan, 

    Yes, but in that flow, the token relationship between AS-RS and AS-RO is only secure if the tokens issued by AS-RS are cryptographically attenuable in the first place. 

    Fabien

    On Mon, Mar 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin Richer <jricher@mit.edu> wrote:

    But with all that in mind, I think the key here is going to be looking at what the inputs to the AS are, and how those can be defined in an interoperable way for AS’s that can accept them. I think there’s a lot of room for innovation and flexibility here that doesn’t break the trust model or core use cases. If I have an AS-RS set that won’t accept my favorite flavor of policy engine inputs, then I can decide not to use that one. But this is a very different question than saying the RS itself needs to accept my own AS — and we can’t keep conflating these two models.

    I agree.  The point of having an AS-RO is to allow RO to specify a policy for which of RO's access tokens should be delegated under what conditions.  AS-RS should not need to understand those policies.  The flow would be
    • RO contacts AS-RS and gets one or more access tokens.
    • RO delegates one or more of those tokens, potentially sub-scoped, to AS-RO.
    • A different user contacts AS-RO to get a potentially sub-scoped access token from AS-RO.
    • That user presents the access token delegated by AS-RO when invoking the resource.
    AS-RS only needs to verify that the delegation chain is legitimate, e.g., no increase in scope, and that it grants permission for the request being made.  AS-RS does not need to understand the policy behind granting the delegation by AS-RO.

    --------------
    Alan Karp


    On Mon, Mar 22, 2021 at 11:40 AM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    I think this shows the problem with the terminology as it’s been applied in this conversation, which I’ve tried to shine light on before. What you and others are calling the “RS” is really the “AS and RS working together” — everything to the right of the line. When Denis had brought up “eliminating the AS” in another thread, what he’d really done is labeled everything to the right of the line as the “RS”. Of course, the irony here is that everything to the right of the line used all be called the “AS” or simply “server” in the OAuth 1 days. As you say below, I don’t want the client to have visibility on what happens on that side. 

    Note well: The Google+ logo labeled “IdP” in the diagram is not the AS, as far as GNAP is concerned. It does not issue an access token that the RS will accept. The elements to the left of the line could be a lot of things, but they are NOT the AS — by definition. The client lives over on the left, but so do any external inputs to the AS. These could be policy inputs on behalf of the RO, they could be presentation artifacts, they could be federated logins, they could be the output of policy decisions. How the AS comes to trust those things is up to the AS’s implementation. It’s something we can talk about, but ultimately GNAP won’t be in any position to dictate because in practice some AS’s are simply going to internalize all policies and we will never successfully force those open. 

    But with all that in mind, I think the key here is going to be looking at what the inputs to the AS are, and how those can be defined in an interoperable way for AS’s that can accept them. I think there’s a lot of room for innovation and flexibility here that doesn’t break the trust model or core use cases. If I have an AS-RS set that won’t accept my favorite flavor of policy engine inputs, then I can decide not to use that one. But this is a very different question than saying the RS itself needs to accept my own AS — and we can’t keep conflating these two models.

    So to me, GNAP can support a Zero Trust Architecture by LEVERAGING the AS, not by subsuming or eliminating it. It is in fact the AS, not the client and not the RS, that will request and consume the results of a privacy-preserving zero-trust policy query thing. Anything that happens downstream from that is of little concern to the zero-trust components because, as you point out, it’s on the “other side” of the line. 

    I think we got this basic component model pretty right in OAuth: the AS and RS and client working together. Where OAuth misses the mark is the assumption that the user has to log in to the AS through a webpage and interact directly, thereby proving they’re the RO. It’s this latter space where I think we can both push innovation and also address the important and compelling use cases like the ones you’re bringing.

     — Justin

    On Mar 22, 2021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I'm sorry, Justin. As a Resource Owner, I look at the RS trust boundary (the dotted line in the diagram) as being the RS. I don't expect any visibility into what's going on on the right. 

    My problem with the framing you propose is that requests are going to the RS (or the AS-RS) and I don't want to share my policies with the AS-RS. I want to keep the RS and AS-RS as ignorant as possible.

    Adrian

    On Mon, Mar 22, 2021 at 1:48 PM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    What you’re discussing below, in terms of logging in to a site, is not approaching the RS. You are in fact approaching the client, and identifying both the AS and RS to the client. The client is a client of your identity in this model, and the RS is part of the identity provider. It’s really important that we don’t conflate the RS and client in this way as it leads to a lot of confusion downstream and a lot of broken trust boundaries.

    With that model in mind, approaching the “RS" and providing it your identity is really just a case of the “federated login to AS” pattern that we discussed on the WG call. The user here approaches an RS, which has its own AS. To share things from this RS, the RO has to authenticate to the RS’s AS. This particular AS allows the RO to do so using an external identity — in which case, the AS is now a “client” of a separate, disconnected (but layered) delegation. The ultimate client that eventually calls the RS down the way may or may not know about these layers. 

    <PastedGraphic-1.png>
    This same AS, which is closely tied to the RS and trusted by the RS, might also take in FIDO credentials, or DIDs, or any number of other proof mechanisms. The output of this is an access token the RS trusts, but the input is up to the AS. The RS is not what you’re logging in to.

     — Justin

    On Mar 22, 2021, at 1:28 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I too am in favor of avoiding consolidation and correlation. Right now, when I approach a service provider (RS) for the first time, I'm offered the opportunity to identify my persona as: email, sign-in with Google, Facebook, or Apple. I know there are people who try to create one-off email addresses but that is mostly a waste of time. 

    So, along come FIDO2 and DID wallets to the rescue. Now, in theory, I have a way to start out my RS relationship pseudonymously. 

    When I want my resource to be discovered or shared I will post that RS URL including my pseudonym. If I then want to introduce a mediator in front of my AS or messaging service endpoint, I have that option. If I want to keep requests away from the mediator, I would publish an encryption key along with my pseudonym.

    - Adrian



    On Mon, Mar 22, 2021 at 9:55 AM Justin Richer <jricher@mit.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhkarp@gmail.com> shared a talk about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use authority
    >> as a core principle. I advocate for a GNAP design that maximizes the power
    >> of the RO, to be seen as a human rights issue when the RO is a human. This
    >> causes me to ask how to combine better security with better human rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO to
    >> partition limited authority across dozens of different ASs by domain and
    >> function, then we are not using technology to empower the individual.
    >> Probably the opposite, as we introduce consent fatigue and burden normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because that maps
    >> into the way we manage our public and private identities. POLA would then
    >> teach care in keeping ASs and RSs related to work / public separate from
    >> ASs and RSs related to private life so that a policy vulnerability in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP
    > seems like a useful exercise.  I do want to point out some potential
    > pitfalls with one-AS-per-persona that we can also be aware of.  If
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS's
    > identity in effect also serves as a persona identity and there are privacy
    > considerations to that.  If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)
    > route is taken, we should consider whether that would lead to various
    > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.  That topic is a current matter of concern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the UMA working group, and it’s one of the biggest problems with the personal AS (and personal data store) model. This kind of thing makes RS-first trust models really difficult in practice.

    As a strawman, let’s say that I’ve got software that wants to access my medical information. It calls an RS and requests access, but it hasn’t been granted anything yet. Now I as the RO have set up the RS so that it talks to my personal AS, that only I use. In addition to the RS having to be able to figure out which medical records are being requested from the context of the unauthenticated request (which means it needs identifiers in the URL or something similar for the RS to be able to tell, assuming that it protects data for more than one person). So this client software doesn’t know who I am and doesn’t know my medical record information, makes a completely unauthorized request to the RS, and the RS says “Go to Justin’s personal AS to get a token”. The client can now make a direct correlation between the data that’s being protected at the RS and the person running the AS that protects it. Importantly, this client makes this call with no prior relationship to the RS and no really auditable way to track it down after the fact. This is a design feature in the good case, and terrifying in the bad case.

    If the RS instead says “welcome to Medicine Doctor RS, please talk to the Medicine Doctor AS to get access”, we haven’t exposed anything at all. And from the perspective of both the patient and the RS, this is more privacy-preserving, and it’s really the least surprising option. Once the client gets to the AS, it can start a negotiation of figuring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS, or set of AS’s for multiple personas to keep things separate, is a huge burden. Even in the tech community, I know people who can’t reliably manage more than one email address for different purposes. I wouldn’t expect my partner to do that — they have trouble enough balancing all the logins and sessions required for different kids remote schooling, I couldn’t imagine them having to understand all the requirements for managing multiple authorization servers and associated policies. I also don’t expect any person to “manage keys” — I’ve been on the internet for decades and I can barely keep tabs on my GPG keys, and only use them when I am forced to. This is exactly the kind of “market pressure” that I think Ben mentions above, people will just want to outsource that to someone else, and the reality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice only to end up with a world where the RS ends up making a limited choice anyway. We see how that plays out with OpenID Connect — RP’s could allow arbitrary IdPs but they choose Google because it works and that’s where the users are. (And that’s not to say anything of the proprietary OIDC-like protocols, but that’s another discussion).

    For further reading on these topics, I recommend both “Why Johnny Can’t Encrypt” and “Why CSCW Systems Fail”.

    So what does this have to do with GNAP? I think we can be clear-eyed on what kinds of expectations we have for the participants. If we expect users (RO’s) to have to set up the AS-RS relationship, or expect them to carry their AS, or manage their personal keys — I think we’ve lost the battle for relevance.

     — Justin


    --
    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



    --------------CAA159ACB28604E87B5096F3-- From nobody Thu Mar 25 08:46:02 2021 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 C91C23A25E3 for ; Thu, 25 Mar 2021 08:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 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_NONE=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 P_urRcmgoRhn for ; Thu, 25 Mar 2021 08:45:54 -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 649D53A25DD for ; Thu, 25 Mar 2021 08:45:53 -0700 (PDT) Received: from [192.168.1.22] (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 12PFjjLR023991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 25 Mar 2021 11:45:45 -0400 From: Justin Richer Message-Id: <4342181C-387A-4FBB-9D68-A1B0EBC93FD1@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_9DDA8BB3-0F5C-4823-BD50-57294ACB0DEF" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 25 Mar 2021 11:45:44 -0400 In-Reply-To: <1d9d5bed-32ff-a864-85a5-a16ee6063802@free.fr> Cc: Adrian Gropper , Alan Karp , Fabien Imbault , Benjamin Kaduk , Mark Miller , GNAP Mailing List To: Denis References: <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> <1d9d5bed-32ff-a864-85a5-a16ee6063802@free.fr> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 15:46:01 -0000 --Apple-Mail=_9DDA8BB3-0F5C-4823-BD50-57294ACB0DEF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Denis, These terms have been explained and defined several times in the thread = below, including in more specific detail in the first paragraph of my = message, quoted below. Much of the purpose of this thread has been = teasing out these very definitions.=20 =E2=80=94 Justin > On Mar 25, 2021, at 11:34 AM, Denis wrote: >=20 > Since there is still no definition to explain what mean the acronyms = AS-RO and AS-RS, > I have created my own terminology RO-AS and RO-RS and wrote a full = story including > the definitions of a RO-AS and RO-RS. See the issue #223 >=20 > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223 = >=20 > Denis >=20 >> Thanks for the summary Justin. You very clearly articulated what I = would call the "regulatory capture" aspects of the problem. The RS will = do everything they can to avoid ceding power to the RO. By avoiding = standards that shift power to the RO, the platforms, IdP's, and most = other service providers delay regulation that would promote agent-based = delegated access to an API as a human right.=20 >>=20 >> It's only recently, with GDPR, that lawmakers have started to = consider human rights outside of healthcare and are now introducing = concepts such as the separation of controller from processor in order to = enable a new generation of regulation. My perspective on GNAP is not = arbitrary. It is honed by years of experience in healthcare as everyone = struggles with OAuth and OpenID Connect, HEART, and now UDAP, to avoid = doing in standards what seems obvious from a human rights perspective. >>=20 >> What's interesting is that the "regulatory capture" standards game is = now playing out in a new arena. The recent transition of DID to W3C = Candidate Recommendation, together with Verifiable Credentials before = that, means that every regulator (e.g. US Health and Human Services, = Scotland, EU...) and some legislatures (e.g. Wyoming) are having to deal = with the concept of Self-Sovereign Identity. It's not fun for the = community that has worked so hard on SSI to now have to dance-around the = actual impact of the SSI standards. >>=20 >> With VC and DID, W3C seems to have broken through a "regulatory = capture" barrier and that community is moving on to standardize = protocols like DIDcomm and Encrypted Data Vaults that may avoid = delegated authorization as a human right. In my opinion, GNAP, and IETF, = is facing the same "regulatory capture" barrier.=20 >>=20 >> Justin says: "Of course, market forces being as they are, I might not = have much of an actionable choice in RS, but GNAP can=E2=80=99t change = that." What GNAP makes core can change the choices the market offers by = making GNAP an interoperability badge that stands for Human-Centered = Protocol. If GNAP moves the human-centered part to an extension, then = we're no better than another "profile" on top of OAuth. >>=20 >> Adrian >>=20 >> On Thu, Mar 25, 2021 at 8:46 AM Justin Richer > wrote: >> The way I=E2=80=99m thinking about Adrian=E2=80=99s use case is that = what we=E2=80=99re calling the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an = =E2=80=9CAS=E2=80=9D in the traditional OAuth/GNAP sense, at least not = exactly. This is the agent that the RO can use to set policies and = manage consent on their behalf, and I=E2=80=99ve been arguing that it = fits better into this vaguely-defined =E2=80=9Cinteraction component=E2=80= =9D aspect of the current AS definition, and it=E2=80=99s not currently = separated from the AS definition. The =E2=80=9CAS-RS=E2=80=9D maps to = what we=E2=80=99d call the =E2=80=9CAS=E2=80=9D in OAuth/GNAP = traditionally, it=E2=80=99s what the RS trusts to issue tokens. In = traditional OAuth the AS-RO and AS-RS are always the same thing, from a = functional protocol perspective. An important point here is that from a = client=E2=80=99s perspective, they=E2=80=99re only talking to the AS-RS = since that=E2=80=99s where the client gets its tokens, because at the = end of the day the client just wants to call the API at the RS and = doesn=E2=80=99t care how that happens (from a protocol standpoint).=20 >>=20 >> Note well: Even thought I don=E2=80=99t believe that =E2=80=9CAS-RO=E2=80= =9D is an authorization server at all, I=E2=80=99m going to keep using = that term below for consistency with previous discussion. >>=20 >> So we have these fundamental relationships around getting the client = to access the RS: >>=20 >> 1. RS trusts AS-RS to issue tokens that RS will accept, validate, and = process for requests from client >> 2. Client trusts AS-RS to issue tokens that client can use at RS >> 3. RO trusts RS to protect RO=E2=80=99s api through delegated access >>=20 >> On top of that, we=E2=80=99ve got some additional aspects that = we=E2=80=99re discussing: >>=20 >> 4. RO trusts AS-RO to manage RO=E2=80=99s policies at runtime >> 5. AS-RS trusts AS-RO to assert RO=E2=80=99s policies for access to = RS >> 6. Client trusts whatever AS-RS sends client to deal with, including = possibly RO-AS at runtime, because of (2) >>=20 >> What I have been saying is that 4/5/6 are optional details of how = RS-AS runs things, and I think this also maps with Adrian=E2=80=99s view = of choice, since if my RS=E2=80=99s AS-RS doesn=E2=80=99t allow me to = plug in my own AS-RO then I would be motivated to pick a different RS = who=E2=80=99s AS-RS lets me do just that. The same way I=E2=80=99d pick = a different RS if their surrounding services didn=E2=80=99t accept my = preferred federation login and I didn=E2=80=99t want to make another = account. Of course, market forces being as they are, I might not have = much of an actionable choice in RS, but GNAP can=E2=80=99t change that.=20= >>=20 >> What we can do is make it possible for AS-RS to talk to AS-RO, both = in philosophy of the protocol design and in concrete hooks to support = (6) above.=20 >>=20 >> Separately, we can approach the issue of making 1/2 above more = dynamic. This was UMA2=E2=80=99s =E2=80=9Cfederated authorization=E2=80=9D= approach, and is behind a lot of the =E2=80=9Cbring your own AS=E2=80=9D = models out there. The problem with these is that we know from many years = of experience that most RS=E2=80=99s aren=E2=80=99t interested in doing = anything of the sort. >>=20 >> So with GNAP we can instead allow 4/5/6 to vary in a predictable and = consistent way, letting the RS keep control over 1/2, thereby enabling = choice in (3). We don=E2=80=99t have to be the ones who define the all = of the details of every permutation of (5) to enable this, though. Some = of this is going to be configuration out of band, some of it=E2=80=99s = going to be communication at runtime. This is where VC=E2=80=99s, ZCAPs, = CHAPI, DIDComm, FIDO, and a whole swath of other tech can come in and = help out. I don=E2=80=99t think we need to put all the details for using = these into core, nor do I think we=E2=80=99ll pull of The Great And = Ultimate Abstraction for using these and other approaches. But we can at = least start talking about =E2=80=9CAS-RS=E2=80=9D in such a way that it = no longer assumes it=E2=80=99s always the same party dealing with the RO = directly. >>=20 >> =E2=80=94 Justin >>=20 >>> On Mar 25, 2021, at 6:40 AM, Fabien Imbault = > wrote: >>>=20 >>> To reframe it closer to GNAP: >>> - AS =3D AS-RO, that's where you find the RO policies. The AS issues = access tokens to the client. >>> - the RO policies could be a) defined locally or b) in relationship = with the RS >>>=20 >>> There have been several ideas related to the AS-RS relationship b: >>> b1) the RS issues capabilities (which can be further attenuated by = the RO) >>> b2) Adrian also discussed a DID based solution >>> b3) there was also an alternative ACL proposal from Denis (+ = preflight) >>>=20 >>> Fabien >>>=20 >>>=20 >>> On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault = > wrote: >>> Ok so I get you correctly:=20 >>> - what matters is the RQ (could be a RO or a end-user or both : we = don't really care at a high-level, they're all treated as entities that = make a request) >>> - the policy is able to handle those different cases, based on its = own internal delegation protocol >>> - currently that requires AS-RS and AS-RO, but maybe it can be = simplified >>>=20 >>> To answer to Denis, here's what I understood: >>> - RO trusts AS-RS (and then handles its own policies within AS-RO) >>> - end-user trusts AS-RO (through its client) >>>=20 >>> Could probably work but that's a fairly different model compared to = OAuth2 (and of today's GNAP), with different frontiers between the AS = and the RS.=20 >>>=20 >>> Please do not hesitate to correct me if I'm wrong. >>>=20 >>> Fabien=20 >>>=20 >>> On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper = > wrote: >>> I believe there are alternatives to having two kinds of ASs. The = problem may be a side-effect of deciding to switch away form treating = the RO as different from the RQ. That leads to downstream privacy = issues. Our desire for architectural simplicity is admirable but that = may have been a step too far. >>>=20 >>> There may also be solutions based on different types of tokens, as = in different capabilities (tokens signed by the RS) vs. tokens signed by = the AS. I=E2=80=99m not sure about that but Alan might have more to say. >>>=20 >>> Adrian >>>=20 >>> On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault = > wrote: >>> Thanks. The general problem statement is clear. >>>=20 >>> The proposed solution a bit less (to me). I understood that from = point 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obvious = reason to have two types of ASs". Do you see an alternative ? >>>=20 >>> Regarding the last item, I don't think that naming RQ by end-user = created the problem. It might just highlight the asymmetry, which = fundamentally exists.=20 >>>=20 >>> Fabien >>>=20 >>>=20 >>> On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper = > wrote: >>> Recap: >>> 1 - Justin (I think) introduced the idea of an AS on the RS trust = boundary side. >>> 2 - I said the RO should not have to share policies with the RS. >>> 3 - Alan invented the concept of AS-RO and AS-RS to separate two = kinds of PDPs.=20 >>>=20 >>> The thing is that step 2 is not symmetrical. The RO has a legitimate = privacy interest in keeping their policies private and minimizing the = leakage of information about requests that are posed against those = policies.=20 >>>=20 >>> The RS, on the other hand, should be publishing its policies (e.g. = what it=E2=80=99s selling or what jurisdiction it=E2=80=99s in or what = tokens or scopes it supports). The RS has no obvious privacy interest in = GNAP. It=E2=80=99s just an enforcer. >>>=20 >>> There is one other privacy interest to consider around the RS and = that is the requesting party (the end-user that is not the RO :-) might = prefer to share attributes with the RS instead of the RO or something = controlled by the RO. This case could be an =E2=80=9Cextension=E2=80=9D = to GNAP and might result in a split AS as a solution. This problem was = introduced when the editors decided to replace RQ with end-user. = Obviously, the RO end-user has no privacy interests relative to itself. >>>=20 >>> Adrian >>>=20 >>>=20 >>>=20 >>>=20 >>> On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault = > wrote: >>> I was referring to "By my definition, this model has two ASs since = both are processing requests into tokens". If there's no reason to have = 2 types of ASs, that's fine then.=20 >>> But I'm a bit lost in where we stand with the idea.=20 >>>=20 >>> Could you recap?=20 >>>=20 >>> Fabien=20 >>>=20 >>> Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper = > a =C3=A9crit : >>> There=E2=80=99s no obvious reason to have two types of ASs. Any AS = that is executing the policies of the RS can look to GNAP like the RS = itself. Why would GNAP expose that interface to anyone?=20 >>>=20 >>> Adrian >>>=20 >>> On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault = > wrote: >>> Note : I'm not sure that's a good idea, but having 2 types of ASs is = not that easy to grasp. >>>=20 >>> Fabien=20 >>>=20 >>> Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault = > a =C3=A9crit = : >>> The purpose of either handling policies locally or delegating them = to the RO agent.=20 >>>=20 >>> Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper = > a =C3=A9crit : >>> What purpose would be served by GNAP splitting the AS into two = components? >>>=20 >>> Adrian=20 >>>=20 >>> On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault = > wrote: >>> Isn't the AS-RO a component of the AS? Same idea as the interact = component, it functionnally belongs to the AS role but could be deployed = either as a monolith or as a separate component? >>>=20 >>> Fabien >>>=20 >>> Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper = > a =C3=A9crit : >>> Yes, but I would say it=E2=80=99s not the RO that wants the access = token. It=E2=80=99s the RO that wants the client making the request to = get an access token.=20 >>>=20 >>> Adrian >>>=20 >>> On Wed, Mar 24, 2021 at 11:22 PM Alan Karp > wrote: >>> Adrian Gropper > wrote: >>>=20 >>> In this design, the AS is the AS-RS and the agent is the AS-RO. By = my definition, this model has two ASs since both are processing requests = into tokens. The problem with this is complexity and privacy. The RO may = not want to share the request information with the AS-RS. >>>=20 >>> More precisely, RO has no choice but to present the required = information to AS-RS if RO wants an access token. However, RO does not = want AS-RS to know the policy by which RO delegates tokens. That's why = RO uses AS-RO for those delegations. >>>=20 >>> -------------- >>> Alan Karp >>>=20 >>>=20 >>> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper = > wrote: >>> Thank you for creating the issue. My definition of AS is independent = of AS-RO or AS-RS. = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomment= -806280421 = I also agree with Alan's definition based on delegation. An = AS-RS would be a delegate of the RS.=20 >>>=20 >>> Based on that, I see it as obvious that the policy has to be = accessible (defined locally?) in order for it to be run as the code that = turns a request into an access token.=20 >>>=20 >>> The only other possibility is that the request is packaged by the AS = and sent elsewhere (an agent) for evaluation against policy and a = proto-token returned. In that case the = AS is acting as a proxy and the PDP is = elsewhere. I can imagine that an AS-RS would behave this way so that the = proto-token could be turned into an access token by the AS-RS. Isn't = this what Justin is proposing? In this design, the AS is the AS-RS and = the agent is the AS-RO. By my definition, this model has two ASs since = both are processing requests into tokens. The problem with this is = complexity and privacy. The RO may not want to share the request = information with the AS-RS. >>>=20 >>> Adrian >>>=20 >>> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault = > wrote: >>> Isn't that what the AS is supposed to be, only with the caveat that = the policy is defined locally?=20 >>>=20 >>> Fabien=20 >>>=20 >>>=20 >>> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp > a =C3=A9crit : >>> AS-RO is an AS that RO trusts to delegate RO's access tokens = according to RO's policies. =20 >>>=20 >>> -------------- >>> Alan Karp >>>=20 >>>=20 >>> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault = > wrote: >>> Hi Alan and Adrian, >>>=20 >>> I've created issue AS-RO policy delegation = (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223 = ) to = capture your input.=20 >>> A first question that arises: can we give a definition to AS-RO? >>>=20 >>> Thanks >>> Fabien >>>=20 >>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp > wrote: >>> Fabien Imbault > wrote: >>> Hi Alan,=20 >>>=20 >>> Yes, but in that flow, the token relationship between AS-RS and = AS-RO is only secure if the tokens issued by AS-RS are cryptographically = attenuable in the first = place.=20 >>> =20 >>> Attenuated delegation is a requirement, but that doesn't have to be = done cryptographically. Token exchange works just fine. SPKI and = zcap-ld are examples of the crypto approach, and we used token exchange = in the system for HP. >>>=20 >>> -------------- >>> Alan Karp >>>=20 >>>=20 >>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault = > wrote: >>> Hi Alan,=20 >>>=20 >>> Yes, but in that flow, the token relationship between AS-RS and = AS-RO is only secure if the tokens issued by AS-RS are cryptographically = attenuable in the first = place.=20 >>>=20 >>> Fabien >>>=20 >>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp > wrote: >>> Justin Richer > wrote: >>>=20 >>> But with all that in mind, I think the key here is going to be = looking at what the inputs to the AS are, and how those can be defined = in an interoperable way for AS=E2=80=99s that can accept them. I think = there=E2=80=99s a lot of room for innovation and flexibility here that = doesn=E2=80=99t break the trust model or core use cases. If I have an = AS-RS set that won=E2=80=99t accept my favorite flavor of policy engine = inputs, then I can decide not to use that one. But this is a very = different question than saying the RS itself needs to accept my own AS = =E2=80=94 and we can=E2=80=99t keep conflating these two models. >>>=20 >>> I agree. The point of having an AS-RO is to allow RO to specify a = policy for which of RO's access tokens should be delegated under what = conditions. AS-RS should not need to understand those policies. The = flow would be >>> RO contacts AS-RS and gets one or more access tokens. >>> RO delegates one or more of those tokens, potentially sub-scoped, to = AS-RO. >>> A different user contacts AS-RO to get a potentially sub-scoped = access token from AS-RO. >>> That user presents the access token delegated by AS-RO when invoking = the resource. >>> AS-RS only needs to verify that the delegation chain is legitimate, = e.g., no increase in scope, and that it grants permission for the = request being made. AS-RS does not need to understand the policy behind = granting the delegation by AS-RO. >>>=20 >>> -------------- >>> Alan Karp >>>=20 >>>=20 >>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer > wrote: >>> Adrian, >>>=20 >>> I think this shows the problem with the terminology as it=E2=80=99s = been applied in this conversation, which I=E2=80=99ve tried to shine = light on before. What you and others are calling the =E2=80=9CRS=E2=80=9D = is really the =E2=80=9CAS and RS working together=E2=80=9D =E2=80=94 = everything to the right of the line. When Denis had brought up = =E2=80=9Celiminating the AS=E2=80=9D in another thread, what he=E2=80=99d = really done is labeled everything to the right of the line as the = =E2=80=9CRS=E2=80=9D. Of course, the irony here is that everything to = the right of the line used all be called the =E2=80=9CAS=E2=80=9D or = simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say below, I = don=E2=80=99t want the client to have visibility on what happens on that = side.=20 >>>=20 >>> Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the = diagram is not the AS, as far as GNAP is concerned. It does not issue an = access token that the RS will accept. The elements to the left of the = line could be a lot of things, but they are NOT the AS =E2=80=94 by = definition. The client lives over on the left, but so do any external = inputs to the AS. These could be policy inputs on behalf of the RO, they = could be presentation artifacts, they could be federated logins, they = could be the output of policy decisions. How the AS comes to trust those = things is up to the AS=E2=80=99s implementation. It=E2=80=99s something = we can talk about, but ultimately GNAP won=E2=80=99t be in any position = to dictate because in practice some AS=E2=80=99s are simply going to = internalize all policies and we will never successfully force those = open.=20 >>>=20 >>> But with all that in mind, I think the key here is going to be = looking at what the inputs to the AS are, and how those can be defined = in an interoperable way for AS=E2=80=99s that can accept them. I think = there=E2=80=99s a lot of room for innovation and flexibility here that = doesn=E2=80=99t break the trust model or core use cases. If I have an = AS-RS set that won=E2=80=99t accept my favorite flavor of policy engine = inputs, then I can decide not to use that one. But this is a very = different question than saying the RS itself needs to accept my own AS = =E2=80=94 and we can=E2=80=99t keep conflating these two models. >>>=20 >>> So to me, GNAP can support a Zero Trust Architecture by LEVERAGING = the AS, not by subsuming or eliminating it. It is in fact the AS, not = the client and not the RS, that will request and consume the results of = a privacy-preserving zero-trust policy query thing. Anything that = happens downstream from that is of little concern to the zero-trust = components because, as you point out, it=E2=80=99s on the =E2=80=9Cother = side=E2=80=9D of the line.=20 >>>=20 >>> I think we got this basic component model pretty right in OAuth: the = AS and RS and client working together. Where OAuth misses the mark is = the assumption that the user has to log in to the AS through a webpage = and interact directly, thereby proving they=E2=80=99re the RO. It=E2=80=99= s this latter space where I think we can both push innovation and also = address the important and compelling use cases like the ones you=E2=80=99r= e bringing. >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper > wrote: >>>>=20 >>>> I'm sorry, Justin. As a Resource Owner, I look at the RS trust = boundary (the dotted line in the diagram) as being the RS. I don't = expect any visibility into what's going on on the right.=20 >>>>=20 >>>> My problem with the framing you propose is that requests are going = to the RS (or the AS-RS) and I don't want to share my policies with the = AS-RS. I want to keep the RS and AS-RS as ignorant as possible. >>>>=20 >>>> Adrian >>>>=20 >>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer > wrote: >>>> Adrian, >>>>=20 >>>> What you=E2=80=99re discussing below, in terms of logging in to a = site, is not approaching the RS. You are in fact approaching the client, = and identifying both the AS and RS to the client. The client is a client = of your identity in this model, and the RS is part of the identity = provider. It=E2=80=99s really important that we don=E2=80=99t conflate = the RS and client in this way as it leads to a lot of confusion = downstream and a lot of broken trust boundaries. >>>>=20 >>>> With that model in mind, approaching the =E2=80=9CRS" and providing = it your identity is really just a case of the =E2=80=9Cfederated login = to AS=E2=80=9D pattern that we discussed on the WG call. The user here = approaches an RS, which has its own AS. To share things from this RS, = the RO has to authenticate to the RS=E2=80=99s AS. This particular AS = allows the RO to do so using an external identity =E2=80=94 in which = case, the AS is now a =E2=80=9Cclient=E2=80=9D of a separate, = disconnected (but layered) delegation. The ultimate client that = eventually calls the RS down the way may or may not know about these = layers.=20 >>>>=20 >>>> >>>> This same AS, which is closely tied to the RS and trusted by the = RS, might also take in FIDO credentials, or DIDs, or any number of other = proof mechanisms. The output of this is an access token the RS trusts, = but the input is up to the AS. The RS is not what you=E2=80=99re logging = in to. >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper = > wrote: >>>>>=20 >>>>> I too am in favor of avoiding consolidation and correlation. Right = now, when I approach a service provider (RS) for the first time, I'm = offered the opportunity to identify my persona as: email, sign-in with = Google, Facebook, or Apple. I know there are people who try to create = one-off email addresses but that is mostly a waste of time.=20 >>>>>=20 >>>>> So, along come FIDO2 and DID wallets to the rescue. Now, in = theory, I have a way to start out my RS relationship pseudonymously.=20 >>>>>=20 >>>>> When I want my resource to be discovered or shared I will post = that RS URL including my pseudonym. If I then want to introduce a = mediator in front of my AS or messaging service endpoint, I have that = option. If I want to keep requests away from the mediator, I would = publish an encryption key along with my pseudonym. >>>>>=20 >>>>> - Adrian >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer > wrote: >>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk > wrote: >>>>> >=20 >>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote: >>>>> >> @Alan Karp > = shared a talk about the Principle Of Least >>>>> >> Authority (POLA) in a recent comment >>>>> >> = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment= -803099693 = >>>>> >> I recommend it. >>>>> >>=20 >>>>> >> We might expect a protocol with authorization in the title to = use authority >>>>> >> as a core principle. I advocate for a GNAP design that = maximizes the power >>>>> >> of the RO, to be seen as a human rights issue when the RO is a = human. This >>>>> >> causes me to ask how to combine better security with better = human rights in >>>>> >> GNAP. >>>>> >>=20 >>>>> >> Who should have the least authority in the GNAP design? >>>>> >>=20 >>>>> >> The AS derives authority as a delegate of the RO. If we ask the = RO to >>>>> >> partition limited authority across dozens of different ASs by = domain and >>>>> >> function, then we are not using technology to empower the = individual. >>>>> >> Probably the opposite, as we introduce consent fatigue and = burden normal >>>>> >> people to partition their lives into non-overlapping domains. >>>>> >>=20 >>>>> >> My experience says we should aim for one AS per persona because = that maps >>>>> >> into the way we manage our public and private identities. POLA = would then >>>>> >> teach care in keeping ASs and RSs related to work / public = separate from >>>>> >> ASs and RSs related to private life so that a policy = vulnerability in our >>>>> >> delegation to an AS would have the least likelihood of harm. >>>>> >=20 >>>>> > Thinking about how least authority/least privilege would apply = to GNAP >>>>> > seems like a useful exercise. I do want to point out some = potential >>>>> > pitfalls with one-AS-per-persona that we can also be aware of. = If >>>>> > one-AS-per-persona becomes one-persona-per-AS as well, then the = AS's >>>>> > identity in effect also serves as a persona identity and there = are privacy >>>>> > considerations to that. If, on the other hand, the >>>>> > multiple-personas-per-AS (presumably corresponding to multiple = humans) >>>>> > route is taken, we should consider whether that would lead to = various >>>>> > (e.g., market) forces driving consolidation to just a handful of >>>>> > super-popular AS services. That topic is a current matter of = concern to >>>>> > some IETF participants. >>>>> >=20 >>>>>=20 >>>>> Hi Ben, big +1 to this. This is something that we discussed ages = ago in the UMA working group, and it=E2=80=99s one of the biggest = problems with the personal AS (and personal data store) model. This kind = of thing makes RS-first trust models really difficult in practice. >>>>>=20 >>>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve got software = that wants to access my medical information. It calls an RS and requests = access, but it hasn=E2=80=99t been granted anything yet. Now I as the RO = have set up the RS so that it talks to my personal AS, that only I use. = In addition to the RS having to be able to figure out which medical = records are being requested from the context of the unauthenticated = request (which means it needs identifiers in the URL or something = similar for the RS to be able to tell, assuming that it protects data = for more than one person). So this client software doesn=E2=80=99t know = who I am and doesn=E2=80=99t know my medical record information, makes a = completely unauthorized request to the RS, and the RS says =E2=80=9CGo = to Justin=E2=80=99s personal AS to get a token=E2=80=9D. The client can = now make a direct correlation between the data that=E2=80=99s being = protected at the RS and the person running the AS that protects it. = Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This = is a design feature in the good case, and terrifying in the bad case. >>>>>=20 >>>>> If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, = please talk to the Medicine Doctor AS to get access=E2=80=9D, we = haven=E2=80=99t exposed anything at all. And from the perspective of = both the patient and the RS, this is more privacy-preserving, and it=E2=80= =99s really the least surprising option. Once the client gets to the AS, = it can start a negotiation of figuring out who the RO is for the = information being accessed. >>>>>=20 >>>>> On top of this, the usability expectations of people managing = their own AS, or set of AS=E2=80=99s for multiple personas to keep = things separate, is a huge burden. Even in the tech community, I know = people who can=E2=80=99t reliably manage more than one email address for = different purposes. I wouldn=E2=80=99t expect my partner to do that =E2=80= =94 they have trouble enough balancing all the logins and sessions = required for different kids remote schooling, I couldn=E2=80=99t imagine = them having to understand all the requirements for managing multiple = authorization servers and associated policies. I also don=E2=80=99t = expect any person to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve = been on the internet for decades and I can barely keep tabs on my GPG = keys, and only use them when I am forced to. This is exactly the kind of = =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions above, = people will just want to outsource that to someone else, and the reality = will be a few popular providers. >>>>>=20 >>>>> In which case, we could end up doing a ton of work to allow an RS = choice only to end up with a world where the RS ends up making a limited = choice anyway. We see how that plays out with OpenID Connect =E2=80=94 = RP=E2=80=99s could allow arbitrary IdPs but they choose Google because = it works and that=E2=80=99s where the users are. (And that=E2=80=99s not = to say anything of the proprietary OIDC-like protocols, but that=E2=80=99s= another discussion). >>>>>=20 >>>>> For further reading on these topics, I recommend both =E2=80=9CWhy = Johnny Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems = Fail=E2=80=9D. >>>>>=20 >>>>> So what does this have to do with GNAP? I think we can be = clear-eyed on what kinds of expectations we have for the participants. = If we expect users (RO=E2=80=99s) to have to set up the AS-RS = relationship, or expect them to carry their AS, or manage their personal = keys =E2=80=94 I think we=E2=80=99ve lost the battle for relevance. >>>>>=20 >>>>> =E2=80=94 Justin >>>>=20 >>>=20 >>> --=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 = >>> --=20 >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >>=20 >>=20 >=20 --Apple-Mail=_9DDA8BB3-0F5C-4823-BD50-57294ACB0DEF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Denis,

    These terms have been explained and defined several times in = the thread below, including in more specific detail in the first = paragraph of my message, quoted below. Much of the purpose of this = thread has been teasing out these very definitions. 

     =E2=80=94 = Justin

    On Mar 25, 2021, at 11:34 AM, Denis <denis.ietf@free.fr> = wrote:

    =20
    Since there is still no definition to explain what mean the acronyms AS-RO and AS-RS,
    I have created my own terminology RO-AS and RO-RS and = wrote a full story including
    the definitions of a RO-AS and RO-RS. See the issue #223

    htt= ps://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223

    Denis

    =20
    Thanks for the summary Justin. You = very clearly articulated what I would call the "regulatory capture" aspects of the problem. The RS will do everything they can to avoid ceding power to the RO. By avoiding standards that shift power to the RO, the platforms, IdP's, and most other service providers delay regulation that would promote agent-based delegated access to an API as a human right. 

    It's only recently, with GDPR, that lawmakers have started to consider human rights = outside of healthcare and are now introducing concepts such as the separation of controller from processor in order to = enable a new generation of regulation. My perspective on GNAP is not arbitrary. It is honed by years of experience in = healthcare as everyone struggles with OAuth and OpenID Connect, HEART, and now UDAP, to avoid doing in standards what seems obvious from a human rights perspective.

    What's interesting is that the "regulatory = capture" standards game is now playing out in a new arena. The recent transition of DID to W3C Candidate Recommendation, together with Verifiable Credentials before that, means that every regulator (e.g. US Health and Human Services, Scotland, EU...) and some legislatures (e.g. Wyoming) are having to deal with the concept of Self-Sovereign Identity. It's not fun for the community that has worked so hard on SSI to now have to dance-around the actual impact of the SSI = standards.

    With VC and DID, W3C seems to have broken = through a "regulatory capture" barrier and that community is moving on to standardize protocols like DIDcomm and Encrypted Data Vaults that may avoid delegated authorization as a human right. In my opinion, GNAP, and IETF, is facing the same "regulatory capture" barrier. 

    Justin says: "Of course, market forces being = as they are, I might not have much of an actionable choice in RS, but GNAP can=E2=80=99t change that." What GNAP makes core can = change the choices the market offers by making GNAP an interoperability badge that stands for Human-Centered Protocol. If GNAP moves the human-centered part to an extension, then we're no better than another "profile" on top of OAuth.

    Adrian

    On Thu, Mar 25, 2021 at = 8:46 AM Justin Richer <jricher@mit.edu> wrote:
    The way I=E2=80=99m thinking about Adrian=E2=80=99s use case is = that what we=E2=80=99re calling the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an = =E2=80=9CAS=E2=80=9D in the traditional OAuth/GNAP sense, at least not exactly. This is the agent that the RO can use to set policies and manage consent on their behalf, and I=E2=80=99ve been arguing that it fits = better into this vaguely-defined =E2=80=9Cinteraction component=E2=80=9D = aspect of the current AS definition, and it=E2=80=99s not currently = separated from the AS definition. The =E2=80=9CAS-RS=E2=80=9D maps to what = we=E2=80=99d call the =E2=80=9CAS=E2=80=9D in OAuth/GNAP traditionally, it=E2=80=99s= what the RS trusts to issue tokens. In traditional OAuth the AS-RO and AS-RS are always the same thing, from a functional protocol perspective. An important point here is that from a = client=E2=80=99s perspective, they=E2=80=99re only talking to the AS-RS since = that=E2=80=99s where the client gets its tokens, because at the end of the day the client just wants to call the API at the RS and doesn=E2=80=99t care how that happens (from a protocol = standpoint). 

    Note well: Even thought I don=E2=80=99t = believe that =E2=80=9CAS-RO=E2=80=9D is an authorization server at all, I=E2=80=99m going to keep = using that term below for consistency with previous = discussion.

    So we have these fundamental relationships = around getting the client to access the RS:

    1. RS trusts AS-RS to issue tokens = that RS will accept, validate, and process for requests from client
    2. Client trusts AS-RS to issue = tokens that client can use at RS
    3. RO trusts RS to protect RO=E2=80=99s api = through delegated access

    On top of that, we=E2=80=99ve got some = additional aspects that we=E2=80=99re discussing:

    4. RO trusts AS-RO to manage = RO=E2=80=99s policies at runtime
    5. AS-RS trusts AS-RO to = assert RO=E2=80=99s policies for access to RS
    6. Client trusts = whatever AS-RS sends client to deal with, including possibly RO-AS at runtime, because of = (2)

    What I have been saying is that 4/5/6 are = optional details of how RS-AS runs things, and I think this also maps with Adrian=E2=80=99s view of choice, since if my = RS=E2=80=99s AS-RS doesn=E2=80=99t allow me to plug in my own AS-RO then I = would be motivated to pick a different RS who=E2=80=99s AS-RS lets = me do just that. The same way I=E2=80=99d pick a different RS if = their surrounding services didn=E2=80=99t accept my preferred = federation login and I didn=E2=80=99t want to make another account. = Of course, market forces being as they are, I might not have much of an actionable choice in RS, but GNAP can=E2=80=99t = change that. 

    What we can do is make it possible for AS-RS = to talk to AS-RO, both in philosophy of the protocol design and in concrete hooks to support (6) above. 

    Separately, we can approach the issue of = making 1/2 above more dynamic. This was UMA2=E2=80=99s =E2=80=9Cfederat= ed authorization=E2=80=9D approach, and is behind a lot of = the =E2=80=9Cbring your own AS=E2=80=9D models out there. The problem with = these is that we know from many years of experience that most = RS=E2=80=99s aren=E2=80=99t interested in doing anything of the = sort.

    So with GNAP we can instead allow 4/5/6 to = vary in a predictable and consistent way, letting the RS keep control over 1/2, thereby enabling choice in (3). We = don=E2=80=99t have to be the ones who define the all of the details of every permutation of (5) to enable this, though. Some of this is going to be configuration out of band, some of it=E2=80=99s going to be communication at runtime. This is = where VC=E2=80=99s, ZCAPs, CHAPI, DIDComm, FIDO, and a whole = swath of other tech can come in and help out. I don=E2=80=99t think = we need to put all the details for using these into core, nor do I think we=E2=80=99ll pull of The Great And Ultimate = Abstraction for using these and other approaches. But we can at least start talking about =E2=80=9CAS-RS=E2=80=9D in such a way = that it no longer assumes it=E2=80=99s always the same party dealing = with the RO directly.

     =E2=80=94 Justin

    On Mar 25, 2021, at 6:40 AM, Fabien = Imbault <fabien.imbault@gmail.com> wrote:

    To reframe it closer = to GNAP:
    - AS =3D AS-RO, that's where you = find the RO policies. The AS issues access tokens to the client.
    - the RO policies could be a) = defined locally or b) in relationship with the = RS

    There have been several ideas = related to the AS-RS relationship b:
    b1) the RS issues capabilities = (which can be further attenuated by the RO)
    b2) Adrian also discussed a DID = based solution
    b3) there was also an = alternative ACL proposal from Denis (+ preflight)

    Fabien


    On Thu, = Mar 25, 2021 at 9:44 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Ok so I get you = correctly: 
    - what matters is the RQ = (could be a RO or a end-user or both : we don't really care at a high-level, they're all treated as entities that make a request)
    - the policy is able to = handle those different cases, based on its own internal delegation protocol
    - currently that requires = AS-RS and AS-RO, but maybe it can be = simplified

    To answer to Denis, here's = what I understood:
    - RO trusts AS-RS (and then = handles its own policies within AS-RO)
    - end-user trusts AS-RO = (through its client)

    Could probably work but = that's a fairly different model compared to OAuth2 (and of today's GNAP), with different frontiers between the AS and the RS. 

    Please do not hesitate to = correct me if I'm wrong.

    Fabien 

    On = Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper <agropper@healthurl.com> wrote:
    I believe = there are alternatives to having two kinds of ASs. The problem may be a side-effect of deciding to switch away form treating the RO as different from the RQ. That leads to downstream privacy issues. Our desire for architectural simplicity is admirable but that may have been a step too far.

    =
    There may = also be solutions based on different types of tokens, as in different capabilities (tokens signed by the RS) vs. tokens signed by the AS. I=E2=80=99m not sure = about that but Alan might have more to = say.

    =
    Adrian

    On= Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks. = The general problem statement is clear.

    The proposed = solution a bit less (to me). I understood that from point 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obvious reason to have two types of ASs". Do = you see an alternative ?

    Regarding the last item, I don't think that naming RQ by end-user created the problem. It might just highlight the = asymmetry, which fundamentally = exists. 
    Fabien


    On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper <agropper@healthurl.com> wrote:
    Recap:
    1 - = Justin (I think) introduced the idea of an AS on the RS trust boundary side.
    2 - = I said the RO should not have to share policies with the RS.
    3 - = Alan invented the concept of AS-RO and AS-RS to separate two kinds of PDPs. 

    The = thing is that step 2 is not symmetrical. The RO has a legitimate privacy interest in keeping their policies private and minimizing the leakage of information about requests that are posed against those policies. 

    The = RS, on the other hand, should be publishing its policies (e.g. what it=E2=80=99s selling or = what jurisdiction it=E2=80=99s in = or what tokens or scopes it supports). The RS has no obvious privacy interest in GNAP. It=E2=80=99s = just an enforcer.

    There= is one other privacy interest to consider around the RS and that is the requesting party (the end-user that is not the RO :-) might prefer to share attributes with the RS instead of the RO or something controlled by the RO. This case could be an = =E2=80=9Cextension=E2=80=9D to GNAP and might result in a split AS as a solution. This problem was introduced when the editors decided to replace RQ with end-user. Obviously, the RO end-user has no privacy interests relative to = itself.

    Adrian




    On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    I was = referring to "By my definition, this model has two ASs since both are processing requests into tokens". If there's no reason to have 2 types of ASs, that's fine = then. 
    But I'm a bit lost in where we stand with the = idea. 

    Could you = recap? 

    Fabien 

    Le jeu. 25 mars 2021 =C3=A0 08:16, = Adrian Gropper <agropper@healthurl.com> a = =C3=A9crit :
    There=E2=80=99s no obvious reason to have two types of ASs. Any AS that is executing the policies of the RS can look to GNAP like the RS itself. Why would GNAP expose that interface to = anyone? 

    Adrian

    On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Note : I'm not sure that's a good idea, but having 2 types of ASs is not that easy to grasp.

    Fabien 

    Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault = <fabien.imbault@gmail.com> a = =C3=A9crit :
    The purpose of either handling policies locally or delegating them to the RO = agent. 

    Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper = <agropper@healthurl.com> a = =C3=A9crit :
    What purpose would be served by GNAP splitting the AS into two = components?

    Adrian 

    On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Isn't the AS-RO a component of the AS? Same idea as the interact component, it functionnally belongs to the AS role but could be deployed either as a monolith or as a separate = component?

    Fabien

    Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper = <agropper@healthurl.com> a = =C3=A9crit :
    Yes, but I would say it=E2=80=99s= not the RO that wants the access token. It=E2=80=99s = the RO that wants the client making the request to get an access = token. 

    Adrian

    On Wed, Mar 24, 2021 at 11:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Adrian Gropper <agropper@healthurl.com> wrote:

    In this design, the AS is the AS-RS and the agent is the AS-RO. By my definition, this model has two ASs since both are processing requests into tokens. The problem with this is complexity and privacy. The RO may not want to share the request information with the AS-RS.
    =

    More precisely, RO has no choice but to present the required information to AS-RS if RO wants an access = token.  However, RO does not want AS-RS to know the policy by which RO delegates tokens.  That's why RO uses AS-RO for those = delegations.

    = --------------
    Alan = Karp


    On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper = <agropper@healthurl.com> wrote:
    Thank you for creating the issue. My definition of AS is independent of AS-RO or AS-RS. https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#i= ssuecomment-806280421 I also agree with Alan's definition based on delegation. An AS-RS would be a delegate of the = RS. 

    Based on that, I see it as = obvious that the policy has to be accessible (defined locally?) in order for it to be run as the code that turns a request into an access = token. 

    The only other possibility is that the request is packaged by the AS and sent elsewhere (an agent) for evaluation against policy and a proto-token returned. In that case the AS is acting as a proxy and the PDP is elsewhere. I can imagine that an AS-RS would behave this way so that the proto-token could be turned into an access token by the AS-RS. Isn't this what Justin is proposing? In this design, the AS is the AS-RS and the agent is the AS-RO. By my definition, this model has two ASs since both are processing requests into tokens. The problem with this is complexity and privacy. The RO may not want to share the request information with the AS-RS.

    Adrian

    On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Isn't that what the AS is supposed to be, only with the caveat that the policy is defined locally? 

    Fabien 


    Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp = <alanhkarp@gmail.com> a = =C3=A9crit :
    AS-RO is an AS that RO trusts to delegate RO's access tokens according to RO's = policies.  
    =

    = --------------
    Alan = Karp


    On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Hi Alan and Adrian,

    I've created issue AS-RO policy delegation (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to capture your = input. 
    A first question that arises: can we give a definition to AS-RO?

    Thanks
    Fabien

    On Tue, Mar 23, 2021 at 4:15 PM Alan Karp <alanhkarp@gmail.com> = wrote:
    Fabien Imbault <fabien.imbault@gmail.com> = wrote:
    Hi Alan, 

    Yes, but in that flow, the token relationship between AS-RS and AS-RO is only secure if the tokens issued by AS-RS are = cryptographically attenuable in the first = place. 
     
    =
    Attenuated delegation is a requirement, but that doesn't have to be done = cryptographically.  Token exchange works just fine.  = SPKI and zcap-ld are examples of the crypto approach, and we used token exchange in the system for HP.

    = --------------
    Alan = Karp


    On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Hi Alan, 

    Yes, but in that flow, the token relationship between AS-RS and AS-RO is only secure if the tokens issued by AS-RS are = cryptographically attenuable in the first = place. 

    Fabien

    On Mon, Mar 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com> = wrote:
    Justin Richer <jricher@mit.edu> wrote:
    =

    But with all that in mind, I think the key here is going to be looking at what the inputs to the AS are, and how those can be defined in an interoperable way for AS=E2=80= =99s that can accept them. I think = there=E2=80=99s a lot of room for innovation and flexibility here that doesn=E2=80=99t = break the trust model or core use cases. If I have an AS-RS set that won=E2=80=99t = accept my favorite flavor of policy engine inputs, then I can decide not to use that one. But this is a very different question than saying the RS itself needs to accept my own AS =E2=80=94= and we can=E2=80=99t= keep conflating these two models.

    I agree.  The point of having an AS-RO is to allow RO to specify a policy for which of RO's access tokens should be delegated under what = conditions.  AS-RS should not need to understand those = policies.  The flow would = be
    =
    • RO contacts AS-RS and gets one or more access tokens.
    • RO delegates one or more of those tokens, potentially sub-scoped, to AS-RO.
    • A= different user contacts AS-RO to get a potentially sub-scoped access token from = AS-RO.
    • That user presents the access token delegated by AS-RO when invoking the resource.
    =
    AS-RS only needs to verify that the delegation chain is legitimate, e.g., no increase in scope, and that it grants permission for the request being = made.  AS-RS does not need to understand the policy behind granting the delegation by AS-RO.

    = --------------
    Alan = Karp


    On Mon, Mar 22, 2021 at 11:40 AM Justin Richer = <jricher@mit.edu> wrote:
    Adrian,

    I think this shows the problem with the terminology as it=E2=80=99s = been applied in this conversation, which I=E2=80=99= ve tried to shine light on before. What you and others are calling the =E2=80=9CRS=E2= =80=9D is really the = =E2=80=9CAS and RS working together=E2=80=9D= =E2=80=94 everything to the right of the line. When Denis had brought up =E2=80=9Celimina= ting the AS=E2=80=9D = in another thread, what he=E2=80=99d = really done is labeled everything to the right of the line as the =E2=80=9CRS=E2= =80=9D. Of course, the irony here is that everything to the right of the line used all be called the =E2=80=9CAS=E2= =80=9D or simply =E2=80=9Cserver=E2= =80=9D in the OAuth 1 days. As you say below, I don=E2=80=99t = want the client to have visibility on what happens on that = side. 

    Note well: The Google+ logo labeled = =E2=80=9CIdP=E2=80=9D in the diagram is not the AS, as far as GNAP is concerned. It does not issue an access token that the RS will accept. The elements to the left of the line could be a lot of things, but they are NOT the AS =E2=80=94= by definition. The client lives over on the left, but so do any external inputs to the AS. These could be policy inputs on behalf of the RO, they could be presentation artifacts, they could be federated logins, they could be the output of policy decisions. How the AS comes to trust those things is up to the AS=E2=80=99= s = implementation. It=E2=80=99s = something we can talk about, but ultimately GNAP won=E2=80=99= t be in any position to dictate because in practice some AS=E2=80=99s = are simply going to internalize all policies and we will never successfully force those = open. 

    But with all that in mind, I think the key here is going to be looking at what the inputs to the AS are, and how those can be defined in an interoperable way for AS=E2=80= =99s that can accept them. I think = there=E2=80=99s a lot of room for innovation and flexibility here that doesn=E2=80=99t = break the trust model or core use cases. If I have an AS-RS set that won=E2=80=99t = accept my favorite flavor of policy engine inputs, then I can decide not to use that one. But this is a very different question than saying the RS itself needs to accept my own AS =E2=80=94= and we can=E2=80=99t= keep conflating these two models.

    So to me, GNAP can support a Zero Trust Architecture by LEVERAGING the AS, not by subsuming or eliminating it. It is in fact the AS, not the client and not the RS, that will request and consume the results of a = privacy-preserving zero-trust policy query thing. Anything that happens downstream from that is of little concern to the zero-trust components because, as you point out, it=E2=80=99s = on the =E2=80=9Cother = side=E2=80=9D of the = line. 

    I think we got this basic component model pretty right in OAuth: the AS and RS and client working together. Where OAuth misses the mark is the assumption that the user has to log in to the AS through a webpage and interact directly, thereby proving they=E2=80=99re = the RO. It=E2=80=99s= this latter space where I think we can both push innovation and also address the important and compelling use cases like the ones you=E2=80=99re = bringing.

     =E2=80=94 Justin

    On Mar 22, 2021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> = wrote:

    =
    I'm sorry, Justin. As a Resource Owner, I look at the RS trust boundary (the dotted line in the diagram) as being the RS. I don't expect any visibility into what's going on on = the right. 

    My problem with the framing you propose is that requests are going to the RS (or the AS-RS) and I don't want to share my policies with the AS-RS. I want to keep the RS and AS-RS as ignorant as = possible.

    Adrian

    On Mon, Mar 22, 2021 at 1:48 PM Justin Richer = <jricher@mit.edu> wrote:
    Adrian,

    What you=E2=80=99re discussing below, in terms of logging in to a site, is not approaching the RS. You are in fact approaching the client, and identifying both the AS and RS to the client. The client is a client of your = identity in this model, and the RS is part of the identity provider. = It=E2=80=99s really important that we don=E2=80=99t= conflate the RS and client in this way as it leads to a lot of confusion downstream and a lot of broken trust = boundaries.

    With that model in mind, approaching the =E2=80=9CRS"= and providing it your identity is really just a case of the =E2=80=9Cfederat= ed login to AS=E2=80= =9D pattern that we discussed on the WG call. The user here approaches an RS, which has its own AS. To share things from this RS, the RO has to authenticate to the RS=E2=80=99= s AS. This particular AS allows the RO to do so using an external identity =E2=80=94= in which case, the AS is now a =E2=80=9Cclien= t=E2=80=9D of a separate, disconnected (but layered) delegation. The ultimate client that eventually calls the RS down the way may or may not know about these = layers. 

    <PastedGraphic-1.png>
    This same AS, which is closely tied to the RS and trusted by the RS, might also take in FIDO credentials, or DIDs, or any number of other proof mechanisms. The output of this is an access token the RS trusts, but the input is up to the AS. The RS is not what you=E2=80=99re = logging in to.

     =E2=80=94 Justin

    On Mar 22, 2021, at 1:28 PM, Adrian Gropper <agropper@healthurl.com> = wrote:

    =
    I too am in favor of avoiding consolidation and correlation. Right now, when I approach a service provider (RS) for the first time, I'm offered the opportunity to identify my persona as: email, sign-in with Google, Facebook, or Apple. I know there are people who try to create one-off email addresses but that is mostly a waste of time. 

    So, along come FIDO2 and DID wallets to the rescue. Now, in theory, I have a way to start out my RS relationship = pseudonymously. 

    When I want my resource to be discovered or shared I will post that RS URL including my pseudonym. If I then want to introduce a = mediator in front of my AS or messaging = service endpoint, I have that option. If I want to keep requests away from the mediator, I would publish an encryption key along with my = pseudonym.

    - Adrian



    On Mon, Mar 22, 2021 at 9:55 AM Justin Richer = <jricher@mit.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper = wrote:
    >> @Alan Karp <alanhkarp@gmail.com> shared a = talk about the Principle Of Least
    >> Authority (POLA) in a recent = comment
    >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#i= ssuecomment-803099693
    >> I recommend = it.
    >>
    >> We might expect a protocol with authorization in the title to use authority
    >> as a core principle. I advocate for a GNAP design that maximizes the power
    >> of the RO, to be seen as a human rights issue when the RO is a human. This
    >> causes me to ask how to combine better security with better human rights in
    >> = GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO = to
    >> partition limited authority across dozens of different ASs by domain and
    >> function, then we are not using technology to empower the individual.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into = non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because that maps
    >> into the way we manage our public and private identities. POLA would then
    >> teach care in keeping ASs and RSs related to work / public separate = from
    >> ASs and RSs related to private life so that a policy vulnerability in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least = authority/least privilege would apply to GNAP
    > seems like a useful = exercise.  I do want to point out some potential
    > pitfalls with = one-AS-per-persona that we can also be aware of.  = If
    > = one-AS-per-persona becomes = one-persona-per-AS as well, then the AS's
    > identity in effect also serves as a persona identity and there are privacy
    > considerations to that.  = If, on the other hand, the
    > = multiple-personas-per-AS (presumably corresponding to multiple humans)
    > route is taken, we should consider whether that would lead to various
    > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS = services.  That topic is a current matter of concern to
    > some IETF = participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the UMA working group, and it=E2=80=99s= one of the biggest problems with the personal AS (and personal data store) model. This kind of thing makes RS-first trust models really difficult in practice.

    As a strawman, let=E2=80=99s = say that I=E2=80=99ve = got software that wants to access my medical information. It calls an RS and requests access, but it hasn=E2=80=99t = been granted anything yet. Now I as the RO have set up the RS so that it talks to my personal AS, that only I use. In addition to the RS having to be able to figure out which medical records are being requested from the context of the = unauthenticated request (which means it needs identifiers in the URL or something similar for the RS to be able to tell, assuming that it protects data for more than one person). So this client software doesn=E2=80=99t = know who I am and doesn=E2=80=99t = know my medical record information, makes a completely unauthorized request to the RS, and the RS says =E2=80=9CGo= to Justin=E2=80=99s= personal AS to get a = token=E2=80=9D. The client can now make a direct correlation between the data that=E2=80=99= s being protected at the RS and the person running the AS that protects it. Importantly, this client makes this call with no prior relationship to the RS and no really auditable way to track it down after the fact. This is a design feature in the good case, and terrifying in the bad = case.

    If the RS instead says =E2=80=9Cwelcome= to Medicine Doctor RS, please talk to the Medicine Doctor AS to get access=E2=80= =9D, we haven=E2=80=99= t exposed anything at all. And from the perspective of both the patient and the RS, this is more = privacy-preserving, and it=E2=80=99s= really the least surprising option. Once the client gets to the AS, it can start a negotiation of figuring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS, or set of AS=E2=80=99s = for multiple personas to keep things separate, is a huge burden. Even in the tech community, I know people who can=E2=80=99= t reliably manage more than one email address for different purposes. I wouldn=E2=80=99t= expect my partner to do that =E2=80=94 = they have trouble enough balancing all the logins and sessions required for different kids remote schooling, I couldn=E2=80=99t= imagine them having to understand all the requirements for managing multiple authorization servers and associated policies. I also don=E2=80=99= t expect any person to =E2=80=9Cmanage = keys=E2=80=9D =E2=80=94 = I=E2=80=99ve been on the internet for decades and I can barely keep tabs on my GPG keys, and only use them when I am forced to. This is exactly the kind of =E2=80=9Cmarket pressure=E2=80=9D= that I think Ben mentions above, people will just want to outsource that to someone else, and the reality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice only to end up with a world where the RS ends up making a limited choice anyway. We see how that plays out with OpenID Connect =E2=80=94 = RP=E2=80=99s could allow arbitrary IdPs but they choose Google because it works and that=E2=80=99s = where the users are. (And that=E2=80=99= s not to say anything of the proprietary OIDC-like protocols, but that=E2=80=99s = another = discussion).

    For further reading on these topics, I recommend both =E2=80=9CWh= y Johnny Can=E2=80= =99t Encrypt=E2=80=9D= and =E2=80=9CWhy = CSCW Systems = Fail=E2=80=9D.

    So what does this have to do with GNAP? I think we can be clear-eyed on what kinds of expectations we have for the participants. If we expect users (RO=E2=80=99= s) to have to set up the AS-RS relationship, or expect them to carry their AS, or manage their personal keys =E2=80=94 = I think we=E2=80=99ve = lost the battle for relevance.

     =E2=80=94 = Justin


    --
    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
    =




    = --Apple-Mail=_9DDA8BB3-0F5C-4823-BD50-57294ACB0DEF-- From nobody Thu Mar 25 09:05:22 2021 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 ADB993A2664 for ; Thu, 25 Mar 2021 09:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 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_NONE=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 II8hWCEtEQcM for ; Thu, 25 Mar 2021 09:05:13 -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 0BA203A25DB for ; Thu, 25 Mar 2021 09:05:12 -0700 (PDT) Received: from [192.168.1.22] (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 12PG53O7031575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 25 Mar 2021 12:05:05 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C10EF2E5-6717-42D8-B8E9-99AD38A7C32D" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 25 Mar 2021 12:05:03 -0400 In-Reply-To: Cc: Fabien Imbault , Alan Karp , Benjamin Kaduk , GNAP Mailing List , Mark Miller To: Adrian Gropper References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 16:05:20 -0000 --Apple-Mail=_C10EF2E5-6717-42D8-B8E9-99AD38A7C32D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Adrian, I think it=E2=80=99s dangerous to overestimate the power and sway that a = standards document will have, even once finalized. There needs to be a = compelling reason for the RS to talk to an AS, and =E2=80=9Cthere=E2=80=99= s a standard=E2=80=9D simply isn=E2=80=99t enough. As we=E2=80=99ve both = said for years, the business, legal, and technical (BLT) sandwich needs = to all come into play. GNAP is all about the technical level, but always = influencing what=E2=80=99s possible in the other two with the decisions = and assumptions we make here. That=E2=80=99s why it=E2=80=99s best to = have clear and specific delineations between components.=20 What=E2=80=99s even more dangerous is paying lip service to a standard, = or being just compliant enough to get by but still having lock in. = That=E2=80=99s a huge problem in the SSI world with the DID and VC specs = =E2=80=94 each silo can continue to exist separate from the rest of the = world and still truthfully claim compliance with the standards. SSI = technology will not push user-centered control on its own. There is = absolutely nothing stopping someone from restricting to their own = proprietary DID method and accepting only their own DID documents and = signatures.=20 At the end of the day, a standard is only a standard if it gets used, = and short of regulations forcing people to use GNAP =E2=80=94 and use it = in a particular profile or deployment pattern =E2=80=94 we can=E2=80=99t = expect specific outcomes. Our best hope is to enable them with clear = paths, so that the human-centered pieces slot into the overall = architecture in a meaningful way. The technical protocol will never be = able to fully define this behavior, since if we tried to, GNAP would = either be avoided, ignored, or wrapped around by RS providers. We see = this with how UMA has been deployed in practice today =E2=80=94 it=E2=80=99= s used for single-domain trust delegation, not =E2=80=9CBring your own = AS=E2=80=9D delegation even though it allows that. It=E2=80=99s the = other layers of the sandwich that will push what=E2=80=99s done, we can = only enable what=E2=80=99s possible. =E2=80=94 Justin > On Mar 25, 2021, at 9:23 AM, Adrian Gropper = wrote: >=20 > Thanks for the summary Justin. You very clearly articulated what I = would call the "regulatory capture" aspects of the problem. The RS will = do everything they can to avoid ceding power to the RO. By avoiding = standards that shift power to the RO, the platforms, IdP's, and most = other service providers delay regulation that would promote agent-based = delegated access to an API as a human right.=20 >=20 > It's only recently, with GDPR, that lawmakers have started to consider = human rights outside of healthcare and are now introducing concepts such = as the separation of controller from processor in order to enable a new = generation of regulation. My perspective on GNAP is not arbitrary. It is = honed by years of experience in healthcare as everyone struggles with = OAuth and OpenID Connect, HEART, and now UDAP, to avoid doing in = standards what seems obvious from a human rights perspective. >=20 > What's interesting is that the "regulatory capture" standards game is = now playing out in a new arena. The recent transition of DID to W3C = Candidate Recommendation, together with Verifiable Credentials before = that, means that every regulator (e.g. US Health and Human Services, = Scotland, EU...) and some legislatures (e.g. Wyoming) are having to deal = with the concept of Self-Sovereign Identity. It's not fun for the = community that has worked so hard on SSI to now have to dance-around the = actual impact of the SSI standards. >=20 > With VC and DID, W3C seems to have broken through a "regulatory = capture" barrier and that community is moving on to standardize = protocols like DIDcomm and Encrypted Data Vaults that may avoid = delegated authorization as a human right. In my opinion, GNAP, and IETF, = is facing the same "regulatory capture" barrier.=20 >=20 > Justin says: "Of course, market forces being as they are, I might not = have much of an actionable choice in RS, but GNAP can=E2=80=99t change = that." What GNAP makes core can change the choices the market offers by = making GNAP an interoperability badge that stands for Human-Centered = Protocol. If GNAP moves the human-centered part to an extension, then = we're no better than another "profile" on top of OAuth. >=20 > Adrian >=20 > On Thu, Mar 25, 2021 at 8:46 AM Justin Richer > wrote: > The way I=E2=80=99m thinking about Adrian=E2=80=99s use case is that = what we=E2=80=99re calling the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an = =E2=80=9CAS=E2=80=9D in the traditional OAuth/GNAP sense, at least not = exactly. This is the agent that the RO can use to set policies and = manage consent on their behalf, and I=E2=80=99ve been arguing that it = fits better into this vaguely-defined =E2=80=9Cinteraction component=E2=80= =9D aspect of the current AS definition, and it=E2=80=99s not currently = separated from the AS definition. The =E2=80=9CAS-RS=E2=80=9D maps to = what we=E2=80=99d call the =E2=80=9CAS=E2=80=9D in OAuth/GNAP = traditionally, it=E2=80=99s what the RS trusts to issue tokens. In = traditional OAuth the AS-RO and AS-RS are always the same thing, from a = functional protocol perspective. An important point here is that from a = client=E2=80=99s perspective, they=E2=80=99re only talking to the AS-RS = since that=E2=80=99s where the client gets its tokens, because at the = end of the day the client just wants to call the API at the RS and = doesn=E2=80=99t care how that happens (from a protocol standpoint).=20 >=20 > Note well: Even thought I don=E2=80=99t believe that =E2=80=9CAS-RO=E2=80= =9D is an authorization server at all, I=E2=80=99m going to keep using = that term below for consistency with previous discussion. >=20 > So we have these fundamental relationships around getting the client = to access the RS: >=20 > 1. RS trusts AS-RS to issue tokens that RS will accept, validate, and = process for requests from client > 2. Client trusts AS-RS to issue tokens that client can use at RS > 3. RO trusts RS to protect RO=E2=80=99s api through delegated access >=20 > On top of that, we=E2=80=99ve got some additional aspects that we=E2=80=99= re discussing: >=20 > 4. RO trusts AS-RO to manage RO=E2=80=99s policies at runtime > 5. AS-RS trusts AS-RO to assert RO=E2=80=99s policies for access to RS > 6. Client trusts whatever AS-RS sends client to deal with, including = possibly RO-AS at runtime, because of (2) >=20 > What I have been saying is that 4/5/6 are optional details of how = RS-AS runs things, and I think this also maps with Adrian=E2=80=99s view = of choice, since if my RS=E2=80=99s AS-RS doesn=E2=80=99t allow me to = plug in my own AS-RO then I would be motivated to pick a different RS = who=E2=80=99s AS-RS lets me do just that. The same way I=E2=80=99d pick = a different RS if their surrounding services didn=E2=80=99t accept my = preferred federation login and I didn=E2=80=99t want to make another = account. Of course, market forces being as they are, I might not have = much of an actionable choice in RS, but GNAP can=E2=80=99t change that.=20= >=20 > What we can do is make it possible for AS-RS to talk to AS-RO, both in = philosophy of the protocol design and in concrete hooks to support (6) = above.=20 >=20 > Separately, we can approach the issue of making 1/2 above more = dynamic. This was UMA2=E2=80=99s =E2=80=9Cfederated authorization=E2=80=9D= approach, and is behind a lot of the =E2=80=9Cbring your own AS=E2=80=9D = models out there. The problem with these is that we know from many years = of experience that most RS=E2=80=99s aren=E2=80=99t interested in doing = anything of the sort. >=20 > So with GNAP we can instead allow 4/5/6 to vary in a predictable and = consistent way, letting the RS keep control over 1/2, thereby enabling = choice in (3). We don=E2=80=99t have to be the ones who define the all = of the details of every permutation of (5) to enable this, though. Some = of this is going to be configuration out of band, some of it=E2=80=99s = going to be communication at runtime. This is where VC=E2=80=99s, ZCAPs, = CHAPI, DIDComm, FIDO, and a whole swath of other tech can come in and = help out. I don=E2=80=99t think we need to put all the details for using = these into core, nor do I think we=E2=80=99ll pull of The Great And = Ultimate Abstraction for using these and other approaches. But we can at = least start talking about =E2=80=9CAS-RS=E2=80=9D in such a way that it = no longer assumes it=E2=80=99s always the same party dealing with the RO = directly. >=20 > =E2=80=94 Justin >=20 >> On Mar 25, 2021, at 6:40 AM, Fabien Imbault > wrote: >>=20 >> To reframe it closer to GNAP: >> - AS =3D AS-RO, that's where you find the RO policies. The AS issues = access tokens to the client. >> - the RO policies could be a) defined locally or b) in relationship = with the RS >>=20 >> There have been several ideas related to the AS-RS relationship b: >> b1) the RS issues capabilities (which can be further attenuated by = the RO) >> b2) Adrian also discussed a DID based solution >> b3) there was also an alternative ACL proposal from Denis (+ = preflight) >>=20 >> Fabien >>=20 >>=20 >> On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault = > wrote: >> Ok so I get you correctly:=20 >> - what matters is the RQ (could be a RO or a end-user or both : we = don't really care at a high-level, they're all treated as entities that = make a request) >> - the policy is able to handle those different cases, based on its = own internal delegation protocol >> - currently that requires AS-RS and AS-RO, but maybe it can be = simplified >>=20 >> To answer to Denis, here's what I understood: >> - RO trusts AS-RS (and then handles its own policies within AS-RO) >> - end-user trusts AS-RO (through its client) >>=20 >> Could probably work but that's a fairly different model compared to = OAuth2 (and of today's GNAP), with different frontiers between the AS = and the RS.=20 >>=20 >> Please do not hesitate to correct me if I'm wrong. >>=20 >> Fabien=20 >>=20 >> On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper = > wrote: >> I believe there are alternatives to having two kinds of ASs. The = problem may be a side-effect of deciding to switch away form treating = the RO as different from the RQ. That leads to downstream privacy = issues. Our desire for architectural simplicity is admirable but that = may have been a step too far. >>=20 >> There may also be solutions based on different types of tokens, as in = different capabilities (tokens signed by the RS) vs. tokens signed by = the AS. I=E2=80=99m not sure about that but Alan might have more to say. >>=20 >> Adrian >>=20 >> On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault = > wrote: >> Thanks. The general problem statement is clear. >>=20 >> The proposed solution a bit less (to me). I understood that from = point 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obvious = reason to have two types of ASs". Do you see an alternative ? >>=20 >> Regarding the last item, I don't think that naming RQ by end-user = created the problem. It might just highlight the asymmetry, which = fundamentally exists.=20 >>=20 >> Fabien >>=20 >>=20 >> On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper = > wrote: >> Recap: >> 1 - Justin (I think) introduced the idea of an AS on the RS trust = boundary side. >> 2 - I said the RO should not have to share policies with the RS. >> 3 - Alan invented the concept of AS-RO and AS-RS to separate two = kinds of PDPs.=20 >>=20 >> The thing is that step 2 is not symmetrical. The RO has a legitimate = privacy interest in keeping their policies private and minimizing the = leakage of information about requests that are posed against those = policies.=20 >>=20 >> The RS, on the other hand, should be publishing its policies (e.g. = what it=E2=80=99s selling or what jurisdiction it=E2=80=99s in or what = tokens or scopes it supports). The RS has no obvious privacy interest in = GNAP. It=E2=80=99s just an enforcer. >>=20 >> There is one other privacy interest to consider around the RS and = that is the requesting party (the end-user that is not the RO :-) might = prefer to share attributes with the RS instead of the RO or something = controlled by the RO. This case could be an =E2=80=9Cextension=E2=80=9D = to GNAP and might result in a split AS as a solution. This problem was = introduced when the editors decided to replace RQ with end-user. = Obviously, the RO end-user has no privacy interests relative to itself. >>=20 >> Adrian >>=20 >>=20 >>=20 >>=20 >> On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault = > wrote: >> I was referring to "By my definition, this model has two ASs since = both are processing requests into tokens". If there's no reason to have = 2 types of ASs, that's fine then.=20 >> But I'm a bit lost in where we stand with the idea.=20 >>=20 >> Could you recap?=20 >>=20 >> Fabien=20 >>=20 >> Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper = > a =C3=A9crit : >> There=E2=80=99s no obvious reason to have two types of ASs. Any AS = that is executing the policies of the RS can look to GNAP like the RS = itself. Why would GNAP expose that interface to anyone?=20 >>=20 >> Adrian >>=20 >> On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault = > wrote: >> Note : I'm not sure that's a good idea, but having 2 types of ASs is = not that easy to grasp. >>=20 >> Fabien=20 >>=20 >> Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault = > a =C3=A9crit = : >> The purpose of either handling policies locally or delegating them to = the RO agent.=20 >>=20 >> Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper = > a =C3=A9crit : >> What purpose would be served by GNAP splitting the AS into two = components? >>=20 >> Adrian=20 >>=20 >> On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault = > wrote: >> Isn't the AS-RO a component of the AS? Same idea as the interact = component, it functionnally belongs to the AS role but could be deployed = either as a monolith or as a separate component? >>=20 >> Fabien >>=20 >> Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper = > a =C3=A9crit : >> Yes, but I would say it=E2=80=99s not the RO that wants the access = token. It=E2=80=99s the RO that wants the client making the request to = get an access token.=20 >>=20 >> Adrian >>=20 >> On Wed, Mar 24, 2021 at 11:22 PM Alan Karp > wrote: >> Adrian Gropper > wrote: >>=20 >> In this design, the AS is the AS-RS and the agent is the AS-RO. By my = definition, this model has two ASs since both are processing requests = into tokens. The problem with this is complexity and privacy. The RO may = not want to share the request information with the AS-RS. >>=20 >> More precisely, RO has no choice but to present the required = information to AS-RS if RO wants an access token. However, RO does not = want AS-RS to know the policy by which RO delegates tokens. That's why = RO uses AS-RO for those delegations. >>=20 >> -------------- >> Alan Karp >>=20 >>=20 >> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper = > wrote: >> Thank you for creating the issue. My definition of AS is independent = of AS-RO or AS-RS. = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomment= -806280421 = I also agree with Alan's definition based on delegation. An = AS-RS would be a delegate of the RS.=20 >>=20 >> Based on that, I see it as obvious that the policy has to be = accessible (defined locally?) in order for it to be run as the code that = turns a request into an access token.=20 >>=20 >> The only other possibility is that the request is packaged by the AS = and sent elsewhere (an agent) for evaluation against policy and a = proto-token returned. In that case the AS is acting as a proxy and the = PDP is elsewhere. I can imagine that an AS-RS would behave this way so = that the proto-token could be turned into an access token by the AS-RS. = Isn't this what Justin is proposing? In this design, the AS is the AS-RS = and the agent is the AS-RO. By my definition, this model has two ASs = since both are processing requests into tokens. The problem with this is = complexity and privacy. The RO may not want to share the request = information with the AS-RS. >>=20 >> Adrian >>=20 >> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault = > wrote: >> Isn't that what the AS is supposed to be, only with the caveat that = the policy is defined locally?=20 >>=20 >> Fabien=20 >>=20 >>=20 >> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp > a =C3=A9crit : >> AS-RO is an AS that RO trusts to delegate RO's access tokens = according to RO's policies. =20 >>=20 >> -------------- >> Alan Karp >>=20 >>=20 >> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault = > wrote: >> Hi Alan and Adrian, >>=20 >> I've created issue AS-RO policy delegation = (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223 = ) to = capture your input.=20 >> A first question that arises: can we give a definition to AS-RO? >>=20 >> Thanks >> Fabien >>=20 >> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp > wrote: >> Fabien Imbault > wrote: >> Hi Alan,=20 >>=20 >> Yes, but in that flow, the token relationship between AS-RS and AS-RO = is only secure if the tokens issued by AS-RS are cryptographically = attenuable in the first place.=20 >> =20 >> Attenuated delegation is a requirement, but that doesn't have to be = done cryptographically. Token exchange works just fine. SPKI and = zcap-ld are examples of the crypto approach, and we used token exchange = in the system for HP. >>=20 >> -------------- >> Alan Karp >>=20 >>=20 >> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault = > wrote: >> Hi Alan,=20 >>=20 >> Yes, but in that flow, the token relationship between AS-RS and AS-RO = is only secure if the tokens issued by AS-RS are cryptographically = attenuable in the first place.=20 >>=20 >> Fabien >>=20 >> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp > wrote: >> Justin Richer > wrote: >>=20 >> But with all that in mind, I think the key here is going to be = looking at what the inputs to the AS are, and how those can be defined = in an interoperable way for AS=E2=80=99s that can accept them. I think = there=E2=80=99s a lot of room for innovation and flexibility here that = doesn=E2=80=99t break the trust model or core use cases. If I have an = AS-RS set that won=E2=80=99t accept my favorite flavor of policy engine = inputs, then I can decide not to use that one. But this is a very = different question than saying the RS itself needs to accept my own AS = =E2=80=94 and we can=E2=80=99t keep conflating these two models. >>=20 >> I agree. The point of having an AS-RO is to allow RO to specify a = policy for which of RO's access tokens should be delegated under what = conditions. AS-RS should not need to understand those policies. The = flow would be >> RO contacts AS-RS and gets one or more access tokens. >> RO delegates one or more of those tokens, potentially sub-scoped, to = AS-RO. >> A different user contacts AS-RO to get a potentially sub-scoped = access token from AS-RO. >> That user presents the access token delegated by AS-RO when invoking = the resource. >> AS-RS only needs to verify that the delegation chain is legitimate, = e.g., no increase in scope, and that it grants permission for the = request being made. AS-RS does not need to understand the policy behind = granting the delegation by AS-RO. >>=20 >> -------------- >> Alan Karp >>=20 >>=20 >> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer > wrote: >> Adrian, >>=20 >> I think this shows the problem with the terminology as it=E2=80=99s = been applied in this conversation, which I=E2=80=99ve tried to shine = light on before. What you and others are calling the =E2=80=9CRS=E2=80=9D = is really the =E2=80=9CAS and RS working together=E2=80=9D =E2=80=94 = everything to the right of the line. When Denis had brought up = =E2=80=9Celiminating the AS=E2=80=9D in another thread, what he=E2=80=99d = really done is labeled everything to the right of the line as the = =E2=80=9CRS=E2=80=9D. Of course, the irony here is that everything to = the right of the line used all be called the =E2=80=9CAS=E2=80=9D or = simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say below, I = don=E2=80=99t want the client to have visibility on what happens on that = side.=20 >>=20 >> Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the = diagram is not the AS, as far as GNAP is concerned. It does not issue an = access token that the RS will accept. The elements to the left of the = line could be a lot of things, but they are NOT the AS =E2=80=94 by = definition. The client lives over on the left, but so do any external = inputs to the AS. These could be policy inputs on behalf of the RO, they = could be presentation artifacts, they could be federated logins, they = could be the output of policy decisions. How the AS comes to trust those = things is up to the AS=E2=80=99s implementation. It=E2=80=99s something = we can talk about, but ultimately GNAP won=E2=80=99t be in any position = to dictate because in practice some AS=E2=80=99s are simply going to = internalize all policies and we will never successfully force those = open.=20 >>=20 >> But with all that in mind, I think the key here is going to be = looking at what the inputs to the AS are, and how those can be defined = in an interoperable way for AS=E2=80=99s that can accept them. I think = there=E2=80=99s a lot of room for innovation and flexibility here that = doesn=E2=80=99t break the trust model or core use cases. If I have an = AS-RS set that won=E2=80=99t accept my favorite flavor of policy engine = inputs, then I can decide not to use that one. But this is a very = different question than saying the RS itself needs to accept my own AS = =E2=80=94 and we can=E2=80=99t keep conflating these two models. >>=20 >> So to me, GNAP can support a Zero Trust Architecture by LEVERAGING = the AS, not by subsuming or eliminating it. It is in fact the AS, not = the client and not the RS, that will request and consume the results of = a privacy-preserving zero-trust policy query thing. Anything that = happens downstream from that is of little concern to the zero-trust = components because, as you point out, it=E2=80=99s on the =E2=80=9Cother = side=E2=80=9D of the line.=20 >>=20 >> I think we got this basic component model pretty right in OAuth: the = AS and RS and client working together. Where OAuth misses the mark is = the assumption that the user has to log in to the AS through a webpage = and interact directly, thereby proving they=E2=80=99re the RO. It=E2=80=99= s this latter space where I think we can both push innovation and also = address the important and compelling use cases like the ones you=E2=80=99r= e bringing. >>=20 >> =E2=80=94 Justin >>=20 >>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper > wrote: >>>=20 >>> I'm sorry, Justin. As a Resource Owner, I look at the RS trust = boundary (the dotted line in the diagram) as being the RS. I don't = expect any visibility into what's going on on the right.=20 >>>=20 >>> My problem with the framing you propose is that requests are going = to the RS (or the AS-RS) and I don't want to share my policies with the = AS-RS. I want to keep the RS and AS-RS as ignorant as possible. >>>=20 >>> Adrian >>>=20 >>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer > wrote: >>> Adrian, >>>=20 >>> What you=E2=80=99re discussing below, in terms of logging in to a = site, is not approaching the RS. You are in fact approaching the client, = and identifying both the AS and RS to the client. The client is a client = of your identity in this model, and the RS is part of the identity = provider. It=E2=80=99s really important that we don=E2=80=99t conflate = the RS and client in this way as it leads to a lot of confusion = downstream and a lot of broken trust boundaries. >>>=20 >>> With that model in mind, approaching the =E2=80=9CRS" and providing = it your identity is really just a case of the =E2=80=9Cfederated login = to AS=E2=80=9D pattern that we discussed on the WG call. The user here = approaches an RS, which has its own AS. To share things from this RS, = the RO has to authenticate to the RS=E2=80=99s AS. This particular AS = allows the RO to do so using an external identity =E2=80=94 in which = case, the AS is now a =E2=80=9Cclient=E2=80=9D of a separate, = disconnected (but layered) delegation. The ultimate client that = eventually calls the RS down the way may or may not know about these = layers.=20 >>>=20 >>> >>> This same AS, which is closely tied to the RS and trusted by the RS, = might also take in FIDO credentials, or DIDs, or any number of other = proof mechanisms. The output of this is an access token the RS trusts, = but the input is up to the AS. The RS is not what you=E2=80=99re logging = in to. >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper > wrote: >>>>=20 >>>> I too am in favor of avoiding consolidation and correlation. Right = now, when I approach a service provider (RS) for the first time, I'm = offered the opportunity to identify my persona as: email, sign-in with = Google, Facebook, or Apple. I know there are people who try to create = one-off email addresses but that is mostly a waste of time.=20 >>>>=20 >>>> So, along come FIDO2 and DID wallets to the rescue. Now, in theory, = I have a way to start out my RS relationship pseudonymously.=20 >>>>=20 >>>> When I want my resource to be discovered or shared I will post that = RS URL including my pseudonym. If I then want to introduce a mediator in = front of my AS or messaging service endpoint, I have that option. If I = want to keep requests away from the mediator, I would publish an = encryption key along with my pseudonym. >>>>=20 >>>> - Adrian >>>>=20 >>>>=20 >>>>=20 >>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer > wrote: >>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk > wrote: >>>> >=20 >>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote: >>>> >> @Alan Karp > = shared a talk about the Principle Of Least >>>> >> Authority (POLA) in a recent comment >>>> >> = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment= -803099693 = >>>> >> I recommend it. >>>> >>=20 >>>> >> We might expect a protocol with authorization in the title to = use authority >>>> >> as a core principle. I advocate for a GNAP design that maximizes = the power >>>> >> of the RO, to be seen as a human rights issue when the RO is a = human. This >>>> >> causes me to ask how to combine better security with better = human rights in >>>> >> GNAP. >>>> >>=20 >>>> >> Who should have the least authority in the GNAP design? >>>> >>=20 >>>> >> The AS derives authority as a delegate of the RO. If we ask the = RO to >>>> >> partition limited authority across dozens of different ASs by = domain and >>>> >> function, then we are not using technology to empower the = individual. >>>> >> Probably the opposite, as we introduce consent fatigue and = burden normal >>>> >> people to partition their lives into non-overlapping domains. >>>> >>=20 >>>> >> My experience says we should aim for one AS per persona because = that maps >>>> >> into the way we manage our public and private identities. POLA = would then >>>> >> teach care in keeping ASs and RSs related to work / public = separate from >>>> >> ASs and RSs related to private life so that a policy = vulnerability in our >>>> >> delegation to an AS would have the least likelihood of harm. >>>> >=20 >>>> > Thinking about how least authority/least privilege would apply to = GNAP >>>> > seems like a useful exercise. I do want to point out some = potential >>>> > pitfalls with one-AS-per-persona that we can also be aware of. = If >>>> > one-AS-per-persona becomes one-persona-per-AS as well, then the = AS's >>>> > identity in effect also serves as a persona identity and there = are privacy >>>> > considerations to that. If, on the other hand, the >>>> > multiple-personas-per-AS (presumably corresponding to multiple = humans) >>>> > route is taken, we should consider whether that would lead to = various >>>> > (e.g., market) forces driving consolidation to just a handful of >>>> > super-popular AS services. That topic is a current matter of = concern to >>>> > some IETF participants. >>>> >=20 >>>>=20 >>>> Hi Ben, big +1 to this. This is something that we discussed ages = ago in the UMA working group, and it=E2=80=99s one of the biggest = problems with the personal AS (and personal data store) model. This kind = of thing makes RS-first trust models really difficult in practice. >>>>=20 >>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve got software = that wants to access my medical information. It calls an RS and requests = access, but it hasn=E2=80=99t been granted anything yet. Now I as the RO = have set up the RS so that it talks to my personal AS, that only I use. = In addition to the RS having to be able to figure out which medical = records are being requested from the context of the unauthenticated = request (which means it needs identifiers in the URL or something = similar for the RS to be able to tell, assuming that it protects data = for more than one person). So this client software doesn=E2=80=99t know = who I am and doesn=E2=80=99t know my medical record information, makes a = completely unauthorized request to the RS, and the RS says =E2=80=9CGo = to Justin=E2=80=99s personal AS to get a token=E2=80=9D. The client can = now make a direct correlation between the data that=E2=80=99s being = protected at the RS and the person running the AS that protects it. = Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This = is a design feature in the good case, and terrifying in the bad case. >>>>=20 >>>> If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, = please talk to the Medicine Doctor AS to get access=E2=80=9D, we = haven=E2=80=99t exposed anything at all. And from the perspective of = both the patient and the RS, this is more privacy-preserving, and it=E2=80= =99s really the least surprising option. Once the client gets to the AS, = it can start a negotiation of figuring out who the RO is for the = information being accessed. >>>>=20 >>>> On top of this, the usability expectations of people managing their = own AS, or set of AS=E2=80=99s for multiple personas to keep things = separate, is a huge burden. Even in the tech community, I know people = who can=E2=80=99t reliably manage more than one email address for = different purposes. I wouldn=E2=80=99t expect my partner to do that =E2=80= =94 they have trouble enough balancing all the logins and sessions = required for different kids remote schooling, I couldn=E2=80=99t imagine = them having to understand all the requirements for managing multiple = authorization servers and associated policies. I also don=E2=80=99t = expect any person to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve = been on the internet for decades and I can barely keep tabs on my GPG = keys, and only use them when I am forced to. This is exactly the kind of = =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions above, = people will just want to outsource that to someone else, and the reality = will be a few popular providers. >>>>=20 >>>> In which case, we could end up doing a ton of work to allow an RS = choice only to end up with a world where the RS ends up making a limited = choice anyway. We see how that plays out with OpenID Connect =E2=80=94 = RP=E2=80=99s could allow arbitrary IdPs but they choose Google because = it works and that=E2=80=99s where the users are. (And that=E2=80=99s not = to say anything of the proprietary OIDC-like protocols, but that=E2=80=99s= another discussion). >>>>=20 >>>> For further reading on these topics, I recommend both =E2=80=9CWhy = Johnny Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems = Fail=E2=80=9D. >>>>=20 >>>> So what does this have to do with GNAP? I think we can be = clear-eyed on what kinds of expectations we have for the participants. = If we expect users (RO=E2=80=99s) to have to set up the AS-RS = relationship, or expect them to carry their AS, or manage their personal = keys =E2=80=94 I think we=E2=80=99ve lost the battle for relevance. >>>>=20 >>>> =E2=80=94 Justin >>>=20 >>=20 >> --=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 = >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >=20 --Apple-Mail=_C10EF2E5-6717-42D8-B8E9-99AD38A7C32D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Adrian,

    I = think it=E2=80=99s dangerous to overestimate the power and sway that a = standards document will have, even once finalized. There needs to be a = compelling reason for the RS to talk to an AS, and =E2=80=9Cthere=E2=80=99= s a standard=E2=80=9D simply isn=E2=80=99t enough. As we=E2=80=99ve both = said for years, the business, legal, and technical (BLT) sandwich needs = to all come into play. GNAP is all about the technical level, but always = influencing what=E2=80=99s possible in the other two with the decisions = and assumptions we make here. That=E2=80=99s why it=E2=80=99s best to = have clear and specific delineations between components. 

    What=E2=80=99s even more = dangerous is paying lip service to a standard, or being just compliant = enough to get by but still having lock in. That=E2=80=99s a huge problem = in the SSI world with the DID and VC specs =E2=80=94 each silo can = continue to exist separate from the rest of the world and still = truthfully claim compliance with the standards. SSI technology will not = push user-centered control on its own. There is absolutely nothing = stopping someone from restricting to their own proprietary DID method = and accepting only their own DID documents and = signatures. 

    At the end of the day, a standard is only a standard if it = gets used, and short of regulations forcing people to use GNAP =E2=80=94 = and use it in a particular profile or deployment pattern =E2=80=94 we = can=E2=80=99t expect specific outcomes. Our best hope is to enable them = with clear paths, so that the human-centered pieces slot into the = overall architecture in a meaningful way. The technical protocol will = never be able to fully define this behavior, since if we tried to, GNAP = would either be avoided, ignored, or wrapped around by RS providers. We = see this with how UMA has been deployed in practice today =E2=80=94 = it=E2=80=99s used for single-domain trust delegation, not =E2=80=9CBring = your own AS=E2=80=9D delegation even though it allows that. It=E2=80=99s = the other layers of the sandwich that will push what=E2=80=99s done, we = can only enable what=E2=80=99s possible.

     =E2=80=94 Justin


    On Mar 25, 2021, at 9:23 AM, Adrian Gropper = <agropper@healthurl.com> wrote:

    Thanks = for the summary Justin. You very clearly articulated what I would call = the "regulatory capture" aspects of the problem. The RS will do = everything they can to avoid ceding power to the RO. By avoiding = standards that shift power to the RO, the platforms, IdP's, and most = other service providers delay regulation that would promote agent-based = delegated access to an API as a human right. 

    It's only recently, with GDPR, that = lawmakers have started to consider human rights outside of = healthcare and are now introducing concepts such as the separation of = controller from processor in order to enable a new generation of = regulation. My perspective on GNAP is not arbitrary. It is honed by = years of experience in healthcare as everyone struggles with OAuth = and OpenID Connect, HEART, and now UDAP, to avoid doing in standards = what seems obvious from a human rights perspective.

    What's interesting is = that the "regulatory capture" standards game is now playing out in a new = arena. The recent transition of DID to W3C Candidate Recommendation, = together with Verifiable Credentials before that, means that every = regulator (e.g. US Health and Human Services, Scotland, EU...) and some = legislatures (e.g. Wyoming) are having to deal with the concept of = Self-Sovereign Identity. It's not fun for the community that has worked = so hard on SSI to now have to dance-around the actual impact of the SSI = standards.

    With = VC and DID, W3C seems to have broken through a "regulatory capture" = barrier and that community is moving on to standardize protocols like = DIDcomm and Encrypted Data Vaults that may avoid delegated authorization = as a human right. In my opinion, GNAP, and IETF, is facing the same = "regulatory capture" barrier. 

    Justin says: "Of course, market forces = being as they are, I might not have much of an actionable choice in RS, = but GNAP can=E2=80=99t change that." What GNAP makes core can change the = choices the market offers by making GNAP an interoperability badge that = stands for Human-Centered Protocol. If GNAP moves the human-centered = part to an extension, then we're no better than another "profile" on top = of OAuth.

    Adrian

    On Thu, Mar = 25, 2021 at 8:46 AM Justin Richer <jricher@mit.edu> wrote:
    The= way I=E2=80=99m thinking about Adrian=E2=80=99s use case is that what = we=E2=80=99re calling the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an = =E2=80=9CAS=E2=80=9D in the traditional OAuth/GNAP sense, at least not = exactly. This is the agent that the RO can use to set policies and = manage consent on their behalf, and I=E2=80=99ve been arguing that it = fits better into this vaguely-defined =E2=80=9Cinteraction component=E2=80= =9D aspect of the current AS definition, and it=E2=80=99s not currently = separated from the AS definition. The =E2=80=9CAS-RS=E2=80=9D maps to = what we=E2=80=99d call the =E2=80=9CAS=E2=80=9D in OAuth/GNAP = traditionally, it=E2=80=99s what the RS trusts to issue tokens. In = traditional OAuth the AS-RO and AS-RS are always the same thing, from a = functional protocol perspective. An important point here is that from a = client=E2=80=99s perspective, they=E2=80=99re only talking to the AS-RS = since that=E2=80=99s where the client gets its tokens, because at the = end of the day the client just wants to call the API at the RS and = doesn=E2=80=99t care how that happens (from a protocol = standpoint). 

    Note well: Even thought I don=E2=80=99t believe that = =E2=80=9CAS-RO=E2=80=9D is an authorization server at all, I=E2=80=99m = going to keep using that term below for consistency with previous = discussion.

    So = we have these fundamental relationships around getting the client to = access the RS:

    1. RS trusts AS-RS to issue tokens that RS will = accept, validate, and process for requests from client
    2. Client trusts AS-RS to issue tokens that client = can use at RS
    3. RO trusts RS to protect RO=E2=80=99s= api through delegated access

    On top of that, we=E2=80=99ve got some = additional aspects that we=E2=80=99re discussing:
    4. RO trusts AS-RO to manage = RO=E2=80=99s policies at runtime
    5. AS-RS trusts AS-RO to assert RO=E2=80=99= s policies for access to RS
    6. Client trusts = whatever AS-RS sends client to deal with, including possibly = RO-AS at runtime, because of (2)

    What I have been saying is that 4/5/6 = are optional details of how RS-AS runs things, and I think this also = maps with Adrian=E2=80=99s view of choice, since if my RS=E2=80=99s = AS-RS doesn=E2=80=99t allow me to plug in my own AS-RO then I would be = motivated to pick a different RS who=E2=80=99s AS-RS lets me do just = that. The same way I=E2=80=99d pick a different RS if their surrounding = services didn=E2=80=99t accept my preferred federation login and I = didn=E2=80=99t want to make another account. Of course, market forces = being as they are, I might not have much of an actionable choice in RS, = but GNAP can=E2=80=99t change that. 

    What we can do is make it possible for = AS-RS to talk to AS-RO, both in philosophy of the protocol design and in = concrete hooks to support (6) above. 

    Separately, we can approach the issue = of making 1/2 above more dynamic. This was UMA2=E2=80=99s =E2=80=9Cfederat= ed authorization=E2=80=9D approach, and is behind a lot of the =E2=80=9Cbr= ing your own AS=E2=80=9D models out there. The problem with these is = that we know from many years of experience that most RS=E2=80=99s = aren=E2=80=99t interested in doing anything of the sort.

    So with GNAP we can = instead allow 4/5/6 to vary in a predictable and consistent way, letting = the RS keep control over 1/2, thereby enabling choice in (3). We don=E2=80= =99t have to be the ones who define the all of the details of every = permutation of (5) to enable this, though. Some of this is going to be = configuration out of band, some of it=E2=80=99s going to be = communication at runtime. This is where VC=E2=80=99s, ZCAPs, CHAPI, = DIDComm, FIDO, and a whole swath of other tech can come in and help out. = I don=E2=80=99t think we need to put all the details for using these = into core, nor do I think we=E2=80=99ll pull of The Great And Ultimate = Abstraction for using these and other approaches. But we can at least = start talking about =E2=80=9CAS-RS=E2=80=9D in such a way that it no = longer assumes it=E2=80=99s always the same party dealing with the RO = directly.

     =E2=80=94 Justin

    On Mar = 25, 2021, at 6:40 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    To reframe it = closer to GNAP:
    - AS =3D AS-RO, that's where you find the = RO policies. The AS issues access tokens to the client.
    - the RO policies could be a) defined locally or b) in = relationship with the RS

    There have been several ideas related to the AS-RS = relationship b:
    b1) the RS issues = capabilities (which can be further attenuated by the RO)
    b2) Adrian also discussed a DID based solution
    b3) there was also an alternative ACL proposal from Denis (+ = preflight)

    Fabien


    On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Ok so I get = you correctly: 
    - what matters is the RQ (could be a = RO or a end-user or both : we don't really care at a high-level, they're = all treated as entities that make a request)
    - the = policy is able to handle those different cases, based on its own = internal delegation protocol
    - currently that = requires AS-RS and AS-RO, but maybe it can be simplified

    To answer to Denis, = here's what I understood:
    - RO trusts AS-RS (and = then handles its own policies within AS-RO)
    - end-user trusts AS-RO (through its client)

    Could probably work but = that's a fairly different model compared to OAuth2 (and of today's = GNAP), with different frontiers between the AS and the = RS. 

    Please= do not hesitate to correct me if I'm wrong.

    Fabien 

    On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper = <agropper@healthurl.com> wrote:
    I believe = there are alternatives to having two kinds of ASs. The problem may be a = side-effect of deciding to switch away form treating the RO as different = from the RQ. That leads to downstream privacy issues. Our desire for = architectural simplicity is admirable but that may have been a step too = far.

    There may also be solutions based on different = types of tokens, as in different capabilities (tokens signed by the RS) = vs. tokens signed by the AS. I=E2=80=99m not sure about that but Alan = might have more to say.

    Adrian

    On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Thanks. The = general problem statement is clear.

    The proposed solution a bit less = (to me). I understood that from point 2, Alan involves 2 ASs. You said : = "There=E2=80=99s no = obvious reason to have two types of ASs". Do you see an = alternative ?

    Regarding the last item, I don't think that = naming RQ by end-user created the problem. It might just highlight the = asymmetry, which fundamentally exists. 

    Fabien


    On Thu, Mar 25, 2021 at 8:48 AM Adrian = Gropper <agropper@healthurl.com> wrote:
    Recap:
    1 - Justin (I think) = introduced the idea of an AS on the RS trust boundary side.
    2 - I said the RO should not have to share = policies with the RS.
    3 - Alan = invented the concept of AS-RO and AS-RS to separate two kinds of = PDPs. 

    The thing is that step 2 is not symmetrical. The = RO has a legitimate privacy interest in keeping their policies private = and minimizing the leakage of information about requests that are posed = against those policies. 

    The RS, on the other hand, = should be publishing its policies (e.g. what it=E2=80=99s selling or = what jurisdiction it=E2=80=99s in or what tokens or scopes it supports). = The RS has no obvious privacy interest in GNAP. It=E2=80=99s just an = enforcer.

    There is one other privacy interest to consider = around the RS and that is the requesting party (the end-user that is not = the RO :-) might prefer to share attributes with the RS instead of the = RO or something controlled by the RO. This case could be an = =E2=80=9Cextension=E2=80=9D to GNAP and might result in a split AS as a = solution. This problem was introduced when the editors decided to = replace RQ with end-user. Obviously, the RO end-user has no privacy = interests relative to itself.

    Adrian




    On Thu, Mar = 25, 2021 at 3:24 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    I was referring to "By my definition, this model has two ASs since both are = processing requests into tokens". If there's no reason to have 2 types = of ASs, that's fine then. 
    But I'm a bit lost in = where we stand with the idea. 

    Could you = recap? 

    Fabien 

    Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper = <agropper@healthurl.com> a =C3=A9crit :
    There=E2=80=99= s no obvious reason to have two types of ASs. Any AS that is executing = the policies of the RS can look to GNAP like the RS itself. Why would = GNAP expose that interface to anyone? 

    Adrian

    On Thu, Mar = 25, 2021 at 3:11 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Note : I'm = not sure that's a good idea, but having 2 types of ASs is not that easy = to grasp.

    Fabien 

    Le jeu. 25 = mars 2021 =C3=A0 08:07, Fabien Imbault <fabien.imbault@gmail.com> a = =C3=A9crit :
    The purpose = of either handling policies locally or delegating them to the RO = agent. 

    Le jeu. 25 mars 2021 =C3=A0 08:04, = Adrian Gropper <agropper@healthurl.com> a =C3=A9crit :
    What purpose = would be served by GNAP splitting the AS into two components?

    Adrian 

    On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Isn't the = AS-RO a component of the AS? Same idea as the interact component, it = functionnally belongs to the AS role but could be deployed either as a = monolith or as a separate component?

    Fabien

    Le jeu. 25 = mars 2021 =C3=A0 04:26, Adrian Gropper <agropper@healthurl.com> = a =C3=A9crit :
    Yes, but I = would say it=E2=80=99s not the RO that wants the access token. It=E2=80=99= s the RO that wants the client making the request to get an access = token. 

    Adrian

    On Wed, Mar = 24, 2021 at 11:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Adrian = Gropper <agropper@healthurl.com> wrote:

    In this = design, the AS is the AS-RS and the agent is the AS-RO. By my = definition, this model has two ASs since both are processing requests = into tokens. The problem with this is complexity and privacy. The RO may = not want to share the request information with the AS-RS.

    More precisely, RO has = no choice but to present the required information to AS-RS if RO wants = an access token.  However, RO does not want AS-RS to know the = policy by which RO delegates tokens.  That's why RO uses AS-RO for = those delegations.

    --------------
    Alan Karp


    On Wed, Mar = 24, 2021 at 7:41 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Thank you for creating the issue. My definition = of AS is independent of AS-RO or AS-RS. https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#i= ssuecomment-806280421 I also agree with Alan's definition based on = delegation. An AS-RS would be a delegate of the RS. 

    Based on = that, I see it as obvious that the policy has to be accessible = (defined locally?) in order for it to be run as the code that turns a = request into an access token. 

    The only other possibility is that the = request is packaged by the AS and sent elsewhere (an agent) for = evaluation against policy and a proto-token returned. In that case the = AS is acting as a proxy and the PDP is elsewhere. I can imagine that an = AS-RS would behave this way so that the proto-token could be turned into = an access token by the AS-RS. Isn't this what Justin is proposing? In = this design, the AS is the AS-RS and the agent is the AS-RO. By my = definition, this model has two ASs since both are processing requests = into tokens. The problem with this is complexity and privacy. The RO may = not want to share the request information with the AS-RS.

    Adrian

    On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Isn't that what the AS is supposed to be, only with the = caveat that the policy is defined locally? 

    Fabien 


    Le mer. 24 = mars 2021 =C3=A0 20:17, Alan Karp <alanhkarp@gmail.com> a =C3=A9crit :
    AS-RO is an AS that RO trusts to delegate RO's = access tokens according to RO's policies.  

    --------------
    Alan Karp


    On Wed, Mar 24, 2021 at 9:36 AM Fabien = Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan and = Adrian,

    I've created = issue AS-RO policy delegation (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to capture your input. 
    A first question = that arises: can we give a definition to AS-RO?

    Thanks
    Fabien

    On Tue, Mar = 23, 2021 at 4:15 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi = Alan, 

    Yes, but = in that flow, the token relationship between AS-RS and AS-RO is only = secure if the tokens issued by AS-RS are cryptographically attenuable in = the first place. 
     
    Attenuated delegation is a requirement, but that doesn't have = to be done cryptographically.  Token exchange works just = fine.  SPKI and zcap-ld are examples of the crypto approach, and we = used token exchange in the system for HP.

    --------------
    Alan = Karp


    On Tue, Mar = 23, 2021 at 4:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi = Alan, 

    Yes, but = in that flow, the token relationship between AS-RS and AS-RO is only = secure if the tokens issued by AS-RS are cryptographically attenuable in = the first place. 

    Fabien

    On Mon, Mar = 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin = Richer <jricher@mit.edu> wrote:

    But with all that in mind, I think the = key here is going to be looking at what the inputs to the AS are, and = how those can be defined in an interoperable way for AS=E2=80=99s that = can accept them. I think there=E2=80=99s a lot of room for innovation = and flexibility here that doesn=E2=80=99t break the trust model or core = use cases. If I have an AS-RS set that won=E2=80=99t accept my favorite = flavor of policy engine inputs, then I can decide not to use that one. = But this is a very different question than saying the RS itself needs to = accept my own AS =E2=80=94 and we can=E2=80=99t keep conflating these = two models.

    I agree.  The = point of having an AS-RO is to allow RO to specify a policy for which of = RO's access tokens should be delegated under what conditions.  = AS-RS should not need to understand those policies.  The flow would = be
    • RO contacts AS-RS = and gets one or more access tokens.
    • RO delegates one = or more of those tokens, potentially sub-scoped, to AS-RO.
    • A different user contacts AS-RO to get a potentially = sub-scoped access token from AS-RO.
    • That user = presents the access token delegated by AS-RO when invoking the = resource.
    AS-RS only = needs to verify that the delegation chain is legitimate, e.g., no = increase in scope, and that it grants permission for the request being = made.  AS-RS does not need to understand the policy behind granting = the delegation by AS-RO.

    --------------
    Alan Karp


    On Mon, Mar 22, 2021 at 11:40 AM Justin = Richer <jricher@mit.edu> wrote:
    Adrian,

    I think this shows the problem with the = terminology as it=E2=80=99s been applied in this conversation, which = I=E2=80=99ve tried to shine light on before. What you and others are = calling the =E2=80=9CRS=E2=80=9D is really the =E2=80=9CAS and RS = working together=E2=80=9D =E2=80=94 everything to the right of the line. = When Denis had brought up =E2=80=9Celiminating the AS=E2=80=9D in = another thread, what he=E2=80=99d really done is labeled everything to = the right of the line as the =E2=80=9CRS=E2=80=9D. Of course, the irony = here is that everything to the right of the line used all be called the = =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 = days. As you say below, I don=E2=80=99t want the client to have = visibility on what happens on that side. 

    Note well: The Google+ logo labeled = =E2=80=9CIdP=E2=80=9D in the diagram is not the AS, as far as GNAP is = concerned. It does not issue an access token that the RS will accept. = The elements to the left of the line could be a lot of things, but they = are NOT the AS =E2=80=94 by definition. The client lives over on the = left, but so do any external inputs to the AS. These could be policy = inputs on behalf of the RO, they could be presentation artifacts, they = could be federated logins, they could be the output of policy decisions. = How the AS comes to trust those things is up to the AS=E2=80=99s = implementation. It=E2=80=99s something we can talk about, but ultimately = GNAP won=E2=80=99t be in any position to dictate because in practice = some AS=E2=80=99s are simply going to internalize all policies and we = will never successfully force those open. 

    But with all that in mind, I think the = key here is going to be looking at what the inputs to the AS are, and = how those can be defined in an interoperable way for AS=E2=80=99s that = can accept them. I think there=E2=80=99s a lot of room for innovation = and flexibility here that doesn=E2=80=99t break the trust model or core = use cases. If I have an AS-RS set that won=E2=80=99t accept my favorite = flavor of policy engine inputs, then I can decide not to use that one. = But this is a very different question than saying the RS itself needs to = accept my own AS =E2=80=94 and we can=E2=80=99t keep conflating these = two models.

    So = to me, GNAP can support a Zero Trust Architecture by LEVERAGING the AS, = not by subsuming or eliminating it. It is in fact the AS, not the client = and not the RS, that will request and consume the results of a = privacy-preserving zero-trust policy query thing. Anything that happens = downstream from that is of little concern to the zero-trust components = because, as you point out, it=E2=80=99s on the =E2=80=9Cother side=E2=80=9D= of the line. 

    I think we got this basic component model pretty right in = OAuth: the AS and RS and client working together. Where OAuth misses the = mark is the assumption that the user has to log in to the AS through a = webpage and interact directly, thereby proving they=E2=80=99re the RO. = It=E2=80=99s this latter space where I think we can both push innovation = and also address the important and compelling use cases like the ones = you=E2=80=99re bringing.

     =E2=80=94 Justin

    On Mar = 22, 2021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I'm sorry, Justin. As a Resource = Owner, I look at the RS trust boundary (the dotted line in the diagram) = as being the RS. I don't expect any visibility into what's going on on = the right. 

    My problem with the framing you propose is that requests are = going to the RS (or the AS-RS) and I don't want to share my policies = with the AS-RS. I want to keep the RS and AS-RS as ignorant as = possible.

    Adrian

    On Mon, Mar = 22, 2021 at 1:48 PM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    What you=E2=80=99re discussing below, = in terms of logging in to a site, is not approaching the RS. You are in = fact approaching the client, and identifying both the AS and RS to the = client. The client is a client of your identity in = this model, and the RS is part of the identity provider. It=E2=80=99s = really important that we don=E2=80=99t conflate the RS and client in = this way as it leads to a lot of confusion downstream and a lot of = broken trust boundaries.

    With that model in mind, approaching the =E2=80=9CRS" and = providing it your identity is really just a case of the =E2=80=9Cfederated= login to AS=E2=80=9D pattern that we discussed on the WG call. The user = here approaches an RS, which has its own AS. To share things from this = RS, the RO has to authenticate to the RS=E2=80=99s AS. This particular = AS allows the RO to do so using an external identity =E2=80=94 in which = case, the AS is now a =E2=80=9Cclient=E2=80=9D of a separate, = disconnected (but layered) delegation. The ultimate client that = eventually calls the RS down the way may or may not know about these = layers. 

    <PastedGraphic-1.png>
    This = same AS, which is closely tied to the RS and trusted by the RS, might = also take in FIDO credentials, or DIDs, or any number of other proof = mechanisms. The output of this is an access token the RS trusts, but the = input is up to the AS. The RS is not what you=E2=80=99re logging in = to.

     =E2=80= =94 Justin

    On Mar 22, 2021, at 1:28 PM, = Adrian Gropper <agropper@healthurl.com> = wrote:

    I = too am in favor of avoiding consolidation and correlation. Right now, = when I approach a service provider (RS) for the first time, I'm offered = the opportunity to identify my persona as: email, sign-in with Google, = Facebook, or Apple. I know there are people who try to create one-off = email addresses but that is mostly a waste of time. 

    So, along come FIDO2 and = DID wallets to the rescue. Now, in theory, I have a way to start out my = RS relationship pseudonymously. 

    When I want my resource to be = discovered or shared I will post that RS URL including my pseudonym. If = I then want to introduce a mediator in front of my AS or messaging = service endpoint, I have that option. If I want to keep requests = away from the mediator, I would publish an encryption key along with my = pseudonym.

    - = Adrian



    On Mon, Mar 22, 2021 at 9:55 AM Justin = Richer <jricher@mit.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin = Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhkarp@gmail.com> shared a talk = about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#i= ssuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to = use authority
    >> as a core principle. I advocate for a GNAP design that = maximizes the power
    >> of the RO, to be seen as a human rights issue when the RO is a = human. This
    >> causes me to ask how to combine better security with better = human rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the = RO to
    >> partition limited authority across dozens of different ASs by = domain and
    >> function, then we are not using technology to empower the = individual.
    >> Probably the opposite, as we introduce consent fatigue and = burden normal
    >> people to partition their lives into non-overlapping = domains.
    >>
    >> My experience says we should aim for one AS per persona because = that maps
    >> into the way we manage our public and private identities. POLA = would then
    >> teach care in keeping ASs and RSs related to work / public = separate from
    >> ASs and RSs related to private life so that a policy = vulnerability in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to = GNAP
    > seems like a useful exercise.  I do want to point out some = potential
    > pitfalls with one-AS-per-persona that we can also be aware = of.  If
    > one-AS-per-persona becomes one-persona-per-AS as well, then the = AS's
    > identity in effect also serves as a persona identity and there are = privacy
    > considerations to that.  If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple = humans)
    > route is taken, we should consider whether that would lead to = various
    > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.  That topic is a current matter of = concern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in = the UMA working group, and it=E2=80=99s one of the biggest problems with = the personal AS (and personal data store) model. This kind of thing = makes RS-first trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that = wants to access my medical information. It calls an RS and requests = access, but it hasn=E2=80=99t been granted anything yet. Now I as the RO = have set up the RS so that it talks to my personal AS, that only I use. = In addition to the RS having to be able to figure out which medical = records are being requested from the context of the unauthenticated = request (which means it needs identifiers in the URL or something = similar for the RS to be able to tell, assuming that it protects data = for more than one person). So this client software doesn=E2=80=99t know = who I am and doesn=E2=80=99t know my medical record information, makes a = completely unauthorized request to the RS, and the RS says =E2=80=9CGo = to Justin=E2=80=99s personal AS to get a token=E2=80=9D. The client can = now make a direct correlation between the data that=E2=80=99s being = protected at the RS and the person running the AS that protects it. = Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This = is a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please = talk to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t = exposed anything at all. And from the perspective of both the patient = and the RS, this is more privacy-preserving, and it=E2=80=99s really the = least surprising option. Once the client gets to the AS, it can start a = negotiation of figuring out who the RO is for the information being = accessed.

    On top of this, the usability expectations of people managing their own = AS, or set of AS=E2=80=99s for multiple personas to keep things = separate, is a huge burden. Even in the tech community, I know people = who can=E2=80=99t reliably manage more than one email address for = different purposes. I wouldn=E2=80=99t expect my partner to do that =E2=80= =94 they have trouble enough balancing all the logins and sessions = required for different kids remote schooling, I couldn=E2=80=99t imagine = them having to understand all the requirements for managing multiple = authorization servers and associated policies. I also don=E2=80=99t = expect any person to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve = been on the internet for decades and I can barely keep tabs on my GPG = keys, and only use them when I am forced to. This is exactly the kind of = =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions above, = people will just want to outsource that to someone else, and the reality = will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice = only to end up with a world where the RS ends up making a limited choice = anyway. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99= s could allow arbitrary IdPs but they choose Google because it works and = that=E2=80=99s where the users are. (And that=E2=80=99s not to say = anything of the proprietary OIDC-like protocols, but that=E2=80=99s = another discussion).

    For further reading on these topics, I recommend both =E2=80=9CWhy = Johnny Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems = Fail=E2=80=9D.

    So what does this have to do with GNAP? I think we can be clear-eyed on = what kinds of expectations we have for the participants. If we expect = users (RO=E2=80=99s) to have to set up the AS-RS relationship, or expect = them to carry their AS, or manage their personal keys =E2=80=94 I think = we=E2=80=99ve lost the battle for relevance.

     =E2=80=94 Justin


    --
    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
    =


    = --Apple-Mail=_C10EF2E5-6717-42D8-B8E9-99AD38A7C32D-- From nobody Thu Mar 25 09:36:27 2021 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 A506A3A2712 for ; Thu, 25 Mar 2021 09:36:24 -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 LvRJAtRw1dDz for ; Thu, 25 Mar 2021 09:36:19 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 26BF63A270C for ; Thu, 25 Mar 2021 09:36:19 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id g24so2103090qts.6 for ; Thu, 25 Mar 2021 09:36:18 -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=o5bvwElZy5ABaIJl0gj0E8O96uW/5QTLMZXLFcNZ2Ic=; b=M2qzZdoi0I6J/oAmo/6sGgsijZ21jKUnXOdynx/9kiCN5ssonqGFSOy8UI/1WOEmR+ vuBhUvXtI48BT3RB9V42/PQOdPPTfmD8hL3vHGCgExlmv2sscb+H5WMypOAEq4mjQtXK FccRrCAKZgzDx6uOscWeoCoay+5A4BOMY6eyhBXdMwmxC7o2fYKeJMbLVraY7N/IQ/tU CGxZspMceDb72YwEv9Lvcaes6Ar7BYbzNZvLjGgWcmCcYAuyTHT2BPfiAcS9NX8aFo4U YIuRk5lG7YWhzi+KF8d1KbpLD9fIGTRNJSQsNzF6v1Z5sJB9W6qE/dcj4PmNJTpJi0Bf /IWg== 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=o5bvwElZy5ABaIJl0gj0E8O96uW/5QTLMZXLFcNZ2Ic=; b=YVJOTNQyompgLfXzGOQNO0Kg50FYMjVI+cHZObne/L6tMwK+5DALdCa45kPHlxnDFQ nruThADVNU+NuSGSO/HwQ0wnrH7lZlE20+LpZ0/q+V1xRPgHdB8NEjzaCP/DB7pwKKtY twvEmhBpzM048Wzlz4cPCJao3Gpxxe+e4cYVcE1u80HT0xLW//nYdfxn0YSpTj3ZX6+w LuGEHZ6ZuAwRY25guf9YQNai20J4HYUwO4NamPkxJ03jZZq5i9gfZ2qPX2Ir1o/wB9xh pYnlLp46HzlUD2E0vibSFAyTt+SZdM4sx8igF4ctDGx9l5RV3zTEbXihlXooVcfa+lf0 hEHQ== X-Gm-Message-State: AOAM530nK6X3ZmiLkfKnzwBUwc6bhpScHV4rb1N1RGPT7Z2VK8TJ1yO1 V4goXpOSoOHaOqr7YJIvHZK9nXJIm0qTiU/RkUc= X-Google-Smtp-Source: ABdhPJxwy6witnfZKcKfl9IR0yGGQO0AmmyUUM4qVI0rsLijmJeAIgRoMHyCwObuI5eXNUz5aFjgDYvSuXiZIKvUGwE= X-Received: by 2002:ac8:7c8d:: with SMTP id y13mr8206216qtv.294.1616690177326; Thu, 25 Mar 2021 09:36:17 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> In-Reply-To: <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> From: Alan Karp Date: Thu, 25 Mar 2021 09:36:04 -0700 Message-ID: To: Justin Richer Cc: Fabien Imbault , Adrian Gropper , Benjamin Kaduk , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="000000000000bb408c05be5f0330" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 16:36:25 -0000 --000000000000bb408c05be5f0330 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There seems to be some confusion about how AS-RO comes into the picture, probably because of the "AS" part. I'm going to try to clear up that confusion by more carefully explaining what I mean. I'm assuming that RO is a computational agent representing the person who is the resource owner, something called the "user agent" in operating systems lingo. I'm also assuming that it's possible to do delegation, either locally or by token exchange with AS-RS. All delegations are potentially sub-scoped, but you may also want to delegate with full scope to have a separately revocable access token. Here's an example of how things work in a capability oriented system. 1. Someone, the service owner, creates a service. 2. The service owner contracts with an policy agent (AS-RS) to create and manage access tokens for that service (RS). 3. A person wishing to create a resource at RS uses their user agent (RO) to contact the service owner's policy agent (AS-RS) and gets back a= n access token for that resource. 4. That user agent (RO) can 1. use that access token to invoke the resource, or 2. delegate an access token to a client of the user agent's (RO) choice, or 3. contract with a policy agent (AS-RO) to manage those delegations on behalf of the user agent (RO), or 4. specify a policy with the service's policy agent (AS-RS). 5. A client can contact any holder of the access token (the user agent (RO) or its policy agent (AS-RO)) or the service's policy agent (AS-RS) = to get a delegated access token. 6. That client can delegate that token to another client. 7. Another user agent (RO') can contact any holder of the access token or the service's policy agent (AS-RS) to get a delegated access token. 8. The other user agent (RO') can 1. use that access token to invoke the resource, or 2. delegate it to a client of its choice, or 3. contract with a policy agent (AS-RO') of its choosing to manage those delegations on its behalf, or 4. specify a policy with the service's policy agent (AS-RS). 9. and so on When any of these computational agents, user agents (ROs) or clients acting on their behalf, invokes the resource, AS-RS verifies that the access token is a valid delegation, i.e., proper sub-scoping, hasn't been revoked, and that it authorizes the request being made before telling the service (RS) to honor the request. At no point does the service's policy agent (AS-RS) know which computational agent did any particular delegation. (Token exchange can be done as anonymously as possible.) In particular, the policy agents (AS-RO) need not be the same, or even compatible with, the service's policy agent (AS-RS). GNAP specifies the protocol between requesters, invokers, delegators (for token exchange) of tokens and AS-RS. That protocol need not be used between user agents (RO), clients, or other policy agents (AS-RO), but it is likely to be. ------------- Alan Karp On Thu, Mar 25, 2021 at 5:45 AM Justin Richer wrote: > The way I=E2=80=99m thinking about Adrian=E2=80=99s use case is that what= we=E2=80=99re calling > the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an =E2=80=9CAS=E2=80=9D in the = traditional OAuth/GNAP sense, at least not > exactly. This is the agent that the RO can use to set policies and manage > consent on their behalf, and I=E2=80=99ve been arguing that it fits bette= r into > this vaguely-defined =E2=80=9Cinteraction component=E2=80=9D aspect of th= e current AS > definition, and it=E2=80=99s not currently separated from the AS definiti= on. The > =E2=80=9CAS-RS=E2=80=9D maps to what we=E2=80=99d call the =E2=80=9CAS=E2= =80=9D in OAuth/GNAP traditionally, it=E2=80=99s > what the RS trusts to issue tokens. In traditional OAuth the AS-RO and > AS-RS are always the same thing, from a functional protocol perspective. = An > important point here is that from a client=E2=80=99s perspective, they=E2= =80=99re only > talking to the AS-RS since that=E2=80=99s where the client gets its token= s, because > at the end of the day the client just wants to call the API at the RS and > doesn=E2=80=99t care how that happens (from a protocol standpoint). > > Note well: Even thought I don=E2=80=99t believe that =E2=80=9CAS-RO=E2=80= =9D is an authorization > server at all, I=E2=80=99m going to keep using that term below for consis= tency with > previous discussion. > > So we have these fundamental relationships around getting the client to > access the RS: > > 1. RS trusts AS-RS to issue tokens that RS will accept, validate, and > process for requests from client > 2. Client trusts AS-RS to issue tokens that client can use at RS > 3. RO trusts RS to protect RO=E2=80=99s api through delegated access > > On top of that, we=E2=80=99ve got some additional aspects that we=E2=80= =99re discussing: > > 4. RO trusts AS-RO to manage RO=E2=80=99s policies at runtime > 5. AS-RS trusts AS-RO to assert RO=E2=80=99s policies for access to RS > 6. Client trusts whatever AS-RS sends client to deal with, including > possibly RO-AS at runtime, because of (2) > > What I have been saying is that 4/5/6 are optional details of how RS-AS > runs things, and I think this also maps with Adrian=E2=80=99s view of cho= ice, since > if my RS=E2=80=99s AS-RS doesn=E2=80=99t allow me to plug in my own AS-RO= then I would be > motivated to pick a different RS who=E2=80=99s AS-RS lets me do just that= . The same > way I=E2=80=99d pick a different RS if their surrounding services didn=E2= =80=99t accept my > preferred federation login and I didn=E2=80=99t want to make another acco= unt. Of > course, market forces being as they are, I might not have much of an > actionable choice in RS, but GNAP can=E2=80=99t change that. > > What we can do is make it possible for AS-RS to talk to AS-RO, both in > philosophy of the protocol design and in concrete hooks to support (6) > above. > > Separately, we can approach the issue of making 1/2 above more dynamic. > This was UMA2=E2=80=99s =E2=80=9Cfederated authorization=E2=80=9D approac= h, and is behind a lot of > the =E2=80=9Cbring your own AS=E2=80=9D models out there. The problem wit= h these is that we > know from many years of experience that most RS=E2=80=99s aren=E2=80=99t = interested in > doing anything of the sort. > > So with GNAP we can instead allow 4/5/6 to vary in a predictable and > consistent way, letting the RS keep control over 1/2, thereby enabling > choice in (3). We don=E2=80=99t have to be the ones who define the all of= the > details of every permutation of (5) to enable this, though. Some of this = is > going to be configuration out of band, some of it=E2=80=99s going to be > communication at runtime. This is where VC=E2=80=99s, ZCAPs, CHAPI, DIDCo= mm, FIDO, > and a whole swath of other tech can come in and help out. I don=E2=80=99t= think we > need to put all the details for using these into core, nor do I think we= =E2=80=99ll > pull of The Great And Ultimate Abstraction for using these and other > approaches. But we can at least start talking about =E2=80=9CAS-RS=E2=80= =9D in such a way > that it no longer assumes it=E2=80=99s always the same party dealing with= the RO > directly. > > =E2=80=94 Justin > > On Mar 25, 2021, at 6:40 AM, Fabien Imbault > wrote: > > To reframe it closer to GNAP: > - AS =3D AS-RO, that's where you find the RO policies. The AS issues acce= ss > tokens to the client. > - the RO policies could be a) defined locally or b) in relationship with > the RS > > There have been several ideas related to the AS-RS relationship b: > b1) the RS issues capabilities (which can be further attenuated by the RO= ) > b2) Adrian also discussed a DID based solution > b3) there was also an alternative ACL proposal from Denis (+ preflight) > > Fabien > > > On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault > wrote: > >> Ok so I get you correctly: >> - what matters is the RQ (could be a RO or a end-user or both : we don't >> really care at a high-level, they're all treated as entities that make a >> request) >> - the policy is able to handle those different cases, based on its own >> internal delegation protocol >> - currently that requires AS-RS and AS-RO, but maybe it can be simplifie= d >> >> To answer to Denis, here's what I understood: >> - RO trusts AS-RS (and then handles its own policies within AS-RO) >> - end-user trusts AS-RO (through its client) >> >> Could probably work but that's a fairly different model compared to >> OAuth2 (and of today's GNAP), with different frontiers between the AS an= d >> the RS. >> >> Please do not hesitate to correct me if I'm wrong. >> >> Fabien >> >> On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper >> wrote: >> >>> I believe there are alternatives to having two kinds of ASs. The proble= m >>> may be a side-effect of deciding to switch away form treating the RO as >>> different from the RQ. That leads to downstream privacy issues. Our des= ire >>> for architectural simplicity is admirable but that may have been a step= too >>> far. >>> >>> There may also be solutions based on different types of tokens, as in >>> different capabilities (tokens signed by the RS) vs. tokens signed by t= he >>> AS. I=E2=80=99m not sure about that but Alan might have more to say. >>> >>> Adrian >>> >>> On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault >>> wrote: >>> >>>> Thanks. The general problem statement is clear. >>>> >>>> The proposed solution a bit less (to me). I understood that from point >>>> 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obvious reason = to have >>>> two types of ASs". Do you see an alternative ? >>>> >>>> Regarding the last item, I don't think that naming RQ by end-user >>>> created the problem. It might just highlight the asymmetry, which >>>> fundamentally exists. >>>> >>>> Fabien >>>> >>>> >>>> On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper >>>> wrote: >>>> >>>>> Recap: >>>>> 1 - Justin (I think) introduced the idea of an AS on the RS trust >>>>> boundary side. >>>>> 2 - I said the RO should not have to share policies with the RS. >>>>> 3 - Alan invented the concept of AS-RO and AS-RS to separate two kind= s >>>>> of PDPs. >>>>> >>>>> The thing is that step 2 is not symmetrical. The RO has a legitimate >>>>> privacy interest in keeping their policies private and minimizing the >>>>> leakage of information about requests that are posed against those >>>>> policies. >>>>> >>>>> The RS, on the other hand, should be publishing its policies (e.g. >>>>> what it=E2=80=99s selling or what jurisdiction it=E2=80=99s in or wha= t tokens or scopes it >>>>> supports). The RS has no obvious privacy interest in GNAP. It=E2=80= =99s just an >>>>> enforcer. >>>>> >>>>> There is one other privacy interest to consider around the RS and tha= t >>>>> is the requesting party (the end-user that is not the RO :-) might pr= efer >>>>> to share attributes with the RS instead of the RO or something contro= lled >>>>> by the RO. This case could be an =E2=80=9Cextension=E2=80=9D to GNAP = and might result in a >>>>> split AS as a solution. This problem was introduced when the editors >>>>> decided to replace RQ with end-user. Obviously, the RO end-user has n= o >>>>> privacy interests relative to itself. >>>>> >>>>> Adrian >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> I was referring to "By my definition, this model has two ASs since >>>>>> both are processing requests into tokens". If there's no reason to h= ave 2 >>>>>> types of ASs, that's fine then. >>>>>> But I'm a bit lost in where we stand with the idea. >>>>>> >>>>>> Could you recap? >>>>>> >>>>>> Fabien >>>>>> >>>>>> Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper >>>>>> a =C3=A9crit : >>>>>> >>>>>>> There=E2=80=99s no obvious reason to have two types of ASs. Any AS = that is >>>>>>> executing the policies of the RS can look to GNAP like the RS itsel= f. Why >>>>>>> would GNAP expose that interface to anyone? >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>> On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>> >>>>>>>> Note : I'm not sure that's a good idea, but having 2 types of ASs >>>>>>>> is not that easy to grasp. >>>>>>>> >>>>>>>> Fabien >>>>>>>> >>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com> a =C3=A9crit : >>>>>>>> >>>>>>>>> The purpose of either handling policies locally or delegating the= m >>>>>>>>> to the RO agent. >>>>>>>>> >>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper < >>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>> >>>>>>>>>> What purpose would be served by GNAP splitting the AS into two >>>>>>>>>> components? >>>>>>>>>> >>>>>>>>>> Adrian >>>>>>>>>> >>>>>>>>>> On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault < >>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Isn't the AS-RO a component of the AS? Same idea as the interac= t >>>>>>>>>>> component, it functionnally belongs to the AS role but could be= deployed >>>>>>>>>>> either as a monolith or as a separate component? >>>>>>>>>>> >>>>>>>>>>> Fabien >>>>>>>>>>> >>>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper < >>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>> >>>>>>>>>>>> Yes, but I would say it=E2=80=99s not the RO that wants the ac= cess >>>>>>>>>>>> token. It=E2=80=99s the RO that wants the client making the re= quest to get an >>>>>>>>>>>> access token. >>>>>>>>>>>> >>>>>>>>>>>> Adrian >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Mar 24, 2021 at 11:22 PM Alan Karp >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Adrian Gropper wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> In this design, the AS is the AS-RS and the agent is the >>>>>>>>>>>>>> AS-RO. By my definition, this model has two ASs since both a= re processing >>>>>>>>>>>>>> requests into tokens. The problem with this is complexity an= d privacy. The >>>>>>>>>>>>>> RO may not want to share the request information with the AS= -RS. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> More precisely, RO has no choice but to present the required >>>>>>>>>>>>> information to AS-RS if RO wants an access token. However, R= O does not >>>>>>>>>>>>> want AS-RS to know the policy by which RO delegates tokens. = That's why RO >>>>>>>>>>>>> uses AS-RO for those delegations. >>>>>>>>>>>>> >>>>>>>>>>>>> -------------- >>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper < >>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you for creating the issue. My definition of AS is >>>>>>>>>>>>>> independent of AS-RO or AS-RS. >>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/22= 3#issuecomment-806280421 >>>>>>>>>>>>>> I also agree with Alan's definition based on delegation. An = AS-RS would be >>>>>>>>>>>>>> a delegate of the RS. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Based on that, I see it as obvious that the policy has to be >>>>>>>>>>>>>> accessible (defined locally?) in order for it to be run as t= he code that >>>>>>>>>>>>>> turns a request into an access token. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The only other possibility is that the request is packaged b= y >>>>>>>>>>>>>> the AS and sent elsewhere (an agent) for evaluation against = policy and a >>>>>>>>>>>>>> proto-token returned. In that case the AS is acting as a pro= xy and the PDP >>>>>>>>>>>>>> is elsewhere. I can imagine that an AS-RS would behave this = way so that the >>>>>>>>>>>>>> proto-token could be turned into an access token by the AS-R= S. Isn't this >>>>>>>>>>>>>> what Justin is proposing? In this design, the AS is the AS-R= S and the agent >>>>>>>>>>>>>> is the AS-RO. By my definition, this model has two ASs since= both are >>>>>>>>>>>>>> processing requests into tokens. The problem with this is co= mplexity and >>>>>>>>>>>>>> privacy. The RO may not want to share the request informatio= n with the >>>>>>>>>>>>>> AS-RS. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault < >>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Isn't that what the AS is supposed to be, only with the >>>>>>>>>>>>>>> caveat that the policy is defined locally? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp >>>>>>>>>>>>>>> a =C3=A9crit : >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> AS-RO is an AS that RO trusts to delegate RO's access >>>>>>>>>>>>>>>> tokens according to RO's policies. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault < >>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Alan and Adrian, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I've created issue AS-RO policy delegation ( >>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues= /223) >>>>>>>>>>>>>>>>> to capture your input. >>>>>>>>>>>>>>>>> A first question that arises: can we give a definition to >>>>>>>>>>>>>>>>> AS-RO? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp < >>>>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Fabien Imbault wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Yes, but in that flow, the token relationship between >>>>>>>>>>>>>>>>>>> AS-RS and AS-RO is only secure if the tokens issued by = AS-RS are >>>>>>>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Attenuated delegation is a requirement, but that doesn't >>>>>>>>>>>>>>>>>> have to be done cryptographically. Token exchange works= just fine. SPKI >>>>>>>>>>>>>>>>>> and zcap-ld are examples of the crypto approach, and we = used token exchange >>>>>>>>>>>>>>>>>> in the system for HP. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault < >>>>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Yes, but in that flow, the token relationship between >>>>>>>>>>>>>>>>>>> AS-RS and AS-RO is only secure if the tokens issued by = AS-RS are >>>>>>>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp < >>>>>>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Justin Richer wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> But with all that in mind, I think the key here is >>>>>>>>>>>>>>>>>>>>> going to be looking at what the inputs to the AS are,= and how those can be >>>>>>>>>>>>>>>>>>>>> defined in an interoperable way for AS=E2=80=99s that= can accept them. I think >>>>>>>>>>>>>>>>>>>>> there=E2=80=99s a lot of room for innovation and flex= ibility here that doesn=E2=80=99t >>>>>>>>>>>>>>>>>>>>> break the trust model or core use cases. If I have an= AS-RS set that won=E2=80=99t >>>>>>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine inputs, th= en I can decide not to >>>>>>>>>>>>>>>>>>>>> use that one. But this is a very different question t= han saying the RS >>>>>>>>>>>>>>>>>>>>> itself needs to accept my own AS =E2=80=94 and we can= =E2=80=99t keep conflating these two >>>>>>>>>>>>>>>>>>>>> models. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I agree. The point of having an AS-RO is to allow RO >>>>>>>>>>>>>>>>>>>> to specify a policy for which of RO's access tokens sh= ould be delegated >>>>>>>>>>>>>>>>>>>> under what conditions. AS-RS should not need to under= stand those >>>>>>>>>>>>>>>>>>>> policies. The flow would be >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> - RO contacts AS-RS and gets one or more access >>>>>>>>>>>>>>>>>>>> tokens. >>>>>>>>>>>>>>>>>>>> - RO delegates one or more of those tokens, >>>>>>>>>>>>>>>>>>>> potentially sub-scoped, to AS-RO. >>>>>>>>>>>>>>>>>>>> - A different user contacts AS-RO to get a >>>>>>>>>>>>>>>>>>>> potentially sub-scoped access token from AS-RO. >>>>>>>>>>>>>>>>>>>> - That user presents the access token delegated by >>>>>>>>>>>>>>>>>>>> AS-RO when invoking the resource. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> AS-RS only needs to verify that the delegation chain i= s >>>>>>>>>>>>>>>>>>>> legitimate, e.g., no increase in scope, and that it gr= ants permission for >>>>>>>>>>>>>>>>>>>> the request being made. AS-RS does not need to unders= tand the policy >>>>>>>>>>>>>>>>>>>> behind granting the delegation by AS-RO. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer < >>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I think this shows the problem with the terminology a= s >>>>>>>>>>>>>>>>>>>>> it=E2=80=99s been applied in this conversation, which= I=E2=80=99ve tried to shine light on >>>>>>>>>>>>>>>>>>>>> before. What you and others are calling the =E2=80=9C= RS=E2=80=9D is really the =E2=80=9CAS and RS >>>>>>>>>>>>>>>>>>>>> working together=E2=80=9D =E2=80=94 everything to the= right of the line. When Denis had >>>>>>>>>>>>>>>>>>>>> brought up =E2=80=9Celiminating the AS=E2=80=9D in an= other thread, what he=E2=80=99d really done is >>>>>>>>>>>>>>>>>>>>> labeled everything to the right of the line as the = =E2=80=9CRS=E2=80=9D. Of course, the >>>>>>>>>>>>>>>>>>>>> irony here is that everything to the right of the lin= e used all be called >>>>>>>>>>>>>>>>>>>>> the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2= =80=9D in the OAuth 1 days. As you say below, I don=E2=80=99t >>>>>>>>>>>>>>>>>>>>> want the client to have visibility on what happens on= that side. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Note well: The Google+ logo labeled =E2=80=9CIdP=E2= =80=9D in the >>>>>>>>>>>>>>>>>>>>> diagram is not the AS, as far as GNAP is concerned. I= t does not issue an >>>>>>>>>>>>>>>>>>>>> access token that the RS will accept. The elements to= the left of the line >>>>>>>>>>>>>>>>>>>>> could be a lot of things, but they are NOT the AS =E2= =80=94 by definition. The >>>>>>>>>>>>>>>>>>>>> client lives over on the left, but so do any external= inputs to the AS. >>>>>>>>>>>>>>>>>>>>> These could be policy inputs on behalf of the RO, the= y could be >>>>>>>>>>>>>>>>>>>>> presentation artifacts, they could be federated login= s, they could be the >>>>>>>>>>>>>>>>>>>>> output of policy decisions. How the AS comes to trust= those things is up to >>>>>>>>>>>>>>>>>>>>> the AS=E2=80=99s implementation. It=E2=80=99s somethi= ng we can talk about, but ultimately >>>>>>>>>>>>>>>>>>>>> GNAP won=E2=80=99t be in any position to dictate beca= use in practice some AS=E2=80=99s are >>>>>>>>>>>>>>>>>>>>> simply going to internalize all policies and we will = never successfully >>>>>>>>>>>>>>>>>>>>> force those open. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> But with all that in mind, I think the key here is >>>>>>>>>>>>>>>>>>>>> going to be looking at what the inputs to the AS are,= and how those can be >>>>>>>>>>>>>>>>>>>>> defined in an interoperable way for AS=E2=80=99s that= can accept them. I think >>>>>>>>>>>>>>>>>>>>> there=E2=80=99s a lot of room for innovation and flex= ibility here that doesn=E2=80=99t >>>>>>>>>>>>>>>>>>>>> break the trust model or core use cases. If I have an= AS-RS set that won=E2=80=99t >>>>>>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine inputs, th= en I can decide not to >>>>>>>>>>>>>>>>>>>>> use that one. But this is a very different question t= han saying the RS >>>>>>>>>>>>>>>>>>>>> itself needs to accept my own AS =E2=80=94 and we can= =E2=80=99t keep conflating these two >>>>>>>>>>>>>>>>>>>>> models. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> So to me, GNAP can support a Zero Trust Architecture >>>>>>>>>>>>>>>>>>>>> by LEVERAGING the AS, not by subsuming or eliminating= it. It is in fact the >>>>>>>>>>>>>>>>>>>>> AS, not the client and not the RS, that will request = and consume the >>>>>>>>>>>>>>>>>>>>> results of a privacy-preserving zero-trust policy que= ry thing. Anything >>>>>>>>>>>>>>>>>>>>> that happens downstream from that is of little concer= n to the zero-trust >>>>>>>>>>>>>>>>>>>>> components because, as you point out, it=E2=80=99s on= the =E2=80=9Cother side=E2=80=9D of the line. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I think we got this basic component model pretty righ= t >>>>>>>>>>>>>>>>>>>>> in OAuth: the AS and RS and client working together. = Where OAuth misses the >>>>>>>>>>>>>>>>>>>>> mark is the assumption that the user has to log in to= the AS through a >>>>>>>>>>>>>>>>>>>>> webpage and interact directly, thereby proving they= =E2=80=99re the RO. It=E2=80=99s this >>>>>>>>>>>>>>>>>>>>> latter space where I think we can both push innovatio= n and also address the >>>>>>>>>>>>>>>>>>>>> important and compelling use cases like the ones you= =E2=80=99re bringing. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper < >>>>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I'm sorry, Justin. As a Resource Owner, I look at the >>>>>>>>>>>>>>>>>>>>> RS trust boundary (the dotted line in the diagram) as= being the RS. I don't >>>>>>>>>>>>>>>>>>>>> expect any visibility into what's going on on the rig= ht. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> My problem with the framing you propose is that >>>>>>>>>>>>>>>>>>>>> requests are going to the RS (or the AS-RS) and I don= 't want to share my >>>>>>>>>>>>>>>>>>>>> policies with the AS-RS. I want to keep the RS and AS= -RS as ignorant as >>>>>>>>>>>>>>>>>>>>> possible. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer < >>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> What you=E2=80=99re discussing below, in terms of lo= gging in >>>>>>>>>>>>>>>>>>>>>> to a site, is not approaching the RS. You are in fac= t approaching the >>>>>>>>>>>>>>>>>>>>>> client, and identifying both the AS and RS to the cl= ient. The client is a >>>>>>>>>>>>>>>>>>>>>> client *of your identity* in this model, and the RS >>>>>>>>>>>>>>>>>>>>>> is part of the identity provider. It=E2=80=99s reall= y important that we don=E2=80=99t >>>>>>>>>>>>>>>>>>>>>> conflate the RS and client in this way as it leads t= o a lot of confusion >>>>>>>>>>>>>>>>>>>>>> downstream and a lot of broken trust boundaries. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> With that model in mind, approaching the =E2=80=9CRS= " and >>>>>>>>>>>>>>>>>>>>>> providing it your identity is really just a case of = the =E2=80=9Cfederated login to >>>>>>>>>>>>>>>>>>>>>> AS=E2=80=9D pattern that we discussed on the WG call= . The user here approaches an >>>>>>>>>>>>>>>>>>>>>> RS, which has its own AS. To share things from this = RS, the RO has to >>>>>>>>>>>>>>>>>>>>>> authenticate to the RS=E2=80=99s AS. This particular= AS allows the RO to do so >>>>>>>>>>>>>>>>>>>>>> using an external identity =E2=80=94 in which case, = the AS is now a =E2=80=9Cclient=E2=80=9D of a >>>>>>>>>>>>>>>>>>>>>> separate, disconnected (but layered) delegation. The= ultimate client that >>>>>>>>>>>>>>>>>>>>>> eventually calls the RS down the way may or may not = know about these >>>>>>>>>>>>>>>>>>>>>> layers. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> This same AS, which is closely tied to the RS and >>>>>>>>>>>>>>>>>>>>>> trusted by the RS, might also take in FIDO credentia= ls, or DIDs, or any >>>>>>>>>>>>>>>>>>>>>> number of other proof mechanisms. The output of this= is an access token the >>>>>>>>>>>>>>>>>>>>>> RS trusts, but the input is up to the AS. The RS is = not what you=E2=80=99re logging >>>>>>>>>>>>>>>>>>>>>> in to. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper < >>>>>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I too am in favor of avoiding consolidation and >>>>>>>>>>>>>>>>>>>>>> correlation. Right now, when I approach a service pr= ovider (RS) for the >>>>>>>>>>>>>>>>>>>>>> first time, I'm offered the opportunity to identify = my persona as: email, >>>>>>>>>>>>>>>>>>>>>> sign-in with Google, Facebook, or Apple. I know ther= e are people who try to >>>>>>>>>>>>>>>>>>>>>> create one-off email addresses but that is mostly a = waste of time. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> So, along come FIDO2 and DID wallets to the rescue. >>>>>>>>>>>>>>>>>>>>>> Now, in theory, I have a way to start out my RS rela= tionship >>>>>>>>>>>>>>>>>>>>>> pseudonymously. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> When I want my resource to be discovered or shared I >>>>>>>>>>>>>>>>>>>>>> will post that RS URL including my pseudonym. If I t= hen want to introduce a >>>>>>>>>>>>>>>>>>>>>> mediator in front of my AS or messaging service endp= oint, I have that >>>>>>>>>>>>>>>>>>>>>> option. If I want to keep requests away from the med= iator, I would publish >>>>>>>>>>>>>>>>>>>>>> an encryption key along with my pseudonym. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> - Adrian >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer < >>>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk < >>>>>>>>>>>>>>>>>>>>>>> kaduk@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian >>>>>>>>>>>>>>>>>>>>>>> Gropper wrote: >>>>>>>>>>>>>>>>>>>>>>> >> @Alan Karp shared a talk >>>>>>>>>>>>>>>>>>>>>>> about the Principle Of Least >>>>>>>>>>>>>>>>>>>>>>> >> Authority (POLA) in a recent comment >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/= issues/145#issuecomment-803099693 >>>>>>>>>>>>>>>>>>>>>>> >> I recommend it. >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> We might expect a protocol with authorization in >>>>>>>>>>>>>>>>>>>>>>> the title to use authority >>>>>>>>>>>>>>>>>>>>>>> >> as a core principle. I advocate for a GNAP desig= n >>>>>>>>>>>>>>>>>>>>>>> that maximizes the power >>>>>>>>>>>>>>>>>>>>>>> >> of the RO, to be seen as a human rights issue >>>>>>>>>>>>>>>>>>>>>>> when the RO is a human. This >>>>>>>>>>>>>>>>>>>>>>> >> causes me to ask how to combine better security >>>>>>>>>>>>>>>>>>>>>>> with better human rights in >>>>>>>>>>>>>>>>>>>>>>> >> GNAP. >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> Who should have the least authority in the GNAP >>>>>>>>>>>>>>>>>>>>>>> design? >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> The AS derives authority as a delegate of the RO= . >>>>>>>>>>>>>>>>>>>>>>> If we ask the RO to >>>>>>>>>>>>>>>>>>>>>>> >> partition limited authority across dozens of >>>>>>>>>>>>>>>>>>>>>>> different ASs by domain and >>>>>>>>>>>>>>>>>>>>>>> >> function, then we are not using technology to >>>>>>>>>>>>>>>>>>>>>>> empower the individual. >>>>>>>>>>>>>>>>>>>>>>> >> Probably the opposite, as we introduce consent >>>>>>>>>>>>>>>>>>>>>>> fatigue and burden normal >>>>>>>>>>>>>>>>>>>>>>> >> people to partition their lives into >>>>>>>>>>>>>>>>>>>>>>> non-overlapping domains. >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> My experience says we should aim for one AS per >>>>>>>>>>>>>>>>>>>>>>> persona because that maps >>>>>>>>>>>>>>>>>>>>>>> >> into the way we manage our public and private >>>>>>>>>>>>>>>>>>>>>>> identities. POLA would then >>>>>>>>>>>>>>>>>>>>>>> >> teach care in keeping ASs and RSs related to wor= k >>>>>>>>>>>>>>>>>>>>>>> / public separate from >>>>>>>>>>>>>>>>>>>>>>> >> ASs and RSs related to private life so that a >>>>>>>>>>>>>>>>>>>>>>> policy vulnerability in our >>>>>>>>>>>>>>>>>>>>>>> >> delegation to an AS would have the least >>>>>>>>>>>>>>>>>>>>>>> likelihood of harm. >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > Thinking about how least authority/least privileg= e >>>>>>>>>>>>>>>>>>>>>>> would apply to GNAP >>>>>>>>>>>>>>>>>>>>>>> > seems like a useful exercise. I do want to point >>>>>>>>>>>>>>>>>>>>>>> out some potential >>>>>>>>>>>>>>>>>>>>>>> > pitfalls with one-AS-per-persona that we can also >>>>>>>>>>>>>>>>>>>>>>> be aware of. If >>>>>>>>>>>>>>>>>>>>>>> > one-AS-per-persona becomes one-persona-per-AS as >>>>>>>>>>>>>>>>>>>>>>> well, then the AS's >>>>>>>>>>>>>>>>>>>>>>> > identity in effect also serves as a persona >>>>>>>>>>>>>>>>>>>>>>> identity and there are privacy >>>>>>>>>>>>>>>>>>>>>>> > considerations to that. If, on the other hand, t= he >>>>>>>>>>>>>>>>>>>>>>> > multiple-personas-per-AS (presumably correspondin= g >>>>>>>>>>>>>>>>>>>>>>> to multiple humans) >>>>>>>>>>>>>>>>>>>>>>> > route is taken, we should consider whether that >>>>>>>>>>>>>>>>>>>>>>> would lead to various >>>>>>>>>>>>>>>>>>>>>>> > (e.g., market) forces driving consolidation to >>>>>>>>>>>>>>>>>>>>>>> just a handful of >>>>>>>>>>>>>>>>>>>>>>> > super-popular AS services. That topic is a >>>>>>>>>>>>>>>>>>>>>>> current matter of concern to >>>>>>>>>>>>>>>>>>>>>>> > some IETF participants. >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Hi Ben, big +1 to this. This is something that we >>>>>>>>>>>>>>>>>>>>>>> discussed ages ago in the UMA working group, and it= =E2=80=99s one of the biggest >>>>>>>>>>>>>>>>>>>>>>> problems with the personal AS (and personal data st= ore) model. This kind of >>>>>>>>>>>>>>>>>>>>>>> thing makes RS-first trust models really difficult = in practice. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve = got software that >>>>>>>>>>>>>>>>>>>>>>> wants to access my medical information. It calls an= RS and requests access, >>>>>>>>>>>>>>>>>>>>>>> but it hasn=E2=80=99t been granted anything yet. No= w I as the RO have set up the RS >>>>>>>>>>>>>>>>>>>>>>> so that it talks to my personal AS, that only I use= . In addition to the RS >>>>>>>>>>>>>>>>>>>>>>> having to be able to figure out which medical recor= ds are being requested >>>>>>>>>>>>>>>>>>>>>>> from the context of the unauthenticated request (wh= ich means it needs >>>>>>>>>>>>>>>>>>>>>>> identifiers in the URL or something similar for the= RS to be able to tell, >>>>>>>>>>>>>>>>>>>>>>> assuming that it protects data for more than one pe= rson). So this client >>>>>>>>>>>>>>>>>>>>>>> software doesn=E2=80=99t know who I am and doesn=E2= =80=99t know my medical record >>>>>>>>>>>>>>>>>>>>>>> information, makes a completely unauthorized reques= t to the RS, and the RS >>>>>>>>>>>>>>>>>>>>>>> says =E2=80=9CGo to Justin=E2=80=99s personal AS to= get a token=E2=80=9D. The client can now make a >>>>>>>>>>>>>>>>>>>>>>> direct correlation between the data that=E2=80=99s = being protected at the RS and >>>>>>>>>>>>>>>>>>>>>>> the person running the AS that protects it. Importa= ntly, this client makes >>>>>>>>>>>>>>>>>>>>>>> this call with no prior relationship to the RS and = no really auditable way >>>>>>>>>>>>>>>>>>>>>>> to track it down after the fact. This is a design f= eature in the good case, >>>>>>>>>>>>>>>>>>>>>>> and terrifying in the bad case. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> If the RS instead says =E2=80=9Cwelcome to Medicine= Doctor >>>>>>>>>>>>>>>>>>>>>>> RS, please talk to the Medicine Doctor AS to get ac= cess=E2=80=9D, we haven=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>> exposed anything at all. And from the perspective o= f both the patient and >>>>>>>>>>>>>>>>>>>>>>> the RS, this is more privacy-preserving, and it=E2= =80=99s really the least >>>>>>>>>>>>>>>>>>>>>>> surprising option. Once the client gets to the AS, = it can start a >>>>>>>>>>>>>>>>>>>>>>> negotiation of figuring out who the RO is for the i= nformation being >>>>>>>>>>>>>>>>>>>>>>> accessed. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On top of this, the usability expectations of peopl= e >>>>>>>>>>>>>>>>>>>>>>> managing their own AS, or set of AS=E2=80=99s for m= ultiple personas to keep things >>>>>>>>>>>>>>>>>>>>>>> separate, is a huge burden. Even in the tech commun= ity, I know people who >>>>>>>>>>>>>>>>>>>>>>> can=E2=80=99t reliably manage more than one email a= ddress for different purposes. I >>>>>>>>>>>>>>>>>>>>>>> wouldn=E2=80=99t expect my partner to do that =E2= =80=94 they have trouble enough balancing >>>>>>>>>>>>>>>>>>>>>>> all the logins and sessions required for different = kids remote schooling, I >>>>>>>>>>>>>>>>>>>>>>> couldn=E2=80=99t imagine them having to understand = all the requirements for >>>>>>>>>>>>>>>>>>>>>>> managing multiple authorization servers and associa= ted policies. I also >>>>>>>>>>>>>>>>>>>>>>> don=E2=80=99t expect any person to =E2=80=9Cmanage = keys=E2=80=9D =E2=80=94 I=E2=80=99ve been on the internet for >>>>>>>>>>>>>>>>>>>>>>> decades and I can barely keep tabs on my GPG keys, = and only use them when I >>>>>>>>>>>>>>>>>>>>>>> am forced to. This is exactly the kind of =E2=80=9C= market pressure=E2=80=9D that I think >>>>>>>>>>>>>>>>>>>>>>> Ben mentions above, people will just want to outsou= rce that to someone >>>>>>>>>>>>>>>>>>>>>>> else, and the reality will be a few popular provide= rs. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> In which case, we could end up doing a ton of work >>>>>>>>>>>>>>>>>>>>>>> to allow an RS choice only to end up with a world w= here the RS ends up >>>>>>>>>>>>>>>>>>>>>>> making a limited choice anyway. We see how that pla= ys out with OpenID >>>>>>>>>>>>>>>>>>>>>>> Connect =E2=80=94 RP=E2=80=99s could allow arbitrar= y IdPs but they choose Google because it >>>>>>>>>>>>>>>>>>>>>>> works and that=E2=80=99s where the users are. (And = that=E2=80=99s not to say anything of >>>>>>>>>>>>>>>>>>>>>>> the proprietary OIDC-like protocols, but that=E2=80= =99s another discussion). >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> For further reading on these topics, I recommend >>>>>>>>>>>>>>>>>>>>>>> both =E2=80=9CWhy Johnny Can=E2=80=99t Encrypt=E2= =80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> So what does this have to do with GNAP? I think we >>>>>>>>>>>>>>>>>>>>>>> can be clear-eyed on what kinds of expectations we = have for the >>>>>>>>>>>>>>>>>>>>>>> participants. If we expect users (RO=E2=80=99s) to = have to set up the AS-RS >>>>>>>>>>>>>>>>>>>>>>> relationship, or expect them to carry their AS, or = manage their personal >>>>>>>>>>>>>>>>>>>>>>> keys =E2=80=94 I think we=E2=80=99ve lost the battl= e for relevance. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>> > --000000000000bb408c05be5f0330 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    There seems to be some confusion about how AS-RO comes int= o the picture, probably because of the "AS" part.=C2=A0 I'm g= oing to try to clear up that confusion by more carefully explaining what I = mean.

    I'm assuming that RO is a computational agent repres= enting the person who is the resource owner, something called the "use= r agent" in operating systems lingo.=C2=A0 I'm also assuming that = it's possible to do delegation, either locally or by token exchange wit= h AS-RS.=C2=A0 All delegations are potentially sub-scoped, but you may also= want to delegate with full scope to have a separately revocable access tok= en.

    =C2=A0 Here's an example of how things wor= k in a capability oriented system.
    1. Someone, the servi= ce owner, creates a service.
    2. The service owner contracts with an po= licy agent (AS-RS) to create and manage access tokens for that service (RS)= .
    3. A person wishing to create a resource at RS uses their user agent= (RO) to contact the service owner's policy agent (AS-RS) and gets back= an access token for that resource.
    4. That user agent (RO) can=C2=A0<= /li>
      1. use that access token to invoke the resource, or
      2. delega= te an access token to a client of the user agent's (RO) choice, or
        3. =
      3. contract with a policy agent (AS-RO) to manage those delegations on beh= alf of the user agent (RO), or
      4. specify a policy with the service= 9;s policy agent (AS-RS).
    5. A client can contact any holder of t= he access token (the user agent (RO) or its policy agent (AS-RO)) or the se= rvice's policy agent (AS-RS) to get a delegated access token.
    6. T= hat client can delegate that token to another client.
    7. Another user = agent (RO') can contact any holder of the access token or the service&#= 39;s policy agent (AS-RS) to get a delegated access token.
    8. The othe= r user agent (RO') can=C2=A0
      1. use that access token to invok= e the resource, or
      2. delegate it to a client of its choice, or
        3. contract with a policy agent (AS-RO') of its choosing to manage thos= e delegations on its behalf, or
      3. specify a policy with the service&#= 39;s policy agent (AS-RS).
    9. and so on
    =
    When any = of these computational agents, user agents (ROs) or clients acting on their= behalf, invokes the resource, AS-RS verifies that the access token is a va= lid delegation, i.e., proper sub-scoping, hasn't been revoked, and that= it authorizes the request being made before telling the service (RS) to ho= nor the request.=C2=A0 At no point does the service's policy agent (AS-= RS) know which computational agent did any particular delegation.=C2=A0 (To= ken exchange can be done as anonymously as possible.)=C2=A0 In particular, = the policy agents (AS-RO) need not be the same, or even compatible with, th= e service's policy agent (AS-RS).=C2=A0 GNAP specifies the protocol bet= ween requesters, invokers, delegators (for token exchange) of tokens and AS= -RS.=C2=A0 That protocol need not be used between user agents (RO), clients= , or other policy agents (AS-RO), but it is likely to be.

    =C2=A0------------= -
    Alan Karp


    On Thu, Mar 25, 2021 at = 5:45 AM Justin Richer <jricher@mit.ed= u> wrote:
    The way I=E2=80=99m thinking abo= ut Adrian=E2=80=99s use case is that what we=E2=80=99re calling the =E2=80= =9CAS-RO=E2=80=9D isn=E2=80=99t an =E2=80=9CAS=E2=80=9D in the traditional = OAuth/GNAP sense, at least not exactly. This is the agent that the RO can u= se to set policies and manage consent on their behalf, and I=E2=80=99ve bee= n arguing that it fits better into this vaguely-defined =E2=80=9Cinteractio= n component=E2=80=9D aspect of the current AS definition, and it=E2=80=99s = not currently separated from the AS definition. The =E2=80=9CAS-RS=E2=80=9D= maps to what we=E2=80=99d call the =E2=80=9CAS=E2=80=9D in OAuth/GNAP trad= itionally, it=E2=80=99s what the RS trusts to issue tokens. In traditional = OAuth the AS-RO and AS-RS are always the same thing, from a functional prot= ocol perspective. An important point here is that from a client=E2=80=99s p= erspective, they=E2=80=99re only talking to the AS-RS since that=E2=80=99s = where the client gets its tokens, because at the end of the day the client = just wants to call the API at the RS and doesn=E2=80=99t care how that happ= ens (from a protocol standpoint).=C2=A0

    Note well: Even = thought I don=E2=80=99t believe that =E2=80=9CAS-RO=E2=80=9D is an authoriz= ation server at all, I=E2=80=99m going to keep using that term below for co= nsistency with previous discussion.

    So we have the= se fundamental relationships around getting the client to access the RS:

    1. RS trusts=C2=A0AS-RS=C2=A0to issue tokens that RS= will accept, validate, and process for requests from client
    2. C= lient trusts=C2=A0AS-RS=C2=A0to issue tokens that client can use at RS
    3. RO trusts RS to protect RO=E2=80=99s api through delegated access<= /div>

    On top of that, we=E2=80=99ve got some additional = aspects that we=E2=80=99re discussing:

    4. RO trust= s=C2=A0AS-RO=C2=A0to manage RO=E2=80=99s policies at runtime
    5.= =C2=A0AS-RS=C2=A0trusts=C2=A0AS-RO=C2=A0to assert RO=E2=80=99s policies for= access to RS
    6. Client trusts whatever=C2=A0AS-RS=C2=A0sends cli= ent to deal with, including possibly RO-AS at runtime, because of (2)
    =

    What I have been saying is that 4/5/6 are optional deta= ils of how RS-AS runs things, and I think this also maps with Adrian=E2=80= =99s view of choice, since if my RS=E2=80=99s AS-RS doesn=E2=80=99t allow m= e to plug in my own AS-RO then I would be motivated to pick a different RS = who=E2=80=99s AS-RS lets me do just that. The same way I=E2=80=99d pick a d= ifferent RS if their surrounding services didn=E2=80=99t accept my preferre= d federation login and I didn=E2=80=99t want to make another account. Of co= urse, market forces being as they are, I might not have much of an actionab= le choice in RS, but GNAP can=E2=80=99t change that.=C2=A0

    What we can do is make it possible for AS-RS to talk to AS-RO, bot= h in philosophy of the protocol design and in concrete hooks to support (6)= above.=C2=A0

    Separately, we can approach the issu= e of making 1/2 above more dynamic. This was UMA2=E2=80=99s =E2=80=9Cfedera= ted authorization=E2=80=9D approach, and is behind a lot of the =E2=80=9Cbr= ing your own AS=E2=80=9D models out there. The problem with these is that w= e know from many years of experience that most RS=E2=80=99s aren=E2=80=99t = interested in doing anything of the sort.

    So with = GNAP we can instead allow 4/5/6 to vary in a predictable and consistent way= , letting the RS keep control over 1/2, thereby enabling choice in (3). We = don=E2=80=99t have to be the ones who define the all of the details of ever= y permutation of (5) to enable this, though. Some of this is going to be co= nfiguration out of band, some of it=E2=80=99s going to be communication at = runtime. This is where VC=E2=80=99s, ZCAPs, CHAPI, DIDComm, FIDO, and a who= le swath of other tech can come in and help out. I don=E2=80=99t think we n= eed to put all the details for using these into core, nor do I think we=E2= =80=99ll pull of The Great And Ultimate Abstraction for using these and oth= er approaches. But we can at least start talking about =E2=80=9CAS-RS=E2=80= =9D in such a way that it no longer assumes it=E2=80=99s always the same pa= rty dealing with the RO directly.

    =C2=A0=E2=80=94 Ju= stin

    On Mar 25, 2021, at 6:40 AM= , Fabien Imbault <fabien.imbault@gmail.com> wrote:

    To reframe it closer to GNAP:
    - AS =3D AS-RO, that's where you = find the RO policies. The AS issues access tokens to the client.
    = - the RO policies could be a) defined locally or b) in relationship with th= e RS

    There have been several ideas related to the = AS-RS relationship b:
    b1) the RS issues capabilities (which c= an be further attenuated by the RO)
    b2) Adrian also discussed a D= ID based solution
    b3) there was also an alternative ACL proposal = from Denis (+ preflight)

    Fabien


    On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault <fabien.imbault@gmail.com> wr= ote:
    Ok so I get you correctly:=C2=A0
    - what matters is the RQ (could = be a RO or a end-user or both : we don't really care at a high-level, t= hey're all treated as entities that make a request)
    - the pol= icy is able to handle those different cases, based on its own internal dele= gation protocol
    - currently that requires AS-RS and AS-RO, but ma= ybe it can be simplified

    To answer to Denis, here&= #39;s what I understood:
    - RO trusts AS-RS (and then handles its = own policies within AS-RO)
    - end-user trusts AS-RO (through i= ts client)

    Could probably work but that's a fa= irly different model compared to OAuth2 (and of today's GNAP), with dif= ferent frontiers between the AS and the RS.=C2=A0

    = Please do not hesitate to correct me if I'm wrong.

    =
    Fabien=C2=A0

    On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper <<= a href=3D"mailto:agropper@healthurl.com" target=3D"_blank">agropper@healthu= rl.com> wrote:
    I believe there are alternatives to having two kind= s of ASs. The problem may be a side-effect of deciding to switch away form = treating the RO as different from the RQ. That leads to downstream privacy = issues. Our desire for architectural simplicity is admirable but that may h= ave been a step too far.

    There may also be solutions based on different types of tokens, as in diff= erent capabilities (tokens signed by the RS) vs. tokens signed by the AS. I= =E2=80=99m not sure about that but Alan might have more to say.

    Adrian

    On Thu, Mar 25, 2021 at = 4:15 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks. The general = problem statement is clear.

    The=C2=A0proposed solution a= bit less (to me). I understood that from point 2, Alan involves 2 ASs. You= said : "There=E2=80=99s no obvious= reason to have two types of ASs".=C2=A0Do you see an alternati= ve ?

    Regarding the last item, I don't th= ink that naming RQ by end-user created the problem. It might just highlight= the asymmetry,=C2=A0which fundamentally exists.=C2=A0

    Fabien


    On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper <agropper@healthurl.com= > wrote:
    Recap:
    1 - Justin (I think) introduced= the idea of an AS on the RS trust boundary side.
    2 = - I said the RO should not have to share policies with the RS.
    3 - Alan invented the concept of AS-RO and AS-RS to separate two= kinds of PDPs.=C2=A0

    Th= e thing is that step 2 is not symmetrical. The RO has a legitimate privacy = interest in keeping their policies private and minimizing the leakage of in= formation about requests that are posed against those policies.=C2=A0
    =

    The RS, on the other hand, sh= ould be publishing its policies (e.g. what it=E2=80=99s selling or what jur= isdiction it=E2=80=99s in or what tokens or scopes it supports). The RS has= no obvious privacy interest in GNAP. It=E2=80=99s just an enforcer.
    <= div dir=3D"auto">
    There is one other privacy int= erest to consider around the RS and that is the requesting party (the end-u= ser that is not the RO :-) might prefer to share attributes with the RS ins= tead of the RO or something controlled by the RO. This case could be an =E2= =80=9Cextension=E2=80=9D to GNAP and might result in a split AS as a soluti= on. This problem was introduced when the editors decided to replace RQ with= end-user. Obviously, the RO end-user has no privacy interests relative to = itself.

    Adrian



    <= /div>

    On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault <fabien.imbault@gmail.com> = wrote:
    I was referring to "By my definition, this model has two ASs since both are processing requ= ests into tokens". If there's no reason to have 2 types of ASs, th= at's fine then.=C2=A0
    But I'm a bit lost in where we stand with the idea.=C2=A0=

    Could you recap?=C2=A0

    =
    Fabien=C2=A0
    Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper <agropper@healthurl.com> = a =C3=A9crit=C2=A0:
    There=E2=80=99s no obvious reason to have two types o= f ASs. Any AS that is executing the policies of the RS can look to GNAP lik= e the RS itself. Why would GNAP expose that interface to anyone?=C2=A0

    Adrian

    On Thu, Mar 25, 2= 021 at 3:11 AM Fabien Imbault <fabien.imbault@gmail.com> wr= ote:
    Note : I'm not sure that's a good idea, but having 2 types o= f ASs is not that easy to grasp.
    <= br>
    Fabien=C2=A0

    Le jeu. 25 mars 2021 =C3=A0 08= :07, Fabien Imbault <fabien.imbault@gmail.com> a =C3=A9crit= =C2=A0:
    The purpose of either handling policies locally or delegating the= m to the RO agent.=C2=A0

    Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper &= lt;agropper@healthurl.com> a =C3=A9crit=C2=A0:
    What= purpose would be served by GNAP splitting the AS into two components?

    Adrian=C2=A0

    On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Isn't th= e AS-RO a component of the AS? Same idea as the interact component, it func= tionnally belongs to the AS role but could be deployed either as a monolith= or as a separate component?

    <= /div>
    Fabien

    Le jeu. 25 mars 2021 =C3=A0 04:26, Adria= n Gropper <agropper@healthurl.com> a = =C3=A9crit=C2=A0:
    Yes, but I would say it=E2=80=99s not the RO that wants= the access token. It=E2=80=99s the RO that wants the client making the req= uest to get an access token.=C2=A0

    Adrian

    On Wed, Mar 24, 2021 at 11:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Adrian Gropper <agropper@healthurl.com> wrote:

    In this design, the AS is the AS-RS and the agent is t= he AS-RO. By my definition, this model has two ASs since both are processin= g requests into tokens. The problem with this is complexity and privacy. Th= e RO may not want to share the request information with the AS-RS.

    More precis= ely, RO has no choice but to present the required information to AS-RS if R= O wants an access token.=C2=A0 However, RO does not want AS-RS to know the = policy by which RO delegates tokens.=C2=A0 That's why RO uses AS-RO for= those delegations.

    --------------
    Alan Karp


    <= div dir=3D"ltr" class=3D"gmail_attr">On Wed, Mar 24, 2021 at 7:41 PM Adrian= Gropper <agropper@healthurl.com> wrote:

    = Based on that, I see it as obvious=C2=A0that the policy has to be accessibl= e (defined locally?) in order for it to be run as the code that turns a req= uest into an access token.=C2=A0

    The only other po= ssibility is that the request is packaged by the AS and sent elsewhere (an = agent) for evaluation against policy and a proto-token returned. In that ca= se the AS is acting as a proxy and the PDP is elsewhere. I can imagine that= an AS-RS would behave this way so that the proto-token could be turned int= o an access token by the AS-RS. Isn't this what Justin is proposing? In= this design, the AS is the AS-RS and the agent is the AS-RO. By my definit= ion, this model has two ASs since both are processing requests into tokens.= The problem with this is complexity and privacy. The RO may not want to sh= are the request information with the AS-RS.

    Adrian=

    On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Isn'= ;t that what the AS is supposed to be, only with the caveat that the policy= is defined locally?=C2=A0

    Fab= ien=C2=A0


    Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp <alanhkarp@gmail.com> a =C3=A9crit=C2=A0:
    AS-RO is an AS that RO trusts to delegate RO's access token= s according to RO's policies.=C2=A0=C2=A0

    --------------
    Alan Karp


    On Wed, Mar 24, 20= 21 at 9:36 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan and Adrian,
    <= br>
    I've created issue AS-RO policy delegation (https://= github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to capture your = input.=C2=A0
    A first question that arises: can we give a definiti= on to AS-RO?

    Thanks
    Fabien
    On Tue, = Mar 23, 2021 at 4:15 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Fabien Imbault &l= t;fabien.imbault@gmail.co= m> wrote:
    Hi Alan,=C2=A0

    Yes, but in that flow, = the token relationship between AS-RS and AS-RO is only secure if the tokens= issued by AS-RS are cryptographically attenuable in the first place.=C2=A0=
    =C2=A0
    Attenuated = delegation is a requirement, but that doesn't have to be done cryptogra= phically.=C2=A0 Token exchange works just fine.=C2=A0 SPKI and zcap-ld are = examples of the crypto approach, and we used token exchange in the system f= or HP.

    --------------
    Alan Karp


    On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    <= /div>
    Hi = Alan,=C2=A0

    Yes, but in that flow, the token relationshi= p between AS-RS and AS-RO is only secure if the tokens issued by AS-RS are = cryptographically attenuable in the first place.=C2=A0

    =
    Fabien

    On Mon, Mar 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin Richer <jricher@mit.edu> 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">

    B= ut with all that in mind, I think the key here is going to be looking at wh= at the inputs to the AS are, and how those can be defined in an interoperab= le way for AS=E2=80=99s that can accept them. I think there=E2=80=99s a lot= of room for innovation and flexibility here that doesn=E2=80=99t break the= trust model or core use cases. If I have an AS-RS set that won=E2=80=99t a= ccept my favorite flavor of policy engine inputs, then I can decide not to = use that one. But this is a very different question than saying the RS itse= lf needs to accept my own AS =E2=80=94 and we can=E2=80=99t keep conflating= these two models.

    I agree.=C2= =A0 The point of having an AS-RO is to allow RO to specify a policy for whi= ch of RO's access tokens should be delegated under what conditions.=C2= =A0 AS-RS should not need to understand those policies.=C2=A0 The flow woul= d be
    • RO contacts AS-RS and gets one or more access tokens= .
    • RO delegates one or more of those tokens, potentially sub-scoped,= to AS-RO.
    • A different user contacts AS-RO to get a potentially sub= -scoped access token from AS-RO.
    • That user presents the access toke= n delegated by AS-RO when invoking the resource.
    A= S-RS only needs to verify that the delegation chain is legitimate, e.g., no= increase in scope, and that it grants permission for the request being mad= e.=C2=A0 AS-RS does not need to understand the policy behind granting the d= elegation by AS-RO.

    --------------
    Alan Karp


    On Mon, Mar 22, 2021 at 11:40 AM Justin Richer <jricher@mit.edu> 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">
    Adrian,

    I think this shows the problem with the terminology as it=E2=80=99s b= een applied in this conversation, which I=E2=80=99ve tried to shine light o= n before. What you and others are calling the =E2=80=9CRS=E2=80=9D is reall= y the =E2=80=9CAS and RS working together=E2=80=9D =E2=80=94 everything to = the right of the line. When Denis had brought up =E2=80=9Celiminating the A= S=E2=80=9D in another thread, what he=E2=80=99d really done is labeled ever= ything to the right of the line as the =E2=80=9CRS=E2=80=9D. Of course, the= irony here is that everything to the right of the line used all be called = the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 = days. As you say below, I don=E2=80=99t want the client to have visibility = on what happens on that side.=C2=A0

    Note well: The= Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the diagram is not the AS, a= s far as GNAP is concerned. It does not issue an access token that the RS w= ill accept. The elements to the left of the line could be a lot of things, = but they are NOT the AS =E2=80=94 by definition. The client lives over on t= he left, but so do any external inputs to the AS. These could be policy inp= uts on behalf of the RO, they could be presentation artifacts, they could b= e federated logins, they could be the output of policy decisions. How the A= S comes to trust those things is up to the AS=E2=80=99s implementation. It= =E2=80=99s something we can talk about, but ultimately GNAP won=E2=80=99t b= e in any position to dictate because in practice some AS=E2=80=99s are simp= ly going to internalize all policies and we will never successfully force t= hose open.=C2=A0

    But with all that in mind, I thin= k the key here is going to be looking at what the inputs to the AS are, and= how those can be defined in an interoperable way for AS=E2=80=99s that can= accept them. I think there=E2=80=99s a lot of room for innovation and flex= ibility here that doesn=E2=80=99t break the trust model or core use cases. = If I have an AS-RS set that won=E2=80=99t accept my favorite flavor of poli= cy engine inputs, then I can decide not to use that one. But this is a very= different question than saying the RS itself needs to accept my own AS =E2= =80=94 and we can=E2=80=99t keep conflating these two models.
    So to me, GNAP can support a Zero Trust Architecture by LEVERAG= ING the AS, not by subsuming or eliminating it. It is in fact the AS, not t= he client and not the RS, that will request and consume the results of a pr= ivacy-preserving zero-trust policy query thing. Anything that happens downs= tream from that is of little concern to the zero-trust components because, = as you point out, it=E2=80=99s on the =E2=80=9Cother side=E2=80=9D of the l= ine.=C2=A0

    I think we got this basic component mod= el pretty right in OAuth: the AS and RS and client working together. Where = OAuth misses the mark is the assumption that the user has to log in to the = AS through a webpage and interact directly, thereby proving they=E2=80=99re= the RO. It=E2=80=99s this latter space where I think we can both push inno= vation and also address the important and compelling use cases like the one= s you=E2=80=99re bringing.

    =C2=A0=E2=80=94 Justin<= br>

    On Mar 22, 2021, at 2:14 PM, Adr= ian Gropper <agropper@he= althurl.com> wrote:

    I'm sorry, Ju= stin. As a Resource Owner, I look at the RS trust boundary (the dotted line= in the diagram) as being the RS. I don't expect any visibility into wh= at's going on on the=C2=A0right.=C2=A0

    My problem wi= th the framing you propose is that requests are going to the RS (or the AS-= RS) and I don't want to share my policies with the AS-RS. I want to kee= p the RS and AS-RS as ignorant as possible.

    Adrian=

    On Mon, Mar 22, 2021 at 1:48 PM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    What y= ou=E2=80=99re discussing below, in terms of logging in to a site, is not ap= proaching the RS. You are in fact approaching the client, and identifying b= oth the AS and RS to the client. The client is a client of your identity= in this model, and the RS is part of the identity provider. It=E2=80= =99s really important that we don=E2=80=99t conflate the RS and client in t= his way as it leads to a lot of confusion downstream and a lot of broken tr= ust boundaries.

    With that model in mind, approachi= ng the =E2=80=9CRS" and providing it your identity is really just a ca= se of the =E2=80=9Cfederated login to AS=E2=80=9D pattern that we discussed= on the WG call. The user here approaches an RS, which has its own AS. To s= hare things from this RS, the RO has to authenticate to the RS=E2=80=99s AS= . This particular AS allows the RO to do so using an external identity =E2= =80=94 in which case, the AS is now a =E2=80=9Cclient=E2=80=9D of a separat= e, disconnected (but layered) delegation. The ultimate client that eventual= ly calls the RS down the way may or may not know about these layers.=C2=A0<= /div>

    <PastedGra= phic-1.png>
    This same AS, which is closely tied to the = RS and trusted by the RS, might also take in FIDO credentials, or DIDs, or = any number of other proof mechanisms. The output of this is an access token= the RS trusts, but the input is up to the AS. The RS is not what you=E2=80= =99re logging in to.

    =C2=A0=E2=80=94 Justin

    On Mar 22, 2021, at 1:28 PM, Adrian Gr= opper <agropper@healthur= l.com> wrote:

    I too am in favor of av= oiding consolidation and correlation. Right now, when I approach a service = provider (RS) for the first time, I'm offered the opportunity to identi= fy my persona as: email, sign-in with Google, Facebook, or Apple. I know th= ere are people who try to create one-off email addresses but that is mostly= a waste of time.=C2=A0

    So, along come FIDO2 and DID wal= lets to the rescue. Now, in theory, I have a way to start out my RS relatio= nship pseudonymously.=C2=A0

    When I want my resourc= e to be discovered or shared I will post that RS URL including my pseudonym= . If I then want to introduce a mediator=C2=A0in front of my AS or messagin= g service=C2=A0endpoint, I have that option. If I want to keep requests awa= y from the mediator, I would publish an encryption key along with my pseudo= nym.

    - Adrian


    <= /div>
    O= n Mon, Mar 22, 2021 at 9:55 AM Justin Richer <jricher@mit.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk &= lt;kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhk= arp@gmail.com> shared a talk about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-= gnap/gnap-core-protocol/issues/145#issuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --
    TXAuth 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
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.= ietf.org/mailman/listinfo/txauth

    --000000000000bb408c05be5f0330-- From nobody Thu Mar 25 09:54:07 2021 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 670793A27DC for ; Thu, 25 Mar 2021 09:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 hSN1843SWtfY for ; Thu, 25 Mar 2021 09:53: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 5F7163A278F for ; Thu, 25 Mar 2021 09:53:50 -0700 (PDT) Received: from [192.168.1.22] (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 12PGrhvC018219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 25 Mar 2021 12:53:44 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B80FD213-7A84-46D1-8E62-C87F8DE81DB5" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 25 Mar 2021 12:53:43 -0400 In-Reply-To: Cc: Fabien Imbault , Adrian Gropper , Benjamin Kaduk , GNAP Mailing List , Mark Miller To: Alan Karp References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 16:54:05 -0000 --Apple-Mail=_B80FD213-7A84-46D1-8E62-C87F8DE81DB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Alan, In all of my discussion, and in the spec itself, the RO is the :entity: = in charge of approving rights. They=E2=80=99re probably a person. It = might be software that makes a policy decision in some way, or a = corporate entity, or something like that. But it=E2=80=99s not assumed = to be a computational agent in the terms of the protocol itself. Would = that recast what you=E2=80=99re saying below? =E2=80=94 Justin > On Mar 25, 2021, at 12:36 PM, Alan Karp wrote: >=20 > There seems to be some confusion about how AS-RO comes into the = picture, probably because of the "AS" part. I'm going to try to clear = up that confusion by more carefully explaining what I mean. >=20 > I'm assuming that RO is a computational agent representing the person = who is the resource owner, something called the "user agent" in = operating systems lingo. I'm also assuming that it's possible to do = delegation, either locally or by token exchange with AS-RS. All = delegations are potentially sub-scoped, but you may also want to = delegate with full scope to have a separately revocable access token. >=20 > Here's an example of how things work in a capability oriented = system. > Someone, the service owner, creates a service. > The service owner contracts with an policy agent (AS-RS) to create and = manage access tokens for that service (RS). > A person wishing to create a resource at RS uses their user agent (RO) = to contact the service owner's policy agent (AS-RS) and gets back an = access token for that resource. > That user agent (RO) can=20 > use that access token to invoke the resource, or > delegate an access token to a client of the user agent's (RO) choice, = or > contract with a policy agent (AS-RO) to manage those delegations on = behalf of the user agent (RO), or > specify a policy with the service's policy agent (AS-RS). > A client can contact any holder of the access token (the user agent = (RO) or its policy agent (AS-RO)) or the service's policy agent (AS-RS) = to get a delegated access token. > That client can delegate that token to another client. > Another user agent (RO') can contact any holder of the access token or = the service's policy agent (AS-RS) to get a delegated access token. > The other user agent (RO') can=20 > use that access token to invoke the resource, or > delegate it to a client of its choice, or > contract with a policy agent (AS-RO') of its choosing to manage those = delegations on its behalf, or > specify a policy with the service's policy agent (AS-RS). > and so on > When any of these computational agents, user agents (ROs) or clients = acting on their behalf, invokes the resource, AS-RS verifies that the = access token is a valid delegation, i.e., proper sub-scoping, hasn't = been revoked, and that it authorizes the request being made before = telling the service (RS) to honor the request. At no point does the = service's policy agent (AS-RS) know which computational agent did any = particular delegation. (Token exchange can be done as anonymously as = possible.) In particular, the policy agents (AS-RO) need not be the = same, or even compatible with, the service's policy agent (AS-RS). GNAP = specifies the protocol between requesters, invokers, delegators (for = token exchange) of tokens and AS-RS. That protocol need not be used = between user agents (RO), clients, or other policy agents (AS-RO), but = it is likely to be. >=20 > ------------- > Alan Karp >=20 >=20 > On Thu, Mar 25, 2021 at 5:45 AM Justin Richer > wrote: > The way I=E2=80=99m thinking about Adrian=E2=80=99s use case is that = what we=E2=80=99re calling the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an = =E2=80=9CAS=E2=80=9D in the traditional OAuth/GNAP sense, at least not = exactly. This is the agent that the RO can use to set policies and = manage consent on their behalf, and I=E2=80=99ve been arguing that it = fits better into this vaguely-defined =E2=80=9Cinteraction component=E2=80= =9D aspect of the current AS definition, and it=E2=80=99s not currently = separated from the AS definition. The =E2=80=9CAS-RS=E2=80=9D maps to = what we=E2=80=99d call the =E2=80=9CAS=E2=80=9D in OAuth/GNAP = traditionally, it=E2=80=99s what the RS trusts to issue tokens. In = traditional OAuth the AS-RO and AS-RS are always the same thing, from a = functional protocol perspective. An important point here is that from a = client=E2=80=99s perspective, they=E2=80=99re only talking to the AS-RS = since that=E2=80=99s where the client gets its tokens, because at the = end of the day the client just wants to call the API at the RS and = doesn=E2=80=99t care how that happens (from a protocol standpoint).=20 >=20 > Note well: Even thought I don=E2=80=99t believe that =E2=80=9CAS-RO=E2=80= =9D is an authorization server at all, I=E2=80=99m going to keep using = that term below for consistency with previous discussion. >=20 > So we have these fundamental relationships around getting the client = to access the RS: >=20 > 1. RS trusts AS-RS to issue tokens that RS will accept, validate, and = process for requests from client > 2. Client trusts AS-RS to issue tokens that client can use at RS > 3. RO trusts RS to protect RO=E2=80=99s api through delegated access >=20 > On top of that, we=E2=80=99ve got some additional aspects that we=E2=80=99= re discussing: >=20 > 4. RO trusts AS-RO to manage RO=E2=80=99s policies at runtime > 5. AS-RS trusts AS-RO to assert RO=E2=80=99s policies for access to RS > 6. Client trusts whatever AS-RS sends client to deal with, including = possibly RO-AS at runtime, because of (2) >=20 > What I have been saying is that 4/5/6 are optional details of how = RS-AS runs things, and I think this also maps with Adrian=E2=80=99s view = of choice, since if my RS=E2=80=99s AS-RS doesn=E2=80=99t allow me to = plug in my own AS-RO then I would be motivated to pick a different RS = who=E2=80=99s AS-RS lets me do just that. The same way I=E2=80=99d pick = a different RS if their surrounding services didn=E2=80=99t accept my = preferred federation login and I didn=E2=80=99t want to make another = account. Of course, market forces being as they are, I might not have = much of an actionable choice in RS, but GNAP can=E2=80=99t change that.=20= >=20 > What we can do is make it possible for AS-RS to talk to AS-RO, both in = philosophy of the protocol design and in concrete hooks to support (6) = above.=20 >=20 > Separately, we can approach the issue of making 1/2 above more = dynamic. This was UMA2=E2=80=99s =E2=80=9Cfederated authorization=E2=80=9D= approach, and is behind a lot of the =E2=80=9Cbring your own AS=E2=80=9D = models out there. The problem with these is that we know from many years = of experience that most RS=E2=80=99s aren=E2=80=99t interested in doing = anything of the sort. >=20 > So with GNAP we can instead allow 4/5/6 to vary in a predictable and = consistent way, letting the RS keep control over 1/2, thereby enabling = choice in (3). We don=E2=80=99t have to be the ones who define the all = of the details of every permutation of (5) to enable this, though. Some = of this is going to be configuration out of band, some of it=E2=80=99s = going to be communication at runtime. This is where VC=E2=80=99s, ZCAPs, = CHAPI, DIDComm, FIDO, and a whole swath of other tech can come in and = help out. I don=E2=80=99t think we need to put all the details for using = these into core, nor do I think we=E2=80=99ll pull of The Great And = Ultimate Abstraction for using these and other approaches. But we can at = least start talking about =E2=80=9CAS-RS=E2=80=9D in such a way that it = no longer assumes it=E2=80=99s always the same party dealing with the RO = directly. >=20 > =E2=80=94 Justin >=20 >> On Mar 25, 2021, at 6:40 AM, Fabien Imbault > wrote: >>=20 >> To reframe it closer to GNAP: >> - AS =3D AS-RO, that's where you find the RO policies. The AS issues = access tokens to the client. >> - the RO policies could be a) defined locally or b) in relationship = with the RS >>=20 >> There have been several ideas related to the AS-RS relationship b: >> b1) the RS issues capabilities (which can be further attenuated by = the RO) >> b2) Adrian also discussed a DID based solution >> b3) there was also an alternative ACL proposal from Denis (+ = preflight) >>=20 >> Fabien >>=20 >>=20 >> On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault = > wrote: >> Ok so I get you correctly:=20 >> - what matters is the RQ (could be a RO or a end-user or both : we = don't really care at a high-level, they're all treated as entities that = make a request) >> - the policy is able to handle those different cases, based on its = own internal delegation protocol >> - currently that requires AS-RS and AS-RO, but maybe it can be = simplified >>=20 >> To answer to Denis, here's what I understood: >> - RO trusts AS-RS (and then handles its own policies within AS-RO) >> - end-user trusts AS-RO (through its client) >>=20 >> Could probably work but that's a fairly different model compared to = OAuth2 (and of today's GNAP), with different frontiers between the AS = and the RS.=20 >>=20 >> Please do not hesitate to correct me if I'm wrong. >>=20 >> Fabien=20 >>=20 >> On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper = > wrote: >> I believe there are alternatives to having two kinds of ASs. The = problem may be a side-effect of deciding to switch away form treating = the RO as different from the RQ. That leads to downstream privacy = issues. Our desire for architectural simplicity is admirable but that = may have been a step too far. >>=20 >> There may also be solutions based on different types of tokens, as in = different capabilities (tokens signed by the RS) vs. tokens signed by = the AS. I=E2=80=99m not sure about that but Alan might have more to say. >>=20 >> Adrian >>=20 >> On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault = > wrote: >> Thanks. The general problem statement is clear. >>=20 >> The proposed solution a bit less (to me). I understood that from = point 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obvious = reason to have two types of ASs". Do you see an alternative ? >>=20 >> Regarding the last item, I don't think that naming RQ by end-user = created the problem. It might just highlight the asymmetry, which = fundamentally exists.=20 >>=20 >> Fabien >>=20 >>=20 >> On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper = > wrote: >> Recap: >> 1 - Justin (I think) introduced the idea of an AS on the RS trust = boundary side. >> 2 - I said the RO should not have to share policies with the RS. >> 3 - Alan invented the concept of AS-RO and AS-RS to separate two = kinds of PDPs.=20 >>=20 >> The thing is that step 2 is not symmetrical. The RO has a legitimate = privacy interest in keeping their policies private and minimizing the = leakage of information about requests that are posed against those = policies.=20 >>=20 >> The RS, on the other hand, should be publishing its policies (e.g. = what it=E2=80=99s selling or what jurisdiction it=E2=80=99s in or what = tokens or scopes it supports). The RS has no obvious privacy interest in = GNAP. It=E2=80=99s just an enforcer. >>=20 >> There is one other privacy interest to consider around the RS and = that is the requesting party (the end-user that is not the RO :-) might = prefer to share attributes with the RS instead of the RO or something = controlled by the RO. This case could be an =E2=80=9Cextension=E2=80=9D = to GNAP and might result in a split AS as a solution. This problem was = introduced when the editors decided to replace RQ with end-user. = Obviously, the RO end-user has no privacy interests relative to itself. >>=20 >> Adrian >>=20 >>=20 >>=20 >>=20 >> On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault = > wrote: >> I was referring to "By my definition, this model has two ASs since = both are processing requests into tokens". If there's no reason to have = 2 types of ASs, that's fine then.=20 >> But I'm a bit lost in where we stand with the idea.=20 >>=20 >> Could you recap?=20 >>=20 >> Fabien=20 >>=20 >> Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper = > a =C3=A9crit : >> There=E2=80=99s no obvious reason to have two types of ASs. Any AS = that is executing the policies of the RS can look to GNAP like the RS = itself. Why would GNAP expose that interface to anyone?=20 >>=20 >> Adrian >>=20 >> On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault = > wrote: >> Note : I'm not sure that's a good idea, but having 2 types of ASs is = not that easy to grasp. >>=20 >> Fabien=20 >>=20 >> Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault = > a =C3=A9crit = : >> The purpose of either handling policies locally or delegating them to = the RO agent.=20 >>=20 >> Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper = > a =C3=A9crit : >> What purpose would be served by GNAP splitting the AS into two = components? >>=20 >> Adrian=20 >>=20 >> On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault = > wrote: >> Isn't the AS-RO a component of the AS? Same idea as the interact = component, it functionnally belongs to the AS role but could be deployed = either as a monolith or as a separate component? >>=20 >> Fabien >>=20 >> Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper = > a =C3=A9crit : >> Yes, but I would say it=E2=80=99s not the RO that wants the access = token. It=E2=80=99s the RO that wants the client making the request to = get an access token.=20 >>=20 >> Adrian >>=20 >> On Wed, Mar 24, 2021 at 11:22 PM Alan Karp > wrote: >> Adrian Gropper > wrote: >>=20 >> In this design, the AS is the AS-RS and the agent is the AS-RO. By my = definition, this model has two ASs since both are processing requests = into tokens. The problem with this is complexity and privacy. The RO may = not want to share the request information with the AS-RS. >>=20 >> More precisely, RO has no choice but to present the required = information to AS-RS if RO wants an access token. However, RO does not = want AS-RS to know the policy by which RO delegates tokens. That's why = RO uses AS-RO for those delegations. >>=20 >> -------------- >> Alan Karp >>=20 >>=20 >> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper = > wrote: >> Thank you for creating the issue. My definition of AS is independent = of AS-RO or AS-RS. = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomment= -806280421 = I also agree with Alan's definition based on delegation. An = AS-RS would be a delegate of the RS.=20 >>=20 >> Based on that, I see it as obvious that the policy has to be = accessible (defined locally?) in order for it to be run as the code that = turns a request into an access token.=20 >>=20 >> The only other possibility is that the request is packaged by the AS = and sent elsewhere (an agent) for evaluation against policy and a = proto-token returned. In that case the AS is acting as a proxy and the = PDP is elsewhere. I can imagine that an AS-RS would behave this way so = that the proto-token could be turned into an access token by the AS-RS. = Isn't this what Justin is proposing? In this design, the AS is the AS-RS = and the agent is the AS-RO. By my definition, this model has two ASs = since both are processing requests into tokens. The problem with this is = complexity and privacy. The RO may not want to share the request = information with the AS-RS. >>=20 >> Adrian >>=20 >> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault = > wrote: >> Isn't that what the AS is supposed to be, only with the caveat that = the policy is defined locally?=20 >>=20 >> Fabien=20 >>=20 >>=20 >> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp > a =C3=A9crit : >> AS-RO is an AS that RO trusts to delegate RO's access tokens = according to RO's policies. =20 >>=20 >> -------------- >> Alan Karp >>=20 >>=20 >> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault = > wrote: >> Hi Alan and Adrian, >>=20 >> I've created issue AS-RO policy delegation = (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223 = ) to = capture your input.=20 >> A first question that arises: can we give a definition to AS-RO? >>=20 >> Thanks >> Fabien >>=20 >> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp > wrote: >> Fabien Imbault > wrote: >> Hi Alan,=20 >>=20 >> Yes, but in that flow, the token relationship between AS-RS and AS-RO = is only secure if the tokens issued by AS-RS are cryptographically = attenuable in the first place.=20 >> =20 >> Attenuated delegation is a requirement, but that doesn't have to be = done cryptographically. Token exchange works just fine. SPKI and = zcap-ld are examples of the crypto approach, and we used token exchange = in the system for HP. >>=20 >> -------------- >> Alan Karp >>=20 >>=20 >> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault = > wrote: >> Hi Alan,=20 >>=20 >> Yes, but in that flow, the token relationship between AS-RS and AS-RO = is only secure if the tokens issued by AS-RS are cryptographically = attenuable in the first place.=20 >>=20 >> Fabien >>=20 >> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp > wrote: >> Justin Richer > wrote: >>=20 >> But with all that in mind, I think the key here is going to be = looking at what the inputs to the AS are, and how those can be defined = in an interoperable way for AS=E2=80=99s that can accept them. I think = there=E2=80=99s a lot of room for innovation and flexibility here that = doesn=E2=80=99t break the trust model or core use cases. If I have an = AS-RS set that won=E2=80=99t accept my favorite flavor of policy engine = inputs, then I can decide not to use that one. But this is a very = different question than saying the RS itself needs to accept my own AS = =E2=80=94 and we can=E2=80=99t keep conflating these two models. >>=20 >> I agree. The point of having an AS-RO is to allow RO to specify a = policy for which of RO's access tokens should be delegated under what = conditions. AS-RS should not need to understand those policies. The = flow would be >> RO contacts AS-RS and gets one or more access tokens. >> RO delegates one or more of those tokens, potentially sub-scoped, to = AS-RO. >> A different user contacts AS-RO to get a potentially sub-scoped = access token from AS-RO. >> That user presents the access token delegated by AS-RO when invoking = the resource. >> AS-RS only needs to verify that the delegation chain is legitimate, = e.g., no increase in scope, and that it grants permission for the = request being made. AS-RS does not need to understand the policy behind = granting the delegation by AS-RO. >>=20 >> -------------- >> Alan Karp >>=20 >>=20 >> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer > wrote: >> Adrian, >>=20 >> I think this shows the problem with the terminology as it=E2=80=99s = been applied in this conversation, which I=E2=80=99ve tried to shine = light on before. What you and others are calling the =E2=80=9CRS=E2=80=9D = is really the =E2=80=9CAS and RS working together=E2=80=9D =E2=80=94 = everything to the right of the line. When Denis had brought up = =E2=80=9Celiminating the AS=E2=80=9D in another thread, what he=E2=80=99d = really done is labeled everything to the right of the line as the = =E2=80=9CRS=E2=80=9D. Of course, the irony here is that everything to = the right of the line used all be called the =E2=80=9CAS=E2=80=9D or = simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say below, I = don=E2=80=99t want the client to have visibility on what happens on that = side.=20 >>=20 >> Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the = diagram is not the AS, as far as GNAP is concerned. It does not issue an = access token that the RS will accept. The elements to the left of the = line could be a lot of things, but they are NOT the AS =E2=80=94 by = definition. The client lives over on the left, but so do any external = inputs to the AS. These could be policy inputs on behalf of the RO, they = could be presentation artifacts, they could be federated logins, they = could be the output of policy decisions. How the AS comes to trust those = things is up to the AS=E2=80=99s implementation. It=E2=80=99s something = we can talk about, but ultimately GNAP won=E2=80=99t be in any position = to dictate because in practice some AS=E2=80=99s are simply going to = internalize all policies and we will never successfully force those = open.=20 >>=20 >> But with all that in mind, I think the key here is going to be = looking at what the inputs to the AS are, and how those can be defined = in an interoperable way for AS=E2=80=99s that can accept them. I think = there=E2=80=99s a lot of room for innovation and flexibility here that = doesn=E2=80=99t break the trust model or core use cases. If I have an = AS-RS set that won=E2=80=99t accept my favorite flavor of policy engine = inputs, then I can decide not to use that one. But this is a very = different question than saying the RS itself needs to accept my own AS = =E2=80=94 and we can=E2=80=99t keep conflating these two models. >>=20 >> So to me, GNAP can support a Zero Trust Architecture by LEVERAGING = the AS, not by subsuming or eliminating it. It is in fact the AS, not = the client and not the RS, that will request and consume the results of = a privacy-preserving zero-trust policy query thing. Anything that = happens downstream from that is of little concern to the zero-trust = components because, as you point out, it=E2=80=99s on the =E2=80=9Cother = side=E2=80=9D of the line.=20 >>=20 >> I think we got this basic component model pretty right in OAuth: the = AS and RS and client working together. Where OAuth misses the mark is = the assumption that the user has to log in to the AS through a webpage = and interact directly, thereby proving they=E2=80=99re the RO. It=E2=80=99= s this latter space where I think we can both push innovation and also = address the important and compelling use cases like the ones you=E2=80=99r= e bringing. >>=20 >> =E2=80=94 Justin >>=20 >>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper > wrote: >>>=20 >>> I'm sorry, Justin. As a Resource Owner, I look at the RS trust = boundary (the dotted line in the diagram) as being the RS. I don't = expect any visibility into what's going on on the right.=20 >>>=20 >>> My problem with the framing you propose is that requests are going = to the RS (or the AS-RS) and I don't want to share my policies with the = AS-RS. I want to keep the RS and AS-RS as ignorant as possible. >>>=20 >>> Adrian >>>=20 >>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer > wrote: >>> Adrian, >>>=20 >>> What you=E2=80=99re discussing below, in terms of logging in to a = site, is not approaching the RS. You are in fact approaching the client, = and identifying both the AS and RS to the client. The client is a client = of your identity in this model, and the RS is part of the identity = provider. It=E2=80=99s really important that we don=E2=80=99t conflate = the RS and client in this way as it leads to a lot of confusion = downstream and a lot of broken trust boundaries. >>>=20 >>> With that model in mind, approaching the =E2=80=9CRS" and providing = it your identity is really just a case of the =E2=80=9Cfederated login = to AS=E2=80=9D pattern that we discussed on the WG call. The user here = approaches an RS, which has its own AS. To share things from this RS, = the RO has to authenticate to the RS=E2=80=99s AS. This particular AS = allows the RO to do so using an external identity =E2=80=94 in which = case, the AS is now a =E2=80=9Cclient=E2=80=9D of a separate, = disconnected (but layered) delegation. The ultimate client that = eventually calls the RS down the way may or may not know about these = layers.=20 >>>=20 >>> >>> This same AS, which is closely tied to the RS and trusted by the RS, = might also take in FIDO credentials, or DIDs, or any number of other = proof mechanisms. The output of this is an access token the RS trusts, = but the input is up to the AS. The RS is not what you=E2=80=99re logging = in to. >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper > wrote: >>>>=20 >>>> I too am in favor of avoiding consolidation and correlation. Right = now, when I approach a service provider (RS) for the first time, I'm = offered the opportunity to identify my persona as: email, sign-in with = Google, Facebook, or Apple. I know there are people who try to create = one-off email addresses but that is mostly a waste of time.=20 >>>>=20 >>>> So, along come FIDO2 and DID wallets to the rescue. Now, in theory, = I have a way to start out my RS relationship pseudonymously.=20 >>>>=20 >>>> When I want my resource to be discovered or shared I will post that = RS URL including my pseudonym. If I then want to introduce a mediator in = front of my AS or messaging service endpoint, I have that option. If I = want to keep requests away from the mediator, I would publish an = encryption key along with my pseudonym. >>>>=20 >>>> - Adrian >>>>=20 >>>>=20 >>>>=20 >>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer > wrote: >>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk > wrote: >>>> >=20 >>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote: >>>> >> @Alan Karp > = shared a talk about the Principle Of Least >>>> >> Authority (POLA) in a recent comment >>>> >> = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment= -803099693 = >>>> >> I recommend it. >>>> >>=20 >>>> >> We might expect a protocol with authorization in the title to = use authority >>>> >> as a core principle. I advocate for a GNAP design that maximizes = the power >>>> >> of the RO, to be seen as a human rights issue when the RO is a = human. This >>>> >> causes me to ask how to combine better security with better = human rights in >>>> >> GNAP. >>>> >>=20 >>>> >> Who should have the least authority in the GNAP design? >>>> >>=20 >>>> >> The AS derives authority as a delegate of the RO. If we ask the = RO to >>>> >> partition limited authority across dozens of different ASs by = domain and >>>> >> function, then we are not using technology to empower the = individual. >>>> >> Probably the opposite, as we introduce consent fatigue and = burden normal >>>> >> people to partition their lives into non-overlapping domains. >>>> >>=20 >>>> >> My experience says we should aim for one AS per persona because = that maps >>>> >> into the way we manage our public and private identities. POLA = would then >>>> >> teach care in keeping ASs and RSs related to work / public = separate from >>>> >> ASs and RSs related to private life so that a policy = vulnerability in our >>>> >> delegation to an AS would have the least likelihood of harm. >>>> >=20 >>>> > Thinking about how least authority/least privilege would apply to = GNAP >>>> > seems like a useful exercise. I do want to point out some = potential >>>> > pitfalls with one-AS-per-persona that we can also be aware of. = If >>>> > one-AS-per-persona becomes one-persona-per-AS as well, then the = AS's >>>> > identity in effect also serves as a persona identity and there = are privacy >>>> > considerations to that. If, on the other hand, the >>>> > multiple-personas-per-AS (presumably corresponding to multiple = humans) >>>> > route is taken, we should consider whether that would lead to = various >>>> > (e.g., market) forces driving consolidation to just a handful of >>>> > super-popular AS services. That topic is a current matter of = concern to >>>> > some IETF participants. >>>> >=20 >>>>=20 >>>> Hi Ben, big +1 to this. This is something that we discussed ages = ago in the UMA working group, and it=E2=80=99s one of the biggest = problems with the personal AS (and personal data store) model. This kind = of thing makes RS-first trust models really difficult in practice. >>>>=20 >>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve got software = that wants to access my medical information. It calls an RS and requests = access, but it hasn=E2=80=99t been granted anything yet. Now I as the RO = have set up the RS so that it talks to my personal AS, that only I use. = In addition to the RS having to be able to figure out which medical = records are being requested from the context of the unauthenticated = request (which means it needs identifiers in the URL or something = similar for the RS to be able to tell, assuming that it protects data = for more than one person). So this client software doesn=E2=80=99t know = who I am and doesn=E2=80=99t know my medical record information, makes a = completely unauthorized request to the RS, and the RS says =E2=80=9CGo = to Justin=E2=80=99s personal AS to get a token=E2=80=9D. The client can = now make a direct correlation between the data that=E2=80=99s being = protected at the RS and the person running the AS that protects it. = Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This = is a design feature in the good case, and terrifying in the bad case. >>>>=20 >>>> If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, = please talk to the Medicine Doctor AS to get access=E2=80=9D, we = haven=E2=80=99t exposed anything at all. And from the perspective of = both the patient and the RS, this is more privacy-preserving, and it=E2=80= =99s really the least surprising option. Once the client gets to the AS, = it can start a negotiation of figuring out who the RO is for the = information being accessed. >>>>=20 >>>> On top of this, the usability expectations of people managing their = own AS, or set of AS=E2=80=99s for multiple personas to keep things = separate, is a huge burden. Even in the tech community, I know people = who can=E2=80=99t reliably manage more than one email address for = different purposes. I wouldn=E2=80=99t expect my partner to do that =E2=80= =94 they have trouble enough balancing all the logins and sessions = required for different kids remote schooling, I couldn=E2=80=99t imagine = them having to understand all the requirements for managing multiple = authorization servers and associated policies. I also don=E2=80=99t = expect any person to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve = been on the internet for decades and I can barely keep tabs on my GPG = keys, and only use them when I am forced to. This is exactly the kind of = =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions above, = people will just want to outsource that to someone else, and the reality = will be a few popular providers. >>>>=20 >>>> In which case, we could end up doing a ton of work to allow an RS = choice only to end up with a world where the RS ends up making a limited = choice anyway. We see how that plays out with OpenID Connect =E2=80=94 = RP=E2=80=99s could allow arbitrary IdPs but they choose Google because = it works and that=E2=80=99s where the users are. (And that=E2=80=99s not = to say anything of the proprietary OIDC-like protocols, but that=E2=80=99s= another discussion). >>>>=20 >>>> For further reading on these topics, I recommend both =E2=80=9CWhy = Johnny Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems = Fail=E2=80=9D. >>>>=20 >>>> So what does this have to do with GNAP? I think we can be = clear-eyed on what kinds of expectations we have for the participants. = If we expect users (RO=E2=80=99s) to have to set up the AS-RS = relationship, or expect them to carry their AS, or manage their personal = keys =E2=80=94 I think we=E2=80=99ve lost the battle for relevance. >>>>=20 >>>> =E2=80=94 Justin >>>=20 >>=20 >> --=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 = >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >=20 --Apple-Mail=_B80FD213-7A84-46D1-8E62-C87F8DE81DB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Alan,

    In all of my = discussion, and in the spec itself, the RO is the :entity: in charge of = approving rights. They=E2=80=99re probably a person. It might be = software that makes a policy decision in some way, or a corporate = entity, or something like that. But it=E2=80=99s not assumed to be a = computational agent in the terms of the protocol itself. Would that = recast what you=E2=80=99re saying below?

     =E2=80=94 Justin

    On Mar 25, 2021, at 12:36 PM, Alan Karp <alanhkarp@gmail.com>= wrote:

    There seems to be some confusion = about how AS-RO comes into the picture, probably because of the "AS" = part.  I'm going to try to clear up that confusion by more = carefully explaining what I mean.

    I'm assuming that RO is a computational agent representing = the person who is the resource owner, something called the "user agent" = in operating systems lingo.  I'm also assuming that it's possible = to do delegation, either locally or by token exchange with AS-RS.  = All delegations are potentially sub-scoped, but you may also want to = delegate with full scope to have a separately revocable access = token.

      = Here's an example of how things work in a capability oriented system.
    1. Someone, = the service owner, creates a service.
    2. The service = owner contracts with an policy agent (AS-RS) to create and manage access = tokens for that service (RS).
    3. A person wishing to = create a resource at RS uses their user agent (RO) to contact the = service owner's policy agent (AS-RS) and gets back an access token for = that resource.
    4. That user agent (RO) can 
      1. use that access token to invoke the resource, = or
      2. delegate an access token to a client of the user = agent's (RO) choice, or
      3. contract with a policy agent = (AS-RO) to manage those delegations on behalf of the user agent (RO), = or
      4. specify a policy with the service's policy agent = (AS-RS).
    5. A client can contact any holder of the = access token (the user agent (RO) or its policy agent (AS-RO)) or the = service's policy agent (AS-RS) to get a delegated access token.
    6. That client can delegate that token to another = client.
    7. Another user agent (RO') can contact any = holder of the access token or the service's policy agent (AS-RS) to get = a delegated access token.
    8. The other user agent (RO') = can 
      1. use that access token to = invoke the resource, or
      2. delegate it to a client of = its choice, or
      3. contract with a policy agent (AS-RO') = of its choosing to manage those delegations on its behalf, or
      4. specify a policy with the service's policy agent = (AS-RS).
    9. and so on
    When any of these computational = agents, user agents (ROs) or clients acting on their behalf, invokes the = resource, AS-RS verifies that the access token is a valid delegation, = i.e., proper sub-scoping, hasn't been revoked, and that it authorizes = the request being made before telling the service (RS) to honor the = request.  At no point does the service's policy agent (AS-RS) know = which computational agent did any particular delegation.  (Token = exchange can be done as anonymously as possible.)  In particular, = the policy agents (AS-RO) need not be the same, or even compatible with, = the service's policy agent (AS-RS).  GNAP specifies the protocol = between requesters, invokers, delegators (for token exchange) of tokens = and AS-RS.  That protocol need not be used between user agents = (RO), clients, or other policy agents (AS-RO), but it is likely to = be.

     -------------
    Alan Karp


    On Thu, Mar = 25, 2021 at 5:45 AM Justin Richer <jricher@mit.edu> wrote:
    The way I=E2=80=99m thinking about Adrian=E2=80=99= s use case is that what we=E2=80=99re calling the =E2=80=9CAS-RO=E2=80=9D = isn=E2=80=99t an =E2=80=9CAS=E2=80=9D in the traditional OAuth/GNAP = sense, at least not exactly. This is the agent that the RO can use to = set policies and manage consent on their behalf, and I=E2=80=99ve been = arguing that it fits better into this vaguely-defined =E2=80=9Cinteraction= component=E2=80=9D aspect of the current AS definition, and it=E2=80=99s = not currently separated from the AS definition. The =E2=80=9CAS-RS=E2=80=9D= maps to what we=E2=80=99d call the =E2=80=9CAS=E2=80=9D in OAuth/GNAP = traditionally, it=E2=80=99s what the RS trusts to issue tokens. In = traditional OAuth the AS-RO and AS-RS are always the same thing, from a = functional protocol perspective. An important point here is that from a = client=E2=80=99s perspective, they=E2=80=99re only talking to the AS-RS = since that=E2=80=99s where the client gets its tokens, because at the = end of the day the client just wants to call the API at the RS and = doesn=E2=80=99t care how that happens (from a protocol = standpoint). 

    Note well: Even thought I don=E2=80=99t believe that = =E2=80=9CAS-RO=E2=80=9D is an authorization server at all, I=E2=80=99m = going to keep using that term below for consistency with previous = discussion.

    So = we have these fundamental relationships around getting the client to = access the RS:

    1. RS trusts AS-RS to issue tokens that RS will = accept, validate, and process for requests from client
    2. Client trusts AS-RS to issue tokens that client = can use at RS
    3. RO trusts RS to protect RO=E2=80=99s= api through delegated access

    On top of that, we=E2=80=99ve got some = additional aspects that we=E2=80=99re discussing:
    4. RO trusts AS-RO to manage = RO=E2=80=99s policies at runtime
    5. AS-RS trusts AS-RO to assert RO=E2=80=99= s policies for access to RS
    6. Client trusts = whatever AS-RS sends client to deal with, including possibly = RO-AS at runtime, because of (2)

    What I have been saying is that 4/5/6 = are optional details of how RS-AS runs things, and I think this also = maps with Adrian=E2=80=99s view of choice, since if my RS=E2=80=99s = AS-RS doesn=E2=80=99t allow me to plug in my own AS-RO then I would be = motivated to pick a different RS who=E2=80=99s AS-RS lets me do just = that. The same way I=E2=80=99d pick a different RS if their surrounding = services didn=E2=80=99t accept my preferred federation login and I = didn=E2=80=99t want to make another account. Of course, market forces = being as they are, I might not have much of an actionable choice in RS, = but GNAP can=E2=80=99t change that. 

    What we can do is make it possible for = AS-RS to talk to AS-RO, both in philosophy of the protocol design and in = concrete hooks to support (6) above. 

    Separately, we can approach the issue = of making 1/2 above more dynamic. This was UMA2=E2=80=99s =E2=80=9Cfederat= ed authorization=E2=80=9D approach, and is behind a lot of the =E2=80=9Cbr= ing your own AS=E2=80=9D models out there. The problem with these is = that we know from many years of experience that most RS=E2=80=99s = aren=E2=80=99t interested in doing anything of the sort.

    So with GNAP we can = instead allow 4/5/6 to vary in a predictable and consistent way, letting = the RS keep control over 1/2, thereby enabling choice in (3). We don=E2=80= =99t have to be the ones who define the all of the details of every = permutation of (5) to enable this, though. Some of this is going to be = configuration out of band, some of it=E2=80=99s going to be = communication at runtime. This is where VC=E2=80=99s, ZCAPs, CHAPI, = DIDComm, FIDO, and a whole swath of other tech can come in and help out. = I don=E2=80=99t think we need to put all the details for using these = into core, nor do I think we=E2=80=99ll pull of The Great And Ultimate = Abstraction for using these and other approaches. But we can at least = start talking about =E2=80=9CAS-RS=E2=80=9D in such a way that it no = longer assumes it=E2=80=99s always the same party dealing with the RO = directly.

     =E2=80=94 Justin

    On Mar = 25, 2021, at 6:40 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    To reframe it = closer to GNAP:
    - AS =3D AS-RO, that's where you find the = RO policies. The AS issues access tokens to the client.
    - the RO policies could be a) defined locally or b) in = relationship with the RS

    There have been several ideas related to the AS-RS = relationship b:
    b1) the RS issues = capabilities (which can be further attenuated by the RO)
    b2) Adrian also discussed a DID based solution
    b3) there was also an alternative ACL proposal from Denis (+ = preflight)

    Fabien


    On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Ok so I = get you correctly: 
    - what matters is the RQ (could = be a RO or a end-user or both : we don't really care at a high-level, = they're all treated as entities that make a request)
    - the policy is able to handle those different cases, based = on its own internal delegation protocol
    - currently = that requires AS-RS and AS-RO, but maybe it can be simplified

    To answer to Denis, = here's what I understood:
    - RO trusts AS-RS (and = then handles its own policies within AS-RO)
    - end-user trusts AS-RO (through its client)

    Could probably work but = that's a fairly different model compared to OAuth2 (and of today's = GNAP), with different frontiers between the AS and the = RS. 

    Please= do not hesitate to correct me if I'm wrong.

    Fabien 

    On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper = <agropper@healthurl.com> wrote:
    I = believe there are alternatives to having two kinds of ASs. The problem = may be a side-effect of deciding to switch away form treating the RO as = different from the RQ. That leads to downstream privacy issues. Our = desire for architectural simplicity is admirable but that may have been = a step too far.

    There may also be = solutions based on different types of tokens, as in different = capabilities (tokens signed by the RS) vs. tokens signed by the AS. = I=E2=80=99m not sure about that but Alan might have more to = say.

    Adrian

    On Thu, Mar = 25, 2021 at 4:15 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks. = The general problem statement is clear.

    The proposed solution a bit less = (to me). I understood that from point 2, Alan involves 2 ASs. You said : = "There=E2=80=99s no = obvious reason to have two types of ASs". Do you see an = alternative ?

    Regarding the last item, I don't think that = naming RQ by end-user created the problem. It might just highlight the = asymmetry, which fundamentally exists. 

    Fabien


    On Thu, Mar 25, 2021 at 8:48 AM Adrian = Gropper <agropper@healthurl.com> wrote:
    Recap:
    1 - Justin (I think) = introduced the idea of an AS on the RS trust boundary side.
    2 - I said the RO should not have to share = policies with the RS.
    3 - Alan = invented the concept of AS-RO and AS-RS to separate two kinds of = PDPs. 

    The thing is that step 2 is not symmetrical. The = RO has a legitimate privacy interest in keeping their policies private = and minimizing the leakage of information about requests that are posed = against those policies. 

    The RS, on the other hand, = should be publishing its policies (e.g. what it=E2=80=99s selling or = what jurisdiction it=E2=80=99s in or what tokens or scopes it supports). = The RS has no obvious privacy interest in GNAP. It=E2=80=99s just an = enforcer.

    There is one other privacy interest to consider = around the RS and that is the requesting party (the end-user that is not = the RO :-) might prefer to share attributes with the RS instead of the = RO or something controlled by the RO. This case could be an = =E2=80=9Cextension=E2=80=9D to GNAP and might result in a split AS as a = solution. This problem was introduced when the editors decided to = replace RQ with end-user. Obviously, the RO end-user has no privacy = interests relative to itself.

    Adrian




    On Thu, Mar = 25, 2021 at 3:24 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    I was referring to "By my definition, this model has two ASs since both are = processing requests into tokens". If there's no reason to have 2 types = of ASs, that's fine then. 
    But I'm a bit lost in = where we stand with the idea. 

    Could you = recap? 

    Fabien 

    Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper = <agropper@healthurl.com> a =C3=A9crit :
    There=E2=80= =99s no obvious reason to have two types of ASs. Any AS that is = executing the policies of the RS can look to GNAP like the RS itself. = Why would GNAP expose that interface to anyone? 

    Adrian

    On Thu, Mar = 25, 2021 at 3:11 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Note : = I'm not sure that's a good idea, but having 2 types of ASs is not that = easy to grasp.

    Fabien 

    Le jeu. 25 = mars 2021 =C3=A0 08:07, Fabien Imbault <fabien.imbault@gmail.com> a = =C3=A9crit :
    The = purpose of either handling policies locally or delegating them to the RO = agent. 

    Le jeu. 25 mars 2021 =C3=A0 08:04, = Adrian Gropper <agropper@healthurl.com> a =C3=A9crit :
    What = purpose would be served by GNAP splitting the AS into two = components?

    Adrian 
    On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Isn't = the AS-RO a component of the AS? Same idea as the interact component, it = functionnally belongs to the AS role but could be deployed either as a = monolith or as a separate component?

    Fabien

    Le jeu. 25 = mars 2021 =C3=A0 04:26, Adrian Gropper <agropper@healthurl.com> = a =C3=A9crit :
    Yes, but = I would say it=E2=80=99s not the RO that wants the access token. It=E2=80=99= s the RO that wants the client making the request to get an access = token. 

    Adrian

    On Wed, Mar = 24, 2021 at 11:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Adrian = Gropper <agropper@healthurl.com> wrote:

    In this = design, the AS is the AS-RS and the agent is the AS-RO. By my = definition, this model has two ASs since both are processing requests = into tokens. The problem with this is complexity and privacy. The RO may = not want to share the request information with the AS-RS.

    More precisely, RO has = no choice but to present the required information to AS-RS if RO wants = an access token.  However, RO does not want AS-RS to know the = policy by which RO delegates tokens.  That's why RO uses AS-RO for = those delegations.

    --------------
    Alan Karp


    On Wed, Mar = 24, 2021 at 7:41 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Thank you for creating the issue. My definition = of AS is independent of AS-RO or AS-RS. https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#i= ssuecomment-806280421 I also agree with Alan's definition based on = delegation. An AS-RS would be a delegate of the RS. 

    Based on = that, I see it as obvious that the policy has to be accessible = (defined locally?) in order for it to be run as the code that turns a = request into an access token. 

    The only other possibility is that the = request is packaged by the AS and sent elsewhere (an agent) for = evaluation against policy and a proto-token returned. In that case the = AS is acting as a proxy and the PDP is elsewhere. I can imagine that an = AS-RS would behave this way so that the proto-token could be turned into = an access token by the AS-RS. Isn't this what Justin is proposing? In = this design, the AS is the AS-RS and the agent is the AS-RO. By my = definition, this model has two ASs since both are processing requests = into tokens. The problem with this is complexity and privacy. The RO may = not want to share the request information with the AS-RS.

    Adrian

    On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Isn't that what the AS is supposed to be, only with the = caveat that the policy is defined locally? 

    Fabien 


    Le mer. 24 = mars 2021 =C3=A0 20:17, Alan Karp <alanhkarp@gmail.com> a =C3=A9crit :
    AS-RO is an AS that RO trusts to delegate RO's = access tokens according to RO's policies.  

    --------------
    Alan Karp


    On Wed, Mar 24, 2021 at 9:36 AM Fabien = Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan = and Adrian,

    I've = created issue AS-RO policy delegation (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to capture your input. 
    A first question = that arises: can we give a definition to AS-RO?

    Thanks
    Fabien

    On Tue, Mar = 23, 2021 at 4:15 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi = Alan, 

    Yes, but = in that flow, the token relationship between AS-RS and AS-RO is only = secure if the tokens issued by AS-RS are cryptographically attenuable in = the first place. 
     
    Attenuated delegation is a requirement, but that doesn't have = to be done cryptographically.  Token exchange works just = fine.  SPKI and zcap-ld are examples of the crypto approach, and we = used token exchange in the system for HP.

    --------------
    Alan = Karp


    On Tue, Mar = 23, 2021 at 4:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi = Alan, 

    Yes, but = in that flow, the token relationship between AS-RS and AS-RO is only = secure if the tokens issued by AS-RS are cryptographically attenuable in = the first place. 

    Fabien

    On Mon, Mar = 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin = Richer <jricher@mit.edu> wrote:

    But with all that in = mind, I think the key here is going to be looking at what the inputs to = the AS are, and how those can be defined in an interoperable way for = AS=E2=80=99s that can accept them. I think there=E2=80=99s a lot of room = for innovation and flexibility here that doesn=E2=80=99t break the trust = model or core use cases. If I have an AS-RS set that won=E2=80=99t = accept my favorite flavor of policy engine inputs, then I can decide not = to use that one. But this is a very different question than saying the = RS itself needs to accept my own AS =E2=80=94 and we can=E2=80=99t keep = conflating these two models.

    I agree.  The = point of having an AS-RO is to allow RO to specify a policy for which of = RO's access tokens should be delegated under what conditions.  = AS-RS should not need to understand those policies.  The flow would = be
    • RO contacts AS-RS = and gets one or more access tokens.
    • RO delegates one = or more of those tokens, potentially sub-scoped, to AS-RO.
    • A different user contacts AS-RO to get a potentially = sub-scoped access token from AS-RO.
    • That user = presents the access token delegated by AS-RO when invoking the = resource.
    AS-RS only = needs to verify that the delegation chain is legitimate, e.g., no = increase in scope, and that it grants permission for the request being = made.  AS-RS does not need to understand the policy behind granting = the delegation by AS-RO.

    --------------
    Alan Karp


    On Mon, Mar 22, 2021 at 11:40 AM Justin = Richer <jricher@mit.edu> wrote:
    Adrian,

    I think this shows the = problem with the terminology as it=E2=80=99s been applied in this = conversation, which I=E2=80=99ve tried to shine light on before. What = you and others are calling the =E2=80=9CRS=E2=80=9D is really the =E2=80=9C= AS and RS working together=E2=80=9D =E2=80=94 everything to the right of = the line. When Denis had brought up =E2=80=9Celiminating the AS=E2=80=9D = in another thread, what he=E2=80=99d really done is labeled everything = to the right of the line as the =E2=80=9CRS=E2=80=9D. Of course, the = irony here is that everything to the right of the line used all be = called the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80=9D in = the OAuth 1 days. As you say below, I don=E2=80=99t want the client to = have visibility on what happens on that side. 

    Note well: The Google+ = logo labeled =E2=80=9CIdP=E2=80=9D in the diagram is not the AS, as far = as GNAP is concerned. It does not issue an access token that the RS will = accept. The elements to the left of the line could be a lot of things, = but they are NOT the AS =E2=80=94 by definition. The client lives over = on the left, but so do any external inputs to the AS. These could be = policy inputs on behalf of the RO, they could be presentation artifacts, = they could be federated logins, they could be the output of policy = decisions. How the AS comes to trust those things is up to the AS=E2=80=99= s implementation. It=E2=80=99s something we can talk about, but = ultimately GNAP won=E2=80=99t be in any position to dictate because in = practice some AS=E2=80=99s are simply going to internalize all policies = and we will never successfully force those open. 

    But with all that in = mind, I think the key here is going to be looking at what the inputs to = the AS are, and how those can be defined in an interoperable way for = AS=E2=80=99s that can accept them. I think there=E2=80=99s a lot of room = for innovation and flexibility here that doesn=E2=80=99t break the trust = model or core use cases. If I have an AS-RS set that won=E2=80=99t = accept my favorite flavor of policy engine inputs, then I can decide not = to use that one. But this is a very different question than saying the = RS itself needs to accept my own AS =E2=80=94 and we can=E2=80=99t keep = conflating these two models.

    So to me, GNAP can support a Zero Trust = Architecture by LEVERAGING the AS, not by subsuming or eliminating it. = It is in fact the AS, not the client and not the RS, that will request = and consume the results of a privacy-preserving zero-trust policy query = thing. Anything that happens downstream from that is of little concern = to the zero-trust components because, as you point out, it=E2=80=99s on = the =E2=80=9Cother side=E2=80=9D of the line. 

    I think we got this = basic component model pretty right in OAuth: the AS and RS and client = working together. Where OAuth misses the mark is the assumption that the = user has to log in to the AS through a webpage and interact directly, = thereby proving they=E2=80=99re the RO. It=E2=80=99s this latter space = where I think we can both push innovation and also address the important = and compelling use cases like the ones you=E2=80=99re = bringing.

     =E2=80=94 Justin

    On Mar = 22, 2021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I'm sorry, Justin. As a Resource = Owner, I look at the RS trust boundary (the dotted line in the diagram) = as being the RS. I don't expect any visibility into what's going on on = the right. 

    My problem with the framing you propose is that requests are = going to the RS (or the AS-RS) and I don't want to share my policies = with the AS-RS. I want to keep the RS and AS-RS as ignorant as = possible.

    Adrian

    On Mon, Mar = 22, 2021 at 1:48 PM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    What you=E2=80=99re = discussing below, in terms of logging in to a site, is not approaching = the RS. You are in fact approaching the client, and identifying both the = AS and RS to the client. The client is a client of your = identity in this model, and the RS is part of the identity provider. = It=E2=80=99s really important that we don=E2=80=99t conflate the RS and = client in this way as it leads to a lot of confusion downstream and a = lot of broken trust boundaries.

    With that model in mind, approaching = the =E2=80=9CRS" and providing it your identity is really just a case of = the =E2=80=9Cfederated login to AS=E2=80=9D pattern that we discussed on = the WG call. The user here approaches an RS, which has its own AS. To = share things from this RS, the RO has to authenticate to the RS=E2=80=99s = AS. This particular AS allows the RO to do so using an external identity = =E2=80=94 in which case, the AS is now a =E2=80=9Cclient=E2=80=9D of a = separate, disconnected (but layered) delegation. The ultimate client = that eventually calls the RS down the way may or may not know about = these layers. 

    <PastedGraphic-1.png>
    This = same AS, which is closely tied to the RS and trusted by the RS, might = also take in FIDO credentials, or DIDs, or any number of other proof = mechanisms. The output of this is an access token the RS trusts, but the = input is up to the AS. The RS is not what you=E2=80=99re logging in = to.

     =E2=80= =94 Justin

    On Mar 22, 2021, at 1:28 PM, = Adrian Gropper <agropper@healthurl.com> = wrote:

    I = too am in favor of avoiding consolidation and correlation. Right now, = when I approach a service provider (RS) for the first time, I'm offered = the opportunity to identify my persona as: email, sign-in with Google, = Facebook, or Apple. I know there are people who try to create one-off = email addresses but that is mostly a waste of time. 

    So, along come FIDO2 and = DID wallets to the rescue. Now, in theory, I have a way to start out my = RS relationship pseudonymously. 

    When I want my resource to be = discovered or shared I will post that RS URL including my pseudonym. If = I then want to introduce a mediator in front of my AS or messaging = service endpoint, I have that option. If I want to keep requests = away from the mediator, I would publish an encryption key along with my = pseudonym.

    - = Adrian



    On Mon, Mar 22, 2021 at 9:55 AM Justin = Richer <jricher@mit.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, = Benjamin Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhkarp@gmail.com> shared a talk = about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#i= ssuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to = use authority
    >> as a core principle. I advocate for a GNAP design that = maximizes the power
    >> of the RO, to be seen as a human rights issue when the RO is a = human. This
    >> causes me to ask how to combine better security with better = human rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the = RO to
    >> partition limited authority across dozens of different ASs by = domain and
    >> function, then we are not using technology to empower the = individual.
    >> Probably the opposite, as we introduce consent fatigue and = burden normal
    >> people to partition their lives into non-overlapping = domains.
    >>
    >> My experience says we should aim for one AS per persona because = that maps
    >> into the way we manage our public and private identities. POLA = would then
    >> teach care in keeping ASs and RSs related to work / public = separate from
    >> ASs and RSs related to private life so that a policy = vulnerability in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to = GNAP
    > seems like a useful exercise.  I do want to point out some = potential
    > pitfalls with one-AS-per-persona that we can also be aware = of.  If
    > one-AS-per-persona becomes one-persona-per-AS as well, then the = AS's
    > identity in effect also serves as a persona identity and there are = privacy
    > considerations to that.  If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple = humans)
    > route is taken, we should consider whether that would lead to = various
    > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.  That topic is a current matter of = concern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in = the UMA working group, and it=E2=80=99s one of the biggest problems with = the personal AS (and personal data store) model. This kind of thing = makes RS-first trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that = wants to access my medical information. It calls an RS and requests = access, but it hasn=E2=80=99t been granted anything yet. Now I as the RO = have set up the RS so that it talks to my personal AS, that only I use. = In addition to the RS having to be able to figure out which medical = records are being requested from the context of the unauthenticated = request (which means it needs identifiers in the URL or something = similar for the RS to be able to tell, assuming that it protects data = for more than one person). So this client software doesn=E2=80=99t know = who I am and doesn=E2=80=99t know my medical record information, makes a = completely unauthorized request to the RS, and the RS says =E2=80=9CGo = to Justin=E2=80=99s personal AS to get a token=E2=80=9D. The client can = now make a direct correlation between the data that=E2=80=99s being = protected at the RS and the person running the AS that protects it. = Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This = is a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please = talk to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t = exposed anything at all. And from the perspective of both the patient = and the RS, this is more privacy-preserving, and it=E2=80=99s really the = least surprising option. Once the client gets to the AS, it can start a = negotiation of figuring out who the RO is for the information being = accessed.

    On top of this, the usability expectations of people managing their own = AS, or set of AS=E2=80=99s for multiple personas to keep things = separate, is a huge burden. Even in the tech community, I know people = who can=E2=80=99t reliably manage more than one email address for = different purposes. I wouldn=E2=80=99t expect my partner to do that =E2=80= =94 they have trouble enough balancing all the logins and sessions = required for different kids remote schooling, I couldn=E2=80=99t imagine = them having to understand all the requirements for managing multiple = authorization servers and associated policies. I also don=E2=80=99t = expect any person to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve = been on the internet for decades and I can barely keep tabs on my GPG = keys, and only use them when I am forced to. This is exactly the kind of = =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions above, = people will just want to outsource that to someone else, and the reality = will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice = only to end up with a world where the RS ends up making a limited choice = anyway. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99= s could allow arbitrary IdPs but they choose Google because it works and = that=E2=80=99s where the users are. (And that=E2=80=99s not to say = anything of the proprietary OIDC-like protocols, but that=E2=80=99s = another discussion).

    For further reading on these topics, I recommend both =E2=80=9CWhy = Johnny Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems = Fail=E2=80=9D.

    So what does this have to do with GNAP? I think we can be clear-eyed on = what kinds of expectations we have for the participants. If we expect = users (RO=E2=80=99s) to have to set up the AS-RS relationship, or expect = them to carry their AS, or manage their personal keys =E2=80=94 I think = we=E2=80=99ve lost the battle for relevance.

     =E2=80=94 Justin


    --
    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
    =


    = --Apple-Mail=_B80FD213-7A84-46D1-8E62-C87F8DE81DB5-- From nobody Thu Mar 25 10:18:36 2021 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 3C94E3A27FD for ; Thu, 25 Mar 2021 10:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 298ux8PCmX02 for ; Thu, 25 Mar 2021 10:18:27 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A99673A27F9 for ; Thu, 25 Mar 2021 10:18:25 -0700 (PDT) Received: from [192.168.1.11] ([90.79.53.231]) by mwinf5d28 with ME id khJM2400H4zJUWJ03hJMX3; Thu, 25 Mar 2021 18:18:23 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Thu, 25 Mar 2021 18:18:23 +0100 X-ME-IP: 90.79.53.231 To: Justin Richer Cc: GNAP Mailing List References: <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> <1d9d5bed-32ff-a864-85a5-a16ee6063802@free.fr> <4342181C-387A-4FBB-9D68-A1B0EBC93FD1@mit.edu> From: Denis Message-ID: Date: Thu, 25 Mar 2021 18:18:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <4342181C-387A-4FBB-9D68-A1B0EBC93FD1@mit.edu> Content-Type: multipart/alternative; boundary="------------947117DD9866359C1B7B5A54" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 17:18:34 -0000 This is a multi-part message in MIME format. --------------947117DD9866359C1B7B5A54 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Justin, Instead of replying this way, it would be much better that you cut and paste these two definitions (if ever they exist). Denis > Denis, > > These terms have been explained and defined several times in the > thread below, including in more specific detail in the first paragraph > of my message, quoted below. Much of the purpose of this thread has > been teasing out these very definitions. > >  — Justin > >> On Mar 25, 2021, at 11:34 AM, Denis > > wrote: >> >> Since there is still no definition to explain what mean the acronyms >> AS-RO and AS-RS, >> I have created my own terminology */RO-AS/* and */RO-RS/* and wrote a >> full story including >> the definitions of a RO-AS and RO-RS. See the issue #223 >> >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223 >> >> Denis >> >>> Thanks for the summary Justin. You very clearly articulated what I >>> would call the "regulatory capture" aspects of the problem. The RS >>> will do everything they can to avoid ceding power to the RO. By >>> avoiding standards that shift power to the RO, the platforms, IdP's, >>> and most other service providers delay regulation that would promote >>> agent-based delegated access to an API as a human right. >>> >>> It's only recently, with GDPR, that lawmakers have started to >>> consider human rights outside of healthcare and are now introducing >>> concepts such as the separation of controller from processor in >>> order to enable a new generation of regulation. My perspective on >>> GNAP is not arbitrary. It is honed by years of experience in >>> healthcare as everyone struggles with OAuth and OpenID Connect, >>> HEART, and now UDAP, to avoid doing in standards what seems obvious >>> from a human rights perspective. >>> >>> What's interesting is that the "regulatory capture" standards game >>> is now playing out in a new arena. The recent transition of DID to >>> W3C Candidate Recommendation, together with Verifiable Credentials >>> before that, means that every regulator (e.g. US Health and Human >>> Services, Scotland, EU...) and some legislatures (e.g. Wyoming) are >>> having to deal with the concept of Self-Sovereign Identity. It's not >>> fun for the community that has worked so hard on SSI to now have to >>> dance-around the actual impact of the SSI standards. >>> >>> With VC and DID, W3C seems to have broken through a "regulatory >>> capture" barrier and that community is moving on to standardize >>> protocols like DIDcomm and Encrypted Data Vaults that may avoid >>> delegated authorization as a human right. In my opinion, GNAP, and >>> IETF, is facing the same "regulatory capture" barrier. >>> >>> Justin says: "Of course, market forces being as they are, I might >>> not have much of an actionable choice in RS, but GNAP can’t change >>> that." What GNAP makes core can change the choices the market offers >>> by making GNAP an interoperability badge that stands for >>> Human-Centered Protocol. If GNAP moves the human-centered part to an >>> extension, then we're no better than another "profile" on top of OAuth. >>> >>> Adrian >>> >>> On Thu, Mar 25, 2021 at 8:46 AM Justin Richer >> > wrote: >>> >>> The way I’m thinking about Adrian’s use case is that what we’re >>> calling the “AS-RO” isn’t an “AS” in the traditional OAuth/GNAP >>> sense, at least not exactly. This is the agent that the RO can >>> use to set policies and manage consent on their behalf, and I’ve >>> been arguing that it fits better into this vaguely-defined >>> “interaction component” aspect of the current AS definition, and >>> it’s not currently separated from the AS definition. The “AS-RS” >>> maps to what we’d call the “AS” in OAuth/GNAP traditionally, >>> it’s what the RS trusts to issue tokens. In traditional OAuth >>> the AS-RO and AS-RS are always the same thing, from a functional >>> protocol perspective. An important point here is that from a >>> client’s perspective, they’re only talking to the AS-RS since >>> that’s where the client gets its tokens, because at the end of >>> the day the client just wants to call the API at the RS and >>> doesn’t care how that happens (from a protocol standpoint). >>> >>> Note well: Even thought I don’t believe that “AS-RO” is an >>> authorization server at all, I’m going to keep using that term >>> below for consistency with previous discussion. >>> >>> So we have these fundamental relationships around getting the >>> client to access the RS: >>> >>> 1. RS trusts AS-RS to issue tokens that RS will accept, >>> validate, and process for requests from client >>> 2. Client trusts AS-RS to issue tokens that client can use at RS >>> 3. RO trusts RS to protect RO’s api through delegated access >>> >>> On top of that, we’ve got some additional aspects that we’re >>> discussing: >>> >>> 4. RO trusts AS-RO to manage RO’s policies at runtime >>> 5. AS-RS trusts AS-RO to assert RO’s policies for access to RS >>> 6. Client trusts whatever AS-RS sends client to deal with, >>> including possibly RO-AS at runtime, because of (2) >>> >>> What I have been saying is that 4/5/6 are optional details of >>> how RS-AS runs things, and I think this also maps with Adrian’s >>> view of choice, since if my RS’s AS-RS doesn’t allow me to plug >>> in my own AS-RO then I would be motivated to pick a different RS >>> who’s AS-RS lets me do just that. The same way I’d pick a >>> different RS if their surrounding services didn’t accept my >>> preferred federation login and I didn’t want to make another >>> account. Of course, market forces being as they are, I might not >>> have much of an actionable choice in RS, but GNAP can’t change >>> that. >>> >>> What we can do is make it possible for AS-RS to talk to AS-RO, >>> both in philosophy of the protocol design and in concrete hooks >>> to support (6) above. >>> >>> Separately, we can approach the issue of making 1/2 above more >>> dynamic. This was UMA2’s “federated authorization” approach, and >>> is behind a lot of the “bring your own AS” models out there. The >>> problem with these is that we know from many years of experience >>> that most RS’s aren’t interested in doing anything of the sort. >>> >>> So with GNAP we can instead allow 4/5/6 to vary in a predictable >>> and consistent way, letting the RS keep control over 1/2, >>> thereby enabling choice in (3). We don’t have to be the ones who >>> define the all of the details of every permutation of (5) to >>> enable this, though. Some of this is going to be configuration >>> out of band, some of it’s going to be communication at runtime. >>> This is where VC’s, ZCAPs, CHAPI, DIDComm, FIDO, and a whole >>> swath of other tech can come in and help out. I don’t think we >>> need to put all the details for using these into core, nor do I >>> think we’ll pull of The Great And Ultimate Abstraction for using >>> these and other approaches. But we can at least start talking >>> about “AS-RS” in such a way that it no longer assumes it’s >>> always the same party dealing with the RO directly. >>> >>>  — Justin >>> >>>> On Mar 25, 2021, at 6:40 AM, Fabien Imbault >>>> > wrote: >>>> >>>> To reframe it closer to GNAP: >>>> - AS = AS-RO, that's where you find the RO policies. The AS >>>> issues access tokens to the client. >>>> - the RO policies could be a) defined locally or b) in >>>> relationship with the RS >>>> >>>> There have been several ideas related to the AS-RS relationship b: >>>> b1) the RS issues capabilities (which can be further attenuated >>>> by the RO) >>>> b2) Adrian also discussed a DID based solution >>>> b3) there was also an alternative ACL proposal from Denis (+ >>>> preflight) >>>> >>>> Fabien >>>> >>>> >>>> On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault >>>> > wrote: >>>> >>>> Ok so I get you correctly: >>>> - what matters is the RQ (could be a RO or a end-user or >>>> both : we don't really care at a high-level, they're all >>>> treated as entities that make a request) >>>> - the policy is able to handle those different cases, based >>>> on its own internal delegation protocol >>>> - currently that requires AS-RS and AS-RO, but maybe it can >>>> be simplified >>>> >>>> To answer to Denis, here's what I understood: >>>> - RO trusts AS-RS (and then handles its own policies within >>>> AS-RO) >>>> - end-user trusts AS-RO (through its client) >>>> >>>> Could probably work but that's a fairly different model >>>> compared to OAuth2 (and of today's GNAP), with different >>>> frontiers between the AS and the RS. >>>> >>>> Please do not hesitate to correct me if I'm wrong. >>>> >>>> Fabien >>>> >>>> On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper >>>> > wrote: >>>> >>>> I believe there are alternatives to having two kinds of >>>> ASs. The problem may be a side-effect of deciding to >>>> switch away form treating the RO as different from the >>>> RQ. That leads to downstream privacy issues. Our desire >>>> for architectural simplicity is admirable but that may >>>> have been a step too far. >>>> >>>> There may also be solutions based on different types of >>>> tokens, as in different capabilities (tokens signed by >>>> the RS) vs. tokens signed by the AS. I’m not sure about >>>> that but Alan might have more to say. >>>> >>>> Adrian >>>> >>>> On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault >>>> >>> > wrote: >>>> >>>> Thanks. The general problem statement is clear. >>>> >>>> The proposed solution a bit less (to me). I >>>> understood that from point 2, Alan involves 2 ASs. >>>> You said : "There’s no obvious reason to have two >>>> types of ASs". Do you see an alternative ? >>>> >>>> Regarding the last item, I don't think that naming >>>> RQ by end-user created the problem. It might just >>>> highlight the asymmetry, which fundamentally exists. >>>> >>>> Fabien >>>> >>>> >>>> On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper >>>> >>> > wrote: >>>> >>>> Recap: >>>> 1 - Justin (I think) introduced the idea of an >>>> AS on the RS trust boundary side. >>>> 2 - I said the RO should not have to share >>>> policies with the RS. >>>> 3 - Alan invented the concept of AS-RO and >>>> AS-RS to separate two kinds of PDPs. >>>> >>>> The thing is that step 2 is not symmetrical. >>>> The RO has a legitimate privacy interest in >>>> keeping their policies private and minimizing >>>> the leakage of information about requests that >>>> are posed against those policies. >>>> >>>> The RS, on the other hand, should be publishing >>>> its policies (e.g. what it’s selling or what >>>> jurisdiction it’s in or what tokens or scopes >>>> it supports). The RS has no obvious privacy >>>> interest in GNAP. It’s just an enforcer. >>>> >>>> There is one other privacy interest to consider >>>> around the RS and that is the requesting party >>>> (the end-user that is not the RO :-) might >>>> prefer to share attributes with the RS instead >>>> of the RO or something controlled by the RO. >>>> This case could be an “extension” to GNAP and >>>> might result in a split AS as a solution. This >>>> problem was introduced when the editors decided >>>> to replace RQ with end-user. Obviously, the RO >>>> end-user has no privacy interests relative to >>>> itself. >>>> >>>> Adrian >>>> >>>> >>>> >>>> >>>> On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault >>>> >>> > wrote: >>>> >>>> I was referring to "By my definition, this >>>> model has two ASs since both are processing >>>> requests into tokens". If there's no reason >>>> to have 2 types of ASs, that's fine then. >>>> But I'm a bit lost in where we stand with >>>> the idea. >>>> >>>> Could you recap? >>>> >>>> Fabien >>>> >>>> Le jeu. 25 mars 2021 à 08:16, Adrian >>>> Gropper >>> > a écrit : >>>> >>>> There’s no obvious reason to have two >>>> types of ASs. Any AS that is executing >>>> the policies of the RS can look to GNAP >>>> like the RS itself. Why would GNAP >>>> expose that interface to anyone? >>>> >>>> Adrian >>>> >>>> On Thu, Mar 25, 2021 at 3:11 AM Fabien >>>> Imbault >>> > wrote: >>>> >>>> Note : I'm not sure that's a good >>>> idea, but having 2 types of ASs is >>>> not that easy to grasp. >>>> >>>> Fabien >>>> >>>> Le jeu. 25 mars 2021 à 08:07, >>>> Fabien Imbault >>>> >>> > >>>> a écrit : >>>> >>>> The purpose of either handling >>>> policies locally or delegating >>>> them to the RO agent. >>>> >>>> Le jeu. 25 mars 2021 à 08:04, >>>> Adrian Gropper >>>> >>> > >>>> a écrit : >>>> >>>> What purpose would be >>>> served by GNAP splitting >>>> the AS into two components? >>>> >>>> Adrian >>>> >>>> On Thu, Mar 25, 2021 at >>>> 2:59 AM Fabien Imbault >>>> >>> > >>>> wrote: >>>> >>>> Isn't the AS-RO a >>>> component of the AS? >>>> Same idea as the >>>> interact component, it >>>> functionnally belongs >>>> to the AS role but >>>> could be deployed >>>> either as a monolith or >>>> as a separate component? >>>> >>>> Fabien >>>> >>>> Le jeu. 25 mars 2021 à >>>> 04:26, Adrian Gropper >>>> >>> > >>>> a écrit : >>>> >>>> Yes, but I would >>>> say it’s not the RO >>>> that wants the >>>> access token. It’s >>>> the RO that wants >>>> the client making >>>> the request to get >>>> an access token. >>>> >>>> Adrian >>>> >>>> On Wed, Mar 24, >>>> 2021 at 11:22 PM >>>> Alan Karp >>>> >>> > >>>> wrote: >>>> >>>> Adrian Gropper >>>> >>> > >>>> wrote: >>>> >>>> >>>> In this >>>> design, the >>>> AS is the >>>> AS-RS and >>>> the agent >>>> is the >>>> AS-RO. By >>>> my >>>> definition, >>>> this model >>>> has two ASs >>>> since both >>>> are >>>> processing >>>> requests >>>> into >>>> tokens. The >>>> problem >>>> with this >>>> is >>>> complexity >>>> and >>>> privacy. >>>> The RO may >>>> not want to >>>> share the >>>> request >>>> information >>>> with the AS-RS. >>>> >>>> >>>> More precisely, >>>> RO has no >>>> choice but to >>>> present the >>>> required >>>> information to >>>> AS-RS if RO >>>> wants an access >>>> token. However, >>>> RO does not >>>> want AS-RS to >>>> know the policy >>>> by which RO >>>> delegates >>>> tokens. That's >>>> why RO uses >>>> AS-RO for those >>>> delegations. >>>> >>>> -------------- >>>> Alan Karp >>>> >>>> >>>> On Wed, Mar 24, >>>> 2021 at 7:41 PM >>>> Adrian Gropper >>>> >>> > >>>> wrote: >>>> >>>> Thank you >>>> for >>>> creating >>>> the issue. >>>> My >>>> definition >>>> of AS is >>>> independent >>>> of AS-RO or >>>> AS-RS. >>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomment-806280421 >>>> >>>> I also >>>> agree with >>>> Alan's >>>> definition >>>> based on >>>> delegation. >>>> An AS-RS >>>> would be a >>>> delegate of >>>> the RS. >>>> >>>> Based on >>>> that, I see >>>> it as >>>> obvious that >>>> the policy >>>> has to be >>>> accessible >>>> (defined >>>> locally?) >>>> in order >>>> for it to >>>> be run as >>>> the code >>>> that turns >>>> a request >>>> into an >>>> access token. >>>> >>>> The only >>>> other >>>> possibility >>>> is that the >>>> request is >>>> packaged by >>>> the AS and >>>> sent >>>> elsewhere >>>> (an agent) >>>> for >>>> evaluation >>>> against >>>> policy and >>>> a >>>> proto-token >>>> returned. >>>> In that >>>> case the AS >>>> is acting >>>> as a proxy >>>> and the PDP >>>> is >>>> elsewhere. >>>> I can >>>> imagine >>>> that an >>>> AS-RS would >>>> behave this >>>> way so that >>>> the >>>> proto-token >>>> could be >>>> turned into >>>> an access >>>> token by >>>> the AS-RS. >>>> Isn't this >>>> what Justin >>>> is >>>> proposing? >>>> In this >>>> design, the >>>> AS is the >>>> AS-RS and >>>> the agent >>>> is the >>>> AS-RO. By >>>> my >>>> definition, >>>> this model >>>> has two ASs >>>> since both >>>> are >>>> processing >>>> requests >>>> into >>>> tokens. The >>>> problem >>>> with this >>>> is >>>> complexity >>>> and >>>> privacy. >>>> The RO may >>>> not want to >>>> share the >>>> request >>>> information >>>> with the AS-RS. >>>> >>>> Adrian >>>> >>>> On Wed, Mar >>>> 24, 2021 at >>>> 5:21 PM >>>> Fabien >>>> Imbault >>>> >>> > >>>> wrote: >>>> >>>> Isn't >>>> that >>>> what >>>> the AS >>>> is >>>> supposed >>>> to be, >>>> only >>>> with >>>> the >>>> caveat >>>> that >>>> the >>>> policy >>>> is >>>> defined >>>> locally? >>>> >>>> Fabien >>>> >>>> >>>> Le mer. >>>> 24 mars >>>> 2021 à >>>> 20:17, >>>> Alan >>>> Karp >>>> >>> > >>>> a écrit : >>>> >>>> AS-RO >>>> is >>>> an >>>> AS >>>> that >>>> RO >>>> trusts >>>> to >>>> delegate >>>> RO's >>>> access >>>> tokens >>>> according >>>> to >>>> RO's >>>> policies. >>>> >>>> >>>> -------------- >>>> Alan >>>> Karp >>>> >>>> >>>> On >>>> Wed, >>>> Mar >>>> 24, >>>> 2021 >>>> at >>>> 9:36 >>>> AM >>>> Fabien >>>> Imbault >>>> >>> > >>>> wrote: >>>> >>>> Hi >>>> Alan >>>> and >>>> Adrian, >>>> >>>> >>>> I've >>>> created >>>> issue >>>> AS-RO >>>> policy >>>> delegation >>>> (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223 >>>> ) >>>> to >>>> capture >>>> your >>>> input. >>>> >>>> A >>>> first >>>> question >>>> that >>>> arises: >>>> can >>>> we >>>> give >>>> a >>>> definition >>>> to >>>> AS-RO? >>>> >>>> Thanks >>>> Fabien >>>> >>>> On >>>> Tue, >>>> Mar >>>> 23, >>>> 2021 >>>> at >>>> 4:15 >>>> PM >>>> Alan >>>> Karp >>>> >>> > >>>> wrote: >>>> >>>> Fabien >>>> Imbault >>>> >>> > >>>> wrote: >>>> >>>> Hi >>>> Alan, >>>> >>>> >>>> Yes, >>>> but >>>> in >>>> that >>>> flow, >>>> the >>>> token >>>> relationship >>>> between >>>> AS-RS >>>> and >>>> AS-RO >>>> is >>>> only >>>> secure >>>> if >>>> the >>>> tokens >>>> issued >>>> by >>>> AS-RS >>>> are >>>> cryptographically >>>> attenuable >>>> in >>>> the >>>> first >>>> place. >>>> >>>> >>>> Attenuated >>>> delegation >>>> is >>>> a >>>> requirement, >>>> but >>>> that >>>> doesn't >>>> have >>>> to >>>> be >>>> done >>>> cryptographically. >>>> Token >>>> exchange >>>> works >>>> just >>>> fine.  >>>> SPKI >>>> and >>>> zcap-ld >>>> are >>>> examples >>>> of >>>> the >>>> crypto >>>> approach, >>>> and >>>> we >>>> used >>>> token >>>> exchange >>>> in >>>> the >>>> system >>>> for >>>> HP. >>>> >>>> -------------- >>>> Alan >>>> Karp >>>> >>>> >>>> On >>>> Tue, >>>> Mar >>>> 23, >>>> 2021 >>>> at >>>> 4:12 >>>> AM >>>> Fabien >>>> Imbault >>>> >>> > >>>> wrote: >>>> >>>> Hi >>>> Alan, >>>> >>>> >>>> Yes, >>>> but >>>> in >>>> that >>>> flow, >>>> the >>>> token >>>> relationship >>>> between >>>> AS-RS >>>> and >>>> AS-RO >>>> is >>>> only >>>> secure >>>> if >>>> the >>>> tokens >>>> issued >>>> by >>>> AS-RS >>>> are >>>> cryptographically >>>> attenuable >>>> in >>>> the >>>> first >>>> place. >>>> >>>> >>>> Fabien >>>> >>>> On >>>> Mon, >>>> Mar >>>> 22, >>>> 2021 >>>> at >>>> 9:26 >>>> PM >>>> Alan >>>> Karp >>>> >>> > >>>> wrote: >>>> >>>> Justin >>>> Richer >>>> >>> > >>>> wrote: >>>> >>>> >>>> But >>>> with >>>> all >>>> that >>>> in >>>> mind, >>>> I >>>> think >>>> the >>>> key >>>> here >>>> is >>>> going >>>> to >>>> be >>>> looking >>>> at >>>> what >>>> the >>>> inputs >>>> to >>>> the >>>> AS >>>> are, >>>> and >>>> how >>>> those >>>> can >>>> be >>>> defined >>>> in >>>> an >>>> interoperable >>>> way >>>> for >>>> AS’s >>>> that >>>> can >>>> accept >>>> them. >>>> I >>>> think >>>> there’s >>>> a >>>> lot >>>> of >>>> room >>>> for >>>> innovation >>>> and >>>> flexibility >>>> here >>>> that >>>> doesn’t >>>> break >>>> the >>>> trust >>>> model >>>> or >>>> core >>>> use >>>> cases. >>>> If >>>> I >>>> have >>>> an >>>> AS-RS >>>> set >>>> that >>>> won’t >>>> accept >>>> my >>>> favorite >>>> flavor >>>> of >>>> policy >>>> engine >>>> inputs, >>>> then >>>> I >>>> can >>>> decide >>>> not >>>> to >>>> use >>>> that >>>> one. >>>> But >>>> this >>>> is >>>> a >>>> very >>>> different >>>> question >>>> than >>>> saying >>>> the >>>> RS >>>> itself >>>> needs >>>> to >>>> accept >>>> my >>>> own >>>> AS >>>> — >>>> and >>>> we >>>> can’t >>>> keep >>>> conflating >>>> these >>>> two >>>> models. >>>> >>>> I >>>> agree.  >>>> The >>>> point >>>> of >>>> having >>>> an >>>> AS-RO >>>> is >>>> to >>>> allow >>>> RO >>>> to >>>> specify >>>> a >>>> policy >>>> for >>>> which >>>> of >>>> RO's >>>> access >>>> tokens >>>> should >>>> be >>>> delegated >>>> under >>>> what >>>> conditions. >>>> AS-RS >>>> should >>>> not >>>> need >>>> to >>>> understand >>>> those >>>> policies.  >>>> The >>>> flow >>>> would >>>> be >>>> >>>> * RO >>>> contacts >>>> AS-RS >>>> and >>>> gets >>>> one >>>> or >>>> more >>>> access >>>> tokens. >>>> * RO >>>> delegates >>>> one >>>> or >>>> more >>>> of >>>> those >>>> tokens, >>>> potentially >>>> sub-scoped, >>>> to >>>> AS-RO. >>>> * A >>>> different >>>> user >>>> contacts >>>> AS-RO >>>> to >>>> get >>>> a >>>> potentially >>>> sub-scoped >>>> access >>>> token >>>> from >>>> AS-RO. >>>> * That >>>> user >>>> presents >>>> the >>>> access >>>> token >>>> delegated >>>> by >>>> AS-RO >>>> when >>>> invoking >>>> the >>>> resource. >>>> >>>> AS-RS >>>> only >>>> needs >>>> to >>>> verify >>>> that >>>> the >>>> delegation >>>> chain >>>> is >>>> legitimate, >>>> e.g., >>>> no >>>> increase >>>> in >>>> scope, >>>> and >>>> that >>>> it >>>> grants >>>> permission >>>> for >>>> the >>>> request >>>> being >>>> made. >>>> AS-RS >>>> does >>>> not >>>> need >>>> to >>>> understand >>>> the >>>> policy >>>> behind >>>> granting >>>> the >>>> delegation >>>> by >>>> AS-RO. >>>> >>>> -------------- >>>> Alan >>>> Karp >>>> >>>> >>>> On >>>> Mon, >>>> Mar >>>> 22, >>>> 2021 >>>> at >>>> 11:40 >>>> AM >>>> Justin >>>> Richer >>>> >>> > >>>> wrote: >>>> >>>> Adrian, >>>> >>>> >>>> I >>>> think >>>> this >>>> shows >>>> the >>>> problem >>>> with >>>> the >>>> terminology >>>> as >>>> it’s >>>> been >>>> applied >>>> in >>>> this >>>> conversation, >>>> which >>>> I’ve >>>> tried >>>> to >>>> shine >>>> light >>>> on >>>> before. >>>> What >>>> you >>>> and >>>> others >>>> are >>>> calling >>>> the >>>> “RS” >>>> is >>>> really >>>> the >>>> “AS >>>> and >>>> RS >>>> working >>>> together” >>>> — >>>> everything >>>> to >>>> the >>>> right >>>> of >>>> the >>>> line. >>>> When >>>> Denis >>>> had >>>> brought >>>> up >>>> “eliminating >>>> the >>>> AS” >>>> in >>>> another >>>> thread, >>>> what >>>> he’d >>>> really >>>> done >>>> is >>>> labeled >>>> everything >>>> to >>>> the >>>> right >>>> of >>>> the >>>> line >>>> as >>>> the >>>> “RS”. >>>> Of >>>> course, >>>> the >>>> irony >>>> here >>>> is >>>> that >>>> everything >>>> to >>>> the >>>> right >>>> of >>>> the >>>> line >>>> used >>>> all >>>> be >>>> called >>>> the >>>> “AS” >>>> or >>>> simply >>>> “server” >>>> in >>>> the >>>> OAuth >>>> 1 >>>> days. >>>> As >>>> you >>>> say >>>> below, >>>> I >>>> don’t >>>> want >>>> the >>>> client >>>> to >>>> have >>>> visibility >>>> on >>>> what >>>> happens >>>> on >>>> that >>>> side. >>>> >>>> >>>> Note >>>> well: >>>> The >>>> Google+ >>>> logo >>>> labeled >>>> “IdP” >>>> in >>>> the >>>> diagram >>>> is >>>> not >>>> the >>>> AS, >>>> as >>>> far >>>> as >>>> GNAP >>>> is >>>> concerned. >>>> It >>>> does >>>> not >>>> issue >>>> an >>>> access >>>> token >>>> that >>>> the >>>> RS >>>> will >>>> accept. >>>> The >>>> elements >>>> to >>>> the >>>> left >>>> of >>>> the >>>> line >>>> could >>>> be >>>> a >>>> lot >>>> of >>>> things, >>>> but >>>> they >>>> are >>>> NOT >>>> the >>>> AS >>>> — >>>> by >>>> definition. >>>> The >>>> client >>>> lives >>>> over >>>> on >>>> the >>>> left, >>>> but >>>> so >>>> do >>>> any >>>> external >>>> inputs >>>> to >>>> the >>>> AS. >>>> These >>>> could >>>> be >>>> policy >>>> inputs >>>> on >>>> behalf >>>> of >>>> the >>>> RO, >>>> they >>>> could >>>> be >>>> presentation >>>> artifacts, >>>> they >>>> could >>>> be >>>> federated >>>> logins, >>>> they >>>> could >>>> be >>>> the >>>> output >>>> of >>>> policy >>>> decisions. >>>> How >>>> the >>>> AS >>>> comes >>>> to >>>> trust >>>> those >>>> things >>>> is >>>> up >>>> to >>>> the >>>> AS’s >>>> implementation. >>>> It’s >>>> something >>>> we >>>> can >>>> talk >>>> about, >>>> but >>>> ultimately >>>> GNAP >>>> won’t >>>> be >>>> in >>>> any >>>> position >>>> to >>>> dictate >>>> because >>>> in >>>> practice >>>> some >>>> AS’s >>>> are >>>> simply >>>> going >>>> to >>>> internalize >>>> all >>>> policies >>>> and >>>> we >>>> will >>>> never >>>> successfully >>>> force >>>> those >>>> open. >>>> >>>> >>>> But >>>> with >>>> all >>>> that >>>> in >>>> mind, >>>> I >>>> think >>>> the >>>> key >>>> here >>>> is >>>> going >>>> to >>>> be >>>> looking >>>> at >>>> what >>>> the >>>> inputs >>>> to >>>> the >>>> AS >>>> are, >>>> and >>>> how >>>> those >>>> can >>>> be >>>> defined >>>> in >>>> an >>>> interoperable >>>> way >>>> for >>>> AS’s >>>> that >>>> can >>>> accept >>>> them. >>>> I >>>> think >>>> there’s >>>> a >>>> lot >>>> of >>>> room >>>> for >>>> innovation >>>> and >>>> flexibility >>>> here >>>> that >>>> doesn’t >>>> break >>>> the >>>> trust >>>> model >>>> or >>>> core >>>> use >>>> cases. >>>> If >>>> I >>>> have >>>> an >>>> AS-RS >>>> set >>>> that >>>> won’t >>>> accept >>>> my >>>> favorite >>>> flavor >>>> of >>>> policy >>>> engine >>>> inputs, >>>> then >>>> I >>>> can >>>> decide >>>> not >>>> to >>>> use >>>> that >>>> one. >>>> But >>>> this >>>> is >>>> a >>>> very >>>> different >>>> question >>>> than >>>> saying >>>> the >>>> RS >>>> itself >>>> needs >>>> to >>>> accept >>>> my >>>> own >>>> AS >>>> — >>>> and >>>> we >>>> can’t >>>> keep >>>> conflating >>>> these >>>> two >>>> models. >>>> >>>> So >>>> to >>>> me, >>>> GNAP >>>> can >>>> support >>>> a >>>> Zero >>>> Trust >>>> Architecture >>>> by >>>> LEVERAGING >>>> the >>>> AS, >>>> not >>>> by >>>> subsuming >>>> or >>>> eliminating >>>> it. >>>> It >>>> is >>>> in >>>> fact >>>> the >>>> AS, >>>> not >>>> the >>>> client >>>> and >>>> not >>>> the >>>> RS, >>>> that >>>> will >>>> request >>>> and >>>> consume >>>> the >>>> results >>>> of >>>> a >>>> privacy-preserving >>>> zero-trust >>>> policy >>>> query >>>> thing. >>>> Anything >>>> that >>>> happens >>>> downstream >>>> from >>>> that >>>> is >>>> of >>>> little >>>> concern >>>> to >>>> the >>>> zero-trust >>>> components >>>> because, >>>> as >>>> you >>>> point >>>> out, >>>> it’s >>>> on >>>> the >>>> “other >>>> side” >>>> of >>>> the >>>> line. >>>> >>>> >>>> I >>>> think >>>> we >>>> got >>>> this >>>> basic >>>> component >>>> model >>>> pretty >>>> right >>>> in >>>> OAuth: >>>> the >>>> AS >>>> and >>>> RS >>>> and >>>> client >>>> working >>>> together. >>>> Where >>>> OAuth >>>> misses >>>> the >>>> mark >>>> is >>>> the >>>> assumption >>>> that >>>> the >>>> user >>>> has >>>> to >>>> log >>>> in >>>> to >>>> the >>>> AS >>>> through >>>> a >>>> webpage >>>> and >>>> interact >>>> directly, >>>> thereby >>>> proving >>>> they’re >>>> the >>>> RO. >>>> It’s >>>> this >>>> latter >>>> space >>>> where >>>> I >>>> think >>>> we >>>> can >>>> both >>>> push >>>> innovation >>>> and >>>> also >>>> address >>>> the >>>> important >>>> and >>>> compelling >>>> use >>>> cases >>>> like >>>> the >>>> ones >>>> you’re >>>> bringing. >>>> >>>>  — >>>> Justin >>>> >>>>> On >>>>> Mar >>>>> 22, >>>>> 2021, >>>>> at >>>>> 2:14 >>>>> PM, >>>>> Adrian >>>>> Gropper >>>>> >>>> > >>>>> wrote: >>>>> >>>>> I'm >>>>> sorry, >>>>> Justin. >>>>> As >>>>> a >>>>> Resource >>>>> Owner, >>>>> I >>>>> look >>>>> at >>>>> the >>>>> RS >>>>> trust >>>>> boundary >>>>> (the >>>>> dotted >>>>> line >>>>> in >>>>> the >>>>> diagram) >>>>> as >>>>> being >>>>> the >>>>> RS. >>>>> I >>>>> don't >>>>> expect >>>>> any >>>>> visibility >>>>> into >>>>> what's >>>>> going >>>>> on >>>>> on >>>>> the right. >>>>> >>>>> >>>>> My >>>>> problem >>>>> with >>>>> the >>>>> framing >>>>> you >>>>> propose >>>>> is >>>>> that >>>>> requests >>>>> are >>>>> going >>>>> to >>>>> the >>>>> RS >>>>> (or >>>>> the >>>>> AS-RS) >>>>> and >>>>> I >>>>> don't >>>>> want >>>>> to >>>>> share >>>>> my >>>>> policies >>>>> with >>>>> the >>>>> AS-RS. >>>>> I >>>>> want >>>>> to >>>>> keep >>>>> the >>>>> RS >>>>> and >>>>> AS-RS >>>>> as >>>>> ignorant >>>>> as >>>>> possible. >>>>> >>>>> Adrian >>>>> >>>>> On >>>>> Mon, >>>>> Mar >>>>> 22, >>>>> 2021 >>>>> at >>>>> 1:48 >>>>> PM >>>>> Justin >>>>> Richer >>>>> >>>> > >>>>> wrote: >>>>> >>>>> Adrian, >>>>> >>>>> >>>>> What >>>>> you’re >>>>> discussing >>>>> below, >>>>> in >>>>> terms >>>>> of >>>>> logging >>>>> in >>>>> to >>>>> a >>>>> site, >>>>> is >>>>> not >>>>> approaching >>>>> the >>>>> RS. >>>>> You >>>>> are >>>>> in >>>>> fact >>>>> approaching >>>>> the >>>>> client, >>>>> and >>>>> identifying >>>>> both >>>>> the >>>>> AS >>>>> and >>>>> RS >>>>> to >>>>> the >>>>> client. >>>>> The >>>>> client >>>>> is >>>>> a >>>>> client >>>>> /of >>>>> your >>>>> identity/ >>>>> in >>>>> this >>>>> model, >>>>> and >>>>> the >>>>> RS >>>>> is >>>>> part >>>>> of >>>>> the >>>>> identity >>>>> provider. >>>>> It’s >>>>> really >>>>> important >>>>> that >>>>> we >>>>> don’t >>>>> conflate >>>>> the >>>>> RS >>>>> and >>>>> client >>>>> in >>>>> this >>>>> way >>>>> as >>>>> it >>>>> leads >>>>> to >>>>> a >>>>> lot >>>>> of >>>>> confusion >>>>> downstream >>>>> and >>>>> a >>>>> lot >>>>> of >>>>> broken >>>>> trust >>>>> boundaries. >>>>> >>>>> With >>>>> that >>>>> model >>>>> in >>>>> mind, >>>>> approaching >>>>> the >>>>> “RS" >>>>> and >>>>> providing >>>>> it >>>>> your >>>>> identity >>>>> is >>>>> really >>>>> just >>>>> a >>>>> case >>>>> of >>>>> the >>>>> “federated >>>>> login >>>>> to >>>>> AS” >>>>> pattern >>>>> that >>>>> we >>>>> discussed >>>>> on >>>>> the >>>>> WG >>>>> call. >>>>> The >>>>> user >>>>> here >>>>> approaches >>>>> an >>>>> RS, >>>>> which >>>>> has >>>>> its >>>>> own >>>>> AS. >>>>> To >>>>> share >>>>> things >>>>> from >>>>> this >>>>> RS, >>>>> the >>>>> RO >>>>> has >>>>> to >>>>> authenticate >>>>> to >>>>> the >>>>> RS’s >>>>> AS. >>>>> This >>>>> particular >>>>> AS >>>>> allows >>>>> the >>>>> RO >>>>> to >>>>> do >>>>> so >>>>> using >>>>> an >>>>> external >>>>> identity >>>>> — >>>>> in >>>>> which >>>>> case, >>>>> the >>>>> AS >>>>> is >>>>> now >>>>> a >>>>> “client” >>>>> of >>>>> a >>>>> separate, >>>>> disconnected >>>>> (but >>>>> layered) >>>>> delegation. >>>>> The >>>>> ultimate >>>>> client >>>>> that >>>>> eventually >>>>> calls >>>>> the >>>>> RS >>>>> down >>>>> the >>>>> way >>>>> may >>>>> or >>>>> may >>>>> not >>>>> know >>>>> about >>>>> these >>>>> layers. >>>>> >>>>> >>>>> >>>>> This >>>>> same >>>>> AS, >>>>> which >>>>> is >>>>> closely >>>>> tied >>>>> to >>>>> the >>>>> RS >>>>> and >>>>> trusted >>>>> by >>>>> the >>>>> RS, >>>>> might >>>>> also >>>>> take >>>>> in >>>>> FIDO >>>>> credentials, >>>>> or >>>>> DIDs, >>>>> or >>>>> any >>>>> number >>>>> of >>>>> other >>>>> proof >>>>> mechanisms. >>>>> The >>>>> output >>>>> of >>>>> this >>>>> is >>>>> an >>>>> access >>>>> token >>>>> the >>>>> RS >>>>> trusts, >>>>> but >>>>> the >>>>> input >>>>> is >>>>> up >>>>> to >>>>> the >>>>> AS. >>>>> The >>>>> RS >>>>> is >>>>> not >>>>> what >>>>> you’re >>>>> logging >>>>> in >>>>> to. >>>>> >>>>>  — >>>>> Justin >>>>> >>>>>> On >>>>>> Mar >>>>>> 22, >>>>>> 2021, >>>>>> at >>>>>> 1:28 >>>>>> PM, >>>>>> Adrian >>>>>> Gropper >>>>>> >>>>> > >>>>>> wrote: >>>>>> >>>>>> I >>>>>> too >>>>>> am >>>>>> in >>>>>> favor >>>>>> of >>>>>> avoiding >>>>>> consolidation >>>>>> and >>>>>> correlation. >>>>>> Right >>>>>> now, >>>>>> when >>>>>> I >>>>>> approach >>>>>> a >>>>>> service >>>>>> provider >>>>>> (RS) >>>>>> for >>>>>> the >>>>>> first >>>>>> time, >>>>>> I'm >>>>>> offered >>>>>> the >>>>>> opportunity >>>>>> to >>>>>> identify >>>>>> my >>>>>> persona >>>>>> as: >>>>>> email, >>>>>> sign-in >>>>>> with >>>>>> Google, >>>>>> Facebook, >>>>>> or >>>>>> Apple. >>>>>> I >>>>>> know >>>>>> there >>>>>> are >>>>>> people >>>>>> who >>>>>> try >>>>>> to >>>>>> create >>>>>> one-off >>>>>> email >>>>>> addresses >>>>>> but >>>>>> that >>>>>> is >>>>>> mostly >>>>>> a >>>>>> waste >>>>>> of >>>>>> time. >>>>>> >>>>>> >>>>>> So, >>>>>> along >>>>>> come >>>>>> FIDO2 >>>>>> and >>>>>> DID >>>>>> wallets >>>>>> to >>>>>> the >>>>>> rescue. >>>>>> Now, >>>>>> in >>>>>> theory, >>>>>> I >>>>>> have >>>>>> a >>>>>> way >>>>>> to >>>>>> start >>>>>> out >>>>>> my >>>>>> RS >>>>>> relationship >>>>>> pseudonymously. >>>>>> >>>>>> >>>>>> When >>>>>> I >>>>>> want >>>>>> my >>>>>> resource >>>>>> to >>>>>> be >>>>>> discovered >>>>>> or >>>>>> shared >>>>>> I >>>>>> will >>>>>> post >>>>>> that >>>>>> RS >>>>>> URL >>>>>> including >>>>>> my >>>>>> pseudonym. >>>>>> If >>>>>> I >>>>>> then >>>>>> want >>>>>> to >>>>>> introduce >>>>>> a >>>>>> mediator in >>>>>> front >>>>>> of >>>>>> my >>>>>> AS >>>>>> or >>>>>> messaging >>>>>> service endpoint, >>>>>> I >>>>>> have >>>>>> that >>>>>> option. >>>>>> If >>>>>> I >>>>>> want >>>>>> to >>>>>> keep >>>>>> requests >>>>>> away >>>>>> from >>>>>> the >>>>>> mediator, >>>>>> I >>>>>> would >>>>>> publish >>>>>> an >>>>>> encryption >>>>>> key >>>>>> along >>>>>> with >>>>>> my >>>>>> pseudonym. >>>>>> >>>>>> - >>>>>> Adrian >>>>>> >>>>>> >>>>>> >>>>>> On >>>>>> Mon, >>>>>> Mar >>>>>> 22, >>>>>> 2021 >>>>>> at >>>>>> 9:55 >>>>>> AM >>>>>> Justin >>>>>> Richer >>>>>> >>>>> > >>>>>> wrote: >>>>>> >>>>>> On >>>>>> Mar >>>>>> 21, >>>>>> 2021, >>>>>> at >>>>>> 1:18 >>>>>> PM, >>>>>> Benjamin >>>>>> Kaduk >>>>>> >>>>> > >>>>>> wrote: >>>>>> > >>>>>> >>>>>> > >>>>>> On >>>>>> Sat, >>>>>> Mar >>>>>> 20, >>>>>> 2021 >>>>>> at >>>>>> 01:07:42AM >>>>>> -0400, >>>>>> Adrian >>>>>> Gropper >>>>>> wrote: >>>>>> >> >>>>>> @Alan >>>>>> Karp >>>>>> >>>>> > >>>>>> shared >>>>>> a >>>>>> talk >>>>>> about >>>>>> the >>>>>> Principle >>>>>> Of >>>>>> Least >>>>>> >> >>>>>> Authority >>>>>> (POLA) >>>>>> in >>>>>> a >>>>>> recent >>>>>> comment >>>>>> >> >>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-803099693 >>>>>> >>>>>> >> >>>>>> I >>>>>> recommend >>>>>> it. >>>>>> >> >>>>>> >>>>>> >> >>>>>> We >>>>>> might >>>>>> expect >>>>>> a >>>>>> protocol >>>>>> with >>>>>> authorization >>>>>> in >>>>>> the >>>>>> title >>>>>> to >>>>>> use >>>>>> authority >>>>>> >> >>>>>> as >>>>>> a >>>>>> core >>>>>> principle. >>>>>> I >>>>>> advocate >>>>>> for >>>>>> a >>>>>> GNAP >>>>>> design >>>>>> that >>>>>> maximizes >>>>>> the >>>>>> power >>>>>> >> >>>>>> of >>>>>> the >>>>>> RO, >>>>>> to >>>>>> be >>>>>> seen >>>>>> as >>>>>> a >>>>>> human >>>>>> rights >>>>>> issue >>>>>> when >>>>>> the >>>>>> RO >>>>>> is >>>>>> a >>>>>> human. >>>>>> This >>>>>> >> >>>>>> causes >>>>>> me >>>>>> to >>>>>> ask >>>>>> how >>>>>> to >>>>>> combine >>>>>> better >>>>>> security >>>>>> with >>>>>> better >>>>>> human >>>>>> rights >>>>>> in >>>>>> >> >>>>>> GNAP. >>>>>> >> >>>>>> >>>>>> >> >>>>>> Who >>>>>> should >>>>>> have >>>>>> the >>>>>> least >>>>>> authority >>>>>> in >>>>>> the >>>>>> GNAP >>>>>> design? >>>>>> >> >>>>>> >>>>>> >> >>>>>> The >>>>>> AS >>>>>> derives >>>>>> authority >>>>>> as >>>>>> a >>>>>> delegate >>>>>> of >>>>>> the >>>>>> RO. >>>>>> If >>>>>> we >>>>>> ask >>>>>> the >>>>>> RO >>>>>> to >>>>>> >> >>>>>> partition >>>>>> limited >>>>>> authority >>>>>> across >>>>>> dozens >>>>>> of >>>>>> different >>>>>> ASs >>>>>> by >>>>>> domain >>>>>> and >>>>>> >> >>>>>> function, >>>>>> then >>>>>> we >>>>>> are >>>>>> not >>>>>> using >>>>>> technology >>>>>> to >>>>>> empower >>>>>> the >>>>>> individual. >>>>>> >> >>>>>> Probably >>>>>> the >>>>>> opposite, >>>>>> as >>>>>> we >>>>>> introduce >>>>>> consent >>>>>> fatigue >>>>>> and >>>>>> burden >>>>>> normal >>>>>> >> >>>>>> people >>>>>> to >>>>>> partition >>>>>> their >>>>>> lives >>>>>> into >>>>>> non-overlapping >>>>>> domains. >>>>>> >> >>>>>> >>>>>> >> >>>>>> My >>>>>> experience >>>>>> says >>>>>> we >>>>>> should >>>>>> aim >>>>>> for >>>>>> one >>>>>> AS >>>>>> per >>>>>> persona >>>>>> because >>>>>> that >>>>>> maps >>>>>> >> >>>>>> into >>>>>> the >>>>>> way >>>>>> we >>>>>> manage >>>>>> our >>>>>> public >>>>>> and >>>>>> private >>>>>> identities. >>>>>> POLA >>>>>> would >>>>>> then >>>>>> >> >>>>>> teach >>>>>> care >>>>>> in >>>>>> keeping >>>>>> ASs >>>>>> and >>>>>> RSs >>>>>> related >>>>>> to >>>>>> work >>>>>> / >>>>>> public >>>>>> separate >>>>>> from >>>>>> >> >>>>>> ASs >>>>>> and >>>>>> RSs >>>>>> related >>>>>> to >>>>>> private >>>>>> life >>>>>> so >>>>>> that >>>>>> a >>>>>> policy >>>>>> vulnerability >>>>>> in >>>>>> our >>>>>> >> >>>>>> delegation >>>>>> to >>>>>> an >>>>>> AS >>>>>> would >>>>>> have >>>>>> the >>>>>> least >>>>>> likelihood >>>>>> of >>>>>> harm. >>>>>> > >>>>>> >>>>>> > >>>>>> Thinking >>>>>> about >>>>>> how >>>>>> least >>>>>> authority/least >>>>>> privilege >>>>>> would >>>>>> apply >>>>>> to >>>>>> GNAP >>>>>> > >>>>>> seems >>>>>> like >>>>>> a >>>>>> useful >>>>>> exercise.  >>>>>> I >>>>>> do >>>>>> want >>>>>> to >>>>>> point >>>>>> out >>>>>> some >>>>>> potential >>>>>> > >>>>>> pitfalls >>>>>> with >>>>>> one-AS-per-persona >>>>>> that >>>>>> we >>>>>> can >>>>>> also >>>>>> be >>>>>> aware >>>>>> of.  >>>>>> If >>>>>> > >>>>>> one-AS-per-persona >>>>>> becomes >>>>>> one-persona-per-AS >>>>>> as >>>>>> well, >>>>>> then >>>>>> the >>>>>> AS's >>>>>> > >>>>>> identity >>>>>> in >>>>>> effect >>>>>> also >>>>>> serves >>>>>> as >>>>>> a >>>>>> persona >>>>>> identity >>>>>> and >>>>>> there >>>>>> are >>>>>> privacy >>>>>> > >>>>>> considerations >>>>>> to >>>>>> that.  >>>>>> If, >>>>>> on >>>>>> the >>>>>> other >>>>>> hand, >>>>>> the >>>>>> > >>>>>> multiple-personas-per-AS >>>>>> (presumably >>>>>> corresponding >>>>>> to >>>>>> multiple >>>>>> humans) >>>>>> > >>>>>> route >>>>>> is >>>>>> taken, >>>>>> we >>>>>> should >>>>>> consider >>>>>> whether >>>>>> that >>>>>> would >>>>>> lead >>>>>> to >>>>>> various >>>>>> > >>>>>> (e.g., >>>>>> market) >>>>>> forces >>>>>> driving >>>>>> consolidation >>>>>> to >>>>>> just >>>>>> a >>>>>> handful >>>>>> of >>>>>> > >>>>>> super-popular >>>>>> AS >>>>>> services. >>>>>> That >>>>>> topic >>>>>> is >>>>>> a >>>>>> current >>>>>> matter >>>>>> of >>>>>> concern >>>>>> to >>>>>> > >>>>>> some >>>>>> IETF >>>>>> participants. >>>>>> > >>>>>> >>>>>> >>>>>> Hi >>>>>> Ben, >>>>>> big >>>>>> +1 >>>>>> to >>>>>> this. >>>>>> This >>>>>> is >>>>>> something >>>>>> that >>>>>> we >>>>>> discussed >>>>>> ages >>>>>> ago >>>>>> in >>>>>> the >>>>>> UMA >>>>>> working >>>>>> group, >>>>>> and >>>>>> it’s >>>>>> one >>>>>> of >>>>>> the >>>>>> biggest >>>>>> problems >>>>>> with >>>>>> the >>>>>> personal >>>>>> AS >>>>>> (and >>>>>> personal >>>>>> data >>>>>> store) >>>>>> model. >>>>>> This >>>>>> kind >>>>>> of >>>>>> thing >>>>>> makes >>>>>> RS-first >>>>>> trust >>>>>> models >>>>>> really >>>>>> difficult >>>>>> in >>>>>> practice. >>>>>> >>>>>> As >>>>>> a >>>>>> strawman, >>>>>> let’s >>>>>> say >>>>>> that >>>>>> I’ve >>>>>> got >>>>>> software >>>>>> that >>>>>> wants >>>>>> to >>>>>> access >>>>>> my >>>>>> medical >>>>>> information. >>>>>> It >>>>>> calls >>>>>> an >>>>>> RS >>>>>> and >>>>>> requests >>>>>> access, >>>>>> but >>>>>> it >>>>>> hasn’t >>>>>> been >>>>>> granted >>>>>> anything >>>>>> yet. >>>>>> Now >>>>>> I >>>>>> as >>>>>> the >>>>>> RO >>>>>> have >>>>>> set >>>>>> up >>>>>> the >>>>>> RS >>>>>> so >>>>>> that >>>>>> it >>>>>> talks >>>>>> to >>>>>> my >>>>>> personal >>>>>> AS, >>>>>> that >>>>>> only >>>>>> I >>>>>> use. >>>>>> In >>>>>> addition >>>>>> to >>>>>> the >>>>>> RS >>>>>> having >>>>>> to >>>>>> be >>>>>> able >>>>>> to >>>>>> figure >>>>>> out >>>>>> which >>>>>> medical >>>>>> records >>>>>> are >>>>>> being >>>>>> requested >>>>>> from >>>>>> the >>>>>> context >>>>>> of >>>>>> the >>>>>> unauthenticated >>>>>> request >>>>>> (which >>>>>> means >>>>>> it >>>>>> needs >>>>>> identifiers >>>>>> in >>>>>> the >>>>>> URL >>>>>> or >>>>>> something >>>>>> similar >>>>>> for >>>>>> the >>>>>> RS >>>>>> to >>>>>> be >>>>>> able >>>>>> to >>>>>> tell, >>>>>> assuming >>>>>> that >>>>>> it >>>>>> protects >>>>>> data >>>>>> for >>>>>> more >>>>>> than >>>>>> one >>>>>> person). >>>>>> So >>>>>> this >>>>>> client >>>>>> software >>>>>> doesn’t >>>>>> know >>>>>> who >>>>>> I >>>>>> am >>>>>> and >>>>>> doesn’t >>>>>> know >>>>>> my >>>>>> medical >>>>>> record >>>>>> information, >>>>>> makes >>>>>> a >>>>>> completely >>>>>> unauthorized >>>>>> request >>>>>> to >>>>>> the >>>>>> RS, >>>>>> and >>>>>> the >>>>>> RS >>>>>> says >>>>>> “Go >>>>>> to >>>>>> Justin’s >>>>>> personal >>>>>> AS >>>>>> to >>>>>> get >>>>>> a >>>>>> token”. >>>>>> The >>>>>> client >>>>>> can >>>>>> now >>>>>> make >>>>>> a >>>>>> direct >>>>>> correlation >>>>>> between >>>>>> the >>>>>> data >>>>>> that’s >>>>>> being >>>>>> protected >>>>>> at >>>>>> the >>>>>> RS >>>>>> and >>>>>> the >>>>>> person >>>>>> running >>>>>> the >>>>>> AS >>>>>> that >>>>>> protects >>>>>> it. >>>>>> Importantly, >>>>>> this >>>>>> client >>>>>> makes >>>>>> this >>>>>> call >>>>>> with >>>>>> no >>>>>> prior >>>>>> relationship >>>>>> to >>>>>> the >>>>>> RS >>>>>> and >>>>>> no >>>>>> really >>>>>> auditable >>>>>> way >>>>>> to >>>>>> track >>>>>> it >>>>>> down >>>>>> after >>>>>> the >>>>>> fact. >>>>>> This >>>>>> is >>>>>> a >>>>>> design >>>>>> feature >>>>>> in >>>>>> the >>>>>> good >>>>>> case, >>>>>> and >>>>>> terrifying >>>>>> in >>>>>> the >>>>>> bad >>>>>> case. >>>>>> >>>>>> If >>>>>> the >>>>>> RS >>>>>> instead >>>>>> says >>>>>> “welcome >>>>>> to >>>>>> Medicine >>>>>> Doctor >>>>>> RS, >>>>>> please >>>>>> talk >>>>>> to >>>>>> the >>>>>> Medicine >>>>>> Doctor >>>>>> AS >>>>>> to >>>>>> get >>>>>> access”, >>>>>> we >>>>>> haven’t >>>>>> exposed >>>>>> anything >>>>>> at >>>>>> all. >>>>>> And >>>>>> from >>>>>> the >>>>>> perspective >>>>>> of >>>>>> both >>>>>> the >>>>>> patient >>>>>> and >>>>>> the >>>>>> RS, >>>>>> this >>>>>> is >>>>>> more >>>>>> privacy-preserving, >>>>>> and >>>>>> it’s >>>>>> really >>>>>> the >>>>>> least >>>>>> surprising >>>>>> option. >>>>>> Once >>>>>> the >>>>>> client >>>>>> gets >>>>>> to >>>>>> the >>>>>> AS, >>>>>> it >>>>>> can >>>>>> start >>>>>> a >>>>>> negotiation >>>>>> of >>>>>> figuring >>>>>> out >>>>>> who >>>>>> the >>>>>> RO >>>>>> is >>>>>> for >>>>>> the >>>>>> information >>>>>> being >>>>>> accessed. >>>>>> >>>>>> On >>>>>> top >>>>>> of >>>>>> this, >>>>>> the >>>>>> usability >>>>>> expectations >>>>>> of >>>>>> people >>>>>> managing >>>>>> their >>>>>> own >>>>>> AS, >>>>>> or >>>>>> set >>>>>> of >>>>>> AS’s >>>>>> for >>>>>> multiple >>>>>> personas >>>>>> to >>>>>> keep >>>>>> things >>>>>> separate, >>>>>> is >>>>>> a >>>>>> huge >>>>>> burden. >>>>>> Even >>>>>> in >>>>>> the >>>>>> tech >>>>>> community, >>>>>> I >>>>>> know >>>>>> people >>>>>> who >>>>>> can’t >>>>>> reliably >>>>>> manage >>>>>> more >>>>>> than >>>>>> one >>>>>> email >>>>>> address >>>>>> for >>>>>> different >>>>>> purposes. >>>>>> I >>>>>> wouldn’t >>>>>> expect >>>>>> my >>>>>> partner >>>>>> to >>>>>> do >>>>>> that >>>>>> — >>>>>> they >>>>>> have >>>>>> trouble >>>>>> enough >>>>>> balancing >>>>>> all >>>>>> the >>>>>> logins >>>>>> and >>>>>> sessions >>>>>> required >>>>>> for >>>>>> different >>>>>> kids >>>>>> remote >>>>>> schooling, >>>>>> I >>>>>> couldn’t >>>>>> imagine >>>>>> them >>>>>> having >>>>>> to >>>>>> understand >>>>>> all >>>>>> the >>>>>> requirements >>>>>> for >>>>>> managing >>>>>> multiple >>>>>> authorization >>>>>> servers >>>>>> and >>>>>> associated >>>>>> policies. >>>>>> I >>>>>> also >>>>>> don’t >>>>>> expect >>>>>> any >>>>>> person >>>>>> to >>>>>> “manage >>>>>> keys” >>>>>> — >>>>>> I’ve >>>>>> been >>>>>> on >>>>>> the >>>>>> internet >>>>>> for >>>>>> decades >>>>>> and >>>>>> I >>>>>> can >>>>>> barely >>>>>> keep >>>>>> tabs >>>>>> on >>>>>> my >>>>>> GPG >>>>>> keys, >>>>>> and >>>>>> only >>>>>> use >>>>>> them >>>>>> when >>>>>> I >>>>>> am >>>>>> forced >>>>>> to. >>>>>> This >>>>>> is >>>>>> exactly >>>>>> the >>>>>> kind >>>>>> of >>>>>> “market >>>>>> pressure” >>>>>> that >>>>>> I >>>>>> think >>>>>> Ben >>>>>> mentions >>>>>> above, >>>>>> people >>>>>> will >>>>>> just >>>>>> want >>>>>> to >>>>>> outsource >>>>>> that >>>>>> to >>>>>> someone >>>>>> else, >>>>>> and >>>>>> the >>>>>> reality >>>>>> will >>>>>> be >>>>>> a >>>>>> few >>>>>> popular >>>>>> providers. >>>>>> >>>>>> In >>>>>> which >>>>>> case, >>>>>> we >>>>>> could >>>>>> end >>>>>> up >>>>>> doing >>>>>> a >>>>>> ton >>>>>> of >>>>>> work >>>>>> to >>>>>> allow >>>>>> an >>>>>> RS >>>>>> choice >>>>>> only >>>>>> to >>>>>> end >>>>>> up >>>>>> with >>>>>> a >>>>>> world >>>>>> where >>>>>> the >>>>>> RS >>>>>> ends >>>>>> up >>>>>> making >>>>>> a >>>>>> limited >>>>>> choice >>>>>> anyway. >>>>>> We >>>>>> see >>>>>> how >>>>>> that >>>>>> plays >>>>>> out >>>>>> with >>>>>> OpenID >>>>>> Connect >>>>>> — >>>>>> RP’s >>>>>> could >>>>>> allow >>>>>> arbitrary >>>>>> IdPs >>>>>> but >>>>>> they >>>>>> choose >>>>>> Google >>>>>> because >>>>>> it >>>>>> works >>>>>> and >>>>>> that’s >>>>>> where >>>>>> the >>>>>> users >>>>>> are. >>>>>> (And >>>>>> that’s >>>>>> not >>>>>> to >>>>>> say >>>>>> anything >>>>>> of >>>>>> the >>>>>> proprietary >>>>>> OIDC-like >>>>>> protocols, >>>>>> but >>>>>> that’s >>>>>> another >>>>>> discussion). >>>>>> >>>>>> For >>>>>> further >>>>>> reading >>>>>> on >>>>>> these >>>>>> topics, >>>>>> I >>>>>> recommend >>>>>> both >>>>>> “Why >>>>>> Johnny >>>>>> Can’t >>>>>> Encrypt” >>>>>> and >>>>>> “Why >>>>>> CSCW >>>>>> Systems >>>>>> Fail”. >>>>>> >>>>>> So >>>>>> what >>>>>> does >>>>>> this >>>>>> have >>>>>> to >>>>>> do >>>>>> with >>>>>> GNAP? >>>>>> I >>>>>> think >>>>>> we >>>>>> can >>>>>> be >>>>>> clear-eyed >>>>>> on >>>>>> what >>>>>> kinds >>>>>> of >>>>>> expectations >>>>>> we >>>>>> have >>>>>> for >>>>>> the >>>>>> participants. >>>>>> If >>>>>> we >>>>>> expect >>>>>> users >>>>>> (RO’s) >>>>>> to >>>>>> have >>>>>> to >>>>>> set >>>>>> up >>>>>> the >>>>>> AS-RS >>>>>> relationship, >>>>>> or >>>>>> expect >>>>>> them >>>>>> to >>>>>> carry >>>>>> their >>>>>> AS, >>>>>> or >>>>>> manage >>>>>> their >>>>>> personal >>>>>> keys >>>>>> — >>>>>> I >>>>>> think >>>>>> we’ve >>>>>> lost >>>>>> the >>>>>> battle >>>>>> for >>>>>> relevance. >>>>>> >>>>>>  — >>>>>> Justin >>>>>> >>>>> >>>> >>>> -- >>>> >>>> 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 >>>> >>>> >>> >>> >> > --------------947117DD9866359C1B7B5A54 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
    Justin,

    Instead of replying this way, it would be much better that you cut and paste these two definitions (if ever they exist).

    Denis

    Denis,

    These terms have been explained and defined several times in the thread below, including in more specific detail in the first paragraph of my message, quoted below. Much of the purpose of this thread has been teasing out these very definitions. 

     — Justin

    On Mar 25, 2021, at 11:34 AM, Denis <denis.ietf@free.fr> wrote:

    Since there is still no definition to explain what mean the acronyms AS-RO and AS-RS,
    I have created my own terminology RO-AS and RO-RS and wrote a full story including
    the definitions of a RO-AS and RO-RS. See the issue #223

    https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223

    Denis

    Thanks for the summary Justin. You very clearly articulated what I would call the "regulatory capture" aspects of the problem. The RS will do everything they can to avoid ceding power to the RO. By avoiding standards that shift power to the RO, the platforms, IdP's, and most other service providers delay regulation that would promote agent-based delegated access to an API as a human right. 

    It's only recently, with GDPR, that lawmakers have started to consider human rights outside of healthcare and are now introducing concepts such as the separation of controller from processor in order to enable a new generation of regulation. My perspective on GNAP is not arbitrary. It is honed by years of experience in healthcare as everyone struggles with OAuth and OpenID Connect, HEART, and now UDAP, to avoid doing in standards what seems obvious from a human rights perspective.

    What's interesting is that the "regulatory capture" standards game is now playing out in a new arena. The recent transition of DID to W3C Candidate Recommendation, together with Verifiable Credentials before that, means that every regulator (e.g. US Health and Human Services, Scotland, EU...) and some legislatures (e.g. Wyoming) are having to deal with the concept of Self-Sovereign Identity. It's not fun for the community that has worked so hard on SSI to now have to dance-around the actual impact of the SSI standards.

    With VC and DID, W3C seems to have broken through a "regulatory capture" barrier and that community is moving on to standardize protocols like DIDcomm and Encrypted Data Vaults that may avoid delegated authorization as a human right. In my opinion, GNAP, and IETF, is facing the same "regulatory capture" barrier. 

    Justin says: "Of course, market forces being as they are, I might not have much of an actionable choice in RS, but GNAP can’t change that." What GNAP makes core can change the choices the market offers by making GNAP an interoperability badge that stands for Human-Centered Protocol. If GNAP moves the human-centered part to an extension, then we're no better than another "profile" on top of OAuth.

    Adrian

    On Thu, Mar 25, 2021 at 8:46 AM Justin Richer <jricher@mit.edu> wrote:
    The way I’m thinking about Adrian’s use case is that what we’re calling the “AS-RO” isn’t an “AS” in the traditional OAuth/GNAP sense, at least not exactly. This is the agent that the RO can use to set policies and manage consent on their behalf, and I’ve been arguing that it fits better into this vaguely-defined “interaction component” aspect of the current AS definition, and it’s not currently separated from the AS definition. The “AS-RS” maps to what we’d call the “AS” in OAuth/GNAP traditionally, it’s what the RS trusts to issue tokens. In traditional OAuth the AS-RO and AS-RS are always the same thing, from a functional protocol perspective. An important point here is that from a client’s perspective, they’re only talking to the AS-RS since that’s where the client gets its tokens, because at the end of the day the client just wants to call the API at the RS and doesn’t care how that happens (from a protocol standpoint). 

    Note well: Even thought I don’t believe that “AS-RO” is an authorization server at all, I’m going to keep using that term below for consistency with previous discussion.

    So we have these fundamental relationships around getting the client to access the RS:

    1. RS trusts AS-RS to issue tokens that RS will accept, validate, and process for requests from client
    2. Client trusts AS-RS to issue tokens that client can use at RS
    3. RO trusts RS to protect RO’s api through delegated access

    On top of that, we’ve got some additional aspects that we’re discussing:

    4. RO trusts AS-RO to manage RO’s policies at runtime
    5. AS-RS trusts AS-RO to assert RO’s policies for access to RS
    6. Client trusts whatever AS-RS sends client to deal with, including possibly RO-AS at runtime, because of (2)

    What I have been saying is that 4/5/6 are optional details of how RS-AS runs things, and I think this also maps with Adrian’s view of choice, since if my RS’s AS-RS doesn’t allow me to plug in my own AS-RO then I would be motivated to pick a different RS who’s AS-RS lets me do just that. The same way I’d pick a different RS if their surrounding services didn’t accept my preferred federation login and I didn’t want to make another account. Of course, market forces being as they are, I might not have much of an actionable choice in RS, but GNAP can’t change that. 

    What we can do is make it possible for AS-RS to talk to AS-RO, both in philosophy of the protocol design and in concrete hooks to support (6) above. 

    Separately, we can approach the issue of making 1/2 above more dynamic. This was UMA2’s “federated authorization” approach, and is behind a lot of the “bring your own AS” models out there. The problem with these is that we know from many years of experience that most RS’s aren’t interested in doing anything of the sort.

    So with GNAP we can instead allow 4/5/6 to vary in a predictable and consistent way, letting the RS keep control over 1/2, thereby enabling choice in (3). We don’t have to be the ones who define the all of the details of every permutation of (5) to enable this, though. Some of this is going to be configuration out of band, some of it’s going to be communication at runtime. This is where VC’s, ZCAPs, CHAPI, DIDComm, FIDO, and a whole swath of other tech can come in and help out. I don’t think we need to put all the details for using these into core, nor do I think we’ll pull of The Great And Ultimate Abstraction for using these and other approaches. But we can at least start talking about “AS-RS” in such a way that it no longer assumes it’s always the same party dealing with the RO directly.

     — Justin

    On Mar 25, 2021, at 6:40 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    To reframe it closer to GNAP:
    - AS = AS-RO, that's where you find the RO policies. The AS issues access tokens to the client.
    - the RO policies could be a) defined locally or b) in relationship with the RS

    There have been several ideas related to the AS-RS relationship b:
    b1) the RS issues capabilities (which can be further attenuated by the RO)
    b2) Adrian also discussed a DID based solution
    b3) there was also an alternative ACL proposal from Denis (+ preflight)

    Fabien


    On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Ok so I get you correctly: 
    - what matters is the RQ (could be a RO or a end-user or both : we don't really care at a high-level, they're all treated as entities that make a request)
    - the policy is able to handle those different cases, based on its own internal delegation protocol
    - currently that requires AS-RS and AS-RO, but maybe it can be simplified

    To answer to Denis, here's what I understood:
    - RO trusts AS-RS (and then handles its own policies within AS-RO)
    - end-user trusts AS-RO (through its client)

    Could probably work but that's a fairly different model compared to OAuth2 (and of today's GNAP), with different frontiers between the AS and the RS. 

    Please do not hesitate to correct me if I'm wrong.

    Fabien 

    On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper <agropper@healthurl.com> wrote:
    I believe there are alternatives to having two kinds of ASs. The problem may be a side-effect of deciding to switch away form treating the RO as different from the RQ. That leads to downstream privacy issues. Our desire for architectural simplicity is admirable but that may have been a step too far.

    There may also be solutions based on different types of tokens, as in different capabilities (tokens signed by the RS) vs. tokens signed by the AS. I’m not sure about that but Alan might have more to say.

    Adrian

    On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks. The general problem statement is clear.

    The proposed solution a bit less (to me). I understood that from point 2, Alan involves 2 ASs. You said : "There’s no obvious reason to have two types of ASs". Do you see an alternative ?

    Regarding the last item, I don't think that naming RQ by end-user created the problem. It might just highlight the asymmetry, which fundamentally exists. 

    Fabien


    On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper <agropper@healthurl.com> wrote:
    Recap:
    1 - Justin (I think) introduced the idea of an AS on the RS trust boundary side.
    2 - I said the RO should not have to share policies with the RS.
    3 - Alan invented the concept of AS-RO and AS-RS to separate two kinds of PDPs. 

    The thing is that step 2 is not symmetrical. The RO has a legitimate privacy interest in keeping their policies private and minimizing the leakage of information about requests that are posed against those policies. 

    The RS, on the other hand, should be publishing its policies (e.g. what it’s selling or what jurisdiction it’s in or what tokens or scopes it supports). The RS has no obvious privacy interest in GNAP. It’s just an enforcer.

    There is one other privacy interest to consider around the RS and that is the requesting party (the end-user that is not the RO :-) might prefer to share attributes with the RS instead of the RO or something controlled by the RO. This case could be an “extension” to GNAP and might result in a split AS as a solution. This problem was introduced when the editors decided to replace RQ with end-user. Obviously, the RO end-user has no privacy interests relative to itself.

    Adrian




    On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    I was referring to "By my definition, this model has two ASs since both are processing requests into tokens". If there's no reason to have 2 types of ASs, that's fine then. 
    But I'm a bit lost in where we stand with the idea. 

    Could you recap? 

    Fabien 

    Le jeu. 25 mars 2021 à 08:16, Adrian Gropper <agropper@healthurl.com> a écrit :
    There’s no obvious reason to have two types of ASs. Any AS that is executing the policies of the RS can look to GNAP like the RS itself. Why would GNAP expose that interface to anyone? 

    Adrian

    On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Note : I'm not sure that's a good idea, but having 2 types of ASs is not that easy to grasp.

    Fabien 

    Le jeu. 25 mars 2021 à 08:07, Fabien Imbault <fabien.imbault@gmail.com> a écrit :
    The purpose of either handling policies locally or delegating them to the RO agent. 

    Le jeu. 25 mars 2021 à 08:04, Adrian Gropper <agropper@healthurl.com> a écrit :
    What purpose would be served by GNAP splitting the AS into two components?

    Adrian 

    On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Isn't the AS-RO a component of the AS? Same idea as the interact component, it functionnally belongs to the AS role but could be deployed either as a monolith or as a separate component?

    Fabien

    Le jeu. 25 mars 2021 à 04:26, Adrian Gropper <agropper@healthurl.com> a écrit :
    Yes, but I would say it’s not the RO that wants the access token. It’s the RO that wants the client making the request to get an access token. 

    Adrian

    On Wed, Mar 24, 2021 at 11:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Adrian Gropper <agropper@healthurl.com> wrote:

    In this design, the AS is the AS-RS and the agent is the AS-RO. By my definition, this model has two ASs since both are processing requests into tokens. The problem with this is complexity and privacy. The RO may not want to share the request information with the AS-RS.

    More precisely, RO has no choice but to present the required information to AS-RS if RO wants an access token.  However, RO does not want AS-RS to know the policy by which RO delegates tokens.  That's why RO uses AS-RO for those delegations.

    --------------
    Alan Karp


    On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Thank you for creating the issue. My definition of AS is independent of AS-RO or AS-RS. https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomment-806280421 I also agree with Alan's definition based on delegation. An AS-RS would be a delegate of the RS. 

    Based on that, I see it as obvious that the policy has to be accessible (defined locally?) in order for it to be run as the code that turns a request into an access token. 

    The only other possibility is that the request is packaged by the AS and sent elsewhere (an agent) for evaluation against policy and a proto-token returned. In that case the AS is acting as a proxy and the PDP is elsewhere. I can imagine that an AS-RS would behave this way so that the proto-token could be turned into an access token by the AS-RS. Isn't this what Justin is proposing? In this design, the AS is the AS-RS and the agent is the AS-RO. By my definition, this model has two ASs since both are processing requests into tokens. The problem with this is complexity and privacy. The RO may not want to share the request information with the AS-RS.

    Adrian

    On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Isn't that what the AS is supposed to be, only with the caveat that the policy is defined locally? 

    Fabien 


    Le mer. 24 mars 2021 à 20:17, Alan Karp <alanhkarp@gmail.com> a écrit :
    AS-RO is an AS that RO trusts to delegate RO's access tokens according to RO's policies.  

    --------------
    Alan Karp


    On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan and Adrian,

    I've created issue AS-RO policy delegation (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to capture your input. 
    A first question that arises: can we give a definition to AS-RO?

    Thanks
    Fabien

    On Tue, Mar 23, 2021 at 4:15 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan, 

    Yes, but in that flow, the token relationship between AS-RS and AS-RO is only secure if the tokens issued by AS-RS are cryptographically attenuable in the first place. 
     
    Attenuated delegation is a requirement, but that doesn't have to be done cryptographically.  Token exchange works just fine.  SPKI and zcap-ld are examples of the crypto approach, and we used token exchange in the system for HP.

    --------------
    Alan Karp


    On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan, 

    Yes, but in that flow, the token relationship between AS-RS and AS-RO is only secure if the tokens issued by AS-RS are cryptographically attenuable in the first place. 

    Fabien

    On Mon, Mar 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin Richer <jricher@mit.edu> wrote:

    But with all that in mind, I think the key here is going to be looking at what the inputs to the AS are, and how those can be defined in an interoperable way for AS’s that can accept them. I think there’s a lot of room for innovation and flexibility here that doesn’t break the trust model or core use cases. If I have an AS-RS set that won’t accept my favorite flavor of policy engine inputs, then I can decide not to use that one. But this is a very different question than saying the RS itself needs to accept my own AS — and we can’t keep conflating these two models.

    I agree.  The point of having an AS-RO is to allow RO to specify a policy for which of RO's access tokens should be delegated under what conditions.  AS-RS should not need to understand those policies.  The flow would be
    • RO contacts AS-RS and gets one or more access tokens.
    • RO delegates one or more of those tokens, potentially sub-scoped, to AS-RO.
    • A different user contacts AS-RO to get a potentially sub-scoped access token from AS-RO.
    • That user presents the access token delegated by AS-RO when invoking the resource.
    AS-RS only needs to verify that the delegation chain is legitimate, e.g., no increase in scope, and that it grants permission for the request being made.  AS-RS does not need to understand the policy behind granting the delegation by AS-RO.

    --------------
    Alan Karp


    On Mon, Mar 22, 2021 at 11:40 AM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    I think this shows the problem with the terminology as it’s been applied in this conversation, which I’ve tried to shine light on before. What you and others are calling the “RS” is really the “AS and RS working together” — everything to the right of the line. When Denis had brought up “eliminating the AS” in another thread, what he’d really done is labeled everything to the right of the line as the “RS”. Of course, the irony here is that everything to the right of the line used all be called the “AS” or simply “server” in the OAuth 1 days. As you say below, I don’t want the client to have visibility on what happens on that side. 

    Note well: The Google+ logo labeled “IdP” in the diagram is not the AS, as far as GNAP is concerned. It does not issue an access token that the RS will accept. The elements to the left of the line could be a lot of things, but they are NOT the AS — by definition. The client lives over on the left, but so do any external inputs to the AS. These could be policy inputs on behalf of the RO, they could be presentation artifacts, they could be federated logins, they could be the output of policy decisions. How the AS comes to trust those things is up to the AS’s implementation. It’s something we can talk about, but ultimately GNAP won’t be in any position to dictate because in practice some AS’s are simply going to internalize all policies and we will never successfully force those open. 

    But with all that in mind, I think the key here is going to be looking at what the inputs to the AS are, and how those can be defined in an interoperable way for AS’s that can accept them. I think there’s a lot of room for innovation and flexibility here that doesn’t break the trust model or core use cases. If I have an AS-RS set that won’t accept my favorite flavor of policy engine inputs, then I can decide not to use that one. But this is a very different question than saying the RS itself needs to accept my own AS — and we can’t keep conflating these two models.

    So to me, GNAP can support a Zero Trust Architecture by LEVERAGING the AS, not by subsuming or eliminating it. It is in fact the AS, not the client and not the RS, that will request and consume the results of a privacy-preserving zero-trust policy query thing. Anything that happens downstream from that is of little concern to the zero-trust components because, as you point out, it’s on the “other side” of the line. 

    I think we got this basic component model pretty right in OAuth: the AS and RS and client working together. Where OAuth misses the mark is the assumption that the user has to log in to the AS through a webpage and interact directly, thereby proving they’re the RO. It’s this latter space where I think we can both push innovation and also address the important and compelling use cases like the ones you’re bringing.

     — Justin

    On Mar 22, 2021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I'm sorry, Justin. As a Resource Owner, I look at the RS trust boundary (the dotted line in the diagram) as being the RS. I don't expect any visibility into what's going on on the right. 

    My problem with the framing you propose is that requests are going to the RS (or the AS-RS) and I don't want to share my policies with the AS-RS. I want to keep the RS and AS-RS as ignorant as possible.

    Adrian

    On Mon, Mar 22, 2021 at 1:48 PM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    What you’re discussing below, in terms of logging in to a site, is not approaching the RS. You are in fact approaching the client, and identifying both the AS and RS to the client. The client is a client of your identity in this model, and the RS is part of the identity provider. It’s really important that we don’t conflate the RS and client in this way as it leads to a lot of confusion downstream and a lot of broken trust boundaries.

    With that model in mind, approaching the “RS" and providing it your identity is really just a case of the “federated login to AS” pattern that we discussed on the WG call. The user here approaches an RS, which has its own AS. To share things from this RS, the RO has to authenticate to the RS’s AS. This particular AS allows the RO to do so using an external identity — in which case, the AS is now a “client” of a separate, disconnected (but layered) delegation. The ultimate client that eventually calls the RS down the way may or may not know about these layers. 

    <PastedGraphic-1.png>
    This same AS, which is closely tied to the RS and trusted by the RS, might also take in FIDO credentials, or DIDs, or any number of other proof mechanisms. The output of this is an access token the RS trusts, but the input is up to the AS. The RS is not what you’re logging in to.

     — Justin

    On Mar 22, 2021, at 1:28 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I too am in favor of avoiding consolidation and correlation. Right now, when I approach a service provider (RS) for the first time, I'm offered the opportunity to identify my persona as: email, sign-in with Google, Facebook, or Apple. I know there are people who try to create one-off email addresses but that is mostly a waste of time. 

    So, along come FIDO2 and DID wallets to the rescue. Now, in theory, I have a way to start out my RS relationship pseudonymously. 

    When I want my resource to be discovered or shared I will post that RS URL including my pseudonym. If I then want to introduce a mediator in front of my AS or messaging service endpoint, I have that option. If I want to keep requests away from the mediator, I would publish an encryption key along with my pseudonym.

    - Adrian



    On Mon, Mar 22, 2021 at 9:55 AM Justin Richer <jricher@mit.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhkarp@gmail.com> shared a talk about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use authority
    >> as a core principle. I advocate for a GNAP design that maximizes the power
    >> of the RO, to be seen as a human rights issue when the RO is a human. This
    >> causes me to ask how to combine better security with better human rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO to
    >> partition limited authority across dozens of different ASs by domain and
    >> function, then we are not using technology to empower the individual.
    >> Probably the opposite, as we introduce consent fatigue and burden normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because that maps
    >> into the way we manage our public and private identities. POLA would then
    >> teach care in keeping ASs and RSs related to work / public separate from
    >> ASs and RSs related to private life so that a policy vulnerability in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP
    > seems like a useful exercise.  I do want to point out some potential
    > pitfalls with one-AS-per-persona that we can also be aware of.  If
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS's
    > identity in effect also serves as a persona identity and there are privacy
    > considerations to that.  If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)
    > route is taken, we should consider whether that would lead to various
    > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.  That topic is a current matter of concern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the UMA working group, and it’s one of the biggest problems with the personal AS (and personal data store) model. This kind of thing makes RS-first trust models really difficult in practice.

    As a strawman, let’s say that I’ve got software that wants to access my medical information. It calls an RS and requests access, but it hasn’t been granted anything yet. Now I as the RO have set up the RS so that it talks to my personal AS, that only I use. In addition to the RS having to be able to figure out which medical records are being requested from the context of the unauthenticated request (which means it needs identifiers in the URL or something similar for the RS to be able to tell, assuming that it protects data for more than one person). So this client software doesn’t know who I am and doesn’t know my medical record information, makes a completely unauthorized request to the RS, and the RS says “Go to Justin’s personal AS to get a token”. The client can now make a direct correlation between the data that’s being protected at the RS and the person running the AS that protects it. Importantly, this client makes this call with no prior relationship to the RS and no really auditable way to track it down after the fact. This is a design feature in the good case, and terrifying in the bad case.

    If the RS instead says “welcome to Medicine Doctor RS, please talk to the Medicine Doctor AS to get access”, we haven’t exposed anything at all. And from the perspective of both the patient and the RS, this is more privacy-preserving, and it’s really the least surprising option. Once the client gets to the AS, it can start a negotiation of figuring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS, or set of AS’s for multiple personas to keep things separate, is a huge burden. Even in the tech community, I know people who can’t reliably manage more than one email address for different purposes. I wouldn’t expect my partner to do that — they have trouble enough balancing all the logins and sessions required for different kids remote schooling, I couldn’t imagine them having to understand all the requirements for managing multiple authorization servers and associated policies. I also don’t expect any person to “manage keys” — I’ve been on the internet for decades and I can barely keep tabs on my GPG keys, and only use them when I am forced to. This is exactly the kind of “market pressure” that I think Ben mentions above, people will just want to outsource that to someone else, and the reality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice only to end up with a world where the RS ends up making a limited choice anyway. We see how that plays out with OpenID Connect — RP’s could allow arbitrary IdPs but they choose Google because it works and that’s where the users are. (And that’s not to say anything of the proprietary OIDC-like protocols, but that’s another discussion).

    For further reading on these topics, I recommend both “Why Johnny Can’t Encrypt” and “Why CSCW Systems Fail”.

    So what does this have to do with GNAP? I think we can be clear-eyed on what kinds of expectations we have for the participants. If we expect users (RO’s) to have to set up the AS-RS relationship, or expect them to carry their AS, or manage their personal keys — I think we’ve lost the battle for relevance.

     — Justin


    --
    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





    --------------947117DD9866359C1B7B5A54-- From nobody Thu Mar 25 10:22:15 2021 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 1285C3A280F for ; Thu, 25 Mar 2021 10:22:13 -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 EoVu6BR8Gj0g for ; Thu, 25 Mar 2021 10:22:06 -0700 (PDT) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 794BB3A280D for ; Thu, 25 Mar 2021 10:22:06 -0700 (PDT) Received: by mail-qv1-xf29.google.com with SMTP id dc12so1569575qvb.4 for ; Thu, 25 Mar 2021 10:22: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=TcRWxcYszZWQj8VveF/AyZBrcv4Sj4tVgGpk4X9ASwI=; b=VkvHQlFRyq3k1DCxD5DcCFBdWpIOUBxcf3lWwxTqHyUN1g0eg9kaBz4BLOPe63xEDl 7jXUV6vXVEhUxBfjO36erBBmm4COdA8Y651p2Z19e1uNGVFBzE4qX2xFz0OigXx/JvUR 48UNt4wYUy2Mq80MCWakCJDvgNSofmvko28rJbdjsPnrxg5Wsx4RBTCXlRDSVhoY0gg4 L3dYz8CX3OZtljuyEknb2ox7vxoQqZUfmWm1/hHFy/Fp+is56kdhHce8I6t5yXKSgMI9 W+O+W9bnnJL7gkMqpkRl8U7AV8EuiLbD0rWp1gwCUfnosCvDtH0FnU5SvJkGhSojqUJH Vr8A== 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=TcRWxcYszZWQj8VveF/AyZBrcv4Sj4tVgGpk4X9ASwI=; b=b69Uc9Rc+FIynQOv0InD2Lq6IRmb/dhu9QAkn2CJdBxNJOGKk9tGs8mU0Y8uVao4ba +nLdFkAI3Hu/AstRzHrQqI0OTJZsBvgQKCj6NviwjnZVkb5TW53R+6EjAY+ZLl49oCC+ ylCFLF4iYo7ymOzhEWjvZGl/kuQ+C76zRcVSCQ1AvgstML7ouTnNhtBEcBnUwQO+JvQJ ILW/VR/v0YIcFlLUg8ZISkp/iAkKxJvNd0HDDMJUppyVdLKOok0l0j6jxrIW8eGrbaXV JHT6Rz4OPUd3EBU0+DjDKLOb5WSpaEiM2X1Z0FAW2n6JuA9JRhx3a57T947tVlr1SU9H DpRg== X-Gm-Message-State: AOAM532ytGIpVtMTZLrdx2FYpfLcYiIThCYVadnwj55of2eh97FXasX6 CnnkYh7bJH1l4Oc4zQfklwtgRgZHNc5TSvLcWXk= X-Google-Smtp-Source: ABdhPJwgisUqbR40LoLrUbe1hkJUza+OfvAYKzg1mLIjdWxm/AsVsQA6C9b3jGIWvxvXtkjcaSseJMuILD1WQdsFVy0= X-Received: by 2002:a0c:80ca:: with SMTP id 68mr9399715qvb.12.1616692924867; Thu, 25 Mar 2021 10:22:04 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> In-Reply-To: From: Alan Karp Date: Thu, 25 Mar 2021 10:21:52 -0700 Message-ID: To: Justin Richer Cc: Fabien Imbault , Adrian Gropper , Benjamin Kaduk , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="0000000000007f68a005be5fa720" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 17:22:13 -0000 --0000000000007f68a005be5fa720 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Justin Richer wrote: > Hi Alan, > > In all of my discussion, and in the spec itself, the RO is the :entity: i= n > charge of approving rights. They=E2=80=99re probably a person. It might b= e software > that makes a policy decision in some way, or a corporate entity, or > something like that. But it=E2=80=99s not assumed to be a computational a= gent in > the terms of the protocol itself. Would that recast what you=E2=80=99re s= aying > below? > Hmmm. I guess not. It's just that the person would be using some UI to express their decisions to what I called the user agent. That model fits in very nicely with what we did with Polaris, our virus safe computing environment for Windows XP, https://dl.acm.org/doi/10.1145/1151030.1151033. The person would click on the icon for a Word file, and an instance of Word would open with only the permission needed to edit that one file. Same thing here. The client could ask for permission to use the resource, or permission could be granted implicitly when the user selects a resource associated with a specific client. -------------- Alan Karp On Thu, Mar 25, 2021 at 9:53 AM Justin Richer wrote: > Hi Alan, > > In all of my discussion, and in the spec itself, the RO is the :entity: i= n > charge of approving rights. They=E2=80=99re probably a person. It might b= e software > that makes a policy decision in some way, or a corporate entity, or > something like that. But it=E2=80=99s not assumed to be a computational a= gent in > the terms of the protocol itself. Would that recast what you=E2=80=99re s= aying > below? > > =E2=80=94 Justin > > On Mar 25, 2021, at 12:36 PM, Alan Karp wrote: > > There seems to be some confusion about how AS-RO comes into the picture, > probably because of the "AS" part. I'm going to try to clear up that > confusion by more carefully explaining what I mean. > > I'm assuming that RO is a computational agent representing the person who > is the resource owner, something called the "user agent" in operating > systems lingo. I'm also assuming that it's possible to do delegation, > either locally or by token exchange with AS-RS. All delegations are > potentially sub-scoped, but you may also want to delegate with full scope > to have a separately revocable access token. > > Here's an example of how things work in a capability oriented system. > > 1. Someone, the service owner, creates a service. > 2. The service owner contracts with an policy agent (AS-RS) to create > and manage access tokens for that service (RS). > 3. A person wishing to create a resource at RS uses their user agent > (RO) to contact the service owner's policy agent (AS-RS) and gets back= an > access token for that resource. > 4. That user agent (RO) can > 1. use that access token to invoke the resource, or > 2. delegate an access token to a client of the user agent's (RO) > choice, or > 3. contract with a policy agent (AS-RO) to manage those delegations > on behalf of the user agent (RO), or > 4. specify a policy with the service's policy agent (AS-RS). > 5. A client can contact any holder of the access token (the user agent > (RO) or its policy agent (AS-RO)) or the service's policy agent (AS-RS= ) to > get a delegated access token. > 6. That client can delegate that token to another client. > 7. Another user agent (RO') can contact any holder of the access token > or the service's policy agent (AS-RS) to get a delegated access token. > 8. The other user agent (RO') can > 1. use that access token to invoke the resource, or > 2. delegate it to a client of its choice, or > 3. contract with a policy agent (AS-RO') of its choosing to manage > those delegations on its behalf, or > 4. specify a policy with the service's policy agent (AS-RS). > 9. and so on > > When any of these computational agents, user agents (ROs) or clients > acting on their behalf, invokes the resource, AS-RS verifies that the > access token is a valid delegation, i.e., proper sub-scoping, hasn't been > revoked, and that it authorizes the request being made before telling the > service (RS) to honor the request. At no point does the service's policy > agent (AS-RS) know which computational agent did any particular > delegation. (Token exchange can be done as anonymously as possible.) In > particular, the policy agents (AS-RO) need not be the same, or even > compatible with, the service's policy agent (AS-RS). GNAP specifies the > protocol between requesters, invokers, delegators (for token exchange) of > tokens and AS-RS. That protocol need not be used between user agents (RO= ), > clients, or other policy agents (AS-RO), but it is likely to be. > > ------------- > Alan Karp > > > On Thu, Mar 25, 2021 at 5:45 AM Justin Richer wrote: > >> The way I=E2=80=99m thinking about Adrian=E2=80=99s use case is that wha= t we=E2=80=99re calling >> the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an =E2=80=9CAS=E2=80=9D in the= traditional OAuth/GNAP sense, at least not >> exactly. This is the agent that the RO can use to set policies and manag= e >> consent on their behalf, and I=E2=80=99ve been arguing that it fits bett= er into >> this vaguely-defined =E2=80=9Cinteraction component=E2=80=9D aspect of t= he current AS >> definition, and it=E2=80=99s not currently separated from the AS definit= ion. The >> =E2=80=9CAS-RS=E2=80=9D maps to what we=E2=80=99d call the =E2=80=9CAS= =E2=80=9D in OAuth/GNAP traditionally, it=E2=80=99s >> what the RS trusts to issue tokens. In traditional OAuth the AS-RO and >> AS-RS are always the same thing, from a functional protocol perspective.= An >> important point here is that from a client=E2=80=99s perspective, they= =E2=80=99re only >> talking to the AS-RS since that=E2=80=99s where the client gets its toke= ns, because >> at the end of the day the client just wants to call the API at the RS an= d >> doesn=E2=80=99t care how that happens (from a protocol standpoint). >> >> Note well: Even thought I don=E2=80=99t believe that =E2=80=9CAS-RO=E2= =80=9D is an authorization >> server at all, I=E2=80=99m going to keep using that term below for consi= stency with >> previous discussion. >> >> So we have these fundamental relationships around getting the client to >> access the RS: >> >> 1. RS trusts AS-RS to issue tokens that RS will accept, validate, and >> process for requests from client >> 2. Client trusts AS-RS to issue tokens that client can use at RS >> 3. RO trusts RS to protect RO=E2=80=99s api through delegated access >> >> On top of that, we=E2=80=99ve got some additional aspects that we=E2=80= =99re discussing: >> >> 4. RO trusts AS-RO to manage RO=E2=80=99s policies at runtime >> 5. AS-RS trusts AS-RO to assert RO=E2=80=99s policies for access to RS >> 6. Client trusts whatever AS-RS sends client to deal with, including >> possibly RO-AS at runtime, because of (2) >> >> What I have been saying is that 4/5/6 are optional details of how RS-AS >> runs things, and I think this also maps with Adrian=E2=80=99s view of ch= oice, since >> if my RS=E2=80=99s AS-RS doesn=E2=80=99t allow me to plug in my own AS-R= O then I would be >> motivated to pick a different RS who=E2=80=99s AS-RS lets me do just tha= t. The same >> way I=E2=80=99d pick a different RS if their surrounding services didn= =E2=80=99t accept my >> preferred federation login and I didn=E2=80=99t want to make another acc= ount. Of >> course, market forces being as they are, I might not have much of an >> actionable choice in RS, but GNAP can=E2=80=99t change that. >> >> What we can do is make it possible for AS-RS to talk to AS-RO, both in >> philosophy of the protocol design and in concrete hooks to support (6) >> above. >> >> Separately, we can approach the issue of making 1/2 above more dynamic. >> This was UMA2=E2=80=99s =E2=80=9Cfederated authorization=E2=80=9D approa= ch, and is behind a lot of >> the =E2=80=9Cbring your own AS=E2=80=9D models out there. The problem wi= th these is that we >> know from many years of experience that most RS=E2=80=99s aren=E2=80=99t= interested in >> doing anything of the sort. >> >> So with GNAP we can instead allow 4/5/6 to vary in a predictable and >> consistent way, letting the RS keep control over 1/2, thereby enabling >> choice in (3). We don=E2=80=99t have to be the ones who define the all o= f the >> details of every permutation of (5) to enable this, though. Some of this= is >> going to be configuration out of band, some of it=E2=80=99s going to be >> communication at runtime. This is where VC=E2=80=99s, ZCAPs, CHAPI, DIDC= omm, FIDO, >> and a whole swath of other tech can come in and help out. I don=E2=80=99= t think we >> need to put all the details for using these into core, nor do I think we= =E2=80=99ll >> pull of The Great And Ultimate Abstraction for using these and other >> approaches. But we can at least start talking about =E2=80=9CAS-RS=E2=80= =9D in such a way >> that it no longer assumes it=E2=80=99s always the same party dealing wit= h the RO >> directly. >> >> =E2=80=94 Justin >> >> On Mar 25, 2021, at 6:40 AM, Fabien Imbault >> wrote: >> >> To reframe it closer to GNAP: >> - AS =3D AS-RO, that's where you find the RO policies. The AS issues acc= ess >> tokens to the client. >> - the RO policies could be a) defined locally or b) in relationship with >> the RS >> >> There have been several ideas related to the AS-RS relationship b: >> b1) the RS issues capabilities (which can be further attenuated by the R= O) >> b2) Adrian also discussed a DID based solution >> b3) there was also an alternative ACL proposal from Denis (+ preflight) >> >> Fabien >> >> >> On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault >> wrote: >> >>> Ok so I get you correctly: >>> - what matters is the RQ (could be a RO or a end-user or both : we don'= t >>> really care at a high-level, they're all treated as entities that make = a >>> request) >>> - the policy is able to handle those different cases, based on its own >>> internal delegation protocol >>> - currently that requires AS-RS and AS-RO, but maybe it can be simplifi= ed >>> >>> To answer to Denis, here's what I understood: >>> - RO trusts AS-RS (and then handles its own policies within AS-RO) >>> - end-user trusts AS-RO (through its client) >>> >>> Could probably work but that's a fairly different model compared to >>> OAuth2 (and of today's GNAP), with different frontiers between the AS a= nd >>> the RS. >>> >>> Please do not hesitate to correct me if I'm wrong. >>> >>> Fabien >>> >>> On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper >>> wrote: >>> >>>> I believe there are alternatives to having two kinds of ASs. The >>>> problem may be a side-effect of deciding to switch away form treating = the >>>> RO as different from the RQ. That leads to downstream privacy issues. = Our >>>> desire for architectural simplicity is admirable but that may have bee= n a >>>> step too far. >>>> >>>> There may also be solutions based on different types of tokens, as in >>>> different capabilities (tokens signed by the RS) vs. tokens signed by = the >>>> AS. I=E2=80=99m not sure about that but Alan might have more to say. >>>> >>>> Adrian >>>> >>>> On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Thanks. The general problem statement is clear. >>>>> >>>>> The proposed solution a bit less (to me). I understood that from poin= t >>>>> 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obvious reason= to have >>>>> two types of ASs". Do you see an alternative ? >>>>> >>>>> Regarding the last item, I don't think that naming RQ by end-user >>>>> created the problem. It might just highlight the asymmetry, which >>>>> fundamentally exists. >>>>> >>>>> Fabien >>>>> >>>>> >>>>> On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper >>>>> wrote: >>>>> >>>>>> Recap: >>>>>> 1 - Justin (I think) introduced the idea of an AS on the RS trust >>>>>> boundary side. >>>>>> 2 - I said the RO should not have to share policies with the RS. >>>>>> 3 - Alan invented the concept of AS-RO and AS-RS to separate two >>>>>> kinds of PDPs. >>>>>> >>>>>> The thing is that step 2 is not symmetrical. The RO has a legitimate >>>>>> privacy interest in keeping their policies private and minimizing th= e >>>>>> leakage of information about requests that are posed against those >>>>>> policies. >>>>>> >>>>>> The RS, on the other hand, should be publishing its policies (e.g. >>>>>> what it=E2=80=99s selling or what jurisdiction it=E2=80=99s in or wh= at tokens or scopes it >>>>>> supports). The RS has no obvious privacy interest in GNAP. It=E2=80= =99s just an >>>>>> enforcer. >>>>>> >>>>>> There is one other privacy interest to consider around the RS and >>>>>> that is the requesting party (the end-user that is not the RO :-) mi= ght >>>>>> prefer to share attributes with the RS instead of the RO or somethin= g >>>>>> controlled by the RO. This case could be an =E2=80=9Cextension=E2=80= =9D to GNAP and might >>>>>> result in a split AS as a solution. This problem was introduced when= the >>>>>> editors decided to replace RQ with end-user. Obviously, the RO end-u= ser has >>>>>> no privacy interests relative to itself. >>>>>> >>>>>> Adrian >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>>> I was referring to "By my definition, this model has two ASs since >>>>>>> both are processing requests into tokens". If there's no reason to = have 2 >>>>>>> types of ASs, that's fine then. >>>>>>> But I'm a bit lost in where we stand with the idea. >>>>>>> >>>>>>> Could you recap? >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper >>>>>>> a =C3=A9crit : >>>>>>> >>>>>>>> There=E2=80=99s no obvious reason to have two types of ASs. Any AS= that is >>>>>>>> executing the policies of the RS can look to GNAP like the RS itse= lf. Why >>>>>>>> would GNAP expose that interface to anyone? >>>>>>>> >>>>>>>> Adrian >>>>>>>> >>>>>>>> On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>> >>>>>>>>> Note : I'm not sure that's a good idea, but having 2 types of ASs >>>>>>>>> is not that easy to grasp. >>>>>>>>> >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault < >>>>>>>>> fabien.imbault@gmail.com> a =C3=A9crit : >>>>>>>>> >>>>>>>>>> The purpose of either handling policies locally or delegating >>>>>>>>>> them to the RO agent. >>>>>>>>>> >>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper < >>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>> >>>>>>>>>>> What purpose would be served by GNAP splitting the AS into two >>>>>>>>>>> components? >>>>>>>>>>> >>>>>>>>>>> Adrian >>>>>>>>>>> >>>>>>>>>>> On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault < >>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Isn't the AS-RO a component of the AS? Same idea as the >>>>>>>>>>>> interact component, it functionnally belongs to the AS role bu= t could be >>>>>>>>>>>> deployed either as a monolith or as a separate component? >>>>>>>>>>>> >>>>>>>>>>>> Fabien >>>>>>>>>>>> >>>>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper < >>>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>>> >>>>>>>>>>>>> Yes, but I would say it=E2=80=99s not the RO that wants the a= ccess >>>>>>>>>>>>> token. It=E2=80=99s the RO that wants the client making the r= equest to get an >>>>>>>>>>>>> access token. >>>>>>>>>>>>> >>>>>>>>>>>>> Adrian >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Mar 24, 2021 at 11:22 PM Alan Karp < >>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Adrian Gropper wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In this design, the AS is the AS-RS and the agent is the >>>>>>>>>>>>>>> AS-RO. By my definition, this model has two ASs since both = are processing >>>>>>>>>>>>>>> requests into tokens. The problem with this is complexity a= nd privacy. The >>>>>>>>>>>>>>> RO may not want to share the request information with the A= S-RS. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> More precisely, RO has no choice but to present the required >>>>>>>>>>>>>> information to AS-RS if RO wants an access token. However, = RO does not >>>>>>>>>>>>>> want AS-RS to know the policy by which RO delegates tokens. = That's why RO >>>>>>>>>>>>>> uses AS-RO for those delegations. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper < >>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thank you for creating the issue. My definition of AS is >>>>>>>>>>>>>>> independent of AS-RO or AS-RS. >>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/2= 23#issuecomment-806280421 >>>>>>>>>>>>>>> I also agree with Alan's definition based on delegation. An= AS-RS would be >>>>>>>>>>>>>>> a delegate of the RS. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Based on that, I see it as obvious that the policy has to b= e >>>>>>>>>>>>>>> accessible (defined locally?) in order for it to be run as = the code that >>>>>>>>>>>>>>> turns a request into an access token. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The only other possibility is that the request is packaged >>>>>>>>>>>>>>> by the AS and sent elsewhere (an agent) for evaluation agai= nst policy and a >>>>>>>>>>>>>>> proto-token returned. In that case the AS is acting as a pr= oxy and the PDP >>>>>>>>>>>>>>> is elsewhere. I can imagine that an AS-RS would behave this= way so that the >>>>>>>>>>>>>>> proto-token could be turned into an access token by the AS-= RS. Isn't this >>>>>>>>>>>>>>> what Justin is proposing? In this design, the AS is the AS-= RS and the agent >>>>>>>>>>>>>>> is the AS-RO. By my definition, this model has two ASs sinc= e both are >>>>>>>>>>>>>>> processing requests into tokens. The problem with this is c= omplexity and >>>>>>>>>>>>>>> privacy. The RO may not want to share the request informati= on with the >>>>>>>>>>>>>>> AS-RS. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault < >>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Isn't that what the AS is supposed to be, only with the >>>>>>>>>>>>>>>> caveat that the policy is defined locally? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp < >>>>>>>>>>>>>>>> alanhkarp@gmail.com> a =C3=A9crit : >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> AS-RO is an AS that RO trusts to delegate RO's access >>>>>>>>>>>>>>>>> tokens according to RO's policies. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault < >>>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi Alan and Adrian, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I've created issue AS-RO policy delegation ( >>>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issue= s/223) >>>>>>>>>>>>>>>>>> to capture your input. >>>>>>>>>>>>>>>>>> A first question that arises: can we give a definition t= o >>>>>>>>>>>>>>>>>> AS-RO? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp < >>>>>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Fabien Imbault wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Yes, but in that flow, the token relationship between >>>>>>>>>>>>>>>>>>>> AS-RS and AS-RO is only secure if the tokens issued by= AS-RS are >>>>>>>>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Attenuated delegation is a requirement, but that doesn'= t >>>>>>>>>>>>>>>>>>> have to be done cryptographically. Token exchange work= s just fine. SPKI >>>>>>>>>>>>>>>>>>> and zcap-ld are examples of the crypto approach, and we= used token exchange >>>>>>>>>>>>>>>>>>> in the system for HP. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault < >>>>>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Yes, but in that flow, the token relationship between >>>>>>>>>>>>>>>>>>>> AS-RS and AS-RO is only secure if the tokens issued by= AS-RS are >>>>>>>>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp < >>>>>>>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Justin Richer wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> But with all that in mind, I think the key here is >>>>>>>>>>>>>>>>>>>>>> going to be looking at what the inputs to the AS are= , and how those can be >>>>>>>>>>>>>>>>>>>>>> defined in an interoperable way for AS=E2=80=99s tha= t can accept them. I think >>>>>>>>>>>>>>>>>>>>>> there=E2=80=99s a lot of room for innovation and fle= xibility here that doesn=E2=80=99t >>>>>>>>>>>>>>>>>>>>>> break the trust model or core use cases. If I have a= n AS-RS set that won=E2=80=99t >>>>>>>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine inputs, t= hen I can decide not to >>>>>>>>>>>>>>>>>>>>>> use that one. But this is a very different question = than saying the RS >>>>>>>>>>>>>>>>>>>>>> itself needs to accept my own AS =E2=80=94 and we ca= n=E2=80=99t keep conflating these two >>>>>>>>>>>>>>>>>>>>>> models. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I agree. The point of having an AS-RO is to allow R= O >>>>>>>>>>>>>>>>>>>>> to specify a policy for which of RO's access tokens s= hould be delegated >>>>>>>>>>>>>>>>>>>>> under what conditions. AS-RS should not need to unde= rstand those >>>>>>>>>>>>>>>>>>>>> policies. The flow would be >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> - RO contacts AS-RS and gets one or more access >>>>>>>>>>>>>>>>>>>>> tokens. >>>>>>>>>>>>>>>>>>>>> - RO delegates one or more of those tokens, >>>>>>>>>>>>>>>>>>>>> potentially sub-scoped, to AS-RO. >>>>>>>>>>>>>>>>>>>>> - A different user contacts AS-RO to get a >>>>>>>>>>>>>>>>>>>>> potentially sub-scoped access token from AS-RO. >>>>>>>>>>>>>>>>>>>>> - That user presents the access token delegated by >>>>>>>>>>>>>>>>>>>>> AS-RO when invoking the resource. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> AS-RS only needs to verify that the delegation chain >>>>>>>>>>>>>>>>>>>>> is legitimate, e.g., no increase in scope, and that i= t grants permission >>>>>>>>>>>>>>>>>>>>> for the request being made. AS-RS does not need to u= nderstand the policy >>>>>>>>>>>>>>>>>>>>> behind granting the delegation by AS-RO. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer < >>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I think this shows the problem with the terminology >>>>>>>>>>>>>>>>>>>>>> as it=E2=80=99s been applied in this conversation, w= hich I=E2=80=99ve tried to shine light >>>>>>>>>>>>>>>>>>>>>> on before. What you and others are calling the =E2= =80=9CRS=E2=80=9D is really the =E2=80=9CAS and >>>>>>>>>>>>>>>>>>>>>> RS working together=E2=80=9D =E2=80=94 everything to= the right of the line. When Denis had >>>>>>>>>>>>>>>>>>>>>> brought up =E2=80=9Celiminating the AS=E2=80=9D in a= nother thread, what he=E2=80=99d really done is >>>>>>>>>>>>>>>>>>>>>> labeled everything to the right of the line as the = =E2=80=9CRS=E2=80=9D. Of course, the >>>>>>>>>>>>>>>>>>>>>> irony here is that everything to the right of the li= ne used all be called >>>>>>>>>>>>>>>>>>>>>> the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver= =E2=80=9D in the OAuth 1 days. As you say below, I don=E2=80=99t >>>>>>>>>>>>>>>>>>>>>> want the client to have visibility on what happens o= n that side. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Note well: The Google+ logo labeled =E2=80=9CIdP=E2= =80=9D in the >>>>>>>>>>>>>>>>>>>>>> diagram is not the AS, as far as GNAP is concerned. = It does not issue an >>>>>>>>>>>>>>>>>>>>>> access token that the RS will accept. The elements t= o the left of the line >>>>>>>>>>>>>>>>>>>>>> could be a lot of things, but they are NOT the AS = =E2=80=94 by definition. The >>>>>>>>>>>>>>>>>>>>>> client lives over on the left, but so do any externa= l inputs to the AS. >>>>>>>>>>>>>>>>>>>>>> These could be policy inputs on behalf of the RO, th= ey could be >>>>>>>>>>>>>>>>>>>>>> presentation artifacts, they could be federated logi= ns, they could be the >>>>>>>>>>>>>>>>>>>>>> output of policy decisions. How the AS comes to trus= t those things is up to >>>>>>>>>>>>>>>>>>>>>> the AS=E2=80=99s implementation. It=E2=80=99s someth= ing we can talk about, but ultimately >>>>>>>>>>>>>>>>>>>>>> GNAP won=E2=80=99t be in any position to dictate bec= ause in practice some AS=E2=80=99s are >>>>>>>>>>>>>>>>>>>>>> simply going to internalize all policies and we will= never successfully >>>>>>>>>>>>>>>>>>>>>> force those open. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> But with all that in mind, I think the key here is >>>>>>>>>>>>>>>>>>>>>> going to be looking at what the inputs to the AS are= , and how those can be >>>>>>>>>>>>>>>>>>>>>> defined in an interoperable way for AS=E2=80=99s tha= t can accept them. I think >>>>>>>>>>>>>>>>>>>>>> there=E2=80=99s a lot of room for innovation and fle= xibility here that doesn=E2=80=99t >>>>>>>>>>>>>>>>>>>>>> break the trust model or core use cases. If I have a= n AS-RS set that won=E2=80=99t >>>>>>>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine inputs, t= hen I can decide not to >>>>>>>>>>>>>>>>>>>>>> use that one. But this is a very different question = than saying the RS >>>>>>>>>>>>>>>>>>>>>> itself needs to accept my own AS =E2=80=94 and we ca= n=E2=80=99t keep conflating these two >>>>>>>>>>>>>>>>>>>>>> models. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> So to me, GNAP can support a Zero Trust Architecture >>>>>>>>>>>>>>>>>>>>>> by LEVERAGING the AS, not by subsuming or eliminatin= g it. It is in fact the >>>>>>>>>>>>>>>>>>>>>> AS, not the client and not the RS, that will request= and consume the >>>>>>>>>>>>>>>>>>>>>> results of a privacy-preserving zero-trust policy qu= ery thing. Anything >>>>>>>>>>>>>>>>>>>>>> that happens downstream from that is of little conce= rn to the zero-trust >>>>>>>>>>>>>>>>>>>>>> components because, as you point out, it=E2=80=99s o= n the =E2=80=9Cother side=E2=80=9D of the line. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I think we got this basic component model pretty >>>>>>>>>>>>>>>>>>>>>> right in OAuth: the AS and RS and client working tog= ether. Where OAuth >>>>>>>>>>>>>>>>>>>>>> misses the mark is the assumption that the user has = to log in to the AS >>>>>>>>>>>>>>>>>>>>>> through a webpage and interact directly, thereby pro= ving they=E2=80=99re the RO. >>>>>>>>>>>>>>>>>>>>>> It=E2=80=99s this latter space where I think we can = both push innovation and also >>>>>>>>>>>>>>>>>>>>>> address the important and compelling use cases like = the ones you=E2=80=99re >>>>>>>>>>>>>>>>>>>>>> bringing. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper < >>>>>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I'm sorry, Justin. As a Resource Owner, I look at th= e >>>>>>>>>>>>>>>>>>>>>> RS trust boundary (the dotted line in the diagram) a= s being the RS. I don't >>>>>>>>>>>>>>>>>>>>>> expect any visibility into what's going on on the ri= ght. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> My problem with the framing you propose is that >>>>>>>>>>>>>>>>>>>>>> requests are going to the RS (or the AS-RS) and I do= n't want to share my >>>>>>>>>>>>>>>>>>>>>> policies with the AS-RS. I want to keep the RS and A= S-RS as ignorant as >>>>>>>>>>>>>>>>>>>>>> possible. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer < >>>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> What you=E2=80=99re discussing below, in terms of l= ogging in >>>>>>>>>>>>>>>>>>>>>>> to a site, is not approaching the RS. You are in fa= ct approaching the >>>>>>>>>>>>>>>>>>>>>>> client, and identifying both the AS and RS to the c= lient. The client is a >>>>>>>>>>>>>>>>>>>>>>> client *of your identity* in this model, and the RS >>>>>>>>>>>>>>>>>>>>>>> is part of the identity provider. It=E2=80=99s real= ly important that we don=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>> conflate the RS and client in this way as it leads = to a lot of confusion >>>>>>>>>>>>>>>>>>>>>>> downstream and a lot of broken trust boundaries. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> With that model in mind, approaching the =E2=80=9CR= S" and >>>>>>>>>>>>>>>>>>>>>>> providing it your identity is really just a case of= the =E2=80=9Cfederated login to >>>>>>>>>>>>>>>>>>>>>>> AS=E2=80=9D pattern that we discussed on the WG cal= l. The user here approaches an >>>>>>>>>>>>>>>>>>>>>>> RS, which has its own AS. To share things from this= RS, the RO has to >>>>>>>>>>>>>>>>>>>>>>> authenticate to the RS=E2=80=99s AS. This particula= r AS allows the RO to do so >>>>>>>>>>>>>>>>>>>>>>> using an external identity =E2=80=94 in which case,= the AS is now a =E2=80=9Cclient=E2=80=9D of a >>>>>>>>>>>>>>>>>>>>>>> separate, disconnected (but layered) delegation. Th= e ultimate client that >>>>>>>>>>>>>>>>>>>>>>> eventually calls the RS down the way may or may not= know about these >>>>>>>>>>>>>>>>>>>>>>> layers. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> This same AS, which is closely tied to the RS and >>>>>>>>>>>>>>>>>>>>>>> trusted by the RS, might also take in FIDO credenti= als, or DIDs, or any >>>>>>>>>>>>>>>>>>>>>>> number of other proof mechanisms. The output of thi= s is an access token the >>>>>>>>>>>>>>>>>>>>>>> RS trusts, but the input is up to the AS. The RS is= not what you=E2=80=99re logging >>>>>>>>>>>>>>>>>>>>>>> in to. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper < >>>>>>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I too am in favor of avoiding consolidation and >>>>>>>>>>>>>>>>>>>>>>> correlation. Right now, when I approach a service p= rovider (RS) for the >>>>>>>>>>>>>>>>>>>>>>> first time, I'm offered the opportunity to identify= my persona as: email, >>>>>>>>>>>>>>>>>>>>>>> sign-in with Google, Facebook, or Apple. I know the= re are people who try to >>>>>>>>>>>>>>>>>>>>>>> create one-off email addresses but that is mostly a= waste of time. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> So, along come FIDO2 and DID wallets to the rescue. >>>>>>>>>>>>>>>>>>>>>>> Now, in theory, I have a way to start out my RS rel= ationship >>>>>>>>>>>>>>>>>>>>>>> pseudonymously. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> When I want my resource to be discovered or shared = I >>>>>>>>>>>>>>>>>>>>>>> will post that RS URL including my pseudonym. If I = then want to introduce a >>>>>>>>>>>>>>>>>>>>>>> mediator in front of my AS or messaging service end= point, I have that >>>>>>>>>>>>>>>>>>>>>>> option. If I want to keep requests away from the me= diator, I would publish >>>>>>>>>>>>>>>>>>>>>>> an encryption key along with my pseudonym. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> - Adrian >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer < >>>>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk < >>>>>>>>>>>>>>>>>>>>>>>> kaduk@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian >>>>>>>>>>>>>>>>>>>>>>>> Gropper wrote: >>>>>>>>>>>>>>>>>>>>>>>> >> @Alan Karp shared a talk >>>>>>>>>>>>>>>>>>>>>>>> about the Principle Of Least >>>>>>>>>>>>>>>>>>>>>>>> >> Authority (POLA) in a recent comment >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol= /issues/145#issuecomment-803099693 >>>>>>>>>>>>>>>>>>>>>>>> >> I recommend it. >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> >> We might expect a protocol with authorization i= n >>>>>>>>>>>>>>>>>>>>>>>> the title to use authority >>>>>>>>>>>>>>>>>>>>>>>> >> as a core principle. I advocate for a GNAP >>>>>>>>>>>>>>>>>>>>>>>> design that maximizes the power >>>>>>>>>>>>>>>>>>>>>>>> >> of the RO, to be seen as a human rights issue >>>>>>>>>>>>>>>>>>>>>>>> when the RO is a human. This >>>>>>>>>>>>>>>>>>>>>>>> >> causes me to ask how to combine better security >>>>>>>>>>>>>>>>>>>>>>>> with better human rights in >>>>>>>>>>>>>>>>>>>>>>>> >> GNAP. >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> >> Who should have the least authority in the GNAP >>>>>>>>>>>>>>>>>>>>>>>> design? >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> >> The AS derives authority as a delegate of the >>>>>>>>>>>>>>>>>>>>>>>> RO. If we ask the RO to >>>>>>>>>>>>>>>>>>>>>>>> >> partition limited authority across dozens of >>>>>>>>>>>>>>>>>>>>>>>> different ASs by domain and >>>>>>>>>>>>>>>>>>>>>>>> >> function, then we are not using technology to >>>>>>>>>>>>>>>>>>>>>>>> empower the individual. >>>>>>>>>>>>>>>>>>>>>>>> >> Probably the opposite, as we introduce consent >>>>>>>>>>>>>>>>>>>>>>>> fatigue and burden normal >>>>>>>>>>>>>>>>>>>>>>>> >> people to partition their lives into >>>>>>>>>>>>>>>>>>>>>>>> non-overlapping domains. >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> >> My experience says we should aim for one AS per >>>>>>>>>>>>>>>>>>>>>>>> persona because that maps >>>>>>>>>>>>>>>>>>>>>>>> >> into the way we manage our public and private >>>>>>>>>>>>>>>>>>>>>>>> identities. POLA would then >>>>>>>>>>>>>>>>>>>>>>>> >> teach care in keeping ASs and RSs related to >>>>>>>>>>>>>>>>>>>>>>>> work / public separate from >>>>>>>>>>>>>>>>>>>>>>>> >> ASs and RSs related to private life so that a >>>>>>>>>>>>>>>>>>>>>>>> policy vulnerability in our >>>>>>>>>>>>>>>>>>>>>>>> >> delegation to an AS would have the least >>>>>>>>>>>>>>>>>>>>>>>> likelihood of harm. >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > Thinking about how least authority/least >>>>>>>>>>>>>>>>>>>>>>>> privilege would apply to GNAP >>>>>>>>>>>>>>>>>>>>>>>> > seems like a useful exercise. I do want to poin= t >>>>>>>>>>>>>>>>>>>>>>>> out some potential >>>>>>>>>>>>>>>>>>>>>>>> > pitfalls with one-AS-per-persona that we can als= o >>>>>>>>>>>>>>>>>>>>>>>> be aware of. If >>>>>>>>>>>>>>>>>>>>>>>> > one-AS-per-persona becomes one-persona-per-AS as >>>>>>>>>>>>>>>>>>>>>>>> well, then the AS's >>>>>>>>>>>>>>>>>>>>>>>> > identity in effect also serves as a persona >>>>>>>>>>>>>>>>>>>>>>>> identity and there are privacy >>>>>>>>>>>>>>>>>>>>>>>> > considerations to that. If, on the other hand, >>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>> > multiple-personas-per-AS (presumably >>>>>>>>>>>>>>>>>>>>>>>> corresponding to multiple humans) >>>>>>>>>>>>>>>>>>>>>>>> > route is taken, we should consider whether that >>>>>>>>>>>>>>>>>>>>>>>> would lead to various >>>>>>>>>>>>>>>>>>>>>>>> > (e.g., market) forces driving consolidation to >>>>>>>>>>>>>>>>>>>>>>>> just a handful of >>>>>>>>>>>>>>>>>>>>>>>> > super-popular AS services. That topic is a >>>>>>>>>>>>>>>>>>>>>>>> current matter of concern to >>>>>>>>>>>>>>>>>>>>>>>> > some IETF participants. >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Hi Ben, big +1 to this. This is something that we >>>>>>>>>>>>>>>>>>>>>>>> discussed ages ago in the UMA working group, and i= t=E2=80=99s one of the biggest >>>>>>>>>>>>>>>>>>>>>>>> problems with the personal AS (and personal data s= tore) model. This kind of >>>>>>>>>>>>>>>>>>>>>>>> thing makes RS-first trust models really difficult= in practice. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve= got software >>>>>>>>>>>>>>>>>>>>>>>> that wants to access my medical information. It ca= lls an RS and requests >>>>>>>>>>>>>>>>>>>>>>>> access, but it hasn=E2=80=99t been granted anythin= g yet. Now I as the RO have set >>>>>>>>>>>>>>>>>>>>>>>> up the RS so that it talks to my personal AS, that= only I use. In addition >>>>>>>>>>>>>>>>>>>>>>>> to the RS having to be able to figure out which me= dical records are being >>>>>>>>>>>>>>>>>>>>>>>> requested from the context of the unauthenticated = request (which means it >>>>>>>>>>>>>>>>>>>>>>>> needs identifiers in the URL or something similar = for the RS to be able to >>>>>>>>>>>>>>>>>>>>>>>> tell, assuming that it protects data for more than= one person). So this >>>>>>>>>>>>>>>>>>>>>>>> client software doesn=E2=80=99t know who I am and = doesn=E2=80=99t know my medical record >>>>>>>>>>>>>>>>>>>>>>>> information, makes a completely unauthorized reque= st to the RS, and the RS >>>>>>>>>>>>>>>>>>>>>>>> says =E2=80=9CGo to Justin=E2=80=99s personal AS t= o get a token=E2=80=9D. The client can now make a >>>>>>>>>>>>>>>>>>>>>>>> direct correlation between the data that=E2=80=99s= being protected at the RS and >>>>>>>>>>>>>>>>>>>>>>>> the person running the AS that protects it. Import= antly, this client makes >>>>>>>>>>>>>>>>>>>>>>>> this call with no prior relationship to the RS and= no really auditable way >>>>>>>>>>>>>>>>>>>>>>>> to track it down after the fact. This is a design = feature in the good case, >>>>>>>>>>>>>>>>>>>>>>>> and terrifying in the bad case. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> If the RS instead says =E2=80=9Cwelcome to Medicin= e Doctor >>>>>>>>>>>>>>>>>>>>>>>> RS, please talk to the Medicine Doctor AS to get a= ccess=E2=80=9D, we haven=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>> exposed anything at all. And from the perspective = of both the patient and >>>>>>>>>>>>>>>>>>>>>>>> the RS, this is more privacy-preserving, and it=E2= =80=99s really the least >>>>>>>>>>>>>>>>>>>>>>>> surprising option. Once the client gets to the AS,= it can start a >>>>>>>>>>>>>>>>>>>>>>>> negotiation of figuring out who the RO is for the = information being >>>>>>>>>>>>>>>>>>>>>>>> accessed. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On top of this, the usability expectations of >>>>>>>>>>>>>>>>>>>>>>>> people managing their own AS, or set of AS=E2=80= =99s for multiple personas to keep >>>>>>>>>>>>>>>>>>>>>>>> things separate, is a huge burden. Even in the tec= h community, I know >>>>>>>>>>>>>>>>>>>>>>>> people who can=E2=80=99t reliably manage more than= one email address for different >>>>>>>>>>>>>>>>>>>>>>>> purposes. I wouldn=E2=80=99t expect my partner to = do that =E2=80=94 they have trouble >>>>>>>>>>>>>>>>>>>>>>>> enough balancing all the logins and sessions requi= red for different kids >>>>>>>>>>>>>>>>>>>>>>>> remote schooling, I couldn=E2=80=99t imagine them = having to understand all the >>>>>>>>>>>>>>>>>>>>>>>> requirements for managing multiple authorization s= ervers and associated >>>>>>>>>>>>>>>>>>>>>>>> policies. I also don=E2=80=99t expect any person t= o =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve been on >>>>>>>>>>>>>>>>>>>>>>>> the internet for decades and I can barely keep tab= s on my GPG keys, and >>>>>>>>>>>>>>>>>>>>>>>> only use them when I am forced to. This is exactly= the kind of =E2=80=9Cmarket >>>>>>>>>>>>>>>>>>>>>>>> pressure=E2=80=9D that I think Ben mentions above,= people will just want to >>>>>>>>>>>>>>>>>>>>>>>> outsource that to someone else, and the reality wi= ll be a few popular >>>>>>>>>>>>>>>>>>>>>>>> providers. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> In which case, we could end up doing a ton of work >>>>>>>>>>>>>>>>>>>>>>>> to allow an RS choice only to end up with a world = where the RS ends up >>>>>>>>>>>>>>>>>>>>>>>> making a limited choice anyway. We see how that pl= ays out with OpenID >>>>>>>>>>>>>>>>>>>>>>>> Connect =E2=80=94 RP=E2=80=99s could allow arbitra= ry IdPs but they choose Google because it >>>>>>>>>>>>>>>>>>>>>>>> works and that=E2=80=99s where the users are. (And= that=E2=80=99s not to say anything of >>>>>>>>>>>>>>>>>>>>>>>> the proprietary OIDC-like protocols, but that=E2= =80=99s another discussion). >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> For further reading on these topics, I recommend >>>>>>>>>>>>>>>>>>>>>>>> both =E2=80=9CWhy Johnny Can=E2=80=99t Encrypt=E2= =80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> So what does this have to do with GNAP? I think we >>>>>>>>>>>>>>>>>>>>>>>> can be clear-eyed on what kinds of expectations we= have for the >>>>>>>>>>>>>>>>>>>>>>>> participants. If we expect users (RO=E2=80=99s) to= have to set up the AS-RS >>>>>>>>>>>>>>>>>>>>>>>> relationship, or expect them to carry their AS, or= manage their personal >>>>>>>>>>>>>>>>>>>>>>>> keys =E2=80=94 I think we=E2=80=99ve lost the batt= le for relevance. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>> >>>>>>>>>>>>> >> > --0000000000007f68a005be5fa720 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Jus= tin Richer <jricher@mit.edu> w= rote:
    Hi Alan,

    In all of my di= scussion, and in the spec itself, the RO is the :entity: in charge of appro= ving rights. They=E2=80=99re probably a person. It might be software that m= akes a policy decision in some way, or a corporate entity, or something lik= e that. But it=E2=80=99s not assumed to be a computational agent in the ter= ms of the protocol itself. Would that recast what you=E2=80=99re saying bel= ow?

    Hmmm.=C2=A0 I guess not.=C2=A0 It'= s just that the person would be using some UI to express their decisions to= what I called the user agent.=C2=A0 That model fits in very nicely with wh= at we did with Polaris, our virus safe computing environment for Windows XP= , https://dl.acm= .org/doi/10.1145/1151030.1151033.=C2=A0 The person would click on the i= con for a Word file, and an instance of Word would open with only the permi= ssion needed to edit that one file.=C2=A0 Same thing here.=C2=A0 The client= could ask for permission to use the resource, or permission could be grant= ed implicitly when the user selects a resource associated with a specific c= lient.

    --------------
    Alan Karp


    On Thu, Mar 2= 5, 2021 at 9:53 AM Justin Richer <jri= cher@mit.edu> wrote:
    Hi Alan,

    In all of my discussion, and in the spec itself, the RO is the :enti= ty: in charge of approving rights. They=E2=80=99re probably a person. It mi= ght be software that makes a policy decision in some way, or a corporate en= tity, or something like that. But it=E2=80=99s not assumed to be a computat= ional agent in the terms of the protocol itself. Would that recast what you= =E2=80=99re saying below?

    =C2=A0=E2=80=94 Justin

    On Mar 25, 2021, at 12:36 PM, Ala= n Karp <alanhka= rp@gmail.com> wrote:

    There seems to b= e some confusion about how AS-RO comes into the picture, probably because o= f the "AS" part.=C2=A0 I'm going to try to clear up that conf= usion by more carefully explaining what I mean.

    I'm assumi= ng that RO is a computational agent representing the person who is the reso= urce owner, something called the "user agent" in operating system= s lingo.=C2=A0 I'm also assuming that it's possible to do delegatio= n, either locally or by token exchange with AS-RS.=C2=A0 All delegations ar= e potentially sub-scoped, but you may also want to delegate with full scope= to have a separately revocable access token.

    =C2= =A0 Here's an example of how things work in a capability oriented syste= m.
    1. Someone, the service owner, creates a service.
    2. The service owner contracts with an policy agent (AS-RS) to create and= manage access tokens for that service (RS).
    3. A person wishing to cr= eate a resource at RS uses their user agent (RO) to contact the service own= er's policy agent (AS-RS) and gets back an access token for that resour= ce.
    4. That user agent (RO) can=C2=A0
      1. use that access toke= n to invoke the resource, or
      2. delegate an access token to a client o= f the user agent's (RO) choice, or
      3. contract with a policy agent= (AS-RO) to manage those delegations on behalf of the user agent (RO), or
      4. specify a policy with the service's policy agent (AS-RS).
      5. A client can contact any holder of the access token (the user agent = (RO) or its policy agent (AS-RO)) or the service's policy agent (AS-RS)= to get a delegated access token.
      6. That client can delegate that tok= en to another client.
      7. Another user agent (RO') can contact any = holder of the access token or the service's policy agent (AS-RS) to get= a delegated access token.
      8. The other user agent (RO') can=C2=A0=
        1. use that access token to invoke the resource, or
        2. deleg= ate it to a client of its choice, or
        3. contract with a policy agent = (AS-RO') of its choosing to manage those delegations on its behalf, or<= /li>
        4. specify a policy with the service's policy agent (AS-RS).
          5. <= /ol>
        5. and so on
    When any of these computati= onal agents, user agents (ROs) or clients acting on their behalf, invokes t= he resource, AS-RS verifies that the access token is a valid delegation, i.= e., proper sub-scoping, hasn't been revoked, and that it authorizes the= request being made before telling the service (RS) to honor the request.= =C2=A0 At no point does the service's policy agent (AS-RS) know which c= omputational agent did any particular delegation.=C2=A0 (Token exchange can= be done as anonymously as possible.)=C2=A0 In particular, the policy agent= s (AS-RO) need not be the same, or even compatible with, the service's = policy agent (AS-RS).=C2=A0 GNAP specifies the protocol between requesters,= invokers, delegators (for token exchange) of tokens and AS-RS.=C2=A0 That = protocol need not be used between user agents (RO), clients, or other polic= y agents (AS-RO), but it is likely to be.

    =C2=A0--= -----------
    Alan Karp

    =

    = On Thu, Mar 25, 2021 at 5:45 AM Justin Richer <jricher@mit.edu> wrote:
    The way I=E2=80=99m thinkin= g about Adrian=E2=80=99s use case is that what we=E2=80=99re calling the = =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an =E2=80=9CAS=E2=80=9D in the tradit= ional OAuth/GNAP sense, at least not exactly. This is the agent that the RO= can use to set policies and manage consent on their behalf, and I=E2=80=99= ve been arguing that it fits better into this vaguely-defined =E2=80=9Cinte= raction component=E2=80=9D aspect of the current AS definition, and it=E2= =80=99s not currently separated from the AS definition. The =E2=80=9CAS-RS= =E2=80=9D maps to what we=E2=80=99d call the =E2=80=9CAS=E2=80=9D in OAuth/= GNAP traditionally, it=E2=80=99s what the RS trusts to issue tokens. In tra= ditional OAuth the AS-RO and AS-RS are always the same thing, from a functi= onal protocol perspective. An important point here is that from a client=E2= =80=99s perspective, they=E2=80=99re only talking to the AS-RS since that= =E2=80=99s where the client gets its tokens, because at the end of the day = the client just wants to call the API at the RS and doesn=E2=80=99t care ho= w that happens (from a protocol standpoint).=C2=A0

    Note = well: Even thought I don=E2=80=99t believe that =E2=80=9CAS-RO=E2=80=9D is = an authorization server at all, I=E2=80=99m going to keep using that term b= elow for consistency with previous discussion.

    So = we have these fundamental relationships around getting the client to access= the RS:

    1. RS trusts=C2=A0AS-RS=C2=A0to issue tok= ens that RS will accept, validate, and process for requests from client
    2. Client trusts=C2=A0AS-RS=C2=A0to issue tokens that client can use= at RS
    3. RO trusts RS to protect RO=E2=80=99s api through delega= ted access

    On top of that, we=E2=80=99ve got some = additional aspects that we=E2=80=99re discussing:

    = 4. RO trusts=C2=A0AS-RO=C2=A0to manage RO=E2=80=99s policies at runtime
    5.=C2=A0AS-RS=C2=A0trusts=C2=A0AS-RO=C2=A0to assert RO=E2=80=99s pol= icies for access to RS
    6. Client trusts whatever=C2=A0AS-RS=C2=A0= sends client to deal with, including possibly RO-AS at runtime, because of = (2)

    What I have been saying is that 4/5/6 are opti= onal details of how RS-AS runs things, and I think this also maps with Adri= an=E2=80=99s view of choice, since if my RS=E2=80=99s AS-RS doesn=E2=80=99t= allow me to plug in my own AS-RO then I would be motivated to pick a diffe= rent RS who=E2=80=99s AS-RS lets me do just that. The same way I=E2=80=99d = pick a different RS if their surrounding services didn=E2=80=99t accept my = preferred federation login and I didn=E2=80=99t want to make another accoun= t. Of course, market forces being as they are, I might not have much of an = actionable choice in RS, but GNAP can=E2=80=99t change that.=C2=A0

    What we can do is make it possible for AS-RS to talk to AS= -RO, both in philosophy of the protocol design and in concrete hooks to sup= port (6) above.=C2=A0

    Separately, we can approach = the issue of making 1/2 above more dynamic. This was UMA2=E2=80=99s =E2=80= =9Cfederated authorization=E2=80=9D approach, and is behind a lot of the = =E2=80=9Cbring your own AS=E2=80=9D models out there. The problem with thes= e is that we know from many years of experience that most RS=E2=80=99s aren= =E2=80=99t interested in doing anything of the sort.

    So with GNAP we can instead allow 4/5/6 to vary in a predictable and con= sistent way, letting the RS keep control over 1/2, thereby enabling choice = in (3). We don=E2=80=99t have to be the ones who define the all of the deta= ils of every permutation of (5) to enable this, though. Some of this is goi= ng to be configuration out of band, some of it=E2=80=99s going to be commun= ication at runtime. This is where VC=E2=80=99s, ZCAPs, CHAPI, DIDComm, FIDO= , and a whole swath of other tech can come in and help out. I don=E2=80=99t= think we need to put all the details for using these into core, nor do I t= hink we=E2=80=99ll pull of The Great And Ultimate Abstraction for using the= se and other approaches. But we can at least start talking about =E2=80=9CA= S-RS=E2=80=9D in such a way that it no longer assumes it=E2=80=99s always t= he same party dealing with the RO directly.

    =C2=A0= =E2=80=94 Justin

    On Mar 25, 2021= , at 6:40 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    <= div dir=3D"ltr">To reframe it closer to GNAP:
    - AS =3D AS-RO, that'= s where you find the RO policies. The AS issues access tokens to the client= .
    - the RO policies could be a) defined locally or b) in relation= ship with the RS

    There have been several ideas rel= ated to the AS-RS relationship b:
    b1) the RS issues capabilit= ies (which can be further attenuated by the RO)
    b2) Adrian also d= iscussed a DID based solution
    b3) there was also an alternative A= CL proposal from Denis (+ preflight)

    Fabien
    <= div>

    On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault <fabien.imbault@gmail= .com> wrote:
    Ok so I get you correctly:=C2=A0
    - what matters is= the RQ (could be a RO or a end-user or both : we don't really care at = a high-level, they're all treated as entities that make a request)
    - the policy is able to handle those different cases, based on its ow= n internal delegation protocol
    - currently that requires AS-RS an= d AS-RO, but maybe it can be simplified

    To answer = to Denis, here's what I understood:
    - RO trusts AS-RS (and th= en handles its own policies within AS-RO)
    - end-user trusts A= S-RO (through its client)

    Could probably work but = that's a fairly different model compared to OAuth2 (and of today's = GNAP), with different frontiers between the AS and the RS.=C2=A0
    =
    Please do not hesitate to correct me if I'm wrong.
    =

    Fabien=C2=A0

    =
    On Thu, Mar 25, 2021 at 9:26 AM Adria= n Gropper <a= gropper@healthurl.com> wrote:
    I believe there are alternatives to = having two kinds of ASs. The problem may be a side-effect of deciding to sw= itch away form treating the RO as different from the RQ. That leads to down= stream privacy issues. Our desire for architectural simplicity is admirable= but that may have been a step too far.

    There may also be solutions based on different types of tok= ens, as in different capabilities (tokens signed by the RS) vs. tokens sign= ed by the AS. I=E2=80=99m not sure about that but Alan might have more to s= ay.

    Adrian
    On Thu, M= ar 25, 2021 at 4:15 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thank= s. The general problem statement is clear.

    The=C2=A0prop= osed solution a bit less (to me). I understood that from point 2, Alan invo= lves 2 ASs. You said : "There=E2=80= =99s no obvious reason to have two types of ASs".=C2=A0Do you s= ee an alternative ?

    Regarding the last item,= I don't think that naming RQ by end-user created the problem. It might= just highlight the asymmetry,=C2=A0which fundamentally exists.=C2=A0

    Fabien=


    On Thu, Mar 25, 2021 at 8:48 AM Adrian Groppe= r <agropper@= healthurl.com> wrote:
    Recap:
    1 - Justin (I = think) introduced the idea of an AS on the RS trust boundary side.
    2 - I said the RO should not have to share policies with the= RS.
    3 - Alan invented the concept of AS-RO and AS-R= S to separate two kinds of PDPs.=C2=A0

    The thing is that step 2 is not symmetrical. The RO has a le= gitimate privacy interest in keeping their policies private and minimizing = the leakage of information about requests that are posed against those poli= cies.=C2=A0

    The RS, on t= he other hand, should be publishing its policies (e.g. what it=E2=80=99s se= lling or what jurisdiction it=E2=80=99s in or what tokens or scopes it supp= orts). The RS has no obvious privacy interest in GNAP. It=E2=80=99s just an= enforcer.

    There is one = other privacy interest to consider around the RS and that is the requesting= party (the end-user that is not the RO :-) might prefer to share attribute= s with the RS instead of the RO or something controlled by the RO. This cas= e could be an =E2=80=9Cextension=E2=80=9D to GNAP and might result in a spl= it AS as a solution. This problem was introduced when the editors decided t= o replace RQ with end-user. Obviously, the RO end-user has no privacy inter= ests relative to itself.

    Adrian




    On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault <fabien.imbault@g= mail.com> wrote:
    I was referring to "By my definition, this model has two ASs since both are= processing requests into tokens". If there's no reason to have 2 = types of ASs, that's fine then.=C2=A0
    But I'm a bit lost in where we stand with the id= ea.=C2=A0

    Could you recap?=C2=A0<= /font>

    Fabien=C2= =A0

    Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper <= agropper@health= url.com> a =C3=A9crit=C2=A0:
    There=E2=80=99s no obvious reason to = have two types of ASs. Any AS that is executing the policies of the RS can = look to GNAP like the RS itself. Why would GNAP expose that interface to an= yone?=C2=A0

    Adrian
    =

    O= n Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault <fabien.imbault@gmai= l.com> wrote:
    Note : I'm not sure that's a good idea, but = having 2 types of ASs is not that easy to grasp.

    Fabien=C2=A0

    Le jeu. 25 mar= s 2021 =C3=A0 08:07, Fabien Imbault <fabien.imbault@gmail.com&= gt; a =C3=A9crit=C2=A0:
    The purpose of either handling policies locally o= r delegating them to the RO agent.=C2=A0

    Le jeu. 25 mars 2021 =C3=A0 08:04, = Adrian Gropper <agropper@healthurl.com> a =C3=A9cr= it=C2=A0:
    What purpose would be served by GNAP splitting the AS into two = components?

    Adrian=C2=A0=

    On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbau= lt <fabien.imbault@gmail.com> wrote:<= br>
    Isn't the AS-RO a component of the AS? Same idea as the interact comp= onent, it functionnally belongs to the AS role but could be deployed either= as a monolith or as a separate component?

    Fabien

    Le jeu. 25 mars 2021 =C3= =A0 04:26, Adrian Gropper <agropper@healthurl.= com> a =C3=A9crit=C2=A0:
    Yes, but I would say it=E2=80=99s not the= RO that wants the access token. It=E2=80=99s the RO that wants the client = making the request to get an access token.=C2=A0
    Adrian

    On Wed, Mar 24, 2021 at 11:22 PM Alan K= arp <alanhkarp@gmail.com> wrote= :
    Adrian Gropper &l= t;agropper@healthurl.com> wrote= :

    In this design, the AS is the AS-RS and = the agent is the AS-RO. By my definition, this model has two ASs since both= are processing requests into tokens. The problem with this is complexity a= nd privacy. The RO may not want to share the request information with the A= S-RS.

    More precisely, RO has no choice but to present the required information= to AS-RS if RO wants an access token.=C2=A0 However, RO does not want AS-R= S to know the policy by which RO delegates tokens.=C2=A0 That's why RO = uses AS-RO for those delegations.

    --------------<= br>Alan Karp


    On Wed, Mar 24, 2021 at = 7:41 PM Adrian Gropper <agropper@he= althurl.com> wrote:
    Thank you for creating the iss= ue. My definition of AS is independent of AS-RO or AS-RS.=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecom= ment-806280421 I also agree with Alan's definition based on delegat= ion. An AS-RS would be a delegate of the RS.=C2=A0
    Based on that, I see it as obvious=C2=A0that the policy has to= be accessible (defined locally?) in order for it to be run as the code tha= t turns a request into an access token.=C2=A0

    The = only other possibility is that the request is packaged by the AS and sent e= lsewhere (an agent) for evaluation against policy and a proto-token returne= d. In that case the AS is acting as a proxy and the PDP is elsewhere. I can= imagine that an AS-RS would behave this way so that the proto-token could = be turned into an access token by the AS-RS. Isn't this what Justin is = proposing? In this design, the AS is the AS-RS and the agent is the AS-RO. = By my definition, this model has two ASs since both are processing requests= into tokens. The problem with this is complexity and privacy. The RO may n= ot want to share the request information with the AS-RS.

    Adrian

    On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Isn't that what the AS is supposed to be, only with the caveat th= at the policy is defined locally?=C2=A0

    Fabien=C2=A0


    Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp <= alanhkarp@gmail.com> a =C3=A9crit= =C2=A0:
    AS-RO is an AS that RO trusts to delegate RO'= s access tokens according to RO's policies.=C2=A0=C2=A0

    --------------
    Alan Karp


    On W= ed, Mar 24, 2021 at 9:36 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan and = Adrian,

    I've created issue AS-RO policy delegation (= https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to = capture your input.=C2=A0
    A first question that arises: can we gi= ve a definition to AS-RO?

    Thanks
    Fabien<= /div>

    On Tue, Mar 23, 2021 at 4:15 PM Alan Karp <alanhkarp@gmail.com> wrote:
    <= div dir=3D"ltr">
    Fabi= en Imbault <fabien.imb= ault@gmail.com> wrote:
    Hi Alan,=C2=A0

    Yes, but i= n that flow, the token relationship between AS-RS and AS-RO is only secure = if the tokens issued by AS-RS are cryptographically attenuable in the first= place.=C2=A0
    =C2=A0
    Attenuated delegation is a requirement, but that doesn't have to be d= one cryptographically.=C2=A0 Token exchange works just fine.=C2=A0 SPKI and= zcap-ld are examples of the crypto approach, and we used token exchange in= the system for HP.

    --------------
    Alan Ka= rp


    On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault <fabien.imbault@gmail.com>= ; wrote:
    Hi Alan,=C2=A0

    Yes, but in that flow, the toke= n relationship between AS-RS and AS-RO is only secure if the tokens issued = by AS-RS are cryptographically attenuable in the first place.=C2=A0

    Fabien

    On Mon, Mar 22, 2021 at 9:26 PM Alan Karp <= ;alanhkarp@gmail.com> w= rote:
    Justin Rich= er <jricher@mit.edu> wro= te:
    But with all that in mind, I think the key here is going to be= looking at what the inputs to the AS are, and how those can be defined in = an interoperable way for AS=E2=80=99s that can accept them. I think there= =E2=80=99s a lot of room for innovation and flexibility here that doesn=E2= =80=99t break the trust model or core use cases. If I have an AS-RS set tha= t won=E2=80=99t accept my favorite flavor of policy engine inputs, then I c= an decide not to use that one. But this is a very different question than s= aying the RS itself needs to accept my own AS =E2=80=94 and we can=E2=80=99= t keep conflating these two models.

    =
    I agree.=C2=A0 The point of having an AS-RO is to allow RO to specify = a policy for which of RO's access tokens should be delegated under what= conditions.=C2=A0 AS-RS should not need to understand those policies.=C2= =A0 The flow would be
    • RO contacts AS-RS and gets one or m= ore access tokens.
    • RO delegates one or more of those tokens, potent= ially sub-scoped, to AS-RO.
    • A different user contacts AS-RO to get = a potentially sub-scoped access token from AS-RO.
    • That user present= s the access token delegated by AS-RO when invoking the resource.
    =
    AS-RS only needs to verify that the delegation chain is leg= itimate, e.g., no increase in scope, and that it grants permission for the = request being made.=C2=A0 AS-RS does not need to understand the policy behi= nd granting the delegation by AS-RO.

    ------------= --
    Alan Karp


    On Mon, Mar 22, 2021 at 11:40 AM Justin Rich= er <jricher@mit.edu> wro= te:
    Adrian,=

    I think this shows the problem with the terminology as = it=E2=80=99s been applied in this conversation, which I=E2=80=99ve tried to= shine light on before. What you and others are calling the =E2=80=9CRS=E2= =80=9D is really the =E2=80=9CAS and RS working together=E2=80=9D =E2=80=94= everything to the right of the line. When Denis had brought up =E2=80=9Cel= iminating the AS=E2=80=9D in another thread, what he=E2=80=99d really done = is labeled everything to the right of the line as the =E2=80=9CRS=E2=80=9D.= Of course, the irony here is that everything to the right of the line used= all be called the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80=9D = in the OAuth 1 days. As you say below, I don=E2=80=99t want the client to h= ave visibility on what happens on that side.=C2=A0

    Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the diagram i= s not the AS, as far as GNAP is concerned. It does not issue an access toke= n that the RS will accept. The elements to the left of the line could be a = lot of things, but they are NOT the AS =E2=80=94 by definition. The client = lives over on the left, but so do any external inputs to the AS. These coul= d be policy inputs on behalf of the RO, they could be presentation artifact= s, they could be federated logins, they could be the output of policy decis= ions. How the AS comes to trust those things is up to the AS=E2=80=99s impl= ementation. It=E2=80=99s something we can talk about, but ultimately GNAP w= on=E2=80=99t be in any position to dictate because in practice some AS=E2= =80=99s are simply going to internalize all policies and we will never succ= essfully force those open.=C2=A0

    But with all that= in mind, I think the key here is going to be looking at what the inputs to= the AS are, and how those can be defined in an interoperable way for AS=E2= =80=99s that can accept them. I think there=E2=80=99s a lot of room for inn= ovation and flexibility here that doesn=E2=80=99t break the trust model or = core use cases. If I have an AS-RS set that won=E2=80=99t accept my favorit= e flavor of policy engine inputs, then I can decide not to use that one. Bu= t this is a very different question than saying the RS itself needs to acce= pt my own AS =E2=80=94 and we can=E2=80=99t keep conflating these two model= s.

    So to me, GNAP can support a Zero Trust Archite= cture by LEVERAGING the AS, not by subsuming or eliminating it. It is in fa= ct the AS, not the client and not the RS, that will request and consume the= results of a privacy-preserving zero-trust policy query thing. Anything th= at happens downstream from that is of little concern to the zero-trust comp= onents because, as you point out, it=E2=80=99s on the =E2=80=9Cother side= =E2=80=9D of the line.=C2=A0

    I think we got this b= asic component model pretty right in OAuth: the AS and RS and client workin= g together. Where OAuth misses the mark is the assumption that the user has= to log in to the AS through a webpage and interact directly, thereby provi= ng they=E2=80=99re the RO. It=E2=80=99s this latter space where I think we = can both push innovation and also address the important and compelling use = cases like the ones you=E2=80=99re bringing.

    =C2= =A0=E2=80=94 Justin

    On Mar 22, 2= 021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I'm sorry, Justin. As a Resource Owner, I look at the RS trust bound= ary (the dotted line in the diagram) as being the RS. I don't expect an= y visibility into what's going on on the=C2=A0right.=C2=A0

    My problem with the framing you propose is that requests are going t= o the RS (or the AS-RS) and I don't want to share my policies with the = AS-RS. I want to keep the RS and AS-RS as ignorant as possible.
    <= br>
    Adrian

    On Mon, Mar 22, 2021 at 1:48 PM Justin Richer <= ;jricher@mit.edu> wrote:
    Adrian,
    <= br>
    What you=E2=80=99re discussing below, in terms of logging in = to a site, is not approaching the RS. You are in fact approaching the clien= t, and identifying both the AS and RS to the client. The client is a client= of your identity in this model, and the RS is part of the identity = provider. It=E2=80=99s really important that we don=E2=80=99t conflate the = RS and client in this way as it leads to a lot of confusion downstream and = a lot of broken trust boundaries.

    With that model = in mind, approaching the =E2=80=9CRS" and providing it your identity i= s really just a case of the =E2=80=9Cfederated login to AS=E2=80=9D pattern= that we discussed on the WG call. The user here approaches an RS, which ha= s its own AS. To share things from this RS, the RO has to authenticate to t= he RS=E2=80=99s AS. This particular AS allows the RO to do so using an exte= rnal identity =E2=80=94 in which case, the AS is now a =E2=80=9Cclient=E2= =80=9D of a separate, disconnected (but layered) delegation. The ultimate c= lient that eventually calls the RS down the way may or may not know about t= hese layers.=C2=A0

    <PastedGraphic-1.png>
    This same AS, which is closely tied to the RS and trusted by the RS, mig= ht also take in FIDO credentials, or DIDs, or any number of other proof mec= hanisms. The output of this is an access token the RS trusts, but the input= is up to the AS. The RS is not what you=E2=80=99re logging in to.

    =C2=A0=E2=80=94 Justin

    On Mar 22, 2021, at 1:28 PM, Adrian Gropper <agropper@healthurl.com> wrote:
    I too am in favor of avoiding consolidation and corr= elation. Right now, when I approach a service provider (RS) for the first t= ime, I'm offered the opportunity to identify my persona as: email, sign= -in with Google, Facebook, or Apple. I know there are people who try to cre= ate one-off email addresses but that is mostly a waste of time.=C2=A0
    <= br>
    So, along come FIDO2 and DID wallets to the rescue. Now, in t= heory, I have a way to start out my RS relationship pseudonymously.=C2=A0

    When I want my resource to be discovered or shared = I will post that RS URL including my pseudonym. If I then want to introduce= a mediator=C2=A0in front of my AS or messaging service=C2=A0endpoint, I ha= ve that option. If I want to keep requests away from the mediator, I would = publish an encryption key along with my pseudonym.

    - Adrian



    On Mon, Mar 22, 2021 at 9:55 A= M Justin Richer <jricher@mit.ed= u> wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhk= arp@gmail.com> shared a talk about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-= gnap/gnap-core-protocol/issues/145#issuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --
    TXAuth 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
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.= ietf.org/mailman/listinfo/txauth


    --0000000000007f68a005be5fa720-- From nobody Thu Mar 25 14:50:36 2021 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 023B13A0AB4 for ; Thu, 25 Mar 2021 14:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 EzRVNM4Exxgl for ; Thu, 25 Mar 2021 14:50:29 -0700 (PDT) Received: from mail-vs1-f41.google.com (mail-vs1-f41.google.com [209.85.217.41]) (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 831AC3A0AB2 for ; Thu, 25 Mar 2021 14:50:29 -0700 (PDT) Received: by mail-vs1-f41.google.com with SMTP id h4so40493vsl.11 for ; Thu, 25 Mar 2021 14:50:29 -0700 (PDT) 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=Bwsg1v/vYOyil9soInWPtSPSXUKwbWHWoQC8bzRREBo=; b=aRXQ+lb0inKhTOy/Nx1bwyySFZQzuH6KIE3BlhrMyeBavmXIixV9rDQbyQo5wKVvHq f7QCtxur3HkU7DqYeulmrPGt+SmFPag4Sz+nRk5lvelsgwknDUn/KhkatPwuNhQ8YmVQ N1xI8VMEr4yxc5qFL9sxacvJ3apareB8DTNcQwfaNxITEAWS6f0poM+x3efPzk2LvXTs wOa1smJP3Zhn+X/BxP/z0ip+ZotF+t0LvHck9phAlfiL5VdYnoOZgCXbc8KcqxAWldf7 112wMcIM9k8HCKEMVFFnRVMlDwwmj/Ek7ye8f+4+wbyHdHbln6dTL2H3eRUrHmi2ws7W vZfQ== X-Gm-Message-State: AOAM533YZ5OUsRxsxbt2b+R3aGVrgW0WkGFFa1yxYGwpvE6znHKzPDWA 4TC/Yq3NVsGmR7+qGoDQPwFm5EMEO39cYjZ26J4TQ7MtkmYjPQ== X-Google-Smtp-Source: ABdhPJwT5zNe2bP0ys9ap76xokG66s8zRxpA0z2L0jYd3jpK6Q/ZIXMe5IYyF8urutZdKvs5608QjfsyiP5HAE0z9T4= X-Received: by 2002:a67:cb87:: with SMTP id h7mr6812514vsl.33.1616709028064; Thu, 25 Mar 2021 14:50:28 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> In-Reply-To: From: Adrian Gropper Date: Thu, 25 Mar 2021 17:50:15 -0400 Message-ID: To: Alan Karp Cc: Justin Richer , GNAP Mailing List , Fabien Imbault , Mark Miller , Benjamin Kaduk Content-Type: multipart/alternative; boundary="00000000000052b56f05be63678e" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 21:50:35 -0000 --00000000000052b56f05be63678e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My issue is with Alan's: "7. Another user agent (RO') can contact any holder of the access token or the service's policy agent (AS-RS) to get a delegated access token." I would prefer "7A. Another user agent (RO') can contact any holder of the access token." by default so that the AS-RS does not see the requests. In other words, the RS and AS-RS only see access tokens. The requests (from RO') that resulted in an access token are none of their business. The reality is that RO' can discover a resource RS and can share whatever information with RS-AS they want and the RO may not even know about it unless the RS decides to let them know somehow. This seems to be a drawback of the capabilities approach. In terms of privacy and control, I, as the RO, want a contract with the RS that says that I or my agent (AS-RO) must sign an access token. This is a fundamental audit requirement. Without it, a rogue RS and AS-RS can do all sorts of things and the RO would never know. I understand that a rogue RS might not support an honest contemporaneous log of access tokens presented so there's a trust issue here that I seems unavoidable unless I specify in my RO-RS contract that they use a separate contemporaneous log such as AS-RO for every access token presented and risk being sued if they process an access token without also updating the separate log. - Adrian On Thu, Mar 25, 2021 at 1:22 PM Alan Karp wrote: > Justin Richer wrote: > >> Hi Alan, >> >> In all of my discussion, and in the spec itself, the RO is the :entity: >> in charge of approving rights. They=E2=80=99re probably a person. It mig= ht be >> software that makes a policy decision in some way, or a corporate entity= , >> or something like that. But it=E2=80=99s not assumed to be a computation= al agent in >> the terms of the protocol itself. Would that recast what you=E2=80=99re = saying >> below? >> > > Hmmm. I guess not. It's just that the person would be using some UI to > express their decisions to what I called the user agent. That model fits > in very nicely with what we did with Polaris, our virus safe computing > environment for Windows XP, https://dl.acm.org/doi/10.1145/1151030.115103= 3. > The person would click on the icon for a Word file, and an instance of Wo= rd > would open with only the permission needed to edit that one file. Same > thing here. The client could ask for permission to use the resource, or > permission could be granted implicitly when the user selects a resource > associated with a specific client. > > -------------- > Alan Karp > > > On Thu, Mar 25, 2021 at 9:53 AM Justin Richer wrote: > >> Hi Alan, >> >> In all of my discussion, and in the spec itself, the RO is the :entity: >> in charge of approving rights. They=E2=80=99re probably a person. It mig= ht be >> software that makes a policy decision in some way, or a corporate entity= , >> or something like that. But it=E2=80=99s not assumed to be a computation= al agent in >> the terms of the protocol itself. Would that recast what you=E2=80=99re = saying >> below? >> >> =E2=80=94 Justin >> >> On Mar 25, 2021, at 12:36 PM, Alan Karp wrote: >> >> There seems to be some confusion about how AS-RO comes into the picture, >> probably because of the "AS" part. I'm going to try to clear up that >> confusion by more carefully explaining what I mean. >> >> I'm assuming that RO is a computational agent representing the person wh= o >> is the resource owner, something called the "user agent" in operating >> systems lingo. I'm also assuming that it's possible to do delegation, >> either locally or by token exchange with AS-RS. All delegations are >> potentially sub-scoped, but you may also want to delegate with full scop= e >> to have a separately revocable access token. >> >> Here's an example of how things work in a capability oriented system. >> >> 1. Someone, the service owner, creates a service. >> 2. The service owner contracts with an policy agent (AS-RS) to create >> and manage access tokens for that service (RS). >> 3. A person wishing to create a resource at RS uses their user agent >> (RO) to contact the service owner's policy agent (AS-RS) and gets bac= k an >> access token for that resource. >> 4. That user agent (RO) can >> 1. use that access token to invoke the resource, or >> 2. delegate an access token to a client of the user agent's (RO) >> choice, or >> 3. contract with a policy agent (AS-RO) to manage those >> delegations on behalf of the user agent (RO), or >> 4. specify a policy with the service's policy agent (AS-RS). >> 5. A client can contact any holder of the access token (the user >> agent (RO) or its policy agent (AS-RO)) or the service's policy agent >> (AS-RS) to get a delegated access token. >> 6. That client can delegate that token to another client. >> 7. Another user agent (RO') can contact any holder of the access >> token or the service's policy agent (AS-RS) to get a delegated access= token. >> 8. The other user agent (RO') can >> 1. use that access token to invoke the resource, or >> 2. delegate it to a client of its choice, or >> 3. contract with a policy agent (AS-RO') of its choosing to manage >> those delegations on its behalf, or >> 4. specify a policy with the service's policy agent (AS-RS). >> 9. and so on >> >> When any of these computational agents, user agents (ROs) or clients >> acting on their behalf, invokes the resource, AS-RS verifies that the >> access token is a valid delegation, i.e., proper sub-scoping, hasn't bee= n >> revoked, and that it authorizes the request being made before telling th= e >> service (RS) to honor the request. At no point does the service's polic= y >> agent (AS-RS) know which computational agent did any particular >> delegation. (Token exchange can be done as anonymously as possible.) I= n >> particular, the policy agents (AS-RO) need not be the same, or even >> compatible with, the service's policy agent (AS-RS). GNAP specifies the >> protocol between requesters, invokers, delegators (for token exchange) o= f >> tokens and AS-RS. That protocol need not be used between user agents (R= O), >> clients, or other policy agents (AS-RO), but it is likely to be. >> >> ------------- >> Alan Karp >> >> >> On Thu, Mar 25, 2021 at 5:45 AM Justin Richer wrote: >> >>> The way I=E2=80=99m thinking about Adrian=E2=80=99s use case is that wh= at we=E2=80=99re calling >>> the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an =E2=80=9CAS=E2=80=9D in th= e traditional OAuth/GNAP sense, at least not >>> exactly. This is the agent that the RO can use to set policies and mana= ge >>> consent on their behalf, and I=E2=80=99ve been arguing that it fits bet= ter into >>> this vaguely-defined =E2=80=9Cinteraction component=E2=80=9D aspect of = the current AS >>> definition, and it=E2=80=99s not currently separated from the AS defini= tion. The >>> =E2=80=9CAS-RS=E2=80=9D maps to what we=E2=80=99d call the =E2=80=9CAS= =E2=80=9D in OAuth/GNAP traditionally, it=E2=80=99s >>> what the RS trusts to issue tokens. In traditional OAuth the AS-RO and >>> AS-RS are always the same thing, from a functional protocol perspective= . An >>> important point here is that from a client=E2=80=99s perspective, they= =E2=80=99re only >>> talking to the AS-RS since that=E2=80=99s where the client gets its tok= ens, because >>> at the end of the day the client just wants to call the API at the RS a= nd >>> doesn=E2=80=99t care how that happens (from a protocol standpoint). >>> >>> Note well: Even thought I don=E2=80=99t believe that =E2=80=9CAS-RO=E2= =80=9D is an authorization >>> server at all, I=E2=80=99m going to keep using that term below for cons= istency with >>> previous discussion. >>> >>> So we have these fundamental relationships around getting the client to >>> access the RS: >>> >>> 1. RS trusts AS-RS to issue tokens that RS will accept, validate, and >>> process for requests from client >>> 2. Client trusts AS-RS to issue tokens that client can use at RS >>> 3. RO trusts RS to protect RO=E2=80=99s api through delegated access >>> >>> On top of that, we=E2=80=99ve got some additional aspects that we=E2=80= =99re discussing: >>> >>> 4. RO trusts AS-RO to manage RO=E2=80=99s policies at runtime >>> 5. AS-RS trusts AS-RO to assert RO=E2=80=99s policies for access to RS >>> 6. Client trusts whatever AS-RS sends client to deal with, including >>> possibly RO-AS at runtime, because of (2) >>> >>> What I have been saying is that 4/5/6 are optional details of how RS-AS >>> runs things, and I think this also maps with Adrian=E2=80=99s view of c= hoice, since >>> if my RS=E2=80=99s AS-RS doesn=E2=80=99t allow me to plug in my own AS-= RO then I would be >>> motivated to pick a different RS who=E2=80=99s AS-RS lets me do just th= at. The same >>> way I=E2=80=99d pick a different RS if their surrounding services didn= =E2=80=99t accept my >>> preferred federation login and I didn=E2=80=99t want to make another ac= count. Of >>> course, market forces being as they are, I might not have much of an >>> actionable choice in RS, but GNAP can=E2=80=99t change that. >>> >>> What we can do is make it possible for AS-RS to talk to AS-RO, both in >>> philosophy of the protocol design and in concrete hooks to support (6) >>> above. >>> >>> Separately, we can approach the issue of making 1/2 above more dynamic. >>> This was UMA2=E2=80=99s =E2=80=9Cfederated authorization=E2=80=9D appro= ach, and is behind a lot of >>> the =E2=80=9Cbring your own AS=E2=80=9D models out there. The problem w= ith these is that we >>> know from many years of experience that most RS=E2=80=99s aren=E2=80=99= t interested in >>> doing anything of the sort. >>> >>> So with GNAP we can instead allow 4/5/6 to vary in a predictable and >>> consistent way, letting the RS keep control over 1/2, thereby enabling >>> choice in (3). We don=E2=80=99t have to be the ones who define the all = of the >>> details of every permutation of (5) to enable this, though. Some of thi= s is >>> going to be configuration out of band, some of it=E2=80=99s going to be >>> communication at runtime. This is where VC=E2=80=99s, ZCAPs, CHAPI, DID= Comm, FIDO, >>> and a whole swath of other tech can come in and help out. I don=E2=80= =99t think we >>> need to put all the details for using these into core, nor do I think w= e=E2=80=99ll >>> pull of The Great And Ultimate Abstraction for using these and other >>> approaches. But we can at least start talking about =E2=80=9CAS-RS=E2= =80=9D in such a way >>> that it no longer assumes it=E2=80=99s always the same party dealing wi= th the RO >>> directly. >>> >>> =E2=80=94 Justin >>> >>> On Mar 25, 2021, at 6:40 AM, Fabien Imbault >>> wrote: >>> >>> To reframe it closer to GNAP: >>> - AS =3D AS-RO, that's where you find the RO policies. The AS issues >>> access tokens to the client. >>> - the RO policies could be a) defined locally or b) in relationship wit= h >>> the RS >>> >>> There have been several ideas related to the AS-RS relationship b: >>> b1) the RS issues capabilities (which can be further attenuated by the >>> RO) >>> b2) Adrian also discussed a DID based solution >>> b3) there was also an alternative ACL proposal from Denis (+ preflight) >>> >>> Fabien >>> >>> >>> On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault >>> wrote: >>> >>>> Ok so I get you correctly: >>>> - what matters is the RQ (could be a RO or a end-user or both : we >>>> don't really care at a high-level, they're all treated as entities tha= t >>>> make a request) >>>> - the policy is able to handle those different cases, based on its own >>>> internal delegation protocol >>>> - currently that requires AS-RS and AS-RO, but maybe it can be >>>> simplified >>>> >>>> To answer to Denis, here's what I understood: >>>> - RO trusts AS-RS (and then handles its own policies within AS-RO) >>>> - end-user trusts AS-RO (through its client) >>>> >>>> Could probably work but that's a fairly different model compared to >>>> OAuth2 (and of today's GNAP), with different frontiers between the AS = and >>>> the RS. >>>> >>>> Please do not hesitate to correct me if I'm wrong. >>>> >>>> Fabien >>>> >>>> On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper >>>> wrote: >>>> >>>>> I believe there are alternatives to having two kinds of ASs. The >>>>> problem may be a side-effect of deciding to switch away form treating= the >>>>> RO as different from the RQ. That leads to downstream privacy issues.= Our >>>>> desire for architectural simplicity is admirable but that may have be= en a >>>>> step too far. >>>>> >>>>> There may also be solutions based on different types of tokens, as in >>>>> different capabilities (tokens signed by the RS) vs. tokens signed by= the >>>>> AS. I=E2=80=99m not sure about that but Alan might have more to say. >>>>> >>>>> Adrian >>>>> >>>>> On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Thanks. The general problem statement is clear. >>>>>> >>>>>> The proposed solution a bit less (to me). I understood that from >>>>>> point 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obvious= reason >>>>>> to have two types of ASs". Do you see an alternative ? >>>>>> >>>>>> Regarding the last item, I don't think that naming RQ by end-user >>>>>> created the problem. It might just highlight the asymmetry, which >>>>>> fundamentally exists. >>>>>> >>>>>> Fabien >>>>>> >>>>>> >>>>>> On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper < >>>>>> agropper@healthurl.com> wrote: >>>>>> >>>>>>> Recap: >>>>>>> 1 - Justin (I think) introduced the idea of an AS on the RS trust >>>>>>> boundary side. >>>>>>> 2 - I said the RO should not have to share policies with the RS. >>>>>>> 3 - Alan invented the concept of AS-RO and AS-RS to separate two >>>>>>> kinds of PDPs. >>>>>>> >>>>>>> The thing is that step 2 is not symmetrical. The RO has a legitimat= e >>>>>>> privacy interest in keeping their policies private and minimizing t= he >>>>>>> leakage of information about requests that are posed against those >>>>>>> policies. >>>>>>> >>>>>>> The RS, on the other hand, should be publishing its policies (e.g. >>>>>>> what it=E2=80=99s selling or what jurisdiction it=E2=80=99s in or w= hat tokens or scopes it >>>>>>> supports). The RS has no obvious privacy interest in GNAP. It=E2=80= =99s just an >>>>>>> enforcer. >>>>>>> >>>>>>> There is one other privacy interest to consider around the RS and >>>>>>> that is the requesting party (the end-user that is not the RO :-) m= ight >>>>>>> prefer to share attributes with the RS instead of the RO or somethi= ng >>>>>>> controlled by the RO. This case could be an =E2=80=9Cextension=E2= =80=9D to GNAP and might >>>>>>> result in a split AS as a solution. This problem was introduced whe= n the >>>>>>> editors decided to replace RQ with end-user. Obviously, the RO end-= user has >>>>>>> no privacy interests relative to itself. >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>> >>>>>>>> I was referring to "By my definition, this model has two ASs since >>>>>>>> both are processing requests into tokens". If there's no reason to= have 2 >>>>>>>> types of ASs, that's fine then. >>>>>>>> But I'm a bit lost in where we stand with the idea. >>>>>>>> >>>>>>>> Could you recap? >>>>>>>> >>>>>>>> Fabien >>>>>>>> >>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper < >>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>> >>>>>>>>> There=E2=80=99s no obvious reason to have two types of ASs. Any A= S that is >>>>>>>>> executing the policies of the RS can look to GNAP like the RS its= elf. Why >>>>>>>>> would GNAP expose that interface to anyone? >>>>>>>>> >>>>>>>>> Adrian >>>>>>>>> >>>>>>>>> On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault < >>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Note : I'm not sure that's a good idea, but having 2 types of AS= s >>>>>>>>>> is not that easy to grasp. >>>>>>>>>> >>>>>>>>>> Fabien >>>>>>>>>> >>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault < >>>>>>>>>> fabien.imbault@gmail.com> a =C3=A9crit : >>>>>>>>>> >>>>>>>>>>> The purpose of either handling policies locally or delegating >>>>>>>>>>> them to the RO agent. >>>>>>>>>>> >>>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper < >>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>> >>>>>>>>>>>> What purpose would be served by GNAP splitting the AS into two >>>>>>>>>>>> components? >>>>>>>>>>>> >>>>>>>>>>>> Adrian >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault < >>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Isn't the AS-RO a component of the AS? Same idea as the >>>>>>>>>>>>> interact component, it functionnally belongs to the AS role b= ut could be >>>>>>>>>>>>> deployed either as a monolith or as a separate component? >>>>>>>>>>>>> >>>>>>>>>>>>> Fabien >>>>>>>>>>>>> >>>>>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper < >>>>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>>>> >>>>>>>>>>>>>> Yes, but I would say it=E2=80=99s not the RO that wants the = access >>>>>>>>>>>>>> token. It=E2=80=99s the RO that wants the client making the = request to get an >>>>>>>>>>>>>> access token. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 11:22 PM Alan Karp < >>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Adrian Gropper wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In this design, the AS is the AS-RS and the agent is the >>>>>>>>>>>>>>>> AS-RO. By my definition, this model has two ASs since both= are processing >>>>>>>>>>>>>>>> requests into tokens. The problem with this is complexity = and privacy. The >>>>>>>>>>>>>>>> RO may not want to share the request information with the = AS-RS. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> More precisely, RO has no choice but to present the require= d >>>>>>>>>>>>>>> information to AS-RS if RO wants an access token. However,= RO does not >>>>>>>>>>>>>>> want AS-RS to know the policy by which RO delegates tokens.= That's why RO >>>>>>>>>>>>>>> uses AS-RO for those delegations. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper < >>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thank you for creating the issue. My definition of AS is >>>>>>>>>>>>>>>> independent of AS-RO or AS-RS. >>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/= 223#issuecomment-806280421 >>>>>>>>>>>>>>>> I also agree with Alan's definition based on delegation. A= n AS-RS would be >>>>>>>>>>>>>>>> a delegate of the RS. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Based on that, I see it as obvious that the policy has to >>>>>>>>>>>>>>>> be accessible (defined locally?) in order for it to be run= as the code that >>>>>>>>>>>>>>>> turns a request into an access token. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The only other possibility is that the request is packaged >>>>>>>>>>>>>>>> by the AS and sent elsewhere (an agent) for evaluation aga= inst policy and a >>>>>>>>>>>>>>>> proto-token returned. In that case the AS is acting as a p= roxy and the PDP >>>>>>>>>>>>>>>> is elsewhere. I can imagine that an AS-RS would behave thi= s way so that the >>>>>>>>>>>>>>>> proto-token could be turned into an access token by the AS= -RS. Isn't this >>>>>>>>>>>>>>>> what Justin is proposing? In this design, the AS is the AS= -RS and the agent >>>>>>>>>>>>>>>> is the AS-RO. By my definition, this model has two ASs sin= ce both are >>>>>>>>>>>>>>>> processing requests into tokens. The problem with this is = complexity and >>>>>>>>>>>>>>>> privacy. The RO may not want to share the request informat= ion with the >>>>>>>>>>>>>>>> AS-RS. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault < >>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Isn't that what the AS is supposed to be, only with the >>>>>>>>>>>>>>>>> caveat that the policy is defined locally? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp < >>>>>>>>>>>>>>>>> alanhkarp@gmail.com> a =C3=A9crit : >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> AS-RO is an AS that RO trusts to delegate RO's access >>>>>>>>>>>>>>>>>> tokens according to RO's policies. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault < >>>>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi Alan and Adrian, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I've created issue AS-RO policy delegation ( >>>>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issu= es/223) >>>>>>>>>>>>>>>>>>> to capture your input. >>>>>>>>>>>>>>>>>>> A first question that arises: can we give a definition >>>>>>>>>>>>>>>>>>> to AS-RO? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp < >>>>>>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Fabien Imbault wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Yes, but in that flow, the token relationship between >>>>>>>>>>>>>>>>>>>>> AS-RS and AS-RO is only secure if the tokens issued b= y AS-RS are >>>>>>>>>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Attenuated delegation is a requirement, but that >>>>>>>>>>>>>>>>>>>> doesn't have to be done cryptographically. Token exch= ange works just >>>>>>>>>>>>>>>>>>>> fine. SPKI and zcap-ld are examples of the crypto app= roach, and we used >>>>>>>>>>>>>>>>>>>> token exchange in the system for HP. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault < >>>>>>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Yes, but in that flow, the token relationship between >>>>>>>>>>>>>>>>>>>>> AS-RS and AS-RO is only secure if the tokens issued b= y AS-RS are >>>>>>>>>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp < >>>>>>>>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Justin Richer wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> But with all that in mind, I think the key here is >>>>>>>>>>>>>>>>>>>>>>> going to be looking at what the inputs to the AS ar= e, and how those can be >>>>>>>>>>>>>>>>>>>>>>> defined in an interoperable way for AS=E2=80=99s th= at can accept them. I think >>>>>>>>>>>>>>>>>>>>>>> there=E2=80=99s a lot of room for innovation and fl= exibility here that doesn=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>> break the trust model or core use cases. If I have = an AS-RS set that won=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine inputs, = then I can decide not to >>>>>>>>>>>>>>>>>>>>>>> use that one. But this is a very different question= than saying the RS >>>>>>>>>>>>>>>>>>>>>>> itself needs to accept my own AS =E2=80=94 and we c= an=E2=80=99t keep conflating these two >>>>>>>>>>>>>>>>>>>>>>> models. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I agree. The point of having an AS-RO is to allow >>>>>>>>>>>>>>>>>>>>>> RO to specify a policy for which of RO's access toke= ns should be delegated >>>>>>>>>>>>>>>>>>>>>> under what conditions. AS-RS should not need to und= erstand those >>>>>>>>>>>>>>>>>>>>>> policies. The flow would be >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> - RO contacts AS-RS and gets one or more access >>>>>>>>>>>>>>>>>>>>>> tokens. >>>>>>>>>>>>>>>>>>>>>> - RO delegates one or more of those tokens, >>>>>>>>>>>>>>>>>>>>>> potentially sub-scoped, to AS-RO. >>>>>>>>>>>>>>>>>>>>>> - A different user contacts AS-RO to get a >>>>>>>>>>>>>>>>>>>>>> potentially sub-scoped access token from AS-RO. >>>>>>>>>>>>>>>>>>>>>> - That user presents the access token delegated >>>>>>>>>>>>>>>>>>>>>> by AS-RO when invoking the resource. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> AS-RS only needs to verify that the delegation chain >>>>>>>>>>>>>>>>>>>>>> is legitimate, e.g., no increase in scope, and that = it grants permission >>>>>>>>>>>>>>>>>>>>>> for the request being made. AS-RS does not need to = understand the policy >>>>>>>>>>>>>>>>>>>>>> behind granting the delegation by AS-RO. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer < >>>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I think this shows the problem with the terminology >>>>>>>>>>>>>>>>>>>>>>> as it=E2=80=99s been applied in this conversation, = which I=E2=80=99ve tried to shine light >>>>>>>>>>>>>>>>>>>>>>> on before. What you and others are calling the =E2= =80=9CRS=E2=80=9D is really the =E2=80=9CAS and >>>>>>>>>>>>>>>>>>>>>>> RS working together=E2=80=9D =E2=80=94 everything t= o the right of the line. When Denis had >>>>>>>>>>>>>>>>>>>>>>> brought up =E2=80=9Celiminating the AS=E2=80=9D in = another thread, what he=E2=80=99d really done is >>>>>>>>>>>>>>>>>>>>>>> labeled everything to the right of the line as the = =E2=80=9CRS=E2=80=9D. Of course, the >>>>>>>>>>>>>>>>>>>>>>> irony here is that everything to the right of the l= ine used all be called >>>>>>>>>>>>>>>>>>>>>>> the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver= =E2=80=9D in the OAuth 1 days. As you say below, I don=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>> want the client to have visibility on what happens = on that side. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Note well: The Google+ logo labeled =E2=80=9CIdP=E2= =80=9D in the >>>>>>>>>>>>>>>>>>>>>>> diagram is not the AS, as far as GNAP is concerned.= It does not issue an >>>>>>>>>>>>>>>>>>>>>>> access token that the RS will accept. The elements = to the left of the line >>>>>>>>>>>>>>>>>>>>>>> could be a lot of things, but they are NOT the AS = =E2=80=94 by definition. The >>>>>>>>>>>>>>>>>>>>>>> client lives over on the left, but so do any extern= al inputs to the AS. >>>>>>>>>>>>>>>>>>>>>>> These could be policy inputs on behalf of the RO, t= hey could be >>>>>>>>>>>>>>>>>>>>>>> presentation artifacts, they could be federated log= ins, they could be the >>>>>>>>>>>>>>>>>>>>>>> output of policy decisions. How the AS comes to tru= st those things is up to >>>>>>>>>>>>>>>>>>>>>>> the AS=E2=80=99s implementation. It=E2=80=99s somet= hing we can talk about, but ultimately >>>>>>>>>>>>>>>>>>>>>>> GNAP won=E2=80=99t be in any position to dictate be= cause in practice some AS=E2=80=99s are >>>>>>>>>>>>>>>>>>>>>>> simply going to internalize all policies and we wil= l never successfully >>>>>>>>>>>>>>>>>>>>>>> force those open. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> But with all that in mind, I think the key here is >>>>>>>>>>>>>>>>>>>>>>> going to be looking at what the inputs to the AS ar= e, and how those can be >>>>>>>>>>>>>>>>>>>>>>> defined in an interoperable way for AS=E2=80=99s th= at can accept them. I think >>>>>>>>>>>>>>>>>>>>>>> there=E2=80=99s a lot of room for innovation and fl= exibility here that doesn=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>> break the trust model or core use cases. If I have = an AS-RS set that won=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine inputs, = then I can decide not to >>>>>>>>>>>>>>>>>>>>>>> use that one. But this is a very different question= than saying the RS >>>>>>>>>>>>>>>>>>>>>>> itself needs to accept my own AS =E2=80=94 and we c= an=E2=80=99t keep conflating these two >>>>>>>>>>>>>>>>>>>>>>> models. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> So to me, GNAP can support a Zero Trust Architectur= e >>>>>>>>>>>>>>>>>>>>>>> by LEVERAGING the AS, not by subsuming or eliminati= ng it. It is in fact the >>>>>>>>>>>>>>>>>>>>>>> AS, not the client and not the RS, that will reques= t and consume the >>>>>>>>>>>>>>>>>>>>>>> results of a privacy-preserving zero-trust policy q= uery thing. Anything >>>>>>>>>>>>>>>>>>>>>>> that happens downstream from that is of little conc= ern to the zero-trust >>>>>>>>>>>>>>>>>>>>>>> components because, as you point out, it=E2=80=99s = on the =E2=80=9Cother side=E2=80=9D of the line. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I think we got this basic component model pretty >>>>>>>>>>>>>>>>>>>>>>> right in OAuth: the AS and RS and client working to= gether. Where OAuth >>>>>>>>>>>>>>>>>>>>>>> misses the mark is the assumption that the user has= to log in to the AS >>>>>>>>>>>>>>>>>>>>>>> through a webpage and interact directly, thereby pr= oving they=E2=80=99re the RO. >>>>>>>>>>>>>>>>>>>>>>> It=E2=80=99s this latter space where I think we can= both push innovation and also >>>>>>>>>>>>>>>>>>>>>>> address the important and compelling use cases like= the ones you=E2=80=99re >>>>>>>>>>>>>>>>>>>>>>> bringing. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper < >>>>>>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I'm sorry, Justin. As a Resource Owner, I look at >>>>>>>>>>>>>>>>>>>>>>> the RS trust boundary (the dotted line in the diagr= am) as being the RS. I >>>>>>>>>>>>>>>>>>>>>>> don't expect any visibility into what's going on on= the right. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> My problem with the framing you propose is that >>>>>>>>>>>>>>>>>>>>>>> requests are going to the RS (or the AS-RS) and I d= on't want to share my >>>>>>>>>>>>>>>>>>>>>>> policies with the AS-RS. I want to keep the RS and = AS-RS as ignorant as >>>>>>>>>>>>>>>>>>>>>>> possible. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer < >>>>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> What you=E2=80=99re discussing below, in terms of = logging >>>>>>>>>>>>>>>>>>>>>>>> in to a site, is not approaching the RS. You are i= n fact approaching the >>>>>>>>>>>>>>>>>>>>>>>> client, and identifying both the AS and RS to the = client. The client is a >>>>>>>>>>>>>>>>>>>>>>>> client *of your identity* in this model, and the >>>>>>>>>>>>>>>>>>>>>>>> RS is part of the identity provider. It=E2=80=99s = really important that we don=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>> conflate the RS and client in this way as it leads= to a lot of confusion >>>>>>>>>>>>>>>>>>>>>>>> downstream and a lot of broken trust boundaries. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> With that model in mind, approaching the =E2=80=9C= RS" and >>>>>>>>>>>>>>>>>>>>>>>> providing it your identity is really just a case o= f the =E2=80=9Cfederated login to >>>>>>>>>>>>>>>>>>>>>>>> AS=E2=80=9D pattern that we discussed on the WG ca= ll. The user here approaches an >>>>>>>>>>>>>>>>>>>>>>>> RS, which has its own AS. To share things from thi= s RS, the RO has to >>>>>>>>>>>>>>>>>>>>>>>> authenticate to the RS=E2=80=99s AS. This particul= ar AS allows the RO to do so >>>>>>>>>>>>>>>>>>>>>>>> using an external identity =E2=80=94 in which case= , the AS is now a =E2=80=9Cclient=E2=80=9D of a >>>>>>>>>>>>>>>>>>>>>>>> separate, disconnected (but layered) delegation. T= he ultimate client that >>>>>>>>>>>>>>>>>>>>>>>> eventually calls the RS down the way may or may no= t know about these >>>>>>>>>>>>>>>>>>>>>>>> layers. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> This same AS, which is closely tied to the RS and >>>>>>>>>>>>>>>>>>>>>>>> trusted by the RS, might also take in FIDO credent= ials, or DIDs, or any >>>>>>>>>>>>>>>>>>>>>>>> number of other proof mechanisms. The output of th= is is an access token the >>>>>>>>>>>>>>>>>>>>>>>> RS trusts, but the input is up to the AS. The RS i= s not what you=E2=80=99re logging >>>>>>>>>>>>>>>>>>>>>>>> in to. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper < >>>>>>>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I too am in favor of avoiding consolidation and >>>>>>>>>>>>>>>>>>>>>>>> correlation. Right now, when I approach a service = provider (RS) for the >>>>>>>>>>>>>>>>>>>>>>>> first time, I'm offered the opportunity to identif= y my persona as: email, >>>>>>>>>>>>>>>>>>>>>>>> sign-in with Google, Facebook, or Apple. I know th= ere are people who try to >>>>>>>>>>>>>>>>>>>>>>>> create one-off email addresses but that is mostly = a waste of time. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> So, along come FIDO2 and DID wallets to the rescue= . >>>>>>>>>>>>>>>>>>>>>>>> Now, in theory, I have a way to start out my RS re= lationship >>>>>>>>>>>>>>>>>>>>>>>> pseudonymously. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> When I want my resource to be discovered or shared >>>>>>>>>>>>>>>>>>>>>>>> I will post that RS URL including my pseudonym. If= I then want to introduce >>>>>>>>>>>>>>>>>>>>>>>> a mediator in front of my AS or messaging service = endpoint, I have that >>>>>>>>>>>>>>>>>>>>>>>> option. If I want to keep requests away from the m= ediator, I would publish >>>>>>>>>>>>>>>>>>>>>>>> an encryption key along with my pseudonym. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> - Adrian >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer < >>>>>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk < >>>>>>>>>>>>>>>>>>>>>>>>> kaduk@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adria= n >>>>>>>>>>>>>>>>>>>>>>>>> Gropper wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >> @Alan Karp shared a talk >>>>>>>>>>>>>>>>>>>>>>>>> about the Principle Of Least >>>>>>>>>>>>>>>>>>>>>>>>> >> Authority (POLA) in a recent comment >>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protoco= l/issues/145#issuecomment-803099693 >>>>>>>>>>>>>>>>>>>>>>>>> >> I recommend it. >>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> >> We might expect a protocol with authorization >>>>>>>>>>>>>>>>>>>>>>>>> in the title to use authority >>>>>>>>>>>>>>>>>>>>>>>>> >> as a core principle. I advocate for a GNAP >>>>>>>>>>>>>>>>>>>>>>>>> design that maximizes the power >>>>>>>>>>>>>>>>>>>>>>>>> >> of the RO, to be seen as a human rights issue >>>>>>>>>>>>>>>>>>>>>>>>> when the RO is a human. This >>>>>>>>>>>>>>>>>>>>>>>>> >> causes me to ask how to combine better securit= y >>>>>>>>>>>>>>>>>>>>>>>>> with better human rights in >>>>>>>>>>>>>>>>>>>>>>>>> >> GNAP. >>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> >> Who should have the least authority in the GNA= P >>>>>>>>>>>>>>>>>>>>>>>>> design? >>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> >> The AS derives authority as a delegate of the >>>>>>>>>>>>>>>>>>>>>>>>> RO. If we ask the RO to >>>>>>>>>>>>>>>>>>>>>>>>> >> partition limited authority across dozens of >>>>>>>>>>>>>>>>>>>>>>>>> different ASs by domain and >>>>>>>>>>>>>>>>>>>>>>>>> >> function, then we are not using technology to >>>>>>>>>>>>>>>>>>>>>>>>> empower the individual. >>>>>>>>>>>>>>>>>>>>>>>>> >> Probably the opposite, as we introduce consent >>>>>>>>>>>>>>>>>>>>>>>>> fatigue and burden normal >>>>>>>>>>>>>>>>>>>>>>>>> >> people to partition their lives into >>>>>>>>>>>>>>>>>>>>>>>>> non-overlapping domains. >>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> >> My experience says we should aim for one AS pe= r >>>>>>>>>>>>>>>>>>>>>>>>> persona because that maps >>>>>>>>>>>>>>>>>>>>>>>>> >> into the way we manage our public and private >>>>>>>>>>>>>>>>>>>>>>>>> identities. POLA would then >>>>>>>>>>>>>>>>>>>>>>>>> >> teach care in keeping ASs and RSs related to >>>>>>>>>>>>>>>>>>>>>>>>> work / public separate from >>>>>>>>>>>>>>>>>>>>>>>>> >> ASs and RSs related to private life so that a >>>>>>>>>>>>>>>>>>>>>>>>> policy vulnerability in our >>>>>>>>>>>>>>>>>>>>>>>>> >> delegation to an AS would have the least >>>>>>>>>>>>>>>>>>>>>>>>> likelihood of harm. >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> > Thinking about how least authority/least >>>>>>>>>>>>>>>>>>>>>>>>> privilege would apply to GNAP >>>>>>>>>>>>>>>>>>>>>>>>> > seems like a useful exercise. I do want to >>>>>>>>>>>>>>>>>>>>>>>>> point out some potential >>>>>>>>>>>>>>>>>>>>>>>>> > pitfalls with one-AS-per-persona that we can >>>>>>>>>>>>>>>>>>>>>>>>> also be aware of. If >>>>>>>>>>>>>>>>>>>>>>>>> > one-AS-per-persona becomes one-persona-per-AS a= s >>>>>>>>>>>>>>>>>>>>>>>>> well, then the AS's >>>>>>>>>>>>>>>>>>>>>>>>> > identity in effect also serves as a persona >>>>>>>>>>>>>>>>>>>>>>>>> identity and there are privacy >>>>>>>>>>>>>>>>>>>>>>>>> > considerations to that. If, on the other hand, >>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>> > multiple-personas-per-AS (presumably >>>>>>>>>>>>>>>>>>>>>>>>> corresponding to multiple humans) >>>>>>>>>>>>>>>>>>>>>>>>> > route is taken, we should consider whether that >>>>>>>>>>>>>>>>>>>>>>>>> would lead to various >>>>>>>>>>>>>>>>>>>>>>>>> > (e.g., market) forces driving consolidation to >>>>>>>>>>>>>>>>>>>>>>>>> just a handful of >>>>>>>>>>>>>>>>>>>>>>>>> > super-popular AS services. That topic is a >>>>>>>>>>>>>>>>>>>>>>>>> current matter of concern to >>>>>>>>>>>>>>>>>>>>>>>>> > some IETF participants. >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Hi Ben, big +1 to this. This is something that we >>>>>>>>>>>>>>>>>>>>>>>>> discussed ages ago in the UMA working group, and = it=E2=80=99s one of the biggest >>>>>>>>>>>>>>>>>>>>>>>>> problems with the personal AS (and personal data = store) model. This kind of >>>>>>>>>>>>>>>>>>>>>>>>> thing makes RS-first trust models really difficul= t in practice. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> As a strawman, let=E2=80=99s say that I=E2=80=99v= e got software >>>>>>>>>>>>>>>>>>>>>>>>> that wants to access my medical information. It c= alls an RS and requests >>>>>>>>>>>>>>>>>>>>>>>>> access, but it hasn=E2=80=99t been granted anythi= ng yet. Now I as the RO have set >>>>>>>>>>>>>>>>>>>>>>>>> up the RS so that it talks to my personal AS, tha= t only I use. In addition >>>>>>>>>>>>>>>>>>>>>>>>> to the RS having to be able to figure out which m= edical records are being >>>>>>>>>>>>>>>>>>>>>>>>> requested from the context of the unauthenticated= request (which means it >>>>>>>>>>>>>>>>>>>>>>>>> needs identifiers in the URL or something similar= for the RS to be able to >>>>>>>>>>>>>>>>>>>>>>>>> tell, assuming that it protects data for more tha= n one person). So this >>>>>>>>>>>>>>>>>>>>>>>>> client software doesn=E2=80=99t know who I am and= doesn=E2=80=99t know my medical record >>>>>>>>>>>>>>>>>>>>>>>>> information, makes a completely unauthorized requ= est to the RS, and the RS >>>>>>>>>>>>>>>>>>>>>>>>> says =E2=80=9CGo to Justin=E2=80=99s personal AS = to get a token=E2=80=9D. The client can now make a >>>>>>>>>>>>>>>>>>>>>>>>> direct correlation between the data that=E2=80=99= s being protected at the RS and >>>>>>>>>>>>>>>>>>>>>>>>> the person running the AS that protects it. Impor= tantly, this client makes >>>>>>>>>>>>>>>>>>>>>>>>> this call with no prior relationship to the RS an= d no really auditable way >>>>>>>>>>>>>>>>>>>>>>>>> to track it down after the fact. This is a design= feature in the good case, >>>>>>>>>>>>>>>>>>>>>>>>> and terrifying in the bad case. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> If the RS instead says =E2=80=9Cwelcome to Medici= ne Doctor >>>>>>>>>>>>>>>>>>>>>>>>> RS, please talk to the Medicine Doctor AS to get = access=E2=80=9D, we haven=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>>> exposed anything at all. And from the perspective= of both the patient and >>>>>>>>>>>>>>>>>>>>>>>>> the RS, this is more privacy-preserving, and it= =E2=80=99s really the least >>>>>>>>>>>>>>>>>>>>>>>>> surprising option. Once the client gets to the AS= , it can start a >>>>>>>>>>>>>>>>>>>>>>>>> negotiation of figuring out who the RO is for the= information being >>>>>>>>>>>>>>>>>>>>>>>>> accessed. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On top of this, the usability expectations of >>>>>>>>>>>>>>>>>>>>>>>>> people managing their own AS, or set of AS=E2=80= =99s for multiple personas to keep >>>>>>>>>>>>>>>>>>>>>>>>> things separate, is a huge burden. Even in the te= ch community, I know >>>>>>>>>>>>>>>>>>>>>>>>> people who can=E2=80=99t reliably manage more tha= n one email address for different >>>>>>>>>>>>>>>>>>>>>>>>> purposes. I wouldn=E2=80=99t expect my partner to= do that =E2=80=94 they have trouble >>>>>>>>>>>>>>>>>>>>>>>>> enough balancing all the logins and sessions requ= ired for different kids >>>>>>>>>>>>>>>>>>>>>>>>> remote schooling, I couldn=E2=80=99t imagine them= having to understand all the >>>>>>>>>>>>>>>>>>>>>>>>> requirements for managing multiple authorization = servers and associated >>>>>>>>>>>>>>>>>>>>>>>>> policies. I also don=E2=80=99t expect any person = to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve been on >>>>>>>>>>>>>>>>>>>>>>>>> the internet for decades and I can barely keep ta= bs on my GPG keys, and >>>>>>>>>>>>>>>>>>>>>>>>> only use them when I am forced to. This is exactl= y the kind of =E2=80=9Cmarket >>>>>>>>>>>>>>>>>>>>>>>>> pressure=E2=80=9D that I think Ben mentions above= , people will just want to >>>>>>>>>>>>>>>>>>>>>>>>> outsource that to someone else, and the reality w= ill be a few popular >>>>>>>>>>>>>>>>>>>>>>>>> providers. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> In which case, we could end up doing a ton of wor= k >>>>>>>>>>>>>>>>>>>>>>>>> to allow an RS choice only to end up with a world= where the RS ends up >>>>>>>>>>>>>>>>>>>>>>>>> making a limited choice anyway. We see how that p= lays out with OpenID >>>>>>>>>>>>>>>>>>>>>>>>> Connect =E2=80=94 RP=E2=80=99s could allow arbitr= ary IdPs but they choose Google because it >>>>>>>>>>>>>>>>>>>>>>>>> works and that=E2=80=99s where the users are. (An= d that=E2=80=99s not to say anything of >>>>>>>>>>>>>>>>>>>>>>>>> the proprietary OIDC-like protocols, but that=E2= =80=99s another discussion). >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> For further reading on these topics, I recommend >>>>>>>>>>>>>>>>>>>>>>>>> both =E2=80=9CWhy Johnny Can=E2=80=99t Encrypt=E2= =80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> So what does this have to do with GNAP? I think w= e >>>>>>>>>>>>>>>>>>>>>>>>> can be clear-eyed on what kinds of expectations w= e have for the >>>>>>>>>>>>>>>>>>>>>>>>> participants. If we expect users (RO=E2=80=99s) t= o have to set up the AS-RS >>>>>>>>>>>>>>>>>>>>>>>>> relationship, or expect them to carry their AS, o= r manage their personal >>>>>>>>>>>>>>>>>>>>>>>>> keys =E2=80=94 I think we=E2=80=99ve lost the bat= tle for relevance. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> >> -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000052b56f05be63678e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    My issue is with Alan's:
    &q= uot;7. Another user agent (RO') can contact any holder of the access to= ken or the service's policy agent (AS-RS) to get a delegated access tok= en."

    I would prefer "7A.=C2=A0Another user agen= t (RO') can contact any holder of the access token." by default so= that the AS-RS does not see the requests. In other words, the RS and AS-RS= only see access tokens. The requests (from RO') that resulted in an ac= cess token are none of their business.

    <= /div>
    The reality is that RO' can discover a resource RS and can share whate= ver information with RS-AS they want and the RO may not even know about it = unless the RS decides to let them know somehow. This seems to be a drawback= of the capabilities approach.=C2=A0

    In = terms of privacy and control, I, as the RO, want a contract=C2=A0with the R= S that says that I or my agent (AS-RO) must sign an access token. This is a= fundamental audit requirement. Without it, a rogue RS and AS-RS can do all= sorts of things and the RO would never know. I understand that a rogue RS = might not support an honest contemporaneous log of access tokens presented = so there's a trust issue here that I seems unavoidable unless I specify= in my RO-RS contract that they use a separate contemporaneous=C2=A0log suc= h as AS-RO for every access token presented and risk being sued if they pro= cess an access token without also updating the separate log.<= /div>

    - Adrian


    On T= hu, Mar 25, 2021 at 1:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin Rich= er <jricher@mit.edu= > wrote:
    Hi Alan,

    = In all of my discussion, and in the spec itself, the RO is the :entity: in = charge of approving rights. They=E2=80=99re probably a person. It might be = software that makes a policy decision in some way, or a corporate entity, o= r something like that. But it=E2=80=99s not assumed to be a computational a= gent in the terms of the protocol itself. Would that recast what you=E2=80= =99re saying below?

    Hmmm.=C2=A0 I guess not.=C2=A0 It's just that the person would be= using some UI to express their decisions to what I called the user agent.= =C2=A0 That model fits in very nicely with what we did with Polaris, our vi= rus safe computing environment for Windows XP, https://dl.acm.org/doi/10.= 1145/1151030.1151033.=C2=A0 The person would click on the icon for a Wo= rd file, and an instance of Word would open with only the permission needed= to edit that one file.=C2=A0 Same thing here.=C2=A0 The client could ask f= or permission to use the resource, or permission could be granted implicitl= y when the user selects a resource associated with a specific client.
    =

    --------------
    Alan Karp


    <= div class=3D"gmail_quote">
    On Thu, Mar= 25, 2021 at 9:53 AM Justin Richer <jricher@mit.edu> wrote:
    =
    Hi Alan,

    In all of my discussion, and in the spec i= tself, the RO is the :entity: in charge of approving rights. They=E2=80=99r= e probably a person. It might be software that makes a policy decision in s= ome way, or a corporate entity, or something like that. But it=E2=80=99s no= t assumed to be a computational agent in the terms of the protocol itself. = Would that recast what you=E2=80=99re saying below?

    =C2=A0=E2=80=94 Justin

    On Mar = 25, 2021, at 12:36 PM, Alan Karp <alanhkarp@gmail.com> wrote:

    There seems to be some confusion about how AS-RO comes into the p= icture, probably because of the "AS" part.=C2=A0 I'm going to= try to clear up that confusion by more carefully explaining what I mean.
    I'm assuming that RO is a computational agent representing = the person who is the resource owner, something called the "user agent= " in operating systems lingo.=C2=A0 I'm also assuming that it'= s possible to do delegation, either locally or by token exchange with AS-RS= .=C2=A0 All delegations are potentially sub-scoped, but you may also want t= o delegate with full scope to have a separately revocable access token.

    =C2=A0 Here's an example of how things work in a = capability oriented system.
    1. Someone, the service owne= r, creates a service.
    2. The service owner contracts with an policy ag= ent (AS-RS) to create and manage access tokens for that service (RS).
      3. <= li>A person wishing to create a resource at RS uses their user agent (RO) t= o contact the service owner's policy agent (AS-RS) and gets back an acc= ess token for that resource.
    3. That user agent (RO) can=C2=A0
    4. use that access token to invoke the resource, or
    5. delegate an a= ccess token to a client of the user agent's (RO) choice, or
    6. con= tract with a policy agent (AS-RO) to manage those delegations on behalf of = the user agent (RO), or
    7. specify a policy with the service's pol= icy agent (AS-RS).
  • A client can contact any holder of the acce= ss token (the user agent (RO) or its policy agent (AS-RO)) or the service&#= 39;s policy agent (AS-RS) to get a delegated access token.
  • That cli= ent can delegate that token to another client.
  • Another user agent (= RO') can contact any holder of the access token or the service's po= licy agent (AS-RS) to get a delegated access token.
  • The other user = agent (RO') can=C2=A0
    1. use that access token to invoke the r= esource, or
    2. delegate it to a client of its choice, or
    3. contr= act with a policy agent (AS-RO') of its choosing to manage those deleg= ations on its behalf, or
    4. specify a policy with the service's po= licy agent (AS-RS).
  • and so on
    • Wh= en any of these computational agents, user agents (ROs) or clients acting o= n their behalf, invokes the resource, AS-RS verifies that the access token = is a valid delegation, i.e., proper sub-scoping, hasn't been revoked, a= nd that it authorizes the request being made before telling the service (RS= ) to honor the request.=C2=A0 At no point does the service's policy age= nt (AS-RS) know which computational agent did any particular delegation.=C2= =A0 (Token exchange can be done as anonymously as possible.)=C2=A0 In parti= cular, the policy agents (AS-RO) need not be the same, or even compatible w= ith, the service's policy agent (AS-RS).=C2=A0 GNAP specifies the proto= col between requesters, invokers, delegators (for token exchange) of tokens= and AS-RS.=C2=A0 That protocol need not be used between user agents (RO), = clients, or other policy agents (AS-RO), but it is likely to be.
    =
    =C2=A0-------------
    Alan Karp


    On Thu, Mar 25, 2021 at 5:45 AM Justin Richer <jricher@mit.edu> = wrote:
    The way I=E2=80=99m thinking about Ad= rian=E2=80=99s use case is that what we=E2=80=99re calling the =E2=80=9CAS-= RO=E2=80=9D isn=E2=80=99t an =E2=80=9CAS=E2=80=9D in the traditional OAuth/= GNAP sense, at least not exactly. This is the agent that the RO can use to = set policies and manage consent on their behalf, and I=E2=80=99ve been argu= ing that it fits better into this vaguely-defined =E2=80=9Cinteraction comp= onent=E2=80=9D aspect of the current AS definition, and it=E2=80=99s not cu= rrently separated from the AS definition. The =E2=80=9CAS-RS=E2=80=9D maps = to what we=E2=80=99d call the =E2=80=9CAS=E2=80=9D in OAuth/GNAP traditiona= lly, it=E2=80=99s what the RS trusts to issue tokens. In traditional OAuth = the AS-RO and AS-RS are always the same thing, from a functional protocol p= erspective. An important point here is that from a client=E2=80=99s perspec= tive, they=E2=80=99re only talking to the AS-RS since that=E2=80=99s where = the client gets its tokens, because at the end of the day the client just w= ants to call the API at the RS and doesn=E2=80=99t care how that happens (f= rom a protocol standpoint).=C2=A0

    Note well: Even though= t I don=E2=80=99t believe that =E2=80=9CAS-RO=E2=80=9D is an authorization = server at all, I=E2=80=99m going to keep using that term below for consiste= ncy with previous discussion.

    So we have these fun= damental relationships around getting the client to access the RS:

    1. RS trusts=C2=A0AS-RS=C2=A0to issue tokens that RS will = accept, validate, and process for requests from client
    2. Client = trusts=C2=A0AS-RS=C2=A0to issue tokens that client can use at RS
    = 3. RO trusts RS to protect RO=E2=80=99s api through delegated access
    <= div>
    On top of that, we=E2=80=99ve got some additional aspect= s that we=E2=80=99re discussing:

    4. RO trusts=C2= =A0AS-RO=C2=A0to manage RO=E2=80=99s policies at runtime
    5.=C2=A0= AS-RS=C2=A0trusts=C2=A0AS-RO=C2=A0to assert RO=E2=80=99s policies for acces= s to RS
    6. Client trusts whatever=C2=A0AS-RS=C2=A0sends client to= deal with, including possibly RO-AS at runtime, because of (2)
    <= br>
    What I have been saying is that 4/5/6 are optional details of= how RS-AS runs things, and I think this also maps with Adrian=E2=80=99s vi= ew of choice, since if my RS=E2=80=99s AS-RS doesn=E2=80=99t allow me to pl= ug in my own AS-RO then I would be motivated to pick a different RS who=E2= =80=99s AS-RS lets me do just that. The same way I=E2=80=99d pick a differe= nt RS if their surrounding services didn=E2=80=99t accept my preferred fede= ration login and I didn=E2=80=99t want to make another account. Of course, = market forces being as they are, I might not have much of an actionable cho= ice in RS, but GNAP can=E2=80=99t change that.=C2=A0

    What we can do is make it possible for AS-RS to talk to AS-RO, both in p= hilosophy of the protocol design and in concrete hooks to support (6) above= .=C2=A0

    Separately, we can approach the issue of m= aking 1/2 above more dynamic. This was UMA2=E2=80=99s =E2=80=9Cfederated au= thorization=E2=80=9D approach, and is behind a lot of the =E2=80=9Cbring yo= ur own AS=E2=80=9D models out there. The problem with these is that we know= from many years of experience that most RS=E2=80=99s aren=E2=80=99t intere= sted in doing anything of the sort.

    So with GNAP w= e can instead allow 4/5/6 to vary in a predictable and consistent way, lett= ing the RS keep control over 1/2, thereby enabling choice in (3). We don=E2= =80=99t have to be the ones who define the all of the details of every perm= utation of (5) to enable this, though. Some of this is going to be configur= ation out of band, some of it=E2=80=99s going to be communication at runtim= e. This is where VC=E2=80=99s, ZCAPs, CHAPI, DIDComm, FIDO, and a whole swa= th of other tech can come in and help out. I don=E2=80=99t think we need to= put all the details for using these into core, nor do I think we=E2=80=99l= l pull of The Great And Ultimate Abstraction for using these and other appr= oaches. But we can at least start talking about =E2=80=9CAS-RS=E2=80=9D in = such a way that it no longer assumes it=E2=80=99s always the same party dea= ling with the RO directly.

    =C2=A0=E2=80=94 Justin

    On Mar 25, 2021, at 6:40 AM, Fabie= n Imbault <fabien.imbault@gmail.com> wrote:

    To = reframe it closer to GNAP:
    - AS =3D AS-RO, that's where you find th= e RO policies. The AS issues access tokens to the client.
    - the R= O policies could be a) defined locally or b) in relationship with the RS

    There have been several ideas related to the AS-RS r= elationship b:
    b1) the RS issues capabilities (which can be f= urther attenuated by the RO)
    b2) Adrian also discussed a DID base= d solution
    b3) there was also an alternative ACL proposal from De= nis (+ preflight)

    Fabien


    On Th= u, Mar 25, 2021 at 9:44 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Ok so I get you correctly:=C2=A0- what matters is the RQ (could be a RO or a end-user or both : we don&#= 39;t really care at a high-level, they're all treated as entities that = make a request)
    - the policy is able to handle those different ca= ses, based on its own internal delegation protocol
    - currently th= at requires AS-RS and AS-RO, but maybe it can be simplified

    <= /div>
    To answer to Denis, here's what I understood:
    - RO = trusts AS-RS (and then handles its own policies within AS-RO)
    - end-user trusts AS-RO (through its client)

    Coul= d probably work but that's a fairly different model compared to OAuth2 = (and of today's GNAP), with different frontiers between the AS and the = RS.=C2=A0

    Please do not hesitate to correct me if = I'm wrong.

    Fabien=C2=A0

    On Thu, Mar 25, 2= 021 at 9:26 AM Adrian Gropper <agropper@healthurl.com> wrote:
    I believe there are alternatives to having two ki= nds of ASs. The problem may be a side-effect of deciding to switch away for= m treating the RO as different from the RQ. That leads to downstream privac= y issues. Our desire for architectural simplicity is admirable but that may= have been a step too far.

    There may also be solutions based on different types of tokens, as in di= fferent capabilities (tokens signed by the RS) vs. tokens signed by the AS.= I=E2=80=99m not sure about that but Alan might have more to say.

    Adrian

    On Thu, Mar 25, 2021= at 4:15 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks. The general problem statement is clear.
    The=C2=A0proposed solution a bit less (to me). I understo= od that from point 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obvious reason to have two types of = ASs".=C2=A0Do you see an alternative ?

    Regarding the last item, I don't think that naming RQ by end-use= r created the problem. It might just highlight the asymmetry,=C2=A0which fu= ndamentally exists.=C2=A0
    Fabien


    On Thu, Mar 25, = 2021 at 8:48 AM Adrian Gropper <agropper@healthurl.com> wrote:
    Recap:
    1 - Justin (I thin= k) introduced the idea of an AS on the RS trust boundary side.
    2 - I said the RO should not have to share policies with the RS.=
    3 - Alan invented the concept of AS-RO and AS-RS to= separate two kinds of PDPs.=C2=A0

    The thing is that step 2 is not symmetrical. The RO has a legiti= mate privacy interest in keeping their policies private and minimizing the = leakage of information about requests that are posed against those policies= .=C2=A0

    The RS, on the o= ther hand, should be publishing its policies (e.g. what it=E2=80=99s sellin= g or what jurisdiction it=E2=80=99s in or what tokens or scopes it supports= ). The RS has no obvious privacy interest in GNAP. It=E2=80=99s just an enf= orcer.

    There is one othe= r privacy interest to consider around the RS and that is the requesting par= ty (the end-user that is not the RO :-) might prefer to share attributes wi= th the RS instead of the RO or something controlled by the RO. This case co= uld be an =E2=80=9Cextension=E2=80=9D to GNAP and might result in a split A= S as a solution. This problem was introduced when the editors decided to re= place RQ with end-user. Obviously, the RO end-user has no privacy interests= relative to itself.

    Adr= ian




    On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault <fabien.imbault@gma= il.com> wrote:
    I wa= s referring to "By my definitio= n, this model has two ASs since both are processing requests into tokens&qu= ot;. If there's no reason to have 2 types of ASs, that's fine then.= =C2=A0
    But I'm = a bit lost in where we stand with the idea.=C2=A0

    Could you recap?=C2=A0

    Fabien=C2=A0

    Le jeu. 25 mar= s 2021 =C3=A0 08:16, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:=
    There=E2=80=99s no obvious rea= son to have two types of ASs. Any AS that is executing the policies of the = RS can look to GNAP like the RS itself. Why would GNAP expose that interfac= e to anyone?=C2=A0

    Adria= n

    On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault <fabien.imbau= lt@gmail.com> wrote:
    Not= e : I'm not sure that's a good idea, but having 2 types of ASs is n= ot that easy to grasp.

    <= div dir=3D"auto">Fabien=C2=A0

    Le jeu. 25 mars 2021 =C3=A0 08:07, Fabie= n Imbault <fabien.imbault@gmail.com> a =C3=A9crit=C2=A0:
    The purpose of either handling po= licies locally or delegating them to the RO agent.=C2=A0

    Le jeu. 25 mars 202= 1 =C3=A0 08:04, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    What= purpose would be served by GNAP splitting the AS into two components?

    Adrian=C2=A0

    Isn't the AS-RO a component of the AS? Sa= me idea as the interact component, it functionnally belongs to the AS role = but could be deployed either as a monolith or as a separate component?

    Fabien

    Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    Yes, but I would say it=E2=80=99s not the RO tha= t wants the access token. It=E2=80=99s the RO that wants the client making = the request to get an access token.=C2=A0

    =
    Adrian

    On Wed, Mar 24, 2021 at 11:22 PM Alan Karp &l= t;alanhkarp@gmail.com> wrote:
    <= /div>
    Adrian Gropper <= agropper@healthurl.com> wrote:

    In this design, the AS is the AS-RS a= nd the agent is the AS-RO. By my definition, this model has two ASs since b= oth are processing requests into tokens. The problem with this is complexit= y and privacy. The RO may not want to share the request information with th= e AS-RS.

    More precisely, RO has no choice but to present the required informat= ion to AS-RS if RO wants an access token.=C2=A0 However, RO does not want A= S-RS to know the policy by which RO delegates tokens.=C2=A0 That's why = RO uses AS-RO for those delegations.

    ------------= --
    Alan Karp


    On Wed, Mar 24, 2021= at 7:41 PM Adrian Gropper <agroppe= r@healthurl.com> wrote:
    <= div dir=3D"ltr">Thank you for creating the issue. My definition of AS is in= dependent of AS-RO or AS-RS.=C2=A0https://github.com/ietf-= wg-gnap/gnap-core-protocol/issues/223#issuecomment-806280421 I also agr= ee with Alan's definition based on delegation. An AS-RS would be a dele= gate of the RS.=C2=A0

    Based on that, I= see it as obvious=C2=A0that the policy has to be accessible (defined local= ly?) in order for it to be run as the code that turns a request into an acc= ess token.=C2=A0

    The only other possibility is tha= t the request is packaged by the AS and sent elsewhere (an agent) for evalu= ation against policy and a proto-token returned. In that case the AS is act= ing as a proxy and the PDP is elsewhere. I can imagine that an AS-RS would = behave this way so that the proto-token could be turned into an access toke= n by the AS-RS. Isn't this what Justin is proposing? In this design, th= e AS is the AS-RS and the agent is the AS-RO. By my definition, this model = has two ASs since both are processing requests into tokens. The problem wit= h this is complexity and privacy. The RO may not want to share the request = information with the AS-RS.

    Adrian

    =
    On Wed, Ma= r 24, 2021 at 5:21 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Isn't that what the AS is supposed to be, only with = the caveat that the policy is defined locally?=C2=A0

    <= /div>
    Fabien=C2=A0


    Le mer. 24 mars 2021 =C3=A0 20:17, A= lan Karp <alanhkarp@gmail.com> = a =C3=A9crit=C2=A0:
    AS-RO is an AS that RO trusts to delegate RO's access tokens accor= ding to RO's policies.=C2=A0=C2=A0

    --------------
    Alan Karp


    On Wed, Mar 24, 2021 at 9= :36 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan and Adrian,

    I've created issue AS= -RO policy delegation (https://github.com/ietf-wg-gnap/gnap-core-proto= col/issues/223) to capture your input.=C2=A0
    A first question= that arises: can we give a definition to AS-RO?

    T= hanks
    Fabien

    On Tue, Mar 23, 2021 at 4:15 PM Alan Karp <= ;alanhkarp@gmail.com> w= rote:
    Fabien Imba= ult <fabien.imbault@gm= ail.com> wrote:
    Hi Alan,= =C2=A0

    Yes, but in that flow, the token relationship bet= ween AS-RS and AS-RO is only secure if the tokens issued by AS-RS are crypt= ographically attenuable in the first place.=C2=A0
    <= div>=C2=A0
    Attenuated delegation is a requiremen= t, but that doesn't have to be done cryptographically.=C2=A0 Token exch= ange works just fine.=C2=A0 SPKI and zcap-ld are examples of the crypto app= roach, and we used token exchange in the system for HP.

    --------------
    Alan Karp


    On Tue, Mar 23, 202= 1 at 4:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    =
    Hi Alan,=C2=A0

    Yes, but in that flow, t= he token relationship between AS-RS and AS-RO is only secure if the tokens = issued by AS-RS are cryptographically attenuable in the first place.=C2=A0<= /div>

    Fabien

    <= div dir=3D"ltr" class=3D"gmail_attr">On Mon, Mar 22, 2021 at 9:26 PM Alan K= arp <alanhkarp@gmail.com> wrote:

    But with all that in mind, I think the key here = is going to be looking at what the inputs to the AS are, and how those can = be defined in an interoperable way for AS=E2=80=99s that can accept them. I= think there=E2=80=99s a lot of room for innovation and flexibility here th= at doesn=E2=80=99t break the trust model or core use cases. If I have an AS= -RS set that won=E2=80=99t accept my favorite flavor of policy engine input= s, then I can decide not to use that one. But this is a very different ques= tion than saying the RS itself needs to accept my own AS =E2=80=94 and we c= an=E2=80=99t keep conflating these two models.

    I agree.=C2=A0 The point of having an AS-RO is to allow RO = to specify a policy for which of RO's access tokens should be delegated= under what conditions.=C2=A0 AS-RS should not need to understand those pol= icies.=C2=A0 The flow would be
    • RO contacts AS-RS and gets= one or more access tokens.
    • RO delegates one or more of those token= s, potentially sub-scoped, to AS-RO.
    • A different user contacts AS-R= O to get a potentially sub-scoped access token from AS-RO.
    • That use= r presents the access token delegated by AS-RO when invoking the resource.<= /li>
    AS-RS only needs to verify that the delegation cha= in is legitimate, e.g., no increase in scope, and that it grants permission= for the request being made.=C2=A0 AS-RS does not need to understand the po= licy behind granting the delegation by AS-RO.

    ---= -----------
    Alan Karp


    On Mon, Mar 22, 2021 at 11:40 AM Ju= stin Richer <jricher@mit.edu> wrote:
    Adrian,

    I th= ink this shows the problem with the terminology as it=E2=80=99s been applie= d in this conversation, which I=E2=80=99ve tried to shine light on before. = What you and others are calling the =E2=80=9CRS=E2=80=9D is really the =E2= =80=9CAS and RS working together=E2=80=9D =E2=80=94 everything to the right= of the line. When Denis had brought up =E2=80=9Celiminating the AS=E2=80= =9D in another thread, what he=E2=80=99d really done is labeled everything = to the right of the line as the =E2=80=9CRS=E2=80=9D. Of course, the irony = here is that everything to the right of the line used all be called the =E2= =80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. A= s you say below, I don=E2=80=99t want the client to have visibility on what= happens on that side.=C2=A0

    Note well: The Google= + logo labeled =E2=80=9CIdP=E2=80=9D in the diagram is not the AS, as far a= s GNAP is concerned. It does not issue an access token that the RS will acc= ept. The elements to the left of the line could be a lot of things, but the= y are NOT the AS =E2=80=94 by definition. The client lives over on the left= , but so do any external inputs to the AS. These could be policy inputs on = behalf of the RO, they could be presentation artifacts, they could be feder= ated logins, they could be the output of policy decisions. How the AS comes= to trust those things is up to the AS=E2=80=99s implementation. It=E2=80= =99s something we can talk about, but ultimately GNAP won=E2=80=99t be in a= ny position to dictate because in practice some AS=E2=80=99s are simply goi= ng to internalize all policies and we will never successfully force those o= pen.=C2=A0

    But with all that in mind, I think the = key here is going to be looking at what the inputs to the AS are, and how t= hose can be defined in an interoperable way for AS=E2=80=99s that can accep= t them. I think there=E2=80=99s a lot of room for innovation and flexibilit= y here that doesn=E2=80=99t break the trust model or core use cases. If I h= ave an AS-RS set that won=E2=80=99t accept my favorite flavor of policy eng= ine inputs, then I can decide not to use that one. But this is a very diffe= rent question than saying the RS itself needs to accept my own AS =E2=80=94= and we can=E2=80=99t keep conflating these two models.

    So to me, GNAP can support a Zero Trust Architecture by LEVERAGING th= e AS, not by subsuming or eliminating it. It is in fact the AS, not the cli= ent and not the RS, that will request and consume the results of a privacy-= preserving zero-trust policy query thing. Anything that happens downstream = from that is of little concern to the zero-trust components because, as you= point out, it=E2=80=99s on the =E2=80=9Cother side=E2=80=9D of the line.= =C2=A0

    I think we got this basic component model p= retty right in OAuth: the AS and RS and client working together. Where OAut= h misses the mark is the assumption that the user has to log in to the AS t= hrough a webpage and interact directly, thereby proving they=E2=80=99re the= RO. It=E2=80=99s this latter space where I think we can both push innovati= on and also address the important and compelling use cases like the ones yo= u=E2=80=99re bringing.

    =C2=A0=E2=80=94 Justin
    <= div>

    I'm sorry, Justin= . As a Resource Owner, I look at the RS trust boundary (the dotted line in = the diagram) as being the RS. I don't expect any visibility into what&#= 39;s going on on the=C2=A0right.=C2=A0

    My problem with t= he framing you propose is that requests are going to the RS (or the AS-RS) = and I don't want to share my policies with the AS-RS. I want to keep th= e RS and AS-RS as ignorant as possible.

    Adrian

    On Mon, Mar 22, 2021 at 1:48 PM Justin Richer <jricher@mit.edu> wrote:
    =
    Adrian,

    What you=E2=80=99re discussing below, in te= rms of logging in to a site, is not approaching the RS. You are in fact app= roaching the client, and identifying both the AS and RS to the client. The = client is a client of your identity in this model, and the RS is par= t of the identity provider. It=E2=80=99s really important that we don=E2=80= =99t conflate the RS and client in this way as it leads to a lot of confusi= on downstream and a lot of broken trust boundaries.

    With that model in mind, approaching the =E2=80=9CRS" and providing = it your identity is really just a case of the =E2=80=9Cfederated login to A= S=E2=80=9D pattern that we discussed on the WG call. The user here approach= es an RS, which has its own AS. To share things from this RS, the RO has to= authenticate to the RS=E2=80=99s AS. This particular AS allows the RO to d= o so using an external identity =E2=80=94 in which case, the AS is now a = =E2=80=9Cclient=E2=80=9D of a separate, disconnected (but layered) delegati= on. The ultimate client that eventually calls the RS down the way may or ma= y not know about these layers.=C2=A0

    <PastedGraphic-1.png>
    This same AS, which is clo= sely tied to the RS and trusted by the RS, might also take in FIDO credenti= als, or DIDs, or any number of other proof mechanisms. The output of this i= s an access token the RS trusts, but the input is up to the AS. The RS is n= ot what you=E2=80=99re logging in to.

    =C2=A0=E2=80= =94 Justin

    On Mar 22, 2021, at 1= :28 PM, Adrian Gropper <= agropper@healthurl.com> wrote:

    I too = am in favor of avoiding consolidation and correlation. Right now, when I ap= proach a service provider (RS) for the first time, I'm offered the oppo= rtunity to identify my persona as: email, sign-in with Google, Facebook, or= Apple. I know there are people who try to create one-off email addresses b= ut that is mostly a waste of time.=C2=A0

    So, along come = FIDO2 and DID wallets to the rescue. Now, in theory, I have a way to start = out my RS relationship pseudonymously.=C2=A0

    When = I want my resource to be discovered or shared I will post that RS URL inclu= ding my pseudonym. If I then want to introduce a mediator=C2=A0in front of = my AS or messaging service=C2=A0endpoint, I have that option. If I want to = keep requests away from the mediator, I would publish an encryption key alo= ng with my pseudonym.

    - Adrian



    On Mon, Mar 22, 2021 at 9:55 AM Justin Richer <jricher@mit.edu> wrote:
    <= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa= dding-left:1ex">On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhk= arp@gmail.com> shared a talk about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-= gnap/gnap-core-protocol/issues/145#issuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --
    TXAuth 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
    --
    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
    --00000000000052b56f05be63678e-- From nobody Fri Mar 26 04:15:45 2021 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 D82A33A1BB3 for ; Fri, 26 Mar 2021 04:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 BhdSYeSPqGrF for ; Fri, 26 Mar 2021 04:15:37 -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 88E483A1BAD for ; Fri, 26 Mar 2021 04:15:36 -0700 (PDT) Received: from [192.168.1.22] (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 12QBFUCS008852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Mar 2021 07:15:31 -0400 From: Justin Richer Message-Id: <5773FA7B-6891-4227-A8CA-2F506909B8CD@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_80EA8814-CD22-4B08-9404-07787EFB09C3" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 26 Mar 2021 07:15:30 -0400 In-Reply-To: Cc: Alan Karp , GNAP Mailing List , Fabien Imbault , Mark Miller , Benjamin Kaduk To: Adrian Gropper References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2021 11:15:44 -0000 --Apple-Mail=_80EA8814-CD22-4B08-9404-07787EFB09C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have a big problem with this line: > the RS and AS-RS only see access tokens. The requests (from RO') that = resulted in an access token are none of their business. In the trust model we=E2=80=99ve been discussing, the requests that = result in access tokens are solely the business of AS-RS, since AS-RS is = the only entity that=E2=80=99s allowed, and trusted by the RS, to create = access tokens for the RS. That is its entire job, the entire reason it = exists in the system. By definition the party generating tokens for use = at the RS is the AS for that RS, I don=E2=80=99t care how you deploy it. = If RO wants to give access to someone else (who isn=E2=80=99t an =E2=80=9C= RO" anymore, they=E2=80=99re another end-user), then that end user=E2=80=99= s client software will need to talk to AS-RS to get its own access = token. Now here=E2=80=99s the trick: when the end user=E2=80=99s client = instance talks to AS-RS, that does NOT mean that AS-RS needs to know all = the details and policy reasons that it should give an access token to = that client instance. It doesn=E2=80=99t even need to know the existence = of another end user. It doesn=E2=80=99t need identity, it doesn=E2=80=99t = need policy. Sure, it COULD handle all of that internally, and many = will, but the protocol doesn=E2=80=99t demand it.=20 This means that the first client instance, the one that gets the access = token, can also be given something alongside the access token that it = can then hand to another piece of software (or to a person to hand eo = their piece of software). This artifact is not an access token. This = artifact could be something structured that the client understands, and = can make derivatives of, and present back to the AS-RS for getting new = access tokens. There could be multiple different flavors of this kind of = artifact for different kinds of environments and groups. But what they = all have in common is that they can potentially be used to request more = access tokens within some context at the AS-RS. =E2=80=94 Justin > On Mar 25, 2021, at 5:50 PM, Adrian Gropper = wrote: >=20 > My issue is with Alan's: > "7. Another user agent (RO') can contact any holder of the access = token or the service's policy agent (AS-RS) to get a delegated access = token." >=20 > I would prefer "7A. Another user agent (RO') can contact any holder of = the access token." by default so that the AS-RS does not see the = requests. In other words, the RS and AS-RS only see access tokens. The = requests (from RO') that resulted in an access token are none of their = business. >=20 > The reality is that RO' can discover a resource RS and can share = whatever information with RS-AS they want and the RO may not even know = about it unless the RS decides to let them know somehow. This seems to = be a drawback of the capabilities approach.=20 >=20 > In terms of privacy and control, I, as the RO, want a contract with = the RS that says that I or my agent (AS-RO) must sign an access token. = This is a fundamental audit requirement. Without it, a rogue RS and = AS-RS can do all sorts of things and the RO would never know. I = understand that a rogue RS might not support an honest contemporaneous = log of access tokens presented so there's a trust issue here that I = seems unavoidable unless I specify in my RO-RS contract that they use a = separate contemporaneous log such as AS-RO for every access token = presented and risk being sued if they process an access token without = also updating the separate log. >=20 > - Adrian >=20 >=20 > On Thu, Mar 25, 2021 at 1:22 PM Alan Karp > wrote: > Justin Richer > wrote: > Hi Alan, >=20 > In all of my discussion, and in the spec itself, the RO is the = :entity: in charge of approving rights. They=E2=80=99re probably a = person. It might be software that makes a policy decision in some way, = or a corporate entity, or something like that. But it=E2=80=99s not = assumed to be a computational agent in the terms of the protocol itself. = Would that recast what you=E2=80=99re saying below? >=20 > Hmmm. I guess not. It's just that the person would be using some UI = to express their decisions to what I called the user agent. That model = fits in very nicely with what we did with Polaris, our virus safe = computing environment for Windows XP, = https://dl.acm.org/doi/10.1145/1151030.1151033 = . The person would = click on the icon for a Word file, and an instance of Word would open = with only the permission needed to edit that one file. Same thing here. = The client could ask for permission to use the resource, or permission = could be granted implicitly when the user selects a resource associated = with a specific client. >=20 > -------------- > Alan Karp >=20 >=20 > On Thu, Mar 25, 2021 at 9:53 AM Justin Richer > wrote: > Hi Alan, >=20 > In all of my discussion, and in the spec itself, the RO is the = :entity: in charge of approving rights. They=E2=80=99re probably a = person. It might be software that makes a policy decision in some way, = or a corporate entity, or something like that. But it=E2=80=99s not = assumed to be a computational agent in the terms of the protocol itself. = Would that recast what you=E2=80=99re saying below? >=20 > =E2=80=94 Justin >=20 >> On Mar 25, 2021, at 12:36 PM, Alan Karp > wrote: >>=20 >> There seems to be some confusion about how AS-RO comes into the = picture, probably because of the "AS" part. I'm going to try to clear = up that confusion by more carefully explaining what I mean. >>=20 >> I'm assuming that RO is a computational agent representing the person = who is the resource owner, something called the "user agent" in = operating systems lingo. I'm also assuming that it's possible to do = delegation, either locally or by token exchange with AS-RS. All = delegations are potentially sub-scoped, but you may also want to = delegate with full scope to have a separately revocable access token. >>=20 >> Here's an example of how things work in a capability oriented = system. >> Someone, the service owner, creates a service. >> The service owner contracts with an policy agent (AS-RS) to create = and manage access tokens for that service (RS). >> A person wishing to create a resource at RS uses their user agent = (RO) to contact the service owner's policy agent (AS-RS) and gets back = an access token for that resource. >> That user agent (RO) can=20 >> use that access token to invoke the resource, or >> delegate an access token to a client of the user agent's (RO) choice, = or >> contract with a policy agent (AS-RO) to manage those delegations on = behalf of the user agent (RO), or >> specify a policy with the service's policy agent (AS-RS). >> A client can contact any holder of the access token (the user agent = (RO) or its policy agent (AS-RO)) or the service's policy agent (AS-RS) = to get a delegated access token. >> That client can delegate that token to another client. >> Another user agent (RO') can contact any holder of the access token = or the service's policy agent (AS-RS) to get a delegated access token. >> The other user agent (RO') can=20 >> use that access token to invoke the resource, or >> delegate it to a client of its choice, or >> contract with a policy agent (AS-RO') of its choosing to manage those = delegations on its behalf, or >> specify a policy with the service's policy agent (AS-RS). >> and so on >> When any of these computational agents, user agents (ROs) or clients = acting on their behalf, invokes the resource, AS-RS verifies that the = access token is a valid delegation, i.e., proper sub-scoping, hasn't = been revoked, and that it authorizes the request being made before = telling the service (RS) to honor the request. At no point does the = service's policy agent (AS-RS) know which computational agent did any = particular delegation. (Token exchange can be done as anonymously as = possible.) In particular, the policy agents (AS-RO) need not be the = same, or even compatible with, the service's policy agent (AS-RS). GNAP = specifies the protocol between requesters, invokers, delegators (for = token exchange) of tokens and AS-RS. That protocol need not be used = between user agents (RO), clients, or other policy agents (AS-RO), but = it is likely to be. >>=20 >> ------------- >> Alan Karp >>=20 >>=20 >> On Thu, Mar 25, 2021 at 5:45 AM Justin Richer > wrote: >> The way I=E2=80=99m thinking about Adrian=E2=80=99s use case is that = what we=E2=80=99re calling the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an = =E2=80=9CAS=E2=80=9D in the traditional OAuth/GNAP sense, at least not = exactly. This is the agent that the RO can use to set policies and = manage consent on their behalf, and I=E2=80=99ve been arguing that it = fits better into this vaguely-defined =E2=80=9Cinteraction component=E2=80= =9D aspect of the current AS definition, and it=E2=80=99s not currently = separated from the AS definition. The =E2=80=9CAS-RS=E2=80=9D maps to = what we=E2=80=99d call the =E2=80=9CAS=E2=80=9D in OAuth/GNAP = traditionally, it=E2=80=99s what the RS trusts to issue tokens. In = traditional OAuth the AS-RO and AS-RS are always the same thing, from a = functional protocol perspective. An important point here is that from a = client=E2=80=99s perspective, they=E2=80=99re only talking to the AS-RS = since that=E2=80=99s where the client gets its tokens, because at the = end of the day the client just wants to call the API at the RS and = doesn=E2=80=99t care how that happens (from a protocol standpoint).=20 >>=20 >> Note well: Even thought I don=E2=80=99t believe that =E2=80=9CAS-RO=E2=80= =9D is an authorization server at all, I=E2=80=99m going to keep using = that term below for consistency with previous discussion. >>=20 >> So we have these fundamental relationships around getting the client = to access the RS: >>=20 >> 1. RS trusts AS-RS to issue tokens that RS will accept, validate, and = process for requests from client >> 2. Client trusts AS-RS to issue tokens that client can use at RS >> 3. RO trusts RS to protect RO=E2=80=99s api through delegated access >>=20 >> On top of that, we=E2=80=99ve got some additional aspects that = we=E2=80=99re discussing: >>=20 >> 4. RO trusts AS-RO to manage RO=E2=80=99s policies at runtime >> 5. AS-RS trusts AS-RO to assert RO=E2=80=99s policies for access to = RS >> 6. Client trusts whatever AS-RS sends client to deal with, including = possibly RO-AS at runtime, because of (2) >>=20 >> What I have been saying is that 4/5/6 are optional details of how = RS-AS runs things, and I think this also maps with Adrian=E2=80=99s view = of choice, since if my RS=E2=80=99s AS-RS doesn=E2=80=99t allow me to = plug in my own AS-RO then I would be motivated to pick a different RS = who=E2=80=99s AS-RS lets me do just that. The same way I=E2=80=99d pick = a different RS if their surrounding services didn=E2=80=99t accept my = preferred federation login and I didn=E2=80=99t want to make another = account. Of course, market forces being as they are, I might not have = much of an actionable choice in RS, but GNAP can=E2=80=99t change that.=20= >>=20 >> What we can do is make it possible for AS-RS to talk to AS-RO, both = in philosophy of the protocol design and in concrete hooks to support = (6) above.=20 >>=20 >> Separately, we can approach the issue of making 1/2 above more = dynamic. This was UMA2=E2=80=99s =E2=80=9Cfederated authorization=E2=80=9D= approach, and is behind a lot of the =E2=80=9Cbring your own AS=E2=80=9D = models out there. The problem with these is that we know from many years = of experience that most RS=E2=80=99s aren=E2=80=99t interested in doing = anything of the sort. >>=20 >> So with GNAP we can instead allow 4/5/6 to vary in a predictable and = consistent way, letting the RS keep control over 1/2, thereby enabling = choice in (3). We don=E2=80=99t have to be the ones who define the all = of the details of every permutation of (5) to enable this, though. Some = of this is going to be configuration out of band, some of it=E2=80=99s = going to be communication at runtime. This is where VC=E2=80=99s, ZCAPs, = CHAPI, DIDComm, FIDO, and a whole swath of other tech can come in and = help out. I don=E2=80=99t think we need to put all the details for using = these into core, nor do I think we=E2=80=99ll pull of The Great And = Ultimate Abstraction for using these and other approaches. But we can at = least start talking about =E2=80=9CAS-RS=E2=80=9D in such a way that it = no longer assumes it=E2=80=99s always the same party dealing with the RO = directly. >>=20 >> =E2=80=94 Justin >>=20 >>> On Mar 25, 2021, at 6:40 AM, Fabien Imbault = > wrote: >>>=20 >>> To reframe it closer to GNAP: >>> - AS =3D AS-RO, that's where you find the RO policies. The AS issues = access tokens to the client. >>> - the RO policies could be a) defined locally or b) in relationship = with the RS >>>=20 >>> There have been several ideas related to the AS-RS relationship b: >>> b1) the RS issues capabilities (which can be further attenuated by = the RO) >>> b2) Adrian also discussed a DID based solution >>> b3) there was also an alternative ACL proposal from Denis (+ = preflight) >>>=20 >>> Fabien >>>=20 >>>=20 >>> On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault = > wrote: >>> Ok so I get you correctly:=20 >>> - what matters is the RQ (could be a RO or a end-user or both : we = don't really care at a high-level, they're all treated as entities that = make a request) >>> - the policy is able to handle those different cases, based on its = own internal delegation protocol >>> - currently that requires AS-RS and AS-RO, but maybe it can be = simplified >>>=20 >>> To answer to Denis, here's what I understood: >>> - RO trusts AS-RS (and then handles its own policies within AS-RO) >>> - end-user trusts AS-RO (through its client) >>>=20 >>> Could probably work but that's a fairly different model compared to = OAuth2 (and of today's GNAP), with different frontiers between the AS = and the RS.=20 >>>=20 >>> Please do not hesitate to correct me if I'm wrong. >>>=20 >>> Fabien=20 >>>=20 >>> On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper = > wrote: >>> I believe there are alternatives to having two kinds of ASs. The = problem may be a side-effect of deciding to switch away form treating = the RO as different from the RQ. That leads to downstream privacy = issues. Our desire for architectural simplicity is admirable but that = may have been a step too far. >>>=20 >>> There may also be solutions based on different types of tokens, as = in different capabilities (tokens signed by the RS) vs. tokens signed by = the AS. I=E2=80=99m not sure about that but Alan might have more to say. >>>=20 >>> Adrian >>>=20 >>> On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault = > wrote: >>> Thanks. The general problem statement is clear. >>>=20 >>> The proposed solution a bit less (to me). I understood that from = point 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obvious = reason to have two types of ASs". Do you see an alternative ? >>>=20 >>> Regarding the last item, I don't think that naming RQ by end-user = created the problem. It might just highlight the asymmetry, which = fundamentally exists.=20 >>>=20 >>> Fabien >>>=20 >>>=20 >>> On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper = > wrote: >>> Recap: >>> 1 - Justin (I think) introduced the idea of an AS on the RS trust = boundary side. >>> 2 - I said the RO should not have to share policies with the RS. >>> 3 - Alan invented the concept of AS-RO and AS-RS to separate two = kinds of PDPs.=20 >>>=20 >>> The thing is that step 2 is not symmetrical. The RO has a legitimate = privacy interest in keeping their policies private and minimizing the = leakage of information about requests that are posed against those = policies.=20 >>>=20 >>> The RS, on the other hand, should be publishing its policies (e.g. = what it=E2=80=99s selling or what jurisdiction it=E2=80=99s in or what = tokens or scopes it supports). The RS has no obvious privacy interest in = GNAP. It=E2=80=99s just an enforcer. >>>=20 >>> There is one other privacy interest to consider around the RS and = that is the requesting party (the end-user that is not the RO :-) might = prefer to share attributes with the RS instead of the RO or something = controlled by the RO. This case could be an =E2=80=9Cextension=E2=80=9D = to GNAP and might result in a split AS as a solution. This problem was = introduced when the editors decided to replace RQ with end-user. = Obviously, the RO end-user has no privacy interests relative to itself. >>>=20 >>> Adrian >>>=20 >>>=20 >>>=20 >>>=20 >>> On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault = > wrote: >>> I was referring to "By my definition, this model has two ASs since = both are processing requests into tokens". If there's no reason to have = 2 types of ASs, that's fine then.=20 >>> But I'm a bit lost in where we stand with the idea.=20 >>>=20 >>> Could you recap?=20 >>>=20 >>> Fabien=20 >>>=20 >>> Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper = > a =C3=A9crit : >>> There=E2=80=99s no obvious reason to have two types of ASs. Any AS = that is executing the policies of the RS can look to GNAP like the RS = itself. Why would GNAP expose that interface to anyone?=20 >>>=20 >>> Adrian >>>=20 >>> On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault = > wrote: >>> Note : I'm not sure that's a good idea, but having 2 types of ASs is = not that easy to grasp. >>>=20 >>> Fabien=20 >>>=20 >>> Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault = > a =C3=A9crit = : >>> The purpose of either handling policies locally or delegating them = to the RO agent.=20 >>>=20 >>> Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper = > a =C3=A9crit : >>> What purpose would be served by GNAP splitting the AS into two = components? >>>=20 >>> Adrian=20 >>>=20 >>> On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault = > wrote: >>> Isn't the AS-RO a component of the AS? Same idea as the interact = component, it functionnally belongs to the AS role but could be deployed = either as a monolith or as a separate component? >>>=20 >>> Fabien >>>=20 >>> Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper = > a =C3=A9crit : >>> Yes, but I would say it=E2=80=99s not the RO that wants the access = token. It=E2=80=99s the RO that wants the client making the request to = get an access token.=20 >>>=20 >>> Adrian >>>=20 >>> On Wed, Mar 24, 2021 at 11:22 PM Alan Karp > wrote: >>> Adrian Gropper > wrote: >>>=20 >>> In this design, the AS is the AS-RS and the agent is the AS-RO. By = my definition, this model has two ASs since both are processing requests = into tokens. The problem with this is complexity and privacy. The RO may = not want to share the request information with the AS-RS. >>>=20 >>> More precisely, RO has no choice but to present the required = information to AS-RS if RO wants an access token. However, RO does not = want AS-RS to know the policy by which RO delegates tokens. That's why = RO uses AS-RO for those delegations. >>>=20 >>> -------------- >>> Alan Karp >>>=20 >>>=20 >>> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper = > wrote: >>> Thank you for creating the issue. My definition of AS is independent = of AS-RO or AS-RS. = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomment= -806280421 = I also agree with Alan's definition based on delegation. An = AS-RS would be a delegate of the RS.=20 >>>=20 >>> Based on that, I see it as obvious that the policy has to be = accessible (defined locally?) in order for it to be run as the code that = turns a request into an access token.=20 >>>=20 >>> The only other possibility is that the request is packaged by the AS = and sent elsewhere (an agent) for evaluation against policy and a = proto-token returned. In that case the AS is acting as a proxy and the = PDP is elsewhere. I can imagine that an AS-RS would behave this way so = that the proto-token could be turned into an access token by the AS-RS. = Isn't this what Justin is proposing? In this design, the AS is the AS-RS = and the agent is the AS-RO. By my definition, this model has two ASs = since both are processing requests into tokens. The problem with this is = complexity and privacy. The RO may not want to share the request = information with the AS-RS. >>>=20 >>> Adrian >>>=20 >>> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault = > wrote: >>> Isn't that what the AS is supposed to be, only with the caveat that = the policy is defined locally?=20 >>>=20 >>> Fabien=20 >>>=20 >>>=20 >>> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp > a =C3=A9crit : >>> AS-RO is an AS that RO trusts to delegate RO's access tokens = according to RO's policies. =20 >>>=20 >>> -------------- >>> Alan Karp >>>=20 >>>=20 >>> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault = > wrote: >>> Hi Alan and Adrian, >>>=20 >>> I've created issue AS-RO policy delegation = (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223 = ) to = capture your input.=20 >>> A first question that arises: can we give a definition to AS-RO? >>>=20 >>> Thanks >>> Fabien >>>=20 >>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp > wrote: >>> Fabien Imbault > wrote: >>> Hi Alan,=20 >>>=20 >>> Yes, but in that flow, the token relationship between AS-RS and = AS-RO is only secure if the tokens issued by AS-RS are cryptographically = attenuable in the first place.=20 >>> =20 >>> Attenuated delegation is a requirement, but that doesn't have to be = done cryptographically. Token exchange works just fine. SPKI and = zcap-ld are examples of the crypto approach, and we used token exchange = in the system for HP. >>>=20 >>> -------------- >>> Alan Karp >>>=20 >>>=20 >>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault = > wrote: >>> Hi Alan,=20 >>>=20 >>> Yes, but in that flow, the token relationship between AS-RS and = AS-RO is only secure if the tokens issued by AS-RS are cryptographically = attenuable in the first place.=20 >>>=20 >>> Fabien >>>=20 >>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp > wrote: >>> Justin Richer > wrote: >>>=20 >>> But with all that in mind, I think the key here is going to be = looking at what the inputs to the AS are, and how those can be defined = in an interoperable way for AS=E2=80=99s that can accept them. I think = there=E2=80=99s a lot of room for innovation and flexibility here that = doesn=E2=80=99t break the trust model or core use cases. If I have an = AS-RS set that won=E2=80=99t accept my favorite flavor of policy engine = inputs, then I can decide not to use that one. But this is a very = different question than saying the RS itself needs to accept my own AS = =E2=80=94 and we can=E2=80=99t keep conflating these two models. >>>=20 >>> I agree. The point of having an AS-RO is to allow RO to specify a = policy for which of RO's access tokens should be delegated under what = conditions. AS-RS should not need to understand those policies. The = flow would be >>> RO contacts AS-RS and gets one or more access tokens. >>> RO delegates one or more of those tokens, potentially sub-scoped, to = AS-RO. >>> A different user contacts AS-RO to get a potentially sub-scoped = access token from AS-RO. >>> That user presents the access token delegated by AS-RO when invoking = the resource. >>> AS-RS only needs to verify that the delegation chain is legitimate, = e.g., no increase in scope, and that it grants permission for the = request being made. AS-RS does not need to understand the policy behind = granting the delegation by AS-RO. >>>=20 >>> -------------- >>> Alan Karp >>>=20 >>>=20 >>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer > wrote: >>> Adrian, >>>=20 >>> I think this shows the problem with the terminology as it=E2=80=99s = been applied in this conversation, which I=E2=80=99ve tried to shine = light on before. What you and others are calling the =E2=80=9CRS=E2=80=9D = is really the =E2=80=9CAS and RS working together=E2=80=9D =E2=80=94 = everything to the right of the line. When Denis had brought up = =E2=80=9Celiminating the AS=E2=80=9D in another thread, what he=E2=80=99d = really done is labeled everything to the right of the line as the = =E2=80=9CRS=E2=80=9D. Of course, the irony here is that everything to = the right of the line used all be called the =E2=80=9CAS=E2=80=9D or = simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say below, I = don=E2=80=99t want the client to have visibility on what happens on that = side.=20 >>>=20 >>> Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the = diagram is not the AS, as far as GNAP is concerned. It does not issue an = access token that the RS will accept. The elements to the left of the = line could be a lot of things, but they are NOT the AS =E2=80=94 by = definition. The client lives over on the left, but so do any external = inputs to the AS. These could be policy inputs on behalf of the RO, they = could be presentation artifacts, they could be federated logins, they = could be the output of policy decisions. How the AS comes to trust those = things is up to the AS=E2=80=99s implementation. It=E2=80=99s something = we can talk about, but ultimately GNAP won=E2=80=99t be in any position = to dictate because in practice some AS=E2=80=99s are simply going to = internalize all policies and we will never successfully force those = open.=20 >>>=20 >>> But with all that in mind, I think the key here is going to be = looking at what the inputs to the AS are, and how those can be defined = in an interoperable way for AS=E2=80=99s that can accept them. I think = there=E2=80=99s a lot of room for innovation and flexibility here that = doesn=E2=80=99t break the trust model or core use cases. If I have an = AS-RS set that won=E2=80=99t accept my favorite flavor of policy engine = inputs, then I can decide not to use that one. But this is a very = different question than saying the RS itself needs to accept my own AS = =E2=80=94 and we can=E2=80=99t keep conflating these two models. >>>=20 >>> So to me, GNAP can support a Zero Trust Architecture by LEVERAGING = the AS, not by subsuming or eliminating it. It is in fact the AS, not = the client and not the RS, that will request and consume the results of = a privacy-preserving zero-trust policy query thing. Anything that = happens downstream from that is of little concern to the zero-trust = components because, as you point out, it=E2=80=99s on the =E2=80=9Cother = side=E2=80=9D of the line.=20 >>>=20 >>> I think we got this basic component model pretty right in OAuth: the = AS and RS and client working together. Where OAuth misses the mark is = the assumption that the user has to log in to the AS through a webpage = and interact directly, thereby proving they=E2=80=99re the RO. It=E2=80=99= s this latter space where I think we can both push innovation and also = address the important and compelling use cases like the ones you=E2=80=99r= e bringing. >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper > wrote: >>>>=20 >>>> I'm sorry, Justin. As a Resource Owner, I look at the RS trust = boundary (the dotted line in the diagram) as being the RS. I don't = expect any visibility into what's going on on the right.=20 >>>>=20 >>>> My problem with the framing you propose is that requests are going = to the RS (or the AS-RS) and I don't want to share my policies with the = AS-RS. I want to keep the RS and AS-RS as ignorant as possible. >>>>=20 >>>> Adrian >>>>=20 >>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer > wrote: >>>> Adrian, >>>>=20 >>>> What you=E2=80=99re discussing below, in terms of logging in to a = site, is not approaching the RS. You are in fact approaching the client, = and identifying both the AS and RS to the client. The client is a client = of your identity in this model, and the RS is part of the identity = provider. It=E2=80=99s really important that we don=E2=80=99t conflate = the RS and client in this way as it leads to a lot of confusion = downstream and a lot of broken trust boundaries. >>>>=20 >>>> With that model in mind, approaching the =E2=80=9CRS" and providing = it your identity is really just a case of the =E2=80=9Cfederated login = to AS=E2=80=9D pattern that we discussed on the WG call. The user here = approaches an RS, which has its own AS. To share things from this RS, = the RO has to authenticate to the RS=E2=80=99s AS. This particular AS = allows the RO to do so using an external identity =E2=80=94 in which = case, the AS is now a =E2=80=9Cclient=E2=80=9D of a separate, = disconnected (but layered) delegation. The ultimate client that = eventually calls the RS down the way may or may not know about these = layers.=20 >>>>=20 >>>> >>>> This same AS, which is closely tied to the RS and trusted by the = RS, might also take in FIDO credentials, or DIDs, or any number of other = proof mechanisms. The output of this is an access token the RS trusts, = but the input is up to the AS. The RS is not what you=E2=80=99re logging = in to. >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper = > wrote: >>>>>=20 >>>>> I too am in favor of avoiding consolidation and correlation. Right = now, when I approach a service provider (RS) for the first time, I'm = offered the opportunity to identify my persona as: email, sign-in with = Google, Facebook, or Apple. I know there are people who try to create = one-off email addresses but that is mostly a waste of time.=20 >>>>>=20 >>>>> So, along come FIDO2 and DID wallets to the rescue. Now, in = theory, I have a way to start out my RS relationship pseudonymously.=20 >>>>>=20 >>>>> When I want my resource to be discovered or shared I will post = that RS URL including my pseudonym. If I then want to introduce a = mediator in front of my AS or messaging service endpoint, I have that = option. If I want to keep requests away from the mediator, I would = publish an encryption key along with my pseudonym. >>>>>=20 >>>>> - Adrian >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer > wrote: >>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk > wrote: >>>>> >=20 >>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote: >>>>> >> @Alan Karp > = shared a talk about the Principle Of Least >>>>> >> Authority (POLA) in a recent comment >>>>> >> = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment= -803099693 = >>>>> >> I recommend it. >>>>> >>=20 >>>>> >> We might expect a protocol with authorization in the title to = use authority >>>>> >> as a core principle. I advocate for a GNAP design that = maximizes the power >>>>> >> of the RO, to be seen as a human rights issue when the RO is a = human. This >>>>> >> causes me to ask how to combine better security with better = human rights in >>>>> >> GNAP. >>>>> >>=20 >>>>> >> Who should have the least authority in the GNAP design? >>>>> >>=20 >>>>> >> The AS derives authority as a delegate of the RO. If we ask the = RO to >>>>> >> partition limited authority across dozens of different ASs by = domain and >>>>> >> function, then we are not using technology to empower the = individual. >>>>> >> Probably the opposite, as we introduce consent fatigue and = burden normal >>>>> >> people to partition their lives into non-overlapping domains. >>>>> >>=20 >>>>> >> My experience says we should aim for one AS per persona because = that maps >>>>> >> into the way we manage our public and private identities. POLA = would then >>>>> >> teach care in keeping ASs and RSs related to work / public = separate from >>>>> >> ASs and RSs related to private life so that a policy = vulnerability in our >>>>> >> delegation to an AS would have the least likelihood of harm. >>>>> >=20 >>>>> > Thinking about how least authority/least privilege would apply = to GNAP >>>>> > seems like a useful exercise. I do want to point out some = potential >>>>> > pitfalls with one-AS-per-persona that we can also be aware of. = If >>>>> > one-AS-per-persona becomes one-persona-per-AS as well, then the = AS's >>>>> > identity in effect also serves as a persona identity and there = are privacy >>>>> > considerations to that. If, on the other hand, the >>>>> > multiple-personas-per-AS (presumably corresponding to multiple = humans) >>>>> > route is taken, we should consider whether that would lead to = various >>>>> > (e.g., market) forces driving consolidation to just a handful of >>>>> > super-popular AS services. That topic is a current matter of = concern to >>>>> > some IETF participants. >>>>> >=20 >>>>>=20 >>>>> Hi Ben, big +1 to this. This is something that we discussed ages = ago in the UMA working group, and it=E2=80=99s one of the biggest = problems with the personal AS (and personal data store) model. This kind = of thing makes RS-first trust models really difficult in practice. >>>>>=20 >>>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve got software = that wants to access my medical information. It calls an RS and requests = access, but it hasn=E2=80=99t been granted anything yet. Now I as the RO = have set up the RS so that it talks to my personal AS, that only I use. = In addition to the RS having to be able to figure out which medical = records are being requested from the context of the unauthenticated = request (which means it needs identifiers in the URL or something = similar for the RS to be able to tell, assuming that it protects data = for more than one person). So this client software doesn=E2=80=99t know = who I am and doesn=E2=80=99t know my medical record information, makes a = completely unauthorized request to the RS, and the RS says =E2=80=9CGo = to Justin=E2=80=99s personal AS to get a token=E2=80=9D. The client can = now make a direct correlation between the data that=E2=80=99s being = protected at the RS and the person running the AS that protects it. = Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This = is a design feature in the good case, and terrifying in the bad case. >>>>>=20 >>>>> If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, = please talk to the Medicine Doctor AS to get access=E2=80=9D, we = haven=E2=80=99t exposed anything at all. And from the perspective of = both the patient and the RS, this is more privacy-preserving, and it=E2=80= =99s really the least surprising option. Once the client gets to the AS, = it can start a negotiation of figuring out who the RO is for the = information being accessed. >>>>>=20 >>>>> On top of this, the usability expectations of people managing = their own AS, or set of AS=E2=80=99s for multiple personas to keep = things separate, is a huge burden. Even in the tech community, I know = people who can=E2=80=99t reliably manage more than one email address for = different purposes. I wouldn=E2=80=99t expect my partner to do that =E2=80= =94 they have trouble enough balancing all the logins and sessions = required for different kids remote schooling, I couldn=E2=80=99t imagine = them having to understand all the requirements for managing multiple = authorization servers and associated policies. I also don=E2=80=99t = expect any person to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve = been on the internet for decades and I can barely keep tabs on my GPG = keys, and only use them when I am forced to. This is exactly the kind of = =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions above, = people will just want to outsource that to someone else, and the reality = will be a few popular providers. >>>>>=20 >>>>> In which case, we could end up doing a ton of work to allow an RS = choice only to end up with a world where the RS ends up making a limited = choice anyway. We see how that plays out with OpenID Connect =E2=80=94 = RP=E2=80=99s could allow arbitrary IdPs but they choose Google because = it works and that=E2=80=99s where the users are. (And that=E2=80=99s not = to say anything of the proprietary OIDC-like protocols, but that=E2=80=99s= another discussion). >>>>>=20 >>>>> For further reading on these topics, I recommend both =E2=80=9CWhy = Johnny Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems = Fail=E2=80=9D. >>>>>=20 >>>>> So what does this have to do with GNAP? I think we can be = clear-eyed on what kinds of expectations we have for the participants. = If we expect users (RO=E2=80=99s) to have to set up the AS-RS = relationship, or expect them to carry their AS, or manage their personal = keys =E2=80=94 I think we=E2=80=99ve lost the battle for relevance. >>>>>=20 >>>>> =E2=80=94 Justin >>>>=20 >>>=20 >>> --=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 = >>> --=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 = --Apple-Mail=_80EA8814-CD22-4B08-9404-07787EFB09C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    I have a big problem with this line:

    > the RS and AS-RS only see access tokens. = The requests (from RO') that resulted in an access token are none of = their business.

    In the = trust model we=E2=80=99ve been discussing, the requests that result in = access tokens are solely the business of AS-RS, since = AS-RS is the only entity that=E2=80=99s allowed, and trusted by the RS, = to create access tokens for the RS. That is its entire job, the entire = reason it exists in the system. By definition the party generating = tokens for use at the RS is the AS for that RS, I don=E2=80=99t care how = you deploy it. If RO wants to give access to someone else (who isn=E2=80=99= t an =E2=80=9CRO" anymore, they=E2=80=99re another end-user), then that = end user=E2=80=99s client software will need to talk to AS-RS to get its = own access token.

    Now = here=E2=80=99s the trick: when the end user=E2=80=99s client instance = talks to AS-RS, that does NOT mean that AS-RS needs to know all the = details and policy reasons that it should give an access token to that = client instance. It doesn=E2=80=99t even need to know the existence of = another end user. It doesn=E2=80=99t need identity, it doesn=E2=80=99t = need policy. Sure, it COULD handle all of that internally, and many = will, but the protocol doesn=E2=80=99t demand it. 

    This means that the = first client instance, the one that gets the access token, can also be = given something alongside the access token that it can then hand to = another piece of software (or to a person to hand eo their piece of = software). This artifact is not an access token. This artifact could be = something structured that the client understands, and can make = derivatives of, and present back to the AS-RS for getting new access = tokens. There could be multiple different flavors of this kind of = artifact for different kinds of environments and groups. But what they = all have in common is that they can potentially be used to request more = access tokens within some context at the AS-RS.

     =E2=80=94 Justin



    On Mar 25, 2021, at 5:50 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    My issue is with Alan's:
    "7. = Another user agent (RO') can contact any holder of the access token or = the service's policy agent (AS-RS) to get a delegated access = token."

    I would prefer = "7A. Another user agent (RO') can contact any holder of the access = token." by default so that the AS-RS does not see the requests. In other = words, the RS and AS-RS only see access tokens. The requests (from RO') = that resulted in an access token are none of their = business.

    The reality is that = RO' can discover a resource RS and can share whatever information with = RS-AS they want and the RO may not even know about it unless the RS = decides to let them know somehow. This seems to be a drawback of the = capabilities approach. 

    In terms of privacy = and control, I, as the RO, want a contract with the RS that says = that I or my agent (AS-RO) must sign an access token. This is a = fundamental audit requirement. Without it, a rogue RS and AS-RS can do = all sorts of things and the RO would never know. I understand that a = rogue RS might not support an honest contemporaneous log of access = tokens presented so there's a trust issue here that I seems unavoidable = unless I specify in my RO-RS contract that they use a separate = contemporaneous log such as AS-RO for every access token presented = and risk being sued if they process an access token without also = updating the separate log.

    - = Adrian


    On Thu, Mar = 25, 2021 at 1:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin = Richer <jricher@mit.edu> wrote:
    Hi Alan,
    In all of my discussion, and in the = spec itself, the RO is the :entity: in charge of approving rights. = They=E2=80=99re probably a person. It might be software that makes a = policy decision in some way, or a corporate entity, or something like = that. But it=E2=80=99s not assumed to be a computational agent in the = terms of the protocol itself. Would that recast what you=E2=80=99re = saying below?

    Hmmm.  I guess = not.  It's just that the person would be using some UI to express = their decisions to what I called the user agent.  That model fits = in very nicely with what we did with Polaris, our virus safe computing = environment for Windows XP, https://dl.acm.org/doi/10.1145/1151030.1151033.  The = person would click on the icon for a Word file, and an instance of Word = would open with only the permission needed to edit that one file.  = Same thing here.  The client could ask for permission to use the = resource, or permission could be granted implicitly when the user = selects a resource associated with a specific client.

    --------------
    Alan = Karp


    On Thu, Mar = 25, 2021 at 9:53 AM Justin Richer <jricher@mit.edu> wrote:
    Hi Alan,
    In all of my discussion, and in the = spec itself, the RO is the :entity: in charge of approving rights. = They=E2=80=99re probably a person. It might be software that makes a = policy decision in some way, or a corporate entity, or something like = that. But it=E2=80=99s not assumed to be a computational agent in the = terms of the protocol itself. Would that recast what you=E2=80=99re = saying below?

     =E2=80=94 Justin

    On Mar = 25, 2021, at 12:36 PM, Alan Karp <alanhkarp@gmail.com> wrote:

    There seems to be some confusion = about how AS-RO comes into the picture, probably because of the "AS" = part.  I'm going to try to clear up that confusion by more = carefully explaining what I mean.

    I'm assuming that RO is a computational agent representing = the person who is the resource owner, something called the "user agent" = in operating systems lingo.  I'm also assuming that it's possible = to do delegation, either locally or by token exchange with AS-RS.  = All delegations are potentially sub-scoped, but you may also want to = delegate with full scope to have a separately revocable access = token.

      = Here's an example of how things work in a capability oriented system.
    1. Someone, = the service owner, creates a service.
    2. The service = owner contracts with an policy agent (AS-RS) to create and manage access = tokens for that service (RS).
    3. A person wishing to = create a resource at RS uses their user agent (RO) to contact the = service owner's policy agent (AS-RS) and gets back an access token for = that resource.
    4. That user agent (RO) can 
      1. use that access token to invoke the resource, = or
      2. delegate an access token to a client of the user = agent's (RO) choice, or
      3. contract with a policy agent = (AS-RO) to manage those delegations on behalf of the user agent (RO), = or
      4. specify a policy with the service's policy agent = (AS-RS).
    5. A client can contact any holder of the = access token (the user agent (RO) or its policy agent (AS-RO)) or the = service's policy agent (AS-RS) to get a delegated access token.
    6. That client can delegate that token to another = client.
    7. Another user agent (RO') can contact any = holder of the access token or the service's policy agent (AS-RS) to get = a delegated access token.
    8. The other user agent (RO') = can 
      1. use that access token to = invoke the resource, or
      2. delegate it to a client of = its choice, or
      3. contract with a policy agent (AS-RO') = of its choosing to manage those delegations on its behalf, or
      4. specify a policy with the service's policy agent = (AS-RS).
    9. and so on
    When any of these = computational agents, user agents (ROs) or clients acting on their = behalf, invokes the resource, AS-RS verifies that the access token is a = valid delegation, i.e., proper sub-scoping, hasn't been revoked, and = that it authorizes the request being made before telling the service = (RS) to honor the request.  At no point does the service's policy = agent (AS-RS) know which computational agent did any particular = delegation.  (Token exchange can be done as anonymously as = possible.)  In particular, the policy agents (AS-RO) need not be = the same, or even compatible with, the service's policy agent = (AS-RS).  GNAP specifies the protocol between requesters, invokers, = delegators (for token exchange) of tokens and AS-RS.  That protocol = need not be used between user agents (RO), clients, or other policy = agents (AS-RO), but it is likely to be.

     -------------
    Alan Karp


    On Thu, Mar = 25, 2021 at 5:45 AM Justin Richer <jricher@mit.edu> wrote:
    The way I=E2=80=99m = thinking about Adrian=E2=80=99s use case is that what we=E2=80=99re = calling the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an =E2=80=9CAS=E2=80=9D = in the traditional OAuth/GNAP sense, at least not exactly. This is the = agent that the RO can use to set policies and manage consent on their = behalf, and I=E2=80=99ve been arguing that it fits better into this = vaguely-defined =E2=80=9Cinteraction component=E2=80=9D aspect of the = current AS definition, and it=E2=80=99s not currently separated from the = AS definition. The =E2=80=9CAS-RS=E2=80=9D maps to what we=E2=80=99d = call the =E2=80=9CAS=E2=80=9D in OAuth/GNAP traditionally, it=E2=80=99s = what the RS trusts to issue tokens. In traditional OAuth the AS-RO and = AS-RS are always the same thing, from a functional protocol perspective. = An important point here is that from a client=E2=80=99s perspective, = they=E2=80=99re only talking to the AS-RS since that=E2=80=99s where the = client gets its tokens, because at the end of the day the client just = wants to call the API at the RS and doesn=E2=80=99t care how that = happens (from a protocol standpoint). 

    Note well: Even thought I don=E2=80=99t = believe that =E2=80=9CAS-RO=E2=80=9D is an authorization server at all, = I=E2=80=99m going to keep using that term below for consistency with = previous discussion.

    So we have these fundamental relationships around getting the = client to access the RS:

    1. RS trusts AS-RS to issue tokens that RS will = accept, validate, and process for requests from client
    2. Client trusts AS-RS to issue tokens that client = can use at RS
    3. RO trusts RS to protect RO=E2=80=99s= api through delegated access

    On top of that, we=E2=80=99ve got some = additional aspects that we=E2=80=99re discussing:
    4. RO trusts AS-RO to manage = RO=E2=80=99s policies at runtime
    5. AS-RS trusts AS-RO to assert RO=E2=80=99= s policies for access to RS
    6. Client trusts = whatever AS-RS sends client to deal with, including possibly = RO-AS at runtime, because of (2)

    What I have been saying is that 4/5/6 = are optional details of how RS-AS runs things, and I think this also = maps with Adrian=E2=80=99s view of choice, since if my RS=E2=80=99s = AS-RS doesn=E2=80=99t allow me to plug in my own AS-RO then I would be = motivated to pick a different RS who=E2=80=99s AS-RS lets me do just = that. The same way I=E2=80=99d pick a different RS if their surrounding = services didn=E2=80=99t accept my preferred federation login and I = didn=E2=80=99t want to make another account. Of course, market forces = being as they are, I might not have much of an actionable choice in RS, = but GNAP can=E2=80=99t change that. 

    What we can do is make it possible for = AS-RS to talk to AS-RO, both in philosophy of the protocol design and in = concrete hooks to support (6) above. 

    Separately, we can approach the issue = of making 1/2 above more dynamic. This was UMA2=E2=80=99s =E2=80=9Cfederat= ed authorization=E2=80=9D approach, and is behind a lot of the =E2=80=9Cbr= ing your own AS=E2=80=9D models out there. The problem with these is = that we know from many years of experience that most RS=E2=80=99s = aren=E2=80=99t interested in doing anything of the sort.

    So with GNAP we can = instead allow 4/5/6 to vary in a predictable and consistent way, letting = the RS keep control over 1/2, thereby enabling choice in (3). We don=E2=80= =99t have to be the ones who define the all of the details of every = permutation of (5) to enable this, though. Some of this is going to be = configuration out of band, some of it=E2=80=99s going to be = communication at runtime. This is where VC=E2=80=99s, ZCAPs, CHAPI, = DIDComm, FIDO, and a whole swath of other tech can come in and help out. = I don=E2=80=99t think we need to put all the details for using these = into core, nor do I think we=E2=80=99ll pull of The Great And Ultimate = Abstraction for using these and other approaches. But we can at least = start talking about =E2=80=9CAS-RS=E2=80=9D in such a way that it no = longer assumes it=E2=80=99s always the same party dealing with the RO = directly.

     =E2=80=94 Justin

    On Mar = 25, 2021, at 6:40 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    To reframe it = closer to GNAP:
    - AS =3D AS-RO, that's where you find the = RO policies. The AS issues access tokens to the client.
    - the RO policies could be a) defined locally or b) in = relationship with the RS

    There have been several ideas related to the AS-RS = relationship b:
    b1) the RS issues = capabilities (which can be further attenuated by the RO)
    b2) Adrian also discussed a DID based solution
    b3) there was also an alternative ACL proposal from Denis (+ = preflight)

    Fabien


    On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Ok so I get = you correctly: 
    - what matters is the RQ (could be a = RO or a end-user or both : we don't really care at a high-level, they're = all treated as entities that make a request)
    - the = policy is able to handle those different cases, based on its own = internal delegation protocol
    - currently that = requires AS-RS and AS-RO, but maybe it can be simplified

    To answer to Denis, = here's what I understood:
    - RO trusts AS-RS (and = then handles its own policies within AS-RO)
    - end-user trusts AS-RO (through its client)

    Could probably work but = that's a fairly different model compared to OAuth2 (and of today's = GNAP), with different frontiers between the AS and the = RS. 

    Please= do not hesitate to correct me if I'm wrong.

    Fabien 

    On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper = <agropper@healthurl.com> wrote:
    I believe = there are alternatives to having two kinds of ASs. The problem may be a = side-effect of deciding to switch away form treating the RO as different = from the RQ. That leads to downstream privacy issues. Our desire for = architectural simplicity is admirable but that may have been a step too = far.

    There may also be solutions based on different = types of tokens, as in different capabilities (tokens signed by the RS) = vs. tokens signed by the AS. I=E2=80=99m not sure about that but Alan = might have more to say.

    Adrian

    On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Thanks. The = general problem statement is clear.

    The proposed solution a bit less = (to me). I understood that from point 2, Alan involves 2 ASs. You said : = "There=E2=80=99s no = obvious reason to have two types of ASs". Do you see an = alternative ?

    Regarding the last item, I don't think that = naming RQ by end-user created the problem. It might just highlight the = asymmetry, which fundamentally exists. 

    Fabien


    On Thu, Mar 25, 2021 at 8:48 AM Adrian = Gropper <agropper@healthurl.com> wrote:
    Recap:
    1 - Justin (I think) = introduced the idea of an AS on the RS trust boundary side.
    2 - I said the RO should not have to share = policies with the RS.
    3 - Alan = invented the concept of AS-RO and AS-RS to separate two kinds of = PDPs. 

    The thing is that step 2 is not symmetrical. The = RO has a legitimate privacy interest in keeping their policies private = and minimizing the leakage of information about requests that are posed = against those policies. 

    The RS, on the other hand, = should be publishing its policies (e.g. what it=E2=80=99s selling or = what jurisdiction it=E2=80=99s in or what tokens or scopes it supports). = The RS has no obvious privacy interest in GNAP. It=E2=80=99s just an = enforcer.

    There is one other privacy interest to consider = around the RS and that is the requesting party (the end-user that is not = the RO :-) might prefer to share attributes with the RS instead of the = RO or something controlled by the RO. This case could be an = =E2=80=9Cextension=E2=80=9D to GNAP and might result in a split AS as a = solution. This problem was introduced when the editors decided to = replace RQ with end-user. Obviously, the RO end-user has no privacy = interests relative to itself.

    Adrian




    On Thu, Mar = 25, 2021 at 3:24 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    I was referring to "By my definition, this model has two ASs since both are = processing requests into tokens". If there's no reason to have 2 types = of ASs, that's fine then. 
    But I'm a bit lost in = where we stand with the idea. 

    Could you = recap? 

    Fabien 

    Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper = <agropper@healthurl.com> a =C3=A9crit :
    There=E2=80=99= s no obvious reason to have two types of ASs. Any AS that is executing = the policies of the RS can look to GNAP like the RS itself. Why would = GNAP expose that interface to anyone? 

    Adrian

    On Thu, Mar = 25, 2021 at 3:11 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Note : I'm = not sure that's a good idea, but having 2 types of ASs is not that easy = to grasp.

    Fabien 

    Le jeu. 25 = mars 2021 =C3=A0 08:07, Fabien Imbault <fabien.imbault@gmail.com> a = =C3=A9crit :
    The purpose = of either handling policies locally or delegating them to the RO = agent. 

    Le jeu. 25 mars 2021 =C3=A0 08:04, = Adrian Gropper <agropper@healthurl.com> a =C3=A9crit :
    What purpose = would be served by GNAP splitting the AS into two components?

    Adrian 

    On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Isn't the = AS-RO a component of the AS? Same idea as the interact component, it = functionnally belongs to the AS role but could be deployed either as a = monolith or as a separate component?

    Fabien

    Le jeu. 25 = mars 2021 =C3=A0 04:26, Adrian Gropper <agropper@healthurl.com> = a =C3=A9crit :
    Yes, but I = would say it=E2=80=99s not the RO that wants the access token. It=E2=80=99= s the RO that wants the client making the request to get an access = token. 

    Adrian

    On Wed, Mar = 24, 2021 at 11:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Adrian = Gropper <agropper@healthurl.com> wrote:

    In this = design, the AS is the AS-RS and the agent is the AS-RO. By my = definition, this model has two ASs since both are processing requests = into tokens. The problem with this is complexity and privacy. The RO may = not want to share the request information with the AS-RS.

    More precisely, RO has = no choice but to present the required information to AS-RS if RO wants = an access token.  However, RO does not want AS-RS to know the = policy by which RO delegates tokens.  That's why RO uses AS-RO for = those delegations.

    --------------
    Alan Karp


    On Wed, Mar = 24, 2021 at 7:41 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Thank you for creating the issue. My definition = of AS is independent of AS-RO or AS-RS. https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#i= ssuecomment-806280421 I also agree with Alan's definition based on = delegation. An AS-RS would be a delegate of the RS. 

    Based on = that, I see it as obvious that the policy has to be accessible = (defined locally?) in order for it to be run as the code that turns a = request into an access token. 

    The only other possibility is that the = request is packaged by the AS and sent elsewhere (an agent) for = evaluation against policy and a proto-token returned. In that case the = AS is acting as a proxy and the PDP is elsewhere. I can imagine that an = AS-RS would behave this way so that the proto-token could be turned into = an access token by the AS-RS. Isn't this what Justin is proposing? In = this design, the AS is the AS-RS and the agent is the AS-RO. By my = definition, this model has two ASs since both are processing requests = into tokens. The problem with this is complexity and privacy. The RO may = not want to share the request information with the AS-RS.

    Adrian

    On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Isn't that what the AS is supposed to be, only with the = caveat that the policy is defined locally? 

    Fabien 


    Le mer. 24 = mars 2021 =C3=A0 20:17, Alan Karp <alanhkarp@gmail.com> a =C3=A9crit :
    AS-RO is an AS that RO trusts to delegate RO's = access tokens according to RO's policies.  

    --------------
    Alan Karp


    On Wed, Mar 24, 2021 at 9:36 AM Fabien = Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan and = Adrian,

    I've created = issue AS-RO policy delegation (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to capture your input. 
    A first question = that arises: can we give a definition to AS-RO?

    Thanks
    Fabien

    On Tue, Mar = 23, 2021 at 4:15 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi = Alan, 

    Yes, but = in that flow, the token relationship between AS-RS and AS-RO is only = secure if the tokens issued by AS-RS are cryptographically attenuable in = the first place. 
     
    Attenuated delegation is a requirement, but that doesn't have = to be done cryptographically.  Token exchange works just = fine.  SPKI and zcap-ld are examples of the crypto approach, and we = used token exchange in the system for HP.

    --------------
    Alan = Karp


    On Tue, Mar = 23, 2021 at 4:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi = Alan, 

    Yes, but = in that flow, the token relationship between AS-RS and AS-RO is only = secure if the tokens issued by AS-RS are cryptographically attenuable in = the first place. 

    Fabien

    On Mon, Mar = 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin = Richer <jricher@mit.edu> wrote:

    But with all that in mind, I think the = key here is going to be looking at what the inputs to the AS are, and = how those can be defined in an interoperable way for AS=E2=80=99s that = can accept them. I think there=E2=80=99s a lot of room for innovation = and flexibility here that doesn=E2=80=99t break the trust model or core = use cases. If I have an AS-RS set that won=E2=80=99t accept my favorite = flavor of policy engine inputs, then I can decide not to use that one. = But this is a very different question than saying the RS itself needs to = accept my own AS =E2=80=94 and we can=E2=80=99t keep conflating these = two models.

    I agree.  The = point of having an AS-RO is to allow RO to specify a policy for which of = RO's access tokens should be delegated under what conditions.  = AS-RS should not need to understand those policies.  The flow would = be
    • RO contacts AS-RS = and gets one or more access tokens.
    • RO delegates one = or more of those tokens, potentially sub-scoped, to AS-RO.
    • A different user contacts AS-RO to get a potentially = sub-scoped access token from AS-RO.
    • That user = presents the access token delegated by AS-RO when invoking the = resource.
    AS-RS only = needs to verify that the delegation chain is legitimate, e.g., no = increase in scope, and that it grants permission for the request being = made.  AS-RS does not need to understand the policy behind granting = the delegation by AS-RO.

    --------------
    Alan Karp


    On Mon, Mar 22, 2021 at 11:40 AM Justin = Richer <jricher@mit.edu> wrote:
    Adrian,

    I think this shows the problem with the = terminology as it=E2=80=99s been applied in this conversation, which = I=E2=80=99ve tried to shine light on before. What you and others are = calling the =E2=80=9CRS=E2=80=9D is really the =E2=80=9CAS and RS = working together=E2=80=9D =E2=80=94 everything to the right of the line. = When Denis had brought up =E2=80=9Celiminating the AS=E2=80=9D in = another thread, what he=E2=80=99d really done is labeled everything to = the right of the line as the =E2=80=9CRS=E2=80=9D. Of course, the irony = here is that everything to the right of the line used all be called the = =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 = days. As you say below, I don=E2=80=99t want the client to have = visibility on what happens on that side. 

    Note well: The Google+ logo labeled = =E2=80=9CIdP=E2=80=9D in the diagram is not the AS, as far as GNAP is = concerned. It does not issue an access token that the RS will accept. = The elements to the left of the line could be a lot of things, but they = are NOT the AS =E2=80=94 by definition. The client lives over on the = left, but so do any external inputs to the AS. These could be policy = inputs on behalf of the RO, they could be presentation artifacts, they = could be federated logins, they could be the output of policy decisions. = How the AS comes to trust those things is up to the AS=E2=80=99s = implementation. It=E2=80=99s something we can talk about, but ultimately = GNAP won=E2=80=99t be in any position to dictate because in practice = some AS=E2=80=99s are simply going to internalize all policies and we = will never successfully force those open. 

    But with all that in mind, I think the = key here is going to be looking at what the inputs to the AS are, and = how those can be defined in an interoperable way for AS=E2=80=99s that = can accept them. I think there=E2=80=99s a lot of room for innovation = and flexibility here that doesn=E2=80=99t break the trust model or core = use cases. If I have an AS-RS set that won=E2=80=99t accept my favorite = flavor of policy engine inputs, then I can decide not to use that one. = But this is a very different question than saying the RS itself needs to = accept my own AS =E2=80=94 and we can=E2=80=99t keep conflating these = two models.

    So = to me, GNAP can support a Zero Trust Architecture by LEVERAGING the AS, = not by subsuming or eliminating it. It is in fact the AS, not the client = and not the RS, that will request and consume the results of a = privacy-preserving zero-trust policy query thing. Anything that happens = downstream from that is of little concern to the zero-trust components = because, as you point out, it=E2=80=99s on the =E2=80=9Cother side=E2=80=9D= of the line. 

    I think we got this basic component model pretty right in = OAuth: the AS and RS and client working together. Where OAuth misses the = mark is the assumption that the user has to log in to the AS through a = webpage and interact directly, thereby proving they=E2=80=99re the RO. = It=E2=80=99s this latter space where I think we can both push innovation = and also address the important and compelling use cases like the ones = you=E2=80=99re bringing.

     =E2=80=94 Justin

    On Mar = 22, 2021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I'm sorry, Justin. As a Resource = Owner, I look at the RS trust boundary (the dotted line in the diagram) = as being the RS. I don't expect any visibility into what's going on on = the right. 

    My problem with the framing you propose is that requests are = going to the RS (or the AS-RS) and I don't want to share my policies = with the AS-RS. I want to keep the RS and AS-RS as ignorant as = possible.

    Adrian

    On Mon, Mar = 22, 2021 at 1:48 PM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    What you=E2=80=99re discussing below, = in terms of logging in to a site, is not approaching the RS. You are in = fact approaching the client, and identifying both the AS and RS to the = client. The client is a client of your identity in = this model, and the RS is part of the identity provider. It=E2=80=99s = really important that we don=E2=80=99t conflate the RS and client in = this way as it leads to a lot of confusion downstream and a lot of = broken trust boundaries.

    With that model in mind, approaching the =E2=80=9CRS" and = providing it your identity is really just a case of the =E2=80=9Cfederated= login to AS=E2=80=9D pattern that we discussed on the WG call. The user = here approaches an RS, which has its own AS. To share things from this = RS, the RO has to authenticate to the RS=E2=80=99s AS. This particular = AS allows the RO to do so using an external identity =E2=80=94 in which = case, the AS is now a =E2=80=9Cclient=E2=80=9D of a separate, = disconnected (but layered) delegation. The ultimate client that = eventually calls the RS down the way may or may not know about these = layers. 

    <PastedGraphic-1.png>
    This = same AS, which is closely tied to the RS and trusted by the RS, might = also take in FIDO credentials, or DIDs, or any number of other proof = mechanisms. The output of this is an access token the RS trusts, but the = input is up to the AS. The RS is not what you=E2=80=99re logging in = to.

     =E2=80= =94 Justin

    On Mar 22, 2021, at 1:28 PM, = Adrian Gropper <agropper@healthurl.com> = wrote:

    I = too am in favor of avoiding consolidation and correlation. Right now, = when I approach a service provider (RS) for the first time, I'm offered = the opportunity to identify my persona as: email, sign-in with Google, = Facebook, or Apple. I know there are people who try to create one-off = email addresses but that is mostly a waste of time. 

    So, along come FIDO2 and = DID wallets to the rescue. Now, in theory, I have a way to start out my = RS relationship pseudonymously. 

    When I want my resource to be = discovered or shared I will post that RS URL including my pseudonym. If = I then want to introduce a mediator in front of my AS or messaging = service endpoint, I have that option. If I want to keep requests = away from the mediator, I would publish an encryption key along with my = pseudonym.

    - = Adrian



    On Mon, Mar 22, 2021 at 9:55 AM Justin = Richer <jricher@mit.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin = Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhkarp@gmail.com> shared a talk = about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#i= ssuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to = use authority
    >> as a core principle. I advocate for a GNAP design that = maximizes the power
    >> of the RO, to be seen as a human rights issue when the RO is a = human. This
    >> causes me to ask how to combine better security with better = human rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the = RO to
    >> partition limited authority across dozens of different ASs by = domain and
    >> function, then we are not using technology to empower the = individual.
    >> Probably the opposite, as we introduce consent fatigue and = burden normal
    >> people to partition their lives into non-overlapping = domains.
    >>
    >> My experience says we should aim for one AS per persona because = that maps
    >> into the way we manage our public and private identities. POLA = would then
    >> teach care in keeping ASs and RSs related to work / public = separate from
    >> ASs and RSs related to private life so that a policy = vulnerability in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to = GNAP
    > seems like a useful exercise.  I do want to point out some = potential
    > pitfalls with one-AS-per-persona that we can also be aware = of.  If
    > one-AS-per-persona becomes one-persona-per-AS as well, then the = AS's
    > identity in effect also serves as a persona identity and there are = privacy
    > considerations to that.  If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple = humans)
    > route is taken, we should consider whether that would lead to = various
    > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.  That topic is a current matter of = concern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in = the UMA working group, and it=E2=80=99s one of the biggest problems with = the personal AS (and personal data store) model. This kind of thing = makes RS-first trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that = wants to access my medical information. It calls an RS and requests = access, but it hasn=E2=80=99t been granted anything yet. Now I as the RO = have set up the RS so that it talks to my personal AS, that only I use. = In addition to the RS having to be able to figure out which medical = records are being requested from the context of the unauthenticated = request (which means it needs identifiers in the URL or something = similar for the RS to be able to tell, assuming that it protects data = for more than one person). So this client software doesn=E2=80=99t know = who I am and doesn=E2=80=99t know my medical record information, makes a = completely unauthorized request to the RS, and the RS says =E2=80=9CGo = to Justin=E2=80=99s personal AS to get a token=E2=80=9D. The client can = now make a direct correlation between the data that=E2=80=99s being = protected at the RS and the person running the AS that protects it. = Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This = is a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please = talk to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t = exposed anything at all. And from the perspective of both the patient = and the RS, this is more privacy-preserving, and it=E2=80=99s really the = least surprising option. Once the client gets to the AS, it can start a = negotiation of figuring out who the RO is for the information being = accessed.

    On top of this, the usability expectations of people managing their own = AS, or set of AS=E2=80=99s for multiple personas to keep things = separate, is a huge burden. Even in the tech community, I know people = who can=E2=80=99t reliably manage more than one email address for = different purposes. I wouldn=E2=80=99t expect my partner to do that =E2=80= =94 they have trouble enough balancing all the logins and sessions = required for different kids remote schooling, I couldn=E2=80=99t imagine = them having to understand all the requirements for managing multiple = authorization servers and associated policies. I also don=E2=80=99t = expect any person to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve = been on the internet for decades and I can barely keep tabs on my GPG = keys, and only use them when I am forced to. This is exactly the kind of = =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions above, = people will just want to outsource that to someone else, and the reality = will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice = only to end up with a world where the RS ends up making a limited choice = anyway. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99= s could allow arbitrary IdPs but they choose Google because it works and = that=E2=80=99s where the users are. (And that=E2=80=99s not to say = anything of the proprietary OIDC-like protocols, but that=E2=80=99s = another discussion).

    For further reading on these topics, I recommend both =E2=80=9CWhy = Johnny Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems = Fail=E2=80=9D.

    So what does this have to do with GNAP? I think we can be clear-eyed on = what kinds of expectations we have for the participants. If we expect = users (RO=E2=80=99s) to have to set up the AS-RS relationship, or expect = them to carry their AS, or manage their personal keys =E2=80=94 I think = we=E2=80=99ve lost the battle for relevance.

     =E2=80=94 Justin


    --
    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
    =


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

    = --Apple-Mail=_80EA8814-CD22-4B08-9404-07787EFB09C3-- From nobody Fri Mar 26 05:31:23 2021 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 49AEF3A1D6C for ; Fri, 26 Mar 2021 05:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 Vswhwf3Yqzuf for ; Fri, 26 Mar 2021 05:31:15 -0700 (PDT) Received: from mail-ua1-f45.google.com (mail-ua1-f45.google.com [209.85.222.45]) (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 A6C6C3A1D70 for ; Fri, 26 Mar 2021 05:31:14 -0700 (PDT) Received: by mail-ua1-f45.google.com with SMTP id 97so1551774uav.7 for ; Fri, 26 Mar 2021 05:31:14 -0700 (PDT) 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=UGmwV+HqQbbqRHoIqUlc/sbFKLHM3CAE23P+gYq74HQ=; b=AnvzwRol7zH+1JC74XYz+qeAnG5JEhOWuxJaugAZMxhZsS5IiFdrHnr2k4elFDiIFH 631/pzIqzFsbl8rJa/R5p72N8E/7iyUBpx+EPrWy5dz6L+7lSvK1MSaJYo8QEKHpmyNI RTUA9eQKyPWmwbIpFK3cFpqSssRU41vMhyAofuQRJmt6C/sZ1ZeJxtfYWTCooir96cpO q/F/e8j3us2AVULUG1XDTFImmUriYJhIVXLhVvS3UgwQKFgBV/7PRXdUM3mWN9pUxz9D 2Az8aw9ZbSaO/FY4SHwA1E2g2mNIzTGbTDqratmd1MjrNiz0DsmFyZbPl1nc30fdAEjU P67g== X-Gm-Message-State: AOAM5315temSLQrnOZi/OUMI4/na05Z7EWnQSxTRU+jl0S96p9sVMrDs WmZI98K2sH8VduGzMNf3axtpFFfuwv7cLT7HAyI= X-Google-Smtp-Source: ABdhPJzbwmOxuQRsjwVPY8pIhz/1jsn9dxquznQkfcpXutWdfzRNeJ++k/kYuhg39TmvhbqyNwwmvt0XdA41I5V9d6g= X-Received: by 2002:ab0:30a3:: with SMTP id b3mr7196755uam.0.1616761872731; Fri, 26 Mar 2021 05:31:12 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> <5773FA7B-6891-4227-A8CA-2F506909B8CD@mit.edu> In-Reply-To: <5773FA7B-6891-4227-A8CA-2F506909B8CD@mit.edu> From: Adrian Gropper Date: Fri, 26 Mar 2021 08:30:59 -0400 Message-ID: To: Justin Richer Cc: Alan Karp , Benjamin Kaduk , Fabien Imbault , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="0000000000001c53bd05be6fb548" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2021 12:31:21 -0000 --0000000000001c53bd05be6fb548 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable @Justin, there=E2=80=99s no separation of concerns here. No partition betwe= en processor and controller. No data minimization. And, I see no obvious reason to make this the core of GNAP. The one thing we can probably all agree on is that there=E2=80=99s only one= RS and one RO. The core of GNAP, in my opinion, can be built and explained around this simple design. The RS is a processor. The RO is a controller. The RS bears only security responsibility. The RS bears no privacy responsibility. The RO delegates this to the RS but this is not authorization as the A in GNAP. The RO retains all rights to delegate within the scope of things that the RS is willing to support using various token formats and endpoint options. Some of these options may do all sorts of things for all sorts of clients and user-agents but these are options. For example, if a request comes to the RS that is not in the form of an access token, then it either gets sent to the RO or their agent, or it gets logged and dumped. One such option, common in healthcare, is =E2=80=9CBreak= the Glass=E2=80=9D where the RS is acting as an authorization server because th= e user-agent is making a request instead of presenting an access token. GNAP can offer this as an option but it is not our core. Adrian On Fri, Mar 26, 2021 at 7:15 AM Justin Richer wrote: > I have a big problem with this line: > > > the RS and AS-RS only see access tokens. The requests (from RO') that > resulted in an access token are none of their business. > > In the trust model we=E2=80=99ve been discussing, the requests that resul= t in > access tokens are *solely the business of AS-RS*, since AS-RS is the only > entity that=E2=80=99s allowed, and trusted by the RS, to create access to= kens for > the RS. That is its entire job, the entire reason it exists in the system= . > By definition the party generating tokens for use at the RS is the AS for > that RS, I don=E2=80=99t care how you deploy it. If RO wants to give acce= ss to > someone else (who isn=E2=80=99t an =E2=80=9CRO" anymore, they=E2=80=99re = another end-user), then > that end user=E2=80=99s client software will need to talk to AS-RS to get= its own > access token. > > Now here=E2=80=99s the trick: when the end user=E2=80=99s client instance= talks to AS-RS, > that does NOT mean that AS-RS needs to know all the details and policy > reasons that it should give an access token to that client instance. It > doesn=E2=80=99t even need to know the existence of another end user. It d= oesn=E2=80=99t > need identity, it doesn=E2=80=99t need policy. Sure, it COULD handle all = of that > internally, and many will, but the protocol doesn=E2=80=99t demand it. > > This means that the first client instance, the one that gets the access > token, can also be given something alongside the access token that it can > then hand to another piece of software (or to a person to hand eo their > piece of software). This artifact is not an access token. This artifact > could be something structured that the client understands, and can make > derivatives of, and present back to the AS-RS for getting new access > tokens. There could be multiple different flavors of this kind of artifac= t > for different kinds of environments and groups. But what they all have in > common is that they can potentially be used to request more access tokens > within some context at the AS-RS. > > =E2=80=94 Justin > > > > On Mar 25, 2021, at 5:50 PM, Adrian Gropper > wrote: > > My issue is with Alan's: > > "7. Another user agent (RO') can contact any holder of the access token o= r > the service's policy agent (AS-RS) to get a delegated access token." > > > I would prefer "7A. Another user agent (RO') can contact any holder of > the access token." by default so that the AS-RS does not see the requests= . > In other words, the RS and AS-RS only see access tokens. The requests (fr= om > RO') that resulted in an access token are none of their business. > > The reality is that RO' can discover a resource RS and can share whatever > information with RS-AS they want and the RO may not even know about it > unless the RS decides to let them know somehow. This seems to be a drawba= ck > of the capabilities approach. > > In terms of privacy and control, I, as the RO, want a contract with the R= S > that says that I or my agent (AS-RO) must sign an access token. This is a > fundamental audit requirement. Without it, a rogue RS and AS-RS can do al= l > sorts of things and the RO would never know. I understand that a rogue RS > might not support an honest contemporaneous log of access tokens presente= d > so there's a trust issue here that I seems unavoidable unless I specify i= n > my RO-RS contract that they use a separate contemporaneous log such as > AS-RO for every access token presented and risk being sued if they proces= s > an access token without also updating the separate log. > > - Adrian > > > On Thu, Mar 25, 2021 at 1:22 PM Alan Karp wrote: > >> Justin Richer wrote: >> >>> Hi Alan, >>> >>> In all of my discussion, and in the spec itself, the RO is the :entity: >>> in charge of approving rights. They=E2=80=99re probably a person. It mi= ght be >>> software that makes a policy decision in some way, or a corporate entit= y, >>> or something like that. But it=E2=80=99s not assumed to be a computatio= nal agent in >>> the terms of the protocol itself. Would that recast what you=E2=80=99re= saying >>> below? >>> >> >> Hmmm. I guess not. It's just that the person would be using some UI to >> express their decisions to what I called the user agent. That model fit= s >> in very nicely with what we did with Polaris, our virus safe computing >> environment for Windows XP, >> https://dl.acm.org/doi/10.1145/1151030.1151033. The person would click >> on the icon for a Word file, and an instance of Word would open with onl= y >> the permission needed to edit that one file. Same thing here. The clie= nt >> could ask for permission to use the resource, or permission could be >> granted implicitly when the user selects a resource associated with a >> specific client. >> >> -------------- >> Alan Karp >> >> >> On Thu, Mar 25, 2021 at 9:53 AM Justin Richer wrote: >> >>> Hi Alan, >>> >>> In all of my discussion, and in the spec itself, the RO is the :entity: >>> in charge of approving rights. They=E2=80=99re probably a person. It mi= ght be >>> software that makes a policy decision in some way, or a corporate entit= y, >>> or something like that. But it=E2=80=99s not assumed to be a computatio= nal agent in >>> the terms of the protocol itself. Would that recast what you=E2=80=99re= saying >>> below? >>> >>> =E2=80=94 Justin >>> >>> On Mar 25, 2021, at 12:36 PM, Alan Karp wrote: >>> >>> There seems to be some confusion about how AS-RO comes into the picture= , >>> probably because of the "AS" part. I'm going to try to clear up that >>> confusion by more carefully explaining what I mean. >>> >>> I'm assuming that RO is a computational agent representing the person >>> who is the resource owner, something called the "user agent" in operati= ng >>> systems lingo. I'm also assuming that it's possible to do delegation, >>> either locally or by token exchange with AS-RS. All delegations are >>> potentially sub-scoped, but you may also want to delegate with full sco= pe >>> to have a separately revocable access token. >>> >>> Here's an example of how things work in a capability oriented system. >>> >>> 1. Someone, the service owner, creates a service. >>> 2. The service owner contracts with an policy agent (AS-RS) to >>> create and manage access tokens for that service (RS). >>> 3. A person wishing to create a resource at RS uses their user agent >>> (RO) to contact the service owner's policy agent (AS-RS) and gets ba= ck an >>> access token for that resource. >>> 4. That user agent (RO) can >>> 1. use that access token to invoke the resource, or >>> 2. delegate an access token to a client of the user agent's (RO) >>> choice, or >>> 3. contract with a policy agent (AS-RO) to manage those >>> delegations on behalf of the user agent (RO), or >>> 4. specify a policy with the service's policy agent (AS-RS). >>> 5. A client can contact any holder of the access token (the user >>> agent (RO) or its policy agent (AS-RO)) or the service's policy agen= t >>> (AS-RS) to get a delegated access token. >>> 6. That client can delegate that token to another client. >>> 7. Another user agent (RO') can contact any holder of the access >>> token or the service's policy agent (AS-RS) to get a delegated acces= s token. >>> 8. The other user agent (RO') can >>> 1. use that access token to invoke the resource, or >>> 2. delegate it to a client of its choice, or >>> 3. contract with a policy agent (AS-RO') of its choosing to >>> manage those delegations on its behalf, or >>> 4. specify a policy with the service's policy agent (AS-RS). >>> 9. and so on >>> >>> When any of these computational agents, user agents (ROs) or clients >>> acting on their behalf, invokes the resource, AS-RS verifies that the >>> access token is a valid delegation, i.e., proper sub-scoping, hasn't be= en >>> revoked, and that it authorizes the request being made before telling t= he >>> service (RS) to honor the request. At no point does the service's poli= cy >>> agent (AS-RS) know which computational agent did any particular >>> delegation. (Token exchange can be done as anonymously as possible.) = In >>> particular, the policy agents (AS-RO) need not be the same, or even >>> compatible with, the service's policy agent (AS-RS). GNAP specifies th= e >>> protocol between requesters, invokers, delegators (for token exchange) = of >>> tokens and AS-RS. That protocol need not be used between user agents (= RO), >>> clients, or other policy agents (AS-RO), but it is likely to be. >>> >>> ------------- >>> Alan Karp >>> >>> >>> On Thu, Mar 25, 2021 at 5:45 AM Justin Richer wrote: >>> >>>> The way I=E2=80=99m thinking about Adrian=E2=80=99s use case is that w= hat we=E2=80=99re calling >>>> the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an =E2=80=9CAS=E2=80=9D in t= he traditional OAuth/GNAP sense, at least not >>>> exactly. This is the agent that the RO can use to set policies and man= age >>>> consent on their behalf, and I=E2=80=99ve been arguing that it fits be= tter into >>>> this vaguely-defined =E2=80=9Cinteraction component=E2=80=9D aspect of= the current AS >>>> definition, and it=E2=80=99s not currently separated from the AS defin= ition. The >>>> =E2=80=9CAS-RS=E2=80=9D maps to what we=E2=80=99d call the =E2=80=9CAS= =E2=80=9D in OAuth/GNAP traditionally, it=E2=80=99s >>>> what the RS trusts to issue tokens. In traditional OAuth the AS-RO and >>>> AS-RS are always the same thing, from a functional protocol perspectiv= e. An >>>> important point here is that from a client=E2=80=99s perspective, they= =E2=80=99re only >>>> talking to the AS-RS since that=E2=80=99s where the client gets its to= kens, because >>>> at the end of the day the client just wants to call the API at the RS = and >>>> doesn=E2=80=99t care how that happens (from a protocol standpoint). >>>> >>>> Note well: Even thought I don=E2=80=99t believe that =E2=80=9CAS-RO=E2= =80=9D is an >>>> authorization server at all, I=E2=80=99m going to keep using that term= below for >>>> consistency with previous discussion. >>>> >>>> So we have these fundamental relationships around getting the client t= o >>>> access the RS: >>>> >>>> 1. RS trusts AS-RS to issue tokens that RS will accept, validate, and >>>> process for requests from client >>>> 2. Client trusts AS-RS to issue tokens that client can use at RS >>>> 3. RO trusts RS to protect RO=E2=80=99s api through delegated access >>>> >>>> On top of that, we=E2=80=99ve got some additional aspects that we=E2= =80=99re discussing: >>>> >>>> 4. RO trusts AS-RO to manage RO=E2=80=99s policies at runtime >>>> 5. AS-RS trusts AS-RO to assert RO=E2=80=99s policies for access to RS >>>> 6. Client trusts whatever AS-RS sends client to deal with, including >>>> possibly RO-AS at runtime, because of (2) >>>> >>>> What I have been saying is that 4/5/6 are optional details of how RS-A= S >>>> runs things, and I think this also maps with Adrian=E2=80=99s view of = choice, since >>>> if my RS=E2=80=99s AS-RS doesn=E2=80=99t allow me to plug in my own AS= -RO then I would be >>>> motivated to pick a different RS who=E2=80=99s AS-RS lets me do just t= hat. The same >>>> way I=E2=80=99d pick a different RS if their surrounding services didn= =E2=80=99t accept my >>>> preferred federation login and I didn=E2=80=99t want to make another a= ccount. Of >>>> course, market forces being as they are, I might not have much of an >>>> actionable choice in RS, but GNAP can=E2=80=99t change that. >>>> >>>> What we can do is make it possible for AS-RS to talk to AS-RO, both in >>>> philosophy of the protocol design and in concrete hooks to support (6) >>>> above. >>>> >>>> Separately, we can approach the issue of making 1/2 above more dynamic= . >>>> This was UMA2=E2=80=99s =E2=80=9Cfederated authorization=E2=80=9D appr= oach, and is behind a lot of >>>> the =E2=80=9Cbring your own AS=E2=80=9D models out there. The problem = with these is that we >>>> know from many years of experience that most RS=E2=80=99s aren=E2=80= =99t interested in >>>> doing anything of the sort. >>>> >>>> So with GNAP we can instead allow 4/5/6 to vary in a predictable and >>>> consistent way, letting the RS keep control over 1/2, thereby enabling >>>> choice in (3). We don=E2=80=99t have to be the ones who define the all= of the >>>> details of every permutation of (5) to enable this, though. Some of th= is is >>>> going to be configuration out of band, some of it=E2=80=99s going to b= e >>>> communication at runtime. This is where VC=E2=80=99s, ZCAPs, CHAPI, DI= DComm, FIDO, >>>> and a whole swath of other tech can come in and help out. I don=E2=80= =99t think we >>>> need to put all the details for using these into core, nor do I think = we=E2=80=99ll >>>> pull of The Great And Ultimate Abstraction for using these and other >>>> approaches. But we can at least start talking about =E2=80=9CAS-RS=E2= =80=9D in such a way >>>> that it no longer assumes it=E2=80=99s always the same party dealing w= ith the RO >>>> directly. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Mar 25, 2021, at 6:40 AM, Fabien Imbault >>>> wrote: >>>> >>>> To reframe it closer to GNAP: >>>> - AS =3D AS-RO, that's where you find the RO policies. The AS issues >>>> access tokens to the client. >>>> - the RO policies could be a) defined locally or b) in relationship >>>> with the RS >>>> >>>> There have been several ideas related to the AS-RS relationship b: >>>> b1) the RS issues capabilities (which can be further attenuated by the >>>> RO) >>>> b2) Adrian also discussed a DID based solution >>>> b3) there was also an alternative ACL proposal from Denis (+ preflight= ) >>>> >>>> Fabien >>>> >>>> >>>> On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Ok so I get you correctly: >>>>> - what matters is the RQ (could be a RO or a end-user or both : we >>>>> don't really care at a high-level, they're all treated as entities th= at >>>>> make a request) >>>>> - the policy is able to handle those different cases, based on its ow= n >>>>> internal delegation protocol >>>>> - currently that requires AS-RS and AS-RO, but maybe it can be >>>>> simplified >>>>> >>>>> To answer to Denis, here's what I understood: >>>>> - RO trusts AS-RS (and then handles its own policies within AS-RO) >>>>> - end-user trusts AS-RO (through its client) >>>>> >>>>> Could probably work but that's a fairly different model compared to >>>>> OAuth2 (and of today's GNAP), with different frontiers between the AS= and >>>>> the RS. >>>>> >>>>> Please do not hesitate to correct me if I'm wrong. >>>>> >>>>> Fabien >>>>> >>>>> On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper >>>>> wrote: >>>>> >>>>>> I believe there are alternatives to having two kinds of ASs. The >>>>>> problem may be a side-effect of deciding to switch away form treatin= g the >>>>>> RO as different from the RQ. That leads to downstream privacy issues= . Our >>>>>> desire for architectural simplicity is admirable but that may have b= een a >>>>>> step too far. >>>>>> >>>>>> There may also be solutions based on different types of tokens, as i= n >>>>>> different capabilities (tokens signed by the RS) vs. tokens signed b= y the >>>>>> AS. I=E2=80=99m not sure about that but Alan might have more to say. >>>>>> >>>>>> Adrian >>>>>> >>>>>> On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>>> Thanks. The general problem statement is clear. >>>>>>> >>>>>>> The proposed solution a bit less (to me). I understood that from >>>>>>> point 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obviou= s reason >>>>>>> to have two types of ASs". Do you see an alternative ? >>>>>>> >>>>>>> Regarding the last item, I don't think that naming RQ by end-user >>>>>>> created the problem. It might just highlight the asymmetry, which >>>>>>> fundamentally exists. >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> >>>>>>> On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper < >>>>>>> agropper@healthurl.com> wrote: >>>>>>> >>>>>>>> Recap: >>>>>>>> 1 - Justin (I think) introduced the idea of an AS on the RS trust >>>>>>>> boundary side. >>>>>>>> 2 - I said the RO should not have to share policies with the RS. >>>>>>>> 3 - Alan invented the concept of AS-RO and AS-RS to separate two >>>>>>>> kinds of PDPs. >>>>>>>> >>>>>>>> The thing is that step 2 is not symmetrical. The RO has a >>>>>>>> legitimate privacy interest in keeping their policies private and >>>>>>>> minimizing the leakage of information about requests that are pose= d against >>>>>>>> those policies. >>>>>>>> >>>>>>>> The RS, on the other hand, should be publishing its policies (e.g. >>>>>>>> what it=E2=80=99s selling or what jurisdiction it=E2=80=99s in or = what tokens or scopes it >>>>>>>> supports). The RS has no obvious privacy interest in GNAP. It=E2= =80=99s just an >>>>>>>> enforcer. >>>>>>>> >>>>>>>> There is one other privacy interest to consider around the RS and >>>>>>>> that is the requesting party (the end-user that is not the RO :-) = might >>>>>>>> prefer to share attributes with the RS instead of the RO or someth= ing >>>>>>>> controlled by the RO. This case could be an =E2=80=9Cextension=E2= =80=9D to GNAP and might >>>>>>>> result in a split AS as a solution. This problem was introduced wh= en the >>>>>>>> editors decided to replace RQ with end-user. Obviously, the RO end= -user has >>>>>>>> no privacy interests relative to itself. >>>>>>>> >>>>>>>> Adrian >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>> >>>>>>>>> I was referring to "By my definition, this model has two ASs >>>>>>>>> since both are processing requests into tokens". If there's no re= ason to >>>>>>>>> have 2 types of ASs, that's fine then. >>>>>>>>> But I'm a bit lost in where we stand with the idea. >>>>>>>>> >>>>>>>>> Could you recap? >>>>>>>>> >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper < >>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>> >>>>>>>>>> There=E2=80=99s no obvious reason to have two types of ASs. Any = AS that >>>>>>>>>> is executing the policies of the RS can look to GNAP like the RS= itself. >>>>>>>>>> Why would GNAP expose that interface to anyone? >>>>>>>>>> >>>>>>>>>> Adrian >>>>>>>>>> >>>>>>>>>> On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault < >>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Note : I'm not sure that's a good idea, but having 2 types of >>>>>>>>>>> ASs is not that easy to grasp. >>>>>>>>>>> >>>>>>>>>>> Fabien >>>>>>>>>>> >>>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault < >>>>>>>>>>> fabien.imbault@gmail.com> a =C3=A9crit : >>>>>>>>>>> >>>>>>>>>>>> The purpose of either handling policies locally or delegating >>>>>>>>>>>> them to the RO agent. >>>>>>>>>>>> >>>>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper < >>>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>>> >>>>>>>>>>>>> What purpose would be served by GNAP splitting the AS into tw= o >>>>>>>>>>>>> components? >>>>>>>>>>>>> >>>>>>>>>>>>> Adrian >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault < >>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Isn't the AS-RO a component of the AS? Same idea as the >>>>>>>>>>>>>> interact component, it functionnally belongs to the AS role = but could be >>>>>>>>>>>>>> deployed either as a monolith or as a separate component? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>> >>>>>>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper < >>>>>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, but I would say it=E2=80=99s not the RO that wants the= access >>>>>>>>>>>>>>> token. It=E2=80=99s the RO that wants the client making the= request to get an >>>>>>>>>>>>>>> access token. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 11:22 PM Alan Karp < >>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Adrian Gropper wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In this design, the AS is the AS-RS and the agent is the >>>>>>>>>>>>>>>>> AS-RO. By my definition, this model has two ASs since bot= h are processing >>>>>>>>>>>>>>>>> requests into tokens. The problem with this is complexity= and privacy. The >>>>>>>>>>>>>>>>> RO may not want to share the request information with the= AS-RS. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> More precisely, RO has no choice but to present the >>>>>>>>>>>>>>>> required information to AS-RS if RO wants an access token.= However, RO >>>>>>>>>>>>>>>> does not want AS-RS to know the policy by which RO delegat= es tokens. >>>>>>>>>>>>>>>> That's why RO uses AS-RO for those delegations. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper < >>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thank you for creating the issue. My definition of AS is >>>>>>>>>>>>>>>>> independent of AS-RO or AS-RS. >>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues= /223#issuecomment-806280421 >>>>>>>>>>>>>>>>> I also agree with Alan's definition based on delegation. = An AS-RS would be >>>>>>>>>>>>>>>>> a delegate of the RS. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Based on that, I see it as obvious that the policy has to >>>>>>>>>>>>>>>>> be accessible (defined locally?) in order for it to be ru= n as the code that >>>>>>>>>>>>>>>>> turns a request into an access token. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The only other possibility is that the request is package= d >>>>>>>>>>>>>>>>> by the AS and sent elsewhere (an agent) for evaluation ag= ainst policy and a >>>>>>>>>>>>>>>>> proto-token returned. In that case the AS is acting as a = proxy and the PDP >>>>>>>>>>>>>>>>> is elsewhere. I can imagine that an AS-RS would behave th= is way so that the >>>>>>>>>>>>>>>>> proto-token could be turned into an access token by the A= S-RS. Isn't this >>>>>>>>>>>>>>>>> what Justin is proposing? In this design, the AS is the A= S-RS and the agent >>>>>>>>>>>>>>>>> is the AS-RO. By my definition, this model has two ASs si= nce both are >>>>>>>>>>>>>>>>> processing requests into tokens. The problem with this is= complexity and >>>>>>>>>>>>>>>>> privacy. The RO may not want to share the request informa= tion with the >>>>>>>>>>>>>>>>> AS-RS. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault < >>>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Isn't that what the AS is supposed to be, only with the >>>>>>>>>>>>>>>>>> caveat that the policy is defined locally? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp < >>>>>>>>>>>>>>>>>> alanhkarp@gmail.com> a =C3=A9crit : >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> AS-RO is an AS that RO trusts to delegate RO's access >>>>>>>>>>>>>>>>>>> tokens according to RO's policies. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault < >>>>>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hi Alan and Adrian, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I've created issue AS-RO policy delegation ( >>>>>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/iss= ues/223) >>>>>>>>>>>>>>>>>>>> to capture your input. >>>>>>>>>>>>>>>>>>>> A first question that arises: can we give a definition >>>>>>>>>>>>>>>>>>>> to AS-RO? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp < >>>>>>>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Fabien Imbault wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Yes, but in that flow, the token relationship betwee= n >>>>>>>>>>>>>>>>>>>>>> AS-RS and AS-RO is only secure if the tokens issued = by AS-RS are >>>>>>>>>>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Attenuated delegation is a requirement, but that >>>>>>>>>>>>>>>>>>>>> doesn't have to be done cryptographically. Token exc= hange works just >>>>>>>>>>>>>>>>>>>>> fine. SPKI and zcap-ld are examples of the crypto ap= proach, and we used >>>>>>>>>>>>>>>>>>>>> token exchange in the system for HP. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault < >>>>>>>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Yes, but in that flow, the token relationship betwee= n >>>>>>>>>>>>>>>>>>>>>> AS-RS and AS-RO is only secure if the tokens issued = by AS-RS are >>>>>>>>>>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp < >>>>>>>>>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Justin Richer wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> But with all that in mind, I think the key here is >>>>>>>>>>>>>>>>>>>>>>>> going to be looking at what the inputs to the AS a= re, and how those can be >>>>>>>>>>>>>>>>>>>>>>>> defined in an interoperable way for AS=E2=80=99s t= hat can accept them. I think >>>>>>>>>>>>>>>>>>>>>>>> there=E2=80=99s a lot of room for innovation and f= lexibility here that doesn=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>> break the trust model or core use cases. If I have= an AS-RS set that won=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine inputs,= then I can decide not to >>>>>>>>>>>>>>>>>>>>>>>> use that one. But this is a very different questio= n than saying the RS >>>>>>>>>>>>>>>>>>>>>>>> itself needs to accept my own AS =E2=80=94 and we = can=E2=80=99t keep conflating these two >>>>>>>>>>>>>>>>>>>>>>>> models. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I agree. The point of having an AS-RO is to allow >>>>>>>>>>>>>>>>>>>>>>> RO to specify a policy for which of RO's access tok= ens should be delegated >>>>>>>>>>>>>>>>>>>>>>> under what conditions. AS-RS should not need to un= derstand those >>>>>>>>>>>>>>>>>>>>>>> policies. The flow would be >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> - RO contacts AS-RS and gets one or more access >>>>>>>>>>>>>>>>>>>>>>> tokens. >>>>>>>>>>>>>>>>>>>>>>> - RO delegates one or more of those tokens, >>>>>>>>>>>>>>>>>>>>>>> potentially sub-scoped, to AS-RO. >>>>>>>>>>>>>>>>>>>>>>> - A different user contacts AS-RO to get a >>>>>>>>>>>>>>>>>>>>>>> potentially sub-scoped access token from AS-RO. >>>>>>>>>>>>>>>>>>>>>>> - That user presents the access token delegated >>>>>>>>>>>>>>>>>>>>>>> by AS-RO when invoking the resource. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> AS-RS only needs to verify that the delegation chai= n >>>>>>>>>>>>>>>>>>>>>>> is legitimate, e.g., no increase in scope, and that= it grants permission >>>>>>>>>>>>>>>>>>>>>>> for the request being made. AS-RS does not need to= understand the policy >>>>>>>>>>>>>>>>>>>>>>> behind granting the delegation by AS-RO. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer < >>>>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I think this shows the problem with the terminolog= y >>>>>>>>>>>>>>>>>>>>>>>> as it=E2=80=99s been applied in this conversation,= which I=E2=80=99ve tried to shine light >>>>>>>>>>>>>>>>>>>>>>>> on before. What you and others are calling the =E2= =80=9CRS=E2=80=9D is really the =E2=80=9CAS and >>>>>>>>>>>>>>>>>>>>>>>> RS working together=E2=80=9D =E2=80=94 everything = to the right of the line. When Denis had >>>>>>>>>>>>>>>>>>>>>>>> brought up =E2=80=9Celiminating the AS=E2=80=9D in= another thread, what he=E2=80=99d really done is >>>>>>>>>>>>>>>>>>>>>>>> labeled everything to the right of the line as the= =E2=80=9CRS=E2=80=9D. Of course, the >>>>>>>>>>>>>>>>>>>>>>>> irony here is that everything to the right of the = line used all be called >>>>>>>>>>>>>>>>>>>>>>>> the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver= =E2=80=9D in the OAuth 1 days. As you say below, I don=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>> want the client to have visibility on what happens= on that side. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Note well: The Google+ logo labeled =E2=80=9CIdP= =E2=80=9D in the >>>>>>>>>>>>>>>>>>>>>>>> diagram is not the AS, as far as GNAP is concerned= . It does not issue an >>>>>>>>>>>>>>>>>>>>>>>> access token that the RS will accept. The elements= to the left of the line >>>>>>>>>>>>>>>>>>>>>>>> could be a lot of things, but they are NOT the AS = =E2=80=94 by definition. The >>>>>>>>>>>>>>>>>>>>>>>> client lives over on the left, but so do any exter= nal inputs to the AS. >>>>>>>>>>>>>>>>>>>>>>>> These could be policy inputs on behalf of the RO, = they could be >>>>>>>>>>>>>>>>>>>>>>>> presentation artifacts, they could be federated lo= gins, they could be the >>>>>>>>>>>>>>>>>>>>>>>> output of policy decisions. How the AS comes to tr= ust those things is up to >>>>>>>>>>>>>>>>>>>>>>>> the AS=E2=80=99s implementation. It=E2=80=99s some= thing we can talk about, but ultimately >>>>>>>>>>>>>>>>>>>>>>>> GNAP won=E2=80=99t be in any position to dictate b= ecause in practice some AS=E2=80=99s are >>>>>>>>>>>>>>>>>>>>>>>> simply going to internalize all policies and we wi= ll never successfully >>>>>>>>>>>>>>>>>>>>>>>> force those open. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> But with all that in mind, I think the key here is >>>>>>>>>>>>>>>>>>>>>>>> going to be looking at what the inputs to the AS a= re, and how those can be >>>>>>>>>>>>>>>>>>>>>>>> defined in an interoperable way for AS=E2=80=99s t= hat can accept them. I think >>>>>>>>>>>>>>>>>>>>>>>> there=E2=80=99s a lot of room for innovation and f= lexibility here that doesn=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>> break the trust model or core use cases. If I have= an AS-RS set that won=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine inputs,= then I can decide not to >>>>>>>>>>>>>>>>>>>>>>>> use that one. But this is a very different questio= n than saying the RS >>>>>>>>>>>>>>>>>>>>>>>> itself needs to accept my own AS =E2=80=94 and we = can=E2=80=99t keep conflating these two >>>>>>>>>>>>>>>>>>>>>>>> models. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> So to me, GNAP can support a Zero Trust >>>>>>>>>>>>>>>>>>>>>>>> Architecture by LEVERAGING the AS, not by subsumin= g or eliminating it. It >>>>>>>>>>>>>>>>>>>>>>>> is in fact the AS, not the client and not the RS, = that will request and >>>>>>>>>>>>>>>>>>>>>>>> consume the results of a privacy-preserving zero-t= rust policy query thing. >>>>>>>>>>>>>>>>>>>>>>>> Anything that happens downstream from that is of l= ittle concern to the >>>>>>>>>>>>>>>>>>>>>>>> zero-trust components because, as you point out, i= t=E2=80=99s on the =E2=80=9Cother side=E2=80=9D >>>>>>>>>>>>>>>>>>>>>>>> of the line. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I think we got this basic component model pretty >>>>>>>>>>>>>>>>>>>>>>>> right in OAuth: the AS and RS and client working t= ogether. Where OAuth >>>>>>>>>>>>>>>>>>>>>>>> misses the mark is the assumption that the user ha= s to log in to the AS >>>>>>>>>>>>>>>>>>>>>>>> through a webpage and interact directly, thereby p= roving they=E2=80=99re the RO. >>>>>>>>>>>>>>>>>>>>>>>> It=E2=80=99s this latter space where I think we ca= n both push innovation and also >>>>>>>>>>>>>>>>>>>>>>>> address the important and compelling use cases lik= e the ones you=E2=80=99re >>>>>>>>>>>>>>>>>>>>>>>> bringing. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper < >>>>>>>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I'm sorry, Justin. As a Resource Owner, I look at >>>>>>>>>>>>>>>>>>>>>>>> the RS trust boundary (the dotted line in the diag= ram) as being the RS. I >>>>>>>>>>>>>>>>>>>>>>>> don't expect any visibility into what's going on o= n the right. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> My problem with the framing you propose is that >>>>>>>>>>>>>>>>>>>>>>>> requests are going to the RS (or the AS-RS) and I = don't want to share my >>>>>>>>>>>>>>>>>>>>>>>> policies with the AS-RS. I want to keep the RS and= AS-RS as ignorant as >>>>>>>>>>>>>>>>>>>>>>>> possible. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer < >>>>>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> What you=E2=80=99re discussing below, in terms of= logging >>>>>>>>>>>>>>>>>>>>>>>>> in to a site, is not approaching the RS. You are = in fact approaching the >>>>>>>>>>>>>>>>>>>>>>>>> client, and identifying both the AS and RS to the= client. The client is a >>>>>>>>>>>>>>>>>>>>>>>>> client *of your identity* in this model, and the >>>>>>>>>>>>>>>>>>>>>>>>> RS is part of the identity provider. It=E2=80=99s= really important that we don=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>>> conflate the RS and client in this way as it lead= s to a lot of confusion >>>>>>>>>>>>>>>>>>>>>>>>> downstream and a lot of broken trust boundaries. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> With that model in mind, approaching the =E2=80= =9CRS" and >>>>>>>>>>>>>>>>>>>>>>>>> providing it your identity is really just a case = of the =E2=80=9Cfederated login to >>>>>>>>>>>>>>>>>>>>>>>>> AS=E2=80=9D pattern that we discussed on the WG c= all. The user here approaches an >>>>>>>>>>>>>>>>>>>>>>>>> RS, which has its own AS. To share things from th= is RS, the RO has to >>>>>>>>>>>>>>>>>>>>>>>>> authenticate to the RS=E2=80=99s AS. This particu= lar AS allows the RO to do so >>>>>>>>>>>>>>>>>>>>>>>>> using an external identity =E2=80=94 in which cas= e, the AS is now a =E2=80=9Cclient=E2=80=9D of a >>>>>>>>>>>>>>>>>>>>>>>>> separate, disconnected (but layered) delegation. = The ultimate client that >>>>>>>>>>>>>>>>>>>>>>>>> eventually calls the RS down the way may or may n= ot know about these >>>>>>>>>>>>>>>>>>>>>>>>> layers. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> This same AS, which is closely tied to the RS and >>>>>>>>>>>>>>>>>>>>>>>>> trusted by the RS, might also take in FIDO creden= tials, or DIDs, or any >>>>>>>>>>>>>>>>>>>>>>>>> number of other proof mechanisms. The output of t= his is an access token the >>>>>>>>>>>>>>>>>>>>>>>>> RS trusts, but the input is up to the AS. The RS = is not what you=E2=80=99re logging >>>>>>>>>>>>>>>>>>>>>>>>> in to. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper < >>>>>>>>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> I too am in favor of avoiding consolidation and >>>>>>>>>>>>>>>>>>>>>>>>> correlation. Right now, when I approach a service= provider (RS) for the >>>>>>>>>>>>>>>>>>>>>>>>> first time, I'm offered the opportunity to identi= fy my persona as: email, >>>>>>>>>>>>>>>>>>>>>>>>> sign-in with Google, Facebook, or Apple. I know t= here are people who try to >>>>>>>>>>>>>>>>>>>>>>>>> create one-off email addresses but that is mostly= a waste of time. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> So, along come FIDO2 and DID wallets to the >>>>>>>>>>>>>>>>>>>>>>>>> rescue. Now, in theory, I have a way to start out= my RS relationship >>>>>>>>>>>>>>>>>>>>>>>>> pseudonymously. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> When I want my resource to be discovered or share= d >>>>>>>>>>>>>>>>>>>>>>>>> I will post that RS URL including my pseudonym. I= f I then want to introduce >>>>>>>>>>>>>>>>>>>>>>>>> a mediator in front of my AS or messaging service= endpoint, I have that >>>>>>>>>>>>>>>>>>>>>>>>> option. If I want to keep requests away from the = mediator, I would publish >>>>>>>>>>>>>>>>>>>>>>>>> an encryption key along with my pseudonym. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> - Adrian >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer < >>>>>>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk < >>>>>>>>>>>>>>>>>>>>>>>>>> kaduk@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, >>>>>>>>>>>>>>>>>>>>>>>>>> Adrian Gropper wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> >> @Alan Karp shared a >>>>>>>>>>>>>>>>>>>>>>>>>> talk about the Principle Of Least >>>>>>>>>>>>>>>>>>>>>>>>>> >> Authority (POLA) in a recent comment >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protoc= ol/issues/145#issuecomment-803099693 >>>>>>>>>>>>>>>>>>>>>>>>>> >> I recommend it. >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>> >> We might expect a protocol with authorization >>>>>>>>>>>>>>>>>>>>>>>>>> in the title to use authority >>>>>>>>>>>>>>>>>>>>>>>>>> >> as a core principle. I advocate for a GNAP >>>>>>>>>>>>>>>>>>>>>>>>>> design that maximizes the power >>>>>>>>>>>>>>>>>>>>>>>>>> >> of the RO, to be seen as a human rights issue >>>>>>>>>>>>>>>>>>>>>>>>>> when the RO is a human. This >>>>>>>>>>>>>>>>>>>>>>>>>> >> causes me to ask how to combine better >>>>>>>>>>>>>>>>>>>>>>>>>> security with better human rights in >>>>>>>>>>>>>>>>>>>>>>>>>> >> GNAP. >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>> >> Who should have the least authority in the >>>>>>>>>>>>>>>>>>>>>>>>>> GNAP design? >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>> >> The AS derives authority as a delegate of the >>>>>>>>>>>>>>>>>>>>>>>>>> RO. If we ask the RO to >>>>>>>>>>>>>>>>>>>>>>>>>> >> partition limited authority across dozens of >>>>>>>>>>>>>>>>>>>>>>>>>> different ASs by domain and >>>>>>>>>>>>>>>>>>>>>>>>>> >> function, then we are not using technology to >>>>>>>>>>>>>>>>>>>>>>>>>> empower the individual. >>>>>>>>>>>>>>>>>>>>>>>>>> >> Probably the opposite, as we introduce consen= t >>>>>>>>>>>>>>>>>>>>>>>>>> fatigue and burden normal >>>>>>>>>>>>>>>>>>>>>>>>>> >> people to partition their lives into >>>>>>>>>>>>>>>>>>>>>>>>>> non-overlapping domains. >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>> >> My experience says we should aim for one AS >>>>>>>>>>>>>>>>>>>>>>>>>> per persona because that maps >>>>>>>>>>>>>>>>>>>>>>>>>> >> into the way we manage our public and private >>>>>>>>>>>>>>>>>>>>>>>>>> identities. POLA would then >>>>>>>>>>>>>>>>>>>>>>>>>> >> teach care in keeping ASs and RSs related to >>>>>>>>>>>>>>>>>>>>>>>>>> work / public separate from >>>>>>>>>>>>>>>>>>>>>>>>>> >> ASs and RSs related to private life so that a >>>>>>>>>>>>>>>>>>>>>>>>>> policy vulnerability in our >>>>>>>>>>>>>>>>>>>>>>>>>> >> delegation to an AS would have the least >>>>>>>>>>>>>>>>>>>>>>>>>> likelihood of harm. >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > Thinking about how least authority/least >>>>>>>>>>>>>>>>>>>>>>>>>> privilege would apply to GNAP >>>>>>>>>>>>>>>>>>>>>>>>>> > seems like a useful exercise. I do want to >>>>>>>>>>>>>>>>>>>>>>>>>> point out some potential >>>>>>>>>>>>>>>>>>>>>>>>>> > pitfalls with one-AS-per-persona that we can >>>>>>>>>>>>>>>>>>>>>>>>>> also be aware of. If >>>>>>>>>>>>>>>>>>>>>>>>>> > one-AS-per-persona becomes one-persona-per-AS >>>>>>>>>>>>>>>>>>>>>>>>>> as well, then the AS's >>>>>>>>>>>>>>>>>>>>>>>>>> > identity in effect also serves as a persona >>>>>>>>>>>>>>>>>>>>>>>>>> identity and there are privacy >>>>>>>>>>>>>>>>>>>>>>>>>> > considerations to that. If, on the other hand= , >>>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>> > multiple-personas-per-AS (presumably >>>>>>>>>>>>>>>>>>>>>>>>>> corresponding to multiple humans) >>>>>>>>>>>>>>>>>>>>>>>>>> > route is taken, we should consider whether tha= t >>>>>>>>>>>>>>>>>>>>>>>>>> would lead to various >>>>>>>>>>>>>>>>>>>>>>>>>> > (e.g., market) forces driving consolidation to >>>>>>>>>>>>>>>>>>>>>>>>>> just a handful of >>>>>>>>>>>>>>>>>>>>>>>>>> > super-popular AS services. That topic is a >>>>>>>>>>>>>>>>>>>>>>>>>> current matter of concern to >>>>>>>>>>>>>>>>>>>>>>>>>> > some IETF participants. >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Hi Ben, big +1 to this. This is something that w= e >>>>>>>>>>>>>>>>>>>>>>>>>> discussed ages ago in the UMA working group, and= it=E2=80=99s one of the biggest >>>>>>>>>>>>>>>>>>>>>>>>>> problems with the personal AS (and personal data= store) model. This kind of >>>>>>>>>>>>>>>>>>>>>>>>>> thing makes RS-first trust models really difficu= lt in practice. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> As a strawman, let=E2=80=99s say that I=E2=80=99= ve got software >>>>>>>>>>>>>>>>>>>>>>>>>> that wants to access my medical information. It = calls an RS and requests >>>>>>>>>>>>>>>>>>>>>>>>>> access, but it hasn=E2=80=99t been granted anyth= ing yet. Now I as the RO have set >>>>>>>>>>>>>>>>>>>>>>>>>> up the RS so that it talks to my personal AS, th= at only I use. In addition >>>>>>>>>>>>>>>>>>>>>>>>>> to the RS having to be able to figure out which = medical records are being >>>>>>>>>>>>>>>>>>>>>>>>>> requested from the context of the unauthenticate= d request (which means it >>>>>>>>>>>>>>>>>>>>>>>>>> needs identifiers in the URL or something simila= r for the RS to be able to >>>>>>>>>>>>>>>>>>>>>>>>>> tell, assuming that it protects data for more th= an one person). So this >>>>>>>>>>>>>>>>>>>>>>>>>> client software doesn=E2=80=99t know who I am an= d doesn=E2=80=99t know my medical record >>>>>>>>>>>>>>>>>>>>>>>>>> information, makes a completely unauthorized req= uest to the RS, and the RS >>>>>>>>>>>>>>>>>>>>>>>>>> says =E2=80=9CGo to Justin=E2=80=99s personal AS= to get a token=E2=80=9D. The client can now make a >>>>>>>>>>>>>>>>>>>>>>>>>> direct correlation between the data that=E2=80= =99s being protected at the RS and >>>>>>>>>>>>>>>>>>>>>>>>>> the person running the AS that protects it. Impo= rtantly, this client makes >>>>>>>>>>>>>>>>>>>>>>>>>> this call with no prior relationship to the RS a= nd no really auditable way >>>>>>>>>>>>>>>>>>>>>>>>>> to track it down after the fact. This is a desig= n feature in the good case, >>>>>>>>>>>>>>>>>>>>>>>>>> and terrifying in the bad case. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> If the RS instead says =E2=80=9Cwelcome to Medic= ine >>>>>>>>>>>>>>>>>>>>>>>>>> Doctor RS, please talk to the Medicine Doctor AS= to get access=E2=80=9D, we haven=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>>>> exposed anything at all. And from the perspectiv= e of both the patient and >>>>>>>>>>>>>>>>>>>>>>>>>> the RS, this is more privacy-preserving, and it= =E2=80=99s really the least >>>>>>>>>>>>>>>>>>>>>>>>>> surprising option. Once the client gets to the A= S, it can start a >>>>>>>>>>>>>>>>>>>>>>>>>> negotiation of figuring out who the RO is for th= e information being >>>>>>>>>>>>>>>>>>>>>>>>>> accessed. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On top of this, the usability expectations of >>>>>>>>>>>>>>>>>>>>>>>>>> people managing their own AS, or set of AS=E2=80= =99s for multiple personas to keep >>>>>>>>>>>>>>>>>>>>>>>>>> things separate, is a huge burden. Even in the t= ech community, I know >>>>>>>>>>>>>>>>>>>>>>>>>> people who can=E2=80=99t reliably manage more th= an one email address for different >>>>>>>>>>>>>>>>>>>>>>>>>> purposes. I wouldn=E2=80=99t expect my partner t= o do that =E2=80=94 they have trouble >>>>>>>>>>>>>>>>>>>>>>>>>> enough balancing all the logins and sessions req= uired for different kids >>>>>>>>>>>>>>>>>>>>>>>>>> remote schooling, I couldn=E2=80=99t imagine the= m having to understand all the >>>>>>>>>>>>>>>>>>>>>>>>>> requirements for managing multiple authorization= servers and associated >>>>>>>>>>>>>>>>>>>>>>>>>> policies. I also don=E2=80=99t expect any person= to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve been on >>>>>>>>>>>>>>>>>>>>>>>>>> the internet for decades and I can barely keep t= abs on my GPG keys, and >>>>>>>>>>>>>>>>>>>>>>>>>> only use them when I am forced to. This is exact= ly the kind of =E2=80=9Cmarket >>>>>>>>>>>>>>>>>>>>>>>>>> pressure=E2=80=9D that I think Ben mentions abov= e, people will just want to >>>>>>>>>>>>>>>>>>>>>>>>>> outsource that to someone else, and the reality = will be a few popular >>>>>>>>>>>>>>>>>>>>>>>>>> providers. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> In which case, we could end up doing a ton of >>>>>>>>>>>>>>>>>>>>>>>>>> work to allow an RS choice only to end up with a= world where the RS ends up >>>>>>>>>>>>>>>>>>>>>>>>>> making a limited choice anyway. We see how that = plays out with OpenID >>>>>>>>>>>>>>>>>>>>>>>>>> Connect =E2=80=94 RP=E2=80=99s could allow arbit= rary IdPs but they choose Google because it >>>>>>>>>>>>>>>>>>>>>>>>>> works and that=E2=80=99s where the users are. (A= nd that=E2=80=99s not to say anything of >>>>>>>>>>>>>>>>>>>>>>>>>> the proprietary OIDC-like protocols, but that=E2= =80=99s another discussion). >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> For further reading on these topics, I recommend >>>>>>>>>>>>>>>>>>>>>>>>>> both =E2=80=9CWhy Johnny Can=E2=80=99t Encrypt= =E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> So what does this have to do with GNAP? I think >>>>>>>>>>>>>>>>>>>>>>>>>> we can be clear-eyed on what kinds of expectatio= ns we have for the >>>>>>>>>>>>>>>>>>>>>>>>>> participants. If we expect users (RO=E2=80=99s) = to have to set up the AS-RS >>>>>>>>>>>>>>>>>>>>>>>>>> relationship, or expect them to carry their AS, = or manage their personal >>>>>>>>>>>>>>>>>>>>>>>>>> keys =E2=80=94 I think we=E2=80=99ve lost the ba= ttle for relevance. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>> >>> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > --0000000000001c53bd05be6fb548 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    @Justin, there=E2=80=99s no separation of concerns here. = No partition between processor and controller. No data minimization. And, I= see no obvious reason to make this the core of GNAP.=C2=A0

    The one thing we can probably all agr= ee on is that there=E2=80=99s only one RS and one RO.=C2=A0

    The core of GNAP, in my=C2=A0opinion,= can be built and explained around this simple design. The RS is a processo= r. The RO is a controller. The RS bears only security responsibility. The R= S bears no privacy responsibility. The RO delegates this to the RS but this= is not authorization as the A in GNAP.

    The RO retains all rights to delegate within the scope of t= hings that the RS is willing to support using various token formats and end= point options. Some of these options may do all sorts of things for all sor= ts of clients and user-agents =C2=A0but these are options.=C2=A0

    For example, if a request comes to= the RS that is not in the form of an access token, then it either gets sen= t to the RO or their agent, or it gets logged and dumped. One such option, = common in healthcare, is =E2=80=9CBreak the Glass=E2=80=9D where the RS is = acting as an authorization server because the user-agent is making a reques= t instead of presenting an access token. GNAP can offer this as an option b= ut it is not our core.

    A= drian


    On Fri, M= ar 26, 2021 at 7:15 AM Justin Richer <jricher@mit.edu> wrote:
    I have a= big problem with this line:

    >=C2=A0the RS and AS-RS only see access tokens. = The requests (from RO') that resulted in an access token are none of th= eir business.

    In the trust model we=E2=80=99ve b= een discussing, the requests that result in access tokens are solely the= business of AS-RS, since AS-RS is the only entity that=E2=80=99s allow= ed, and trusted by the RS, to create access tokens for the RS. That is its = entire job, the entire reason it exists in the system. By definition the pa= rty generating tokens for use at the RS is the AS for that RS, I don=E2=80= =99t care how you deploy it. If RO wants to give access to someone else (wh= o isn=E2=80=99t an =E2=80=9CRO" anymore, they=E2=80=99re another end-u= ser), then that end user=E2=80=99s client software will need to talk to AS-= RS to get its own access token.

    Now here=E2=80=99s the t= rick: when the end user=E2=80=99s client instance talks to AS-RS, that does= NOT mean that AS-RS needs to know all the details and policy reasons that = it should give an access token to that client instance. It doesn=E2=80=99t = even need to know the existence of another end user. It doesn=E2=80=99t nee= d identity, it doesn=E2=80=99t need policy. Sure, it COULD handle all of th= at internally, and many will, but the protocol doesn=E2=80=99t demand it.= =C2=A0

    This means that the first client instance, = the one that gets the access token, can also be given something alongside t= he access token that it can then hand to another piece of software (or to a= person to hand eo their piece of software). This artifact is not an access= token. This artifact could be something structured that the client underst= ands, and can make derivatives of, and present back to the AS-RS for gettin= g new access tokens. There could be multiple different flavors of this kind= of artifact for different kinds of environments and groups. But what they = all have in common is that they can potentially be used to request more acc= ess tokens within some context at the AS-RS.

    =C2=A0=E2= =80=94 Justin



    On Mar 25, 2021, at 5:50 PM, Adrian Gropper <agropper@healthurl.com&= gt; wrote:

    My issue is= with Alan's:
    "7. Another user agent (RO') can contact an= y holder of the access token or the service's policy agent (AS-RS) to g= et a delegated access token."

    I would prefe= r "7A.=C2=A0Another user agent = (RO') can contact any holder of the access token." by default so t= hat the AS-RS does not see the requests. In other words, the RS and AS-RS o= nly see access tokens. The requests (from RO') that resulted in an acce= ss token are none of their business.

    The reality is that RO' can discover a resource RS an= d can share whatever information with RS-AS they want and the RO may not ev= en know about it unless the RS decides to let them know somehow. This seems= to be a drawback of the capabilities approach.=C2=A0

    In terms of privacy and control, I, as t= he RO, want a contract=C2=A0with the RS that says that I or my agent (AS-RO= ) must sign an access token. This is a fundamental audit requirement. Witho= ut it, a rogue RS and AS-RS can do all sorts of things and the RO would nev= er know. I understand that a rogue RS might not support an honest contempor= aneous log of access tokens presented so there's a trust issue here tha= t I seems unavoidable unless I specify in my RO-RS contract that they use a= separate contemporaneous=C2=A0log such as AS-RO for every access token pre= sented and risk being sued if they process an access token without also upd= ating the separate log.

    <= span>- Adrian


    On Thu, Mar 25, 2021= at 1:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin Ri= cher <jricher@mit.e= du> wrote:
    Hi Alan,

    In all of my discussion, and in the spec itself, the RO is the :entity: i= n charge of approving rights. They=E2=80=99re probably a person. It might b= e software that makes a policy decision in some way, or a corporate entity,= or something like that. But it=E2=80=99s not assumed to be a computational= agent in the terms of the protocol itself. Would that recast what you=E2= =80=99re saying below?

    Hmmm.=C2=A0 I guess not.=C2=A0 It's just that the person would= be using some UI to express their decisions to what I called the user agen= t.=C2=A0 That model fits in very nicely with what we did with Polaris, our = virus safe computing environment for Windows XP, https://dl.acm.org/doi/1= 0.1145/1151030.1151033.=C2=A0 The person would click on the icon for a = Word file, and an instance of Word would open with only the permission need= ed to edit that one file.=C2=A0 Same thing here.=C2=A0 The client could ask= for permission to use the resource, or permission could be granted implici= tly when the user selects a resource associated with a specific client.

    --------------
    Alan Karp

    On Thu, M= ar 25, 2021 at 9:53 AM Justin Richer <jricher@mit.edu> wrote:
    Hi Alan,

    In all of my discussion, and in the spec = itself, the RO is the :entity: in charge of approving rights. They=E2=80=99= re probably a person. It might be software that makes a policy decision in = some way, or a corporate entity, or something like that. But it=E2=80=99s n= ot assumed to be a computational agent in the terms of the protocol itself.= Would that recast what you=E2=80=99re saying below?

    =C2=A0=E2=80=94 Justin

    On Mar= 25, 2021, at 12:36 PM, Alan Karp <alanhkarp@gmail.com> wrote:

    There seems to be some confusion about how AS-RO comes into the = picture, probably because of the "AS" part.=C2=A0 I'm going t= o try to clear up that confusion by more carefully explaining what I mean.<= div>
    I'm assuming that RO is a computational agent representing= the person who is the resource owner, something called the "user agen= t" in operating systems lingo.=C2=A0 I'm also assuming that it'= ;s possible to do delegation, either locally or by token exchange with AS-R= S.=C2=A0 All delegations are potentially sub-scoped, but you may also want = to delegate with full scope to have a separately revocable access token.

    =C2=A0 Here's an example of how things work in a= capability oriented system.
    1. Someone, the service own= er, creates a service.
    2. The service owner contracts with an policy a= gent (AS-RS) to create and manage access tokens for that service (RS).
      3. =
    3. A person wishing to create a resource at RS uses their user agent (RO) = to contact the service owner's policy agent (AS-RS) and gets back an ac= cess token for that resource.
    4. That user agent (RO) can=C2=A0
    5. use that access token to invoke the resource, or
    6. delegate an = access token to a client of the user agent's (RO) choice, or
    7. co= ntract with a policy agent (AS-RO) to manage those delegations on behalf of= the user agent (RO), or
    8. specify a policy with the service's po= licy agent (AS-RS).
  • A client can contact any holder of the acc= ess token (the user agent (RO) or its policy agent (AS-RO)) or the service&= #39;s policy agent (AS-RS) to get a delegated access token.
  • That cl= ient can delegate that token to another client.
  • Another user agent = (RO') can contact any holder of the access token or the service's p= olicy agent (AS-RS) to get a delegated access token.
  • The other user= agent (RO') can=C2=A0
    1. use that access token to invoke the = resource, or
    2. delegate it to a client of its choice, or
    3. cont= ract with a policy agent (AS-RO') of its choosing to manage those dele= gations on its behalf, or
    4. specify a policy with the service's p= olicy agent (AS-RS).
  • and so on
    • W= hen any of these computational agents, user agents (ROs) or clients acting = on their behalf, invokes the resource, AS-RS verifies that the access token= is a valid delegation, i.e., proper sub-scoping, hasn't been revoked, = and that it authorizes the request being made before telling the service (R= S) to honor the request.=C2=A0 At no point does the service's policy ag= ent (AS-RS) know which computational agent did any particular delegation.= =C2=A0 (Token exchange can be done as anonymously as possible.)=C2=A0 In pa= rticular, the policy agents (AS-RO) need not be the same, or even compatibl= e with, the service's policy agent (AS-RS).=C2=A0 GNAP specifies the pr= otocol between requesters, invokers, delegators (for token exchange) of tok= ens and AS-RS.=C2=A0 That protocol need not be used between user agents (RO= ), clients, or other policy agents (AS-RO), but it is likely to be.

    =C2=A0-------------
    Alan Karp


    On Thu, Mar 25, 2021 at 5:45 AM Justin Richer <= ;jricher@mit.edu&g= t; wrote:
    The way I=E2=80=99m thinking about= Adrian=E2=80=99s use case is that what we=E2=80=99re calling the =E2=80=9C= AS-RO=E2=80=9D isn=E2=80=99t an =E2=80=9CAS=E2=80=9D in the traditional OAu= th/GNAP sense, at least not exactly. This is the agent that the RO can use = to set policies and manage consent on their behalf, and I=E2=80=99ve been a= rguing that it fits better into this vaguely-defined =E2=80=9Cinteraction c= omponent=E2=80=9D aspect of the current AS definition, and it=E2=80=99s not= currently separated from the AS definition. The =E2=80=9CAS-RS=E2=80=9D ma= ps to what we=E2=80=99d call the =E2=80=9CAS=E2=80=9D in OAuth/GNAP traditi= onally, it=E2=80=99s what the RS trusts to issue tokens. In traditional OAu= th the AS-RO and AS-RS are always the same thing, from a functional protoco= l perspective. An important point here is that from a client=E2=80=99s pers= pective, they=E2=80=99re only talking to the AS-RS since that=E2=80=99s whe= re the client gets its tokens, because at the end of the day the client jus= t wants to call the API at the RS and doesn=E2=80=99t care how that happens= (from a protocol standpoint).=C2=A0

    Note well: Even tho= ught I don=E2=80=99t believe that =E2=80=9CAS-RO=E2=80=9D is an authorizati= on server at all, I=E2=80=99m going to keep using that term below for consi= stency with previous discussion.

    So we have these = fundamental relationships around getting the client to access the RS:
    =

    1. RS trusts=C2=A0AS-RS=C2=A0to issue tokens that RS wi= ll accept, validate, and process for requests from client
    2. Clie= nt trusts=C2=A0AS-RS=C2=A0to issue tokens that client can use at RS
    3. RO trusts RS to protect RO=E2=80=99s api through delegated access

    On top of that, we=E2=80=99ve got some additional asp= ects that we=E2=80=99re discussing:

    4. RO trusts= =C2=A0AS-RO=C2=A0to manage RO=E2=80=99s policies at runtime
    5.=C2= =A0AS-RS=C2=A0trusts=C2=A0AS-RO=C2=A0to assert RO=E2=80=99s policies for ac= cess to RS
    6. Client trusts whatever=C2=A0AS-RS=C2=A0sends client= to deal with, including possibly RO-AS at runtime, because of (2)

    What I have been saying is that 4/5/6 are optional details= of how RS-AS runs things, and I think this also maps with Adrian=E2=80=99s= view of choice, since if my RS=E2=80=99s AS-RS doesn=E2=80=99t allow me to= plug in my own AS-RO then I would be motivated to pick a different RS who= =E2=80=99s AS-RS lets me do just that. The same way I=E2=80=99d pick a diff= erent RS if their surrounding services didn=E2=80=99t accept my preferred f= ederation login and I didn=E2=80=99t want to make another account. Of cours= e, market forces being as they are, I might not have much of an actionable = choice in RS, but GNAP can=E2=80=99t change that.=C2=A0

    What we can do is make it possible for AS-RS to talk to AS-RO, both i= n philosophy of the protocol design and in concrete hooks to support (6) ab= ove.=C2=A0

    Separately, we can approach the issue o= f making 1/2 above more dynamic. This was UMA2=E2=80=99s =E2=80=9Cfederated= authorization=E2=80=9D approach, and is behind a lot of the =E2=80=9Cbring= your own AS=E2=80=9D models out there. The problem with these is that we k= now from many years of experience that most RS=E2=80=99s aren=E2=80=99t int= erested in doing anything of the sort.

    So with GNA= P we can instead allow 4/5/6 to vary in a predictable and consistent way, l= etting the RS keep control over 1/2, thereby enabling choice in (3). We don= =E2=80=99t have to be the ones who define the all of the details of every p= ermutation of (5) to enable this, though. Some of this is going to be confi= guration out of band, some of it=E2=80=99s going to be communication at run= time. This is where VC=E2=80=99s, ZCAPs, CHAPI, DIDComm, FIDO, and a whole = swath of other tech can come in and help out. I don=E2=80=99t think we need= to put all the details for using these into core, nor do I think we=E2=80= =99ll pull of The Great And Ultimate Abstraction for using these and other = approaches. But we can at least start talking about =E2=80=9CAS-RS=E2=80=9D= in such a way that it no longer assumes it=E2=80=99s always the same party= dealing with the RO directly.

    =C2=A0=E2=80=94 Justi= n

    On Mar 25, 2021, at 6:40 AM, F= abien Imbault <fabien.imbault@gmail.com> wrote:

    To reframe it closer to GNAP:
    - AS =3D AS-RO, that's where you fin= d the RO policies. The AS issues access tokens to the client.
    - t= he RO policies could be a) defined locally or b) in relationship with the R= S

    There have been several ideas related to the AS-= RS relationship b:
    b1) the RS issues capabilities (which can = be further attenuated by the RO)
    b2) Adrian also discussed a DID = based solution
    b3) there was also an alternative ACL proposal fro= m Denis (+ preflight)

    Fabien

    <= /div>
    O= n Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault <fabien.imbault@gmail.com> wrote= :
    Ok so I get you correctly:=C2= =A0
    - what matters is the RQ (could be a RO or a end-user or both : we = don't really care at a high-level, they're all treated as entities = that make a request)
    - the policy is able to handle those differe= nt cases, based on its own internal delegation protocol
    - current= ly that requires AS-RS and AS-RO, but maybe it can be simplified
    =
    To answer to Denis, here's what I understood:
    = - RO trusts AS-RS (and then handles its own policies within AS-RO)
    - end-user trusts AS-RO (through its client)

    Could probably work but that's a fairly different model compared to OA= uth2 (and of today's GNAP), with different frontiers between the AS and= the RS.=C2=A0

    Please do not hesitate to correct m= e if I'm wrong.

    Fabien=C2=A0

    On Thu, Mar = 25, 2021 at 9:26 AM Adrian Gropper <agropper@healthurl.com> wrote:
    I believe there are alternatives to having t= wo kinds of ASs. The problem may be a side-effect of deciding to switch awa= y form treating the RO as different from the RQ. That leads to downstream p= rivacy issues. Our desire for architectural simplicity is admirable but tha= t may have been a step too far.

    There may also be solutions based on different types of tokens, a= s in different capabilities (tokens signed by the RS) vs. tokens signed by = the AS. I=E2=80=99m not sure about that but Alan might have more to say.

    Adrian

    On Thu, Mar 25,= 2021 at 4:15 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks. The general problem statement is cle= ar.

    The=C2=A0proposed solution a bit less (to me). I und= erstood that from point 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obvious reason to have two type= s of ASs".=C2=A0Do you see an alternative ?

    Regarding the last item, I don't think that naming RQ by en= d-user created the problem. It might just highlight the asymmetry,=C2=A0whi= ch fundamentally exists.=C2=A0

    Fabien


    <= div class=3D"gmail_quote">
    On Thu, Mar= 25, 2021 at 8:48 AM Adrian Gropper <agropper@healthurl.com> wrote:
    Recap:
    1 - Justin (I= think) introduced the idea of an AS on the RS trust boundary side.
    2 - I said the RO should not have to share policies with th= e RS.
    3 - Alan invented the concept of AS-RO and AS-= RS to separate two kinds of PDPs.=C2=A0

    The thing is that step 2 is not symmetrical. The RO has a l= egitimate privacy interest in keeping their policies private and minimizing= the leakage of information about requests that are posed against those pol= icies.=C2=A0

    The RS, on = the other hand, should be publishing its policies (e.g. what it=E2=80=99s s= elling or what jurisdiction it=E2=80=99s in or what tokens or scopes it sup= ports). The RS has no obvious privacy interest in GNAP. It=E2=80=99s just a= n enforcer.

    There is one= other privacy interest to consider around the RS and that is the requestin= g party (the end-user that is not the RO :-) might prefer to share attribut= es with the RS instead of the RO or something controlled by the RO. This ca= se could be an =E2=80=9Cextension=E2=80=9D to GNAP and might result in a sp= lit AS as a solution. This problem was introduced when the editors decided = to replace RQ with end-user. Obviously, the RO end-user has no privacy inte= rests relative to itself.

    Adrian




    On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault <fabien.imbault@= gmail.com> wrote:
    I was referring to "By my defi= nition, this model has two ASs since both are processing requests into toke= ns". If there's no reason to have 2 types of ASs, that's fine = then.=C2=A0
    But I&#= 39;m a bit lost in where we stand with the idea.=C2=A0

    Could you recap?=C2=A0

    Fabien=C2=A0

    Le jeu.= 25 mars 2021 =C3=A0 08:16, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit= =C2=A0:
    There=E2=80=99s no obvi= ous reason to have two types of ASs. Any AS that is executing the policies = of the RS can look to GNAP like the RS itself. Why would GNAP expose that i= nterface to anyone?=C2=A0

    Adrian

    On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault <fabie= n.imbault@gmail.com> wrote:
    Note : I'm not sure that's a good idea, but having 2 types of A= Ss is not that easy to grasp.

    =
    Fabien=C2=A0

    Le jeu. 25 mars 2021 =C3=A0 08:07= , Fabien Imbault <fabien.imbault@gmail.com> a =C3=A9crit=C2= =A0:
    The purpose of either hand= ling policies locally or delegating them to the RO agent.=C2=A0

    Le jeu. 25 m= ars 2021 =C3=A0 08:04, Adrian Gropper <agropper@healthurl= .com> a =C3=A9crit=C2=A0:
    What purpose would be served by GNAP splitting the AS into two components= ?

    Adrian=C2=A0

    On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    <= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa= dding-left:1ex">
    Isn't the AS-RO a component of the AS= ? Same idea as the interact component, it functionnally belongs to the AS r= ole but could be deployed either as a monolith or as a separate component?<= /div>

    Fabien=

    Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    Yes, but I would say it=E2=80=99s not the R= O that wants the access token. It=E2=80=99s the RO that wants the client ma= king the request to get an access token.=C2=A0

    <= /div>
    Adrian

    On Wed, Mar 24, 2021 at 11:22 PM Alan Kar= p <alanhkarp@gmail.com> wrote:<= br>
    Adrian Gropper <agropper@healthurl.com> wrote:

    In this design, the AS is the AS-= RS and the agent is the AS-RO. By my definition, this model has two ASs sin= ce both are processing requests into tokens. The problem with this is compl= exity and privacy. The RO may not want to share the request information wit= h the AS-RS.

    <= /div>
    More precisely, RO has no choice but to present the required info= rmation to AS-RS if RO wants an access token.=C2=A0 However, RO does not wa= nt AS-RS to know the policy by which RO delegates tokens.=C2=A0 That's = why RO uses AS-RO for those delegations.

    --------= ------
    Alan Karp


    On Wed, Mar 24, 2= 021 at 7:41 PM Adrian Gropper <agro= pper@healthurl.com> wrote:
    Thank you for creating the issue. My definition of AS is= independent of AS-RO or AS-RS.=C2=A0https://github.com/ie= tf-wg-gnap/gnap-core-protocol/issues/223#issuecomment-806280421 I also = agree with Alan's definition based on delegation. An AS-RS would be a d= elegate of the RS.=C2=A0

    Based on that= , I see it as obvious=C2=A0that the policy has to be accessible (defined lo= cally?) in order for it to be run as the code that turns a request into an = access token.=C2=A0

    The only other possibility is = that the request is packaged by the AS and sent elsewhere (an agent) for ev= aluation against policy and a proto-token returned. In that case the AS is = acting as a proxy and the PDP is elsewhere. I can imagine that an AS-RS wou= ld behave this way so that the proto-token could be turned into an access t= oken by the AS-RS. Isn't this what Justin is proposing? In this design,= the AS is the AS-RS and the agent is the AS-RO. By my definition, this mod= el has two ASs since both are processing requests into tokens. The problem = with this is complexity and privacy. The RO may not want to share the reque= st information with the AS-RS.

    Adrian
    <= br>
    On Wed,= Mar 24, 2021 at 5:21 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    =
    Isn't that what the AS is supposed to be, only w= ith the caveat that the policy is defined locally?=C2=A0
    <= br>
    Fabien=C2=A0


    Le mer. 24 mars 2021 =C3=A0 20:1= 7, Alan Karp <alanhkarp@gmail.com&= gt; a =C3=A9crit=C2=A0:
    AS-RO is an AS that RO trusts to delegate RO's access tokens a= ccording to RO's policies.=C2=A0=C2=A0

    --------------
    Alan Karp


    On Wed, Mar 24, 202= 1 at 9:36 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    =
    Hi Alan and Adrian,

    I've created is= sue AS-RO policy delegation (https://github.com/ietf-wg-gnap/gnap-core= -protocol/issues/223) to capture your input.=C2=A0
    A first qu= estion that arises: can we give a definition to AS-RO?

    =
    Thanks
    Fabien

    On Tue, Mar 23, 2021 at 4:15 PM Alan Karp= <alanhkarp@gmail.com&g= t; wrote:
    Fabien I= mbault <fabien.imbault= @gmail.com> wrote:
    Hi Al= an,=C2=A0

    Yes, but in that flow, the token relationship = between AS-RS and AS-RO is only secure if the tokens issued by AS-RS are cr= yptographically attenuable in the first place.=C2=A0
    =C2=A0
    Attenuated delegation is a require= ment, but that doesn't have to be done cryptographically.=C2=A0 Token e= xchange works just fine.=C2=A0 SPKI and zcap-ld are examples of the crypto = approach, and we used token exchange in the system for HP.

    --------------
    Alan Karp


    On Tue, Mar 23, 20= 21 at 4:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    =
    Hi Alan,=C2=A0

    Yes, but in that flow, t= he token relationship between AS-RS and AS-RO is only secure if the tokens = issued by AS-RS are cryptographically attenuable in the first place.=C2=A0<= /div>

    Fabien

    <= div dir=3D"ltr" class=3D"gmail_attr">On Mon, Mar 22, 2021 at 9:26 PM Alan K= arp <alanhkarp@gmail.com> wrote:

    But with all that in mind, I think the key here = is going to be looking at what the inputs to the AS are, and how those can = be defined in an interoperable way for AS=E2=80=99s that can accept them. I= think there=E2=80=99s a lot of room for innovation and flexibility here th= at doesn=E2=80=99t break the trust model or core use cases. If I have an AS= -RS set that won=E2=80=99t accept my favorite flavor of policy engine input= s, then I can decide not to use that one. But this is a very different ques= tion than saying the RS itself needs to accept my own AS =E2=80=94 and we c= an=E2=80=99t keep conflating these two models.

    I agree.=C2=A0 The point of having an AS-RO is to allow RO = to specify a policy for which of RO's access tokens should be delegated= under what conditions.=C2=A0 AS-RS should not need to understand those pol= icies.=C2=A0 The flow would be
    • RO contacts AS-RS and gets= one or more access tokens.
    • RO delegates one or more of those token= s, potentially sub-scoped, to AS-RO.
    • A different user contacts AS-R= O to get a potentially sub-scoped access token from AS-RO.
    • That use= r presents the access token delegated by AS-RO when invoking the resource.<= /li>
    AS-RS only needs to verify that the delegation cha= in is legitimate, e.g., no increase in scope, and that it grants permission= for the request being made.=C2=A0 AS-RS does not need to understand the po= licy behind granting the delegation by AS-RO.

    ---= -----------
    Alan Karp


    On Mon, Mar 22, 2021 at 11:40 AM Ju= stin Richer <jricher@mit.edu> wrote:
    Adrian,

    I th= ink this shows the problem with the terminology as it=E2=80=99s been applie= d in this conversation, which I=E2=80=99ve tried to shine light on before. = What you and others are calling the =E2=80=9CRS=E2=80=9D is really the =E2= =80=9CAS and RS working together=E2=80=9D =E2=80=94 everything to the right= of the line. When Denis had brought up =E2=80=9Celiminating the AS=E2=80= =9D in another thread, what he=E2=80=99d really done is labeled everything = to the right of the line as the =E2=80=9CRS=E2=80=9D. Of course, the irony = here is that everything to the right of the line used all be called the =E2= =80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. A= s you say below, I don=E2=80=99t want the client to have visibility on what= happens on that side.=C2=A0

    Note well: The Google= + logo labeled =E2=80=9CIdP=E2=80=9D in the diagram is not the AS, as far a= s GNAP is concerned. It does not issue an access token that the RS will acc= ept. The elements to the left of the line could be a lot of things, but the= y are NOT the AS =E2=80=94 by definition. The client lives over on the left= , but so do any external inputs to the AS. These could be policy inputs on = behalf of the RO, they could be presentation artifacts, they could be feder= ated logins, they could be the output of policy decisions. How the AS comes= to trust those things is up to the AS=E2=80=99s implementation. It=E2=80= =99s something we can talk about, but ultimately GNAP won=E2=80=99t be in a= ny position to dictate because in practice some AS=E2=80=99s are simply goi= ng to internalize all policies and we will never successfully force those o= pen.=C2=A0

    But with all that in mind, I think the = key here is going to be looking at what the inputs to the AS are, and how t= hose can be defined in an interoperable way for AS=E2=80=99s that can accep= t them. I think there=E2=80=99s a lot of room for innovation and flexibilit= y here that doesn=E2=80=99t break the trust model or core use cases. If I h= ave an AS-RS set that won=E2=80=99t accept my favorite flavor of policy eng= ine inputs, then I can decide not to use that one. But this is a very diffe= rent question than saying the RS itself needs to accept my own AS =E2=80=94= and we can=E2=80=99t keep conflating these two models.

    So to me, GNAP can support a Zero Trust Architecture by LEVERAGING th= e AS, not by subsuming or eliminating it. It is in fact the AS, not the cli= ent and not the RS, that will request and consume the results of a privacy-= preserving zero-trust policy query thing. Anything that happens downstream = from that is of little concern to the zero-trust components because, as you= point out, it=E2=80=99s on the =E2=80=9Cother side=E2=80=9D of the line.= =C2=A0

    I think we got this basic component model p= retty right in OAuth: the AS and RS and client working together. Where OAut= h misses the mark is the assumption that the user has to log in to the AS t= hrough a webpage and interact directly, thereby proving they=E2=80=99re the= RO. It=E2=80=99s this latter space where I think we can both push innovati= on and also address the important and compelling use cases like the ones yo= u=E2=80=99re bringing.

    =C2=A0=E2=80=94 Justin
    <= div>

    I'm sorry, Justin= . As a Resource Owner, I look at the RS trust boundary (the dotted line in = the diagram) as being the RS. I don't expect any visibility into what&#= 39;s going on on the=C2=A0right.=C2=A0

    My problem with t= he framing you propose is that requests are going to the RS (or the AS-RS) = and I don't want to share my policies with the AS-RS. I want to keep th= e RS and AS-RS as ignorant as possible.

    Adrian

    On Mon, Mar 22, 2021 at 1:48 PM Justin Richer <jricher@mit.edu> wrote:
    =
    Adrian,

    What you=E2=80=99re discussing below, in te= rms of logging in to a site, is not approaching the RS. You are in fact app= roaching the client, and identifying both the AS and RS to the client. The = client is a client of your identity in this model, and the RS is par= t of the identity provider. It=E2=80=99s really important that we don=E2=80= =99t conflate the RS and client in this way as it leads to a lot of confusi= on downstream and a lot of broken trust boundaries.

    With that model in mind, approaching the =E2=80=9CRS" and providing = it your identity is really just a case of the =E2=80=9Cfederated login to A= S=E2=80=9D pattern that we discussed on the WG call. The user here approach= es an RS, which has its own AS. To share things from this RS, the RO has to= authenticate to the RS=E2=80=99s AS. This particular AS allows the RO to d= o so using an external identity =E2=80=94 in which case, the AS is now a = =E2=80=9Cclient=E2=80=9D of a separate, disconnected (but layered) delegati= on. The ultimate client that eventually calls the RS down the way may or ma= y not know about these layers.=C2=A0

    <PastedGraphic-1.png>
    This= same AS, which is closely tied to the RS and trusted by the RS, might also= take in FIDO credentials, or DIDs, or any number of other proof mechanisms= . The output of this is an access token the RS trusts, but the input is up = to the AS. The RS is not what you=E2=80=99re logging in to.

    <= /div>
    =C2=A0=E2=80=94 Justin

    On Mar 22, 2021, at 1:28 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    <= div dir=3D"ltr">I too am in favor of avoiding consolidation and correlation= . Right now, when I approach a service provider (RS) for the first time, I&= #39;m offered the opportunity to identify my persona as: email, sign-in wit= h Google, Facebook, or Apple. I know there are people who try to create one= -off email addresses but that is mostly a waste of time.=C2=A0

    So, along come FIDO2 and DID wallets to the rescue. Now, in theory, = I have a way to start out my RS relationship pseudonymously.=C2=A0

    When I want my resource to be discovered or shared I will = post that RS URL including my pseudonym. If I then want to introduce a medi= ator=C2=A0in front of my AS or messaging service=C2=A0endpoint, I have that= option. If I want to keep requests away from the mediator, I would publish= an encryption key along with my pseudonym.

    - Adri= an



    =
    On Mon, Mar 22, 2021 at 9:55 AM Justi= n Richer <jricher@mit.edu&g= t; wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin K= aduk <kaduk@mit.edu> wrote= :
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhk= arp@gmail.com> shared a talk about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-= gnap/gnap-core-protocol/issues/145#issuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --
    TXAuth 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
    --
    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

    --0000000000001c53bd05be6fb548-- From nobody Fri Mar 26 06:30:46 2021 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 D51353A1EA8 for ; Fri, 26 Mar 2021 06:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.194 X-Spam-Level: X-Spam-Status: No, score=-4.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 sv6EMs8PCt4I for ; Fri, 26 Mar 2021 06:30:37 -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 CCF9F3A1EAB for ; Fri, 26 Mar 2021 06:30:36 -0700 (PDT) Received: from [192.168.1.22] (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 12QDUVvx025024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Mar 2021 09:30:32 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_2CD10F34-603C-46EA-8B31-3AB416215010" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 26 Mar 2021 09:30:31 -0400 In-Reply-To: Cc: Alan Karp , Benjamin Kaduk , Fabien Imbault , GNAP Mailing List , Mark Miller To: Adrian Gropper References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> <5773FA7B-6891-4227-A8CA-2F506909B8CD@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2021 13:30:45 -0000 --Apple-Mail=_2CD10F34-603C-46EA-8B31-3AB416215010 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Adrian, I disagree, I believe that what I have laid out is exactly separating = the concerns into working components.=20 Like OAuth before it, GNAP is a protocol negotiate access for a client = instance to an RS, using an AS as the facilitator of that delegated = negotiation. (Unlike OAuth, it=E2=80=99s importantly also for = negotiating user information to the client directly from the AS with no = RS involved, but that=E2=80=99s an aside for the purposes of our = conversation here). If a particular GNAP RS also allows other kinds of processes to enable = access to it, that is completely fine, but outside of GNAP. If an RS = allows a username/password HTTP Basic auth in addition to accepting = access tokens, it can do so, but GNAP doesn=E2=80=99t have anything to = say about the Basic auth use, or even its relation to any access tokens = or RO=E2=80=99s or anything else. If an RS accepts structured access = tokens signed by trusted keys that don=E2=80=99t come from an AS through = a negotiated request =E2=80=94 again, that=E2=80=99s fine, but GNAP is = silent about the RS doing that. If the RS acts as =E2=80=9Cits own AS=E2=80= =9D then it=E2=80=99s really just an RS and an AS living in the same = box. Again, that=E2=80=99s fine, and super common with OAuth today.=20 GNAP is solving the problem of connecting the client to the RS through = means of an AS. Other solutions are possible and many of them can be = deployed right alongside, but that=E2=80=99s not the corner of the world = that GNAP is solving. GNAP should be concerned about how these other = technologies can be used alongside it. I think there=E2=80=99s a lot of = room for the things that you=E2=80=99re talking about, and more = importantly for solving the use cases that you=E2=80=99re bringing. But = GNAP should be more than a single-point solution, and so we need to = balance these concerns. The conceptual framework of an AS that takes in = lots of different information and spits out access tokens is exactly the = abstraction layer that is necessary for making these use cases = interoperable. =E2=80=94 Justin > On Mar 26, 2021, at 8:30 AM, Adrian Gropper = wrote: >=20 > @Justin, there=E2=80=99s no separation of concerns here. No partition = between processor and controller. No data minimization. And, I see no = obvious reason to make this the core of GNAP.=20 >=20 > The one thing we can probably all agree on is that there=E2=80=99s = only one RS and one RO.=20 >=20 > The core of GNAP, in my opinion, can be built and explained around = this simple design. The RS is a processor. The RO is a controller. The = RS bears only security responsibility. The RS bears no privacy = responsibility. The RO delegates this to the RS but this is not = authorization as the A in GNAP. >=20 > The RO retains all rights to delegate within the scope of things that = the RS is willing to support using various token formats and endpoint = options. Some of these options may do all sorts of things for all sorts = of clients and user-agents but these are options.=20 >=20 > For example, if a request comes to the RS that is not in the form of = an access token, then it either gets sent to the RO or their agent, or = it gets logged and dumped. One such option, common in healthcare, is = =E2=80=9CBreak the Glass=E2=80=9D where the RS is acting as an = authorization server because the user-agent is making a request instead = of presenting an access token. GNAP can offer this as an option but it = is not our core. >=20 > Adrian >=20 >=20 >=20 > On Fri, Mar 26, 2021 at 7:15 AM Justin Richer > wrote: > I have a big problem with this line: >=20 > > the RS and AS-RS only see access tokens. The requests (from RO') = that resulted in an access token are none of their business. >=20 > In the trust model we=E2=80=99ve been discussing, the requests that = result in access tokens are solely the business of AS-RS, since AS-RS is = the only entity that=E2=80=99s allowed, and trusted by the RS, to create = access tokens for the RS. That is its entire job, the entire reason it = exists in the system. By definition the party generating tokens for use = at the RS is the AS for that RS, I don=E2=80=99t care how you deploy it. = If RO wants to give access to someone else (who isn=E2=80=99t an =E2=80=9C= RO" anymore, they=E2=80=99re another end-user), then that end user=E2=80=99= s client software will need to talk to AS-RS to get its own access = token. >=20 > Now here=E2=80=99s the trick: when the end user=E2=80=99s client = instance talks to AS-RS, that does NOT mean that AS-RS needs to know all = the details and policy reasons that it should give an access token to = that client instance. It doesn=E2=80=99t even need to know the existence = of another end user. It doesn=E2=80=99t need identity, it doesn=E2=80=99t = need policy. Sure, it COULD handle all of that internally, and many = will, but the protocol doesn=E2=80=99t demand it.=20 >=20 > This means that the first client instance, the one that gets the = access token, can also be given something alongside the access token = that it can then hand to another piece of software (or to a person to = hand eo their piece of software). This artifact is not an access token. = This artifact could be something structured that the client understands, = and can make derivatives of, and present back to the AS-RS for getting = new access tokens. There could be multiple different flavors of this = kind of artifact for different kinds of environments and groups. But = what they all have in common is that they can potentially be used to = request more access tokens within some context at the AS-RS. >=20 > =E2=80=94 Justin >=20 >=20 >=20 >> On Mar 25, 2021, at 5:50 PM, Adrian Gropper > wrote: >>=20 >> My issue is with Alan's: >> "7. Another user agent (RO') can contact any holder of the access = token or the service's policy agent (AS-RS) to get a delegated access = token." >>=20 >> I would prefer "7A. Another user agent (RO') can contact any holder = of the access token." by default so that the AS-RS does not see the = requests. In other words, the RS and AS-RS only see access tokens. The = requests (from RO') that resulted in an access token are none of their = business. >>=20 >> The reality is that RO' can discover a resource RS and can share = whatever information with RS-AS they want and the RO may not even know = about it unless the RS decides to let them know somehow. This seems to = be a drawback of the capabilities approach.=20 >>=20 >> In terms of privacy and control, I, as the RO, want a contract with = the RS that says that I or my agent (AS-RO) must sign an access token. = This is a fundamental audit requirement. Without it, a rogue RS and = AS-RS can do all sorts of things and the RO would never know. I = understand that a rogue RS might not support an honest contemporaneous = log of access tokens presented so there's a trust issue here that I = seems unavoidable unless I specify in my RO-RS contract that they use a = separate contemporaneous log such as AS-RO for every access token = presented and risk being sued if they process an access token without = also updating the separate log. >>=20 >> - Adrian >>=20 >>=20 >> On Thu, Mar 25, 2021 at 1:22 PM Alan Karp > wrote: >> Justin Richer > wrote: >> Hi Alan, >>=20 >> In all of my discussion, and in the spec itself, the RO is the = :entity: in charge of approving rights. They=E2=80=99re probably a = person. It might be software that makes a policy decision in some way, = or a corporate entity, or something like that. But it=E2=80=99s not = assumed to be a computational agent in the terms of the protocol itself. = Would that recast what you=E2=80=99re saying below? >>=20 >> Hmmm. I guess not. It's just that the person would be using some UI = to express their decisions to what I called the user agent. That model = fits in very nicely with what we did with Polaris, our virus safe = computing environment for Windows XP, = https://dl.acm.org/doi/10.1145/1151030.1151033 = . The person would = click on the icon for a Word file, and an instance of Word would open = with only the permission needed to edit that one file. Same thing here. = The client could ask for permission to use the resource, or permission = could be granted implicitly when the user selects a resource associated = with a specific client. >>=20 >> -------------- >> Alan Karp >>=20 >>=20 >> On Thu, Mar 25, 2021 at 9:53 AM Justin Richer > wrote: >> Hi Alan, >>=20 >> In all of my discussion, and in the spec itself, the RO is the = :entity: in charge of approving rights. They=E2=80=99re probably a = person. It might be software that makes a policy decision in some way, = or a corporate entity, or something like that. But it=E2=80=99s not = assumed to be a computational agent in the terms of the protocol itself. = Would that recast what you=E2=80=99re saying below? >>=20 >> =E2=80=94 Justin >>=20 >>> On Mar 25, 2021, at 12:36 PM, Alan Karp > wrote: >>>=20 >>> There seems to be some confusion about how AS-RO comes into the = picture, probably because of the "AS" part. I'm going to try to clear = up that confusion by more carefully explaining what I mean. >>>=20 >>> I'm assuming that RO is a computational agent representing the = person who is the resource owner, something called the "user agent" in = operating systems lingo. I'm also assuming that it's possible to do = delegation, either locally or by token exchange with AS-RS. All = delegations are potentially sub-scoped, but you may also want to = delegate with full scope to have a separately revocable access token. >>>=20 >>> Here's an example of how things work in a capability oriented = system. >>> Someone, the service owner, creates a service. >>> The service owner contracts with an policy agent (AS-RS) to create = and manage access tokens for that service (RS). >>> A person wishing to create a resource at RS uses their user agent = (RO) to contact the service owner's policy agent (AS-RS) and gets back = an access token for that resource. >>> That user agent (RO) can=20 >>> use that access token to invoke the resource, or >>> delegate an access token to a client of the user agent's (RO) = choice, or >>> contract with a policy agent (AS-RO) to manage those delegations on = behalf of the user agent (RO), or >>> specify a policy with the service's policy agent (AS-RS). >>> A client can contact any holder of the access token (the user agent = (RO) or its policy agent (AS-RO)) or the service's policy agent (AS-RS) = to get a delegated access token. >>> That client can delegate that token to another client. >>> Another user agent (RO') can contact any holder of the access token = or the service's policy agent (AS-RS) to get a delegated access token. >>> The other user agent (RO') can=20 >>> use that access token to invoke the resource, or >>> delegate it to a client of its choice, or >>> contract with a policy agent (AS-RO') of its choosing to manage = those delegations on its behalf, or >>> specify a policy with the service's policy agent (AS-RS). >>> and so on >>> When any of these computational agents, user agents (ROs) or clients = acting on their behalf, invokes the resource, AS-RS verifies that the = access token is a valid delegation, i.e., proper sub-scoping, hasn't = been revoked, and that it authorizes the request being made before = telling the service (RS) to honor the request. At no point does the = service's policy agent (AS-RS) know which computational agent did any = particular delegation. (Token exchange can be done as anonymously as = possible.) In particular, the policy agents (AS-RO) need not be the = same, or even compatible with, the service's policy agent (AS-RS). GNAP = specifies the protocol between requesters, invokers, delegators (for = token exchange) of tokens and AS-RS. That protocol need not be used = between user agents (RO), clients, or other policy agents (AS-RO), but = it is likely to be. >>>=20 >>> ------------- >>> Alan Karp >>>=20 >>>=20 >>> On Thu, Mar 25, 2021 at 5:45 AM Justin Richer > wrote: >>> The way I=E2=80=99m thinking about Adrian=E2=80=99s use case is that = what we=E2=80=99re calling the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an = =E2=80=9CAS=E2=80=9D in the traditional OAuth/GNAP sense, at least not = exactly. This is the agent that the RO can use to set policies and = manage consent on their behalf, and I=E2=80=99ve been arguing that it = fits better into this vaguely-defined =E2=80=9Cinteraction component=E2=80= =9D aspect of the current AS definition, and it=E2=80=99s not currently = separated from the AS definition. The =E2=80=9CAS-RS=E2=80=9D maps to = what we=E2=80=99d call the =E2=80=9CAS=E2=80=9D in OAuth/GNAP = traditionally, it=E2=80=99s what the RS trusts to issue tokens. In = traditional OAuth the AS-RO and AS-RS are always the same thing, from a = functional protocol perspective. An important point here is that from a = client=E2=80=99s perspective, they=E2=80=99re only talking to the AS-RS = since that=E2=80=99s where the client gets its tokens, because at the = end of the day the client just wants to call the API at the RS and = doesn=E2=80=99t care how that happens (from a protocol standpoint).=20 >>>=20 >>> Note well: Even thought I don=E2=80=99t believe that =E2=80=9CAS-RO=E2= =80=9D is an authorization server at all, I=E2=80=99m going to keep = using that term below for consistency with previous discussion. >>>=20 >>> So we have these fundamental relationships around getting the client = to access the RS: >>>=20 >>> 1. RS trusts AS-RS to issue tokens that RS will accept, validate, = and process for requests from client >>> 2. Client trusts AS-RS to issue tokens that client can use at RS >>> 3. RO trusts RS to protect RO=E2=80=99s api through delegated access >>>=20 >>> On top of that, we=E2=80=99ve got some additional aspects that = we=E2=80=99re discussing: >>>=20 >>> 4. RO trusts AS-RO to manage RO=E2=80=99s policies at runtime >>> 5. AS-RS trusts AS-RO to assert RO=E2=80=99s policies for access to = RS >>> 6. Client trusts whatever AS-RS sends client to deal with, including = possibly RO-AS at runtime, because of (2) >>>=20 >>> What I have been saying is that 4/5/6 are optional details of how = RS-AS runs things, and I think this also maps with Adrian=E2=80=99s view = of choice, since if my RS=E2=80=99s AS-RS doesn=E2=80=99t allow me to = plug in my own AS-RO then I would be motivated to pick a different RS = who=E2=80=99s AS-RS lets me do just that. The same way I=E2=80=99d pick = a different RS if their surrounding services didn=E2=80=99t accept my = preferred federation login and I didn=E2=80=99t want to make another = account. Of course, market forces being as they are, I might not have = much of an actionable choice in RS, but GNAP can=E2=80=99t change that.=20= >>>=20 >>> What we can do is make it possible for AS-RS to talk to AS-RO, both = in philosophy of the protocol design and in concrete hooks to support = (6) above.=20 >>>=20 >>> Separately, we can approach the issue of making 1/2 above more = dynamic. This was UMA2=E2=80=99s =E2=80=9Cfederated authorization=E2=80=9D= approach, and is behind a lot of the =E2=80=9Cbring your own AS=E2=80=9D = models out there. The problem with these is that we know from many years = of experience that most RS=E2=80=99s aren=E2=80=99t interested in doing = anything of the sort. >>>=20 >>> So with GNAP we can instead allow 4/5/6 to vary in a predictable and = consistent way, letting the RS keep control over 1/2, thereby enabling = choice in (3). We don=E2=80=99t have to be the ones who define the all = of the details of every permutation of (5) to enable this, though. Some = of this is going to be configuration out of band, some of it=E2=80=99s = going to be communication at runtime. This is where VC=E2=80=99s, ZCAPs, = CHAPI, DIDComm, FIDO, and a whole swath of other tech can come in and = help out. I don=E2=80=99t think we need to put all the details for using = these into core, nor do I think we=E2=80=99ll pull of The Great And = Ultimate Abstraction for using these and other approaches. But we can at = least start talking about =E2=80=9CAS-RS=E2=80=9D in such a way that it = no longer assumes it=E2=80=99s always the same party dealing with the RO = directly. >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Mar 25, 2021, at 6:40 AM, Fabien Imbault = > wrote: >>>>=20 >>>> To reframe it closer to GNAP: >>>> - AS =3D AS-RO, that's where you find the RO policies. The AS = issues access tokens to the client. >>>> - the RO policies could be a) defined locally or b) in relationship = with the RS >>>>=20 >>>> There have been several ideas related to the AS-RS relationship b: >>>> b1) the RS issues capabilities (which can be further attenuated by = the RO) >>>> b2) Adrian also discussed a DID based solution >>>> b3) there was also an alternative ACL proposal from Denis (+ = preflight) >>>>=20 >>>> Fabien >>>>=20 >>>>=20 >>>> On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault = > wrote: >>>> Ok so I get you correctly:=20 >>>> - what matters is the RQ (could be a RO or a end-user or both : we = don't really care at a high-level, they're all treated as entities that = make a request) >>>> - the policy is able to handle those different cases, based on its = own internal delegation protocol >>>> - currently that requires AS-RS and AS-RO, but maybe it can be = simplified >>>>=20 >>>> To answer to Denis, here's what I understood: >>>> - RO trusts AS-RS (and then handles its own policies within AS-RO) >>>> - end-user trusts AS-RO (through its client) >>>>=20 >>>> Could probably work but that's a fairly different model compared to = OAuth2 (and of today's GNAP), with different frontiers between the AS = and the RS.=20 >>>>=20 >>>> Please do not hesitate to correct me if I'm wrong. >>>>=20 >>>> Fabien=20 >>>>=20 >>>> On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper = > wrote: >>>> I believe there are alternatives to having two kinds of ASs. The = problem may be a side-effect of deciding to switch away form treating = the RO as different from the RQ. That leads to downstream privacy = issues. Our desire for architectural simplicity is admirable but that = may have been a step too far. >>>>=20 >>>> There may also be solutions based on different types of tokens, as = in different capabilities (tokens signed by the RS) vs. tokens signed by = the AS. I=E2=80=99m not sure about that but Alan might have more to say. >>>>=20 >>>> Adrian >>>>=20 >>>> On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault = > wrote: >>>> Thanks. The general problem statement is clear. >>>>=20 >>>> The proposed solution a bit less (to me). I understood that from = point 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obvious = reason to have two types of ASs". Do you see an alternative ? >>>>=20 >>>> Regarding the last item, I don't think that naming RQ by end-user = created the problem. It might just highlight the asymmetry, which = fundamentally exists.=20 >>>>=20 >>>> Fabien >>>>=20 >>>>=20 >>>> On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper = > wrote: >>>> Recap: >>>> 1 - Justin (I think) introduced the idea of an AS on the RS trust = boundary side. >>>> 2 - I said the RO should not have to share policies with the RS. >>>> 3 - Alan invented the concept of AS-RO and AS-RS to separate two = kinds of PDPs.=20 >>>>=20 >>>> The thing is that step 2 is not symmetrical. The RO has a = legitimate privacy interest in keeping their policies private and = minimizing the leakage of information about requests that are posed = against those policies.=20 >>>>=20 >>>> The RS, on the other hand, should be publishing its policies (e.g. = what it=E2=80=99s selling or what jurisdiction it=E2=80=99s in or what = tokens or scopes it supports). The RS has no obvious privacy interest in = GNAP. It=E2=80=99s just an enforcer. >>>>=20 >>>> There is one other privacy interest to consider around the RS and = that is the requesting party (the end-user that is not the RO :-) might = prefer to share attributes with the RS instead of the RO or something = controlled by the RO. This case could be an =E2=80=9Cextension=E2=80=9D = to GNAP and might result in a split AS as a solution. This problem was = introduced when the editors decided to replace RQ with end-user. = Obviously, the RO end-user has no privacy interests relative to itself. >>>>=20 >>>> Adrian >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault = > wrote: >>>> I was referring to "By my definition, this model has two ASs since = both are processing requests into tokens". If there's no reason to have = 2 types of ASs, that's fine then.=20 >>>> But I'm a bit lost in where we stand with the idea.=20 >>>>=20 >>>> Could you recap?=20 >>>>=20 >>>> Fabien=20 >>>>=20 >>>> Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper = > a =C3=A9crit : >>>> There=E2=80=99s no obvious reason to have two types of ASs. Any AS = that is executing the policies of the RS can look to GNAP like the RS = itself. Why would GNAP expose that interface to anyone?=20 >>>>=20 >>>> Adrian >>>>=20 >>>> On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault = > wrote: >>>> Note : I'm not sure that's a good idea, but having 2 types of ASs = is not that easy to grasp. >>>>=20 >>>> Fabien=20 >>>>=20 >>>> Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault = > a =C3=A9crit = : >>>> The purpose of either handling policies locally or delegating them = to the RO agent.=20 >>>>=20 >>>> Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper = > a =C3=A9crit : >>>> What purpose would be served by GNAP splitting the AS into two = components? >>>>=20 >>>> Adrian=20 >>>>=20 >>>> On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault = > wrote: >>>> Isn't the AS-RO a component of the AS? Same idea as the interact = component, it functionnally belongs to the AS role but could be deployed = either as a monolith or as a separate component? >>>>=20 >>>> Fabien >>>>=20 >>>> Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper = > a =C3=A9crit : >>>> Yes, but I would say it=E2=80=99s not the RO that wants the access = token. It=E2=80=99s the RO that wants the client making the request to = get an access token.=20 >>>>=20 >>>> Adrian >>>>=20 >>>> On Wed, Mar 24, 2021 at 11:22 PM Alan Karp > wrote: >>>> Adrian Gropper > wrote: >>>>=20 >>>> In this design, the AS is the AS-RS and the agent is the AS-RO. By = my definition, this model has two ASs since both are processing requests = into tokens. The problem with this is complexity and privacy. The RO may = not want to share the request information with the AS-RS. >>>>=20 >>>> More precisely, RO has no choice but to present the required = information to AS-RS if RO wants an access token. However, RO does not = want AS-RS to know the policy by which RO delegates tokens. That's why = RO uses AS-RO for those delegations. >>>>=20 >>>> -------------- >>>> Alan Karp >>>>=20 >>>>=20 >>>> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper = > wrote: >>>> Thank you for creating the issue. My definition of AS is = independent of AS-RO or AS-RS. = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomment= -806280421 = I also agree with Alan's definition based on delegation. An = AS-RS would be a delegate of the RS.=20 >>>>=20 >>>> Based on that, I see it as obvious that the policy has to be = accessible (defined locally?) in order for it to be run as the code that = turns a request into an access token.=20 >>>>=20 >>>> The only other possibility is that the request is packaged by the = AS and sent elsewhere (an agent) for evaluation against policy and a = proto-token returned. In that case the AS is acting as a proxy and the = PDP is elsewhere. I can imagine that an AS-RS would behave this way so = that the proto-token could be turned into an access token by the AS-RS. = Isn't this what Justin is proposing? In this design, the AS is the AS-RS = and the agent is the AS-RO. By my definition, this model has two ASs = since both are processing requests into tokens. The problem with this is = complexity and privacy. The RO may not want to share the request = information with the AS-RS. >>>>=20 >>>> Adrian >>>>=20 >>>> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault = > wrote: >>>> Isn't that what the AS is supposed to be, only with the caveat that = the policy is defined locally?=20 >>>>=20 >>>> Fabien=20 >>>>=20 >>>>=20 >>>> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp > a =C3=A9crit : >>>> AS-RO is an AS that RO trusts to delegate RO's access tokens = according to RO's policies. =20 >>>>=20 >>>> -------------- >>>> Alan Karp >>>>=20 >>>>=20 >>>> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault = > wrote: >>>> Hi Alan and Adrian, >>>>=20 >>>> I've created issue AS-RO policy delegation = (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223 = ) to = capture your input.=20 >>>> A first question that arises: can we give a definition to AS-RO? >>>>=20 >>>> Thanks >>>> Fabien >>>>=20 >>>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp > wrote: >>>> Fabien Imbault > wrote: >>>> Hi Alan,=20 >>>>=20 >>>> Yes, but in that flow, the token relationship between AS-RS and = AS-RO is only secure if the tokens issued by AS-RS are cryptographically = attenuable in the first place.=20 >>>> =20 >>>> Attenuated delegation is a requirement, but that doesn't have to be = done cryptographically. Token exchange works just fine. SPKI and = zcap-ld are examples of the crypto approach, and we used token exchange = in the system for HP. >>>>=20 >>>> -------------- >>>> Alan Karp >>>>=20 >>>>=20 >>>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault = > wrote: >>>> Hi Alan,=20 >>>>=20 >>>> Yes, but in that flow, the token relationship between AS-RS and = AS-RO is only secure if the tokens issued by AS-RS are cryptographically = attenuable in the first place.=20 >>>>=20 >>>> Fabien >>>>=20 >>>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp > wrote: >>>> Justin Richer > wrote: >>>>=20 >>>> But with all that in mind, I think the key here is going to be = looking at what the inputs to the AS are, and how those can be defined = in an interoperable way for AS=E2=80=99s that can accept them. I think = there=E2=80=99s a lot of room for innovation and flexibility here that = doesn=E2=80=99t break the trust model or core use cases. If I have an = AS-RS set that won=E2=80=99t accept my favorite flavor of policy engine = inputs, then I can decide not to use that one. But this is a very = different question than saying the RS itself needs to accept my own AS = =E2=80=94 and we can=E2=80=99t keep conflating these two models. >>>>=20 >>>> I agree. The point of having an AS-RO is to allow RO to specify a = policy for which of RO's access tokens should be delegated under what = conditions. AS-RS should not need to understand those policies. The = flow would be >>>> RO contacts AS-RS and gets one or more access tokens. >>>> RO delegates one or more of those tokens, potentially sub-scoped, = to AS-RO. >>>> A different user contacts AS-RO to get a potentially sub-scoped = access token from AS-RO. >>>> That user presents the access token delegated by AS-RO when = invoking the resource. >>>> AS-RS only needs to verify that the delegation chain is legitimate, = e.g., no increase in scope, and that it grants permission for the = request being made. AS-RS does not need to understand the policy behind = granting the delegation by AS-RO. >>>>=20 >>>> -------------- >>>> Alan Karp >>>>=20 >>>>=20 >>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer > wrote: >>>> Adrian, >>>>=20 >>>> I think this shows the problem with the terminology as it=E2=80=99s = been applied in this conversation, which I=E2=80=99ve tried to shine = light on before. What you and others are calling the =E2=80=9CRS=E2=80=9D = is really the =E2=80=9CAS and RS working together=E2=80=9D =E2=80=94 = everything to the right of the line. When Denis had brought up = =E2=80=9Celiminating the AS=E2=80=9D in another thread, what he=E2=80=99d = really done is labeled everything to the right of the line as the = =E2=80=9CRS=E2=80=9D. Of course, the irony here is that everything to = the right of the line used all be called the =E2=80=9CAS=E2=80=9D or = simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say below, I = don=E2=80=99t want the client to have visibility on what happens on that = side.=20 >>>>=20 >>>> Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the = diagram is not the AS, as far as GNAP is concerned. It does not issue an = access token that the RS will accept. The elements to the left of the = line could be a lot of things, but they are NOT the AS =E2=80=94 by = definition. The client lives over on the left, but so do any external = inputs to the AS. These could be policy inputs on behalf of the RO, they = could be presentation artifacts, they could be federated logins, they = could be the output of policy decisions. How the AS comes to trust those = things is up to the AS=E2=80=99s implementation. It=E2=80=99s something = we can talk about, but ultimately GNAP won=E2=80=99t be in any position = to dictate because in practice some AS=E2=80=99s are simply going to = internalize all policies and we will never successfully force those = open.=20 >>>>=20 >>>> But with all that in mind, I think the key here is going to be = looking at what the inputs to the AS are, and how those can be defined = in an interoperable way for AS=E2=80=99s that can accept them. I think = there=E2=80=99s a lot of room for innovation and flexibility here that = doesn=E2=80=99t break the trust model or core use cases. If I have an = AS-RS set that won=E2=80=99t accept my favorite flavor of policy engine = inputs, then I can decide not to use that one. But this is a very = different question than saying the RS itself needs to accept my own AS = =E2=80=94 and we can=E2=80=99t keep conflating these two models. >>>>=20 >>>> So to me, GNAP can support a Zero Trust Architecture by LEVERAGING = the AS, not by subsuming or eliminating it. It is in fact the AS, not = the client and not the RS, that will request and consume the results of = a privacy-preserving zero-trust policy query thing. Anything that = happens downstream from that is of little concern to the zero-trust = components because, as you point out, it=E2=80=99s on the =E2=80=9Cother = side=E2=80=9D of the line.=20 >>>>=20 >>>> I think we got this basic component model pretty right in OAuth: = the AS and RS and client working together. Where OAuth misses the mark = is the assumption that the user has to log in to the AS through a = webpage and interact directly, thereby proving they=E2=80=99re the RO. = It=E2=80=99s this latter space where I think we can both push innovation = and also address the important and compelling use cases like the ones = you=E2=80=99re bringing. >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper = > wrote: >>>>>=20 >>>>> I'm sorry, Justin. As a Resource Owner, I look at the RS trust = boundary (the dotted line in the diagram) as being the RS. I don't = expect any visibility into what's going on on the right.=20 >>>>>=20 >>>>> My problem with the framing you propose is that requests are going = to the RS (or the AS-RS) and I don't want to share my policies with the = AS-RS. I want to keep the RS and AS-RS as ignorant as possible. >>>>>=20 >>>>> Adrian >>>>>=20 >>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer > wrote: >>>>> Adrian, >>>>>=20 >>>>> What you=E2=80=99re discussing below, in terms of logging in to a = site, is not approaching the RS. You are in fact approaching the client, = and identifying both the AS and RS to the client. The client is a client = of your identity in this model, and the RS is part of the identity = provider. It=E2=80=99s really important that we don=E2=80=99t conflate = the RS and client in this way as it leads to a lot of confusion = downstream and a lot of broken trust boundaries. >>>>>=20 >>>>> With that model in mind, approaching the =E2=80=9CRS" and = providing it your identity is really just a case of the =E2=80=9Cfederated= login to AS=E2=80=9D pattern that we discussed on the WG call. The user = here approaches an RS, which has its own AS. To share things from this = RS, the RO has to authenticate to the RS=E2=80=99s AS. This particular = AS allows the RO to do so using an external identity =E2=80=94 in which = case, the AS is now a =E2=80=9Cclient=E2=80=9D of a separate, = disconnected (but layered) delegation. The ultimate client that = eventually calls the RS down the way may or may not know about these = layers.=20 >>>>>=20 >>>>> >>>>> This same AS, which is closely tied to the RS and trusted by the = RS, might also take in FIDO credentials, or DIDs, or any number of other = proof mechanisms. The output of this is an access token the RS trusts, = but the input is up to the AS. The RS is not what you=E2=80=99re logging = in to. >>>>>=20 >>>>> =E2=80=94 Justin >>>>>=20 >>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper = > wrote: >>>>>>=20 >>>>>> I too am in favor of avoiding consolidation and correlation. = Right now, when I approach a service provider (RS) for the first time, = I'm offered the opportunity to identify my persona as: email, sign-in = with Google, Facebook, or Apple. I know there are people who try to = create one-off email addresses but that is mostly a waste of time.=20 >>>>>>=20 >>>>>> So, along come FIDO2 and DID wallets to the rescue. Now, in = theory, I have a way to start out my RS relationship pseudonymously.=20 >>>>>>=20 >>>>>> When I want my resource to be discovered or shared I will post = that RS URL including my pseudonym. If I then want to introduce a = mediator in front of my AS or messaging service endpoint, I have that = option. If I want to keep requests away from the mediator, I would = publish an encryption key along with my pseudonym. >>>>>>=20 >>>>>> - Adrian >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer > wrote: >>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk > wrote: >>>>>> >=20 >>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote: >>>>>> >> @Alan Karp > = shared a talk about the Principle Of Least >>>>>> >> Authority (POLA) in a recent comment >>>>>> >> = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment= -803099693 = >>>>>> >> I recommend it. >>>>>> >>=20 >>>>>> >> We might expect a protocol with authorization in the title to = use authority >>>>>> >> as a core principle. I advocate for a GNAP design that = maximizes the power >>>>>> >> of the RO, to be seen as a human rights issue when the RO is a = human. This >>>>>> >> causes me to ask how to combine better security with better = human rights in >>>>>> >> GNAP. >>>>>> >>=20 >>>>>> >> Who should have the least authority in the GNAP design? >>>>>> >>=20 >>>>>> >> The AS derives authority as a delegate of the RO. If we ask = the RO to >>>>>> >> partition limited authority across dozens of different ASs by = domain and >>>>>> >> function, then we are not using technology to empower the = individual. >>>>>> >> Probably the opposite, as we introduce consent fatigue and = burden normal >>>>>> >> people to partition their lives into non-overlapping domains. >>>>>> >>=20 >>>>>> >> My experience says we should aim for one AS per persona = because that maps >>>>>> >> into the way we manage our public and private identities. POLA = would then >>>>>> >> teach care in keeping ASs and RSs related to work / public = separate from >>>>>> >> ASs and RSs related to private life so that a policy = vulnerability in our >>>>>> >> delegation to an AS would have the least likelihood of harm. >>>>>> >=20 >>>>>> > Thinking about how least authority/least privilege would apply = to GNAP >>>>>> > seems like a useful exercise. I do want to point out some = potential >>>>>> > pitfalls with one-AS-per-persona that we can also be aware of. = If >>>>>> > one-AS-per-persona becomes one-persona-per-AS as well, then the = AS's >>>>>> > identity in effect also serves as a persona identity and there = are privacy >>>>>> > considerations to that. If, on the other hand, the >>>>>> > multiple-personas-per-AS (presumably corresponding to multiple = humans) >>>>>> > route is taken, we should consider whether that would lead to = various >>>>>> > (e.g., market) forces driving consolidation to just a handful = of >>>>>> > super-popular AS services. That topic is a current matter of = concern to >>>>>> > some IETF participants. >>>>>> >=20 >>>>>>=20 >>>>>> Hi Ben, big +1 to this. This is something that we discussed ages = ago in the UMA working group, and it=E2=80=99s one of the biggest = problems with the personal AS (and personal data store) model. This kind = of thing makes RS-first trust models really difficult in practice. >>>>>>=20 >>>>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve got software = that wants to access my medical information. It calls an RS and requests = access, but it hasn=E2=80=99t been granted anything yet. Now I as the RO = have set up the RS so that it talks to my personal AS, that only I use. = In addition to the RS having to be able to figure out which medical = records are being requested from the context of the unauthenticated = request (which means it needs identifiers in the URL or something = similar for the RS to be able to tell, assuming that it protects data = for more than one person). So this client software doesn=E2=80=99t know = who I am and doesn=E2=80=99t know my medical record information, makes a = completely unauthorized request to the RS, and the RS says =E2=80=9CGo = to Justin=E2=80=99s personal AS to get a token=E2=80=9D. The client can = now make a direct correlation between the data that=E2=80=99s being = protected at the RS and the person running the AS that protects it. = Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This = is a design feature in the good case, and terrifying in the bad case. >>>>>>=20 >>>>>> If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, = please talk to the Medicine Doctor AS to get access=E2=80=9D, we = haven=E2=80=99t exposed anything at all. And from the perspective of = both the patient and the RS, this is more privacy-preserving, and it=E2=80= =99s really the least surprising option. Once the client gets to the AS, = it can start a negotiation of figuring out who the RO is for the = information being accessed. >>>>>>=20 >>>>>> On top of this, the usability expectations of people managing = their own AS, or set of AS=E2=80=99s for multiple personas to keep = things separate, is a huge burden. Even in the tech community, I know = people who can=E2=80=99t reliably manage more than one email address for = different purposes. I wouldn=E2=80=99t expect my partner to do that =E2=80= =94 they have trouble enough balancing all the logins and sessions = required for different kids remote schooling, I couldn=E2=80=99t imagine = them having to understand all the requirements for managing multiple = authorization servers and associated policies. I also don=E2=80=99t = expect any person to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve = been on the internet for decades and I can barely keep tabs on my GPG = keys, and only use them when I am forced to. This is exactly the kind of = =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions above, = people will just want to outsource that to someone else, and the reality = will be a few popular providers. >>>>>>=20 >>>>>> In which case, we could end up doing a ton of work to allow an RS = choice only to end up with a world where the RS ends up making a limited = choice anyway. We see how that plays out with OpenID Connect =E2=80=94 = RP=E2=80=99s could allow arbitrary IdPs but they choose Google because = it works and that=E2=80=99s where the users are. (And that=E2=80=99s not = to say anything of the proprietary OIDC-like protocols, but that=E2=80=99s= another discussion). >>>>>>=20 >>>>>> For further reading on these topics, I recommend both =E2=80=9CWhy = Johnny Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems = Fail=E2=80=9D. >>>>>>=20 >>>>>> So what does this have to do with GNAP? I think we can be = clear-eyed on what kinds of expectations we have for the participants. = If we expect users (RO=E2=80=99s) to have to set up the AS-RS = relationship, or expect them to carry their AS, or manage their personal = keys =E2=80=94 I think we=E2=80=99ve lost the battle for relevance. >>>>>>=20 >>>>>> =E2=80=94 Justin >>>>>=20 >>>>=20 >>>> --=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 = >>>> --=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 = >=20 --Apple-Mail=_2CD10F34-603C-46EA-8B31-3AB416215010 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Adrian,

    I = disagree, I believe that what I have laid out is exactly separating the = concerns into working components. 

    Like OAuth before it, GNAP is a = protocol negotiate access for a client instance to an RS, using an AS as = the facilitator of that delegated negotiation. (Unlike OAuth, it=E2=80=99s= importantly also for negotiating user information to the client = directly from the AS with no RS involved, but that=E2=80=99s an aside = for the purposes of our conversation here).

    If a particular GNAP RS also allows = other kinds of processes to enable access to it, that is completely = fine, but outside of GNAP. If an RS allows a username/password HTTP = Basic auth in addition to accepting access tokens, it can do so, but = GNAP doesn=E2=80=99t have anything to say about the Basic auth use, or = even its relation to any access tokens or RO=E2=80=99s or anything else. = If an RS accepts structured access tokens signed by trusted keys that = don=E2=80=99t come from an AS through a negotiated request =E2=80=94 = again, that=E2=80=99s fine, but GNAP is silent about the RS doing that. = If the RS acts as =E2=80=9Cits own AS=E2=80=9D then it=E2=80=99s really = just an RS and an AS living in the same box. Again, that=E2=80=99s fine, = and super common with OAuth today. 

    GNAP is solving the problem of = connecting the client to the RS through means of an AS. Other solutions = are possible and many of them can be deployed right alongside, but = that=E2=80=99s not the corner of the world that GNAP is solving. GNAP = should be concerned about how these other technologies can be used = alongside it. I think there=E2=80=99s a lot of room for the things that = you=E2=80=99re talking about, and more importantly for solving the use = cases that you=E2=80=99re bringing. But GNAP should be more than a = single-point solution, and so we need to balance these concerns. The = conceptual framework of an AS that takes in lots of different = information and spits out access tokens is exactly the abstraction layer = that is necessary for making these use cases interoperable.

     =E2=80=94 = Justin

    On Mar 26, 2021, at 8:30 AM, Adrian Gropper = <agropper@healthurl.com> wrote:

    @Justin, there=E2=80=99s no = separation of concerns here. No partition between processor and = controller. No data minimization. And, I see no obvious reason to make = this the core of GNAP. 

    The one thing we can = probably all agree on is that there=E2=80=99s only one RS and one = RO. 

    The core of GNAP, in my opinion, can be = built and explained around this simple design. The RS is a processor. = The RO is a controller. The RS bears only security responsibility. The = RS bears no privacy responsibility. The RO delegates this to the RS but = this is not authorization as the A in GNAP.

    The RO = retains all rights to delegate within the scope of things that the RS is = willing to support using various token formats and endpoint options. = Some of these options may do all sorts of things for all sorts of = clients and user-agents  but these are options. 

    For example, if a request comes to the RS that is not in the = form of an access token, then it either gets sent to the RO or their = agent, or it gets logged and dumped. One such option, common in = healthcare, is =E2=80=9CBreak the Glass=E2=80=9D where the RS is acting = as an authorization server because the user-agent is making a request = instead of presenting an access token. GNAP can offer this as an option = but it is not our core.

    Adrian



    On Fri, Mar = 26, 2021 at 7:15 AM Justin Richer <jricher@mit.edu> wrote:
    I have a big problem with this = line:

    > the RS and AS-RS only see access tokens. The requests (from = RO') that resulted in an access token are none of their = business.

    In the trust = model we=E2=80=99ve been discussing, the requests that result in access = tokens are solely the business of AS-RS, since AS-RS = is the only entity that=E2=80=99s allowed, and trusted by the RS, to = create access tokens for the RS. That is its entire job, the entire = reason it exists in the system. By definition the party generating = tokens for use at the RS is the AS for that RS, I don=E2=80=99t care how = you deploy it. If RO wants to give access to someone else (who isn=E2=80=99= t an =E2=80=9CRO" anymore, they=E2=80=99re another end-user), then that = end user=E2=80=99s client software will need to talk to AS-RS to get its = own access token.

    Now = here=E2=80=99s the trick: when the end user=E2=80=99s client instance = talks to AS-RS, that does NOT mean that AS-RS needs to know all the = details and policy reasons that it should give an access token to that = client instance. It doesn=E2=80=99t even need to know the existence of = another end user. It doesn=E2=80=99t need identity, it doesn=E2=80=99t = need policy. Sure, it COULD handle all of that internally, and many = will, but the protocol doesn=E2=80=99t demand it. 

    This means that the = first client instance, the one that gets the access token, can also be = given something alongside the access token that it can then hand to = another piece of software (or to a person to hand eo their piece of = software). This artifact is not an access token. This artifact could be = something structured that the client understands, and can make = derivatives of, and present back to the AS-RS for getting new access = tokens. There could be multiple different flavors of this kind of = artifact for different kinds of environments and groups. But what they = all have in common is that they can potentially be used to request more = access tokens within some context at the AS-RS.

     =E2=80= =94 Justin



    On Mar 25, 2021, at 5:50 PM, = Adrian Gropper <agropper@healthurl.com> = wrote:

    My issue is with = Alan's:
    "7. Another = user agent (RO') can contact any holder of the access token or the = service's policy agent (AS-RS) to get a delegated access = token."

    I would prefer = "7A. Another user agent (RO') can contact any holder of the access = token." by default so that the AS-RS does not see the requests. In other = words, the RS and AS-RS only see access tokens. The requests (from RO') = that resulted in an access token are none of their = business.

    The reality is that RO' can = discover a resource RS and can share whatever information with RS-AS = they want and the RO may not even know about it unless the RS decides to = let them know somehow. This seems to be a drawback of the capabilities = approach. 

    In terms of privacy and control, = I, as the RO, want a contract with the RS that says that I or my = agent (AS-RO) must sign an access token. This is a fundamental audit = requirement. Without it, a rogue RS and AS-RS can do all sorts of things = and the RO would never know. I understand that a rogue RS might not = support an honest contemporaneous log of access tokens presented so = there's a trust issue here that I seems unavoidable unless I specify in = my RO-RS contract that they use a separate contemporaneous log such = as AS-RO for every access token presented and risk being sued if they = process an access token without also updating the separate = log.

    - = Adrian


    On Thu, Mar = 25, 2021 at 1:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin = Richer <jricher@mit.edu> wrote:
    Hi Alan,
    In all of my discussion, and in the = spec itself, the RO is the :entity: in charge of approving rights. = They=E2=80=99re probably a person. It might be software that makes a = policy decision in some way, or a corporate entity, or something like = that. But it=E2=80=99s not assumed to be a computational agent in the = terms of the protocol itself. Would that recast what you=E2=80=99re = saying below?

    Hmmm.  I guess = not.  It's just that the person would be using some UI to express = their decisions to what I called the user agent.  That model fits = in very nicely with what we did with Polaris, our virus safe computing = environment for Windows XP, https://dl.acm.org/doi/10.1145/1151030.1151033.  The = person would click on the icon for a Word file, and an instance of Word = would open with only the permission needed to edit that one file.  = Same thing here.  The client could ask for permission to use the = resource, or permission could be granted implicitly when the user = selects a resource associated with a specific client.

    --------------
    Alan = Karp


    On Thu, Mar = 25, 2021 at 9:53 AM Justin Richer <jricher@mit.edu> wrote:
    Hi Alan,
    In all of my discussion, and in the = spec itself, the RO is the :entity: in charge of approving rights. = They=E2=80=99re probably a person. It might be software that makes a = policy decision in some way, or a corporate entity, or something like = that. But it=E2=80=99s not assumed to be a computational agent in the = terms of the protocol itself. Would that recast what you=E2=80=99re = saying below?

     =E2=80=94 Justin

    On Mar = 25, 2021, at 12:36 PM, Alan Karp <alanhkarp@gmail.com> wrote:

    There seems to be some confusion = about how AS-RO comes into the picture, probably because of the "AS" = part.  I'm going to try to clear up that confusion by more = carefully explaining what I mean.

    I'm assuming that RO is a computational agent representing = the person who is the resource owner, something called the "user agent" = in operating systems lingo.  I'm also assuming that it's possible = to do delegation, either locally or by token exchange with AS-RS.  = All delegations are potentially sub-scoped, but you may also want to = delegate with full scope to have a separately revocable access = token.

      = Here's an example of how things work in a capability oriented system.
    1. Someone, = the service owner, creates a service.
    2. The service = owner contracts with an policy agent (AS-RS) to create and manage access = tokens for that service (RS).
    3. A person wishing to = create a resource at RS uses their user agent (RO) to contact the = service owner's policy agent (AS-RS) and gets back an access token for = that resource.
    4. That user agent (RO) can 
      1. use that access token to invoke the resource, = or
      2. delegate an access token to a client of the user = agent's (RO) choice, or
      3. contract with a policy agent = (AS-RO) to manage those delegations on behalf of the user agent (RO), = or
      4. specify a policy with the service's policy agent = (AS-RS).
    5. A client can contact any holder of the = access token (the user agent (RO) or its policy agent (AS-RO)) or the = service's policy agent (AS-RS) to get a delegated access token.
    6. That client can delegate that token to another = client.
    7. Another user agent (RO') can contact any = holder of the access token or the service's policy agent (AS-RS) to get = a delegated access token.
    8. The other user agent (RO') = can 
      1. use that access token to = invoke the resource, or
      2. delegate it to a client of = its choice, or
      3. contract with a policy agent (AS-RO') = of its choosing to manage those delegations on its behalf, or
      4. specify a policy with the service's policy agent = (AS-RS).
    9. and so on
    When any of these = computational agents, user agents (ROs) or clients acting on their = behalf, invokes the resource, AS-RS verifies that the access token is a = valid delegation, i.e., proper sub-scoping, hasn't been revoked, and = that it authorizes the request being made before telling the service = (RS) to honor the request.  At no point does the service's policy = agent (AS-RS) know which computational agent did any particular = delegation.  (Token exchange can be done as anonymously as = possible.)  In particular, the policy agents (AS-RO) need not be = the same, or even compatible with, the service's policy agent = (AS-RS).  GNAP specifies the protocol between requesters, invokers, = delegators (for token exchange) of tokens and AS-RS.  That protocol = need not be used between user agents (RO), clients, or other policy = agents (AS-RO), but it is likely to be.

     -------------
    Alan Karp


    On Thu, Mar = 25, 2021 at 5:45 AM Justin Richer <jricher@mit.edu> wrote:
    The way I=E2=80=99m = thinking about Adrian=E2=80=99s use case is that what we=E2=80=99re = calling the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an =E2=80=9CAS=E2=80=9D = in the traditional OAuth/GNAP sense, at least not exactly. This is the = agent that the RO can use to set policies and manage consent on their = behalf, and I=E2=80=99ve been arguing that it fits better into this = vaguely-defined =E2=80=9Cinteraction component=E2=80=9D aspect of the = current AS definition, and it=E2=80=99s not currently separated from the = AS definition. The =E2=80=9CAS-RS=E2=80=9D maps to what we=E2=80=99d = call the =E2=80=9CAS=E2=80=9D in OAuth/GNAP traditionally, it=E2=80=99s = what the RS trusts to issue tokens. In traditional OAuth the AS-RO and = AS-RS are always the same thing, from a functional protocol perspective. = An important point here is that from a client=E2=80=99s perspective, = they=E2=80=99re only talking to the AS-RS since that=E2=80=99s where the = client gets its tokens, because at the end of the day the client just = wants to call the API at the RS and doesn=E2=80=99t care how that = happens (from a protocol standpoint). 

    Note well: Even thought I don=E2=80=99t = believe that =E2=80=9CAS-RO=E2=80=9D is an authorization server at all, = I=E2=80=99m going to keep using that term below for consistency with = previous discussion.

    So we have these fundamental relationships around getting the = client to access the RS:

    1. RS trusts AS-RS to issue tokens that RS will = accept, validate, and process for requests from client
    2. Client trusts AS-RS to issue tokens that client = can use at RS
    3. RO trusts RS to protect RO=E2=80=99s= api through delegated access

    On top of that, we=E2=80=99ve got some = additional aspects that we=E2=80=99re discussing:
    4. RO trusts AS-RO to manage = RO=E2=80=99s policies at runtime
    5. AS-RS trusts AS-RO to assert RO=E2=80=99= s policies for access to RS
    6. Client trusts = whatever AS-RS sends client to deal with, including possibly = RO-AS at runtime, because of (2)

    What I have been saying is that 4/5/6 = are optional details of how RS-AS runs things, and I think this also = maps with Adrian=E2=80=99s view of choice, since if my RS=E2=80=99s = AS-RS doesn=E2=80=99t allow me to plug in my own AS-RO then I would be = motivated to pick a different RS who=E2=80=99s AS-RS lets me do just = that. The same way I=E2=80=99d pick a different RS if their surrounding = services didn=E2=80=99t accept my preferred federation login and I = didn=E2=80=99t want to make another account. Of course, market forces = being as they are, I might not have much of an actionable choice in RS, = but GNAP can=E2=80=99t change that. 

    What we can do is make it possible for = AS-RS to talk to AS-RO, both in philosophy of the protocol design and in = concrete hooks to support (6) above. 

    Separately, we can approach the issue = of making 1/2 above more dynamic. This was UMA2=E2=80=99s =E2=80=9Cfederat= ed authorization=E2=80=9D approach, and is behind a lot of the =E2=80=9Cbr= ing your own AS=E2=80=9D models out there. The problem with these is = that we know from many years of experience that most RS=E2=80=99s = aren=E2=80=99t interested in doing anything of the sort.

    So with GNAP we can = instead allow 4/5/6 to vary in a predictable and consistent way, letting = the RS keep control over 1/2, thereby enabling choice in (3). We don=E2=80= =99t have to be the ones who define the all of the details of every = permutation of (5) to enable this, though. Some of this is going to be = configuration out of band, some of it=E2=80=99s going to be = communication at runtime. This is where VC=E2=80=99s, ZCAPs, CHAPI, = DIDComm, FIDO, and a whole swath of other tech can come in and help out. = I don=E2=80=99t think we need to put all the details for using these = into core, nor do I think we=E2=80=99ll pull of The Great And Ultimate = Abstraction for using these and other approaches. But we can at least = start talking about =E2=80=9CAS-RS=E2=80=9D in such a way that it no = longer assumes it=E2=80=99s always the same party dealing with the RO = directly.

     =E2=80=94 Justin

    On Mar = 25, 2021, at 6:40 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    To reframe it = closer to GNAP:
    - AS =3D AS-RO, that's where you find the = RO policies. The AS issues access tokens to the client.
    - the RO policies could be a) defined locally or b) in = relationship with the RS

    There have been several ideas related to the AS-RS = relationship b:
    b1) the RS issues = capabilities (which can be further attenuated by the RO)
    b2) Adrian also discussed a DID based solution
    b3) there was also an alternative ACL proposal from Denis (+ = preflight)

    Fabien


    On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Ok so I get = you correctly: 
    - what matters is the RQ (could be a = RO or a end-user or both : we don't really care at a high-level, they're = all treated as entities that make a request)
    - the = policy is able to handle those different cases, based on its own = internal delegation protocol
    - currently that = requires AS-RS and AS-RO, but maybe it can be simplified

    To answer to Denis, = here's what I understood:
    - RO trusts AS-RS (and = then handles its own policies within AS-RO)
    - end-user trusts AS-RO (through its client)

    Could probably work but = that's a fairly different model compared to OAuth2 (and of today's = GNAP), with different frontiers between the AS and the = RS. 

    Please= do not hesitate to correct me if I'm wrong.

    Fabien 

    On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper = <agropper@healthurl.com> wrote:
    I believe = there are alternatives to having two kinds of ASs. The problem may be a = side-effect of deciding to switch away form treating the RO as different = from the RQ. That leads to downstream privacy issues. Our desire for = architectural simplicity is admirable but that may have been a step too = far.

    There may also be solutions based on different = types of tokens, as in different capabilities (tokens signed by the RS) = vs. tokens signed by the AS. I=E2=80=99m not sure about that but Alan = might have more to say.

    Adrian

    On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Thanks. The = general problem statement is clear.

    The proposed solution a bit less = (to me). I understood that from point 2, Alan involves 2 ASs. You said : = "There=E2=80=99s no = obvious reason to have two types of ASs". Do you see an = alternative ?

    Regarding the last item, I don't think that = naming RQ by end-user created the problem. It might just highlight the = asymmetry, which fundamentally exists. 

    Fabien


    On Thu, Mar 25, 2021 at 8:48 AM Adrian = Gropper <agropper@healthurl.com> wrote:
    Recap:
    1 - Justin (I think) = introduced the idea of an AS on the RS trust boundary side.
    2 - I said the RO should not have to share = policies with the RS.
    3 - Alan = invented the concept of AS-RO and AS-RS to separate two kinds of = PDPs. 

    The thing is that step 2 is not symmetrical. The = RO has a legitimate privacy interest in keeping their policies private = and minimizing the leakage of information about requests that are posed = against those policies. 

    The RS, on the other hand, = should be publishing its policies (e.g. what it=E2=80=99s selling or = what jurisdiction it=E2=80=99s in or what tokens or scopes it supports). = The RS has no obvious privacy interest in GNAP. It=E2=80=99s just an = enforcer.

    There is one other privacy interest to consider = around the RS and that is the requesting party (the end-user that is not = the RO :-) might prefer to share attributes with the RS instead of the = RO or something controlled by the RO. This case could be an = =E2=80=9Cextension=E2=80=9D to GNAP and might result in a split AS as a = solution. This problem was introduced when the editors decided to = replace RQ with end-user. Obviously, the RO end-user has no privacy = interests relative to itself.

    Adrian




    On Thu, Mar = 25, 2021 at 3:24 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    I was referring to "By my definition, this model has two ASs since both are = processing requests into tokens". If there's no reason to have 2 types = of ASs, that's fine then. 
    But I'm a bit lost in = where we stand with the idea. 

    Could you = recap? 

    Fabien 

    Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper = <agropper@healthurl.com> a =C3=A9crit :
    There=E2=80=99= s no obvious reason to have two types of ASs. Any AS that is executing = the policies of the RS can look to GNAP like the RS itself. Why would = GNAP expose that interface to anyone? 

    Adrian

    On Thu, Mar = 25, 2021 at 3:11 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Note : I'm = not sure that's a good idea, but having 2 types of ASs is not that easy = to grasp.

    Fabien 

    Le jeu. 25 = mars 2021 =C3=A0 08:07, Fabien Imbault <fabien.imbault@gmail.com> a = =C3=A9crit :
    The purpose = of either handling policies locally or delegating them to the RO = agent. 

    Le jeu. 25 mars 2021 =C3=A0 08:04, = Adrian Gropper <agropper@healthurl.com> a =C3=A9crit :
    What purpose = would be served by GNAP splitting the AS into two components?

    Adrian 

    On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Isn't the = AS-RO a component of the AS? Same idea as the interact component, it = functionnally belongs to the AS role but could be deployed either as a = monolith or as a separate component?

    Fabien

    Le jeu. 25 = mars 2021 =C3=A0 04:26, Adrian Gropper <agropper@healthurl.com> = a =C3=A9crit :
    Yes, but I = would say it=E2=80=99s not the RO that wants the access token. It=E2=80=99= s the RO that wants the client making the request to get an access = token. 

    Adrian

    On Wed, Mar = 24, 2021 at 11:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Adrian = Gropper <agropper@healthurl.com> wrote:

    In this = design, the AS is the AS-RS and the agent is the AS-RO. By my = definition, this model has two ASs since both are processing requests = into tokens. The problem with this is complexity and privacy. The RO may = not want to share the request information with the AS-RS.

    More precisely, RO has = no choice but to present the required information to AS-RS if RO wants = an access token.  However, RO does not want AS-RS to know the = policy by which RO delegates tokens.  That's why RO uses AS-RO for = those delegations.

    --------------
    Alan Karp


    On Wed, Mar = 24, 2021 at 7:41 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Thank you for creating the issue. My definition = of AS is independent of AS-RO or AS-RS. https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#i= ssuecomment-806280421 I also agree with Alan's definition based on = delegation. An AS-RS would be a delegate of the RS. 

    Based on = that, I see it as obvious that the policy has to be accessible = (defined locally?) in order for it to be run as the code that turns a = request into an access token. 

    The only other possibility is that the = request is packaged by the AS and sent elsewhere (an agent) for = evaluation against policy and a proto-token returned. In that case the = AS is acting as a proxy and the PDP is elsewhere. I can imagine that an = AS-RS would behave this way so that the proto-token could be turned into = an access token by the AS-RS. Isn't this what Justin is proposing? In = this design, the AS is the AS-RS and the agent is the AS-RO. By my = definition, this model has two ASs since both are processing requests = into tokens. The problem with this is complexity and privacy. The RO may = not want to share the request information with the AS-RS.

    Adrian

    On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Isn't that what the AS is supposed to be, only with the = caveat that the policy is defined locally? 

    Fabien 


    Le mer. 24 = mars 2021 =C3=A0 20:17, Alan Karp <alanhkarp@gmail.com> a =C3=A9crit :
    AS-RO is an AS that RO trusts to delegate RO's = access tokens according to RO's policies.  

    --------------
    Alan Karp


    On Wed, Mar 24, 2021 at 9:36 AM Fabien = Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan and = Adrian,

    I've created = issue AS-RO policy delegation (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to capture your input. 
    A first question = that arises: can we give a definition to AS-RO?

    Thanks
    Fabien

    On Tue, Mar = 23, 2021 at 4:15 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi = Alan, 

    Yes, but = in that flow, the token relationship between AS-RS and AS-RO is only = secure if the tokens issued by AS-RS are cryptographically attenuable in = the first place. 
     
    Attenuated delegation is a requirement, but that doesn't have = to be done cryptographically.  Token exchange works just = fine.  SPKI and zcap-ld are examples of the crypto approach, and we = used token exchange in the system for HP.

    --------------
    Alan = Karp


    On Tue, Mar = 23, 2021 at 4:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi = Alan, 

    Yes, but = in that flow, the token relationship between AS-RS and AS-RO is only = secure if the tokens issued by AS-RS are cryptographically attenuable in = the first place. 

    Fabien

    On Mon, Mar = 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin = Richer <jricher@mit.edu> wrote:

    But with all that in mind, I think the = key here is going to be looking at what the inputs to the AS are, and = how those can be defined in an interoperable way for AS=E2=80=99s that = can accept them. I think there=E2=80=99s a lot of room for innovation = and flexibility here that doesn=E2=80=99t break the trust model or core = use cases. If I have an AS-RS set that won=E2=80=99t accept my favorite = flavor of policy engine inputs, then I can decide not to use that one. = But this is a very different question than saying the RS itself needs to = accept my own AS =E2=80=94 and we can=E2=80=99t keep conflating these = two models.

    I agree.  The = point of having an AS-RO is to allow RO to specify a policy for which of = RO's access tokens should be delegated under what conditions.  = AS-RS should not need to understand those policies.  The flow would = be
    • RO contacts AS-RS = and gets one or more access tokens.
    • RO delegates one = or more of those tokens, potentially sub-scoped, to AS-RO.
    • A different user contacts AS-RO to get a potentially = sub-scoped access token from AS-RO.
    • That user = presents the access token delegated by AS-RO when invoking the = resource.
    AS-RS only = needs to verify that the delegation chain is legitimate, e.g., no = increase in scope, and that it grants permission for the request being = made.  AS-RS does not need to understand the policy behind granting = the delegation by AS-RO.

    --------------
    Alan Karp


    On Mon, Mar 22, 2021 at 11:40 AM Justin = Richer <jricher@mit.edu> wrote:
    Adrian,

    I think this shows the problem with the = terminology as it=E2=80=99s been applied in this conversation, which = I=E2=80=99ve tried to shine light on before. What you and others are = calling the =E2=80=9CRS=E2=80=9D is really the =E2=80=9CAS and RS = working together=E2=80=9D =E2=80=94 everything to the right of the line. = When Denis had brought up =E2=80=9Celiminating the AS=E2=80=9D in = another thread, what he=E2=80=99d really done is labeled everything to = the right of the line as the =E2=80=9CRS=E2=80=9D. Of course, the irony = here is that everything to the right of the line used all be called the = =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 = days. As you say below, I don=E2=80=99t want the client to have = visibility on what happens on that side. 

    Note well: The Google+ logo labeled = =E2=80=9CIdP=E2=80=9D in the diagram is not the AS, as far as GNAP is = concerned. It does not issue an access token that the RS will accept. = The elements to the left of the line could be a lot of things, but they = are NOT the AS =E2=80=94 by definition. The client lives over on the = left, but so do any external inputs to the AS. These could be policy = inputs on behalf of the RO, they could be presentation artifacts, they = could be federated logins, they could be the output of policy decisions. = How the AS comes to trust those things is up to the AS=E2=80=99s = implementation. It=E2=80=99s something we can talk about, but ultimately = GNAP won=E2=80=99t be in any position to dictate because in practice = some AS=E2=80=99s are simply going to internalize all policies and we = will never successfully force those open. 

    But with all that in mind, I think the = key here is going to be looking at what the inputs to the AS are, and = how those can be defined in an interoperable way for AS=E2=80=99s that = can accept them. I think there=E2=80=99s a lot of room for innovation = and flexibility here that doesn=E2=80=99t break the trust model or core = use cases. If I have an AS-RS set that won=E2=80=99t accept my favorite = flavor of policy engine inputs, then I can decide not to use that one. = But this is a very different question than saying the RS itself needs to = accept my own AS =E2=80=94 and we can=E2=80=99t keep conflating these = two models.

    So = to me, GNAP can support a Zero Trust Architecture by LEVERAGING the AS, = not by subsuming or eliminating it. It is in fact the AS, not the client = and not the RS, that will request and consume the results of a = privacy-preserving zero-trust policy query thing. Anything that happens = downstream from that is of little concern to the zero-trust components = because, as you point out, it=E2=80=99s on the =E2=80=9Cother side=E2=80=9D= of the line. 

    I think we got this basic component model pretty right in = OAuth: the AS and RS and client working together. Where OAuth misses the = mark is the assumption that the user has to log in to the AS through a = webpage and interact directly, thereby proving they=E2=80=99re the RO. = It=E2=80=99s this latter space where I think we can both push innovation = and also address the important and compelling use cases like the ones = you=E2=80=99re bringing.

     =E2=80=94 Justin

    On Mar = 22, 2021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I'm sorry, Justin. As a Resource = Owner, I look at the RS trust boundary (the dotted line in the diagram) = as being the RS. I don't expect any visibility into what's going on on = the right. 

    My problem with the framing you propose is that requests are = going to the RS (or the AS-RS) and I don't want to share my policies = with the AS-RS. I want to keep the RS and AS-RS as ignorant as = possible.

    Adrian

    On Mon, Mar = 22, 2021 at 1:48 PM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    What you=E2=80=99re discussing below, = in terms of logging in to a site, is not approaching the RS. You are in = fact approaching the client, and identifying both the AS and RS to the = client. The client is a client of your identity in = this model, and the RS is part of the identity provider. It=E2=80=99s = really important that we don=E2=80=99t conflate the RS and client in = this way as it leads to a lot of confusion downstream and a lot of = broken trust boundaries.

    With that model in mind, approaching the =E2=80=9CRS" and = providing it your identity is really just a case of the =E2=80=9Cfederated= login to AS=E2=80=9D pattern that we discussed on the WG call. The user = here approaches an RS, which has its own AS. To share things from this = RS, the RO has to authenticate to the RS=E2=80=99s AS. This particular = AS allows the RO to do so using an external identity =E2=80=94 in which = case, the AS is now a =E2=80=9Cclient=E2=80=9D of a separate, = disconnected (but layered) delegation. The ultimate client that = eventually calls the RS down the way may or may not know about these = layers. 

    <PastedGraphic-1.png>
    This = same AS, which is closely tied to the RS and trusted by the RS, might = also take in FIDO credentials, or DIDs, or any number of other proof = mechanisms. The output of this is an access token the RS trusts, but the = input is up to the AS. The RS is not what you=E2=80=99re logging in = to.

     =E2=80= =94 Justin

    On Mar 22, 2021, at 1:28 PM, = Adrian Gropper <agropper@healthurl.com> = wrote:

    I = too am in favor of avoiding consolidation and correlation. Right now, = when I approach a service provider (RS) for the first time, I'm offered = the opportunity to identify my persona as: email, sign-in with Google, = Facebook, or Apple. I know there are people who try to create one-off = email addresses but that is mostly a waste of time. 

    So, along come FIDO2 and = DID wallets to the rescue. Now, in theory, I have a way to start out my = RS relationship pseudonymously. 

    When I want my resource to be = discovered or shared I will post that RS URL including my pseudonym. If = I then want to introduce a mediator in front of my AS or messaging = service endpoint, I have that option. If I want to keep requests = away from the mediator, I would publish an encryption key along with my = pseudonym.

    - = Adrian



    On Mon, Mar 22, 2021 at 9:55 AM Justin = Richer <jricher@mit.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin = Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhkarp@gmail.com> shared a talk = about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#i= ssuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to = use authority
    >> as a core principle. I advocate for a GNAP design that = maximizes the power
    >> of the RO, to be seen as a human rights issue when the RO is a = human. This
    >> causes me to ask how to combine better security with better = human rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the = RO to
    >> partition limited authority across dozens of different ASs by = domain and
    >> function, then we are not using technology to empower the = individual.
    >> Probably the opposite, as we introduce consent fatigue and = burden normal
    >> people to partition their lives into non-overlapping = domains.
    >>
    >> My experience says we should aim for one AS per persona because = that maps
    >> into the way we manage our public and private identities. POLA = would then
    >> teach care in keeping ASs and RSs related to work / public = separate from
    >> ASs and RSs related to private life so that a policy = vulnerability in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to = GNAP
    > seems like a useful exercise.  I do want to point out some = potential
    > pitfalls with one-AS-per-persona that we can also be aware = of.  If
    > one-AS-per-persona becomes one-persona-per-AS as well, then the = AS's
    > identity in effect also serves as a persona identity and there are = privacy
    > considerations to that.  If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple = humans)
    > route is taken, we should consider whether that would lead to = various
    > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.  That topic is a current matter of = concern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in = the UMA working group, and it=E2=80=99s one of the biggest problems with = the personal AS (and personal data store) model. This kind of thing = makes RS-first trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that = wants to access my medical information. It calls an RS and requests = access, but it hasn=E2=80=99t been granted anything yet. Now I as the RO = have set up the RS so that it talks to my personal AS, that only I use. = In addition to the RS having to be able to figure out which medical = records are being requested from the context of the unauthenticated = request (which means it needs identifiers in the URL or something = similar for the RS to be able to tell, assuming that it protects data = for more than one person). So this client software doesn=E2=80=99t know = who I am and doesn=E2=80=99t know my medical record information, makes a = completely unauthorized request to the RS, and the RS says =E2=80=9CGo = to Justin=E2=80=99s personal AS to get a token=E2=80=9D. The client can = now make a direct correlation between the data that=E2=80=99s being = protected at the RS and the person running the AS that protects it. = Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This = is a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please = talk to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t = exposed anything at all. And from the perspective of both the patient = and the RS, this is more privacy-preserving, and it=E2=80=99s really the = least surprising option. Once the client gets to the AS, it can start a = negotiation of figuring out who the RO is for the information being = accessed.

    On top of this, the usability expectations of people managing their own = AS, or set of AS=E2=80=99s for multiple personas to keep things = separate, is a huge burden. Even in the tech community, I know people = who can=E2=80=99t reliably manage more than one email address for = different purposes. I wouldn=E2=80=99t expect my partner to do that =E2=80= =94 they have trouble enough balancing all the logins and sessions = required for different kids remote schooling, I couldn=E2=80=99t imagine = them having to understand all the requirements for managing multiple = authorization servers and associated policies. I also don=E2=80=99t = expect any person to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve = been on the internet for decades and I can barely keep tabs on my GPG = keys, and only use them when I am forced to. This is exactly the kind of = =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions above, = people will just want to outsource that to someone else, and the reality = will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice = only to end up with a world where the RS ends up making a limited choice = anyway. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99= s could allow arbitrary IdPs but they choose Google because it works and = that=E2=80=99s where the users are. (And that=E2=80=99s not to say = anything of the proprietary OIDC-like protocols, but that=E2=80=99s = another discussion).

    For further reading on these topics, I recommend both =E2=80=9CWhy = Johnny Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems = Fail=E2=80=9D.

    So what does this have to do with GNAP? I think we can be clear-eyed on = what kinds of expectations we have for the participants. If we expect = users (RO=E2=80=99s) to have to set up the AS-RS relationship, or expect = them to carry their AS, or manage their personal keys =E2=80=94 I think = we=E2=80=99ve lost the battle for relevance.

     =E2=80=94 Justin


    --
    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
    =


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


    = --Apple-Mail=_2CD10F34-603C-46EA-8B31-3AB416215010-- From nobody Fri Mar 26 07:04:57 2021 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 E0FC33A1F4A for ; Fri, 26 Mar 2021 07:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 yI6oWTKJc9b6 for ; Fri, 26 Mar 2021 07:04:49 -0700 (PDT) Received: from mail-vs1-f42.google.com (mail-vs1-f42.google.com [209.85.217.42]) (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 3AFA93A197D for ; Fri, 26 Mar 2021 07:04:49 -0700 (PDT) Received: by mail-vs1-f42.google.com with SMTP id a15so2761473vsi.0 for ; Fri, 26 Mar 2021 07:04:49 -0700 (PDT) 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=AXeRlUtEKYu5hYFrtIJ8LTs/BQIYkQLznVZyYcghn+M=; b=Jrr+6Mbso1u8YYg7FS08p9VQ/YfW4ZWmLOLgAytvQDigjGrJw6tAVuw7VSLfAuOUBC AdsiT37BhmdE6EjFK2z52OJfhw6f1GOKKvfziriFaU1H/wm478GClh0cIekB5dqMPMh5 OmD5B2ImUa6It+I85FyUcQTuoG3AldcCHHF9r6rQQ6VE3t+hBRVpffwotV4EY3l+mWXZ wayr4HKyh7+NxlLgSHGXBHCAMwhOLSDO1WpBI1jMqDQg6piUQSWpMkfw+UE/a+FDVKOw EPndxJ79wHo+uV+LbqcRN99Qu4cfvlrYOKfMyUCM3DFZUcfT7gbxsT21ZzDR+ciCPWsI riPw== X-Gm-Message-State: AOAM53289FVcaudvKPrtuFSelAwnNuo3LtL9wBUYlcEybFlTFbH60bvF f7QGszoMZET9wEciR+Iz4z3k+AGqpTRxoqQInP4= X-Google-Smtp-Source: ABdhPJzDaf4qqHMzC3AV0woCjo5Gpni/GXNJ2xKipRluf4MlXw/yWX7cP0nJkFXJyjMyjXP5/HRp5ZsH0Sasl1Ho7eg= X-Received: by 2002:a05:6102:24a:: with SMTP id a10mr8425718vsq.39.1616767487418; Fri, 26 Mar 2021 07:04:47 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> <5773FA7B-6891-4227-A8CA-2F506909B8CD@mit.edu> In-Reply-To: From: Adrian Gropper Date: Fri, 26 Mar 2021 10:04:34 -0400 Message-ID: To: Justin Richer Cc: Alan Karp , Benjamin Kaduk , Fabien Imbault , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="000000000000c5a5a205be7103dd" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2021 14:04:56 -0000 --000000000000c5a5a205be7103dd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Justin, Big YES to =E2=80=9C The conceptual framework of an AS that takes in lots o= f different information and spits out access tokens is exactly the abstraction layer that is necessary for making these use cases interoperable.=E2=80=9D and probably everything else you just said. I seem to not understand the delegation design between RS and AS. In my view, that delegation always goes through the RO, although the RO may be forced to choose from a list provided by the RS. In my view, GNAP, can acknowledge this and design to be agnostic to whether the AS is specified by he RO or picked from a list of 1 or more choices provided by the RS. - Adrian On Fri, Mar 26, 2021 at 9:30 AM Justin Richer wrote: > Adrian, > > I disagree, I believe that what I have laid out is exactly separating the > concerns into working components. > > Like OAuth before it, GNAP is a protocol negotiate access for a client > instance to an RS, using an AS as the facilitator of that delegated > negotiation. (Unlike OAuth, it=E2=80=99s importantly also for negotiating= user > information to the client directly from the AS with no RS involved, but > that=E2=80=99s an aside for the purposes of our conversation here). > > If a particular GNAP RS also allows other kinds of processes to enable > access to it, that is completely fine, but outside of GNAP. If an RS allo= ws > a username/password HTTP Basic auth in addition to accepting access token= s, > it can do so, but GNAP doesn=E2=80=99t have anything to say about the Bas= ic auth > use, or even its relation to any access tokens or RO=E2=80=99s or anythin= g else. If > an RS accepts structured access tokens signed by trusted keys that don=E2= =80=99t > come from an AS through a negotiated request =E2=80=94 again, that=E2=80= =99s fine, but GNAP > is silent about the RS doing that. If the RS acts as =E2=80=9Cits own AS= =E2=80=9D then it=E2=80=99s > really just an RS and an AS living in the same box. Again, that=E2=80=99s= fine, and > super common with OAuth today. > > GNAP is solving the problem of connecting the client to the RS through > means of an AS. Other solutions are possible and many of them can be > deployed right alongside, but that=E2=80=99s not the corner of the world = that GNAP > is solving. GNAP should be concerned about how these other technologies c= an > be used alongside it. I think there=E2=80=99s a lot of room for the thing= s that > you=E2=80=99re talking about, and more importantly for solving the use ca= ses that > you=E2=80=99re bringing. But GNAP should be more than a single-point solu= tion, and > so we need to balance these concerns. The conceptual framework of an AS > that takes in lots of different information and spits out access tokens i= s > exactly the abstraction layer that is necessary for making these use case= s > interoperable. > > =E2=80=94 Justin > > On Mar 26, 2021, at 8:30 AM, Adrian Gropper > wrote: > > @Justin, there=E2=80=99s no separation of concerns here. No partition bet= ween > processor and controller. No data minimization. And, I see no obvious > reason to make this the core of GNAP. > > The one thing we can probably all agree on is that there=E2=80=99s only o= ne RS and > one RO. > > The core of GNAP, in my opinion, can be built and explained around this > simple design. The RS is a processor. The RO is a controller. The RS bear= s > only security responsibility. The RS bears no privacy responsibility. The > RO delegates this to the RS but this is not authorization as the A in GNA= P. > > The RO retains all rights to delegate within the scope of things that the > RS is willing to support using various token formats and endpoint options= . > Some of these options may do all sorts of things for all sorts of clients > and user-agents but these are options. > > For example, if a request comes to the RS that is not in the form of an > access token, then it either gets sent to the RO or their agent, or it ge= ts > logged and dumped. One such option, common in healthcare, is =E2=80=9CBre= ak the > Glass=E2=80=9D where the RS is acting as an authorization server because = the > user-agent is making a request instead of presenting an access token. GNA= P > can offer this as an option but it is not our core. > > Adrian > > > > On Fri, Mar 26, 2021 at 7:15 AM Justin Richer wrote: > >> I have a big problem with this line: >> >> > the RS and AS-RS only see access tokens. The requests (from RO') that >> resulted in an access token are none of their business. >> >> In the trust model we=E2=80=99ve been discussing, the requests that resu= lt in >> access tokens are *solely the business of AS-RS*, since AS-RS is the >> only entity that=E2=80=99s allowed, and trusted by the RS, to create acc= ess tokens >> for the RS. That is its entire job, the entire reason it exists in the >> system. By definition the party generating tokens for use at the RS is t= he >> AS for that RS, I don=E2=80=99t care how you deploy it. If RO wants to g= ive access >> to someone else (who isn=E2=80=99t an =E2=80=9CRO" anymore, they=E2=80= =99re another end-user), then >> that end user=E2=80=99s client software will need to talk to AS-RS to ge= t its own >> access token. >> >> Now here=E2=80=99s the trick: when the end user=E2=80=99s client instanc= e talks to AS-RS, >> that does NOT mean that AS-RS needs to know all the details and policy >> reasons that it should give an access token to that client instance. It >> doesn=E2=80=99t even need to know the existence of another end user. It = doesn=E2=80=99t >> need identity, it doesn=E2=80=99t need policy. Sure, it COULD handle all= of that >> internally, and many will, but the protocol doesn=E2=80=99t demand it. >> >> This means that the first client instance, the one that gets the access >> token, can also be given something alongside the access token that it ca= n >> then hand to another piece of software (or to a person to hand eo their >> piece of software). This artifact is not an access token. This artifact >> could be something structured that the client understands, and can make >> derivatives of, and present back to the AS-RS for getting new access >> tokens. There could be multiple different flavors of this kind of artifa= ct >> for different kinds of environments and groups. But what they all have i= n >> common is that they can potentially be used to request more access token= s >> within some context at the AS-RS. >> >> =E2=80=94 Justin >> >> >> >> On Mar 25, 2021, at 5:50 PM, Adrian Gropper >> wrote: >> >> My issue is with Alan's: >> >> "7. Another user agent (RO') can contact any holder of the access token >> or the service's policy agent (AS-RS) to get a delegated access token." >> >> >> I would prefer "7A. Another user agent (RO') can contact any holder of >> the access token." by default so that the AS-RS does not see the request= s. >> In other words, the RS and AS-RS only see access tokens. The requests (f= rom >> RO') that resulted in an access token are none of their business. >> >> The reality is that RO' can discover a resource RS and can share whateve= r >> information with RS-AS they want and the RO may not even know about it >> unless the RS decides to let them know somehow. This seems to be a drawb= ack >> of the capabilities approach. >> >> In terms of privacy and control, I, as the RO, want a contract with the >> RS that says that I or my agent (AS-RO) must sign an access token. This = is >> a fundamental audit requirement. Without it, a rogue RS and AS-RS can do >> all sorts of things and the RO would never know. I understand that a rog= ue >> RS might not support an honest contemporaneous log of access tokens >> presented so there's a trust issue here that I seems unavoidable unless = I >> specify in my RO-RS contract that they use a separate contemporaneous lo= g >> such as AS-RO for every access token presented and risk being sued if th= ey >> process an access token without also updating the separate log. >> >> - Adrian >> >> >> On Thu, Mar 25, 2021 at 1:22 PM Alan Karp wrote: >> >>> Justin Richer wrote: >>> >>>> Hi Alan, >>>> >>>> In all of my discussion, and in the spec itself, the RO is the :entity= : >>>> in charge of approving rights. They=E2=80=99re probably a person. It m= ight be >>>> software that makes a policy decision in some way, or a corporate enti= ty, >>>> or something like that. But it=E2=80=99s not assumed to be a computati= onal agent in >>>> the terms of the protocol itself. Would that recast what you=E2=80=99r= e saying >>>> below? >>>> >>> >>> Hmmm. I guess not. It's just that the person would be using some UI t= o >>> express their decisions to what I called the user agent. That model fi= ts >>> in very nicely with what we did with Polaris, our virus safe computing >>> environment for Windows XP, >>> https://dl.acm.org/doi/10.1145/1151030.1151033. The person would click >>> on the icon for a Word file, and an instance of Word would open with on= ly >>> the permission needed to edit that one file. Same thing here. The cli= ent >>> could ask for permission to use the resource, or permission could be >>> granted implicitly when the user selects a resource associated with a >>> specific client. >>> >>> -------------- >>> Alan Karp >>> >>> >>> On Thu, Mar 25, 2021 at 9:53 AM Justin Richer wrote: >>> >>>> Hi Alan, >>>> >>>> In all of my discussion, and in the spec itself, the RO is the :entity= : >>>> in charge of approving rights. They=E2=80=99re probably a person. It m= ight be >>>> software that makes a policy decision in some way, or a corporate enti= ty, >>>> or something like that. But it=E2=80=99s not assumed to be a computati= onal agent in >>>> the terms of the protocol itself. Would that recast what you=E2=80=99r= e saying >>>> below? >>>> >>>> =E2=80=94 Justin >>>> >>>> On Mar 25, 2021, at 12:36 PM, Alan Karp wrote: >>>> >>>> There seems to be some confusion about how AS-RO comes into the >>>> picture, probably because of the "AS" part. I'm going to try to clear= up >>>> that confusion by more carefully explaining what I mean. >>>> >>>> I'm assuming that RO is a computational agent representing the person >>>> who is the resource owner, something called the "user agent" in operat= ing >>>> systems lingo. I'm also assuming that it's possible to do delegation, >>>> either locally or by token exchange with AS-RS. All delegations are >>>> potentially sub-scoped, but you may also want to delegate with full sc= ope >>>> to have a separately revocable access token. >>>> >>>> Here's an example of how things work in a capability oriented system= . >>>> >>>> 1. Someone, the service owner, creates a service. >>>> 2. The service owner contracts with an policy agent (AS-RS) to >>>> create and manage access tokens for that service (RS). >>>> 3. A person wishing to create a resource at RS uses their user >>>> agent (RO) to contact the service owner's policy agent (AS-RS) and = gets >>>> back an access token for that resource. >>>> 4. That user agent (RO) can >>>> 1. use that access token to invoke the resource, or >>>> 2. delegate an access token to a client of the user agent's (RO) >>>> choice, or >>>> 3. contract with a policy agent (AS-RO) to manage those >>>> delegations on behalf of the user agent (RO), or >>>> 4. specify a policy with the service's policy agent (AS-RS). >>>> 5. A client can contact any holder of the access token (the user >>>> agent (RO) or its policy agent (AS-RO)) or the service's policy age= nt >>>> (AS-RS) to get a delegated access token. >>>> 6. That client can delegate that token to another client. >>>> 7. Another user agent (RO') can contact any holder of the access >>>> token or the service's policy agent (AS-RS) to get a delegated acce= ss token. >>>> 8. The other user agent (RO') can >>>> 1. use that access token to invoke the resource, or >>>> 2. delegate it to a client of its choice, or >>>> 3. contract with a policy agent (AS-RO') of its choosing to >>>> manage those delegations on its behalf, or >>>> 4. specify a policy with the service's policy agent (AS-RS). >>>> 9. and so on >>>> >>>> When any of these computational agents, user agents (ROs) or clients >>>> acting on their behalf, invokes the resource, AS-RS verifies that the >>>> access token is a valid delegation, i.e., proper sub-scoping, hasn't b= een >>>> revoked, and that it authorizes the request being made before telling = the >>>> service (RS) to honor the request. At no point does the service's pol= icy >>>> agent (AS-RS) know which computational agent did any particular >>>> delegation. (Token exchange can be done as anonymously as possible.) = In >>>> particular, the policy agents (AS-RO) need not be the same, or even >>>> compatible with, the service's policy agent (AS-RS). GNAP specifies t= he >>>> protocol between requesters, invokers, delegators (for token exchange)= of >>>> tokens and AS-RS. That protocol need not be used between user agents = (RO), >>>> clients, or other policy agents (AS-RO), but it is likely to be. >>>> >>>> ------------- >>>> Alan Karp >>>> >>>> >>>> On Thu, Mar 25, 2021 at 5:45 AM Justin Richer wrote: >>>> >>>>> The way I=E2=80=99m thinking about Adrian=E2=80=99s use case is that = what we=E2=80=99re >>>>> calling the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an =E2=80=9CAS=E2= =80=9D in the traditional OAuth/GNAP sense, at >>>>> least not exactly. This is the agent that the RO can use to set polic= ies >>>>> and manage consent on their behalf, and I=E2=80=99ve been arguing tha= t it fits >>>>> better into this vaguely-defined =E2=80=9Cinteraction component=E2=80= =9D aspect of the >>>>> current AS definition, and it=E2=80=99s not currently separated from = the AS >>>>> definition. The =E2=80=9CAS-RS=E2=80=9D maps to what we=E2=80=99d cal= l the =E2=80=9CAS=E2=80=9D in OAuth/GNAP >>>>> traditionally, it=E2=80=99s what the RS trusts to issue tokens. In tr= aditional >>>>> OAuth the AS-RO and AS-RS are always the same thing, from a functiona= l >>>>> protocol perspective. An important point here is that from a client= =E2=80=99s >>>>> perspective, they=E2=80=99re only talking to the AS-RS since that=E2= =80=99s where the >>>>> client gets its tokens, because at the end of the day the client just= wants >>>>> to call the API at the RS and doesn=E2=80=99t care how that happens (= from a >>>>> protocol standpoint). >>>>> >>>>> Note well: Even thought I don=E2=80=99t believe that =E2=80=9CAS-RO= =E2=80=9D is an >>>>> authorization server at all, I=E2=80=99m going to keep using that ter= m below for >>>>> consistency with previous discussion. >>>>> >>>>> So we have these fundamental relationships around getting the client >>>>> to access the RS: >>>>> >>>>> 1. RS trusts AS-RS to issue tokens that RS will accept, validate, and >>>>> process for requests from client >>>>> 2. Client trusts AS-RS to issue tokens that client can use at RS >>>>> 3. RO trusts RS to protect RO=E2=80=99s api through delegated access >>>>> >>>>> On top of that, we=E2=80=99ve got some additional aspects that we=E2= =80=99re >>>>> discussing: >>>>> >>>>> 4. RO trusts AS-RO to manage RO=E2=80=99s policies at runtime >>>>> 5. AS-RS trusts AS-RO to assert RO=E2=80=99s policies for access to R= S >>>>> 6. Client trusts whatever AS-RS sends client to deal with, including >>>>> possibly RO-AS at runtime, because of (2) >>>>> >>>>> What I have been saying is that 4/5/6 are optional details of how >>>>> RS-AS runs things, and I think this also maps with Adrian=E2=80=99s v= iew of choice, >>>>> since if my RS=E2=80=99s AS-RS doesn=E2=80=99t allow me to plug in my= own AS-RO then I >>>>> would be motivated to pick a different RS who=E2=80=99s AS-RS lets me= do just that. >>>>> The same way I=E2=80=99d pick a different RS if their surrounding ser= vices didn=E2=80=99t >>>>> accept my preferred federation login and I didn=E2=80=99t want to mak= e another >>>>> account. Of course, market forces being as they are, I might not have= much >>>>> of an actionable choice in RS, but GNAP can=E2=80=99t change that. >>>>> >>>>> What we can do is make it possible for AS-RS to talk to AS-RO, both i= n >>>>> philosophy of the protocol design and in concrete hooks to support (6= ) >>>>> above. >>>>> >>>>> Separately, we can approach the issue of making 1/2 above more >>>>> dynamic. This was UMA2=E2=80=99s =E2=80=9Cfederated authorization=E2= =80=9D approach, and is behind >>>>> a lot of the =E2=80=9Cbring your own AS=E2=80=9D models out there. Th= e problem with these >>>>> is that we know from many years of experience that most RS=E2=80=99s = aren=E2=80=99t >>>>> interested in doing anything of the sort. >>>>> >>>>> So with GNAP we can instead allow 4/5/6 to vary in a predictable and >>>>> consistent way, letting the RS keep control over 1/2, thereby enablin= g >>>>> choice in (3). We don=E2=80=99t have to be the ones who define the al= l of the >>>>> details of every permutation of (5) to enable this, though. Some of t= his is >>>>> going to be configuration out of band, some of it=E2=80=99s going to = be >>>>> communication at runtime. This is where VC=E2=80=99s, ZCAPs, CHAPI, D= IDComm, FIDO, >>>>> and a whole swath of other tech can come in and help out. I don=E2=80= =99t think we >>>>> need to put all the details for using these into core, nor do I think= we=E2=80=99ll >>>>> pull of The Great And Ultimate Abstraction for using these and other >>>>> approaches. But we can at least start talking about =E2=80=9CAS-RS=E2= =80=9D in such a way >>>>> that it no longer assumes it=E2=80=99s always the same party dealing = with the RO >>>>> directly. >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Mar 25, 2021, at 6:40 AM, Fabien Imbault >>>>> wrote: >>>>> >>>>> To reframe it closer to GNAP: >>>>> - AS =3D AS-RO, that's where you find the RO policies. The AS issues >>>>> access tokens to the client. >>>>> - the RO policies could be a) defined locally or b) in relationship >>>>> with the RS >>>>> >>>>> There have been several ideas related to the AS-RS relationship b: >>>>> b1) the RS issues capabilities (which can be further attenuated by th= e >>>>> RO) >>>>> b2) Adrian also discussed a DID based solution >>>>> b3) there was also an alternative ACL proposal from Denis (+ prefligh= t) >>>>> >>>>> Fabien >>>>> >>>>> >>>>> On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Ok so I get you correctly: >>>>>> - what matters is the RQ (could be a RO or a end-user or both : we >>>>>> don't really care at a high-level, they're all treated as entities t= hat >>>>>> make a request) >>>>>> - the policy is able to handle those different cases, based on its >>>>>> own internal delegation protocol >>>>>> - currently that requires AS-RS and AS-RO, but maybe it can be >>>>>> simplified >>>>>> >>>>>> To answer to Denis, here's what I understood: >>>>>> - RO trusts AS-RS (and then handles its own policies within AS-RO) >>>>>> - end-user trusts AS-RO (through its client) >>>>>> >>>>>> Could probably work but that's a fairly different model compared to >>>>>> OAuth2 (and of today's GNAP), with different frontiers between the A= S and >>>>>> the RS. >>>>>> >>>>>> Please do not hesitate to correct me if I'm wrong. >>>>>> >>>>>> Fabien >>>>>> >>>>>> On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper < >>>>>> agropper@healthurl.com> wrote: >>>>>> >>>>>>> I believe there are alternatives to having two kinds of ASs. The >>>>>>> problem may be a side-effect of deciding to switch away form treati= ng the >>>>>>> RO as different from the RQ. That leads to downstream privacy issue= s. Our >>>>>>> desire for architectural simplicity is admirable but that may have = been a >>>>>>> step too far. >>>>>>> >>>>>>> There may also be solutions based on different types of tokens, as >>>>>>> in different capabilities (tokens signed by the RS) vs. tokens sign= ed by >>>>>>> the AS. I=E2=80=99m not sure about that but Alan might have more to= say. >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>> On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>> >>>>>>>> Thanks. The general problem statement is clear. >>>>>>>> >>>>>>>> The proposed solution a bit less (to me). I understood that from >>>>>>>> point 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obvio= us >>>>>>>> reason to have two types of ASs". Do you see an alternative ? >>>>>>>> >>>>>>>> Regarding the last item, I don't think that naming RQ by end-user >>>>>>>> created the problem. It might just highlight the asymmetry, which >>>>>>>> fundamentally exists. >>>>>>>> >>>>>>>> Fabien >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper < >>>>>>>> agropper@healthurl.com> wrote: >>>>>>>> >>>>>>>>> Recap: >>>>>>>>> 1 - Justin (I think) introduced the idea of an AS on the RS trust >>>>>>>>> boundary side. >>>>>>>>> 2 - I said the RO should not have to share policies with the RS. >>>>>>>>> 3 - Alan invented the concept of AS-RO and AS-RS to separate two >>>>>>>>> kinds of PDPs. >>>>>>>>> >>>>>>>>> The thing is that step 2 is not symmetrical. The RO has a >>>>>>>>> legitimate privacy interest in keeping their policies private and >>>>>>>>> minimizing the leakage of information about requests that are pos= ed against >>>>>>>>> those policies. >>>>>>>>> >>>>>>>>> The RS, on the other hand, should be publishing its policies (e.g= . >>>>>>>>> what it=E2=80=99s selling or what jurisdiction it=E2=80=99s in or= what tokens or scopes it >>>>>>>>> supports). The RS has no obvious privacy interest in GNAP. It=E2= =80=99s just an >>>>>>>>> enforcer. >>>>>>>>> >>>>>>>>> There is one other privacy interest to consider around the RS and >>>>>>>>> that is the requesting party (the end-user that is not the RO :-)= might >>>>>>>>> prefer to share attributes with the RS instead of the RO or somet= hing >>>>>>>>> controlled by the RO. This case could be an =E2=80=9Cextension=E2= =80=9D to GNAP and might >>>>>>>>> result in a split AS as a solution. This problem was introduced w= hen the >>>>>>>>> editors decided to replace RQ with end-user. Obviously, the RO en= d-user has >>>>>>>>> no privacy interests relative to itself. >>>>>>>>> >>>>>>>>> Adrian >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault < >>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> I was referring to "By my definition, this model has two ASs >>>>>>>>>> since both are processing requests into tokens". If there's no r= eason to >>>>>>>>>> have 2 types of ASs, that's fine then. >>>>>>>>>> But I'm a bit lost in where we stand with the idea. >>>>>>>>>> >>>>>>>>>> Could you recap? >>>>>>>>>> >>>>>>>>>> Fabien >>>>>>>>>> >>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper < >>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>> >>>>>>>>>>> There=E2=80=99s no obvious reason to have two types of ASs. Any= AS that >>>>>>>>>>> is executing the policies of the RS can look to GNAP like the R= S itself. >>>>>>>>>>> Why would GNAP expose that interface to anyone? >>>>>>>>>>> >>>>>>>>>>> Adrian >>>>>>>>>>> >>>>>>>>>>> On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault < >>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Note : I'm not sure that's a good idea, but having 2 types of >>>>>>>>>>>> ASs is not that easy to grasp. >>>>>>>>>>>> >>>>>>>>>>>> Fabien >>>>>>>>>>>> >>>>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault < >>>>>>>>>>>> fabien.imbault@gmail.com> a =C3=A9crit : >>>>>>>>>>>> >>>>>>>>>>>>> The purpose of either handling policies locally or delegating >>>>>>>>>>>>> them to the RO agent. >>>>>>>>>>>>> >>>>>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper < >>>>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>>>> >>>>>>>>>>>>>> What purpose would be served by GNAP splitting the AS into >>>>>>>>>>>>>> two components? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault < >>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Isn't the AS-RO a component of the AS? Same idea as the >>>>>>>>>>>>>>> interact component, it functionnally belongs to the AS role= but could be >>>>>>>>>>>>>>> deployed either as a monolith or as a separate component? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper < >>>>>>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yes, but I would say it=E2=80=99s not the RO that wants th= e access >>>>>>>>>>>>>>>> token. It=E2=80=99s the RO that wants the client making th= e request to get an >>>>>>>>>>>>>>>> access token. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 11:22 PM Alan Karp < >>>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Adrian Gropper wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> In this design, the AS is the AS-RS and the agent is the >>>>>>>>>>>>>>>>>> AS-RO. By my definition, this model has two ASs since bo= th are processing >>>>>>>>>>>>>>>>>> requests into tokens. The problem with this is complexit= y and privacy. The >>>>>>>>>>>>>>>>>> RO may not want to share the request information with th= e AS-RS. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> More precisely, RO has no choice but to present the >>>>>>>>>>>>>>>>> required information to AS-RS if RO wants an access token= . However, RO >>>>>>>>>>>>>>>>> does not want AS-RS to know the policy by which RO delega= tes tokens. >>>>>>>>>>>>>>>>> That's why RO uses AS-RO for those delegations. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper < >>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thank you for creating the issue. My definition of AS is >>>>>>>>>>>>>>>>>> independent of AS-RO or AS-RS. >>>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issue= s/223#issuecomment-806280421 >>>>>>>>>>>>>>>>>> I also agree with Alan's definition based on delegation.= An AS-RS would be >>>>>>>>>>>>>>>>>> a delegate of the RS. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Based on that, I see it as obvious that the policy has t= o >>>>>>>>>>>>>>>>>> be accessible (defined locally?) in order for it to be r= un as the code that >>>>>>>>>>>>>>>>>> turns a request into an access token. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The only other possibility is that the request is >>>>>>>>>>>>>>>>>> packaged by the AS and sent elsewhere (an agent) for eva= luation against >>>>>>>>>>>>>>>>>> policy and a proto-token returned. In that case the AS i= s acting as a proxy >>>>>>>>>>>>>>>>>> and the PDP is elsewhere. I can imagine that an AS-RS wo= uld behave this way >>>>>>>>>>>>>>>>>> so that the proto-token could be turned into an access t= oken by the AS-RS. >>>>>>>>>>>>>>>>>> Isn't this what Justin is proposing? In this design, the= AS is the AS-RS >>>>>>>>>>>>>>>>>> and the agent is the AS-RO. By my definition, this model= has two ASs since >>>>>>>>>>>>>>>>>> both are processing requests into tokens. The problem wi= th this is >>>>>>>>>>>>>>>>>> complexity and privacy. The RO may not want to share the= request >>>>>>>>>>>>>>>>>> information with the AS-RS. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault < >>>>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Isn't that what the AS is supposed to be, only with the >>>>>>>>>>>>>>>>>>> caveat that the policy is defined locally? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp < >>>>>>>>>>>>>>>>>>> alanhkarp@gmail.com> a =C3=A9crit : >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> AS-RO is an AS that RO trusts to delegate RO's access >>>>>>>>>>>>>>>>>>>> tokens according to RO's policies. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault < >>>>>>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hi Alan and Adrian, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I've created issue AS-RO policy delegation ( >>>>>>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/is= sues/223) >>>>>>>>>>>>>>>>>>>>> to capture your input. >>>>>>>>>>>>>>>>>>>>> A first question that arises: can we give a definitio= n >>>>>>>>>>>>>>>>>>>>> to AS-RO? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp < >>>>>>>>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Fabien Imbault wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Yes, but in that flow, the token relationship >>>>>>>>>>>>>>>>>>>>>>> between AS-RS and AS-RO is only secure if the token= s issued by AS-RS are >>>>>>>>>>>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Attenuated delegation is a requirement, but that >>>>>>>>>>>>>>>>>>>>>> doesn't have to be done cryptographically. Token ex= change works just >>>>>>>>>>>>>>>>>>>>>> fine. SPKI and zcap-ld are examples of the crypto a= pproach, and we used >>>>>>>>>>>>>>>>>>>>>> token exchange in the system for HP. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault < >>>>>>>>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Yes, but in that flow, the token relationship >>>>>>>>>>>>>>>>>>>>>>> between AS-RS and AS-RO is only secure if the token= s issued by AS-RS are >>>>>>>>>>>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp < >>>>>>>>>>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Justin Richer wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> But with all that in mind, I think the key here i= s >>>>>>>>>>>>>>>>>>>>>>>>> going to be looking at what the inputs to the AS = are, and how those can be >>>>>>>>>>>>>>>>>>>>>>>>> defined in an interoperable way for AS=E2=80=99s = that can accept them. I think >>>>>>>>>>>>>>>>>>>>>>>>> there=E2=80=99s a lot of room for innovation and = flexibility here that doesn=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>>> break the trust model or core use cases. If I hav= e an AS-RS set that won=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine inputs= , then I can decide not to >>>>>>>>>>>>>>>>>>>>>>>>> use that one. But this is a very different questi= on than saying the RS >>>>>>>>>>>>>>>>>>>>>>>>> itself needs to accept my own AS =E2=80=94 and we= can=E2=80=99t keep conflating these two >>>>>>>>>>>>>>>>>>>>>>>>> models. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> I agree. The point of having an AS-RO is to allo= w >>>>>>>>>>>>>>>>>>>>>>>> RO to specify a policy for which of RO's access to= kens should be delegated >>>>>>>>>>>>>>>>>>>>>>>> under what conditions. AS-RS should not need to u= nderstand those >>>>>>>>>>>>>>>>>>>>>>>> policies. The flow would be >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> - RO contacts AS-RS and gets one or more access >>>>>>>>>>>>>>>>>>>>>>>> tokens. >>>>>>>>>>>>>>>>>>>>>>>> - RO delegates one or more of those tokens, >>>>>>>>>>>>>>>>>>>>>>>> potentially sub-scoped, to AS-RO. >>>>>>>>>>>>>>>>>>>>>>>> - A different user contacts AS-RO to get a >>>>>>>>>>>>>>>>>>>>>>>> potentially sub-scoped access token from AS-RO. >>>>>>>>>>>>>>>>>>>>>>>> - That user presents the access token delegated >>>>>>>>>>>>>>>>>>>>>>>> by AS-RO when invoking the resource. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> AS-RS only needs to verify that the delegation >>>>>>>>>>>>>>>>>>>>>>>> chain is legitimate, e.g., no increase in scope, a= nd that it grants >>>>>>>>>>>>>>>>>>>>>>>> permission for the request being made. AS-RS does= not need to understand >>>>>>>>>>>>>>>>>>>>>>>> the policy behind granting the delegation by AS-RO= . >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer < >>>>>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> I think this shows the problem with the >>>>>>>>>>>>>>>>>>>>>>>>> terminology as it=E2=80=99s been applied in this = conversation, which I=E2=80=99ve tried to >>>>>>>>>>>>>>>>>>>>>>>>> shine light on before. What you and others are ca= lling the =E2=80=9CRS=E2=80=9D is really >>>>>>>>>>>>>>>>>>>>>>>>> the =E2=80=9CAS and RS working together=E2=80=9D = =E2=80=94 everything to the right of the line. >>>>>>>>>>>>>>>>>>>>>>>>> When Denis had brought up =E2=80=9Celiminating th= e AS=E2=80=9D in another thread, what he=E2=80=99d >>>>>>>>>>>>>>>>>>>>>>>>> really done is labeled everything to the right of= the line as the =E2=80=9CRS=E2=80=9D. Of >>>>>>>>>>>>>>>>>>>>>>>>> course, the irony here is that everything to the = right of the line used all >>>>>>>>>>>>>>>>>>>>>>>>> be called the =E2=80=9CAS=E2=80=9D or simply =E2= =80=9Cserver=E2=80=9D in the OAuth 1 days. As you say >>>>>>>>>>>>>>>>>>>>>>>>> below, I don=E2=80=99t want the client to have vi= sibility on what happens on that >>>>>>>>>>>>>>>>>>>>>>>>> side. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Note well: The Google+ logo labeled =E2=80=9CIdP= =E2=80=9D in the >>>>>>>>>>>>>>>>>>>>>>>>> diagram is not the AS, as far as GNAP is concerne= d. It does not issue an >>>>>>>>>>>>>>>>>>>>>>>>> access token that the RS will accept. The element= s to the left of the line >>>>>>>>>>>>>>>>>>>>>>>>> could be a lot of things, but they are NOT the AS= =E2=80=94 by definition. The >>>>>>>>>>>>>>>>>>>>>>>>> client lives over on the left, but so do any exte= rnal inputs to the AS. >>>>>>>>>>>>>>>>>>>>>>>>> These could be policy inputs on behalf of the RO,= they could be >>>>>>>>>>>>>>>>>>>>>>>>> presentation artifacts, they could be federated l= ogins, they could be the >>>>>>>>>>>>>>>>>>>>>>>>> output of policy decisions. How the AS comes to t= rust those things is up to >>>>>>>>>>>>>>>>>>>>>>>>> the AS=E2=80=99s implementation. It=E2=80=99s som= ething we can talk about, but ultimately >>>>>>>>>>>>>>>>>>>>>>>>> GNAP won=E2=80=99t be in any position to dictate = because in practice some AS=E2=80=99s are >>>>>>>>>>>>>>>>>>>>>>>>> simply going to internalize all policies and we w= ill never successfully >>>>>>>>>>>>>>>>>>>>>>>>> force those open. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> But with all that in mind, I think the key here i= s >>>>>>>>>>>>>>>>>>>>>>>>> going to be looking at what the inputs to the AS = are, and how those can be >>>>>>>>>>>>>>>>>>>>>>>>> defined in an interoperable way for AS=E2=80=99s = that can accept them. I think >>>>>>>>>>>>>>>>>>>>>>>>> there=E2=80=99s a lot of room for innovation and = flexibility here that doesn=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>>> break the trust model or core use cases. If I hav= e an AS-RS set that won=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine inputs= , then I can decide not to >>>>>>>>>>>>>>>>>>>>>>>>> use that one. But this is a very different questi= on than saying the RS >>>>>>>>>>>>>>>>>>>>>>>>> itself needs to accept my own AS =E2=80=94 and we= can=E2=80=99t keep conflating these two >>>>>>>>>>>>>>>>>>>>>>>>> models. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> So to me, GNAP can support a Zero Trust >>>>>>>>>>>>>>>>>>>>>>>>> Architecture by LEVERAGING the AS, not by subsumi= ng or eliminating it. It >>>>>>>>>>>>>>>>>>>>>>>>> is in fact the AS, not the client and not the RS,= that will request and >>>>>>>>>>>>>>>>>>>>>>>>> consume the results of a privacy-preserving zero-= trust policy query thing. >>>>>>>>>>>>>>>>>>>>>>>>> Anything that happens downstream from that is of = little concern to the >>>>>>>>>>>>>>>>>>>>>>>>> zero-trust components because, as you point out, = it=E2=80=99s on the =E2=80=9Cother side=E2=80=9D >>>>>>>>>>>>>>>>>>>>>>>>> of the line. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> I think we got this basic component model pretty >>>>>>>>>>>>>>>>>>>>>>>>> right in OAuth: the AS and RS and client working = together. Where OAuth >>>>>>>>>>>>>>>>>>>>>>>>> misses the mark is the assumption that the user h= as to log in to the AS >>>>>>>>>>>>>>>>>>>>>>>>> through a webpage and interact directly, thereby = proving they=E2=80=99re the RO. >>>>>>>>>>>>>>>>>>>>>>>>> It=E2=80=99s this latter space where I think we c= an both push innovation and also >>>>>>>>>>>>>>>>>>>>>>>>> address the important and compelling use cases li= ke the ones you=E2=80=99re >>>>>>>>>>>>>>>>>>>>>>>>> bringing. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper < >>>>>>>>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> I'm sorry, Justin. As a Resource Owner, I look at >>>>>>>>>>>>>>>>>>>>>>>>> the RS trust boundary (the dotted line in the dia= gram) as being the RS. I >>>>>>>>>>>>>>>>>>>>>>>>> don't expect any visibility into what's going on = on the right. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> My problem with the framing you propose is that >>>>>>>>>>>>>>>>>>>>>>>>> requests are going to the RS (or the AS-RS) and I= don't want to share my >>>>>>>>>>>>>>>>>>>>>>>>> policies with the AS-RS. I want to keep the RS an= d AS-RS as ignorant as >>>>>>>>>>>>>>>>>>>>>>>>> possible. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer < >>>>>>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> What you=E2=80=99re discussing below, in terms o= f logging >>>>>>>>>>>>>>>>>>>>>>>>>> in to a site, is not approaching the RS. You are= in fact approaching the >>>>>>>>>>>>>>>>>>>>>>>>>> client, and identifying both the AS and RS to th= e client. The client is a >>>>>>>>>>>>>>>>>>>>>>>>>> client *of your identity* in this model, and the >>>>>>>>>>>>>>>>>>>>>>>>>> RS is part of the identity provider. It=E2=80=99= s really important that we don=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>>>> conflate the RS and client in this way as it lea= ds to a lot of confusion >>>>>>>>>>>>>>>>>>>>>>>>>> downstream and a lot of broken trust boundaries. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> With that model in mind, approaching the =E2=80= =9CRS" and >>>>>>>>>>>>>>>>>>>>>>>>>> providing it your identity is really just a case= of the =E2=80=9Cfederated login to >>>>>>>>>>>>>>>>>>>>>>>>>> AS=E2=80=9D pattern that we discussed on the WG = call. The user here approaches an >>>>>>>>>>>>>>>>>>>>>>>>>> RS, which has its own AS. To share things from t= his RS, the RO has to >>>>>>>>>>>>>>>>>>>>>>>>>> authenticate to the RS=E2=80=99s AS. This partic= ular AS allows the RO to do so >>>>>>>>>>>>>>>>>>>>>>>>>> using an external identity =E2=80=94 in which ca= se, the AS is now a =E2=80=9Cclient=E2=80=9D of a >>>>>>>>>>>>>>>>>>>>>>>>>> separate, disconnected (but layered) delegation.= The ultimate client that >>>>>>>>>>>>>>>>>>>>>>>>>> eventually calls the RS down the way may or may = not know about these >>>>>>>>>>>>>>>>>>>>>>>>>> layers. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> This same AS, which is closely tied to the RS an= d >>>>>>>>>>>>>>>>>>>>>>>>>> trusted by the RS, might also take in FIDO crede= ntials, or DIDs, or any >>>>>>>>>>>>>>>>>>>>>>>>>> number of other proof mechanisms. The output of = this is an access token the >>>>>>>>>>>>>>>>>>>>>>>>>> RS trusts, but the input is up to the AS. The RS= is not what you=E2=80=99re logging >>>>>>>>>>>>>>>>>>>>>>>>>> in to. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper < >>>>>>>>>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I too am in favor of avoiding consolidation and >>>>>>>>>>>>>>>>>>>>>>>>>> correlation. Right now, when I approach a servic= e provider (RS) for the >>>>>>>>>>>>>>>>>>>>>>>>>> first time, I'm offered the opportunity to ident= ify my persona as: email, >>>>>>>>>>>>>>>>>>>>>>>>>> sign-in with Google, Facebook, or Apple. I know = there are people who try to >>>>>>>>>>>>>>>>>>>>>>>>>> create one-off email addresses but that is mostl= y a waste of time. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> So, along come FIDO2 and DID wallets to the >>>>>>>>>>>>>>>>>>>>>>>>>> rescue. Now, in theory, I have a way to start ou= t my RS relationship >>>>>>>>>>>>>>>>>>>>>>>>>> pseudonymously. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> When I want my resource to be discovered or >>>>>>>>>>>>>>>>>>>>>>>>>> shared I will post that RS URL including my pseu= donym. If I then want to >>>>>>>>>>>>>>>>>>>>>>>>>> introduce a mediator in front of my AS or messag= ing service endpoint, I >>>>>>>>>>>>>>>>>>>>>>>>>> have that option. If I want to keep requests awa= y from the mediator, I >>>>>>>>>>>>>>>>>>>>>>>>>> would publish an encryption key along with my ps= eudonym. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> - Adrian >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer < >>>>>>>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk < >>>>>>>>>>>>>>>>>>>>>>>>>>> kaduk@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, >>>>>>>>>>>>>>>>>>>>>>>>>>> Adrian Gropper wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> >> @Alan Karp shared a >>>>>>>>>>>>>>>>>>>>>>>>>>> talk about the Principle Of Least >>>>>>>>>>>>>>>>>>>>>>>>>>> >> Authority (POLA) in a recent comment >>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-proto= col/issues/145#issuecomment-803099693 >>>>>>>>>>>>>>>>>>>>>>>>>>> >> I recommend it. >>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>> >> We might expect a protocol with authorizatio= n >>>>>>>>>>>>>>>>>>>>>>>>>>> in the title to use authority >>>>>>>>>>>>>>>>>>>>>>>>>>> >> as a core principle. I advocate for a GNAP >>>>>>>>>>>>>>>>>>>>>>>>>>> design that maximizes the power >>>>>>>>>>>>>>>>>>>>>>>>>>> >> of the RO, to be seen as a human rights issu= e >>>>>>>>>>>>>>>>>>>>>>>>>>> when the RO is a human. This >>>>>>>>>>>>>>>>>>>>>>>>>>> >> causes me to ask how to combine better >>>>>>>>>>>>>>>>>>>>>>>>>>> security with better human rights in >>>>>>>>>>>>>>>>>>>>>>>>>>> >> GNAP. >>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>> >> Who should have the least authority in the >>>>>>>>>>>>>>>>>>>>>>>>>>> GNAP design? >>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>> >> The AS derives authority as a delegate of th= e >>>>>>>>>>>>>>>>>>>>>>>>>>> RO. If we ask the RO to >>>>>>>>>>>>>>>>>>>>>>>>>>> >> partition limited authority across dozens of >>>>>>>>>>>>>>>>>>>>>>>>>>> different ASs by domain and >>>>>>>>>>>>>>>>>>>>>>>>>>> >> function, then we are not using technology t= o >>>>>>>>>>>>>>>>>>>>>>>>>>> empower the individual. >>>>>>>>>>>>>>>>>>>>>>>>>>> >> Probably the opposite, as we introduce >>>>>>>>>>>>>>>>>>>>>>>>>>> consent fatigue and burden normal >>>>>>>>>>>>>>>>>>>>>>>>>>> >> people to partition their lives into >>>>>>>>>>>>>>>>>>>>>>>>>>> non-overlapping domains. >>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>> >> My experience says we should aim for one AS >>>>>>>>>>>>>>>>>>>>>>>>>>> per persona because that maps >>>>>>>>>>>>>>>>>>>>>>>>>>> >> into the way we manage our public and privat= e >>>>>>>>>>>>>>>>>>>>>>>>>>> identities. POLA would then >>>>>>>>>>>>>>>>>>>>>>>>>>> >> teach care in keeping ASs and RSs related to >>>>>>>>>>>>>>>>>>>>>>>>>>> work / public separate from >>>>>>>>>>>>>>>>>>>>>>>>>>> >> ASs and RSs related to private life so that = a >>>>>>>>>>>>>>>>>>>>>>>>>>> policy vulnerability in our >>>>>>>>>>>>>>>>>>>>>>>>>>> >> delegation to an AS would have the least >>>>>>>>>>>>>>>>>>>>>>>>>>> likelihood of harm. >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> > Thinking about how least authority/least >>>>>>>>>>>>>>>>>>>>>>>>>>> privilege would apply to GNAP >>>>>>>>>>>>>>>>>>>>>>>>>>> > seems like a useful exercise. I do want to >>>>>>>>>>>>>>>>>>>>>>>>>>> point out some potential >>>>>>>>>>>>>>>>>>>>>>>>>>> > pitfalls with one-AS-per-persona that we can >>>>>>>>>>>>>>>>>>>>>>>>>>> also be aware of. If >>>>>>>>>>>>>>>>>>>>>>>>>>> > one-AS-per-persona becomes one-persona-per-AS >>>>>>>>>>>>>>>>>>>>>>>>>>> as well, then the AS's >>>>>>>>>>>>>>>>>>>>>>>>>>> > identity in effect also serves as a persona >>>>>>>>>>>>>>>>>>>>>>>>>>> identity and there are privacy >>>>>>>>>>>>>>>>>>>>>>>>>>> > considerations to that. If, on the other >>>>>>>>>>>>>>>>>>>>>>>>>>> hand, the >>>>>>>>>>>>>>>>>>>>>>>>>>> > multiple-personas-per-AS (presumably >>>>>>>>>>>>>>>>>>>>>>>>>>> corresponding to multiple humans) >>>>>>>>>>>>>>>>>>>>>>>>>>> > route is taken, we should consider whether >>>>>>>>>>>>>>>>>>>>>>>>>>> that would lead to various >>>>>>>>>>>>>>>>>>>>>>>>>>> > (e.g., market) forces driving consolidation t= o >>>>>>>>>>>>>>>>>>>>>>>>>>> just a handful of >>>>>>>>>>>>>>>>>>>>>>>>>>> > super-popular AS services. That topic is a >>>>>>>>>>>>>>>>>>>>>>>>>>> current matter of concern to >>>>>>>>>>>>>>>>>>>>>>>>>>> > some IETF participants. >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Ben, big +1 to this. This is something that >>>>>>>>>>>>>>>>>>>>>>>>>>> we discussed ages ago in the UMA working group,= and it=E2=80=99s one of the biggest >>>>>>>>>>>>>>>>>>>>>>>>>>> problems with the personal AS (and personal dat= a store) model. This kind of >>>>>>>>>>>>>>>>>>>>>>>>>>> thing makes RS-first trust models really diffic= ult in practice. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> As a strawman, let=E2=80=99s say that I=E2=80= =99ve got software >>>>>>>>>>>>>>>>>>>>>>>>>>> that wants to access my medical information. It= calls an RS and requests >>>>>>>>>>>>>>>>>>>>>>>>>>> access, but it hasn=E2=80=99t been granted anyt= hing yet. Now I as the RO have set >>>>>>>>>>>>>>>>>>>>>>>>>>> up the RS so that it talks to my personal AS, t= hat only I use. In addition >>>>>>>>>>>>>>>>>>>>>>>>>>> to the RS having to be able to figure out which= medical records are being >>>>>>>>>>>>>>>>>>>>>>>>>>> requested from the context of the unauthenticat= ed request (which means it >>>>>>>>>>>>>>>>>>>>>>>>>>> needs identifiers in the URL or something simil= ar for the RS to be able to >>>>>>>>>>>>>>>>>>>>>>>>>>> tell, assuming that it protects data for more t= han one person). So this >>>>>>>>>>>>>>>>>>>>>>>>>>> client software doesn=E2=80=99t know who I am a= nd doesn=E2=80=99t know my medical record >>>>>>>>>>>>>>>>>>>>>>>>>>> information, makes a completely unauthorized re= quest to the RS, and the RS >>>>>>>>>>>>>>>>>>>>>>>>>>> says =E2=80=9CGo to Justin=E2=80=99s personal A= S to get a token=E2=80=9D. The client can now make a >>>>>>>>>>>>>>>>>>>>>>>>>>> direct correlation between the data that=E2=80= =99s being protected at the RS and >>>>>>>>>>>>>>>>>>>>>>>>>>> the person running the AS that protects it. Imp= ortantly, this client makes >>>>>>>>>>>>>>>>>>>>>>>>>>> this call with no prior relationship to the RS = and no really auditable way >>>>>>>>>>>>>>>>>>>>>>>>>>> to track it down after the fact. This is a desi= gn feature in the good case, >>>>>>>>>>>>>>>>>>>>>>>>>>> and terrifying in the bad case. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> If the RS instead says =E2=80=9Cwelcome to Medi= cine >>>>>>>>>>>>>>>>>>>>>>>>>>> Doctor RS, please talk to the Medicine Doctor A= S to get access=E2=80=9D, we haven=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>>>>> exposed anything at all. And from the perspecti= ve of both the patient and >>>>>>>>>>>>>>>>>>>>>>>>>>> the RS, this is more privacy-preserving, and it= =E2=80=99s really the least >>>>>>>>>>>>>>>>>>>>>>>>>>> surprising option. Once the client gets to the = AS, it can start a >>>>>>>>>>>>>>>>>>>>>>>>>>> negotiation of figuring out who the RO is for t= he information being >>>>>>>>>>>>>>>>>>>>>>>>>>> accessed. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On top of this, the usability expectations of >>>>>>>>>>>>>>>>>>>>>>>>>>> people managing their own AS, or set of AS=E2= =80=99s for multiple personas to keep >>>>>>>>>>>>>>>>>>>>>>>>>>> things separate, is a huge burden. Even in the = tech community, I know >>>>>>>>>>>>>>>>>>>>>>>>>>> people who can=E2=80=99t reliably manage more t= han one email address for different >>>>>>>>>>>>>>>>>>>>>>>>>>> purposes. I wouldn=E2=80=99t expect my partner = to do that =E2=80=94 they have trouble >>>>>>>>>>>>>>>>>>>>>>>>>>> enough balancing all the logins and sessions re= quired for different kids >>>>>>>>>>>>>>>>>>>>>>>>>>> remote schooling, I couldn=E2=80=99t imagine th= em having to understand all the >>>>>>>>>>>>>>>>>>>>>>>>>>> requirements for managing multiple authorizatio= n servers and associated >>>>>>>>>>>>>>>>>>>>>>>>>>> policies. I also don=E2=80=99t expect any perso= n to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve been on >>>>>>>>>>>>>>>>>>>>>>>>>>> the internet for decades and I can barely keep = tabs on my GPG keys, and >>>>>>>>>>>>>>>>>>>>>>>>>>> only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket >>>>>>>>>>>>>>>>>>>>>>>>>>> pressure=E2=80=9D that I think Ben mentions abo= ve, people will just want to >>>>>>>>>>>>>>>>>>>>>>>>>>> outsource that to someone else, and the reality= will be a few popular >>>>>>>>>>>>>>>>>>>>>>>>>>> providers. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> In which case, we could end up doing a ton of >>>>>>>>>>>>>>>>>>>>>>>>>>> work to allow an RS choice only to end up with = a world where the RS ends up >>>>>>>>>>>>>>>>>>>>>>>>>>> making a limited choice anyway. We see how that= plays out with OpenID >>>>>>>>>>>>>>>>>>>>>>>>>>> Connect =E2=80=94 RP=E2=80=99s could allow arbi= trary IdPs but they choose Google because it >>>>>>>>>>>>>>>>>>>>>>>>>>> works and that=E2=80=99s where the users are. (= And that=E2=80=99s not to say anything of >>>>>>>>>>>>>>>>>>>>>>>>>>> the proprietary OIDC-like protocols, but that= =E2=80=99s another discussion). >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> For further reading on these topics, I recommen= d >>>>>>>>>>>>>>>>>>>>>>>>>>> both =E2=80=9CWhy Johnny Can=E2=80=99t Encrypt= =E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> So what does this have to do with GNAP? I think >>>>>>>>>>>>>>>>>>>>>>>>>>> we can be clear-eyed on what kinds of expectati= ons we have for the >>>>>>>>>>>>>>>>>>>>>>>>>>> participants. If we expect users (RO=E2=80=99s)= to have to set up the AS-RS >>>>>>>>>>>>>>>>>>>>>>>>>>> relationship, or expect them to carry their AS,= or manage their personal >>>>>>>>>>>>>>>>>>>>>>>>>>> keys =E2=80=94 I think we=E2=80=99ve lost the b= attle for relevance. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>> >>>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> >> > --000000000000c5a5a205be7103dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Justin,=C2=A0

    Big YES to =E2=80=9C The conceptual framework of an AS that takes= in lots of different information and spits out access tokens is exactly th= e abstraction layer that is necessary for making these use cases interopera= ble.=E2=80=9D and probably everything else you just said.=C2=A0

    I seem to not understand the delega= tion design between RS and AS. In my view, that delegation always goes thro= ugh the RO, although the RO may be forced to choose from a list provided by= the RS.

    In my view, GNA= P, can acknowledge this and design to be agnostic to whether the AS is spec= ified by he RO or picked from a list of 1 or more choices provided by the R= S.

    - Adrian
    On Fri, = Mar 26, 2021 at 9:30 AM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    I disagree, I believe that what I have laid out is exactly separating the = concerns into working components.=C2=A0

    Like OAuth= before it, GNAP is a protocol negotiate access for a client instance to an= RS, using an AS as the facilitator of that delegated negotiation. (Unlike = OAuth, it=E2=80=99s importantly also for negotiating user information to th= e client directly from the AS with no RS involved, but that=E2=80=99s an as= ide for the purposes of our conversation here).

    If= a particular GNAP RS also allows other kinds of processes to enable access= to it, that is completely fine, but outside of GNAP. If an RS allows a use= rname/password HTTP Basic auth in addition to accepting access tokens, it c= an do so, but GNAP doesn=E2=80=99t have anything to say about the Basic aut= h use, or even its relation to any access tokens or RO=E2=80=99s or anythin= g else. If an RS accepts structured access tokens signed by trusted keys th= at don=E2=80=99t come from an AS through a negotiated request =E2=80=94 aga= in, that=E2=80=99s fine, but GNAP is silent about the RS doing that. If the= RS acts as =E2=80=9Cits own AS=E2=80=9D then it=E2=80=99s really just an R= S and an AS living in the same box. Again, that=E2=80=99s fine, and super c= ommon with OAuth today.=C2=A0

    GNAP is solving the = problem of connecting the client to the RS through means of an AS. Other so= lutions are possible and many of them can be deployed right alongside, but = that=E2=80=99s not the corner of the world that GNAP is solving. GNAP shoul= d be concerned about how these other technologies can be used alongside it.= I think there=E2=80=99s a lot of room for the things that you=E2=80=99re t= alking about, and more importantly for solving the use cases that you=E2=80= =99re bringing. But GNAP should be more than a single-point solution, and s= o we need to balance these concerns. The conceptual framework of an AS that= takes in lots of different information and spits out access tokens is exac= tly the abstraction layer that is necessary for making these use cases inte= roperable.

    =C2=A0=E2=80=94 Justin

    On Mar 26, 2021, at 8:30 AM, Adrian Gropper <agropper@healthurl.= com> wrote:

    @Justin, there=E2=80=99s= no separation of concerns here. No partition between processor and control= ler. No data minimization. And, I see no obvious reason to make this the co= re of GNAP.=C2=A0

    The on= e thing we can probably all agree on is that there=E2=80=99s only one RS an= d one RO.=C2=A0

    The core= of GNAP, in my=C2=A0opinion, can be built and explained around this simple= design. The RS is a processor. The RO is a controller. The RS bears only s= ecurity responsibility. The RS bears no privacy responsibility. The RO dele= gates this to the RS but this is not authorization as the A in GNAP.
    <= div dir=3D"auto">
    The RO retains all rights to d= elegate within the scope of things that the RS is willing to support using = various token formats and endpoint options. Some of these options may do al= l sorts of things for all sorts of clients and user-agents =C2=A0but these = are options.=C2=A0

    For e= xample, if a request comes to the RS that is not in the form of an access t= oken, then it either gets sent to the RO or their agent, or it gets logged = and dumped. One such option, common in healthcare, is =E2=80=9CBreak the Gl= ass=E2=80=9D where the RS is acting as an authorization server because the = user-agent is making a request instead of presenting an access token. GNAP = can offer this as an option but it is not our core.
    =
    Adrian



    On Fri, Mar 26, 2021 at 7:15 AM Justin Richer <jricher@mit.edu> wro= te:
    I have a big problem with this line:
    >=C2=A0the RS a= nd AS-RS only see access tokens. The requests (from RO') that resulted = in an access token are none of their business.

    I= n the trust model we=E2=80=99ve been discussing, the requests that result i= n access tokens are solely the business of AS-RS, since AS-RS is the= only entity that=E2=80=99s allowed, and trusted by the RS, to create acces= s tokens for the RS. That is its entire job, the entire reason it exists in= the system. By definition the party generating tokens for use at the RS is= the AS for that RS, I don=E2=80=99t care how you deploy it. If RO wants to= give access to someone else (who isn=E2=80=99t an =E2=80=9CRO" anymor= e, they=E2=80=99re another end-user), then that end user=E2=80=99s client s= oftware will need to talk to AS-RS to get its own access token.

    Now here=E2=80=99s the trick: when the end user=E2=80=99s client in= stance talks to AS-RS, that does NOT mean that AS-RS needs to know all the = details and policy reasons that it should give an access token to that clie= nt instance. It doesn=E2=80=99t even need to know the existence of another = end user. It doesn=E2=80=99t need identity, it doesn=E2=80=99t need policy.= Sure, it COULD handle all of that internally, and many will, but the proto= col doesn=E2=80=99t demand it.=C2=A0

    This means th= at the first client instance, the one that gets the access token, can also = be given something alongside the access token that it can then hand to anot= her piece of software (or to a person to hand eo their piece of software). = This artifact is not an access token. This artifact could be something stru= ctured that the client understands, and can make derivatives of, and presen= t back to the AS-RS for getting new access tokens. There could be multiple = different flavors of this kind of artifact for different kinds of environme= nts and groups. But what they all have in common is that they can potential= ly be used to request more access tokens within some context at the AS-RS.<= /div>

    =C2=A0=E2=80=94 Justin

    <= br>

    On Mar 25, 2021, at 5:50 PM, Adr= ian Gropper <agropper@healthurl.com> wrote:

    My issue is with Alan's:
    "7. Another user ag= ent (RO') can contact any holder of the access token or the service'= ;s policy agent (AS-RS) to get a delegated access token."

    I would prefer "7A.=C2=A0Another user agent (RO') can contact any h= older of the access token." by default so that the AS-RS does not see = the requests. In other words, the RS and AS-RS only see access tokens. The = requests (from RO') that resulted in an access token are none of their = business.

    The reality is that RO' can discover a r= esource RS and can share whatever information with RS-AS they want and the = RO may not even know about it unless the RS decides to let them know someho= w. This seems to be a drawback of the capabilities approach.=C2=A0
    =
    In terms of privacy and control, I, as the RO, want a contract= =C2=A0with the RS that says that I or my agent (AS-RO) must sign an access = token. This is a fundamental audit requirement. Without it, a rogue RS and = AS-RS can do all sorts of things and the RO would never know. I understand = that a rogue RS might not support an honest contemporaneous log of access t= okens presented so there's a trust issue here that I seems unavoidable = unless I specify in my RO-RS contract that they use a separate contemporane= ous=C2=A0log such as AS-RO for every access token presented and risk being = sued if they process an access token without also updating the separate log= .

    - Adrian


    On = Thu, Mar 25, 2021 at 1:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin Richer <jricher@mit.edu> wrote:
    Hi Alan,<= div>
    In all of my discussion, and in the spec itself, the RO = is the :entity: in charge of approving rights. They=E2=80=99re probably a p= erson. It might be software that makes a policy decision in some way, or a = corporate entity, or something like that. But it=E2=80=99s not assumed to b= e a computational agent in the terms of the protocol itself. Would that rec= ast what you=E2=80=99re saying below?

    Hmmm.=C2=A0 I guess not.=C2=A0 It's just that t= he person would be using some UI to express their decisions to what I calle= d the user agent.=C2=A0 That model fits in very nicely with what we did wit= h Polaris, our virus safe computing environment for Windows XP, https://d= l.acm.org/doi/10.1145/1151030.1151033.=C2=A0 The person would click on = the icon for a Word file, and an instance of Word would open with only the = permission needed to edit that one file.=C2=A0 Same thing here.=C2=A0 The c= lient could ask for permission to use the resource, or permission could be = granted implicitly when the user selects a resource associated with a speci= fic client.

    --------------
    Alan Karp


    On Thu, Mar 25, 2021 at 9:53 AM Justin Richer <jricher@mit.edu> wrote:
    <= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rg= b(204,204,204)">
    Hi Alan,

    In all of my discussion, a= nd in the spec itself, the RO is the :entity: in charge of approving rights= . They=E2=80=99re probably a person. It might be software that makes a poli= cy decision in some way, or a corporate entity, or something like that. But= it=E2=80=99s not assumed to be a computational agent in the terms of the p= rotocol itself. Would that recast what you=E2=80=99re saying below?

    =C2=A0=E2=80=94 Justin

    On Mar 25, 2021, at 12:36 PM, Alan Karp <alanhkarp@gmail.com> wrote:
    =
    There seems to be some confusion about how AS-RO = comes into the picture, probably because of the "AS" part.=C2=A0 = I'm going to try to clear up that confusion by more carefully explainin= g what I mean.

    I'm assuming that RO is a computational age= nt representing the person who is the resource owner, something called the = "user agent" in operating systems lingo.=C2=A0 I'm also assum= ing that it's possible to do delegation, either locally or by token exc= hange with AS-RS.=C2=A0 All delegations are potentially sub-scoped, but you= may also want to delegate with full scope to have a separately revocable a= ccess token.

    =C2=A0 Here's an example of how t= hings work in a capability oriented system.
    1. Someone, = the service owner, creates a service.
    2. The service owner contracts w= ith an policy agent (AS-RS) to create and manage access tokens for that ser= vice (RS).
    3. A person wishing to create a resource at RS uses their u= ser agent (RO) to contact the service owner's policy agent (AS-RS) and = gets back an access token for that resource.
    4. That user agent (RO) c= an=C2=A0
      1. use that access token to invoke the resource, or
        2. <= li>delegate an access token to a client of the user agent's (RO) choice= , or
      2. contract with a policy agent (AS-RO) to manage those delegatio= ns on behalf of the user agent (RO), or
      3. specify a policy with the s= ervice's policy agent (AS-RS).
    5. A client can contact any ho= lder of the access token (the user agent (RO) or its policy agent (AS-RO)) = or the service's policy agent (AS-RS) to get a delegated access token.<= /li>
    6. That client can delegate that token to another client.
    7. Anot= her user agent (RO') can contact any holder of the access token or the = service's policy agent (AS-RS) to get a delegated access token.
      8. The other user agent (RO') can=C2=A0
      1. use that access token= to invoke the resource, or
      2. delegate it to a client of its choice, = or
      3. contract with a policy agent (AS-RO') of its choosing to ma= nage those delegations on its behalf, or
      4. specify a policy with the = service's policy agent (AS-RS).
    8. and so on
    <= div>
    When any of these computational agents, user agents (ROs) or = clients acting on their behalf, invokes the resource, AS-RS verifies that t= he access token is a valid delegation, i.e., proper sub-scoping, hasn't= been revoked, and that it authorizes the request being made before telling= the service (RS) to honor the request.=C2=A0 At no point does the service&= #39;s policy agent (AS-RS) know which computational agent did any particula= r delegation.=C2=A0 (Token exchange can be done as anonymously as possible.= )=C2=A0 In particular, the policy agents (AS-RO) need not be the same, or e= ven compatible with, the service's policy agent (AS-RS).=C2=A0 GNAP spe= cifies the protocol between requesters, invokers, delegators (for token exc= hange) of tokens and AS-RS.=C2=A0 That protocol need not be used between us= er agents (RO), clients, or other policy agents (AS-RO), but it is likely t= o be.

    =C2=A0-------------
    Alan Karp


    On Thu, Mar 25, 2021 at 5:45 AM Just= in Richer <jricher@= mit.edu> wrote:
    The way I=E2=80=99m t= hinking about Adrian=E2=80=99s use case is that what we=E2=80=99re calling = the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an =E2=80=9CAS=E2=80=9D in the tr= aditional OAuth/GNAP sense, at least not exactly. This is the agent that th= e RO can use to set policies and manage consent on their behalf, and I=E2= =80=99ve been arguing that it fits better into this vaguely-defined =E2=80= =9Cinteraction component=E2=80=9D aspect of the current AS definition, and = it=E2=80=99s not currently separated from the AS definition. The =E2=80=9CA= S-RS=E2=80=9D maps to what we=E2=80=99d call the =E2=80=9CAS=E2=80=9D in OA= uth/GNAP traditionally, it=E2=80=99s what the RS trusts to issue tokens. In= traditional OAuth the AS-RO and AS-RS are always the same thing, from a fu= nctional protocol perspective. An important point here is that from a clien= t=E2=80=99s perspective, they=E2=80=99re only talking to the AS-RS since th= at=E2=80=99s where the client gets its tokens, because at the end of the da= y the client just wants to call the API at the RS and doesn=E2=80=99t care = how that happens (from a protocol standpoint).=C2=A0

    Not= e well: Even thought I don=E2=80=99t believe that =E2=80=9CAS-RO=E2=80=9D i= s an authorization server at all, I=E2=80=99m going to keep using that term= below for consistency with previous discussion.

    S= o we have these fundamental relationships around getting the client to acce= ss the RS:

    1. RS trusts=C2=A0AS-RS=C2=A0to issue t= okens that RS will accept, validate, and process for requests from client
    2. Client trusts=C2=A0AS-RS=C2=A0to issue tokens that client can u= se at RS
    3. RO trusts RS to protect RO=E2=80=99s api through dele= gated access

    On top of that, we=E2=80=99ve got som= e additional aspects that we=E2=80=99re discussing:

    4. RO trusts=C2=A0AS-RO=C2=A0to manage RO=E2=80=99s policies at runtime
    5.=C2=A0AS-RS=C2=A0trusts=C2=A0AS-RO=C2=A0to assert RO=E2=80=99s p= olicies for access to RS
    6. Client trusts whatever=C2=A0AS-RS=C2= =A0sends client to deal with, including possibly RO-AS at runtime, because = of (2)

    What I have been saying is that 4/5/6 are o= ptional details of how RS-AS runs things, and I think this also maps with A= drian=E2=80=99s view of choice, since if my RS=E2=80=99s AS-RS doesn=E2=80= =99t allow me to plug in my own AS-RO then I would be motivated to pick a d= ifferent RS who=E2=80=99s AS-RS lets me do just that. The same way I=E2=80= =99d pick a different RS if their surrounding services didn=E2=80=99t accep= t my preferred federation login and I didn=E2=80=99t want to make another a= ccount. Of course, market forces being as they are, I might not have much o= f an actionable choice in RS, but GNAP can=E2=80=99t change that.=C2=A0

    What we can do is make it possible for AS-RS to talk = to AS-RO, both in philosophy of the protocol design and in concrete hooks t= o support (6) above.=C2=A0

    Separately, we can appr= oach the issue of making 1/2 above more dynamic. This was UMA2=E2=80=99s = =E2=80=9Cfederated authorization=E2=80=9D approach, and is behind a lot of = the =E2=80=9Cbring your own AS=E2=80=9D models out there. The problem with = these is that we know from many years of experience that most RS=E2=80=99s = aren=E2=80=99t interested in doing anything of the sort.

    So with GNAP we can instead allow 4/5/6 to vary in a predictable and= consistent way, letting the RS keep control over 1/2, thereby enabling cho= ice in (3). We don=E2=80=99t have to be the ones who define the all of the = details of every permutation of (5) to enable this, though. Some of this is= going to be configuration out of band, some of it=E2=80=99s going to be co= mmunication at runtime. This is where VC=E2=80=99s, ZCAPs, CHAPI, DIDComm, = FIDO, and a whole swath of other tech can come in and help out. I don=E2=80= =99t think we need to put all the details for using these into core, nor do= I think we=E2=80=99ll pull of The Great And Ultimate Abstraction for using= these and other approaches. But we can at least start talking about =E2=80= =9CAS-RS=E2=80=9D in such a way that it no longer assumes it=E2=80=99s alwa= ys the same party dealing with the RO directly.

    =C2= =A0=E2=80=94 Justin

    On Mar 25, 2= 021, at 6:40 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    To reframe it closer to GNAP:
    - AS =3D AS-RO, that&#= 39;s where you find the RO policies. The AS issues access tokens to the cli= ent.
    - the RO policies could be a) defined locally or b) in relat= ionship with the RS

    There have been several ideas = related to the AS-RS relationship b:
    b1) the RS issues capabi= lities (which can be further attenuated by the RO)
    b2) Adrian als= o discussed a DID based solution
    b3) there was also an alternativ= e ACL proposal from Denis (+ preflight)

    Fabien


    On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault <fabien.imbault@gmail= .com> wrote:
    Ok so I get = you correctly:=C2=A0
    - what matters is the RQ (could be a RO or a end-u= ser or both : we don't really care at a high-level, they're all tre= ated as entities that make a request)
    - the policy is able to han= dle those different cases, based on its own internal delegation protocol
    - currently that requires AS-RS and AS-RO, but maybe it can be simp= lified

    To answer to Denis, here's what I under= stood:
    - RO trusts AS-RS (and then handles its own policies withi= n AS-RO)
    - end-user trusts AS-RO (through its client)

    Could probably work but that's a fairly different mod= el compared to OAuth2 (and of today's GNAP), with different frontiers b= etween the AS and the RS.=C2=A0

    Please do not hesi= tate to correct me if I'm wrong.

    Fabien=C2=A0<= /div>

    On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper <agropper@healthurl.com> wro= te:
    I believe there are alterna= tives to having two kinds of ASs. The problem may be a side-effect of decid= ing to switch away form treating the RO as different from the RQ. That lead= s to downstream privacy issues. Our desire for architectural simplicity is = admirable but that may have been a step too far.
    There may also be solutions based on different typ= es of tokens, as in different capabilities (tokens signed by the RS) vs. to= kens signed by the AS. I=E2=80=99m not sure about that but Alan might have = more to say.

    Adrian

    = On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault <fabien.imbault@gmail.com> wrot= e:
    Thanks. The general problem s= tatement is clear.

    The=C2=A0proposed solution a bit less= (to me). I understood that from point 2, Alan involves 2 ASs. You said : &= quot;There=E2=80=99s no obvious reason t= o have two types of ASs".=C2=A0Do you see an alternative ?

    Regarding the last it= em, I don't think that naming RQ by end-user created the problem. It mi= ght just highlight the asymmetry,=C2=A0which fundamentally exists.=C2=A0

    =
    Fabien
    =

    On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper <agropper@healthurl.com>= ; wrote:
    Recap:
    1 - Justin (I think) introduced the idea of an AS on the RS trust= boundary side.
    2 - I said the RO should not have to= share policies with the RS.
    3 - Alan invented the c= oncept of AS-RO and AS-RS to separate two kinds of PDPs.=C2=A0

    The thing is that step 2 is not symm= etrical. The RO has a legitimate privacy interest in keeping their policies= private and minimizing the leakage of information about requests that are = posed against those policies.=C2=A0

    The RS, on the other hand, should be publishing its policies (e= .g. what it=E2=80=99s selling or what jurisdiction it=E2=80=99s in or what = tokens or scopes it supports). The RS has no obvious privacy interest in GN= AP. It=E2=80=99s just an enforcer.

    There is one other privacy interest to consider around the RS an= d that is the requesting party (the end-user that is not the RO :-) might p= refer to share attributes with the RS instead of the RO or something contro= lled by the RO. This case could be an =E2=80=9Cextension=E2=80=9D to GNAP a= nd might result in a split AS as a solution. This problem was introduced wh= en the editors decided to replace RQ with end-user. Obviously, the RO end-u= ser has no privacy interests relative to itself.
    Adrian




    On Thu, Mar 25, 2021 at 3:24= AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    I was referring to "By my definition, this model has two ASs since both are proc= essing requests into tokens". If there's no reason to have 2 types= of ASs, that's fine then.=C2=A0
    But I&#= 39;m a bit lost in where we stand with the idea.=C2=A0

    Could you recap?=C2=A0

    Fabien=C2=A0

    Le jeu. 25 mars 2021 =C3=A0 08:16,= Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    There=E2=80=99s no obvious reason to have two type= s of ASs. Any AS that is executing the policies of the RS can look to GNAP = like the RS itself. Why would GNAP expose that interface to anyone?=C2=A0

    Adrian

    On Thu, Mar 25= , 2021 at 3:11 AM Fabien Imbault <fabien.imbault@gmail.com>= wrote:
    Note : I'm not sure= that's a good idea, but having 2 types of ASs is not that easy to gras= p.

    Fab= ien=C2=A0

    Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault <fabien.imbault@gmail.com> a =C3=A9crit=C2=A0:
    The purpose of either handling policies locally or d= elegating them to the RO agent.=C2=A0

    <= div dir=3D"ltr" class=3D"gmail_attr">Le jeu. 25 mars 2021 =C3=A0 08:04, Adr= ian Gropper <agropper@healthurl.com> a =C3=A9crit= =C2=A0:
    What purpose would be s= erved by GNAP splitting the AS into two components?
    =
    Adrian=C2=A0

    On T= hu, Mar 25, 2021 at 2:59 AM Fabien Imbault <= fabien.imbault@gmail.com> wrote:
    Isn't the AS-RO a component of the AS? Same idea as the inter= act component, it functionnally belongs to the AS role but could be deploye= d either as a monolith or as a separate component?
    <= div dir=3D"auto">
    Fabien

    Le jeu. 25 mars 20= 21 =C3=A0 04:26, Adrian Gropper <agropper@heal= thurl.com> a =C3=A9crit=C2=A0:
    Yes, but I would say it=E2=80=99s not the RO that wants the access t= oken. It=E2=80=99s the RO that wants the client making the request to get a= n access token.=C2=A0

    Ad= rian

    On Wed, Mar 24, 2021 at 11:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Ad= rian Gropper <agropper@healthurl.co= m> wrote:

    In this design, the AS is the AS-RS and the agent is the A= S-RO. By my definition, this model has two ASs since both are processing re= quests into tokens. The problem with this is complexity and privacy. The RO= may not want to share the request information with the AS-RS.

    More precisely,= RO has no choice but to present the required information to AS-RS if RO wa= nts an access token.=C2=A0 However, RO does not want AS-RS to know the poli= cy by which RO delegates tokens.=C2=A0 That's why RO uses AS-RO for tho= se delegations.

    --------------
    Alan Karp
    =


    On Wed, Mar 24, 2021 at 7:41 PM Adrian Gro= pper <agropper@healthurl.com>= ; wrote:
    Thank = you for creating the issue. My definition of AS is independent of AS-RO or = AS-RS.=C2=A0https://github.com/ietf-wg-gnap/gnap-core-prot= ocol/issues/223#issuecomment-806280421 I also agree with Alan's def= inition based on delegation. An AS-RS would be a delegate of the RS.=C2=A0<= /div>

    Based on that, I see it as obvious=C2= =A0that the policy has to be accessible (defined locally?) in order for it = to be run as the code that turns a request into an access token.=C2=A0

    The only other possibility is that the request is pack= aged by the AS and sent elsewhere (an agent) for evaluation against policy = and a proto-token returned. In that case the AS is acting as a proxy and th= e PDP is elsewhere. I can imagine that an AS-RS would behave this way so th= at the proto-token could be turned into an access token by the AS-RS. Isn&#= 39;t this what Justin is proposing? In this design, the AS is the AS-RS and= the agent is the AS-RO. By my definition, this model has two ASs since bot= h are processing requests into tokens. The problem with this is complexity = and privacy. The RO may not want to share the request information with the = AS-RS.

    Adrian

    On Wed, Mar 24, 2021 at 5:21 PM= Fabien Imbault <fabien.imbault@g= mail.com> wrote:
    Is= n't that what the AS is supposed to be, only with the caveat that the p= olicy is defined locally?=C2=A0

    Fabien=C2=A0


    Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp <alanhkarp@gmail.com> a =C3=A9crit=C2=A0:<= br>
    AS-RO is an AS = that RO trusts to delegate RO's access tokens according to RO's pol= icies.=C2=A0=C2=A0

    -------------= -
    Alan Karp


    On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbaul= t <fabien.imbault@gmai= l.com> wrote:
    Hi Alan and= Adrian,

    I've created issue AS-RO policy delegation = (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to= capture your input.=C2=A0
    A first question that arises: can we g= ive a definition to AS-RO?

    Thanks
    Fabien=

    On Tue, Mar 23, 2021 at 4:15 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan,=C2=A0

    = Yes, but in that flow, the token relationship between AS-RS and AS-RO is on= ly secure if the tokens issued by AS-RS are cryptographically attenuable in= the first place.=C2=A0
    =C2=A0
    Attenuated delegation is a requirement, but that doesn't ha= ve to be done cryptographically.=C2=A0 Token exchange works just fine.=C2= =A0 SPKI and zcap-ld are examples of the crypto approach, and we used token= exchange in the system for HP.

    -------------= -
    Alan Karp


    On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbaul= t <fabien.imbault@gmai= l.com> wrote:
    Hi Alan,=C2= =A0

    Yes, but in that flow, the token relationship betwee= n AS-RS and AS-RO is only secure if the tokens issued by AS-RS are cryptogr= aphically attenuable in the first place.=C2=A0

    Fab= ien

    On Mon, Mar 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin Richer <jricher@= mit.edu> wrote:

    B= ut with all that in mind, I think the key here is going to be looking at wh= at the inputs to the AS are, and how those can be defined in an interoperab= le way for AS=E2=80=99s that can accept them. I think there=E2=80=99s a lot= of room for innovation and flexibility here that doesn=E2=80=99t break the= trust model or core use cases. If I have an AS-RS set that won=E2=80=99t a= ccept my favorite flavor of policy engine inputs, then I can decide not to = use that one. But this is a very different question than saying the RS itse= lf needs to accept my own AS =E2=80=94 and we can=E2=80=99t keep conflating= these two models.

    I agree.=C2= =A0 The point of having an AS-RO is to allow RO to specify a policy for whi= ch of RO's access tokens should be delegated under what conditions.=C2= =A0 AS-RS should not need to understand those policies.=C2=A0 The flow woul= d be
    • RO contacts AS-RS and gets one or more access tokens= .
    • RO delegates one or more of those tokens, potentially sub-scoped,= to AS-RO.
    • A different user contacts AS-RO to get a potentially sub= -scoped access token from AS-RO.
    • That user presents the access toke= n delegated by AS-RO when invoking the resource.
    A= S-RS only needs to verify that the delegation chain is legitimate, e.g., no= increase in scope, and that it grants permission for the request being mad= e.=C2=A0 AS-RS does not need to understand the policy behind granting the d= elegation by AS-RO.

    --------------
    Alan Karp


    On Mon, Mar 22, 2021 at 11:40 AM Justin Richer <jricher@mit.edu> wrote:
    <= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rg= b(204,204,204)">
    Adrian,

    I think this shows the prob= lem with the terminology as it=E2=80=99s been applied in this conversation,= which I=E2=80=99ve tried to shine light on before. What you and others are= calling the =E2=80=9CRS=E2=80=9D is really the =E2=80=9CAS and RS working = together=E2=80=9D =E2=80=94 everything to the right of the line. When Denis= had brought up =E2=80=9Celiminating the AS=E2=80=9D in another thread, wha= t he=E2=80=99d really done is labeled everything to the right of the line a= s the =E2=80=9CRS=E2=80=9D. Of course, the irony here is that everything to= the right of the line used all be called the =E2=80=9CAS=E2=80=9D or simpl= y =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say below, I don=E2= =80=99t want the client to have visibility on what happens on that side.=C2= =A0

    Note well: The Google+ logo labeled =E2=80=9CI= dP=E2=80=9D in the diagram is not the AS, as far as GNAP is concerned. It d= oes not issue an access token that the RS will accept. The elements to the = left of the line could be a lot of things, but they are NOT the AS =E2=80= =94 by definition. The client lives over on the left, but so do any externa= l inputs to the AS. These could be policy inputs on behalf of the RO, they = could be presentation artifacts, they could be federated logins, they could= be the output of policy decisions. How the AS comes to trust those things = is up to the AS=E2=80=99s implementation. It=E2=80=99s something we can tal= k about, but ultimately GNAP won=E2=80=99t be in any position to dictate be= cause in practice some AS=E2=80=99s are simply going to internalize all pol= icies and we will never successfully force those open.=C2=A0

    =
    But with all that in mind, I think the key here is going to be l= ooking at what the inputs to the AS are, and how those can be defined in an= interoperable way for AS=E2=80=99s that can accept them. I think there=E2= =80=99s a lot of room for innovation and flexibility here that doesn=E2=80= =99t break the trust model or core use cases. If I have an AS-RS set that w= on=E2=80=99t accept my favorite flavor of policy engine inputs, then I can = decide not to use that one. But this is a very different question than sayi= ng the RS itself needs to accept my own AS =E2=80=94 and we can=E2=80=99t k= eep conflating these two models.

    So to me, GNAP ca= n support a Zero Trust Architecture by LEVERAGING the AS, not by subsuming = or eliminating it. It is in fact the AS, not the client and not the RS, tha= t will request and consume the results of a privacy-preserving zero-trust p= olicy query thing. Anything that happens downstream from that is of little = concern to the zero-trust components because, as you point out, it=E2=80=99= s on the =E2=80=9Cother side=E2=80=9D of the line.=C2=A0

    I think we got this basic component model pretty right in OAuth: the= AS and RS and client working together. Where OAuth misses the mark is the = assumption that the user has to log in to the AS through a webpage and inte= ract directly, thereby proving they=E2=80=99re the RO. It=E2=80=99s this la= tter space where I think we can both push innovation and also address the i= mportant and compelling use cases like the ones you=E2=80=99re bringing.

    =C2=A0=E2=80=94 Justin

    On Mar 22, 2021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> wrote:
    I'm sorry, Justin. As a Resource Owner, I= look at the RS trust boundary (the dotted line in the diagram) as being th= e RS. I don't expect any visibility into what's going on on the=C2= =A0right.=C2=A0

    My problem with the framing you propose = is that requests are going to the RS (or the AS-RS) and I don't want to= share my policies with the AS-RS. I want to keep the RS and AS-RS as ignor= ant as possible.

    Adrian

    On Mon, Mar 22, 2021= at 1:48 PM Justin Richer <jric= her@mit.edu> wrote:
    Adrian,

    <= /div>
    What you=E2=80=99re discussing below, in terms of logging in to a= site, is not approaching the RS. You are in fact approaching the client, a= nd identifying both the AS and RS to the client. The client is a client = of your identity in this model, and the RS is part of the identity prov= ider. It=E2=80=99s really important that we don=E2=80=99t conflate the RS a= nd client in this way as it leads to a lot of confusion downstream and a lo= t of broken trust boundaries.

    With that model in m= ind, approaching the =E2=80=9CRS" and providing it your identity is re= ally just a case of the =E2=80=9Cfederated login to AS=E2=80=9D pattern tha= t we discussed on the WG call. The user here approaches an RS, which has it= s own AS. To share things from this RS, the RO has to authenticate to the R= S=E2=80=99s AS. This particular AS allows the RO to do so using an external= identity =E2=80=94 in which case, the AS is now a =E2=80=9Cclient=E2=80=9D= of a separate, disconnected (but layered) delegation. The ultimate client = that eventually calls the RS down the way may or may not know about these l= ayers.=C2=A0

    <PastedGraphic-1.png>
    This sa= me AS, which is closely tied to the RS and trusted by the RS, might also ta= ke in FIDO credentials, or DIDs, or any number of other proof mechanisms. T= he output of this is an access token the RS trusts, but the input is up to = the AS. The RS is not what you=E2=80=99re logging in to.

    =C2=A0=E2=80=94 Justin

    On= Mar 22, 2021, at 1:28 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I too am in favor of avoiding consolidation and correlation. R= ight now, when I approach a service provider (RS) for the first time, I'= ;m offered the opportunity to identify my persona as: email, sign-in with G= oogle, Facebook, or Apple. I know there are people who try to create one-of= f email addresses but that is mostly a waste of time.=C2=A0

    <= div>So, along come FIDO2 and DID wallets to the rescue. Now, in theory, I h= ave a way to start out my RS relationship pseudonymously.=C2=A0
    <= br>
    When I want my resource to be discovered or shared I will pos= t that RS URL including my pseudonym. If I then want to introduce a mediato= r=C2=A0in front of my AS or messaging service=C2=A0endpoint, I have that op= tion. If I want to keep requests away from the mediator, I would publish an= encryption key along with my pseudonym.

    - Adrian<= /div>



    On Mon, Mar 22, 2021 at 9:55 AM Justin R= icher <jricher@mit.edu> = wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin Kadu= k <kaduk@mit.edu> wrote: >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhk= arp@gmail.com> shared a talk about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-= gnap/gnap-core-protocol/issues/145#issuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --
    TXAuth 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
    --
    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


    --000000000000c5a5a205be7103dd-- From nobody Fri Mar 26 07:38:47 2021 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 789E53A2011 for ; Fri, 26 Mar 2021 07:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 SzdTfqCZ08-L for ; Fri, 26 Mar 2021 07:38:40 -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 89C393A200E for ; Fri, 26 Mar 2021 07:38:39 -0700 (PDT) Received: from [192.168.1.22] (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 12QEcXg9022966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Mar 2021 10:38:34 -0400 From: Justin Richer Message-Id: <497B7A43-546E-4296-916F-6D177AEBE228@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_BDBF259F-F935-4ED9-92C5-A28C097A7204" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 26 Mar 2021 10:38:33 -0400 In-Reply-To: Cc: Alan Karp , Benjamin Kaduk , Fabien Imbault , GNAP Mailing List , Mark Miller To: Adrian Gropper References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> <5773FA7B-6891-4227-A8CA-2F506909B8CD@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2021 14:38:47 -0000 --Apple-Mail=_BDBF259F-F935-4ED9-92C5-A28C097A7204 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Adrian, Yes, the RO is the party/entity which holds the rights for delegation, = and they perform that delegation to a piece of software (the client) = through the AS. The RS is what they=E2=80=99re delegating the access of, = for API-access use cases (again, user/subject information is similar but = different).=20 There isn=E2=80=99t a delegation between the RS and AS, then. You can = perhaps view them as externalizing functions that they might otherwise = hold close, but not delegating in the same way the client gets delegated = to. You can frame it one of two ways: - The RS externalizes its security, policy, authorization, and = delegation functions to the AS and looks for access tokens from the AS = as proof of that happening (this is the most in line with the model = you=E2=80=99ve been presenting) - The AS externalizes its data-API functions to into the RS and = produces access tokens for the RS to consume/validate (this is actually = the model that OAuth 2 started with, in extracting the RS as a separate = entity as opposed to OAuth 1) They tell different views of the same reality. In OAuth, it=E2=80=99s = assumed that the RO interacts with the AS directly to perform the = delegation to the client. In GNAP, we=E2=80=99ve got an opportunity to = expand that, which has been (to me) one of the biggest outcomes of this = discussion. =E2=80=94 Justin > On Mar 26, 2021, at 10:04 AM, Adrian Gropper = wrote: >=20 > Justin,=20 >=20 > Big YES to =E2=80=9C The conceptual framework of an AS that takes in = lots of different information and spits out access tokens is exactly the = abstraction layer that is necessary for making these use cases = interoperable.=E2=80=9D and probably everything else you just said.=20 >=20 > I seem to not understand the delegation design between RS and AS. In = my view, that delegation always goes through the RO, although the RO may = be forced to choose from a list provided by the RS. >=20 > In my view, GNAP, can acknowledge this and design to be agnostic to = whether the AS is specified by he RO or picked from a list of 1 or more = choices provided by the RS. >=20 > - Adrian >=20 > On Fri, Mar 26, 2021 at 9:30 AM Justin Richer > wrote: > Adrian, >=20 > I disagree, I believe that what I have laid out is exactly separating = the concerns into working components.=20 >=20 > Like OAuth before it, GNAP is a protocol negotiate access for a client = instance to an RS, using an AS as the facilitator of that delegated = negotiation. (Unlike OAuth, it=E2=80=99s importantly also for = negotiating user information to the client directly from the AS with no = RS involved, but that=E2=80=99s an aside for the purposes of our = conversation here). >=20 > If a particular GNAP RS also allows other kinds of processes to enable = access to it, that is completely fine, but outside of GNAP. If an RS = allows a username/password HTTP Basic auth in addition to accepting = access tokens, it can do so, but GNAP doesn=E2=80=99t have anything to = say about the Basic auth use, or even its relation to any access tokens = or RO=E2=80=99s or anything else. If an RS accepts structured access = tokens signed by trusted keys that don=E2=80=99t come from an AS through = a negotiated request =E2=80=94 again, that=E2=80=99s fine, but GNAP is = silent about the RS doing that. If the RS acts as =E2=80=9Cits own AS=E2=80= =9D then it=E2=80=99s really just an RS and an AS living in the same = box. Again, that=E2=80=99s fine, and super common with OAuth today.=20 >=20 > GNAP is solving the problem of connecting the client to the RS through = means of an AS. Other solutions are possible and many of them can be = deployed right alongside, but that=E2=80=99s not the corner of the world = that GNAP is solving. GNAP should be concerned about how these other = technologies can be used alongside it. I think there=E2=80=99s a lot of = room for the things that you=E2=80=99re talking about, and more = importantly for solving the use cases that you=E2=80=99re bringing. But = GNAP should be more than a single-point solution, and so we need to = balance these concerns. The conceptual framework of an AS that takes in = lots of different information and spits out access tokens is exactly the = abstraction layer that is necessary for making these use cases = interoperable. >=20 > =E2=80=94 Justin >=20 >> On Mar 26, 2021, at 8:30 AM, Adrian Gropper > wrote: >>=20 >> @Justin, there=E2=80=99s no separation of concerns here. No partition = between processor and controller. No data minimization. And, I see no = obvious reason to make this the core of GNAP.=20 >>=20 >> The one thing we can probably all agree on is that there=E2=80=99s = only one RS and one RO.=20 >>=20 >> The core of GNAP, in my opinion, can be built and explained around = this simple design. The RS is a processor. The RO is a controller. The = RS bears only security responsibility. The RS bears no privacy = responsibility. The RO delegates this to the RS but this is not = authorization as the A in GNAP. >>=20 >> The RO retains all rights to delegate within the scope of things that = the RS is willing to support using various token formats and endpoint = options. Some of these options may do all sorts of things for all sorts = of clients and user-agents but these are options.=20 >>=20 >> For example, if a request comes to the RS that is not in the form of = an access token, then it either gets sent to the RO or their agent, or = it gets logged and dumped. One such option, common in healthcare, is = =E2=80=9CBreak the Glass=E2=80=9D where the RS is acting as an = authorization server because the user-agent is making a request instead = of presenting an access token. GNAP can offer this as an option but it = is not our core. >>=20 >> Adrian >>=20 >>=20 >>=20 >> On Fri, Mar 26, 2021 at 7:15 AM Justin Richer > wrote: >> I have a big problem with this line: >>=20 >> > the RS and AS-RS only see access tokens. The requests (from RO') = that resulted in an access token are none of their business. >>=20 >> In the trust model we=E2=80=99ve been discussing, the requests that = result in access tokens are solely the business of AS-RS, since AS-RS is = the only entity that=E2=80=99s allowed, and trusted by the RS, to create = access tokens for the RS. That is its entire job, the entire reason it = exists in the system. By definition the party generating tokens for use = at the RS is the AS for that RS, I don=E2=80=99t care how you deploy it. = If RO wants to give access to someone else (who isn=E2=80=99t an =E2=80=9C= RO" anymore, they=E2=80=99re another end-user), then that end user=E2=80=99= s client software will need to talk to AS-RS to get its own access = token. >>=20 >> Now here=E2=80=99s the trick: when the end user=E2=80=99s client = instance talks to AS-RS, that does NOT mean that AS-RS needs to know all = the details and policy reasons that it should give an access token to = that client instance. It doesn=E2=80=99t even need to know the existence = of another end user. It doesn=E2=80=99t need identity, it doesn=E2=80=99t = need policy. Sure, it COULD handle all of that internally, and many = will, but the protocol doesn=E2=80=99t demand it.=20 >>=20 >> This means that the first client instance, the one that gets the = access token, can also be given something alongside the access token = that it can then hand to another piece of software (or to a person to = hand eo their piece of software). This artifact is not an access token. = This artifact could be something structured that the client understands, = and can make derivatives of, and present back to the AS-RS for getting = new access tokens. There could be multiple different flavors of this = kind of artifact for different kinds of environments and groups. But = what they all have in common is that they can potentially be used to = request more access tokens within some context at the AS-RS. >>=20 >> =E2=80=94 Justin >>=20 >>=20 >>=20 >>> On Mar 25, 2021, at 5:50 PM, Adrian Gropper > wrote: >>>=20 >>> My issue is with Alan's: >>> "7. Another user agent (RO') can contact any holder of the access = token or the service's policy agent (AS-RS) to get a delegated access = token." >>>=20 >>> I would prefer "7A. Another user agent (RO') can contact any holder = of the access token." by default so that the AS-RS does not see the = requests. In other words, the RS and AS-RS only see access tokens. The = requests (from RO') that resulted in an access token are none of their = business. >>>=20 >>> The reality is that RO' can discover a resource RS and can share = whatever information with RS-AS they want and the RO may not even know = about it unless the RS decides to let them know somehow. This seems to = be a drawback of the capabilities approach.=20 >>>=20 >>> In terms of privacy and control, I, as the RO, want a contract with = the RS that says that I or my agent (AS-RO) must sign an access token. = This is a fundamental audit requirement. Without it, a rogue RS and = AS-RS can do all sorts of things and the RO would never know. I = understand that a rogue RS might not support an honest contemporaneous = log of access tokens presented so there's a trust issue here that I = seems unavoidable unless I specify in my RO-RS contract that they use a = separate contemporaneous log such as AS-RO for every access token = presented and risk being sued if they process an access token without = also updating the separate log. >>>=20 >>> - Adrian >>>=20 >>>=20 >>> On Thu, Mar 25, 2021 at 1:22 PM Alan Karp > wrote: >>> Justin Richer > wrote: >>> Hi Alan, >>>=20 >>> In all of my discussion, and in the spec itself, the RO is the = :entity: in charge of approving rights. They=E2=80=99re probably a = person. It might be software that makes a policy decision in some way, = or a corporate entity, or something like that. But it=E2=80=99s not = assumed to be a computational agent in the terms of the protocol itself. = Would that recast what you=E2=80=99re saying below? >>>=20 >>> Hmmm. I guess not. It's just that the person would be using some = UI to express their decisions to what I called the user agent. That = model fits in very nicely with what we did with Polaris, our virus safe = computing environment for Windows XP, = https://dl.acm.org/doi/10.1145/1151030.1151033 = . The person would = click on the icon for a Word file, and an instance of Word would open = with only the permission needed to edit that one file. Same thing here. = The client could ask for permission to use the resource, or permission = could be granted implicitly when the user selects a resource associated = with a specific client. >>>=20 >>> -------------- >>> Alan Karp >>>=20 >>>=20 >>> On Thu, Mar 25, 2021 at 9:53 AM Justin Richer > wrote: >>> Hi Alan, >>>=20 >>> In all of my discussion, and in the spec itself, the RO is the = :entity: in charge of approving rights. They=E2=80=99re probably a = person. It might be software that makes a policy decision in some way, = or a corporate entity, or something like that. But it=E2=80=99s not = assumed to be a computational agent in the terms of the protocol itself. = Would that recast what you=E2=80=99re saying below? >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Mar 25, 2021, at 12:36 PM, Alan Karp > wrote: >>>>=20 >>>> There seems to be some confusion about how AS-RO comes into the = picture, probably because of the "AS" part. I'm going to try to clear = up that confusion by more carefully explaining what I mean. >>>>=20 >>>> I'm assuming that RO is a computational agent representing the = person who is the resource owner, something called the "user agent" in = operating systems lingo. I'm also assuming that it's possible to do = delegation, either locally or by token exchange with AS-RS. All = delegations are potentially sub-scoped, but you may also want to = delegate with full scope to have a separately revocable access token. >>>>=20 >>>> Here's an example of how things work in a capability oriented = system. >>>> Someone, the service owner, creates a service. >>>> The service owner contracts with an policy agent (AS-RS) to create = and manage access tokens for that service (RS). >>>> A person wishing to create a resource at RS uses their user agent = (RO) to contact the service owner's policy agent (AS-RS) and gets back = an access token for that resource. >>>> That user agent (RO) can=20 >>>> use that access token to invoke the resource, or >>>> delegate an access token to a client of the user agent's (RO) = choice, or >>>> contract with a policy agent (AS-RO) to manage those delegations on = behalf of the user agent (RO), or >>>> specify a policy with the service's policy agent (AS-RS). >>>> A client can contact any holder of the access token (the user agent = (RO) or its policy agent (AS-RO)) or the service's policy agent (AS-RS) = to get a delegated access token. >>>> That client can delegate that token to another client. >>>> Another user agent (RO') can contact any holder of the access token = or the service's policy agent (AS-RS) to get a delegated access token. >>>> The other user agent (RO') can=20 >>>> use that access token to invoke the resource, or >>>> delegate it to a client of its choice, or >>>> contract with a policy agent (AS-RO') of its choosing to manage = those delegations on its behalf, or >>>> specify a policy with the service's policy agent (AS-RS). >>>> and so on >>>> When any of these computational agents, user agents (ROs) or = clients acting on their behalf, invokes the resource, AS-RS verifies = that the access token is a valid delegation, i.e., proper sub-scoping, = hasn't been revoked, and that it authorizes the request being made = before telling the service (RS) to honor the request. At no point does = the service's policy agent (AS-RS) know which computational agent did = any particular delegation. (Token exchange can be done as anonymously = as possible.) In particular, the policy agents (AS-RO) need not be the = same, or even compatible with, the service's policy agent (AS-RS). GNAP = specifies the protocol between requesters, invokers, delegators (for = token exchange) of tokens and AS-RS. That protocol need not be used = between user agents (RO), clients, or other policy agents (AS-RO), but = it is likely to be. >>>>=20 >>>> ------------- >>>> Alan Karp >>>>=20 >>>>=20 >>>> On Thu, Mar 25, 2021 at 5:45 AM Justin Richer > wrote: >>>> The way I=E2=80=99m thinking about Adrian=E2=80=99s use case is = that what we=E2=80=99re calling the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t = an =E2=80=9CAS=E2=80=9D in the traditional OAuth/GNAP sense, at least = not exactly. This is the agent that the RO can use to set policies and = manage consent on their behalf, and I=E2=80=99ve been arguing that it = fits better into this vaguely-defined =E2=80=9Cinteraction component=E2=80= =9D aspect of the current AS definition, and it=E2=80=99s not currently = separated from the AS definition. The =E2=80=9CAS-RS=E2=80=9D maps to = what we=E2=80=99d call the =E2=80=9CAS=E2=80=9D in OAuth/GNAP = traditionally, it=E2=80=99s what the RS trusts to issue tokens. In = traditional OAuth the AS-RO and AS-RS are always the same thing, from a = functional protocol perspective. An important point here is that from a = client=E2=80=99s perspective, they=E2=80=99re only talking to the AS-RS = since that=E2=80=99s where the client gets its tokens, because at the = end of the day the client just wants to call the API at the RS and = doesn=E2=80=99t care how that happens (from a protocol standpoint).=20 >>>>=20 >>>> Note well: Even thought I don=E2=80=99t believe that =E2=80=9CAS-RO=E2= =80=9D is an authorization server at all, I=E2=80=99m going to keep = using that term below for consistency with previous discussion. >>>>=20 >>>> So we have these fundamental relationships around getting the = client to access the RS: >>>>=20 >>>> 1. RS trusts AS-RS to issue tokens that RS will accept, validate, = and process for requests from client >>>> 2. Client trusts AS-RS to issue tokens that client can use at RS >>>> 3. RO trusts RS to protect RO=E2=80=99s api through delegated = access >>>>=20 >>>> On top of that, we=E2=80=99ve got some additional aspects that = we=E2=80=99re discussing: >>>>=20 >>>> 4. RO trusts AS-RO to manage RO=E2=80=99s policies at runtime >>>> 5. AS-RS trusts AS-RO to assert RO=E2=80=99s policies for access to = RS >>>> 6. Client trusts whatever AS-RS sends client to deal with, = including possibly RO-AS at runtime, because of (2) >>>>=20 >>>> What I have been saying is that 4/5/6 are optional details of how = RS-AS runs things, and I think this also maps with Adrian=E2=80=99s view = of choice, since if my RS=E2=80=99s AS-RS doesn=E2=80=99t allow me to = plug in my own AS-RO then I would be motivated to pick a different RS = who=E2=80=99s AS-RS lets me do just that. The same way I=E2=80=99d pick = a different RS if their surrounding services didn=E2=80=99t accept my = preferred federation login and I didn=E2=80=99t want to make another = account. Of course, market forces being as they are, I might not have = much of an actionable choice in RS, but GNAP can=E2=80=99t change that.=20= >>>>=20 >>>> What we can do is make it possible for AS-RS to talk to AS-RO, both = in philosophy of the protocol design and in concrete hooks to support = (6) above.=20 >>>>=20 >>>> Separately, we can approach the issue of making 1/2 above more = dynamic. This was UMA2=E2=80=99s =E2=80=9Cfederated authorization=E2=80=9D= approach, and is behind a lot of the =E2=80=9Cbring your own AS=E2=80=9D = models out there. The problem with these is that we know from many years = of experience that most RS=E2=80=99s aren=E2=80=99t interested in doing = anything of the sort. >>>>=20 >>>> So with GNAP we can instead allow 4/5/6 to vary in a predictable = and consistent way, letting the RS keep control over 1/2, thereby = enabling choice in (3). We don=E2=80=99t have to be the ones who define = the all of the details of every permutation of (5) to enable this, = though. Some of this is going to be configuration out of band, some of = it=E2=80=99s going to be communication at runtime. This is where VC=E2=80=99= s, ZCAPs, CHAPI, DIDComm, FIDO, and a whole swath of other tech can come = in and help out. I don=E2=80=99t think we need to put all the details = for using these into core, nor do I think we=E2=80=99ll pull of The = Great And Ultimate Abstraction for using these and other approaches. But = we can at least start talking about =E2=80=9CAS-RS=E2=80=9D in such a = way that it no longer assumes it=E2=80=99s always the same party dealing = with the RO directly. >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>> On Mar 25, 2021, at 6:40 AM, Fabien Imbault = > wrote: >>>>>=20 >>>>> To reframe it closer to GNAP: >>>>> - AS =3D AS-RO, that's where you find the RO policies. The AS = issues access tokens to the client. >>>>> - the RO policies could be a) defined locally or b) in = relationship with the RS >>>>>=20 >>>>> There have been several ideas related to the AS-RS relationship b: >>>>> b1) the RS issues capabilities (which can be further attenuated by = the RO) >>>>> b2) Adrian also discussed a DID based solution >>>>> b3) there was also an alternative ACL proposal from Denis (+ = preflight) >>>>>=20 >>>>> Fabien >>>>>=20 >>>>>=20 >>>>> On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault = > wrote: >>>>> Ok so I get you correctly:=20 >>>>> - what matters is the RQ (could be a RO or a end-user or both : we = don't really care at a high-level, they're all treated as entities that = make a request) >>>>> - the policy is able to handle those different cases, based on its = own internal delegation protocol >>>>> - currently that requires AS-RS and AS-RO, but maybe it can be = simplified >>>>>=20 >>>>> To answer to Denis, here's what I understood: >>>>> - RO trusts AS-RS (and then handles its own policies within AS-RO) >>>>> - end-user trusts AS-RO (through its client) >>>>>=20 >>>>> Could probably work but that's a fairly different model compared = to OAuth2 (and of today's GNAP), with different frontiers between the AS = and the RS.=20 >>>>>=20 >>>>> Please do not hesitate to correct me if I'm wrong. >>>>>=20 >>>>> Fabien=20 >>>>>=20 >>>>> On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper = > wrote: >>>>> I believe there are alternatives to having two kinds of ASs. The = problem may be a side-effect of deciding to switch away form treating = the RO as different from the RQ. That leads to downstream privacy = issues. Our desire for architectural simplicity is admirable but that = may have been a step too far. >>>>>=20 >>>>> There may also be solutions based on different types of tokens, as = in different capabilities (tokens signed by the RS) vs. tokens signed by = the AS. I=E2=80=99m not sure about that but Alan might have more to say. >>>>>=20 >>>>> Adrian >>>>>=20 >>>>> On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault = > wrote: >>>>> Thanks. The general problem statement is clear. >>>>>=20 >>>>> The proposed solution a bit less (to me). I understood that from = point 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obvious = reason to have two types of ASs". Do you see an alternative ? >>>>>=20 >>>>> Regarding the last item, I don't think that naming RQ by end-user = created the problem. It might just highlight the asymmetry, which = fundamentally exists.=20 >>>>>=20 >>>>> Fabien >>>>>=20 >>>>>=20 >>>>> On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper = > wrote: >>>>> Recap: >>>>> 1 - Justin (I think) introduced the idea of an AS on the RS trust = boundary side. >>>>> 2 - I said the RO should not have to share policies with the RS. >>>>> 3 - Alan invented the concept of AS-RO and AS-RS to separate two = kinds of PDPs.=20 >>>>>=20 >>>>> The thing is that step 2 is not symmetrical. The RO has a = legitimate privacy interest in keeping their policies private and = minimizing the leakage of information about requests that are posed = against those policies.=20 >>>>>=20 >>>>> The RS, on the other hand, should be publishing its policies (e.g. = what it=E2=80=99s selling or what jurisdiction it=E2=80=99s in or what = tokens or scopes it supports). The RS has no obvious privacy interest in = GNAP. It=E2=80=99s just an enforcer. >>>>>=20 >>>>> There is one other privacy interest to consider around the RS and = that is the requesting party (the end-user that is not the RO :-) might = prefer to share attributes with the RS instead of the RO or something = controlled by the RO. This case could be an =E2=80=9Cextension=E2=80=9D = to GNAP and might result in a split AS as a solution. This problem was = introduced when the editors decided to replace RQ with end-user. = Obviously, the RO end-user has no privacy interests relative to itself. >>>>>=20 >>>>> Adrian >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault = > wrote: >>>>> I was referring to "By my definition, this model has two ASs since = both are processing requests into tokens". If there's no reason to have = 2 types of ASs, that's fine then.=20 >>>>> But I'm a bit lost in where we stand with the idea.=20 >>>>>=20 >>>>> Could you recap?=20 >>>>>=20 >>>>> Fabien=20 >>>>>=20 >>>>> Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper = > a =C3=A9crit : >>>>> There=E2=80=99s no obvious reason to have two types of ASs. Any AS = that is executing the policies of the RS can look to GNAP like the RS = itself. Why would GNAP expose that interface to anyone?=20 >>>>>=20 >>>>> Adrian >>>>>=20 >>>>> On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault = > wrote: >>>>> Note : I'm not sure that's a good idea, but having 2 types of ASs = is not that easy to grasp. >>>>>=20 >>>>> Fabien=20 >>>>>=20 >>>>> Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault = > a =C3=A9crit = : >>>>> The purpose of either handling policies locally or delegating them = to the RO agent.=20 >>>>>=20 >>>>> Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper = > a =C3=A9crit : >>>>> What purpose would be served by GNAP splitting the AS into two = components? >>>>>=20 >>>>> Adrian=20 >>>>>=20 >>>>> On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault = > wrote: >>>>> Isn't the AS-RO a component of the AS? Same idea as the interact = component, it functionnally belongs to the AS role but could be deployed = either as a monolith or as a separate component? >>>>>=20 >>>>> Fabien >>>>>=20 >>>>> Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper = > a =C3=A9crit : >>>>> Yes, but I would say it=E2=80=99s not the RO that wants the access = token. It=E2=80=99s the RO that wants the client making the request to = get an access token.=20 >>>>>=20 >>>>> Adrian >>>>>=20 >>>>> On Wed, Mar 24, 2021 at 11:22 PM Alan Karp > wrote: >>>>> Adrian Gropper > wrote: >>>>>=20 >>>>> In this design, the AS is the AS-RS and the agent is the AS-RO. By = my definition, this model has two ASs since both are processing requests = into tokens. The problem with this is complexity and privacy. The RO may = not want to share the request information with the AS-RS. >>>>>=20 >>>>> More precisely, RO has no choice but to present the required = information to AS-RS if RO wants an access token. However, RO does not = want AS-RS to know the policy by which RO delegates tokens. That's why = RO uses AS-RO for those delegations. >>>>>=20 >>>>> -------------- >>>>> Alan Karp >>>>>=20 >>>>>=20 >>>>> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper = > wrote: >>>>> Thank you for creating the issue. My definition of AS is = independent of AS-RO or AS-RS. = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomment= -806280421 = I also agree with Alan's definition based on delegation. An = AS-RS would be a delegate of the RS.=20 >>>>>=20 >>>>> Based on that, I see it as obvious that the policy has to be = accessible (defined locally?) in order for it to be run as the code that = turns a request into an access token.=20 >>>>>=20 >>>>> The only other possibility is that the request is packaged by the = AS and sent elsewhere (an agent) for evaluation against policy and a = proto-token returned. In that case the AS is acting as a proxy and the = PDP is elsewhere. I can imagine that an AS-RS would behave this way so = that the proto-token could be turned into an access token by the AS-RS. = Isn't this what Justin is proposing? In this design, the AS is the AS-RS = and the agent is the AS-RO. By my definition, this model has two ASs = since both are processing requests into tokens. The problem with this is = complexity and privacy. The RO may not want to share the request = information with the AS-RS. >>>>>=20 >>>>> Adrian >>>>>=20 >>>>> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault = > wrote: >>>>> Isn't that what the AS is supposed to be, only with the caveat = that the policy is defined locally?=20 >>>>>=20 >>>>> Fabien=20 >>>>>=20 >>>>>=20 >>>>> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp > a =C3=A9crit : >>>>> AS-RO is an AS that RO trusts to delegate RO's access tokens = according to RO's policies. =20 >>>>>=20 >>>>> -------------- >>>>> Alan Karp >>>>>=20 >>>>>=20 >>>>> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault = > wrote: >>>>> Hi Alan and Adrian, >>>>>=20 >>>>> I've created issue AS-RO policy delegation = (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223 = ) to = capture your input.=20 >>>>> A first question that arises: can we give a definition to AS-RO? >>>>>=20 >>>>> Thanks >>>>> Fabien >>>>>=20 >>>>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp > wrote: >>>>> Fabien Imbault > wrote: >>>>> Hi Alan,=20 >>>>>=20 >>>>> Yes, but in that flow, the token relationship between AS-RS and = AS-RO is only secure if the tokens issued by AS-RS are cryptographically = attenuable in the first place.=20 >>>>> =20 >>>>> Attenuated delegation is a requirement, but that doesn't have to = be done cryptographically. Token exchange works just fine. SPKI and = zcap-ld are examples of the crypto approach, and we used token exchange = in the system for HP. >>>>>=20 >>>>> -------------- >>>>> Alan Karp >>>>>=20 >>>>>=20 >>>>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault = > wrote: >>>>> Hi Alan,=20 >>>>>=20 >>>>> Yes, but in that flow, the token relationship between AS-RS and = AS-RO is only secure if the tokens issued by AS-RS are cryptographically = attenuable in the first place.=20 >>>>>=20 >>>>> Fabien >>>>>=20 >>>>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp > wrote: >>>>> Justin Richer > wrote: >>>>>=20 >>>>> But with all that in mind, I think the key here is going to be = looking at what the inputs to the AS are, and how those can be defined = in an interoperable way for AS=E2=80=99s that can accept them. I think = there=E2=80=99s a lot of room for innovation and flexibility here that = doesn=E2=80=99t break the trust model or core use cases. If I have an = AS-RS set that won=E2=80=99t accept my favorite flavor of policy engine = inputs, then I can decide not to use that one. But this is a very = different question than saying the RS itself needs to accept my own AS = =E2=80=94 and we can=E2=80=99t keep conflating these two models. >>>>>=20 >>>>> I agree. The point of having an AS-RO is to allow RO to specify a = policy for which of RO's access tokens should be delegated under what = conditions. AS-RS should not need to understand those policies. The = flow would be >>>>> RO contacts AS-RS and gets one or more access tokens. >>>>> RO delegates one or more of those tokens, potentially sub-scoped, = to AS-RO. >>>>> A different user contacts AS-RO to get a potentially sub-scoped = access token from AS-RO. >>>>> That user presents the access token delegated by AS-RO when = invoking the resource. >>>>> AS-RS only needs to verify that the delegation chain is = legitimate, e.g., no increase in scope, and that it grants permission = for the request being made. AS-RS does not need to understand the = policy behind granting the delegation by AS-RO. >>>>>=20 >>>>> -------------- >>>>> Alan Karp >>>>>=20 >>>>>=20 >>>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer > wrote: >>>>> Adrian, >>>>>=20 >>>>> I think this shows the problem with the terminology as it=E2=80=99s = been applied in this conversation, which I=E2=80=99ve tried to shine = light on before. What you and others are calling the =E2=80=9CRS=E2=80=9D = is really the =E2=80=9CAS and RS working together=E2=80=9D =E2=80=94 = everything to the right of the line. When Denis had brought up = =E2=80=9Celiminating the AS=E2=80=9D in another thread, what he=E2=80=99d = really done is labeled everything to the right of the line as the = =E2=80=9CRS=E2=80=9D. Of course, the irony here is that everything to = the right of the line used all be called the =E2=80=9CAS=E2=80=9D or = simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say below, I = don=E2=80=99t want the client to have visibility on what happens on that = side.=20 >>>>>=20 >>>>> Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the = diagram is not the AS, as far as GNAP is concerned. It does not issue an = access token that the RS will accept. The elements to the left of the = line could be a lot of things, but they are NOT the AS =E2=80=94 by = definition. The client lives over on the left, but so do any external = inputs to the AS. These could be policy inputs on behalf of the RO, they = could be presentation artifacts, they could be federated logins, they = could be the output of policy decisions. How the AS comes to trust those = things is up to the AS=E2=80=99s implementation. It=E2=80=99s something = we can talk about, but ultimately GNAP won=E2=80=99t be in any position = to dictate because in practice some AS=E2=80=99s are simply going to = internalize all policies and we will never successfully force those = open.=20 >>>>>=20 >>>>> But with all that in mind, I think the key here is going to be = looking at what the inputs to the AS are, and how those can be defined = in an interoperable way for AS=E2=80=99s that can accept them. I think = there=E2=80=99s a lot of room for innovation and flexibility here that = doesn=E2=80=99t break the trust model or core use cases. If I have an = AS-RS set that won=E2=80=99t accept my favorite flavor of policy engine = inputs, then I can decide not to use that one. But this is a very = different question than saying the RS itself needs to accept my own AS = =E2=80=94 and we can=E2=80=99t keep conflating these two models. >>>>>=20 >>>>> So to me, GNAP can support a Zero Trust Architecture by LEVERAGING = the AS, not by subsuming or eliminating it. It is in fact the AS, not = the client and not the RS, that will request and consume the results of = a privacy-preserving zero-trust policy query thing. Anything that = happens downstream from that is of little concern to the zero-trust = components because, as you point out, it=E2=80=99s on the =E2=80=9Cother = side=E2=80=9D of the line.=20 >>>>>=20 >>>>> I think we got this basic component model pretty right in OAuth: = the AS and RS and client working together. Where OAuth misses the mark = is the assumption that the user has to log in to the AS through a = webpage and interact directly, thereby proving they=E2=80=99re the RO. = It=E2=80=99s this latter space where I think we can both push innovation = and also address the important and compelling use cases like the ones = you=E2=80=99re bringing. >>>>>=20 >>>>> =E2=80=94 Justin >>>>>=20 >>>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper = > wrote: >>>>>>=20 >>>>>> I'm sorry, Justin. As a Resource Owner, I look at the RS trust = boundary (the dotted line in the diagram) as being the RS. I don't = expect any visibility into what's going on on the right.=20 >>>>>>=20 >>>>>> My problem with the framing you propose is that requests are = going to the RS (or the AS-RS) and I don't want to share my policies = with the AS-RS. I want to keep the RS and AS-RS as ignorant as possible. >>>>>>=20 >>>>>> Adrian >>>>>>=20 >>>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer > wrote: >>>>>> Adrian, >>>>>>=20 >>>>>> What you=E2=80=99re discussing below, in terms of logging in to a = site, is not approaching the RS. You are in fact approaching the client, = and identifying both the AS and RS to the client. The client is a client = of your identity in this model, and the RS is part of the identity = provider. It=E2=80=99s really important that we don=E2=80=99t conflate = the RS and client in this way as it leads to a lot of confusion = downstream and a lot of broken trust boundaries. >>>>>>=20 >>>>>> With that model in mind, approaching the =E2=80=9CRS" and = providing it your identity is really just a case of the =E2=80=9Cfederated= login to AS=E2=80=9D pattern that we discussed on the WG call. The user = here approaches an RS, which has its own AS. To share things from this = RS, the RO has to authenticate to the RS=E2=80=99s AS. This particular = AS allows the RO to do so using an external identity =E2=80=94 in which = case, the AS is now a =E2=80=9Cclient=E2=80=9D of a separate, = disconnected (but layered) delegation. The ultimate client that = eventually calls the RS down the way may or may not know about these = layers.=20 >>>>>>=20 >>>>>> >>>>>> This same AS, which is closely tied to the RS and trusted by the = RS, might also take in FIDO credentials, or DIDs, or any number of other = proof mechanisms. The output of this is an access token the RS trusts, = but the input is up to the AS. The RS is not what you=E2=80=99re logging = in to. >>>>>>=20 >>>>>> =E2=80=94 Justin >>>>>>=20 >>>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper = > wrote: >>>>>>>=20 >>>>>>> I too am in favor of avoiding consolidation and correlation. = Right now, when I approach a service provider (RS) for the first time, = I'm offered the opportunity to identify my persona as: email, sign-in = with Google, Facebook, or Apple. I know there are people who try to = create one-off email addresses but that is mostly a waste of time.=20 >>>>>>>=20 >>>>>>> So, along come FIDO2 and DID wallets to the rescue. Now, in = theory, I have a way to start out my RS relationship pseudonymously.=20 >>>>>>>=20 >>>>>>> When I want my resource to be discovered or shared I will post = that RS URL including my pseudonym. If I then want to introduce a = mediator in front of my AS or messaging service endpoint, I have that = option. If I want to keep requests away from the mediator, I would = publish an encryption key along with my pseudonym. >>>>>>>=20 >>>>>>> - Adrian >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer > wrote: >>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk > wrote: >>>>>>> >=20 >>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper = wrote: >>>>>>> >> @Alan Karp > = shared a talk about the Principle Of Least >>>>>>> >> Authority (POLA) in a recent comment >>>>>>> >> = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment= -803099693 = >>>>>>> >> I recommend it. >>>>>>> >>=20 >>>>>>> >> We might expect a protocol with authorization in the title to = use authority >>>>>>> >> as a core principle. I advocate for a GNAP design that = maximizes the power >>>>>>> >> of the RO, to be seen as a human rights issue when the RO is = a human. This >>>>>>> >> causes me to ask how to combine better security with better = human rights in >>>>>>> >> GNAP. >>>>>>> >>=20 >>>>>>> >> Who should have the least authority in the GNAP design? >>>>>>> >>=20 >>>>>>> >> The AS derives authority as a delegate of the RO. If we ask = the RO to >>>>>>> >> partition limited authority across dozens of different ASs by = domain and >>>>>>> >> function, then we are not using technology to empower the = individual. >>>>>>> >> Probably the opposite, as we introduce consent fatigue and = burden normal >>>>>>> >> people to partition their lives into non-overlapping domains. >>>>>>> >>=20 >>>>>>> >> My experience says we should aim for one AS per persona = because that maps >>>>>>> >> into the way we manage our public and private identities. = POLA would then >>>>>>> >> teach care in keeping ASs and RSs related to work / public = separate from >>>>>>> >> ASs and RSs related to private life so that a policy = vulnerability in our >>>>>>> >> delegation to an AS would have the least likelihood of harm. >>>>>>> >=20 >>>>>>> > Thinking about how least authority/least privilege would apply = to GNAP >>>>>>> > seems like a useful exercise. I do want to point out some = potential >>>>>>> > pitfalls with one-AS-per-persona that we can also be aware of. = If >>>>>>> > one-AS-per-persona becomes one-persona-per-AS as well, then = the AS's >>>>>>> > identity in effect also serves as a persona identity and there = are privacy >>>>>>> > considerations to that. If, on the other hand, the >>>>>>> > multiple-personas-per-AS (presumably corresponding to multiple = humans) >>>>>>> > route is taken, we should consider whether that would lead to = various >>>>>>> > (e.g., market) forces driving consolidation to just a handful = of >>>>>>> > super-popular AS services. That topic is a current matter of = concern to >>>>>>> > some IETF participants. >>>>>>> >=20 >>>>>>>=20 >>>>>>> Hi Ben, big +1 to this. This is something that we discussed ages = ago in the UMA working group, and it=E2=80=99s one of the biggest = problems with the personal AS (and personal data store) model. This kind = of thing makes RS-first trust models really difficult in practice. >>>>>>>=20 >>>>>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve got software = that wants to access my medical information. It calls an RS and requests = access, but it hasn=E2=80=99t been granted anything yet. Now I as the RO = have set up the RS so that it talks to my personal AS, that only I use. = In addition to the RS having to be able to figure out which medical = records are being requested from the context of the unauthenticated = request (which means it needs identifiers in the URL or something = similar for the RS to be able to tell, assuming that it protects data = for more than one person). So this client software doesn=E2=80=99t know = who I am and doesn=E2=80=99t know my medical record information, makes a = completely unauthorized request to the RS, and the RS says =E2=80=9CGo = to Justin=E2=80=99s personal AS to get a token=E2=80=9D. The client can = now make a direct correlation between the data that=E2=80=99s being = protected at the RS and the person running the AS that protects it. = Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This = is a design feature in the good case, and terrifying in the bad case. >>>>>>>=20 >>>>>>> If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, = please talk to the Medicine Doctor AS to get access=E2=80=9D, we = haven=E2=80=99t exposed anything at all. And from the perspective of = both the patient and the RS, this is more privacy-preserving, and it=E2=80= =99s really the least surprising option. Once the client gets to the AS, = it can start a negotiation of figuring out who the RO is for the = information being accessed. >>>>>>>=20 >>>>>>> On top of this, the usability expectations of people managing = their own AS, or set of AS=E2=80=99s for multiple personas to keep = things separate, is a huge burden. Even in the tech community, I know = people who can=E2=80=99t reliably manage more than one email address for = different purposes. I wouldn=E2=80=99t expect my partner to do that =E2=80= =94 they have trouble enough balancing all the logins and sessions = required for different kids remote schooling, I couldn=E2=80=99t imagine = them having to understand all the requirements for managing multiple = authorization servers and associated policies. I also don=E2=80=99t = expect any person to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve = been on the internet for decades and I can barely keep tabs on my GPG = keys, and only use them when I am forced to. This is exactly the kind of = =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions above, = people will just want to outsource that to someone else, and the reality = will be a few popular providers. >>>>>>>=20 >>>>>>> In which case, we could end up doing a ton of work to allow an = RS choice only to end up with a world where the RS ends up making a = limited choice anyway. We see how that plays out with OpenID Connect =E2=80= =94 RP=E2=80=99s could allow arbitrary IdPs but they choose Google = because it works and that=E2=80=99s where the users are. (And that=E2=80=99= s not to say anything of the proprietary OIDC-like protocols, but = that=E2=80=99s another discussion). >>>>>>>=20 >>>>>>> For further reading on these topics, I recommend both =E2=80=9CWhy= Johnny Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems = Fail=E2=80=9D. >>>>>>>=20 >>>>>>> So what does this have to do with GNAP? I think we can be = clear-eyed on what kinds of expectations we have for the participants. = If we expect users (RO=E2=80=99s) to have to set up the AS-RS = relationship, or expect them to carry their AS, or manage their personal = keys =E2=80=94 I think we=E2=80=99ve lost the battle for relevance. >>>>>>>=20 >>>>>>> =E2=80=94 Justin >>>>>>=20 >>>>>=20 >>>>> --=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 = >>>>> --=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 = >>=20 >=20 --Apple-Mail=_BDBF259F-F935-4ED9-92C5-A28C097A7204 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Adrian,

    Yes, the RO is the party/entity which holds the rights for = delegation, and they perform that delegation to a piece of software (the = client) through the AS. The RS is what they=E2=80=99re delegating the = access of, for API-access use cases (again, user/subject information is = similar but different). 

    There isn=E2=80=99t a delegation = between the RS and AS, then. You can perhaps view them as externalizing = functions that they might otherwise hold close, but not delegating in = the same way the client gets delegated to. You can frame it one of two = ways:

     - = The RS externalizes its security, policy, authorization, and delegation = functions to the AS and looks for access tokens from the AS as proof of = that happening (this is the most in line with the model you=E2=80=99ve = been presenting)
     - The AS externalizes its = data-API functions to into the RS and produces access tokens for the RS = to consume/validate (this is actually the model that OAuth 2 started = with, in extracting the RS as a separate entity as opposed to OAuth = 1)

    They tell = different views of the same reality. In OAuth, it=E2=80=99s assumed that = the RO interacts with the AS directly to perform the delegation to the = client. In GNAP, we=E2=80=99ve got an opportunity to expand that, which = has been (to me) one of the biggest outcomes of this = discussion.

     =E2=80=94 Justin

    On Mar = 26, 2021, at 10:04 AM, Adrian Gropper <agropper@healthurl.com> wrote:

    Justin, 

    Big YES to =E2=80=9C The conceptual framework of an AS that = takes in lots of different information and spits out access tokens is = exactly the abstraction layer that is necessary for making these use = cases interoperable.=E2=80=9D and probably everything else you just = said. 

    I seem to not understand the delegation design = between RS and AS. In my view, that delegation always goes through the = RO, although the RO may be forced to choose from a list provided by the = RS.

    In my view, GNAP, can acknowledge this and = design to be agnostic to whether the AS is specified by he RO or picked = from a list of 1 or more choices provided by the RS.

    - Adrian

    On Fri, Mar = 26, 2021 at 9:30 AM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    I = disagree, I believe that what I have laid out is exactly separating the = concerns into working components. 

    Like OAuth before it, GNAP is a = protocol negotiate access for a client instance to an RS, using an AS as = the facilitator of that delegated negotiation. (Unlike OAuth, it=E2=80=99s= importantly also for negotiating user information to the client = directly from the AS with no RS involved, but that=E2=80=99s an aside = for the purposes of our conversation here).

    If a particular GNAP RS also allows = other kinds of processes to enable access to it, that is completely = fine, but outside of GNAP. If an RS allows a username/password HTTP = Basic auth in addition to accepting access tokens, it can do so, but = GNAP doesn=E2=80=99t have anything to say about the Basic auth use, or = even its relation to any access tokens or RO=E2=80=99s or anything else. = If an RS accepts structured access tokens signed by trusted keys that = don=E2=80=99t come from an AS through a negotiated request =E2=80=94 = again, that=E2=80=99s fine, but GNAP is silent about the RS doing that. = If the RS acts as =E2=80=9Cits own AS=E2=80=9D then it=E2=80=99s really = just an RS and an AS living in the same box. Again, that=E2=80=99s fine, = and super common with OAuth today. 

    GNAP is solving the problem of = connecting the client to the RS through means of an AS. Other solutions = are possible and many of them can be deployed right alongside, but = that=E2=80=99s not the corner of the world that GNAP is solving. GNAP = should be concerned about how these other technologies can be used = alongside it. I think there=E2=80=99s a lot of room for the things that = you=E2=80=99re talking about, and more importantly for solving the use = cases that you=E2=80=99re bringing. But GNAP should be more than a = single-point solution, and so we need to balance these concerns. The = conceptual framework of an AS that takes in lots of different = information and spits out access tokens is exactly the abstraction layer = that is necessary for making these use cases = interoperable.

     =E2=80= =94 Justin

    On Mar 26, 2021, at 8:30 AM, = Adrian Gropper <agropper@healthurl.com> = wrote:

    @Justin, there=E2=80=99s no separation of concerns here. No = partition between processor and controller. No data minimization. And, I = see no obvious reason to make this the core of GNAP. 

    The one thing we can probably all agree on is that there=E2=80=99= s only one RS and one RO. 

    The core of GNAP, in = my opinion, can be built and explained around this simple design. = The RS is a processor. The RO is a controller. The RS bears only = security responsibility. The RS bears no privacy responsibility. The RO = delegates this to the RS but this is not authorization as the A in = GNAP.

    The RO retains all rights to delegate within the = scope of things that the RS is willing to support using various token = formats and endpoint options. Some of these options may do all sorts of = things for all sorts of clients and user-agents  but these are = options. 

    For example, if a request comes to the RS that = is not in the form of an access token, then it either gets sent to the = RO or their agent, or it gets logged and dumped. One such option, common = in healthcare, is =E2=80=9CBreak the Glass=E2=80=9D where the RS is = acting as an authorization server because the user-agent is making a = request instead of presenting an access token. GNAP can offer this as an = option but it is not our core.

    Adrian



    On Fri, Mar = 26, 2021 at 7:15 AM Justin Richer <jricher@mit.edu> wrote:
    I have a big problem with this = line:

    > the RS and AS-RS only see access tokens. The requests (from = RO') that resulted in an access token are none of their = business.

    In the trust = model we=E2=80=99ve been discussing, the requests that result in access = tokens are solely the business of AS-RS, since AS-RS = is the only entity that=E2=80=99s allowed, and trusted by the RS, to = create access tokens for the RS. That is its entire job, the entire = reason it exists in the system. By definition the party generating = tokens for use at the RS is the AS for that RS, I don=E2=80=99t care how = you deploy it. If RO wants to give access to someone else (who isn=E2=80=99= t an =E2=80=9CRO" anymore, they=E2=80=99re another end-user), then that = end user=E2=80=99s client software will need to talk to AS-RS to get its = own access token.

    Now = here=E2=80=99s the trick: when the end user=E2=80=99s client instance = talks to AS-RS, that does NOT mean that AS-RS needs to know all the = details and policy reasons that it should give an access token to that = client instance. It doesn=E2=80=99t even need to know the existence of = another end user. It doesn=E2=80=99t need identity, it doesn=E2=80=99t = need policy. Sure, it COULD handle all of that internally, and many = will, but the protocol doesn=E2=80=99t demand it. 

    This means that the = first client instance, the one that gets the access token, can also be = given something alongside the access token that it can then hand to = another piece of software (or to a person to hand eo their piece of = software). This artifact is not an access token. This artifact could be = something structured that the client understands, and can make = derivatives of, and present back to the AS-RS for getting new access = tokens. There could be multiple different flavors of this kind of = artifact for different kinds of environments and groups. But what they = all have in common is that they can potentially be used to request more = access tokens within some context at the AS-RS.

     =E2=80= =94 Justin



    On Mar 25, 2021, at 5:50 PM, = Adrian Gropper <agropper@healthurl.com> = wrote:

    My issue is with = Alan's:
    "7. Another = user agent (RO') can contact any holder of the access token or the = service's policy agent (AS-RS) to get a delegated access = token."

    I would prefer = "7A. Another user agent (RO') can contact any holder of the = access token." by default so that the AS-RS does not see the requests. = In other words, the RS and AS-RS only see access tokens. The requests = (from RO') that resulted in an access token are none of their = business.

    The reality is that = RO' can discover a resource RS and can share whatever information with = RS-AS they want and the RO may not even know about it unless the RS = decides to let them know somehow. This seems to be a drawback of the = capabilities approach. 

    In terms of privacy = and control, I, as the RO, want a contract with the RS that says = that I or my agent (AS-RO) must sign an access token. This is a = fundamental audit requirement. Without it, a rogue RS and AS-RS can do = all sorts of things and the RO would never know. I understand that a = rogue RS might not support an honest contemporaneous log of access = tokens presented so there's a trust issue here that I seems unavoidable = unless I specify in my RO-RS contract that they use a separate = contemporaneous log such as AS-RO for every access token presented = and risk being sued if they process an access token without also = updating the separate log.

    - = Adrian


    On Thu, Mar = 25, 2021 at 1:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin = Richer <jricher@mit.edu> wrote:
    Hi Alan,
    In all of my discussion, and in the = spec itself, the RO is the :entity: in charge of approving rights. = They=E2=80=99re probably a person. It might be software that makes a = policy decision in some way, or a corporate entity, or something like = that. But it=E2=80=99s not assumed to be a computational agent in the = terms of the protocol itself. Would that recast what you=E2=80=99re = saying below?

    Hmmm.  I guess = not.  It's just that the person would be using some UI to express = their decisions to what I called the user agent.  That model fits = in very nicely with what we did with Polaris, our virus safe computing = environment for Windows XP, https://dl.acm.org/doi/10.1145/1151030.1151033.  The = person would click on the icon for a Word file, and an instance of Word = would open with only the permission needed to edit that one file.  = Same thing here.  The client could ask for permission to use the = resource, or permission could be granted implicitly when the user = selects a resource associated with a specific client.

    --------------
    Alan = Karp


    On Thu, Mar = 25, 2021 at 9:53 AM Justin Richer <jricher@mit.edu> wrote:
    Hi Alan,
    In all of my discussion, and in the = spec itself, the RO is the :entity: in charge of approving rights. = They=E2=80=99re probably a person. It might be software that makes a = policy decision in some way, or a corporate entity, or something like = that. But it=E2=80=99s not assumed to be a computational agent in the = terms of the protocol itself. Would that recast what you=E2=80=99re = saying below?

     =E2=80=94 Justin

    On Mar = 25, 2021, at 12:36 PM, Alan Karp <alanhkarp@gmail.com> wrote:

    There seems to be some confusion = about how AS-RO comes into the picture, probably because of the "AS" = part.  I'm going to try to clear up that confusion by more = carefully explaining what I mean.

    I'm assuming that RO is a computational agent representing = the person who is the resource owner, something called the "user agent" = in operating systems lingo.  I'm also assuming that it's possible = to do delegation, either locally or by token exchange with AS-RS.  = All delegations are potentially sub-scoped, but you may also want to = delegate with full scope to have a separately revocable access = token.

      = Here's an example of how things work in a capability oriented system.
    1. Someone, = the service owner, creates a service.
    2. The service = owner contracts with an policy agent (AS-RS) to create and manage access = tokens for that service (RS).
    3. A person wishing to = create a resource at RS uses their user agent (RO) to contact the = service owner's policy agent (AS-RS) and gets back an access token for = that resource.
    4. That user agent (RO) can 
      1. use that access token to invoke the resource, = or
      2. delegate an access token to a client of the user = agent's (RO) choice, or
      3. contract with a policy agent = (AS-RO) to manage those delegations on behalf of the user agent (RO), = or
      4. specify a policy with the service's policy agent = (AS-RS).
    5. A client can contact any holder of the = access token (the user agent (RO) or its policy agent (AS-RO)) or the = service's policy agent (AS-RS) to get a delegated access token.
    6. That client can delegate that token to another = client.
    7. Another user agent (RO') can contact any = holder of the access token or the service's policy agent (AS-RS) to get = a delegated access token.
    8. The other user agent (RO') = can 
      1. use that access token to = invoke the resource, or
      2. delegate it to a client of = its choice, or
      3. contract with a policy agent (AS-RO') = of its choosing to manage those delegations on its behalf, or
      4. specify a policy with the service's policy agent = (AS-RS).
    9. and so on
    When any of these = computational agents, user agents (ROs) or clients acting on their = behalf, invokes the resource, AS-RS verifies that the access token is a = valid delegation, i.e., proper sub-scoping, hasn't been revoked, and = that it authorizes the request being made before telling the service = (RS) to honor the request.  At no point does the service's policy = agent (AS-RS) know which computational agent did any particular = delegation.  (Token exchange can be done as anonymously as = possible.)  In particular, the policy agents (AS-RO) need not be = the same, or even compatible with, the service's policy agent = (AS-RS).  GNAP specifies the protocol between requesters, invokers, = delegators (for token exchange) of tokens and AS-RS.  That protocol = need not be used between user agents (RO), clients, or other policy = agents (AS-RO), but it is likely to be.

     -------------
    Alan Karp


    On Thu, Mar = 25, 2021 at 5:45 AM Justin Richer <jricher@mit.edu> wrote:
    The way I=E2=80=99m = thinking about Adrian=E2=80=99s use case is that what we=E2=80=99re = calling the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an =E2=80=9CAS=E2=80=9D = in the traditional OAuth/GNAP sense, at least not exactly. This is the = agent that the RO can use to set policies and manage consent on their = behalf, and I=E2=80=99ve been arguing that it fits better into this = vaguely-defined =E2=80=9Cinteraction component=E2=80=9D aspect of the = current AS definition, and it=E2=80=99s not currently separated from the = AS definition. The =E2=80=9CAS-RS=E2=80=9D maps to what we=E2=80=99d = call the =E2=80=9CAS=E2=80=9D in OAuth/GNAP traditionally, it=E2=80=99s = what the RS trusts to issue tokens. In traditional OAuth the AS-RO and = AS-RS are always the same thing, from a functional protocol perspective. = An important point here is that from a client=E2=80=99s perspective, = they=E2=80=99re only talking to the AS-RS since that=E2=80=99s where the = client gets its tokens, because at the end of the day the client just = wants to call the API at the RS and doesn=E2=80=99t care how that = happens (from a protocol standpoint). 

    Note well: Even thought I don=E2=80=99t = believe that =E2=80=9CAS-RO=E2=80=9D is an authorization server at all, = I=E2=80=99m going to keep using that term below for consistency with = previous discussion.

    So we have these fundamental relationships around getting the = client to access the RS:

    1. RS trusts AS-RS to issue tokens that RS will = accept, validate, and process for requests from client
    2. Client trusts AS-RS to issue tokens that client = can use at RS
    3. RO trusts RS to protect RO=E2=80=99s= api through delegated access

    On top of that, we=E2=80=99ve got some = additional aspects that we=E2=80=99re discussing:
    4. RO trusts AS-RO to manage = RO=E2=80=99s policies at runtime
    5. AS-RS trusts AS-RO to assert RO=E2=80=99= s policies for access to RS
    6. Client trusts = whatever AS-RS sends client to deal with, including possibly = RO-AS at runtime, because of (2)

    What I have been saying is that 4/5/6 = are optional details of how RS-AS runs things, and I think this also = maps with Adrian=E2=80=99s view of choice, since if my RS=E2=80=99s = AS-RS doesn=E2=80=99t allow me to plug in my own AS-RO then I would be = motivated to pick a different RS who=E2=80=99s AS-RS lets me do just = that. The same way I=E2=80=99d pick a different RS if their surrounding = services didn=E2=80=99t accept my preferred federation login and I = didn=E2=80=99t want to make another account. Of course, market forces = being as they are, I might not have much of an actionable choice in RS, = but GNAP can=E2=80=99t change that. 

    What we can do is make it possible for = AS-RS to talk to AS-RO, both in philosophy of the protocol design and in = concrete hooks to support (6) above. 

    Separately, we can approach the issue = of making 1/2 above more dynamic. This was UMA2=E2=80=99s =E2=80=9Cfederat= ed authorization=E2=80=9D approach, and is behind a lot of the =E2=80=9Cbr= ing your own AS=E2=80=9D models out there. The problem with these is = that we know from many years of experience that most RS=E2=80=99s = aren=E2=80=99t interested in doing anything of the sort.

    So with GNAP we can = instead allow 4/5/6 to vary in a predictable and consistent way, letting = the RS keep control over 1/2, thereby enabling choice in (3). We don=E2=80= =99t have to be the ones who define the all of the details of every = permutation of (5) to enable this, though. Some of this is going to be = configuration out of band, some of it=E2=80=99s going to be = communication at runtime. This is where VC=E2=80=99s, ZCAPs, CHAPI, = DIDComm, FIDO, and a whole swath of other tech can come in and help out. = I don=E2=80=99t think we need to put all the details for using these = into core, nor do I think we=E2=80=99ll pull of The Great And Ultimate = Abstraction for using these and other approaches. But we can at least = start talking about =E2=80=9CAS-RS=E2=80=9D in such a way that it no = longer assumes it=E2=80=99s always the same party dealing with the RO = directly.

     =E2=80=94 Justin

    On Mar = 25, 2021, at 6:40 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    To reframe it = closer to GNAP:
    - AS =3D AS-RO, that's where you find the = RO policies. The AS issues access tokens to the client.
    - the RO policies could be a) defined locally or b) in = relationship with the RS

    There have been several ideas related to the AS-RS = relationship b:
    b1) the RS issues = capabilities (which can be further attenuated by the RO)
    b2) Adrian also discussed a DID based solution
    b3) there was also an alternative ACL proposal from Denis (+ = preflight)

    Fabien


    On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Ok so I get = you correctly: 
    - what matters is the RQ (could be a = RO or a end-user or both : we don't really care at a high-level, they're = all treated as entities that make a request)
    - the = policy is able to handle those different cases, based on its own = internal delegation protocol
    - currently that = requires AS-RS and AS-RO, but maybe it can be simplified

    To answer to Denis, = here's what I understood:
    - RO trusts AS-RS (and = then handles its own policies within AS-RO)
    - end-user trusts AS-RO (through its client)

    Could probably work but = that's a fairly different model compared to OAuth2 (and of today's = GNAP), with different frontiers between the AS and the = RS. 

    Please= do not hesitate to correct me if I'm wrong.

    Fabien 

    On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper = <agropper@healthurl.com> wrote:
    I believe = there are alternatives to having two kinds of ASs. The problem may be a = side-effect of deciding to switch away form treating the RO as different = from the RQ. That leads to downstream privacy issues. Our desire for = architectural simplicity is admirable but that may have been a step too = far.

    There may also be solutions based on different = types of tokens, as in different capabilities (tokens signed by the RS) = vs. tokens signed by the AS. I=E2=80=99m not sure about that but Alan = might have more to say.

    Adrian

    On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Thanks. The = general problem statement is clear.

    The proposed solution a bit less = (to me). I understood that from point 2, Alan involves 2 ASs. You said : = "There=E2=80=99s no = obvious reason to have two types of ASs". Do you see an = alternative ?

    Regarding the last item, I don't = think that naming RQ by end-user created the problem. It might just = highlight the asymmetry, which fundamentally = exists. 

    Fabien


    On Thu, Mar = 25, 2021 at 8:48 AM Adrian Gropper <agropper@healthurl.com> wrote:
    Recap:
    1 - Justin (I think) = introduced the idea of an AS on the RS trust boundary side.
    2 - I said the RO should not have to share = policies with the RS.
    3 - Alan = invented the concept of AS-RO and AS-RS to separate two kinds of = PDPs. 

    The thing is that step 2 is not symmetrical. The = RO has a legitimate privacy interest in keeping their policies private = and minimizing the leakage of information about requests that are posed = against those policies. 

    The RS, on the other hand, = should be publishing its policies (e.g. what it=E2=80=99s selling or = what jurisdiction it=E2=80=99s in or what tokens or scopes it supports). = The RS has no obvious privacy interest in GNAP. It=E2=80=99s just an = enforcer.

    There is one other privacy interest to consider = around the RS and that is the requesting party (the end-user that is not = the RO :-) might prefer to share attributes with the RS instead of the = RO or something controlled by the RO. This case could be an = =E2=80=9Cextension=E2=80=9D to GNAP and might result in a split AS as a = solution. This problem was introduced when the editors decided to = replace RQ with end-user. Obviously, the RO end-user has no privacy = interests relative to itself.

    Adrian




    On Thu, Mar = 25, 2021 at 3:24 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    I was referring to "By my definition, this model has two ASs since both are = processing requests into tokens". If there's no reason to have 2 types = of ASs, that's fine then. 
    But I'm a bit lost in where we stand with the = idea. 

    Could = you recap? 

    Fabien 

    Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper = <agropper@healthurl.com> a =C3=A9crit :
    There=E2=80=99= s no obvious reason to have two types of ASs. Any AS that is executing = the policies of the RS can look to GNAP like the RS itself. Why would = GNAP expose that interface to anyone? 

    Adrian

    On Thu, Mar = 25, 2021 at 3:11 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Note : I'm = not sure that's a good idea, but having 2 types of ASs is not that easy = to grasp.

    Fabien 

    Le jeu. 25 = mars 2021 =C3=A0 08:07, Fabien Imbault <fabien.imbault@gmail.com> a = =C3=A9crit :
    The purpose = of either handling policies locally or delegating them to the RO = agent. 

    Le jeu. 25 mars 2021 =C3=A0 08:04, = Adrian Gropper <agropper@healthurl.com> a =C3=A9crit :
    What purpose = would be served by GNAP splitting the AS into two components?

    Adrian 

    On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Isn't the = AS-RO a component of the AS? Same idea as the interact component, it = functionnally belongs to the AS role but could be deployed either as a = monolith or as a separate component?

    Fabien

    Le jeu. 25 = mars 2021 =C3=A0 04:26, Adrian Gropper <agropper@healthurl.com> = a =C3=A9crit :
    Yes, but I = would say it=E2=80=99s not the RO that wants the access token. It=E2=80=99= s the RO that wants the client making the request to get an access = token. 

    Adrian

    On Wed, Mar = 24, 2021 at 11:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Adrian = Gropper <agropper@healthurl.com> wrote:

    In this = design, the AS is the AS-RS and the agent is the AS-RO. By my = definition, this model has two ASs since both are processing requests = into tokens. The problem with this is complexity and privacy. The RO may = not want to share the request information with the AS-RS.

    More precisely, RO has = no choice but to present the required information to AS-RS if RO wants = an access token.  However, RO does not want AS-RS to know the = policy by which RO delegates tokens.  That's why RO uses AS-RO for = those delegations.

    --------------
    Alan Karp


    On Wed, Mar = 24, 2021 at 7:41 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Thank you for creating the issue. My definition = of AS is independent of AS-RO or AS-RS. https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#i= ssuecomment-806280421 I also agree with Alan's definition based on = delegation. An AS-RS would be a delegate of the RS. 

    Based on = that, I see it as obvious that the policy has to be accessible = (defined locally?) in order for it to be run as the code that turns a = request into an access token. 

    The only other possibility is that the = request is packaged by the AS and sent elsewhere (an agent) for = evaluation against policy and a proto-token returned. In that case the = AS is acting as a proxy and the PDP is elsewhere. I can imagine that an = AS-RS would behave this way so that the proto-token could be turned into = an access token by the AS-RS. Isn't this what Justin is proposing? In = this design, the AS is the AS-RS and the agent is the AS-RO. By my = definition, this model has two ASs since both are processing requests = into tokens. The problem with this is complexity and privacy. The RO may = not want to share the request information with the AS-RS.

    Adrian

    On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Isn't that what the AS is supposed to be, only with the = caveat that the policy is defined locally? 

    Fabien 


    Le mer. 24 = mars 2021 =C3=A0 20:17, Alan Karp <alanhkarp@gmail.com> a =C3=A9crit :
    AS-RO is an AS that RO trusts to delegate RO's = access tokens according to RO's policies.  

    --------------
    Alan Karp


    On Wed, Mar 24, 2021 at 9:36 AM Fabien = Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan and = Adrian,

    I've created = issue AS-RO policy delegation (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to capture your input. 
    A first question = that arises: can we give a definition to AS-RO?

    Thanks
    Fabien

    On Tue, Mar = 23, 2021 at 4:15 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi = Alan, 

    Yes, but = in that flow, the token relationship between AS-RS and AS-RO is only = secure if the tokens issued by AS-RS are cryptographically attenuable in = the first place. 
     
    Attenuated delegation is a requirement, but that doesn't have = to be done cryptographically.  Token exchange works just = fine.  SPKI and zcap-ld are examples of the crypto approach, and we = used token exchange in the system for HP.

    --------------
    Alan = Karp


    On Tue, Mar = 23, 2021 at 4:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi = Alan, 

    Yes, but = in that flow, the token relationship between AS-RS and AS-RO is only = secure if the tokens issued by AS-RS are cryptographically attenuable in = the first place. 

    Fabien

    On Mon, Mar = 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin = Richer <jricher@mit.edu> wrote:

    But with all that in mind, I think the = key here is going to be looking at what the inputs to the AS are, and = how those can be defined in an interoperable way for AS=E2=80=99s that = can accept them. I think there=E2=80=99s a lot of room for innovation = and flexibility here that doesn=E2=80=99t break the trust model or core = use cases. If I have an AS-RS set that won=E2=80=99t accept my favorite = flavor of policy engine inputs, then I can decide not to use that one. = But this is a very different question than saying the RS itself needs to = accept my own AS =E2=80=94 and we can=E2=80=99t keep conflating these = two models.

    I agree.  The = point of having an AS-RO is to allow RO to specify a policy for which of = RO's access tokens should be delegated under what conditions.  = AS-RS should not need to understand those policies.  The flow would = be
    • RO contacts AS-RS = and gets one or more access tokens.
    • RO delegates one = or more of those tokens, potentially sub-scoped, to AS-RO.
    • A different user contacts AS-RO to get a potentially = sub-scoped access token from AS-RO.
    • That user = presents the access token delegated by AS-RO when invoking the = resource.
    AS-RS only = needs to verify that the delegation chain is legitimate, e.g., no = increase in scope, and that it grants permission for the request being = made.  AS-RS does not need to understand the policy behind granting = the delegation by AS-RO.

    --------------
    Alan Karp


    On Mon, Mar 22, 2021 at 11:40 AM Justin = Richer <jricher@mit.edu> wrote:
    Adrian,

    I think this shows the problem with the = terminology as it=E2=80=99s been applied in this conversation, which = I=E2=80=99ve tried to shine light on before. What you and others are = calling the =E2=80=9CRS=E2=80=9D is really the =E2=80=9CAS and RS = working together=E2=80=9D =E2=80=94 everything to the right of the line. = When Denis had brought up =E2=80=9Celiminating the AS=E2=80=9D in = another thread, what he=E2=80=99d really done is labeled everything to = the right of the line as the =E2=80=9CRS=E2=80=9D. Of course, the irony = here is that everything to the right of the line used all be called the = =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 = days. As you say below, I don=E2=80=99t want the client to have = visibility on what happens on that side. 

    Note well: The Google+ logo labeled = =E2=80=9CIdP=E2=80=9D in the diagram is not the AS, as far as GNAP is = concerned. It does not issue an access token that the RS will accept. = The elements to the left of the line could be a lot of things, but they = are NOT the AS =E2=80=94 by definition. The client lives over on the = left, but so do any external inputs to the AS. These could be policy = inputs on behalf of the RO, they could be presentation artifacts, they = could be federated logins, they could be the output of policy decisions. = How the AS comes to trust those things is up to the AS=E2=80=99s = implementation. It=E2=80=99s something we can talk about, but ultimately = GNAP won=E2=80=99t be in any position to dictate because in practice = some AS=E2=80=99s are simply going to internalize all policies and we = will never successfully force those open. 

    But with all that in mind, I think the = key here is going to be looking at what the inputs to the AS are, and = how those can be defined in an interoperable way for AS=E2=80=99s that = can accept them. I think there=E2=80=99s a lot of room for innovation = and flexibility here that doesn=E2=80=99t break the trust model or core = use cases. If I have an AS-RS set that won=E2=80=99t accept my favorite = flavor of policy engine inputs, then I can decide not to use that one. = But this is a very different question than saying the RS itself needs to = accept my own AS =E2=80=94 and we can=E2=80=99t keep conflating these = two models.

    So = to me, GNAP can support a Zero Trust Architecture by LEVERAGING the AS, = not by subsuming or eliminating it. It is in fact the AS, not the client = and not the RS, that will request and consume the results of a = privacy-preserving zero-trust policy query thing. Anything that happens = downstream from that is of little concern to the zero-trust components = because, as you point out, it=E2=80=99s on the =E2=80=9Cother side=E2=80=9D= of the line. 

    I think we got this basic component model pretty right in = OAuth: the AS and RS and client working together. Where OAuth misses the = mark is the assumption that the user has to log in to the AS through a = webpage and interact directly, thereby proving they=E2=80=99re the RO. = It=E2=80=99s this latter space where I think we can both push innovation = and also address the important and compelling use cases like the ones = you=E2=80=99re bringing.

     =E2=80=94 Justin

    On Mar = 22, 2021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I'm sorry, Justin. As a Resource = Owner, I look at the RS trust boundary (the dotted line in the diagram) = as being the RS. I don't expect any visibility into what's going on on = the right. 

    My problem with the framing you propose is that requests are = going to the RS (or the AS-RS) and I don't want to share my policies = with the AS-RS. I want to keep the RS and AS-RS as ignorant as = possible.

    Adrian

    On Mon, Mar = 22, 2021 at 1:48 PM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    What you=E2=80=99re discussing below, = in terms of logging in to a site, is not approaching the RS. You are in = fact approaching the client, and identifying both the AS and RS to the = client. The client is a client of your identity in = this model, and the RS is part of the identity provider. It=E2=80=99s = really important that we don=E2=80=99t conflate the RS and client in = this way as it leads to a lot of confusion downstream and a lot of = broken trust boundaries.

    With that model in mind, approaching the =E2=80=9CRS" and = providing it your identity is really just a case of the =E2=80=9Cfederated= login to AS=E2=80=9D pattern that we discussed on the WG call. The user = here approaches an RS, which has its own AS. To share things from this = RS, the RO has to authenticate to the RS=E2=80=99s AS. This particular = AS allows the RO to do so using an external identity =E2=80=94 in which = case, the AS is now a =E2=80=9Cclient=E2=80=9D of a separate, = disconnected (but layered) delegation. The ultimate client that = eventually calls the RS down the way may or may not know about these = layers. 

    <PastedGraphic-1.png>
    This = same AS, which is closely tied to the RS and trusted by the RS, might = also take in FIDO credentials, or DIDs, or any number of other proof = mechanisms. The output of this is an access token the RS trusts, but the = input is up to the AS. The RS is not what you=E2=80=99re logging in = to.

     =E2=80= =94 Justin

    On Mar 22, 2021, at 1:28 PM, = Adrian Gropper <agropper@healthurl.com> = wrote:

    I = too am in favor of avoiding consolidation and correlation. Right now, = when I approach a service provider (RS) for the first time, I'm offered = the opportunity to identify my persona as: email, sign-in with Google, = Facebook, or Apple. I know there are people who try to create one-off = email addresses but that is mostly a waste of time. 

    So, along come FIDO2 and = DID wallets to the rescue. Now, in theory, I have a way to start out my = RS relationship pseudonymously. 

    When I want my resource to be = discovered or shared I will post that RS URL including my pseudonym. If = I then want to introduce a mediator in front of my AS or messaging = service endpoint, I have that option. If I want to keep requests = away from the mediator, I would publish an encryption key along with my = pseudonym.

    - = Adrian



    On Mon, Mar 22, 2021 at 9:55 AM Justin = Richer <jricher@mit.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin = Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhkarp@gmail.com> shared a talk = about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#i= ssuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to = use authority
    >> as a core principle. I advocate for a GNAP design that = maximizes the power
    >> of the RO, to be seen as a human rights issue when the RO is a = human. This
    >> causes me to ask how to combine better security with better = human rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the = RO to
    >> partition limited authority across dozens of different ASs by = domain and
    >> function, then we are not using technology to empower the = individual.
    >> Probably the opposite, as we introduce consent fatigue and = burden normal
    >> people to partition their lives into non-overlapping = domains.
    >>
    >> My experience says we should aim for one AS per persona because = that maps
    >> into the way we manage our public and private identities. POLA = would then
    >> teach care in keeping ASs and RSs related to work / public = separate from
    >> ASs and RSs related to private life so that a policy = vulnerability in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to = GNAP
    > seems like a useful exercise.  I do want to point out some = potential
    > pitfalls with one-AS-per-persona that we can also be aware = of.  If
    > one-AS-per-persona becomes one-persona-per-AS as well, then the = AS's
    > identity in effect also serves as a persona identity and there are = privacy
    > considerations to that.  If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple = humans)
    > route is taken, we should consider whether that would lead to = various
    > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.  That topic is a current matter of = concern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in = the UMA working group, and it=E2=80=99s one of the biggest problems with = the personal AS (and personal data store) model. This kind of thing = makes RS-first trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that = wants to access my medical information. It calls an RS and requests = access, but it hasn=E2=80=99t been granted anything yet. Now I as the RO = have set up the RS so that it talks to my personal AS, that only I use. = In addition to the RS having to be able to figure out which medical = records are being requested from the context of the unauthenticated = request (which means it needs identifiers in the URL or something = similar for the RS to be able to tell, assuming that it protects data = for more than one person). So this client software doesn=E2=80=99t know = who I am and doesn=E2=80=99t know my medical record information, makes a = completely unauthorized request to the RS, and the RS says =E2=80=9CGo = to Justin=E2=80=99s personal AS to get a token=E2=80=9D. The client can = now make a direct correlation between the data that=E2=80=99s being = protected at the RS and the person running the AS that protects it. = Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This = is a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please = talk to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t = exposed anything at all. And from the perspective of both the patient = and the RS, this is more privacy-preserving, and it=E2=80=99s really the = least surprising option. Once the client gets to the AS, it can start a = negotiation of figuring out who the RO is for the information being = accessed.

    On top of this, the usability expectations of people managing their own = AS, or set of AS=E2=80=99s for multiple personas to keep things = separate, is a huge burden. Even in the tech community, I know people = who can=E2=80=99t reliably manage more than one email address for = different purposes. I wouldn=E2=80=99t expect my partner to do that =E2=80= =94 they have trouble enough balancing all the logins and sessions = required for different kids remote schooling, I couldn=E2=80=99t imagine = them having to understand all the requirements for managing multiple = authorization servers and associated policies. I also don=E2=80=99t = expect any person to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve = been on the internet for decades and I can barely keep tabs on my GPG = keys, and only use them when I am forced to. This is exactly the kind of = =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions above, = people will just want to outsource that to someone else, and the reality = will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice = only to end up with a world where the RS ends up making a limited choice = anyway. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99= s could allow arbitrary IdPs but they choose Google because it works and = that=E2=80=99s where the users are. (And that=E2=80=99s not to say = anything of the proprietary OIDC-like protocols, but that=E2=80=99s = another discussion).

    For further reading on these topics, I recommend both =E2=80=9CWhy = Johnny Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems = Fail=E2=80=9D.

    So what does this have to do with GNAP? I think we can be clear-eyed on = what kinds of expectations we have for the participants. If we expect = users (RO=E2=80=99s) to have to set up the AS-RS relationship, or expect = them to carry their AS, or manage their personal keys =E2=80=94 I think = we=E2=80=99ve lost the battle for relevance.

     =E2=80=94 Justin


    --
    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
    =


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



    = --Apple-Mail=_BDBF259F-F935-4ED9-92C5-A28C097A7204-- From nobody Fri Mar 26 08:23:44 2021 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 386873A210F for ; Fri, 26 Mar 2021 08:23:43 -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 Pptz3BU2iyZC for ; Fri, 26 Mar 2021 08:23:36 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 BB0AE3A2113 for ; Fri, 26 Mar 2021 08:23:35 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id s2so4446941qtx.10 for ; Fri, 26 Mar 2021 08:23:35 -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=QtUmengyM5Eh1zyihDGX6+pmEaIQiWRyicZ3qli6IMU=; b=kGQY8ECHNsqxB9qWjMu6xEsyRRTyH+RILLr1ZDLcYAw38L4rSH3m0Sh0HFgZ6yhuRb ZTxF0g7FOYMQHp1GvqgPnLuJsfMDxp9NLle1TsBnHN2yTJ7YDb3ftJxIkU0QDvsjG4C0 ++uqqecelivaSPs1KS/XexlR08f4682e00POV5DdtT5slEKAnX5CsJfQnps7CJDYCF/w AokB2GCFP+3pwRizxwaEqlnYzT7Tf167ml1agVUDYdy6tqQp3znUfUl+BIyPfKiywx9G ajH/4HWP8XdVFOo3Ug5WmwQ2DMhm13Q5DbIMgIDwMqoZDyGuY+IgGJ8RtjMrRJffkfep F0aA== 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=QtUmengyM5Eh1zyihDGX6+pmEaIQiWRyicZ3qli6IMU=; b=UueoUQAHGF1D1mD1QWwnH2X/IdeXQLqyszpoAcLRqMJIU+UvPcGouBK7rpfvJiFOWL IKGHTmrRfyP6cKxpsZR26znvaXxnizZZPsvFX9mfZ+3DrEiJ9ugVwdy8rKj+YDBYqOyI uhoXK5of3Ht4nb7TmrfVqbB/ZysuE/I0Sen6nQX43bcUI9avhSsXVtpVOBlKy+I4c9gs dYPdp0bfD781+8Iq46sWtdJCbNk5RJDrDlbKmFhf4OoU/pN0O64dXtwMZiBFxNj3CLU/ jDPla+hnDMLAnk8nYfRY24QR2HFCOEV+VheIlO6vMauhYXy8Ciy0WHZk4w9MmlGkb/uC e3eg== X-Gm-Message-State: AOAM531TmsBVtrap5vcsxNrT/U8n4cbKRXOV89boxjsK1y35qGFQcnLX EFXjkozDu4G6+8PYaxLgbqiGBdZ+H1r1qSUxhk0= X-Google-Smtp-Source: ABdhPJwYuaXoq1kiu6bqO9VWd1UodHk9o/geJ40dhRYxPSWuTzhrC/j9kzgHEa6ThbQ2YU9azNudTLyVhmqpA3pklKg= X-Received: by 2002:ac8:4750:: with SMTP id k16mr12284502qtp.239.1616772212708; Fri, 26 Mar 2021 08:23:32 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> In-Reply-To: From: Alan Karp Date: Fri, 26 Mar 2021 08:23:20 -0700 Message-ID: To: Adrian Gropper Cc: Justin Richer , GNAP Mailing List , Fabien Imbault , Mark Miller , Benjamin Kaduk Content-Type: multipart/alternative; boundary="0000000000006bde0205be721dc1" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2021 15:23:43 -0000 --0000000000006bde0205be721dc1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Adrian Gropper wrote: > My issue is with Alan's: > > "7. Another user agent (RO') can contact any holder of the access token o= r > the service's policy agent (AS-RS) to get a delegated access token." > > > I would prefer "7A. Another user agent (RO') can contact any holder of > the access token." by default so that the AS-RS does not see the requests= . > In other words, the RS and AS-RS only see access tokens. The requests (fr= om > RO') that resulted in an access token are none of their business. > It is common in enterprise systems for employees not to know the access policies. For example, employee RO might not know if contractor RO' is entitled to use the resource. In this case, RO would designate the resource to RO' who would have to get an access token from the agent managing the enterprise policy, which in this case could be AS-RS. In a personal setting, RO' won't have the credentials required to get an access token from AS-RS and will only be able to get an access token from RO or AS-RO. > > The reality is that RO' can discover a resource RS and can share whatever > information with RS-AS they want and the RO may not even know about it > unless the RS decides to let them know somehow. This seems to be a drawba= ck > of the capabilities approach. > If RO' can reach AS-RS or RS, then RO' can share any information it has about RO. That's an irreducible problem that occurs no matter what access control model you use. RO should disclose to RO' only information RO' needs to act on behalf of RO. Any violation of the privacy agreement by RO' is between RO and RO'; AS-RS has no knowledge of it. It's up to RO to decide if the risk of potential exposure of the disclosed information is worth the benefit of delegating to RO'. (You can replace RO' with client.) That's the way I like to think of trust. Not, "Do I trust this guy?", but "In what ways am I vulnerable to this guy's bad behavior?" > > In terms of privacy and control, I, as the RO, want a contract with the R= S > that says that I or my agent (AS-RO) must sign an access token. This is a > fundamental audit requirement. Without it, a rogue RS and AS-RS can do al= l > sorts of things and the RO would never know. I understand that a rogue RS > might not support an honest contemporaneous log of access tokens presente= d > so there's a trust issue here that I seems unavoidable unless I specify i= n > my RO-RS contract that they use a separate contemporaneous log such as > AS-RO for every access token presented and risk being sued if they proces= s > an access token without also updating the separate log. > Whether or not access tokens and/or the requests made with them must be signed is up to the provider of the service. Some low-value services may not want the overhead of verifying signatures. High-value services almost always will. As far as a rogue service goes, signing alone doesn't help you. The rogue service could create a key pair and claim you provided the public key. You'll need additional mechanisms to get that guarantee. You've got more problems than non-repudiation if the service is malicious. Our philosophy with HP's E-speak product was, "Fool me once, shame on you. Fool me twice, shame on me." You can rely on reputation or bootstrap trust, as was shown in the Digital Silk Road project from the 1990s, https://www.semanticscholar.org/paper/The-Digital-Silk-Road-Hardy-Tribble/4= cf20dc626013d112f434022c50a1f18848077e1 . Signing access tokens and requests using them is the standard pattern in certificate-based capability systems, e.g., SPKI, zcap-ld. A nice feature of these systems is that each token can be issued to a public key created solely for that token, making correlation difficult. Those other systems use non-opaque tokens, but there is no reason the tokens can't be opaque. -------------- Alan Karp On Thu, Mar 25, 2021 at 2:50 PM Adrian Gropper wrote: > My issue is with Alan's: > > "7. Another user agent (RO') can contact any holder of the access token o= r > the service's policy agent (AS-RS) to get a delegated access token." > > > I would prefer "7A. Another user agent (RO') can contact any holder of > the access token." by default so that the AS-RS does not see the requests= . > In other words, the RS and AS-RS only see access tokens. The requests (fr= om > RO') that resulted in an access token are none of their business. > > The reality is that RO' can discover a resource RS and can share whatever > information with RS-AS they want and the RO may not even know about it > unless the RS decides to let them know somehow. This seems to be a drawba= ck > of the capabilities approach. > > In terms of privacy and control, I, as the RO, want a contract with the R= S > that says that I or my agent (AS-RO) must sign an access token. This is a > fundamental audit requirement. Without it, a rogue RS and AS-RS can do al= l > sorts of things and the RO would never know. I understand that a rogue RS > might not support an honest contemporaneous log of access tokens presente= d > so there's a trust issue here that I seems unavoidable unless I specify i= n > my RO-RS contract that they use a separate contemporaneous log such as > AS-RO for every access token presented and risk being sued if they proces= s > an access token without also updating the separate log. > > - Adrian > > > On Thu, Mar 25, 2021 at 1:22 PM Alan Karp wrote: > >> Justin Richer wrote: >> >>> Hi Alan, >>> >>> In all of my discussion, and in the spec itself, the RO is the :entity: >>> in charge of approving rights. They=E2=80=99re probably a person. It mi= ght be >>> software that makes a policy decision in some way, or a corporate entit= y, >>> or something like that. But it=E2=80=99s not assumed to be a computatio= nal agent in >>> the terms of the protocol itself. Would that recast what you=E2=80=99re= saying >>> below? >>> >> >> Hmmm. I guess not. It's just that the person would be using some UI to >> express their decisions to what I called the user agent. That model fit= s >> in very nicely with what we did with Polaris, our virus safe computing >> environment for Windows XP, >> https://dl.acm.org/doi/10.1145/1151030.1151033. The person would click >> on the icon for a Word file, and an instance of Word would open with onl= y >> the permission needed to edit that one file. Same thing here. The clie= nt >> could ask for permission to use the resource, or permission could be >> granted implicitly when the user selects a resource associated with a >> specific client. >> >> -------------- >> Alan Karp >> >> >> On Thu, Mar 25, 2021 at 9:53 AM Justin Richer wrote: >> >>> Hi Alan, >>> >>> In all of my discussion, and in the spec itself, the RO is the :entity: >>> in charge of approving rights. They=E2=80=99re probably a person. It mi= ght be >>> software that makes a policy decision in some way, or a corporate entit= y, >>> or something like that. But it=E2=80=99s not assumed to be a computatio= nal agent in >>> the terms of the protocol itself. Would that recast what you=E2=80=99re= saying >>> below? >>> >>> =E2=80=94 Justin >>> >>> On Mar 25, 2021, at 12:36 PM, Alan Karp wrote: >>> >>> There seems to be some confusion about how AS-RO comes into the picture= , >>> probably because of the "AS" part. I'm going to try to clear up that >>> confusion by more carefully explaining what I mean. >>> >>> I'm assuming that RO is a computational agent representing the person >>> who is the resource owner, something called the "user agent" in operati= ng >>> systems lingo. I'm also assuming that it's possible to do delegation, >>> either locally or by token exchange with AS-RS. All delegations are >>> potentially sub-scoped, but you may also want to delegate with full sco= pe >>> to have a separately revocable access token. >>> >>> Here's an example of how things work in a capability oriented system. >>> >>> 1. Someone, the service owner, creates a service. >>> 2. The service owner contracts with an policy agent (AS-RS) to >>> create and manage access tokens for that service (RS). >>> 3. A person wishing to create a resource at RS uses their user agent >>> (RO) to contact the service owner's policy agent (AS-RS) and gets ba= ck an >>> access token for that resource. >>> 4. That user agent (RO) can >>> 1. use that access token to invoke the resource, or >>> 2. delegate an access token to a client of the user agent's (RO) >>> choice, or >>> 3. contract with a policy agent (AS-RO) to manage those >>> delegations on behalf of the user agent (RO), or >>> 4. specify a policy with the service's policy agent (AS-RS). >>> 5. A client can contact any holder of the access token (the user >>> agent (RO) or its policy agent (AS-RO)) or the service's policy agen= t >>> (AS-RS) to get a delegated access token. >>> 6. That client can delegate that token to another client. >>> 7. Another user agent (RO') can contact any holder of the access >>> token or the service's policy agent (AS-RS) to get a delegated acces= s token. >>> 8. The other user agent (RO') can >>> 1. use that access token to invoke the resource, or >>> 2. delegate it to a client of its choice, or >>> 3. contract with a policy agent (AS-RO') of its choosing to >>> manage those delegations on its behalf, or >>> 4. specify a policy with the service's policy agent (AS-RS). >>> 9. and so on >>> >>> When any of these computational agents, user agents (ROs) or clients >>> acting on their behalf, invokes the resource, AS-RS verifies that the >>> access token is a valid delegation, i.e., proper sub-scoping, hasn't be= en >>> revoked, and that it authorizes the request being made before telling t= he >>> service (RS) to honor the request. At no point does the service's poli= cy >>> agent (AS-RS) know which computational agent did any particular >>> delegation. (Token exchange can be done as anonymously as possible.) = In >>> particular, the policy agents (AS-RO) need not be the same, or even >>> compatible with, the service's policy agent (AS-RS). GNAP specifies th= e >>> protocol between requesters, invokers, delegators (for token exchange) = of >>> tokens and AS-RS. That protocol need not be used between user agents (= RO), >>> clients, or other policy agents (AS-RO), but it is likely to be. >>> >>> ------------- >>> Alan Karp >>> >>> >>> On Thu, Mar 25, 2021 at 5:45 AM Justin Richer wrote: >>> >>>> The way I=E2=80=99m thinking about Adrian=E2=80=99s use case is that w= hat we=E2=80=99re calling >>>> the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an =E2=80=9CAS=E2=80=9D in t= he traditional OAuth/GNAP sense, at least not >>>> exactly. This is the agent that the RO can use to set policies and man= age >>>> consent on their behalf, and I=E2=80=99ve been arguing that it fits be= tter into >>>> this vaguely-defined =E2=80=9Cinteraction component=E2=80=9D aspect of= the current AS >>>> definition, and it=E2=80=99s not currently separated from the AS defin= ition. The >>>> =E2=80=9CAS-RS=E2=80=9D maps to what we=E2=80=99d call the =E2=80=9CAS= =E2=80=9D in OAuth/GNAP traditionally, it=E2=80=99s >>>> what the RS trusts to issue tokens. In traditional OAuth the AS-RO and >>>> AS-RS are always the same thing, from a functional protocol perspectiv= e. An >>>> important point here is that from a client=E2=80=99s perspective, they= =E2=80=99re only >>>> talking to the AS-RS since that=E2=80=99s where the client gets its to= kens, because >>>> at the end of the day the client just wants to call the API at the RS = and >>>> doesn=E2=80=99t care how that happens (from a protocol standpoint). >>>> >>>> Note well: Even thought I don=E2=80=99t believe that =E2=80=9CAS-RO=E2= =80=9D is an >>>> authorization server at all, I=E2=80=99m going to keep using that term= below for >>>> consistency with previous discussion. >>>> >>>> So we have these fundamental relationships around getting the client t= o >>>> access the RS: >>>> >>>> 1. RS trusts AS-RS to issue tokens that RS will accept, validate, and >>>> process for requests from client >>>> 2. Client trusts AS-RS to issue tokens that client can use at RS >>>> 3. RO trusts RS to protect RO=E2=80=99s api through delegated access >>>> >>>> On top of that, we=E2=80=99ve got some additional aspects that we=E2= =80=99re discussing: >>>> >>>> 4. RO trusts AS-RO to manage RO=E2=80=99s policies at runtime >>>> 5. AS-RS trusts AS-RO to assert RO=E2=80=99s policies for access to RS >>>> 6. Client trusts whatever AS-RS sends client to deal with, including >>>> possibly RO-AS at runtime, because of (2) >>>> >>>> What I have been saying is that 4/5/6 are optional details of how RS-A= S >>>> runs things, and I think this also maps with Adrian=E2=80=99s view of = choice, since >>>> if my RS=E2=80=99s AS-RS doesn=E2=80=99t allow me to plug in my own AS= -RO then I would be >>>> motivated to pick a different RS who=E2=80=99s AS-RS lets me do just t= hat. The same >>>> way I=E2=80=99d pick a different RS if their surrounding services didn= =E2=80=99t accept my >>>> preferred federation login and I didn=E2=80=99t want to make another a= ccount. Of >>>> course, market forces being as they are, I might not have much of an >>>> actionable choice in RS, but GNAP can=E2=80=99t change that. >>>> >>>> What we can do is make it possible for AS-RS to talk to AS-RO, both in >>>> philosophy of the protocol design and in concrete hooks to support (6) >>>> above. >>>> >>>> Separately, we can approach the issue of making 1/2 above more dynamic= . >>>> This was UMA2=E2=80=99s =E2=80=9Cfederated authorization=E2=80=9D appr= oach, and is behind a lot of >>>> the =E2=80=9Cbring your own AS=E2=80=9D models out there. The problem = with these is that we >>>> know from many years of experience that most RS=E2=80=99s aren=E2=80= =99t interested in >>>> doing anything of the sort. >>>> >>>> So with GNAP we can instead allow 4/5/6 to vary in a predictable and >>>> consistent way, letting the RS keep control over 1/2, thereby enabling >>>> choice in (3). We don=E2=80=99t have to be the ones who define the all= of the >>>> details of every permutation of (5) to enable this, though. Some of th= is is >>>> going to be configuration out of band, some of it=E2=80=99s going to b= e >>>> communication at runtime. This is where VC=E2=80=99s, ZCAPs, CHAPI, DI= DComm, FIDO, >>>> and a whole swath of other tech can come in and help out. I don=E2=80= =99t think we >>>> need to put all the details for using these into core, nor do I think = we=E2=80=99ll >>>> pull of The Great And Ultimate Abstraction for using these and other >>>> approaches. But we can at least start talking about =E2=80=9CAS-RS=E2= =80=9D in such a way >>>> that it no longer assumes it=E2=80=99s always the same party dealing w= ith the RO >>>> directly. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Mar 25, 2021, at 6:40 AM, Fabien Imbault >>>> wrote: >>>> >>>> To reframe it closer to GNAP: >>>> - AS =3D AS-RO, that's where you find the RO policies. The AS issues >>>> access tokens to the client. >>>> - the RO policies could be a) defined locally or b) in relationship >>>> with the RS >>>> >>>> There have been several ideas related to the AS-RS relationship b: >>>> b1) the RS issues capabilities (which can be further attenuated by the >>>> RO) >>>> b2) Adrian also discussed a DID based solution >>>> b3) there was also an alternative ACL proposal from Denis (+ preflight= ) >>>> >>>> Fabien >>>> >>>> >>>> On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Ok so I get you correctly: >>>>> - what matters is the RQ (could be a RO or a end-user or both : we >>>>> don't really care at a high-level, they're all treated as entities th= at >>>>> make a request) >>>>> - the policy is able to handle those different cases, based on its ow= n >>>>> internal delegation protocol >>>>> - currently that requires AS-RS and AS-RO, but maybe it can be >>>>> simplified >>>>> >>>>> To answer to Denis, here's what I understood: >>>>> - RO trusts AS-RS (and then handles its own policies within AS-RO) >>>>> - end-user trusts AS-RO (through its client) >>>>> >>>>> Could probably work but that's a fairly different model compared to >>>>> OAuth2 (and of today's GNAP), with different frontiers between the AS= and >>>>> the RS. >>>>> >>>>> Please do not hesitate to correct me if I'm wrong. >>>>> >>>>> Fabien >>>>> >>>>> On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper >>>>> wrote: >>>>> >>>>>> I believe there are alternatives to having two kinds of ASs. The >>>>>> problem may be a side-effect of deciding to switch away form treatin= g the >>>>>> RO as different from the RQ. That leads to downstream privacy issues= . Our >>>>>> desire for architectural simplicity is admirable but that may have b= een a >>>>>> step too far. >>>>>> >>>>>> There may also be solutions based on different types of tokens, as i= n >>>>>> different capabilities (tokens signed by the RS) vs. tokens signed b= y the >>>>>> AS. I=E2=80=99m not sure about that but Alan might have more to say. >>>>>> >>>>>> Adrian >>>>>> >>>>>> On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>>> Thanks. The general problem statement is clear. >>>>>>> >>>>>>> The proposed solution a bit less (to me). I understood that from >>>>>>> point 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obviou= s reason >>>>>>> to have two types of ASs". Do you see an alternative ? >>>>>>> >>>>>>> Regarding the last item, I don't think that naming RQ by end-user >>>>>>> created the problem. It might just highlight the asymmetry, which >>>>>>> fundamentally exists. >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> >>>>>>> On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper < >>>>>>> agropper@healthurl.com> wrote: >>>>>>> >>>>>>>> Recap: >>>>>>>> 1 - Justin (I think) introduced the idea of an AS on the RS trust >>>>>>>> boundary side. >>>>>>>> 2 - I said the RO should not have to share policies with the RS. >>>>>>>> 3 - Alan invented the concept of AS-RO and AS-RS to separate two >>>>>>>> kinds of PDPs. >>>>>>>> >>>>>>>> The thing is that step 2 is not symmetrical. The RO has a >>>>>>>> legitimate privacy interest in keeping their policies private and >>>>>>>> minimizing the leakage of information about requests that are pose= d against >>>>>>>> those policies. >>>>>>>> >>>>>>>> The RS, on the other hand, should be publishing its policies (e.g. >>>>>>>> what it=E2=80=99s selling or what jurisdiction it=E2=80=99s in or = what tokens or scopes it >>>>>>>> supports). The RS has no obvious privacy interest in GNAP. It=E2= =80=99s just an >>>>>>>> enforcer. >>>>>>>> >>>>>>>> There is one other privacy interest to consider around the RS and >>>>>>>> that is the requesting party (the end-user that is not the RO :-) = might >>>>>>>> prefer to share attributes with the RS instead of the RO or someth= ing >>>>>>>> controlled by the RO. This case could be an =E2=80=9Cextension=E2= =80=9D to GNAP and might >>>>>>>> result in a split AS as a solution. This problem was introduced wh= en the >>>>>>>> editors decided to replace RQ with end-user. Obviously, the RO end= -user has >>>>>>>> no privacy interests relative to itself. >>>>>>>> >>>>>>>> Adrian >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>> >>>>>>>>> I was referring to "By my definition, this model has two ASs >>>>>>>>> since both are processing requests into tokens". If there's no re= ason to >>>>>>>>> have 2 types of ASs, that's fine then. >>>>>>>>> But I'm a bit lost in where we stand with the idea. >>>>>>>>> >>>>>>>>> Could you recap? >>>>>>>>> >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper < >>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>> >>>>>>>>>> There=E2=80=99s no obvious reason to have two types of ASs. Any = AS that >>>>>>>>>> is executing the policies of the RS can look to GNAP like the RS= itself. >>>>>>>>>> Why would GNAP expose that interface to anyone? >>>>>>>>>> >>>>>>>>>> Adrian >>>>>>>>>> >>>>>>>>>> On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault < >>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Note : I'm not sure that's a good idea, but having 2 types of >>>>>>>>>>> ASs is not that easy to grasp. >>>>>>>>>>> >>>>>>>>>>> Fabien >>>>>>>>>>> >>>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault < >>>>>>>>>>> fabien.imbault@gmail.com> a =C3=A9crit : >>>>>>>>>>> >>>>>>>>>>>> The purpose of either handling policies locally or delegating >>>>>>>>>>>> them to the RO agent. >>>>>>>>>>>> >>>>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper < >>>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>>> >>>>>>>>>>>>> What purpose would be served by GNAP splitting the AS into tw= o >>>>>>>>>>>>> components? >>>>>>>>>>>>> >>>>>>>>>>>>> Adrian >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault < >>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Isn't the AS-RO a component of the AS? Same idea as the >>>>>>>>>>>>>> interact component, it functionnally belongs to the AS role = but could be >>>>>>>>>>>>>> deployed either as a monolith or as a separate component? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>> >>>>>>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper < >>>>>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, but I would say it=E2=80=99s not the RO that wants the= access >>>>>>>>>>>>>>> token. It=E2=80=99s the RO that wants the client making the= request to get an >>>>>>>>>>>>>>> access token. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 11:22 PM Alan Karp < >>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Adrian Gropper wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In this design, the AS is the AS-RS and the agent is the >>>>>>>>>>>>>>>>> AS-RO. By my definition, this model has two ASs since bot= h are processing >>>>>>>>>>>>>>>>> requests into tokens. The problem with this is complexity= and privacy. The >>>>>>>>>>>>>>>>> RO may not want to share the request information with the= AS-RS. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> More precisely, RO has no choice but to present the >>>>>>>>>>>>>>>> required information to AS-RS if RO wants an access token.= However, RO >>>>>>>>>>>>>>>> does not want AS-RS to know the policy by which RO delegat= es tokens. >>>>>>>>>>>>>>>> That's why RO uses AS-RO for those delegations. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper < >>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thank you for creating the issue. My definition of AS is >>>>>>>>>>>>>>>>> independent of AS-RO or AS-RS. >>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues= /223#issuecomment-806280421 >>>>>>>>>>>>>>>>> I also agree with Alan's definition based on delegation. = An AS-RS would be >>>>>>>>>>>>>>>>> a delegate of the RS. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Based on that, I see it as obvious that the policy has to >>>>>>>>>>>>>>>>> be accessible (defined locally?) in order for it to be ru= n as the code that >>>>>>>>>>>>>>>>> turns a request into an access token. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The only other possibility is that the request is package= d >>>>>>>>>>>>>>>>> by the AS and sent elsewhere (an agent) for evaluation ag= ainst policy and a >>>>>>>>>>>>>>>>> proto-token returned. In that case the AS is acting as a = proxy and the PDP >>>>>>>>>>>>>>>>> is elsewhere. I can imagine that an AS-RS would behave th= is way so that the >>>>>>>>>>>>>>>>> proto-token could be turned into an access token by the A= S-RS. Isn't this >>>>>>>>>>>>>>>>> what Justin is proposing? In this design, the AS is the A= S-RS and the agent >>>>>>>>>>>>>>>>> is the AS-RO. By my definition, this model has two ASs si= nce both are >>>>>>>>>>>>>>>>> processing requests into tokens. The problem with this is= complexity and >>>>>>>>>>>>>>>>> privacy. The RO may not want to share the request informa= tion with the >>>>>>>>>>>>>>>>> AS-RS. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault < >>>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Isn't that what the AS is supposed to be, only with the >>>>>>>>>>>>>>>>>> caveat that the policy is defined locally? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp < >>>>>>>>>>>>>>>>>> alanhkarp@gmail.com> a =C3=A9crit : >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> AS-RO is an AS that RO trusts to delegate RO's access >>>>>>>>>>>>>>>>>>> tokens according to RO's policies. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault < >>>>>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hi Alan and Adrian, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I've created issue AS-RO policy delegation ( >>>>>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/iss= ues/223) >>>>>>>>>>>>>>>>>>>> to capture your input. >>>>>>>>>>>>>>>>>>>> A first question that arises: can we give a definition >>>>>>>>>>>>>>>>>>>> to AS-RO? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp < >>>>>>>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Fabien Imbault wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Yes, but in that flow, the token relationship betwee= n >>>>>>>>>>>>>>>>>>>>>> AS-RS and AS-RO is only secure if the tokens issued = by AS-RS are >>>>>>>>>>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Attenuated delegation is a requirement, but that >>>>>>>>>>>>>>>>>>>>> doesn't have to be done cryptographically. Token exc= hange works just >>>>>>>>>>>>>>>>>>>>> fine. SPKI and zcap-ld are examples of the crypto ap= proach, and we used >>>>>>>>>>>>>>>>>>>>> token exchange in the system for HP. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault < >>>>>>>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Yes, but in that flow, the token relationship betwee= n >>>>>>>>>>>>>>>>>>>>>> AS-RS and AS-RO is only secure if the tokens issued = by AS-RS are >>>>>>>>>>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp < >>>>>>>>>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Justin Richer wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> But with all that in mind, I think the key here is >>>>>>>>>>>>>>>>>>>>>>>> going to be looking at what the inputs to the AS a= re, and how those can be >>>>>>>>>>>>>>>>>>>>>>>> defined in an interoperable way for AS=E2=80=99s t= hat can accept them. I think >>>>>>>>>>>>>>>>>>>>>>>> there=E2=80=99s a lot of room for innovation and f= lexibility here that doesn=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>> break the trust model or core use cases. If I have= an AS-RS set that won=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine inputs,= then I can decide not to >>>>>>>>>>>>>>>>>>>>>>>> use that one. But this is a very different questio= n than saying the RS >>>>>>>>>>>>>>>>>>>>>>>> itself needs to accept my own AS =E2=80=94 and we = can=E2=80=99t keep conflating these two >>>>>>>>>>>>>>>>>>>>>>>> models. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I agree. The point of having an AS-RO is to allow >>>>>>>>>>>>>>>>>>>>>>> RO to specify a policy for which of RO's access tok= ens should be delegated >>>>>>>>>>>>>>>>>>>>>>> under what conditions. AS-RS should not need to un= derstand those >>>>>>>>>>>>>>>>>>>>>>> policies. The flow would be >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> - RO contacts AS-RS and gets one or more access >>>>>>>>>>>>>>>>>>>>>>> tokens. >>>>>>>>>>>>>>>>>>>>>>> - RO delegates one or more of those tokens, >>>>>>>>>>>>>>>>>>>>>>> potentially sub-scoped, to AS-RO. >>>>>>>>>>>>>>>>>>>>>>> - A different user contacts AS-RO to get a >>>>>>>>>>>>>>>>>>>>>>> potentially sub-scoped access token from AS-RO. >>>>>>>>>>>>>>>>>>>>>>> - That user presents the access token delegated >>>>>>>>>>>>>>>>>>>>>>> by AS-RO when invoking the resource. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> AS-RS only needs to verify that the delegation chai= n >>>>>>>>>>>>>>>>>>>>>>> is legitimate, e.g., no increase in scope, and that= it grants permission >>>>>>>>>>>>>>>>>>>>>>> for the request being made. AS-RS does not need to= understand the policy >>>>>>>>>>>>>>>>>>>>>>> behind granting the delegation by AS-RO. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer < >>>>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I think this shows the problem with the terminolog= y >>>>>>>>>>>>>>>>>>>>>>>> as it=E2=80=99s been applied in this conversation,= which I=E2=80=99ve tried to shine light >>>>>>>>>>>>>>>>>>>>>>>> on before. What you and others are calling the =E2= =80=9CRS=E2=80=9D is really the =E2=80=9CAS and >>>>>>>>>>>>>>>>>>>>>>>> RS working together=E2=80=9D =E2=80=94 everything = to the right of the line. When Denis had >>>>>>>>>>>>>>>>>>>>>>>> brought up =E2=80=9Celiminating the AS=E2=80=9D in= another thread, what he=E2=80=99d really done is >>>>>>>>>>>>>>>>>>>>>>>> labeled everything to the right of the line as the= =E2=80=9CRS=E2=80=9D. Of course, the >>>>>>>>>>>>>>>>>>>>>>>> irony here is that everything to the right of the = line used all be called >>>>>>>>>>>>>>>>>>>>>>>> the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver= =E2=80=9D in the OAuth 1 days. As you say below, I don=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>> want the client to have visibility on what happens= on that side. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Note well: The Google+ logo labeled =E2=80=9CIdP= =E2=80=9D in the >>>>>>>>>>>>>>>>>>>>>>>> diagram is not the AS, as far as GNAP is concerned= . It does not issue an >>>>>>>>>>>>>>>>>>>>>>>> access token that the RS will accept. The elements= to the left of the line >>>>>>>>>>>>>>>>>>>>>>>> could be a lot of things, but they are NOT the AS = =E2=80=94 by definition. The >>>>>>>>>>>>>>>>>>>>>>>> client lives over on the left, but so do any exter= nal inputs to the AS. >>>>>>>>>>>>>>>>>>>>>>>> These could be policy inputs on behalf of the RO, = they could be >>>>>>>>>>>>>>>>>>>>>>>> presentation artifacts, they could be federated lo= gins, they could be the >>>>>>>>>>>>>>>>>>>>>>>> output of policy decisions. How the AS comes to tr= ust those things is up to >>>>>>>>>>>>>>>>>>>>>>>> the AS=E2=80=99s implementation. It=E2=80=99s some= thing we can talk about, but ultimately >>>>>>>>>>>>>>>>>>>>>>>> GNAP won=E2=80=99t be in any position to dictate b= ecause in practice some AS=E2=80=99s are >>>>>>>>>>>>>>>>>>>>>>>> simply going to internalize all policies and we wi= ll never successfully >>>>>>>>>>>>>>>>>>>>>>>> force those open. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> But with all that in mind, I think the key here is >>>>>>>>>>>>>>>>>>>>>>>> going to be looking at what the inputs to the AS a= re, and how those can be >>>>>>>>>>>>>>>>>>>>>>>> defined in an interoperable way for AS=E2=80=99s t= hat can accept them. I think >>>>>>>>>>>>>>>>>>>>>>>> there=E2=80=99s a lot of room for innovation and f= lexibility here that doesn=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>> break the trust model or core use cases. If I have= an AS-RS set that won=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine inputs,= then I can decide not to >>>>>>>>>>>>>>>>>>>>>>>> use that one. But this is a very different questio= n than saying the RS >>>>>>>>>>>>>>>>>>>>>>>> itself needs to accept my own AS =E2=80=94 and we = can=E2=80=99t keep conflating these two >>>>>>>>>>>>>>>>>>>>>>>> models. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> So to me, GNAP can support a Zero Trust >>>>>>>>>>>>>>>>>>>>>>>> Architecture by LEVERAGING the AS, not by subsumin= g or eliminating it. It >>>>>>>>>>>>>>>>>>>>>>>> is in fact the AS, not the client and not the RS, = that will request and >>>>>>>>>>>>>>>>>>>>>>>> consume the results of a privacy-preserving zero-t= rust policy query thing. >>>>>>>>>>>>>>>>>>>>>>>> Anything that happens downstream from that is of l= ittle concern to the >>>>>>>>>>>>>>>>>>>>>>>> zero-trust components because, as you point out, i= t=E2=80=99s on the =E2=80=9Cother side=E2=80=9D >>>>>>>>>>>>>>>>>>>>>>>> of the line. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I think we got this basic component model pretty >>>>>>>>>>>>>>>>>>>>>>>> right in OAuth: the AS and RS and client working t= ogether. Where OAuth >>>>>>>>>>>>>>>>>>>>>>>> misses the mark is the assumption that the user ha= s to log in to the AS >>>>>>>>>>>>>>>>>>>>>>>> through a webpage and interact directly, thereby p= roving they=E2=80=99re the RO. >>>>>>>>>>>>>>>>>>>>>>>> It=E2=80=99s this latter space where I think we ca= n both push innovation and also >>>>>>>>>>>>>>>>>>>>>>>> address the important and compelling use cases lik= e the ones you=E2=80=99re >>>>>>>>>>>>>>>>>>>>>>>> bringing. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper < >>>>>>>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I'm sorry, Justin. As a Resource Owner, I look at >>>>>>>>>>>>>>>>>>>>>>>> the RS trust boundary (the dotted line in the diag= ram) as being the RS. I >>>>>>>>>>>>>>>>>>>>>>>> don't expect any visibility into what's going on o= n the right. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> My problem with the framing you propose is that >>>>>>>>>>>>>>>>>>>>>>>> requests are going to the RS (or the AS-RS) and I = don't want to share my >>>>>>>>>>>>>>>>>>>>>>>> policies with the AS-RS. I want to keep the RS and= AS-RS as ignorant as >>>>>>>>>>>>>>>>>>>>>>>> possible. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer < >>>>>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> What you=E2=80=99re discussing below, in terms of= logging >>>>>>>>>>>>>>>>>>>>>>>>> in to a site, is not approaching the RS. You are = in fact approaching the >>>>>>>>>>>>>>>>>>>>>>>>> client, and identifying both the AS and RS to the= client. The client is a >>>>>>>>>>>>>>>>>>>>>>>>> client *of your identity* in this model, and the >>>>>>>>>>>>>>>>>>>>>>>>> RS is part of the identity provider. It=E2=80=99s= really important that we don=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>>> conflate the RS and client in this way as it lead= s to a lot of confusion >>>>>>>>>>>>>>>>>>>>>>>>> downstream and a lot of broken trust boundaries. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> With that model in mind, approaching the =E2=80= =9CRS" and >>>>>>>>>>>>>>>>>>>>>>>>> providing it your identity is really just a case = of the =E2=80=9Cfederated login to >>>>>>>>>>>>>>>>>>>>>>>>> AS=E2=80=9D pattern that we discussed on the WG c= all. The user here approaches an >>>>>>>>>>>>>>>>>>>>>>>>> RS, which has its own AS. To share things from th= is RS, the RO has to >>>>>>>>>>>>>>>>>>>>>>>>> authenticate to the RS=E2=80=99s AS. This particu= lar AS allows the RO to do so >>>>>>>>>>>>>>>>>>>>>>>>> using an external identity =E2=80=94 in which cas= e, the AS is now a =E2=80=9Cclient=E2=80=9D of a >>>>>>>>>>>>>>>>>>>>>>>>> separate, disconnected (but layered) delegation. = The ultimate client that >>>>>>>>>>>>>>>>>>>>>>>>> eventually calls the RS down the way may or may n= ot know about these >>>>>>>>>>>>>>>>>>>>>>>>> layers. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> This same AS, which is closely tied to the RS and >>>>>>>>>>>>>>>>>>>>>>>>> trusted by the RS, might also take in FIDO creden= tials, or DIDs, or any >>>>>>>>>>>>>>>>>>>>>>>>> number of other proof mechanisms. The output of t= his is an access token the >>>>>>>>>>>>>>>>>>>>>>>>> RS trusts, but the input is up to the AS. The RS = is not what you=E2=80=99re logging >>>>>>>>>>>>>>>>>>>>>>>>> in to. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper < >>>>>>>>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> I too am in favor of avoiding consolidation and >>>>>>>>>>>>>>>>>>>>>>>>> correlation. Right now, when I approach a service= provider (RS) for the >>>>>>>>>>>>>>>>>>>>>>>>> first time, I'm offered the opportunity to identi= fy my persona as: email, >>>>>>>>>>>>>>>>>>>>>>>>> sign-in with Google, Facebook, or Apple. I know t= here are people who try to >>>>>>>>>>>>>>>>>>>>>>>>> create one-off email addresses but that is mostly= a waste of time. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> So, along come FIDO2 and DID wallets to the >>>>>>>>>>>>>>>>>>>>>>>>> rescue. Now, in theory, I have a way to start out= my RS relationship >>>>>>>>>>>>>>>>>>>>>>>>> pseudonymously. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> When I want my resource to be discovered or share= d >>>>>>>>>>>>>>>>>>>>>>>>> I will post that RS URL including my pseudonym. I= f I then want to introduce >>>>>>>>>>>>>>>>>>>>>>>>> a mediator in front of my AS or messaging service= endpoint, I have that >>>>>>>>>>>>>>>>>>>>>>>>> option. If I want to keep requests away from the = mediator, I would publish >>>>>>>>>>>>>>>>>>>>>>>>> an encryption key along with my pseudonym. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> - Adrian >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer < >>>>>>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk < >>>>>>>>>>>>>>>>>>>>>>>>>> kaduk@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, >>>>>>>>>>>>>>>>>>>>>>>>>> Adrian Gropper wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> >> @Alan Karp shared a >>>>>>>>>>>>>>>>>>>>>>>>>> talk about the Principle Of Least >>>>>>>>>>>>>>>>>>>>>>>>>> >> Authority (POLA) in a recent comment >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protoc= ol/issues/145#issuecomment-803099693 >>>>>>>>>>>>>>>>>>>>>>>>>> >> I recommend it. >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>> >> We might expect a protocol with authorization >>>>>>>>>>>>>>>>>>>>>>>>>> in the title to use authority >>>>>>>>>>>>>>>>>>>>>>>>>> >> as a core principle. I advocate for a GNAP >>>>>>>>>>>>>>>>>>>>>>>>>> design that maximizes the power >>>>>>>>>>>>>>>>>>>>>>>>>> >> of the RO, to be seen as a human rights issue >>>>>>>>>>>>>>>>>>>>>>>>>> when the RO is a human. This >>>>>>>>>>>>>>>>>>>>>>>>>> >> causes me to ask how to combine better >>>>>>>>>>>>>>>>>>>>>>>>>> security with better human rights in >>>>>>>>>>>>>>>>>>>>>>>>>> >> GNAP. >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>> >> Who should have the least authority in the >>>>>>>>>>>>>>>>>>>>>>>>>> GNAP design? >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>> >> The AS derives authority as a delegate of the >>>>>>>>>>>>>>>>>>>>>>>>>> RO. If we ask the RO to >>>>>>>>>>>>>>>>>>>>>>>>>> >> partition limited authority across dozens of >>>>>>>>>>>>>>>>>>>>>>>>>> different ASs by domain and >>>>>>>>>>>>>>>>>>>>>>>>>> >> function, then we are not using technology to >>>>>>>>>>>>>>>>>>>>>>>>>> empower the individual. >>>>>>>>>>>>>>>>>>>>>>>>>> >> Probably the opposite, as we introduce consen= t >>>>>>>>>>>>>>>>>>>>>>>>>> fatigue and burden normal >>>>>>>>>>>>>>>>>>>>>>>>>> >> people to partition their lives into >>>>>>>>>>>>>>>>>>>>>>>>>> non-overlapping domains. >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>> >> My experience says we should aim for one AS >>>>>>>>>>>>>>>>>>>>>>>>>> per persona because that maps >>>>>>>>>>>>>>>>>>>>>>>>>> >> into the way we manage our public and private >>>>>>>>>>>>>>>>>>>>>>>>>> identities. POLA would then >>>>>>>>>>>>>>>>>>>>>>>>>> >> teach care in keeping ASs and RSs related to >>>>>>>>>>>>>>>>>>>>>>>>>> work / public separate from >>>>>>>>>>>>>>>>>>>>>>>>>> >> ASs and RSs related to private life so that a >>>>>>>>>>>>>>>>>>>>>>>>>> policy vulnerability in our >>>>>>>>>>>>>>>>>>>>>>>>>> >> delegation to an AS would have the least >>>>>>>>>>>>>>>>>>>>>>>>>> likelihood of harm. >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > Thinking about how least authority/least >>>>>>>>>>>>>>>>>>>>>>>>>> privilege would apply to GNAP >>>>>>>>>>>>>>>>>>>>>>>>>> > seems like a useful exercise. I do want to >>>>>>>>>>>>>>>>>>>>>>>>>> point out some potential >>>>>>>>>>>>>>>>>>>>>>>>>> > pitfalls with one-AS-per-persona that we can >>>>>>>>>>>>>>>>>>>>>>>>>> also be aware of. If >>>>>>>>>>>>>>>>>>>>>>>>>> > one-AS-per-persona becomes one-persona-per-AS >>>>>>>>>>>>>>>>>>>>>>>>>> as well, then the AS's >>>>>>>>>>>>>>>>>>>>>>>>>> > identity in effect also serves as a persona >>>>>>>>>>>>>>>>>>>>>>>>>> identity and there are privacy >>>>>>>>>>>>>>>>>>>>>>>>>> > considerations to that. If, on the other hand= , >>>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>> > multiple-personas-per-AS (presumably >>>>>>>>>>>>>>>>>>>>>>>>>> corresponding to multiple humans) >>>>>>>>>>>>>>>>>>>>>>>>>> > route is taken, we should consider whether tha= t >>>>>>>>>>>>>>>>>>>>>>>>>> would lead to various >>>>>>>>>>>>>>>>>>>>>>>>>> > (e.g., market) forces driving consolidation to >>>>>>>>>>>>>>>>>>>>>>>>>> just a handful of >>>>>>>>>>>>>>>>>>>>>>>>>> > super-popular AS services. That topic is a >>>>>>>>>>>>>>>>>>>>>>>>>> current matter of concern to >>>>>>>>>>>>>>>>>>>>>>>>>> > some IETF participants. >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Hi Ben, big +1 to this. This is something that w= e >>>>>>>>>>>>>>>>>>>>>>>>>> discussed ages ago in the UMA working group, and= it=E2=80=99s one of the biggest >>>>>>>>>>>>>>>>>>>>>>>>>> problems with the personal AS (and personal data= store) model. This kind of >>>>>>>>>>>>>>>>>>>>>>>>>> thing makes RS-first trust models really difficu= lt in practice. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> As a strawman, let=E2=80=99s say that I=E2=80=99= ve got software >>>>>>>>>>>>>>>>>>>>>>>>>> that wants to access my medical information. It = calls an RS and requests >>>>>>>>>>>>>>>>>>>>>>>>>> access, but it hasn=E2=80=99t been granted anyth= ing yet. Now I as the RO have set >>>>>>>>>>>>>>>>>>>>>>>>>> up the RS so that it talks to my personal AS, th= at only I use. In addition >>>>>>>>>>>>>>>>>>>>>>>>>> to the RS having to be able to figure out which = medical records are being >>>>>>>>>>>>>>>>>>>>>>>>>> requested from the context of the unauthenticate= d request (which means it >>>>>>>>>>>>>>>>>>>>>>>>>> needs identifiers in the URL or something simila= r for the RS to be able to >>>>>>>>>>>>>>>>>>>>>>>>>> tell, assuming that it protects data for more th= an one person). So this >>>>>>>>>>>>>>>>>>>>>>>>>> client software doesn=E2=80=99t know who I am an= d doesn=E2=80=99t know my medical record >>>>>>>>>>>>>>>>>>>>>>>>>> information, makes a completely unauthorized req= uest to the RS, and the RS >>>>>>>>>>>>>>>>>>>>>>>>>> says =E2=80=9CGo to Justin=E2=80=99s personal AS= to get a token=E2=80=9D. The client can now make a >>>>>>>>>>>>>>>>>>>>>>>>>> direct correlation between the data that=E2=80= =99s being protected at the RS and >>>>>>>>>>>>>>>>>>>>>>>>>> the person running the AS that protects it. Impo= rtantly, this client makes >>>>>>>>>>>>>>>>>>>>>>>>>> this call with no prior relationship to the RS a= nd no really auditable way >>>>>>>>>>>>>>>>>>>>>>>>>> to track it down after the fact. This is a desig= n feature in the good case, >>>>>>>>>>>>>>>>>>>>>>>>>> and terrifying in the bad case. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> If the RS instead says =E2=80=9Cwelcome to Medic= ine >>>>>>>>>>>>>>>>>>>>>>>>>> Doctor RS, please talk to the Medicine Doctor AS= to get access=E2=80=9D, we haven=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>>>> exposed anything at all. And from the perspectiv= e of both the patient and >>>>>>>>>>>>>>>>>>>>>>>>>> the RS, this is more privacy-preserving, and it= =E2=80=99s really the least >>>>>>>>>>>>>>>>>>>>>>>>>> surprising option. Once the client gets to the A= S, it can start a >>>>>>>>>>>>>>>>>>>>>>>>>> negotiation of figuring out who the RO is for th= e information being >>>>>>>>>>>>>>>>>>>>>>>>>> accessed. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On top of this, the usability expectations of >>>>>>>>>>>>>>>>>>>>>>>>>> people managing their own AS, or set of AS=E2=80= =99s for multiple personas to keep >>>>>>>>>>>>>>>>>>>>>>>>>> things separate, is a huge burden. Even in the t= ech community, I know >>>>>>>>>>>>>>>>>>>>>>>>>> people who can=E2=80=99t reliably manage more th= an one email address for different >>>>>>>>>>>>>>>>>>>>>>>>>> purposes. I wouldn=E2=80=99t expect my partner t= o do that =E2=80=94 they have trouble >>>>>>>>>>>>>>>>>>>>>>>>>> enough balancing all the logins and sessions req= uired for different kids >>>>>>>>>>>>>>>>>>>>>>>>>> remote schooling, I couldn=E2=80=99t imagine the= m having to understand all the >>>>>>>>>>>>>>>>>>>>>>>>>> requirements for managing multiple authorization= servers and associated >>>>>>>>>>>>>>>>>>>>>>>>>> policies. I also don=E2=80=99t expect any person= to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve been on >>>>>>>>>>>>>>>>>>>>>>>>>> the internet for decades and I can barely keep t= abs on my GPG keys, and >>>>>>>>>>>>>>>>>>>>>>>>>> only use them when I am forced to. This is exact= ly the kind of =E2=80=9Cmarket >>>>>>>>>>>>>>>>>>>>>>>>>> pressure=E2=80=9D that I think Ben mentions abov= e, people will just want to >>>>>>>>>>>>>>>>>>>>>>>>>> outsource that to someone else, and the reality = will be a few popular >>>>>>>>>>>>>>>>>>>>>>>>>> providers. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> In which case, we could end up doing a ton of >>>>>>>>>>>>>>>>>>>>>>>>>> work to allow an RS choice only to end up with a= world where the RS ends up >>>>>>>>>>>>>>>>>>>>>>>>>> making a limited choice anyway. We see how that = plays out with OpenID >>>>>>>>>>>>>>>>>>>>>>>>>> Connect =E2=80=94 RP=E2=80=99s could allow arbit= rary IdPs but they choose Google because it >>>>>>>>>>>>>>>>>>>>>>>>>> works and that=E2=80=99s where the users are. (A= nd that=E2=80=99s not to say anything of >>>>>>>>>>>>>>>>>>>>>>>>>> the proprietary OIDC-like protocols, but that=E2= =80=99s another discussion). >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> For further reading on these topics, I recommend >>>>>>>>>>>>>>>>>>>>>>>>>> both =E2=80=9CWhy Johnny Can=E2=80=99t Encrypt= =E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> So what does this have to do with GNAP? I think >>>>>>>>>>>>>>>>>>>>>>>>>> we can be clear-eyed on what kinds of expectatio= ns we have for the >>>>>>>>>>>>>>>>>>>>>>>>>> participants. If we expect users (RO=E2=80=99s) = to have to set up the AS-RS >>>>>>>>>>>>>>>>>>>>>>>>>> relationship, or expect them to carry their AS, = or manage their personal >>>>>>>>>>>>>>>>>>>>>>>>>> keys =E2=80=94 I think we=E2=80=99ve lost the ba= ttle for relevance. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>> >>> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --0000000000006bde0205be721dc1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Adrian Gropper <<= a href=3D"mailto:agropper@healthurl.com" target=3D"_blank">agropper@healthu= rl.com> wrote:
    My issue is with Alan's:
    <= div>"7. Another user agent (RO') can contact any holder of the acc= ess token or the service's policy agent (AS-RS) to get a delegated acce= ss token."

    I would prefer "7A.=C2=A0Another use= r agent (RO') can contact any holder of the access token." by defa= ult so that the AS-RS does not see the requests. In other words, the RS and= AS-RS only see access tokens. The requests (from RO') that resulted in= an access token are none of their business.

    It is common in enterprise systems for em= ployees not to know the access policies.=C2=A0 For example, employee RO mig= ht not know if contractor RO' is entitled to use the resource.=C2=A0 In= this case, RO would designate the resource to RO' who would have to ge= t an access token from the agent managing the enterprise policy, which in t= his case could be AS-RS.=C2=A0 In a personal setting, RO' won't hav= e the credentials required to get an access token from AS-RS and will only = be able to get an access token from RO or AS-RO.

    The reality is that RO' can discover a resource RS and can share wh= atever information with RS-AS they want and the RO may not even know about = it unless the RS decides to let them know somehow. This seems to be a drawb= ack of the capabilities approach.=C2=A0

    If RO' can reach AS-RS or RS, then RO'= can share any information it has about RO.=C2=A0 That's an irreducible= problem that occurs no matter what access control model you use.=C2=A0 RO = should disclose to RO' only information RO' needs to act on behalf = of RO.=C2=A0 Any violation of the privacy agreement by RO' is between R= O and RO'; AS-RS has no knowledge of it.=C2=A0 It's up to RO to dec= ide if the risk of potential exposure of the disclosed information is worth= the benefit of delegating to RO'.=C2=A0 (You can replace RO' with = client.)=C2=A0 That's the way I like to think of trust.=C2=A0 Not, &quo= t;Do I trust this guy?", but "In what ways am I vulnerable to thi= s guy's bad behavior?"=C2=A0

    In term= s of privacy and control, I, as the RO, want a contract=C2=A0with the RS th= at says that I or my agent (AS-RO) must sign an access token. This is a fun= damental audit requirement. Without it, a rogue RS and AS-RS can do all sor= ts of things and the RO would never know. I understand that a rogue RS migh= t not support an honest contemporaneous log of access tokens presented so t= here's a trust issue here that I seems unavoidable unless I specify in = my RO-RS contract that they use a separate contemporaneous=C2=A0log such as= AS-RO for every access token presented and risk being sued if they process= an access token without also updating the separate log.

    Whether or not access tokens = and/or the requests made with them must be signed is up to the provider of = the service.=C2=A0 Some low-value services may not want the overhead of ver= ifying signatures.=C2=A0 High-value services almost always will.=C2=A0 As f= ar as a rogue service goes, signing alone doesn't help you.=C2=A0 The r= ogue service could create a key pair and claim you provided the public key.= =C2=A0 You'll need additional mechanisms to get that guarantee.=C2=A0= =C2=A0

    You've got more problems than non-repud= iation if the service is malicious.=C2=A0 Our philosophy with HP's E-sp= eak product was, "Fool me once, shame on you.=C2=A0 Fool me twice, sha= me on me."=C2=A0 You can rely on reputation or bootstrap trust, as was= shown in the Digital Silk Road project from the 1990s,=C2=A0https://www.semanti= cscholar.org/paper/The-Digital-Silk-Road-Hardy-Tribble/4cf20dc626013d112f43= 4022c50a1f18848077e1.

    Signing access tokens an= d requests using them is the standard pattern in certificate-based capabili= ty systems, e.g., SPKI, zcap-ld.=C2=A0 A nice feature of these systems is t= hat each token can be issued to a public key created solely for that token,= =C2=A0making correlation difficult.=C2=A0 Those other systems use non-opaqu= e tokens, but there is no reason the tokens can't be opaque.=C2=A0

    --------------
    Alan Karp


    On Thu, Mar 25, 2021 at 2:50 P= M Adrian Gropper <agropper@healthurl.com> wrote:
    My issue= is with Alan's:
    "7. Another user agent (RO') can contact= any holder of the access token or the service's policy agent (AS-RS) t= o get a delegated access token."

    I would pr= efer "7A.=C2=A0Another user agent (RO') can contact any holder of the acces= s token." by default so that the AS-RS does not see the requests. In o= ther words, the RS and AS-RS only see access tokens. The requests (from RO&= #39;) that resulted in an access token are none of their business.

    The reality is that RO' can discover a resou= rce RS and can share whatever information with RS-AS they want and the RO m= ay not even know about it unless the RS decides to let them know somehow. T= his seems to be a drawback of the capabilities approach.=C2=A0

    In terms of privacy and control, I, as the RO, want = a contract=C2=A0with the RS that says that I or my agent (AS-RO) must sign = an access token. This is a fundamental audit requirement. Without it, a rog= ue RS and AS-RS can do all sorts of things and the RO would never know. I u= nderstand that a rogue RS might not support an honest contemporaneous log o= f access tokens presented so there's a trust issue here that I seems un= avoidable unless I specify in my RO-RS contract that they use a separate co= ntemporaneous=C2=A0log such as AS-RO for every access token presented and r= isk being sued if they process an access token without also updating the se= parate log.

    - Adrian
    =


    On Thu, Mar 25, 2021 at 1:22 PM Alan Karp <alanhkarp@gmail.com&g= t; wrote:
    Justin Ri= cher <jricher@mit.e= du> wrote:

    Hmmm.=C2=A0 I guess not.=C2=A0 It= 's just that the person would be using some UI to express their decisio= ns to what I called the user agent.=C2=A0 That model fits in very nicely wi= th what we did with Polaris, our virus safe computing environment for Windo= ws XP, https://dl.acm.org/doi/10.1145/1151030.1151033.=C2=A0 The pers= on would click on the icon for a Word file, and an instance of Word would o= pen with only the permission needed to edit that one file.=C2=A0 Same thing= here.=C2=A0 The client could ask for permission to use the resource, or pe= rmission could be granted implicitly when the user selects a resource assoc= iated with a specific client.

    --------------
    A= lan Karp


    On Thu, Mar 25, 2021 at 9:53 AM Justin Richer <<= a href=3D"mailto:jricher@mit.edu" target=3D"_blank">jricher@mit.edu>= wrote:
    Hi = Alan,

    In all of my discussion, and in the spec itself, t= he RO is the :entity: in charge of approving rights. They=E2=80=99re probab= ly a person. It might be software that makes a policy decision in some way,= or a corporate entity, or something like that. But it=E2=80=99s not assume= d to be a computational agent in the terms of the protocol itself. Would th= at recast what you=E2=80=99re saying below?

    =C2=A0= =E2=80=94 Justin

    On Mar 25, 2021= , at 12:36 PM, Alan Karp <alanhkarp@gmail.com> wrote:

    There seems to be some confusion about how AS-RO comes into the picture,= probably because of the "AS" part.=C2=A0 I'm going to try to= clear up that confusion by more carefully explaining what I mean.

    =
    I'm assuming that RO is a computational agent representing the per= son who is the resource owner, something called the "user agent" = in operating systems lingo.=C2=A0 I'm also assuming that it's possi= ble to do delegation, either locally or by token exchange with AS-RS.=C2=A0= All delegations are potentially sub-scoped, but you may also want to deleg= ate with full scope to have a separately revocable access token.
    =
    =C2=A0 Here's an example of how things work in a capabil= ity oriented system.
    1. Someone, the service owner, crea= tes a service.
    2. The service owner contracts with an policy agent (AS= -RS) to create and manage access tokens for that service (RS).
    3. A pe= rson wishing to create a resource at RS uses their user agent (RO) to conta= ct the service owner's policy agent (AS-RS) and gets back an access tok= en for that resource.
    4. That user agent (RO) can=C2=A0
      1. us= e that access token to invoke the resource, or
      2. delegate an access t= oken to a client of the user agent's (RO) choice, or
      3. contract w= ith a policy agent (AS-RO) to manage those delegations on behalf of the use= r agent (RO), or
      4. specify a policy with the service's policy age= nt (AS-RS).
    5. A client can contact any holder of the access toke= n (the user agent (RO) or its policy agent (AS-RO)) or the service's po= licy agent (AS-RS) to get a delegated access token.
    6. That client can= delegate that token to another client.
    7. Another user agent (RO'= ) can contact any holder of the access token or the service's policy ag= ent (AS-RS) to get a delegated access token.
    8. The other user agent (= RO') can=C2=A0
      1. use that access token to invoke the resource= , or
      2. delegate it to a client of its choice, or
      3. contract wit= h a policy agent (AS-RO') of its choosing to manage those delegations = on its behalf, or
      4. specify a policy with the service's policy ag= ent (AS-RS).
    9. and so on
    When any = of these computational agents, user agents (ROs) or clients acting on their= behalf, invokes the resource, AS-RS verifies that the access token is a va= lid delegation, i.e., proper sub-scoping, hasn't been revoked, and that= it authorizes the request being made before telling the service (RS) to ho= nor the request.=C2=A0 At no point does the service's policy agent (AS-= RS) know which computational agent did any particular delegation.=C2=A0 (To= ken exchange can be done as anonymously as possible.)=C2=A0 In particular, = the policy agents (AS-RO) need not be the same, or even compatible with, th= e service's policy agent (AS-RS).=C2=A0 GNAP specifies the protocol bet= ween requesters, invokers, delegators (for token exchange) of tokens and AS= -RS.=C2=A0 That protocol need not be used between user agents (RO), clients= , or other policy agents (AS-RO), but it is likely to be.

    =C2=A0-------------
    Alan Karp
    =

    On Thu, Mar 25, 2021 at 5:45 AM Justin Richer <jricher@mit.edu> wrote= :
    The way I= =E2=80=99m thinking about Adrian=E2=80=99s use case is that what we=E2=80= =99re calling the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an =E2=80=9CAS=E2= =80=9D in the traditional OAuth/GNAP sense, at least not exactly. This is t= he agent that the RO can use to set policies and manage consent on their be= half, and I=E2=80=99ve been arguing that it fits better into this vaguely-d= efined =E2=80=9Cinteraction component=E2=80=9D aspect of the current AS def= inition, and it=E2=80=99s not currently separated from the AS definition. T= he =E2=80=9CAS-RS=E2=80=9D maps to what we=E2=80=99d call the =E2=80=9CAS= =E2=80=9D in OAuth/GNAP traditionally, it=E2=80=99s what the RS trusts to i= ssue tokens. In traditional OAuth the AS-RO and AS-RS are always the same t= hing, from a functional protocol perspective. An important point here is th= at from a client=E2=80=99s perspective, they=E2=80=99re only talking to the= AS-RS since that=E2=80=99s where the client gets its tokens, because at th= e end of the day the client just wants to call the API at the RS and doesn= =E2=80=99t care how that happens (from a protocol standpoint).=C2=A0
    Note well: Even thought I don=E2=80=99t believe that =E2=80=9C= AS-RO=E2=80=9D is an authorization server at all, I=E2=80=99m going to keep= using that term below for consistency with previous discussion.
    =
    So we have these fundamental relationships around getting th= e client to access the RS:

    1. RS trusts=C2=A0AS-RS= =C2=A0to issue tokens that RS will accept, validate, and process for reques= ts from client
    2. Client trusts=C2=A0AS-RS=C2=A0to issue tokens t= hat client can use at RS
    3. RO trusts RS to protect RO=E2=80=99s = api through delegated access

    On top of that, we=E2= =80=99ve got some additional aspects that we=E2=80=99re discussing:

    4. RO trusts=C2=A0AS-RO=C2=A0to manage RO=E2=80=99s polic= ies at runtime
    5.=C2=A0AS-RS=C2=A0trusts=C2=A0AS-RO=C2=A0to asser= t RO=E2=80=99s policies for access to RS
    6. Client trusts whateve= r=C2=A0AS-RS=C2=A0sends client to deal with, including possibly RO-AS at ru= ntime, because of (2)

    What I have been saying is t= hat 4/5/6 are optional details of how RS-AS runs things, and I think this a= lso maps with Adrian=E2=80=99s view of choice, since if my RS=E2=80=99s AS-= RS doesn=E2=80=99t allow me to plug in my own AS-RO then I would be motivat= ed to pick a different RS who=E2=80=99s AS-RS lets me do just that. The sam= e way I=E2=80=99d pick a different RS if their surrounding services didn=E2= =80=99t accept my preferred federation login and I didn=E2=80=99t want to m= ake another account. Of course, market forces being as they are, I might no= t have much of an actionable choice in RS, but GNAP can=E2=80=99t change th= at.=C2=A0

    What we can do is make it possible for A= S-RS to talk to AS-RO, both in philosophy of the protocol design and in con= crete hooks to support (6) above.=C2=A0

    Separately= , we can approach the issue of making 1/2 above more dynamic. This was UMA2= =E2=80=99s =E2=80=9Cfederated authorization=E2=80=9D approach, and is behin= d a lot of the =E2=80=9Cbring your own AS=E2=80=9D models out there. The pr= oblem with these is that we know from many years of experience that most RS= =E2=80=99s aren=E2=80=99t interested in doing anything of the sort.

    So with GNAP we can instead allow 4/5/6 to vary in a pred= ictable and consistent way, letting the RS keep control over 1/2, thereby e= nabling choice in (3). We don=E2=80=99t have to be the ones who define the = all of the details of every permutation of (5) to enable this, though. Some= of this is going to be configuration out of band, some of it=E2=80=99s goi= ng to be communication at runtime. This is where VC=E2=80=99s, ZCAPs, CHAPI= , DIDComm, FIDO, and a whole swath of other tech can come in and help out. = I don=E2=80=99t think we need to put all the details for using these into c= ore, nor do I think we=E2=80=99ll pull of The Great And Ultimate Abstractio= n for using these and other approaches. But we can at least start talking a= bout =E2=80=9CAS-RS=E2=80=9D in such a way that it no longer assumes it=E2= =80=99s always the same party dealing with the RO directly.

    =C2=A0=E2=80=94 Justin

    O= n Mar 25, 2021, at 6:40 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    To reframe it closer to GNAP:
    - AS =3D AS= -RO, that's where you find the RO policies. The AS issues access tokens= to the client.
    - the RO policies could be a) defined locally or = b) in relationship with the RS

    There have been sev= eral ideas related to the AS-RS relationship b:
    b1) the RS is= sues capabilities (which can be further attenuated by the RO)
    b2)= Adrian also discussed a DID based solution
    b3) there was also an= alternative ACL proposal from Denis (+ preflight)

    Fabien


    On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbaul= t <fabien.= imbault@gmail.com> wrote:
    Ok so I get you correctly:=C2=A0
    - wh= at matters is the RQ (could be a RO or a end-user or both : we don't re= ally care at a high-level, they're all treated as entities that make a = request)
    - the policy is able to handle those different cases, ba= sed on its own internal delegation protocol
    - currently that requ= ires AS-RS and AS-RO, but maybe it can be simplified

    To answer to Denis, here's what I understood:
    - RO trusts = AS-RS (and then handles its own policies within AS-RO)
    - end-= user trusts AS-RO (through its client)

    Could proba= bly work but that's a fairly different model compared to OAuth2 (and of= today's GNAP), with different frontiers between the AS and the RS.=C2= =A0

    Please do not hesitate to correct me if I'= m wrong.

    Fabien=C2=A0

    On Thu, Mar 25, 2021 at= 9:26 AM Adrian Gropper <agropper@healthurl.com> wrote:
    I believe there are al= ternatives to having two kinds of ASs. The problem may be a side-effect of = deciding to switch away form treating the RO as different from the RQ. That= leads to downstream privacy issues. Our desire for architectural simplicit= y is admirable but that may have been a step too far.

    There may also be solutions based on differen= t types of tokens, as in different capabilities (tokens signed by the RS) v= s. tokens signed by the AS. I=E2=80=99m not sure about that but Alan might = have more to say.

    Adrian=

    On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault <fabien.imbault@gmail.com>= wrote:
    Thanks. The general problem statement is clear.

    The=C2=A0proposed solution a bit less (to me). I understood that from poin= t 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obvious reason to have two types of ASs".=C2=A0<= /span>Do you see an alternative ?

    Regarding = the last item, I don't think that naming RQ by end-user created the pro= blem. It might just highlight the asymmetry,=C2=A0which fundamentally exist= s.=C2=A0

    Fabien


    On Thu, Mar 25, 2021 at 8:48 AM A= drian Gropper <agropper@healthurl.com> wrote:
    Recap:
    1 = - Justin (I think) introduced the idea of an AS on the RS trust boundary si= de.
    2 - I said the RO should not have to share polic= ies with the RS.
    3 - Alan invented the concept of AS= -RO and AS-RS to separate two kinds of PDPs.=C2=A0
    <= br>
    The thing is that step 2 is not symmetrical. The= RO has a legitimate privacy interest in keeping their policies private and= minimizing the leakage of information about requests that are posed agains= t those policies.=C2=A0

    = The RS, on the other hand, should be publishing its policies (e.g. what it= =E2=80=99s selling or what jurisdiction it=E2=80=99s in or what tokens or s= copes it supports). The RS has no obvious privacy interest in GNAP. It=E2= =80=99s just an enforcer.

    There is one other privacy interest to consider around the RS and that is= the requesting party (the end-user that is not the RO :-) might prefer to = share attributes with the RS instead of the RO or something controlled by t= he RO. This case could be an =E2=80=9Cextension=E2=80=9D to GNAP and might = result in a split AS as a solution. This problem was introduced when the ed= itors decided to replace RQ with end-user. Obviously, the RO end-user has n= o privacy interests relative to itself.

    Adrian

    <= br>


    On Thu, Mar 25, 2021 at 3:24 AM Fabien = Imbault <f= abien.imbault@gmail.com> wrote:
    I was referring to "By my definition, this model has two ASs= since both are processing requests into tokens". If there's no re= ason to have 2 types of ASs, that's fine then.=C2=A0
    But I'm a bit lost in where we st= and with the idea.=C2=A0

    Could yo= u recap?=C2=A0

    Fabien=C2=A0

    Le jeu. 25 mars 2021 =C3=A0 08:16, Adri= an Gropper <= agropper@healthurl.com> a =C3=A9crit=C2=A0:
    There=E2=80=99s no obv= ious reason to have two types of ASs. Any AS that is executing the policies= of the RS can look to GNAP like the RS itself. Why would GNAP expose that = interface to anyone?=C2=A0

    Adrian

    On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault <f= abien.imbault@gmail.com> wrote:
    Note : I'm not sure that's= a good idea, but having 2 types of ASs is not that easy to grasp.

    Fabien=C2=A0

    Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault <fabien.imba= ult@gmail.com> a =C3=A9crit=C2=A0:
    The purpose of either handling = policies locally or delegating them to the RO agent.=C2=A0

    Le jeu. 25 mars 2= 021 =C3=A0 08:04, Adrian Gropper <agropper@healthurl.com<= /a>> a =C3=A9crit=C2=A0:


    On Thu, Mar 25, 2021 at 2:= 59 AM Fabien Imbault <fabien.imbault@gmail.c= om> wrote:
    Isn't the AS-RO a component of the AS? Same idea as= the interact component, it functionnally belongs to the AS role but could = be deployed either as a monolith or as a separate component?

    Fabien
    <= br>
    Le jeu.= 25 mars 2021 =C3=A0 04:26, Adrian Gropper <ag= ropper@healthurl.com> a =C3=A9crit=C2=A0:
    Yes, but I would say it= =E2=80=99s not the RO that wants the access token. It=E2=80=99s the RO that= wants the client making the request to get an access token.=C2=A0

    Adrian

    On Wed, Mar 24, 2021= at 11:22 PM Alan Karp <alanhkarp@gmai= l.com> wrote:
    Adrian Gropper <agropper@healthur= l.com> wrote:

    In this design, the A= S is the AS-RS and the agent is the AS-RO. By my definition, this model has= two ASs since both are processing requests into tokens. The problem with t= his is complexity and privacy. The RO may not want to share the request inf= ormation with the AS-RS.

    More precisely, RO has no choice but to present the= required information to AS-RS if RO wants an access token.=C2=A0 However, = RO does not want AS-RS to know the policy by which RO delegates tokens.=C2= =A0 That's why RO uses AS-RO for those delegations.

    --------------
    Alan Karp


    On= Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Thank y= ou for creating the issue. My definition of AS is independent of AS-RO or A= S-RS.=C2=A0https://github.com/ietf-wg-gnap/gnap-core-proto= col/issues/223#issuecomment-806280421 I also agree with Alan's defi= nition based on delegation. An AS-RS would be a delegate of the RS.=C2=A0

    Based on that, I see it as obvious=C2= =A0that the policy has to be accessible (defined locally?) in order for it = to be run as the code that turns a request into an access token.=C2=A0

    The only other possibility is that the request is pack= aged by the AS and sent elsewhere (an agent) for evaluation against policy = and a proto-token returned. In that case the AS is acting as a proxy and th= e PDP is elsewhere. I can imagine that an AS-RS would behave this way so th= at the proto-token could be turned into an access token by the AS-RS. Isn&#= 39;t this what Justin is proposing? In this design, the AS is the AS-RS and= the agent is the AS-RO. By my definition, this model has two ASs since bot= h are processing requests into tokens. The problem with this is complexity = and privacy. The RO may not want to share the request information with the = AS-RS.

    Adrian

    On Wed, Mar 24, 2021 at 5:21 PM= Fabien Imbault <fabien.imbault@g= mail.com> wrote:
    Isn't that what the AS is supposed to be= , only with the caveat that the policy is defined locally?=C2=A0

    Fabien=C2=A0


    Le mer. 24 mars 2021 =C3= =A0 20:17, Alan Karp <alanhkarp@gmail.= com> a =C3=A9crit=C2=A0:
    AS-RO is an AS that RO tr= usts to delegate RO's access tokens according to RO's policies.=C2= =A0=C2=A0

    --------------
    Alan= Karp


    On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault <fabien.imbault@gmail.com= > wrote:
    Hi Alan and Adrian,

    I've created issue = AS-RO policy delegation (https://github.com/ietf-wg-gnap/gnap-core-pro= tocol/issues/223) to capture your input.=C2=A0
    A first questi= on that arises: can we give a definition to AS-RO?

    Thanks
    Fabien

    On Tue, Mar 23, 2021 at 4:15 PM Alan Karp <= ;alanhkarp@gmail.com> w= rote:
    Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan,=C2=A0
    Yes, but in that flow, the token relationship between AS-R= S and AS-RO is only secure if the tokens issued by AS-RS are cryptographica= lly attenuable in the first place.=C2=A0
    =C2= =A0
    Attenuated delegation is a requirement, but = that doesn't have to be done cryptographically.=C2=A0 Token exchange wo= rks just fine.=C2=A0 SPKI and zcap-ld are examples of the crypto approach, = and we used token exchange in the system for HP.
    =
    --------------
    Alan Karp


    On Tue, Mar 23, 2021 at 4:12= AM Fabien Imbault <fa= bien.imbault@gmail.com> wrote:
    Hi Alan,=C2=A0

    Ye= s, but in that flow, the token relationship between AS-RS and AS-RO is only= secure if the tokens issued by AS-RS are cryptographically attenuable in t= he first place.=C2=A0

    Fabien

    On Mon, Mar 22, = 2021 at 9:26 PM Alan Karp <= alanhkarp@gmail.com> wrote:
    Justin Richer <= jricher@mit.edu> wrote:

    But with all that in mind, I think = the key here is going to be looking at what the inputs to the AS are, and h= ow those can be defined in an interoperable way for AS=E2=80=99s that can a= ccept them. I think there=E2=80=99s a lot of room for innovation and flexib= ility here that doesn=E2=80=99t break the trust model or core use cases. If= I have an AS-RS set that won=E2=80=99t accept my favorite flavor of policy= engine inputs, then I can decide not to use that one. But this is a very d= ifferent question than saying the RS itself needs to accept my own AS =E2= =80=94 and we can=E2=80=99t keep conflating these two models.
    I agree.=C2=A0 The point of having an AS-RO = is to allow RO to specify a policy for which of RO's access tokens shou= ld be delegated under what conditions.=C2=A0 AS-RS should not need to under= stand those policies.=C2=A0 The flow would be
    • RO contacts= AS-RS and gets one or more access tokens.
    • RO delegates one or more= of those tokens, potentially sub-scoped, to AS-RO.
    • A different use= r contacts AS-RO to get a potentially sub-scoped access token from AS-RO.
    • That user presents the access token delegated by AS-RO when invoking= the resource.
    AS-RS only needs to verify that the= delegation chain is legitimate, e.g., no increase in scope, and that it gr= ants permission for the request being made.=C2=A0 AS-RS does not need to un= derstand the policy behind granting the delegation by AS-RO.

    --------------
    Alan Karp


    On Mon, Mar 22, 202= 1 at 11:40 AM Justin Richer <jr= icher@mit.edu> wrote:
    Adrian,

    I think this shows the problem= with the terminology as it=E2=80=99s been applied in this conversation, wh= ich I=E2=80=99ve tried to shine light on before. What you and others are ca= lling the =E2=80=9CRS=E2=80=9D is really the =E2=80=9CAS and RS working tog= ether=E2=80=9D =E2=80=94 everything to the right of the line. When Denis ha= d brought up =E2=80=9Celiminating the AS=E2=80=9D in another thread, what h= e=E2=80=99d really done is labeled everything to the right of the line as t= he =E2=80=9CRS=E2=80=9D. Of course, the irony here is that everything to th= e right of the line used all be called the =E2=80=9CAS=E2=80=9D or simply = =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say below, I don=E2=80= =99t want the client to have visibility on what happens on that side.=C2=A0=

    Note well: The Google+ logo labeled =E2=80=9CIdP= =E2=80=9D in the diagram is not the AS, as far as GNAP is concerned. It doe= s not issue an access token that the RS will accept. The elements to the le= ft of the line could be a lot of things, but they are NOT the AS =E2=80=94 = by definition. The client lives over on the left, but so do any external in= puts to the AS. These could be policy inputs on behalf of the RO, they coul= d be presentation artifacts, they could be federated logins, they could be = the output of policy decisions. How the AS comes to trust those things is u= p to the AS=E2=80=99s implementation. It=E2=80=99s something we can talk ab= out, but ultimately GNAP won=E2=80=99t be in any position to dictate becaus= e in practice some AS=E2=80=99s are simply going to internalize all policie= s and we will never successfully force those open.=C2=A0

    But with all that in mind, I think the key here is going to be looki= ng at what the inputs to the AS are, and how those can be defined in an int= eroperable way for AS=E2=80=99s that can accept them. I think there=E2=80= =99s a lot of room for innovation and flexibility here that doesn=E2=80=99t= break the trust model or core use cases. If I have an AS-RS set that won= =E2=80=99t accept my favorite flavor of policy engine inputs, then I can de= cide not to use that one. But this is a very different question than saying= the RS itself needs to accept my own AS =E2=80=94 and we can=E2=80=99t kee= p conflating these two models.

    So to me, GNAP can = support a Zero Trust Architecture by LEVERAGING the AS, not by subsuming or= eliminating it. It is in fact the AS, not the client and not the RS, that = will request and consume the results of a privacy-preserving zero-trust pol= icy query thing. Anything that happens downstream from that is of little co= ncern to the zero-trust components because, as you point out, it=E2=80=99s = on the =E2=80=9Cother side=E2=80=9D of the line.=C2=A0

    =
    I think we got this basic component model pretty right in OAuth: the A= S and RS and client working together. Where OAuth misses the mark is the as= sumption that the user has to log in to the AS through a webpage and intera= ct directly, thereby proving they=E2=80=99re the RO. It=E2=80=99s this latt= er space where I think we can both push innovation and also address the imp= ortant and compelling use cases like the ones you=E2=80=99re bringing.

    =C2=A0=E2=80=94 Justin

    On Mar 22, 2021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> wrote:
    I'm sorry, Justin. As a Resource Owner, I lo= ok at the RS trust boundary (the dotted line in the diagram) as being the R= S. I don't expect any visibility into what's going on on the=C2=A0r= ight.=C2=A0

    My problem with the framing you propose is t= hat requests are going to the RS (or the AS-RS) and I don't want to sha= re my policies with the AS-RS. I want to keep the RS and AS-RS as ignorant = as possible.

    Adrian

    On Mon, Mar 22, 2021 at 1= :48 PM Justin Richer <jricher@m= it.edu> wrote:
    Adrian,

    What you=E2=80=99re discussing below,= in terms of logging in to a site, is not approaching the RS. You are in fa= ct approaching the client, and identifying both the AS and RS to the client= . The client is a client of your identity in this model, and the RS = is part of the identity provider. It=E2=80=99s really important that we don= =E2=80=99t conflate the RS and client in this way as it leads to a lot of c= onfusion downstream and a lot of broken trust boundaries.

    With that model in mind, approaching the =E2=80=9CRS" and prov= iding it your identity is really just a case of the =E2=80=9Cfederated logi= n to AS=E2=80=9D pattern that we discussed on the WG call. The user here ap= proaches an RS, which has its own AS. To share things from this RS, the RO = has to authenticate to the RS=E2=80=99s AS. This particular AS allows the R= O to do so using an external identity =E2=80=94 in which case, the AS is no= w a =E2=80=9Cclient=E2=80=9D of a separate, disconnected (but layered) dele= gation. The ultimate client that eventually calls the RS down the way may o= r may not know about these layers.=C2=A0

    <PastedGr= aphic-1.png>
    This same AS, which is closely tied to the= RS and trusted by the RS, might also take in FIDO credentials, or DIDs, or= any number of other proof mechanisms. The output of this is an access toke= n the RS trusts, but the input is up to the AS. The RS is not what you=E2= =80=99re logging in to.

    =C2=A0=E2=80=94 Justin
    =

    On Mar 22, 2021, at 1:28 PM, Adrian= Gropper <agropper@healt= hurl.com> wrote:

    I too am in favor of= avoiding consolidation and correlation. Right now, when I approach a servi= ce provider (RS) for the first time, I'm offered the opportunity to ide= ntify my persona as: email, sign-in with Google, Facebook, or Apple. I know= there are people who try to create one-off email addresses but that is mos= tly a waste of time.=C2=A0

    So, along come FIDO2 and DID = wallets to the rescue. Now, in theory, I have a way to start out my RS rela= tionship pseudonymously.=C2=A0

    When I want my reso= urce to be discovered or shared I will post that RS URL including my pseudo= nym. If I then want to introduce a mediator=C2=A0in front of my AS or messa= ging service=C2=A0endpoint, I have that option. If I want to keep requests = away from the mediator, I would publish an encryption key along with my pse= udonym.

    - Adrian



    On Mon, Mar 22, 2021 at 9:55 AM Justin Richer <jricher@mit.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin Kadu= k <kaduk@mit.edu> wrote: >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhk= arp@gmail.com> shared a talk about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-= gnap/gnap-core-protocol/issues/145#issuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --
    TXAuth 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
    --
    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
    --0000000000006bde0205be721dc1-- From nobody Fri Mar 26 08:26:23 2021 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 08BF23A2124 for ; Fri, 26 Mar 2021 08:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 TFQQYMz50TpA for ; Fri, 26 Mar 2021 08:26:14 -0700 (PDT) Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43]) (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 DFD373A2121 for ; Fri, 26 Mar 2021 08:26:13 -0700 (PDT) Received: by mail-ua1-f43.google.com with SMTP id y20so1520282uay.6 for ; Fri, 26 Mar 2021 08:26:13 -0700 (PDT) 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=VYx1GtEDW61XUp1SCnP5Gw1KgbT5YVEOD35BEEcAfDo=; b=jQCbKoIUrojhN6xtZaOEhEvCG6NwUvT/T7kI1pIFBJpYoG2o4zjcxkaDV8WWPV82cY oRSCwAU7vvmKjIYwPtG7mbaJxIMKVR2nA6r4uIHRb84V4zV6tnwukM0Q1iKaQytxrmYO 1vwgZnQqZY9KGtZw+oy8HTCh2uXGwQLJvcp5k78o4apjyLQHTN8uhni3LMvZJnsstQdV kDqyegC1WPxP+t3zuX7mgC7k+ZP9itkVnjd8pQQT1C3Ez3zz2dTpyLwsOqLvEm+O32qF 7JS7TiwKvcJdgjLbgaqBdGjUBGUFX02n6uQoLOVu71+fdzlIFD/HeSvCZ9YwCBgkgWJi TAnw== X-Gm-Message-State: AOAM533P0Pn/FzTp1bSsCvob6RaEkgvY8KXpZVkljBBZofYwdW4jy+Ou WqhRRChzdJ47uJSLlSjhLubqFxiVKbvxtytXgZBTG2dcR5Y= X-Google-Smtp-Source: ABdhPJzTTx7GBBjTwz6MfWtS8X2rAC8fGhpGvklkPVBqrm19v0V4V/CBbL85MCgICb2lPMV86YlOyONlKn85UoP0iv0= X-Received: by 2002:ab0:30a3:: with SMTP id b3mr7942954uam.0.1616772372289; Fri, 26 Mar 2021 08:26:12 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> <5773FA7B-6891-4227-A8CA-2F506909B8CD@mit.edu> <497B7A43-546E-4296-916F-6D177AEBE228@mit.edu> In-Reply-To: <497B7A43-546E-4296-916F-6D177AEBE228@mit.edu> From: Adrian Gropper Date: Fri, 26 Mar 2021 11:26:00 -0400 Message-ID: To: Justin Richer Cc: Alan Karp , Benjamin Kaduk , Fabien Imbault , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="000000000000eedc9e05be7226b8" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2021 15:26:22 -0000 --000000000000eedc9e05be7226b8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Good. I agree with the externalizing framing you use. To me, they are a pair. They represent the separation of concerns I=E2=80=99m focused on. The= AS has policies, gets requests from clients, and returns access tokens. So what are we disagreeing about? - Adrian On Fri, Mar 26, 2021 at 10:38 AM Justin Richer wrote: > Adrian, > > Yes, the RO is the party/entity which holds the rights for delegation, an= d > they perform that delegation to a piece of software (the client) through > the AS. The RS is what they=E2=80=99re delegating the access of, for API-= access use > cases (again, user/subject information is similar but different). > > There isn=E2=80=99t a delegation between the RS and AS, then. You can per= haps view > them as externalizing functions that they might otherwise hold close, but > not delegating in the same way the client gets delegated to. You can fram= e > it one of two ways: > > - The RS externalizes its security, policy, authorization, and delegatio= n > functions to the AS and looks for access tokens from the AS as proof of > that happening (this is the most in line with the model you=E2=80=99ve be= en > presenting) > - The AS externalizes its data-API functions to into the RS and produces > access tokens for the RS to consume/validate (this is actually the model > that OAuth 2 started with, in extracting the RS as a separate entity as > opposed to OAuth 1) > > They tell different views of the same reality. In OAuth, it=E2=80=99s ass= umed that > the RO interacts with the AS directly to perform the delegation to the > client. In GNAP, we=E2=80=99ve got an opportunity to expand that, which h= as been > (to me) one of the biggest outcomes of this discussion. > > =E2=80=94 Justin > > On Mar 26, 2021, at 10:04 AM, Adrian Gropper > wrote: > > Justin, > > Big YES to =E2=80=9C The conceptual framework of an AS that takes in lots= of > different information and spits out access tokens is exactly the > abstraction layer that is necessary for making these use cases > interoperable.=E2=80=9D and probably everything else you just said. > > I seem to not understand the delegation design between RS and AS. In my > view, that delegation always goes through the RO, although the RO may be > forced to choose from a list provided by the RS. > > In my view, GNAP, can acknowledge this and design to be agnostic to > whether the AS is specified by he RO or picked from a list of 1 or more > choices provided by the RS. > > - Adrian > > On Fri, Mar 26, 2021 at 9:30 AM Justin Richer wrote: > >> Adrian, >> >> I disagree, I believe that what I have laid out is exactly separating th= e >> concerns into working components. >> >> Like OAuth before it, GNAP is a protocol negotiate access for a client >> instance to an RS, using an AS as the facilitator of that delegated >> negotiation. (Unlike OAuth, it=E2=80=99s importantly also for negotiatin= g user >> information to the client directly from the AS with no RS involved, but >> that=E2=80=99s an aside for the purposes of our conversation here). >> >> If a particular GNAP RS also allows other kinds of processes to enable >> access to it, that is completely fine, but outside of GNAP. If an RS all= ows >> a username/password HTTP Basic auth in addition to accepting access toke= ns, >> it can do so, but GNAP doesn=E2=80=99t have anything to say about the Ba= sic auth >> use, or even its relation to any access tokens or RO=E2=80=99s or anythi= ng else. If >> an RS accepts structured access tokens signed by trusted keys that don= =E2=80=99t >> come from an AS through a negotiated request =E2=80=94 again, that=E2=80= =99s fine, but GNAP >> is silent about the RS doing that. If the RS acts as =E2=80=9Cits own AS= =E2=80=9D then it=E2=80=99s >> really just an RS and an AS living in the same box. Again, that=E2=80=99= s fine, and >> super common with OAuth today. >> >> GNAP is solving the problem of connecting the client to the RS through >> means of an AS. Other solutions are possible and many of them can be >> deployed right alongside, but that=E2=80=99s not the corner of the world= that GNAP >> is solving. GNAP should be concerned about how these other technologies = can >> be used alongside it. I think there=E2=80=99s a lot of room for the thin= gs that >> you=E2=80=99re talking about, and more importantly for solving the use c= ases that >> you=E2=80=99re bringing. But GNAP should be more than a single-point sol= ution, and >> so we need to balance these concerns. The conceptual framework of an AS >> that takes in lots of different information and spits out access tokens = is >> exactly the abstraction layer that is necessary for making these use cas= es >> interoperable. >> >> =E2=80=94 Justin >> >> On Mar 26, 2021, at 8:30 AM, Adrian Gropper >> wrote: >> >> @Justin, there=E2=80=99s no separation of concerns here. No partition be= tween >> processor and controller. No data minimization. And, I see no obvious >> reason to make this the core of GNAP. >> >> The one thing we can probably all agree on is that there=E2=80=99s only = one RS >> and one RO. >> >> The core of GNAP, in my opinion, can be built and explained around this >> simple design. The RS is a processor. The RO is a controller. The RS bea= rs >> only security responsibility. The RS bears no privacy responsibility. Th= e >> RO delegates this to the RS but this is not authorization as the A in GN= AP. >> >> The RO retains all rights to delegate within the scope of things that th= e >> RS is willing to support using various token formats and endpoint option= s. >> Some of these options may do all sorts of things for all sorts of client= s >> and user-agents but these are options. >> >> For example, if a request comes to the RS that is not in the form of an >> access token, then it either gets sent to the RO or their agent, or it g= ets >> logged and dumped. One such option, common in healthcare, is =E2=80=9CBr= eak the >> Glass=E2=80=9D where the RS is acting as an authorization server because= the >> user-agent is making a request instead of presenting an access token. GN= AP >> can offer this as an option but it is not our core. >> >> Adrian >> >> >> >> On Fri, Mar 26, 2021 at 7:15 AM Justin Richer wrote: >> >>> I have a big problem with this line: >>> >>> > the RS and AS-RS only see access tokens. The requests (from RO') that >>> resulted in an access token are none of their business. >>> >>> In the trust model we=E2=80=99ve been discussing, the requests that res= ult in >>> access tokens are *solely the business of AS-RS*, since AS-RS is the >>> only entity that=E2=80=99s allowed, and trusted by the RS, to create ac= cess tokens >>> for the RS. That is its entire job, the entire reason it exists in the >>> system. By definition the party generating tokens for use at the RS is = the >>> AS for that RS, I don=E2=80=99t care how you deploy it. If RO wants to = give access >>> to someone else (who isn=E2=80=99t an =E2=80=9CRO" anymore, they=E2=80= =99re another end-user), then >>> that end user=E2=80=99s client software will need to talk to AS-RS to g= et its own >>> access token. >>> >>> Now here=E2=80=99s the trick: when the end user=E2=80=99s client instan= ce talks to >>> AS-RS, that does NOT mean that AS-RS needs to know all the details and >>> policy reasons that it should give an access token to that client insta= nce. >>> It doesn=E2=80=99t even need to know the existence of another end user.= It doesn=E2=80=99t >>> need identity, it doesn=E2=80=99t need policy. Sure, it COULD handle al= l of that >>> internally, and many will, but the protocol doesn=E2=80=99t demand it. >>> >>> This means that the first client instance, the one that gets the access >>> token, can also be given something alongside the access token that it c= an >>> then hand to another piece of software (or to a person to hand eo their >>> piece of software). This artifact is not an access token. This artifact >>> could be something structured that the client understands, and can make >>> derivatives of, and present back to the AS-RS for getting new access >>> tokens. There could be multiple different flavors of this kind of artif= act >>> for different kinds of environments and groups. But what they all have = in >>> common is that they can potentially be used to request more access toke= ns >>> within some context at the AS-RS. >>> >>> =E2=80=94 Justin >>> >>> >>> >>> On Mar 25, 2021, at 5:50 PM, Adrian Gropper >>> wrote: >>> >>> My issue is with Alan's: >>> >>> "7. Another user agent (RO') can contact any holder of the access token >>> or the service's policy agent (AS-RS) to get a delegated access token." >>> >>> >>> I would prefer "7A. Another user agent (RO') can contact any holder of >>> the access token." by default so that the AS-RS does not see the reques= ts. >>> In other words, the RS and AS-RS only see access tokens. The requests (= from >>> RO') that resulted in an access token are none of their business. >>> >>> The reality is that RO' can discover a resource RS and can share >>> whatever information with RS-AS they want and the RO may not even know >>> about it unless the RS decides to let them know somehow. This seems to = be a >>> drawback of the capabilities approach. >>> >>> In terms of privacy and control, I, as the RO, want a contract with the >>> RS that says that I or my agent (AS-RO) must sign an access token. This= is >>> a fundamental audit requirement. Without it, a rogue RS and AS-RS can d= o >>> all sorts of things and the RO would never know. I understand that a ro= gue >>> RS might not support an honest contemporaneous log of access tokens >>> presented so there's a trust issue here that I seems unavoidable unless= I >>> specify in my RO-RS contract that they use a separate contemporaneous l= og >>> such as AS-RO for every access token presented and risk being sued if t= hey >>> process an access token without also updating the separate log. >>> >>> - Adrian >>> >>> >>> On Thu, Mar 25, 2021 at 1:22 PM Alan Karp wrote: >>> >>>> Justin Richer wrote: >>>> >>>>> Hi Alan, >>>>> >>>>> In all of my discussion, and in the spec itself, the RO is the >>>>> :entity: in charge of approving rights. They=E2=80=99re probably a pe= rson. It might >>>>> be software that makes a policy decision in some way, or a corporate >>>>> entity, or something like that. But it=E2=80=99s not assumed to be a = computational >>>>> agent in the terms of the protocol itself. Would that recast what you= =E2=80=99re >>>>> saying below? >>>>> >>>> >>>> Hmmm. I guess not. It's just that the person would be using some UI >>>> to express their decisions to what I called the user agent. That mode= l >>>> fits in very nicely with what we did with Polaris, our virus safe comp= uting >>>> environment for Windows XP, >>>> https://dl.acm.org/doi/10.1145/1151030.1151033. The person would >>>> click on the icon for a Word file, and an instance of Word would open = with >>>> only the permission needed to edit that one file. Same thing here. T= he >>>> client could ask for permission to use the resource, or permission cou= ld be >>>> granted implicitly when the user selects a resource associated with a >>>> specific client. >>>> >>>> -------------- >>>> Alan Karp >>>> >>>> >>>> On Thu, Mar 25, 2021 at 9:53 AM Justin Richer wrote: >>>> >>>>> Hi Alan, >>>>> >>>>> In all of my discussion, and in the spec itself, the RO is the >>>>> :entity: in charge of approving rights. They=E2=80=99re probably a pe= rson. It might >>>>> be software that makes a policy decision in some way, or a corporate >>>>> entity, or something like that. But it=E2=80=99s not assumed to be a = computational >>>>> agent in the terms of the protocol itself. Would that recast what you= =E2=80=99re >>>>> saying below? >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Mar 25, 2021, at 12:36 PM, Alan Karp wrote: >>>>> >>>>> There seems to be some confusion about how AS-RO comes into the >>>>> picture, probably because of the "AS" part. I'm going to try to clea= r up >>>>> that confusion by more carefully explaining what I mean. >>>>> >>>>> I'm assuming that RO is a computational agent representing the person >>>>> who is the resource owner, something called the "user agent" in opera= ting >>>>> systems lingo. I'm also assuming that it's possible to do delegation= , >>>>> either locally or by token exchange with AS-RS. All delegations are >>>>> potentially sub-scoped, but you may also want to delegate with full s= cope >>>>> to have a separately revocable access token. >>>>> >>>>> Here's an example of how things work in a capability oriented syste= m. >>>>> >>>>> 1. Someone, the service owner, creates a service. >>>>> 2. The service owner contracts with an policy agent (AS-RS) to >>>>> create and manage access tokens for that service (RS). >>>>> 3. A person wishing to create a resource at RS uses their user >>>>> agent (RO) to contact the service owner's policy agent (AS-RS) and= gets >>>>> back an access token for that resource. >>>>> 4. That user agent (RO) can >>>>> 1. use that access token to invoke the resource, or >>>>> 2. delegate an access token to a client of the user agent's >>>>> (RO) choice, or >>>>> 3. contract with a policy agent (AS-RO) to manage those >>>>> delegations on behalf of the user agent (RO), or >>>>> 4. specify a policy with the service's policy agent (AS-RS). >>>>> 5. A client can contact any holder of the access token (the user >>>>> agent (RO) or its policy agent (AS-RO)) or the service's policy ag= ent >>>>> (AS-RS) to get a delegated access token. >>>>> 6. That client can delegate that token to another client. >>>>> 7. Another user agent (RO') can contact any holder of the access >>>>> token or the service's policy agent (AS-RS) to get a delegated acc= ess token. >>>>> 8. The other user agent (RO') can >>>>> 1. use that access token to invoke the resource, or >>>>> 2. delegate it to a client of its choice, or >>>>> 3. contract with a policy agent (AS-RO') of its choosing to >>>>> manage those delegations on its behalf, or >>>>> 4. specify a policy with the service's policy agent (AS-RS). >>>>> 9. and so on >>>>> >>>>> When any of these computational agents, user agents (ROs) or clients >>>>> acting on their behalf, invokes the resource, AS-RS verifies that the >>>>> access token is a valid delegation, i.e., proper sub-scoping, hasn't = been >>>>> revoked, and that it authorizes the request being made before telling= the >>>>> service (RS) to honor the request. At no point does the service's po= licy >>>>> agent (AS-RS) know which computational agent did any particular >>>>> delegation. (Token exchange can be done as anonymously as possible.)= In >>>>> particular, the policy agents (AS-RO) need not be the same, or even >>>>> compatible with, the service's policy agent (AS-RS). GNAP specifies = the >>>>> protocol between requesters, invokers, delegators (for token exchange= ) of >>>>> tokens and AS-RS. That protocol need not be used between user agents= (RO), >>>>> clients, or other policy agents (AS-RO), but it is likely to be. >>>>> >>>>> ------------- >>>>> Alan Karp >>>>> >>>>> >>>>> On Thu, Mar 25, 2021 at 5:45 AM Justin Richer wrote= : >>>>> >>>>>> The way I=E2=80=99m thinking about Adrian=E2=80=99s use case is that= what we=E2=80=99re >>>>>> calling the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an =E2=80=9CAS=E2= =80=9D in the traditional OAuth/GNAP sense, at >>>>>> least not exactly. This is the agent that the RO can use to set poli= cies >>>>>> and manage consent on their behalf, and I=E2=80=99ve been arguing th= at it fits >>>>>> better into this vaguely-defined =E2=80=9Cinteraction component=E2= =80=9D aspect of the >>>>>> current AS definition, and it=E2=80=99s not currently separated from= the AS >>>>>> definition. The =E2=80=9CAS-RS=E2=80=9D maps to what we=E2=80=99d ca= ll the =E2=80=9CAS=E2=80=9D in OAuth/GNAP >>>>>> traditionally, it=E2=80=99s what the RS trusts to issue tokens. In t= raditional >>>>>> OAuth the AS-RO and AS-RS are always the same thing, from a function= al >>>>>> protocol perspective. An important point here is that from a client= =E2=80=99s >>>>>> perspective, they=E2=80=99re only talking to the AS-RS since that=E2= =80=99s where the >>>>>> client gets its tokens, because at the end of the day the client jus= t wants >>>>>> to call the API at the RS and doesn=E2=80=99t care how that happens = (from a >>>>>> protocol standpoint). >>>>>> >>>>>> Note well: Even thought I don=E2=80=99t believe that =E2=80=9CAS-RO= =E2=80=9D is an >>>>>> authorization server at all, I=E2=80=99m going to keep using that te= rm below for >>>>>> consistency with previous discussion. >>>>>> >>>>>> So we have these fundamental relationships around getting the client >>>>>> to access the RS: >>>>>> >>>>>> 1. RS trusts AS-RS to issue tokens that RS will accept, validate, an= d >>>>>> process for requests from client >>>>>> 2. Client trusts AS-RS to issue tokens that client can use at RS >>>>>> 3. RO trusts RS to protect RO=E2=80=99s api through delegated access >>>>>> >>>>>> On top of that, we=E2=80=99ve got some additional aspects that we=E2= =80=99re >>>>>> discussing: >>>>>> >>>>>> 4. RO trusts AS-RO to manage RO=E2=80=99s policies at runtime >>>>>> 5. AS-RS trusts AS-RO to assert RO=E2=80=99s policies for access to = RS >>>>>> 6. Client trusts whatever AS-RS sends client to deal with, including >>>>>> possibly RO-AS at runtime, because of (2) >>>>>> >>>>>> What I have been saying is that 4/5/6 are optional details of how >>>>>> RS-AS runs things, and I think this also maps with Adrian=E2=80=99s = view of choice, >>>>>> since if my RS=E2=80=99s AS-RS doesn=E2=80=99t allow me to plug in m= y own AS-RO then I >>>>>> would be motivated to pick a different RS who=E2=80=99s AS-RS lets m= e do just that. >>>>>> The same way I=E2=80=99d pick a different RS if their surrounding se= rvices didn=E2=80=99t >>>>>> accept my preferred federation login and I didn=E2=80=99t want to ma= ke another >>>>>> account. Of course, market forces being as they are, I might not hav= e much >>>>>> of an actionable choice in RS, but GNAP can=E2=80=99t change that. >>>>>> >>>>>> What we can do is make it possible for AS-RS to talk to AS-RO, both >>>>>> in philosophy of the protocol design and in concrete hooks to suppor= t (6) >>>>>> above. >>>>>> >>>>>> Separately, we can approach the issue of making 1/2 above more >>>>>> dynamic. This was UMA2=E2=80=99s =E2=80=9Cfederated authorization=E2= =80=9D approach, and is behind >>>>>> a lot of the =E2=80=9Cbring your own AS=E2=80=9D models out there. T= he problem with these >>>>>> is that we know from many years of experience that most RS=E2=80=99s= aren=E2=80=99t >>>>>> interested in doing anything of the sort. >>>>>> >>>>>> So with GNAP we can instead allow 4/5/6 to vary in a predictable and >>>>>> consistent way, letting the RS keep control over 1/2, thereby enabli= ng >>>>>> choice in (3). We don=E2=80=99t have to be the ones who define the a= ll of the >>>>>> details of every permutation of (5) to enable this, though. Some of = this is >>>>>> going to be configuration out of band, some of it=E2=80=99s going to= be >>>>>> communication at runtime. This is where VC=E2=80=99s, ZCAPs, CHAPI, = DIDComm, FIDO, >>>>>> and a whole swath of other tech can come in and help out. I don=E2= =80=99t think we >>>>>> need to put all the details for using these into core, nor do I thin= k we=E2=80=99ll >>>>>> pull of The Great And Ultimate Abstraction for using these and other >>>>>> approaches. But we can at least start talking about =E2=80=9CAS-RS= =E2=80=9D in such a way >>>>>> that it no longer assumes it=E2=80=99s always the same party dealing= with the RO >>>>>> directly. >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> On Mar 25, 2021, at 6:40 AM, Fabien Imbault >>>>>> wrote: >>>>>> >>>>>> To reframe it closer to GNAP: >>>>>> - AS =3D AS-RO, that's where you find the RO policies. The AS issues >>>>>> access tokens to the client. >>>>>> - the RO policies could be a) defined locally or b) in relationship >>>>>> with the RS >>>>>> >>>>>> There have been several ideas related to the AS-RS relationship b: >>>>>> b1) the RS issues capabilities (which can be further attenuated by >>>>>> the RO) >>>>>> b2) Adrian also discussed a DID based solution >>>>>> b3) there was also an alternative ACL proposal from Denis (+ >>>>>> preflight) >>>>>> >>>>>> Fabien >>>>>> >>>>>> >>>>>> On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>>> Ok so I get you correctly: >>>>>>> - what matters is the RQ (could be a RO or a end-user or both : we >>>>>>> don't really care at a high-level, they're all treated as entities = that >>>>>>> make a request) >>>>>>> - the policy is able to handle those different cases, based on its >>>>>>> own internal delegation protocol >>>>>>> - currently that requires AS-RS and AS-RO, but maybe it can be >>>>>>> simplified >>>>>>> >>>>>>> To answer to Denis, here's what I understood: >>>>>>> - RO trusts AS-RS (and then handles its own policies within AS-RO) >>>>>>> - end-user trusts AS-RO (through its client) >>>>>>> >>>>>>> Could probably work but that's a fairly different model compared to >>>>>>> OAuth2 (and of today's GNAP), with different frontiers between the = AS and >>>>>>> the RS. >>>>>>> >>>>>>> Please do not hesitate to correct me if I'm wrong. >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper < >>>>>>> agropper@healthurl.com> wrote: >>>>>>> >>>>>>>> I believe there are alternatives to having two kinds of ASs. The >>>>>>>> problem may be a side-effect of deciding to switch away form treat= ing the >>>>>>>> RO as different from the RQ. That leads to downstream privacy issu= es. Our >>>>>>>> desire for architectural simplicity is admirable but that may have= been a >>>>>>>> step too far. >>>>>>>> >>>>>>>> There may also be solutions based on different types of tokens, as >>>>>>>> in different capabilities (tokens signed by the RS) vs. tokens sig= ned by >>>>>>>> the AS. I=E2=80=99m not sure about that but Alan might have more t= o say. >>>>>>>> >>>>>>>> Adrian >>>>>>>> >>>>>>>> On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>> >>>>>>>>> Thanks. The general problem statement is clear. >>>>>>>>> >>>>>>>>> The proposed solution a bit less (to me). I understood that from >>>>>>>>> point 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obvi= ous >>>>>>>>> reason to have two types of ASs". Do you see an alternative ? >>>>>>>>> >>>>>>>>> Regarding the last item, I don't think that naming RQ by end-user >>>>>>>>> created the problem. It might just highlight the asymmetry, which >>>>>>>>> fundamentally exists. >>>>>>>>> >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper < >>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>> >>>>>>>>>> Recap: >>>>>>>>>> 1 - Justin (I think) introduced the idea of an AS on the RS trus= t >>>>>>>>>> boundary side. >>>>>>>>>> 2 - I said the RO should not have to share policies with the RS. >>>>>>>>>> 3 - Alan invented the concept of AS-RO and AS-RS to separate two >>>>>>>>>> kinds of PDPs. >>>>>>>>>> >>>>>>>>>> The thing is that step 2 is not symmetrical. The RO has a >>>>>>>>>> legitimate privacy interest in keeping their policies private an= d >>>>>>>>>> minimizing the leakage of information about requests that are po= sed against >>>>>>>>>> those policies. >>>>>>>>>> >>>>>>>>>> The RS, on the other hand, should be publishing its policies >>>>>>>>>> (e.g. what it=E2=80=99s selling or what jurisdiction it=E2=80=99= s in or what tokens or >>>>>>>>>> scopes it supports). The RS has no obvious privacy interest in G= NAP. It=E2=80=99s >>>>>>>>>> just an enforcer. >>>>>>>>>> >>>>>>>>>> There is one other privacy interest to consider around the RS an= d >>>>>>>>>> that is the requesting party (the end-user that is not the RO :-= ) might >>>>>>>>>> prefer to share attributes with the RS instead of the RO or some= thing >>>>>>>>>> controlled by the RO. This case could be an =E2=80=9Cextension= =E2=80=9D to GNAP and might >>>>>>>>>> result in a split AS as a solution. This problem was introduced = when the >>>>>>>>>> editors decided to replace RQ with end-user. Obviously, the RO e= nd-user has >>>>>>>>>> no privacy interests relative to itself. >>>>>>>>>> >>>>>>>>>> Adrian >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault < >>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> I was referring to "By my definition, this model has two ASs >>>>>>>>>>> since both are processing requests into tokens". If there's no = reason to >>>>>>>>>>> have 2 types of ASs, that's fine then. >>>>>>>>>>> But I'm a bit lost in where we stand with the idea. >>>>>>>>>>> >>>>>>>>>>> Could you recap? >>>>>>>>>>> >>>>>>>>>>> Fabien >>>>>>>>>>> >>>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper < >>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>> >>>>>>>>>>>> There=E2=80=99s no obvious reason to have two types of ASs. An= y AS that >>>>>>>>>>>> is executing the policies of the RS can look to GNAP like the = RS itself. >>>>>>>>>>>> Why would GNAP expose that interface to anyone? >>>>>>>>>>>> >>>>>>>>>>>> Adrian >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault < >>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Note : I'm not sure that's a good idea, but having 2 types of >>>>>>>>>>>>> ASs is not that easy to grasp. >>>>>>>>>>>>> >>>>>>>>>>>>> Fabien >>>>>>>>>>>>> >>>>>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault < >>>>>>>>>>>>> fabien.imbault@gmail.com> a =C3=A9crit : >>>>>>>>>>>>> >>>>>>>>>>>>>> The purpose of either handling policies locally or delegatin= g >>>>>>>>>>>>>> them to the RO agent. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper < >>>>>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>>>>> >>>>>>>>>>>>>>> What purpose would be served by GNAP splitting the AS into >>>>>>>>>>>>>>> two components? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault < >>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Isn't the AS-RO a component of the AS? Same idea as the >>>>>>>>>>>>>>>> interact component, it functionnally belongs to the AS rol= e but could be >>>>>>>>>>>>>>>> deployed either as a monolith or as a separate component? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper < >>>>>>>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yes, but I would say it=E2=80=99s not the RO that wants t= he access >>>>>>>>>>>>>>>>> token. It=E2=80=99s the RO that wants the client making t= he request to get an >>>>>>>>>>>>>>>>> access token. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 11:22 PM Alan Karp < >>>>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Adrian Gropper wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> In this design, the AS is the AS-RS and the agent is th= e >>>>>>>>>>>>>>>>>>> AS-RO. By my definition, this model has two ASs since b= oth are processing >>>>>>>>>>>>>>>>>>> requests into tokens. The problem with this is complexi= ty and privacy. The >>>>>>>>>>>>>>>>>>> RO may not want to share the request information with t= he AS-RS. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> More precisely, RO has no choice but to present the >>>>>>>>>>>>>>>>>> required information to AS-RS if RO wants an access toke= n. However, RO >>>>>>>>>>>>>>>>>> does not want AS-RS to know the policy by which RO deleg= ates tokens. >>>>>>>>>>>>>>>>>> That's why RO uses AS-RO for those delegations. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper < >>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thank you for creating the issue. My definition of AS i= s >>>>>>>>>>>>>>>>>>> independent of AS-RO or AS-RS. >>>>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issu= es/223#issuecomment-806280421 >>>>>>>>>>>>>>>>>>> I also agree with Alan's definition based on delegation= . An AS-RS would be >>>>>>>>>>>>>>>>>>> a delegate of the RS. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Based on that, I see it as obvious that the policy has >>>>>>>>>>>>>>>>>>> to be accessible (defined locally?) in order for it to = be run as the code >>>>>>>>>>>>>>>>>>> that turns a request into an access token. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The only other possibility is that the request is >>>>>>>>>>>>>>>>>>> packaged by the AS and sent elsewhere (an agent) for ev= aluation against >>>>>>>>>>>>>>>>>>> policy and a proto-token returned. In that case the AS = is acting as a proxy >>>>>>>>>>>>>>>>>>> and the PDP is elsewhere. I can imagine that an AS-RS w= ould behave this way >>>>>>>>>>>>>>>>>>> so that the proto-token could be turned into an access = token by the AS-RS. >>>>>>>>>>>>>>>>>>> Isn't this what Justin is proposing? In this design, th= e AS is the AS-RS >>>>>>>>>>>>>>>>>>> and the agent is the AS-RO. By my definition, this mode= l has two ASs since >>>>>>>>>>>>>>>>>>> both are processing requests into tokens. The problem w= ith this is >>>>>>>>>>>>>>>>>>> complexity and privacy. The RO may not want to share th= e request >>>>>>>>>>>>>>>>>>> information with the AS-RS. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault < >>>>>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Isn't that what the AS is supposed to be, only with th= e >>>>>>>>>>>>>>>>>>>> caveat that the policy is defined locally? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp < >>>>>>>>>>>>>>>>>>>> alanhkarp@gmail.com> a =C3=A9crit : >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> AS-RO is an AS that RO trusts to delegate RO's access >>>>>>>>>>>>>>>>>>>>> tokens according to RO's policies. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault < >>>>>>>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Hi Alan and Adrian, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I've created issue AS-RO policy delegation ( >>>>>>>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/i= ssues/223) >>>>>>>>>>>>>>>>>>>>>> to capture your input. >>>>>>>>>>>>>>>>>>>>>> A first question that arises: can we give a >>>>>>>>>>>>>>>>>>>>>> definition to AS-RO? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp < >>>>>>>>>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Fabien Imbault wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Yes, but in that flow, the token relationship >>>>>>>>>>>>>>>>>>>>>>>> between AS-RS and AS-RO is only secure if the toke= ns issued by AS-RS are >>>>>>>>>>>>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Attenuated delegation is a requirement, but that >>>>>>>>>>>>>>>>>>>>>>> doesn't have to be done cryptographically. Token e= xchange works just >>>>>>>>>>>>>>>>>>>>>>> fine. SPKI and zcap-ld are examples of the crypto = approach, and we used >>>>>>>>>>>>>>>>>>>>>>> token exchange in the system for HP. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault < >>>>>>>>>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Yes, but in that flow, the token relationship >>>>>>>>>>>>>>>>>>>>>>>> between AS-RS and AS-RO is only secure if the toke= ns issued by AS-RS are >>>>>>>>>>>>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp < >>>>>>>>>>>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Justin Richer wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> But with all that in mind, I think the key here >>>>>>>>>>>>>>>>>>>>>>>>>> is going to be looking at what the inputs to the= AS are, and how those can >>>>>>>>>>>>>>>>>>>>>>>>>> be defined in an interoperable way for AS=E2=80= =99s that can accept them. I think >>>>>>>>>>>>>>>>>>>>>>>>>> there=E2=80=99s a lot of room for innovation and= flexibility here that doesn=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>>>> break the trust model or core use cases. If I ha= ve an AS-RS set that won=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine input= s, then I can decide not to >>>>>>>>>>>>>>>>>>>>>>>>>> use that one. But this is a very different quest= ion than saying the RS >>>>>>>>>>>>>>>>>>>>>>>>>> itself needs to accept my own AS =E2=80=94 and w= e can=E2=80=99t keep conflating these two >>>>>>>>>>>>>>>>>>>>>>>>>> models. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I agree. The point of having an AS-RO is to >>>>>>>>>>>>>>>>>>>>>>>>> allow RO to specify a policy for which of RO's ac= cess tokens should be >>>>>>>>>>>>>>>>>>>>>>>>> delegated under what conditions. AS-RS should no= t need to understand those >>>>>>>>>>>>>>>>>>>>>>>>> policies. The flow would be >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> - RO contacts AS-RS and gets one or more >>>>>>>>>>>>>>>>>>>>>>>>> access tokens. >>>>>>>>>>>>>>>>>>>>>>>>> - RO delegates one or more of those tokens, >>>>>>>>>>>>>>>>>>>>>>>>> potentially sub-scoped, to AS-RO. >>>>>>>>>>>>>>>>>>>>>>>>> - A different user contacts AS-RO to get a >>>>>>>>>>>>>>>>>>>>>>>>> potentially sub-scoped access token from AS-RO= . >>>>>>>>>>>>>>>>>>>>>>>>> - That user presents the access token >>>>>>>>>>>>>>>>>>>>>>>>> delegated by AS-RO when invoking the resource. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> AS-RS only needs to verify that the delegation >>>>>>>>>>>>>>>>>>>>>>>>> chain is legitimate, e.g., no increase in scope, = and that it grants >>>>>>>>>>>>>>>>>>>>>>>>> permission for the request being made. AS-RS doe= s not need to understand >>>>>>>>>>>>>>>>>>>>>>>>> the policy behind granting the delegation by AS-R= O. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer < >>>>>>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I think this shows the problem with the >>>>>>>>>>>>>>>>>>>>>>>>>> terminology as it=E2=80=99s been applied in this= conversation, which I=E2=80=99ve tried to >>>>>>>>>>>>>>>>>>>>>>>>>> shine light on before. What you and others are c= alling the =E2=80=9CRS=E2=80=9D is really >>>>>>>>>>>>>>>>>>>>>>>>>> the =E2=80=9CAS and RS working together=E2=80=9D= =E2=80=94 everything to the right of the line. >>>>>>>>>>>>>>>>>>>>>>>>>> When Denis had brought up =E2=80=9Celiminating t= he AS=E2=80=9D in another thread, what he=E2=80=99d >>>>>>>>>>>>>>>>>>>>>>>>>> really done is labeled everything to the right o= f the line as the =E2=80=9CRS=E2=80=9D. Of >>>>>>>>>>>>>>>>>>>>>>>>>> course, the irony here is that everything to the= right of the line used all >>>>>>>>>>>>>>>>>>>>>>>>>> be called the =E2=80=9CAS=E2=80=9D or simply =E2= =80=9Cserver=E2=80=9D in the OAuth 1 days. As you say >>>>>>>>>>>>>>>>>>>>>>>>>> below, I don=E2=80=99t want the client to have v= isibility on what happens on that >>>>>>>>>>>>>>>>>>>>>>>>>> side. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Note well: The Google+ logo labeled =E2=80=9CIdP= =E2=80=9D in the >>>>>>>>>>>>>>>>>>>>>>>>>> diagram is not the AS, as far as GNAP is concern= ed. It does not issue an >>>>>>>>>>>>>>>>>>>>>>>>>> access token that the RS will accept. The elemen= ts to the left of the line >>>>>>>>>>>>>>>>>>>>>>>>>> could be a lot of things, but they are NOT the A= S =E2=80=94 by definition. The >>>>>>>>>>>>>>>>>>>>>>>>>> client lives over on the left, but so do any ext= ernal inputs to the AS. >>>>>>>>>>>>>>>>>>>>>>>>>> These could be policy inputs on behalf of the RO= , they could be >>>>>>>>>>>>>>>>>>>>>>>>>> presentation artifacts, they could be federated = logins, they could be the >>>>>>>>>>>>>>>>>>>>>>>>>> output of policy decisions. How the AS comes to = trust those things is up to >>>>>>>>>>>>>>>>>>>>>>>>>> the AS=E2=80=99s implementation. It=E2=80=99s so= mething we can talk about, but ultimately >>>>>>>>>>>>>>>>>>>>>>>>>> GNAP won=E2=80=99t be in any position to dictate= because in practice some AS=E2=80=99s are >>>>>>>>>>>>>>>>>>>>>>>>>> simply going to internalize all policies and we = will never successfully >>>>>>>>>>>>>>>>>>>>>>>>>> force those open. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> But with all that in mind, I think the key here >>>>>>>>>>>>>>>>>>>>>>>>>> is going to be looking at what the inputs to the= AS are, and how those can >>>>>>>>>>>>>>>>>>>>>>>>>> be defined in an interoperable way for AS=E2=80= =99s that can accept them. I think >>>>>>>>>>>>>>>>>>>>>>>>>> there=E2=80=99s a lot of room for innovation and= flexibility here that doesn=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>>>> break the trust model or core use cases. If I ha= ve an AS-RS set that won=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine input= s, then I can decide not to >>>>>>>>>>>>>>>>>>>>>>>>>> use that one. But this is a very different quest= ion than saying the RS >>>>>>>>>>>>>>>>>>>>>>>>>> itself needs to accept my own AS =E2=80=94 and w= e can=E2=80=99t keep conflating these two >>>>>>>>>>>>>>>>>>>>>>>>>> models. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> So to me, GNAP can support a Zero Trust >>>>>>>>>>>>>>>>>>>>>>>>>> Architecture by LEVERAGING the AS, not by subsum= ing or eliminating it. It >>>>>>>>>>>>>>>>>>>>>>>>>> is in fact the AS, not the client and not the RS= , that will request and >>>>>>>>>>>>>>>>>>>>>>>>>> consume the results of a privacy-preserving zero= -trust policy query thing. >>>>>>>>>>>>>>>>>>>>>>>>>> Anything that happens downstream from that is of= little concern to the >>>>>>>>>>>>>>>>>>>>>>>>>> zero-trust components because, as you point out,= it=E2=80=99s on the =E2=80=9Cother side=E2=80=9D >>>>>>>>>>>>>>>>>>>>>>>>>> of the line. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I think we got this basic component model pretty >>>>>>>>>>>>>>>>>>>>>>>>>> right in OAuth: the AS and RS and client working= together. Where OAuth >>>>>>>>>>>>>>>>>>>>>>>>>> misses the mark is the assumption that the user = has to log in to the AS >>>>>>>>>>>>>>>>>>>>>>>>>> through a webpage and interact directly, thereby= proving they=E2=80=99re the RO. >>>>>>>>>>>>>>>>>>>>>>>>>> It=E2=80=99s this latter space where I think we = can both push innovation and also >>>>>>>>>>>>>>>>>>>>>>>>>> address the important and compelling use cases l= ike the ones you=E2=80=99re >>>>>>>>>>>>>>>>>>>>>>>>>> bringing. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper < >>>>>>>>>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I'm sorry, Justin. As a Resource Owner, I look a= t >>>>>>>>>>>>>>>>>>>>>>>>>> the RS trust boundary (the dotted line in the di= agram) as being the RS. I >>>>>>>>>>>>>>>>>>>>>>>>>> don't expect any visibility into what's going on= on the right. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> My problem with the framing you propose is that >>>>>>>>>>>>>>>>>>>>>>>>>> requests are going to the RS (or the AS-RS) and = I don't want to share my >>>>>>>>>>>>>>>>>>>>>>>>>> policies with the AS-RS. I want to keep the RS a= nd AS-RS as ignorant as >>>>>>>>>>>>>>>>>>>>>>>>>> possible. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer < >>>>>>>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> What you=E2=80=99re discussing below, in terms = of >>>>>>>>>>>>>>>>>>>>>>>>>>> logging in to a site, is not approaching the RS= . You are in fact >>>>>>>>>>>>>>>>>>>>>>>>>>> approaching the client, and identifying both th= e AS and RS to the client. >>>>>>>>>>>>>>>>>>>>>>>>>>> The client is a client *of your identity* in >>>>>>>>>>>>>>>>>>>>>>>>>>> this model, and the RS is part of the identity = provider. It=E2=80=99s really >>>>>>>>>>>>>>>>>>>>>>>>>>> important that we don=E2=80=99t conflate the RS= and client in this way as it leads >>>>>>>>>>>>>>>>>>>>>>>>>>> to a lot of confusion downstream and a lot of b= roken trust boundaries. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> With that model in mind, approaching the =E2=80= =9CRS" >>>>>>>>>>>>>>>>>>>>>>>>>>> and providing it your identity is really just a= case of the =E2=80=9Cfederated >>>>>>>>>>>>>>>>>>>>>>>>>>> login to AS=E2=80=9D pattern that we discussed = on the WG call. The user here >>>>>>>>>>>>>>>>>>>>>>>>>>> approaches an RS, which has its own AS. To shar= e things from this RS, the >>>>>>>>>>>>>>>>>>>>>>>>>>> RO has to authenticate to the RS=E2=80=99s AS. = This particular AS allows the RO to >>>>>>>>>>>>>>>>>>>>>>>>>>> do so using an external identity =E2=80=94 in w= hich case, the AS is now a =E2=80=9Cclient=E2=80=9D >>>>>>>>>>>>>>>>>>>>>>>>>>> of a separate, disconnected (but layered) deleg= ation. The ultimate client >>>>>>>>>>>>>>>>>>>>>>>>>>> that eventually calls the RS down the way may o= r may not know about these >>>>>>>>>>>>>>>>>>>>>>>>>>> layers. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> This same AS, which is closely tied to the RS >>>>>>>>>>>>>>>>>>>>>>>>>>> and trusted by the RS, might also take in FIDO = credentials, or DIDs, or any >>>>>>>>>>>>>>>>>>>>>>>>>>> number of other proof mechanisms. The output of= this is an access token the >>>>>>>>>>>>>>>>>>>>>>>>>>> RS trusts, but the input is up to the AS. The R= S is not what you=E2=80=99re logging >>>>>>>>>>>>>>>>>>>>>>>>>>> in to. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper < >>>>>>>>>>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> I too am in favor of avoiding consolidation and >>>>>>>>>>>>>>>>>>>>>>>>>>> correlation. Right now, when I approach a servi= ce provider (RS) for the >>>>>>>>>>>>>>>>>>>>>>>>>>> first time, I'm offered the opportunity to iden= tify my persona as: email, >>>>>>>>>>>>>>>>>>>>>>>>>>> sign-in with Google, Facebook, or Apple. I know= there are people who try to >>>>>>>>>>>>>>>>>>>>>>>>>>> create one-off email addresses but that is most= ly a waste of time. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> So, along come FIDO2 and DID wallets to the >>>>>>>>>>>>>>>>>>>>>>>>>>> rescue. Now, in theory, I have a way to start o= ut my RS relationship >>>>>>>>>>>>>>>>>>>>>>>>>>> pseudonymously. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> When I want my resource to be discovered or >>>>>>>>>>>>>>>>>>>>>>>>>>> shared I will post that RS URL including my pse= udonym. If I then want to >>>>>>>>>>>>>>>>>>>>>>>>>>> introduce a mediator in front of my AS or messa= ging service endpoint, I >>>>>>>>>>>>>>>>>>>>>>>>>>> have that option. If I want to keep requests aw= ay from the mediator, I >>>>>>>>>>>>>>>>>>>>>>>>>>> would publish an encryption key along with my p= seudonym. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> - Adrian >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer < >>>>>>>>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk < >>>>>>>>>>>>>>>>>>>>>>>>>>>> kaduk@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, >>>>>>>>>>>>>>>>>>>>>>>>>>>> Adrian Gropper wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> @Alan Karp shared a >>>>>>>>>>>>>>>>>>>>>>>>>>>> talk about the Principle Of Least >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> Authority (POLA) in a recent comment >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-prot= ocol/issues/145#issuecomment-803099693 >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> I recommend it. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> We might expect a protocol with >>>>>>>>>>>>>>>>>>>>>>>>>>>> authorization in the title to use authority >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> as a core principle. I advocate for a GNAP >>>>>>>>>>>>>>>>>>>>>>>>>>>> design that maximizes the power >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> of the RO, to be seen as a human rights >>>>>>>>>>>>>>>>>>>>>>>>>>>> issue when the RO is a human. This >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> causes me to ask how to combine better >>>>>>>>>>>>>>>>>>>>>>>>>>>> security with better human rights in >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> GNAP. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> Who should have the least authority in the >>>>>>>>>>>>>>>>>>>>>>>>>>>> GNAP design? >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> The AS derives authority as a delegate of >>>>>>>>>>>>>>>>>>>>>>>>>>>> the RO. If we ask the RO to >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> partition limited authority across dozens o= f >>>>>>>>>>>>>>>>>>>>>>>>>>>> different ASs by domain and >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> function, then we are not using technology >>>>>>>>>>>>>>>>>>>>>>>>>>>> to empower the individual. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> Probably the opposite, as we introduce >>>>>>>>>>>>>>>>>>>>>>>>>>>> consent fatigue and burden normal >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> people to partition their lives into >>>>>>>>>>>>>>>>>>>>>>>>>>>> non-overlapping domains. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> My experience says we should aim for one AS >>>>>>>>>>>>>>>>>>>>>>>>>>>> per persona because that maps >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> into the way we manage our public and >>>>>>>>>>>>>>>>>>>>>>>>>>>> private identities. POLA would then >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> teach care in keeping ASs and RSs related t= o >>>>>>>>>>>>>>>>>>>>>>>>>>>> work / public separate from >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> ASs and RSs related to private life so that >>>>>>>>>>>>>>>>>>>>>>>>>>>> a policy vulnerability in our >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> delegation to an AS would have the least >>>>>>>>>>>>>>>>>>>>>>>>>>>> likelihood of harm. >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > Thinking about how least authority/least >>>>>>>>>>>>>>>>>>>>>>>>>>>> privilege would apply to GNAP >>>>>>>>>>>>>>>>>>>>>>>>>>>> > seems like a useful exercise. I do want to >>>>>>>>>>>>>>>>>>>>>>>>>>>> point out some potential >>>>>>>>>>>>>>>>>>>>>>>>>>>> > pitfalls with one-AS-per-persona that we can >>>>>>>>>>>>>>>>>>>>>>>>>>>> also be aware of. If >>>>>>>>>>>>>>>>>>>>>>>>>>>> > one-AS-per-persona becomes one-persona-per-A= S >>>>>>>>>>>>>>>>>>>>>>>>>>>> as well, then the AS's >>>>>>>>>>>>>>>>>>>>>>>>>>>> > identity in effect also serves as a persona >>>>>>>>>>>>>>>>>>>>>>>>>>>> identity and there are privacy >>>>>>>>>>>>>>>>>>>>>>>>>>>> > considerations to that. If, on the other >>>>>>>>>>>>>>>>>>>>>>>>>>>> hand, the >>>>>>>>>>>>>>>>>>>>>>>>>>>> > multiple-personas-per-AS (presumably >>>>>>>>>>>>>>>>>>>>>>>>>>>> corresponding to multiple humans) >>>>>>>>>>>>>>>>>>>>>>>>>>>> > route is taken, we should consider whether >>>>>>>>>>>>>>>>>>>>>>>>>>>> that would lead to various >>>>>>>>>>>>>>>>>>>>>>>>>>>> > (e.g., market) forces driving consolidation >>>>>>>>>>>>>>>>>>>>>>>>>>>> to just a handful of >>>>>>>>>>>>>>>>>>>>>>>>>>>> > super-popular AS services. That topic is a >>>>>>>>>>>>>>>>>>>>>>>>>>>> current matter of concern to >>>>>>>>>>>>>>>>>>>>>>>>>>>> > some IETF participants. >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Ben, big +1 to this. This is something that >>>>>>>>>>>>>>>>>>>>>>>>>>>> we discussed ages ago in the UMA working group= , and it=E2=80=99s one of the biggest >>>>>>>>>>>>>>>>>>>>>>>>>>>> problems with the personal AS (and personal da= ta store) model. This kind of >>>>>>>>>>>>>>>>>>>>>>>>>>>> thing makes RS-first trust models really diffi= cult in practice. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> As a strawman, let=E2=80=99s say that I=E2=80= =99ve got software >>>>>>>>>>>>>>>>>>>>>>>>>>>> that wants to access my medical information. I= t calls an RS and requests >>>>>>>>>>>>>>>>>>>>>>>>>>>> access, but it hasn=E2=80=99t been granted any= thing yet. Now I as the RO have set >>>>>>>>>>>>>>>>>>>>>>>>>>>> up the RS so that it talks to my personal AS, = that only I use. In addition >>>>>>>>>>>>>>>>>>>>>>>>>>>> to the RS having to be able to figure out whic= h medical records are being >>>>>>>>>>>>>>>>>>>>>>>>>>>> requested from the context of the unauthentica= ted request (which means it >>>>>>>>>>>>>>>>>>>>>>>>>>>> needs identifiers in the URL or something simi= lar for the RS to be able to >>>>>>>>>>>>>>>>>>>>>>>>>>>> tell, assuming that it protects data for more = than one person). So this >>>>>>>>>>>>>>>>>>>>>>>>>>>> client software doesn=E2=80=99t know who I am = and doesn=E2=80=99t know my medical record >>>>>>>>>>>>>>>>>>>>>>>>>>>> information, makes a completely unauthorized r= equest to the RS, and the RS >>>>>>>>>>>>>>>>>>>>>>>>>>>> says =E2=80=9CGo to Justin=E2=80=99s personal = AS to get a token=E2=80=9D. The client can now make a >>>>>>>>>>>>>>>>>>>>>>>>>>>> direct correlation between the data that=E2=80= =99s being protected at the RS and >>>>>>>>>>>>>>>>>>>>>>>>>>>> the person running the AS that protects it. Im= portantly, this client makes >>>>>>>>>>>>>>>>>>>>>>>>>>>> this call with no prior relationship to the RS= and no really auditable way >>>>>>>>>>>>>>>>>>>>>>>>>>>> to track it down after the fact. This is a des= ign feature in the good case, >>>>>>>>>>>>>>>>>>>>>>>>>>>> and terrifying in the bad case. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> If the RS instead says =E2=80=9Cwelcome to Med= icine >>>>>>>>>>>>>>>>>>>>>>>>>>>> Doctor RS, please talk to the Medicine Doctor = AS to get access=E2=80=9D, we haven=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>>>>>> exposed anything at all. And from the perspect= ive of both the patient and >>>>>>>>>>>>>>>>>>>>>>>>>>>> the RS, this is more privacy-preserving, and i= t=E2=80=99s really the least >>>>>>>>>>>>>>>>>>>>>>>>>>>> surprising option. Once the client gets to the= AS, it can start a >>>>>>>>>>>>>>>>>>>>>>>>>>>> negotiation of figuring out who the RO is for = the information being >>>>>>>>>>>>>>>>>>>>>>>>>>>> accessed. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On top of this, the usability expectations of >>>>>>>>>>>>>>>>>>>>>>>>>>>> people managing their own AS, or set of AS=E2= =80=99s for multiple personas to keep >>>>>>>>>>>>>>>>>>>>>>>>>>>> things separate, is a huge burden. Even in the= tech community, I know >>>>>>>>>>>>>>>>>>>>>>>>>>>> people who can=E2=80=99t reliably manage more = than one email address for different >>>>>>>>>>>>>>>>>>>>>>>>>>>> purposes. I wouldn=E2=80=99t expect my partner= to do that =E2=80=94 they have trouble >>>>>>>>>>>>>>>>>>>>>>>>>>>> enough balancing all the logins and sessions r= equired for different kids >>>>>>>>>>>>>>>>>>>>>>>>>>>> remote schooling, I couldn=E2=80=99t imagine t= hem having to understand all the >>>>>>>>>>>>>>>>>>>>>>>>>>>> requirements for managing multiple authorizati= on servers and associated >>>>>>>>>>>>>>>>>>>>>>>>>>>> policies. I also don=E2=80=99t expect any pers= on to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve been on >>>>>>>>>>>>>>>>>>>>>>>>>>>> the internet for decades and I can barely keep= tabs on my GPG keys, and >>>>>>>>>>>>>>>>>>>>>>>>>>>> only use them when I am forced to. This is exa= ctly the kind of =E2=80=9Cmarket >>>>>>>>>>>>>>>>>>>>>>>>>>>> pressure=E2=80=9D that I think Ben mentions ab= ove, people will just want to >>>>>>>>>>>>>>>>>>>>>>>>>>>> outsource that to someone else, and the realit= y will be a few popular >>>>>>>>>>>>>>>>>>>>>>>>>>>> providers. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> In which case, we could end up doing a ton of >>>>>>>>>>>>>>>>>>>>>>>>>>>> work to allow an RS choice only to end up with= a world where the RS ends up >>>>>>>>>>>>>>>>>>>>>>>>>>>> making a limited choice anyway. We see how tha= t plays out with OpenID >>>>>>>>>>>>>>>>>>>>>>>>>>>> Connect =E2=80=94 RP=E2=80=99s could allow arb= itrary IdPs but they choose Google because it >>>>>>>>>>>>>>>>>>>>>>>>>>>> works and that=E2=80=99s where the users are. = (And that=E2=80=99s not to say anything of >>>>>>>>>>>>>>>>>>>>>>>>>>>> the proprietary OIDC-like protocols, but that= =E2=80=99s another discussion). >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> For further reading on these topics, I >>>>>>>>>>>>>>>>>>>>>>>>>>>> recommend both =E2=80=9CWhy Johnny Can=E2=80= =99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> So what does this have to do with GNAP? I thin= k >>>>>>>>>>>>>>>>>>>>>>>>>>>> we can be clear-eyed on what kinds of expectat= ions we have for the >>>>>>>>>>>>>>>>>>>>>>>>>>>> participants. If we expect users (RO=E2=80=99s= ) to have to set up the AS-RS >>>>>>>>>>>>>>>>>>>>>>>>>>>> relationship, or expect them to carry their AS= , or manage their personal >>>>>>>>>>>>>>>>>>>>>>>>>>>> keys =E2=80=94 I think we=E2=80=99ve lost the = battle for relevance. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> >>> >> > --000000000000eedc9e05be7226b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Good. I agree with the externalizing framing you use. To = me, they are a pair. They represent the separation of concerns I=E2=80=99m = focused on. The AS has policies, gets requests from clients, and returns ac= cess tokens.=C2=A0

    So wh= at are we disagreeing about?

    - Adrian

    On Fri, Mar 26, 2021 at 10:38 AM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    Yes, the RO is the party/entity w= hich holds the rights for delegation, and they perform that delegation to a= piece of software (the client) through the AS. The RS is what they=E2=80= =99re delegating the access of, for API-access use cases (again, user/subje= ct information is similar but different).=C2=A0

    Th= ere isn=E2=80=99t a delegation between the RS and AS, then. You can perhaps= view them as externalizing functions that they might otherwise hold close,= but not delegating in the same way the client gets delegated to. You can f= rame it one of two ways:

    =C2=A0- The RS externaliz= es its security, policy, authorization, and delegation functions to the AS = and looks for access tokens from the AS as proof of that happening (this is= the most in line with the model you=E2=80=99ve been presenting)
    = =C2=A0- The AS externalizes its data-API functions to into the RS and produ= ces access tokens for the RS to consume/validate (this is actually the mode= l that OAuth 2 started with, in extracting the RS as a separate entity as o= pposed to OAuth 1)

    They tell different views of th= e same reality. In OAuth, it=E2=80=99s assumed that the RO interacts with t= he AS directly to perform the delegation to the client. In GNAP, we=E2=80= =99ve got an opportunity to expand that, which has been (to me) one of the = biggest outcomes of this discussion.

    =C2=A0=E2=80=94 J= ustin

    On Mar 26, 2021, at 10:04 = AM, Adrian Gropper <agropper@healthurl.com> wrote:

    Justin,=C2=A0

    Big YES= to =E2=80=9C The conceptual framework of an AS that takes in lots of diffe= rent information and spits out access tokens is exactly the abstraction lay= er that is necessary for making these use cases interoperable.=E2=80=9D and= probably everything else you just said.=C2=A0

    <= /div>
    I seem to not understand the delegation design betwe= en RS and AS. In my view, that delegation always goes through the RO, altho= ugh the RO may be forced to choose from a list provided by the RS.

    In my view, GNAP, can acknowledg= e this and design to be agnostic to whether the AS is specified by he RO or= picked from a list of 1 or more choices provided by the RS.

    - Adrian

    On Fri, Mar 26, 2021 at = 9:30 AM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    I disagree, I believe that what I have laid out is exactly separating th= e concerns into working components.=C2=A0

    Like OAu= th before it, GNAP is a protocol negotiate access for a client instance to = an RS, using an AS as the facilitator of that delegated negotiation. (Unlik= e OAuth, it=E2=80=99s importantly also for negotiating user information to = the client directly from the AS with no RS involved, but that=E2=80=99s an = aside for the purposes of our conversation here).

    = If a particular GNAP RS also allows other kinds of processes to enable acce= ss to it, that is completely fine, but outside of GNAP. If an RS allows a u= sername/password HTTP Basic auth in addition to accepting access tokens, it= can do so, but GNAP doesn=E2=80=99t have anything to say about the Basic a= uth use, or even its relation to any access tokens or RO=E2=80=99s or anyth= ing else. If an RS accepts structured access tokens signed by trusted keys = that don=E2=80=99t come from an AS through a negotiated request =E2=80=94 a= gain, that=E2=80=99s fine, but GNAP is silent about the RS doing that. If t= he RS acts as =E2=80=9Cits own AS=E2=80=9D then it=E2=80=99s really just an= RS and an AS living in the same box. Again, that=E2=80=99s fine, and super= common with OAuth today.=C2=A0

    GNAP is solving th= e problem of connecting the client to the RS through means of an AS. Other = solutions are possible and many of them can be deployed right alongside, bu= t that=E2=80=99s not the corner of the world that GNAP is solving. GNAP sho= uld be concerned about how these other technologies can be used alongside i= t. I think there=E2=80=99s a lot of room for the things that you=E2=80=99re= talking about, and more importantly for solving the use cases that you=E2= =80=99re bringing. But GNAP should be more than a single-point solution, an= d so we need to balance these concerns. The conceptual framework of an AS t= hat takes in lots of different information and spits out access tokens is e= xactly the abstraction layer that is necessary for making these use cases i= nteroperable.

    =C2=A0=E2=80=94 Justin

    On Mar 26, 2021, at 8:30 AM, Adrian Gropper <<= a href=3D"mailto:agropper@healthurl.com" target=3D"_blank">agropper@healthu= rl.com> wrote:

    @Justin, there=E2=80= =99s no separation of concerns here. No partition between processor and con= troller. No data minimization. And, I see no obvious reason to make this th= e core of GNAP.=C2=A0

    Th= e one thing we can probably all agree on is that there=E2=80=99s only one R= S and one RO.=C2=A0

    The = core of GNAP, in my=C2=A0opinion, can be built and explained around this si= mple design. The RS is a processor. The RO is a controller. The RS bears on= ly security responsibility. The RS bears no privacy responsibility. The RO = delegates this to the RS but this is not authorization as the A in GNAP.

    The RO retains all rights = to delegate within the scope of things that the RS is willing to support us= ing various token formats and endpoint options. Some of these options may d= o all sorts of things for all sorts of clients and user-agents =C2=A0but th= ese are options.=C2=A0

    F= or example, if a request comes to the RS that is not in the form of an acce= ss token, then it either gets sent to the RO or their agent, or it gets log= ged and dumped. One such option, common in healthcare, is =E2=80=9CBreak th= e Glass=E2=80=9D where the RS is acting as an authorization server because = the user-agent is making a request instead of presenting an access token. G= NAP can offer this as an option but it is not our core.

    Adrian



    On Fri, Mar 26, 2021 at 7:15 AM Justin Richer <<= a href=3D"mailto:jricher@mit.edu" target=3D"_blank">jricher@mit.edu>= wrote:
    I have a big problem with this line:

    >=C2=A0the = RS and AS-RS only see access tokens. The requests (from RO') that resul= ted in an access token are none of their business.

    In the trust model we=E2=80=99ve been discussing, the requests that resu= lt in access tokens are solely the business of AS-RS, since AS-RS is= the only entity that=E2=80=99s allowed, and trusted by the RS, to create a= ccess tokens for the RS. That is its entire job, the entire reason it exist= s in the system. By definition the party generating tokens for use at the R= S is the AS for that RS, I don=E2=80=99t care how you deploy it. If RO want= s to give access to someone else (who isn=E2=80=99t an =E2=80=9CRO" an= ymore, they=E2=80=99re another end-user), then that end user=E2=80=99s clie= nt software will need to talk to AS-RS to get its own access token.
    Now here=E2=80=99s the trick: when the end user=E2=80=99s clien= t instance talks to AS-RS, that does NOT mean that AS-RS needs to know all = the details and policy reasons that it should give an access token to that = client instance. It doesn=E2=80=99t even need to know the existence of anot= her end user. It doesn=E2=80=99t need identity, it doesn=E2=80=99t need pol= icy. Sure, it COULD handle all of that internally, and many will, but the p= rotocol doesn=E2=80=99t demand it.=C2=A0

    This mean= s that the first client instance, the one that gets the access token, can a= lso be given something alongside the access token that it can then hand to = another piece of software (or to a person to hand eo their piece of softwar= e). This artifact is not an access token. This artifact could be something = structured that the client understands, and can make derivatives of, and pr= esent back to the AS-RS for getting new access tokens. There could be multi= ple different flavors of this kind of artifact for different kinds of envir= onments and groups. But what they all have in common is that they can poten= tially be used to request more access tokens within some context at the AS-= RS.

    =C2=A0=E2=80=94 Justin



    On Mar 25, 2021, at 5:50 PM,= Adrian Gropper <agropper@healthurl.com> wrote:

    <= div dir=3D"ltr">
    My issue is with Alan's:
    "7. Another use= r agent (RO') can contact any holder of the access token or the service= 's policy agent (AS-RS) to get a delegated access token."

    I would prefer "7A.=C2=A0Another user agent (RO') can contact any holder of the = access token." by default so that the AS-RS does not see the requests.= In other words, the RS and AS-RS only see access tokens. The requests (fro= m RO') that resulted in an access token are none of their business.

    <= /font>
    The reality is t= hat RO' can discover a resource RS and can share whatever information w= ith RS-AS they want and the RO may not even know about it unless the RS dec= ides to let them know somehow. This seems to be a drawback of the capabilit= ies approach.=C2=A0

    In terms of privacy and control, I, as the RO, want a contract=C2=A0= with the RS that says that I or my agent (AS-RO) must sign an access token.= This is a fundamental audit requirement. Without it, a rogue RS and AS-RS = can do all sorts of things and the RO would never know. I understand that a= rogue RS might not support an honest contemporaneous log of access tokens = presented so there's a trust issue here that I seems unavoidable unless= I specify in my RO-RS contract that they use a separate contemporaneous=C2= =A0log such as AS-RO for every access token presented and risk being sued i= f they process an access token without also updating the separate log.

    - Adrian


    On Thu, Mar 25, 2021 at 1:22 PM Alan Karp &= lt;alanhkarp@gmail= .com> wrote:
    Justin Richer <jricher@mit.edu> wrote:
    Hi Alan,

    In all of my discussi= on, and in the spec itself, the RO is the :entity: in charge of approving r= ights. They=E2=80=99re probably a person. It might be software that makes a= policy decision in some way, or a corporate entity, or something like that= . But it=E2=80=99s not assumed to be a computational agent in the terms of = the protocol itself. Would that recast what you=E2=80=99re saying below?


    On Thu, Mar 25, 2021 at 9:53 AM Ju= stin Richer <jriche= r@mit.edu> wrote:
    Hi Alan,

    =
    In all of my discussion, and in the spec itself, the RO is the := entity: in charge of approving rights. They=E2=80=99re probably a person. I= t might be software that makes a policy decision in some way, or a corporat= e entity, or something like that. But it=E2=80=99s not assumed to be a comp= utational agent in the terms of the protocol itself. Would that recast what= you=E2=80=99re saying below?

    =C2=A0=E2=80=94 Just= in

    On Mar 25, 2021, at 12:36 PM,= Alan Karp <ala= nhkarp@gmail.com> wrote:

    There seems = to be some confusion about how AS-RO comes into the picture, probably becau= se of the "AS" part.=C2=A0 I'm going to try to clear up that = confusion by more carefully explaining what I mean.

    I'm as= suming that RO is a computational agent representing the person who is the = resource owner, something called the "user agent" in operating sy= stems lingo.=C2=A0 I'm also assuming that it's possible to do deleg= ation, either locally or by token exchange with AS-RS.=C2=A0 All delegation= s are potentially sub-scoped, but you may also want to delegate with full s= cope to have a separately revocable access token.

    = =C2=A0 Here's an example of how things work in a capability oriented sy= stem.
    1. Someone, the service owner, creates a service.<= /li>
    2. The service owner contracts with an policy agent (AS-RS) to create = and manage access tokens for that service (RS).
    3. A person wishing to= create a resource at RS uses their user agent (RO) to contact the service = owner's policy agent (AS-RS) and gets back an access token for that res= ource.
    4. That user agent (RO) can=C2=A0
      1. use that access t= oken to invoke the resource, or
      2. delegate an access token to a clien= t of the user agent's (RO) choice, or
      3. contract with a policy ag= ent (AS-RO) to manage those delegations on behalf of the user agent (RO), o= r
      4. specify a policy with the service's policy agent (AS-RS).
    5. A client can contact any holder of the access token (the user age= nt (RO) or its policy agent (AS-RO)) or the service's policy agent (AS-= RS) to get a delegated access token.
    6. That client can delegate that = token to another client.
    7. Another user agent (RO') can contact a= ny holder of the access token or the service's policy agent (AS-RS) to = get a delegated access token.
    8. The other user agent (RO') can=C2= =A0
      1. use that access token to invoke the resource, or
      2. de= legate it to a client of its choice, or
      3. contract with a policy agen= t (AS-RO') of its choosing to manage those delegations on its behalf, = or
      4. specify a policy with the service's policy agent (AS-RS).
    9. and so on
    When any of these comput= ational agents, user agents (ROs) or clients acting on their behalf, invoke= s the resource, AS-RS verifies that the access token is a valid delegation,= i.e., proper sub-scoping, hasn't been revoked, and that it authorizes = the request being made before telling the service (RS) to honor the request= .=C2=A0 At no point does the service's policy agent (AS-RS) know which = computational agent did any particular delegation.=C2=A0 (Token exchange ca= n be done as anonymously as possible.)=C2=A0 In particular, the policy agen= ts (AS-RO) need not be the same, or even compatible with, the service's= policy agent (AS-RS).=C2=A0 GNAP specifies the protocol between requesters= , invokers, delegators (for token exchange) of tokens and AS-RS.=C2=A0 That= protocol need not be used between user agents (RO), clients, or other poli= cy agents (AS-RO), but it is likely to be.

    =C2=A0-= ------------
    Alan Karp


    On Thu, Mar 25, 2021 at 5:45 AM Justin Richer <jricher@mit.edu> wrote:
    The way I=E2=80=99m thinking about Adrian=E2=80=99s use cas= e is that what we=E2=80=99re calling the =E2=80=9CAS-RO=E2=80=9D isn=E2=80= =99t an =E2=80=9CAS=E2=80=9D in the traditional OAuth/GNAP sense, at least = not exactly. This is the agent that the RO can use to set policies and mana= ge consent on their behalf, and I=E2=80=99ve been arguing that it fits bett= er into this vaguely-defined =E2=80=9Cinteraction component=E2=80=9D aspect= of the current AS definition, and it=E2=80=99s not currently separated fro= m the AS definition. The =E2=80=9CAS-RS=E2=80=9D maps to what we=E2=80=99d = call the =E2=80=9CAS=E2=80=9D in OAuth/GNAP traditionally, it=E2=80=99s wha= t the RS trusts to issue tokens. In traditional OAuth the AS-RO and AS-RS a= re always the same thing, from a functional protocol perspective. An import= ant point here is that from a client=E2=80=99s perspective, they=E2=80=99re= only talking to the AS-RS since that=E2=80=99s where the client gets its t= okens, because at the end of the day the client just wants to call the API = at the RS and doesn=E2=80=99t care how that happens (from a protocol standp= oint).=C2=A0

    Note well: Even thought I don=E2=80=99t bel= ieve that =E2=80=9CAS-RO=E2=80=9D is an authorization server at all, I=E2= =80=99m going to keep using that term below for consistency with previous d= iscussion.

    So we have these fundamental relationsh= ips around getting the client to access the RS:

    1.= RS trusts=C2=A0AS-RS=C2=A0to issue tokens that RS will accept, validate, a= nd process for requests from client
    2. Client trusts=C2=A0AS-RS= =C2=A0to issue tokens that client can use at RS
    3. RO trusts RS t= o protect RO=E2=80=99s api through delegated access

    On top of that, we=E2=80=99ve got some additional aspects that we=E2=80= =99re discussing:

    4. RO trusts=C2=A0AS-RO=C2=A0to = manage RO=E2=80=99s policies at runtime
    5.=C2=A0AS-RS=C2=A0trusts= =C2=A0AS-RO=C2=A0to assert RO=E2=80=99s policies for access to RS
    6. Client trusts whatever=C2=A0AS-RS=C2=A0sends client to deal with, inclu= ding possibly RO-AS at runtime, because of (2)

    Wha= t I have been saying is that 4/5/6 are optional details of how RS-AS runs t= hings, and I think this also maps with Adrian=E2=80=99s view of choice, sin= ce if my RS=E2=80=99s AS-RS doesn=E2=80=99t allow me to plug in my own AS-R= O then I would be motivated to pick a different RS who=E2=80=99s AS-RS lets= me do just that. The same way I=E2=80=99d pick a different RS if their sur= rounding services didn=E2=80=99t accept my preferred federation login and I= didn=E2=80=99t want to make another account. Of course, market forces bein= g as they are, I might not have much of an actionable choice in RS, but GNA= P can=E2=80=99t change that.=C2=A0

    What we can do = is make it possible for AS-RS to talk to AS-RO, both in philosophy of the p= rotocol design and in concrete hooks to support (6) above.=C2=A0
    =
    Separately, we can approach the issue of making 1/2 above mo= re dynamic. This was UMA2=E2=80=99s =E2=80=9Cfederated authorization=E2=80= =9D approach, and is behind a lot of the =E2=80=9Cbring your own AS=E2=80= =9D models out there. The problem with these is that we know from many year= s of experience that most RS=E2=80=99s aren=E2=80=99t interested in doing a= nything of the sort.

    So with GNAP we can instead a= llow 4/5/6 to vary in a predictable and consistent way, letting the RS keep= control over 1/2, thereby enabling choice in (3). We don=E2=80=99t have to= be the ones who define the all of the details of every permutation of (5) = to enable this, though. Some of this is going to be configuration out of ba= nd, some of it=E2=80=99s going to be communication at runtime. This is wher= e VC=E2=80=99s, ZCAPs, CHAPI, DIDComm, FIDO, and a whole swath of other tec= h can come in and help out. I don=E2=80=99t think we need to put all the de= tails for using these into core, nor do I think we=E2=80=99ll pull of The G= reat And Ultimate Abstraction for using these and other approaches. But we = can at least start talking about =E2=80=9CAS-RS=E2=80=9D in such a way that= it no longer assumes it=E2=80=99s always the same party dealing with the R= O directly.

    =C2=A0=E2=80=94 Justin

    On Mar 25, 2021, at 6:40 AM, Fabien Imbault <<= a href=3D"mailto:fabien.imbault@gmail.com" target=3D"_blank">fabien.imbault= @gmail.com> wrote:

    To reframe it clos= er to GNAP:
    - AS =3D AS-RO, that's where you find the RO policies. = The AS issues access tokens to the client.
    - the RO policies coul= d be a) defined locally or b) in relationship with the RS

    There have been several ideas related to the AS-RS relationship b:<= br>
    b1) the RS issues capabilities (which can be further attenuat= ed by the RO)
    b2) Adrian also discussed a DID based solution
    b3) there was also an alternative ACL proposal from Denis (+ prefligh= t)

    Fabien


    On Thu, Mar 25, 2021= at 9:44 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Ok so I get you correctly:=C2=A0
    - what matte= rs is the RQ (could be a RO or a end-user or both : we don't really car= e at a high-level, they're all treated as entities that make a request)=
    - the policy is able to handle those different cases, based on i= ts own internal delegation protocol
    - currently that requires AS-= RS and AS-RO, but maybe it can be simplified

    To an= swer to Denis, here's what I understood:
    - RO trusts AS-RS (a= nd then handles its own policies within AS-RO)
    - end-user tru= sts AS-RO (through its client)

    Could probably work= but that's a fairly different model compared to OAuth2 (and of today&#= 39;s GNAP), with different frontiers between the AS and the RS.=C2=A0
    =

    Please do not hesitate to correct me if I'm wrong.<= /div>

    Fabien=C2=A0

    On Thu, Mar 25, 2021 at 9:26 AM = Adrian Gropper <agropper@healthurl.com> wrote:
    I believe there are alternatives to having two kinds of ASs. The= problem may be a side-effect of deciding to switch away form treating the = RO as different from the RQ. That leads to downstream privacy issues. Our d= esire for architectural simplicity is admirable but that may have been a st= ep too far.

    There may al= so be solutions based on different types of tokens, as in different capabil= ities (tokens signed by the RS) vs. tokens signed by the AS. I=E2=80=99m no= t sure about that but Alan might have more to say.
    <= br>
    Adrian

    =
    On Thu, Mar 25, 2021 at 4:15 AM Fabie= n Imbault <fabien.imbault@gmail.com> wrote:
    Thanks. The general problem statement is clear.

    The=C2=A0proposed solution a bit less (to me). I understood that from poin= t 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obvious reason to have two types of ASs".=C2=A0<= /span>Do you see an alternative ?

    Regarding = the last item, I don't think that naming RQ by end-user created the pro= blem. It might just highlight the asymmetry,=C2=A0which fundamentally exist= s.=C2=A0

    Fabien


    On Thu, Mar 25, 2021 at 8:48 AM A= drian Gropper <agropper@healthurl.com> wrote:
    Recap:
    1 - Justin (I think) introduced the= idea of an AS on the RS trust boundary side.
    2 - I = said the RO should not have to share policies with the RS.
    3 - Alan invented the concept of AS-RO and AS-RS to separate two kin= ds of PDPs.=C2=A0

    The th= ing is that step 2 is not symmetrical. The RO has a legitimate privacy inte= rest in keeping their policies private and minimizing the leakage of inform= ation about requests that are posed against those policies.=C2=A0

    The RS, on the other hand, should= be publishing its policies (e.g. what it=E2=80=99s selling or what jurisdi= ction it=E2=80=99s in or what tokens or scopes it supports). The RS has no = obvious privacy interest in GNAP. It=E2=80=99s just an enforcer.

    There is one other privacy interes= t to consider around the RS and that is the requesting party (the end-user = that is not the RO :-) might prefer to share attributes with the RS instead= of the RO or something controlled by the RO. This case could be an =E2=80= =9Cextension=E2=80=9D to GNAP and might result in a split AS as a solution.= This problem was introduced when the editors decided to replace RQ with en= d-user. Obviously, the RO end-user has no privacy interests relative to its= elf.

    Adrian




    On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault <fabien.imbault@gmail.com> wro= te:
    I was referring to &qu= ot;By my definition, this model has = two ASs since both are processing requests into tokens". If there'= s no reason to have 2 types of ASs, that's fine then.=C2=A0
    But I'm a bit lost in where we stand with the idea.=C2=A0

    Could you recap?=C2=A0

    Fabien=C2=A0

    Le jeu. 25 mars 2= 021 =C3=A0 08:16, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    There=E2=80=99s no obvious reason= to have two types of ASs. Any AS that is executing the policies of the RS = can look to GNAP like the RS itself. Why would GNAP expose that interface t= o anyone?=C2=A0

    Adrian

    On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault <fabien.imbault@= gmail.com> wrote:
    Note= : I'm not sure that's a good idea, but having 2 types of ASs is no= t that easy to grasp.

    Fabien=C2=A0

    Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien= Imbault <fabien.imbault@gmail.com> a =C3=A9crit=C2=A0:
    =
    The purpose of either handling pol= icies locally or delegating them to the RO agent.=C2=A0

    Le jeu. 25 mars 2021= =C3=A0 08:04, Adrian Gropper <agropper@healthurl.com= > a =C3=A9crit=C2=A0:
    What= purpose would be served by GNAP splitting the AS into two components?

    Adrian=C2=A0

    On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Isn't the AS-RO a component of the AS? Sa= me idea as the interact component, it functionnally belongs to the AS role = but could be deployed either as a monolith or as a separate component?

    Fabien

    Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    Yes, but I would say it=E2=80=99s not the RO tha= t wants the access token. It=E2=80=99s the RO that wants the client making = the request to get an access token.=C2=A0

    =
    Adrian

    On Wed, Mar 24, 2021 at 11:22 PM Alan Karp &l= t;alanhkarp@gmail.com> wrote:
    <= /div>
    Adrian Gropper <= agropper@healthurl.com> wrote:

    In this design, the AS is the AS-RS a= nd the agent is the AS-RO. By my definition, this model has two ASs since b= oth are processing requests into tokens. The problem with this is complexit= y and privacy. The RO may not want to share the request information with th= e AS-RS.

    More precisely, RO has no choice but to present the required informat= ion to AS-RS if RO wants an access token.=C2=A0 However, RO does not want A= S-RS to know the policy by which RO delegates tokens.=C2=A0 That's why = RO uses AS-RO for those delegations.

    ------------= --
    Alan Karp


    On Wed, Mar 24, 2021= at 7:41 PM Adrian Gropper <agroppe= r@healthurl.com> wrote:
    <= div dir=3D"ltr">Thank you for creating the issue. My definition of AS is in= dependent of AS-RO or AS-RS.=C2=A0https://github.com/ietf-= wg-gnap/gnap-core-protocol/issues/223#issuecomment-806280421 I also agr= ee with Alan's definition based on delegation. An AS-RS would be a dele= gate of the RS.=C2=A0

    Based on that, I= see it as obvious=C2=A0that the policy has to be accessible (defined local= ly?) in order for it to be run as the code that turns a request into an acc= ess token.=C2=A0

    The only other possibility is tha= t the request is packaged by the AS and sent elsewhere (an agent) for evalu= ation against policy and a proto-token returned. In that case the AS is act= ing as a proxy and the PDP is elsewhere. I can imagine that an AS-RS would = behave this way so that the proto-token could be turned into an access toke= n by the AS-RS. Isn't this what Justin is proposing? In this design, th= e AS is the AS-RS and the agent is the AS-RO. By my definition, this model = has two ASs since both are processing requests into tokens. The problem wit= h this is complexity and privacy. The RO may not want to share the request = information with the AS-RS.

    Adrian

    =
    On Wed, Ma= r 24, 2021 at 5:21 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Isn't that what the AS is supposed to be, only with = the caveat that the policy is defined locally?=C2=A0

    <= /div>
    Fabien=C2=A0


    Le mer. 24 mars 2021 =C3=A0 20:17, A= lan Karp <alanhkarp@gmail.com> = a =C3=A9crit=C2=A0:
    AS-RO is an AS that RO trusts to delegate RO's access tokens accor= ding to RO's policies.=C2=A0=C2=A0

    --------------
    Alan Karp


    On Wed, Mar 24, 2021 at 9= :36 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan and Adrian,

    I've created issue AS= -RO policy delegation (https://github.com/ietf-wg-gnap/gnap-core-proto= col/issues/223) to capture your input.=C2=A0
    A first question= that arises: can we give a definition to AS-RO?

    T= hanks
    Fabien

    On Tue, Mar 23, 2021 at 4:15 PM Alan Karp <= ;alanhkarp@gmail.com> w= rote:
    Fabien Imba= ult <fabien.imbault@gm= ail.com> wrote:
    Hi Alan,= =C2=A0

    Yes, but in that flow, the token relationship bet= ween AS-RS and AS-RO is only secure if the tokens issued by AS-RS are crypt= ographically attenuable in the first place.=C2=A0
    <= div>=C2=A0
    Attenuated delegation is a requiremen= t, but that doesn't have to be done cryptographically.=C2=A0 Token exch= ange works just fine.=C2=A0 SPKI and zcap-ld are examples of the crypto app= roach, and we used token exchange in the system for HP.

    --------------
    Alan Karp


    On Tue, Mar 23, 202= 1 at 4:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    =
    Hi Alan,=C2=A0

    Yes, but in that flow, t= he token relationship between AS-RS and AS-RO is only secure if the tokens = issued by AS-RS are cryptographically attenuable in the first place.=C2=A0<= /div>

    Fabien

    <= div dir=3D"ltr" class=3D"gmail_attr">On Mon, Mar 22, 2021 at 9:26 PM Alan K= arp <alanhkarp@gmail.com> wrote:

    But with all that in mind, I think the key here = is going to be looking at what the inputs to the AS are, and how those can = be defined in an interoperable way for AS=E2=80=99s that can accept them. I= think there=E2=80=99s a lot of room for innovation and flexibility here th= at doesn=E2=80=99t break the trust model or core use cases. If I have an AS= -RS set that won=E2=80=99t accept my favorite flavor of policy engine input= s, then I can decide not to use that one. But this is a very different ques= tion than saying the RS itself needs to accept my own AS =E2=80=94 and we c= an=E2=80=99t keep conflating these two models.

    I agree.=C2=A0 The point of having an AS-RO is to allow RO = to specify a policy for which of RO's access tokens should be delegated= under what conditions.=C2=A0 AS-RS should not need to understand those pol= icies.=C2=A0 The flow would be
    • RO contacts AS-RS and gets= one or more access tokens.
    • RO delegates one or more of those token= s, potentially sub-scoped, to AS-RO.
    • A different user contacts AS-R= O to get a potentially sub-scoped access token from AS-RO.
    • That use= r presents the access token delegated by AS-RO when invoking the resource.<= /li>
    AS-RS only needs to verify that the delegation cha= in is legitimate, e.g., no increase in scope, and that it grants permission= for the request being made.=C2=A0 AS-RS does not need to understand the po= licy behind granting the delegation by AS-RO.

    ---= -----------
    Alan Karp


    On Mon, Mar 22, 2021 at 11:40 AM Ju= stin Richer <jricher@mit.edu> wrote:
    Adrian,

    I th= ink this shows the problem with the terminology as it=E2=80=99s been applie= d in this conversation, which I=E2=80=99ve tried to shine light on before. = What you and others are calling the =E2=80=9CRS=E2=80=9D is really the =E2= =80=9CAS and RS working together=E2=80=9D =E2=80=94 everything to the right= of the line. When Denis had brought up =E2=80=9Celiminating the AS=E2=80= =9D in another thread, what he=E2=80=99d really done is labeled everything = to the right of the line as the =E2=80=9CRS=E2=80=9D. Of course, the irony = here is that everything to the right of the line used all be called the =E2= =80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. A= s you say below, I don=E2=80=99t want the client to have visibility on what= happens on that side.=C2=A0

    Note well: The Google= + logo labeled =E2=80=9CIdP=E2=80=9D in the diagram is not the AS, as far a= s GNAP is concerned. It does not issue an access token that the RS will acc= ept. The elements to the left of the line could be a lot of things, but the= y are NOT the AS =E2=80=94 by definition. The client lives over on the left= , but so do any external inputs to the AS. These could be policy inputs on = behalf of the RO, they could be presentation artifacts, they could be feder= ated logins, they could be the output of policy decisions. How the AS comes= to trust those things is up to the AS=E2=80=99s implementation. It=E2=80= =99s something we can talk about, but ultimately GNAP won=E2=80=99t be in a= ny position to dictate because in practice some AS=E2=80=99s are simply goi= ng to internalize all policies and we will never successfully force those o= pen.=C2=A0

    But with all that in mind, I think the = key here is going to be looking at what the inputs to the AS are, and how t= hose can be defined in an interoperable way for AS=E2=80=99s that can accep= t them. I think there=E2=80=99s a lot of room for innovation and flexibilit= y here that doesn=E2=80=99t break the trust model or core use cases. If I h= ave an AS-RS set that won=E2=80=99t accept my favorite flavor of policy eng= ine inputs, then I can decide not to use that one. But this is a very diffe= rent question than saying the RS itself needs to accept my own AS =E2=80=94= and we can=E2=80=99t keep conflating these two models.

    So to me, GNAP can support a Zero Trust Architecture by LEVERAGING th= e AS, not by subsuming or eliminating it. It is in fact the AS, not the cli= ent and not the RS, that will request and consume the results of a privacy-= preserving zero-trust policy query thing. Anything that happens downstream = from that is of little concern to the zero-trust components because, as you= point out, it=E2=80=99s on the =E2=80=9Cother side=E2=80=9D of the line.= =C2=A0

    I think we got this basic component model p= retty right in OAuth: the AS and RS and client working together. Where OAut= h misses the mark is the assumption that the user has to log in to the AS t= hrough a webpage and interact directly, thereby proving they=E2=80=99re the= RO. It=E2=80=99s this latter space where I think we can both push innovati= on and also address the important and compelling use cases like the ones yo= u=E2=80=99re bringing.

    =C2=A0=E2=80=94 Justin
    <= div>

    I'm sorry, Justin= . As a Resource Owner, I look at the RS trust boundary (the dotted line in = the diagram) as being the RS. I don't expect any visibility into what&#= 39;s going on on the=C2=A0right.=C2=A0

    My problem with t= he framing you propose is that requests are going to the RS (or the AS-RS) = and I don't want to share my policies with the AS-RS. I want to keep th= e RS and AS-RS as ignorant as possible.

    Adrian

    On Mon, Mar 22, 2021 at 1:48 PM Justin Richer <jricher@mit.edu> wrote:
    =
    Adrian,

    What you=E2=80=99re discussing below, in te= rms of logging in to a site, is not approaching the RS. You are in fact app= roaching the client, and identifying both the AS and RS to the client. The = client is a client of your identity in this model, and the RS is par= t of the identity provider. It=E2=80=99s really important that we don=E2=80= =99t conflate the RS and client in this way as it leads to a lot of confusi= on downstream and a lot of broken trust boundaries.

    With that model in mind, approaching the =E2=80=9CRS" and providing = it your identity is really just a case of the =E2=80=9Cfederated login to A= S=E2=80=9D pattern that we discussed on the WG call. The user here approach= es an RS, which has its own AS. To share things from this RS, the RO has to= authenticate to the RS=E2=80=99s AS. This particular AS allows the RO to d= o so using an external identity =E2=80=94 in which case, the AS is now a = =E2=80=9Cclient=E2=80=9D of a separate, disconnected (but layered) delegati= on. The ultimate client that eventually calls the RS down the way may or ma= y not know about these layers.=C2=A0

    <Pas= tedGraphic-1.png>
    This same AS, which is closely tied t= o the RS and trusted by the RS, might also take in FIDO credentials, or DID= s, or any number of other proof mechanisms. The output of this is an access= token the RS trusts, but the input is up to the AS. The RS is not what you= =E2=80=99re logging in to.

    =C2=A0=E2=80=94 Justin<= br>

    On Mar 22, 2021, at 1:28 PM, Adr= ian Gropper <agropper@he= althurl.com> wrote:

    I too am in favor= of avoiding consolidation and correlation. Right now, when I approach a se= rvice provider (RS) for the first time, I'm offered the opportunity to = identify my persona as: email, sign-in with Google, Facebook, or Apple. I k= now there are people who try to create one-off email addresses but that is = mostly a waste of time.=C2=A0

    So, along come FIDO2 and D= ID wallets to the rescue. Now, in theory, I have a way to start out my RS r= elationship pseudonymously.=C2=A0

    When I want my r= esource to be discovered or shared I will post that RS URL including my pse= udonym. If I then want to introduce a mediator=C2=A0in front of my AS or me= ssaging service=C2=A0endpoint, I have that option. If I want to keep reques= ts away from the mediator, I would publish an encryption key along with my = pseudonym.

    - Adrian


    <= /div>

    On Mon, Mar 22, 2021 at 9:55 AM Justin Richer <jricher@mit.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhk= arp@gmail.com> shared a talk about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-= gnap/gnap-core-protocol/issues/145#issuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --
    TXAuth 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
    --
    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



    --000000000000eedc9e05be7226b8-- From nobody Fri Mar 26 08:35:54 2021 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 823DC3A2160 for ; Fri, 26 Mar 2021 08:35:52 -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 cSRpRx1WeV5s for ; Fri, 26 Mar 2021 08:35:44 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 7515A3A215E for ; Fri, 26 Mar 2021 08:35:44 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id x14so5580905qki.10 for ; Fri, 26 Mar 2021 08:35: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=JHR4SVK49FeLbzQF0lQh0LIBu8zdPYxwd7mQmB9Tbzc=; b=jPUtkw0h6ihg+UPPs5H6Aflh9XsrXoIBZQZt58c1lP3dYPqa8bQxO5JgEtSjyoghNp I3pUGxXBAO90w2pmdbSwcpjHO7jNCRDsmO6/sboDWsgJuqeiL+f/sOT2T5Qt9oXvP6YD 0pQm8G6MZ3kBdQiR/P/DwQuQANVkBJ6yPpxY51lUChX8HT03eIuJexlRicjyaockKYN1 Mgo6ABJH2jyBbUm05dzU0PbVLrtU/KRqiGiIG0W4Y+AdBWCctvlOYiaTAEzpXIUTNJop Mxyh2j1m5RjQO+NZsb8gbKn5RW+vzt085jRlt8CXJwmjNDSAwO16YkafwC/p/EZT1lIV 5aUQ== 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=JHR4SVK49FeLbzQF0lQh0LIBu8zdPYxwd7mQmB9Tbzc=; b=qtuBxudRrfuv6aBM75e6/fvptCcx1eYQ7EwfAj2UpOG5YqTcvbrUPRVytr7a/HxE+h fRQSSLnXzmAA4j9wSJK2xdokTDi+w8shdXBvkUAkMVfYepqzCUaqP7NfqdSX5kO20CpI p2MKt/2rzS4G7V8HyCXXEzbHJd+HgshdB0zG+sdrx3b7j3bYJcntaSMjZmamKPfJvtkR KZnULFf97HYn6KHkHPaaSIHNKZdO1WGYp25uEHzyfyvcdsPUoZGeLf7fBj5cCmVF5YlU L7KWmJDCTvJiW6vVHlvxov95naZzUvhi+pLHcL0ni5299IN8vhCyFxOtxLR45A45t6VP P+9w== X-Gm-Message-State: AOAM5331bivp54tf0wGR7mud96nb5hy2fs5uQFW9daV7ie2DqsT1oy1i PWY/iaBgPqxdOn6MJ6k4PzGU4bf0RleqtR9R71E= X-Google-Smtp-Source: ABdhPJyI2zM+4TY9IPp14lxdQKKngY6ha3suDWfEFNUYauSUSG/5EWtivjSdCrVghzHLGqKr7gpsWA96Cay+tVngFEk= X-Received: by 2002:a05:620a:2206:: with SMTP id m6mr13531377qkh.176.1616772941789; Fri, 26 Mar 2021 08:35:41 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> <5773FA7B-6891-4227-A8CA-2F506909B8CD@mit.edu> <497B7A43-546E-4296-916F-6D177AEBE228@mit.edu> In-Reply-To: From: Alan Karp Date: Fri, 26 Mar 2021 08:35:29 -0700 Message-ID: To: Adrian Gropper Cc: Justin Richer , Benjamin Kaduk , Fabien Imbault , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="000000000000e0bc4605be724872" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2021 15:35:53 -0000 --000000000000e0bc4605be724872 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Adrian Gropper wrote: > Good. I agree with the externalizing framing you use. To me, they are a > pair. They represent the separation of concerns I=E2=80=99m focused on. T= he AS has > policies, gets requests from clients, and returns access tokens. > I thought you also want RO to be able to delegate to a client without AS-RS knowing what policy was used for that delegation. That's the function of AS-RO. The client asks AS-RO for some permissions. AS-RO either does a token exchange with AS-RS or gives the client something to present to AS-RS to get a new access token. Introducing AS-RO also allows RO to express policies that AS-RS may not support, such as break glass. -------------- Alan Karp On Fri, Mar 26, 2021 at 8:26 AM Adrian Gropper wrote: > Good. I agree with the externalizing framing you use. To me, they are a > pair. They represent the separation of concerns I=E2=80=99m focused on. T= he AS has > policies, gets requests from clients, and returns access tokens. > > So what are we disagreeing about? > > - Adrian > > On Fri, Mar 26, 2021 at 10:38 AM Justin Richer wrote: > >> Adrian, >> >> Yes, the RO is the party/entity which holds the rights for delegation, >> and they perform that delegation to a piece of software (the client) >> through the AS. The RS is what they=E2=80=99re delegating the access of,= for >> API-access use cases (again, user/subject information is similar but >> different). >> >> There isn=E2=80=99t a delegation between the RS and AS, then. You can pe= rhaps >> view them as externalizing functions that they might otherwise hold clos= e, >> but not delegating in the same way the client gets delegated to. You can >> frame it one of two ways: >> >> - The RS externalizes its security, policy, authorization, and >> delegation functions to the AS and looks for access tokens from the AS a= s >> proof of that happening (this is the most in line with the model you=E2= =80=99ve >> been presenting) >> - The AS externalizes its data-API functions to into the RS and produce= s >> access tokens for the RS to consume/validate (this is actually the model >> that OAuth 2 started with, in extracting the RS as a separate entity as >> opposed to OAuth 1) >> >> They tell different views of the same reality. In OAuth, it=E2=80=99s as= sumed >> that the RO interacts with the AS directly to perform the delegation to = the >> client. In GNAP, we=E2=80=99ve got an opportunity to expand that, which = has been >> (to me) one of the biggest outcomes of this discussion. >> >> =E2=80=94 Justin >> >> On Mar 26, 2021, at 10:04 AM, Adrian Gropper >> wrote: >> >> Justin, >> >> Big YES to =E2=80=9C The conceptual framework of an AS that takes in lot= s of >> different information and spits out access tokens is exactly the >> abstraction layer that is necessary for making these use cases >> interoperable.=E2=80=9D and probably everything else you just said. >> >> I seem to not understand the delegation design between RS and AS. In my >> view, that delegation always goes through the RO, although the RO may be >> forced to choose from a list provided by the RS. >> >> In my view, GNAP, can acknowledge this and design to be agnostic to >> whether the AS is specified by he RO or picked from a list of 1 or more >> choices provided by the RS. >> >> - Adrian >> >> On Fri, Mar 26, 2021 at 9:30 AM Justin Richer wrote: >> >>> Adrian, >>> >>> I disagree, I believe that what I have laid out is exactly separating >>> the concerns into working components. >>> >>> Like OAuth before it, GNAP is a protocol negotiate access for a client >>> instance to an RS, using an AS as the facilitator of that delegated >>> negotiation. (Unlike OAuth, it=E2=80=99s importantly also for negotiati= ng user >>> information to the client directly from the AS with no RS involved, but >>> that=E2=80=99s an aside for the purposes of our conversation here). >>> >>> If a particular GNAP RS also allows other kinds of processes to enable >>> access to it, that is completely fine, but outside of GNAP. If an RS al= lows >>> a username/password HTTP Basic auth in addition to accepting access tok= ens, >>> it can do so, but GNAP doesn=E2=80=99t have anything to say about the B= asic auth >>> use, or even its relation to any access tokens or RO=E2=80=99s or anyth= ing else. If >>> an RS accepts structured access tokens signed by trusted keys that don= =E2=80=99t >>> come from an AS through a negotiated request =E2=80=94 again, that=E2= =80=99s fine, but GNAP >>> is silent about the RS doing that. If the RS acts as =E2=80=9Cits own A= S=E2=80=9D then it=E2=80=99s >>> really just an RS and an AS living in the same box. Again, that=E2=80= =99s fine, and >>> super common with OAuth today. >>> >>> GNAP is solving the problem of connecting the client to the RS through >>> means of an AS. Other solutions are possible and many of them can be >>> deployed right alongside, but that=E2=80=99s not the corner of the worl= d that GNAP >>> is solving. GNAP should be concerned about how these other technologies= can >>> be used alongside it. I think there=E2=80=99s a lot of room for the thi= ngs that >>> you=E2=80=99re talking about, and more importantly for solving the use = cases that >>> you=E2=80=99re bringing. But GNAP should be more than a single-point so= lution, and >>> so we need to balance these concerns. The conceptual framework of an AS >>> that takes in lots of different information and spits out access tokens= is >>> exactly the abstraction layer that is necessary for making these use ca= ses >>> interoperable. >>> >>> =E2=80=94 Justin >>> >>> On Mar 26, 2021, at 8:30 AM, Adrian Gropper >>> wrote: >>> >>> @Justin, there=E2=80=99s no separation of concerns here. No partition b= etween >>> processor and controller. No data minimization. And, I see no obvious >>> reason to make this the core of GNAP. >>> >>> The one thing we can probably all agree on is that there=E2=80=99s only= one RS >>> and one RO. >>> >>> The core of GNAP, in my opinion, can be built and explained around this >>> simple design. The RS is a processor. The RO is a controller. The RS be= ars >>> only security responsibility. The RS bears no privacy responsibility. T= he >>> RO delegates this to the RS but this is not authorization as the A in G= NAP. >>> >>> The RO retains all rights to delegate within the scope of things that >>> the RS is willing to support using various token formats and endpoint >>> options. Some of these options may do all sorts of things for all sorts= of >>> clients and user-agents but these are options. >>> >>> For example, if a request comes to the RS that is not in the form of an >>> access token, then it either gets sent to the RO or their agent, or it = gets >>> logged and dumped. One such option, common in healthcare, is =E2=80=9CB= reak the >>> Glass=E2=80=9D where the RS is acting as an authorization server becaus= e the >>> user-agent is making a request instead of presenting an access token. G= NAP >>> can offer this as an option but it is not our core. >>> >>> Adrian >>> >>> >>> >>> On Fri, Mar 26, 2021 at 7:15 AM Justin Richer wrote: >>> >>>> I have a big problem with this line: >>>> >>>> > the RS and AS-RS only see access tokens. The requests (from RO') >>>> that resulted in an access token are none of their business. >>>> >>>> In the trust model we=E2=80=99ve been discussing, the requests that re= sult in >>>> access tokens are *solely the business of AS-RS*, since AS-RS is the >>>> only entity that=E2=80=99s allowed, and trusted by the RS, to create a= ccess tokens >>>> for the RS. That is its entire job, the entire reason it exists in the >>>> system. By definition the party generating tokens for use at the RS is= the >>>> AS for that RS, I don=E2=80=99t care how you deploy it. If RO wants to= give access >>>> to someone else (who isn=E2=80=99t an =E2=80=9CRO" anymore, they=E2=80= =99re another end-user), then >>>> that end user=E2=80=99s client software will need to talk to AS-RS to = get its own >>>> access token. >>>> >>>> Now here=E2=80=99s the trick: when the end user=E2=80=99s client insta= nce talks to >>>> AS-RS, that does NOT mean that AS-RS needs to know all the details and >>>> policy reasons that it should give an access token to that client inst= ance. >>>> It doesn=E2=80=99t even need to know the existence of another end user= . It doesn=E2=80=99t >>>> need identity, it doesn=E2=80=99t need policy. Sure, it COULD handle a= ll of that >>>> internally, and many will, but the protocol doesn=E2=80=99t demand it. >>>> >>>> This means that the first client instance, the one that gets the acces= s >>>> token, can also be given something alongside the access token that it = can >>>> then hand to another piece of software (or to a person to hand eo thei= r >>>> piece of software). This artifact is not an access token. This artifac= t >>>> could be something structured that the client understands, and can mak= e >>>> derivatives of, and present back to the AS-RS for getting new access >>>> tokens. There could be multiple different flavors of this kind of arti= fact >>>> for different kinds of environments and groups. But what they all have= in >>>> common is that they can potentially be used to request more access tok= ens >>>> within some context at the AS-RS. >>>> >>>> =E2=80=94 Justin >>>> >>>> >>>> >>>> On Mar 25, 2021, at 5:50 PM, Adrian Gropper >>>> wrote: >>>> >>>> My issue is with Alan's: >>>> >>>> "7. Another user agent (RO') can contact any holder of the access toke= n >>>> or the service's policy agent (AS-RS) to get a delegated access token.= " >>>> >>>> >>>> I would prefer "7A. Another user agent (RO') can contact any holder of >>>> the access token." by default so that the AS-RS does not see the reque= sts. >>>> In other words, the RS and AS-RS only see access tokens. The requests = (from >>>> RO') that resulted in an access token are none of their business. >>>> >>>> The reality is that RO' can discover a resource RS and can share >>>> whatever information with RS-AS they want and the RO may not even know >>>> about it unless the RS decides to let them know somehow. This seems to= be a >>>> drawback of the capabilities approach. >>>> >>>> In terms of privacy and control, I, as the RO, want a contract with th= e >>>> RS that says that I or my agent (AS-RO) must sign an access token. Thi= s is >>>> a fundamental audit requirement. Without it, a rogue RS and AS-RS can = do >>>> all sorts of things and the RO would never know. I understand that a r= ogue >>>> RS might not support an honest contemporaneous log of access tokens >>>> presented so there's a trust issue here that I seems unavoidable unles= s I >>>> specify in my RO-RS contract that they use a separate contemporaneous = log >>>> such as AS-RO for every access token presented and risk being sued if = they >>>> process an access token without also updating the separate log. >>>> >>>> - Adrian >>>> >>>> >>>> On Thu, Mar 25, 2021 at 1:22 PM Alan Karp wrote: >>>> >>>>> Justin Richer wrote: >>>>> >>>>>> Hi Alan, >>>>>> >>>>>> In all of my discussion, and in the spec itself, the RO is the >>>>>> :entity: in charge of approving rights. They=E2=80=99re probably a p= erson. It might >>>>>> be software that makes a policy decision in some way, or a corporate >>>>>> entity, or something like that. But it=E2=80=99s not assumed to be a= computational >>>>>> agent in the terms of the protocol itself. Would that recast what yo= u=E2=80=99re >>>>>> saying below? >>>>>> >>>>> >>>>> Hmmm. I guess not. It's just that the person would be using some UI >>>>> to express their decisions to what I called the user agent. That mod= el >>>>> fits in very nicely with what we did with Polaris, our virus safe com= puting >>>>> environment for Windows XP, >>>>> https://dl.acm.org/doi/10.1145/1151030.1151033. The person would >>>>> click on the icon for a Word file, and an instance of Word would open= with >>>>> only the permission needed to edit that one file. Same thing here. = The >>>>> client could ask for permission to use the resource, or permission co= uld be >>>>> granted implicitly when the user selects a resource associated with a >>>>> specific client. >>>>> >>>>> -------------- >>>>> Alan Karp >>>>> >>>>> >>>>> On Thu, Mar 25, 2021 at 9:53 AM Justin Richer wrote= : >>>>> >>>>>> Hi Alan, >>>>>> >>>>>> In all of my discussion, and in the spec itself, the RO is the >>>>>> :entity: in charge of approving rights. They=E2=80=99re probably a p= erson. It might >>>>>> be software that makes a policy decision in some way, or a corporate >>>>>> entity, or something like that. But it=E2=80=99s not assumed to be a= computational >>>>>> agent in the terms of the protocol itself. Would that recast what yo= u=E2=80=99re >>>>>> saying below? >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> On Mar 25, 2021, at 12:36 PM, Alan Karp wrote: >>>>>> >>>>>> There seems to be some confusion about how AS-RO comes into the >>>>>> picture, probably because of the "AS" part. I'm going to try to cle= ar up >>>>>> that confusion by more carefully explaining what I mean. >>>>>> >>>>>> I'm assuming that RO is a computational agent representing the perso= n >>>>>> who is the resource owner, something called the "user agent" in oper= ating >>>>>> systems lingo. I'm also assuming that it's possible to do delegatio= n, >>>>>> either locally or by token exchange with AS-RS. All delegations are >>>>>> potentially sub-scoped, but you may also want to delegate with full = scope >>>>>> to have a separately revocable access token. >>>>>> >>>>>> Here's an example of how things work in a capability oriented >>>>>> system. >>>>>> >>>>>> 1. Someone, the service owner, creates a service. >>>>>> 2. The service owner contracts with an policy agent (AS-RS) to >>>>>> create and manage access tokens for that service (RS). >>>>>> 3. A person wishing to create a resource at RS uses their user >>>>>> agent (RO) to contact the service owner's policy agent (AS-RS) an= d gets >>>>>> back an access token for that resource. >>>>>> 4. That user agent (RO) can >>>>>> 1. use that access token to invoke the resource, or >>>>>> 2. delegate an access token to a client of the user agent's >>>>>> (RO) choice, or >>>>>> 3. contract with a policy agent (AS-RO) to manage those >>>>>> delegations on behalf of the user agent (RO), or >>>>>> 4. specify a policy with the service's policy agent (AS-RS). >>>>>> 5. A client can contact any holder of the access token (the user >>>>>> agent (RO) or its policy agent (AS-RO)) or the service's policy a= gent >>>>>> (AS-RS) to get a delegated access token. >>>>>> 6. That client can delegate that token to another client. >>>>>> 7. Another user agent (RO') can contact any holder of the access >>>>>> token or the service's policy agent (AS-RS) to get a delegated ac= cess token. >>>>>> 8. The other user agent (RO') can >>>>>> 1. use that access token to invoke the resource, or >>>>>> 2. delegate it to a client of its choice, or >>>>>> 3. contract with a policy agent (AS-RO') of its choosing to >>>>>> manage those delegations on its behalf, or >>>>>> 4. specify a policy with the service's policy agent (AS-RS). >>>>>> 9. and so on >>>>>> >>>>>> When any of these computational agents, user agents (ROs) or clients >>>>>> acting on their behalf, invokes the resource, AS-RS verifies that th= e >>>>>> access token is a valid delegation, i.e., proper sub-scoping, hasn't= been >>>>>> revoked, and that it authorizes the request being made before tellin= g the >>>>>> service (RS) to honor the request. At no point does the service's p= olicy >>>>>> agent (AS-RS) know which computational agent did any particular >>>>>> delegation. (Token exchange can be done as anonymously as possible.= ) In >>>>>> particular, the policy agents (AS-RO) need not be the same, or even >>>>>> compatible with, the service's policy agent (AS-RS). GNAP specifies= the >>>>>> protocol between requesters, invokers, delegators (for token exchang= e) of >>>>>> tokens and AS-RS. That protocol need not be used between user agent= s (RO), >>>>>> clients, or other policy agents (AS-RO), but it is likely to be. >>>>>> >>>>>> ------------- >>>>>> Alan Karp >>>>>> >>>>>> >>>>>> On Thu, Mar 25, 2021 at 5:45 AM Justin Richer >>>>>> wrote: >>>>>> >>>>>>> The way I=E2=80=99m thinking about Adrian=E2=80=99s use case is tha= t what we=E2=80=99re >>>>>>> calling the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an =E2=80=9CAS=E2= =80=9D in the traditional OAuth/GNAP sense, at >>>>>>> least not exactly. This is the agent that the RO can use to set pol= icies >>>>>>> and manage consent on their behalf, and I=E2=80=99ve been arguing t= hat it fits >>>>>>> better into this vaguely-defined =E2=80=9Cinteraction component=E2= =80=9D aspect of the >>>>>>> current AS definition, and it=E2=80=99s not currently separated fro= m the AS >>>>>>> definition. The =E2=80=9CAS-RS=E2=80=9D maps to what we=E2=80=99d c= all the =E2=80=9CAS=E2=80=9D in OAuth/GNAP >>>>>>> traditionally, it=E2=80=99s what the RS trusts to issue tokens. In = traditional >>>>>>> OAuth the AS-RO and AS-RS are always the same thing, from a functio= nal >>>>>>> protocol perspective. An important point here is that from a client= =E2=80=99s >>>>>>> perspective, they=E2=80=99re only talking to the AS-RS since that= =E2=80=99s where the >>>>>>> client gets its tokens, because at the end of the day the client ju= st wants >>>>>>> to call the API at the RS and doesn=E2=80=99t care how that happens= (from a >>>>>>> protocol standpoint). >>>>>>> >>>>>>> Note well: Even thought I don=E2=80=99t believe that =E2=80=9CAS-RO= =E2=80=9D is an >>>>>>> authorization server at all, I=E2=80=99m going to keep using that t= erm below for >>>>>>> consistency with previous discussion. >>>>>>> >>>>>>> So we have these fundamental relationships around getting the clien= t >>>>>>> to access the RS: >>>>>>> >>>>>>> 1. RS trusts AS-RS to issue tokens that RS will accept, validate, >>>>>>> and process for requests from client >>>>>>> 2. Client trusts AS-RS to issue tokens that client can use at RS >>>>>>> 3. RO trusts RS to protect RO=E2=80=99s api through delegated acces= s >>>>>>> >>>>>>> On top of that, we=E2=80=99ve got some additional aspects that we= =E2=80=99re >>>>>>> discussing: >>>>>>> >>>>>>> 4. RO trusts AS-RO to manage RO=E2=80=99s policies at runtime >>>>>>> 5. AS-RS trusts AS-RO to assert RO=E2=80=99s policies for access to= RS >>>>>>> 6. Client trusts whatever AS-RS sends client to deal with, includin= g >>>>>>> possibly RO-AS at runtime, because of (2) >>>>>>> >>>>>>> What I have been saying is that 4/5/6 are optional details of how >>>>>>> RS-AS runs things, and I think this also maps with Adrian=E2=80=99s= view of choice, >>>>>>> since if my RS=E2=80=99s AS-RS doesn=E2=80=99t allow me to plug in = my own AS-RO then I >>>>>>> would be motivated to pick a different RS who=E2=80=99s AS-RS lets = me do just that. >>>>>>> The same way I=E2=80=99d pick a different RS if their surrounding s= ervices didn=E2=80=99t >>>>>>> accept my preferred federation login and I didn=E2=80=99t want to m= ake another >>>>>>> account. Of course, market forces being as they are, I might not ha= ve much >>>>>>> of an actionable choice in RS, but GNAP can=E2=80=99t change that. >>>>>>> >>>>>>> What we can do is make it possible for AS-RS to talk to AS-RO, both >>>>>>> in philosophy of the protocol design and in concrete hooks to suppo= rt (6) >>>>>>> above. >>>>>>> >>>>>>> Separately, we can approach the issue of making 1/2 above more >>>>>>> dynamic. This was UMA2=E2=80=99s =E2=80=9Cfederated authorization= =E2=80=9D approach, and is behind >>>>>>> a lot of the =E2=80=9Cbring your own AS=E2=80=9D models out there. = The problem with these >>>>>>> is that we know from many years of experience that most RS=E2=80=99= s aren=E2=80=99t >>>>>>> interested in doing anything of the sort. >>>>>>> >>>>>>> So with GNAP we can instead allow 4/5/6 to vary in a predictable an= d >>>>>>> consistent way, letting the RS keep control over 1/2, thereby enabl= ing >>>>>>> choice in (3). We don=E2=80=99t have to be the ones who define the = all of the >>>>>>> details of every permutation of (5) to enable this, though. Some of= this is >>>>>>> going to be configuration out of band, some of it=E2=80=99s going t= o be >>>>>>> communication at runtime. This is where VC=E2=80=99s, ZCAPs, CHAPI,= DIDComm, FIDO, >>>>>>> and a whole swath of other tech can come in and help out. I don=E2= =80=99t think we >>>>>>> need to put all the details for using these into core, nor do I thi= nk we=E2=80=99ll >>>>>>> pull of The Great And Ultimate Abstraction for using these and othe= r >>>>>>> approaches. But we can at least start talking about =E2=80=9CAS-RS= =E2=80=9D in such a way >>>>>>> that it no longer assumes it=E2=80=99s always the same party dealin= g with the RO >>>>>>> directly. >>>>>>> >>>>>>> =E2=80=94 Justin >>>>>>> >>>>>>> On Mar 25, 2021, at 6:40 AM, Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>> >>>>>>> To reframe it closer to GNAP: >>>>>>> - AS =3D AS-RO, that's where you find the RO policies. The AS issue= s >>>>>>> access tokens to the client. >>>>>>> - the RO policies could be a) defined locally or b) in relationship >>>>>>> with the RS >>>>>>> >>>>>>> There have been several ideas related to the AS-RS relationship b: >>>>>>> b1) the RS issues capabilities (which can be further attenuated by >>>>>>> the RO) >>>>>>> b2) Adrian also discussed a DID based solution >>>>>>> b3) there was also an alternative ACL proposal from Denis (+ >>>>>>> preflight) >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> >>>>>>> On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>> >>>>>>>> Ok so I get you correctly: >>>>>>>> - what matters is the RQ (could be a RO or a end-user or both : we >>>>>>>> don't really care at a high-level, they're all treated as entities= that >>>>>>>> make a request) >>>>>>>> - the policy is able to handle those different cases, based on its >>>>>>>> own internal delegation protocol >>>>>>>> - currently that requires AS-RS and AS-RO, but maybe it can be >>>>>>>> simplified >>>>>>>> >>>>>>>> To answer to Denis, here's what I understood: >>>>>>>> - RO trusts AS-RS (and then handles its own policies within AS-RO) >>>>>>>> - end-user trusts AS-RO (through its client) >>>>>>>> >>>>>>>> Could probably work but that's a fairly different model compared t= o >>>>>>>> OAuth2 (and of today's GNAP), with different frontiers between the= AS and >>>>>>>> the RS. >>>>>>>> >>>>>>>> Please do not hesitate to correct me if I'm wrong. >>>>>>>> >>>>>>>> Fabien >>>>>>>> >>>>>>>> On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper < >>>>>>>> agropper@healthurl.com> wrote: >>>>>>>> >>>>>>>>> I believe there are alternatives to having two kinds of ASs. The >>>>>>>>> problem may be a side-effect of deciding to switch away form trea= ting the >>>>>>>>> RO as different from the RQ. That leads to downstream privacy iss= ues. Our >>>>>>>>> desire for architectural simplicity is admirable but that may hav= e been a >>>>>>>>> step too far. >>>>>>>>> >>>>>>>>> There may also be solutions based on different types of tokens, a= s >>>>>>>>> in different capabilities (tokens signed by the RS) vs. tokens si= gned by >>>>>>>>> the AS. I=E2=80=99m not sure about that but Alan might have more = to say. >>>>>>>>> >>>>>>>>> Adrian >>>>>>>>> >>>>>>>>> On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault < >>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Thanks. The general problem statement is clear. >>>>>>>>>> >>>>>>>>>> The proposed solution a bit less (to me). I understood that from >>>>>>>>>> point 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obv= ious >>>>>>>>>> reason to have two types of ASs". Do you see an alternative ? >>>>>>>>>> >>>>>>>>>> Regarding the last item, I don't think that naming RQ by end-use= r >>>>>>>>>> created the problem. It might just highlight the asymmetry, whic= h >>>>>>>>>> fundamentally exists. >>>>>>>>>> >>>>>>>>>> Fabien >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper < >>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>> >>>>>>>>>>> Recap: >>>>>>>>>>> 1 - Justin (I think) introduced the idea of an AS on the RS >>>>>>>>>>> trust boundary side. >>>>>>>>>>> 2 - I said the RO should not have to share policies with the RS= . >>>>>>>>>>> 3 - Alan invented the concept of AS-RO and AS-RS to separate tw= o >>>>>>>>>>> kinds of PDPs. >>>>>>>>>>> >>>>>>>>>>> The thing is that step 2 is not symmetrical. The RO has a >>>>>>>>>>> legitimate privacy interest in keeping their policies private a= nd >>>>>>>>>>> minimizing the leakage of information about requests that are p= osed against >>>>>>>>>>> those policies. >>>>>>>>>>> >>>>>>>>>>> The RS, on the other hand, should be publishing its policies >>>>>>>>>>> (e.g. what it=E2=80=99s selling or what jurisdiction it=E2=80= =99s in or what tokens or >>>>>>>>>>> scopes it supports). The RS has no obvious privacy interest in = GNAP. It=E2=80=99s >>>>>>>>>>> just an enforcer. >>>>>>>>>>> >>>>>>>>>>> There is one other privacy interest to consider around the RS >>>>>>>>>>> and that is the requesting party (the end-user that is not the = RO :-) might >>>>>>>>>>> prefer to share attributes with the RS instead of the RO or som= ething >>>>>>>>>>> controlled by the RO. This case could be an =E2=80=9Cextension= =E2=80=9D to GNAP and might >>>>>>>>>>> result in a split AS as a solution. This problem was introduced= when the >>>>>>>>>>> editors decided to replace RQ with end-user. Obviously, the RO = end-user has >>>>>>>>>>> no privacy interests relative to itself. >>>>>>>>>>> >>>>>>>>>>> Adrian >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault < >>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> I was referring to "By my definition, this model has two ASs >>>>>>>>>>>> since both are processing requests into tokens". If there's no= reason to >>>>>>>>>>>> have 2 types of ASs, that's fine then. >>>>>>>>>>>> But I'm a bit lost in where we stand with the idea. >>>>>>>>>>>> >>>>>>>>>>>> Could you recap? >>>>>>>>>>>> >>>>>>>>>>>> Fabien >>>>>>>>>>>> >>>>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper < >>>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>>> >>>>>>>>>>>>> There=E2=80=99s no obvious reason to have two types of ASs. A= ny AS >>>>>>>>>>>>> that is executing the policies of the RS can look to GNAP lik= e the RS >>>>>>>>>>>>> itself. Why would GNAP expose that interface to anyone? >>>>>>>>>>>>> >>>>>>>>>>>>> Adrian >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault < >>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Note : I'm not sure that's a good idea, but having 2 types o= f >>>>>>>>>>>>>> ASs is not that easy to grasp. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>> >>>>>>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault < >>>>>>>>>>>>>> fabien.imbault@gmail.com> a =C3=A9crit : >>>>>>>>>>>>>> >>>>>>>>>>>>>>> The purpose of either handling policies locally or >>>>>>>>>>>>>>> delegating them to the RO agent. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper < >>>>>>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> What purpose would be served by GNAP splitting the AS into >>>>>>>>>>>>>>>> two components? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault < >>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Isn't the AS-RO a component of the AS? Same idea as the >>>>>>>>>>>>>>>>> interact component, it functionnally belongs to the AS ro= le but could be >>>>>>>>>>>>>>>>> deployed either as a monolith or as a separate component? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper < >>>>>>>>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Yes, but I would say it=E2=80=99s not the RO that wants = the >>>>>>>>>>>>>>>>>> access token. It=E2=80=99s the RO that wants the client = making the request to get >>>>>>>>>>>>>>>>>> an access token. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 11:22 PM Alan Karp < >>>>>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Adrian Gropper wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> In this design, the AS is the AS-RS and the agent is >>>>>>>>>>>>>>>>>>>> the AS-RO. By my definition, this model has two ASs si= nce both are >>>>>>>>>>>>>>>>>>>> processing requests into tokens. The problem with this= is complexity and >>>>>>>>>>>>>>>>>>>> privacy. The RO may not want to share the request info= rmation with the >>>>>>>>>>>>>>>>>>>> AS-RS. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> More precisely, RO has no choice but to present the >>>>>>>>>>>>>>>>>>> required information to AS-RS if RO wants an access tok= en. However, RO >>>>>>>>>>>>>>>>>>> does not want AS-RS to know the policy by which RO dele= gates tokens. >>>>>>>>>>>>>>>>>>> That's why RO uses AS-RO for those delegations. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper < >>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thank you for creating the issue. My definition of AS >>>>>>>>>>>>>>>>>>>> is independent of AS-RO or AS-RS. >>>>>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/iss= ues/223#issuecomment-806280421 >>>>>>>>>>>>>>>>>>>> I also agree with Alan's definition based on delegatio= n. An AS-RS would be >>>>>>>>>>>>>>>>>>>> a delegate of the RS. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Based on that, I see it as obvious that the policy has >>>>>>>>>>>>>>>>>>>> to be accessible (defined locally?) in order for it to= be run as the code >>>>>>>>>>>>>>>>>>>> that turns a request into an access token. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> The only other possibility is that the request is >>>>>>>>>>>>>>>>>>>> packaged by the AS and sent elsewhere (an agent) for e= valuation against >>>>>>>>>>>>>>>>>>>> policy and a proto-token returned. In that case the AS= is acting as a proxy >>>>>>>>>>>>>>>>>>>> and the PDP is elsewhere. I can imagine that an AS-RS = would behave this way >>>>>>>>>>>>>>>>>>>> so that the proto-token could be turned into an access= token by the AS-RS. >>>>>>>>>>>>>>>>>>>> Isn't this what Justin is proposing? In this design, t= he AS is the AS-RS >>>>>>>>>>>>>>>>>>>> and the agent is the AS-RO. By my definition, this mod= el has two ASs since >>>>>>>>>>>>>>>>>>>> both are processing requests into tokens. The problem = with this is >>>>>>>>>>>>>>>>>>>> complexity and privacy. The RO may not want to share t= he request >>>>>>>>>>>>>>>>>>>> information with the AS-RS. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault < >>>>>>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Isn't that what the AS is supposed to be, only with >>>>>>>>>>>>>>>>>>>>> the caveat that the policy is defined locally? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp < >>>>>>>>>>>>>>>>>>>>> alanhkarp@gmail.com> a =C3=A9crit : >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> AS-RO is an AS that RO trusts to delegate RO's acces= s >>>>>>>>>>>>>>>>>>>>>> tokens according to RO's policies. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault < >>>>>>>>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Hi Alan and Adrian, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I've created issue AS-RO policy delegation ( >>>>>>>>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/= issues/223) >>>>>>>>>>>>>>>>>>>>>>> to capture your input. >>>>>>>>>>>>>>>>>>>>>>> A first question that arises: can we give a >>>>>>>>>>>>>>>>>>>>>>> definition to AS-RO? >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp < >>>>>>>>>>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Fabien Imbault wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Yes, but in that flow, the token relationship >>>>>>>>>>>>>>>>>>>>>>>>> between AS-RS and AS-RO is only secure if the tok= ens issued by AS-RS are >>>>>>>>>>>>>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Attenuated delegation is a requirement, but that >>>>>>>>>>>>>>>>>>>>>>>> doesn't have to be done cryptographically. Token = exchange works just >>>>>>>>>>>>>>>>>>>>>>>> fine. SPKI and zcap-ld are examples of the crypto= approach, and we used >>>>>>>>>>>>>>>>>>>>>>>> token exchange in the system for HP. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault < >>>>>>>>>>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Yes, but in that flow, the token relationship >>>>>>>>>>>>>>>>>>>>>>>>> between AS-RS and AS-RO is only secure if the tok= ens issued by AS-RS are >>>>>>>>>>>>>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp < >>>>>>>>>>>>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Justin Richer wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> But with all that in mind, I think the key here >>>>>>>>>>>>>>>>>>>>>>>>>>> is going to be looking at what the inputs to th= e AS are, and how those can >>>>>>>>>>>>>>>>>>>>>>>>>>> be defined in an interoperable way for AS=E2=80= =99s that can accept them. I think >>>>>>>>>>>>>>>>>>>>>>>>>>> there=E2=80=99s a lot of room for innovation an= d flexibility here that doesn=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>>>>> break the trust model or core use cases. If I h= ave an AS-RS set that won=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine inpu= ts, then I can decide not to >>>>>>>>>>>>>>>>>>>>>>>>>>> use that one. But this is a very different ques= tion than saying the RS >>>>>>>>>>>>>>>>>>>>>>>>>>> itself needs to accept my own AS =E2=80=94 and = we can=E2=80=99t keep conflating these two >>>>>>>>>>>>>>>>>>>>>>>>>>> models. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> I agree. The point of having an AS-RO is to >>>>>>>>>>>>>>>>>>>>>>>>>> allow RO to specify a policy for which of RO's a= ccess tokens should be >>>>>>>>>>>>>>>>>>>>>>>>>> delegated under what conditions. AS-RS should n= ot need to understand those >>>>>>>>>>>>>>>>>>>>>>>>>> policies. The flow would be >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> - RO contacts AS-RS and gets one or more >>>>>>>>>>>>>>>>>>>>>>>>>> access tokens. >>>>>>>>>>>>>>>>>>>>>>>>>> - RO delegates one or more of those tokens, >>>>>>>>>>>>>>>>>>>>>>>>>> potentially sub-scoped, to AS-RO. >>>>>>>>>>>>>>>>>>>>>>>>>> - A different user contacts AS-RO to get a >>>>>>>>>>>>>>>>>>>>>>>>>> potentially sub-scoped access token from AS-R= O. >>>>>>>>>>>>>>>>>>>>>>>>>> - That user presents the access token >>>>>>>>>>>>>>>>>>>>>>>>>> delegated by AS-RO when invoking the resource= . >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> AS-RS only needs to verify that the delegation >>>>>>>>>>>>>>>>>>>>>>>>>> chain is legitimate, e.g., no increase in scope,= and that it grants >>>>>>>>>>>>>>>>>>>>>>>>>> permission for the request being made. AS-RS do= es not need to understand >>>>>>>>>>>>>>>>>>>>>>>>>> the policy behind granting the delegation by AS-= RO. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer < >>>>>>>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> I think this shows the problem with the >>>>>>>>>>>>>>>>>>>>>>>>>>> terminology as it=E2=80=99s been applied in thi= s conversation, which I=E2=80=99ve tried to >>>>>>>>>>>>>>>>>>>>>>>>>>> shine light on before. What you and others are = calling the =E2=80=9CRS=E2=80=9D is really >>>>>>>>>>>>>>>>>>>>>>>>>>> the =E2=80=9CAS and RS working together=E2=80= =9D =E2=80=94 everything to the right of the line. >>>>>>>>>>>>>>>>>>>>>>>>>>> When Denis had brought up =E2=80=9Celiminating = the AS=E2=80=9D in another thread, what he=E2=80=99d >>>>>>>>>>>>>>>>>>>>>>>>>>> really done is labeled everything to the right = of the line as the =E2=80=9CRS=E2=80=9D. Of >>>>>>>>>>>>>>>>>>>>>>>>>>> course, the irony here is that everything to th= e right of the line used all >>>>>>>>>>>>>>>>>>>>>>>>>>> be called the =E2=80=9CAS=E2=80=9D or simply = =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say >>>>>>>>>>>>>>>>>>>>>>>>>>> below, I don=E2=80=99t want the client to have = visibility on what happens on that >>>>>>>>>>>>>>>>>>>>>>>>>>> side. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Note well: The Google+ logo labeled =E2=80=9CId= P=E2=80=9D in the >>>>>>>>>>>>>>>>>>>>>>>>>>> diagram is not the AS, as far as GNAP is concer= ned. It does not issue an >>>>>>>>>>>>>>>>>>>>>>>>>>> access token that the RS will accept. The eleme= nts to the left of the line >>>>>>>>>>>>>>>>>>>>>>>>>>> could be a lot of things, but they are NOT the = AS =E2=80=94 by definition. The >>>>>>>>>>>>>>>>>>>>>>>>>>> client lives over on the left, but so do any ex= ternal inputs to the AS. >>>>>>>>>>>>>>>>>>>>>>>>>>> These could be policy inputs on behalf of the R= O, they could be >>>>>>>>>>>>>>>>>>>>>>>>>>> presentation artifacts, they could be federated= logins, they could be the >>>>>>>>>>>>>>>>>>>>>>>>>>> output of policy decisions. How the AS comes to= trust those things is up to >>>>>>>>>>>>>>>>>>>>>>>>>>> the AS=E2=80=99s implementation. It=E2=80=99s s= omething we can talk about, but ultimately >>>>>>>>>>>>>>>>>>>>>>>>>>> GNAP won=E2=80=99t be in any position to dictat= e because in practice some AS=E2=80=99s are >>>>>>>>>>>>>>>>>>>>>>>>>>> simply going to internalize all policies and we= will never successfully >>>>>>>>>>>>>>>>>>>>>>>>>>> force those open. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> But with all that in mind, I think the key here >>>>>>>>>>>>>>>>>>>>>>>>>>> is going to be looking at what the inputs to th= e AS are, and how those can >>>>>>>>>>>>>>>>>>>>>>>>>>> be defined in an interoperable way for AS=E2=80= =99s that can accept them. I think >>>>>>>>>>>>>>>>>>>>>>>>>>> there=E2=80=99s a lot of room for innovation an= d flexibility here that doesn=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>>>>> break the trust model or core use cases. If I h= ave an AS-RS set that won=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine inpu= ts, then I can decide not to >>>>>>>>>>>>>>>>>>>>>>>>>>> use that one. But this is a very different ques= tion than saying the RS >>>>>>>>>>>>>>>>>>>>>>>>>>> itself needs to accept my own AS =E2=80=94 and = we can=E2=80=99t keep conflating these two >>>>>>>>>>>>>>>>>>>>>>>>>>> models. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> So to me, GNAP can support a Zero Trust >>>>>>>>>>>>>>>>>>>>>>>>>>> Architecture by LEVERAGING the AS, not by subsu= ming or eliminating it. It >>>>>>>>>>>>>>>>>>>>>>>>>>> is in fact the AS, not the client and not the R= S, that will request and >>>>>>>>>>>>>>>>>>>>>>>>>>> consume the results of a privacy-preserving zer= o-trust policy query thing. >>>>>>>>>>>>>>>>>>>>>>>>>>> Anything that happens downstream from that is o= f little concern to the >>>>>>>>>>>>>>>>>>>>>>>>>>> zero-trust components because, as you point out= , it=E2=80=99s on the =E2=80=9Cother side=E2=80=9D >>>>>>>>>>>>>>>>>>>>>>>>>>> of the line. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> I think we got this basic component model prett= y >>>>>>>>>>>>>>>>>>>>>>>>>>> right in OAuth: the AS and RS and client workin= g together. Where OAuth >>>>>>>>>>>>>>>>>>>>>>>>>>> misses the mark is the assumption that the user= has to log in to the AS >>>>>>>>>>>>>>>>>>>>>>>>>>> through a webpage and interact directly, thereb= y proving they=E2=80=99re the RO. >>>>>>>>>>>>>>>>>>>>>>>>>>> It=E2=80=99s this latter space where I think we= can both push innovation and also >>>>>>>>>>>>>>>>>>>>>>>>>>> address the important and compelling use cases = like the ones you=E2=80=99re >>>>>>>>>>>>>>>>>>>>>>>>>>> bringing. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper < >>>>>>>>>>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> I'm sorry, Justin. As a Resource Owner, I look >>>>>>>>>>>>>>>>>>>>>>>>>>> at the RS trust boundary (the dotted line in th= e diagram) as being the RS. >>>>>>>>>>>>>>>>>>>>>>>>>>> I don't expect any visibility into what's going= on on the right. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> My problem with the framing you propose is that >>>>>>>>>>>>>>>>>>>>>>>>>>> requests are going to the RS (or the AS-RS) and= I don't want to share my >>>>>>>>>>>>>>>>>>>>>>>>>>> policies with the AS-RS. I want to keep the RS = and AS-RS as ignorant as >>>>>>>>>>>>>>>>>>>>>>>>>>> possible. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer < >>>>>>>>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> What you=E2=80=99re discussing below, in terms= of >>>>>>>>>>>>>>>>>>>>>>>>>>>> logging in to a site, is not approaching the R= S. You are in fact >>>>>>>>>>>>>>>>>>>>>>>>>>>> approaching the client, and identifying both t= he AS and RS to the client. >>>>>>>>>>>>>>>>>>>>>>>>>>>> The client is a client *of your identity* in >>>>>>>>>>>>>>>>>>>>>>>>>>>> this model, and the RS is part of the identity= provider. It=E2=80=99s really >>>>>>>>>>>>>>>>>>>>>>>>>>>> important that we don=E2=80=99t conflate the R= S and client in this way as it leads >>>>>>>>>>>>>>>>>>>>>>>>>>>> to a lot of confusion downstream and a lot of = broken trust boundaries. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> With that model in mind, approaching the =E2= =80=9CRS" >>>>>>>>>>>>>>>>>>>>>>>>>>>> and providing it your identity is really just = a case of the =E2=80=9Cfederated >>>>>>>>>>>>>>>>>>>>>>>>>>>> login to AS=E2=80=9D pattern that we discussed= on the WG call. The user here >>>>>>>>>>>>>>>>>>>>>>>>>>>> approaches an RS, which has its own AS. To sha= re things from this RS, the >>>>>>>>>>>>>>>>>>>>>>>>>>>> RO has to authenticate to the RS=E2=80=99s AS.= This particular AS allows the RO to >>>>>>>>>>>>>>>>>>>>>>>>>>>> do so using an external identity =E2=80=94 in = which case, the AS is now a =E2=80=9Cclient=E2=80=9D >>>>>>>>>>>>>>>>>>>>>>>>>>>> of a separate, disconnected (but layered) dele= gation. The ultimate client >>>>>>>>>>>>>>>>>>>>>>>>>>>> that eventually calls the RS down the way may = or may not know about these >>>>>>>>>>>>>>>>>>>>>>>>>>>> layers. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> This same AS, which is closely tied to the RS >>>>>>>>>>>>>>>>>>>>>>>>>>>> and trusted by the RS, might also take in FIDO= credentials, or DIDs, or any >>>>>>>>>>>>>>>>>>>>>>>>>>>> number of other proof mechanisms. The output o= f this is an access token the >>>>>>>>>>>>>>>>>>>>>>>>>>>> RS trusts, but the input is up to the AS. The = RS is not what you=E2=80=99re logging >>>>>>>>>>>>>>>>>>>>>>>>>>>> in to. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper < >>>>>>>>>>>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> I too am in favor of avoiding consolidation an= d >>>>>>>>>>>>>>>>>>>>>>>>>>>> correlation. Right now, when I approach a serv= ice provider (RS) for the >>>>>>>>>>>>>>>>>>>>>>>>>>>> first time, I'm offered the opportunity to ide= ntify my persona as: email, >>>>>>>>>>>>>>>>>>>>>>>>>>>> sign-in with Google, Facebook, or Apple. I kno= w there are people who try to >>>>>>>>>>>>>>>>>>>>>>>>>>>> create one-off email addresses but that is mos= tly a waste of time. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> So, along come FIDO2 and DID wallets to the >>>>>>>>>>>>>>>>>>>>>>>>>>>> rescue. Now, in theory, I have a way to start = out my RS relationship >>>>>>>>>>>>>>>>>>>>>>>>>>>> pseudonymously. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> When I want my resource to be discovered or >>>>>>>>>>>>>>>>>>>>>>>>>>>> shared I will post that RS URL including my ps= eudonym. If I then want to >>>>>>>>>>>>>>>>>>>>>>>>>>>> introduce a mediator in front of my AS or mess= aging service endpoint, I >>>>>>>>>>>>>>>>>>>>>>>>>>>> have that option. If I want to keep requests a= way from the mediator, I >>>>>>>>>>>>>>>>>>>>>>>>>>>> would publish an encryption key along with my = pseudonym. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> - Adrian >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer = < >>>>>>>>>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk < >>>>>>>>>>>>>>>>>>>>>>>>>>>>> kaduk@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Adrian Gropper wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> @Alan Karp shared a >>>>>>>>>>>>>>>>>>>>>>>>>>>>> talk about the Principle Of Least >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> Authority (POLA) in a recent comment >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-pro= tocol/issues/145#issuecomment-803099693 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> I recommend it. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> We might expect a protocol with >>>>>>>>>>>>>>>>>>>>>>>>>>>>> authorization in the title to use authority >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> as a core principle. I advocate for a GNAP >>>>>>>>>>>>>>>>>>>>>>>>>>>>> design that maximizes the power >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> of the RO, to be seen as a human rights >>>>>>>>>>>>>>>>>>>>>>>>>>>>> issue when the RO is a human. This >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> causes me to ask how to combine better >>>>>>>>>>>>>>>>>>>>>>>>>>>>> security with better human rights in >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> GNAP. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> Who should have the least authority in the >>>>>>>>>>>>>>>>>>>>>>>>>>>>> GNAP design? >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> The AS derives authority as a delegate of >>>>>>>>>>>>>>>>>>>>>>>>>>>>> the RO. If we ask the RO to >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> partition limited authority across dozens >>>>>>>>>>>>>>>>>>>>>>>>>>>>> of different ASs by domain and >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> function, then we are not using technology >>>>>>>>>>>>>>>>>>>>>>>>>>>>> to empower the individual. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> Probably the opposite, as we introduce >>>>>>>>>>>>>>>>>>>>>>>>>>>>> consent fatigue and burden normal >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> people to partition their lives into >>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-overlapping domains. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> My experience says we should aim for one A= S >>>>>>>>>>>>>>>>>>>>>>>>>>>>> per persona because that maps >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> into the way we manage our public and >>>>>>>>>>>>>>>>>>>>>>>>>>>>> private identities. POLA would then >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> teach care in keeping ASs and RSs related >>>>>>>>>>>>>>>>>>>>>>>>>>>>> to work / public separate from >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> ASs and RSs related to private life so tha= t >>>>>>>>>>>>>>>>>>>>>>>>>>>>> a policy vulnerability in our >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> delegation to an AS would have the least >>>>>>>>>>>>>>>>>>>>>>>>>>>>> likelihood of harm. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Thinking about how least authority/least >>>>>>>>>>>>>>>>>>>>>>>>>>>>> privilege would apply to GNAP >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > seems like a useful exercise. I do want to >>>>>>>>>>>>>>>>>>>>>>>>>>>>> point out some potential >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > pitfalls with one-AS-per-persona that we ca= n >>>>>>>>>>>>>>>>>>>>>>>>>>>>> also be aware of. If >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > one-AS-per-persona becomes >>>>>>>>>>>>>>>>>>>>>>>>>>>>> one-persona-per-AS as well, then the AS's >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > identity in effect also serves as a persona >>>>>>>>>>>>>>>>>>>>>>>>>>>>> identity and there are privacy >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > considerations to that. If, on the other >>>>>>>>>>>>>>>>>>>>>>>>>>>>> hand, the >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > multiple-personas-per-AS (presumably >>>>>>>>>>>>>>>>>>>>>>>>>>>>> corresponding to multiple humans) >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > route is taken, we should consider whether >>>>>>>>>>>>>>>>>>>>>>>>>>>>> that would lead to various >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > (e.g., market) forces driving consolidation >>>>>>>>>>>>>>>>>>>>>>>>>>>>> to just a handful of >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > super-popular AS services. That topic is a >>>>>>>>>>>>>>>>>>>>>>>>>>>>> current matter of concern to >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > some IETF participants. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Ben, big +1 to this. This is something tha= t >>>>>>>>>>>>>>>>>>>>>>>>>>>>> we discussed ages ago in the UMA working grou= p, and it=E2=80=99s one of the biggest >>>>>>>>>>>>>>>>>>>>>>>>>>>>> problems with the personal AS (and personal d= ata store) model. This kind of >>>>>>>>>>>>>>>>>>>>>>>>>>>>> thing makes RS-first trust models really diff= icult in practice. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> As a strawman, let=E2=80=99s say that I=E2=80= =99ve got >>>>>>>>>>>>>>>>>>>>>>>>>>>>> software that wants to access my medical info= rmation. It calls an RS and >>>>>>>>>>>>>>>>>>>>>>>>>>>>> requests access, but it hasn=E2=80=99t been g= ranted anything yet. Now I as the RO >>>>>>>>>>>>>>>>>>>>>>>>>>>>> have set up the RS so that it talks to my per= sonal AS, that only I use. In >>>>>>>>>>>>>>>>>>>>>>>>>>>>> addition to the RS having to be able to figur= e out which medical records >>>>>>>>>>>>>>>>>>>>>>>>>>>>> are being requested from the context of the u= nauthenticated request (which >>>>>>>>>>>>>>>>>>>>>>>>>>>>> means it needs identifiers in the URL or some= thing similar for the RS to be >>>>>>>>>>>>>>>>>>>>>>>>>>>>> able to tell, assuming that it protects data = for more than one person). So >>>>>>>>>>>>>>>>>>>>>>>>>>>>> this client software doesn=E2=80=99t know who= I am and doesn=E2=80=99t know my medical >>>>>>>>>>>>>>>>>>>>>>>>>>>>> record information, makes a completely unauth= orized request to the RS, and >>>>>>>>>>>>>>>>>>>>>>>>>>>>> the RS says =E2=80=9CGo to Justin=E2=80=99s p= ersonal AS to get a token=E2=80=9D. The client can now >>>>>>>>>>>>>>>>>>>>>>>>>>>>> make a direct correlation between the data th= at=E2=80=99s being protected at the RS >>>>>>>>>>>>>>>>>>>>>>>>>>>>> and the person running the AS that protects i= t. Importantly, this client >>>>>>>>>>>>>>>>>>>>>>>>>>>>> makes this call with no prior relationship to= the RS and no really >>>>>>>>>>>>>>>>>>>>>>>>>>>>> auditable way to track it down after the fact= . This is a design feature in >>>>>>>>>>>>>>>>>>>>>>>>>>>>> the good case, and terrifying in the bad case= . >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> If the RS instead says =E2=80=9Cwelcome to Me= dicine >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Doctor RS, please talk to the Medicine Doctor= AS to get access=E2=80=9D, we haven=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>>>>>>> exposed anything at all. And from the perspec= tive of both the patient and >>>>>>>>>>>>>>>>>>>>>>>>>>>>> the RS, this is more privacy-preserving, and = it=E2=80=99s really the least >>>>>>>>>>>>>>>>>>>>>>>>>>>>> surprising option. Once the client gets to th= e AS, it can start a >>>>>>>>>>>>>>>>>>>>>>>>>>>>> negotiation of figuring out who the RO is for= the information being >>>>>>>>>>>>>>>>>>>>>>>>>>>>> accessed. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On top of this, the usability expectations of >>>>>>>>>>>>>>>>>>>>>>>>>>>>> people managing their own AS, or set of AS=E2= =80=99s for multiple personas to keep >>>>>>>>>>>>>>>>>>>>>>>>>>>>> things separate, is a huge burden. Even in th= e tech community, I know >>>>>>>>>>>>>>>>>>>>>>>>>>>>> people who can=E2=80=99t reliably manage more= than one email address for different >>>>>>>>>>>>>>>>>>>>>>>>>>>>> purposes. I wouldn=E2=80=99t expect my partne= r to do that =E2=80=94 they have trouble >>>>>>>>>>>>>>>>>>>>>>>>>>>>> enough balancing all the logins and sessions = required for different kids >>>>>>>>>>>>>>>>>>>>>>>>>>>>> remote schooling, I couldn=E2=80=99t imagine = them having to understand all the >>>>>>>>>>>>>>>>>>>>>>>>>>>>> requirements for managing multiple authorizat= ion servers and associated >>>>>>>>>>>>>>>>>>>>>>>>>>>>> policies. I also don=E2=80=99t expect any per= son to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve been on >>>>>>>>>>>>>>>>>>>>>>>>>>>>> the internet for decades and I can barely kee= p tabs on my GPG keys, and >>>>>>>>>>>>>>>>>>>>>>>>>>>>> only use them when I am forced to. This is ex= actly the kind of =E2=80=9Cmarket >>>>>>>>>>>>>>>>>>>>>>>>>>>>> pressure=E2=80=9D that I think Ben mentions a= bove, people will just want to >>>>>>>>>>>>>>>>>>>>>>>>>>>>> outsource that to someone else, and the reali= ty will be a few popular >>>>>>>>>>>>>>>>>>>>>>>>>>>>> providers. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> In which case, we could end up doing a ton of >>>>>>>>>>>>>>>>>>>>>>>>>>>>> work to allow an RS choice only to end up wit= h a world where the RS ends up >>>>>>>>>>>>>>>>>>>>>>>>>>>>> making a limited choice anyway. We see how th= at plays out with OpenID >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Connect =E2=80=94 RP=E2=80=99s could allow ar= bitrary IdPs but they choose Google because it >>>>>>>>>>>>>>>>>>>>>>>>>>>>> works and that=E2=80=99s where the users are.= (And that=E2=80=99s not to say anything of >>>>>>>>>>>>>>>>>>>>>>>>>>>>> the proprietary OIDC-like protocols, but that= =E2=80=99s another discussion). >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> For further reading on these topics, I >>>>>>>>>>>>>>>>>>>>>>>>>>>>> recommend both =E2=80=9CWhy Johnny Can=E2=80= =99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> So what does this have to do with GNAP? I >>>>>>>>>>>>>>>>>>>>>>>>>>>>> think we can be clear-eyed on what kinds of e= xpectations we have for the >>>>>>>>>>>>>>>>>>>>>>>>>>>>> participants. If we expect users (RO=E2=80=99= s) to have to set up the AS-RS >>>>>>>>>>>>>>>>>>>>>>>>>>>>> relationship, or expect them to carry their A= S, or manage their personal >>>>>>>>>>>>>>>>>>>>>>>>>>>>> keys =E2=80=94 I think we=E2=80=99ve lost the= battle for relevance. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>> >>>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> >>>> >>> >> --000000000000e0bc4605be724872 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    =C2= =A0Adrian Gropper <agropper@he= althurl.com> wrote:
    Good. I agree with the externalizing framing y= ou use. To me, they are a pair. They represent the separation of concerns I= =E2=80=99m focused on. The AS has policies, gets requests from clients, and= returns access tokens.=C2=A0

    I thought you also want RO to be able to delegate to a client without= AS-RS knowing what policy was used for that delegation.=C2=A0 That's t= he function of AS-RO.=C2=A0 The client asks AS-RO for some permissions.=C2= =A0 AS-RO either does a token exchange with AS-RS or gives the client somet= hing to present to AS-RS to get a new access token.=C2=A0 Introducing AS-RO= also allows RO to express policies that AS-RS may not support, such as bre= ak glass.

    --------------
    Alan Karp


    =
    On Fri, Ma= r 26, 2021 at 8:26 AM Adrian Gropper <agropper@healthurl.com> wrote:
    Good. I agree with the exte= rnalizing framing you use. To me, they are a pair. They represent the separ= ation of concerns I=E2=80=99m focused on. The AS has policies, gets request= s from clients, and returns access tokens.=C2=A0
    So what are we disagreeing about?

    - Adrian

    On Fri, Mar 26, 2021 at 10:= 38 AM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    =
    Yes, the RO is the party/entity which holds the rights for deleg= ation, and they perform that delegation to a piece of software (the client)= through the AS. The RS is what they=E2=80=99re delegating the access of, f= or API-access use cases (again, user/subject information is similar but dif= ferent).=C2=A0

    There isn=E2=80=99t a delegation be= tween the RS and AS, then. You can perhaps view them as externalizing funct= ions that they might otherwise hold close, but not delegating in the same w= ay the client gets delegated to. You can frame it one of two ways:

    =C2=A0- The RS externalizes its security, policy, authoriz= ation, and delegation functions to the AS and looks for access tokens from = the AS as proof of that happening (this is the most in line with the model = you=E2=80=99ve been presenting)
    =C2=A0- The AS externalizes its d= ata-API functions to into the RS and produces access tokens for the RS to c= onsume/validate (this is actually the model that OAuth 2 started with, in e= xtracting the RS as a separate entity as opposed to OAuth 1)

    =
    They tell different views of the same reality. In OAuth, it=E2= =80=99s assumed that the RO interacts with the AS directly to perform the d= elegation to the client. In GNAP, we=E2=80=99ve got an opportunity to expan= d that, which has been (to me) one of the biggest outcomes of this discussi= on.

    =C2=A0=E2=80=94 Justin

    On Mar = 26, 2021, at 10:04 AM, Adrian Gropper <agropper@healthurl.com> wrote:

    <= div>
    Justin,=C2=A0

    Big YES to =E2=80=9C The conceptual framework of an AS that tak= es in lots of different information and spits out access tokens is exactly = the abstraction layer that is necessary for making these use cases interope= rable.=E2=80=9D and probably everything else you just said.=C2=A0

    I seem to not understand the dele= gation design between RS and AS. In my view, that delegation always goes th= rough the RO, although the RO may be forced to choose from a list provided = by the RS.

    In my view, G= NAP, can acknowledge this and design to be agnostic to whether the AS is sp= ecified by he RO or picked from a list of 1 or more choices provided by the= RS.

    - Adrian
    =
    On Fri= , Mar 26, 2021 at 9:30 AM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    I disagree, I believe that what I have laid = out is exactly separating the concerns into working components.=C2=A0
    =

    Like OAuth before it, GNAP is a protocol negotiate acce= ss for a client instance to an RS, using an AS as the facilitator of that d= elegated negotiation. (Unlike OAuth, it=E2=80=99s importantly also for nego= tiating user information to the client directly from the AS with no RS invo= lved, but that=E2=80=99s an aside for the purposes of our conversation here= ).

    If a particular GNAP RS also allows other kinds= of processes to enable access to it, that is completely fine, but outside = of GNAP. If an RS allows a username/password HTTP Basic auth in addition to= accepting access tokens, it can do so, but GNAP doesn=E2=80=99t have anyth= ing to say about the Basic auth use, or even its relation to any access tok= ens or RO=E2=80=99s or anything else. If an RS accepts structured access to= kens signed by trusted keys that don=E2=80=99t come from an AS through a ne= gotiated request =E2=80=94 again, that=E2=80=99s fine, but GNAP is silent a= bout the RS doing that. If the RS acts as =E2=80=9Cits own AS=E2=80=9D then= it=E2=80=99s really just an RS and an AS living in the same box. Again, th= at=E2=80=99s fine, and super common with OAuth today.=C2=A0

    <= /div>
    GNAP is solving the problem of connecting the client to the RS th= rough means of an AS. Other solutions are possible and many of them can be = deployed right alongside, but that=E2=80=99s not the corner of the world th= at GNAP is solving. GNAP should be concerned about how these other technolo= gies can be used alongside it. I think there=E2=80=99s a lot of room for th= e things that you=E2=80=99re talking about, and more importantly for solvin= g the use cases that you=E2=80=99re bringing. But GNAP should be more than = a single-point solution, and so we need to balance these concerns. The conc= eptual framework of an AS that takes in lots of different information and s= pits out access tokens is exactly the abstraction layer that is necessary f= or making these use cases interoperable.

    =C2=A0=E2=80=94 Justin

    <= blockquote type=3D"cite">
    On Mar 26, 2021, at 8:30 AM, Adrian Gropper &= lt;agropper@hea= lthurl.com> wrote:

    @Justin, there=E2= =80=99s no separation of concerns here. No partition between processor and = controller. No data minimization. And, I see no obvious reason to make this= the core of GNAP.=C2=A0

    The one thing we can probably all agree on is that there=E2=80=99s only on= e RS and one RO.=C2=A0

    T= he core of GNAP, in my=C2=A0opinion, can be built and explained around this= simple design. The RS is a processor. The RO is a controller. The RS bears= only security responsibility. The RS bears no privacy responsibility. The = RO delegates this to the RS but this is not authorization as the A in GNAP.=

    The RO retains all righ= ts to delegate within the scope of things that the RS is willing to support= using various token formats and endpoint options. Some of these options ma= y do all sorts of things for all sorts of clients and user-agents =C2=A0but= these are options.=C2=A0

    For example, if a request comes to the RS that is not in the form of an a= ccess token, then it either gets sent to the RO or their agent, or it gets = logged and dumped. One such option, common in healthcare, is =E2=80=9CBreak= the Glass=E2=80=9D where the RS is acting as an authorization server becau= se the user-agent is making a request instead of presenting an access token= . GNAP can offer this as an option but it is not our core.

    Adrian

    =


    On Fri, Mar 26, 2021 at 7:15 AM Justin Richer &l= t;jricher@mit.edu&= gt; wrote:
    I have a big problem with this li= ne:

    >=C2=A0the RS and AS-RS only see access tokens. The requests (from RO'= ;) that resulted in an access token are none of their business.

    In the trust model we=E2=80=99ve been discussing, the reque= sts that result in access tokens are solely the business of AS-RS, s= ince AS-RS is the only entity that=E2=80=99s allowed, and trusted by the RS= , to create access tokens for the RS. That is its entire job, the entire re= ason it exists in the system. By definition the party generating tokens for= use at the RS is the AS for that RS, I don=E2=80=99t care how you deploy i= t. If RO wants to give access to someone else (who isn=E2=80=99t an =E2=80= =9CRO" anymore, they=E2=80=99re another end-user), then that end user= =E2=80=99s client software will need to talk to AS-RS to get its own access= token.

    Now here=E2=80=99s the trick: when the end user= =E2=80=99s client instance talks to AS-RS, that does NOT mean that AS-RS ne= eds to know all the details and policy reasons that it should give an acces= s token to that client instance. It doesn=E2=80=99t even need to know the e= xistence of another end user. It doesn=E2=80=99t need identity, it doesn=E2= =80=99t need policy. Sure, it COULD handle all of that internally, and many= will, but the protocol doesn=E2=80=99t demand it.=C2=A0

    This means that the first client instance, the one that gets the acc= ess token, can also be given something alongside the access token that it c= an then hand to another piece of software (or to a person to hand eo their = piece of software). This artifact is not an access token. This artifact cou= ld be something structured that the client understands, and can make deriva= tives of, and present back to the AS-RS for getting new access tokens. Ther= e could be multiple different flavors of this kind of artifact for differen= t kinds of environments and groups. But what they all have in common is tha= t they can potentially be used to request more access tokens within some co= ntext at the AS-RS.

    =C2=A0=E2=80=94 Justin


    =

    On Mar 25, 2021, at 5:50 PM, Adrian= Gropper <ag= ropper@healthurl.com> wrote:

    My issue is with Alan's:
    "7. Another user agent= (RO') can contact any holder of the access token or the service's = policy agent (AS-RS) to get a delegated access token."

    I would prefer "7A.=C2=A0Another user agent (RO') can contact any holder of the access= token." by default so that the AS-RS does not see the requests. In ot= her words, the RS and AS-RS only see access tokens. The requests (from RO&#= 39;) that resulted in an access token are none of their business.

    =
    The reality is that RO= ' can discover a resource RS and can share whatever information with RS= -AS they want and the RO may not even know about it unless the RS decides t= o let them know somehow. This seems to be a drawback of the capabilities ap= proach.=C2=A0

    In terms of privacy and control, I, as the RO, want a contract=C2=A0with t= he RS that says that I or my agent (AS-RO) must sign an access token. This = is a fundamental audit requirement. Without it, a rogue RS and AS-RS can do= all sorts of things and the RO would never know. I understand that a rogue= RS might not support an honest contemporaneous log of access tokens presen= ted so there's a trust issue here that I seems unavoidable unless I spe= cify in my RO-RS contract that they use a separate contemporaneous=C2=A0log= such as AS-RO for every access token presented and risk being sued if they= process an access token without also updating the separate log.

    <= /div>
    - Adrian<= /div>


    On Thu, Mar 25, 2021 at 1:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justi= n Richer <jricher@m= it.edu> wrote:
    Hi Alan,

    In all of my discussion, and in the = spec itself, the RO is the :entity: in charge of approving rights. They=E2= =80=99re probably a person. It might be software that makes a policy decisi= on in some way, or a corporate entity, or something like that. But it=E2=80= =99s not assumed to be a computational agent in the terms of the protocol i= tself. Would that recast what you=E2=80=99re saying below?

    Hmmm.=C2=A0 I guess not.=C2=A0= It's just that the person would be using some UI to express their deci= sions to what I called the user agent.=C2=A0 That model fits in very nicely= with what we did with Polaris, our virus safe computing environment for Wi= ndows XP, https://dl.acm.org/doi/10.1145/1151030.1151033.=C2=A0 The p= erson would click on the icon for a Word file, and an instance of Word woul= d open with only the permission needed to edit that one file.=C2=A0 Same th= ing here.=C2=A0 The client could ask for permission to use the resource, or= permission could be granted implicitly when the user selects a resource as= sociated with a specific client.

    --------------Alan Karp


    On Thu, Mar 25, 2021 at 9:53 AM Justin Richer &l= t;jricher@mit.edu&= gt; wrote:
    = Hi Alan,

    In all of my discussion, and in the spec itself= , the RO is the :entity: in charge of approving rights. They=E2=80=99re pro= bably a person. It might be software that makes a policy decision in some w= ay, or a corporate entity, or something like that. But it=E2=80=99s not ass= umed to be a computational agent in the terms of the protocol itself. Would= that recast what you=E2=80=99re saying below?

    =C2= =A0=E2=80=94 Justin

    On Mar 25, 2= 021, at 12:36 PM, Alan Karp <alanhkarp@gmail.com> wrote:

    There seems to be some confusion about how AS-RO comes into the pictur= e, probably because of the "AS" part.=C2=A0 I'm going to try = to clear up that confusion by more carefully explaining what I mean.
    I'm assuming that RO is a computational agent representing the p= erson who is the resource owner, something called the "user agent"= ; in operating systems lingo.=C2=A0 I'm also assuming that it's pos= sible to do delegation, either locally or by token exchange with AS-RS.=C2= =A0 All delegations are potentially sub-scoped, but you may also want to de= legate with full scope to have a separately revocable access token.

    =C2=A0 Here's an example of how things work in a capa= bility oriented system.
    1. Someone, the service owner, c= reates a service.
    2. The service owner contracts with an policy agent = (AS-RS) to create and manage access tokens for that service (RS).
    3. A= person wishing to create a resource at RS uses their user agent (RO) to co= ntact the service owner's policy agent (AS-RS) and gets back an access = token for that resource.
    4. That user agent (RO) can=C2=A0
        5. use that access token to invoke the resource, or
      1. delegate an acces= s token to a client of the user agent's (RO) choice, or
      2. contrac= t with a policy agent (AS-RO) to manage those delegations on behalf of the = user agent (RO), or
      3. specify a policy with the service's policy = agent (AS-RS).
    5. A client can contact any holder of the access t= oken (the user agent (RO) or its policy agent (AS-RO)) or the service's= policy agent (AS-RS) to get a delegated access token.
    6. That client = can delegate that token to another client.
    7. Another user agent (RO&#= 39;) can contact any holder of the access token or the service's policy= agent (AS-RS) to get a delegated access token.
    8. The other user agen= t (RO') can=C2=A0
      1. use that access token to invoke the resou= rce, or
      2. delegate it to a client of its choice, or
      3. contract = with a policy agent (AS-RO') of its choosing to manage those delegatio= ns on its behalf, or
      4. specify a policy with the service's policy= agent (AS-RS).
    9. and so on
    When a= ny of these computational agents, user agents (ROs) or clients acting on th= eir behalf, invokes the resource, AS-RS verifies that the access token is a= valid delegation, i.e., proper sub-scoping, hasn't been revoked, and t= hat it authorizes the request being made before telling the service (RS) to= honor the request.=C2=A0 At no point does the service's policy agent (= AS-RS) know which computational agent did any particular delegation.=C2=A0 = (Token exchange can be done as anonymously as possible.)=C2=A0 In particula= r, the policy agents (AS-RO) need not be the same, or even compatible with,= the service's policy agent (AS-RS).=C2=A0 GNAP specifies the protocol = between requesters, invokers, delegators (for token exchange) of tokens and= AS-RS.=C2=A0 That protocol need not be used between user agents (RO), clie= nts, or other policy agents (AS-RO), but it is likely to be.

    =
    =C2=A0-------------
    Alan Karp


    On Thu, Mar 25, 2021 at 5:45 AM Justin Richer <jricher@mit.edu> wrot= e:
    The way = I=E2=80=99m thinking about Adrian=E2=80=99s use case is that what we=E2=80= =99re calling the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an =E2=80=9CAS=E2= =80=9D in the traditional OAuth/GNAP sense, at least not exactly. This is t= he agent that the RO can use to set policies and manage consent on their be= half, and I=E2=80=99ve been arguing that it fits better into this vaguely-d= efined =E2=80=9Cinteraction component=E2=80=9D aspect of the current AS def= inition, and it=E2=80=99s not currently separated from the AS definition. T= he =E2=80=9CAS-RS=E2=80=9D maps to what we=E2=80=99d call the =E2=80=9CAS= =E2=80=9D in OAuth/GNAP traditionally, it=E2=80=99s what the RS trusts to i= ssue tokens. In traditional OAuth the AS-RO and AS-RS are always the same t= hing, from a functional protocol perspective. An important point here is th= at from a client=E2=80=99s perspective, they=E2=80=99re only talking to the= AS-RS since that=E2=80=99s where the client gets its tokens, because at th= e end of the day the client just wants to call the API at the RS and doesn= =E2=80=99t care how that happens (from a protocol standpoint).=C2=A0
    Note well: Even thought I don=E2=80=99t believe that =E2=80=9C= AS-RO=E2=80=9D is an authorization server at all, I=E2=80=99m going to keep= using that term below for consistency with previous discussion.
    =
    So we have these fundamental relationships around getting th= e client to access the RS:

    1. RS trusts=C2=A0AS-RS= =C2=A0to issue tokens that RS will accept, validate, and process for reques= ts from client
    2. Client trusts=C2=A0AS-RS=C2=A0to issue tokens t= hat client can use at RS
    3. RO trusts RS to protect RO=E2=80=99s = api through delegated access

    On top of that, we=E2= =80=99ve got some additional aspects that we=E2=80=99re discussing:

    4. RO trusts=C2=A0AS-RO=C2=A0to manage RO=E2=80=99s polic= ies at runtime
    5.=C2=A0AS-RS=C2=A0trusts=C2=A0AS-RO=C2=A0to asser= t RO=E2=80=99s policies for access to RS
    6. Client trusts whateve= r=C2=A0AS-RS=C2=A0sends client to deal with, including possibly RO-AS at ru= ntime, because of (2)

    What I have been saying is t= hat 4/5/6 are optional details of how RS-AS runs things, and I think this a= lso maps with Adrian=E2=80=99s view of choice, since if my RS=E2=80=99s AS-= RS doesn=E2=80=99t allow me to plug in my own AS-RO then I would be motivat= ed to pick a different RS who=E2=80=99s AS-RS lets me do just that. The sam= e way I=E2=80=99d pick a different RS if their surrounding services didn=E2= =80=99t accept my preferred federation login and I didn=E2=80=99t want to m= ake another account. Of course, market forces being as they are, I might no= t have much of an actionable choice in RS, but GNAP can=E2=80=99t change th= at.=C2=A0

    What we can do is make it possible for A= S-RS to talk to AS-RO, both in philosophy of the protocol design and in con= crete hooks to support (6) above.=C2=A0

    Separately= , we can approach the issue of making 1/2 above more dynamic. This was UMA2= =E2=80=99s =E2=80=9Cfederated authorization=E2=80=9D approach, and is behin= d a lot of the =E2=80=9Cbring your own AS=E2=80=9D models out there. The pr= oblem with these is that we know from many years of experience that most RS= =E2=80=99s aren=E2=80=99t interested in doing anything of the sort.

    So with GNAP we can instead allow 4/5/6 to vary in a pred= ictable and consistent way, letting the RS keep control over 1/2, thereby e= nabling choice in (3). We don=E2=80=99t have to be the ones who define the = all of the details of every permutation of (5) to enable this, though. Some= of this is going to be configuration out of band, some of it=E2=80=99s goi= ng to be communication at runtime. This is where VC=E2=80=99s, ZCAPs, CHAPI= , DIDComm, FIDO, and a whole swath of other tech can come in and help out. = I don=E2=80=99t think we need to put all the details for using these into c= ore, nor do I think we=E2=80=99ll pull of The Great And Ultimate Abstractio= n for using these and other approaches. But we can at least start talking a= bout =E2=80=9CAS-RS=E2=80=9D in such a way that it no longer assumes it=E2= =80=99s always the same party dealing with the RO directly.

    =C2=A0=E2=80=94 Justin

    O= n Mar 25, 2021, at 6:40 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    To reframe it closer to GNAP:
    - AS =3D AS= -RO, that's where you find the RO policies. The AS issues access tokens= to the client.
    - the RO policies could be a) defined locally or = b) in relationship with the RS

    There have been sev= eral ideas related to the AS-RS relationship b:
    b1) the RS is= sues capabilities (which can be further attenuated by the RO)
    b2)= Adrian also discussed a DID based solution
    b3) there was also an= alternative ACL proposal from Denis (+ preflight)

    Fabien


    On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbaul= t <fabien.= imbault@gmail.com> wrote:
    Ok so I get you correctly:=C2=A0
    - wh= at matters is the RQ (could be a RO or a end-user or both : we don't re= ally care at a high-level, they're all treated as entities that make a = request)
    - the policy is able to handle those different cases, ba= sed on its own internal delegation protocol
    - currently that requ= ires AS-RS and AS-RO, but maybe it can be simplified

    To answer to Denis, here's what I understood:
    - RO trusts = AS-RS (and then handles its own policies within AS-RO)
    - end-= user trusts AS-RO (through its client)

    Could proba= bly work but that's a fairly different model compared to OAuth2 (and of= today's GNAP), with different frontiers between the AS and the RS.=C2= =A0

    Please do not hesitate to correct me if I'= m wrong.

    Fabien=C2=A0

    On Thu, Mar 25, 2021 at= 9:26 AM Adrian Gropper <agropper@healthurl.com> wrote:
    I believe there are al= ternatives to having two kinds of ASs. The problem may be a side-effect of = deciding to switch away form treating the RO as different from the RQ. That= leads to downstream privacy issues. Our desire for architectural simplicit= y is admirable but that may have been a step too far.

    There may also be solutions based on differen= t types of tokens, as in different capabilities (tokens signed by the RS) v= s. tokens signed by the AS. I=E2=80=99m not sure about that but Alan might = have more to say.

    Adrian=

    On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault <fabien.imbault@gmail.com>= wrote:
    Thanks. The general problem statement is clear.

    The=C2=A0proposed solution a bit less (to me). I understood that from poin= t 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obvious reason to have two types of ASs".=C2=A0<= /span>Do you see an alternative ?

    Regarding = the last item, I don't think that naming RQ by end-user created the pro= blem. It might just highlight the asymmetry,=C2=A0which fundamentally exist= s.=C2=A0

    Fabien


    On Thu, Mar 25, 2021 at 8:48 AM A= drian Gropper <agropper@healthurl.com> wrote:
    Recap:
    1 = - Justin (I think) introduced the idea of an AS on the RS trust boundary si= de.
    2 - I said the RO should not have to share polic= ies with the RS.
    3 - Alan invented the concept of AS= -RO and AS-RS to separate two kinds of PDPs.=C2=A0
    <= br>
    The thing is that step 2 is not symmetrical. The= RO has a legitimate privacy interest in keeping their policies private and= minimizing the leakage of information about requests that are posed agains= t those policies.=C2=A0

    = The RS, on the other hand, should be publishing its policies (e.g. what it= =E2=80=99s selling or what jurisdiction it=E2=80=99s in or what tokens or s= copes it supports). The RS has no obvious privacy interest in GNAP. It=E2= =80=99s just an enforcer.

    There is one other privacy interest to consider around the RS and that is= the requesting party (the end-user that is not the RO :-) might prefer to = share attributes with the RS instead of the RO or something controlled by t= he RO. This case could be an =E2=80=9Cextension=E2=80=9D to GNAP and might = result in a split AS as a solution. This problem was introduced when the ed= itors decided to replace RQ with end-user. Obviously, the RO end-user has n= o privacy interests relative to itself.

    Adrian

    <= br>


    On Thu, Mar 25, 2021 at 3:24 AM Fabien = Imbault <f= abien.imbault@gmail.com> wrote:
    I was referring to "By my definition, this model has two ASs= since both are processing requests into tokens". If there's no re= ason to have 2 types of ASs, that's fine then.=C2=A0
    But = I'm a bit lost in where we stand with the idea.=C2=A0
    Could you recap?=C2=A0
    =

    Fabien=C2=A0

    Le jeu. 25 mars 2021 =C3= =A0 08:16, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    =
    There= =E2=80=99s no obvious reason to have two types of ASs. Any AS that is execu= ting the policies of the RS can look to GNAP like the RS itself. Why would = GNAP expose that interface to anyone?=C2=A0

    Adrian

    On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbau= lt <fabien.imbault@gmail.com> wrote:
    Note : I'm not s= ure that's a good idea, but having 2 types of ASs is not that easy to g= rasp.

    = Fabien=C2=A0

    Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault <fabien.imbault@gmail.com> a =C3=A9crit=C2=A0:
    The purpose of ei= ther handling policies locally or delegating them to the RO agent.=C2=A0
    Le = jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper <agropper@= healthurl.com> a =C3=A9crit=C2=A0:
    What purpose would be served by= GNAP splitting the AS into two components?

    Adrian=C2=A0

    On Thu, Mar = 25, 2021 at 2:59 AM Fabien Imbault <fabien.i= mbault@gmail.com> wrote:
    Isn't the AS-RO a component of the AS= ? Same idea as the interact component, it functionnally belongs to the AS r= ole but could be deployed either as a monolith or as a separate component?<= /div>

    Fabien=

    Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    Yes, but I= would say it=E2=80=99s not the RO that wants the access token. It=E2=80=99= s the RO that wants the client making the request to get an access token.= =C2=A0

    Adrian
    =
    On Wed= , Mar 24, 2021 at 11:22 PM Alan Karp <= alanhkarp@gmail.com> wrote:
    Adrian Gropper <agr= opper@healthurl.com> wrote:

    In this= design, the AS is the AS-RS and the agent is the AS-RO. By my definition, = this model has two ASs since both are processing requests into tokens. The = problem with this is complexity and privacy. The RO may not want to share t= he request information with the AS-RS.
    <= div>

    More precisely, RO has no choice but to= present the required information to AS-RS if RO wants an access token.=C2= =A0 However, RO does not want AS-RS to know the policy by which RO delegate= s tokens.=C2=A0 That's why RO uses AS-RO for those delegations.

    --------------
    Alan Karp

    <= div dir=3D"ltr">
    On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Thank you for creating the issue. My definition of AS is independent of= AS-RO or AS-RS.=C2=A0https://github.com/ietf-wg-gnap/gnap= -core-protocol/issues/223#issuecomment-806280421 I also agree with Alan= 's definition based on delegation. An AS-RS would be a delegate of the = RS.=C2=A0

    Based on that, I see it as o= bvious=C2=A0that the policy has to be accessible (defined locally?) in orde= r for it to be run as the code that turns a request into an access token.= =C2=A0

    The only other possibility is that the requ= est is packaged by the AS and sent elsewhere (an agent) for evaluation agai= nst policy and a proto-token returned. In that case the AS is acting as a p= roxy and the PDP is elsewhere. I can imagine that an AS-RS would behave thi= s way so that the proto-token could be turned into an access token by the A= S-RS. Isn't this what Justin is proposing? In this design, the AS is th= e AS-RS and the agent is the AS-RO. By my definition, this model has two AS= s since both are processing requests into tokens. The problem with this is = complexity and privacy. The RO may not want to share the request informatio= n with the AS-RS.

    Adrian

    On Wed, Mar 24, 2021= at 5:21 PM Fabien Imbault <fabie= n.imbault@gmail.com> wrote:
    Isn't that what the AS is sup= posed to be, only with the caveat that the policy is defined locally?=C2=A0=

    Fabien=C2=A0


    Le mer. 24 ma= rs 2021 =C3=A0 20:17, Alan Karp <alanh= karp@gmail.com> a =C3=A9crit=C2=A0:
    AS-RO is an AS= that RO trusts to delegate RO's access tokens according to RO's po= licies.=C2=A0=C2=A0

    ------------= --
    Alan Karp


    On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbau= lt <fabien.imbault@gma= il.com> wrote:
    Hi Alan and Adrian,

    I've crea= ted issue AS-RO policy delegation (https://github.com/ietf-wg-gnap/gna= p-core-protocol/issues/223) to capture your input.=C2=A0
    A fi= rst question that arises: can we give a definition to AS-RO?

    =
    Thanks
    Fabien

    On Tue, Mar 23, 2021 at 4:15 PM Ala= n Karp <alanhkarp@gmail.com= > wrote:
    =
    Fabien Imbault <fabien.imbault@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 Alan,= =C2=A0

    Yes, but in that flow, the token relationship bet= ween AS-RS and AS-RO is only secure if the tokens issued by AS-RS are crypt= ographically attenuable in the first place.=C2=A0
    <= div>=C2=A0
    Attenuated delegation is a requiremen= t, but that doesn't have to be done cryptographically.=C2=A0 Token exch= ange works just fine.=C2=A0 SPKI and zcap-ld are examples of the crypto app= roach, and we used token exchange in the system for HP.

    --------------
    Alan Karp


    On Tue, Mar 23, 202= 1 at 4:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan,=C2=A0

    Yes, but in that flow, the token relationship between AS-RS and AS= -RO is only secure if the tokens issued by AS-RS are cryptographically atte= nuable in the first place.=C2=A0

    Fabien

    On Mo= n, Mar 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin Richer <jricher@mit.edu> wrote:

    But with all that in = mind, I think the key here is going to be looking at what the inputs to the= AS are, and how those can be defined in an interoperable way for AS=E2=80= =99s that can accept them. I think there=E2=80=99s a lot of room for innova= tion and flexibility here that doesn=E2=80=99t break the trust model or cor= e use cases. If I have an AS-RS set that won=E2=80=99t accept my favorite f= lavor of policy engine inputs, then I can decide not to use that one. But t= his is a very different question than saying the RS itself needs to accept = my own AS =E2=80=94 and we can=E2=80=99t keep conflating these two models.<= /div>

    I agree.=C2=A0 The point of hav= ing an AS-RO is to allow RO to specify a policy for which of RO's acces= s tokens should be delegated under what conditions.=C2=A0 AS-RS should not = need to understand those policies.=C2=A0 The flow would be
      RO contacts AS-RS and gets one or more access tokens.
    • RO delegate= s one or more of those tokens, potentially sub-scoped, to AS-RO.
    • A = different user contacts AS-RO to get a potentially sub-scoped access token = from AS-RO.
    • That user presents the access token delegated by AS-RO = when invoking the resource.
    AS-RS only needs to ve= rify that the delegation chain is legitimate, e.g., no increase in scope, a= nd that it grants permission for the request being made.=C2=A0 AS-RS does n= ot need to understand the policy behind granting the delegation by AS-RO.

    --------------
    Alan Karp

    <= br>
    On Mon,= Mar 22, 2021 at 11:40 AM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    I think this sho= ws the problem with the terminology as it=E2=80=99s been applied in this co= nversation, which I=E2=80=99ve tried to shine light on before. What you and= others are calling the =E2=80=9CRS=E2=80=9D is really the =E2=80=9CAS and = RS working together=E2=80=9D =E2=80=94 everything to the right of the line.= When Denis had brought up =E2=80=9Celiminating the AS=E2=80=9D in another = thread, what he=E2=80=99d really done is labeled everything to the right of= the line as the =E2=80=9CRS=E2=80=9D. Of course, the irony here is that ev= erything to the right of the line used all be called the =E2=80=9CAS=E2=80= =9D or simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say belo= w, I don=E2=80=99t want the client to have visibility on what happens on th= at side.=C2=A0

    Note well: The Google+ logo labeled= =E2=80=9CIdP=E2=80=9D in the diagram is not the AS, as far as GNAP is conc= erned. It does not issue an access token that the RS will accept. The eleme= nts to the left of the line could be a lot of things, but they are NOT the = AS =E2=80=94 by definition. The client lives over on the left, but so do an= y external inputs to the AS. These could be policy inputs on behalf of the = RO, they could be presentation artifacts, they could be federated logins, t= hey could be the output of policy decisions. How the AS comes to trust thos= e things is up to the AS=E2=80=99s implementation. It=E2=80=99s something w= e can talk about, but ultimately GNAP won=E2=80=99t be in any position to d= ictate because in practice some AS=E2=80=99s are simply going to internaliz= e all policies and we will never successfully force those open.=C2=A0
    =

    But with all that in mind, I think the key here is goin= g to be looking at what the inputs to the AS are, and how those can be defi= ned in an interoperable way for AS=E2=80=99s that can accept them. I think = there=E2=80=99s a lot of room for innovation and flexibility here that does= n=E2=80=99t break the trust model or core use cases. If I have an AS-RS set= that won=E2=80=99t accept my favorite flavor of policy engine inputs, then= I can decide not to use that one. But this is a very different question th= an saying the RS itself needs to accept my own AS =E2=80=94 and we can=E2= =80=99t keep conflating these two models.

    So to me= , GNAP can support a Zero Trust Architecture by LEVERAGING the AS, not by s= ubsuming or eliminating it. It is in fact the AS, not the client and not th= e RS, that will request and consume the results of a privacy-preserving zer= o-trust policy query thing. Anything that happens downstream from that is o= f little concern to the zero-trust components because, as you point out, it= =E2=80=99s on the =E2=80=9Cother side=E2=80=9D of the line.=C2=A0

    I think we got this basic component model pretty right in O= Auth: the AS and RS and client working together. Where OAuth misses the mar= k is the assumption that the user has to log in to the AS through a webpage= and interact directly, thereby proving they=E2=80=99re the RO. It=E2=80=99= s this latter space where I think we can both push innovation and also addr= ess the important and compelling use cases like the ones you=E2=80=99re bri= nging.

    =C2=A0=E2=80=94 Justin

    On Mar 22, 2021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> = wrote:

    I'm sorry, Justin. As a Resource = Owner, I look at the RS trust boundary (the dotted line in the diagram) as = being the RS. I don't expect any visibility into what's going on on= the=C2=A0right.=C2=A0

    My problem with the framing you p= ropose is that requests are going to the RS (or the AS-RS) and I don't = want to share my policies with the AS-RS. I want to keep the RS and AS-RS a= s ignorant as possible.

    Adrian

    On Mon, Mar 22= , 2021 at 1:48 PM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    What you=E2=80=99re discu= ssing below, in terms of logging in to a site, is not approaching the RS. Y= ou are in fact approaching the client, and identifying both the AS and RS t= o the client. The client is a client of your identity in this model,= and the RS is part of the identity provider. It=E2=80=99s really important= that we don=E2=80=99t conflate the RS and client in this way as it leads t= o a lot of confusion downstream and a lot of broken trust boundaries.
    =

    With that model in mind, approaching the =E2=80=9CRS&qu= ot; and providing it your identity is really just a case of the =E2=80=9Cfe= derated login to AS=E2=80=9D pattern that we discussed on the WG call. The = user here approaches an RS, which has its own AS. To share things from this= RS, the RO has to authenticate to the RS=E2=80=99s AS. This particular AS = allows the RO to do so using an external identity =E2=80=94 in which case, = the AS is now a =E2=80=9Cclient=E2=80=9D of a separate, disconnected (but l= ayered) delegation. The ultimate client that eventually calls the RS down t= he way may or may not know about these layers.=C2=A0

    <PastedGraphic-1.png>
    This same AS, which is closely tied to the RS and trusted by the RS, = might also take in FIDO credentials, or DIDs, or any number of other proof = mechanisms. The output of this is an access token the RS trusts, but the in= put is up to the AS. The RS is not what you=E2=80=99re logging in to.
    =

    =C2=A0=E2=80=94 Justin

    On Mar 22, 2021, at 1:28 PM, Adrian Gropper <agropper@healthurl.com> wrote:
    =
    I too am in favor of avoiding consolidation and c= orrelation. Right now, when I approach a service provider (RS) for the firs= t time, I'm offered the opportunity to identify my persona as: email, s= ign-in with Google, Facebook, or Apple. I know there are people who try to = create one-off email addresses but that is mostly a waste of time.=C2=A0
    So, along come FIDO2 and DID wallets to the rescue. Now, i= n theory, I have a way to start out my RS relationship pseudonymously.=C2= =A0

    When I want my resource to be discovered or sh= ared I will post that RS URL including my pseudonym. If I then want to intr= oduce a mediator=C2=A0in front of my AS or messaging service=C2=A0endpoint,= I have that option. If I want to keep requests away from the mediator, I w= ould publish an encryption key along with my pseudonym.

    - Adrian



    On Mon, Mar 22, 2021 at 9= :55 AM Justin Richer <jricher@m= it.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhk= arp@gmail.com> shared a talk about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-= gnap/gnap-core-protocol/issues/145#issuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --
    TXAuth 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
    --
    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



    --000000000000e0bc4605be724872-- From nobody Fri Mar 26 08:55:53 2021 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 79A393A21B9 for ; Fri, 26 Mar 2021 08:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 Io-nRfHECMeK for ; Fri, 26 Mar 2021 08:55:43 -0700 (PDT) Received: from mail-vk1-f182.google.com (mail-vk1-f182.google.com [209.85.221.182]) (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 2927A3A21B2 for ; Fri, 26 Mar 2021 08:55:43 -0700 (PDT) Received: by mail-vk1-f182.google.com with SMTP id k27so1291624vki.2 for ; Fri, 26 Mar 2021 08:55:43 -0700 (PDT) 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=TK/i3JXHRMvvnIb9O80nprwsw2cS9yxGd8bkdFEMDwQ=; b=rCzJHV2T966UDZhrhERlrkLQqx39n6Mne8TJJ4KmfQNSBAewf2GsSrit9gL32jqEU6 VltAAhF62BKIgtt6XOd9vimTfXJvZyyYAJDhd5TB/WnSeLEglM8OOrb/2vEcAPIsbB4k 83Bky6Am0+oxTUyF8376V0TyIHat9HN2qwXT/wEyRFZbA67gMCTVrGkyhVefmyJZ4mqN N8lx/vDyxT5n1FfYVbQqfi0CmeziSRWzPocU3Ezzjf26VEKRqjJKGIm2u1WrWu9vH39l Kck/h+ITAGzWwEc6WJh+t0COD6V6PT3BFdZPBFZeWUvTX7M6gzECyHwtnwcWgAE+kBAl 8NwA== X-Gm-Message-State: AOAM533rqrJbqeEaIlaA5A1gXGq6zTxkegUBp2W1NWkG+1TXqgMnzH2B ytZGuWDU7kZ0D6s7r10irZ8BYdcqxGH5PmZ/V98= X-Google-Smtp-Source: ABdhPJzjuMdRnQ3gAxFYytAzjr+VxgAi4i4bN5YGnu9zzbBwbG7wZJng6YN1Oi+elU8RXWK+PAA/kocWuWekcqG82GY= X-Received: by 2002:a1f:9345:: with SMTP id v66mr8916255vkd.22.1616774141389; Fri, 26 Mar 2021 08:55:41 -0700 (PDT) MIME-Version: 1.0 References: <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> <5773FA7B-6891-4227-A8CA-2F506909B8CD@mit.edu> <497B7A43-546E-4296-916F-6D177AEBE228@mit.edu> In-Reply-To: From: Adrian Gropper Date: Fri, 26 Mar 2021 11:55:29 -0400 Message-ID: To: Alan Karp Cc: Justin Richer , Benjamin Kaduk , Fabien Imbault , GNAP Mailing List , Mark Miller Content-Type: multipart/alternative; boundary="000000000000612ee105be7290c2" Archived-At: Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2021 15:55:52 -0000 --000000000000612ee105be7290c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable @Alan - The recent conversation between Justin and I does not use the AS-RS / AS-RO framing. For now, we're trying to figure out what is core to GNAP and what is optional. - Adrian On Fri, Mar 26, 2021 at 11:35 AM Alan Karp wrote: > Adrian Gropper wrote: > >> Good. I agree with the externalizing framing you use. To me, they are a >> pair. They represent the separation of concerns I=E2=80=99m focused on. = The AS has >> policies, gets requests from clients, and returns access tokens. >> > > I thought you also want RO to be able to delegate to a client without > AS-RS knowing what policy was used for that delegation. That's the > function of AS-RO. The client asks AS-RO for some permissions. AS-RO > either does a token exchange with AS-RS or gives the client something to > present to AS-RS to get a new access token. Introducing AS-RO also allow= s > RO to express policies that AS-RS may not support, such as break glass. > > -------------- > Alan Karp > > > On Fri, Mar 26, 2021 at 8:26 AM Adrian Gropper > wrote: > >> Good. I agree with the externalizing framing you use. To me, they are a >> pair. They represent the separation of concerns I=E2=80=99m focused on. = The AS has >> policies, gets requests from clients, and returns access tokens. >> >> So what are we disagreeing about? >> >> - Adrian >> >> On Fri, Mar 26, 2021 at 10:38 AM Justin Richer wrote: >> >>> Adrian, >>> >>> Yes, the RO is the party/entity which holds the rights for delegation, >>> and they perform that delegation to a piece of software (the client) >>> through the AS. The RS is what they=E2=80=99re delegating the access of= , for >>> API-access use cases (again, user/subject information is similar but >>> different). >>> >>> There isn=E2=80=99t a delegation between the RS and AS, then. You can p= erhaps >>> view them as externalizing functions that they might otherwise hold clo= se, >>> but not delegating in the same way the client gets delegated to. You ca= n >>> frame it one of two ways: >>> >>> - The RS externalizes its security, policy, authorization, and >>> delegation functions to the AS and looks for access tokens from the AS = as >>> proof of that happening (this is the most in line with the model you=E2= =80=99ve >>> been presenting) >>> - The AS externalizes its data-API functions to into the RS and >>> produces access tokens for the RS to consume/validate (this is actually= the >>> model that OAuth 2 started with, in extracting the RS as a separate ent= ity >>> as opposed to OAuth 1) >>> >>> They tell different views of the same reality. In OAuth, it=E2=80=99s a= ssumed >>> that the RO interacts with the AS directly to perform the delegation to= the >>> client. In GNAP, we=E2=80=99ve got an opportunity to expand that, which= has been >>> (to me) one of the biggest outcomes of this discussion. >>> >>> =E2=80=94 Justin >>> >>> On Mar 26, 2021, at 10:04 AM, Adrian Gropper >>> wrote: >>> >>> Justin, >>> >>> Big YES to =E2=80=9C The conceptual framework of an AS that takes in lo= ts of >>> different information and spits out access tokens is exactly the >>> abstraction layer that is necessary for making these use cases >>> interoperable.=E2=80=9D and probably everything else you just said. >>> >>> I seem to not understand the delegation design between RS and AS. In my >>> view, that delegation always goes through the RO, although the RO may b= e >>> forced to choose from a list provided by the RS. >>> >>> In my view, GNAP, can acknowledge this and design to be agnostic to >>> whether the AS is specified by he RO or picked from a list of 1 or more >>> choices provided by the RS. >>> >>> - Adrian >>> >>> On Fri, Mar 26, 2021 at 9:30 AM Justin Richer wrote: >>> >>>> Adrian, >>>> >>>> I disagree, I believe that what I have laid out is exactly separating >>>> the concerns into working components. >>>> >>>> Like OAuth before it, GNAP is a protocol negotiate access for a client >>>> instance to an RS, using an AS as the facilitator of that delegated >>>> negotiation. (Unlike OAuth, it=E2=80=99s importantly also for negotiat= ing user >>>> information to the client directly from the AS with no RS involved, bu= t >>>> that=E2=80=99s an aside for the purposes of our conversation here). >>>> >>>> If a particular GNAP RS also allows other kinds of processes to enable >>>> access to it, that is completely fine, but outside of GNAP. If an RS a= llows >>>> a username/password HTTP Basic auth in addition to accepting access to= kens, >>>> it can do so, but GNAP doesn=E2=80=99t have anything to say about the = Basic auth >>>> use, or even its relation to any access tokens or RO=E2=80=99s or anyt= hing else. If >>>> an RS accepts structured access tokens signed by trusted keys that don= =E2=80=99t >>>> come from an AS through a negotiated request =E2=80=94 again, that=E2= =80=99s fine, but GNAP >>>> is silent about the RS doing that. If the RS acts as =E2=80=9Cits own = AS=E2=80=9D then it=E2=80=99s >>>> really just an RS and an AS living in the same box. Again, that=E2=80= =99s fine, and >>>> super common with OAuth today. >>>> >>>> GNAP is solving the problem of connecting the client to the RS through >>>> means of an AS. Other solutions are possible and many of them can be >>>> deployed right alongside, but that=E2=80=99s not the corner of the wor= ld that GNAP >>>> is solving. GNAP should be concerned about how these other technologie= s can >>>> be used alongside it. I think there=E2=80=99s a lot of room for the th= ings that >>>> you=E2=80=99re talking about, and more importantly for solving the use= cases that >>>> you=E2=80=99re bringing. But GNAP should be more than a single-point s= olution, and >>>> so we need to balance these concerns. The conceptual framework of an A= S >>>> that takes in lots of different information and spits out access token= s is >>>> exactly the abstraction layer that is necessary for making these use c= ases >>>> interoperable. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Mar 26, 2021, at 8:30 AM, Adrian Gropper >>>> wrote: >>>> >>>> @Justin, there=E2=80=99s no separation of concerns here. No partition = between >>>> processor and controller. No data minimization. And, I see no obvious >>>> reason to make this the core of GNAP. >>>> >>>> The one thing we can probably all agree on is that there=E2=80=99s onl= y one RS >>>> and one RO. >>>> >>>> The core of GNAP, in my opinion, can be built and explained around thi= s >>>> simple design. The RS is a processor. The RO is a controller. The RS b= ears >>>> only security responsibility. The RS bears no privacy responsibility. = The >>>> RO delegates this to the RS but this is not authorization as the A in = GNAP. >>>> >>>> The RO retains all rights to delegate within the scope of things that >>>> the RS is willing to support using various token formats and endpoint >>>> options. Some of these options may do all sorts of things for all sort= s of >>>> clients and user-agents but these are options. >>>> >>>> For example, if a request comes to the RS that is not in the form of a= n >>>> access token, then it either gets sent to the RO or their agent, or it= gets >>>> logged and dumped. One such option, common in healthcare, is =E2=80=9C= Break the >>>> Glass=E2=80=9D where the RS is acting as an authorization server becau= se the >>>> user-agent is making a request instead of presenting an access token. = GNAP >>>> can offer this as an option but it is not our core. >>>> >>>> Adrian >>>> >>>> >>>> >>>> On Fri, Mar 26, 2021 at 7:15 AM Justin Richer wrote: >>>> >>>>> I have a big problem with this line: >>>>> >>>>> > the RS and AS-RS only see access tokens. The requests (from RO') >>>>> that resulted in an access token are none of their business. >>>>> >>>>> In the trust model we=E2=80=99ve been discussing, the requests that r= esult in >>>>> access tokens are *solely the business of AS-RS*, since AS-RS is the >>>>> only entity that=E2=80=99s allowed, and trusted by the RS, to create = access tokens >>>>> for the RS. That is its entire job, the entire reason it exists in th= e >>>>> system. By definition the party generating tokens for use at the RS i= s the >>>>> AS for that RS, I don=E2=80=99t care how you deploy it. If RO wants t= o give access >>>>> to someone else (who isn=E2=80=99t an =E2=80=9CRO" anymore, they=E2= =80=99re another end-user), then >>>>> that end user=E2=80=99s client software will need to talk to AS-RS to= get its own >>>>> access token. >>>>> >>>>> Now here=E2=80=99s the trick: when the end user=E2=80=99s client inst= ance talks to >>>>> AS-RS, that does NOT mean that AS-RS needs to know all the details an= d >>>>> policy reasons that it should give an access token to that client ins= tance. >>>>> It doesn=E2=80=99t even need to know the existence of another end use= r. It doesn=E2=80=99t >>>>> need identity, it doesn=E2=80=99t need policy. Sure, it COULD handle = all of that >>>>> internally, and many will, but the protocol doesn=E2=80=99t demand it= . >>>>> >>>>> This means that the first client instance, the one that gets the >>>>> access token, can also be given something alongside the access token = that >>>>> it can then hand to another piece of software (or to a person to hand= eo >>>>> their piece of software). This artifact is not an access token. This >>>>> artifact could be something structured that the client understands, a= nd can >>>>> make derivatives of, and present back to the AS-RS for getting new ac= cess >>>>> tokens. There could be multiple different flavors of this kind of art= ifact >>>>> for different kinds of environments and groups. But what they all hav= e in >>>>> common is that they can potentially be used to request more access to= kens >>>>> within some context at the AS-RS. >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> >>>>> >>>>> On Mar 25, 2021, at 5:50 PM, Adrian Gropper >>>>> wrote: >>>>> >>>>> My issue is with Alan's: >>>>> >>>>> "7. Another user agent (RO') can contact any holder of the access >>>>> token or the service's policy agent (AS-RS) to get a delegated access >>>>> token." >>>>> >>>>> >>>>> I would prefer "7A. Another user agent (RO') can contact any holder >>>>> of the access token." by default so that the AS-RS does not see the >>>>> requests. In other words, the RS and AS-RS only see access tokens. Th= e >>>>> requests (from RO') that resulted in an access token are none of thei= r >>>>> business. >>>>> >>>>> The reality is that RO' can discover a resource RS and can share >>>>> whatever information with RS-AS they want and the RO may not even kno= w >>>>> about it unless the RS decides to let them know somehow. This seems t= o be a >>>>> drawback of the capabilities approach. >>>>> >>>>> In terms of privacy and control, I, as the RO, want a contract with >>>>> the RS that says that I or my agent (AS-RO) must sign an access token= . This >>>>> is a fundamental audit requirement. Without it, a rogue RS and AS-RS = can do >>>>> all sorts of things and the RO would never know. I understand that a = rogue >>>>> RS might not support an honest contemporaneous log of access tokens >>>>> presented so there's a trust issue here that I seems unavoidable unle= ss I >>>>> specify in my RO-RS contract that they use a separate contemporaneous= log >>>>> such as AS-RO for every access token presented and risk being sued if= they >>>>> process an access token without also updating the separate log. >>>>> >>>>> - Adrian >>>>> >>>>> >>>>> On Thu, Mar 25, 2021 at 1:22 PM Alan Karp wrote= : >>>>> >>>>>> Justin Richer wrote: >>>>>> >>>>>>> Hi Alan, >>>>>>> >>>>>>> In all of my discussion, and in the spec itself, the RO is the >>>>>>> :entity: in charge of approving rights. They=E2=80=99re probably a = person. It might >>>>>>> be software that makes a policy decision in some way, or a corporat= e >>>>>>> entity, or something like that. But it=E2=80=99s not assumed to be = a computational >>>>>>> agent in the terms of the protocol itself. Would that recast what y= ou=E2=80=99re >>>>>>> saying below? >>>>>>> >>>>>> >>>>>> Hmmm. I guess not. It's just that the person would be using some U= I >>>>>> to express their decisions to what I called the user agent. That mo= del >>>>>> fits in very nicely with what we did with Polaris, our virus safe co= mputing >>>>>> environment for Windows XP, >>>>>> https://dl.acm.org/doi/10.1145/1151030.1151033. The person would >>>>>> click on the icon for a Word file, and an instance of Word would ope= n with >>>>>> only the permission needed to edit that one file. Same thing here. = The >>>>>> client could ask for permission to use the resource, or permission c= ould be >>>>>> granted implicitly when the user selects a resource associated with = a >>>>>> specific client. >>>>>> >>>>>> -------------- >>>>>> Alan Karp >>>>>> >>>>>> >>>>>> On Thu, Mar 25, 2021 at 9:53 AM Justin Richer >>>>>> wrote: >>>>>> >>>>>>> Hi Alan, >>>>>>> >>>>>>> In all of my discussion, and in the spec itself, the RO is the >>>>>>> :entity: in charge of approving rights. They=E2=80=99re probably a = person. It might >>>>>>> be software that makes a policy decision in some way, or a corporat= e >>>>>>> entity, or something like that. But it=E2=80=99s not assumed to be = a computational >>>>>>> agent in the terms of the protocol itself. Would that recast what y= ou=E2=80=99re >>>>>>> saying below? >>>>>>> >>>>>>> =E2=80=94 Justin >>>>>>> >>>>>>> On Mar 25, 2021, at 12:36 PM, Alan Karp wrote= : >>>>>>> >>>>>>> There seems to be some confusion about how AS-RO comes into the >>>>>>> picture, probably because of the "AS" part. I'm going to try to cl= ear up >>>>>>> that confusion by more carefully explaining what I mean. >>>>>>> >>>>>>> I'm assuming that RO is a computational agent representing the >>>>>>> person who is the resource owner, something called the "user agent"= in >>>>>>> operating systems lingo. I'm also assuming that it's possible to d= o >>>>>>> delegation, either locally or by token exchange with AS-RS. All >>>>>>> delegations are potentially sub-scoped, but you may also want to de= legate >>>>>>> with full scope to have a separately revocable access token. >>>>>>> >>>>>>> Here's an example of how things work in a capability oriented >>>>>>> system. >>>>>>> >>>>>>> 1. Someone, the service owner, creates a service. >>>>>>> 2. The service owner contracts with an policy agent (AS-RS) to >>>>>>> create and manage access tokens for that service (RS). >>>>>>> 3. A person wishing to create a resource at RS uses their user >>>>>>> agent (RO) to contact the service owner's policy agent (AS-RS) a= nd gets >>>>>>> back an access token for that resource. >>>>>>> 4. That user agent (RO) can >>>>>>> 1. use that access token to invoke the resource, or >>>>>>> 2. delegate an access token to a client of the user agent's >>>>>>> (RO) choice, or >>>>>>> 3. contract with a policy agent (AS-RO) to manage those >>>>>>> delegations on behalf of the user agent (RO), or >>>>>>> 4. specify a policy with the service's policy agent (AS-RS). >>>>>>> 5. A client can contact any holder of the access token (the user >>>>>>> agent (RO) or its policy agent (AS-RO)) or the service's policy = agent >>>>>>> (AS-RS) to get a delegated access token. >>>>>>> 6. That client can delegate that token to another client. >>>>>>> 7. Another user agent (RO') can contact any holder of the access >>>>>>> token or the service's policy agent (AS-RS) to get a delegated a= ccess token. >>>>>>> 8. The other user agent (RO') can >>>>>>> 1. use that access token to invoke the resource, or >>>>>>> 2. delegate it to a client of its choice, or >>>>>>> 3. contract with a policy agent (AS-RO') of its choosing to >>>>>>> manage those delegations on its behalf, or >>>>>>> 4. specify a policy with the service's policy agent (AS-RS). >>>>>>> 9. and so on >>>>>>> >>>>>>> When any of these computational agents, user agents (ROs) or client= s >>>>>>> acting on their behalf, invokes the resource, AS-RS verifies that t= he >>>>>>> access token is a valid delegation, i.e., proper sub-scoping, hasn'= t been >>>>>>> revoked, and that it authorizes the request being made before telli= ng the >>>>>>> service (RS) to honor the request. At no point does the service's = policy >>>>>>> agent (AS-RS) know which computational agent did any particular >>>>>>> delegation. (Token exchange can be done as anonymously as possible= .) In >>>>>>> particular, the policy agents (AS-RO) need not be the same, or even >>>>>>> compatible with, the service's policy agent (AS-RS). GNAP specifie= s the >>>>>>> protocol between requesters, invokers, delegators (for token exchan= ge) of >>>>>>> tokens and AS-RS. That protocol need not be used between user agen= ts (RO), >>>>>>> clients, or other policy agents (AS-RO), but it is likely to be. >>>>>>> >>>>>>> ------------- >>>>>>> Alan Karp >>>>>>> >>>>>>> >>>>>>> On Thu, Mar 25, 2021 at 5:45 AM Justin Richer >>>>>>> wrote: >>>>>>> >>>>>>>> The way I=E2=80=99m thinking about Adrian=E2=80=99s use case is th= at what we=E2=80=99re >>>>>>>> calling the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an =E2=80=9CAS= =E2=80=9D in the traditional OAuth/GNAP sense, at >>>>>>>> least not exactly. This is the agent that the RO can use to set po= licies >>>>>>>> and manage consent on their behalf, and I=E2=80=99ve been arguing = that it fits >>>>>>>> better into this vaguely-defined =E2=80=9Cinteraction component=E2= =80=9D aspect of the >>>>>>>> current AS definition, and it=E2=80=99s not currently separated fr= om the AS >>>>>>>> definition. The =E2=80=9CAS-RS=E2=80=9D maps to what we=E2=80=99d = call the =E2=80=9CAS=E2=80=9D in OAuth/GNAP >>>>>>>> traditionally, it=E2=80=99s what the RS trusts to issue tokens. In= traditional >>>>>>>> OAuth the AS-RO and AS-RS are always the same thing, from a functi= onal >>>>>>>> protocol perspective. An important point here is that from a clien= t=E2=80=99s >>>>>>>> perspective, they=E2=80=99re only talking to the AS-RS since that= =E2=80=99s where the >>>>>>>> client gets its tokens, because at the end of the day the client j= ust wants >>>>>>>> to call the API at the RS and doesn=E2=80=99t care how that happen= s (from a >>>>>>>> protocol standpoint). >>>>>>>> >>>>>>>> Note well: Even thought I don=E2=80=99t believe that =E2=80=9CAS-R= O=E2=80=9D is an >>>>>>>> authorization server at all, I=E2=80=99m going to keep using that = term below for >>>>>>>> consistency with previous discussion. >>>>>>>> >>>>>>>> So we have these fundamental relationships around getting the >>>>>>>> client to access the RS: >>>>>>>> >>>>>>>> 1. RS trusts AS-RS to issue tokens that RS will accept, validate, >>>>>>>> and process for requests from client >>>>>>>> 2. Client trusts AS-RS to issue tokens that client can use at RS >>>>>>>> 3. RO trusts RS to protect RO=E2=80=99s api through delegated acce= ss >>>>>>>> >>>>>>>> On top of that, we=E2=80=99ve got some additional aspects that we= =E2=80=99re >>>>>>>> discussing: >>>>>>>> >>>>>>>> 4. RO trusts AS-RO to manage RO=E2=80=99s policies at runtime >>>>>>>> 5. AS-RS trusts AS-RO to assert RO=E2=80=99s policies for access t= o RS >>>>>>>> 6. Client trusts whatever AS-RS sends client to deal with, >>>>>>>> including possibly RO-AS at runtime, because of (2) >>>>>>>> >>>>>>>> What I have been saying is that 4/5/6 are optional details of how >>>>>>>> RS-AS runs things, and I think this also maps with Adrian=E2=80=99= s view of choice, >>>>>>>> since if my RS=E2=80=99s AS-RS doesn=E2=80=99t allow me to plug in= my own AS-RO then I >>>>>>>> would be motivated to pick a different RS who=E2=80=99s AS-RS lets= me do just that. >>>>>>>> The same way I=E2=80=99d pick a different RS if their surrounding = services didn=E2=80=99t >>>>>>>> accept my preferred federation login and I didn=E2=80=99t want to = make another >>>>>>>> account. Of course, market forces being as they are, I might not h= ave much >>>>>>>> of an actionable choice in RS, but GNAP can=E2=80=99t change that. >>>>>>>> >>>>>>>> What we can do is make it possible for AS-RS to talk to AS-RO, bot= h >>>>>>>> in philosophy of the protocol design and in concrete hooks to supp= ort (6) >>>>>>>> above. >>>>>>>> >>>>>>>> Separately, we can approach the issue of making 1/2 above more >>>>>>>> dynamic. This was UMA2=E2=80=99s =E2=80=9Cfederated authorization= =E2=80=9D approach, and is behind >>>>>>>> a lot of the =E2=80=9Cbring your own AS=E2=80=9D models out there.= The problem with these >>>>>>>> is that we know from many years of experience that most RS=E2=80= =99s aren=E2=80=99t >>>>>>>> interested in doing anything of the sort. >>>>>>>> >>>>>>>> So with GNAP we can instead allow 4/5/6 to vary in a predictable >>>>>>>> and consistent way, letting the RS keep control over 1/2, thereby = enabling >>>>>>>> choice in (3). We don=E2=80=99t have to be the ones who define the= all of the >>>>>>>> details of every permutation of (5) to enable this, though. Some o= f this is >>>>>>>> going to be configuration out of band, some of it=E2=80=99s going = to be >>>>>>>> communication at runtime. This is where VC=E2=80=99s, ZCAPs, CHAPI= , DIDComm, FIDO, >>>>>>>> and a whole swath of other tech can come in and help out. I don=E2= =80=99t think we >>>>>>>> need to put all the details for using these into core, nor do I th= ink we=E2=80=99ll >>>>>>>> pull of The Great And Ultimate Abstraction for using these and oth= er >>>>>>>> approaches. But we can at least start talking about =E2=80=9CAS-RS= =E2=80=9D in such a way >>>>>>>> that it no longer assumes it=E2=80=99s always the same party deali= ng with the RO >>>>>>>> directly. >>>>>>>> >>>>>>>> =E2=80=94 Justin >>>>>>>> >>>>>>>> On Mar 25, 2021, at 6:40 AM, Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>> >>>>>>>> To reframe it closer to GNAP: >>>>>>>> - AS =3D AS-RO, that's where you find the RO policies. The AS issu= es >>>>>>>> access tokens to the client. >>>>>>>> - the RO policies could be a) defined locally or b) in relationshi= p >>>>>>>> with the RS >>>>>>>> >>>>>>>> There have been several ideas related to the AS-RS relationship b: >>>>>>>> b1) the RS issues capabilities (which can be further attenuated by >>>>>>>> the RO) >>>>>>>> b2) Adrian also discussed a DID based solution >>>>>>>> b3) there was also an alternative ACL proposal from Denis (+ >>>>>>>> preflight) >>>>>>>> >>>>>>>> Fabien >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>> >>>>>>>>> Ok so I get you correctly: >>>>>>>>> - what matters is the RQ (could be a RO or a end-user or both : w= e >>>>>>>>> don't really care at a high-level, they're all treated as entitie= s that >>>>>>>>> make a request) >>>>>>>>> - the policy is able to handle those different cases, based on it= s >>>>>>>>> own internal delegation protocol >>>>>>>>> - currently that requires AS-RS and AS-RO, but maybe it can be >>>>>>>>> simplified >>>>>>>>> >>>>>>>>> To answer to Denis, here's what I understood: >>>>>>>>> - RO trusts AS-RS (and then handles its own policies within AS-RO= ) >>>>>>>>> - end-user trusts AS-RO (through its client) >>>>>>>>> >>>>>>>>> Could probably work but that's a fairly different model compared >>>>>>>>> to OAuth2 (and of today's GNAP), with different frontiers between= the AS >>>>>>>>> and the RS. >>>>>>>>> >>>>>>>>> Please do not hesitate to correct me if I'm wrong. >>>>>>>>> >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper < >>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>> >>>>>>>>>> I believe there are alternatives to having two kinds of ASs. The >>>>>>>>>> problem may be a side-effect of deciding to switch away form tre= ating the >>>>>>>>>> RO as different from the RQ. That leads to downstream privacy is= sues. Our >>>>>>>>>> desire for architectural simplicity is admirable but that may ha= ve been a >>>>>>>>>> step too far. >>>>>>>>>> >>>>>>>>>> There may also be solutions based on different types of tokens, >>>>>>>>>> as in different capabilities (tokens signed by the RS) vs. token= s signed by >>>>>>>>>> the AS. I=E2=80=99m not sure about that but Alan might have more= to say. >>>>>>>>>> >>>>>>>>>> Adrian >>>>>>>>>> >>>>>>>>>> On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault < >>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Thanks. The general problem statement is clear. >>>>>>>>>>> >>>>>>>>>>> The proposed solution a bit less (to me). I understood that fro= m >>>>>>>>>>> point 2, Alan involves 2 ASs. You said : "There=E2=80=99s no ob= vious >>>>>>>>>>> reason to have two types of ASs". Do you see an alternative ? >>>>>>>>>>> >>>>>>>>>>> Regarding the last item, I don't think that naming RQ by >>>>>>>>>>> end-user created the problem. It might just highlight the asymm= etry, which >>>>>>>>>>> fundamentally exists. >>>>>>>>>>> >>>>>>>>>>> Fabien >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper < >>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Recap: >>>>>>>>>>>> 1 - Justin (I think) introduced the idea of an AS on the RS >>>>>>>>>>>> trust boundary side. >>>>>>>>>>>> 2 - I said the RO should not have to share policies with the R= S. >>>>>>>>>>>> 3 - Alan invented the concept of AS-RO and AS-RS to separate >>>>>>>>>>>> two kinds of PDPs. >>>>>>>>>>>> >>>>>>>>>>>> The thing is that step 2 is not symmetrical. The RO has a >>>>>>>>>>>> legitimate privacy interest in keeping their policies private = and >>>>>>>>>>>> minimizing the leakage of information about requests that are = posed against >>>>>>>>>>>> those policies. >>>>>>>>>>>> >>>>>>>>>>>> The RS, on the other hand, should be publishing its policies >>>>>>>>>>>> (e.g. what it=E2=80=99s selling or what jurisdiction it=E2=80= =99s in or what tokens or >>>>>>>>>>>> scopes it supports). The RS has no obvious privacy interest in= GNAP. It=E2=80=99s >>>>>>>>>>>> just an enforcer. >>>>>>>>>>>> >>>>>>>>>>>> There is one other privacy interest to consider around the RS >>>>>>>>>>>> and that is the requesting party (the end-user that is not the= RO :-) might >>>>>>>>>>>> prefer to share attributes with the RS instead of the RO or so= mething >>>>>>>>>>>> controlled by the RO. This case could be an =E2=80=9Cextension= =E2=80=9D to GNAP and might >>>>>>>>>>>> result in a split AS as a solution. This problem was introduce= d when the >>>>>>>>>>>> editors decided to replace RQ with end-user. Obviously, the RO= end-user has >>>>>>>>>>>> no privacy interests relative to itself. >>>>>>>>>>>> >>>>>>>>>>>> Adrian >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault < >>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I was referring to "By my definition, this model has two ASs >>>>>>>>>>>>> since both are processing requests into tokens". If there's n= o reason to >>>>>>>>>>>>> have 2 types of ASs, that's fine then. >>>>>>>>>>>>> But I'm a bit lost in where we stand with the idea. >>>>>>>>>>>>> >>>>>>>>>>>>> Could you recap? >>>>>>>>>>>>> >>>>>>>>>>>>> Fabien >>>>>>>>>>>>> >>>>>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper < >>>>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>>>> >>>>>>>>>>>>>> There=E2=80=99s no obvious reason to have two types of ASs. = Any AS >>>>>>>>>>>>>> that is executing the policies of the RS can look to GNAP li= ke the RS >>>>>>>>>>>>>> itself. Why would GNAP expose that interface to anyone? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault < >>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Note : I'm not sure that's a good idea, but having 2 types >>>>>>>>>>>>>>> of ASs is not that easy to grasp. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault < >>>>>>>>>>>>>>> fabien.imbault@gmail.com> a =C3=A9crit : >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The purpose of either handling policies locally or >>>>>>>>>>>>>>>> delegating them to the RO agent. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper < >>>>>>>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> What purpose would be served by GNAP splitting the AS int= o >>>>>>>>>>>>>>>>> two components? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault < >>>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Isn't the AS-RO a component of the AS? Same idea as the >>>>>>>>>>>>>>>>>> interact component, it functionnally belongs to the AS r= ole but could be >>>>>>>>>>>>>>>>>> deployed either as a monolith or as a separate component= ? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper < >>>>>>>>>>>>>>>>>> agropper@healthurl.com> a =C3=A9crit : >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Yes, but I would say it=E2=80=99s not the RO that wants= the >>>>>>>>>>>>>>>>>>> access token. It=E2=80=99s the RO that wants the client= making the request to get >>>>>>>>>>>>>>>>>>> an access token. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 11:22 PM Alan Karp < >>>>>>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Adrian Gropper wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> In this design, the AS is the AS-RS and the agent is >>>>>>>>>>>>>>>>>>>>> the AS-RO. By my definition, this model has two ASs s= ince both are >>>>>>>>>>>>>>>>>>>>> processing requests into tokens. The problem with thi= s is complexity and >>>>>>>>>>>>>>>>>>>>> privacy. The RO may not want to share the request inf= ormation with the >>>>>>>>>>>>>>>>>>>>> AS-RS. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> More precisely, RO has no choice but to present the >>>>>>>>>>>>>>>>>>>> required information to AS-RS if RO wants an access to= ken. However, RO >>>>>>>>>>>>>>>>>>>> does not want AS-RS to know the policy by which RO del= egates tokens. >>>>>>>>>>>>>>>>>>>> That's why RO uses AS-RO for those delegations. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper < >>>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thank you for creating the issue. My definition of AS >>>>>>>>>>>>>>>>>>>>> is independent of AS-RO or AS-RS. >>>>>>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/is= sues/223#issuecomment-806280421 >>>>>>>>>>>>>>>>>>>>> I also agree with Alan's definition based on delegati= on. An AS-RS would be >>>>>>>>>>>>>>>>>>>>> a delegate of the RS. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Based on that, I see it as obvious that the policy ha= s >>>>>>>>>>>>>>>>>>>>> to be accessible (defined locally?) in order for it t= o be run as the code >>>>>>>>>>>>>>>>>>>>> that turns a request into an access token. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> The only other possibility is that the request is >>>>>>>>>>>>>>>>>>>>> packaged by the AS and sent elsewhere (an agent) for = evaluation against >>>>>>>>>>>>>>>>>>>>> policy and a proto-token returned. In that case the A= S is acting as a proxy >>>>>>>>>>>>>>>>>>>>> and the PDP is elsewhere. I can imagine that an AS-RS= would behave this way >>>>>>>>>>>>>>>>>>>>> so that the proto-token could be turned into an acces= s token by the AS-RS. >>>>>>>>>>>>>>>>>>>>> Isn't this what Justin is proposing? In this design, = the AS is the AS-RS >>>>>>>>>>>>>>>>>>>>> and the agent is the AS-RO. By my definition, this mo= del has two ASs since >>>>>>>>>>>>>>>>>>>>> both are processing requests into tokens. The problem= with this is >>>>>>>>>>>>>>>>>>>>> complexity and privacy. The RO may not want to share = the request >>>>>>>>>>>>>>>>>>>>> information with the AS-RS. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault < >>>>>>>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Isn't that what the AS is supposed to be, only with >>>>>>>>>>>>>>>>>>>>>> the caveat that the policy is defined locally? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp < >>>>>>>>>>>>>>>>>>>>>> alanhkarp@gmail.com> a =C3=A9crit : >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> AS-RO is an AS that RO trusts to delegate RO's >>>>>>>>>>>>>>>>>>>>>>> access tokens according to RO's policies. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault < >>>>>>>>>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Hi Alan and Adrian, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I've created issue AS-RO policy delegation ( >>>>>>>>>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol= /issues/223) >>>>>>>>>>>>>>>>>>>>>>>> to capture your input. >>>>>>>>>>>>>>>>>>>>>>>> A first question that arises: can we give a >>>>>>>>>>>>>>>>>>>>>>>> definition to AS-RO? >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp < >>>>>>>>>>>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Fabien Imbault wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Yes, but in that flow, the token relationship >>>>>>>>>>>>>>>>>>>>>>>>>> between AS-RS and AS-RO is only secure if the to= kens issued by AS-RS are >>>>>>>>>>>>>>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Attenuated delegation is a requirement, but that >>>>>>>>>>>>>>>>>>>>>>>>> doesn't have to be done cryptographically. Token= exchange works just >>>>>>>>>>>>>>>>>>>>>>>>> fine. SPKI and zcap-ld are examples of the crypt= o approach, and we used >>>>>>>>>>>>>>>>>>>>>>>>> token exchange in the system for HP. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault < >>>>>>>>>>>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Yes, but in that flow, the token relationship >>>>>>>>>>>>>>>>>>>>>>>>>> between AS-RS and AS-RO is only secure if the to= kens issued by AS-RS are >>>>>>>>>>>>>>>>>>>>>>>>>> cryptographically attenuable in the first place. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp < >>>>>>>>>>>>>>>>>>>>>>>>>> alanhkarp@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Justin Richer wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> But with all that in mind, I think the key her= e >>>>>>>>>>>>>>>>>>>>>>>>>>>> is going to be looking at what the inputs to t= he AS are, and how those can >>>>>>>>>>>>>>>>>>>>>>>>>>>> be defined in an interoperable way for AS=E2= =80=99s that can accept them. I think >>>>>>>>>>>>>>>>>>>>>>>>>>>> there=E2=80=99s a lot of room for innovation a= nd flexibility here that doesn=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>>>>>> break the trust model or core use cases. If I = have an AS-RS set that won=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine inp= uts, then I can decide not to >>>>>>>>>>>>>>>>>>>>>>>>>>>> use that one. But this is a very different que= stion than saying the RS >>>>>>>>>>>>>>>>>>>>>>>>>>>> itself needs to accept my own AS =E2=80=94 and= we can=E2=80=99t keep conflating these two >>>>>>>>>>>>>>>>>>>>>>>>>>>> models. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> I agree. The point of having an AS-RO is to >>>>>>>>>>>>>>>>>>>>>>>>>>> allow RO to specify a policy for which of RO's = access tokens should be >>>>>>>>>>>>>>>>>>>>>>>>>>> delegated under what conditions. AS-RS should = not need to understand those >>>>>>>>>>>>>>>>>>>>>>>>>>> policies. The flow would be >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> - RO contacts AS-RS and gets one or more >>>>>>>>>>>>>>>>>>>>>>>>>>> access tokens. >>>>>>>>>>>>>>>>>>>>>>>>>>> - RO delegates one or more of those tokens, >>>>>>>>>>>>>>>>>>>>>>>>>>> potentially sub-scoped, to AS-RO. >>>>>>>>>>>>>>>>>>>>>>>>>>> - A different user contacts AS-RO to get a >>>>>>>>>>>>>>>>>>>>>>>>>>> potentially sub-scoped access token from AS-= RO. >>>>>>>>>>>>>>>>>>>>>>>>>>> - That user presents the access token >>>>>>>>>>>>>>>>>>>>>>>>>>> delegated by AS-RO when invoking the resourc= e. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> AS-RS only needs to verify that the delegation >>>>>>>>>>>>>>>>>>>>>>>>>>> chain is legitimate, e.g., no increase in scope= , and that it grants >>>>>>>>>>>>>>>>>>>>>>>>>>> permission for the request being made. AS-RS d= oes not need to understand >>>>>>>>>>>>>>>>>>>>>>>>>>> the policy behind granting the delegation by AS= -RO. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>>>>>>>> Alan Karp >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer = < >>>>>>>>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> I think this shows the problem with the >>>>>>>>>>>>>>>>>>>>>>>>>>>> terminology as it=E2=80=99s been applied in th= is conversation, which I=E2=80=99ve tried to >>>>>>>>>>>>>>>>>>>>>>>>>>>> shine light on before. What you and others are= calling the =E2=80=9CRS=E2=80=9D is really >>>>>>>>>>>>>>>>>>>>>>>>>>>> the =E2=80=9CAS and RS working together=E2=80= =9D =E2=80=94 everything to the right of the line. >>>>>>>>>>>>>>>>>>>>>>>>>>>> When Denis had brought up =E2=80=9Celiminating= the AS=E2=80=9D in another thread, what he=E2=80=99d >>>>>>>>>>>>>>>>>>>>>>>>>>>> really done is labeled everything to the right= of the line as the =E2=80=9CRS=E2=80=9D. Of >>>>>>>>>>>>>>>>>>>>>>>>>>>> course, the irony here is that everything to t= he right of the line used all >>>>>>>>>>>>>>>>>>>>>>>>>>>> be called the =E2=80=9CAS=E2=80=9D or simply = =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say >>>>>>>>>>>>>>>>>>>>>>>>>>>> below, I don=E2=80=99t want the client to have= visibility on what happens on that >>>>>>>>>>>>>>>>>>>>>>>>>>>> side. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Note well: The Google+ logo labeled =E2=80=9CI= dP=E2=80=9D in >>>>>>>>>>>>>>>>>>>>>>>>>>>> the diagram is not the AS, as far as GNAP is c= oncerned. It does not issue >>>>>>>>>>>>>>>>>>>>>>>>>>>> an access token that the RS will accept. The e= lements to the left of the >>>>>>>>>>>>>>>>>>>>>>>>>>>> line could be a lot of things, but they are NO= T the AS =E2=80=94 by definition. The >>>>>>>>>>>>>>>>>>>>>>>>>>>> client lives over on the left, but so do any e= xternal inputs to the AS. >>>>>>>>>>>>>>>>>>>>>>>>>>>> These could be policy inputs on behalf of the = RO, they could be >>>>>>>>>>>>>>>>>>>>>>>>>>>> presentation artifacts, they could be federate= d logins, they could be the >>>>>>>>>>>>>>>>>>>>>>>>>>>> output of policy decisions. How the AS comes t= o trust those things is up to >>>>>>>>>>>>>>>>>>>>>>>>>>>> the AS=E2=80=99s implementation. It=E2=80=99s = something we can talk about, but ultimately >>>>>>>>>>>>>>>>>>>>>>>>>>>> GNAP won=E2=80=99t be in any position to dicta= te because in practice some AS=E2=80=99s are >>>>>>>>>>>>>>>>>>>>>>>>>>>> simply going to internalize all policies and w= e will never successfully >>>>>>>>>>>>>>>>>>>>>>>>>>>> force those open. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> But with all that in mind, I think the key her= e >>>>>>>>>>>>>>>>>>>>>>>>>>>> is going to be looking at what the inputs to t= he AS are, and how those can >>>>>>>>>>>>>>>>>>>>>>>>>>>> be defined in an interoperable way for AS=E2= =80=99s that can accept them. I think >>>>>>>>>>>>>>>>>>>>>>>>>>>> there=E2=80=99s a lot of room for innovation a= nd flexibility here that doesn=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>>>>>> break the trust model or core use cases. If I = have an AS-RS set that won=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine inp= uts, then I can decide not to >>>>>>>>>>>>>>>>>>>>>>>>>>>> use that one. But this is a very different que= stion than saying the RS >>>>>>>>>>>>>>>>>>>>>>>>>>>> itself needs to accept my own AS =E2=80=94 and= we can=E2=80=99t keep conflating these two >>>>>>>>>>>>>>>>>>>>>>>>>>>> models. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> So to me, GNAP can support a Zero Trust >>>>>>>>>>>>>>>>>>>>>>>>>>>> Architecture by LEVERAGING the AS, not by subs= uming or eliminating it. It >>>>>>>>>>>>>>>>>>>>>>>>>>>> is in fact the AS, not the client and not the = RS, that will request and >>>>>>>>>>>>>>>>>>>>>>>>>>>> consume the results of a privacy-preserving ze= ro-trust policy query thing. >>>>>>>>>>>>>>>>>>>>>>>>>>>> Anything that happens downstream from that is = of little concern to the >>>>>>>>>>>>>>>>>>>>>>>>>>>> zero-trust components because, as you point ou= t, it=E2=80=99s on the =E2=80=9Cother side=E2=80=9D >>>>>>>>>>>>>>>>>>>>>>>>>>>> of the line. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> I think we got this basic component model >>>>>>>>>>>>>>>>>>>>>>>>>>>> pretty right in OAuth: the AS and RS and clien= t working together. Where >>>>>>>>>>>>>>>>>>>>>>>>>>>> OAuth misses the mark is the assumption that t= he user has to log in to the >>>>>>>>>>>>>>>>>>>>>>>>>>>> AS through a webpage and interact directly, th= ereby proving they=E2=80=99re the RO. >>>>>>>>>>>>>>>>>>>>>>>>>>>> It=E2=80=99s this latter space where I think w= e can both push innovation and also >>>>>>>>>>>>>>>>>>>>>>>>>>>> address the important and compelling use cases= like the ones you=E2=80=99re >>>>>>>>>>>>>>>>>>>>>>>>>>>> bringing. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper < >>>>>>>>>>>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> I'm sorry, Justin. As a Resource Owner, I look >>>>>>>>>>>>>>>>>>>>>>>>>>>> at the RS trust boundary (the dotted line in t= he diagram) as being the RS. >>>>>>>>>>>>>>>>>>>>>>>>>>>> I don't expect any visibility into what's goin= g on on the right. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> My problem with the framing you propose is tha= t >>>>>>>>>>>>>>>>>>>>>>>>>>>> requests are going to the RS (or the AS-RS) an= d I don't want to share my >>>>>>>>>>>>>>>>>>>>>>>>>>>> policies with the AS-RS. I want to keep the RS= and AS-RS as ignorant as >>>>>>>>>>>>>>>>>>>>>>>>>>>> possible. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer = < >>>>>>>>>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Adrian, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> What you=E2=80=99re discussing below, in term= s of >>>>>>>>>>>>>>>>>>>>>>>>>>>>> logging in to a site, is not approaching the = RS. You are in fact >>>>>>>>>>>>>>>>>>>>>>>>>>>>> approaching the client, and identifying both = the AS and RS to the client. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> The client is a client *of your identity* in >>>>>>>>>>>>>>>>>>>>>>>>>>>>> this model, and the RS is part of the identit= y provider. It=E2=80=99s really >>>>>>>>>>>>>>>>>>>>>>>>>>>>> important that we don=E2=80=99t conflate the = RS and client in this way as it leads >>>>>>>>>>>>>>>>>>>>>>>>>>>>> to a lot of confusion downstream and a lot of= broken trust boundaries. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> With that model in mind, approaching the =E2= =80=9CRS" >>>>>>>>>>>>>>>>>>>>>>>>>>>>> and providing it your identity is really just= a case of the =E2=80=9Cfederated >>>>>>>>>>>>>>>>>>>>>>>>>>>>> login to AS=E2=80=9D pattern that we discusse= d on the WG call. The user here >>>>>>>>>>>>>>>>>>>>>>>>>>>>> approaches an RS, which has its own AS. To sh= are things from this RS, the >>>>>>>>>>>>>>>>>>>>>>>>>>>>> RO has to authenticate to the RS=E2=80=99s AS= . This particular AS allows the RO to >>>>>>>>>>>>>>>>>>>>>>>>>>>>> do so using an external identity =E2=80=94 in= which case, the AS is now a =E2=80=9Cclient=E2=80=9D >>>>>>>>>>>>>>>>>>>>>>>>>>>>> of a separate, disconnected (but layered) del= egation. The ultimate client >>>>>>>>>>>>>>>>>>>>>>>>>>>>> that eventually calls the RS down the way may= or may not know about these >>>>>>>>>>>>>>>>>>>>>>>>>>>>> layers. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> This same AS, which is closely tied to the RS >>>>>>>>>>>>>>>>>>>>>>>>>>>>> and trusted by the RS, might also take in FID= O credentials, or DIDs, or any >>>>>>>>>>>>>>>>>>>>>>>>>>>>> number of other proof mechanisms. The output = of this is an access token the >>>>>>>>>>>>>>>>>>>>>>>>>>>>> RS trusts, but the input is up to the AS. The= RS is not what you=E2=80=99re logging >>>>>>>>>>>>>>>>>>>>>>>>>>>>> in to. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper < >>>>>>>>>>>>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> I too am in favor of avoiding consolidation >>>>>>>>>>>>>>>>>>>>>>>>>>>>> and correlation. Right now, when I approach a= service provider (RS) for the >>>>>>>>>>>>>>>>>>>>>>>>>>>>> first time, I'm offered the opportunity to id= entify my persona as: email, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> sign-in with Google, Facebook, or Apple. I kn= ow there are people who try to >>>>>>>>>>>>>>>>>>>>>>>>>>>>> create one-off email addresses but that is mo= stly a waste of time. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> So, along come FIDO2 and DID wallets to the >>>>>>>>>>>>>>>>>>>>>>>>>>>>> rescue. Now, in theory, I have a way to start= out my RS relationship >>>>>>>>>>>>>>>>>>>>>>>>>>>>> pseudonymously. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> When I want my resource to be discovered or >>>>>>>>>>>>>>>>>>>>>>>>>>>>> shared I will post that RS URL including my p= seudonym. If I then want to >>>>>>>>>>>>>>>>>>>>>>>>>>>>> introduce a mediator in front of my AS or mes= saging service endpoint, I >>>>>>>>>>>>>>>>>>>>>>>>>>>>> have that option. If I want to keep requests = away from the mediator, I >>>>>>>>>>>>>>>>>>>>>>>>>>>>> would publish an encryption key along with my= pseudonym. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> - Adrian >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer= < >>>>>>>>>>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk = < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> kaduk@mit.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Adrian Gropper wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> @Alan Karp shared a >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> talk about the Principle Of Least >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> Authority (POLA) in a recent comment >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-pr= otocol/issues/145#issuecomment-803099693 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> I recommend it. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> We might expect a protocol with >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> authorization in the title to use authority >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> as a core principle. I advocate for a GNA= P >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> design that maximizes the power >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> of the RO, to be seen as a human rights >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> issue when the RO is a human. This >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> causes me to ask how to combine better >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> security with better human rights in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> GNAP. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> Who should have the least authority in th= e >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> GNAP design? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> The AS derives authority as a delegate of >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the RO. If we ask the RO to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> partition limited authority across dozens >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of different ASs by domain and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> function, then we are not using technolog= y >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to empower the individual. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> Probably the opposite, as we introduce >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> consent fatigue and burden normal >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> people to partition their lives into >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-overlapping domains. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> My experience says we should aim for one >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AS per persona because that maps >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> into the way we manage our public and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> private identities. POLA would then >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> teach care in keeping ASs and RSs related >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to work / public separate from >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> ASs and RSs related to private life so >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that a policy vulnerability in our >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> delegation to an AS would have the least >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> likelihood of harm. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Thinking about how least authority/least >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> privilege would apply to GNAP >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > seems like a useful exercise. I do want t= o >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> point out some potential >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > pitfalls with one-AS-per-persona that we >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can also be aware of. If >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > one-AS-per-persona becomes >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> one-persona-per-AS as well, then the AS's >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > identity in effect also serves as a person= a >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> identity and there are privacy >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > considerations to that. If, on the other >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> hand, the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > multiple-personas-per-AS (presumably >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> corresponding to multiple humans) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > route is taken, we should consider whether >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that would lead to various >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > (e.g., market) forces driving consolidatio= n >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to just a handful of >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > super-popular AS services. That topic is = a >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> current matter of concern to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > some IETF participants. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Ben, big +1 to this. This is something >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that we discussed ages ago in the UMA workin= g group, and it=E2=80=99s one of the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> biggest problems with the personal AS (and p= ersonal data store) model. This >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> kind of thing makes RS-first trust models re= ally difficult in practice. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> As a strawman, let=E2=80=99s say that I=E2= =80=99ve got >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> software that wants to access my medical inf= ormation. It calls an RS and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> requests access, but it hasn=E2=80=99t been = granted anything yet. Now I as the RO >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> have set up the RS so that it talks to my pe= rsonal AS, that only I use. In >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> addition to the RS having to be able to figu= re out which medical records >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are being requested from the context of the = unauthenticated request (which >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> means it needs identifiers in the URL or som= ething similar for the RS to be >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> able to tell, assuming that it protects data= for more than one person). So >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this client software doesn=E2=80=99t know wh= o I am and doesn=E2=80=99t know my medical >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> record information, makes a completely unaut= horized request to the RS, and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the RS says =E2=80=9CGo to Justin=E2=80=99s = personal AS to get a token=E2=80=9D. The client can now >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> make a direct correlation between the data t= hat=E2=80=99s being protected at the RS >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and the person running the AS that protects = it. Importantly, this client >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> makes this call with no prior relationship t= o the RS and no really >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> auditable way to track it down after the fac= t. This is a design feature in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the good case, and terrifying in the bad cas= e. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If the RS instead says =E2=80=9Cwelcome to M= edicine >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Doctor RS, please talk to the Medicine Docto= r AS to get access=E2=80=9D, we haven=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> exposed anything at all. And from the perspe= ctive of both the patient and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the RS, this is more privacy-preserving, and= it=E2=80=99s really the least >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> surprising option. Once the client gets to t= he AS, it can start a >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> negotiation of figuring out who the RO is fo= r the information being >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> accessed. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On top of this, the usability expectations o= f >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> people managing their own AS, or set of AS= =E2=80=99s for multiple personas to keep >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> things separate, is a huge burden. Even in t= he tech community, I know >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> people who can=E2=80=99t reliably manage mor= e than one email address for different >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> purposes. I wouldn=E2=80=99t expect my partn= er to do that =E2=80=94 they have trouble >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> enough balancing all the logins and sessions= required for different kids >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> remote schooling, I couldn=E2=80=99t imagine= them having to understand all the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> requirements for managing multiple authoriza= tion servers and associated >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> policies. I also don=E2=80=99t expect any pe= rson to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve been on >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the internet for decades and I can barely ke= ep tabs on my GPG keys, and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> only use them when I am forced to. This is e= xactly the kind of =E2=80=9Cmarket >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pressure=E2=80=9D that I think Ben mentions = above, people will just want to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> outsource that to someone else, and the real= ity will be a few popular >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> providers. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In which case, we could end up doing a ton o= f >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> work to allow an RS choice only to end up wi= th a world where the RS ends up >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> making a limited choice anyway. We see how t= hat plays out with OpenID >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Connect =E2=80=94 RP=E2=80=99s could allow a= rbitrary IdPs but they choose Google because it >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> works and that=E2=80=99s where the users are= . (And that=E2=80=99s not to say anything of >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the proprietary OIDC-like protocols, but tha= t=E2=80=99s another discussion). >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> For further reading on these topics, I >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> recommend both =E2=80=9CWhy Johnny Can=E2=80= =99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So what does this have to do with GNAP? I >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> think we can be clear-eyed on what kinds of = expectations we have for the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> participants. If we expect users (RO=E2=80= =99s) to have to set up the AS-RS >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> relationship, or expect them to carry their = AS, or manage their personal >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> keys =E2=80=94 I think we=E2=80=99ve lost th= e battle for relevance. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>> >>>>> >>>> >>> --000000000000612ee105be7290c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    @Alan - The recent conversation between Justin and I does = not use the AS-RS / AS-RO framing. For now, we're trying to figure out = what is core to GNAP and what is optional.

    - Adrian<= /div>

    On Fri, Mar 26, 2021 at 11:35 AM Alan Karp <alanhkarp@gmail.com> wrote:
    = =C2=A0Adrian Gropper <agropper@healthurl.com> wrote:
    Good. I agree with the externalizing framing you use. To= me, they are a pair. They represent the separation of concerns I=E2=80=99m= focused on. The AS has policies, gets requests from clients, and returns a= ccess tokens.=C2=A0

    I thought you also want RO to be able to delegate t= o a client without AS-RS knowing what policy was used for that delegation.= =C2=A0 That's the function of AS-RO.=C2=A0 The client asks AS-RO for so= me permissions.=C2=A0 AS-RO either does a token exchange with AS-RS or give= s the client something to present to AS-RS to get a new access token.=C2=A0= Introducing AS-RO also allows RO to express policies that AS-RS may not su= pport, such as break glass.

    --------------
    Ala= n Karp


    On Fri, Mar 26, 2021 at 8:26 AM Adrian Gropper <agropper@healthur= l.com> wrote:
    Good. I ag= ree with the externalizing framing you use. To me, they are a pair. They re= present the separation of concerns I=E2=80=99m focused on. The AS has polic= ies, gets requests from clients, and returns access tokens.=C2=A0

    So what are we disagreeing about?=

    - Adrian

    =
    On Fri, Ma= r 26, 2021 at 10:38 AM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    Yes, the RO is the party/entity which hold= s the rights for delegation, and they perform that delegation to a piece of= software (the client) through the AS. The RS is what they=E2=80=99re deleg= ating the access of, for API-access use cases (again, user/subject informat= ion is similar but different).=C2=A0

    There isn=E2= =80=99t a delegation between the RS and AS, then. You can perhaps view them= as externalizing functions that they might otherwise hold close, but not d= elegating in the same way the client gets delegated to. You can frame it on= e of two ways:

    =C2=A0- The RS externalizes its sec= urity, policy, authorization, and delegation functions to the AS and looks = for access tokens from the AS as proof of that happening (this is the most = in line with the model you=E2=80=99ve been presenting)
    =C2=A0- Th= e AS externalizes its data-API functions to into the RS and produces access= tokens for the RS to consume/validate (this is actually the model that OAu= th 2 started with, in extracting the RS as a separate entity as opposed to = OAuth 1)

    They tell different views of the same rea= lity. In OAuth, it=E2=80=99s assumed that the RO interacts with the AS dire= ctly to perform the delegation to the client. In GNAP, we=E2=80=99ve got an= opportunity to expand that, which has been (to me) one of the biggest outc= omes of this discussion.

    =C2=A0=E2=80= =94 Justin

    On Mar 26, 2021, at 1= 0:04 AM, Adrian Gropper <agropper@healthurl.com> wrote:

    Justin,=C2=A0

    = Big YES to =E2=80=9C The conceptual framework of an AS that takes in lots o= f different information and spits out access tokens is exactly the abstract= ion layer that is necessary for making these use cases interoperable.=E2=80= =9D and probably everything else you just said.=C2=A0

    I seem to not understand the delegation desig= n between RS and AS. In my view, that delegation always goes through the RO= , although the RO may be forced to choose from a list provided by the RS.

    In my view, GNAP, can ack= nowledge this and design to be agnostic to whether the AS is specified by h= e RO or picked from a list of 1 or more choices provided by the RS.

    - Adrian

    On Fri, Mar 26, 20= 21 at 9:30 AM Justin Richer <jricher@mit.edu> wrote:
    A= drian,

    I disagree, I believe that what I have laid out i= s exactly separating the concerns into working components.=C2=A0
    =
    Like OAuth before it, GNAP is a protocol negotiate access fo= r a client instance to an RS, using an AS as the facilitator of that delega= ted negotiation. (Unlike OAuth, it=E2=80=99s importantly also for negotiati= ng user information to the client directly from the AS with no RS involved,= but that=E2=80=99s an aside for the purposes of our conversation here).

    If a particular GNAP RS also allows other kinds of p= rocesses to enable access to it, that is completely fine, but outside of GN= AP. If an RS allows a username/password HTTP Basic auth in addition to acce= pting access tokens, it can do so, but GNAP doesn=E2=80=99t have anything t= o say about the Basic auth use, or even its relation to any access tokens o= r RO=E2=80=99s or anything else. If an RS accepts structured access tokens = signed by trusted keys that don=E2=80=99t come from an AS through a negotia= ted request =E2=80=94 again, that=E2=80=99s fine, but GNAP is silent about = the RS doing that. If the RS acts as =E2=80=9Cits own AS=E2=80=9D then it= =E2=80=99s really just an RS and an AS living in the same box. Again, that= =E2=80=99s fine, and super common with OAuth today.=C2=A0

    GNAP is solving the problem of connecting the client to the RS thro= ugh means of an AS. Other solutions are possible and many of them can be de= ployed right alongside, but that=E2=80=99s not the corner of the world that= GNAP is solving. GNAP should be concerned about how these other technologi= es can be used alongside it. I think there=E2=80=99s a lot of room for the = things that you=E2=80=99re talking about, and more importantly for solving = the use cases that you=E2=80=99re bringing. But GNAP should be more than a = single-point solution, and so we need to balance these concerns. The concep= tual framework of an AS that takes in lots of different information and spi= ts out access tokens is exactly the abstraction layer that is necessary for= making these use cases interoperable.

    = =C2=A0=E2=80=94 Justin

    On Mar 26= , 2021, at 8:30 AM, Adrian Gropper <agropper@healthurl.com> wrote:

    @Justin, there=E2=80=99s no separation of concerns here.= No partition between processor and controller. No data minimization. And, = I see no obvious reason to make this the core of GNAP.=C2=A0

    The one thing we can probably all agr= ee on is that there=E2=80=99s only one RS and one RO.=C2=A0

    The core of GNAP, in my=C2=A0opinion,= can be built and explained around this simple design. The RS is a processo= r. The RO is a controller. The RS bears only security responsibility. The R= S bears no privacy responsibility. The RO delegates this to the RS but this= is not authorization as the A in GNAP.

    The RO retains all rights to delegate within the scope of t= hings that the RS is willing to support using various token formats and end= point options. Some of these options may do all sorts of things for all sor= ts of clients and user-agents =C2=A0but these are options.=C2=A0

    For example, if a request comes to= the RS that is not in the form of an access token, then it either gets sen= t to the RO or their agent, or it gets logged and dumped. One such option, = common in healthcare, is =E2=80=9CBreak the Glass=E2=80=9D where the RS is = acting as an authorization server because the user-agent is making a reques= t instead of presenting an access token. GNAP can offer this as an option b= ut it is not our core.

    A= drian


    On Fri, M= ar 26, 2021 at 7:15 AM Justin Richer <jricher@mit.edu> wrote:
    I have a big problem with this line:

    &g= t;=C2=A0the RS and AS-RS only = see access tokens. The requests (from RO') that resulted in an access t= oken are none of their business.

    In the trust mo= del we=E2=80=99ve been discussing, the requests that result in access token= s are solely the business of AS-RS, since AS-RS is the only entity t= hat=E2=80=99s allowed, and trusted by the RS, to create access tokens for t= he RS. That is its entire job, the entire reason it exists in the system. B= y definition the party generating tokens for use at the RS is the AS for th= at RS, I don=E2=80=99t care how you deploy it. If RO wants to give access t= o someone else (who isn=E2=80=99t an =E2=80=9CRO" anymore, they=E2=80= =99re another end-user), then that end user=E2=80=99s client software will = need to talk to AS-RS to get its own access token.

    Now h= ere=E2=80=99s the trick: when the end user=E2=80=99s client instance talks = to AS-RS, that does NOT mean that AS-RS needs to know all the details and p= olicy reasons that it should give an access token to that client instance. = It doesn=E2=80=99t even need to know the existence of another end user. It = doesn=E2=80=99t need identity, it doesn=E2=80=99t need policy. Sure, it COU= LD handle all of that internally, and many will, but the protocol doesn=E2= =80=99t demand it.=C2=A0

    This means that the first= client instance, the one that gets the access token, can also be given som= ething alongside the access token that it can then hand to another piece of= software (or to a person to hand eo their piece of software). This artifac= t is not an access token. This artifact could be something structured that = the client understands, and can make derivatives of, and present back to th= e AS-RS for getting new access tokens. There could be multiple different fl= avors of this kind of artifact for different kinds of environments and grou= ps. But what they all have in common is that they can potentially be used t= o request more access tokens within some context at the AS-RS.
    <= div>

    =C2=A0=E2=80=94 Justin



    On Mar 25, 2021, at 5:50 PM, = Adrian Gropper <agropper@healthurl.com> wrote:

    My issue is with Alan's:
    "7. Another user= agent (RO') can contact any holder of the access token or the service&= #39;s policy agent (AS-RS) to get a delegated access token."

    I would prefer "7A.=C2=A0Another user agent (RO') can contact any holder of the a= ccess token." by default so that the AS-RS does not see the requests. = In other words, the RS and AS-RS only see access tokens. The requests (from= RO') that resulted in an access token are none of their business.

    The reality is th= at RO' can discover a resource RS and can share whatever information wi= th RS-AS they want and the RO may not even know about it unless the RS deci= des to let them know somehow. This seems to be a drawback of the capabiliti= es approach.=C2=A0

    In terms of privacy and control, I, as the RO, want a contract=C2=A0w= ith the RS that says that I or my agent (AS-RO) must sign an access token. = This is a fundamental audit requirement. Without it, a rogue RS and AS-RS c= an do all sorts of things and the RO would never know. I understand that a = rogue RS might not support an honest contemporaneous log of access tokens p= resented so there's a trust issue here that I seems unavoidable unless = I specify in my RO-RS contract that they use a separate contemporaneous=C2= =A0log such as AS-RO for every access token presented and risk being sued i= f they process an access token without also updating the separate log.

    - Adrian


    On Thu, Mar 25, 2021 at 1:22 PM Alan Karp &= lt;alanhkarp@gmail= .com> wrote:
    Justin Richer <jricher@mit.edu> wrote:
    Hi Alan,

    In all of my discussi= on, and in the spec itself, the RO is the :entity: in charge of approving r= ights. They=E2=80=99re probably a person. It might be software that makes a= policy decision in some way, or a corporate entity, or something like that= . But it=E2=80=99s not assumed to be a computational agent in the terms of = the protocol itself. Would that recast what you=E2=80=99re saying below?


    On Thu, Mar 25, 2021 at 9:53 AM Ju= stin Richer <jriche= r@mit.edu> wrote:
    Hi Alan,

    =
    In all of my discussion, and in the spec itself, the RO is the := entity: in charge of approving rights. They=E2=80=99re probably a person. I= t might be software that makes a policy decision in some way, or a corporat= e entity, or something like that. But it=E2=80=99s not assumed to be a comp= utational agent in the terms of the protocol itself. Would that recast what= you=E2=80=99re saying below?

    =C2=A0=E2=80=94 Just= in

    On Mar 25, 2021, at 12:36 PM,= Alan Karp <ala= nhkarp@gmail.com> wrote:

    There seems = to be some confusion about how AS-RO comes into the picture, probably becau= se of the "AS" part.=C2=A0 I'm going to try to clear up that = confusion by more carefully explaining what I mean.

    I'm as= suming that RO is a computational agent representing the person who is the = resource owner, something called the "user agent" in operating sy= stems lingo.=C2=A0 I'm also assuming that it's possible to do deleg= ation, either locally or by token exchange with AS-RS.=C2=A0 All delegation= s are potentially sub-scoped, but you may also want to delegate with full s= cope to have a separately revocable access token.

    = =C2=A0 Here's an example of how things work in a capability oriented sy= stem.
    1. Someone, the service owner, creates a service.<= /li>
    2. The service owner contracts with an policy agent (AS-RS) to create = and manage access tokens for that service (RS).
    3. A person wishing to= create a resource at RS uses their user agent (RO) to contact the service = owner's policy agent (AS-RS) and gets back an access token for that res= ource.
    4. That user agent (RO) can=C2=A0
      1. use that access t= oken to invoke the resource, or
      2. delegate an access token to a clien= t of the user agent's (RO) choice, or
      3. contract with a policy ag= ent (AS-RO) to manage those delegations on behalf of the user agent (RO), o= r
      4. specify a policy with the service's policy agent (AS-RS).
    5. A client can contact any holder of the access token (the user age= nt (RO) or its policy agent (AS-RO)) or the service's policy agent (AS-= RS) to get a delegated access token.
    6. That client can delegate that = token to another client.
    7. Another user agent (RO') can contact a= ny holder of the access token or the service's policy agent (AS-RS) to = get a delegated access token.
    8. The other user agent (RO') can=C2= =A0
      1. use that access token to invoke the resource, or
      2. de= legate it to a client of its choice, or
      3. contract with a policy agen= t (AS-RO') of its choosing to manage those delegations on its behalf, = or
      4. specify a policy with the service's policy agent (AS-RS).
    9. and so on
    When any of these comput= ational agents, user agents (ROs) or clients acting on their behalf, invoke= s the resource, AS-RS verifies that the access token is a valid delegation,= i.e., proper sub-scoping, hasn't been revoked, and that it authorizes = the request being made before telling the service (RS) to honor the request= .=C2=A0 At no point does the service's policy agent (AS-RS) know which = computational agent did any particular delegation.=C2=A0 (Token exchange ca= n be done as anonymously as possible.)=C2=A0 In particular, the policy agen= ts (AS-RO) need not be the same, or even compatible with, the service's= policy agent (AS-RS).=C2=A0 GNAP specifies the protocol between requesters= , invokers, delegators (for token exchange) of tokens and AS-RS.=C2=A0 That= protocol need not be used between user agents (RO), clients, or other poli= cy agents (AS-RO), but it is likely to be.

    =C2=A0-= ------------
    Alan Karp


    On Thu, Mar 25, 2021 at 5:45 AM Justin Richer <jricher@mit.edu> wrote:
    The way I=E2=80=99m thinking about Adrian=E2=80=99s use cas= e is that what we=E2=80=99re calling the =E2=80=9CAS-RO=E2=80=9D isn=E2=80= =99t an =E2=80=9CAS=E2=80=9D in the traditional OAuth/GNAP sense, at least = not exactly. This is the agent that the RO can use to set policies and mana= ge consent on their behalf, and I=E2=80=99ve been arguing that it fits bett= er into this vaguely-defined =E2=80=9Cinteraction component=E2=80=9D aspect= of the current AS definition, and it=E2=80=99s not currently separated fro= m the AS definition. The =E2=80=9CAS-RS=E2=80=9D maps to what we=E2=80=99d = call the =E2=80=9CAS=E2=80=9D in OAuth/GNAP traditionally, it=E2=80=99s wha= t the RS trusts to issue tokens. In traditional OAuth the AS-RO and AS-RS a= re always the same thing, from a functional protocol perspective. An import= ant point here is that from a client=E2=80=99s perspective, they=E2=80=99re= only talking to the AS-RS since that=E2=80=99s where the client gets its t= okens, because at the end of the day the client just wants to call the API = at the RS and doesn=E2=80=99t care how that happens (from a protocol standp= oint).=C2=A0

    Note well: Even thought I don=E2=80=99t bel= ieve that =E2=80=9CAS-RO=E2=80=9D is an authorization server at all, I=E2= =80=99m going to keep using that term below for consistency with previous d= iscussion.

    So we have these fundamental relationsh= ips around getting the client to access the RS:

    1.= RS trusts=C2=A0AS-RS=C2=A0to issue tokens that RS will accept, validate, a= nd process for requests from client
    2. Client trusts=C2=A0AS-RS= =C2=A0to issue tokens that client can use at RS
    3. RO trusts RS t= o protect RO=E2=80=99s api through delegated access

    On top of that, we=E2=80=99ve got some additional aspects that we=E2=80= =99re discussing:

    4. RO trusts=C2=A0AS-RO=C2=A0to = manage RO=E2=80=99s policies at runtime
    5.=C2=A0AS-RS=C2=A0trusts= =C2=A0AS-RO=C2=A0to assert RO=E2=80=99s policies for access to RS
    6. Client trusts whatever=C2=A0AS-RS=C2=A0sends client to deal with, inclu= ding possibly RO-AS at runtime, because of (2)

    Wha= t I have been saying is that 4/5/6 are optional details of how RS-AS runs t= hings, and I think this also maps with Adrian=E2=80=99s view of choice, sin= ce if my RS=E2=80=99s AS-RS doesn=E2=80=99t allow me to plug in my own AS-R= O then I would be motivated to pick a different RS who=E2=80=99s AS-RS lets= me do just that. The same way I=E2=80=99d pick a different RS if their sur= rounding services didn=E2=80=99t accept my preferred federation login and I= didn=E2=80=99t want to make another account. Of course, market forces bein= g as they are, I might not have much of an actionable choice in RS, but GNA= P can=E2=80=99t change that.=C2=A0

    What we can do = is make it possible for AS-RS to talk to AS-RO, both in philosophy of the p= rotocol design and in concrete hooks to support (6) above.=C2=A0
    =
    Separately, we can approach the issue of making 1/2 above mo= re dynamic. This was UMA2=E2=80=99s =E2=80=9Cfederated authorization=E2=80= =9D approach, and is behind a lot of the =E2=80=9Cbring your own AS=E2=80= =9D models out there. The problem with these is that we know from many year= s of experience that most RS=E2=80=99s aren=E2=80=99t interested in doing a= nything of the sort.

    So with GNAP we can instead a= llow 4/5/6 to vary in a predictable and consistent way, letting the RS keep= control over 1/2, thereby enabling choice in (3). We don=E2=80=99t have to= be the ones who define the all of the details of every permutation of (5) = to enable this, though. Some of this is going to be configuration out of ba= nd, some of it=E2=80=99s going to be communication at runtime. This is wher= e VC=E2=80=99s, ZCAPs, CHAPI, DIDComm, FIDO, and a whole swath of other tec= h can come in and help out. I don=E2=80=99t think we need to put all the de= tails for using these into core, nor do I think we=E2=80=99ll pull of The G= reat And Ultimate Abstraction for using these and other approaches. But we = can at least start talking about =E2=80=9CAS-RS=E2=80=9D in such a way that= it no longer assumes it=E2=80=99s always the same party dealing with the R= O directly.

    =C2=A0=E2=80=94 Justin

    On Mar 25, 2021, at 6:40 AM, Fabien Imbault <<= a href=3D"mailto:fabien.imbault@gmail.com" target=3D"_blank">fabien.imbault= @gmail.com> wrote:

    To reframe it clos= er to GNAP:
    - AS =3D AS-RO, that's where you find the RO policies. = The AS issues access tokens to the client.
    - the RO policies coul= d be a) defined locally or b) in relationship with the RS

    There have been several ideas related to the AS-RS relationship b:<= br>
    b1) the RS issues capabilities (which can be further attenuat= ed by the RO)
    b2) Adrian also discussed a DID based solution
    b3) there was also an alternative ACL proposal from Denis (+ prefligh= t)

    Fabien


    On Thu, Mar 25, 2021= at 9:44 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Ok so I get you correctly:=C2=A0
    - what matte= rs is the RQ (could be a RO or a end-user or both : we don't really car= e at a high-level, they're all treated as entities that make a request)=
    - the policy is able to handle those different cases, based on i= ts own internal delegation protocol
    - currently that requires AS-= RS and AS-RO, but maybe it can be simplified

    To an= swer to Denis, here's what I understood:
    - RO trusts AS-RS (a= nd then handles its own policies within AS-RO)
    - end-user tru= sts AS-RO (through its client)

    Could probably work= but that's a fairly different model compared to OAuth2 (and of today&#= 39;s GNAP), with different frontiers between the AS and the RS.=C2=A0
    =

    Please do not hesitate to correct me if I'm wrong.<= /div>

    Fabien=C2=A0

    On Thu, Mar 25, 2021 at 9:26 AM = Adrian Gropper <agropper@healthurl.com> wrote:
    I believe there are alternatives to having two kinds of ASs. The= problem may be a side-effect of deciding to switch away form treating the = RO as different from the RQ. That leads to downstream privacy issues. Our d= esire for architectural simplicity is admirable but that may have been a st= ep too far.

    There may al= so be solutions based on different types of tokens, as in different capabil= ities (tokens signed by the RS) vs. tokens signed by the AS. I=E2=80=99m no= t sure about that but Alan might have more to say.
    <= br>
    Adrian

    =
    On Thu, Mar 25, 2021 at 4:15 AM Fabie= n Imbault <fabien.imbault@gmail.com> wrote:
    Thanks. The general problem statement is clear.

    The=C2=A0proposed solution a bit less (to me). I understood that from poin= t 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obvious reason to have two types of ASs".=C2=A0<= /span>Do you see an alternative ?

    Regarding = the last item, I don't think that naming RQ by end-user created the pro= blem. It might just highlight the asymmetry,=C2=A0which fundamentally exist= s.=C2=A0

    Fabien


    On Thu, Mar 25, 2021 at 8:48 AM A= drian Gropper <agropper@healthurl.com> wrote:
    Recap:
    1 - Justin (I think) introduced the= idea of an AS on the RS trust boundary side.
    2 - I = said the RO should not have to share policies with the RS.
    3 - Alan invented the concept of AS-RO and AS-RS to separate two kin= ds of PDPs.=C2=A0

    The th= ing is that step 2 is not symmetrical. The RO has a legitimate privacy inte= rest in keeping their policies private and minimizing the leakage of inform= ation about requests that are posed against those policies.=C2=A0

    The RS, on the other hand, should= be publishing its policies (e.g. what it=E2=80=99s selling or what jurisdi= ction it=E2=80=99s in or what tokens or scopes it supports). The RS has no = obvious privacy interest in GNAP. It=E2=80=99s just an enforcer.

    There is one other privacy interes= t to consider around the RS and that is the requesting party (the end-user = that is not the RO :-) might prefer to share attributes with the RS instead= of the RO or something controlled by the RO. This case could be an =E2=80= =9Cextension=E2=80=9D to GNAP and might result in a split AS as a solution.= This problem was introduced when the editors decided to replace RQ with en= d-user. Obviously, the RO end-user has no privacy interests relative to its= elf.

    Adrian




    On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault <fabien.imbault@gmail.com> wro= te:
    I was referring to &qu= ot;By my definition, this model has = two ASs since both are processing requests into tokens". If there'= s no reason to have 2 types of ASs, that's fine then.=C2=A0
    But I'm a bit lost in where we stand with the idea.=C2=A0

    Could you recap?=C2=A0

    Fabien=C2=A0

    Le jeu. 25 mars 2= 021 =C3=A0 08:16, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    There=E2=80=99s no obvious reason= to have two types of ASs. Any AS that is executing the policies of the RS = can look to GNAP like the RS itself. Why would GNAP expose that interface t= o anyone?=C2=A0

    Adrian

    On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault <fabien.imbault@= gmail.com> wrote:
    Note= : I'm not sure that's a good idea, but having 2 types of ASs is no= t that easy to grasp.

    Fabien=C2=A0

    Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien= Imbault <fabien.imbault@gmail.com> a =C3=A9crit=C2=A0:
    =
    The purpose of either handling pol= icies locally or delegating them to the RO agent.=C2=A0

    Le jeu. 25 mars 2021= =C3=A0 08:04, Adrian Gropper <agropper@healthurl.com= > a =C3=A9crit=C2=A0:
    What= purpose would be served by GNAP splitting the AS into two components?

    Adrian=C2=A0

    On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Isn't the AS-RO a component of the AS? Sa= me idea as the interact component, it functionnally belongs to the AS role = but could be deployed either as a monolith or as a separate component?

    Fabien

    Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
    Yes, but I would say it=E2=80=99s not the RO tha= t wants the access token. It=E2=80=99s the RO that wants the client making = the request to get an access token.=C2=A0

    =
    Adrian

    On Wed, Mar 24, 2021 at 11:22 PM Alan Karp &l= t;alanhkarp@gmail.com> wrote:
    <= /div>
    Adrian Gropper <= agropper@healthurl.com> wrote:

    In this design, the AS is the AS-RS a= nd the agent is the AS-RO. By my definition, this model has two ASs since b= oth are processing requests into tokens. The problem with this is complexit= y and privacy. The RO may not want to share the request information with th= e AS-RS.

    More precisely, RO has no choice but to present the required informat= ion to AS-RS if RO wants an access token.=C2=A0 However, RO does not want A= S-RS to know the policy by which RO delegates tokens.=C2=A0 That's why = RO uses AS-RO for those delegations.

    ------------= --
    Alan Karp


    On Wed, Mar 24, 2021= at 7:41 PM Adrian Gropper <agroppe= r@healthurl.com> wrote:
    <= div dir=3D"ltr">Thank you for creating the issue. My definition of AS is in= dependent of AS-RO or AS-RS.=C2=A0https://github.com/ietf-= wg-gnap/gnap-core-protocol/issues/223#issuecomment-806280421 I also agr= ee with Alan's definition based on delegation. An AS-RS would be a dele= gate of the RS.=C2=A0

    Based on that, I= see it as obvious=C2=A0that the policy has to be accessible (defined local= ly?) in order for it to be run as the code that turns a request into an acc= ess token.=C2=A0

    The only other possibility is tha= t the request is packaged by the AS and sent elsewhere (an agent) for evalu= ation against policy and a proto-token returned. In that case the AS is act= ing as a proxy and the PDP is elsewhere. I can imagine that an AS-RS would = behave this way so that the proto-token could be turned into an access toke= n by the AS-RS. Isn't this what Justin is proposing? In this design, th= e AS is the AS-RS and the agent is the AS-RO. By my definition, this model = has two ASs since both are processing requests into tokens. The problem wit= h this is complexity and privacy. The RO may not want to share the request = information with the AS-RS.

    Adrian

    =
    On Wed, Ma= r 24, 2021 at 5:21 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Isn't that what the AS is supposed to be, only with = the caveat that the policy is defined locally?=C2=A0

    <= /div>
    Fabien=C2=A0


    Le mer. 24 mars 2021 =C3=A0 20:17, A= lan Karp <alanhkarp@gmail.com> = a =C3=A9crit=C2=A0:
    AS-RO is an AS that RO trusts to delegate RO's access tokens accor= ding to RO's policies.=C2=A0=C2=A0

    --------------
    Alan Karp


    On Wed, Mar 24, 2021 at 9= :36 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan and Adrian,

    I've created issue AS= -RO policy delegation (https://github.com/ietf-wg-gnap/gnap-core-proto= col/issues/223) to capture your input.=C2=A0
    A first question= that arises: can we give a definition to AS-RO?

    T= hanks
    Fabien

    On Tue, Mar 23, 2021 at 4:15 PM Alan Karp <= ;alanhkarp@gmail.com> w= rote:
    Fabien Imba= ult <fabien.imbault@gm= ail.com> wrote:
    Hi Alan,= =C2=A0

    Yes, but in that flow, the token relationship bet= ween AS-RS and AS-RO is only secure if the tokens issued by AS-RS are crypt= ographically attenuable in the first place.=C2=A0
    <= div>=C2=A0
    Attenuated delegation is a requiremen= t, but that doesn't have to be done cryptographically.=C2=A0 Token exch= ange works just fine.=C2=A0 SPKI and zcap-ld are examples of the crypto app= roach, and we used token exchange in the system for HP.

    --------------
    Alan Karp


    On Tue, Mar 23, 202= 1 at 4:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    =
    Hi Alan,=C2=A0

    Yes, but in that flow, t= he token relationship between AS-RS and AS-RO is only secure if the tokens = issued by AS-RS are cryptographically attenuable in the first place.=C2=A0<= /div>

    Fabien

    <= div dir=3D"ltr" class=3D"gmail_attr">On Mon, Mar 22, 2021 at 9:26 PM Alan K= arp <alanhkarp@gmail.com> wrote:

    But with all that in mind, I think the key here = is going to be looking at what the inputs to the AS are, and how those can = be defined in an interoperable way for AS=E2=80=99s that can accept them. I= think there=E2=80=99s a lot of room for innovation and flexibility here th= at doesn=E2=80=99t break the trust model or core use cases. If I have an AS= -RS set that won=E2=80=99t accept my favorite flavor of policy engine input= s, then I can decide not to use that one. But this is a very different ques= tion than saying the RS itself needs to accept my own AS =E2=80=94 and we c= an=E2=80=99t keep conflating these two models.

    I agree.=C2=A0 The point of having an AS-RO is to allow RO = to specify a policy for which of RO's access tokens should be delegated= under what conditions.=C2=A0 AS-RS should not need to understand those pol= icies.=C2=A0 The flow would be
    • RO contacts AS-RS and gets= one or more access tokens.
    • RO delegates one or more of those token= s, potentially sub-scoped, to AS-RO.
    • A different user contacts AS-R= O to get a potentially sub-scoped access token from AS-RO.
    • That use= r presents the access token delegated by AS-RO when invoking the resource.<= /li>
    AS-RS only needs to verify that the delegation cha= in is legitimate, e.g., no increase in scope, and that it grants permission= for the request being made.=C2=A0 AS-RS does not need to understand the po= licy behind granting the delegation by AS-RO.

    ---= -----------
    Alan Karp


    On Mon, Mar 22, 2021 at 11:40 AM Ju= stin Richer <jricher@mit.edu> wrote:
    Adrian,

    I th= ink this shows the problem with the terminology as it=E2=80=99s been applie= d in this conversation, which I=E2=80=99ve tried to shine light on before. = What you and others are calling the =E2=80=9CRS=E2=80=9D is really the =E2= =80=9CAS and RS working together=E2=80=9D =E2=80=94 everything to the right= of the line. When Denis had brought up =E2=80=9Celiminating the AS=E2=80= =9D in another thread, what he=E2=80=99d really done is labeled everything = to the right of the line as the =E2=80=9CRS=E2=80=9D. Of course, the irony = here is that everything to the right of the line used all be called the =E2= =80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. A= s you say below, I don=E2=80=99t want the client to have visibility on what= happens on that side.=C2=A0

    Note well: The Google= + logo labeled =E2=80=9CIdP=E2=80=9D in the diagram is not the AS, as far a= s GNAP is concerned. It does not issue an access token that the RS will acc= ept. The elements to the left of the line could be a lot of things, but the= y are NOT the AS =E2=80=94 by definition. The client lives over on the left= , but so do any external inputs to the AS. These could be policy inputs on = behalf of the RO, they could be presentation artifacts, they could be feder= ated logins, they could be the output of policy decisions. How the AS comes= to trust those things is up to the AS=E2=80=99s implementation. It=E2=80= =99s something we can talk about, but ultimately GNAP won=E2=80=99t be in a= ny position to dictate because in practice some AS=E2=80=99s are simply goi= ng to internalize all policies and we will never successfully force those o= pen.=C2=A0

    But with all that in mind, I think the = key here is going to be looking at what the inputs to the AS are, and how t= hose can be defined in an interoperable way for AS=E2=80=99s that can accep= t them. I think there=E2=80=99s a lot of room for innovation and flexibilit= y here that doesn=E2=80=99t break the trust model or core use cases. If I h= ave an AS-RS set that won=E2=80=99t accept my favorite flavor of policy eng= ine inputs, then I can decide not to use that one. But this is a very diffe= rent question than saying the RS itself needs to accept my own AS =E2=80=94= and we can=E2=80=99t keep conflating these two models.

    So to me, GNAP can support a Zero Trust Architecture by LEVERAGING th= e AS, not by subsuming or eliminating it. It is in fact the AS, not the cli= ent and not the RS, that will request and consume the results of a privacy-= preserving zero-trust policy query thing. Anything that happens downstream = from that is of little concern to the zero-trust components because, as you= point out, it=E2=80=99s on the =E2=80=9Cother side=E2=80=9D of the line.= =C2=A0

    I think we got this basic component model p= retty right in OAuth: the AS and RS and client working together. Where OAut= h misses the mark is the assumption that the user has to log in to the AS t= hrough a webpage and interact directly, thereby proving they=E2=80=99re the= RO. It=E2=80=99s this latter space where I think we can both push innovati= on and also address the important and compelling use cases like the ones yo= u=E2=80=99re bringing.

    =C2=A0=E2=80=94 Justin
    <= div>

    I'm sorry, Justin= . As a Resource Owner, I look at the RS trust boundary (the dotted line in = the diagram) as being the RS. I don't expect any visibility into what&#= 39;s going on on the=C2=A0right.=C2=A0

    My problem with t= he framing you propose is that requests are going to the RS (or the AS-RS) = and I don't want to share my policies with the AS-RS. I want to keep th= e RS and AS-RS as ignorant as possible.

    Adrian

    On Mon, Mar 22, 2021 at 1:48 PM Justin Richer <jricher@mit.edu> wrote:
    =
    Adrian,

    What you=E2=80=99re discussing below, in te= rms of logging in to a site, is not approaching the RS. You are in fact app= roaching the client, and identifying both the AS and RS to the client. The = client is a client of your identity in this model, and the RS is par= t of the identity provider. It=E2=80=99s really important that we don=E2=80= =99t conflate the RS and client in this way as it leads to a lot of confusi= on downstream and a lot of broken trust boundaries.

    With that model in mind, approaching the =E2=80=9CRS" and providing = it your identity is really just a case of the =E2=80=9Cfederated login to A= S=E2=80=9D pattern that we discussed on the WG call. The user here approach= es an RS, which has its own AS. To share things from this RS, the RO has to= authenticate to the RS=E2=80=99s AS. This particular AS allows the RO to d= o so using an external identity =E2=80=94 in which case, the AS is now a = =E2=80=9Cclient=E2=80=9D of a separate, disconnected (but layered) delegati= on. The ultimate client that eventually calls the RS down the way may or ma= y not know about these layers.=C2=A0

    <PastedGraphic-1.png><= /span>
    This same AS, which is closely tied to the RS and trusted = by the RS, might also take in FIDO credentials, or DIDs, or any number of o= ther proof mechanisms. The output of this is an access token the RS trusts,= but the input is up to the AS. The RS is not what you=E2=80=99re logging i= n to.

    =C2=A0=E2=80=94 Justin

    On Mar 22, 2021, at 1:28 PM, Adrian Gropper <agropper@healthurl.com> w= rote:

    I too am in favor of avoiding consolid= ation and correlation. Right now, when I approach a service provider (RS) f= or the first time, I'm offered the opportunity to identify my persona a= s: email, sign-in with Google, Facebook, or Apple. I know there are people = who try to create one-off email addresses but that is mostly a waste of tim= e.=C2=A0

    So, along come FIDO2 and DID wallets to the res= cue. Now, in theory, I have a way to start out my RS relationship pseudonym= ously.=C2=A0

    When I want my resource to be discove= red or shared I will post that RS URL including my pseudonym. If I then wan= t to introduce a mediator=C2=A0in front of my AS or messaging service=C2=A0= endpoint, I have that option. If I want to keep requests away from the medi= ator, I would publish an encryption key along with my pseudonym.
    =
    - Adrian



    On Mon, Mar 22, = 2021 at 9:55 AM Justin Richer <= jricher@mit.edu> wrote:
    On Mar 21, 2021, a= t 1:18 PM, Benjamin Kaduk <kaduk@= mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhk= arp@gmail.com> shared a talk about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-= gnap/gnap-core-protocol/issues/145#issuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --
    TXAuth 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
    --
    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



    --000000000000612ee105be7290c2-- From nobody Fri Mar 26 10:07:24 2021 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 282423A2547 for ; Fri, 26 Mar 2021 10:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 WTqYgSF-zOWG for ; Fri, 26 Mar 2021 10:07:11 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B7853A2445 for ; Fri, 26 Mar 2021 10:06:47 -0700 (PDT) Received: from [192.168.1.11] ([90.79.53.231]) by mwinf5d85 with ME id l56i2400H4zJUWJ0356iK8; Fri, 26 Mar 2021 18:06:44 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Fri, 26 Mar 2021 18:06:44 +0100 X-ME-IP: 90.79.53.231 To: txauth@ietf.org, Justin Richer References: <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> <5773FA7B-6891-4227-A8CA-2F506909B8CD@mit.edu> From: Denis Message-ID: <3c103293-56a1-4be5-e2a3-12eb82d13238@free.fr> Date: Fri, 26 Mar 2021 18:06:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------93F7E09FFA01472A6B23BD51" Content-Language: en-GB Archived-At: Subject: [GNAP] Relationship between Authentication and Authorization ? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2021 17:07:22 -0000 This is a multi-part message in MIME format. --------------93F7E09FFA01472A6B23BD51 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi everybody, The content of this thread has nothing to do any more with its original title which was: "Will GNAP support Zero Trust Architecture?" Since I am going to use some sentences of this thread to open a new topic, I changed the title of this thread into : "Relationship between Authentication and Authorization ?" At the moment, I got the impression that nobody agrees any more about *what GNAP is or is not, what it should address and what it should not address*. The components of the model are becoming more numerous and hazy. A new terminology is sometimes being used, but is not yet present in the last published draft. I still can't understand any of the new terms that are being used (*AS-RS* and *AS-RO*), _which are still left undefined_. The last exchanges look more as conversations between workers during the construction of the Babel tower. Last year, my first remark was to mention that a section or an Annex explaining the common points and the differences with OAuth 2.0 would be useful. Such section or Annex still does not exist. Justin wrote: /If an RS allows a username/password HTTP Basic auth in addition to accepting access tokens, it can do so, but // //GNAP doesn’t have anything to say about the Basic auth use, or even its relation to any access tokens or RO’s or anything else./ Let us split the end of this sentence into two parts: "/GNAP doesn’t have anything //to say about the Basic auth use/":  If an authentication exchange  is necessary, the draft document should describe, for completeness, the HTTP error code that will be returned. "/or even its relation to any access tokens or RO’s or anything else/". Let us suppose that a RS supports FIDO as an authentication mechanism to authenticate its end-users. FIDO provides the major advantage that, for every RS, a different identifier is used by every end-user. This prevents end-users accounts correlations between RSs by using such identifiers. In practice, a FIDO identifier is a pseudonym. At this very moment, the RS is able to identify and authenticate its end-users using FIDO pseudonyms. Now, let us raise the following question: How will a RS be bootstrapped for working with a GNAP "sub" claim or a "sub_id" claim, whereas FIDO is already being used ? Denis > Adrian, > > I disagree, I believe that what I have laid out is exactly separating > the concerns into working components. > > Like OAuth before it, GNAP is a protocol negotiate access for a client > instance to an RS, using an AS as the facilitator of that delegated > negotiation. (Unlike OAuth, it’s importantly also for negotiating user > information to the client directly from the AS with no RS involved, > but that’s an aside for the purposes of our conversation here). > > If a particular GNAP RS also allows other kinds of processes to enable > access to it, that is completely fine, but outside of GNAP. If an RS > allows a username/password HTTP Basic auth in addition to accepting > access tokens, it can do so, but GNAP doesn’t have anything to say > about the Basic auth use, or even its relation to any access tokens or > RO’s or anything else. If an RS accepts structured access tokens > signed by trusted keys that don’t come from an AS through a negotiated > request — again, that’s fine, but GNAP is silent about the RS doing > that. If the RS acts as “its own AS” then it’s really just an RS and > an AS living in the same box. Again, that’s fine, and super common > with OAuth today. > > GNAP is solving the problem of connecting the client to the RS through > means of an AS. Other solutions are possible and many of them can be > deployed right alongside, but that’s not the corner of the world that > GNAP is solving. GNAP should be concerned about how these other > technologies can be used alongside it. I think there’s a lot of room > for the things that you’re talking about, and more importantly for > solving the use cases that you’re bringing. But GNAP should be more > than a single-point solution, and so we need to balance these > concerns. The conceptual framework of an AS that takes in lots of > different information and spits out access tokens is exactly the > abstraction layer that is necessary for making these use cases > interoperable. > >  — Justin > >> On Mar 26, 2021, at 8:30 AM, Adrian Gropper > > wrote: >> >> @Justin, there’s no separation of concerns here. No partition between >> processor and controller. No data minimization. And, I see no obvious >> reason to make this the core of GNAP. >> >> The one thing we can probably all agree on is that there’s only one >> RS and one RO. >> >> The core of GNAP, in my opinion, can be built and explained around >> this simple design. The RS is a processor. The RO is a controller. >> The RS bears only security responsibility. The RS bears no privacy >> responsibility. The RO delegates this to the RS but this is not >> authorization as the A in GNAP. >> >> The RO retains all rights to delegate within the scope of things that >> the RS is willing to support using various token formats and endpoint >> options. Some of these options may do all sorts of things for all >> sorts of clients and user-agents  but these are options. >> >> For example, if a request comes to the RS that is not in the form of >> an access token, then it either gets sent to the RO or their agent, >> or it gets logged and dumped. One such option, common in healthcare, >> is “Break the Glass” where the RS is acting as an authorization >> server because the user-agent is making a request instead of >> presenting an access token. GNAP can offer this as an option but it >> is not our core. >> >> Adrian >> >> >> >> On Fri, Mar 26, 2021 at 7:15 AM Justin Richer > > wrote: >> >> I have a big problem with this line: >> >> > the RS and AS-RS only see access tokens. The requests (from >> RO') that resulted in an access token are none of their business. >> >> In the trust model we’ve been discussing, the requests that >> result in access tokens are *solely the business of AS-RS*, since >> AS-RS is the only entity that’s allowed, and trusted by the RS, >> to create access tokens for the RS. That is its entire job, the >> entire reason it exists in the system. By definition the party >> generating tokens for use at the RS is the AS for that RS, I >> don’t care how you deploy it. If RO wants to give access to >> someone else (who isn’t an “RO" anymore, they’re another >> end-user), then that end user’s client software will need to talk >> to AS-RS to get its own access token. >> >> Now here’s the trick: when the end user’s client instance talks >> to AS-RS, that does NOT mean that AS-RS needs to know all the >> details and policy reasons that it should give an access token to >> that client instance. It doesn’t even need to know the existence >> of another end user. It doesn’t need identity, it doesn’t need >> policy. Sure, it COULD handle all of that internally, and many >> will, but the protocol doesn’t demand it. >> >> This means that the first client instance, the one that gets the >> access token, can also be given something alongside the access >> token that it can then hand to another piece of software (or to a >> person to hand eo their piece of software). This artifact is not >> an access token. This artifact could be something structured that >> the client understands, and can make derivatives of, and present >> back to the AS-RS for getting new access tokens. There could be >> multiple different flavors of this kind of artifact for different >> kinds of environments and groups. But what they all have in >> common is that they can potentially be used to request more >> access tokens within some context at the AS-RS. >> >>  — Justin >> >> >> >>> On Mar 25, 2021, at 5:50 PM, Adrian Gropper >>> > wrote: >>> >>> My issue is with Alan's: >>> >>> "7. Another user agent (RO') can contact any holder of the >>> access token or the service's policy agent (AS-RS) to get a >>> delegated access token." >>> >>> >>> I would prefer "7A.Another user agent (RO') can contact any >>> holder of the access token." by default so that the AS-RS does >>> not see the requests. In other words, the RS and AS-RS only see >>> access tokens. The requests (from RO') that resulted in an >>> access token are none of their business. >>> >>> The reality is that RO' can discover a resource RS and can share >>> whatever information with RS-AS they want and the RO may not >>> even know about it unless the RS decides to let them know >>> somehow. This seems to be a drawback of the capabilities approach. >>> >>> In terms of privacy and control, I, as the RO, want a >>> contract with the RS that says that I or my agent (AS-RO) must >>> sign an access token. This is a fundamental audit requirement. >>> Without it, a rogue RS and AS-RS can do all sorts of things and >>> the RO would never know. I understand that a rogue RS might not >>> support an honest contemporaneous log of access tokens presented >>> so there's a trust issue here that I seems unavoidable unless I >>> specify in my RO-RS contract that they use a separate >>> contemporaneous log such as AS-RO for every access token >>> presented and risk being sued if they process an access token >>> without also updating the separate log. >>> >>> - Adrian >>> >>> >>> On Thu, Mar 25, 2021 at 1:22 PM Alan Karp >> > wrote: >>> >>> Justin Richer > wrote: >>> >>> Hi Alan, >>> >>> In all of my discussion, and in the spec itself, the RO >>> is the :entity: in charge of approving rights. They’re >>> probably a person. It might be software that makes a >>> policy decision in some way, or a corporate entity, or >>> something like that. But it’s not assumed to be a >>> computational agent in the terms of the protocol itself. >>> Would that recast what you’re saying below? >>> >>> >>> Hmmm.  I guess not.  It's just that the person would be >>> using some UI to express their decisions to what I called >>> the user agent.  That model fits in very nicely with what we >>> did with Polaris, our virus safe computing environment for >>> Windows XP, https://dl.acm.org/doi/10.1145/1151030.1151033 >>> . The person >>> would click on the icon for a Word file, and an instance of >>> Word would open with only the permission needed to edit that >>> one file.  Same thing here.  The client could ask for >>> permission to use the resource, or permission could be >>> granted implicitly when the user selects a resource >>> associated with a specific client. >>> >>> -------------- >>> Alan Karp >>> >>> >>> On Thu, Mar 25, 2021 at 9:53 AM Justin Richer >>> > wrote: >>> >>> Hi Alan, >>> >>> In all of my discussion, and in the spec itself, the RO >>> is the :entity: in charge of approving rights. They’re >>> probably a person. It might be software that makes a >>> policy decision in some way, or a corporate entity, or >>> something like that. But it’s not assumed to be a >>> computational agent in the terms of the protocol itself. >>> Would that recast what you’re saying below? >>> >>>  — Justin >>> >>>> On Mar 25, 2021, at 12:36 PM, Alan Karp >>>> > wrote: >>>> >>>> There seems to be some confusion about how AS-RO comes >>>> into the picture, probably because of the "AS" part. >>>> I'm going to try to clear up that confusion by more >>>> carefully explaining what I mean. >>>> >>>> I'm assuming that RO is a computational agent >>>> representing the person who is the resource owner, >>>> something called the "user agent" in operating systems >>>> lingo.  I'm also assuming that it's possible to do >>>> delegation, either locally or by token exchange with >>>> AS-RS.  All delegations are potentially sub-scoped, but >>>> you may also want to delegate with full scope to have a >>>> separately revocable access token. >>>> >>>> Here's an example of how things work in a capability >>>> oriented system. >>>> >>>> 1. Someone, the service owner, creates a service. >>>> 2. The service owner contracts with an policy agent >>>> (AS-RS) to create and manage access tokens for that >>>> service (RS). >>>> 3. A person wishing to create a resource at RS uses >>>> their user agent (RO) to contact the service >>>> owner's policy agent (AS-RS) and gets back an >>>> access token for that resource. >>>> 4. That user agent (RO) can >>>> 1. use that access token to invoke the resource, or >>>> 2. delegate an access token to a client of the >>>> user agent's (RO) choice, or >>>> 3. contract with a policy agent (AS-RO) to manage >>>> those delegations on behalf of the user agent >>>> (RO), or >>>> 4. specify a policy with the service's policy >>>> agent (AS-RS). >>>> 5. A client can contact any holder of the access token >>>> (the user agent (RO) or its policy agent (AS-RO)) >>>> or the service's policy agent (AS-RS) to get a >>>> delegated access token. >>>> 6. That client can delegate that token to another client. >>>> 7. Another user agent (RO') can contact any holder of >>>> the access token or the service's policy agent >>>> (AS-RS) to get a delegated access token. >>>> 8. The other user agent (RO') can >>>> 1. use that access token to invoke the resource, or >>>> 2. delegate it to a client of its choice, or >>>> 3. contract with a policy agent (AS-RO') of its >>>> choosing to manage those delegations on its >>>> behalf, or >>>> 4. specify a policy with the service's policy >>>> agent (AS-RS). >>>> 9. and so on >>>> >>>> When any of these computational agents, user agents >>>> (ROs) or clients acting on their behalf, invokes the >>>> resource, AS-RS verifies that the access token is a >>>> valid delegation, i.e., proper sub-scoping, hasn't been >>>> revoked, and that it authorizes the request being made >>>> before telling the service (RS) to honor the request.  >>>> At no point does the service's policy agent (AS-RS) >>>> know which computational agent did any particular >>>> delegation. (Token exchange can be done as anonymously >>>> as possible.)  In particular, the policy agents (AS-RO) >>>> need not be the same, or even compatible with, the >>>> service's policy agent (AS-RS).  GNAP specifies the >>>> protocol between requesters, invokers, delegators (for >>>> token exchange) of tokens and AS-RS.  That protocol >>>> need not be used between user agents (RO), clients, or >>>> other policy agents (AS-RO), but it is likely to be. >>>> >>>>  ------------- >>>> Alan Karp >>>> >>>> >>>> On Thu, Mar 25, 2021 at 5:45 AM Justin Richer >>>> > wrote: >>>> >>>> The way I’m thinking about Adrian’s use case is >>>> that what we’re calling the “AS-RO” isn’t an “AS” >>>> in the traditional OAuth/GNAP sense, at least not >>>> exactly. This is the agent that the RO can use to >>>> set policies and manage consent on their behalf, >>>> and I’ve been arguing that it fits better into this >>>> vaguely-defined “interaction component” aspect of >>>> the current AS definition, and it’s not currently >>>> separated from the AS definition. The “AS-RS” maps >>>> to what we’d call the “AS” in OAuth/GNAP >>>> traditionally, it’s what the RS trusts to issue >>>> tokens. In traditional OAuth the AS-RO and AS-RS >>>> are always the same thing, from a functional >>>> protocol perspective. An important point here is >>>> that from a client’s perspective, they’re only >>>> talking to the AS-RS since that’s where the client >>>> gets its tokens, because at the end of the day the >>>> client just wants to call the API at the RS and >>>> doesn’t care how that happens (from a protocol >>>> standpoint). >>>> >>>> Note well: Even thought I don’t believe that >>>> “AS-RO” is an authorization server at all, I’m >>>> going to keep using that term below for consistency >>>> with previous discussion. >>>> >>>> So we have these fundamental relationships around >>>> getting the client to access the RS: >>>> >>>> 1. RS trusts AS-RS to issue tokens that RS will >>>> accept, validate, and process for requests from client >>>> 2. Client trusts AS-RS to issue tokens that client >>>> can use at RS >>>> 3. RO trusts RS to protect RO’s api through >>>> delegated access >>>> >>>> On top of that, we’ve got some additional aspects >>>> that we’re discussing: >>>> >>>> 4. RO trusts AS-RO to manage RO’s policies at runtime >>>> 5. AS-RS trusts AS-RO to assert RO’s policies for >>>> access to RS >>>> 6. Client trusts whatever AS-RS sends client to >>>> deal with, including possibly RO-AS at runtime, >>>> because of (2) >>>> >>>> What I have been saying is that 4/5/6 are optional >>>> details of how RS-AS runs things, and I think this >>>> also maps with Adrian’s view of choice, since if my >>>> RS’s AS-RS doesn’t allow me to plug in my own AS-RO >>>> then I would be motivated to pick a different RS >>>> who’s AS-RS lets me do just that. The same way I’d >>>> pick a different RS if their surrounding services >>>> didn’t accept my preferred federation login and I >>>> didn’t want to make another account. Of course, >>>> market forces being as they are, I might not have >>>> much of an actionable choice in RS, but GNAP can’t >>>> change that. >>>> >>>> What we can do is make it possible for AS-RS to >>>> talk to AS-RO, both in philosophy of the protocol >>>> design and in concrete hooks to support (6) above. >>>> >>>> Separately, we can approach the issue of making 1/2 >>>> above more dynamic. This was UMA2’s “federated >>>> authorization” approach, and is behind a lot of the >>>> “bring your own AS” models out there. The problem >>>> with these is that we know from many years of >>>> experience that most RS’s aren’t interested in >>>> doing anything of the sort. >>>> >>>> So with GNAP we can instead allow 4/5/6 to vary in >>>> a predictable and consistent way, letting the RS >>>> keep control over 1/2, thereby enabling choice in >>>> (3). We don’t have to be the ones who define the >>>> all of the details of every permutation of (5) to >>>> enable this, though. Some of this is going to be >>>> configuration out of band, some of it’s going to be >>>> communication at runtime. This is where VC’s, >>>> ZCAPs, CHAPI, DIDComm, FIDO, and a whole swath of >>>> other tech can come in and help out. I don’t think >>>> we need to put all the details for using these into >>>> core, nor do I think we’ll pull of The Great And >>>> Ultimate Abstraction for using these and other >>>> approaches. But we can at least start talking about >>>> “AS-RS” in such a way that it no longer assumes >>>> it’s always the same party dealing with the RO >>>> directly. >>>> >>>>  — Justin >>>> >>>>> On Mar 25, 2021, at 6:40 AM, Fabien Imbault >>>>> >>>> > wrote: >>>>> >>>>> To reframe it closer to GNAP: >>>>> - AS = AS-RO, that's where you find the RO >>>>> policies. The AS issues access tokens to the client. >>>>> - the RO policies could be a) defined locally or >>>>> b) in relationship with the RS >>>>> >>>>> There have been several ideas related to the AS-RS >>>>> relationship b: >>>>> b1) the RS issues capabilities (which can be >>>>> further attenuated by the RO) >>>>> b2) Adrian also discussed a DID based solution >>>>> b3) there was also an alternative ACL proposal >>>>> from Denis (+ preflight) >>>>> >>>>> Fabien >>>>> >>>>> >>>>> On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault >>>>> >>>> > wrote: >>>>> >>>>> Ok so I get you correctly: >>>>> - what matters is the RQ (could be a RO or a >>>>> end-user or both : we don't really care at a >>>>> high-level, they're all treated as entities >>>>> that make a request) >>>>> - the policy is able to handle those different >>>>> cases, based on its own internal delegation >>>>> protocol >>>>> - currently that requires AS-RS and AS-RO, but >>>>> maybe it can be simplified >>>>> >>>>> To answer to Denis, here's what I understood: >>>>> - RO trusts AS-RS (and then handles its own >>>>> policies within AS-RO) >>>>> - end-user trusts AS-RO (through its client) >>>>> >>>>> Could probably work but that's a fairly >>>>> different model compared to OAuth2 (and of >>>>> today's GNAP), with different frontiers >>>>> between the AS and the RS. >>>>> >>>>> Please do not hesitate to correct me if I'm wrong. >>>>> >>>>> Fabien >>>>> >>>>> On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper >>>>> >>>> > wrote: >>>>> >>>>> I believe there are alternatives to having >>>>> two kinds of ASs. The problem may be a >>>>> side-effect of deciding to switch away >>>>> form treating the RO as different from the >>>>> RQ. That leads to downstream privacy >>>>> issues. Our desire for architectural >>>>> simplicity is admirable but that may have >>>>> been a step too far. >>>>> >>>>> There may also be solutions based on >>>>> different types of tokens, as in different >>>>> capabilities (tokens signed by the RS) vs. >>>>> tokens signed by the AS. I’m not sure >>>>> about that but Alan might have more to say. >>>>> >>>>> Adrian >>>>> >>>>> On Thu, Mar 25, 2021 at 4:15 AM Fabien >>>>> Imbault >>>> > wrote: >>>>> >>>>> Thanks. The general problem statement >>>>> is clear. >>>>> >>>>> The proposed solution a bit less (to >>>>> me). I understood that from point 2, >>>>> Alan involves 2 ASs. You said : >>>>> "There’s no obvious reason to have two >>>>> types of ASs". Do you see an alternative ? >>>>> >>>>> Regarding the last item, I don't think >>>>> that naming RQ by end-user created the >>>>> problem. It might just highlight the >>>>> asymmetry, which fundamentally exists. >>>>> >>>>> Fabien >>>>> >>>>> >>>>> On Thu, Mar 25, 2021 at 8:48 AM Adrian >>>>> Gropper >>>> > wrote: >>>>> >>>>> Recap: >>>>> 1 - Justin (I think) introduced >>>>> the idea of an AS on the RS trust >>>>> boundary side. >>>>> 2 - I said the RO should not have >>>>> to share policies with the RS. >>>>> 3 - Alan invented the concept of >>>>> AS-RO and AS-RS to separate two >>>>> kinds of PDPs. >>>>> >>>>> The thing is that step 2 is not >>>>> symmetrical. The RO has a >>>>> legitimate privacy interest in >>>>> keeping their policies private and >>>>> minimizing the leakage of >>>>> information about requests that >>>>> are posed against those policies. >>>>> >>>>> The RS, on the other hand, should >>>>> be publishing its policies (e.g. >>>>> what it’s selling or what >>>>> jurisdiction it’s in or what >>>>> tokens or scopes it supports). The >>>>> RS has no obvious privacy interest >>>>> in GNAP. It’s just an enforcer. >>>>> >>>>> There is one other privacy >>>>> interest to consider around the RS >>>>> and that is the requesting party >>>>> (the end-user that is not the RO >>>>> :-) might prefer to share >>>>> attributes with the RS instead of >>>>> the RO or something controlled by >>>>> the RO. This case could be an >>>>> “extension” to GNAP and might >>>>> result in a split AS as a >>>>> solution. This problem was >>>>> introduced when the editors >>>>> decided to replace RQ with >>>>> end-user. Obviously, the RO >>>>> end-user has no privacy interests >>>>> relative to itself. >>>>> >>>>> Adrian >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Mar 25, 2021 at 3:24 AM >>>>> Fabien Imbault >>>>> >>>> > >>>>> wrote: >>>>> >>>>> I was referring to "By my >>>>> definition, this model has two >>>>> ASs since both are processing >>>>> requests into tokens". If >>>>> there's no reason to have 2 >>>>> types of ASs, that's fine then. >>>>> But I'm a bit lost in where we >>>>> stand with the idea. >>>>> >>>>> Could you recap? >>>>> >>>>> Fabien >>>>> >>>>> Le jeu. 25 mars 2021 à 08:16, >>>>> Adrian Gropper >>>>> >>>> > >>>>> a écrit : >>>>> >>>>> There’s no obvious reason >>>>> to have two types of ASs. >>>>> Any AS that is executing >>>>> the policies of the RS can >>>>> look to GNAP like the RS >>>>> itself. Why would GNAP >>>>> expose that interface to >>>>> anyone? >>>>> >>>>> Adrian >>>>> >>>>> On Thu, Mar 25, 2021 at >>>>> 3:11 AM Fabien Imbault >>>>> >>>> > >>>>> wrote: >>>>> >>>>> Note : I'm not sure >>>>> that's a good idea, >>>>> but having 2 types of >>>>> ASs is not that easy >>>>> to grasp. >>>>> >>>>> Fabien >>>>> >>>>> Le jeu. 25 mars 2021 à >>>>> 08:07, Fabien Imbault >>>>> >>>> > >>>>> a écrit : >>>>> >>>>> The purpose of >>>>> either handling >>>>> policies locally >>>>> or delegating them >>>>> to the RO agent. >>>>> >>>>> Le jeu. 25 mars >>>>> 2021 à 08:04, >>>>> Adrian Gropper >>>>> >>>> > >>>>> a écrit : >>>>> >>>>> What purpose >>>>> would be >>>>> served by GNAP >>>>> splitting the >>>>> AS into two >>>>> components? >>>>> >>>>> Adrian >>>>> >>>>> On Thu, Mar >>>>> 25, 2021 at >>>>> 2:59 AM Fabien >>>>> Imbault >>>>> >>>> > >>>>> wrote: >>>>> >>>>> Isn't the >>>>> AS-RO a >>>>> component >>>>> of the AS? >>>>> Same idea >>>>> as the >>>>> interact >>>>> component, >>>>> it >>>>> functionnally >>>>> belongs to >>>>> the AS >>>>> role but >>>>> could be >>>>> deployed >>>>> either as >>>>> a monolith >>>>> or as a >>>>> separate >>>>> component? >>>>> >>>>> Fabien >>>>> >>>>> Le jeu. 25 >>>>> mars 2021 >>>>> à 04:26, >>>>> Adrian >>>>> Gropper >>>>> >>>> > >>>>> a écrit : >>>>> >>>>> Yes, >>>>> but I >>>>> would >>>>> say >>>>> it’s >>>>> not >>>>> the RO >>>>> that >>>>> wants >>>>> the >>>>> access >>>>> token. >>>>> It’s >>>>> the RO >>>>> that >>>>> wants >>>>> the >>>>> client >>>>> making >>>>> the >>>>> request >>>>> to get >>>>> an >>>>> access >>>>> token. >>>>> >>>>> Adrian >>>>> >>>>> On >>>>> Wed, >>>>> Mar >>>>> 24, >>>>> 2021 >>>>> at >>>>> 11:22 >>>>> PM >>>>> Alan >>>>> Karp >>>>> >>>> > >>>>> wrote: >>>>> >>>>> Adrian >>>>> Gropper >>>>> >>>> > >>>>> wrote: >>>>> >>>>> >>>>> In >>>>> this >>>>> design, >>>>> the >>>>> AS >>>>> is >>>>> the >>>>> AS-RS >>>>> and >>>>> the >>>>> agent >>>>> is >>>>> the >>>>> AS-RO. >>>>> By >>>>> my >>>>> definition, >>>>> this >>>>> model >>>>> has >>>>> two >>>>> ASs >>>>> since >>>>> both >>>>> are >>>>> processing >>>>> requests >>>>> into >>>>> tokens. >>>>> The >>>>> problem >>>>> with >>>>> this >>>>> is >>>>> complexity >>>>> and >>>>> privacy. >>>>> The >>>>> RO >>>>> may >>>>> not >>>>> want >>>>> to >>>>> share >>>>> the >>>>> request >>>>> information >>>>> with >>>>> the >>>>> AS-RS. >>>>> >>>>> >>>>> More >>>>> precisely, >>>>> RO >>>>> has >>>>> no >>>>> choice >>>>> but >>>>> to >>>>> present >>>>> the >>>>> required >>>>> information >>>>> to >>>>> AS-RS >>>>> if >>>>> RO >>>>> wants >>>>> an >>>>> access >>>>> token. >>>>> However, >>>>> RO >>>>> does >>>>> not >>>>> want >>>>> AS-RS >>>>> to >>>>> know >>>>> the >>>>> policy >>>>> by >>>>> which >>>>> RO >>>>> delegates >>>>> tokens. >>>>> That's >>>>> why >>>>> RO >>>>> uses >>>>> AS-RO >>>>> for >>>>> those >>>>> delegations. >>>>> >>>>> -------------- >>>>> Alan >>>>> Karp >>>>> >>>>> >>>>> On >>>>> Wed, >>>>> Mar >>>>> 24, >>>>> 2021 >>>>> at >>>>> 7:41 >>>>> PM >>>>> Adrian >>>>> Gropper >>>>> >>>> > >>>>> wrote: >>>>> >>>>> Thank >>>>> you >>>>> for >>>>> creating >>>>> the >>>>> issue. >>>>> My >>>>> definition >>>>> of >>>>> AS >>>>> is >>>>> independent >>>>> of >>>>> AS-RO >>>>> or >>>>> AS-RS. >>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomment-806280421 >>>>> >>>>> I >>>>> also >>>>> agree >>>>> with >>>>> Alan's >>>>> definition >>>>> based >>>>> on >>>>> delegation. >>>>> An >>>>> AS-RS >>>>> would >>>>> be >>>>> a >>>>> delegate >>>>> of >>>>> the >>>>> RS. >>>>> >>>>> >>>>> Based >>>>> on >>>>> that, >>>>> I >>>>> see >>>>> it >>>>> as >>>>> obvious that >>>>> the >>>>> policy >>>>> has >>>>> to >>>>> be >>>>> accessible >>>>> (defined >>>>> locally?) >>>>> in >>>>> order >>>>> for >>>>> it >>>>> to >>>>> be >>>>> run >>>>> as >>>>> the >>>>> code >>>>> that >>>>> turns >>>>> a >>>>> request >>>>> into >>>>> an >>>>> access >>>>> token. >>>>> >>>>> >>>>> The >>>>> only >>>>> other >>>>> possibility >>>>> is >>>>> that >>>>> the >>>>> request >>>>> is >>>>> packaged >>>>> by >>>>> the >>>>> AS >>>>> and >>>>> sent >>>>> elsewhere >>>>> (an >>>>> agent) >>>>> for >>>>> evaluation >>>>> against >>>>> policy >>>>> and >>>>> a >>>>> proto-token >>>>> returned. >>>>> In >>>>> that >>>>> case >>>>> the >>>>> AS >>>>> is >>>>> acting >>>>> as >>>>> a >>>>> proxy >>>>> and >>>>> the >>>>> PDP >>>>> is >>>>> elsewhere. >>>>> I >>>>> can >>>>> imagine >>>>> that >>>>> an >>>>> AS-RS >>>>> would >>>>> behave >>>>> this >>>>> way >>>>> so >>>>> that >>>>> the >>>>> proto-token >>>>> could >>>>> be >>>>> turned >>>>> into >>>>> an >>>>> access >>>>> token >>>>> by >>>>> the >>>>> AS-RS. >>>>> Isn't >>>>> this >>>>> what >>>>> Justin >>>>> is >>>>> proposing? >>>>> In >>>>> this >>>>> design, >>>>> the >>>>> AS >>>>> is >>>>> the >>>>> AS-RS >>>>> and >>>>> the >>>>> agent >>>>> is >>>>> the >>>>> AS-RO. >>>>> By >>>>> my >>>>> definition, >>>>> this >>>>> model >>>>> has >>>>> two >>>>> ASs >>>>> since >>>>> both >>>>> are >>>>> processing >>>>> requests >>>>> into >>>>> tokens. >>>>> The >>>>> problem >>>>> with >>>>> this >>>>> is >>>>> complexity >>>>> and >>>>> privacy. >>>>> The >>>>> RO >>>>> may >>>>> not >>>>> want >>>>> to >>>>> share >>>>> the >>>>> request >>>>> information >>>>> with >>>>> the >>>>> AS-RS. >>>>> >>>>> Adrian >>>>> >>>>> On >>>>> Wed, >>>>> Mar >>>>> 24, >>>>> 2021 >>>>> at >>>>> 5:21 >>>>> PM >>>>> Fabien >>>>> Imbault >>>>> >>>> > >>>>> wrote: >>>>> >>>>> Isn't >>>>> that >>>>> what >>>>> the >>>>> AS >>>>> is >>>>> supposed >>>>> to >>>>> be, >>>>> only >>>>> with >>>>> the >>>>> caveat >>>>> that >>>>> the >>>>> policy >>>>> is >>>>> defined >>>>> locally? >>>>> >>>>> >>>>> Fabien >>>>> >>>>> >>>>> >>>>> Le >>>>> mer. >>>>> 24 >>>>> mars >>>>> 2021 >>>>> à >>>>> 20:17, >>>>> Alan >>>>> Karp >>>>> >>>> > >>>>> a >>>>> écrit : >>>>> >>>>> AS-RO >>>>> is >>>>> an >>>>> AS >>>>> that >>>>> RO >>>>> trusts >>>>> to >>>>> delegate >>>>> RO's >>>>> access >>>>> tokens >>>>> according >>>>> to >>>>> RO's >>>>> policies. >>>>> >>>>> >>>>> -------------- >>>>> Alan >>>>> Karp >>>>> >>>>> >>>>> On >>>>> Wed, >>>>> Mar >>>>> 24, >>>>> 2021 >>>>> at >>>>> 9:36 >>>>> AM >>>>> Fabien >>>>> Imbault >>>>> >>>> > >>>>> wrote: >>>>> >>>>> Hi >>>>> Alan >>>>> and >>>>> Adrian, >>>>> >>>>> >>>>> I've >>>>> created >>>>> issue >>>>> AS-RO >>>>> policy >>>>> delegation >>>>> (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223 >>>>> ) >>>>> to >>>>> capture >>>>> your >>>>> input. >>>>> >>>>> A >>>>> first >>>>> question >>>>> that >>>>> arises: >>>>> can >>>>> we >>>>> give >>>>> a >>>>> definition >>>>> to >>>>> AS-RO? >>>>> >>>>> Thanks >>>>> Fabien >>>>> >>>>> On >>>>> Tue, >>>>> Mar >>>>> 23, >>>>> 2021 >>>>> at >>>>> 4:15 >>>>> PM >>>>> Alan >>>>> Karp >>>>> >>>> > >>>>> wrote: >>>>> >>>>> Fabien >>>>> Imbault >>>>> >>>> > >>>>> wrote: >>>>> >>>>> Hi >>>>> Alan, >>>>> >>>>> >>>>> Yes, >>>>> but >>>>> in >>>>> that >>>>> flow, >>>>> the >>>>> token >>>>> relationship >>>>> between >>>>> AS-RS >>>>> and >>>>> AS-RO >>>>> is >>>>> only >>>>> secure >>>>> if >>>>> the >>>>> tokens >>>>> issued >>>>> by >>>>> AS-RS >>>>> are >>>>> cryptographically >>>>> attenuable >>>>> in >>>>> the >>>>> first >>>>> place. >>>>> >>>>> >>>>> Attenuated >>>>> delegation >>>>> is >>>>> a >>>>> requirement, >>>>> but >>>>> that >>>>> doesn't >>>>> have >>>>> to >>>>> be >>>>> done >>>>> cryptographically. >>>>> Token >>>>> exchange >>>>> works >>>>> just >>>>> fine.  >>>>> SPKI >>>>> and >>>>> zcap-ld >>>>> are >>>>> examples >>>>> of >>>>> the >>>>> crypto >>>>> approach, >>>>> and >>>>> we >>>>> used >>>>> token >>>>> exchange >>>>> in >>>>> the >>>>> system >>>>> for >>>>> HP. >>>>> >>>>> -------------- >>>>> Alan >>>>> Karp >>>>> >>>>> >>>>> On >>>>> Tue, >>>>> Mar >>>>> 23, >>>>> 2021 >>>>> at >>>>> 4:12 >>>>> AM >>>>> Fabien >>>>> Imbault >>>>> >>>> > >>>>> wrote: >>>>> >>>>> Hi >>>>> Alan, >>>>> >>>>> >>>>> Yes, >>>>> but >>>>> in >>>>> that >>>>> flow, >>>>> the >>>>> token >>>>> relationship >>>>> between >>>>> AS-RS >>>>> and >>>>> AS-RO >>>>> is >>>>> only >>>>> secure >>>>> if >>>>> the >>>>> tokens >>>>> issued >>>>> by >>>>> AS-RS >>>>> are >>>>> cryptographically >>>>> attenuable >>>>> in >>>>> the >>>>> first >>>>> place. >>>>> >>>>> >>>>> Fabien >>>>> >>>>> On >>>>> Mon, >>>>> Mar >>>>> 22, >>>>> 2021 >>>>> at >>>>> 9:26 >>>>> PM >>>>> Alan >>>>> Karp >>>>> >>>> > >>>>> wrote: >>>>> >>>>> Justin >>>>> Richer >>>>> >>>> > >>>>> wrote: >>>>> >>>>> >>>>> But >>>>> with >>>>> all >>>>> that >>>>> in >>>>> mind, >>>>> I >>>>> think >>>>> the >>>>> key >>>>> here >>>>> is >>>>> going >>>>> to >>>>> be >>>>> looking >>>>> at >>>>> what >>>>> the >>>>> inputs >>>>> to >>>>> the >>>>> AS >>>>> are, >>>>> and >>>>> how >>>>> those >>>>> can >>>>> be >>>>> defined >>>>> in >>>>> an >>>>> interoperable >>>>> way >>>>> for >>>>> AS’s >>>>> that >>>>> can >>>>> accept >>>>> them. >>>>> I >>>>> think >>>>> there’s >>>>> a >>>>> lot >>>>> of >>>>> room >>>>> for >>>>> innovation >>>>> and >>>>> flexibility >>>>> here >>>>> that >>>>> doesn’t >>>>> break >>>>> the >>>>> trust >>>>> model >>>>> or >>>>> core >>>>> use >>>>> cases. >>>>> If >>>>> I >>>>> have >>>>> an >>>>> AS-RS >>>>> set >>>>> that >>>>> won’t >>>>> accept >>>>> my >>>>> favorite >>>>> flavor >>>>> of >>>>> policy >>>>> engine >>>>> inputs, >>>>> then >>>>> I >>>>> can >>>>> decide >>>>> not >>>>> to >>>>> use >>>>> that >>>>> one. >>>>> But >>>>> this >>>>> is >>>>> a >>>>> very >>>>> different >>>>> question >>>>> than >>>>> saying >>>>> the >>>>> RS >>>>> itself >>>>> needs >>>>> to >>>>> accept >>>>> my >>>>> own >>>>> AS >>>>> — >>>>> and >>>>> we >>>>> can’t >>>>> keep >>>>> conflating >>>>> these >>>>> two >>>>> models. >>>>> >>>>> I >>>>> agree.  >>>>> The >>>>> point >>>>> of >>>>> having >>>>> an >>>>> AS-RO >>>>> is >>>>> to >>>>> allow >>>>> RO >>>>> to >>>>> specify >>>>> a >>>>> policy >>>>> for >>>>> which >>>>> of >>>>> RO's >>>>> access >>>>> tokens >>>>> should >>>>> be >>>>> delegated >>>>> under >>>>> what >>>>> conditions. >>>>> AS-RS >>>>> should >>>>> not >>>>> need >>>>> to >>>>> understand >>>>> those >>>>> policies.  >>>>> The >>>>> flow >>>>> would >>>>> be >>>>> >>>>> * RO >>>>> contacts >>>>> AS-RS >>>>> and >>>>> gets >>>>> one >>>>> or >>>>> more >>>>> access >>>>> tokens. >>>>> * RO >>>>> delegates >>>>> one >>>>> or >>>>> more >>>>> of >>>>> those >>>>> tokens, >>>>> potentially >>>>> sub-scoped, >>>>> to >>>>> AS-RO. >>>>> * A >>>>> different >>>>> user >>>>> contacts >>>>> AS-RO >>>>> to >>>>> get >>>>> a >>>>> potentially >>>>> sub-scoped >>>>> access >>>>> token >>>>> from >>>>> AS-RO. >>>>> * That >>>>> user >>>>> presents >>>>> the >>>>> access >>>>> token >>>>> delegated >>>>> by >>>>> AS-RO >>>>> when >>>>> invoking >>>>> the >>>>> resource. >>>>> >>>>> AS-RS >>>>> only >>>>> needs >>>>> to >>>>> verify >>>>> that >>>>> the >>>>> delegation >>>>> chain >>>>> is >>>>> legitimate, >>>>> e.g., >>>>> no >>>>> increase >>>>> in >>>>> scope, >>>>> and >>>>> that >>>>> it >>>>> grants >>>>> permission >>>>> for >>>>> the >>>>> request >>>>> being >>>>> made. >>>>> AS-RS >>>>> does >>>>> not >>>>> need >>>>> to >>>>> understand >>>>> the >>>>> policy >>>>> behind >>>>> granting >>>>> the >>>>> delegation >>>>> by >>>>> AS-RO. >>>>> >>>>> -------------- >>>>> Alan >>>>> Karp >>>>> >>>>> >>>>> On >>>>> Mon, >>>>> Mar >>>>> 22, >>>>> 2021 >>>>> at >>>>> 11:40 >>>>> AM >>>>> Justin >>>>> Richer >>>>> >>>> > >>>>> wrote: >>>>> >>>>> Adrian, >>>>> >>>>> >>>>> I >>>>> think >>>>> this >>>>> shows >>>>> the >>>>> problem >>>>> with >>>>> the >>>>> terminology >>>>> as >>>>> it’s >>>>> been >>>>> applied >>>>> in >>>>> this >>>>> conversation, >>>>> which >>>>> I’ve >>>>> tried >>>>> to >>>>> shine >>>>> light >>>>> on >>>>> before. >>>>> What >>>>> you >>>>> and >>>>> others >>>>> are >>>>> calling >>>>> the >>>>> “RS” >>>>> is >>>>> really >>>>> the >>>>> “AS >>>>> and >>>>> RS >>>>> working >>>>> together” >>>>> — >>>>> everything >>>>> to >>>>> the >>>>> right >>>>> of >>>>> the >>>>> line. >>>>> When >>>>> Denis >>>>> had >>>>> brought >>>>> up >>>>> “eliminating >>>>> the >>>>> AS” >>>>> in >>>>> another >>>>> thread, >>>>> what >>>>> he’d >>>>> really >>>>> done >>>>> is >>>>> labeled >>>>> everything >>>>> to >>>>> the >>>>> right >>>>> of >>>>> the >>>>> line >>>>> as >>>>> the >>>>> “RS”. >>>>> Of >>>>> course, >>>>> the >>>>> irony >>>>> here >>>>> is >>>>> that >>>>> everything >>>>> to >>>>> the >>>>> right >>>>> of >>>>> the >>>>> line >>>>> used >>>>> all >>>>> be >>>>> called >>>>> the >>>>> “AS” >>>>> or >>>>> simply >>>>> “server” >>>>> in >>>>> the >>>>> OAuth >>>>> 1 >>>>> days. >>>>> As >>>>> you >>>>> say >>>>> below, >>>>> I >>>>> don’t >>>>> want >>>>> the >>>>> client >>>>> to >>>>> have >>>>> visibility >>>>> on >>>>> what >>>>> happens >>>>> on >>>>> that >>>>> side. >>>>> >>>>> >>>>> Note >>>>> well: >>>>> The >>>>> Google+ >>>>> logo >>>>> labeled >>>>> “IdP” >>>>> in >>>>> the >>>>> diagram >>>>> is >>>>> not >>>>> the >>>>> AS, >>>>> as >>>>> far >>>>> as >>>>> GNAP >>>>> is >>>>> concerned. >>>>> It >>>>> does >>>>> not >>>>> issue >>>>> an >>>>> access >>>>> token >>>>> that >>>>> the >>>>> RS >>>>> will >>>>> accept. >>>>> The >>>>> elements >>>>> to >>>>> the >>>>> left >>>>> of >>>>> the >>>>> line >>>>> could >>>>> be >>>>> a >>>>> lot >>>>> of >>>>> things, >>>>> but >>>>> they >>>>> are >>>>> NOT >>>>> the >>>>> AS >>>>> — >>>>> by >>>>> definition. >>>>> The >>>>> client >>>>> lives >>>>> over >>>>> on >>>>> the >>>>> left, >>>>> but >>>>> so >>>>> do >>>>> any >>>>> external >>>>> inputs >>>>> to >>>>> the >>>>> AS. >>>>> These >>>>> could >>>>> be >>>>> policy >>>>> inputs >>>>> on >>>>> behalf >>>>> of >>>>> the >>>>> RO, >>>>> they >>>>> could >>>>> be >>>>> presentation >>>>> artifacts, >>>>> they >>>>> could >>>>> be >>>>> federated >>>>> logins, >>>>> they >>>>> could >>>>> be >>>>> the >>>>> output >>>>> of >>>>> policy >>>>> decisions. >>>>> How >>>>> the >>>>> AS >>>>> comes >>>>> to >>>>> trust >>>>> those >>>>> things >>>>> is >>>>> up >>>>> to >>>>> the >>>>> AS’s >>>>> implementation. >>>>> It’s >>>>> something >>>>> we >>>>> can >>>>> talk >>>>> about, >>>>> but >>>>> ultimately >>>>> GNAP >>>>> won’t >>>>> be >>>>> in >>>>> any >>>>> position >>>>> to >>>>> dictate >>>>> because >>>>> in >>>>> practice >>>>> some >>>>> AS’s >>>>> are >>>>> simply >>>>> going >>>>> to >>>>> internalize >>>>> all >>>>> policies >>>>> and >>>>> we >>>>> will >>>>> never >>>>> successfully >>>>> force >>>>> those >>>>> open. >>>>> >>>>> >>>>> But >>>>> with >>>>> all >>>>> that >>>>> in >>>>> mind, >>>>> I >>>>> think >>>>> the >>>>> key >>>>> here >>>>> is >>>>> going >>>>> to >>>>> be >>>>> looking >>>>> at >>>>> what >>>>> the >>>>> inputs >>>>> to >>>>> the >>>>> AS >>>>> are, >>>>> and >>>>> how >>>>> those >>>>> can >>>>> be >>>>> defined >>>>> in >>>>> an >>>>> interoperable >>>>> way >>>>> for >>>>> AS’s >>>>> that >>>>> can >>>>> accept >>>>> them. >>>>> I >>>>> think >>>>> there’s >>>>> a >>>>> lot >>>>> of >>>>> room >>>>> for >>>>> innovation >>>>> and >>>>> flexibility >>>>> here >>>>> that >>>>> doesn’t >>>>> break >>>>> the >>>>> trust >>>>> model >>>>> or >>>>> core >>>>> use >>>>> cases. >>>>> If >>>>> I >>>>> have >>>>> an >>>>> AS-RS >>>>> set >>>>> that >>>>> won’t >>>>> accept >>>>> my >>>>> favorite >>>>> flavor >>>>> of >>>>> policy >>>>> engine >>>>> inputs, >>>>> then >>>>> I >>>>> can >>>>> decide >>>>> not >>>>> to >>>>> use >>>>> that >>>>> one. >>>>> But >>>>> this >>>>> is >>>>> a >>>>> very >>>>> different >>>>> question >>>>> than >>>>> saying >>>>> the >>>>> RS >>>>> itself >>>>> needs >>>>> to >>>>> accept >>>>> my >>>>> own >>>>> AS >>>>> — >>>>> and >>>>> we >>>>> can’t >>>>> keep >>>>> conflating >>>>> these >>>>> two >>>>> models. >>>>> >>>>> So >>>>> to >>>>> me, >>>>> GNAP >>>>> can >>>>> support >>>>> a >>>>> Zero >>>>> Trust >>>>> Architecture >>>>> by >>>>> LEVERAGING >>>>> the >>>>> AS, >>>>> not >>>>> by >>>>> subsuming >>>>> or >>>>> eliminating >>>>> it. >>>>> It >>>>> is >>>>> in >>>>> fact >>>>> the >>>>> AS, >>>>> not >>>>> the >>>>> client >>>>> and >>>>> not >>>>> the >>>>> RS, >>>>> that >>>>> will >>>>> request >>>>> and >>>>> consume >>>>> the >>>>> results >>>>> of >>>>> a >>>>> privacy-preserving >>>>> zero-trust >>>>> policy >>>>> query >>>>> thing. >>>>> Anything >>>>> that >>>>> happens >>>>> downstream >>>>> from >>>>> that >>>>> is >>>>> of >>>>> little >>>>> concern >>>>> to >>>>> the >>>>> zero-trust >>>>> components >>>>> because, >>>>> as >>>>> you >>>>> point >>>>> out, >>>>> it’s >>>>> on >>>>> the >>>>> “other >>>>> side” >>>>> of >>>>> the >>>>> line. >>>>> >>>>> >>>>> I >>>>> think >>>>> we >>>>> got >>>>> this >>>>> basic >>>>> component >>>>> model >>>>> pretty >>>>> right >>>>> in >>>>> OAuth: >>>>> the >>>>> AS >>>>> and >>>>> RS >>>>> and >>>>> client >>>>> working >>>>> together. >>>>> Where >>>>> OAuth >>>>> misses >>>>> the >>>>> mark >>>>> is >>>>> the >>>>> assumption >>>>> that >>>>> the >>>>> user >>>>> has >>>>> to >>>>> log >>>>> in >>>>> to >>>>> the >>>>> AS >>>>> through >>>>> a >>>>> webpage >>>>> and >>>>> interact >>>>> directly, >>>>> thereby >>>>> proving >>>>> they’re >>>>> the >>>>> RO. >>>>> It’s >>>>> this >>>>> latter >>>>> space >>>>> where >>>>> I >>>>> think >>>>> we >>>>> can >>>>> both >>>>> push >>>>> innovation >>>>> and >>>>> also >>>>> address >>>>> the >>>>> important >>>>> and >>>>> compelling >>>>> use >>>>> cases >>>>> like >>>>> the >>>>> ones >>>>> you’re >>>>> bringing. >>>>> >>>>>  — >>>>> Justin >>>>> >>>>>> On >>>>>> Mar >>>>>> 22, >>>>>> 2021, >>>>>> at >>>>>> 2:14 >>>>>> PM, >>>>>> Adrian >>>>>> Gropper >>>>>> >>>>> > >>>>>> wrote: >>>>>> >>>>>> I'm >>>>>> sorry, >>>>>> Justin. >>>>>> As >>>>>> a >>>>>> Resource >>>>>> Owner, >>>>>> I >>>>>> look >>>>>> at >>>>>> the >>>>>> RS >>>>>> trust >>>>>> boundary >>>>>> (the >>>>>> dotted >>>>>> line >>>>>> in >>>>>> the >>>>>> diagram) >>>>>> as >>>>>> being >>>>>> the >>>>>> RS. >>>>>> I >>>>>> don't >>>>>> expect >>>>>> any >>>>>> visibility >>>>>> into >>>>>> what's >>>>>> going >>>>>> on >>>>>> on >>>>>> the right. >>>>>> >>>>>> >>>>>> My >>>>>> problem >>>>>> with >>>>>> the >>>>>> framing >>>>>> you >>>>>> propose >>>>>> is >>>>>> that >>>>>> requests >>>>>> are >>>>>> going >>>>>> to >>>>>> the >>>>>> RS >>>>>> (or >>>>>> the >>>>>> AS-RS) >>>>>> and >>>>>> I >>>>>> don't >>>>>> want >>>>>> to >>>>>> share >>>>>> my >>>>>> policies >>>>>> with >>>>>> the >>>>>> AS-RS. >>>>>> I >>>>>> want >>>>>> to >>>>>> keep >>>>>> the >>>>>> RS >>>>>> and >>>>>> AS-RS >>>>>> as >>>>>> ignorant >>>>>> as >>>>>> possible. >>>>>> >>>>>> Adrian >>>>>> >>>>>> On >>>>>> Mon, >>>>>> Mar >>>>>> 22, >>>>>> 2021 >>>>>> at >>>>>> 1:48 >>>>>> PM >>>>>> Justin >>>>>> Richer >>>>>> >>>>> > >>>>>> wrote: >>>>>> >>>>>> Adrian, >>>>>> >>>>>> >>>>>> What >>>>>> you’re >>>>>> discussing >>>>>> below, >>>>>> in >>>>>> terms >>>>>> of >>>>>> logging >>>>>> in >>>>>> to >>>>>> a >>>>>> site, >>>>>> is >>>>>> not >>>>>> approaching >>>>>> the >>>>>> RS. >>>>>> You >>>>>> are >>>>>> in >>>>>> fact >>>>>> approaching >>>>>> the >>>>>> client, >>>>>> and >>>>>> identifying >>>>>> both >>>>>> the >>>>>> AS >>>>>> and >>>>>> RS >>>>>> to >>>>>> the >>>>>> client. >>>>>> The >>>>>> client >>>>>> is >>>>>> a >>>>>> client >>>>>> /of >>>>>> your >>>>>> identity/ >>>>>> in >>>>>> this >>>>>> model, >>>>>> and >>>>>> the >>>>>> RS >>>>>> is >>>>>> part >>>>>> of >>>>>> the >>>>>> identity >>>>>> provider. >>>>>> It’s >>>>>> really >>>>>> important >>>>>> that >>>>>> we >>>>>> don’t >>>>>> conflate >>>>>> the >>>>>> RS >>>>>> and >>>>>> client >>>>>> in >>>>>> this >>>>>> way >>>>>> as >>>>>> it >>>>>> leads >>>>>> to >>>>>> a >>>>>> lot >>>>>> of >>>>>> confusion >>>>>> downstream >>>>>> and >>>>>> a >>>>>> lot >>>>>> of >>>>>> broken >>>>>> trust >>>>>> boundaries. >>>>>> >>>>>> With >>>>>> that >>>>>> model >>>>>> in >>>>>> mind, >>>>>> approaching >>>>>> the >>>>>> “RS" >>>>>> and >>>>>> providing >>>>>> it >>>>>> your >>>>>> identity >>>>>> is >>>>>> really >>>>>> just >>>>>> a >>>>>> case >>>>>> of >>>>>> the >>>>>> “federated >>>>>> login >>>>>> to >>>>>> AS” >>>>>> pattern >>>>>> that >>>>>> we >>>>>> discussed >>>>>> on >>>>>> the >>>>>> WG >>>>>> call. >>>>>> The >>>>>> user >>>>>> here >>>>>> approaches >>>>>> an >>>>>> RS, >>>>>> which >>>>>> has >>>>>> its >>>>>> own >>>>>> AS. >>>>>> To >>>>>> share >>>>>> things >>>>>> from >>>>>> this >>>>>> RS, >>>>>> the >>>>>> RO >>>>>> has >>>>>> to >>>>>> authenticate >>>>>> to >>>>>> the >>>>>> RS’s >>>>>> AS. >>>>>> This >>>>>> particular >>>>>> AS >>>>>> allows >>>>>> the >>>>>> RO >>>>>> to >>>>>> do >>>>>> so >>>>>> using >>>>>> an >>>>>> external >>>>>> identity >>>>>> — >>>>>> in >>>>>> which >>>>>> case, >>>>>> the >>>>>> AS >>>>>> is >>>>>> now >>>>>> a >>>>>> “client” >>>>>> of >>>>>> a >>>>>> separate, >>>>>> disconnected >>>>>> (but >>>>>> layered) >>>>>> delegation. >>>>>> The >>>>>> ultimate >>>>>> client >>>>>> that >>>>>> eventually >>>>>> calls >>>>>> the >>>>>> RS >>>>>> down >>>>>> the >>>>>> way >>>>>> may >>>>>> or >>>>>> may >>>>>> not >>>>>> know >>>>>> about >>>>>> these >>>>>> layers. >>>>>> >>>>>> >>>>>> >>>>>> This >>>>>> same >>>>>> AS, >>>>>> which >>>>>> is >>>>>> closely >>>>>> tied >>>>>> to >>>>>> the >>>>>> RS >>>>>> and >>>>>> trusted >>>>>> by >>>>>> the >>>>>> RS, >>>>>> might >>>>>> also >>>>>> take >>>>>> in >>>>>> FIDO >>>>>> credentials, >>>>>> or >>>>>> DIDs, >>>>>> or >>>>>> any >>>>>> number >>>>>> of >>>>>> other >>>>>> proof >>>>>> mechanisms. >>>>>> The >>>>>> output >>>>>> of >>>>>> this >>>>>> is >>>>>> an >>>>>> access >>>>>> token >>>>>> the >>>>>> RS >>>>>> trusts, >>>>>> but >>>>>> the >>>>>> input >>>>>> is >>>>>> up >>>>>> to >>>>>> the >>>>>> AS. >>>>>> The >>>>>> RS >>>>>> is >>>>>> not >>>>>> what >>>>>> you’re >>>>>> logging >>>>>> in >>>>>> to. >>>>>> >>>>>>  — >>>>>> Justin >>>>>> >>>>>>> On >>>>>>> Mar >>>>>>> 22, >>>>>>> 2021, >>>>>>> at >>>>>>> 1:28 >>>>>>> PM, >>>>>>> Adrian >>>>>>> Gropper >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> I >>>>>>> too >>>>>>> am >>>>>>> in >>>>>>> favor >>>>>>> of >>>>>>> avoiding >>>>>>> consolidation >>>>>>> and >>>>>>> correlation. >>>>>>> Right >>>>>>> now, >>>>>>> when >>>>>>> I >>>>>>> approach >>>>>>> a >>>>>>> service >>>>>>> provider >>>>>>> (RS) >>>>>>> for >>>>>>> the >>>>>>> first >>>>>>> time, >>>>>>> I'm >>>>>>> offered >>>>>>> the >>>>>>> opportunity >>>>>>> to >>>>>>> identify >>>>>>> my >>>>>>> persona >>>>>>> as: >>>>>>> email, >>>>>>> sign-in >>>>>>> with >>>>>>> Google, >>>>>>> Facebook, >>>>>>> or >>>>>>> Apple. >>>>>>> I >>>>>>> know >>>>>>> there >>>>>>> are >>>>>>> people >>>>>>> who >>>>>>> try >>>>>>> to >>>>>>> create >>>>>>> one-off >>>>>>> email >>>>>>> addresses >>>>>>> but >>>>>>> that >>>>>>> is >>>>>>> mostly >>>>>>> a >>>>>>> waste >>>>>>> of >>>>>>> time. >>>>>>> >>>>>>> >>>>>>> So, >>>>>>> along >>>>>>> come >>>>>>> FIDO2 >>>>>>> and >>>>>>> DID >>>>>>> wallets >>>>>>> to >>>>>>> the >>>>>>> rescue. >>>>>>> Now, >>>>>>> in >>>>>>> theory, >>>>>>> I >>>>>>> have >>>>>>> a >>>>>>> way >>>>>>> to >>>>>>> start >>>>>>> out >>>>>>> my >>>>>>> RS >>>>>>> relationship >>>>>>> pseudonymously. >>>>>>> >>>>>>> >>>>>>> When >>>>>>> I >>>>>>> want >>>>>>> my >>>>>>> resource >>>>>>> to >>>>>>> be >>>>>>> discovered >>>>>>> or >>>>>>> shared >>>>>>> I >>>>>>> will >>>>>>> post >>>>>>> that >>>>>>> RS >>>>>>> URL >>>>>>> including >>>>>>> my >>>>>>> pseudonym. >>>>>>> If >>>>>>> I >>>>>>> then >>>>>>> want >>>>>>> to >>>>>>> introduce >>>>>>> a >>>>>>> mediator in >>>>>>> front >>>>>>> of >>>>>>> my >>>>>>> AS >>>>>>> or >>>>>>> messaging >>>>>>> service endpoint, >>>>>>> I >>>>>>> have >>>>>>> that >>>>>>> option. >>>>>>> If >>>>>>> I >>>>>>> want >>>>>>> to >>>>>>> keep >>>>>>> requests >>>>>>> away >>>>>>> from >>>>>>> the >>>>>>> mediator, >>>>>>> I >>>>>>> would >>>>>>> publish >>>>>>> an >>>>>>> encryption >>>>>>> key >>>>>>> along >>>>>>> with >>>>>>> my >>>>>>> pseudonym. >>>>>>> >>>>>>> - >>>>>>> Adrian >>>>>>> >>>>>>> >>>>>>> >>>>>>> On >>>>>>> Mon, >>>>>>> Mar >>>>>>> 22, >>>>>>> 2021 >>>>>>> at >>>>>>> 9:55 >>>>>>> AM >>>>>>> Justin >>>>>>> Richer >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> On >>>>>>> Mar >>>>>>> 21, >>>>>>> 2021, >>>>>>> at >>>>>>> 1:18 >>>>>>> PM, >>>>>>> Benjamin >>>>>>> Kaduk >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> > >>>>>>> >>>>>>> > >>>>>>> On >>>>>>> Sat, >>>>>>> Mar >>>>>>> 20, >>>>>>> 2021 >>>>>>> at >>>>>>> 01:07:42AM >>>>>>> -0400, >>>>>>> Adrian >>>>>>> Gropper >>>>>>> wrote: >>>>>>> >> >>>>>>> @Alan >>>>>>> Karp >>>>>>> >>>>>> > >>>>>>> shared >>>>>>> a >>>>>>> talk >>>>>>> about >>>>>>> the >>>>>>> Principle >>>>>>> Of >>>>>>> Least >>>>>>> >> >>>>>>> Authority >>>>>>> (POLA) >>>>>>> in >>>>>>> a >>>>>>> recent >>>>>>> comment >>>>>>> >> >>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-803099693 >>>>>>> >>>>>>> >> >>>>>>> I >>>>>>> recommend >>>>>>> it. >>>>>>> >> >>>>>>> >>>>>>> >> >>>>>>> We >>>>>>> might >>>>>>> expect >>>>>>> a >>>>>>> protocol >>>>>>> with >>>>>>> authorization >>>>>>> in >>>>>>> the >>>>>>> title >>>>>>> to >>>>>>> use >>>>>>> authority >>>>>>> >> >>>>>>> as >>>>>>> a >>>>>>> core >>>>>>> principle. >>>>>>> I >>>>>>> advocate >>>>>>> for >>>>>>> a >>>>>>> GNAP >>>>>>> design >>>>>>> that >>>>>>> maximizes >>>>>>> the >>>>>>> power >>>>>>> >> >>>>>>> of >>>>>>> the >>>>>>> RO, >>>>>>> to >>>>>>> be >>>>>>> seen >>>>>>> as >>>>>>> a >>>>>>> human >>>>>>> rights >>>>>>> issue >>>>>>> when >>>>>>> the >>>>>>> RO >>>>>>> is >>>>>>> a >>>>>>> human. >>>>>>> This >>>>>>> >> >>>>>>> causes >>>>>>> me >>>>>>> to >>>>>>> ask >>>>>>> how >>>>>>> to >>>>>>> combine >>>>>>> better >>>>>>> security >>>>>>> with >>>>>>> better >>>>>>> human >>>>>>> rights >>>>>>> in >>>>>>> >> >>>>>>> GNAP. >>>>>>> >> >>>>>>> >>>>>>> >> >>>>>>> Who >>>>>>> should >>>>>>> have >>>>>>> the >>>>>>> least >>>>>>> authority >>>>>>> in >>>>>>> the >>>>>>> GNAP >>>>>>> design? >>>>>>> >> >>>>>>> >>>>>>> >> >>>>>>> The >>>>>>> AS >>>>>>> derives >>>>>>> authority >>>>>>> as >>>>>>> a >>>>>>> delegate >>>>>>> of >>>>>>> the >>>>>>> RO. >>>>>>> If >>>>>>> we >>>>>>> ask >>>>>>> the >>>>>>> RO >>>>>>> to >>>>>>> >> >>>>>>> partition >>>>>>> limited >>>>>>> authority >>>>>>> across >>>>>>> dozens >>>>>>> of >>>>>>> different >>>>>>> ASs >>>>>>> by >>>>>>> domain >>>>>>> and >>>>>>> >> >>>>>>> function, >>>>>>> then >>>>>>> we >>>>>>> are >>>>>>> not >>>>>>> using >>>>>>> technology >>>>>>> to >>>>>>> empower >>>>>>> the >>>>>>> individual. >>>>>>> >> >>>>>>> Probably >>>>>>> the >>>>>>> opposite, >>>>>>> as >>>>>>> we >>>>>>> introduce >>>>>>> consent >>>>>>> fatigue >>>>>>> and >>>>>>> burden >>>>>>> normal >>>>>>> >> >>>>>>> people >>>>>>> to >>>>>>> partition >>>>>>> their >>>>>>> lives >>>>>>> into >>>>>>> non-overlapping >>>>>>> domains. >>>>>>> >> >>>>>>> >>>>>>> >> >>>>>>> My >>>>>>> experience >>>>>>> says >>>>>>> we >>>>>>> should >>>>>>> aim >>>>>>> for >>>>>>> one >>>>>>> AS >>>>>>> per >>>>>>> persona >>>>>>> because >>>>>>> that >>>>>>> maps >>>>>>> >> >>>>>>> into >>>>>>> the >>>>>>> way >>>>>>> we >>>>>>> manage >>>>>>> our >>>>>>> public >>>>>>> and >>>>>>> private >>>>>>> identities. >>>>>>> POLA >>>>>>> would >>>>>>> then >>>>>>> >> >>>>>>> teach >>>>>>> care >>>>>>> in >>>>>>> keeping >>>>>>> ASs >>>>>>> and >>>>>>> RSs >>>>>>> related >>>>>>> to >>>>>>> work >>>>>>> / >>>>>>> public >>>>>>> separate >>>>>>> from >>>>>>> >> >>>>>>> ASs >>>>>>> and >>>>>>> RSs >>>>>>> related >>>>>>> to >>>>>>> private >>>>>>> life >>>>>>> so >>>>>>> that >>>>>>> a >>>>>>> policy >>>>>>> vulnerability >>>>>>> in >>>>>>> our >>>>>>> >> >>>>>>> delegation >>>>>>> to >>>>>>> an >>>>>>> AS >>>>>>> would >>>>>>> have >>>>>>> the >>>>>>> least >>>>>>> likelihood >>>>>>> of >>>>>>> harm. >>>>>>> > >>>>>>> >>>>>>> > >>>>>>> Thinking >>>>>>> about >>>>>>> how >>>>>>> least >>>>>>> authority/least >>>>>>> privilege >>>>>>> would >>>>>>> apply >>>>>>> to >>>>>>> GNAP >>>>>>> > >>>>>>> seems >>>>>>> like >>>>>>> a >>>>>>> useful >>>>>>> exercise.  >>>>>>> I >>>>>>> do >>>>>>> want >>>>>>> to >>>>>>> point >>>>>>> out >>>>>>> some >>>>>>> potential >>>>>>> > >>>>>>> pitfalls >>>>>>> with >>>>>>> one-AS-per-persona >>>>>>> that >>>>>>> we >>>>>>> can >>>>>>> also >>>>>>> be >>>>>>> aware >>>>>>> of.  >>>>>>> If >>>>>>> > >>>>>>> one-AS-per-persona >>>>>>> becomes >>>>>>> one-persona-per-AS >>>>>>> as >>>>>>> well, >>>>>>> then >>>>>>> the >>>>>>> AS's >>>>>>> > >>>>>>> identity >>>>>>> in >>>>>>> effect >>>>>>> also >>>>>>> serves >>>>>>> as >>>>>>> a >>>>>>> persona >>>>>>> identity >>>>>>> and >>>>>>> there >>>>>>> are >>>>>>> privacy >>>>>>> > >>>>>>> considerations >>>>>>> to >>>>>>> that.  >>>>>>> If, >>>>>>> on >>>>>>> the >>>>>>> other >>>>>>> hand, >>>>>>> the >>>>>>> > >>>>>>> multiple-personas-per-AS >>>>>>> (presumably >>>>>>> corresponding >>>>>>> to >>>>>>> multiple >>>>>>> humans) >>>>>>> > >>>>>>> route >>>>>>> is >>>>>>> taken, >>>>>>> we >>>>>>> should >>>>>>> consider >>>>>>> whether >>>>>>> that >>>>>>> would >>>>>>> lead >>>>>>> to >>>>>>> various >>>>>>> > >>>>>>> (e.g., >>>>>>> market) >>>>>>> forces >>>>>>> driving >>>>>>> consolidation >>>>>>> to >>>>>>> just >>>>>>> a >>>>>>> handful >>>>>>> of >>>>>>> > >>>>>>> super-popular >>>>>>> AS >>>>>>> services. >>>>>>> That >>>>>>> topic >>>>>>> is >>>>>>> a >>>>>>> current >>>>>>> matter >>>>>>> of >>>>>>> concern >>>>>>> to >>>>>>> > >>>>>>> some >>>>>>> IETF >>>>>>> participants. >>>>>>> > >>>>>>> >>>>>>> >>>>>>> Hi >>>>>>> Ben, >>>>>>> big >>>>>>> +1 >>>>>>> to >>>>>>> this. >>>>>>> This >>>>>>> is >>>>>>> something >>>>>>> that >>>>>>> we >>>>>>> discussed >>>>>>> ages >>>>>>> ago >>>>>>> in >>>>>>> the >>>>>>> UMA >>>>>>> working >>>>>>> group, >>>>>>> and >>>>>>> it’s >>>>>>> one >>>>>>> of >>>>>>> the >>>>>>> biggest >>>>>>> problems >>>>>>> with >>>>>>> the >>>>>>> personal >>>>>>> AS >>>>>>> (and >>>>>>> personal >>>>>>> data >>>>>>> store) >>>>>>> model. >>>>>>> This >>>>>>> kind >>>>>>> of >>>>>>> thing >>>>>>> makes >>>>>>> RS-first >>>>>>> trust >>>>>>> models >>>>>>> really >>>>>>> difficult >>>>>>> in >>>>>>> practice. >>>>>>> >>>>>>> As >>>>>>> a >>>>>>> strawman, >>>>>>> let’s >>>>>>> say >>>>>>> that >>>>>>> I’ve >>>>>>> got >>>>>>> software >>>>>>> that >>>>>>> wants >>>>>>> to >>>>>>> access >>>>>>> my >>>>>>> medical >>>>>>> information. >>>>>>> It >>>>>>> calls >>>>>>> an >>>>>>> RS >>>>>>> and >>>>>>> requests >>>>>>> access, >>>>>>> but >>>>>>> it >>>>>>> hasn’t >>>>>>> been >>>>>>> granted >>>>>>> anything >>>>>>> yet. >>>>>>> Now >>>>>>> I >>>>>>> as >>>>>>> the >>>>>>> RO >>>>>>> have >>>>>>> set >>>>>>> up >>>>>>> the >>>>>>> RS >>>>>>> so >>>>>>> that >>>>>>> it >>>>>>> talks >>>>>>> to >>>>>>> my >>>>>>> personal >>>>>>> AS, >>>>>>> that >>>>>>> only >>>>>>> I >>>>>>> use. >>>>>>> In >>>>>>> addition >>>>>>> to >>>>>>> the >>>>>>> RS >>>>>>> having >>>>>>> to >>>>>>> be >>>>>>> able >>>>>>> to >>>>>>> figure >>>>>>> out >>>>>>> which >>>>>>> medical >>>>>>> records >>>>>>> are >>>>>>> being >>>>>>> requested >>>>>>> from >>>>>>> the >>>>>>> context >>>>>>> of >>>>>>> the >>>>>>> unauthenticated >>>>>>> request >>>>>>> (which >>>>>>> means >>>>>>> it >>>>>>> needs >>>>>>> identifiers >>>>>>> in >>>>>>> the >>>>>>> URL >>>>>>> or >>>>>>> something >>>>>>> similar >>>>>>> for >>>>>>> the >>>>>>> RS >>>>>>> to >>>>>>> be >>>>>>> able >>>>>>> to >>>>>>> tell, >>>>>>> assuming >>>>>>> that >>>>>>> it >>>>>>> protects >>>>>>> data >>>>>>> for >>>>>>> more >>>>>>> than >>>>>>> one >>>>>>> person). >>>>>>> So >>>>>>> this >>>>>>> client >>>>>>> software >>>>>>> doesn’t >>>>>>> know >>>>>>> who >>>>>>> I >>>>>>> am >>>>>>> and >>>>>>> doesn’t >>>>>>> know >>>>>>> my >>>>>>> medical >>>>>>> record >>>>>>> information, >>>>>>> makes >>>>>>> a >>>>>>> completely >>>>>>> unauthorized >>>>>>> request >>>>>>> to >>>>>>> the >>>>>>> RS, >>>>>>> and >>>>>>> the >>>>>>> RS >>>>>>> says >>>>>>> “Go >>>>>>> to >>>>>>> Justin’s >>>>>>> personal >>>>>>> AS >>>>>>> to >>>>>>> get >>>>>>> a >>>>>>> token”. >>>>>>> The >>>>>>> client >>>>>>> can >>>>>>> now >>>>>>> make >>>>>>> a >>>>>>> direct >>>>>>> correlation >>>>>>> between >>>>>>> the >>>>>>> data >>>>>>> that’s >>>>>>> being >>>>>>> protected >>>>>>> at >>>>>>> the >>>>>>> RS >>>>>>> and >>>>>>> the >>>>>>> person >>>>>>> running >>>>>>> the >>>>>>> AS >>>>>>> that >>>>>>> protects >>>>>>> it. >>>>>>> Importantly, >>>>>>> this >>>>>>> client >>>>>>> makes >>>>>>> this >>>>>>> call >>>>>>> with >>>>>>> no >>>>>>> prior >>>>>>> relationship >>>>>>> to >>>>>>> the >>>>>>> RS >>>>>>> and >>>>>>> no >>>>>>> really >>>>>>> auditable >>>>>>> way >>>>>>> to >>>>>>> track >>>>>>> it >>>>>>> down >>>>>>> after >>>>>>> the >>>>>>> fact. >>>>>>> This >>>>>>> is >>>>>>> a >>>>>>> design >>>>>>> feature >>>>>>> in >>>>>>> the >>>>>>> good >>>>>>> case, >>>>>>> and >>>>>>> terrifying >>>>>>> in >>>>>>> the >>>>>>> bad >>>>>>> case. >>>>>>> >>>>>>> If >>>>>>> the >>>>>>> RS >>>>>>> instead >>>>>>> says >>>>>>> “welcome >>>>>>> to >>>>>>> Medicine >>>>>>> Doctor >>>>>>> RS, >>>>>>> please >>>>>>> talk >>>>>>> to >>>>>>> the >>>>>>> Medicine >>>>>>> Doctor >>>>>>> AS >>>>>>> to >>>>>>> get >>>>>>> access”, >>>>>>> we >>>>>>> haven’t >>>>>>> exposed >>>>>>> anything >>>>>>> at >>>>>>> all. >>>>>>> And >>>>>>> from >>>>>>> the >>>>>>> perspective >>>>>>> of >>>>>>> both >>>>>>> the >>>>>>> patient >>>>>>> and >>>>>>> the >>>>>>> RS, >>>>>>> this >>>>>>> is >>>>>>> more >>>>>>> privacy-preserving, >>>>>>> and >>>>>>> it’s >>>>>>> really >>>>>>> the >>>>>>> least >>>>>>> surprising >>>>>>> option. >>>>>>> Once >>>>>>> the >>>>>>> client >>>>>>> gets >>>>>>> to >>>>>>> the >>>>>>> AS, >>>>>>> it >>>>>>> can >>>>>>> start >>>>>>> a >>>>>>> negotiation >>>>>>> of >>>>>>> figuring >>>>>>> out >>>>>>> who >>>>>>> the >>>>>>> RO >>>>>>> is >>>>>>> for >>>>>>> the >>>>>>> information >>>>>>> being >>>>>>> accessed. >>>>>>> >>>>>>> On >>>>>>> top >>>>>>> of >>>>>>> this, >>>>>>> the >>>>>>> usability >>>>>>> expectations >>>>>>> of >>>>>>> people >>>>>>> managing >>>>>>> their >>>>>>> own >>>>>>> AS, >>>>>>> or >>>>>>> set >>>>>>> of >>>>>>> AS’s >>>>>>> for >>>>>>> multiple >>>>>>> personas >>>>>>> to >>>>>>> keep >>>>>>> things >>>>>>> separate, >>>>>>> is >>>>>>> a >>>>>>> huge >>>>>>> burden. >>>>>>> Even >>>>>>> in >>>>>>> the >>>>>>> tech >>>>>>> community, >>>>>>> I >>>>>>> know >>>>>>> people >>>>>>> who >>>>>>> can’t >>>>>>> reliably >>>>>>> manage >>>>>>> more >>>>>>> than >>>>>>> one >>>>>>> email >>>>>>> address >>>>>>> for >>>>>>> different >>>>>>> purposes. >>>>>>> I >>>>>>> wouldn’t >>>>>>> expect >>>>>>> my >>>>>>> partner >>>>>>> to >>>>>>> do >>>>>>> that >>>>>>> — >>>>>>> they >>>>>>> have >>>>>>> trouble >>>>>>> enough >>>>>>> balancing >>>>>>> all >>>>>>> the >>>>>>> logins >>>>>>> and >>>>>>> sessions >>>>>>> required >>>>>>> for >>>>>>> different >>>>>>> kids >>>>>>> remote >>>>>>> schooling, >>>>>>> I >>>>>>> couldn’t >>>>>>> imagine >>>>>>> them >>>>>>> having >>>>>>> to >>>>>>> understand >>>>>>> all >>>>>>> the >>>>>>> requirements >>>>>>> for >>>>>>> managing >>>>>>> multiple >>>>>>> authorization >>>>>>> servers >>>>>>> and >>>>>>> associated >>>>>>> policies. >>>>>>> I >>>>>>> also >>>>>>> don’t >>>>>>> expect >>>>>>> any >>>>>>> person >>>>>>> to >>>>>>> “manage >>>>>>> keys” >>>>>>> — >>>>>>> I’ve >>>>>>> been >>>>>>> on >>>>>>> the >>>>>>> internet >>>>>>> for >>>>>>> decades >>>>>>> and >>>>>>> I >>>>>>> can >>>>>>> barely >>>>>>> keep >>>>>>> tabs >>>>>>> on >>>>>>> my >>>>>>> GPG >>>>>>> keys, >>>>>>> and >>>>>>> only >>>>>>> use >>>>>>> them >>>>>>> when >>>>>>> I >>>>>>> am >>>>>>> forced >>>>>>> to. >>>>>>> This >>>>>>> is >>>>>>> exactly >>>>>>> the >>>>>>> kind >>>>>>> of >>>>>>> “market >>>>>>> pressure” >>>>>>> that >>>>>>> I >>>>>>> think >>>>>>> Ben >>>>>>> mentions >>>>>>> above, >>>>>>> people >>>>>>> will >>>>>>> just >>>>>>> want >>>>>>> to >>>>>>> outsource >>>>>>> that >>>>>>> to >>>>>>> someone >>>>>>> else, >>>>>>> and >>>>>>> the >>>>>>> reality >>>>>>> will >>>>>>> be >>>>>>> a >>>>>>> few >>>>>>> popular >>>>>>> providers. >>>>>>> >>>>>>> In >>>>>>> which >>>>>>> case, >>>>>>> we >>>>>>> could >>>>>>> end >>>>>>> up >>>>>>> doing >>>>>>> a >>>>>>> ton >>>>>>> of >>>>>>> work >>>>>>> to >>>>>>> allow >>>>>>> an >>>>>>> RS >>>>>>> choice >>>>>>> only >>>>>>> to >>>>>>> end >>>>>>> up >>>>>>> with >>>>>>> a >>>>>>> world >>>>>>> where >>>>>>> the >>>>>>> RS >>>>>>> ends >>>>>>> up >>>>>>> making >>>>>>> a >>>>>>> limited >>>>>>> choice >>>>>>> anyway. >>>>>>> We >>>>>>> see >>>>>>> how >>>>>>> that >>>>>>> plays >>>>>>> out >>>>>>> with >>>>>>> OpenID >>>>>>> Connect >>>>>>> — >>>>>>> RP’s >>>>>>> could >>>>>>> allow >>>>>>> arbitrary >>>>>>> IdPs >>>>>>> but >>>>>>> they >>>>>>> choose >>>>>>> Google >>>>>>> because >>>>>>> it >>>>>>> works >>>>>>> and >>>>>>> that’s >>>>>>> where >>>>>>> the >>>>>>> users >>>>>>> are. >>>>>>> (And >>>>>>> that’s >>>>>>> not >>>>>>> to >>>>>>> say >>>>>>> anything >>>>>>> of >>>>>>> the >>>>>>> proprietary >>>>>>> OIDC-like >>>>>>> protocols, >>>>>>> but >>>>>>> that’s >>>>>>> another >>>>>>> discussion). >>>>>>> >>>>>>> For >>>>>>> further >>>>>>> reading >>>>>>> on >>>>>>> these >>>>>>> topics, >>>>>>> I >>>>>>> recommend >>>>>>> both >>>>>>> “Why >>>>>>> Johnny >>>>>>> Can’t >>>>>>> Encrypt” >>>>>>> and >>>>>>> “Why >>>>>>> CSCW >>>>>>> Systems >>>>>>> Fail”. >>>>>>> >>>>>>> So >>>>>>> what >>>>>>> does >>>>>>> this >>>>>>> have >>>>>>> to >>>>>>> do >>>>>>> with >>>>>>> GNAP? >>>>>>> I >>>>>>> think >>>>>>> we >>>>>>> can >>>>>>> be >>>>>>> clear-eyed >>>>>>> on >>>>>>> what >>>>>>> kinds >>>>>>> of >>>>>>> expectations >>>>>>> we >>>>>>> have >>>>>>> for >>>>>>> the >>>>>>> participants. >>>>>>> If >>>>>>> we >>>>>>> expect >>>>>>> users >>>>>>> (RO’s) >>>>>>> to >>>>>>> have >>>>>>> to >>>>>>> set >>>>>>> up >>>>>>> the >>>>>>> AS-RS >>>>>>> relationship, >>>>>>> or >>>>>>> expect >>>>>>> them >>>>>>> to >>>>>>> carry >>>>>>> their >>>>>>> AS, >>>>>>> or >>>>>>> manage >>>>>>> their >>>>>>> personal >>>>>>> keys >>>>>>> — >>>>>>> I >>>>>>> think >>>>>>> we’ve >>>>>>> lost >>>>>>> the >>>>>>> battle >>>>>>> for >>>>>>> relevance. >>>>>>> >>>>>>>  — >>>>>>> Justin >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> >>>>> 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 >>>>> >>>>> >>>> >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >> > > --------------93F7E09FFA01472A6B23BD51 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
    Hi everybody,

    The content of this thread has nothing to do any more with its original title which was: "Will GNAP support Zero Trust Architecture?"
    Since I am going to use some sentences of this thread to open a new topic, I changed the title of this thread into :
    "Relationship between Authentication and Authorization ?"

    At the moment, I got the impression that nobody agrees any more about what GNAP is or is not, what it should address and what it should not address.
    The components of the model are becoming more numerous and hazy. A new terminology is sometimes being used, but is not yet present in the last published draft.

    I still can't understand any of the new terms that are being used (AS-RS and AS-RO), which are still left undefined.

    The last exchanges look more as conversations between workers during the construction of the Babel tower.

    Last year, my first remark was to mention that a section or an Annex explaining the common points and the differences with OAuth 2.0
    would be useful. Such section or Annex still does not exist.

    Justin wrote:
    If an RS allows a username/password HTTP Basic auth in addition to accepting access tokens, it can do so, but
    GNAP doesn’t have anything to say about the Basic auth use, or even its relation to any access tokens or RO’s or anything else.
    Let us split the end of this sentence into two parts:

    "GNAP doesn’t have anything to say about the Basic auth use":  If an authentication exchange  is necessary, the draft document should describe, for completeness,
    the HTTP error code that will be returned.

    "or even its relation to any access tokens or RO’s or anything else". Let us suppose that a RS supports FIDO as an authentication mechanism to authenticate its end-users.
    FIDO provides the major advantage that, for every RS, a different identifier is used by every end-user. This prevents end-users accounts correlations between RSs by using
    such identifiers. In practice, a FIDO identifier is a pseudonym.

    At this very moment, the RS is able to identify and authenticate its end-users using FIDO pseudonyms. Now, let us raise the following question:

    How will a RS be bootstrapped for working with a GNAP "sub" claim or a "sub_id" claim, whereas FIDO is already being used ?

    Denis


    Adrian,

    I disagree, I believe that what I have laid out is exactly separating the concerns into working components. 

    Like OAuth before it, GNAP is a protocol negotiate access for a client instance to an RS, using an AS as the facilitator of that delegated negotiation. (Unlike OAuth, it’s importantly also for negotiating user information to the client directly from the AS with no RS involved, but that’s an aside for the purposes of our conversation here).

    If a particular GNAP RS also allows other kinds of processes to enable access to it, that is completely fine, but outside of GNAP. If an RS allows a username/password HTTP Basic auth in addition to accepting access tokens, it can do so, but GNAP doesn’t have anything to say about the Basic auth use, or even its relation to any access tokens or RO’s or anything else. If an RS accepts structured access tokens signed by trusted keys that don’t come from an AS through a negotiated request — again, that’s fine, but GNAP is silent about the RS doing that. If the RS acts as “its own AS” then it’s really just an RS and an AS living in the same box. Again, that’s fine, and super common with OAuth today. 

    GNAP is solving the problem of connecting the client to the RS through means of an AS. Other solutions are possible and many of them can be deployed right alongside, but that’s not the corner of the world that GNAP is solving. GNAP should be concerned about how these other technologies can be used alongside it. I think there’s a lot of room for the things that you’re talking about, and more importantly for solving the use cases that you’re bringing. But GNAP should be more than a single-point solution, and so we need to balance these concerns. The conceptual framework of an AS that takes in lots of different information and spits out access tokens is exactly the abstraction layer that is necessary for making these use cases interoperable.

     — Justin

    On Mar 26, 2021, at 8:30 AM, Adrian Gropper <agropper@healthurl.com> wrote:

    @Justin, there’s no separation of concerns here. No partition between processor and controller. No data minimization. And, I see no obvious reason to make this the core of GNAP. 

    The one thing we can probably all agree on is that there’s only one RS and one RO. 

    The core of GNAP, in my opinion, can be built and explained around this simple design. The RS is a processor. The RO is a controller. The RS bears only security responsibility. The RS bears no privacy responsibility. The RO delegates this to the RS but this is not authorization as the A in GNAP.

    The RO retains all rights to delegate within the scope of things that the RS is willing to support using various token formats and endpoint options. Some of these options may do all sorts of things for all sorts of clients and user-agents  but these are options. 

    For example, if a request comes to the RS that is not in the form of an access token, then it either gets sent to the RO or their agent, or it gets logged and dumped. One such option, common in healthcare, is “Break the Glass” where the RS is acting as an authorization server because the user-agent is making a request instead of presenting an access token. GNAP can offer this as an option but it is not our core.

    Adrian



    On Fri, Mar 26, 2021 at 7:15 AM Justin Richer <jricher@mit.edu> wrote:
    I have a big problem with this line:

    > the RS and AS-RS only see access tokens. The requests (from RO') that resulted in an access token are none of their business.

    In the trust model we’ve been discussing, the requests that result in access tokens are solely the business of AS-RS, since AS-RS is the only entity that’s allowed, and trusted by the RS, to create access tokens for the RS. That is its entire job, the entire reason it exists in the system. By definition the party generating tokens for use at the RS is the AS for that RS, I don’t care how you deploy it. If RO wants to give access to someone else (who isn’t an “RO" anymore, they’re another end-user), then that end user’s client software will need to talk to AS-RS to get its own access token.

    Now here’s the trick: when the end user’s client instance talks to AS-RS, that does NOT mean that AS-RS needs to know all the details and policy reasons that it should give an access token to that client instance. It doesn’t even need to know the existence of another end user. It doesn’t need identity, it doesn’t need policy. Sure, it COULD handle all of that internally, and many will, but the protocol doesn’t demand it. 

    This means that the first client instance, the one that gets the access token, can also be given something alongside the access token that it can then hand to another piece of software (or to a person to hand eo their piece of software). This artifact is not an access token. This artifact could be something structured that the client understands, and can make derivatives of, and present back to the AS-RS for getting new access tokens. There could be multiple different flavors of this kind of artifact for different kinds of environments and groups. But what they all have in common is that they can potentially be used to request more access tokens within some context at the AS-RS.

     — Justin



    On Mar 25, 2021, at 5:50 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    My issue is with Alan's:
    "7. Another user agent (RO') can contact any holder of the access token or the service's policy agent (AS-RS) to get a delegated access token."

    I would prefer "7A. Another user agent (RO') can contact any holder of the access token." by default so that the AS-RS does not see the requests. In other words, the RS and AS-RS only see access tokens. The requests (from RO') that resulted in an access token are none of their business.

    The reality is that RO' can discover a resource RS and can share whatever information with RS-AS they want and the RO may not even know about it unless the RS decides to let them know somehow. This seems to be a drawback of the capabilities approach. 

    In terms of privacy and control, I, as the RO, want a contract with the RS that says that I or my agent (AS-RO) must sign an access token. This is a fundamental audit requirement. Without it, a rogue RS and AS-RS can do all sorts of things and the RO would never know. I understand that a rogue RS might not support an honest contemporaneous log of access tokens presented so there's a trust issue here that I seems unavoidable unless I specify in my RO-RS contract that they use a separate contemporaneous log such as AS-RO for every access token presented and risk being sued if they process an access token without also updating the separate log.

    - Adrian


    On Thu, Mar 25, 2021 at 1:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin Richer <jricher@mit.edu> wrote:
    Hi Alan,

    In all of my discussion, and in the spec itself, the RO is the :entity: in charge of approving rights. They’re probably a person. It might be software that makes a policy decision in some way, or a corporate entity, or something like that. But it’s not assumed to be a computational agent in the terms of the protocol itself. Would that recast what you’re saying below?

    Hmmm.  I guess not.  It's just that the person would be using some UI to express their decisions to what I called the user agent.  That model fits in very nicely with what we did with Polaris, our virus safe computing environment for Windows XP, https://dl.acm.org/doi/10.1145/1151030.1151033.  The person would click on the icon for a Word file, and an instance of Word would open with only the permission needed to edit that one file.  Same thing here.  The client could ask for permission to use the resource, or permission could be granted implicitly when the user selects a resource associated with a specific client.

    --------------
    Alan Karp


    On Thu, Mar 25, 2021 at 9:53 AM Justin Richer <jricher@mit.edu> wrote:
    Hi Alan,

    In all of my discussion, and in the spec itself, the RO is the :entity: in charge of approving rights. They’re probably a person. It might be software that makes a policy decision in some way, or a corporate entity, or something like that. But it’s not assumed to be a computational agent in the terms of the protocol itself. Would that recast what you’re saying below?

     — Justin

    On Mar 25, 2021, at 12:36 PM, Alan Karp <alanhkarp@gmail.com> wrote:

    There seems to be some confusion about how AS-RO comes into the picture, probably because of the "AS" part.  I'm going to try to clear up that confusion by more carefully explaining what I mean.

    I'm assuming that RO is a computational agent representing the person who is the resource owner, something called the "user agent" in operating systems lingo.  I'm also assuming that it's possible to do delegation, either locally or by token exchange with AS-RS.  All delegations are potentially sub-scoped, but you may also want to delegate with full scope to have a separately revocable access token.

      Here's an example of how things work in a capability oriented system.
    1. Someone, the service owner, creates a service.
    2. The service owner contracts with an policy agent (AS-RS) to create and manage access tokens for that service (RS).
    3. A person wishing to create a resource at RS uses their user agent (RO) to contact the service owner's policy agent (AS-RS) and gets back an access token for that resource.
    4. That user agent (RO) can 
      1. use that access token to invoke the resource, or
      2. delegate an access token to a client of the user agent's (RO) choice, or
      3. contract with a policy agent (AS-RO) to manage those delegations on behalf of the user agent (RO), or
      4. specify a policy with the service's policy agent (AS-RS).
    5. A client can contact any holder of the access token (the user agent (RO) or its policy agent (AS-RO)) or the service's policy agent (AS-RS) to get a delegated access token.
    6. That client can delegate that token to another client.
    7. Another user agent (RO') can contact any holder of the access token or the service's policy agent (AS-RS) to get a delegated access token.
    8. The other user agent (RO') can 
      1. use that access token to invoke the resource, or
      2. delegate it to a client of its choice, or
      3. contract with a policy agent (AS-RO') of its choosing to manage those delegations on its behalf, or
      4. specify a policy with the service's policy agent (AS-RS).
    9. and so on
    When any of these computational agents, user agents (ROs) or clients acting on their behalf, invokes the resource, AS-RS verifies that the access token is a valid delegation, i.e., proper sub-scoping, hasn't been revoked, and that it authorizes the request being made before telling the service (RS) to honor the request.  At no point does the service's policy agent (AS-RS) know which computational agent did any particular delegation.  (Token exchange can be done as anonymously as possible.)  In particular, the policy agents (AS-RO) need not be the same, or even compatible with, the service's policy agent (AS-RS).  GNAP specifies the protocol between requesters, invokers, delegators (for token exchange) of tokens and AS-RS.  That protocol need not be used between user agents (RO), clients, or other policy agents (AS-RO), but it is likely to be.

     -------------
    Alan Karp


    On Thu, Mar 25, 2021 at 5:45 AM Justin Richer <jricher@mit.edu> wrote:
    The way I’m thinking about Adrian’s use case is that what we’re calling the “AS-RO” isn’t an “AS” in the traditional OAuth/GNAP sense, at least not exactly. This is the agent that the RO can use to set policies and manage consent on their behalf, and I’ve been arguing that it fits better into this vaguely-defined “interaction component” aspect of the current AS definition, and it’s not currently separated from the AS definition. The “AS-RS” maps to what we’d call the “AS” in OAuth/GNAP traditionally, it’s what the RS trusts to issue tokens. In traditional OAuth the AS-RO and AS-RS are always the same thing, from a functional protocol perspective. An important point here is that from a client’s perspective, they’re only talking to the AS-RS since that’s where the client gets its tokens, because at the end of the day the client just wants to call the API at the RS and doesn’t care how that happens (from a protocol standpoint). 

    Note well: Even thought I don’t believe that “AS-RO” is an authorization server at all, I’m going to keep using that term below for consistency with previous discussion.

    So we have these fundamental relationships around getting the client to access the RS:

    1. RS trusts AS-RS to issue tokens that RS will accept, validate, and process for requests from client
    2. Client trusts AS-RS to issue tokens that client can use at RS
    3. RO trusts RS to protect RO’s api through delegated access

    On top of that, we’ve got some additional aspects that we’re discussing:

    4. RO trusts AS-RO to manage RO’s policies at runtime
    5. AS-RS trusts AS-RO to assert RO’s policies for access to RS
    6. Client trusts whatever AS-RS sends client to deal with, including possibly RO-AS at runtime, because of (2)

    What I have been saying is that 4/5/6 are optional details of how RS-AS runs things, and I think this also maps with Adrian’s view of choice, since if my RS’s AS-RS doesn’t allow me to plug in my own AS-RO then I would be motivated to pick a different RS who’s AS-RS lets me do just that. The same way I’d pick a different RS if their surrounding services didn’t accept my preferred federation login and I didn’t want to make another account. Of course, market forces being as they are, I might not have much of an actionable choice in RS, but GNAP can’t change that. 

    What we can do is make it possible for AS-RS to talk to AS-RO, both in philosophy of the protocol design and in concrete hooks to support (6) above. 

    Separately, we can approach the issue of making 1/2 above more dynamic. This was UMA2’s “federated authorization” approach, and is behind a lot of the “bring your own AS” models out there. The problem with these is that we know from many years of experience that most RS’s aren’t interested in doing anything of the sort.

    So with GNAP we can instead allow 4/5/6 to vary in a predictable and consistent way, letting the RS keep control over 1/2, thereby enabling choice in (3). We don’t have to be the ones who define the all of the details of every permutation of (5) to enable this, though. Some of this is going to be configuration out of band, some of it’s going to be communication at runtime. This is where VC’s, ZCAPs, CHAPI, DIDComm, FIDO, and a whole swath of other tech can come in and help out. I don’t think we need to put all the details for using these into core, nor do I think we’ll pull of The Great And Ultimate Abstraction for using these and other approaches. But we can at least start talking about “AS-RS” in such a way that it no longer assumes it’s always the same party dealing with the RO directly.

     — Justin

    On Mar 25, 2021, at 6:40 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    To reframe it closer to GNAP:
    - AS = AS-RO, that's where you find the RO policies. The AS issues access tokens to the client.
    - the RO policies could be a) defined locally or b) in relationship with the RS

    There have been several ideas related to the AS-RS relationship b:
    b1) the RS issues capabilities (which can be further attenuated by the RO)
    b2) Adrian also discussed a DID based solution
    b3) there was also an alternative ACL proposal from Denis (+ preflight)

    Fabien


    On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Ok so I get you correctly: 
    - what matters is the RQ (could be a RO or a end-user or both : we don't really care at a high-level, they're all treated as entities that make a request)
    - the policy is able to handle those different cases, based on its own internal delegation protocol
    - currently that requires AS-RS and AS-RO, but maybe it can be simplified

    To answer to Denis, here's what I understood:
    - RO trusts AS-RS (and then handles its own policies within AS-RO)
    - end-user trusts AS-RO (through its client)

    Could probably work but that's a fairly different model compared to OAuth2 (and of today's GNAP), with different frontiers between the AS and the RS. 

    Please do not hesitate to correct me if I'm wrong.

    Fabien 

    On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper <agropper@healthurl.com> wrote:
    I believe there are alternatives to having two kinds of ASs. The problem may be a side-effect of deciding to switch away form treating the RO as different from the RQ. That leads to downstream privacy issues. Our desire for architectural simplicity is admirable but that may have been a step too far.

    There may also be solutions based on different types of tokens, as in different capabilities (tokens signed by the RS) vs. tokens signed by the AS. I’m not sure about that but Alan might have more to say.

    Adrian

    On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks. The general problem statement is clear.

    The proposed solution a bit less (to me). I understood that from point 2, Alan involves 2 ASs. You said : "There’s no obvious reason to have two types of ASs". Do you see an alternative ?

    Regarding the last item, I don't think that naming RQ by end-user created the problem. It might just highlight the asymmetry, which fundamentally exists. 

    Fabien


    On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper <agropper@healthurl.com> wrote:
    Recap:
    1 - Justin (I think) introduced the idea of an AS on the RS trust boundary side.
    2 - I said the RO should not have to share policies with the RS.
    3 - Alan invented the concept of AS-RO and AS-RS to separate two kinds of PDPs. 

    The thing is that step 2 is not symmetrical. The RO has a legitimate privacy interest in keeping their policies private and minimizing the leakage of information about requests that are posed against those policies. 

    The RS, on the other hand, should be publishing its policies (e.g. what it’s selling or what jurisdiction it’s in or what tokens or scopes it supports). The RS has no obvious privacy interest in GNAP. It’s just an enforcer.

    There is one other privacy interest to consider around the RS and that is the requesting party (the end-user that is not the RO :-) might prefer to share attributes with the RS instead of the RO or something controlled by the RO. This case could be an “extension” to GNAP and might result in a split AS as a solution. This problem was introduced when the editors decided to replace RQ with end-user. Obviously, the RO end-user has no privacy interests relative to itself.

    Adrian




    On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    I was referring to "By my definition, this model has two ASs since both are processing requests into tokens". If there's no reason to have 2 types of ASs, that's fine then. 
    But I'm a bit lost in where we stand with the idea. 

    Could you recap? 

    Fabien 

    Le jeu. 25 mars 2021 à 08:16, Adrian Gropper <agropper@healthurl.com> a écrit :
    There’s no obvious reason to have two types of ASs. Any AS that is executing the policies of the RS can look to GNAP like the RS itself. Why would GNAP expose that interface to anyone? 

    Adrian

    On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Note : I'm not sure that's a good idea, but having 2 types of ASs is not that easy to grasp.

    Fabien 

    Le jeu. 25 mars 2021 à 08:07, Fabien Imbault <fabien.imbault@gmail.com> a écrit :
    The purpose of either handling policies locally or delegating them to the RO agent. 

    Le jeu. 25 mars 2021 à 08:04, Adrian Gropper <agropper@healthurl.com> a écrit :
    What purpose would be served by GNAP splitting the AS into two components?

    Adrian 

    On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Isn't the AS-RO a component of the AS? Same idea as the interact component, it functionnally belongs to the AS role but could be deployed either as a monolith or as a separate component?

    Fabien

    Le jeu. 25 mars 2021 à 04:26, Adrian Gropper <agropper@healthurl.com> a écrit :
    Yes, but I would say it’s not the RO that wants the access token. It’s the RO that wants the client making the request to get an access token. 

    Adrian

    On Wed, Mar 24, 2021 at 11:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Adrian Gropper <agropper@healthurl.com> wrote:

    In this design, the AS is the AS-RS and the agent is the AS-RO. By my definition, this model has two ASs since both are processing requests into tokens. The problem with this is complexity and privacy. The RO may not want to share the request information with the AS-RS.

    More precisely, RO has no choice but to present the required information to AS-RS if RO wants an access token.  However, RO does not want AS-RS to know the policy by which RO delegates tokens.  That's why RO uses AS-RO for those delegations.

    --------------
    Alan Karp


    On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Thank you for creating the issue. My definition of AS is independent of AS-RO or AS-RS. https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomment-806280421 I also agree with Alan's definition based on delegation. An AS-RS would be a delegate of the RS. 

    Based on that, I see it as obvious that the policy has to be accessible (defined locally?) in order for it to be run as the code that turns a request into an access token. 

    The only other possibility is that the request is packaged by the AS and sent elsewhere (an agent) for evaluation against policy and a proto-token returned. In that case the AS is acting as a proxy and the PDP is elsewhere. I can imagine that an AS-RS would behave this way so that the proto-token could be turned into an access token by the AS-RS. Isn't this what Justin is proposing? In this design, the AS is the AS-RS and the agent is the AS-RO. By my definition, this model has two ASs since both are processing requests into tokens. The problem with this is complexity and privacy. The RO may not want to share the request information with the AS-RS.

    Adrian

    On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Isn't that what the AS is supposed to be, only with the caveat that the policy is defined locally? 

    Fabien 


    Le mer. 24 mars 2021 à 20:17, Alan Karp <alanhkarp@gmail.com> a écrit :
    AS-RO is an AS that RO trusts to delegate RO's access tokens according to RO's policies.  

    --------------
    Alan Karp


    On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan and Adrian,

    I've created issue AS-RO policy delegation (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to capture your input. 
    A first question that arises: can we give a definition to AS-RO?

    Thanks
    Fabien

    On Tue, Mar 23, 2021 at 4:15 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan, 

    Yes, but in that flow, the token relationship between AS-RS and AS-RO is only secure if the tokens issued by AS-RS are cryptographically attenuable in the first place. 
     
    Attenuated delegation is a requirement, but that doesn't have to be done cryptographically.  Token exchange works just fine.  SPKI and zcap-ld are examples of the crypto approach, and we used token exchange in the system for HP.

    --------------
    Alan Karp


    On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan, 

    Yes, but in that flow, the token relationship between AS-RS and AS-RO is only secure if the tokens issued by AS-RS are cryptographically attenuable in the first place. 

    Fabien

    On Mon, Mar 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin Richer <jricher@mit.edu> wrote:

    But with all that in mind, I think the key here is going to be looking at what the inputs to the AS are, and how those can be defined in an interoperable way for AS’s that can accept them. I think there’s a lot of room for innovation and flexibility here that doesn’t break the trust model or core use cases. If I have an AS-RS set that won’t accept my favorite flavor of policy engine inputs, then I can decide not to use that one. But this is a very different question than saying the RS itself needs to accept my own AS — and we can’t keep conflating these two models.

    I agree.  The point of having an AS-RO is to allow RO to specify a policy for which of RO's access tokens should be delegated under what conditions.  AS-RS should not need to understand those policies.  The flow would be
    • RO contacts AS-RS and gets one or more access tokens.
    • RO delegates one or more of those tokens, potentially sub-scoped, to AS-RO.
    • A different user contacts AS-RO to get a potentially sub-scoped access token from AS-RO.
    • That user presents the access token delegated by AS-RO when invoking the resource.
    AS-RS only needs to verify that the delegation chain is legitimate, e.g., no increase in scope, and that it grants permission for the request being made.  AS-RS does not need to understand the policy behind granting the delegation by AS-RO.

    --------------
    Alan Karp


    On Mon, Mar 22, 2021 at 11:40 AM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    I think this shows the problem with the terminology as it’s been applied in this conversation, which I’ve tried to shine light on before. What you and others are calling the “RS” is really the “AS and RS working together” — everything to the right of the line. When Denis had brought up “eliminating the AS” in another thread, what he’d really done is labeled everything to the right of the line as the “RS”. Of course, the irony here is that everything to the right of the line used all be called the “AS” or simply “server” in the OAuth 1 days. As you say below, I don’t want the client to have visibility on what happens on that side. 

    Note well: The Google+ logo labeled “IdP” in the diagram is not the AS, as far as GNAP is concerned. It does not issue an access token that the RS will accept. The elements to the left of the line could be a lot of things, but they are NOT the AS — by definition. The client lives over on the left, but so do any external inputs to the AS. These could be policy inputs on behalf of the RO, they could be presentation artifacts, they could be federated logins, they could be the output of policy decisions. How the AS comes to trust those things is up to the AS’s implementation. It’s something we can talk about, but ultimately GNAP won’t be in any position to dictate because in practice some AS’s are simply going to internalize all policies and we will never successfully force those open. 

    But with all that in mind, I think the key here is going to be looking at what the inputs to the AS are, and how those can be defined in an interoperable way for AS’s that can accept them. I think there’s a lot of room for innovation and flexibility here that doesn’t break the trust model or core use cases. If I have an AS-RS set that won’t accept my favorite flavor of policy engine inputs, then I can decide not to use that one. But this is a very different question than saying the RS itself needs to accept my own AS — and we can’t keep conflating these two models.

    So to me, GNAP can support a Zero Trust Architecture by LEVERAGING the AS, not by subsuming or eliminating it. It is in fact the AS, not the client and not the RS, that will request and consume the results of a privacy-preserving zero-trust policy query thing. Anything that happens downstream from that is of little concern to the zero-trust components because, as you point out, it’s on the “other side” of the line. 

    I think we got this basic component model pretty right in OAuth: the AS and RS and client working together. Where OAuth misses the mark is the assumption that the user has to log in to the AS through a webpage and interact directly, thereby proving they’re the RO. It’s this latter space where I think we can both push innovation and also address the important and compelling use cases like the ones you’re bringing.

     — Justin

    On Mar 22, 2021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I'm sorry, Justin. As a Resource Owner, I look at the RS trust boundary (the dotted line in the diagram) as being the RS. I don't expect any visibility into what's going on on the right. 

    My problem with the framing you propose is that requests are going to the RS (or the AS-RS) and I don't want to share my policies with the AS-RS. I want to keep the RS and AS-RS as ignorant as possible.

    Adrian

    On Mon, Mar 22, 2021 at 1:48 PM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    What you’re discussing below, in terms of logging in to a site, is not approaching the RS. You are in fact approaching the client, and identifying both the AS and RS to the client. The client is a client of your identity in this model, and the RS is part of the identity provider. It’s really important that we don’t conflate the RS and client in this way as it leads to a lot of confusion downstream and a lot of broken trust boundaries.

    With that model in mind, approaching the “RS" and providing it your identity is really just a case of the “federated login to AS” pattern that we discussed on the WG call. The user here approaches an RS, which has its own AS. To share things from this RS, the RO has to authenticate to the RS’s AS. This particular AS allows the RO to do so using an external identity — in which case, the AS is now a “client” of a separate, disconnected (but layered) delegation. The ultimate client that eventually calls the RS down the way may or may not know about these layers. 

    <PastedGraphic-1.png>
    This same AS, which is closely tied to the RS and trusted by the RS, might also take in FIDO credentials, or DIDs, or any number of other proof mechanisms. The output of this is an access token the RS trusts, but the input is up to the AS. The RS is not what you’re logging in to.

     — Justin

    On Mar 22, 2021, at 1:28 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I too am in favor of avoiding consolidation and correlation. Right now, when I approach a service provider (RS) for the first time, I'm offered the opportunity to identify my persona as: email, sign-in with Google, Facebook, or Apple. I know there are people who try to create one-off email addresses but that is mostly a waste of time. 

    So, along come FIDO2 and DID wallets to the rescue. Now, in theory, I have a way to start out my RS relationship pseudonymously. 

    When I want my resource to be discovered or shared I will post that RS URL including my pseudonym. If I then want to introduce a mediator in front of my AS or messaging service endpoint, I have that option. If I want to keep requests away from the mediator, I would publish an encryption key along with my pseudonym.

    - Adrian



    On Mon, Mar 22, 2021 at 9:55 AM Justin Richer <jricher@mit.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhkarp@gmail.com> shared a talk about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use authority
    >> as a core principle. I advocate for a GNAP design that maximizes the power
    >> of the RO, to be seen as a human rights issue when the RO is a human. This
    >> causes me to ask how to combine better security with better human rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO to
    >> partition limited authority across dozens of different ASs by domain and
    >> function, then we are not using technology to empower the individual.
    >> Probably the opposite, as we introduce consent fatigue and burden normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because that maps
    >> into the way we manage our public and private identities. POLA would then
    >> teach care in keeping ASs and RSs related to work / public separate from
    >> ASs and RSs related to private life so that a policy vulnerability in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP
    > seems like a useful exercise.  I do want to point out some potential
    > pitfalls with one-AS-per-persona that we can also be aware of.  If
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS's
    > identity in effect also serves as a persona identity and there are privacy
    > considerations to that.  If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)
    > route is taken, we should consider whether that would lead to various
    > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.  That topic is a current matter of concern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the UMA working group, and it’s one of the biggest problems with the personal AS (and personal data store) model. This kind of thing makes RS-first trust models really difficult in practice.

    As a strawman, let’s say that I’ve got software that wants to access my medical information. It calls an RS and requests access, but it hasn’t been granted anything yet. Now I as the RO have set up the RS so that it talks to my personal AS, that only I use. In addition to the RS having to be able to figure out which medical records are being requested from the context of the unauthenticated request (which means it needs identifiers in the URL or something similar for the RS to be able to tell, assuming that it protects data for more than one person). So this client software doesn’t know who I am and doesn’t know my medical record information, makes a completely unauthorized request to the RS, and the RS says “Go to Justin’s personal AS to get a token”. The client can now make a direct correlation between the data that’s being protected at the RS and the person running the AS that protects it. Importantly, this client makes this call with no prior relationship to the RS and no really auditable way to track it down after the fact. This is a design feature in the good case, and terrifying in the bad case.

    If the RS instead says “welcome to Medicine Doctor RS, please talk to the Medicine Doctor AS to get access”, we haven’t exposed anything at all. And from the perspective of both the patient and the RS, this is more privacy-preserving, and it’s really the least surprising option. Once the client gets to the AS, it can start a negotiation of figuring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS, or set of AS’s for multiple personas to keep things separate, is a huge burden. Even in the tech community, I know people who can’t reliably manage more than one email address for different purposes. I wouldn’t expect my partner to do that — they have trouble enough balancing all the logins and sessions required for different kids remote schooling, I couldn’t imagine them having to understand all the requirements for managing multiple authorization servers and associated policies. I also don’t expect any person to “manage keys” — I’ve been on the internet for decades and I can barely keep tabs on my GPG keys, and only use them when I am forced to. This is exactly the kind of “market pressure” that I think Ben mentions above, people will just want to outsource that to someone else, and the reality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice only to end up with a world where the RS ends up making a limited choice anyway. We see how that plays out with OpenID Connect — RP’s could allow arbitrary IdPs but they choose Google because it works and that’s where the users are. (And that’s not to say anything of the proprietary OIDC-like protocols, but that’s another discussion).

    For further reading on these topics, I recommend both “Why Johnny Can’t Encrypt” and “Why CSCW Systems Fail”.

    So what does this have to do with GNAP? I think we can be clear-eyed on what kinds of expectations we have for the participants. If we expect users (RO’s) to have to set up the AS-RS relationship, or expect them to carry their AS, or manage their personal keys — I think we’ve lost the battle for relevance.

     — Justin


    --
    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


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




    --------------93F7E09FFA01472A6B23BD51-- From nobody Fri Mar 26 10:20:15 2021 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 300493A2384 for ; Fri, 26 Mar 2021 10:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 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_NONE=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 lHzmp58dOkzK for ; Fri, 26 Mar 2021 10:20:05 -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 19E5E3A2381 for ; Fri, 26 Mar 2021 10:20:03 -0700 (PDT) Received: from [192.168.1.22] (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 12QHJxVE031787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Mar 2021 13:19:59 -0400 From: Justin Richer Message-Id: <91D11E67-34AB-4426-803C-7B5A6F50537F@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_D35AE2A6-3D28-4CA0-B621-7A7525635810" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 26 Mar 2021 13:19:59 -0400 In-Reply-To: <3c103293-56a1-4be5-e2a3-12eb82d13238@free.fr> Cc: txauth@ietf.org To: Denis References: <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> <5773FA7B-6891-4227-A8CA-2F506909B8CD@mit.edu> <3c103293-56a1-4be5-e2a3-12eb82d13238@free.fr> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Relationship between Authentication and Authorization ? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2021 17:20:13 -0000 --Apple-Mail=_D35AE2A6-3D28-4CA0-B621-7A7525635810 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 GNAP doesn=E2=80=99t have anything too say about anybody authenticating = directly to the RS. If that happens, it=E2=80=99s out of the view and = out of scope of GNAP. =E2=80=94 Justin > On Mar 26, 2021, at 1:06 PM, Denis wrote: >=20 > Hi everybody, >=20 > The content of this thread has nothing to do any more with its = original title which was: "Will GNAP support Zero Trust Architecture?" > Since I am going to use some sentences of this thread to open a new = topic, I changed the title of this thread into : > "Relationship between Authentication and Authorization ?" >=20 > At the moment, I got the impression that nobody agrees any more about = what GNAP is or is not, what it should address and what it should not = address. > The components of the model are becoming more numerous and hazy. A new = terminology is sometimes being used, but is not yet present in the last = published draft. >=20 > I still can't understand any of the new terms that are being used = (AS-RS and AS-RO), which are still left undefined.=20 >=20 > The last exchanges look more as conversations between workers during = the construction of the Babel tower. >=20 > Last year, my first remark was to mention that a section or an Annex = explaining the common points and the differences with OAuth 2.0 > would be useful. Such section or Annex still does not exist. >=20 > Justin wrote: > If an RS allows a username/password HTTP Basic auth in addition to = accepting access tokens, it can do so, but=20 > GNAP doesn=E2=80=99t have anything to say about the Basic auth use, or = even its relation to any access tokens or RO=E2=80=99s or anything else. > Let us split the end of this sentence into two parts: >=20 > "GNAP doesn=E2=80=99t have anything to say about the Basic auth use": = If an authentication exchange is necessary, the draft document should = describe, for completeness, > the HTTP error code that will be returned. >=20 > "or even its relation to any access tokens or RO=E2=80=99s or anything = else". Let us suppose that a RS supports FIDO as an authentication = mechanism to authenticate its end-users. > FIDO provides the major advantage that, for every RS, a different = identifier is used by every end-user. This prevents end-users accounts = correlations between RSs by using=20 > such identifiers. In practice, a FIDO identifier is a pseudonym. >=20 > At this very moment, the RS is able to identify and authenticate its = end-users using FIDO pseudonyms. Now, let us raise the following = question:=20 >=20 > How will a RS be bootstrapped for working with a GNAP "sub" claim or a = "sub_id" claim, whereas FIDO is already being used ? > Denis >=20 >=20 >=20 >> Adrian, >>=20 >> I disagree, I believe that what I have laid out is exactly separating = the concerns into working components.=20 >>=20 >> Like OAuth before it, GNAP is a protocol negotiate access for a = client instance to an RS, using an AS as the facilitator of that = delegated negotiation. (Unlike OAuth, it=E2=80=99s importantly also for = negotiating user information to the client directly from the AS with no = RS involved, but that=E2=80=99s an aside for the purposes of our = conversation here). >>=20 >> If a particular GNAP RS also allows other kinds of processes to = enable access to it, that is completely fine, but outside of GNAP. If an = RS allows a username/password HTTP Basic auth in addition to accepting = access tokens, it can do so, but GNAP doesn=E2=80=99t have anything to = say about the Basic auth use, or even its relation to any access tokens = or RO=E2=80=99s or anything else. If an RS accepts structured access = tokens signed by trusted keys that don=E2=80=99t come from an AS through = a negotiated request =E2=80=94 again, that=E2=80=99s fine, but GNAP is = silent about the RS doing that. If the RS acts as =E2=80=9Cits own AS=E2=80= =9D then it=E2=80=99s really just an RS and an AS living in the same = box. Again, that=E2=80=99s fine, and super common with OAuth today.=20 >>=20 >> GNAP is solving the problem of connecting the client to the RS = through means of an AS. Other solutions are possible and many of them = can be deployed right alongside, but that=E2=80=99s not the corner of = the world that GNAP is solving. GNAP should be concerned about how these = other technologies can be used alongside it. I think there=E2=80=99s a = lot of room for the things that you=E2=80=99re talking about, and more = importantly for solving the use cases that you=E2=80=99re bringing. But = GNAP should be more than a single-point solution, and so we need to = balance these concerns. The conceptual framework of an AS that takes in = lots of different information and spits out access tokens is exactly the = abstraction layer that is necessary for making these use cases = interoperable. >>=20 >> =E2=80=94 Justin >>=20 >>> On Mar 26, 2021, at 8:30 AM, Adrian Gropper > wrote: >>>=20 >>> @Justin, there=E2=80=99s no separation of concerns here. No = partition between processor and controller. No data minimization. And, I = see no obvious reason to make this the core of GNAP.=20 >>>=20 >>> The one thing we can probably all agree on is that there=E2=80=99s = only one RS and one RO.=20 >>>=20 >>> The core of GNAP, in my opinion, can be built and explained around = this simple design. The RS is a processor. The RO is a controller. The = RS bears only security responsibility. The RS bears no privacy = responsibility. The RO delegates this to the RS but this is not = authorization as the A in GNAP. >>>=20 >>> The RO retains all rights to delegate within the scope of things = that the RS is willing to support using various token formats and = endpoint options. Some of these options may do all sorts of things for = all sorts of clients and user-agents but these are options.=20 >>>=20 >>> For example, if a request comes to the RS that is not in the form of = an access token, then it either gets sent to the RO or their agent, or = it gets logged and dumped. One such option, common in healthcare, is = =E2=80=9CBreak the Glass=E2=80=9D where the RS is acting as an = authorization server because the user-agent is making a request instead = of presenting an access token. GNAP can offer this as an option but it = is not our core. >>>=20 >>> Adrian >>>=20 >>>=20 >>>=20 >>> On Fri, Mar 26, 2021 at 7:15 AM Justin Richer > wrote: >>> I have a big problem with this line: >>>=20 >>> > the RS and AS-RS only see access tokens. The requests (from RO') = that resulted in an access token are none of their business. >>>=20 >>> In the trust model we=E2=80=99ve been discussing, the requests that = result in access tokens are solely the business of AS-RS, since AS-RS is = the only entity that=E2=80=99s allowed, and trusted by the RS, to create = access tokens for the RS. That is its entire job, the entire reason it = exists in the system. By definition the party generating tokens for use = at the RS is the AS for that RS, I don=E2=80=99t care how you deploy it. = If RO wants to give access to someone else (who isn=E2=80=99t an =E2=80=9C= RO" anymore, they=E2=80=99re another end-user), then that end user=E2=80=99= s client software will need to talk to AS-RS to get its own access = token. >>>=20 >>> Now here=E2=80=99s the trick: when the end user=E2=80=99s client = instance talks to AS-RS, that does NOT mean that AS-RS needs to know all = the details and policy reasons that it should give an access token to = that client instance. It doesn=E2=80=99t even need to know the existence = of another end user. It doesn=E2=80=99t need identity, it doesn=E2=80=99t = need policy. Sure, it COULD handle all of that internally, and many = will, but the protocol doesn=E2=80=99t demand it.=20 >>>=20 >>> This means that the first client instance, the one that gets the = access token, can also be given something alongside the access token = that it can then hand to another piece of software (or to a person to = hand eo their piece of software). This artifact is not an access token. = This artifact could be something structured that the client understands, = and can make derivatives of, and present back to the AS-RS for getting = new access tokens. There could be multiple different flavors of this = kind of artifact for different kinds of environments and groups. But = what they all have in common is that they can potentially be used to = request more access tokens within some context at the AS-RS. >>>=20 >>> =E2=80=94 Justin >>>=20 >>>=20 >>>=20 >>>> On Mar 25, 2021, at 5:50 PM, Adrian Gropper > wrote: >>>>=20 >>>> My issue is with Alan's: >>>> "7. Another user agent (RO') can contact any holder of the access = token or the service's policy agent (AS-RS) to get a delegated access = token." >>>>=20 >>>> I would prefer "7A. Another user agent (RO') can contact any holder = of the access token." by default so that the AS-RS does not see the = requests. In other words, the RS and AS-RS only see access tokens. The = requests (from RO') that resulted in an access token are none of their = business. >>>>=20 >>>> The reality is that RO' can discover a resource RS and can share = whatever information with RS-AS they want and the RO may not even know = about it unless the RS decides to let them know somehow. This seems to = be a drawback of the capabilities approach.=20 >>>>=20 >>>> In terms of privacy and control, I, as the RO, want a contract with = the RS that says that I or my agent (AS-RO) must sign an access token. = This is a fundamental audit requirement. Without it, a rogue RS and = AS-RS can do all sorts of things and the RO would never know. I = understand that a rogue RS might not support an honest contemporaneous = log of access tokens presented so there's a trust issue here that I = seems unavoidable unless I specify in my RO-RS contract that they use a = separate contemporaneous log such as AS-RO for every access token = presented and risk being sued if they process an access token without = also updating the separate log. >>>>=20 >>>> - Adrian >>>>=20 >>>>=20 >>>> On Thu, Mar 25, 2021 at 1:22 PM Alan Karp > wrote: >>>> Justin Richer > wrote: >>>> Hi Alan, >>>>=20 >>>> In all of my discussion, and in the spec itself, the RO is the = :entity: in charge of approving rights. They=E2=80=99re probably a = person. It might be software that makes a policy decision in some way, = or a corporate entity, or something like that. But it=E2=80=99s not = assumed to be a computational agent in the terms of the protocol itself. = Would that recast what you=E2=80=99re saying below? >>>>=20 >>>> Hmmm. I guess not. It's just that the person would be using some = UI to express their decisions to what I called the user agent. That = model fits in very nicely with what we did with Polaris, our virus safe = computing environment for Windows XP, = https://dl.acm.org/doi/10.1145/1151030.1151033 = . The person would = click on the icon for a Word file, and an instance of Word would open = with only the permission = needed to edit that one file. Same thing here. The client could ask = for permission to use the resource, or permission could be granted = implicitly when the user selects a resource associated with a specific = client. >>>>=20 >>>> -------------- >>>> Alan Karp >>>>=20 >>>>=20 >>>> On Thu, Mar 25, 2021 at 9:53 AM Justin Richer > wrote: >>>> Hi Alan, >>>>=20 >>>> In all of my discussion, and in the spec itself, the RO is the = :entity: in charge of approving rights. They=E2=80=99re probably a = person. It might be software that makes a policy decision in some way, = or a corporate entity, or something like that. But it=E2=80=99s not = assumed to be a computational agent in the terms of the protocol itself. = Would that recast what you=E2=80=99re saying below? >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>> On Mar 25, 2021, at 12:36 PM, Alan Karp > wrote: >>>>>=20 >>>>> There seems to be some confusion about how AS-RO comes into the = picture, probably because of the "AS" part. I'm going to try to clear = up that confusion by more carefully explaining what I mean. >>>>>=20 >>>>> I'm assuming that RO is a computational agent representing the = person who is the resource owner, something called the "user agent" in = operating systems lingo. I'm also assuming that it's possible to do = delegation, either locally or by token exchange with AS-RS. All = delegations are potentially sub-scoped, but you may also want to = delegate with full scope to have a separately revocable access token. >>>>>=20 >>>>> Here's an example of how things work in a capability oriented = system. >>>>> Someone, the service owner, creates a service. >>>>> The service owner contracts with an policy agent (AS-RS) to create = and manage access tokens for that service (RS). >>>>> A person wishing to create a resource at RS uses their user agent = (RO) to contact the service owner's policy agent (AS-RS) and gets back = an access token for that resource. >>>>> That user agent (RO) can=20 >>>>> use that access token to invoke the resource, or >>>>> delegate an access token to a client of the user agent's (RO) = choice, or >>>>> contract with a policy agent (AS-RO) to manage those delegations = on behalf of the user agent (RO), or >>>>> specify a policy with the service's policy agent (AS-RS). >>>>> A client can contact any holder of the access token (the user = agent (RO) or its policy agent (AS-RO)) or the service's policy agent = (AS-RS) to get a delegated access token. >>>>> That client can delegate that token to another client. >>>>> Another user agent (RO') can contact any holder of the access = token or the service's policy agent (AS-RS) to get a delegated access = token. >>>>> The other user agent (RO') can=20 >>>>> use that access token to invoke the resource, or >>>>> delegate it to a client of its choice, or >>>>> contract with a policy agent (AS-RO') of its choosing to manage = those delegations on its behalf, or >>>>> specify a policy with the service's policy agent (AS-RS). >>>>> and so on >>>>> When any of these computational agents, user agents (ROs) or = clients acting on their behalf, invokes the resource, AS-RS verifies = that the access token is a valid delegation, i.e., proper sub-scoping, = hasn't been revoked, and that it authorizes the request being made = before telling the service (RS) to honor the request. At no point does = the service's policy agent (AS-RS) know which computational agent did = any particular delegation. (Token exchange can be done as anonymously = as possible.) In particular, the policy agents (AS-RO) need not be the = same, or even compatible with, the service's policy agent (AS-RS). GNAP = specifies the protocol between requesters, invokers, delegators (for = token exchange) of tokens and AS-RS. That protocol need not be used = between user agents (RO), clients, or other policy agents (AS-RO), but = it is likely to be. >>>>>=20 >>>>> ------------- >>>>> Alan Karp >>>>>=20 >>>>>=20 >>>>> On Thu, Mar 25, 2021 at 5:45 AM Justin Richer > wrote: >>>>> The way I=E2=80=99m thinking about Adrian=E2=80=99s use case is = that what we=E2=80=99re calling the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t = an =E2=80=9CAS=E2=80=9D in the traditional OAuth/GNAP sense, at least = not exactly. This is the agent that the RO can use to set policies and = manage consent on their behalf, and I=E2=80=99ve been arguing that it = fits better into this vaguely-defined =E2=80=9Cinteraction component=E2=80= =9D aspect of the current AS definition, and it=E2=80=99s not = currently separated from = the AS definition. The =E2=80=9CAS-RS=E2=80=9D maps to what we=E2=80=99d = call the =E2=80=9CAS=E2=80=9D in OAuth/GNAP traditionally, it=E2=80=99s = what the RS trusts to issue tokens. In traditional OAuth the AS-RO and = AS-RS are always the same thing, from a functional protocol perspective. = An important point here is that from a client=E2=80=99s perspective, = they=E2=80=99re only talking to the AS-RS since that=E2=80=99s where the = client gets its tokens, because at the end of the day the client just = wants to call the API at the RS and doesn=E2=80=99t care how that = happens (from a protocol standpoint).=20 >>>>>=20 >>>>> Note well: Even thought I don=E2=80=99t believe that =E2=80=9CAS-RO=E2= =80=9D is an authorization server at all, I=E2=80=99m going to keep = using that term below for consistency with previous discussion. >>>>>=20 >>>>> So we have these fundamental relationships around getting the = client to access the RS: >>>>>=20 >>>>> 1. RS trusts AS-RS to issue tokens that RS will accept, validate, = and process for requests from client >>>>> 2. Client trusts AS-RS to issue tokens that client can use at RS >>>>> 3. RO trusts RS to protect RO=E2=80=99s api through delegated = access >>>>>=20 >>>>> On top of that, we=E2=80=99ve got some additional aspects that = we=E2=80=99re discussing: >>>>>=20 >>>>> 4. RO trusts AS-RO to manage RO=E2=80=99s policies at runtime >>>>> 5. AS-RS trusts AS-RO to assert RO=E2=80=99s policies for access = to RS >>>>> 6. Client trusts whatever AS-RS sends client to deal with, = including possibly RO-AS at runtime, because of (2) >>>>>=20 >>>>> What I have been saying is that 4/5/6 are optional details of how = RS-AS runs things, and I think this also maps with Adrian=E2=80=99s view = of choice, since if my RS=E2=80=99s AS-RS doesn=E2=80=99t allow me to = plug in my own AS-RO then I would be motivated to pick a different RS = who=E2=80=99s AS-RS lets me do just that. The same way I=E2=80=99d pick = a different RS if their surrounding services didn=E2=80=99t accept my = preferred federation login and I didn=E2=80=99t want to make another = account. Of course, market forces being as they are, I might not have = much of an actionable choice in RS, but GNAP can=E2=80=99t change that.=20= >>>>>=20 >>>>> What we can do is make it possible for AS-RS to talk to AS-RO, = both in philosophy of the protocol design and in concrete hooks to = support (6) above.=20 >>>>>=20 >>>>> Separately, we can approach the issue of making 1/2 above more = dynamic. This was UMA2=E2=80=99s =E2=80=9Cfederated authorization=E2=80=9D= approach, and is behind a lot of the =E2=80=9Cbring your own AS=E2=80=9D = models out there. The problem with these is that we know from many years = of experience that most RS=E2=80=99s aren=E2=80=99t interested in doing = anything of the sort. >>>>>=20 >>>>> So with GNAP we can instead allow 4/5/6 to vary in a predictable = and consistent way, letting the RS keep control over 1/2, thereby = enabling choice in (3). We don=E2=80=99t have to be the ones who define = the all of the details of every permutation of (5) to enable this, = though. Some of this is going to be configuration out of band, some of = it=E2=80=99s going to be communication at runtime. This is where VC=E2=80=99= s, ZCAPs, CHAPI, DIDComm, FIDO, and a whole swath of other tech can come = in and help out. I don=E2=80=99t think we need to put all the details = for using these into core, nor do I think we=E2=80=99ll pull of The = Great And Ultimate Abstraction for using these and other approaches. But = we can at least start talking about =E2=80=9CAS-RS=E2=80=9D in such a = way that it no longer assumes it=E2=80=99s always the same party dealing = with the RO directly. >>>>>=20 >>>>> =E2=80=94 Justin >>>>>=20 >>>>>> On Mar 25, 2021, at 6:40 AM, Fabien Imbault = > wrote: >>>>>>=20 >>>>>> To reframe it closer to GNAP: >>>>>> - AS =3D AS-RO, that's where you find the RO policies. The AS = issues access tokens to the client. >>>>>> - the RO policies could be a) defined locally or b) in = relationship with the RS >>>>>>=20 >>>>>> There have been several ideas related to the AS-RS relationship = b: >>>>>> b1) the RS issues capabilities (which can be further attenuated = by the RO) >>>>>> b2) Adrian also discussed a DID based solution >>>>>> b3) there was also an alternative ACL proposal from Denis (+ = preflight) >>>>>>=20 >>>>>> Fabien >>>>>>=20 >>>>>>=20 >>>>>> On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault = > wrote: >>>>>> Ok so I get you correctly:=20 >>>>>> - what matters is the RQ (could be a RO or a end-user or both : = we don't really care at a high-level, they're all treated as entities = that make a request) >>>>>> - the policy is able to handle those different cases, based on = its own internal delegation protocol >>>>>> - currently that requires AS-RS and AS-RO, but maybe it can be = simplified >>>>>>=20 >>>>>> To answer to Denis, here's what I understood: >>>>>> - RO trusts AS-RS (and then handles its own policies within = AS-RO) >>>>>> - end-user trusts AS-RO (through its client) >>>>>>=20 >>>>>> Could probably work but that's a fairly different model compared = to OAuth2 (and of today's GNAP), with different frontiers between the AS = and the RS.=20 >>>>>>=20 >>>>>> Please do not hesitate to correct me if I'm wrong. >>>>>>=20 >>>>>> Fabien=20 >>>>>>=20 >>>>>> On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper = > wrote: >>>>>> I believe there are alternatives to having two kinds of ASs. The = problem may be a side-effect of deciding to switch away form treating = the RO as different from the RQ. That leads to downstream privacy = issues. Our desire for architectural simplicity is admirable but that = may have been a step too far. >>>>>>=20 >>>>>> There may also be solutions based on different types of tokens, = as in different capabilities (tokens signed by the RS) vs. tokens signed = by the AS. I=E2=80=99m not sure about that but Alan might have more to = say. >>>>>>=20 >>>>>> Adrian >>>>>>=20 >>>>>> On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault = > wrote: >>>>>> Thanks. The general problem statement is clear. >>>>>>=20 >>>>>> The proposed solution a bit less (to me). I understood that from = point 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obvious = reason to have two types of ASs". Do you see an alternative ? >>>>>>=20 >>>>>> Regarding the last item, I don't think that naming RQ by end-user = created the problem. It might just highlight the asymmetry, which = fundamentally exists.=20 >>>>>>=20 >>>>>> Fabien >>>>>>=20 >>>>>>=20 >>>>>> On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper = > wrote: >>>>>> Recap: >>>>>> 1 - Justin (I think) introduced the idea of an AS on the RS trust = boundary side. >>>>>> 2 - I said the RO should not have to share policies with the RS. >>>>>> 3 - Alan invented the concept of AS-RO and AS-RS to separate two = kinds of PDPs.=20 >>>>>>=20 >>>>>> The thing is that step 2 is not symmetrical. The RO has a = legitimate privacy interest in keeping their policies private and = minimizing the leakage of information about requests that are posed = against those policies.=20 >>>>>>=20 >>>>>> The RS, on the other hand, should be publishing its policies = (e.g. what it=E2=80=99s selling or what jurisdiction it=E2=80=99s in or = what tokens or scopes it supports). The RS has no obvious privacy = interest in GNAP. It=E2=80=99s just an enforcer. >>>>>>=20 >>>>>> There is one other privacy interest to consider around the RS and = that is the requesting party (the end-user that is not the RO :-) might = prefer to share attributes with the RS instead of the RO or something = controlled by the RO. This case could be an =E2=80=9Cextension=E2=80=9D = to GNAP and might result in a split AS as a solution. This problem was = introduced when the editors decided to replace RQ with end-user. = Obviously, the RO end-user has no privacy interests relative to itself. >>>>>>=20 >>>>>> Adrian >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault = > wrote: >>>>>> I was referring to "By my definition, this model has two ASs = since both are processing requests into tokens". If there's no reason to = have 2 types of ASs, that's fine then.=20 >>>>>> But I'm a bit lost in where we stand with the idea.=20 >>>>>>=20 >>>>>> Could you recap?=20 >>>>>>=20 >>>>>> Fabien=20 >>>>>>=20 >>>>>> Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper = > a =C3=A9crit : >>>>>> There=E2=80=99s no obvious reason to have two types of ASs. Any = AS that is executing the policies of the RS can look to GNAP like the RS = itself. Why would GNAP expose that interface to anyone?=20 >>>>>>=20 >>>>>> Adrian >>>>>>=20 >>>>>> On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault = > wrote: >>>>>> Note : I'm not sure that's a good idea, but having 2 types of ASs = is not that easy to grasp. >>>>>>=20 >>>>>> Fabien=20 >>>>>>=20 >>>>>> Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault = > a =C3=A9crit = : >>>>>> The purpose of either handling policies locally or delegating = them to the RO agent.=20 >>>>>>=20 >>>>>> Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper = > a =C3=A9crit : >>>>>> What purpose would be served by GNAP splitting the AS into two = components? >>>>>>=20 >>>>>> Adrian=20 >>>>>>=20 >>>>>> On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault = > wrote: >>>>>> Isn't the AS-RO a component of the AS? Same idea as the interact = component, it functionnally belongs to the AS role but could be deployed = either as a monolith or as a separate component? >>>>>>=20 >>>>>> Fabien >>>>>>=20 >>>>>> Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper = > a =C3=A9crit : >>>>>> Yes, but I would say it=E2=80=99s not the RO that wants the = access token. It=E2=80=99s the RO that wants the client making the = request to get an access token.=20 >>>>>>=20 >>>>>> Adrian >>>>>>=20 >>>>>> On Wed, Mar 24, 2021 at 11:22 PM Alan Karp > wrote: >>>>>> Adrian Gropper > wrote: >>>>>>=20 >>>>>> In this design, the AS is the AS-RS and the agent is the AS-RO. = By my definition, this model has two ASs since both are processing = requests into tokens. The problem with this is complexity and privacy. = The RO may not want to share the request information with the AS-RS. >>>>>>=20 >>>>>> More precisely, RO has no choice but to present the required = information to AS-RS if RO wants an access token. However, RO does not = want AS-RS to know the policy by which RO delegates tokens. That's why = RO uses AS-RO for those delegations. >>>>>>=20 >>>>>> -------------- >>>>>> Alan Karp >>>>>>=20 >>>>>>=20 >>>>>> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper = > wrote: >>>>>> Thank you for creating the issue. My definition of AS is = independent of AS-RO or AS-RS. = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomment= -806280421 = I also agree with Alan's definition based on delegation. An = AS-RS would be a delegate of the RS.=20 >>>>>>=20 >>>>>> Based on that, I see it as obvious that the policy has to be = accessible (defined locally?) in order for it to be run as the code that = turns a request into an access token.=20 >>>>>>=20 >>>>>> The only other possibility is that the request is packaged by the = AS and sent elsewhere (an agent) for evaluation against policy and a = proto-token returned. In that case the AS is acting as a proxy and the = PDP is elsewhere. I can imagine that an AS-RS would behave this way so = that the proto-token could be turned into an access token by the AS-RS. = Isn't this what Justin is proposing? In this design, the AS is the AS-RS = and the agent is the AS-RO. By my definition, this model has two ASs = since both are processing requests into tokens. The problem with this is = complexity and privacy. The RO may not want to share the request = information with the AS-RS. >>>>>>=20 >>>>>> Adrian >>>>>>=20 >>>>>> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault = > wrote: >>>>>> Isn't that what the AS is supposed to be, only with the caveat = that the policy is defined locally?=20 >>>>>>=20 >>>>>> Fabien=20 >>>>>>=20 >>>>>>=20 >>>>>> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp > a =C3=A9crit : >>>>>> AS-RO is an AS that RO trusts to delegate RO's access tokens = according to RO's policies. =20 >>>>>>=20 >>>>>> -------------- >>>>>> Alan Karp >>>>>>=20 >>>>>>=20 >>>>>> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault = > wrote: >>>>>> Hi Alan and Adrian, >>>>>>=20 >>>>>> I've created issue AS-RO policy delegation = (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223 = ) to = capture your input.=20 >>>>>> A first question that arises: can we give a definition to AS-RO? >>>>>>=20 >>>>>> Thanks >>>>>> Fabien >>>>>>=20 >>>>>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp > wrote: >>>>>> Fabien Imbault > wrote: >>>>>> Hi Alan,=20 >>>>>>=20 >>>>>> Yes, but in that flow, the token relationship between AS-RS and = AS-RO is only secure if the tokens issued by AS-RS are cryptographically = attenuable in the first place.=20 >>>>>> =20 >>>>>> Attenuated delegation is a requirement, but that doesn't have to = be done cryptographically. Token exchange works just fine. SPKI and = zcap-ld are examples of the crypto approach, and we used token exchange = in the system for HP. >>>>>>=20 >>>>>> -------------- >>>>>> Alan Karp >>>>>>=20 >>>>>>=20 >>>>>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault = > wrote: >>>>>> Hi Alan,=20 >>>>>>=20 >>>>>> Yes, but in that flow, the token relationship between AS-RS and = AS-RO is only secure if the tokens issued by AS-RS are cryptographically = attenuable in the first place.=20 >>>>>>=20 >>>>>> Fabien >>>>>>=20 >>>>>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp > wrote: >>>>>> Justin Richer > wrote: >>>>>>=20 >>>>>> But with all that in mind, I think the key here is going to be = looking at what the inputs to the AS are, and how those can be defined = in an interoperable way for AS=E2=80=99s that can accept them. I think = there=E2=80=99s a lot of room for innovation and flexibility here that = doesn=E2=80=99t break the trust model or core use cases. If I have an = AS-RS set that won=E2=80=99t accept my favorite flavor of policy engine = inputs, then I can decide not to use that one. But this is a very = different question than saying the RS itself needs to accept my own AS = =E2=80=94 and we can=E2=80=99t keep conflating these two models. >>>>>>=20 >>>>>> I agree. The point of having an AS-RO is to allow RO to specify = a policy for which of RO's access tokens should be delegated under what = conditions. AS-RS should not need to understand those policies. The = flow would be >>>>>> RO contacts AS-RS and gets one or more access tokens. >>>>>> RO delegates one or more of those tokens, potentially sub-scoped, = to AS-RO. >>>>>> A different user contacts AS-RO to get a potentially sub-scoped = access token from AS-RO. >>>>>> That user presents the access token delegated by AS-RO when = invoking the resource. >>>>>> AS-RS only needs to verify that the delegation chain is = legitimate, e.g., no increase in scope, and that it grants permission = for the request being made. AS-RS does not need to understand the = policy behind granting the delegation by AS-RO. >>>>>>=20 >>>>>> -------------- >>>>>> Alan Karp >>>>>>=20 >>>>>>=20 >>>>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer > wrote: >>>>>> Adrian, >>>>>>=20 >>>>>> I think this shows the problem with the terminology as it=E2=80=99s= been applied in this conversation, which I=E2=80=99ve tried to shine = light on before. What you and others are calling the =E2=80=9CRS=E2=80=9D = is really the =E2=80=9CAS and RS working together=E2=80=9D =E2=80=94 = everything to the right of the line. When Denis had brought up = =E2=80=9Celiminating the AS=E2=80=9D in another thread, what he=E2=80=99d = really done is labeled everything to the right of the line as the = =E2=80=9CRS=E2=80=9D. Of course, the irony here is that everything to = the right of the line used all be called the =E2=80=9CAS=E2=80=9D or = simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say below, I = don=E2=80=99t want the client to have visibility on what happens on that = side.=20 >>>>>>=20 >>>>>> Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the = diagram is not the AS, as far as GNAP is concerned. It does not issue an = access token that the RS will accept. The elements to the left of the = line could be a lot of things, but they are NOT the AS =E2=80=94 by = definition. The client lives over on the left, but so do any external = inputs to the AS. These could be policy inputs on behalf of the RO, they = could be presentation artifacts, they could be federated logins, they = could be the output of policy decisions. How the AS comes to trust those = things is up to the AS=E2=80=99s implementation. It=E2=80=99s something = we can talk about, but ultimately GNAP won=E2=80=99t be in any position = to dictate because in practice some AS=E2=80=99s are simply going to = internalize all policies and we will never successfully force those = open.=20 >>>>>>=20 >>>>>> But with all that in mind, I think the key here is going to be = looking at what the inputs to the AS are, and how those can be defined = in an interoperable way for AS=E2=80=99s that can accept them. I think = there=E2=80=99s a lot of room for innovation and flexibility here that = doesn=E2=80=99t break the trust model or core use cases. If I have an = AS-RS set that won=E2=80=99t accept my favorite flavor of policy engine = inputs, then I can decide not to use that one. But this is a very = different question than saying the RS itself needs to accept my own AS = =E2=80=94 and we can=E2=80=99t keep conflating these two models. >>>>>>=20 >>>>>> So to me, GNAP can support a Zero Trust Architecture by = LEVERAGING the AS, not by subsuming or eliminating it. It is in fact the = AS, not the client and not the RS, that will request and consume the = results of a privacy-preserving zero-trust policy query thing. Anything = that happens downstream from that is of little concern to the zero-trust = components because, as you point out, it=E2=80=99s on the =E2=80=9Cother = side=E2=80=9D of the line.=20 >>>>>>=20 >>>>>> I think we got this basic component model pretty right in OAuth: = the AS and RS and client working together. Where OAuth misses the mark = is the assumption that the user has to log in to the AS through a = webpage and interact directly, thereby proving they=E2=80=99re the RO. = It=E2=80=99s this latter space where I think we can both push innovation = and also address the important and compelling use cases like the ones = you=E2=80=99re bringing. >>>>>>=20 >>>>>> =E2=80=94 Justin >>>>>>=20 >>>>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper = > wrote: >>>>>>>=20 >>>>>>> I'm sorry, Justin. As a Resource Owner, I look at the RS trust = boundary (the dotted line in the diagram) as being the RS. I don't = expect any visibility into what's going on on the right.=20 >>>>>>>=20 >>>>>>> My problem with the framing you propose is that requests are = going to the RS (or the AS-RS) and I don't want to share my policies = with the AS-RS. I want to keep the RS and AS-RS as ignorant as possible. >>>>>>>=20 >>>>>>> Adrian >>>>>>>=20 >>>>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer > wrote: >>>>>>> Adrian, >>>>>>>=20 >>>>>>> What you=E2=80=99re discussing below, in terms of logging in to = a site, is not approaching the RS. You are in fact approaching the = client, and identifying both the AS and RS to the client. The client is = a client of your identity in this model, and the RS is part of the = identity provider. It=E2=80=99s really important that we don=E2=80=99t = conflate the RS and client in this way as it leads to a lot of confusion = downstream and a lot of broken trust boundaries. >>>>>>>=20 >>>>>>> With that model in mind, approaching the =E2=80=9CRS" and = providing it your identity is really just a case of the =E2=80=9Cfederated= login to AS=E2=80=9D pattern that we discussed on the WG call. The user = here approaches an RS, which has its own AS. To share things from this = RS, the RO has to authenticate to the RS=E2=80=99s AS. This particular = AS allows the RO to do so using an external identity =E2=80=94 in which = case, the AS is now a =E2=80=9Cclient=E2=80=9D of a separate, = disconnected (but layered) delegation. The ultimate client that = eventually calls the RS down the way may or may not know about these = layers.=20 >>>>>>>=20 >>>>>>> >>>>>>> This same AS, which is closely tied to the RS and trusted by the = RS, might also take in FIDO credentials, or DIDs, or any number of other = proof mechanisms. The output of this is an access token the RS trusts, = but the input is up to the AS. The RS is not what you=E2=80=99re logging = in to. >>>>>>>=20 >>>>>>> =E2=80=94 Justin >>>>>>>=20 >>>>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper = > wrote: >>>>>>>>=20 >>>>>>>> I too am in favor of avoiding consolidation and correlation. = Right now, when I approach a service provider (RS) for the first time, = I'm offered the opportunity to identify my persona as: email, sign-in = with Google, Facebook, or Apple. I know there are people who try to = create one-off email addresses but that is mostly a waste of time.=20 >>>>>>>>=20 >>>>>>>> So, along come FIDO2 and DID wallets to the rescue. Now, in = theory, I have a way to start out my RS relationship pseudonymously.=20 >>>>>>>>=20 >>>>>>>> When I want my resource to be discovered or shared I will post = that RS URL including my pseudonym. If I then want to introduce a = mediator in front of my AS or messaging service endpoint, I have that = option. If I want to keep requests away from the mediator, I would = publish an encryption key along with my pseudonym. >>>>>>>>=20 >>>>>>>> - Adrian >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer > wrote: >>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk > wrote: >>>>>>>> >=20 >>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper = wrote: >>>>>>>> >> @Alan Karp > shared a talk about the Principle Of Least >>>>>>>> >> Authority (POLA) in a recent comment >>>>>>>> >> = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment= -803099693 = >>>>>>>> >> I recommend it. >>>>>>>> >>=20 >>>>>>>> >> We might expect a protocol with authorization in the title = to use authority >>>>>>>> >> as a core principle. I advocate for a GNAP design that = maximizes the power >>>>>>>> >> of the RO, to be seen as a human rights issue when the RO is = a human. This >>>>>>>> >> causes me to ask how to combine better security with better = human rights in >>>>>>>> >> GNAP. >>>>>>>> >>=20 >>>>>>>> >> Who should have the least authority in the GNAP design? >>>>>>>> >>=20 >>>>>>>> >> The AS derives authority as a delegate of the RO. If we ask = the RO to >>>>>>>> >> partition limited authority across dozens of different ASs = by domain and >>>>>>>> >> function, then we are not using technology to empower the = individual. >>>>>>>> >> Probably the opposite, as we introduce consent fatigue and = burden normal >>>>>>>> >> people to partition their lives into non-overlapping = domains. >>>>>>>> >>=20 >>>>>>>> >> My experience says we should aim for one AS per persona = because that maps >>>>>>>> >> into the way we manage our public and private identities. = POLA would then >>>>>>>> >> teach care in keeping ASs and RSs related to work / public = separate from >>>>>>>> >> ASs and RSs related to private life so that a policy = vulnerability in our >>>>>>>> >> delegation to an AS would have the least likelihood of harm. >>>>>>>> >=20 >>>>>>>> > Thinking about how least authority/least privilege would = apply to GNAP >>>>>>>> > seems like a useful exercise. I do want to point out some = potential >>>>>>>> > pitfalls with one-AS-per-persona that we can also be aware = of. If >>>>>>>> > one-AS-per-persona becomes one-persona-per-AS as well, then = the AS's >>>>>>>> > identity in effect also serves as a persona identity and = there are privacy >>>>>>>> > considerations to that. If, on the other hand, the >>>>>>>> > multiple-personas-per-AS (presumably corresponding to = multiple humans) >>>>>>>> > route is taken, we should consider whether that would lead to = various >>>>>>>> > (e.g., market) forces driving consolidation to just a handful = of >>>>>>>> > super-popular AS services. That topic is a current matter of = concern to >>>>>>>> > some IETF participants. >>>>>>>> >=20 >>>>>>>>=20 >>>>>>>> Hi Ben, big +1 to this. This is something that we discussed = ages ago in the UMA working group, and it=E2=80=99s one of the biggest = problems with the personal AS (and personal data store) model. This kind = of thing makes RS-first trust models really difficult in practice. >>>>>>>>=20 >>>>>>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve got software = that wants to access my medical information. It calls an RS and requests = access, but it hasn=E2=80=99t been granted anything yet. Now I as the RO = have set up the RS so that it talks to my personal AS, that only I use. = In addition to = the RS having to be able to figure out which medical records are being = requested from the context of the unauthenticated request (which means = it needs identifiers in the URL or something similar for the RS to be = able to tell, assuming that it protects data for more than one person). = So this client software doesn=E2=80=99t know who I am and doesn=E2=80=99t = know my medical record information, makes a completely unauthorized = request to the RS, and the RS says =E2=80=9CGo to Justin=E2=80=99s = personal AS to get a token=E2=80=9D. The client can now make a direct = correlation between the data that=E2=80=99s being protected at the RS = and the person running the AS that protects it. Importantly, this client = makes this call with no prior relationship to the RS and no really = auditable way to track it down after the fact. This is a design feature = in the good case, and terrifying in the bad case. >>>>>>>>=20 >>>>>>>> If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, = please talk to the Medicine Doctor AS to get access=E2=80=9D, we = haven=E2=80=99t exposed anything at all. And from the perspective of = both the patient and the RS, this is more privacy-preserving, and it=E2=80= =99s really the least surprising option. Once the client gets to the AS, = it can start a negotiation of figuring out who the RO is for the = information being accessed. >>>>>>>>=20 >>>>>>>> On top of this, the usability expectations of people managing = their own AS, or set of AS=E2=80=99s for multiple personas to keep = things separate, is a huge burden. Even in the tech community, I know = people who can=E2=80=99t reliably manage more than one email address for = different purposes. I wouldn=E2=80=99t expect my partner to do that =E2=80= =94 they have trouble enough balancing all the logins and sessions = required for different kids remote schooling, I couldn=E2=80=99t imagine = them having to understand all the requirements for managing multiple = authorization servers and associated policies. I also don=E2=80=99t = expect any person to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve = been on the internet for decades and I can barely keep tabs on my GPG = keys, and only use them when I am forced to. This is exactly the kind of = =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions above, = people will just want to outsource that to someone else, and the reality = will be a few popular providers. >>>>>>>>=20 >>>>>>>> In which case, we could end up doing a ton of work to allow an = RS choice only to end up with a world where the RS ends up making a = limited choice anyway. We see how that plays out with OpenID Connect =E2=80= =94 RP=E2=80=99s could allow arbitrary IdPs but they choose Google = because it works and that=E2=80=99s where the users are. (And that=E2=80=99= s not to say anything of the proprietary OIDC-like protocols, but = that=E2=80=99s another discussion). >>>>>>>>=20 >>>>>>>> For further reading on these topics, I recommend both =E2=80=9CWh= y Johnny Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems = Fail=E2=80=9D. >>>>>>>>=20 >>>>>>>> So what does this have to do with GNAP? I think we can be = clear-eyed on what kinds of expectations we have for the participants. = If we expect users (RO=E2=80=99s) to have to set up the AS-RS = relationship, or expect them to carry their AS, or manage their personal = keys =E2=80=94 I think we=E2=80=99ve lost the battle for relevance. >>>>>>>>=20 >>>>>>>> =E2=80=94 Justin >>>>>>>=20 >>>>>>=20 >>>>>> --=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 = >>>>>> --=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 = >>>=20 >>=20 >>=20 >=20 --Apple-Mail=_D35AE2A6-3D28-4CA0-B621-7A7525635810 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 GNAP = doesn=E2=80=99t have anything too say about anybody authenticating = directly to the RS. If that happens, it=E2=80=99s out of the view and = out of scope of GNAP.

     =E2=80=94 Justin

    On Mar 26, 2021, at 1:06 PM, Denis <denis.ietf@free.fr> = wrote:

    =20
    Hi everybody,

    The content of this thread has = nothing to do any more with its original title which was: "Will GNAP support Zero Trust Architecture?"
    Since I am going to use some sentences of this thread to open a new topic, I changed the title of this thread into :
    "Relationship between Authentication and Authorization ?"

    At the moment, I got the impression that nobody agrees any more about what GNAP is or is = not, what it should address and what it should not address.
    The components of the model are becoming more numerous and hazy. A new terminology is sometimes being used, but is not yet present in the last published draft.

    I still can't understand any of the new terms that are being used (AS-RS and AS-RO), which are still left undefined.

    The last exchanges look more as conversations between workers during the construction of the Babel tower.

    Last year, my first remark was to mention that a section or an Annex explaining the common points and the differences with OAuth 2.0
    would be useful. Such section or Annex still does not exist.

    Justin wrote:
    If an RS allows a username/password HTTP Basic auth in addition to accepting access tokens, it can do so, but
    GNAP doesn=E2=80=99t have anything to say = about the Basic auth use, or even its relation to any access tokens or RO=E2=80=99s = or anything else.
    Let us split the end of this sentence into two parts:

    "GNAP doesn=E2=80=99t = have anything to say about the Basic auth use":  If an authentication exchange  is necessary, the draft document should describe, = for completeness,
    the HTTP error code that will be returned.

    "or even its relation = to any access tokens or RO=E2=80=99s or anything else". Let us suppose = that a RS supports FIDO as an authentication mechanism to authenticate its end-users.
    FIDO provides the major advantage = that, for every RS, a different identifier is used by every end-user. This prevents end-users accounts correlations between RSs by using
    such identifiers. In practice, a FIDO identifier is a = pseudonym.

    At this very moment, the RS is able = to identify and authenticate its end-users using FIDO pseudonyms. Now, let us raise the following question:

    How will a RS be bootstrapped for working with a GNAP "sub" claim or a "sub_id" claim, whereas FIDO is already being used ?

    Denis


    =20 Adrian,

    I disagree, I believe that what I have laid out is exactly separating the concerns into working = components. 

    Like OAuth before it, GNAP is a protocol negotiate access for a client instance to an RS, using an AS as the facilitator of that delegated negotiation. (Unlike OAuth, it=E2=80= =99s importantly also for negotiating user information to the client directly from the AS with no RS involved, but that=E2=80=99s an = aside for the purposes of our conversation here).

    If a particular GNAP RS also allows other kinds of processes to enable access to it, that is completely fine, but outside of GNAP. If an RS allows a username/password HTTP Basic auth in addition to accepting access tokens, it can do so, but GNAP doesn=E2=80=99t have anything to say about the Basic auth = use, or even its relation to any access tokens or RO=E2=80=99s or = anything else. If an RS accepts structured access tokens signed by trusted keys that don=E2=80=99t come from an AS through a negotiated request = =E2=80=94 again, that=E2=80=99s fine, but GNAP is silent about the RS doing that. = If the RS acts as =E2=80=9Cits own AS=E2=80=9D then it=E2=80=99s really = just an RS and an AS living in the same box. Again, that=E2=80=99s fine, and super = common with OAuth today. 

    GNAP is solving the problem of connecting the = client to the RS through means of an AS. Other solutions are possible and many of them can be deployed right alongside, but that=E2=80=99= s not the corner of the world that GNAP is solving. GNAP should be concerned about how these other technologies can be used alongside it. I think there=E2=80=99s a lot of room for the = things that you=E2=80=99re talking about, and more importantly for solving = the use cases that you=E2=80=99re bringing. But GNAP should be more than = a single-point solution, and so we need to balance these concerns. The conceptual framework of an AS that takes in lots of different information and spits out access tokens is exactly the abstraction layer that is necessary for making these use cases interoperable.

     =E2=80=94 Justin

    On Mar 26, 2021, at 8:30 AM, Adrian Gropper <agropper@healthurl.com> wrote:

    =20
    @Justin, there=E2=80=99s no = separation of concerns here. No partition between processor and controller. No data minimization. And, I see no obvious reason to make this the core of GNAP. 

    The one thing we can probably = all agree on is that there=E2=80=99s only one RS and one = RO. 

    The core of GNAP, in = my opinion, can be built and explained around this simple design. The RS is a processor. The RO is a controller. The RS bears only security responsibility. The RS bears no privacy responsibility. The RO delegates this to the RS but this is not authorization as the A in GNAP.

    The RO retains all rights to delegate within the scope of things that the RS is willing to support using various token formats and endpoint options. Some of these options may do all sorts of things for all sorts of clients and user-agents =  but these are options. 

    For example, if a request = comes to the RS that is not in the form of an access token, then it either gets sent to the RO or their agent, or it gets logged and dumped. One such option, common in healthcare, is =E2=80=9CBreak the Glass=E2=80=9D where = the RS is acting as an authorization server because the user-agent is making a request instead of presenting an access token. GNAP can offer this as an option but it is not our = core.

    Adrian



    On Fri, Mar 26, = 2021 at 7:15 AM Justin Richer <jricher@mit.edu> wrote:
    I have a big problem with this = line:

    > the RS and AS-RS only see access tokens. The requests (from RO') that resulted in an access token are none of their business.

    In the trust model we=E2=80=99ve been discussing, = the requests that result in access tokens are solely the business of AS-RS, since AS-RS is the only entity that=E2=80=99s allowed, = and trusted by the RS, to create access tokens for the RS. That is its entire job, the entire reason it exists in the system. By definition the party generating tokens for use at the RS is the AS for that RS, I don=E2=80=99t care how you deploy it. = If RO wants to give access to someone else (who isn=E2=80=99= t an =E2=80=9CRO" anymore, they=E2=80=99re another = end-user), then that end user=E2=80=99s client software will need to = talk to AS-RS to get its own access token.

    Now here=E2=80=99s the trick: when = the end user=E2=80=99s client instance talks to AS-RS, = that does NOT mean that AS-RS needs to know all the details and policy reasons that it should give an access token to that client instance. It doesn=E2=80=99t even need to know the existence = of another end user. It doesn=E2=80=99t need = identity, it doesn=E2=80=99t need policy. Sure, it COULD = handle all of that internally, and many will, but the protocol doesn=E2=80=99t demand it. 

    This means that the first client instance, the one that gets the access token, can also be given something alongside the access token that it can then hand to another piece of software (or to a person to hand eo their piece of software). This artifact is not an access token. This artifact could be something structured that the client understands, and can make derivatives of, and present back to the AS-RS for getting new access tokens. There could be multiple different flavors of this kind of artifact for different kinds of environments and groups. But what they all have in common is that they can potentially be used to request more access tokens within some context at the = AS-RS.

     =E2=80=94 Justin



    On Mar 25, 2021, at 5:50 = PM, Adrian Gropper <agropper@healthurl.com> wrote:

    My issue is with Alan's:
    "7. Another user agent (RO') can contact any holder of the access token or the service's policy agent (AS-RS) to get a delegated access token."

    I would prefer = "7A. Another user agent (RO') can contact any holder of the access token." by default so that the AS-RS does not see the requests. In other words, the RS and AS-RS only see access tokens. The requests (from RO') that resulted in an access token are none of their business.

    The reality is that RO' can discover a resource RS and can share whatever information with RS-AS they want and the RO may not even know about it unless the RS decides to let them know somehow. This seems to be a drawback of the capabilities = approach. 

    In terms of privacy and control, I, as the RO, want a contract with the = RS that says that I or my agent (AS-RO) must sign an access token. This is a fundamental audit requirement. Without it, a rogue RS and AS-RS can do all sorts of things and the RO would never know. I understand that a rogue RS might not support an honest contemporaneous log of access tokens presented so there's a trust issue here that I seems unavoidable unless I specify in my RO-RS contract that they use a separate contemporaneous log such = as AS-RO for every access token presented and risk being sued if they process an access token without also updating the separate = log.

    - Adrian


    On= Thu, Mar 25, 2021 at 1:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin Richer <jricher@mit.edu> wrote:
    Hi Alan,

    In all of my discussion, and in the spec itself, the RO is the :entity: in charge of approving rights. = They=E2=80=99re probably a person. It might be software that makes a policy decision in some way, or a corporate entity, or something like that. But it=E2=80=99s not = assumed to be a computational agent in the terms of the protocol itself. Would that recast what you=E2=80=99= re saying below?

    Hmmm.  I = guess not.  It's just that = the person would be using some UI to express their decisions to what I called the user agent.  That = model fits in very nicely with what we did with Polaris, our virus safe computing environment for Windows XP, https://dl.acm.org/doi/10.1145/1151030.1151033.  The person would click on the icon for a Word file, and an instance of Word would open with only the permission needed to edit that one file.  Same = thing here.  The client could = ask for permission to use the resource, or permission could be granted implicitly when the user selects a resource associated with a specific client.

    --------------
    Alan Karp


    On Thu, Mar 25, 2021 at 9:53 AM Justin Richer <jricher@mit.edu> wrote:
    Hi Alan,

    In all of my discussion, and in the spec itself, the RO is the :entity: in charge of approving rights. = They=E2=80=99re probably a person. It might be software that makes a policy decision in some way, or a corporate entity, or something like that. But it=E2=80=99s not = assumed to be a computational agent in the terms of the protocol itself. Would that recast what you=E2=80=99= re saying below?

     =E2=80=94= Justin

    On Mar 25, 2021, at 12:36 PM, Alan Karp <alanhkarp@gmail.com> wrote:

    There seems to be some confusion about how AS-RO comes into the picture, probably because of the "AS" = part.  I'm going to try to clear up that confusion by more carefully explaining what I mean.

    I'm assuming that RO is a computational agent representing the person who is the resource owner, something called the "user agent" in operating systems lingo.  = I'm also assuming that it's possible to do delegation, either locally or by token exchange with AS-RS.  = All delegations are potentially sub-scoped, but you may also want to delegate with full scope to have a separately revocable access = token.

      Here's an example of how things work in a capability oriented system.
    1. Someone, the service owner, creates a = service.
    2. The service owner contracts with an policy agent (AS-RS) to create and manage access tokens for that service (RS).
    3. A= person wishing to create a resource at RS uses their user agent (RO) to contact the service owner's policy agent (AS-RS) and gets back an access token for that resource.
    4. That user agent (RO) = can 
      1. use that access token to invoke the resource, = or
      2. delegate an access token to a client of the user agent's (RO) choice, or
      3. contract with a policy agent (AS-RO) to manage those delegations on behalf of the user agent (RO), or
      4. specify a policy with the service's policy agent (AS-RS).
    5. A= client can contact any holder of the access token (the user agent (RO) or its policy agent (AS-RO)) or the service's policy agent (AS-RS) to get a delegated access = token.
    6. That client can delegate that token to another client.
    7. Another user agent (RO') can contact any holder of the access token or the service's policy agent (AS-RS) to get a delegated access = token.
    8. The other user agent (RO') can 
      1. use that access token to invoke the resource, = or
      2. delegate it to a client of its choice, or
      3. contract with a policy agent (AS-RO') of its choosing to manage those delegations on its behalf, = or
      4. specify a policy with the service's policy agent (AS-RS).
    9. and so on
    =
    When any of these computational agents, user agents (ROs) or clients acting on their behalf, invokes the resource, AS-RS verifies that the access token is a valid delegation, i.e., proper sub-scoping, hasn't been revoked, and that it authorizes the request being made before telling the service (RS) to honor the request.  = At no point does the service's policy agent (AS-RS) know which computational agent did any particular = delegation.  (Token exchange can be done as anonymously as = possible.)  In particular, the policy agents (AS-RO) need not be the same, or even compatible with, the service's policy agent (AS-RS).  = GNAP specifies the protocol between requesters, invokers, delegators (for token exchange) of tokens and AS-RS.  = That protocol need not be used between user agents (RO), clients, or other policy agents (AS-RO), but it is likely to be.

     -------------
    Alan Karp


    On Thu, Mar 25, 2021 at 5:45 AM Justin Richer <jricher@mit.edu> wrote:
    The way I=E2=80=99m thinking about Adrian=E2=80=99s= use case is that what we=E2=80=99= re calling the =E2=80=9CAS-RO=E2= =80=9D isn=E2=80=99t an =E2=80=9CAS=E2= =80=9D in the traditional OAuth/GNAP sense, at least not exactly. This is the agent that the RO can use to set policies and manage consent on their behalf, and I=E2=80=99ve = been arguing that it fits better into this = vaguely-defined =E2=80=9Cinterac= tion component=E2=80=9D= aspect of the current AS definition, and it=E2=80=99s= not currently separated from the AS definition. The = =E2=80=9CAS-RS=E2=80=9D maps to what we=E2=80=99d = call the =E2=80=9CAS=E2=80= =9D in OAuth/GNAP traditionally, it=E2=80=99s = what the RS trusts to issue tokens. In traditional OAuth the AS-RO and AS-RS are always the same thing, from a functional protocol perspective. An important point here is that from a client=E2=80=99s= perspective, they=E2=80=99re = only talking to the AS-RS since that=E2=80=99s = where the client gets its tokens, because at the end of the day the client just wants to call the API at the RS and doesn=E2=80=99t = care how that happens (from a protocol = standpoint). 

    Note well: Even thought I don=E2=80=99t = believe that = =E2=80=9CAS-RO=E2=80=9D is an authorization server at all, I=E2=80=99m = going to keep using that term below for consistency with previous = discussion.

    So we have these fundamental relationships around getting the client to access the = RS:

    1. RS = trusts AS-RS to issue tokens that RS will accept, validate, and process for requests from client
    2. Client = trusts AS-RS to issue tokens that client can use at = RS
    3. RO trusts RS to protect RO=E2=80=99s = api through delegated access

    On top of that, we=E2=80=99ve = got some additional aspects that we=E2=80=99re = discussing:

    4. RO = trusts AS-RO to manage RO=E2=80=99= s policies at runtime
    5. AS-RS trusts AS-RO to assert RO=E2=80=99= s policies for access to = RS
    6. Client trusts whatever AS-RS sends client to deal with, including possibly = RO-AS at runtime, because of = (2)

    What I have been saying is that 4/5/6 are optional details of how RS-AS runs things, and I think this also maps with Adrian=E2=80=99s= view of choice, since if my RS=E2=80=99s = AS-RS doesn=E2=80=99t = allow me to plug in my own AS-RO then I would be motivated to pick a different RS who=E2=80=99s = AS-RS lets me do just that. The same way I=E2=80= =99d pick a different RS if their surrounding services didn=E2=80=99t = accept my preferred federation login and I didn=E2=80=99t = want to make another account. Of course, market forces being as they are, I might not have much of an actionable choice in RS, but GNAP = can=E2=80=99t change = that. 

    What we can do is make it possible for AS-RS to talk to AS-RO, both in philosophy of the protocol design and in concrete hooks to support (6) = above. 

    Separately, we can approach the issue of making 1/2 above more dynamic. This was UMA2=E2=80=99= s =E2=80=9Cfederat= ed = authorization=E2=80=9D approach, and is behind a lot of the =E2=80=9Cbring = your own AS=E2=80=9D = models out there. The problem with these is that we know from many years of experience that most = RS=E2=80=99s aren=E2=80=99t interested in doing anything of the = sort.

    So with GNAP we can instead allow 4/5/6 to vary in a predictable and consistent way, letting the RS keep control over 1/2, thereby enabling choice in (3). We don=E2=80=99t= have to be the ones who define the all of the details of every permutation of (5) to enable this, though. Some of this is going to be configuration out of band, some of it=E2=80= =99s going to be communication at runtime. This is where VC=E2=80=99s, = ZCAPs, CHAPI, DIDComm, FIDO, and a whole swath of other tech can come in and help out. I don=E2=80= =99t think we need to put all the details for using these into core, nor do I think we=E2=80=99ll = pull of The Great And Ultimate Abstraction for using these and other approaches. But we can at least start talking about =E2=80=9CAS-RS=E2= =80=9D in such a way that it no longer assumes it=E2=80=99s = always the same party dealing with the RO directly.

     =E2=80=94 Justin

    On Mar 25, 2021, at 6:40 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    =
    To reframe it closer to GNAP:
    - AS =3D AS-RO, that's where you find the RO policies. The AS issues access tokens to the = client.
    - the RO policies could be a) defined locally or b) in relationship with the = RS

    There have been several ideas related to the AS-RS relationship b:
    b1) the RS issues capabilities (which can be further attenuated by the RO)
    b2) Adrian also discussed a DID based solution
    b3) there was also an alternative ACL proposal from Denis (+ = preflight)

    Fabien


    On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Ok so I get you = correctly: 
    - what matters is the RQ (could be a RO or a end-user or both : we don't really care at a high-level, they're all treated as entities that make a request)
    - the policy is able to handle those different cases, based on its own internal delegation protocol
    - currently that requires AS-RS and AS-RO, but maybe it can be = simplified

    To answer to Denis, here's what I = understood:
    - RO trusts AS-RS (and then handles its own policies within = AS-RO)
    - end-user trusts AS-RO (through its client)

    Could probably work but that's a fairly different model compared to OAuth2 (and of today's GNAP), with different frontiers between the AS and the = RS. 

    Please do not hesitate to correct me if I'm = wrong.

    Fabien 

    On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper = <agropper@healthurl.com> wrote:
    I believe there are alternatives to having two kinds of ASs. The problem may be a side-effect of deciding to switch away form treating the RO as different from the RQ. That leads to downstream privacy issues. Our desire for architectural simplicity is admirable but that may have been a step too far.

    There may also be solutions based on different types of tokens, as in different capabilities (tokens signed by the RS) vs. tokens signed by the AS. = I=E2=80=99m not sure about that but Alan might have more to = say.

    Adrian

    On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Thanks. The general problem statement is clear.

    The proposed solution a bit less (to me). I understood that from point 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obvious reason to have two types of = ASs". Do you see an alternative = ?

    Regarding the last item, I don't think that naming RQ by end-user created the problem. It might just highlight the asymmetry, which fundamentally exists. 

    Fabien


    On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper = <agropper@healthurl.com> wrote:
    Recap:
    1 - Justin (I think) introduced the idea of an AS on the RS trust boundary side.
    2 - I said the RO should not have to share policies with the RS.
    3 - Alan invented the concept of AS-RO and AS-RS to separate two kinds of = PDPs. 

    The thing is that step 2 is not symmetrical. The RO has a legitimate privacy interest in keeping their policies private and minimizing the leakage of information about requests that are posed against those = policies. 

    The RS, on the other hand, should be publishing its policies (e.g. what it=E2=80=99= s selling or what jurisdiction it=E2=80=99s = in or what tokens or scopes it supports). The RS has no obvious privacy interest in GNAP. It=E2=80=99= s just an = enforcer.

    There is one other privacy interest to consider around the RS and that is the requesting party (the end-user that is not the RO :-) might prefer to share attributes with the RS instead of the RO or something controlled by the RO. This case could be an = =E2=80=9Cextension=E2=80=9D to GNAP and might result in a split AS as a solution. This problem was introduced when the editors decided to replace RQ with end-user. Obviously, the RO end-user has no privacy interests relative to itself.

    Adrian




    On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    I was referring to "By my definition, this model has two ASs since both are processing requests into tokens". If there's no reason to have 2 types of ASs, that's fine = then. 
    But I'm a bit lost in where we stand with the = idea. 

    Could you = recap? 

    Fabien 

    Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper = <agropper@healthurl.com> a = =C3=A9crit :
    There=E2=80=99s no obvious reason to have two types of ASs. Any AS that is executing the policies of the RS can look to GNAP like the RS itself. Why would GNAP expose that interface to = anyone? 

    Adrian

    On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Note : I'm not sure that's a good idea, but having 2 types of ASs is not that easy to grasp.

    Fabien 

    Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault = <fabien.imbault@gmail.com> a = =C3=A9crit :
    The purpose of either handling policies locally or delegating them to the RO = agent. 

    Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper = <agropper@healthurl.com> a = =C3=A9crit :
    What purpose would be served by GNAP splitting the AS into two = components?

    Adrian 

    On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Isn't the AS-RO a component of the AS? Same idea as the interact component, it functionnally belongs to the AS role but could be deployed either as a monolith or as a separate = component?

    Fabien

    Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper = <agropper@healthurl.com> a = =C3=A9crit :
    Yes, but I would say it=E2=80=99s= not the RO that wants the access token. It=E2=80=99s = the RO that wants the client making the request to get an access = token. 

    Adrian

    On Wed, Mar 24, 2021 at 11:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Adrian Gropper <agropper@healthurl.com> wrote:

    In this design, the AS is the AS-RS and the agent is the AS-RO. By my definition, this model has two ASs since both are processing requests into tokens. The problem with this is complexity and privacy. The RO may not want to share the request information with the AS-RS.
    =

    More precisely, RO has no choice but to present the required information to AS-RS if RO wants an access = token.  However, RO does not want AS-RS to know the policy by which RO delegates tokens.  That's why RO uses AS-RO for those = delegations.

    = --------------
    Alan = Karp


    On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper = <agropper@healthurl.com> wrote:
    Thank you for creating the issue. My definition of AS is independent of AS-RO or AS-RS. https://github.com/ietf-wg-gnap/gnap-core-protoco= l/issues/223#issuecomment-806280421 I also agree with Alan's definition based on delegation. An AS-RS would be a delegate of the = RS. 

    Based on that, I see it as = obvious that the policy has to be accessible (defined locally?) in order for it to be run as the code that turns a request into an access = token. 

    The only other possibility is that the request is packaged by the AS and sent elsewhere (an agent) for evaluation against policy and a proto-token returned. In that case the AS is acting as a proxy and the PDP is elsewhere. I can imagine that an AS-RS would behave this way so that the proto-token could be turned into an access token by the AS-RS. Isn't this what Justin is proposing? In this design, the AS is the AS-RS and the agent is the AS-RO. By my definition, this model has two ASs since both are processing requests into tokens. The problem with this is complexity and privacy. The RO may not want to share the request information with the AS-RS.

    Adrian

    On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Isn't that what the AS is supposed to be, only with the caveat that the policy is defined locally? 

    Fabien 


    Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp = <alanhkarp@gmail.com> a = =C3=A9crit :
    AS-RO is an AS that RO trusts to delegate RO's access tokens according to RO's = policies.  
    =

    = --------------
    Alan = Karp


    On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Hi Alan and Adrian,

    I've created issue AS-RO policy delegation (https://github.com/ietf-wg-gnap/gnap-core-protoco= l/issues/223) to capture your = input. 
    A first question that arises: can we give a definition to AS-RO?

    Thanks
    Fabien

    On Tue, Mar 23, 2021 at 4:15 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan, 

    Yes, but in that flow, the token relationship between AS-RS and AS-RO is only secure if the tokens issued by AS-RS are = cryptographically attenuable in the first = place. 
     
    =
    Attenuated delegation is a requirement, but that doesn't have to be done = cryptographically.  Token exchange works just fine.  = SPKI and zcap-ld are examples of the crypto approach, and we used token exchange in the system for HP.

    = --------------
    Alan = Karp


    On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Hi Alan, 

    Yes, but in that flow, the token relationship between AS-RS and AS-RO is only secure if the tokens issued by AS-RS are = cryptographically attenuable in the first = place. 

    Fabien

    On Mon, Mar 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin Richer <jricher@mit.edu> wrote:
    =

    But with all that in mind, I think the key here is going to be looking at what the inputs to the AS are, and how those can be defined in an interoperable way for AS=E2=80= =99s that can accept them. I think = there=E2=80=99s a lot of room for innovation and flexibility here that doesn=E2=80=99t = break the trust model or core use cases. If I have an AS-RS set that won=E2=80=99t = accept my favorite flavor of policy engine inputs, then I can decide not to use that one. But this is a very different question than saying the RS itself needs to accept my own AS =E2=80=94= and we can=E2=80=99t= keep conflating these two models.

    I agree.  = The point of having an AS-RO is to allow RO to specify a policy for which of RO's access tokens should be delegated under what = conditions.  AS-RS should not need to understand those = policies.  The flow would = be
    =
    • RO contacts AS-RS and gets one or more access tokens.
    • RO delegates one or more of those tokens, potentially sub-scoped, to AS-RO.
    • A= different user contacts AS-RO to get a potentially sub-scoped access token from = AS-RO.
    • That user presents the access token delegated by AS-RO when invoking the resource.
    =
    AS-RS only needs to verify that the delegation chain is legitimate, e.g., no increase in scope, and that it grants permission for the request being = made.  AS-RS does not need to understand the policy behind granting the delegation by AS-RO.

    = --------------
    Alan = Karp


    On Mon, Mar 22, 2021 at 11:40 AM Justin Richer = <jricher@mit.edu> wrote:
    Adrian,

    I think this shows the problem with the terminology as it=E2=80=99s = been applied in this conversation, which I=E2=80=99= ve tried to shine light on before. What you and others are calling the =E2=80=9CRS=E2= =80=9D is really the = =E2=80=9CAS and RS working together=E2=80=9D= =E2=80=94 everything to the right of the line. When Denis had brought up =E2=80=9Celimina= ting the AS=E2=80=9D = in another thread, what he=E2=80=99d = really done is labeled everything to the right of the line as the =E2=80=9CRS=E2= =80=9D. Of course, the irony here is that everything to the right of the line used all be called the =E2=80=9CAS=E2= =80=9D or simply =E2=80=9Cserver=E2= =80=9D in the OAuth 1 days. As you say below, I don=E2=80=99t = want the client to have visibility on what happens on that = side. 

    Note well: The Google+ logo labeled = =E2=80=9CIdP=E2=80=9D in the diagram is not the AS, as far as GNAP is concerned. It does not issue an access token that the RS will accept. The elements to the left of the line could be a lot of things, but they are NOT the AS =E2=80=94= by definition. The client lives over on the left, but so do any external inputs to the AS. These could be policy inputs on behalf of the RO, they could be presentation artifacts, they could be federated logins, they could be the output of policy decisions. How the AS comes to trust those things is up to the AS=E2=80=99= s = implementation. It=E2=80=99s = something we can talk about, but ultimately GNAP won=E2=80=99= t be in any position to dictate because in practice some AS=E2=80=99s = are simply going to internalize all policies and we will never successfully force those = open. 

    But with all that in mind, I think the key here is going to be looking at what the inputs to the AS are, and how those can be defined in an interoperable way for AS=E2=80= =99s that can accept them. I think = there=E2=80=99s a lot of room for innovation and flexibility here that doesn=E2=80=99t = break the trust model or core use cases. If I have an AS-RS set that won=E2=80=99t = accept my favorite flavor of policy engine inputs, then I can decide not to use that one. But this is a very different question than saying the RS itself needs to accept my own AS =E2=80=94= and we can=E2=80=99t= keep conflating these two models.

    So to me, GNAP can support a Zero Trust Architecture by LEVERAGING the AS, not by subsuming or eliminating it. It is in fact the AS, not the client and not the RS, that will request and consume the results of a = privacy-preserving zero-trust policy query thing. Anything that happens downstream from that is of little concern to the zero-trust components because, as you point out, it=E2=80=99s = on the =E2=80=9Cother = side=E2=80=9D of the = line. 

    I think we got this basic component model pretty right in OAuth: the AS and RS and client working together. Where OAuth misses the mark is the assumption that the user has to log in to the AS through a webpage and interact directly, thereby proving they=E2=80=99re = the RO. It=E2=80=99s= this latter space where I think we can both push innovation and also address the important and compelling use cases like the ones you=E2=80=99re = bringing.

     =E2=80=94 Justin

    On Mar 22, 2021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    =
    I'm sorry, Justin. As a Resource Owner, I look at the RS trust boundary (the dotted line in the diagram) as being the RS. I don't expect any visibility into what's going on on = the right. 

    My problem with the framing you propose is that requests are going to the RS (or the AS-RS) and I don't want to share my policies with the AS-RS. I want to keep the RS and AS-RS as ignorant as = possible.

    Adrian

    On Mon, Mar 22, 2021 at 1:48 PM Justin Richer = <jricher@mit.edu> wrote:
    Adrian,

    What you=E2=80=99re discussing below, in terms of logging in to a site, is not approaching the RS. You are in fact approaching the client, and identifying both the AS and RS to the client. The client is a client of your = identity in this model, and the RS is part of the identity provider. = It=E2=80=99s really important that we don=E2=80=99t= conflate the RS and client in this way as it leads to a lot of confusion downstream and a lot of broken trust = boundaries.

    With that model in mind, approaching the =E2=80=9CRS"= and providing it your identity is really just a case of the =E2=80=9Cfederat= ed login to AS=E2=80= =9D pattern that we discussed on the WG call. The user here approaches an RS, which has its own AS. To share things from this RS, the RO has to authenticate to the RS=E2=80=99= s AS. This particular AS allows the RO to do so using an external identity =E2=80=94= in which case, the AS is now a =E2=80=9Cclien= t=E2=80=9D of a separate, disconnected (but layered) delegation. The ultimate client that eventually calls the RS down the way may or may not know about these = layers. 

    <PastedGraphic-1.png>
    This same AS, which is closely tied to the RS and trusted by the RS, might also take in FIDO credentials, or DIDs, or any number of other proof mechanisms. The output of this is an access token the RS trusts, but the input is up to the AS. The RS is not what you=E2=80=99re = logging in to.

     =E2=80=94 Justin

    On Mar 22, 2021, at 1:28 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    =
    I too am in favor of avoiding consolidation and correlation. Right now, when I approach a service provider (RS) for the first time, I'm offered the opportunity to identify my persona as: email, sign-in with Google, Facebook, or Apple. I know there are people who try to create one-off email addresses but that is mostly a waste of time. 

    So, along come FIDO2 and DID wallets to the rescue. Now, in theory, I have a way to start out my RS relationship = pseudonymously. 

    When I want my resource to be discovered or shared I will post that RS URL including my pseudonym. If I then want to introduce a = mediator in front of my AS or messaging = service endpoint, I have that option. If I want to keep requests away from the mediator, I would publish an encryption key along with my = pseudonym.

    - Adrian



    On Mon, Mar 22, 2021 at 9:55 AM Justin Richer = <jricher@mit.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper = wrote:
    >> @Alan Karp <alanhkarp@gmail.com> shared a talk about the Principle Of Least
    >> Authority (POLA) in a recent = comment
    >> https://github.com/ietf-wg-gnap/gnap-core-protoco= l/issues/145#issuecomment-803099693
    >> I recommend = it.
    >>
    >> We might expect a protocol with authorization in the title to use authority
    >> as a core principle. I advocate for a GNAP design that maximizes the power
    >> of the RO, to be seen as a human rights issue when the RO is a human. This
    >> causes me to ask how to combine better security with better human rights in
    >> = GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO = to
    >> partition limited authority across dozens of different ASs by domain and
    >> function, then we are not using technology to empower the individual.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into = non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because that maps
    >> into the way we manage our public and private identities. POLA would then
    >> teach care in keeping ASs and RSs related to work / public separate = from
    >> ASs and RSs related to private life so that a policy vulnerability in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least = authority/least privilege would apply to GNAP
    > seems like a useful = exercise.  I do want to point out some potential
    > pitfalls with = one-AS-per-persona that we can also be aware of.  = If
    > = one-AS-per-persona becomes = one-persona-per-AS as well, then the AS's
    > identity in effect also serves as a persona identity and there are privacy
    > considerations to that.  = If, on the other hand, the
    > = multiple-personas-per-AS (presumably corresponding to multiple humans)
    > route is taken, we should consider whether that would lead to various
    > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS = services.  That topic is a current matter of concern to
    > some IETF = participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the UMA working group, and it=E2=80=99s= one of the biggest problems with the personal AS (and personal data store) model. This kind of thing makes RS-first trust models really difficult in practice.

    As a strawman, let=E2=80=99s = say that I=E2=80=99ve = got software that wants to access my medical information. It calls an RS and requests access, but it hasn=E2=80=99t = been granted anything yet. Now I as the RO have set up the RS so that it talks to my personal AS, that only I use. In addition to the RS having to be able to figure out which medical records are being requested from the context of the = unauthenticated request (which means it needs identifiers in the URL or something similar for the RS to be able to tell, assuming that it protects data for more than one person). So this client software doesn=E2=80=99t = know who I am and doesn=E2=80=99t = know my medical record information, makes a completely unauthorized request to the RS, and the RS says =E2=80=9CGo= to Justin=E2=80=99s= personal AS to get a = token=E2=80=9D. The client can now make a direct correlation between the data that=E2=80=99= s being protected at the RS and the person running the AS that protects it. Importantly, this client makes this call with no prior relationship to the RS and no really auditable way to track it down after the fact. This is a design feature in the good case, and terrifying in the bad = case.

    If the RS instead says =E2=80=9Cwelcome= to Medicine Doctor RS, please talk to the Medicine Doctor AS to get access=E2=80= =9D, we haven=E2=80=99= t exposed anything at all. And from the perspective of both the patient and the RS, this is more = privacy-preserving, and it=E2=80=99s= really the least surprising option. Once the client gets to the AS, it can start a negotiation of figuring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS, or set of AS=E2=80=99s = for multiple personas to keep things separate, is a huge burden. Even in the tech community, I know people who can=E2=80=99= t reliably manage more than one email address for different purposes. I wouldn=E2=80=99t= expect my partner to do that =E2=80=94 = they have trouble enough balancing all the logins and sessions required for different kids remote schooling, I couldn=E2=80=99t= imagine them having to understand all the requirements for managing multiple authorization servers and associated policies. I also don=E2=80=99= t expect any person to =E2=80=9Cmanage = keys=E2=80=9D =E2=80=94 = I=E2=80=99ve been on the internet for decades and I can barely keep tabs on my GPG keys, and only use them when I am forced to. This is exactly the kind of =E2=80=9Cmarket pressure=E2=80=9D= that I think Ben mentions above, people will just want to outsource that to someone else, and the reality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice only to end up with a world where the RS ends up making a limited choice anyway. We see how that plays out with OpenID Connect =E2=80=94 = RP=E2=80=99s could allow arbitrary IdPs but they choose Google because it works and that=E2=80=99s = where the users are. (And that=E2=80=99= s not to say anything of the proprietary OIDC-like protocols, but that=E2=80=99s = another = discussion).

    For further reading on these topics, I recommend both =E2=80=9CWh= y Johnny Can=E2=80= =99t Encrypt=E2=80=9D= and =E2=80=9CWhy = CSCW Systems = Fail=E2=80=9D.

    So what does this have to do with GNAP? I think we can be clear-eyed on what kinds of expectations we have for the participants. If we expect users (RO=E2=80=99= s) to have to set up the AS-RS relationship, or expect them to carry their AS, or manage their personal keys =E2=80=94 = I think we=E2=80=99ve = lost the battle for relevance.

     =E2=80=94 = Justin


    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= br class=3D"">
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= br class=3D"">
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= br class=3D"">


    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= br class=3D"">





    = --Apple-Mail=_D35AE2A6-3D28-4CA0-B621-7A7525635810-- From nobody Fri Mar 26 10:27:15 2021 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 81DCF3A23B3 for ; Fri, 26 Mar 2021 10:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 HaNzEaay6Qii for ; Fri, 26 Mar 2021 10:27:06 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A4043A23B1 for ; Fri, 26 Mar 2021 10:27:04 -0700 (PDT) Received: from [192.168.1.11] ([90.79.53.231]) by mwinf5d85 with ME id l5T1240094zJUWJ035T1Y6; Fri, 26 Mar 2021 18:27:02 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Fri, 26 Mar 2021 18:27:02 +0100 X-ME-IP: 90.79.53.231 To: Justin Richer Cc: txauth@ietf.org References: <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> <5773FA7B-6891-4227-A8CA-2F506909B8CD@mit.edu> <3c103293-56a1-4be5-e2a3-12eb82d13238@free.fr> <91D11E67-34AB-4426-803C-7B5A6F50537F@mit.edu> From: Denis Message-ID: Date: Fri, 26 Mar 2021 18:27:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <91D11E67-34AB-4426-803C-7B5A6F50537F@mit.edu> Content-Type: multipart/alternative; boundary="------------DB453B141C0C9C7C416DF8F8" Content-Language: fr Archived-At: Subject: Re: [GNAP] Relationship between Authentication and Authorization ? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2021 17:27:14 -0000 This is a multi-part message in MIME format. --------------DB453B141C0C9C7C416DF8F8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Justin, Let me rephrase the last question: How will a RS or a RO be bootstrapped for working with a GNAP "sub" claim or a "sub_id" claim ? Denis > GNAP doesn’t have anything too say about anybody authenticating > directly to the RS. If that happens, it’s out of the view and out of > scope of GNAP. > >  — Justin > >> On Mar 26, 2021, at 1:06 PM, Denis > > wrote: >> >> Hi everybody, >> >> The content of this thread has nothing to do any more with its >> original title which was: "Will GNAP support Zero Trust Architecture?" >> Since I am going to use some sentences of this thread to open a new >> topic, I changed the title of this thread into : >> "Relationship between Authentication and Authorization ?" >> >> At the moment, I got the impression that nobody agrees any more about >> *what GNAP is or is not, what it should address and what it should >> not address*. >> The components of the model are becoming more numerous and hazy. A >> new terminology is sometimes being used, but is not yet present in >> the last published draft. >> >> I still can't understand any of the new terms that are being used >> (*AS-RS* and *AS-RO*), _which are still left undefined_. >> >> The last exchanges look more as conversations between workers during >> the construction of the Babel tower. >> >> Last year, my first remark was to mention that a section or an Annex >> explaining the common points and the differences with OAuth 2.0 >> would be useful. Such section or Annex still does not exist. >> >> Justin wrote: >> >> /If an RS allows a username/password HTTP Basic auth in addition >> to accepting access tokens, it can do so, but // >> //GNAP doesn’t have anything to say about the Basic auth use, or >> even its relation to any access tokens or RO’s or anything else./ >> >> Let us split the end of this sentence into two parts: >> >> "/GNAP doesn’t have anything //to say about the Basic auth use/":  If >> an authentication exchange  is necessary, the draft document should >> describe, for completeness, >> the HTTP error code that will be returned. >> >> "/or even its relation to any access tokens or RO’s or anything >> else/". Let us suppose that a RS supports FIDO as an authentication >> mechanism to authenticate its end-users. >> FIDO provides the major advantage that, for every RS, a different >> identifier is used by every end-user. This prevents end-users >> accounts correlations between RSs by using >> such identifiers. In practice, a FIDO identifier is a pseudonym. >> >> At this very moment, the RS is able to identify and authenticate its >> end-users using FIDO pseudonyms. Now, let us raise the following >> question: >> >> How will a RS be bootstrapped for working with a GNAP "sub" claim or >> a "sub_id" claim, whereas FIDO is already being used ? >> >> Denis >> >> >>> Adrian, >>> >>> I disagree, I believe that what I have laid out is exactly >>> separating the concerns into working components. >>> >>> Like OAuth before it, GNAP is a protocol negotiate access for a >>> client instance to an RS, using an AS as the facilitator of that >>> delegated negotiation. (Unlike OAuth, it’s importantly also for >>> negotiating user information to the client directly from the AS with >>> no RS involved, but that’s an aside for the purposes of our >>> conversation here). >>> >>> If a particular GNAP RS also allows other kinds of processes to >>> enable access to it, that is completely fine, but outside of GNAP. >>> If an RS allows a username/password HTTP Basic auth in addition to >>> accepting access tokens, it can do so, but GNAP doesn’t have >>> anything to say about the Basic auth use, or even its relation to >>> any access tokens or RO’s or anything else. If an RS accepts >>> structured access tokens signed by trusted keys that don’t come from >>> an AS through a negotiated request — again, that’s fine, but GNAP is >>> silent about the RS doing that. If the RS acts as “its own AS” then >>> it’s really just an RS and an AS living in the same box. Again, >>> that’s fine, and super common with OAuth today. >>> >>> GNAP is solving the problem of connecting the client to the RS >>> through means of an AS. Other solutions are possible and many of >>> them can be deployed right alongside, but that’s not the corner of >>> the world that GNAP is solving. GNAP should be concerned about how >>> these other technologies can be used alongside it. I think there’s a >>> lot of room for the things that you’re talking about, and more >>> importantly for solving the use cases that you’re bringing. But GNAP >>> should be more than a single-point solution, and so we need to >>> balance these concerns. The conceptual framework of an AS that takes >>> in lots of different information and spits out access tokens is >>> exactly the abstraction layer that is necessary for making these use >>> cases interoperable. >>> >>>  — Justin >>> >>>> On Mar 26, 2021, at 8:30 AM, Adrian Gropper >>> > wrote: >>>> >>>> @Justin, there’s no separation of concerns here. No partition >>>> between processor and controller. No data minimization. And, I see >>>> no obvious reason to make this the core of GNAP. >>>> >>>> The one thing we can probably all agree on is that there’s only one >>>> RS and one RO. >>>> >>>> The core of GNAP, in my opinion, can be built and explained around >>>> this simple design. The RS is a processor. The RO is a controller. >>>> The RS bears only security responsibility. The RS bears no privacy >>>> responsibility. The RO delegates this to the RS but this is not >>>> authorization as the A in GNAP. >>>> >>>> The RO retains all rights to delegate within the scope of things >>>> that the RS is willing to support using various token formats and >>>> endpoint options. Some of these options may do all sorts of things >>>> for all sorts of clients and user-agents  but these are options. >>>> >>>> For example, if a request comes to the RS that is not in the form >>>> of an access token, then it either gets sent to the RO or their >>>> agent, or it gets logged and dumped. One such option, common in >>>> healthcare, is “Break the Glass” where the RS is acting as an >>>> authorization server because the user-agent is making a request >>>> instead of presenting an access token. GNAP can offer this as an >>>> option but it is not our core. >>>> >>>> Adrian >>>> >>>> >>>> >>>> On Fri, Mar 26, 2021 at 7:15 AM Justin Richer >>> > wrote: >>>> >>>> I have a big problem with this line: >>>> >>>> > the RS and AS-RS only see access tokens. The requests (from >>>> RO') that resulted in an access token are none of their business. >>>> >>>> In the trust model we’ve been discussing, the requests that >>>> result in access tokens are *solely the business of AS-RS*, >>>> since AS-RS is the only entity that’s allowed, and trusted by >>>> the RS, to create access tokens for the RS. That is its entire >>>> job, the entire reason it exists in the system. By definition >>>> the party generating tokens for use at the RS is the AS for >>>> that RS, I don’t care how you deploy it. If RO wants to give >>>> access to someone else (who isn’t an “RO" anymore, they’re >>>> another end-user), then that end user’s client software will >>>> need to talk to AS-RS to get its own access token. >>>> >>>> Now here’s the trick: when the end user’s client instance talks >>>> to AS-RS, that does NOT mean that AS-RS needs to know all the >>>> details and policy reasons that it should give an access token >>>> to that client instance. It doesn’t even need to know the >>>> existence of another end user. It doesn’t need identity, it >>>> doesn’t need policy. Sure, it COULD handle all of that >>>> internally, and many will, but the protocol doesn’t demand it. >>>> >>>> This means that the first client instance, the one that gets >>>> the access token, can also be given something alongside the >>>> access token that it can then hand to another piece of software >>>> (or to a person to hand eo their piece of software). This >>>> artifact is not an access token. This artifact could be >>>> something structured that the client understands, and can make >>>> derivatives of, and present back to the AS-RS for getting new >>>> access tokens. There could be multiple different flavors of >>>> this kind of artifact for different kinds of environments and >>>> groups. But what they all have in common is that they can >>>> potentially be used to request more access tokens within some >>>> context at the AS-RS. >>>> >>>>  — Justin >>>> >>>> >>>> >>>>> On Mar 25, 2021, at 5:50 PM, Adrian Gropper >>>>> > wrote: >>>>> >>>>> My issue is with Alan's: >>>>> >>>>> "7. Another user agent (RO') can contact any holder of the >>>>> access token or the service's policy agent (AS-RS) to get >>>>> a delegated access token." >>>>> >>>>> >>>>> I would prefer "7A.Another user agent (RO') can contact any >>>>> holder of the access token." by default so that the AS-RS does >>>>> not see the requests. In other words, the RS and AS-RS only >>>>> see access tokens. The requests (from RO') that resulted in an >>>>> access token are none of their business. >>>>> >>>>> The reality is that RO' can discover a resource RS and can >>>>> share whatever information with RS-AS they want and the RO may >>>>> not even know about it unless the RS decides to let them know >>>>> somehow. This seems to be a drawback of the capabilities >>>>> approach. >>>>> >>>>> In terms of privacy and control, I, as the RO, want a >>>>> contract with the RS that says that I or my agent (AS-RO) must >>>>> sign an access token. This is a fundamental audit requirement. >>>>> Without it, a rogue RS and AS-RS can do all sorts of things >>>>> and the RO would never know. I understand that a rogue RS >>>>> might not support an honest contemporaneous log of access >>>>> tokens presented so there's a trust issue here that I seems >>>>> unavoidable unless I specify in my RO-RS contract that they >>>>> use a separate contemporaneous log such as AS-RO for every >>>>> access token presented and risk being sued if they process an >>>>> access token without also updating the separate log. >>>>> >>>>> - Adrian >>>>> >>>>> >>>>> On Thu, Mar 25, 2021 at 1:22 PM Alan Karp >>>> > wrote: >>>>> >>>>> Justin Richer > >>>>> wrote: >>>>> >>>>> Hi Alan, >>>>> >>>>> In all of my discussion, and in the spec itself, the >>>>> RO is the :entity: in charge of approving rights. >>>>> They’re probably a person. It might be software that >>>>> makes a policy decision in some way, or a corporate >>>>> entity, or something like that. But it’s not assumed >>>>> to be a computational agent in the terms of the >>>>> protocol itself. Would that recast what you’re saying >>>>> below? >>>>> >>>>> >>>>> Hmmm. I guess not. It's just that the person would be >>>>> using some UI to express their decisions to what I called >>>>> the user agent.  That model fits in very nicely with what >>>>> we did with Polaris, our virus safe computing environment >>>>> for Windows XP, >>>>> https://dl.acm.org/doi/10.1145/1151030.1151033 >>>>> . The >>>>> person would click on the icon for a Word file, and an >>>>> instance of Word would open with only the permission >>>>> needed to edit that one file.  Same thing here. The client >>>>> could ask for permission to use the resource, or >>>>> permission could be granted implicitly when the user >>>>> selects a resource associated with a specific client. >>>>> >>>>> -------------- >>>>> Alan Karp >>>>> >>>>> >>>>> On Thu, Mar 25, 2021 at 9:53 AM Justin Richer >>>>> > wrote: >>>>> >>>>> Hi Alan, >>>>> >>>>> In all of my discussion, and in the spec itself, the >>>>> RO is the :entity: in charge of approving rights. >>>>> They’re probably a person. It might be software that >>>>> makes a policy decision in some way, or a corporate >>>>> entity, or something like that. But it’s not assumed >>>>> to be a computational agent in the terms of the >>>>> protocol itself. Would that recast what you’re saying >>>>> below? >>>>> >>>>>  — Justin >>>>> >>>>>> On Mar 25, 2021, at 12:36 PM, Alan Karp >>>>>> > wrote: >>>>>> >>>>>> There seems to be some confusion about how AS-RO >>>>>> comes into the picture, probably because of the "AS" >>>>>> part. I'm going to try to clear up that confusion by >>>>>> more carefully explaining what I mean. >>>>>> >>>>>> I'm assuming that RO is a computational agent >>>>>> representing the person who is the resource owner, >>>>>> something called the "user agent" in operating >>>>>> systems lingo.  I'm also assuming that it's possible >>>>>> to do delegation, either locally or by token exchange >>>>>> with AS-RS.  All delegations are potentially >>>>>> sub-scoped, but you may also want to delegate with >>>>>> full scope to have a separately revocable access token. >>>>>> >>>>>> Here's an example of how things work in a capability >>>>>> oriented system. >>>>>> >>>>>> 1. Someone, the service owner, creates a service. >>>>>> 2. The service owner contracts with an policy agent >>>>>> (AS-RS) to create and manage access tokens for >>>>>> that service (RS). >>>>>> 3. A person wishing to create a resource at RS uses >>>>>> their user agent (RO) to contact the service >>>>>> owner's policy agent (AS-RS) and gets back an >>>>>> access token for that resource. >>>>>> 4. That user agent (RO) can >>>>>> 1. use that access token to invoke the resource, or >>>>>> 2. delegate an access token to a client of the >>>>>> user agent's (RO) choice, or >>>>>> 3. contract with a policy agent (AS-RO) to >>>>>> manage those delegations on behalf of the >>>>>> user agent (RO), or >>>>>> 4. specify a policy with the service's policy >>>>>> agent (AS-RS). >>>>>> 5. A client can contact any holder of the access >>>>>> token (the user agent (RO) or its policy agent >>>>>> (AS-RO)) or the service's policy agent (AS-RS) to >>>>>> get a delegated access token. >>>>>> 6. That client can delegate that token to another >>>>>> client. >>>>>> 7. Another user agent (RO') can contact any holder >>>>>> of the access token or the service's policy agent >>>>>> (AS-RS) to get a delegated access token. >>>>>> 8. The other user agent (RO') can >>>>>> 1. use that access token to invoke the resource, or >>>>>> 2. delegate it to a client of its choice, or >>>>>> 3. contract with a policy agent (AS-RO') of its >>>>>> choosing to manage those delegations on its >>>>>> behalf, or >>>>>> 4. specify a policy with the service's policy >>>>>> agent (AS-RS). >>>>>> 9. and so on >>>>>> >>>>>> When any of these computational agents, user agents >>>>>> (ROs) or clients acting on their behalf, invokes the >>>>>> resource, AS-RS verifies that the access token is a >>>>>> valid delegation, i.e., proper sub-scoping, hasn't >>>>>> been revoked, and that it authorizes the request >>>>>> being made before telling the service (RS) to honor >>>>>> the request.  At no point does the service's policy >>>>>> agent (AS-RS) know which computational agent did any >>>>>> particular delegation. (Token exchange can be done as >>>>>> anonymously as possible.)  In particular, the policy >>>>>> agents (AS-RO) need not be the same, or even >>>>>> compatible with, the service's policy agent (AS-RS).  >>>>>> GNAP specifies the protocol between requesters, >>>>>> invokers, delegators (for token exchange) of tokens >>>>>> and AS-RS.  That protocol need not be used between >>>>>> user agents (RO), clients, or other policy agents >>>>>> (AS-RO), but it is likely to be. >>>>>> >>>>>>  ------------- >>>>>> Alan Karp >>>>>> >>>>>> >>>>>> On Thu, Mar 25, 2021 at 5:45 AM Justin Richer >>>>>> > wrote: >>>>>> >>>>>> The way I’m thinking about Adrian’s use case is >>>>>> that what we’re calling the “AS-RO” isn’t an “AS” >>>>>> in the traditional OAuth/GNAP sense, at least not >>>>>> exactly. This is the agent that the RO can use to >>>>>> set policies and manage consent on their behalf, >>>>>> and I’ve been arguing that it fits better into >>>>>> this vaguely-defined “interaction component” >>>>>> aspect of the current AS definition, and it’s not >>>>>> currently separated from the AS definition. The >>>>>> “AS-RS” maps to what we’d call the “AS” in >>>>>> OAuth/GNAP traditionally, it’s what the RS trusts >>>>>> to issue tokens. In traditional OAuth the AS-RO >>>>>> and AS-RS are always the same thing, from a >>>>>> functional protocol perspective. An important >>>>>> point here is that from a client’s perspective, >>>>>> they’re only talking to the AS-RS since that’s >>>>>> where the client gets its tokens, because at the >>>>>> end of the day the client just wants to call the >>>>>> API at the RS and doesn’t care how that happens >>>>>> (from a protocol standpoint). >>>>>> >>>>>> Note well: Even thought I don’t believe that >>>>>> “AS-RO” is an authorization server at all, I’m >>>>>> going to keep using that term below for >>>>>> consistency with previous discussion. >>>>>> >>>>>> So we have these fundamental relationships around >>>>>> getting the client to access the RS: >>>>>> >>>>>> 1. RS trusts AS-RS to issue tokens that RS will >>>>>> accept, validate, and process for requests from >>>>>> client >>>>>> 2. Client trusts AS-RS to issue tokens that >>>>>> client can use at RS >>>>>> 3. RO trusts RS to protect RO’s api through >>>>>> delegated access >>>>>> >>>>>> On top of that, we’ve got some additional aspects >>>>>> that we’re discussing: >>>>>> >>>>>> 4. RO trusts AS-RO to manage RO’s policies at runtime >>>>>> 5. AS-RS trusts AS-RO to assert RO’s policies for >>>>>> access to RS >>>>>> 6. Client trusts whatever AS-RS sends client to >>>>>> deal with, including possibly RO-AS at runtime, >>>>>> because of (2) >>>>>> >>>>>> What I have been saying is that 4/5/6 are >>>>>> optional details of how RS-AS runs things, and I >>>>>> think this also maps with Adrian’s view of >>>>>> choice, since if my RS’s AS-RS doesn’t allow me >>>>>> to plug in my own AS-RO then I would be motivated >>>>>> to pick a different RS who’s AS-RS lets me do >>>>>> just that. The same way I’d pick a different RS >>>>>> if their surrounding services didn’t accept my >>>>>> preferred federation login and I didn’t want to >>>>>> make another account. Of course, market forces >>>>>> being as they are, I might not have much of an >>>>>> actionable choice in RS, but GNAP can’t change that. >>>>>> >>>>>> What we can do is make it possible for AS-RS to >>>>>> talk to AS-RO, both in philosophy of the protocol >>>>>> design and in concrete hooks to support (6) above. >>>>>> >>>>>> Separately, we can approach the issue of making >>>>>> 1/2 above more dynamic. This was UMA2’s >>>>>> “federated authorization” approach, and is behind >>>>>> a lot of the “bring your own AS” models out >>>>>> there. The problem with these is that we know >>>>>> from many years of experience that most RS’s >>>>>> aren’t interested in doing anything of the sort. >>>>>> >>>>>> So with GNAP we can instead allow 4/5/6 to vary >>>>>> in a predictable and consistent way, letting the >>>>>> RS keep control over 1/2, thereby enabling choice >>>>>> in (3). We don’t have to be the ones who define >>>>>> the all of the details of every permutation of >>>>>> (5) to enable this, though. Some of this is going >>>>>> to be configuration out of band, some of it’s >>>>>> going to be communication at runtime. This is >>>>>> where VC’s, ZCAPs, CHAPI, DIDComm, FIDO, and a >>>>>> whole swath of other tech can come in and help >>>>>> out. I don’t think we need to put all the details >>>>>> for using these into core, nor do I think we’ll >>>>>> pull of The Great And Ultimate Abstraction for >>>>>> using these and other approaches. But we can at >>>>>> least start talking about “AS-RS” in such a way >>>>>> that it no longer assumes it’s always the same >>>>>> party dealing with the RO directly. >>>>>> >>>>>>  — Justin >>>>>> >>>>>>> On Mar 25, 2021, at 6:40 AM, Fabien Imbault >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> To reframe it closer to GNAP: >>>>>>> - AS = AS-RO, that's where you find the RO >>>>>>> policies. The AS issues access tokens to the client. >>>>>>> - the RO policies could be a) defined locally or >>>>>>> b) in relationship with the RS >>>>>>> >>>>>>> There have been several ideas related to the >>>>>>> AS-RS relationship b: >>>>>>> b1) the RS issues capabilities (which can be >>>>>>> further attenuated by the RO) >>>>>>> b2) Adrian also discussed a DID based solution >>>>>>> b3) there was also an alternative ACL proposal >>>>>>> from Denis (+ preflight) >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> >>>>>>> On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> Ok so I get you correctly: >>>>>>> - what matters is the RQ (could be a RO or a >>>>>>> end-user or both : we don't really care at a >>>>>>> high-level, they're all treated as entities >>>>>>> that make a request) >>>>>>> - the policy is able to handle those >>>>>>> different cases, based on its own internal >>>>>>> delegation protocol >>>>>>> - currently that requires AS-RS and AS-RO, >>>>>>> but maybe it can be simplified >>>>>>> >>>>>>> To answer to Denis, here's what I understood: >>>>>>> - RO trusts AS-RS (and then handles its own >>>>>>> policies within AS-RO) >>>>>>> - end-user trusts AS-RO (through its client) >>>>>>> >>>>>>> Could probably work but that's a fairly >>>>>>> different model compared to OAuth2 (and of >>>>>>> today's GNAP), with different frontiers >>>>>>> between the AS and the RS. >>>>>>> >>>>>>> Please do not hesitate to correct me if I'm >>>>>>> wrong. >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> On Thu, Mar 25, 2021 at 9:26 AM Adrian >>>>>>> Gropper >>>>>> > wrote: >>>>>>> >>>>>>> I believe there are alternatives to >>>>>>> having two kinds of ASs. The problem may >>>>>>> be a side-effect of deciding to switch >>>>>>> away form treating the RO as different >>>>>>> from the RQ. That leads to downstream >>>>>>> privacy issues. Our desire for >>>>>>> architectural simplicity is admirable >>>>>>> but that may have been a step too far. >>>>>>> >>>>>>> There may also be solutions based on >>>>>>> different types of tokens, as in >>>>>>> different capabilities (tokens signed by >>>>>>> the RS) vs. tokens signed by the AS. I’m >>>>>>> not sure about that but Alan might have >>>>>>> more to say. >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>> On Thu, Mar 25, 2021 at 4:15 AM Fabien >>>>>>> Imbault >>>>>> > wrote: >>>>>>> >>>>>>> Thanks. The general problem >>>>>>> statement is clear. >>>>>>> >>>>>>> The proposed solution a bit less (to >>>>>>> me). I understood that from point 2, >>>>>>> Alan involves 2 ASs. You said : >>>>>>> "There’s no obvious reason to have >>>>>>> two types of ASs". Do you see an >>>>>>> alternative ? >>>>>>> >>>>>>> Regarding the last item, I don't >>>>>>> think that naming RQ by end-user >>>>>>> created the problem. It might just >>>>>>> highlight the asymmetry, which >>>>>>> fundamentally exists. >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> >>>>>>> On Thu, Mar 25, 2021 at 8:48 AM >>>>>>> Adrian Gropper >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> Recap: >>>>>>> 1 - Justin (I think) introduced >>>>>>> the idea of an AS on the RS >>>>>>> trust boundary side. >>>>>>> 2 - I said the RO should not >>>>>>> have to share policies with the RS. >>>>>>> 3 - Alan invented the concept of >>>>>>> AS-RO and AS-RS to separate two >>>>>>> kinds of PDPs. >>>>>>> >>>>>>> The thing is that step 2 is not >>>>>>> symmetrical. The RO has a >>>>>>> legitimate privacy interest in >>>>>>> keeping their policies private >>>>>>> and minimizing the leakage of >>>>>>> information about requests that >>>>>>> are posed against those policies. >>>>>>> >>>>>>> The RS, on the other hand, >>>>>>> should be publishing its >>>>>>> policies (e.g. what it’s selling >>>>>>> or what jurisdiction it’s in or >>>>>>> what tokens or scopes it >>>>>>> supports). The RS has no obvious >>>>>>> privacy interest in GNAP. It’s >>>>>>> just an enforcer. >>>>>>> >>>>>>> There is one other privacy >>>>>>> interest to consider around the >>>>>>> RS and that is the requesting >>>>>>> party (the end-user that is not >>>>>>> the RO :-) might prefer to share >>>>>>> attributes with the RS instead >>>>>>> of the RO or something >>>>>>> controlled by the RO. This case >>>>>>> could be an “extension” to GNAP >>>>>>> and might result in a split AS >>>>>>> as a solution. This problem was >>>>>>> introduced when the editors >>>>>>> decided to replace RQ with >>>>>>> end-user. Obviously, the RO >>>>>>> end-user has no privacy >>>>>>> interests relative to itself. >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Mar 25, 2021 at 3:24 AM >>>>>>> Fabien Imbault >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> I was referring to "By my >>>>>>> definition, this model has >>>>>>> two ASs since both are >>>>>>> processing requests into >>>>>>> tokens". If there's no >>>>>>> reason to have 2 types of >>>>>>> ASs, that's fine then. >>>>>>> But I'm a bit lost in where >>>>>>> we stand with the idea. >>>>>>> >>>>>>> Could you recap? >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> Le jeu. 25 mars 2021 à >>>>>>> 08:16, Adrian Gropper >>>>>>> >>>>>> > >>>>>>> a écrit : >>>>>>> >>>>>>> There’s no obvious >>>>>>> reason to have two types >>>>>>> of ASs. Any AS that is >>>>>>> executing the policies >>>>>>> of the RS can look to >>>>>>> GNAP like the RS itself. >>>>>>> Why would GNAP expose >>>>>>> that interface to anyone? >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>> On Thu, Mar 25, 2021 at >>>>>>> 3:11 AM Fabien Imbault >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Note : I'm not sure >>>>>>> that's a good idea, >>>>>>> but having 2 types >>>>>>> of ASs is not that >>>>>>> easy to grasp. >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> Le jeu. 25 mars 2021 >>>>>>> à 08:07, Fabien >>>>>>> Imbault >>>>>>> >>>>>> > >>>>>>> a écrit : >>>>>>> >>>>>>> The purpose of >>>>>>> either handling >>>>>>> policies locally >>>>>>> or delegating >>>>>>> them to the RO >>>>>>> agent. >>>>>>> >>>>>>> Le jeu. 25 mars >>>>>>> 2021 à 08:04, >>>>>>> Adrian Gropper >>>>>>> >>>>>> > >>>>>>> a écrit : >>>>>>> >>>>>>> What purpose >>>>>>> would be >>>>>>> served by >>>>>>> GNAP >>>>>>> splitting >>>>>>> the AS into >>>>>>> two components? >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>> On Thu, Mar >>>>>>> 25, 2021 at >>>>>>> 2:59 AM >>>>>>> Fabien >>>>>>> Imbault >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Isn't >>>>>>> the >>>>>>> AS-RO a >>>>>>> component >>>>>>> of the >>>>>>> AS? Same >>>>>>> idea as >>>>>>> the >>>>>>> interact >>>>>>> component, >>>>>>> it >>>>>>> functionnally >>>>>>> belongs >>>>>>> to the >>>>>>> AS role >>>>>>> but >>>>>>> could be >>>>>>> deployed >>>>>>> either >>>>>>> as a >>>>>>> monolith >>>>>>> or as a >>>>>>> separate >>>>>>> component? >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> Le jeu. >>>>>>> 25 mars >>>>>>> 2021 à >>>>>>> 04:26, >>>>>>> Adrian >>>>>>> Gropper >>>>>>> >>>>>> > >>>>>>> a écrit : >>>>>>> >>>>>>> Yes, >>>>>>> but >>>>>>> I >>>>>>> would >>>>>>> say >>>>>>> it’s >>>>>>> not >>>>>>> the >>>>>>> RO >>>>>>> that >>>>>>> wants >>>>>>> the >>>>>>> access >>>>>>> token. >>>>>>> It’s >>>>>>> the >>>>>>> RO >>>>>>> that >>>>>>> wants >>>>>>> the >>>>>>> client >>>>>>> making >>>>>>> the >>>>>>> request >>>>>>> to >>>>>>> get >>>>>>> an >>>>>>> access >>>>>>> token. >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>> On >>>>>>> Wed, >>>>>>> Mar >>>>>>> 24, >>>>>>> 2021 >>>>>>> at >>>>>>> 11:22 >>>>>>> PM >>>>>>> Alan >>>>>>> Karp >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Adrian >>>>>>> Gropper >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> In >>>>>>> this >>>>>>> design, >>>>>>> the >>>>>>> AS >>>>>>> is >>>>>>> the >>>>>>> AS-RS >>>>>>> and >>>>>>> the >>>>>>> agent >>>>>>> is >>>>>>> the >>>>>>> AS-RO. >>>>>>> By >>>>>>> my >>>>>>> definition, >>>>>>> this >>>>>>> model >>>>>>> has >>>>>>> two >>>>>>> ASs >>>>>>> since >>>>>>> both >>>>>>> are >>>>>>> processing >>>>>>> requests >>>>>>> into >>>>>>> tokens. >>>>>>> The >>>>>>> problem >>>>>>> with >>>>>>> this >>>>>>> is >>>>>>> complexity >>>>>>> and >>>>>>> privacy. >>>>>>> The >>>>>>> RO >>>>>>> may >>>>>>> not >>>>>>> want >>>>>>> to >>>>>>> share >>>>>>> the >>>>>>> request >>>>>>> information >>>>>>> with >>>>>>> the >>>>>>> AS-RS. >>>>>>> >>>>>>> >>>>>>> More >>>>>>> precisely, >>>>>>> RO >>>>>>> has >>>>>>> no >>>>>>> choice >>>>>>> but >>>>>>> to >>>>>>> present >>>>>>> the >>>>>>> required >>>>>>> information >>>>>>> to >>>>>>> AS-RS >>>>>>> if >>>>>>> RO >>>>>>> wants >>>>>>> an >>>>>>> access >>>>>>> token. >>>>>>> However, >>>>>>> RO >>>>>>> does >>>>>>> not >>>>>>> want >>>>>>> AS-RS >>>>>>> to >>>>>>> know >>>>>>> the >>>>>>> policy >>>>>>> by >>>>>>> which >>>>>>> RO >>>>>>> delegates >>>>>>> tokens. >>>>>>> That's >>>>>>> why >>>>>>> RO >>>>>>> uses >>>>>>> AS-RO >>>>>>> for >>>>>>> those >>>>>>> delegations. >>>>>>> >>>>>>> -------------- >>>>>>> Alan >>>>>>> Karp >>>>>>> >>>>>>> >>>>>>> On >>>>>>> Wed, >>>>>>> Mar >>>>>>> 24, >>>>>>> 2021 >>>>>>> at >>>>>>> 7:41 >>>>>>> PM >>>>>>> Adrian >>>>>>> Gropper >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Thank >>>>>>> you >>>>>>> for >>>>>>> creating >>>>>>> the >>>>>>> issue. >>>>>>> My >>>>>>> definition >>>>>>> of >>>>>>> AS >>>>>>> is >>>>>>> independent >>>>>>> of >>>>>>> AS-RO >>>>>>> or >>>>>>> AS-RS. >>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomment-806280421 >>>>>>> >>>>>>> I >>>>>>> also >>>>>>> agree >>>>>>> with >>>>>>> Alan's >>>>>>> definition >>>>>>> based >>>>>>> on >>>>>>> delegation. >>>>>>> An >>>>>>> AS-RS >>>>>>> would >>>>>>> be >>>>>>> a >>>>>>> delegate >>>>>>> of >>>>>>> the >>>>>>> RS. >>>>>>> >>>>>>> >>>>>>> Based >>>>>>> on >>>>>>> that, >>>>>>> I >>>>>>> see >>>>>>> it >>>>>>> as >>>>>>> obvious that >>>>>>> the >>>>>>> policy >>>>>>> has >>>>>>> to >>>>>>> be >>>>>>> accessible >>>>>>> (defined >>>>>>> locally?) >>>>>>> in >>>>>>> order >>>>>>> for >>>>>>> it >>>>>>> to >>>>>>> be >>>>>>> run >>>>>>> as >>>>>>> the >>>>>>> code >>>>>>> that >>>>>>> turns >>>>>>> a >>>>>>> request >>>>>>> into >>>>>>> an >>>>>>> access >>>>>>> token. >>>>>>> >>>>>>> >>>>>>> The >>>>>>> only >>>>>>> other >>>>>>> possibility >>>>>>> is >>>>>>> that >>>>>>> the >>>>>>> request >>>>>>> is >>>>>>> packaged >>>>>>> by >>>>>>> the >>>>>>> AS >>>>>>> and >>>>>>> sent >>>>>>> elsewhere >>>>>>> (an >>>>>>> agent) >>>>>>> for >>>>>>> evaluation >>>>>>> against >>>>>>> policy >>>>>>> and >>>>>>> a >>>>>>> proto-token >>>>>>> returned. >>>>>>> In >>>>>>> that >>>>>>> case >>>>>>> the >>>>>>> AS >>>>>>> is >>>>>>> acting >>>>>>> as >>>>>>> a >>>>>>> proxy >>>>>>> and >>>>>>> the >>>>>>> PDP >>>>>>> is >>>>>>> elsewhere. >>>>>>> I >>>>>>> can >>>>>>> imagine >>>>>>> that >>>>>>> an >>>>>>> AS-RS >>>>>>> would >>>>>>> behave >>>>>>> this >>>>>>> way >>>>>>> so >>>>>>> that >>>>>>> the >>>>>>> proto-token >>>>>>> could >>>>>>> be >>>>>>> turned >>>>>>> into >>>>>>> an >>>>>>> access >>>>>>> token >>>>>>> by >>>>>>> the >>>>>>> AS-RS. >>>>>>> Isn't >>>>>>> this >>>>>>> what >>>>>>> Justin >>>>>>> is >>>>>>> proposing? >>>>>>> In >>>>>>> this >>>>>>> design, >>>>>>> the >>>>>>> AS >>>>>>> is >>>>>>> the >>>>>>> AS-RS >>>>>>> and >>>>>>> the >>>>>>> agent >>>>>>> is >>>>>>> the >>>>>>> AS-RO. >>>>>>> By >>>>>>> my >>>>>>> definition, >>>>>>> this >>>>>>> model >>>>>>> has >>>>>>> two >>>>>>> ASs >>>>>>> since >>>>>>> both >>>>>>> are >>>>>>> processing >>>>>>> requests >>>>>>> into >>>>>>> tokens. >>>>>>> The >>>>>>> problem >>>>>>> with >>>>>>> this >>>>>>> is >>>>>>> complexity >>>>>>> and >>>>>>> privacy. >>>>>>> The >>>>>>> RO >>>>>>> may >>>>>>> not >>>>>>> want >>>>>>> to >>>>>>> share >>>>>>> the >>>>>>> request >>>>>>> information >>>>>>> with >>>>>>> the >>>>>>> AS-RS. >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>> On >>>>>>> Wed, >>>>>>> Mar >>>>>>> 24, >>>>>>> 2021 >>>>>>> at >>>>>>> 5:21 >>>>>>> PM >>>>>>> Fabien >>>>>>> Imbault >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Isn't >>>>>>> that >>>>>>> what >>>>>>> the >>>>>>> AS >>>>>>> is >>>>>>> supposed >>>>>>> to >>>>>>> be, >>>>>>> only >>>>>>> with >>>>>>> the >>>>>>> caveat >>>>>>> that >>>>>>> the >>>>>>> policy >>>>>>> is >>>>>>> defined >>>>>>> locally? >>>>>>> >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> >>>>>>> >>>>>>> Le >>>>>>> mer. >>>>>>> 24 >>>>>>> mars >>>>>>> 2021 >>>>>>> à >>>>>>> 20:17, >>>>>>> Alan >>>>>>> Karp >>>>>>> >>>>>> > >>>>>>> a >>>>>>> écrit : >>>>>>> >>>>>>> AS-RO >>>>>>> is >>>>>>> an >>>>>>> AS >>>>>>> that >>>>>>> RO >>>>>>> trusts >>>>>>> to >>>>>>> delegate >>>>>>> RO's >>>>>>> access >>>>>>> tokens >>>>>>> according >>>>>>> to >>>>>>> RO's >>>>>>> policies. >>>>>>> >>>>>>> >>>>>>> -------------- >>>>>>> Alan >>>>>>> Karp >>>>>>> >>>>>>> >>>>>>> On >>>>>>> Wed, >>>>>>> Mar >>>>>>> 24, >>>>>>> 2021 >>>>>>> at >>>>>>> 9:36 >>>>>>> AM >>>>>>> Fabien >>>>>>> Imbault >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Hi >>>>>>> Alan >>>>>>> and >>>>>>> Adrian, >>>>>>> >>>>>>> >>>>>>> I've >>>>>>> created >>>>>>> issue >>>>>>> AS-RO >>>>>>> policy >>>>>>> delegation >>>>>>> (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223 >>>>>>> ) >>>>>>> to >>>>>>> capture >>>>>>> your >>>>>>> input. >>>>>>> >>>>>>> A >>>>>>> first >>>>>>> question >>>>>>> that >>>>>>> arises: >>>>>>> can >>>>>>> we >>>>>>> give >>>>>>> a >>>>>>> definition >>>>>>> to >>>>>>> AS-RO? >>>>>>> >>>>>>> Thanks >>>>>>> Fabien >>>>>>> >>>>>>> On >>>>>>> Tue, >>>>>>> Mar >>>>>>> 23, >>>>>>> 2021 >>>>>>> at >>>>>>> 4:15 >>>>>>> PM >>>>>>> Alan >>>>>>> Karp >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Fabien >>>>>>> Imbault >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Hi >>>>>>> Alan, >>>>>>> >>>>>>> >>>>>>> Yes, >>>>>>> but >>>>>>> in >>>>>>> that >>>>>>> flow, >>>>>>> the >>>>>>> token >>>>>>> relationship >>>>>>> between >>>>>>> AS-RS >>>>>>> and >>>>>>> AS-RO >>>>>>> is >>>>>>> only >>>>>>> secure >>>>>>> if >>>>>>> the >>>>>>> tokens >>>>>>> issued >>>>>>> by >>>>>>> AS-RS >>>>>>> are >>>>>>> cryptographically >>>>>>> attenuable >>>>>>> in >>>>>>> the >>>>>>> first >>>>>>> place. >>>>>>> >>>>>>> >>>>>>> Attenuated >>>>>>> delegation >>>>>>> is >>>>>>> a >>>>>>> requirement, >>>>>>> but >>>>>>> that >>>>>>> doesn't >>>>>>> have >>>>>>> to >>>>>>> be >>>>>>> done >>>>>>> cryptographically. >>>>>>> Token >>>>>>> exchange >>>>>>> works >>>>>>> just >>>>>>> fine.  >>>>>>> SPKI >>>>>>> and >>>>>>> zcap-ld >>>>>>> are >>>>>>> examples >>>>>>> of >>>>>>> the >>>>>>> crypto >>>>>>> approach, >>>>>>> and >>>>>>> we >>>>>>> used >>>>>>> token >>>>>>> exchange >>>>>>> in >>>>>>> the >>>>>>> system >>>>>>> for >>>>>>> HP. >>>>>>> >>>>>>> -------------- >>>>>>> Alan >>>>>>> Karp >>>>>>> >>>>>>> >>>>>>> On >>>>>>> Tue, >>>>>>> Mar >>>>>>> 23, >>>>>>> 2021 >>>>>>> at >>>>>>> 4:12 >>>>>>> AM >>>>>>> Fabien >>>>>>> Imbault >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Hi >>>>>>> Alan, >>>>>>> >>>>>>> >>>>>>> Yes, >>>>>>> but >>>>>>> in >>>>>>> that >>>>>>> flow, >>>>>>> the >>>>>>> token >>>>>>> relationship >>>>>>> between >>>>>>> AS-RS >>>>>>> and >>>>>>> AS-RO >>>>>>> is >>>>>>> only >>>>>>> secure >>>>>>> if >>>>>>> the >>>>>>> tokens >>>>>>> issued >>>>>>> by >>>>>>> AS-RS >>>>>>> are >>>>>>> cryptographically >>>>>>> attenuable >>>>>>> in >>>>>>> the >>>>>>> first >>>>>>> place. >>>>>>> >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> On >>>>>>> Mon, >>>>>>> Mar >>>>>>> 22, >>>>>>> 2021 >>>>>>> at >>>>>>> 9:26 >>>>>>> PM >>>>>>> Alan >>>>>>> Karp >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Justin >>>>>>> Richer >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> But >>>>>>> with >>>>>>> all >>>>>>> that >>>>>>> in >>>>>>> mind, >>>>>>> I >>>>>>> think >>>>>>> the >>>>>>> key >>>>>>> here >>>>>>> is >>>>>>> going >>>>>>> to >>>>>>> be >>>>>>> looking >>>>>>> at >>>>>>> what >>>>>>> the >>>>>>> inputs >>>>>>> to >>>>>>> the >>>>>>> AS >>>>>>> are, >>>>>>> and >>>>>>> how >>>>>>> those >>>>>>> can >>>>>>> be >>>>>>> defined >>>>>>> in >>>>>>> an >>>>>>> interoperable >>>>>>> way >>>>>>> for >>>>>>> AS’s >>>>>>> that >>>>>>> can >>>>>>> accept >>>>>>> them. >>>>>>> I >>>>>>> think >>>>>>> there’s >>>>>>> a >>>>>>> lot >>>>>>> of >>>>>>> room >>>>>>> for >>>>>>> innovation >>>>>>> and >>>>>>> flexibility >>>>>>> here >>>>>>> that >>>>>>> doesn’t >>>>>>> break >>>>>>> the >>>>>>> trust >>>>>>> model >>>>>>> or >>>>>>> core >>>>>>> use >>>>>>> cases. >>>>>>> If >>>>>>> I >>>>>>> have >>>>>>> an >>>>>>> AS-RS >>>>>>> set >>>>>>> that >>>>>>> won’t >>>>>>> accept >>>>>>> my >>>>>>> favorite >>>>>>> flavor >>>>>>> of >>>>>>> policy >>>>>>> engine >>>>>>> inputs, >>>>>>> then >>>>>>> I >>>>>>> can >>>>>>> decide >>>>>>> not >>>>>>> to >>>>>>> use >>>>>>> that >>>>>>> one. >>>>>>> But >>>>>>> this >>>>>>> is >>>>>>> a >>>>>>> very >>>>>>> different >>>>>>> question >>>>>>> than >>>>>>> saying >>>>>>> the >>>>>>> RS >>>>>>> itself >>>>>>> needs >>>>>>> to >>>>>>> accept >>>>>>> my >>>>>>> own >>>>>>> AS >>>>>>> — >>>>>>> and >>>>>>> we >>>>>>> can’t >>>>>>> keep >>>>>>> conflating >>>>>>> these >>>>>>> two >>>>>>> models. >>>>>>> >>>>>>> I >>>>>>> agree.  >>>>>>> The >>>>>>> point >>>>>>> of >>>>>>> having >>>>>>> an >>>>>>> AS-RO >>>>>>> is >>>>>>> to >>>>>>> allow >>>>>>> RO >>>>>>> to >>>>>>> specify >>>>>>> a >>>>>>> policy >>>>>>> for >>>>>>> which >>>>>>> of >>>>>>> RO's >>>>>>> access >>>>>>> tokens >>>>>>> should >>>>>>> be >>>>>>> delegated >>>>>>> under >>>>>>> what >>>>>>> conditions. >>>>>>> AS-RS >>>>>>> should >>>>>>> not >>>>>>> need >>>>>>> to >>>>>>> understand >>>>>>> those >>>>>>> policies.  >>>>>>> The >>>>>>> flow >>>>>>> would >>>>>>> be >>>>>>> >>>>>>> * RO >>>>>>> contacts >>>>>>> AS-RS >>>>>>> and >>>>>>> gets >>>>>>> one >>>>>>> or >>>>>>> more >>>>>>> access >>>>>>> tokens. >>>>>>> * RO >>>>>>> delegates >>>>>>> one >>>>>>> or >>>>>>> more >>>>>>> of >>>>>>> those >>>>>>> tokens, >>>>>>> potentially >>>>>>> sub-scoped, >>>>>>> to >>>>>>> AS-RO. >>>>>>> * A >>>>>>> different >>>>>>> user >>>>>>> contacts >>>>>>> AS-RO >>>>>>> to >>>>>>> get >>>>>>> a >>>>>>> potentially >>>>>>> sub-scoped >>>>>>> access >>>>>>> token >>>>>>> from >>>>>>> AS-RO. >>>>>>> * That >>>>>>> user >>>>>>> presents >>>>>>> the >>>>>>> access >>>>>>> token >>>>>>> delegated >>>>>>> by >>>>>>> AS-RO >>>>>>> when >>>>>>> invoking >>>>>>> the >>>>>>> resource. >>>>>>> >>>>>>> AS-RS >>>>>>> only >>>>>>> needs >>>>>>> to >>>>>>> verify >>>>>>> that >>>>>>> the >>>>>>> delegation >>>>>>> chain >>>>>>> is >>>>>>> legitimate, >>>>>>> e.g., >>>>>>> no >>>>>>> increase >>>>>>> in >>>>>>> scope, >>>>>>> and >>>>>>> that >>>>>>> it >>>>>>> grants >>>>>>> permission >>>>>>> for >>>>>>> the >>>>>>> request >>>>>>> being >>>>>>> made. >>>>>>> AS-RS >>>>>>> does >>>>>>> not >>>>>>> need >>>>>>> to >>>>>>> understand >>>>>>> the >>>>>>> policy >>>>>>> behind >>>>>>> granting >>>>>>> the >>>>>>> delegation >>>>>>> by >>>>>>> AS-RO. >>>>>>> >>>>>>> -------------- >>>>>>> Alan >>>>>>> Karp >>>>>>> >>>>>>> >>>>>>> On >>>>>>> Mon, >>>>>>> Mar >>>>>>> 22, >>>>>>> 2021 >>>>>>> at >>>>>>> 11:40 >>>>>>> AM >>>>>>> Justin >>>>>>> Richer >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Adrian, >>>>>>> >>>>>>> >>>>>>> I >>>>>>> think >>>>>>> this >>>>>>> shows >>>>>>> the >>>>>>> problem >>>>>>> with >>>>>>> the >>>>>>> terminology >>>>>>> as >>>>>>> it’s >>>>>>> been >>>>>>> applied >>>>>>> in >>>>>>> this >>>>>>> conversation, >>>>>>> which >>>>>>> I’ve >>>>>>> tried >>>>>>> to >>>>>>> shine >>>>>>> light >>>>>>> on >>>>>>> before. >>>>>>> What >>>>>>> you >>>>>>> and >>>>>>> others >>>>>>> are >>>>>>> calling >>>>>>> the >>>>>>> “RS” >>>>>>> is >>>>>>> really >>>>>>> the >>>>>>> “AS >>>>>>> and >>>>>>> RS >>>>>>> working >>>>>>> together” >>>>>>> — >>>>>>> everything >>>>>>> to >>>>>>> the >>>>>>> right >>>>>>> of >>>>>>> the >>>>>>> line. >>>>>>> When >>>>>>> Denis >>>>>>> had >>>>>>> brought >>>>>>> up >>>>>>> “eliminating >>>>>>> the >>>>>>> AS” >>>>>>> in >>>>>>> another >>>>>>> thread, >>>>>>> what >>>>>>> he’d >>>>>>> really >>>>>>> done >>>>>>> is >>>>>>> labeled >>>>>>> everything >>>>>>> to >>>>>>> the >>>>>>> right >>>>>>> of >>>>>>> the >>>>>>> line >>>>>>> as >>>>>>> the >>>>>>> “RS”. >>>>>>> Of >>>>>>> course, >>>>>>> the >>>>>>> irony >>>>>>> here >>>>>>> is >>>>>>> that >>>>>>> everything >>>>>>> to >>>>>>> the >>>>>>> right >>>>>>> of >>>>>>> the >>>>>>> line >>>>>>> used >>>>>>> all >>>>>>> be >>>>>>> called >>>>>>> the >>>>>>> “AS” >>>>>>> or >>>>>>> simply >>>>>>> “server” >>>>>>> in >>>>>>> the >>>>>>> OAuth >>>>>>> 1 >>>>>>> days. >>>>>>> As >>>>>>> you >>>>>>> say >>>>>>> below, >>>>>>> I >>>>>>> don’t >>>>>>> want >>>>>>> the >>>>>>> client >>>>>>> to >>>>>>> have >>>>>>> visibility >>>>>>> on >>>>>>> what >>>>>>> happens >>>>>>> on >>>>>>> that >>>>>>> side. >>>>>>> >>>>>>> >>>>>>> Note >>>>>>> well: >>>>>>> The >>>>>>> Google+ >>>>>>> logo >>>>>>> labeled >>>>>>> “IdP” >>>>>>> in >>>>>>> the >>>>>>> diagram >>>>>>> is >>>>>>> not >>>>>>> the >>>>>>> AS, >>>>>>> as >>>>>>> far >>>>>>> as >>>>>>> GNAP >>>>>>> is >>>>>>> concerned. >>>>>>> It >>>>>>> does >>>>>>> not >>>>>>> issue >>>>>>> an >>>>>>> access >>>>>>> token >>>>>>> that >>>>>>> the >>>>>>> RS >>>>>>> will >>>>>>> accept. >>>>>>> The >>>>>>> elements >>>>>>> to >>>>>>> the >>>>>>> left >>>>>>> of >>>>>>> the >>>>>>> line >>>>>>> could >>>>>>> be >>>>>>> a >>>>>>> lot >>>>>>> of >>>>>>> things, >>>>>>> but >>>>>>> they >>>>>>> are >>>>>>> NOT >>>>>>> the >>>>>>> AS >>>>>>> — >>>>>>> by >>>>>>> definition. >>>>>>> The >>>>>>> client >>>>>>> lives >>>>>>> over >>>>>>> on >>>>>>> the >>>>>>> left, >>>>>>> but >>>>>>> so >>>>>>> do >>>>>>> any >>>>>>> external >>>>>>> inputs >>>>>>> to >>>>>>> the >>>>>>> AS. >>>>>>> These >>>>>>> could >>>>>>> be >>>>>>> policy >>>>>>> inputs >>>>>>> on >>>>>>> behalf >>>>>>> of >>>>>>> the >>>>>>> RO, >>>>>>> they >>>>>>> could >>>>>>> be >>>>>>> presentation >>>>>>> artifacts, >>>>>>> they >>>>>>> could >>>>>>> be >>>>>>> federated >>>>>>> logins, >>>>>>> they >>>>>>> could >>>>>>> be >>>>>>> the >>>>>>> output >>>>>>> of >>>>>>> policy >>>>>>> decisions. >>>>>>> How >>>>>>> the >>>>>>> AS >>>>>>> comes >>>>>>> to >>>>>>> trust >>>>>>> those >>>>>>> things >>>>>>> is >>>>>>> up >>>>>>> to >>>>>>> the >>>>>>> AS’s >>>>>>> implementation. >>>>>>> It’s >>>>>>> something >>>>>>> we >>>>>>> can >>>>>>> talk >>>>>>> about, >>>>>>> but >>>>>>> ultimately >>>>>>> GNAP >>>>>>> won’t >>>>>>> be >>>>>>> in >>>>>>> any >>>>>>> position >>>>>>> to >>>>>>> dictate >>>>>>> because >>>>>>> in >>>>>>> practice >>>>>>> some >>>>>>> AS’s >>>>>>> are >>>>>>> simply >>>>>>> going >>>>>>> to >>>>>>> internalize >>>>>>> all >>>>>>> policies >>>>>>> and >>>>>>> we >>>>>>> will >>>>>>> never >>>>>>> successfully >>>>>>> force >>>>>>> those >>>>>>> open. >>>>>>> >>>>>>> >>>>>>> But >>>>>>> with >>>>>>> all >>>>>>> that >>>>>>> in >>>>>>> mind, >>>>>>> I >>>>>>> think >>>>>>> the >>>>>>> key >>>>>>> here >>>>>>> is >>>>>>> going >>>>>>> to >>>>>>> be >>>>>>> looking >>>>>>> at >>>>>>> what >>>>>>> the >>>>>>> inputs >>>>>>> to >>>>>>> the >>>>>>> AS >>>>>>> are, >>>>>>> and >>>>>>> how >>>>>>> those >>>>>>> can >>>>>>> be >>>>>>> defined >>>>>>> in >>>>>>> an >>>>>>> interoperable >>>>>>> way >>>>>>> for >>>>>>> AS’s >>>>>>> that >>>>>>> can >>>>>>> accept >>>>>>> them. >>>>>>> I >>>>>>> think >>>>>>> there’s >>>>>>> a >>>>>>> lot >>>>>>> of >>>>>>> room >>>>>>> for >>>>>>> innovation >>>>>>> and >>>>>>> flexibility >>>>>>> here >>>>>>> that >>>>>>> doesn’t >>>>>>> break >>>>>>> the >>>>>>> trust >>>>>>> model >>>>>>> or >>>>>>> core >>>>>>> use >>>>>>> cases. >>>>>>> If >>>>>>> I >>>>>>> have >>>>>>> an >>>>>>> AS-RS >>>>>>> set >>>>>>> that >>>>>>> won’t >>>>>>> accept >>>>>>> my >>>>>>> favorite >>>>>>> flavor >>>>>>> of >>>>>>> policy >>>>>>> engine >>>>>>> inputs, >>>>>>> then >>>>>>> I >>>>>>> can >>>>>>> decide >>>>>>> not >>>>>>> to >>>>>>> use >>>>>>> that >>>>>>> one. >>>>>>> But >>>>>>> this >>>>>>> is >>>>>>> a >>>>>>> very >>>>>>> different >>>>>>> question >>>>>>> than >>>>>>> saying >>>>>>> the >>>>>>> RS >>>>>>> itself >>>>>>> needs >>>>>>> to >>>>>>> accept >>>>>>> my >>>>>>> own >>>>>>> AS >>>>>>> — >>>>>>> and >>>>>>> we >>>>>>> can’t >>>>>>> keep >>>>>>> conflating >>>>>>> these >>>>>>> two >>>>>>> models. >>>>>>> >>>>>>> So >>>>>>> to >>>>>>> me, >>>>>>> GNAP >>>>>>> can >>>>>>> support >>>>>>> a >>>>>>> Zero >>>>>>> Trust >>>>>>> Architecture >>>>>>> by >>>>>>> LEVERAGING >>>>>>> the >>>>>>> AS, >>>>>>> not >>>>>>> by >>>>>>> subsuming >>>>>>> or >>>>>>> eliminating >>>>>>> it. >>>>>>> It >>>>>>> is >>>>>>> in >>>>>>> fact >>>>>>> the >>>>>>> AS, >>>>>>> not >>>>>>> the >>>>>>> client >>>>>>> and >>>>>>> not >>>>>>> the >>>>>>> RS, >>>>>>> that >>>>>>> will >>>>>>> request >>>>>>> and >>>>>>> consume >>>>>>> the >>>>>>> results >>>>>>> of >>>>>>> a >>>>>>> privacy-preserving >>>>>>> zero-trust >>>>>>> policy >>>>>>> query >>>>>>> thing. >>>>>>> Anything >>>>>>> that >>>>>>> happens >>>>>>> downstream >>>>>>> from >>>>>>> that >>>>>>> is >>>>>>> of >>>>>>> little >>>>>>> concern >>>>>>> to >>>>>>> the >>>>>>> zero-trust >>>>>>> components >>>>>>> because, >>>>>>> as >>>>>>> you >>>>>>> point >>>>>>> out, >>>>>>> it’s >>>>>>> on >>>>>>> the >>>>>>> “other >>>>>>> side” >>>>>>> of >>>>>>> the >>>>>>> line. >>>>>>> >>>>>>> >>>>>>> I >>>>>>> think >>>>>>> we >>>>>>> got >>>>>>> this >>>>>>> basic >>>>>>> component >>>>>>> model >>>>>>> pretty >>>>>>> right >>>>>>> in >>>>>>> OAuth: >>>>>>> the >>>>>>> AS >>>>>>> and >>>>>>> RS >>>>>>> and >>>>>>> client >>>>>>> working >>>>>>> together. >>>>>>> Where >>>>>>> OAuth >>>>>>> misses >>>>>>> the >>>>>>> mark >>>>>>> is >>>>>>> the >>>>>>> assumption >>>>>>> that >>>>>>> the >>>>>>> user >>>>>>> has >>>>>>> to >>>>>>> log >>>>>>> in >>>>>>> to >>>>>>> the >>>>>>> AS >>>>>>> through >>>>>>> a >>>>>>> webpage >>>>>>> and >>>>>>> interact >>>>>>> directly, >>>>>>> thereby >>>>>>> proving >>>>>>> they’re >>>>>>> the >>>>>>> RO. >>>>>>> It’s >>>>>>> this >>>>>>> latter >>>>>>> space >>>>>>> where >>>>>>> I >>>>>>> think >>>>>>> we >>>>>>> can >>>>>>> both >>>>>>> push >>>>>>> innovation >>>>>>> and >>>>>>> also >>>>>>> address >>>>>>> the >>>>>>> important >>>>>>> and >>>>>>> compelling >>>>>>> use >>>>>>> cases >>>>>>> like >>>>>>> the >>>>>>> ones >>>>>>> you’re >>>>>>> bringing. >>>>>>> >>>>>>>  — >>>>>>> Justin >>>>>>> >>>>>>>> On >>>>>>>> Mar >>>>>>>> 22, >>>>>>>> 2021, >>>>>>>> at >>>>>>>> 2:14 >>>>>>>> PM, >>>>>>>> Adrian >>>>>>>> Gropper >>>>>>>> >>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>> I'm >>>>>>>> sorry, >>>>>>>> Justin. >>>>>>>> As >>>>>>>> a >>>>>>>> Resource >>>>>>>> Owner, >>>>>>>> I >>>>>>>> look >>>>>>>> at >>>>>>>> the >>>>>>>> RS >>>>>>>> trust >>>>>>>> boundary >>>>>>>> (the >>>>>>>> dotted >>>>>>>> line >>>>>>>> in >>>>>>>> the >>>>>>>> diagram) >>>>>>>> as >>>>>>>> being >>>>>>>> the >>>>>>>> RS. >>>>>>>> I >>>>>>>> don't >>>>>>>> expect >>>>>>>> any >>>>>>>> visibility >>>>>>>> into >>>>>>>> what's >>>>>>>> going >>>>>>>> on >>>>>>>> on >>>>>>>> the right. >>>>>>>> >>>>>>>> >>>>>>>> My >>>>>>>> problem >>>>>>>> with >>>>>>>> the >>>>>>>> framing >>>>>>>> you >>>>>>>> propose >>>>>>>> is >>>>>>>> that >>>>>>>> requests >>>>>>>> are >>>>>>>> going >>>>>>>> to >>>>>>>> the >>>>>>>> RS >>>>>>>> (or >>>>>>>> the >>>>>>>> AS-RS) >>>>>>>> and >>>>>>>> I >>>>>>>> don't >>>>>>>> want >>>>>>>> to >>>>>>>> share >>>>>>>> my >>>>>>>> policies >>>>>>>> with >>>>>>>> the >>>>>>>> AS-RS. >>>>>>>> I >>>>>>>> want >>>>>>>> to >>>>>>>> keep >>>>>>>> the >>>>>>>> RS >>>>>>>> and >>>>>>>> AS-RS >>>>>>>> as >>>>>>>> ignorant >>>>>>>> as >>>>>>>> possible. >>>>>>>> >>>>>>>> Adrian >>>>>>>> >>>>>>>> On >>>>>>>> Mon, >>>>>>>> Mar >>>>>>>> 22, >>>>>>>> 2021 >>>>>>>> at >>>>>>>> 1:48 >>>>>>>> PM >>>>>>>> Justin >>>>>>>> Richer >>>>>>>> >>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>> Adrian, >>>>>>>> >>>>>>>> >>>>>>>> What >>>>>>>> you’re >>>>>>>> discussing >>>>>>>> below, >>>>>>>> in >>>>>>>> terms >>>>>>>> of >>>>>>>> logging >>>>>>>> in >>>>>>>> to >>>>>>>> a >>>>>>>> site, >>>>>>>> is >>>>>>>> not >>>>>>>> approaching >>>>>>>> the >>>>>>>> RS. >>>>>>>> You >>>>>>>> are >>>>>>>> in >>>>>>>> fact >>>>>>>> approaching >>>>>>>> the >>>>>>>> client, >>>>>>>> and >>>>>>>> identifying >>>>>>>> both >>>>>>>> the >>>>>>>> AS >>>>>>>> and >>>>>>>> RS >>>>>>>> to >>>>>>>> the >>>>>>>> client. >>>>>>>> The >>>>>>>> client >>>>>>>> is >>>>>>>> a >>>>>>>> client >>>>>>>> /of >>>>>>>> your >>>>>>>> identity/ >>>>>>>> in >>>>>>>> this >>>>>>>> model, >>>>>>>> and >>>>>>>> the >>>>>>>> RS >>>>>>>> is >>>>>>>> part >>>>>>>> of >>>>>>>> the >>>>>>>> identity >>>>>>>> provider. >>>>>>>> It’s >>>>>>>> really >>>>>>>> important >>>>>>>> that >>>>>>>> we >>>>>>>> don’t >>>>>>>> conflate >>>>>>>> the >>>>>>>> RS >>>>>>>> and >>>>>>>> client >>>>>>>> in >>>>>>>> this >>>>>>>> way >>>>>>>> as >>>>>>>> it >>>>>>>> leads >>>>>>>> to >>>>>>>> a >>>>>>>> lot >>>>>>>> of >>>>>>>> confusion >>>>>>>> downstream >>>>>>>> and >>>>>>>> a >>>>>>>> lot >>>>>>>> of >>>>>>>> broken >>>>>>>> trust >>>>>>>> boundaries. >>>>>>>> >>>>>>>> With >>>>>>>> that >>>>>>>> model >>>>>>>> in >>>>>>>> mind, >>>>>>>> approaching >>>>>>>> the >>>>>>>> “RS" >>>>>>>> and >>>>>>>> providing >>>>>>>> it >>>>>>>> your >>>>>>>> identity >>>>>>>> is >>>>>>>> really >>>>>>>> just >>>>>>>> a >>>>>>>> case >>>>>>>> of >>>>>>>> the >>>>>>>> “federated >>>>>>>> login >>>>>>>> to >>>>>>>> AS” >>>>>>>> pattern >>>>>>>> that >>>>>>>> we >>>>>>>> discussed >>>>>>>> on >>>>>>>> the >>>>>>>> WG >>>>>>>> call. >>>>>>>> The >>>>>>>> user >>>>>>>> here >>>>>>>> approaches >>>>>>>> an >>>>>>>> RS, >>>>>>>> which >>>>>>>> has >>>>>>>> its >>>>>>>> own >>>>>>>> AS. >>>>>>>> To >>>>>>>> share >>>>>>>> things >>>>>>>> from >>>>>>>> this >>>>>>>> RS, >>>>>>>> the >>>>>>>> RO >>>>>>>> has >>>>>>>> to >>>>>>>> authenticate >>>>>>>> to >>>>>>>> the >>>>>>>> RS’s >>>>>>>> AS. >>>>>>>> This >>>>>>>> particular >>>>>>>> AS >>>>>>>> allows >>>>>>>> the >>>>>>>> RO >>>>>>>> to >>>>>>>> do >>>>>>>> so >>>>>>>> using >>>>>>>> an >>>>>>>> external >>>>>>>> identity >>>>>>>> — >>>>>>>> in >>>>>>>> which >>>>>>>> case, >>>>>>>> the >>>>>>>> AS >>>>>>>> is >>>>>>>> now >>>>>>>> a >>>>>>>> “client” >>>>>>>> of >>>>>>>> a >>>>>>>> separate, >>>>>>>> disconnected >>>>>>>> (but >>>>>>>> layered) >>>>>>>> delegation. >>>>>>>> The >>>>>>>> ultimate >>>>>>>> client >>>>>>>> that >>>>>>>> eventually >>>>>>>> calls >>>>>>>> the >>>>>>>> RS >>>>>>>> down >>>>>>>> the >>>>>>>> way >>>>>>>> may >>>>>>>> or >>>>>>>> may >>>>>>>> not >>>>>>>> know >>>>>>>> about >>>>>>>> these >>>>>>>> layers. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This >>>>>>>> same >>>>>>>> AS, >>>>>>>> which >>>>>>>> is >>>>>>>> closely >>>>>>>> tied >>>>>>>> to >>>>>>>> the >>>>>>>> RS >>>>>>>> and >>>>>>>> trusted >>>>>>>> by >>>>>>>> the >>>>>>>> RS, >>>>>>>> might >>>>>>>> also >>>>>>>> take >>>>>>>> in >>>>>>>> FIDO >>>>>>>> credentials, >>>>>>>> or >>>>>>>> DIDs, >>>>>>>> or >>>>>>>> any >>>>>>>> number >>>>>>>> of >>>>>>>> other >>>>>>>> proof >>>>>>>> mechanisms. >>>>>>>> The >>>>>>>> output >>>>>>>> of >>>>>>>> this >>>>>>>> is >>>>>>>> an >>>>>>>> access >>>>>>>> token >>>>>>>> the >>>>>>>> RS >>>>>>>> trusts, >>>>>>>> but >>>>>>>> the >>>>>>>> input >>>>>>>> is >>>>>>>> up >>>>>>>> to >>>>>>>> the >>>>>>>> AS. >>>>>>>> The >>>>>>>> RS >>>>>>>> is >>>>>>>> not >>>>>>>> what >>>>>>>> you’re >>>>>>>> logging >>>>>>>> in >>>>>>>> to. >>>>>>>> >>>>>>>>  — >>>>>>>> Justin >>>>>>>> >>>>>>>>> On >>>>>>>>> Mar >>>>>>>>> 22, >>>>>>>>> 2021, >>>>>>>>> at >>>>>>>>> 1:28 >>>>>>>>> PM, >>>>>>>>> Adrian >>>>>>>>> Gropper >>>>>>>>> >>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> I >>>>>>>>> too >>>>>>>>> am >>>>>>>>> in >>>>>>>>> favor >>>>>>>>> of >>>>>>>>> avoiding >>>>>>>>> consolidation >>>>>>>>> and >>>>>>>>> correlation. >>>>>>>>> Right >>>>>>>>> now, >>>>>>>>> when >>>>>>>>> I >>>>>>>>> approach >>>>>>>>> a >>>>>>>>> service >>>>>>>>> provider >>>>>>>>> (RS) >>>>>>>>> for >>>>>>>>> the >>>>>>>>> first >>>>>>>>> time, >>>>>>>>> I'm >>>>>>>>> offered >>>>>>>>> the >>>>>>>>> opportunity >>>>>>>>> to >>>>>>>>> identify >>>>>>>>> my >>>>>>>>> persona >>>>>>>>> as: >>>>>>>>> email, >>>>>>>>> sign-in >>>>>>>>> with >>>>>>>>> Google, >>>>>>>>> Facebook, >>>>>>>>> or >>>>>>>>> Apple. >>>>>>>>> I >>>>>>>>> know >>>>>>>>> there >>>>>>>>> are >>>>>>>>> people >>>>>>>>> who >>>>>>>>> try >>>>>>>>> to >>>>>>>>> create >>>>>>>>> one-off >>>>>>>>> email >>>>>>>>> addresses >>>>>>>>> but >>>>>>>>> that >>>>>>>>> is >>>>>>>>> mostly >>>>>>>>> a >>>>>>>>> waste >>>>>>>>> of >>>>>>>>> time. >>>>>>>>> >>>>>>>>> >>>>>>>>> So, >>>>>>>>> along >>>>>>>>> come >>>>>>>>> FIDO2 >>>>>>>>> and >>>>>>>>> DID >>>>>>>>> wallets >>>>>>>>> to >>>>>>>>> the >>>>>>>>> rescue. >>>>>>>>> Now, >>>>>>>>> in >>>>>>>>> theory, >>>>>>>>> I >>>>>>>>> have >>>>>>>>> a >>>>>>>>> way >>>>>>>>> to >>>>>>>>> start >>>>>>>>> out >>>>>>>>> my >>>>>>>>> RS >>>>>>>>> relationship >>>>>>>>> pseudonymously. >>>>>>>>> >>>>>>>>> >>>>>>>>> When >>>>>>>>> I >>>>>>>>> want >>>>>>>>> my >>>>>>>>> resource >>>>>>>>> to >>>>>>>>> be >>>>>>>>> discovered >>>>>>>>> or >>>>>>>>> shared >>>>>>>>> I >>>>>>>>> will >>>>>>>>> post >>>>>>>>> that >>>>>>>>> RS >>>>>>>>> URL >>>>>>>>> including >>>>>>>>> my >>>>>>>>> pseudonym. >>>>>>>>> If >>>>>>>>> I >>>>>>>>> then >>>>>>>>> want >>>>>>>>> to >>>>>>>>> introduce >>>>>>>>> a >>>>>>>>> mediator in >>>>>>>>> front >>>>>>>>> of >>>>>>>>> my >>>>>>>>> AS >>>>>>>>> or >>>>>>>>> messaging >>>>>>>>> service endpoint, >>>>>>>>> I >>>>>>>>> have >>>>>>>>> that >>>>>>>>> option. >>>>>>>>> If >>>>>>>>> I >>>>>>>>> want >>>>>>>>> to >>>>>>>>> keep >>>>>>>>> requests >>>>>>>>> away >>>>>>>>> from >>>>>>>>> the >>>>>>>>> mediator, >>>>>>>>> I >>>>>>>>> would >>>>>>>>> publish >>>>>>>>> an >>>>>>>>> encryption >>>>>>>>> key >>>>>>>>> along >>>>>>>>> with >>>>>>>>> my >>>>>>>>> pseudonym. >>>>>>>>> >>>>>>>>> - >>>>>>>>> Adrian >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On >>>>>>>>> Mon, >>>>>>>>> Mar >>>>>>>>> 22, >>>>>>>>> 2021 >>>>>>>>> at >>>>>>>>> 9:55 >>>>>>>>> AM >>>>>>>>> Justin >>>>>>>>> Richer >>>>>>>>> >>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> On >>>>>>>>> Mar >>>>>>>>> 21, >>>>>>>>> 2021, >>>>>>>>> at >>>>>>>>> 1:18 >>>>>>>>> PM, >>>>>>>>> Benjamin >>>>>>>>> Kaduk >>>>>>>>> >>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> > >>>>>>>>> >>>>>>>>> > >>>>>>>>> On >>>>>>>>> Sat, >>>>>>>>> Mar >>>>>>>>> 20, >>>>>>>>> 2021 >>>>>>>>> at >>>>>>>>> 01:07:42AM >>>>>>>>> -0400, >>>>>>>>> Adrian >>>>>>>>> Gropper >>>>>>>>> wrote: >>>>>>>>> >> >>>>>>>>> @Alan >>>>>>>>> Karp >>>>>>>>> >>>>>>>> > >>>>>>>>> shared >>>>>>>>> a >>>>>>>>> talk >>>>>>>>> about >>>>>>>>> the >>>>>>>>> Principle >>>>>>>>> Of >>>>>>>>> Least >>>>>>>>> >> >>>>>>>>> Authority >>>>>>>>> (POLA) >>>>>>>>> in >>>>>>>>> a >>>>>>>>> recent >>>>>>>>> comment >>>>>>>>> >> >>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-803099693 >>>>>>>>> >>>>>>>>> >> >>>>>>>>> I >>>>>>>>> recommend >>>>>>>>> it. >>>>>>>>> >> >>>>>>>>> >>>>>>>>> >> >>>>>>>>> We >>>>>>>>> might >>>>>>>>> expect >>>>>>>>> a >>>>>>>>> protocol >>>>>>>>> with >>>>>>>>> authorization >>>>>>>>> in >>>>>>>>> the >>>>>>>>> title >>>>>>>>> to >>>>>>>>> use >>>>>>>>> authority >>>>>>>>> >> >>>>>>>>> as >>>>>>>>> a >>>>>>>>> core >>>>>>>>> principle. >>>>>>>>> I >>>>>>>>> advocate >>>>>>>>> for >>>>>>>>> a >>>>>>>>> GNAP >>>>>>>>> design >>>>>>>>> that >>>>>>>>> maximizes >>>>>>>>> the >>>>>>>>> power >>>>>>>>> >> >>>>>>>>> of >>>>>>>>> the >>>>>>>>> RO, >>>>>>>>> to >>>>>>>>> be >>>>>>>>> seen >>>>>>>>> as >>>>>>>>> a >>>>>>>>> human >>>>>>>>> rights >>>>>>>>> issue >>>>>>>>> when >>>>>>>>> the >>>>>>>>> RO >>>>>>>>> is >>>>>>>>> a >>>>>>>>> human. >>>>>>>>> This >>>>>>>>> >> >>>>>>>>> causes >>>>>>>>> me >>>>>>>>> to >>>>>>>>> ask >>>>>>>>> how >>>>>>>>> to >>>>>>>>> combine >>>>>>>>> better >>>>>>>>> security >>>>>>>>> with >>>>>>>>> better >>>>>>>>> human >>>>>>>>> rights >>>>>>>>> in >>>>>>>>> >> >>>>>>>>> GNAP. >>>>>>>>> >> >>>>>>>>> >>>>>>>>> >> >>>>>>>>> Who >>>>>>>>> should >>>>>>>>> have >>>>>>>>> the >>>>>>>>> least >>>>>>>>> authority >>>>>>>>> in >>>>>>>>> the >>>>>>>>> GNAP >>>>>>>>> design? >>>>>>>>> >> >>>>>>>>> >>>>>>>>> >> >>>>>>>>> The >>>>>>>>> AS >>>>>>>>> derives >>>>>>>>> authority >>>>>>>>> as >>>>>>>>> a >>>>>>>>> delegate >>>>>>>>> of >>>>>>>>> the >>>>>>>>> RO. >>>>>>>>> If >>>>>>>>> we >>>>>>>>> ask >>>>>>>>> the >>>>>>>>> RO >>>>>>>>> to >>>>>>>>> >> >>>>>>>>> partition >>>>>>>>> limited >>>>>>>>> authority >>>>>>>>> across >>>>>>>>> dozens >>>>>>>>> of >>>>>>>>> different >>>>>>>>> ASs >>>>>>>>> by >>>>>>>>> domain >>>>>>>>> and >>>>>>>>> >> >>>>>>>>> function, >>>>>>>>> then >>>>>>>>> we >>>>>>>>> are >>>>>>>>> not >>>>>>>>> using >>>>>>>>> technology >>>>>>>>> to >>>>>>>>> empower >>>>>>>>> the >>>>>>>>> individual. >>>>>>>>> >> >>>>>>>>> Probably >>>>>>>>> the >>>>>>>>> opposite, >>>>>>>>> as >>>>>>>>> we >>>>>>>>> introduce >>>>>>>>> consent >>>>>>>>> fatigue >>>>>>>>> and >>>>>>>>> burden >>>>>>>>> normal >>>>>>>>> >> >>>>>>>>> people >>>>>>>>> to >>>>>>>>> partition >>>>>>>>> their >>>>>>>>> lives >>>>>>>>> into >>>>>>>>> non-overlapping >>>>>>>>> domains. >>>>>>>>> >> >>>>>>>>> >>>>>>>>> >> >>>>>>>>> My >>>>>>>>> experience >>>>>>>>> says >>>>>>>>> we >>>>>>>>> should >>>>>>>>> aim >>>>>>>>> for >>>>>>>>> one >>>>>>>>> AS >>>>>>>>> per >>>>>>>>> persona >>>>>>>>> because >>>>>>>>> that >>>>>>>>> maps >>>>>>>>> >> >>>>>>>>> into >>>>>>>>> the >>>>>>>>> way >>>>>>>>> we >>>>>>>>> manage >>>>>>>>> our >>>>>>>>> public >>>>>>>>> and >>>>>>>>> private >>>>>>>>> identities. >>>>>>>>> POLA >>>>>>>>> would >>>>>>>>> then >>>>>>>>> >> >>>>>>>>> teach >>>>>>>>> care >>>>>>>>> in >>>>>>>>> keeping >>>>>>>>> ASs >>>>>>>>> and >>>>>>>>> RSs >>>>>>>>> related >>>>>>>>> to >>>>>>>>> work >>>>>>>>> / >>>>>>>>> public >>>>>>>>> separate >>>>>>>>> from >>>>>>>>> >> >>>>>>>>> ASs >>>>>>>>> and >>>>>>>>> RSs >>>>>>>>> related >>>>>>>>> to >>>>>>>>> private >>>>>>>>> life >>>>>>>>> so >>>>>>>>> that >>>>>>>>> a >>>>>>>>> policy >>>>>>>>> vulnerability >>>>>>>>> in >>>>>>>>> our >>>>>>>>> >> >>>>>>>>> delegation >>>>>>>>> to >>>>>>>>> an >>>>>>>>> AS >>>>>>>>> would >>>>>>>>> have >>>>>>>>> the >>>>>>>>> least >>>>>>>>> likelihood >>>>>>>>> of >>>>>>>>> harm. >>>>>>>>> > >>>>>>>>> >>>>>>>>> > >>>>>>>>> Thinking >>>>>>>>> about >>>>>>>>> how >>>>>>>>> least >>>>>>>>> authority/least >>>>>>>>> privilege >>>>>>>>> would >>>>>>>>> apply >>>>>>>>> to >>>>>>>>> GNAP >>>>>>>>> > >>>>>>>>> seems >>>>>>>>> like >>>>>>>>> a >>>>>>>>> useful >>>>>>>>> exercise.  >>>>>>>>> I >>>>>>>>> do >>>>>>>>> want >>>>>>>>> to >>>>>>>>> point >>>>>>>>> out >>>>>>>>> some >>>>>>>>> potential >>>>>>>>> > >>>>>>>>> pitfalls >>>>>>>>> with >>>>>>>>> one-AS-per-persona >>>>>>>>> that >>>>>>>>> we >>>>>>>>> can >>>>>>>>> also >>>>>>>>> be >>>>>>>>> aware >>>>>>>>> of.  >>>>>>>>> If >>>>>>>>> > >>>>>>>>> one-AS-per-persona >>>>>>>>> becomes >>>>>>>>> one-persona-per-AS >>>>>>>>> as >>>>>>>>> well, >>>>>>>>> then >>>>>>>>> the >>>>>>>>> AS's >>>>>>>>> > >>>>>>>>> identity >>>>>>>>> in >>>>>>>>> effect >>>>>>>>> also >>>>>>>>> serves >>>>>>>>> as >>>>>>>>> a >>>>>>>>> persona >>>>>>>>> identity >>>>>>>>> and >>>>>>>>> there >>>>>>>>> are >>>>>>>>> privacy >>>>>>>>> > >>>>>>>>> considerations >>>>>>>>> to >>>>>>>>> that.  >>>>>>>>> If, >>>>>>>>> on >>>>>>>>> the >>>>>>>>> other >>>>>>>>> hand, >>>>>>>>> the >>>>>>>>> > >>>>>>>>> multiple-personas-per-AS >>>>>>>>> (presumably >>>>>>>>> corresponding >>>>>>>>> to >>>>>>>>> multiple >>>>>>>>> humans) >>>>>>>>> > >>>>>>>>> route >>>>>>>>> is >>>>>>>>> taken, >>>>>>>>> we >>>>>>>>> should >>>>>>>>> consider >>>>>>>>> whether >>>>>>>>> that >>>>>>>>> would >>>>>>>>> lead >>>>>>>>> to >>>>>>>>> various >>>>>>>>> > >>>>>>>>> (e.g., >>>>>>>>> market) >>>>>>>>> forces >>>>>>>>> driving >>>>>>>>> consolidation >>>>>>>>> to >>>>>>>>> just >>>>>>>>> a >>>>>>>>> handful >>>>>>>>> of >>>>>>>>> > >>>>>>>>> super-popular >>>>>>>>> AS >>>>>>>>> services. >>>>>>>>> That >>>>>>>>> topic >>>>>>>>> is >>>>>>>>> a >>>>>>>>> current >>>>>>>>> matter >>>>>>>>> of >>>>>>>>> concern >>>>>>>>> to >>>>>>>>> > >>>>>>>>> some >>>>>>>>> IETF >>>>>>>>> participants. >>>>>>>>> > >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi >>>>>>>>> Ben, >>>>>>>>> big >>>>>>>>> +1 >>>>>>>>> to >>>>>>>>> this. >>>>>>>>> This >>>>>>>>> is >>>>>>>>> something >>>>>>>>> that >>>>>>>>> we >>>>>>>>> discussed >>>>>>>>> ages >>>>>>>>> ago >>>>>>>>> in >>>>>>>>> the >>>>>>>>> UMA >>>>>>>>> working >>>>>>>>> group, >>>>>>>>> and >>>>>>>>> it’s >>>>>>>>> one >>>>>>>>> of >>>>>>>>> the >>>>>>>>> biggest >>>>>>>>> problems >>>>>>>>> with >>>>>>>>> the >>>>>>>>> personal >>>>>>>>> AS >>>>>>>>> (and >>>>>>>>> personal >>>>>>>>> data >>>>>>>>> store) >>>>>>>>> model. >>>>>>>>> This >>>>>>>>> kind >>>>>>>>> of >>>>>>>>> thing >>>>>>>>> makes >>>>>>>>> RS-first >>>>>>>>> trust >>>>>>>>> models >>>>>>>>> really >>>>>>>>> difficult >>>>>>>>> in >>>>>>>>> practice. >>>>>>>>> >>>>>>>>> As >>>>>>>>> a >>>>>>>>> strawman, >>>>>>>>> let’s >>>>>>>>> say >>>>>>>>> that >>>>>>>>> I’ve >>>>>>>>> got >>>>>>>>> software >>>>>>>>> that >>>>>>>>> wants >>>>>>>>> to >>>>>>>>> access >>>>>>>>> my >>>>>>>>> medical >>>>>>>>> information. >>>>>>>>> It >>>>>>>>> calls >>>>>>>>> an >>>>>>>>> RS >>>>>>>>> and >>>>>>>>> requests >>>>>>>>> access, >>>>>>>>> but >>>>>>>>> it >>>>>>>>> hasn’t >>>>>>>>> been >>>>>>>>> granted >>>>>>>>> anything >>>>>>>>> yet. >>>>>>>>> Now >>>>>>>>> I >>>>>>>>> as >>>>>>>>> the >>>>>>>>> RO >>>>>>>>> have >>>>>>>>> set >>>>>>>>> up >>>>>>>>> the >>>>>>>>> RS >>>>>>>>> so >>>>>>>>> that >>>>>>>>> it >>>>>>>>> talks >>>>>>>>> to >>>>>>>>> my >>>>>>>>> personal >>>>>>>>> AS, >>>>>>>>> that >>>>>>>>> only >>>>>>>>> I >>>>>>>>> use. >>>>>>>>> In >>>>>>>>> addition >>>>>>>>> to >>>>>>>>> the >>>>>>>>> RS >>>>>>>>> having >>>>>>>>> to >>>>>>>>> be >>>>>>>>> able >>>>>>>>> to >>>>>>>>> figure >>>>>>>>> out >>>>>>>>> which >>>>>>>>> medical >>>>>>>>> records >>>>>>>>> are >>>>>>>>> being >>>>>>>>> requested >>>>>>>>> from >>>>>>>>> the >>>>>>>>> context >>>>>>>>> of >>>>>>>>> the >>>>>>>>> unauthenticated >>>>>>>>> request >>>>>>>>> (which >>>>>>>>> means >>>>>>>>> it >>>>>>>>> needs >>>>>>>>> identifiers >>>>>>>>> in >>>>>>>>> the >>>>>>>>> URL >>>>>>>>> or >>>>>>>>> something >>>>>>>>> similar >>>>>>>>> for >>>>>>>>> the >>>>>>>>> RS >>>>>>>>> to >>>>>>>>> be >>>>>>>>> able >>>>>>>>> to >>>>>>>>> tell, >>>>>>>>> assuming >>>>>>>>> that >>>>>>>>> it >>>>>>>>> protects >>>>>>>>> data >>>>>>>>> for >>>>>>>>> more >>>>>>>>> than >>>>>>>>> one >>>>>>>>> person). >>>>>>>>> So >>>>>>>>> this >>>>>>>>> client >>>>>>>>> software >>>>>>>>> doesn’t >>>>>>>>> know >>>>>>>>> who >>>>>>>>> I >>>>>>>>> am >>>>>>>>> and >>>>>>>>> doesn’t >>>>>>>>> know >>>>>>>>> my >>>>>>>>> medical >>>>>>>>> record >>>>>>>>> information, >>>>>>>>> makes >>>>>>>>> a >>>>>>>>> completely >>>>>>>>> unauthorized >>>>>>>>> request >>>>>>>>> to >>>>>>>>> the >>>>>>>>> RS, >>>>>>>>> and >>>>>>>>> the >>>>>>>>> RS >>>>>>>>> says >>>>>>>>> “Go >>>>>>>>> to >>>>>>>>> Justin’s >>>>>>>>> personal >>>>>>>>> AS >>>>>>>>> to >>>>>>>>> get >>>>>>>>> a >>>>>>>>> token”. >>>>>>>>> The >>>>>>>>> client >>>>>>>>> can >>>>>>>>> now >>>>>>>>> make >>>>>>>>> a >>>>>>>>> direct >>>>>>>>> correlation >>>>>>>>> between >>>>>>>>> the >>>>>>>>> data >>>>>>>>> that’s >>>>>>>>> being >>>>>>>>> protected >>>>>>>>> at >>>>>>>>> the >>>>>>>>> RS >>>>>>>>> and >>>>>>>>> the >>>>>>>>> person >>>>>>>>> running >>>>>>>>> the >>>>>>>>> AS >>>>>>>>> that >>>>>>>>> protects >>>>>>>>> it. >>>>>>>>> Importantly, >>>>>>>>> this >>>>>>>>> client >>>>>>>>> makes >>>>>>>>> this >>>>>>>>> call >>>>>>>>> with >>>>>>>>> no >>>>>>>>> prior >>>>>>>>> relationship >>>>>>>>> to >>>>>>>>> the >>>>>>>>> RS >>>>>>>>> and >>>>>>>>> no >>>>>>>>> really >>>>>>>>> auditable >>>>>>>>> way >>>>>>>>> to >>>>>>>>> track >>>>>>>>> it >>>>>>>>> down >>>>>>>>> after >>>>>>>>> the >>>>>>>>> fact. >>>>>>>>> This >>>>>>>>> is >>>>>>>>> a >>>>>>>>> design >>>>>>>>> feature >>>>>>>>> in >>>>>>>>> the >>>>>>>>> good >>>>>>>>> case, >>>>>>>>> and >>>>>>>>> terrifying >>>>>>>>> in >>>>>>>>> the >>>>>>>>> bad >>>>>>>>> case. >>>>>>>>> >>>>>>>>> If >>>>>>>>> the >>>>>>>>> RS >>>>>>>>> instead >>>>>>>>> says >>>>>>>>> “welcome >>>>>>>>> to >>>>>>>>> Medicine >>>>>>>>> Doctor >>>>>>>>> RS, >>>>>>>>> please >>>>>>>>> talk >>>>>>>>> to >>>>>>>>> the >>>>>>>>> Medicine >>>>>>>>> Doctor >>>>>>>>> AS >>>>>>>>> to >>>>>>>>> get >>>>>>>>> access”, >>>>>>>>> we >>>>>>>>> haven’t >>>>>>>>> exposed >>>>>>>>> anything >>>>>>>>> at >>>>>>>>> all. >>>>>>>>> And >>>>>>>>> from >>>>>>>>> the >>>>>>>>> perspective >>>>>>>>> of >>>>>>>>> both >>>>>>>>> the >>>>>>>>> patient >>>>>>>>> and >>>>>>>>> the >>>>>>>>> RS, >>>>>>>>> this >>>>>>>>> is >>>>>>>>> more >>>>>>>>> privacy-preserving, >>>>>>>>> and >>>>>>>>> it’s >>>>>>>>> really >>>>>>>>> the >>>>>>>>> least >>>>>>>>> surprising >>>>>>>>> option. >>>>>>>>> Once >>>>>>>>> the >>>>>>>>> client >>>>>>>>> gets >>>>>>>>> to >>>>>>>>> the >>>>>>>>> AS, >>>>>>>>> it >>>>>>>>> can >>>>>>>>> start >>>>>>>>> a >>>>>>>>> negotiation >>>>>>>>> of >>>>>>>>> figuring >>>>>>>>> out >>>>>>>>> who >>>>>>>>> the >>>>>>>>> RO >>>>>>>>> is >>>>>>>>> for >>>>>>>>> the >>>>>>>>> information >>>>>>>>> being >>>>>>>>> accessed. >>>>>>>>> >>>>>>>>> On >>>>>>>>> top >>>>>>>>> of >>>>>>>>> this, >>>>>>>>> the >>>>>>>>> usability >>>>>>>>> expectations >>>>>>>>> of >>>>>>>>> people >>>>>>>>> managing >>>>>>>>> their >>>>>>>>> own >>>>>>>>> AS, >>>>>>>>> or >>>>>>>>> set >>>>>>>>> of >>>>>>>>> AS’s >>>>>>>>> for >>>>>>>>> multiple >>>>>>>>> personas >>>>>>>>> to >>>>>>>>> keep >>>>>>>>> things >>>>>>>>> separate, >>>>>>>>> is >>>>>>>>> a >>>>>>>>> huge >>>>>>>>> burden. >>>>>>>>> Even >>>>>>>>> in >>>>>>>>> the >>>>>>>>> tech >>>>>>>>> community, >>>>>>>>> I >>>>>>>>> know >>>>>>>>> people >>>>>>>>> who >>>>>>>>> can’t >>>>>>>>> reliably >>>>>>>>> manage >>>>>>>>> more >>>>>>>>> than >>>>>>>>> one >>>>>>>>> email >>>>>>>>> address >>>>>>>>> for >>>>>>>>> different >>>>>>>>> purposes. >>>>>>>>> I >>>>>>>>> wouldn’t >>>>>>>>> expect >>>>>>>>> my >>>>>>>>> partner >>>>>>>>> to >>>>>>>>> do >>>>>>>>> that >>>>>>>>> — >>>>>>>>> they >>>>>>>>> have >>>>>>>>> trouble >>>>>>>>> enough >>>>>>>>> balancing >>>>>>>>> all >>>>>>>>> the >>>>>>>>> logins >>>>>>>>> and >>>>>>>>> sessions >>>>>>>>> required >>>>>>>>> for >>>>>>>>> different >>>>>>>>> kids >>>>>>>>> remote >>>>>>>>> schooling, >>>>>>>>> I >>>>>>>>> couldn’t >>>>>>>>> imagine >>>>>>>>> them >>>>>>>>> having >>>>>>>>> to >>>>>>>>> understand >>>>>>>>> all >>>>>>>>> the >>>>>>>>> requirements >>>>>>>>> for >>>>>>>>> managing >>>>>>>>> multiple >>>>>>>>> authorization >>>>>>>>> servers >>>>>>>>> and >>>>>>>>> associated >>>>>>>>> policies. >>>>>>>>> I >>>>>>>>> also >>>>>>>>> don’t >>>>>>>>> expect >>>>>>>>> any >>>>>>>>> person >>>>>>>>> to >>>>>>>>> “manage >>>>>>>>> keys” >>>>>>>>> — >>>>>>>>> I’ve >>>>>>>>> been >>>>>>>>> on >>>>>>>>> the >>>>>>>>> internet >>>>>>>>> for >>>>>>>>> decades >>>>>>>>> and >>>>>>>>> I >>>>>>>>> can >>>>>>>>> barely >>>>>>>>> keep >>>>>>>>> tabs >>>>>>>>> on >>>>>>>>> my >>>>>>>>> GPG >>>>>>>>> keys, >>>>>>>>> and >>>>>>>>> only >>>>>>>>> use >>>>>>>>> them >>>>>>>>> when >>>>>>>>> I >>>>>>>>> am >>>>>>>>> forced >>>>>>>>> to. >>>>>>>>> This >>>>>>>>> is >>>>>>>>> exactly >>>>>>>>> the >>>>>>>>> kind >>>>>>>>> of >>>>>>>>> “market >>>>>>>>> pressure” >>>>>>>>> that >>>>>>>>> I >>>>>>>>> think >>>>>>>>> Ben >>>>>>>>> mentions >>>>>>>>> above, >>>>>>>>> people >>>>>>>>> will >>>>>>>>> just >>>>>>>>> want >>>>>>>>> to >>>>>>>>> outsource >>>>>>>>> that >>>>>>>>> to >>>>>>>>> someone >>>>>>>>> else, >>>>>>>>> and >>>>>>>>> the >>>>>>>>> reality >>>>>>>>> will >>>>>>>>> be >>>>>>>>> a >>>>>>>>> few >>>>>>>>> popular >>>>>>>>> providers. >>>>>>>>> >>>>>>>>> In >>>>>>>>> which >>>>>>>>> case, >>>>>>>>> we >>>>>>>>> could >>>>>>>>> end >>>>>>>>> up >>>>>>>>> doing >>>>>>>>> a >>>>>>>>> ton >>>>>>>>> of >>>>>>>>> work >>>>>>>>> to >>>>>>>>> allow >>>>>>>>> an >>>>>>>>> RS >>>>>>>>> choice >>>>>>>>> only >>>>>>>>> to >>>>>>>>> end >>>>>>>>> up >>>>>>>>> with >>>>>>>>> a >>>>>>>>> world >>>>>>>>> where >>>>>>>>> the >>>>>>>>> RS >>>>>>>>> ends >>>>>>>>> up >>>>>>>>> making >>>>>>>>> a >>>>>>>>> limited >>>>>>>>> choice >>>>>>>>> anyway. >>>>>>>>> We >>>>>>>>> see >>>>>>>>> how >>>>>>>>> that >>>>>>>>> plays >>>>>>>>> out >>>>>>>>> with >>>>>>>>> OpenID >>>>>>>>> Connect >>>>>>>>> — >>>>>>>>> RP’s >>>>>>>>> could >>>>>>>>> allow >>>>>>>>> arbitrary >>>>>>>>> IdPs >>>>>>>>> but >>>>>>>>> they >>>>>>>>> choose >>>>>>>>> Google >>>>>>>>> because >>>>>>>>> it >>>>>>>>> works >>>>>>>>> and >>>>>>>>> that’s >>>>>>>>> where >>>>>>>>> the >>>>>>>>> users >>>>>>>>> are. >>>>>>>>> (And >>>>>>>>> that’s >>>>>>>>> not >>>>>>>>> to >>>>>>>>> say >>>>>>>>> anything >>>>>>>>> of >>>>>>>>> the >>>>>>>>> proprietary >>>>>>>>> OIDC-like >>>>>>>>> protocols, >>>>>>>>> but >>>>>>>>> that’s >>>>>>>>> another >>>>>>>>> discussion). >>>>>>>>> >>>>>>>>> For >>>>>>>>> further >>>>>>>>> reading >>>>>>>>> on >>>>>>>>> these >>>>>>>>> topics, >>>>>>>>> I >>>>>>>>> recommend >>>>>>>>> both >>>>>>>>> “Why >>>>>>>>> Johnny >>>>>>>>> Can’t >>>>>>>>> Encrypt” >>>>>>>>> and >>>>>>>>> “Why >>>>>>>>> CSCW >>>>>>>>> Systems >>>>>>>>> Fail”. >>>>>>>>> >>>>>>>>> So >>>>>>>>> what >>>>>>>>> does >>>>>>>>> this >>>>>>>>> have >>>>>>>>> to >>>>>>>>> do >>>>>>>>> with >>>>>>>>> GNAP? >>>>>>>>> I >>>>>>>>> think >>>>>>>>> we >>>>>>>>> can >>>>>>>>> be >>>>>>>>> clear-eyed >>>>>>>>> on >>>>>>>>> what >>>>>>>>> kinds >>>>>>>>> of >>>>>>>>> expectations >>>>>>>>> we >>>>>>>>> have >>>>>>>>> for >>>>>>>>> the >>>>>>>>> participants. >>>>>>>>> If >>>>>>>>> we >>>>>>>>> expect >>>>>>>>> users >>>>>>>>> (RO’s) >>>>>>>>> to >>>>>>>>> have >>>>>>>>> to >>>>>>>>> set >>>>>>>>> up >>>>>>>>> the >>>>>>>>> AS-RS >>>>>>>>> relationship, >>>>>>>>> or >>>>>>>>> expect >>>>>>>>> them >>>>>>>>> to >>>>>>>>> carry >>>>>>>>> their >>>>>>>>> AS, >>>>>>>>> or >>>>>>>>> manage >>>>>>>>> their >>>>>>>>> personal >>>>>>>>> keys >>>>>>>>> — >>>>>>>>> I >>>>>>>>> think >>>>>>>>> we’ve >>>>>>>>> lost >>>>>>>>> the >>>>>>>>> battle >>>>>>>>> for >>>>>>>>> relevance. >>>>>>>>> >>>>>>>>>  — >>>>>>>>> Justin >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> 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 >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>>> >>>> >>> >>> >> > --------------DB453B141C0C9C7C416DF8F8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
    Hi Justin,

    Let me rephrase the last question: How will a RS or a RO be bootstrapped for working with a GNAP "sub" claim or a "sub_id" claim ?

    Denis

    GNAP doesn’t have anything too say about anybody authenticating directly to the RS. If that happens, it’s out of the view and out of scope of GNAP.

     — Justin

    On Mar 26, 2021, at 1:06 PM, Denis <denis.ietf@free.fr> wrote:

    Hi everybody,

    The content of this thread has nothing to do any more with its original title which was: "Will GNAP support Zero Trust Architecture?"
    Since I am going to use some sentences of this thread to open a new topic, I changed the title of this thread into :
    "Relationship between Authentication and Authorization ?"

    At the moment, I got the impression that nobody agrees any more about what GNAP is or is not, what it should address and what it should not address.
    The components of the model are becoming more numerous and hazy. A new terminology is sometimes being used, but is not yet present in the last published draft.

    I still can't understand any of the new terms that are being used (AS-RS and AS-RO), which are still left undefined.

    The last exchanges look more as conversations between workers during the construction of the Babel tower.

    Last year, my first remark was to mention that a section or an Annex explaining the common points and the differences with OAuth 2.0
    would be useful. Such section or Annex still does not exist.

    Justin wrote:
    If an RS allows a username/password HTTP Basic auth in addition to accepting access tokens, it can do so, but
    GNAP doesn’t have anything to say about the Basic auth use, or even its relation to any access tokens or RO’s or anything else.
    Let us split the end of this sentence into two parts:

    "GNAP doesn’t have anything to say about the Basic auth use":  If an authentication exchange  is necessary, the draft document should describe, for completeness,
    the HTTP error code that will be returned.

    "or even its relation to any access tokens or RO’s or anything else". Let us suppose that a RS supports FIDO as an authentication mechanism to authenticate its end-users.
    FIDO provides the major advantage that, for every RS, a different identifier is used by every end-user. This prevents end-users accounts correlations between RSs by using
    such identifiers. In practice, a FIDO identifier is a pseudonym.

    At this very moment, the RS is able to identify and authenticate its end-users using FIDO pseudonyms. Now, let us raise the following question:

    How will a RS be bootstrapped for working with a GNAP "sub" claim or a "sub_id" claim, whereas FIDO is already being used ?

    Denis


    Adrian,

    I disagree, I believe that what I have laid out is exactly separating the concerns into working components. 

    Like OAuth before it, GNAP is a protocol negotiate access for a client instance to an RS, using an AS as the facilitator of that delegated negotiation. (Unlike OAuth, it’s importantly also for negotiating user information to the client directly from the AS with no RS involved, but that’s an aside for the purposes of our conversation here).

    If a particular GNAP RS also allows other kinds of processes to enable access to it, that is completely fine, but outside of GNAP. If an RS allows a username/password HTTP Basic auth in addition to accepting access tokens, it can do so, but GNAP doesn’t have anything to say about the Basic auth use, or even its relation to any access tokens or RO’s or anything else. If an RS accepts structured access tokens signed by trusted keys that don’t come from an AS through a negotiated request — again, that’s fine, but GNAP is silent about the RS doing that. If the RS acts as “its own AS” then it’s really just an RS and an AS living in the same box. Again, that’s fine, and super common with OAuth today. 

    GNAP is solving the problem of connecting the client to the RS through means of an AS. Other solutions are possible and many of them can be deployed right alongside, but that’s not the corner of the world that GNAP is solving. GNAP should be concerned about how these other technologies can be used alongside it. I think there’s a lot of room for the things that you’re talking about, and more importantly for solving the use cases that you’re bringing. But GNAP should be more than a single-point solution, and so we need to balance these concerns. The conceptual framework of an AS that takes in lots of different information and spits out access tokens is exactly the abstraction layer that is necessary for making these use cases interoperable.

     — Justin

    On Mar 26, 2021, at 8:30 AM, Adrian Gropper <agropper@healthurl.com> wrote:

    @Justin, there’s no separation of concerns here. No partition between processor and controller. No data minimization. And, I see no obvious reason to make this the core of GNAP. 

    The one thing we can probably all agree on is that there’s only one RS and one RO. 

    The core of GNAP, in my opinion, can be built and explained around this simple design. The RS is a processor. The RO is a controller. The RS bears only security responsibility. The RS bears no privacy responsibility. The RO delegates this to the RS but this is not authorization as the A in GNAP.

    The RO retains all rights to delegate within the scope of things that the RS is willing to support using various token formats and endpoint options. Some of these options may do all sorts of things for all sorts of clients and user-agents  but these are options. 

    For example, if a request comes to the RS that is not in the form of an access token, then it either gets sent to the RO or their agent, or it gets logged and dumped. One such option, common in healthcare, is “Break the Glass” where the RS is acting as an authorization server because the user-agent is making a request instead of presenting an access token. GNAP can offer this as an option but it is not our core.

    Adrian



    On Fri, Mar 26, 2021 at 7:15 AM Justin Richer <jricher@mit.edu> wrote:
    I have a big problem with this line:

    > the RS and AS-RS only see access tokens. The requests (from RO') that resulted in an access token are none of their business.

    In the trust model we’ve been discussing, the requests that result in access tokens are solely the business of AS-RS, since AS-RS is the only entity that’s allowed, and trusted by the RS, to create access tokens for the RS. That is its entire job, the entire reason it exists in the system. By definition the party generating tokens for use at the RS is the AS for that RS, I don’t care how you deploy it. If RO wants to give access to someone else (who isn’t an “RO" anymore, they’re another end-user), then that end user’s client software will need to talk to AS-RS to get its own access token.

    Now here’s the trick: when the end user’s client instance talks to AS-RS, that does NOT mean that AS-RS needs to know all the details and policy reasons that it should give an access token to that client instance. It doesn’t even need to know the existence of another end user. It doesn’t need identity, it doesn’t need policy. Sure, it COULD handle all of that internally, and many will, but the protocol doesn’t demand it. 

    This means that the first client instance, the one that gets the access token, can also be given something alongside the access token that it can then hand to another piece of software (or to a person to hand eo their piece of software). This artifact is not an access token. This artifact could be something structured that the client understands, and can make derivatives of, and present back to the AS-RS for getting new access tokens. There could be multiple different flavors of this kind of artifact for different kinds of environments and groups. But what they all have in common is that they can potentially be used to request more access tokens within some context at the AS-RS.

     — Justin



    On Mar 25, 2021, at 5:50 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    My issue is with Alan's:
    "7. Another user agent (RO') can contact any holder of the access token or the service's policy agent (AS-RS) to get a delegated access token."

    I would prefer "7A. Another user agent (RO') can contact any holder of the access token." by default so that the AS-RS does not see the requests. In other words, the RS and AS-RS only see access tokens. The requests (from RO') that resulted in an access token are none of their business.

    The reality is that RO' can discover a resource RS and can share whatever information with RS-AS they want and the RO may not even know about it unless the RS decides to let them know somehow. This seems to be a drawback of the capabilities approach. 

    In terms of privacy and control, I, as the RO, want a contract with the RS that says that I or my agent (AS-RO) must sign an access token. This is a fundamental audit requirement. Without it, a rogue RS and AS-RS can do all sorts of things and the RO would never know. I understand that a rogue RS might not support an honest contemporaneous log of access tokens presented so there's a trust issue here that I seems unavoidable unless I specify in my RO-RS contract that they use a separate contemporaneous log such as AS-RO for every access token presented and risk being sued if they process an access token without also updating the separate log.

    - Adrian


    On Thu, Mar 25, 2021 at 1:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin Richer <jricher@mit.edu> wrote:
    Hi Alan,

    In all of my discussion, and in the spec itself, the RO is the :entity: in charge of approving rights. They’re probably a person. It might be software that makes a policy decision in some way, or a corporate entity, or something like that. But it’s not assumed to be a computational agent in the terms of the protocol itself. Would that recast what you’re saying below?

    Hmmm.  I guess not.  It's just that the person would be using some UI to express their decisions to what I called the user agent.  That model fits in very nicely with what we did with Polaris, our virus safe computing environment for Windows XP, https://dl.acm.org/doi/10.1145/1151030.1151033.  The person would click on the icon for a Word file, and an instance of Word would open with only the permission needed to edit that one file.  Same thing here.  The client could ask for permission to use the resource, or permission could be granted implicitly when the user selects a resource associated with a specific client.

    --------------
    Alan Karp


    On Thu, Mar 25, 2021 at 9:53 AM Justin Richer <jricher@mit.edu> wrote:
    Hi Alan,

    In all of my discussion, and in the spec itself, the RO is the :entity: in charge of approving rights. They’re probably a person. It might be software that makes a policy decision in some way, or a corporate entity, or something like that. But it’s not assumed to be a computational agent in the terms of the protocol itself. Would that recast what you’re saying below?

     — Justin

    On Mar 25, 2021, at 12:36 PM, Alan Karp <alanhkarp@gmail.com> wrote:

    There seems to be some confusion about how AS-RO comes into the picture, probably because of the "AS" part.  I'm going to try to clear up that confusion by more carefully explaining what I mean.

    I'm assuming that RO is a computational agent representing the person who is the resource owner, something called the "user agent" in operating systems lingo.  I'm also assuming that it's possible to do delegation, either locally or by token exchange with AS-RS.  All delegations are potentially sub-scoped, but you may also want to delegate with full scope to have a separately revocable access token.

      Here's an example of how things work in a capability oriented system.
    1. Someone, the service owner, creates a service.
    2. The service owner contracts with an policy agent (AS-RS) to create and manage access tokens for that service (RS).
    3. A person wishing to create a resource at RS uses their user agent (RO) to contact the service owner's policy agent (AS-RS) and gets back an access token for that resource.
    4. That user agent (RO) can 
      1. use that access token to invoke the resource, or
      2. delegate an access token to a client of the user agent's (RO) choice, or
      3. contract with a policy agent (AS-RO) to manage those delegations on behalf of the user agent (RO), or
      4. specify a policy with the service's policy agent (AS-RS).
    5. A client can contact any holder of the access token (the user agent (RO) or its policy agent (AS-RO)) or the service's policy agent (AS-RS) to get a delegated access token.
    6. That client can delegate that token to another client.
    7. Another user agent (RO') can contact any holder of the access token or the service's policy agent (AS-RS) to get a delegated access token.
    8. The other user agent (RO') can 
      1. use that access token to invoke the resource, or
      2. delegate it to a client of its choice, or
      3. contract with a policy agent (AS-RO') of its choosing to manage those delegations on its behalf, or
      4. specify a policy with the service's policy agent (AS-RS).
    9. and so on
    When any of these computational agents, user agents (ROs) or clients acting on their behalf, invokes the resource, AS-RS verifies that the access token is a valid delegation, i.e., proper sub-scoping, hasn't been revoked, and that it authorizes the request being made before telling the service (RS) to honor the request.  At no point does the service's policy agent (AS-RS) know which computational agent did any particular delegation.  (Token exchange can be done as anonymously as possible.)  In particular, the policy agents (AS-RO) need not be the same, or even compatible with, the service's policy agent (AS-RS).  GNAP specifies the protocol between requesters, invokers, delegators (for token exchange) of tokens and AS-RS.  That protocol need not be used between user agents (RO), clients, or other policy agents (AS-RO), but it is likely to be.

     -------------
    Alan Karp


    On Thu, Mar 25, 2021 at 5:45 AM Justin Richer <jricher@mit.edu> wrote:
    The way I’m thinking about Adrian’s use case is that what we’re calling the “AS-RO” isn’t an “AS” in the traditional OAuth/GNAP sense, at least not exactly. This is the agent that the RO can use to set policies and manage consent on their behalf, and I’ve been arguing that it fits better into this vaguely-defined “interaction component” aspect of the current AS definition, and it’s not currently separated from the AS definition. The “AS-RS” maps to what we’d call the “AS” in OAuth/GNAP traditionally, it’s what the RS trusts to issue tokens. In traditional OAuth the AS-RO and AS-RS are always the same thing, from a functional protocol perspective. An important point here is that from a client’s perspective, they’re only talking to the AS-RS since that’s where the client gets its tokens, because at the end of the day the client just wants to call the API at the RS and doesn’t care how that happens (from a protocol standpoint). 

    Note well: Even thought I don’t believe that “AS-RO” is an authorization server at all, I’m going to keep using that term below for consistency with previous discussion.

    So we have these fundamental relationships around getting the client to access the RS:

    1. RS trusts AS-RS to issue tokens that RS will accept, validate, and process for requests from client
    2. Client trusts AS-RS to issue tokens that client can use at RS
    3. RO trusts RS to protect RO’s api through delegated access

    On top of that, we’ve got some additional aspects that we’re discussing:

    4. RO trusts AS-RO to manage RO’s policies at runtime
    5. AS-RS trusts AS-RO to assert RO’s policies for access to RS
    6. Client trusts whatever AS-RS sends client to deal with, including possibly RO-AS at runtime, because of (2)

    What I have been saying is that 4/5/6 are optional details of how RS-AS runs things, and I think this also maps with Adrian’s view of choice, since if my RS’s AS-RS doesn’t allow me to plug in my own AS-RO then I would be motivated to pick a different RS who’s AS-RS lets me do just that. The same way I’d pick a different RS if their surrounding services didn’t accept my preferred federation login and I didn’t want to make another account. Of course, market forces being as they are, I might not have much of an actionable choice in RS, but GNAP can’t change that. 

    What we can do is make it possible for AS-RS to talk to AS-RO, both in philosophy of the protocol design and in concrete hooks to support (6) above. 

    Separately, we can approach the issue of making 1/2 above more dynamic. This was UMA2’s “federated authorization” approach, and is behind a lot of the “bring your own AS” models out there. The problem with these is that we know from many years of experience that most RS’s aren’t interested in doing anything of the sort.

    So with GNAP we can instead allow 4/5/6 to vary in a predictable and consistent way, letting the RS keep control over 1/2, thereby enabling choice in (3). We don’t have to be the ones who define the all of the details of every permutation of (5) to enable this, though. Some of this is going to be configuration out of band, some of it’s going to be communication at runtime. This is where VC’s, ZCAPs, CHAPI, DIDComm, FIDO, and a whole swath of other tech can come in and help out. I don’t think we need to put all the details for using these into core, nor do I think we’ll pull of The Great And Ultimate Abstraction for using these and other approaches. But we can at least start talking about “AS-RS” in such a way that it no longer assumes it’s always the same party dealing with the RO directly.

     — Justin

    On Mar 25, 2021, at 6:40 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    To reframe it closer to GNAP:
    - AS = AS-RO, that's where you find the RO policies. The AS issues access tokens to the client.
    - the RO policies could be a) defined locally or b) in relationship with the RS

    There have been several ideas related to the AS-RS relationship b:
    b1) the RS issues capabilities (which can be further attenuated by the RO)
    b2) Adrian also discussed a DID based solution
    b3) there was also an alternative ACL proposal from Denis (+ preflight)

    Fabien


    On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Ok so I get you correctly: 
    - what matters is the RQ (could be a RO or a end-user or both : we don't really care at a high-level, they're all treated as entities that make a request)
    - the policy is able to handle those different cases, based on its own internal delegation protocol
    - currently that requires AS-RS and AS-RO, but maybe it can be simplified

    To answer to Denis, here's what I understood:
    - RO trusts AS-RS (and then handles its own policies within AS-RO)
    - end-user trusts AS-RO (through its client)

    Could probably work but that's a fairly different model compared to OAuth2 (and of today's GNAP), with different frontiers between the AS and the RS. 

    Please do not hesitate to correct me if I'm wrong.

    Fabien 

    On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper <agropper@healthurl.com> wrote:
    I believe there are alternatives to having two kinds of ASs. The problem may be a side-effect of deciding to switch away form treating the RO as different from the RQ. That leads to downstream privacy issues. Our desire for architectural simplicity is admirable but that may have been a step too far.

    There may also be solutions based on different types of tokens, as in different capabilities (tokens signed by the RS) vs. tokens signed by the AS. I’m not sure about that but Alan might have more to say.

    Adrian

    On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks. The general problem statement is clear.

    The proposed solution a bit less (to me). I understood that from point 2, Alan involves 2 ASs. You said : "There’s no obvious reason to have two types of ASs". Do you see an alternative ?

    Regarding the last item, I don't think that naming RQ by end-user created the problem. It might just highlight the asymmetry, which fundamentally exists. 

    Fabien


    On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper <agropper@healthurl.com> wrote:
    Recap:
    1 - Justin (I think) introduced the idea of an AS on the RS trust boundary side.
    2 - I said the RO should not have to share policies with the RS.
    3 - Alan invented the concept of AS-RO and AS-RS to separate two kinds of PDPs. 

    The thing is that step 2 is not symmetrical. The RO has a legitimate privacy interest in keeping their policies private and minimizing the leakage of information about requests that are posed against those policies. 

    The RS, on the other hand, should be publishing its policies (e.g. what it’s selling or what jurisdiction it’s in or what tokens or scopes it supports). The RS has no obvious privacy interest in GNAP. It’s just an enforcer.

    There is one other privacy interest to consider around the RS and that is the requesting party (the end-user that is not the RO :-) might prefer to share attributes with the RS instead of the RO or something controlled by the RO. This case could be an “extension” to GNAP and might result in a split AS as a solution. This problem was introduced when the editors decided to replace RQ with end-user. Obviously, the RO end-user has no privacy interests relative to itself.

    Adrian




    On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    I was referring to "By my definition, this model has two ASs since both are processing requests into tokens". If there's no reason to have 2 types of ASs, that's fine then. 
    But I'm a bit lost in where we stand with the idea. 

    Could you recap? 

    Fabien 

    Le jeu. 25 mars 2021 à 08:16, Adrian Gropper <agropper@healthurl.com> a écrit :
    There’s no obvious reason to have two types of ASs. Any AS that is executing the policies of the RS can look to GNAP like the RS itself. Why would GNAP expose that interface to anyone? 

    Adrian

    On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Note : I'm not sure that's a good idea, but having 2 types of ASs is not that easy to grasp.

    Fabien 

    Le jeu. 25 mars 2021 à 08:07, Fabien Imbault <fabien.imbault@gmail.com> a écrit :
    The purpose of either handling policies locally or delegating them to the RO agent. 

    Le jeu. 25 mars 2021 à 08:04, Adrian Gropper <agropper@healthurl.com> a écrit :
    What purpose would be served by GNAP splitting the AS into two components?

    Adrian 

    On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Isn't the AS-RO a component of the AS? Same idea as the interact component, it functionnally belongs to the AS role but could be deployed either as a monolith or as a separate component?

    Fabien

    Le jeu. 25 mars 2021 à 04:26, Adrian Gropper <agropper@healthurl.com> a écrit :
    Yes, but I would say it’s not the RO that wants the access token. It’s the RO that wants the client making the request to get an access token. 

    Adrian

    On Wed, Mar 24, 2021 at 11:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Adrian Gropper <agropper@healthurl.com> wrote:

    In this design, the AS is the AS-RS and the agent is the AS-RO. By my definition, this model has two ASs since both are processing requests into tokens. The problem with this is complexity and privacy. The RO may not want to share the request information with the AS-RS.

    More precisely, RO has no choice but to present the required information to AS-RS if RO wants an access token.  However, RO does not want AS-RS to know the policy by which RO delegates tokens.  That's why RO uses AS-RO for those delegations.

    --------------
    Alan Karp


    On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Thank you for creating the issue. My definition of AS is independent of AS-RO or AS-RS. https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomment-806280421 I also agree with Alan's definition based on delegation. An AS-RS would be a delegate of the RS. 

    Based on that, I see it as obvious that the policy has to be accessible (defined locally?) in order for it to be run as the code that turns a request into an access token. 

    The only other possibility is that the request is packaged by the AS and sent elsewhere (an agent) for evaluation against policy and a proto-token returned. In that case the AS is acting as a proxy and the PDP is elsewhere. I can imagine that an AS-RS would behave this way so that the proto-token could be turned into an access token by the AS-RS. Isn't this what Justin is proposing? In this design, the AS is the AS-RS and the agent is the AS-RO. By my definition, this model has two ASs since both are processing requests into tokens. The problem with this is complexity and privacy. The RO may not want to share the request information with the AS-RS.

    Adrian

    On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Isn't that what the AS is supposed to be, only with the caveat that the policy is defined locally? 

    Fabien 


    Le mer. 24 mars 2021 à 20:17, Alan Karp <alanhkarp@gmail.com> a écrit :
    AS-RO is an AS that RO trusts to delegate RO's access tokens according to RO's policies.  

    --------------
    Alan Karp


    On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan and Adrian,

    I've created issue AS-RO policy delegation (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to capture your input. 
    A first question that arises: can we give a definition to AS-RO?

    Thanks
    Fabien

    On Tue, Mar 23, 2021 at 4:15 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan, 

    Yes, but in that flow, the token relationship between AS-RS and AS-RO is only secure if the tokens issued by AS-RS are cryptographically attenuable in the first place. 
     
    Attenuated delegation is a requirement, but that doesn't have to be done cryptographically.  Token exchange works just fine.  SPKI and zcap-ld are examples of the crypto approach, and we used token exchange in the system for HP.

    --------------
    Alan Karp


    On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan, 

    Yes, but in that flow, the token relationship between AS-RS and AS-RO is only secure if the tokens issued by AS-RS are cryptographically attenuable in the first place. 

    Fabien

    On Mon, Mar 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin Richer <jricher@mit.edu> wrote:

    But with all that in mind, I think the key here is going to be looking at what the inputs to the AS are, and how those can be defined in an interoperable way for AS’s that can accept them. I think there’s a lot of room for innovation and flexibility here that doesn’t break the trust model or core use cases. If I have an AS-RS set that won’t accept my favorite flavor of policy engine inputs, then I can decide not to use that one. But this is a very different question than saying the RS itself needs to accept my own AS — and we can’t keep conflating these two models.

    I agree.  The point of having an AS-RO is to allow RO to specify a policy for which of RO's access tokens should be delegated under what conditions.  AS-RS should not need to understand those policies.  The flow would be
    • RO contacts AS-RS and gets one or more access tokens.
    • RO delegates one or more of those tokens, potentially sub-scoped, to AS-RO.
    • A different user contacts AS-RO to get a potentially sub-scoped access token from AS-RO.
    • That user presents the access token delegated by AS-RO when invoking the resource.
    AS-RS only needs to verify that the delegation chain is legitimate, e.g., no increase in scope, and that it grants permission for the request being made.  AS-RS does not need to understand the policy behind granting the delegation by AS-RO.

    --------------
    Alan Karp


    On Mon, Mar 22, 2021 at 11:40 AM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    I think this shows the problem with the terminology as it’s been applied in this conversation, which I’ve tried to shine light on before. What you and others are calling the “RS” is really the “AS and RS working together” — everything to the right of the line. When Denis had brought up “eliminating the AS” in another thread, what he’d really done is labeled everything to the right of the line as the “RS”. Of course, the irony here is that everything to the right of the line used all be called the “AS” or simply “server” in the OAuth 1 days. As you say below, I don’t want the client to have visibility on what happens on that side. 

    Note well: The Google+ logo labeled “IdP” in the diagram is not the AS, as far as GNAP is concerned. It does not issue an access token that the RS will accept. The elements to the left of the line could be a lot of things, but they are NOT the AS — by definition. The client lives over on the left, but so do any external inputs to the AS. These could be policy inputs on behalf of the RO, they could be presentation artifacts, they could be federated logins, they could be the output of policy decisions. How the AS comes to trust those things is up to the AS’s implementation. It’s something we can talk about, but ultimately GNAP won’t be in any position to dictate because in practice some AS’s are simply going to internalize all policies and we will never successfully force those open. 

    But with all that in mind, I think the key here is going to be looking at what the inputs to the AS are, and how those can be defined in an interoperable way for AS’s that can accept them. I think there’s a lot of room for innovation and flexibility here that doesn’t break the trust model or core use cases. If I have an AS-RS set that won’t accept my favorite flavor of policy engine inputs, then I can decide not to use that one. But this is a very different question than saying the RS itself needs to accept my own AS — and we can’t keep conflating these two models.

    So to me, GNAP can support a Zero Trust Architecture by LEVERAGING the AS, not by subsuming or eliminating it. It is in fact the AS, not the client and not the RS, that will request and consume the results of a privacy-preserving zero-trust policy query thing. Anything that happens downstream from that is of little concern to the zero-trust components because, as you point out, it’s on the “other side” of the line. 

    I think we got this basic component model pretty right in OAuth: the AS and RS and client working together. Where OAuth misses the mark is the assumption that the user has to log in to the AS through a webpage and interact directly, thereby proving they’re the RO. It’s this latter space where I think we can both push innovation and also address the important and compelling use cases like the ones you’re bringing.

     — Justin

    On Mar 22, 2021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I'm sorry, Justin. As a Resource Owner, I look at the RS trust boundary (the dotted line in the diagram) as being the RS. I don't expect any visibility into what's going on on the right. 

    My problem with the framing you propose is that requests are going to the RS (or the AS-RS) and I don't want to share my policies with the AS-RS. I want to keep the RS and AS-RS as ignorant as possible.

    Adrian

    On Mon, Mar 22, 2021 at 1:48 PM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    What you’re discussing below, in terms of logging in to a site, is not approaching the RS. You are in fact approaching the client, and identifying both the AS and RS to the client. The client is a client of your identity in this model, and the RS is part of the identity provider. It’s really important that we don’t conflate the RS and client in this way as it leads to a lot of confusion downstream and a lot of broken trust boundaries.

    With that model in mind, approaching the “RS" and providing it your identity is really just a case of the “federated login to AS” pattern that we discussed on the WG call. The user here approaches an RS, which has its own AS. To share things from this RS, the RO has to authenticate to the RS’s AS. This particular AS allows the RO to do so using an external identity — in which case, the AS is now a “client” of a separate, disconnected (but layered) delegation. The ultimate client that eventually calls the RS down the way may or may not know about these layers. 

    <PastedGraphic-1.png>
    This same AS, which is closely tied to the RS and trusted by the RS, might also take in FIDO credentials, or DIDs, or any number of other proof mechanisms. The output of this is an access token the RS trusts, but the input is up to the AS. The RS is not what you’re logging in to.

     — Justin

    On Mar 22, 2021, at 1:28 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I too am in favor of avoiding consolidation and correlation. Right now, when I approach a service provider (RS) for the first time, I'm offered the opportunity to identify my persona as: email, sign-in with Google, Facebook, or Apple. I know there are people who try to create one-off email addresses but that is mostly a waste of time. 

    So, along come FIDO2 and DID wallets to the rescue. Now, in theory, I have a way to start out my RS relationship pseudonymously. 

    When I want my resource to be discovered or shared I will post that RS URL including my pseudonym. If I then want to introduce a mediator in front of my AS or messaging service endpoint, I have that option. If I want to keep requests away from the mediator, I would publish an encryption key along with my pseudonym.

    - Adrian



    On Mon, Mar 22, 2021 at 9:55 AM Justin Richer <jricher@mit.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhkarp@gmail.com> shared a talk about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use authority
    >> as a core principle. I advocate for a GNAP design that maximizes the power
    >> of the RO, to be seen as a human rights issue when the RO is a human. This
    >> causes me to ask how to combine better security with better human rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO to
    >> partition limited authority across dozens of different ASs by domain and
    >> function, then we are not using technology to empower the individual.
    >> Probably the opposite, as we introduce consent fatigue and burden normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because that maps
    >> into the way we manage our public and private identities. POLA would then
    >> teach care in keeping ASs and RSs related to work / public separate from
    >> ASs and RSs related to private life so that a policy vulnerability in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP
    > seems like a useful exercise.  I do want to point out some potential
    > pitfalls with one-AS-per-persona that we can also be aware of.  If
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS's
    > identity in effect also serves as a persona identity and there are privacy
    > considerations to that.  If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)
    > route is taken, we should consider whether that would lead to various
    > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.  That topic is a current matter of concern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the UMA working group, and it’s one of the biggest problems with the personal AS (and personal data store) model. This kind of thing makes RS-first trust models really difficult in practice.

    As a strawman, let’s say that I’ve got software that wants to access my medical information. It calls an RS and requests access, but it hasn’t been granted anything yet. Now I as the RO have set up the RS so that it talks to my personal AS, that only I use. In addition to the RS having to be able to figure out which medical records are being requested from the context of the unauthenticated request (which means it needs identifiers in the URL or something similar for the RS to be able to tell, assuming that it protects data for more than one person). So this client software doesn’t know who I am and doesn’t know my medical record information, makes a completely unauthorized request to the RS, and the RS says “Go to Justin’s personal AS to get a token”. The client can now make a direct correlation between the data that’s being protected at the RS and the person running the AS that protects it. Importantly, this client makes this call with no prior relationship to the RS and no really auditable way to track it down after the fact. This is a design feature in the good case, and terrifying in the bad case.

    If the RS instead says “welcome to Medicine Doctor RS, please talk to the Medicine Doctor AS to get access”, we haven’t exposed anything at all. And from the perspective of both the patient and the RS, this is more privacy-preserving, and it’s really the least surprising option. Once the client gets to the AS, it can start a negotiation of figuring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS, or set of AS’s for multiple personas to keep things separate, is a huge burden. Even in the tech community, I know people who can’t reliably manage more than one email address for different purposes. I wouldn’t expect my partner to do that — they have trouble enough balancing all the logins and sessions required for different kids remote schooling, I couldn’t imagine them having to understand all the requirements for managing multiple authorization servers and associated policies. I also don’t expect any person to “manage keys” — I’ve been on the internet for decades and I can barely keep tabs on my GPG keys, and only use them when I am forced to. This is exactly the kind of “market pressure” that I think Ben mentions above, people will just want to outsource that to someone else, and the reality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice only to end up with a world where the RS ends up making a limited choice anyway. We see how that plays out with OpenID Connect — RP’s could allow arbitrary IdPs but they choose Google because it works and that’s where the users are. (And that’s not to say anything of the proprietary OIDC-like protocols, but that’s another discussion).

    For further reading on these topics, I recommend both “Why Johnny Can’t Encrypt” and “Why CSCW Systems Fail”.

    So what does this have to do with GNAP? I think we can be clear-eyed on what kinds of expectations we have for the participants. If we expect users (RO’s) to have to set up the AS-RS relationship, or expect them to carry their AS, or manage their personal keys — I think we’ve lost the battle for relevance.

     — Justin


    --
    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


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






    --------------DB453B141C0C9C7C416DF8F8-- From nobody Fri Mar 26 12:57:56 2021 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 B82203A0C35 for ; Fri, 26 Mar 2021 12:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 PP_qvpiUBQTw for ; Fri, 26 Mar 2021 12:57:47 -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 E8C423A0C31 for ; Fri, 26 Mar 2021 12:57:45 -0700 (PDT) Received: from [192.168.1.22] (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 12QJvfxe026557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Mar 2021 15:57:41 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_DBD3EA7C-15CD-4F0D-AD78-6E6F97E06411" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 26 Mar 2021 15:57:40 -0400 In-Reply-To: Cc: txauth@ietf.org To: Denis References: <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> <5773FA7B-6891-4227-A8CA-2F506909B8CD@mit.edu> <3c103293-56a1-4be5-e2a3-12eb82d13238@free.fr> <91D11E67-34AB-4426-803C-7B5A6F50537F@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Relationship between Authentication and Authorization ? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2021 19:57:55 -0000 --Apple-Mail=_DBD3EA7C-15CD-4F0D-AD78-6E6F97E06411 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The subject identifier is whatever identifier the AS knows the subject = as. If they log in using only a FIDO token and the AS asserts that key = value as the identifier, then that=E2=80=99s what it will be. If they = sign up with an email address or make a username or get assigned a = random number, that=E2=80=99s what it will be. Or they could sign up = using any number of those and the AS still assigns them a random value, = because it=E2=80=99s always the AS that determines which value to assign = the number.=20 The RS is not involved in any subject information. Identity APIs, like = OpenID Connect=E2=80=99s UserInfo Endpoint, are out of scope for GNAP. If there is a subject identifier either included in or referenced by the = access token, that is up to any agreements between the AS and RS that = lead to the ability of the AS to create the tokens the RS can trust. All = of this is outside the scope of the core GNAP protocol and invisible to = the client.=20 =E2=80=94 Justin > On Mar 26, 2021, at 1:27 PM, Denis wrote: >=20 > Hi Justin, >=20 > Let me rephrase the last question: How will a RS or a RO be = bootstrapped for working with a GNAP "sub" claim or a "sub_id" claim ? >=20 > Denis >=20 >> GNAP doesn=E2=80=99t have anything too say about anybody = authenticating directly to the RS. If that happens, it=E2=80=99s out of = the view and out of scope of GNAP. >>=20 >> =E2=80=94 Justin >>=20 >>> On Mar 26, 2021, at 1:06 PM, Denis > wrote: >>>=20 >>> Hi everybody, >>>=20 >>> The content of this thread has nothing to do any more with its = original title which was: "Will GNAP support Zero Trust Architecture?" >>> Since I am going to use some sentences of this thread to open a new = topic, I changed the title of this thread into : >>> "Relationship between Authentication and Authorization ?" >>>=20 >>> At the moment, I got the impression that nobody agrees any more = about what GNAP is or is not, what it should address and what it should = not address. >>> The components of the model are becoming more numerous and hazy. A = new terminology is sometimes being used, but is not yet present in the = last published draft. >>>=20 >>> I still can't understand any of the new terms that are being used = (AS-RS and AS-RO), which are still left undefined.=20 >>>=20 >>> The last exchanges look more as conversations between workers during = the construction of the Babel tower. >>>=20 >>> Last year, my first remark was to mention that a section or an Annex = explaining the common points and the differences with OAuth 2.0 >>> would be useful. Such section or Annex still does not exist. >>>=20 >>> Justin wrote: >>> If an RS allows a username/password HTTP Basic auth in addition to = accepting access tokens, it can do so, but=20 >>> GNAP doesn=E2=80=99t have anything to say about the Basic auth use, = or even its relation to any access tokens or RO=E2=80=99s or anything = else. >>> Let us split the end of this sentence into two parts: >>>=20 >>> "GNAP doesn=E2=80=99t have anything to say about the Basic auth = use": If an authentication exchange is necessary, the draft document = should describe, for completeness, >>> the HTTP error code that will be returned. >>>=20 >>> "or even its relation to any access tokens or RO=E2=80=99s or = anything else". Let us suppose that a RS supports FIDO as an = authentication mechanism to authenticate its end-users. >>> FIDO provides the major advantage that, for every RS, a different = identifier is used by every end-user. This prevents end-users accounts = correlations between RSs by using=20 >>> such identifiers. In practice, a FIDO identifier is a pseudonym. >>>=20 >>> At this very moment, the RS is able to identify and authenticate its = end-users using FIDO pseudonyms. Now, let us raise the following = question:=20 >>>=20 >>> How will a RS be bootstrapped for working with a GNAP "sub" claim or = a "sub_id" claim, whereas FIDO is already being used ? >>> Denis >>>=20 >>>=20 >>>=20 >>>> Adrian, >>>>=20 >>>> I disagree, I believe that what I have laid out is exactly = separating the concerns into working components.=20 >>>>=20 >>>> Like OAuth before it, GNAP is a protocol negotiate access for a = client instance to an RS, using an AS as the facilitator of that = delegated negotiation. (Unlike OAuth, it=E2=80=99s importantly also for = negotiating user information to the client directly from the AS with no = RS involved, but that=E2=80=99s an aside for the purposes of our = conversation here). >>>>=20 >>>> If a particular GNAP RS also allows other kinds of processes to = enable access to it, that is completely fine, but outside of GNAP. If an = RS allows a username/password HTTP Basic auth in addition to accepting = access tokens, it can do so, but GNAP doesn=E2=80=99t have anything to = say about the Basic auth use, or even its relation to any access tokens = or RO=E2=80=99s or anything else. If an RS accepts structured access = tokens signed by trusted keys that don=E2=80=99t come from an AS through = a negotiated request =E2=80=94 again, that=E2=80=99s fine, but GNAP is = silent about the RS doing that. If the RS acts as =E2=80=9Cits own AS=E2=80= =9D then it=E2=80=99s really just an RS and an AS living in the same = box. Again, that=E2=80=99s fine, and super common with OAuth today.=20 >>>>=20 >>>> GNAP is solving the problem of connecting the client to the RS = through means of an AS. Other solutions are possible and many of them = can be deployed right alongside, but that=E2=80=99s not the corner of = the world that GNAP is solving. GNAP should be concerned about how these = other technologies can be used alongside it. I think there=E2=80=99s a = lot of room for the things that you=E2=80=99re talking about, and more = importantly for solving the use cases that you=E2=80=99re bringing. But = GNAP should be more than a single-point solution, and so we need to = balance these concerns. The conceptual framework of an AS that takes in = lots of different information and spits out access tokens is exactly the = abstraction layer that is necessary for making these use cases = interoperable. >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>> On Mar 26, 2021, at 8:30 AM, Adrian Gropper = > wrote: >>>>>=20 >>>>> @Justin, there=E2=80=99s no separation of concerns here. No = partition between processor and controller. No data minimization. And, I = see no obvious reason to make this the core of GNAP.=20 >>>>>=20 >>>>> The one thing we can probably all agree on is that there=E2=80=99s = only one RS and one RO.=20 >>>>>=20 >>>>> The core of GNAP, in my opinion, can be built and explained around = this simple design. The RS is a processor. The RO is a controller. The = RS bears only security responsibility. The RS bears no privacy = responsibility. The RO delegates this to the RS but this is not = authorization as the A in GNAP. >>>>>=20 >>>>> The RO retains all rights to delegate within the scope of things = that the RS is willing to support using various token formats and = endpoint options. Some of these options may do all sorts of things for = all sorts of clients and user-agents but these are options.=20 >>>>>=20 >>>>> For example, if a request comes to the RS that is not in the form = of an access token, then it either gets sent to the RO or their agent, = or it gets logged and dumped. One such option, common in healthcare, is = =E2=80=9CBreak the Glass=E2=80=9D where the RS is acting as an = authorization server because the user-agent is making a request instead = of presenting an access token. GNAP can offer this as an option but it = is not our core. >>>>>=20 >>>>> Adrian >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Fri, Mar 26, 2021 at 7:15 AM Justin Richer > wrote: >>>>> I have a big problem with this line: >>>>>=20 >>>>> > the RS and AS-RS only see access tokens. The requests (from RO') = that resulted in an access token are none of their business. >>>>>=20 >>>>> In the trust model we=E2=80=99ve been discussing, the requests = that result in access tokens are solely the business of AS-RS, since = AS-RS is the only entity that=E2=80=99s allowed, and trusted by the RS, = to create access tokens for the RS. That is its entire job, the entire = reason it exists in the system. By definition the party generating = tokens for use at the RS is the AS for that RS, I don=E2=80=99t care how = you deploy it. If RO wants to give access to someone else (who isn=E2=80=99= t an =E2=80=9CRO" anymore, they=E2=80=99re another end-user), then that = end user=E2=80=99s client software will need to talk to AS-RS to get its = own access token. >>>>>=20 >>>>> Now here=E2=80=99s the trick: when the end user=E2=80=99s client = instance talks to AS-RS, that does NOT mean that AS-RS needs to know all = the details and policy reasons that it should give an access token to = that client instance. It doesn=E2=80=99t even need to know the existence = of another end user. It doesn=E2=80=99t need identity, it doesn=E2=80=99t = need policy. Sure, it COULD handle all of that internally, and many = will, but the protocol doesn=E2=80=99t demand it.=20 >>>>>=20 >>>>> This means that the first client instance, the one that gets the = access token, can also be given something alongside the access token = that it can then hand to another piece of software (or to a person to = hand eo their piece of software). This artifact is not an access token. = This artifact could be something structured that the client understands, = and can make derivatives of, and present back = to the AS-RS for getting new access tokens. There could be = multiple different flavors of this kind of artifact for different kinds = of environments and groups. But what they all have in common is that = they can potentially be used to request more access tokens within some = context at the AS-RS. >>>>>=20 >>>>> =E2=80=94 Justin >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On Mar 25, 2021, at 5:50 PM, Adrian Gropper = > wrote: >>>>>>=20 >>>>>> My issue is with Alan's: >>>>>> "7. Another user agent (RO') can contact any holder of the access = token or the service's policy agent (AS-RS) to get a delegated access = token." >>>>>>=20 >>>>>> I would prefer "7A. Another user agent (RO') can contact any = holder of the access token." by default so that the AS-RS does not see = the requests. In other words, the RS and AS-RS only see access tokens. = The requests (from RO') that resulted in an access token are none of = their business. >>>>>>=20 >>>>>> The reality is that RO' can discover a resource RS and can share = whatever information with RS-AS they want and the RO may not even know = about it unless the RS decides to let them know somehow. This seems to = be a drawback of the capabilities approach.=20 >>>>>>=20 >>>>>> In terms of privacy and control, I, as the RO, want a contract = with the RS that says that I or my agent (AS-RO) must sign an access = token. This is a fundamental audit requirement. Without it, a rogue RS = and AS-RS can do all sorts of things and the RO would never know. I = understand that a rogue RS might not support an honest contemporaneous = log of access tokens presented so there's a trust issue here that I = seems unavoidable unless I specify in my RO-RS contract that they use a = separate contemporaneous log such as AS-RO for every access token = presented and risk being sued if they process an access token without = also updating the separate log. >>>>>>=20 >>>>>> - Adrian >>>>>>=20 >>>>>>=20 >>>>>> On Thu, Mar 25, 2021 at 1:22 PM Alan Karp > wrote: >>>>>> Justin Richer > wrote: >>>>>> Hi Alan, >>>>>>=20 >>>>>> In all of my discussion, and in the spec itself, the RO is the = :entity: in charge of approving rights. They=E2=80=99re probably a = person. It might be software that makes a policy decision in some way, = or a corporate = entity, or something like that. But it=E2=80=99s not assumed to be a = computational agent in the terms of the protocol itself. Would that = recast what you=E2=80=99re saying below? >>>>>>=20 >>>>>> Hmmm. I guess not. It's just that the person would be using = some UI to express their decisions to what I called the user agent. = That model fits in very nicely with what we did with Polaris, our virus = safe computing environment for Windows XP, = https://dl.acm.org/doi/10.1145/1151030.1151033 = . The person would = click on the icon for a Word file, and an instance of Word would open = with only the permission needed to edit that one file. Same thing here. = The client could ask for permission to use the resource, or permission = could be granted implicitly when the user selects a = resource associated with a specific = client. >>>>>>=20 >>>>>> -------------- >>>>>> Alan Karp >>>>>>=20 >>>>>>=20 >>>>>> On Thu, Mar 25, 2021 at 9:53 AM Justin Richer > wrote: >>>>>> Hi Alan, >>>>>>=20 >>>>>> In all of my discussion, and in the spec itself, the RO is the = :entity: in charge of approving rights. They=E2=80=99re probably a = person. It might be software that makes a policy decision in some way, = or a corporate = entity, or something like that. But it=E2=80=99s not assumed to be a = computational agent in the terms of the protocol itself. Would that = recast what you=E2=80=99re saying below? >>>>>>=20 >>>>>> =E2=80=94 Justin >>>>>>=20 >>>>>>> On Mar 25, 2021, at 12:36 PM, Alan Karp > wrote: >>>>>>>=20 >>>>>>> There seems to be some confusion about how AS-RO comes into the = picture, probably because of the "AS" part. I'm going to try to clear = up that confusion by more carefully explaining what I mean. >>>>>>>=20 >>>>>>> I'm assuming that RO is a computational agent representing the = person who is the resource owner, something called the "user agent" in = operating systems lingo. I'm also assuming that it's possible to do = delegation, either locally or by token exchange with AS-RS. All = delegations are potentially sub-scoped, but you may also want to = delegate with full scope to have a separately = revocable access token. >>>>>>>=20 >>>>>>> Here's an example of how things work in a capability oriented = system. >>>>>>> Someone, the service owner, creates a service. >>>>>>> The service owner contracts with an policy agent (AS-RS) to = create and manage access tokens for that service (RS). >>>>>>> A person wishing to create a resource at RS uses their user = agent (RO) to contact the service owner's policy agent (AS-RS) and gets = back an access token for that resource. >>>>>>> That user agent (RO) can=20 >>>>>>> use that access token to invoke the resource, or >>>>>>> delegate an access token to a client of the user agent's (RO) = choice, or >>>>>>> contract with a policy agent (AS-RO) to manage those delegations = on behalf of the user agent (RO), or >>>>>>> specify a policy with the service's policy agent (AS-RS). >>>>>>> A client can contact any holder of the access token (the user = agent (RO) or its policy agent (AS-RO)) or the service's policy agent = (AS-RS) to get a delegated access token. >>>>>>> That client can delegate that token to another client. >>>>>>> Another user agent (RO') can contact any holder of the access = token or the service's policy agent (AS-RS) to get a delegated access = token. >>>>>>> The other user agent (RO') can=20 >>>>>>> use that access token to invoke the resource, or >>>>>>> delegate it to a client of its choice, or >>>>>>> contract with a policy agent (AS-RO') of its choosing to manage = those delegations on its behalf, or >>>>>>> specify a policy with the service's policy agent (AS-RS). >>>>>>> and so on >>>>>>> When any of these computational agents, user agents (ROs) or = clients acting on their behalf, invokes the resource, AS-RS verifies = that the access token is a valid delegation, i.e., proper sub-scoping, = hasn't been revoked, and that it authorizes the request being made = before telling the service (RS) to honor the request. At no point does = the service's policy agent (AS-RS) know which computational agent did = any particular delegation. (Token exchange can be done as anonymously = as possible.) In particular, the policy agents (AS-RO) need not be the = same, or even compatible with, the service's policy agent (AS-RS). GNAP = specifies the protocol between requesters, invokers, delegators (for = token exchange) of tokens and AS-RS. That protocol need not be used = between user agents (RO), clients, or other policy agents (AS-RO), but = it is likely to be. >>>>>>>=20 >>>>>>> ------------- >>>>>>> Alan Karp >>>>>>>=20 >>>>>>>=20 >>>>>>> On Thu, Mar 25, 2021 at 5:45 AM Justin Richer > wrote: >>>>>>> The way I=E2=80=99m thinking about Adrian=E2=80=99s use case is = that what we=E2=80=99re calling the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t = an =E2=80=9CAS=E2=80=9D in the traditional OAuth/GNAP sense, at least = not exactly. This is the agent that the RO can use to set policies and = manage consent on their behalf, and I=E2=80=99ve been arguing that it = fits better into this vaguely-defined =E2=80=9Cinteraction component=E2=80= =9D aspect of the current AS definition, and it=E2=80=99s not currently = separated from the AS definition. The =E2=80=9CAS-RS=E2=80=9D maps to = what we=E2=80=99d call the =E2=80=9CAS=E2=80=9D in OAuth/GNAP = traditionally, it=E2=80=99s what the RS trusts to issue tokens. In = traditional OAuth the AS-RO and AS-RS are always the same thing, from a = functional protocol perspective. An important point here is that from a = client=E2=80=99s perspective, they=E2=80=99re only talking to the AS-RS = since that=E2=80=99s where the client gets its tokens, because at the = end of the day the client just wants to call the API at the RS and = doesn=E2=80=99t care how that happens (from a protocol standpoint).=20 >>>>>>>=20 >>>>>>> Note well: Even thought I don=E2=80=99t believe that =E2=80=9CAS-R= O=E2=80=9D is an authorization server at all, I=E2=80=99m going to keep = using that term below for consistency with previous discussion. >>>>>>>=20 >>>>>>> So we have these fundamental relationships around getting the = client to access the RS: >>>>>>>=20 >>>>>>> 1. RS trusts AS-RS to issue tokens that RS will accept, = validate, and process for requests from client >>>>>>> 2. Client trusts AS-RS to issue tokens that client can use at RS >>>>>>> 3. RO trusts RS to protect RO=E2=80=99s api through delegated = access >>>>>>>=20 >>>>>>> On top of that, we=E2=80=99ve got some additional aspects that = we=E2=80=99re discussing: >>>>>>>=20 >>>>>>> 4. RO trusts AS-RO to manage RO=E2=80=99s policies at runtime >>>>>>> 5. AS-RS trusts AS-RO to assert RO=E2=80=99s policies for access = to RS >>>>>>> 6. Client trusts whatever AS-RS sends client to deal with, = including possibly RO-AS at runtime, because of (2) >>>>>>>=20 >>>>>>> What I have been saying is that 4/5/6 are optional details of = how RS-AS runs things, and I think this also maps with Adrian=E2=80=99s = view of choice, since if my RS=E2=80=99s AS-RS doesn=E2=80=99t allow me = to plug in my own AS-RO then I would be motivated to pick a different RS = who=E2=80=99s AS-RS lets me do just that. The same way I=E2=80=99d pick = a different RS if their surrounding services didn=E2=80=99t accept my = preferred federation login and I didn=E2=80=99t want to make another = account. Of course, market forces being as they are, I might not have = much of an actionable choice in RS, but GNAP can=E2=80=99t change that.=20= >>>>>>>=20 >>>>>>> What we can do is make it possible for AS-RS to talk to AS-RO, = both in philosophy of the protocol design and in concrete hooks to = support (6) above.=20 >>>>>>>=20 >>>>>>> Separately, we can approach the issue of making 1/2 above more = dynamic. This was UMA2=E2=80=99s =E2=80=9Cfederated authorization=E2=80=9D= approach, and is behind a lot of the =E2=80=9Cbring your own AS=E2=80=9D = models out there. The problem with these is that we know from many years = of experience that most RS=E2=80=99s aren=E2=80=99t interested in doing = anything of the sort. >>>>>>>=20 >>>>>>> So with GNAP we can instead allow 4/5/6 to vary in a predictable = and consistent way, letting the RS keep control over 1/2, thereby = enabling choice in (3). We don=E2=80=99t have to be the ones who define = the all of the details of every permutation of (5) to enable this, = though. Some of this is going to be configuration out of band, some of = it=E2=80=99s going to be communication at runtime. This is where VC=E2=80=99= s, ZCAPs, CHAPI, DIDComm, FIDO, and a whole swath of other tech can come = in and help out. I don=E2=80=99t think we need to put all the details = for using these into core, nor do I think we=E2=80=99ll pull of The = Great And Ultimate Abstraction for using these and other approaches. But = we can at least start talking about =E2=80=9CAS-RS=E2=80=9D in such a = way that it no longer assumes it=E2=80=99s always the same party dealing = with the RO directly. >>>>>>>=20 >>>>>>> =E2=80=94 Justin >>>>>>>=20 >>>>>>>> On Mar 25, 2021, at 6:40 AM, Fabien Imbault = > wrote: >>>>>>>>=20 >>>>>>>> To reframe it closer to GNAP: >>>>>>>> - AS =3D AS-RO, that's where you find the RO policies. The AS = issues access tokens to the client. >>>>>>>> - the RO policies could be a) defined locally or b) in = relationship with the RS >>>>>>>>=20 >>>>>>>> There have been several ideas related to the AS-RS relationship = b: >>>>>>>> b1) the RS issues capabilities (which can be further attenuated = by the RO) >>>>>>>> b2) Adrian also discussed a DID based solution >>>>>>>> b3) there was also an alternative ACL proposal from Denis (+ = preflight) >>>>>>>>=20 >>>>>>>> Fabien >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault = > wrote: >>>>>>>> Ok so I get you correctly:=20 >>>>>>>> - what matters is the RQ (could be a RO or a end-user or both : = we don't really care at a high-level, they're all treated as entities = that make a request) >>>>>>>> - the policy is able to handle those different cases, based on = its own internal delegation protocol >>>>>>>> - currently that requires AS-RS and AS-RO, but maybe it can be = simplified >>>>>>>>=20 >>>>>>>> To answer to Denis, here's what I understood: >>>>>>>> - RO trusts AS-RS (and then handles its own policies within = AS-RO) >>>>>>>> - end-user trusts AS-RO (through its client) >>>>>>>>=20 >>>>>>>> Could probably work but that's a fairly different model = compared to OAuth2 (and of today's GNAP), with different frontiers = between the AS and the RS.=20 >>>>>>>>=20 >>>>>>>> Please do not hesitate to correct me if I'm wrong. >>>>>>>>=20 >>>>>>>> Fabien=20 >>>>>>>>=20 >>>>>>>> On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper = > wrote: >>>>>>>> I believe there are alternatives to having two kinds of ASs. = The problem may be a side-effect of deciding to switch away form = treating the RO as different from the RQ. That leads to = downstream privacy issues. Our = desire for architectural simplicity is admirable but that may have been = a step too far. >>>>>>>>=20 >>>>>>>> There may also be solutions based on different types of tokens, = as in different capabilities (tokens signed by the RS) vs. tokens signed = by the AS. I=E2=80=99m not sure about that but Alan might have more to = say. >>>>>>>>=20 >>>>>>>> Adrian >>>>>>>>=20 >>>>>>>> On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault = > wrote: >>>>>>>> Thanks. The general problem statement is clear. >>>>>>>>=20 >>>>>>>> The proposed solution a bit less (to me). I understood that = from point 2, Alan involves 2 ASs. You said : "There=E2=80=99s no = obvious reason to have two types of ASs". Do you see an alternative ? >>>>>>>>=20 >>>>>>>> Regarding the last item, I don't think that naming RQ by = end-user created the problem. It might just highlight the asymmetry, = which fundamentally exists.=20 >>>>>>>>=20 >>>>>>>> Fabien >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper = > wrote: >>>>>>>> Recap: >>>>>>>> 1 - Justin (I think) introduced the idea of an AS on the RS = trust boundary side. >>>>>>>> 2 - I said the RO should not have to share policies with the = RS. >>>>>>>> 3 - Alan invented the concept of AS-RO and AS-RS to separate = two kinds of PDPs.=20 >>>>>>>>=20 >>>>>>>> The thing is that step 2 is not symmetrical. The RO has a = legitimate privacy interest in keeping their policies private and = minimizing the leakage of information about requests that are posed = against those policies.=20 >>>>>>>>=20 >>>>>>>> The RS, on the other hand, should be publishing its policies = (e.g. what it=E2=80=99s selling or what jurisdiction it=E2=80=99s in or = what tokens or scopes it supports). The RS has no obvious privacy = interest in GNAP. It=E2=80=99s just an enforcer. >>>>>>>>=20 >>>>>>>> There is one other privacy interest to consider around the RS = and that is the requesting party (the end-user that is not the RO :-) = might prefer to share attributes with the RS instead of the RO or = something controlled by the RO. This case could be an =E2=80=9Cextension=E2= =80=9D to GNAP and might result in a split AS as a solution. This = problem was introduced when the editors decided to replace RQ with = end-user. Obviously, the RO end-user has no privacy interests relative = to itself. >>>>>>>>=20 >>>>>>>> Adrian >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault = > wrote: >>>>>>>> I was referring to "By my definition, this model has two ASs = since both are processing requests into tokens". If there's no reason to = have 2 types of ASs, that's fine then.=20 >>>>>>>> But I'm a bit lost in where we stand with the idea.=20 >>>>>>>>=20 >>>>>>>> Could you recap?=20 >>>>>>>>=20 >>>>>>>> Fabien=20 >>>>>>>>=20 >>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper = > a =C3=A9crit : >>>>>>>> There=E2=80=99s no obvious reason to have two types of ASs. Any = AS that is executing the policies of the RS can look to GNAP like the RS = itself. Why would GNAP expose that interface to anyone?=20 >>>>>>>>=20 >>>>>>>> Adrian >>>>>>>>=20 >>>>>>>> On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault = > wrote: >>>>>>>> Note : I'm not sure that's a good idea, but having 2 types of = ASs is not that easy to grasp. >>>>>>>>=20 >>>>>>>> Fabien=20 >>>>>>>>=20 >>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault = > a =C3=A9crit = : >>>>>>>> The purpose of either handling policies locally or delegating = them to the RO agent.=20 >>>>>>>>=20 >>>>>>>> Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper = > a =C3=A9crit : >>>>>>>> What purpose would be served by GNAP splitting the AS into two = components? >>>>>>>>=20 >>>>>>>> Adrian=20 >>>>>>>>=20 >>>>>>>> On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault = > wrote: >>>>>>>> Isn't the AS-RO a component of the AS? Same idea as the = interact component, it functionnally belongs to the AS role but could be = deployed either as a monolith or as a separate component? >>>>>>>>=20 >>>>>>>> Fabien >>>>>>>>=20 >>>>>>>> Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper = > a =C3=A9crit : >>>>>>>> Yes, but I would say it=E2=80=99s not the RO that wants the = access token. It=E2=80=99s the RO that wants the client making the = request to get an access token.=20 >>>>>>>>=20 >>>>>>>> Adrian >>>>>>>>=20 >>>>>>>> On Wed, Mar 24, 2021 at 11:22 PM Alan Karp > wrote: >>>>>>>> Adrian Gropper > wrote: >>>>>>>>=20 >>>>>>>> In this design, the AS is the AS-RS and the agent is the AS-RO. = By my definition, this model has two ASs since both are processing = requests into tokens. The problem with this is complexity and privacy. = The RO may not want to share the request information with the AS-RS. >>>>>>>>=20 >>>>>>>> More precisely, RO has no choice but to present the required = information to AS-RS if RO wants an access token. However, RO does not = want AS-RS to know the policy by which RO delegates tokens. That's why = RO uses AS-RO for those delegations. >>>>>>>>=20 >>>>>>>> -------------- >>>>>>>> Alan Karp >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper = > wrote: >>>>>>>> Thank you for creating the issue. My definition of AS is = independent of AS-RO or AS-RS. = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomment= -806280421 = I also agree with Alan's definition based on delegation. An = AS-RS would be a delegate of the RS.=20 >>>>>>>>=20 >>>>>>>> Based on that, I see it as obvious that the policy has to be = accessible (defined locally?) in order for it to be run as the code that = turns a request into an access token.=20 >>>>>>>>=20 >>>>>>>> The only other possibility is that the request is packaged by = the AS and sent elsewhere (an agent) for evaluation against policy and a = proto-token returned. In that case the AS is acting as a proxy and the = PDP is elsewhere. I can imagine that an AS-RS would behave this way so = that the proto-token could be turned into an access token by the AS-RS. = Isn't this what Justin is proposing? In this design, the AS is the AS-RS = and the agent is the AS-RO. By my definition, this model has two ASs = since both are processing requests into tokens. The problem with this is = complexity and privacy. The RO may not want to share the request = information with the AS-RS. >>>>>>>>=20 >>>>>>>> Adrian >>>>>>>>=20 >>>>>>>> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault = > wrote: >>>>>>>> Isn't that what the AS is supposed to be, only with the caveat = that the policy is defined locally?=20 >>>>>>>>=20 >>>>>>>> Fabien=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp = > a =C3=A9crit : >>>>>>>> AS-RO is an AS that RO trusts to delegate RO's access tokens = according to RO's policies. =20 >>>>>>>>=20 >>>>>>>> -------------- >>>>>>>> Alan Karp >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault = > wrote: >>>>>>>> Hi Alan and Adrian, >>>>>>>>=20 >>>>>>>> I've created issue AS-RO policy delegation = (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223 = ) to = capture your input.=20 >>>>>>>> A first question that arises: can we give a definition to = AS-RO? >>>>>>>>=20 >>>>>>>> Thanks >>>>>>>> Fabien >>>>>>>>=20 >>>>>>>> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp > wrote: >>>>>>>> Fabien Imbault > wrote: >>>>>>>> Hi Alan,=20 >>>>>>>>=20 >>>>>>>> Yes, but in that flow, the token relationship between AS-RS and = AS-RO is only secure if the tokens issued by AS-RS are cryptographically = attenuable in the first place.=20 >>>>>>>> =20 >>>>>>>> Attenuated delegation is a requirement, but that doesn't have = to be done cryptographically. Token exchange works just fine. SPKI and = zcap-ld are examples of the crypto approach, and we used token exchange = in the system for HP. >>>>>>>>=20 >>>>>>>> -------------- >>>>>>>> Alan Karp >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault = > wrote: >>>>>>>> Hi Alan,=20 >>>>>>>>=20 >>>>>>>> Yes, but in that flow, the token relationship between AS-RS and = AS-RO is only secure if the tokens issued by AS-RS are cryptographically = attenuable in the first place.=20 >>>>>>>>=20 >>>>>>>> Fabien >>>>>>>>=20 >>>>>>>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp > wrote: >>>>>>>> Justin Richer > wrote: >>>>>>>>=20 >>>>>>>> But with all that in mind, I think the key here is going to be = looking at what the inputs to the AS are, and how those can be defined = in an interoperable way for AS=E2=80=99s that can accept them. I think = there=E2=80=99s a lot of room for innovation and flexibility here that = doesn=E2=80=99t break the trust model or core use cases. If I have an = AS-RS set that won=E2=80=99t accept my favorite flavor of policy engine = inputs, then I can decide not to use that one. But this is a very = different question than saying the RS itself needs to accept my own AS = =E2=80=94 and we can=E2=80=99t keep conflating these two models. >>>>>>>>=20 >>>>>>>> I agree. The point of having an AS-RO is to allow RO to = specify a policy for which of RO's access tokens should be delegated = under what conditions. AS-RS should not need to understand those = policies. The flow would be >>>>>>>> RO contacts AS-RS and gets one or more access tokens. >>>>>>>> RO delegates one or more of those tokens, potentially = sub-scoped, to AS-RO. >>>>>>>> A different user contacts AS-RO to get a potentially sub-scoped = access token from AS-RO. >>>>>>>> That user presents the access token delegated by AS-RO when = invoking the resource. >>>>>>>> AS-RS only needs to verify that the delegation chain is = legitimate, e.g., no increase in scope, and that it grants permission = for the request being made. AS-RS does not need to understand the = policy behind granting the delegation by AS-RO. >>>>>>>>=20 >>>>>>>> -------------- >>>>>>>> Alan Karp >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer > wrote: >>>>>>>> Adrian, >>>>>>>>=20 >>>>>>>> I think this shows the problem with the terminology as it=E2=80=99= s been applied in this conversation, which I=E2=80=99ve tried to shine = light on before. What you and others are calling the =E2=80=9CRS=E2=80=9D = is really the =E2=80=9CAS and RS working together=E2=80=9D =E2=80=94 = everything to the right of the line. When Denis had brought up = =E2=80=9Celiminating the AS=E2=80=9D in another thread, what he=E2=80=99d = really done is labeled everything to the right of the line as the = =E2=80=9CRS=E2=80=9D. Of course, the irony here is that everything to = the right of the line used all be called the =E2=80=9CAS=E2=80=9D or = simply =E2=80=9Cserver=E2=80=9D in the OAuth 1 days. As you say below, I = don=E2=80=99t want the client to have visibility on what happens on that = side.=20 >>>>>>>>=20 >>>>>>>> Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in = the diagram is not the AS, as far as GNAP is concerned. It does not = issue an access token that the RS will accept. The elements to the left = of the line could be a lot of things, but they are NOT the AS =E2=80=94 = by definition. The client lives over on the left, but so do any external = inputs to the AS. These could be policy inputs on behalf of the RO, they = could be presentation = artifacts, they could be federated logins, they could be the = output of policy decisions. How the AS comes to trust those things is up = to the AS=E2=80=99s implementation. It=E2=80=99s something we can talk = about, but ultimately GNAP won=E2=80=99t be in any position to dictate = because in practice some AS=E2=80=99s are simply going to internalize = all policies and we will never successfully force those open.=20 >>>>>>>>=20 >>>>>>>> But with all that in mind, I think the key here is going to be = looking at what the inputs to the AS are, and how those can be defined = in an interoperable way for AS=E2=80=99s that can accept them. I think = there=E2=80=99s a lot of room for innovation and flexibility here that = doesn=E2=80=99t break the trust model or core use cases. If I have an = AS-RS set that won=E2=80=99t accept my favorite flavor of policy engine = inputs, then I can decide not to use that one. But this is a very = different question than saying the RS itself needs to accept my own AS = =E2=80=94 and we can=E2=80=99t keep conflating these two models. >>>>>>>>=20 >>>>>>>> So to me, GNAP can support a Zero Trust Architecture by = LEVERAGING the AS, not by subsuming or eliminating it. It is in fact the = AS, not the client and not the RS, that will request and consume the = results of a privacy-preserving zero-trust policy query thing. Anything = that happens downstream from that is of little concern to the zero-trust = components because, as you point out, it=E2=80=99s on the =E2=80=9Cother = side=E2=80=9D of the line.=20 >>>>>>>>=20 >>>>>>>> I think we got this basic component model pretty right in = OAuth: the AS and RS and client working together. Where OAuth misses the = mark is the assumption that the user has to log in to the AS through a = webpage and interact directly, thereby proving they=E2=80=99re the RO. = It=E2=80=99s this latter space where I think we can both push innovation = and also address the important and compelling use cases like the ones = you=E2=80=99re bringing. >>>>>>>>=20 >>>>>>>> =E2=80=94 Justin >>>>>>>>=20 >>>>>>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper = > wrote: >>>>>>>>>=20 >>>>>>>>> I'm sorry, Justin. As a Resource Owner, I look at the RS trust = boundary (the dotted line in the diagram) as being the RS. I don't = expect any visibility into what's going on on the right.=20 >>>>>>>>>=20 >>>>>>>>> My problem with the framing you propose is that requests are = going to the RS (or the AS-RS) and I don't want to share my policies = with the AS-RS. I want to keep the RS and AS-RS as ignorant as possible. >>>>>>>>>=20 >>>>>>>>> Adrian >>>>>>>>>=20 >>>>>>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer > wrote: >>>>>>>>> Adrian, >>>>>>>>>=20 >>>>>>>>> What you=E2=80=99re discussing below, in terms of logging in = to a site, is not approaching the RS. You are in fact approaching the = client, and identifying both the AS and RS to the client. The client is = a client of your identity in this model, and the RS is part of the = identity provider. It=E2=80=99s really important that we don=E2=80=99t = conflate the RS and client in this way as it leads to a lot of confusion = downstream and a lot of broken trust boundaries. >>>>>>>>>=20 >>>>>>>>> With that model in mind, approaching the =E2=80=9CRS" and = providing it your identity is really just a case of the =E2=80=9Cfederated= login to AS=E2=80=9D pattern that we discussed on the WG call. The user = here approaches an RS, which has its own AS. To share things from this = RS, the RO has to authenticate to the RS=E2=80=99s AS. This particular = AS allows the RO to do so using an external identity =E2=80=94 in which = case, the AS is now a =E2=80=9Cclient=E2=80=9D of a separate, = disconnected (but layered) delegation. The ultimate client that = eventually calls the RS down the way may or may not know about these = layers.=20 >>>>>>>>>=20 >>>>>>>>> >>>>>>>>> This same AS, which is closely tied to the RS and trusted by = the RS, might also take in FIDO credentials, or DIDs, or any number of = other proof mechanisms. The output of this is an access token the RS = trusts, but the input is up to the AS. The RS is not what you=E2=80=99re = logging in to. >>>>>>>>>=20 >>>>>>>>> =E2=80=94 Justin >>>>>>>>>=20 >>>>>>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper = > wrote: >>>>>>>>>>=20 >>>>>>>>>> I too am in favor of avoiding consolidation and correlation. = Right now, when I approach a service provider (RS) for the first time, = I'm offered the opportunity to identify my persona as: email, sign-in = with Google, Facebook, or Apple. I know there are people who try to = create one-off email addresses but that is mostly a waste of time.=20 >>>>>>>>>>=20 >>>>>>>>>> So, along come FIDO2 and DID wallets to the rescue. Now, in = theory, I have a way to start out my RS relationship pseudonymously.=20 >>>>>>>>>>=20 >>>>>>>>>> When I want my resource to be discovered or shared I will = post that RS URL including my pseudonym. If I then want to introduce a = mediator in front of my AS or messaging service endpoint, I have that = option. If I want to keep requests away from the mediator, I would = publish an encryption key along with my pseudonym. >>>>>>>>>>=20 >>>>>>>>>> - Adrian >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer = > wrote: >>>>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk > wrote: >>>>>>>>>> >=20 >>>>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper = wrote: >>>>>>>>>> >> @Alan Karp > shared a talk about the Principle Of Least >>>>>>>>>> >> Authority (POLA) in a recent comment >>>>>>>>>> >> = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment= -803099693 = >>>>>>>>>> >> I recommend it. >>>>>>>>>> >>=20 >>>>>>>>>> >> We might expect a protocol with authorization in the title = to use authority >>>>>>>>>> >> as a core principle. I advocate for a GNAP design that = maximizes the power >>>>>>>>>> >> of the RO, to be seen as a human rights issue when the RO = is a human. This >>>>>>>>>> >> causes me to ask how to combine better security with = better human rights in >>>>>>>>>> >> GNAP. >>>>>>>>>> >>=20 >>>>>>>>>> >> Who should have the least authority in the GNAP design? >>>>>>>>>> >>=20 >>>>>>>>>> >> The AS derives authority as a delegate of the RO. If we = ask the RO to >>>>>>>>>> >> partition limited authority across dozens of different ASs = by domain and >>>>>>>>>> >> function, then we are not using technology to empower the = individual. >>>>>>>>>> >> Probably the opposite, as we introduce consent fatigue and = burden normal >>>>>>>>>> >> people to partition their lives into non-overlapping = domains. >>>>>>>>>> >>=20 >>>>>>>>>> >> My experience says we should aim for one AS per persona = because that maps >>>>>>>>>> >> into the way we manage our public and private identities. = POLA would then >>>>>>>>>> >> teach care in keeping ASs and RSs related to work / public = separate from >>>>>>>>>> >> ASs and RSs related to private life so that a policy = vulnerability in our >>>>>>>>>> >> delegation to an AS would have the least likelihood of = harm. >>>>>>>>>> >=20 >>>>>>>>>> > Thinking about how least authority/least privilege would = apply to GNAP >>>>>>>>>> > seems like a useful exercise. I do want to point out some = potential >>>>>>>>>> > pitfalls with one-AS-per-persona that we can also be aware = of. If >>>>>>>>>> > one-AS-per-persona becomes one-persona-per-AS as well, then = the AS's >>>>>>>>>> > identity in effect also serves as a persona identity and = there are privacy >>>>>>>>>> > considerations to that. If, on the other hand, the >>>>>>>>>> > multiple-personas-per-AS (presumably corresponding to = multiple humans) >>>>>>>>>> > route is taken, we should consider whether that would lead = to various >>>>>>>>>> > (e.g., market) forces driving consolidation to just a = handful of >>>>>>>>>> > super-popular AS services. That topic is a current matter = of concern to >>>>>>>>>> > some IETF participants. >>>>>>>>>> >=20 >>>>>>>>>>=20 >>>>>>>>>> Hi Ben, big +1 to this. This is something that we discussed = ages ago in the UMA working group, and it=E2=80=99s one of the biggest = problems with the personal AS (and personal data store) model. This kind = of thing makes RS-first trust models really difficult in practice. >>>>>>>>>>=20 >>>>>>>>>> As a strawman, let=E2=80=99s say that I=E2=80=99ve got = software that wants to access my medical information. It calls an RS and = requests access, but it hasn=E2=80=99t been granted anything yet. Now I = as the RO have set up the RS so that it talks to my personal AS, that = only I use. In addition to the RS having to be able to figure out which = medical records are being requested from the context of the = unauthenticated request (which means it needs identifiers in the URL or = something similar for the RS to be able to tell, assuming that it = protects data for more than one person). So this client software = doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical record = information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that = protects it. Importantly, this client makes this call with no prior = relationship to the RS and no really auditable way to track it down = after the fact. This is a design feature in the good case, and = terrifying in the bad case. >>>>>>>>>>=20 >>>>>>>>>> If the RS instead says =E2=80=9Cwelcome to Medicine Doctor = RS, please talk to the Medicine Doctor AS to get access=E2=80=9D, we = haven=E2=80=99t exposed anything at all. And from the perspective of = both the patient and the RS, this is more privacy-preserving, and it=E2=80= =99s really the least surprising option. Once the client gets to the AS, = it can start a negotiation of figuring out who the RO is for the = information being accessed. >>>>>>>>>>=20 >>>>>>>>>> On top of this, the usability expectations of people managing = their own AS, or set of AS=E2=80=99s for multiple personas to keep = things separate, is a huge burden. Even in the tech community, I know = people who can=E2=80=99t reliably manage more than one email address for = different purposes. I wouldn=E2=80=99t expect my partner to do that =E2=80= =94 they have trouble enough balancing all the logins and sessions = required for different kids remote schooling, I couldn=E2=80=99t imagine = them having to understand all the requirements for managing multiple = authorization servers and associated policies. I also don=E2=80=99t = expect any person to =E2=80=9Cmanage keys=E2=80=9D =E2=80=94 I=E2=80=99ve = been on the internet for decades and I can barely keep tabs on my GPG = keys, and only use them when I am forced to. This is exactly the kind of = =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions above, = people will just want to outsource that to someone else, and the reality = will be a few popular providers. >>>>>>>>>>=20 >>>>>>>>>> In which case, we could end up doing a ton of work to allow = an RS choice only to end up with a world where the RS ends up making a = limited choice anyway. We see how that plays out with OpenID Connect =E2=80= =94 RP=E2=80=99s could allow arbitrary IdPs but they choose Google = because it works and that=E2=80=99s where the users are. (And that=E2=80=99= s not to say anything of the proprietary OIDC-like protocols, but = that=E2=80=99s another discussion). >>>>>>>>>>=20 >>>>>>>>>> For further reading on these topics, I recommend both =E2=80=9C= Why Johnny Can=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems = Fail=E2=80=9D. >>>>>>>>>>=20 >>>>>>>>>> So what does this have to do with GNAP? I think we can be = clear-eyed on what kinds of expectations we have for the participants. = If we expect users (RO=E2=80=99s) to have to set up the AS-RS = relationship, or expect them to carry their AS, or manage their personal = keys =E2=80=94 I think we=E2=80=99ve lost the battle for relevance. >>>>>>>>>>=20 >>>>>>>>>> =E2=80=94 Justin >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> --=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 = >>>>>>>> --=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 = >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_DBD3EA7C-15CD-4F0D-AD78-6E6F97E06411 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = subject identifier is whatever identifier the AS knows the subject as. = If they log in using only a FIDO token and the AS asserts that key value = as the identifier, then that=E2=80=99s what it will be. If they sign up = with an email address or make a username or get assigned a random = number, that=E2=80=99s what it will be. Or they could sign up using any = number of those and the AS still assigns them a random value, because = it=E2=80=99s always the AS that determines which value to assign the = number. 

    The RS = is not involved in any subject information. Identity APIs, like OpenID = Connect=E2=80=99s UserInfo Endpoint, are out of scope for = GNAP.

    If there = is a subject identifier either included in or referenced by the access = token, that is up to any agreements between the AS and RS that lead to = the ability of the AS to create the tokens the RS can trust. All of this = is outside the scope of the core GNAP protocol and invisible to the = client. 

     =E2=80=94 Justin

    On Mar = 26, 2021, at 1:27 PM, Denis <denis.ietf@free.fr> wrote:

    =20
    Hi Justin,

    Let me rephrase the last question: = How will a RS or a RO be bootstrapped for working with a GNAP "sub" claim or a "sub_id" claim ?

    Denis

    =20 GNAP doesn=E2=80=99t have anything too say about anybody = authenticating directly to the RS. If that happens, it=E2=80=99s out of the view = and out of scope of GNAP.

     =E2=80=94 Justin

    On Mar 26, 2021, at 1:06 PM, Denis <denis.ietf@free.fr> wrote:

    =20
    Hi everybody,

    The content of this thread has nothing to do any more with its original title which was: "Will GNAP support Zero Trust Architecture?"
    Since I am going to use some sentences of this thread to open a new topic, I changed the title of this thread into :
    "Relationship between Authentication and Authorization ?"

    At the moment, I got = the impression that nobody agrees any more about what GNAP is or is not, what it should address and what it should not address.
    The components of the model are becoming more numerous and hazy. A new terminology is sometimes being used, but is not yet present in the last published draft.

    I still can't understand any of the new terms that are being used (AS-RS and AS-RO), which are still left undefined.

    The last exchanges look more as conversations between workers during the construction of the Babel tower.

    Last year, my first remark was to mention that a section or an Annex explaining the common points and the differences with OAuth 2.0
    would be useful. Such section or Annex still does not exist.

    Justin wrote:
    If an = RS allows a username/password HTTP Basic auth in addition to accepting access tokens, it can do so, but
    GNAP doesn=E2=80=99t have = anything to say about the Basic auth use, or even its relation to any access tokens or RO=E2=80=99s or anything = else.
    Let us split the end of this sentence into two parts:

    "GNAP = doesn=E2=80=99t have anything to say about the Basic auth use":  If an authentication exchange  is necessary, the draft document = should describe, for completeness,
    the HTTP error code that will be returned.

    "or even = its relation to any access tokens or RO=E2=80=99s or = anything else". Let us suppose that a RS supports FIDO as an authentication mechanism to authenticate its end-users.
    FIDO provides the major advantage that, for every RS, a different identifier is used by every end-user. This prevents end-users accounts correlations between RSs by using
    such identifiers. In practice, a FIDO identifier is a pseudonym.

    At this very moment, = the RS is able to identify and authenticate its end-users using FIDO pseudonyms. Now, let us raise the following question:

    How will a RS be bootstrapped for working with a GNAP "sub" claim or a "sub_id" claim, whereas FIDO is already being used ?

    Denis


    = Adrian,

    I disagree, I believe that what I = have laid out is exactly separating the concerns into working components. 

    Like OAuth before it, GNAP is a protocol negotiate access for a client instance to an RS, using an AS as the facilitator of that delegated negotiation. (Unlike OAuth, it=E2=80=99s importantly also for negotiating user information to the client directly from the AS with no RS involved, but that=E2=80=99s an aside for the = purposes of our conversation here).

    If a particular GNAP RS also allows other kinds of processes to enable access to it, that is completely fine, but outside of GNAP. If an RS allows a username/password HTTP Basic auth in addition to accepting access tokens, it can do so, but GNAP doesn=E2=80=99t have anything to say = about the Basic auth use, or even its relation to any access tokens or RO=E2=80=99s or anything else. If = an RS accepts structured access tokens signed by trusted keys that don=E2=80=99t come from an AS through a negotiated request =E2=80=94 again, that=E2=80=99s = fine, but GNAP is silent about the RS doing that. If the RS acts as =E2=80=9Cits own AS=E2=80=9D then it=E2=80=99s = really just an RS and an AS living in the same box. Again, that=E2=80=99s = fine, and super common with OAuth today. 

    GNAP is solving the problem of connecting the client to the RS through means of an AS. Other solutions are possible and many of them can be deployed right alongside, but that=E2=80= =99s not the corner of the world that GNAP is solving. GNAP should be concerned about how these other technologies can be used alongside it. I think there=E2=80=99s a lot of room for the things that = you=E2=80=99re talking about, and more importantly for solving the use cases that you=E2=80=99re bringing. But = GNAP should be more than a single-point solution, and so we need to balance these concerns. The conceptual framework of an AS that takes in lots of different information and spits out access tokens is exactly the abstraction layer that is necessary for making these use cases interoperable.

     =E2=80=94 Justin

    On Mar 26, 2021, at 8:30 AM, Adrian Gropper <agropper@healthurl.com> wrote:

    @Justin, = there=E2=80=99s no separation of concerns here. No partition between processor and controller. No data minimization. And, I see no obvious reason to make this the core of GNAP. 

    The one thing = we can probably all agree on is that = there=E2=80=99s only one RS and one RO. 

    The core of = GNAP, in my opinion, can be built and = explained around this simple design. The RS is a processor. The RO is a controller. The RS bears only security responsibility. The RS bears no privacy responsibility. The RO delegates this to the RS but this is not authorization as the A in GNAP.

    The RO retains = all rights to delegate within the scope of things that the RS is willing to support using various token formats and endpoint options. Some of these options may do all sorts of things for all sorts of clients and user-agents  but these are = options. 

    For example, if = a request comes to the RS that is not in the form of an access token, then it either gets sent to the RO or their agent, or it gets logged and dumped. One such option, common in healthcare, is =E2=80=9CBreak = the Glass=E2=80=9D where the RS is acting as an authorization server because the user-agent is making a request instead of presenting an access token. GNAP can offer this as an option but it is not our core.

    Adrian



    On Fri, Mar 26, 2021 at 7:15 AM Justin Richer <jricher@mit.edu> wrote:
    I have a big problem with this line:

    > the RS and AS-RS only see access tokens. The requests (from RO') that resulted in an access token are none of their business.

    In the trust model we=E2=80=99ve = been discussing, the requests that result in access tokens are solely the business of AS-RS, since AS-RS is the only entity that=E2=80=99= s allowed, and trusted by the RS, to create access tokens for the RS. That is its entire job, the entire reason it exists in the system. By definition the party generating tokens for use at the RS is the AS for that RS, I don=E2=80=99t care = how you deploy it. If RO wants to give access to someone else (who isn=E2=80=99= t an =E2=80=9CRO" anymore, they=E2=80=99re = another end-user), then that end user=E2=80=99= s client software will need to talk to AS-RS to get its own access token.

    Now here=E2=80=99s = the trick: when the end user=E2=80=99s client instance talks to AS-RS, that does NOT mean that AS-RS needs to know all the details and policy reasons that it should give an access token to that client instance. It doesn=E2=80=99t even need to know = the existence of another end user. It doesn=E2=80=99t need identity, it = doesn=E2=80=99t need policy. Sure, it COULD handle all of that internally, and many will, but the protocol doesn=E2=80=99= t demand it. 

    This means that the first client instance, the one that gets the access token, can also be given something alongside the access token that it can then hand to another piece of software (or to a person to hand eo their piece of software). This artifact is not an access token. This artifact could be something structured that the client understands, and can make derivatives of, and present back to the AS-RS for getting new access tokens. There could be multiple different flavors of this kind of artifact for different kinds of environments and groups. But what they all have in common is that they can potentially be used to request more access tokens within some context at the = AS-RS.

     =E2=80=94 = Justin



    On Mar 25, 2021, at 5:50 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    =
    My = issue is with = Alan's:
    "7. Another user agent (RO') can contact any holder of the access token or the service's policy agent (AS-RS) to get a delegated access token."

    I = would prefer "7A. Another user agent (RO') can contact any holder of the access token." by default so that the AS-RS does not see the requests. In other words, the RS and AS-RS only see access tokens. The requests (from RO') that resulted in an access token are none of their = business.

    =
    The reality is that RO' can discover a resource RS and can share whatever information with RS-AS they want and the RO may not even know about it unless the RS decides to let them know somehow. This seems to be a drawback of the capabilities = approach. 

    =
    In terms of privacy and control, I, as the RO, want a = contract with the RS that says that I or my agent (AS-RO) must sign an access token. This is a fundamental audit requirement. Without it, a rogue RS and AS-RS can do all sorts of things and the RO would never know. I understand that a rogue RS might not support an honest contemporaneous log of access tokens presented so there's a trust issue here that I seems unavoidable unless I specify in my RO-RS contract that they use a separate = contemporaneous log such as AS-RO for every access token presented and risk being sued if they process an access token without also updating the separate = log.

    =
    - = Adrian


    On Thu, Mar 25, 2021 at 1:22 PM Alan Karp = <alanhkarp@gmail.com> wrote:
    Justin Richer <jricher@mit.edu> wrote:
    Hi= Alan,

    In all of my discussion, and in the spec itself, the RO is the :entity: in charge of approving rights. They=E2=80=99re probably a person. It might be software that makes a policy decision in some way, or a corporate entity, or something like that. But = it=E2=80=99s not assumed to be a computational agent in the terms of the protocol itself. Would that recast what you=E2=80=99= re saying = below?

    Hmmm.  I guess = not.  It's just that the person would be using some UI to express their decisions to what I called the user agent.  = That model fits in very nicely with what we did with Polaris, our virus safe computing environment for Windows XP, https://dl.acm.org/doi/10.1145/1151030.1151033.  The person would click on the icon for a Word file, and an instance of Word would open with only the permission needed to edit that one file.  = Same thing = here.  The client could ask for permission to use the resource, or permission could be granted implicitly when the user selects a resource associated with a specific client.

    = --------------
    Alan = Karp


    On Thu, Mar 25, 2021 at 9:53 AM Justin Richer <jricher@mit.edu> wrote:
    Hi= Alan,

    In all of my discussion, and in the spec itself, the RO is the :entity: in charge of approving rights. They=E2=80=99re probably a person. It might be software that makes a policy decision in some way, or a corporate entity, or something like that. But = it=E2=80=99s not assumed to be a computational agent in the terms of the protocol itself. Would that recast what you=E2=80=99= re saying = below?

     =E2=80=94 Justin

    On Mar 25, 2021, at 12:36 PM, Alan Karp = <alanhkarp@gmail.com> wrote:

    =
    There seems to be some confusion about how AS-RO comes into the picture, probably because of the "AS" = part.  I'm going to try to clear up that confusion by more carefully explaining what I mean.

    I'm assuming that RO is a computational agent representing the person who is the resource owner, something called the "user agent" in operating systems lingo.  = I'm also assuming that it's possible to do delegation, either locally or by token exchange with AS-RS.  = All delegations are potentially sub-scoped, but you may also want to delegate with full scope to have a separately revocable access = token.

      Here's an example of how things work in a capability oriented system.
    =
    1. Someone, the service owner, creates a = service.
    2. The service owner contracts with an policy agent (AS-RS) to create and manage access tokens for that service (RS).
    3. A= person wishing to create a resource at RS uses their user agent (RO) to contact the service owner's policy agent (AS-RS) and gets back an access token for that resource.
    4. That user agent (RO) = can 
      1. use that access token to invoke the resource, = or
      2. delegate an access token to a client of the user agent's (RO) choice, or
      3. contract with a policy agent (AS-RO) to manage those delegations on behalf of the user agent (RO), or
      4. specify a policy with the service's policy agent (AS-RS).
    5. A= client can contact any holder of the access token (the user agent (RO) or its policy agent (AS-RO)) or the service's policy agent (AS-RS) to get a delegated access = token.
    6. That client can delegate that token to another client.
    7. Another user agent (RO') can contact any holder of the access token or the service's policy agent (AS-RS) to get a delegated access = token.
    8. The other user agent (RO') can 
      1. use that access token to invoke the resource, = or
      2. delegate it to a client of its choice, or
      3. contract with a policy agent (AS-RO') of its choosing to manage those delegations on its behalf, = or
      4. specify a policy with the service's policy agent (AS-RS).
    9. and so on
    =
    =
    When any of these computational agents, user agents (ROs) or clients acting on their behalf, invokes the resource, AS-RS verifies that the access token is a valid delegation, i.e., proper sub-scoping, hasn't been revoked, and that it authorizes the request being made before telling the service (RS) to honor the request.  = At no point does the service's policy agent (AS-RS) know which computational agent did any particular = delegation.  (Token exchange can be done as anonymously as = possible.)  In particular, the policy agents (AS-RO) need not be the same, or even compatible with, the service's policy agent (AS-RS).  = GNAP specifies the protocol between requesters, invokers, delegators (for token exchange) of tokens and AS-RS.  = That protocol need not be used between user agents (RO), clients, or other policy agents (AS-RO), but it is likely to be.

     -------------
    Alan Karp


    On Thu, Mar 25, 2021 at 5:45 AM Justin Richer = <jricher@mit.edu> wrote:
    The way I=E2=80=99m thinking about Adrian=E2=80=99s= use case is that what we=E2=80=99= re calling the =E2=80=9CAS-RO=E2= =80=9D isn=E2=80=99t an =E2=80=9CAS=E2= =80=9D in the traditional OAuth/GNAP sense, at least not exactly. This is the agent that the RO can use to set policies and manage consent on their behalf, and I=E2=80=99ve = been arguing that it fits better into this = vaguely-defined =E2=80=9Cinterac= tion component=E2=80=9D= aspect of the current AS definition, and it=E2=80=99s= not currently separated from the AS definition. The = =E2=80=9CAS-RS=E2=80=9D maps to what we=E2=80=99d = call the =E2=80=9CAS=E2=80= =9D in OAuth/GNAP traditionally, it=E2=80=99s = what the RS trusts to issue tokens. In traditional OAuth the AS-RO and AS-RS are always the same thing, from a functional protocol perspective. An important point here is that from a client=E2=80=99s= perspective, they=E2=80=99re = only talking to the AS-RS since that=E2=80=99s = where the client gets its tokens, because at the end of the day the client just wants to call the API at the RS and doesn=E2=80=99t = care how that happens (from a protocol = standpoint). 

    Note well: Even thought I don=E2=80=99t = believe that = =E2=80=9CAS-RO=E2=80=9D is an authorization server at all, I=E2=80=99m = going to keep using that term below for consistency with previous = discussion.

    So we have these fundamental relationships around getting the client to access the = RS:

    1. RS = trusts AS-RS to issue tokens that RS will accept, validate, and process for requests from client
    2. Client = trusts AS-RS to issue tokens that client can use at = RS
    3. RO trusts RS to protect RO=E2=80=99s = api through delegated access

    On top of that, we=E2=80=99ve = got some additional aspects that we=E2=80=99re = discussing:

    4. RO = trusts AS-RO to manage RO=E2=80=99= s policies at runtime
    5. AS-RS trusts AS-RO to assert RO=E2=80=99= s policies for access to = RS
    6. Client trusts whatever AS-RS sends client to deal with, including possibly = RO-AS at runtime, because of = (2)

    What I have been saying is that 4/5/6 are optional details of how RS-AS runs things, and I think this also maps with Adrian=E2=80=99s= view of choice, since if my RS=E2=80=99s = AS-RS doesn=E2=80=99t = allow me to plug in my own AS-RO then I would be motivated to pick a different RS who=E2=80=99s = AS-RS lets me do just that. The same way I=E2=80= =99d pick a different RS if their surrounding services didn=E2=80=99t = accept my preferred federation login and I didn=E2=80=99t = want to make another account. Of course, market forces being as they are, I might not have much of an actionable choice in RS, but GNAP = can=E2=80=99t change = that. 

    What we can do is make it possible for AS-RS to talk to AS-RO, both in philosophy of the protocol design and in concrete hooks to support (6) = above. 

    Separately, we can approach the issue of making 1/2 above more dynamic. This was UMA2=E2=80=99= s =E2=80=9Cfederat= ed = authorization=E2=80=9D approach, and is behind a lot of the =E2=80=9Cbring = your own AS=E2=80=9D = models out there. The problem with these is that we know from many years of experience that most = RS=E2=80=99s aren=E2=80=99t interested in doing anything of the = sort.

    So with GNAP we can instead allow 4/5/6 to vary in a predictable and consistent way, letting the RS keep control over 1/2, thereby enabling choice in (3). We don=E2=80=99t= have to be the ones who define the all of the details of every permutation of (5) to enable this, though. Some of this is going to be configuration out of band, some of it=E2=80= =99s going to be communication at runtime. This is where VC=E2=80=99s, = ZCAPs, CHAPI, DIDComm, FIDO, and a whole swath of other tech can come in and help out. I don=E2=80= =99t think we need to put all the details for using these into core, nor do I think we=E2=80=99ll = pull of The Great And Ultimate Abstraction for using these and other approaches. But we can at least start talking about =E2=80=9CAS-RS=E2= =80=9D in such a way that it no longer assumes it=E2=80=99s = always the same party dealing with the RO directly.

     =E2=80=94 Justin

    On Mar 25, 2021, at 6:40 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    =
    To reframe it closer to GNAP:
    - AS =3D AS-RO, that's where you find the RO policies. The AS issues access tokens to the = client.
    - the RO policies could be a) defined locally or b) in relationship with the = RS

    There have been several ideas related to the AS-RS relationship b:
    b1) the RS issues capabilities (which can be further attenuated by the RO)
    b2) Adrian also discussed a DID based solution
    b3) there was also an alternative ACL proposal from Denis (+ = preflight)

    Fabien


    On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Ok so I get you = correctly: 
    - what matters is the RQ (could be a RO or a end-user or both : we don't really care at a high-level, they're all treated as entities that make a request)
    - the policy is able to handle those different cases, based on its own internal delegation protocol
    - currently that requires AS-RS and AS-RO, but maybe it can be = simplified

    To answer to Denis, here's what I = understood:
    - RO trusts AS-RS (and then handles its own policies within = AS-RO)
    - end-user trusts AS-RO (through its client)

    Could probably work but that's a fairly different model compared to OAuth2 (and of today's GNAP), with different frontiers between the AS and the = RS. 

    Please do not hesitate to correct me if I'm = wrong.

    Fabien 

    On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper = <agropper@healthurl.com> wrote:
    I believe there are alternatives to having two kinds of ASs. The problem may be a side-effect of deciding to switch away form treating the RO as different from the RQ. That leads to downstream privacy issues. Our desire for architectural simplicity is admirable but that may have been a step too far.

    There may also be solutions based on different types of tokens, as in different capabilities (tokens signed by the RS) vs. tokens signed by the AS. = I=E2=80=99m not sure about that but Alan might have more to = say.

    Adrian

    On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Thanks. The general problem statement is clear.

    The proposed solution a bit less (to me). I understood that from point 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obvious reason to have two types of = ASs". Do you see an alternative = ?

    Regarding the last item, I don't think that naming RQ by end-user created the problem. It might just highlight the asymmetry, which fundamentally exists. 

    Fabien


    On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper = <agropper@healthurl.com> wrote:
    Recap:
    1 - Justin (I think) introduced the idea of an AS on the RS trust boundary side.
    2 - I said the RO should not have to share policies with the RS.
    3 - Alan invented the concept of AS-RO and AS-RS to separate two kinds of = PDPs. 

    The thing is that step 2 is not symmetrical. The RO has a legitimate privacy interest in keeping their policies private and minimizing the leakage of information about requests that are posed against those = policies. 

    The RS, on the other hand, should be publishing its policies (e.g. what it=E2=80=99= s selling or what jurisdiction it=E2=80=99s = in or what tokens or scopes it supports). The RS has no obvious privacy interest in GNAP. It=E2=80=99= s just an = enforcer.

    There is one other privacy interest to consider around the RS and that is the requesting party (the end-user that is not the RO :-) might prefer to share attributes with the RS instead of the RO or something controlled by the RO. This case could be an = =E2=80=9Cextension=E2=80=9D to GNAP and might result in a split AS as a solution. This problem was introduced when the editors decided to replace RQ with end-user. Obviously, the RO end-user has no privacy interests relative to itself.

    Adrian




    On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    I was referring to "By my definition, this model has two ASs since both are processing requests into tokens". If there's no reason to have 2 types of ASs, that's fine = then. 
    But I'm a bit lost in where we stand with the = idea. 

    Could you = recap? 

    Fabien 

    Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper = <agropper@healthurl.com> a = =C3=A9crit :
    There=E2=80=99s no obvious reason to have two types of ASs. Any AS that is executing the policies of the RS can look to GNAP like the RS itself. Why would GNAP expose that interface to = anyone? 

    Adrian

    On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Note : I'm not sure that's a good idea, but having 2 types of ASs is not that easy to grasp.

    Fabien 

    Le jeu. 25 mars 2021 =C3=A0 08:07, Fabien Imbault = <fabien.imbault@gmail.com> a = =C3=A9crit :
    The purpose of either handling policies locally or delegating them to the RO = agent. 

    Le jeu. 25 mars 2021 =C3=A0 08:04, Adrian Gropper = <agropper@healthurl.com> a = =C3=A9crit :
    What purpose would be served by GNAP splitting the AS into two = components?

    Adrian 

    On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Isn't the AS-RO a component of the AS? Same idea as the interact component, it functionnally belongs to the AS role but could be deployed either as a monolith or as a separate = component?

    Fabien

    Le jeu. 25 mars 2021 =C3=A0 04:26, Adrian Gropper = <agropper@healthurl.com> a = =C3=A9crit :
    Yes, but I would say it=E2=80=99s= not the RO that wants the access token. It=E2=80=99s = the RO that wants the client making the request to get an access = token. 

    Adrian

    On Wed, Mar 24, 2021 at 11:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Adrian Gropper <agropper@healthurl.com> wrote:

    In this design, the AS is the AS-RS and the agent is the AS-RO. By my definition, this model has two ASs since both are processing requests into tokens. The problem with this is complexity and privacy. The RO may not want to share the request information with the AS-RS.
    =

    More precisely, RO has no choice but to present the required information to AS-RS if RO wants an access = token.  However, RO does not want AS-RS to know the policy by which RO delegates tokens.  That's why RO uses AS-RO for those = delegations.

    = --------------
    Alan = Karp


    On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper = <agropper@healthurl.com> wrote:
    Thank you for creating the issue. My definition of AS is independent of AS-RO or AS-RS. https://github.com/ietf-wg-gnap/gnap-core-protoco= l/issues/223#issuecomment-806280421 I also agree with Alan's definition based on delegation. An AS-RS would be a delegate of the = RS. 

    Based on that, I see it as = obvious that the policy has to be accessible (defined locally?) in order for it to be run as the code that turns a request into an access = token. 

    The only other possibility is that the request is packaged by the AS and sent elsewhere (an agent) for evaluation against policy and a proto-token returned. In that case the AS is acting as a proxy and the PDP is elsewhere. I can imagine that an AS-RS would behave this way so that the proto-token could be turned into an access token by the AS-RS. Isn't this what Justin is proposing? In this design, the AS is the AS-RS and the agent is the AS-RO. By my definition, this model has two ASs since both are processing requests into tokens. The problem with this is complexity and privacy. The RO may not want to share the request information with the AS-RS.

    Adrian

    On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Isn't that what the AS is supposed to be, only with the caveat that the policy is defined locally? 

    Fabien 


    Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp = <alanhkarp@gmail.com> a = =C3=A9crit :
    AS-RO is an AS that RO trusts to delegate RO's access tokens according to RO's = policies.  
    =

    = --------------
    Alan = Karp


    On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Hi Alan and Adrian,

    I've created issue AS-RO policy delegation (https://github.com/ietf-wg-gnap/gnap-core-protoco= l/issues/223) to capture your = input. 
    A first question that arises: can we give a definition to AS-RO?

    Thanks
    Fabien

    On Tue, Mar 23, 2021 at 4:15 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan, 

    Yes, but in that flow, the token relationship between AS-RS and AS-RO is only secure if the tokens issued by AS-RS are = cryptographically attenuable in the first = place. 
     
    =
    Attenuated delegation is a requirement, but that doesn't have to be done = cryptographically.  Token exchange works just fine.  = SPKI and zcap-ld are examples of the crypto approach, and we used token exchange in the system for HP.

    = --------------
    Alan = Karp


    On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Hi Alan, 

    Yes, but in that flow, the token relationship between AS-RS and AS-RO is only secure if the tokens issued by AS-RS are = cryptographically attenuable in the first = place. 

    Fabien

    On Mon, Mar 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin Richer <jricher@mit.edu> wrote:
    =

    But with all that in mind, I think the key here is going to be looking at what the inputs to the AS are, and how those can be defined in an interoperable way for AS=E2=80= =99s that can accept them. I think = there=E2=80=99s a lot of room for innovation and flexibility here that doesn=E2=80=99t = break the trust model or core use cases. If I have an AS-RS set that won=E2=80=99t = accept my favorite flavor of policy engine inputs, then I can decide not to use that one. But this is a very different question than saying the RS itself needs to accept my own AS =E2=80=94= and we can=E2=80=99t= keep conflating these two models.

    I agree.  = The point of having an AS-RO is to allow RO to specify a policy for which of RO's access tokens should be delegated under what = conditions.  AS-RS should not need to understand those = policies.  The flow would = be
    =
    • RO contacts AS-RS and gets one or more access tokens.
    • RO delegates one or more of those tokens, potentially sub-scoped, to AS-RO.
    • A= different user contacts AS-RO to get a potentially sub-scoped access token from = AS-RO.
    • That user presents the access token delegated by AS-RO when invoking the resource.
    =
    AS-RS only needs to verify that the delegation chain is legitimate, e.g., no increase in scope, and that it grants permission for the request being = made.  AS-RS does not need to understand the policy behind granting the delegation by AS-RO.

    = --------------
    Alan = Karp


    On Mon, Mar 22, 2021 at 11:40 AM Justin Richer = <jricher@mit.edu> wrote:
    Adrian,

    I think this shows the problem with the terminology as it=E2=80=99s = been applied in this conversation, which I=E2=80=99= ve tried to shine light on before. What you and others are calling the =E2=80=9CRS=E2= =80=9D is really the = =E2=80=9CAS and RS working together=E2=80=9D= =E2=80=94 everything to the right of the line. When Denis had brought up =E2=80=9Celimina= ting the AS=E2=80=9D = in another thread, what he=E2=80=99d = really done is labeled everything to the right of the line as the =E2=80=9CRS=E2= =80=9D. Of course, the irony here is that everything to the right of the line used all be called the =E2=80=9CAS=E2= =80=9D or simply =E2=80=9Cserver=E2= =80=9D in the OAuth 1 days. As you say below, I don=E2=80=99t = want the client to have visibility on what happens on that = side. 

    Note well: The Google+ logo labeled = =E2=80=9CIdP=E2=80=9D in the diagram is not the AS, as far as GNAP is concerned. It does not issue an access token that the RS will accept. The elements to the left of the line could be a lot of things, but they are NOT the AS =E2=80=94= by definition. The client lives over on the left, but so do any external inputs to the AS. These could be policy inputs on behalf of the RO, they could be presentation artifacts, they could be federated logins, they could be the output of policy decisions. How the AS comes to trust those things is up to the AS=E2=80=99= s = implementation. It=E2=80=99s = something we can talk about, but ultimately GNAP won=E2=80=99= t be in any position to dictate because in practice some AS=E2=80=99s = are simply going to internalize all policies and we will never successfully force those = open. 

    But with all that in mind, I think the key here is going to be looking at what the inputs to the AS are, and how those can be defined in an interoperable way for AS=E2=80= =99s that can accept them. I think = there=E2=80=99s a lot of room for innovation and flexibility here that doesn=E2=80=99t = break the trust model or core use cases. If I have an AS-RS set that won=E2=80=99t = accept my favorite flavor of policy engine inputs, then I can decide not to use that one. But this is a very different question than saying the RS itself needs to accept my own AS =E2=80=94= and we can=E2=80=99t= keep conflating these two models.

    So to me, GNAP can support a Zero Trust Architecture by LEVERAGING the AS, not by subsuming or eliminating it. It is in fact the AS, not the client and not the RS, that will request and consume the results of a = privacy-preserving zero-trust policy query thing. Anything that happens downstream from that is of little concern to the zero-trust components because, as you point out, it=E2=80=99s = on the =E2=80=9Cother = side=E2=80=9D of the = line. 

    I think we got this basic component model pretty right in OAuth: the AS and RS and client working together. Where OAuth misses the mark is the assumption that the user has to log in to the AS through a webpage and interact directly, thereby proving they=E2=80=99re = the RO. It=E2=80=99s= this latter space where I think we can both push innovation and also address the important and compelling use cases like the ones you=E2=80=99re = bringing.

     =E2=80=94 Justin

    On Mar 22, 2021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    =
    I'm sorry, Justin. As a Resource Owner, I look at the RS trust boundary (the dotted line in the diagram) as being the RS. I don't expect any visibility into what's going on on = the right. 

    My problem with the framing you propose is that requests are going to the RS (or the AS-RS) and I don't want to share my policies with the AS-RS. I want to keep the RS and AS-RS as ignorant as = possible.

    Adrian

    On Mon, Mar 22, 2021 at 1:48 PM Justin Richer = <jricher@mit.edu> wrote:
    Adrian,

    What you=E2=80=99re discussing below, in terms of logging in to a site, is not approaching the RS. You are in fact approaching the client, and identifying both the AS and RS to the client. The client is a client of your = identity in this model, and the RS is part of the identity provider. = It=E2=80=99s really important that we don=E2=80=99t= conflate the RS and client in this way as it leads to a lot of confusion downstream and a lot of broken trust = boundaries.

    With that model in mind, approaching the =E2=80=9CRS"= and providing it your identity is really just a case of the =E2=80=9Cfederat= ed login to AS=E2=80= =9D pattern that we discussed on the WG call. The user here approaches an RS, which has its own AS. To share things from this RS, the RO has to authenticate to the RS=E2=80=99= s AS. This particular AS allows the RO to do so using an external identity =E2=80=94= in which case, the AS is now a =E2=80=9Cclien= t=E2=80=9D of a separate, disconnected (but layered) delegation. The ultimate client that eventually calls the RS down the way may or may not know about these = layers. 

    <PastedGraphic-1.png>
    This same AS, which is closely tied to the RS and trusted by the RS, might also take in FIDO credentials, or DIDs, or any number of other proof mechanisms. The output of this is an access token the RS trusts, but the input is up to the AS. The RS is not what you=E2=80=99re = logging in to.

     =E2=80=94 Justin

    On Mar 22, 2021, at 1:28 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    =
    I too am in favor of avoiding consolidation and correlation. Right now, when I approach a service provider (RS) for the first time, I'm offered the opportunity to identify my persona as: email, sign-in with Google, Facebook, or Apple. I know there are people who try to create one-off email addresses but that is mostly a waste of time. 

    So, along come FIDO2 and DID wallets to the rescue. Now, in theory, I have a way to start out my RS relationship = pseudonymously. 

    When I want my resource to be discovered or shared I will post that RS URL including my pseudonym. If I then want to introduce a = mediator in front of my AS or messaging = service endpoint, I have that option. If I want to keep requests away from the mediator, I would publish an encryption key along with my = pseudonym.

    - Adrian



    On Mon, Mar 22, 2021 at 9:55 AM Justin Richer = <jricher@mit.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper = wrote:
    >> @Alan Karp <alanhkarp@gmail.com> shared a talk about the Principle Of Least
    >> Authority (POLA) in a recent = comment
    >> https://github.com/ietf-wg-gnap/gnap-core-protoco= l/issues/145#issuecomment-803099693
    >> I recommend = it.
    >>
    >> We might expect a protocol with authorization in the title to use authority
    >> as a core principle. I advocate for a GNAP design that maximizes the power
    >> of the RO, to be seen as a human rights issue when the RO is a human. This
    >> causes me to ask how to combine better security with better human rights in
    >> = GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO = to
    >> partition limited authority across dozens of different ASs by domain and
    >> function, then we are not using technology to empower the individual.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into = non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because that maps
    >> into the way we manage our public and private identities. POLA would then
    >> teach care in keeping ASs and RSs related to work / public separate = from
    >> ASs and RSs related to private life so that a policy vulnerability in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least = authority/least privilege would apply to GNAP
    > seems like a useful = exercise.  I do want to point out some potential
    > pitfalls with = one-AS-per-persona that we can also be aware of.  = If
    > = one-AS-per-persona becomes = one-persona-per-AS as well, then the AS's
    > identity in effect also serves as a persona identity and there are privacy
    > considerations to that.  = If, on the other hand, the
    > = multiple-personas-per-AS (presumably corresponding to multiple humans)
    > route is taken, we should consider whether that would lead to various
    > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS = services.  That topic is a current matter of concern to
    > some IETF = participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the UMA working group, and it=E2=80=99s= one of the biggest problems with the personal AS (and personal data store) model. This kind of thing makes RS-first trust models really difficult in practice.

    As a strawman, let=E2=80=99s = say that I=E2=80=99ve = got software that wants to access my medical information. It calls an RS and requests access, but it hasn=E2=80=99t = been granted anything yet. Now I as the RO have set up the RS so that it talks to my personal AS, that only I use. In addition to the RS having to be able to figure out which medical records are being requested from the context of the = unauthenticated request (which means it needs identifiers in the URL or something similar for the RS to be able to tell, assuming that it protects data for more than one person). So this client software doesn=E2=80=99t = know who I am and doesn=E2=80=99t = know my medical record information, makes a completely unauthorized request to the RS, and the RS says =E2=80=9CGo= to Justin=E2=80=99s= personal AS to get a = token=E2=80=9D. The client can now make a direct correlation between the data that=E2=80=99= s being protected at the RS and the person running the AS that protects it. Importantly, this client makes this call with no prior relationship to the RS and no really auditable way to track it down after the fact. This is a design feature in the good case, and terrifying in the bad = case.

    If the RS instead says =E2=80=9Cwelcome= to Medicine Doctor RS, please talk to the Medicine Doctor AS to get access=E2=80= =9D, we haven=E2=80=99= t exposed anything at all. And from the perspective of both the patient and the RS, this is more = privacy-preserving, and it=E2=80=99s= really the least surprising option. Once the client gets to the AS, it can start a negotiation of figuring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS, or set of AS=E2=80=99s = for multiple personas to keep things separate, is a huge burden. Even in the tech community, I know people who can=E2=80=99= t reliably manage more than one email address for different purposes. I wouldn=E2=80=99t= expect my partner to do that =E2=80=94 = they have trouble enough balancing all the logins and sessions required for different kids remote schooling, I couldn=E2=80=99t= imagine them having to understand all the requirements for managing multiple authorization servers and associated policies. I also don=E2=80=99= t expect any person to =E2=80=9Cmanage = keys=E2=80=9D =E2=80=94 = I=E2=80=99ve been on the internet for decades and I can barely keep tabs on my GPG keys, and only use them when I am forced to. This is exactly the kind of =E2=80=9Cmarket pressure=E2=80=9D= that I think Ben mentions above, people will just want to outsource that to someone else, and the reality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice only to end up with a world where the RS ends up making a limited choice anyway. We see how that plays out with OpenID Connect =E2=80=94 = RP=E2=80=99s could allow arbitrary IdPs but they choose Google because it works and that=E2=80=99s = where the users are. (And that=E2=80=99= s not to say anything of the proprietary OIDC-like protocols, but that=E2=80=99s = another = discussion).

    For further reading on these topics, I recommend both =E2=80=9CWh= y Johnny Can=E2=80= =99t Encrypt=E2=80=9D= and =E2=80=9CWhy = CSCW Systems = Fail=E2=80=9D.

    So what does this have to do with GNAP? I think we can be clear-eyed on what kinds of expectations we have for the participants. If we expect users (RO=E2=80=99= s) to have to set up the AS-RS relationship, or expect them to carry their AS, or manage their personal keys =E2=80=94 = I think we=E2=80=99ve = lost the battle for relevance.

     =E2=80=94 = Justin


    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= br class=3D"">
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= br class=3D"">
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= br class=3D"">


    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= br class=3D"">







    = --Apple-Mail=_DBD3EA7C-15CD-4F0D-AD78-6E6F97E06411-- From nobody Fri Mar 26 13:24:53 2021 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 E52753A0D58 for ; Fri, 26 Mar 2021 13:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 mnt4CG-PUwTm for ; Fri, 26 Mar 2021 13:24:49 -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 F288B3A0D51 for ; Fri, 26 Mar 2021 13:24:48 -0700 (PDT) Received: from [192.168.1.22] (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 12QKOkqX004062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 26 Mar 2021 16:24:47 -0400 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_6B430942-C458-4EA1-B322-D6CE009C5C37" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <1C29A4EC-CF11-4C49-AB84-D91A0F9D30CD@mit.edu> Date: Fri, 26 Mar 2021 16:24:46 -0400 To: GNAP Mailing List X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [GNAP] Core specification restructuring X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2021 20:24:51 -0000 --Apple-Mail=_6B430942-C458-4EA1-B322-D6CE009C5C37 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 After a long and productive conversation spanning both the mailing list = and the GitHub issue tracker, it seems clear that the overall consensus = is for access tokens to remain opaque to the client instance within the = GNAP protocol, and the use cases asking for a non-opaque access token = are either concerned more with capabilities of the RS or could be = handled by an extension or profile of GNAP. What=E2=80=99s also become = clear is the need for more focused discussion on the relationship that = the RS will have an AS, and how that can be made in a more dynamic = fashion when needed. Additionally, it has also become clear that carry = through OAuth 2=E2=80=99s mindset of =E2=80=9Cthe RO interacts with the = AS=E2=80=9D is too limiting. While the GNAP protocol can already = accommodate other types of consent-and-authorization-gathering = processes, the current draft sticks closely to OAuth 2=E2=80=99s = presentation of a single user interacting with a server, usually through = a web page at that server.=20 To help fix this, the editors are going to take the following actions: - The current section 4 (interaction at the AS) will be rewritten to = accommodate the more wide set of capabilities that GNAP enables, = especially in light of the syntax changes around start/finish/hints that = we have there now. (see = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/224 = ) - The current section 10 (resource servers) will be extracted into a = companion document, along with whatever other pieces of the core are = best fit for that. This document might end up being a separate = publication, or the working group can always opt to merge things back in = at a later date. For now, facilitating the discussion will be helped by = having separate targets to focus on. (See = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/114 = ) Please be on the lookout for PRs to execute these changes in the = near-ish future. Thank you to everyone who=E2=80=99s been participating and pushing the = conversation! Your editorial team, - Justin, Aaron, and Fabien= --Apple-Mail=_6B430942-C458-4EA1-B322-D6CE009C5C37 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 After= a long and productive conversation spanning both the mailing list and = the GitHub issue tracker, it seems clear that the overall consensus is = for access tokens to remain opaque to the client instance within the = GNAP protocol, and the use cases asking for a non-opaque access token = are either concerned more with capabilities of the RS or could be = handled by an extension or profile of GNAP. What=E2=80=99s also become = clear is the need for more focused discussion on the relationship that = the RS will have an AS, and how that can be made in a more dynamic = fashion when needed. Additionally, it has also become clear that carry = through OAuth 2=E2=80=99s mindset of =E2=80=9Cthe RO interacts with the = AS=E2=80=9D is too limiting. While the GNAP protocol can already = accommodate other types of consent-and-authorization-gathering = processes, the current draft sticks closely to OAuth 2=E2=80=99s = presentation of a single user interacting with a server, usually through = a web page at that server. 

    To help = fix this, the editors are going to take the following actions:

    - The current section 4 (interaction at the = AS) will be rewritten to accommodate the more wide set of capabilities = that GNAP enables, especially in light of the syntax changes around = start/finish/hints that we have there now. (see https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/224)
    - The current section 10 (resource servers) will be = extracted into a companion document, along with whatever other pieces of = the core are best fit for that. This document might end up being a = separate publication, or the working group can always opt to merge = things back in at a later date. For now, facilitating the discussion = will be helped by having separate targets to focus on. (See     https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/114)

    Please be on the lookout for PRs to = execute these changes in the near-ish future.

    Thank you to everyone who=E2=80=99s been participating and = pushing the conversation!

    Your editorial team,
     - Justin, = Aaron, and Fabien
    = --Apple-Mail=_6B430942-C458-4EA1-B322-D6CE009C5C37-- From nobody Sun Mar 28 00:51:55 2021 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 ED91A3A1064 for ; Sun, 28 Mar 2021 00:51:49 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=RajGiLY1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CqlTM17G 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 XdCvZs_dGRk1 for ; Sun, 28 Mar 2021 00:51:44 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5262C3A1067 for ; Sun, 28 Mar 2021 00:51:44 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id CFF925C00D5 for ; Sun, 28 Mar 2021 03:42:33 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 28 Mar 2021 03:42:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=mod0dOE4L+q/H58NiPbkSmvX1lFRTQeVRkwaL5MjaUw=; b=RajGiLY1 EsoDNr+835LYrTi9X73axiww+/xqnVPJ4uqsA6j5n9fgtwpPCGL5MX6WhJl2MMdy yP4oDnumJpSG3YtId1IbsXgaAAJwfXHNdpmcF3k82SBe8PpLhA2QBEqVoyk9oJgw AqAeLeYtabXMRWXKtuHDBDmJJkfHjhGYbZhmyM/xzpmZcq65aQ7eRLEK1ZbxkSSC fWDHQSHxMWFgh7ru1xlR4rVTLFCr9Bzt14WnulLuzEeWXCYKfVUx0A1XZRUJ9s7/ DhvRspS3b7aQt/45c3MMUeDHL6/ivnkkkl13qqcY4htUgRrxCZI5zq7w7ZN7ySxa wLJdvwtbtZ0zqw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=mod0dOE4L+q/H58NiPbkSmvX1lFRT QeVRkwaL5MjaUw=; b=CqlTM17G5L88zptJOipjJ22cstPxxF8rkkFwiQeTFJhp4 vPMUtzLjhJySfQCuLiKU6n9Wtj/ncdGc7U7jDnTSvu8G7sy82B7dUqOEcFqG6HeL HD7Q0KB4B8cvssmkJ60B+hvC69bkNOiP0nu4KuNgq96taG76VOMn6mMXtQhqHevg YoxIrl34dKe+4p65WoUqFyMgf+3gdcogOI0Ww53ddv71s3VkggTqW2onRRSJFSFC YgAx2RSvgpkxFvsfOZu6yFTFTMQPXMlOY32WUuoGHyDL0r4FyKHxc1e8fn2HzGyi bVHb7hg5AHoRkhxZWlPWIORg82OjVB6AQmjFPHXbw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudehhedguddutdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeehvddrudeijedrudeivd drjeefnecuvehluhhsthgvrhfuihiivgepjeenucfrrghrrghmpehmrghilhhfrhhomhep ughopghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az186-764.internal.cloudapp.net (unknown [52.167.162.73]) by mail.messagingengine.com (Postfix) with ESMTPA id 6F93724005A for ; Sun, 28 Mar 2021 03:42:33 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============8197198238912621119==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20210328074233.6F93724005A@mailuser.nyi.internal> Date: Sun, 28 Mar 2021 03:42:33 -0400 (EDT) Archived-At: Subject: [GNAP] Weekly github digest (GNAP Weekly GitHub Activity Summary) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2021 07:51:50 -0000 --===============8197198238912621119== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * ietf-wg-gnap/core-protocol (+3/-1/=F0=9F=92=AC74) 3 issues created: - Expand "user interaction" discussion (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/224=20 - AS-RO policy delegation (by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223=20 - paramaters x5c and x5t#S256 and GNAP key formats (by adeinega) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/222=20 12 issues received 74 new comments: - #223 AS-RO policy delegation (9 by Denisthemalice, agropper, fimbault, = jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223=20 - #222 paramaters x5c and x5t#S256 and GNAP key formats (5 by IDmachines,= fimbault, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/222=20 - #221 DID as identifier (2 by fimbault, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/221=20 - #215 User choice and consent, and user notice (5 by Denisthemalice, agr= opper, jricher, smartopian) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/215=20 - #214 Trust relationships (9 by Denisthemalice, fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/214=20 - #203 Requesting resources with insufficient access (2 by Denisthemalice= , fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/203=20 - #145 Opaque / Non opaque access token (31 by Denisthemalice, agropper, = alanhkarp, fimbault, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145 [Pending = Close]=20 - #115 Token Introspection (2 by adeinega, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/115=20 - #114 Resource Server Section (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/114=20 - #105 Rotation of bound client keys (3 by adeinega, fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/105=20 - #62 Referencing an existing grant request (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/62=20 - #6 Polymorphism (4 by adeinega, fimbault, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/6=20 1 issues closed: - Opaque / Non opaque access token https://github.com/ietf-wg-gnap/gnap-c= ore-protocol/issues/145 [Pending Close]=20 Pull requests ------------- * ietf-wg-gnap/core-protocol (+0/-4/=F0=9F=92=AC0) 4 pull requests merged: - These are examples of not sender-constrained tokens. Hence, the "bound"= v=E2=80=A6 https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/209 [Pending Me= rge]=20 - updated diagrams, included subject-only flow https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/211 [Pending Me= rge]=20 - Minor changes on the language in section "Presenting Access Tokens". https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/208 [Pending Me= rge]=20 - Mnr editorial changes for jws and jwsd https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/207 [Pending Me= rge]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol --===============8197198238912621119== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (GNAP Weekly GitHub Activity Summary)

    Sunday March 28, 2021

    Events without label "editorial"

    Issues

    ietf-wg-gnap/core-protocol (+3/-1/=F0=9F=92=AC74)

    3 issues created:

    12 issues received 74 new comments:

    1 issues closed:

    Pull requests

    ietf-wg-gnap/core-protocol (+0/-4/=F0=9F=92=AC0)

    4 pull requests merged:

    Repositories tracked by this digest:

    --===============8197198238912621119==-- From nobody Mon Mar 29 03:39:12 2021 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 856343A176B for ; Mon, 29 Mar 2021 03:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 0CvW4b5nRpqh for ; Mon, 29 Mar 2021 03:39:02 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767E03A1789 for ; Mon, 29 Mar 2021 03:39:00 -0700 (PDT) Received: from [192.168.1.11] ([90.79.53.231]) by mwinf5d40 with ME id mAeq2400J4zJUWJ03AeqUr; Mon, 29 Mar 2021 12:38:58 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Mon, 29 Mar 2021 12:38:58 +0200 X-ME-IP: 90.79.53.231 To: Justin Richer Cc: txauth@ietf.org References: <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> <5773FA7B-6891-4227-A8CA-2F506909B8CD@mit.edu> <3c103293-56a1-4be5-e2a3-12eb82d13238@free.fr> <91D11E67-34AB-4426-803C-7B5A6F50537F@mit.edu> From: Denis Message-ID: Date: Mon, 29 Mar 2021 12:38:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9A2AB8EF9F419184280F8DE4" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Relationship between Authentication and Authorization ? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2021 10:39:11 -0000 This is a multi-part message in MIME format. --------------9A2AB8EF9F419184280F8DE4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi  Justin, Since your response only deals with the AS, but not the RS nor the RO, it is not a response to my question which was: How will a RS or a RO be bootstrapped for working with a GNAP "sub" claim or a "sub_id" claim ? > The subject identifier is whatever identifier the AS knows the subject > as. If they log in using only a FIDO token and the AS asserts that key > value as the identifier, then that’s what it will be. If they sign up > with an email address or make a username or get assigned a random > number, that’s what it will be. Or they could sign up using any number > of those and the AS still assigns them a random value, because it’s > always the AS that determines which value to assign the number. When looking at Section 3.2 (Access Tokens), the client (and hence the end-user) has currently /no practical way/ to indicate which of its attributes should be placed into an access token, The only reference within Section 3.2 is pointing to the empty Section 12. Among the many examples, there is not a single example that addresses the case of attributes being placed into an access token. Nevertheless, it seems that in your opinion, only the AS, but NOT the client (and hence the end-user), SHALL have control at all of what kind of /subject identifier/ claim will be placed inside the access token. Then after, invoking the postulate "the access token SHALL remain opaque to the client (and hence the end-user)", it seems that in your opinion, the end-user SHALL have no way to verify whether its privacy has been respected. If this is not an architecture built along "spy by design" principles, I don't know what else it might be. It is important to re-read two of the current definitions: *Privilege*: right *or attribute* associated with a subject. *Access Toke*n: data artifact representing a set of rights *a**nd/or attributes*. In the current draft, the case of rights is indeed addressed while *the case of attributes is fully ignored*. > The RS is not involved in any subject information. Identity APIs, like > OpenID Connect’s UserInfo Endpoint, are out of scope for GNAP. Really ? Do you mean that an access token should not contain a "sub" claim nor a "sub_id" claim  and if it does, the RS SHALL ignore such claims ? In the "OAuth Access Token JWT Profile", there is the following sentence in Section 6 (Privacy Considerations) :    This profile mandates the presence of the "sub" claim in every JWT    access token, making it possible for resource servers to rely on that    information for performing tasks such as correlating incoming    requests with /data stored locally for the authenticated principal/. This sentence clearly makes a relationship between the value present in the "sub" claim and "/data stored locally for the //*authenticated *//principal/". However, note that the "OAuth Access Token JWT Profile" fails to allow the client (and hence the end-user) to control his privacy, since the client cannot choose which value will be placed in the "sub" claim and also because access tokens are considered to be opaque for the clients in OAuth. > If there is a subject identifier either included in or referenced by > the access token, that is /up to any agreements between the AS and RS/ > that lead to the ability of the AS to create the tokens the RS can > trust. All of this is outside the scope of the core GNAP protocol and > invisible to the client. You are using the following words "/up to any agreements between the AS and RS/". This mandates prior agreements between ASs and RSs and in such a case the architecture will be non-scalable over the Internet. The trust relationship between a RS and an AS is unilateral: The RS trusts the AS to issue appropriate access tokens corresponding to the requests of its clients. From an end-user point of view, if there cannot be *transparency* because of the access token opacity,**then there cannot be *confidence *about GNAP . Denis >  — Justin > >> On Mar 26, 2021, at 1:27 PM, Denis > > wrote: >> >> Hi Justin, >> >> Let me rephrase the last question: How will a RS or a RO be >> bootstrapped for working with a GNAP "sub" claim or a "sub_id" claim ? >> >> Denis >> >>> GNAP doesn’t have anything too say about anybody authenticating >>> directly to the RS. If that happens, it’s out of the view and out of >>> scope of GNAP. >>> >>>  — Justin >>> >>>> On Mar 26, 2021, at 1:06 PM, Denis >>> > wrote: >>>> >>>> Hi everybody, >>>> >>>> The content of this thread has nothing to do any more with its >>>> original title which was: "Will GNAP support Zero Trust Architecture?" >>>> Since I am going to use some sentences of this thread to open a new >>>> topic, I changed the title of this thread into : >>>> "Relationship between Authentication and Authorization ?" >>>> >>>> At the moment, I got the impression that nobody agrees any more >>>> about *what GNAP is or is not, what it should address and what it >>>> should not address*. >>>> The components of the model are becoming more numerous and hazy. A >>>> new terminology is sometimes being used, but is not yet present in >>>> the last published draft. >>>> >>>> I still can't understand any of the new terms that are being used >>>> (*AS-RS* and *AS-RO*), _which are still left undefined_. >>>> >>>> The last exchanges look more as conversations between workers >>>> during the construction of the Babel tower. >>>> >>>> Last year, my first remark was to mention that a section or an >>>> Annex explaining the common points and the differences with OAuth 2.0 >>>> would be useful. Such section or Annex still does not exist. >>>> >>>> Justin wrote: >>>> >>>> /If an RS allows a username/password HTTP Basic auth in >>>> addition to accepting access tokens, it can do so, but // >>>> //GNAP doesn’t have anything to say about the Basic auth use, >>>> or even its relation to any access tokens or RO’s or anything >>>> else./ >>>> >>>> Let us split the end of this sentence into two parts: >>>> >>>> "/GNAP doesn’t have anything //to say about the Basic auth use/":  >>>> If an authentication exchange  is necessary, the draft document >>>> should describe, for completeness, >>>> the HTTP error code that will be returned. >>>> >>>> "/or even its relation to any access tokens or RO’s or anything >>>> else/". Let us suppose that a RS supports FIDO as an authentication >>>> mechanism to authenticate its end-users. >>>> FIDO provides the major advantage that, for every RS, a different >>>> identifier is used by every end-user. This prevents end-users >>>> accounts correlations between RSs by using >>>> such identifiers. In practice, a FIDO identifier is a pseudonym. >>>> >>>> At this very moment, the RS is able to identify and authenticate >>>> its end-users using FIDO pseudonyms. Now, let us raise the >>>> following question: >>>> >>>> How will a RS be bootstrapped for working with a GNAP "sub" claim >>>> or a "sub_id" claim, whereas FIDO is already being used ? >>>> >>>> Denis >>>> >>>> >>>>> Adrian, >>>>> >>>>> I disagree, I believe that what I have laid out is exactly >>>>> separating the concerns into working components. >>>>> >>>>> Like OAuth before it, GNAP is a protocol negotiate access for a >>>>> client instance to an RS, using an AS as the facilitator of that >>>>> delegated negotiation. (Unlike OAuth, it’s importantly also for >>>>> negotiating user information to the client directly from the AS >>>>> with no RS involved, but that’s an aside for the purposes of our >>>>> conversation here). >>>>> >>>>> If a particular GNAP RS also allows other kinds of processes to >>>>> enable access to it, that is completely fine, but outside of GNAP. >>>>> If an RS allows a username/password HTTP Basic auth in addition to >>>>> accepting access tokens, it can do so, but GNAP doesn’t have >>>>> anything to say about the Basic auth use, or even its relation to >>>>> any access tokens or RO’s or anything else. If an RS accepts >>>>> structured access tokens signed by trusted keys that don’t come >>>>> from an AS through a negotiated request — again, that’s fine, but >>>>> GNAP is silent about the RS doing that. If the RS acts as “its own >>>>> AS” then it’s really just an RS and an AS living in the same box. >>>>> Again, that’s fine, and super common with OAuth today. >>>>> >>>>> GNAP is solving the problem of connecting the client to the RS >>>>> through means of an AS. Other solutions are possible and many of >>>>> them can be deployed right alongside, but that’s not the corner of >>>>> the world that GNAP is solving. GNAP should be concerned about how >>>>> these other technologies can be used alongside it. I think there’s >>>>> a lot of room for the things that you’re talking about, and more >>>>> importantly for solving the use cases that you’re bringing. But >>>>> GNAP should be more than a single-point solution, and so we need >>>>> to balance these concerns. The conceptual framework of an AS that >>>>> takes in lots of different information and spits out access tokens >>>>> is exactly the abstraction layer that is necessary for making >>>>> these use cases interoperable. >>>>> >>>>>  — Justin >>>>> >>>>>> On Mar 26, 2021, at 8:30 AM, Adrian Gropper >>>>>> > wrote: >>>>>> >>>>>> @Justin, there’s no separation of concerns here. No partition >>>>>> between processor and controller. No data minimization. And, I >>>>>> see no obvious reason to make this the core of GNAP. >>>>>> >>>>>> The one thing we can probably all agree on is that there’s only >>>>>> one RS and one RO. >>>>>> >>>>>> The core of GNAP, in my opinion, can be built and explained >>>>>> around this simple design. The RS is a processor. The RO is a >>>>>> controller. The RS bears only security responsibility. The RS >>>>>> bears no privacy responsibility. The RO delegates this to the RS >>>>>> but this is not authorization as the A in GNAP. >>>>>> >>>>>> The RO retains all rights to delegate within the scope of things >>>>>> that the RS is willing to support using various token formats and >>>>>> endpoint options. Some of these options may do all sorts of >>>>>> things for all sorts of clients and user-agents  but these are >>>>>> options. >>>>>> >>>>>> For example, if a request comes to the RS that is not in the form >>>>>> of an access token, then it either gets sent to the RO or their >>>>>> agent, or it gets logged and dumped. One such option, common in >>>>>> healthcare, is “Break the Glass” where the RS is acting as an >>>>>> authorization server because the user-agent is making a request >>>>>> instead of presenting an access token. GNAP can offer this as an >>>>>> option but it is not our core. >>>>>> >>>>>> Adrian >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Mar 26, 2021 at 7:15 AM Justin Richer >>>>> > wrote: >>>>>> >>>>>> I have a big problem with this line: >>>>>> >>>>>> > the RS and AS-RS only see access tokens. The requests (from >>>>>> RO') that resulted in an access token are none of their business. >>>>>> >>>>>> In the trust model we’ve been discussing, the requests that >>>>>> result in access tokens are *solely the business of AS-RS*, >>>>>> since AS-RS is the only entity that’s allowed, and trusted by >>>>>> the RS, to create access tokens for the RS. That is its >>>>>> entire job, the entire reason it exists in the system. By >>>>>> definition the party generating tokens for use at the RS is >>>>>> the AS for that RS, I don’t care how you deploy it. If RO >>>>>> wants to give access to someone else (who isn’t an “RO" >>>>>> anymore, they’re another end-user), then that end user’s >>>>>> client software will need to talk to AS-RS to get its own >>>>>> access token. >>>>>> >>>>>> Now here’s the trick: when the end user’s client instance >>>>>> talks to AS-RS, that does NOT mean that AS-RS needs to know >>>>>> all the details and policy reasons that it should give an >>>>>> access token to that client instance. It doesn’t even need to >>>>>> know the existence of another end user. It doesn’t need >>>>>> identity, it doesn’t need policy. Sure, it COULD handle all >>>>>> of that internally, and many will, but the protocol doesn’t >>>>>> demand it. >>>>>> >>>>>> This means that the first client instance, the one that gets >>>>>> the access token, can also be given something alongside the >>>>>> access token that it can then hand to another piece of >>>>>> software (or to a person to hand eo their piece of software). >>>>>> This artifact is not an access token. This artifact could be >>>>>> something structured that the client understands, and can >>>>>> make derivatives of, and present back to the AS-RS for >>>>>> getting new access tokens. There could be multiple different >>>>>> flavors of this kind of artifact for different kinds of >>>>>> environments and groups. But what they all have in common is >>>>>> that they can potentially be used to request more access >>>>>> tokens within some context at the AS-RS. >>>>>> >>>>>>  — Justin >>>>>> >>>>>> >>>>>> >>>>>>> On Mar 25, 2021, at 5:50 PM, Adrian Gropper >>>>>>> > wrote: >>>>>>> >>>>>>> My issue is with Alan's: >>>>>>> >>>>>>> "7. Another user agent (RO') can contact any holder of >>>>>>> the access token or the service's policy agent (AS-RS) >>>>>>> to get a delegated access token." >>>>>>> >>>>>>> >>>>>>> I would prefer "7A.Another user agent (RO') can contact any >>>>>>> holder of the access token." by default so that the AS-RS >>>>>>> does not see the requests. In other words, the RS and AS-RS >>>>>>> only see access tokens. The requests (from RO') that >>>>>>> resulted in an access token are none of their business. >>>>>>> >>>>>>> The reality is that RO' can discover a resource RS and can >>>>>>> share whatever information with RS-AS they want and the RO >>>>>>> may not even know about it unless the RS decides to let them >>>>>>> know somehow. This seems to be a drawback of the >>>>>>> capabilities approach. >>>>>>> >>>>>>> In terms of privacy and control, I, as the RO, want a >>>>>>> contract with the RS that says that I or my agent (AS-RO) >>>>>>> must sign an access token. This is a fundamental audit >>>>>>> requirement. Without it, a rogue RS and AS-RS can do all >>>>>>> sorts of things and the RO would never know. I understand >>>>>>> that a rogue RS might not support an honest contemporaneous >>>>>>> log of access tokens presented so there's a trust issue here >>>>>>> that I seems unavoidable unless I specify in my RO-RS >>>>>>> contract that they use a separate contemporaneous log such >>>>>>> as AS-RO for every access token presented and risk being >>>>>>> sued if they process an access token without also updating >>>>>>> the separate log. >>>>>>> >>>>>>> - Adrian >>>>>>> >>>>>>> >>>>>>> On Thu, Mar 25, 2021 at 1:22 PM Alan Karp >>>>>>> > wrote: >>>>>>> >>>>>>> Justin Richer > >>>>>>> wrote: >>>>>>> >>>>>>> Hi Alan, >>>>>>> >>>>>>> In all of my discussion, and in the spec itself, the >>>>>>> RO is the :entity: in charge of approving rights. >>>>>>> They’re probably a person. It might be software that >>>>>>> makes a policy decision in some way, or a corporate >>>>>>> entity, or something like that. But it’s not assumed >>>>>>> to be a computational agent in the terms of the >>>>>>> protocol itself. Would that recast what you’re >>>>>>> saying below? >>>>>>> >>>>>>> >>>>>>> Hmmm. I guess not. It's just that the person would be >>>>>>> using some UI to express their decisions to what I >>>>>>> called the user agent.  That model fits in very nicely >>>>>>> with what we did with Polaris, our virus safe computing >>>>>>> environment for Windows XP, >>>>>>> https://dl.acm.org/doi/10.1145/1151030.1151033 >>>>>>> . The >>>>>>> person would click on the icon for a Word file, and an >>>>>>> instance of Word would open with only the permission >>>>>>> needed to edit that one file.  Same thing here. The >>>>>>> client could ask for permission to use the resource, or >>>>>>> permission could be granted implicitly when the user >>>>>>> selects a resource associated with a specific client. >>>>>>> >>>>>>> -------------- >>>>>>> Alan Karp >>>>>>> >>>>>>> >>>>>>> On Thu, Mar 25, 2021 at 9:53 AM Justin Richer >>>>>>> > wrote: >>>>>>> >>>>>>> Hi Alan, >>>>>>> >>>>>>> In all of my discussion, and in the spec itself, the >>>>>>> RO is the :entity: in charge of approving rights. >>>>>>> They’re probably a person. It might be software that >>>>>>> makes a policy decision in some way, or a corporate >>>>>>> entity, or something like that. But it’s not assumed >>>>>>> to be a computational agent in the terms of the >>>>>>> protocol itself. Would that recast what you’re >>>>>>> saying below? >>>>>>> >>>>>>>  — Justin >>>>>>> >>>>>>>> On Mar 25, 2021, at 12:36 PM, Alan Karp >>>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>> There seems to be some confusion about how AS-RO >>>>>>>> comes into the picture, probably because of the >>>>>>>> "AS" part. I'm going to try to clear up that >>>>>>>> confusion by more carefully explaining what I mean. >>>>>>>> >>>>>>>> I'm assuming that RO is a computational agent >>>>>>>> representing the person who is the resource owner, >>>>>>>> something called the "user agent" in operating >>>>>>>> systems lingo.  I'm also assuming that it's >>>>>>>> possible to do delegation, either locally or by >>>>>>>> token exchange with AS-RS.  All delegations are >>>>>>>> potentially sub-scoped, but you may also want to >>>>>>>> delegate with full scope to have a separately >>>>>>>> revocable access token. >>>>>>>> >>>>>>>> Here's an example of how things work in a >>>>>>>> capability oriented system. >>>>>>>> >>>>>>>> 1. Someone, the service owner, creates a service. >>>>>>>> 2. The service owner contracts with an policy >>>>>>>> agent (AS-RS) to create and manage access >>>>>>>> tokens for that service (RS). >>>>>>>> 3. A person wishing to create a resource at RS >>>>>>>> uses their user agent (RO) to contact the >>>>>>>> service owner's policy agent (AS-RS) and gets >>>>>>>> back an access token for that resource. >>>>>>>> 4. That user agent (RO) can >>>>>>>> 1. use that access token to invoke the >>>>>>>> resource, or >>>>>>>> 2. delegate an access token to a client of the >>>>>>>> user agent's (RO) choice, or >>>>>>>> 3. contract with a policy agent (AS-RO) to >>>>>>>> manage those delegations on behalf of the >>>>>>>> user agent (RO), or >>>>>>>> 4. specify a policy with the service's policy >>>>>>>> agent (AS-RS). >>>>>>>> 5. A client can contact any holder of the access >>>>>>>> token (the user agent (RO) or its policy agent >>>>>>>> (AS-RO)) or the service's policy agent (AS-RS) >>>>>>>> to get a delegated access token. >>>>>>>> 6. That client can delegate that token to another >>>>>>>> client. >>>>>>>> 7. Another user agent (RO') can contact any holder >>>>>>>> of the access token or the service's policy >>>>>>>> agent (AS-RS) to get a delegated access token. >>>>>>>> 8. The other user agent (RO') can >>>>>>>> 1. use that access token to invoke the >>>>>>>> resource, or >>>>>>>> 2. delegate it to a client of its choice, or >>>>>>>> 3. contract with a policy agent (AS-RO') of >>>>>>>> its choosing to manage those delegations on >>>>>>>> its behalf, or >>>>>>>> 4. specify a policy with the service's policy >>>>>>>> agent (AS-RS). >>>>>>>> 9. and so on >>>>>>>> >>>>>>>> When any of these computational agents, user agents >>>>>>>> (ROs) or clients acting on their behalf, invokes >>>>>>>> the resource, AS-RS verifies that the access token >>>>>>>> is a valid delegation, i.e., proper sub-scoping, >>>>>>>> hasn't been revoked, and that it authorizes the >>>>>>>> request being made before telling the service (RS) >>>>>>>> to honor the request.  At no point does the >>>>>>>> service's policy agent (AS-RS) know which >>>>>>>> computational agent did any particular delegation. >>>>>>>> (Token exchange can be done as anonymously as >>>>>>>> possible.)  In particular, the policy agents >>>>>>>> (AS-RO) need not be the same, or even compatible >>>>>>>> with, the service's policy agent (AS-RS).  GNAP >>>>>>>> specifies the protocol between requesters, >>>>>>>> invokers, delegators (for token exchange) of tokens >>>>>>>> and AS-RS.  That protocol need not be used between >>>>>>>> user agents (RO), clients, or other policy agents >>>>>>>> (AS-RO), but it is likely to be. >>>>>>>> >>>>>>>>  ------------- >>>>>>>> Alan Karp >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Mar 25, 2021 at 5:45 AM Justin Richer >>>>>>>> > wrote: >>>>>>>> >>>>>>>> The way I’m thinking about Adrian’s use case is >>>>>>>> that what we’re calling the “AS-RO” isn’t an >>>>>>>> “AS” in the traditional OAuth/GNAP sense, at >>>>>>>> least not exactly. This is the agent that the >>>>>>>> RO can use to set policies and manage consent >>>>>>>> on their behalf, and I’ve been arguing that it >>>>>>>> fits better into this vaguely-defined >>>>>>>> “interaction component” aspect of the current >>>>>>>> AS definition, and it’s not currently separated >>>>>>>> from the AS definition. The “AS-RS” maps to >>>>>>>> what we’d call the “AS” in OAuth/GNAP >>>>>>>> traditionally, it’s what the RS trusts to issue >>>>>>>> tokens. In traditional OAuth the AS-RO and >>>>>>>> AS-RS are always the same thing, from a >>>>>>>> functional protocol perspective. An important >>>>>>>> point here is that from a client’s perspective, >>>>>>>> they’re only talking to the AS-RS since that’s >>>>>>>> where the client gets its tokens, because at >>>>>>>> the end of the day the client just wants to >>>>>>>> call the API at the RS and doesn’t care how >>>>>>>> that happens (from a protocol standpoint). >>>>>>>> >>>>>>>> Note well: Even thought I don’t believe that >>>>>>>> “AS-RO” is an authorization server at all, I’m >>>>>>>> going to keep using that term below for >>>>>>>> consistency with previous discussion. >>>>>>>> >>>>>>>> So we have these fundamental relationships >>>>>>>> around getting the client to access the RS: >>>>>>>> >>>>>>>> 1. RS trusts AS-RS to issue tokens that RS will >>>>>>>> accept, validate, and process for requests from >>>>>>>> client >>>>>>>> 2. Client trusts AS-RS to issue tokens that >>>>>>>> client can use at RS >>>>>>>> 3. RO trusts RS to protect RO’s api through >>>>>>>> delegated access >>>>>>>> >>>>>>>> On top of that, we’ve got some additional >>>>>>>> aspects that we’re discussing: >>>>>>>> >>>>>>>> 4. RO trusts AS-RO to manage RO’s policies at >>>>>>>> runtime >>>>>>>> 5. AS-RS trusts AS-RO to assert RO’s policies >>>>>>>> for access to RS >>>>>>>> 6. Client trusts whatever AS-RS sends client to >>>>>>>> deal with, including possibly RO-AS at runtime, >>>>>>>> because of (2) >>>>>>>> >>>>>>>> What I have been saying is that 4/5/6 are >>>>>>>> optional details of how RS-AS runs things, and >>>>>>>> I think this also maps with Adrian’s view of >>>>>>>> choice, since if my RS’s AS-RS doesn’t allow me >>>>>>>> to plug in my own AS-RO then I would be >>>>>>>> motivated to pick a different RS who’s AS-RS >>>>>>>> lets me do just that. The same way I’d pick a >>>>>>>> different RS if their surrounding services >>>>>>>> didn’t accept my preferred federation login and >>>>>>>> I didn’t want to make another account. Of >>>>>>>> course, market forces being as they are, I >>>>>>>> might not have much of an actionable choice in >>>>>>>> RS, but GNAP can’t change that. >>>>>>>> >>>>>>>> What we can do is make it possible for AS-RS to >>>>>>>> talk to AS-RO, both in philosophy of the >>>>>>>> protocol design and in concrete hooks to >>>>>>>> support (6) above. >>>>>>>> >>>>>>>> Separately, we can approach the issue of making >>>>>>>> 1/2 above more dynamic. This was UMA2’s >>>>>>>> “federated authorization” approach, and is >>>>>>>> behind a lot of the “bring your own AS” models >>>>>>>> out there. The problem with these is that we >>>>>>>> know from many years of experience that most >>>>>>>> RS’s aren’t interested in doing anything of the >>>>>>>> sort. >>>>>>>> >>>>>>>> So with GNAP we can instead allow 4/5/6 to vary >>>>>>>> in a predictable and consistent way, letting >>>>>>>> the RS keep control over 1/2, thereby enabling >>>>>>>> choice in (3). We don’t have to be the ones who >>>>>>>> define the all of the details of every >>>>>>>> permutation of (5) to enable this, though. Some >>>>>>>> of this is going to be configuration out of >>>>>>>> band, some of it’s going to be communication at >>>>>>>> runtime. This is where VC’s, ZCAPs, CHAPI, >>>>>>>> DIDComm, FIDO, and a whole swath of other tech >>>>>>>> can come in and help out. I don’t think we need >>>>>>>> to put all the details for using these into >>>>>>>> core, nor do I think we’ll pull of The Great >>>>>>>> And Ultimate Abstraction for using these and >>>>>>>> other approaches. But we can at least start >>>>>>>> talking about “AS-RS” in such a way that it no >>>>>>>> longer assumes it’s always the same party >>>>>>>> dealing with the RO directly. >>>>>>>> >>>>>>>>  — Justin >>>>>>>> >>>>>>>>> On Mar 25, 2021, at 6:40 AM, Fabien Imbault >>>>>>>>> >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> To reframe it closer to GNAP: >>>>>>>>> - AS = AS-RO, that's where you find the RO >>>>>>>>> policies. The AS issues access tokens to the >>>>>>>>> client. >>>>>>>>> - the RO policies could be a) defined locally >>>>>>>>> or b) in relationship with the RS >>>>>>>>> >>>>>>>>> There have been several ideas related to the >>>>>>>>> AS-RS relationship b: >>>>>>>>> b1) the RS issues capabilities (which can be >>>>>>>>> further attenuated by the RO) >>>>>>>>> b2) Adrian also discussed a DID based solution >>>>>>>>> b3) there was also an alternative ACL proposal >>>>>>>>> from Denis (+ preflight) >>>>>>>>> >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault >>>>>>>>> >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> Ok so I get you correctly: >>>>>>>>> - what matters is the RQ (could be a RO or >>>>>>>>> a end-user or both : we don't really care >>>>>>>>> at a high-level, they're all treated as >>>>>>>>> entities that make a request) >>>>>>>>> - the policy is able to handle those >>>>>>>>> different cases, based on its own internal >>>>>>>>> delegation protocol >>>>>>>>> - currently that requires AS-RS and AS-RO, >>>>>>>>> but maybe it can be simplified >>>>>>>>> >>>>>>>>> To answer to Denis, here's what I understood: >>>>>>>>> - RO trusts AS-RS (and then handles its >>>>>>>>> own policies within AS-RO) >>>>>>>>> - end-user trusts AS-RO (through its client) >>>>>>>>> >>>>>>>>> Could probably work but that's a fairly >>>>>>>>> different model compared to OAuth2 (and of >>>>>>>>> today's GNAP), with different frontiers >>>>>>>>> between the AS and the RS. >>>>>>>>> >>>>>>>>> Please do not hesitate to correct me if >>>>>>>>> I'm wrong. >>>>>>>>> >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> On Thu, Mar 25, 2021 at 9:26 AM Adrian >>>>>>>>> Gropper >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> I believe there are alternatives to >>>>>>>>> having two kinds of ASs. The problem >>>>>>>>> may be a side-effect of deciding to >>>>>>>>> switch away form treating the RO as >>>>>>>>> different from the RQ. That leads to >>>>>>>>> downstream privacy issues. Our desire >>>>>>>>> for architectural simplicity is >>>>>>>>> admirable but that may have been a >>>>>>>>> step too far. >>>>>>>>> >>>>>>>>> There may also be solutions based on >>>>>>>>> different types of tokens, as in >>>>>>>>> different capabilities (tokens signed >>>>>>>>> by the RS) vs. tokens signed by the >>>>>>>>> AS. I’m not sure about that but Alan >>>>>>>>> might have more to say. >>>>>>>>> >>>>>>>>> Adrian >>>>>>>>> >>>>>>>>> On Thu, Mar 25, 2021 at 4:15 AM Fabien >>>>>>>>> Imbault >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> Thanks. The general problem >>>>>>>>> statement is clear. >>>>>>>>> >>>>>>>>> The proposed solution a bit less >>>>>>>>> (to me). I understood that from >>>>>>>>> point 2, Alan involves 2 ASs. You >>>>>>>>> said : "There’s no obvious reason >>>>>>>>> to have two types of ASs". Do you >>>>>>>>> see an alternative ? >>>>>>>>> >>>>>>>>> Regarding the last item, I don't >>>>>>>>> think that naming RQ by end-user >>>>>>>>> created the problem. It might just >>>>>>>>> highlight the asymmetry, which >>>>>>>>> fundamentally exists. >>>>>>>>> >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Mar 25, 2021 at 8:48 AM >>>>>>>>> Adrian Gropper >>>>>>>>> >>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Recap: >>>>>>>>> 1 - Justin (I think) >>>>>>>>> introduced the idea of an AS >>>>>>>>> on the RS trust boundary side. >>>>>>>>> 2 - I said the RO should not >>>>>>>>> have to share policies with >>>>>>>>> the RS. >>>>>>>>> 3 - Alan invented the concept >>>>>>>>> of AS-RO and AS-RS to separate >>>>>>>>> two kinds of PDPs. >>>>>>>>> >>>>>>>>> The thing is that step 2 is >>>>>>>>> not symmetrical. The RO has a >>>>>>>>> legitimate privacy interest in >>>>>>>>> keeping their policies private >>>>>>>>> and minimizing the leakage of >>>>>>>>> information about requests >>>>>>>>> that are posed against those >>>>>>>>> policies. >>>>>>>>> >>>>>>>>> The RS, on the other hand, >>>>>>>>> should be publishing its >>>>>>>>> policies (e.g. what it’s >>>>>>>>> selling or what jurisdiction >>>>>>>>> it’s in or what tokens or >>>>>>>>> scopes it supports). The RS >>>>>>>>> has no obvious privacy >>>>>>>>> interest in GNAP. It’s just an >>>>>>>>> enforcer. >>>>>>>>> >>>>>>>>> There is one other privacy >>>>>>>>> interest to consider around >>>>>>>>> the RS and that is the >>>>>>>>> requesting party (the end-user >>>>>>>>> that is not the RO :-) might >>>>>>>>> prefer to share attributes >>>>>>>>> with the RS instead of the RO >>>>>>>>> or something controlled by the >>>>>>>>> RO. This case could be an >>>>>>>>> “extension” to GNAP and might >>>>>>>>> result in a split AS as a >>>>>>>>> solution. This problem was >>>>>>>>> introduced when the editors >>>>>>>>> decided to replace RQ with >>>>>>>>> end-user. Obviously, the RO >>>>>>>>> end-user has no privacy >>>>>>>>> interests relative to itself. >>>>>>>>> >>>>>>>>> Adrian >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Mar 25, 2021 at 3:24 >>>>>>>>> AM Fabien Imbault >>>>>>>>> >>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> I was referring to "By my >>>>>>>>> definition, this model has >>>>>>>>> two ASs since both are >>>>>>>>> processing requests into >>>>>>>>> tokens". If there's no >>>>>>>>> reason to have 2 types of >>>>>>>>> ASs, that's fine then. >>>>>>>>> But I'm a bit lost in >>>>>>>>> where we stand with the idea. >>>>>>>>> >>>>>>>>> Could you recap? >>>>>>>>> >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> Le jeu. 25 mars 2021 à >>>>>>>>> 08:16, Adrian Gropper >>>>>>>>> >>>>>>>> > >>>>>>>>> a écrit : >>>>>>>>> >>>>>>>>> There’s no obvious >>>>>>>>> reason to have two >>>>>>>>> types of ASs. Any AS >>>>>>>>> that is executing the >>>>>>>>> policies of the RS can >>>>>>>>> look to GNAP like the >>>>>>>>> RS itself. Why would >>>>>>>>> GNAP expose that >>>>>>>>> interface to anyone? >>>>>>>>> >>>>>>>>> Adrian >>>>>>>>> >>>>>>>>> On Thu, Mar 25, 2021 >>>>>>>>> at 3:11 AM Fabien >>>>>>>>> Imbault >>>>>>>>> >>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Note : I'm not >>>>>>>>> sure that's a good >>>>>>>>> idea, but having 2 >>>>>>>>> types of ASs is >>>>>>>>> not that easy to >>>>>>>>> grasp. >>>>>>>>> >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> Le jeu. 25 mars >>>>>>>>> 2021 à 08:07, >>>>>>>>> Fabien Imbault >>>>>>>>> >>>>>>>> > >>>>>>>>> a écrit : >>>>>>>>> >>>>>>>>> The purpose of >>>>>>>>> either >>>>>>>>> handling >>>>>>>>> policies >>>>>>>>> locally or >>>>>>>>> delegating >>>>>>>>> them to the RO >>>>>>>>> agent. >>>>>>>>> >>>>>>>>> Le jeu. 25 >>>>>>>>> mars 2021 à >>>>>>>>> 08:04, Adrian >>>>>>>>> Gropper >>>>>>>>> >>>>>>>> > >>>>>>>>> a écrit : >>>>>>>>> >>>>>>>>> What >>>>>>>>> purpose >>>>>>>>> would be >>>>>>>>> served by >>>>>>>>> GNAP >>>>>>>>> splitting >>>>>>>>> the AS >>>>>>>>> into two >>>>>>>>> components? >>>>>>>>> >>>>>>>>> Adrian >>>>>>>>> >>>>>>>>> On Thu, >>>>>>>>> Mar 25, >>>>>>>>> 2021 at >>>>>>>>> 2:59 AM >>>>>>>>> Fabien >>>>>>>>> Imbault >>>>>>>>> >>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Isn't >>>>>>>>> the >>>>>>>>> AS-RO >>>>>>>>> a >>>>>>>>> component >>>>>>>>> of the >>>>>>>>> AS? >>>>>>>>> Same >>>>>>>>> idea >>>>>>>>> as the >>>>>>>>> interact >>>>>>>>> component, >>>>>>>>> it >>>>>>>>> functionnally >>>>>>>>> belongs >>>>>>>>> to the >>>>>>>>> AS >>>>>>>>> role >>>>>>>>> but >>>>>>>>> could >>>>>>>>> be >>>>>>>>> deployed >>>>>>>>> either >>>>>>>>> as a >>>>>>>>> monolith >>>>>>>>> or as >>>>>>>>> a >>>>>>>>> separate >>>>>>>>> component? >>>>>>>>> >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> Le >>>>>>>>> jeu. >>>>>>>>> 25 >>>>>>>>> mars >>>>>>>>> 2021 à >>>>>>>>> 04:26, >>>>>>>>> Adrian >>>>>>>>> Gropper >>>>>>>>> >>>>>>>> > >>>>>>>>> a écrit : >>>>>>>>> >>>>>>>>> Yes, >>>>>>>>> but >>>>>>>>> I >>>>>>>>> would >>>>>>>>> say >>>>>>>>> it’s >>>>>>>>> not >>>>>>>>> the >>>>>>>>> RO >>>>>>>>> that >>>>>>>>> wants >>>>>>>>> the >>>>>>>>> access >>>>>>>>> token. >>>>>>>>> It’s >>>>>>>>> the >>>>>>>>> RO >>>>>>>>> that >>>>>>>>> wants >>>>>>>>> the >>>>>>>>> client >>>>>>>>> making >>>>>>>>> the >>>>>>>>> request >>>>>>>>> to >>>>>>>>> get >>>>>>>>> an >>>>>>>>> access >>>>>>>>> token. >>>>>>>>> >>>>>>>>> >>>>>>>>> Adrian >>>>>>>>> >>>>>>>>> On >>>>>>>>> Wed, >>>>>>>>> Mar >>>>>>>>> 24, >>>>>>>>> 2021 >>>>>>>>> at >>>>>>>>> 11:22 >>>>>>>>> PM >>>>>>>>> Alan >>>>>>>>> Karp >>>>>>>>> >>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Adrian >>>>>>>>> Gropper >>>>>>>>> >>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> In >>>>>>>>> this >>>>>>>>> design, >>>>>>>>> the >>>>>>>>> AS >>>>>>>>> is >>>>>>>>> the >>>>>>>>> AS-RS >>>>>>>>> and >>>>>>>>> the >>>>>>>>> agent >>>>>>>>> is >>>>>>>>> the >>>>>>>>> AS-RO. >>>>>>>>> By >>>>>>>>> my >>>>>>>>> definition, >>>>>>>>> this >>>>>>>>> model >>>>>>>>> has >>>>>>>>> two >>>>>>>>> ASs >>>>>>>>> since >>>>>>>>> both >>>>>>>>> are >>>>>>>>> processing >>>>>>>>> requests >>>>>>>>> into >>>>>>>>> tokens. >>>>>>>>> The >>>>>>>>> problem >>>>>>>>> with >>>>>>>>> this >>>>>>>>> is >>>>>>>>> complexity >>>>>>>>> and >>>>>>>>> privacy. >>>>>>>>> The >>>>>>>>> RO >>>>>>>>> may >>>>>>>>> not >>>>>>>>> want >>>>>>>>> to >>>>>>>>> share >>>>>>>>> the >>>>>>>>> request >>>>>>>>> information >>>>>>>>> with >>>>>>>>> the >>>>>>>>> AS-RS. >>>>>>>>> >>>>>>>>> >>>>>>>>> More >>>>>>>>> precisely, >>>>>>>>> RO >>>>>>>>> has >>>>>>>>> no >>>>>>>>> choice >>>>>>>>> but >>>>>>>>> to >>>>>>>>> present >>>>>>>>> the >>>>>>>>> required >>>>>>>>> information >>>>>>>>> to >>>>>>>>> AS-RS >>>>>>>>> if >>>>>>>>> RO >>>>>>>>> wants >>>>>>>>> an >>>>>>>>> access >>>>>>>>> token. >>>>>>>>> However, >>>>>>>>> RO >>>>>>>>> does >>>>>>>>> not >>>>>>>>> want >>>>>>>>> AS-RS >>>>>>>>> to >>>>>>>>> know >>>>>>>>> the >>>>>>>>> policy >>>>>>>>> by >>>>>>>>> which >>>>>>>>> RO >>>>>>>>> delegates >>>>>>>>> tokens. >>>>>>>>> That's >>>>>>>>> why >>>>>>>>> RO >>>>>>>>> uses >>>>>>>>> AS-RO >>>>>>>>> for >>>>>>>>> those >>>>>>>>> delegations. >>>>>>>>> >>>>>>>>> -------------- >>>>>>>>> Alan >>>>>>>>> Karp >>>>>>>>> >>>>>>>>> >>>>>>>>> On >>>>>>>>> Wed, >>>>>>>>> Mar >>>>>>>>> 24, >>>>>>>>> 2021 >>>>>>>>> at >>>>>>>>> 7:41 >>>>>>>>> PM >>>>>>>>> Adrian >>>>>>>>> Gropper >>>>>>>>> >>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Thank >>>>>>>>> you >>>>>>>>> for >>>>>>>>> creating >>>>>>>>> the >>>>>>>>> issue. >>>>>>>>> My >>>>>>>>> definition >>>>>>>>> of >>>>>>>>> AS >>>>>>>>> is >>>>>>>>> independent >>>>>>>>> of >>>>>>>>> AS-RO >>>>>>>>> or >>>>>>>>> AS-RS. >>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomment-806280421 >>>>>>>>> >>>>>>>>> I >>>>>>>>> also >>>>>>>>> agree >>>>>>>>> with >>>>>>>>> Alan's >>>>>>>>> definition >>>>>>>>> based >>>>>>>>> on >>>>>>>>> delegation. >>>>>>>>> An >>>>>>>>> AS-RS >>>>>>>>> would >>>>>>>>> be >>>>>>>>> a >>>>>>>>> delegate >>>>>>>>> of >>>>>>>>> the >>>>>>>>> RS. >>>>>>>>> >>>>>>>>> >>>>>>>>> Based >>>>>>>>> on >>>>>>>>> that, >>>>>>>>> I >>>>>>>>> see >>>>>>>>> it >>>>>>>>> as >>>>>>>>> obvious that >>>>>>>>> the >>>>>>>>> policy >>>>>>>>> has >>>>>>>>> to >>>>>>>>> be >>>>>>>>> accessible >>>>>>>>> (defined >>>>>>>>> locally?) >>>>>>>>> in >>>>>>>>> order >>>>>>>>> for >>>>>>>>> it >>>>>>>>> to >>>>>>>>> be >>>>>>>>> run >>>>>>>>> as >>>>>>>>> the >>>>>>>>> code >>>>>>>>> that >>>>>>>>> turns >>>>>>>>> a >>>>>>>>> request >>>>>>>>> into >>>>>>>>> an >>>>>>>>> access >>>>>>>>> token. >>>>>>>>> >>>>>>>>> >>>>>>>>> The >>>>>>>>> only >>>>>>>>> other >>>>>>>>> possibility >>>>>>>>> is >>>>>>>>> that >>>>>>>>> the >>>>>>>>> request >>>>>>>>> is >>>>>>>>> packaged >>>>>>>>> by >>>>>>>>> the >>>>>>>>> AS >>>>>>>>> and >>>>>>>>> sent >>>>>>>>> elsewhere >>>>>>>>> (an >>>>>>>>> agent) >>>>>>>>> for >>>>>>>>> evaluation >>>>>>>>> against >>>>>>>>> policy >>>>>>>>> and >>>>>>>>> a >>>>>>>>> proto-token >>>>>>>>> returned. >>>>>>>>> In >>>>>>>>> that >>>>>>>>> case >>>>>>>>> the >>>>>>>>> AS >>>>>>>>> is >>>>>>>>> acting >>>>>>>>> as >>>>>>>>> a >>>>>>>>> proxy >>>>>>>>> and >>>>>>>>> the >>>>>>>>> PDP >>>>>>>>> is >>>>>>>>> elsewhere. >>>>>>>>> I >>>>>>>>> can >>>>>>>>> imagine >>>>>>>>> that >>>>>>>>> an >>>>>>>>> AS-RS >>>>>>>>> would >>>>>>>>> behave >>>>>>>>> this >>>>>>>>> way >>>>>>>>> so >>>>>>>>> that >>>>>>>>> the >>>>>>>>> proto-token >>>>>>>>> could >>>>>>>>> be >>>>>>>>> turned >>>>>>>>> into >>>>>>>>> an >>>>>>>>> access >>>>>>>>> token >>>>>>>>> by >>>>>>>>> the >>>>>>>>> AS-RS. >>>>>>>>> Isn't >>>>>>>>> this >>>>>>>>> what >>>>>>>>> Justin >>>>>>>>> is >>>>>>>>> proposing? >>>>>>>>> In >>>>>>>>> this >>>>>>>>> design, >>>>>>>>> the >>>>>>>>> AS >>>>>>>>> is >>>>>>>>> the >>>>>>>>> AS-RS >>>>>>>>> and >>>>>>>>> the >>>>>>>>> agent >>>>>>>>> is >>>>>>>>> the >>>>>>>>> AS-RO. >>>>>>>>> By >>>>>>>>> my >>>>>>>>> definition, >>>>>>>>> this >>>>>>>>> model >>>>>>>>> has >>>>>>>>> two >>>>>>>>> ASs >>>>>>>>> since >>>>>>>>> both >>>>>>>>> are >>>>>>>>> processing >>>>>>>>> requests >>>>>>>>> into >>>>>>>>> tokens. >>>>>>>>> The >>>>>>>>> problem >>>>>>>>> with >>>>>>>>> this >>>>>>>>> is >>>>>>>>> complexity >>>>>>>>> and >>>>>>>>> privacy. >>>>>>>>> The >>>>>>>>> RO >>>>>>>>> may >>>>>>>>> not >>>>>>>>> want >>>>>>>>> to >>>>>>>>> share >>>>>>>>> the >>>>>>>>> request >>>>>>>>> information >>>>>>>>> with >>>>>>>>> the >>>>>>>>> AS-RS. >>>>>>>>> >>>>>>>>> Adrian >>>>>>>>> >>>>>>>>> On >>>>>>>>> Wed, >>>>>>>>> Mar >>>>>>>>> 24, >>>>>>>>> 2021 >>>>>>>>> at >>>>>>>>> 5:21 >>>>>>>>> PM >>>>>>>>> Fabien >>>>>>>>> Imbault >>>>>>>>> >>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Isn't >>>>>>>>> that >>>>>>>>> what >>>>>>>>> the >>>>>>>>> AS >>>>>>>>> is >>>>>>>>> supposed >>>>>>>>> to >>>>>>>>> be, >>>>>>>>> only >>>>>>>>> with >>>>>>>>> the >>>>>>>>> caveat >>>>>>>>> that >>>>>>>>> the >>>>>>>>> policy >>>>>>>>> is >>>>>>>>> defined >>>>>>>>> locally? >>>>>>>>> >>>>>>>>> >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Le >>>>>>>>> mer. >>>>>>>>> 24 >>>>>>>>> mars >>>>>>>>> 2021 >>>>>>>>> à >>>>>>>>> 20:17, >>>>>>>>> Alan >>>>>>>>> Karp >>>>>>>>> >>>>>>>> > >>>>>>>>> a >>>>>>>>> écrit : >>>>>>>>> >>>>>>>>> AS-RO >>>>>>>>> is >>>>>>>>> an >>>>>>>>> AS >>>>>>>>> that >>>>>>>>> RO >>>>>>>>> trusts >>>>>>>>> to >>>>>>>>> delegate >>>>>>>>> RO's >>>>>>>>> access >>>>>>>>> tokens >>>>>>>>> according >>>>>>>>> to >>>>>>>>> RO's >>>>>>>>> policies. >>>>>>>>> >>>>>>>>> >>>>>>>>> -------------- >>>>>>>>> Alan >>>>>>>>> Karp >>>>>>>>> >>>>>>>>> >>>>>>>>> On >>>>>>>>> Wed, >>>>>>>>> Mar >>>>>>>>> 24, >>>>>>>>> 2021 >>>>>>>>> at >>>>>>>>> 9:36 >>>>>>>>> AM >>>>>>>>> Fabien >>>>>>>>> Imbault >>>>>>>>> >>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi >>>>>>>>> Alan >>>>>>>>> and >>>>>>>>> Adrian, >>>>>>>>> >>>>>>>>> >>>>>>>>> I've >>>>>>>>> created >>>>>>>>> issue >>>>>>>>> AS-RO >>>>>>>>> policy >>>>>>>>> delegation >>>>>>>>> (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223 >>>>>>>>> ) >>>>>>>>> to >>>>>>>>> capture >>>>>>>>> your >>>>>>>>> input. >>>>>>>>> >>>>>>>>> A >>>>>>>>> first >>>>>>>>> question >>>>>>>>> that >>>>>>>>> arises: >>>>>>>>> can >>>>>>>>> we >>>>>>>>> give >>>>>>>>> a >>>>>>>>> definition >>>>>>>>> to >>>>>>>>> AS-RO? >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> On >>>>>>>>> Tue, >>>>>>>>> Mar >>>>>>>>> 23, >>>>>>>>> 2021 >>>>>>>>> at >>>>>>>>> 4:15 >>>>>>>>> PM >>>>>>>>> Alan >>>>>>>>> Karp >>>>>>>>> >>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Fabien >>>>>>>>> Imbault >>>>>>>>> >>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi >>>>>>>>> Alan, >>>>>>>>> >>>>>>>>> >>>>>>>>> Yes, >>>>>>>>> but >>>>>>>>> in >>>>>>>>> that >>>>>>>>> flow, >>>>>>>>> the >>>>>>>>> token >>>>>>>>> relationship >>>>>>>>> between >>>>>>>>> AS-RS >>>>>>>>> and >>>>>>>>> AS-RO >>>>>>>>> is >>>>>>>>> only >>>>>>>>> secure >>>>>>>>> if >>>>>>>>> the >>>>>>>>> tokens >>>>>>>>> issued >>>>>>>>> by >>>>>>>>> AS-RS >>>>>>>>> are >>>>>>>>> cryptographically >>>>>>>>> attenuable >>>>>>>>> in >>>>>>>>> the >>>>>>>>> first >>>>>>>>> place. >>>>>>>>> >>>>>>>>> >>>>>>>>> Attenuated >>>>>>>>> delegation >>>>>>>>> is >>>>>>>>> a >>>>>>>>> requirement, >>>>>>>>> but >>>>>>>>> that >>>>>>>>> doesn't >>>>>>>>> have >>>>>>>>> to >>>>>>>>> be >>>>>>>>> done >>>>>>>>> cryptographically. >>>>>>>>> Token >>>>>>>>> exchange >>>>>>>>> works >>>>>>>>> just >>>>>>>>> fine.  >>>>>>>>> SPKI >>>>>>>>> and >>>>>>>>> zcap-ld >>>>>>>>> are >>>>>>>>> examples >>>>>>>>> of >>>>>>>>> the >>>>>>>>> crypto >>>>>>>>> approach, >>>>>>>>> and >>>>>>>>> we >>>>>>>>> used >>>>>>>>> token >>>>>>>>> exchange >>>>>>>>> in >>>>>>>>> the >>>>>>>>> system >>>>>>>>> for >>>>>>>>> HP. >>>>>>>>> >>>>>>>>> -------------- >>>>>>>>> Alan >>>>>>>>> Karp >>>>>>>>> >>>>>>>>> >>>>>>>>> On >>>>>>>>> Tue, >>>>>>>>> Mar >>>>>>>>> 23, >>>>>>>>> 2021 >>>>>>>>> at >>>>>>>>> 4:12 >>>>>>>>> AM >>>>>>>>> Fabien >>>>>>>>> Imbault >>>>>>>>> >>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi >>>>>>>>> Alan, >>>>>>>>> >>>>>>>>> >>>>>>>>> Yes, >>>>>>>>> but >>>>>>>>> in >>>>>>>>> that >>>>>>>>> flow, >>>>>>>>> the >>>>>>>>> token >>>>>>>>> relationship >>>>>>>>> between >>>>>>>>> AS-RS >>>>>>>>> and >>>>>>>>> AS-RO >>>>>>>>> is >>>>>>>>> only >>>>>>>>> secure >>>>>>>>> if >>>>>>>>> the >>>>>>>>> tokens >>>>>>>>> issued >>>>>>>>> by >>>>>>>>> AS-RS >>>>>>>>> are >>>>>>>>> cryptographically >>>>>>>>> attenuable >>>>>>>>> in >>>>>>>>> the >>>>>>>>> first >>>>>>>>> place. >>>>>>>>> >>>>>>>>> >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> On >>>>>>>>> Mon, >>>>>>>>> Mar >>>>>>>>> 22, >>>>>>>>> 2021 >>>>>>>>> at >>>>>>>>> 9:26 >>>>>>>>> PM >>>>>>>>> Alan >>>>>>>>> Karp >>>>>>>>> >>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Justin >>>>>>>>> Richer >>>>>>>>> >>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> But >>>>>>>>> with >>>>>>>>> all >>>>>>>>> that >>>>>>>>> in >>>>>>>>> mind, >>>>>>>>> I >>>>>>>>> think >>>>>>>>> the >>>>>>>>> key >>>>>>>>> here >>>>>>>>> is >>>>>>>>> going >>>>>>>>> to >>>>>>>>> be >>>>>>>>> looking >>>>>>>>> at >>>>>>>>> what >>>>>>>>> the >>>>>>>>> inputs >>>>>>>>> to >>>>>>>>> the >>>>>>>>> AS >>>>>>>>> are, >>>>>>>>> and >>>>>>>>> how >>>>>>>>> those >>>>>>>>> can >>>>>>>>> be >>>>>>>>> defined >>>>>>>>> in >>>>>>>>> an >>>>>>>>> interoperable >>>>>>>>> way >>>>>>>>> for >>>>>>>>> AS’s >>>>>>>>> that >>>>>>>>> can >>>>>>>>> accept >>>>>>>>> them. >>>>>>>>> I >>>>>>>>> think >>>>>>>>> there’s >>>>>>>>> a >>>>>>>>> lot >>>>>>>>> of >>>>>>>>> room >>>>>>>>> for >>>>>>>>> innovation >>>>>>>>> and >>>>>>>>> flexibility >>>>>>>>> here >>>>>>>>> that >>>>>>>>> doesn’t >>>>>>>>> break >>>>>>>>> the >>>>>>>>> trust >>>>>>>>> model >>>>>>>>> or >>>>>>>>> core >>>>>>>>> use >>>>>>>>> cases. >>>>>>>>> If >>>>>>>>> I >>>>>>>>> have >>>>>>>>> an >>>>>>>>> AS-RS >>>>>>>>> set >>>>>>>>> that >>>>>>>>> won’t >>>>>>>>> accept >>>>>>>>> my >>>>>>>>> favorite >>>>>>>>> flavor >>>>>>>>> of >>>>>>>>> policy >>>>>>>>> engine >>>>>>>>> inputs, >>>>>>>>> then >>>>>>>>> I >>>>>>>>> can >>>>>>>>> decide >>>>>>>>> not >>>>>>>>> to >>>>>>>>> use >>>>>>>>> that >>>>>>>>> one. >>>>>>>>> But >>>>>>>>> this >>>>>>>>> is >>>>>>>>> a >>>>>>>>> very >>>>>>>>> different >>>>>>>>> question >>>>>>>>> than >>>>>>>>> saying >>>>>>>>> the >>>>>>>>> RS >>>>>>>>> itself >>>>>>>>> needs >>>>>>>>> to >>>>>>>>> accept >>>>>>>>> my >>>>>>>>> own >>>>>>>>> AS >>>>>>>>> — >>>>>>>>> and >>>>>>>>> we >>>>>>>>> can’t >>>>>>>>> keep >>>>>>>>> conflating >>>>>>>>> these >>>>>>>>> two >>>>>>>>> models. >>>>>>>>> >>>>>>>>> I >>>>>>>>> agree.  >>>>>>>>> The >>>>>>>>> point >>>>>>>>> of >>>>>>>>> having >>>>>>>>> an >>>>>>>>> AS-RO >>>>>>>>> is >>>>>>>>> to >>>>>>>>> allow >>>>>>>>> RO >>>>>>>>> to >>>>>>>>> specify >>>>>>>>> a >>>>>>>>> policy >>>>>>>>> for >>>>>>>>> which >>>>>>>>> of >>>>>>>>> RO's >>>>>>>>> access >>>>>>>>> tokens >>>>>>>>> should >>>>>>>>> be >>>>>>>>> delegated >>>>>>>>> under >>>>>>>>> what >>>>>>>>> conditions. >>>>>>>>> AS-RS >>>>>>>>> should >>>>>>>>> not >>>>>>>>> need >>>>>>>>> to >>>>>>>>> understand >>>>>>>>> those >>>>>>>>> policies.  >>>>>>>>> The >>>>>>>>> flow >>>>>>>>> would >>>>>>>>> be >>>>>>>>> >>>>>>>>> * RO >>>>>>>>> contacts >>>>>>>>> AS-RS >>>>>>>>> and >>>>>>>>> gets >>>>>>>>> one >>>>>>>>> or >>>>>>>>> more >>>>>>>>> access >>>>>>>>> tokens. >>>>>>>>> * RO >>>>>>>>> delegates >>>>>>>>> one >>>>>>>>> or >>>>>>>>> more >>>>>>>>> of >>>>>>>>> those >>>>>>>>> tokens, >>>>>>>>> potentially >>>>>>>>> sub-scoped, >>>>>>>>> to >>>>>>>>> AS-RO. >>>>>>>>> * A >>>>>>>>> different >>>>>>>>> user >>>>>>>>> contacts >>>>>>>>> AS-RO >>>>>>>>> to >>>>>>>>> get >>>>>>>>> a >>>>>>>>> potentially >>>>>>>>> sub-scoped >>>>>>>>> access >>>>>>>>> token >>>>>>>>> from >>>>>>>>> AS-RO. >>>>>>>>> * That >>>>>>>>> user >>>>>>>>> presents >>>>>>>>> the >>>>>>>>> access >>>>>>>>> token >>>>>>>>> delegated >>>>>>>>> by >>>>>>>>> AS-RO >>>>>>>>> when >>>>>>>>> invoking >>>>>>>>> the >>>>>>>>> resource. >>>>>>>>> >>>>>>>>> AS-RS >>>>>>>>> only >>>>>>>>> needs >>>>>>>>> to >>>>>>>>> verify >>>>>>>>> that >>>>>>>>> the >>>>>>>>> delegation >>>>>>>>> chain >>>>>>>>> is >>>>>>>>> legitimate, >>>>>>>>> e.g., >>>>>>>>> no >>>>>>>>> increase >>>>>>>>> in >>>>>>>>> scope, >>>>>>>>> and >>>>>>>>> that >>>>>>>>> it >>>>>>>>> grants >>>>>>>>> permission >>>>>>>>> for >>>>>>>>> the >>>>>>>>> request >>>>>>>>> being >>>>>>>>> made. >>>>>>>>> AS-RS >>>>>>>>> does >>>>>>>>> not >>>>>>>>> need >>>>>>>>> to >>>>>>>>> understand >>>>>>>>> the >>>>>>>>> policy >>>>>>>>> behind >>>>>>>>> granting >>>>>>>>> the >>>>>>>>> delegation >>>>>>>>> by >>>>>>>>> AS-RO. >>>>>>>>> >>>>>>>>> -------------- >>>>>>>>> Alan >>>>>>>>> Karp >>>>>>>>> >>>>>>>>> >>>>>>>>> On >>>>>>>>> Mon, >>>>>>>>> Mar >>>>>>>>> 22, >>>>>>>>> 2021 >>>>>>>>> at >>>>>>>>> 11:40 >>>>>>>>> AM >>>>>>>>> Justin >>>>>>>>> Richer >>>>>>>>> >>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Adrian, >>>>>>>>> >>>>>>>>> >>>>>>>>> I >>>>>>>>> think >>>>>>>>> this >>>>>>>>> shows >>>>>>>>> the >>>>>>>>> problem >>>>>>>>> with >>>>>>>>> the >>>>>>>>> terminology >>>>>>>>> as >>>>>>>>> it’s >>>>>>>>> been >>>>>>>>> applied >>>>>>>>> in >>>>>>>>> this >>>>>>>>> conversation, >>>>>>>>> which >>>>>>>>> I’ve >>>>>>>>> tried >>>>>>>>> to >>>>>>>>> shine >>>>>>>>> light >>>>>>>>> on >>>>>>>>> before. >>>>>>>>> What >>>>>>>>> you >>>>>>>>> and >>>>>>>>> others >>>>>>>>> are >>>>>>>>> calling >>>>>>>>> the >>>>>>>>> “RS” >>>>>>>>> is >>>>>>>>> really >>>>>>>>> the >>>>>>>>> “AS >>>>>>>>> and >>>>>>>>> RS >>>>>>>>> working >>>>>>>>> together” >>>>>>>>> — >>>>>>>>> everything >>>>>>>>> to >>>>>>>>> the >>>>>>>>> right >>>>>>>>> of >>>>>>>>> the >>>>>>>>> line. >>>>>>>>> When >>>>>>>>> Denis >>>>>>>>> had >>>>>>>>> brought >>>>>>>>> up >>>>>>>>> “eliminating >>>>>>>>> the >>>>>>>>> AS” >>>>>>>>> in >>>>>>>>> another >>>>>>>>> thread, >>>>>>>>> what >>>>>>>>> he’d >>>>>>>>> really >>>>>>>>> done >>>>>>>>> is >>>>>>>>> labeled >>>>>>>>> everything >>>>>>>>> to >>>>>>>>> the >>>>>>>>> right >>>>>>>>> of >>>>>>>>> the >>>>>>>>> line >>>>>>>>> as >>>>>>>>> the >>>>>>>>> “RS”. >>>>>>>>> Of >>>>>>>>> course, >>>>>>>>> the >>>>>>>>> irony >>>>>>>>> here >>>>>>>>> is >>>>>>>>> that >>>>>>>>> everything >>>>>>>>> to >>>>>>>>> the >>>>>>>>> right >>>>>>>>> of >>>>>>>>> the >>>>>>>>> line >>>>>>>>> used >>>>>>>>> all >>>>>>>>> be >>>>>>>>> called >>>>>>>>> the >>>>>>>>> “AS” >>>>>>>>> or >>>>>>>>> simply >>>>>>>>> “server” >>>>>>>>> in >>>>>>>>> the >>>>>>>>> OAuth >>>>>>>>> 1 >>>>>>>>> days. >>>>>>>>> As >>>>>>>>> you >>>>>>>>> say >>>>>>>>> below, >>>>>>>>> I >>>>>>>>> don’t >>>>>>>>> want >>>>>>>>> the >>>>>>>>> client >>>>>>>>> to >>>>>>>>> have >>>>>>>>> visibility >>>>>>>>> on >>>>>>>>> what >>>>>>>>> happens >>>>>>>>> on >>>>>>>>> that >>>>>>>>> side. >>>>>>>>> >>>>>>>>> >>>>>>>>> Note >>>>>>>>> well: >>>>>>>>> The >>>>>>>>> Google+ >>>>>>>>> logo >>>>>>>>> labeled >>>>>>>>> “IdP” >>>>>>>>> in >>>>>>>>> the >>>>>>>>> diagram >>>>>>>>> is >>>>>>>>> not >>>>>>>>> the >>>>>>>>> AS, >>>>>>>>> as >>>>>>>>> far >>>>>>>>> as >>>>>>>>> GNAP >>>>>>>>> is >>>>>>>>> concerned. >>>>>>>>> It >>>>>>>>> does >>>>>>>>> not >>>>>>>>> issue >>>>>>>>> an >>>>>>>>> access >>>>>>>>> token >>>>>>>>> that >>>>>>>>> the >>>>>>>>> RS >>>>>>>>> will >>>>>>>>> accept. >>>>>>>>> The >>>>>>>>> elements >>>>>>>>> to >>>>>>>>> the >>>>>>>>> left >>>>>>>>> of >>>>>>>>> the >>>>>>>>> line >>>>>>>>> could >>>>>>>>> be >>>>>>>>> a >>>>>>>>> lot >>>>>>>>> of >>>>>>>>> things, >>>>>>>>> but >>>>>>>>> they >>>>>>>>> are >>>>>>>>> NOT >>>>>>>>> the >>>>>>>>> AS >>>>>>>>> — >>>>>>>>> by >>>>>>>>> definition. >>>>>>>>> The >>>>>>>>> client >>>>>>>>> lives >>>>>>>>> over >>>>>>>>> on >>>>>>>>> the >>>>>>>>> left, >>>>>>>>> but >>>>>>>>> so >>>>>>>>> do >>>>>>>>> any >>>>>>>>> external >>>>>>>>> inputs >>>>>>>>> to >>>>>>>>> the >>>>>>>>> AS. >>>>>>>>> These >>>>>>>>> could >>>>>>>>> be >>>>>>>>> policy >>>>>>>>> inputs >>>>>>>>> on >>>>>>>>> behalf >>>>>>>>> of >>>>>>>>> the >>>>>>>>> RO, >>>>>>>>> they >>>>>>>>> could >>>>>>>>> be >>>>>>>>> presentation >>>>>>>>> artifacts, >>>>>>>>> they >>>>>>>>> could >>>>>>>>> be >>>>>>>>> federated >>>>>>>>> logins, >>>>>>>>> they >>>>>>>>> could >>>>>>>>> be >>>>>>>>> the >>>>>>>>> output >>>>>>>>> of >>>>>>>>> policy >>>>>>>>> decisions. >>>>>>>>> How >>>>>>>>> the >>>>>>>>> AS >>>>>>>>> comes >>>>>>>>> to >>>>>>>>> trust >>>>>>>>> those >>>>>>>>> things >>>>>>>>> is >>>>>>>>> up >>>>>>>>> to >>>>>>>>> the >>>>>>>>> AS’s >>>>>>>>> implementation. >>>>>>>>> It’s >>>>>>>>> something >>>>>>>>> we >>>>>>>>> can >>>>>>>>> talk >>>>>>>>> about, >>>>>>>>> but >>>>>>>>> ultimately >>>>>>>>> GNAP >>>>>>>>> won’t >>>>>>>>> be >>>>>>>>> in >>>>>>>>> any >>>>>>>>> position >>>>>>>>> to >>>>>>>>> dictate >>>>>>>>> because >>>>>>>>> in >>>>>>>>> practice >>>>>>>>> some >>>>>>>>> AS’s >>>>>>>>> are >>>>>>>>> simply >>>>>>>>> going >>>>>>>>> to >>>>>>>>> internalize >>>>>>>>> all >>>>>>>>> policies >>>>>>>>> and >>>>>>>>> we >>>>>>>>> will >>>>>>>>> never >>>>>>>>> successfully >>>>>>>>> force >>>>>>>>> those >>>>>>>>> open. >>>>>>>>> >>>>>>>>> >>>>>>>>> But >>>>>>>>> with >>>>>>>>> all >>>>>>>>> that >>>>>>>>> in >>>>>>>>> mind, >>>>>>>>> I >>>>>>>>> think >>>>>>>>> the >>>>>>>>> key >>>>>>>>> here >>>>>>>>> is >>>>>>>>> going >>>>>>>>> to >>>>>>>>> be >>>>>>>>> looking >>>>>>>>> at >>>>>>>>> what >>>>>>>>> the >>>>>>>>> inputs >>>>>>>>> to >>>>>>>>> the >>>>>>>>> AS >>>>>>>>> are, >>>>>>>>> and >>>>>>>>> how >>>>>>>>> those >>>>>>>>> can >>>>>>>>> be >>>>>>>>> defined >>>>>>>>> in >>>>>>>>> an >>>>>>>>> interoperable >>>>>>>>> way >>>>>>>>> for >>>>>>>>> AS’s >>>>>>>>> that >>>>>>>>> can >>>>>>>>> accept >>>>>>>>> them. >>>>>>>>> I >>>>>>>>> think >>>>>>>>> there’s >>>>>>>>> a >>>>>>>>> lot >>>>>>>>> of >>>>>>>>> room >>>>>>>>> for >>>>>>>>> innovation >>>>>>>>> and >>>>>>>>> flexibility >>>>>>>>> here >>>>>>>>> that >>>>>>>>> doesn’t >>>>>>>>> break >>>>>>>>> the >>>>>>>>> trust >>>>>>>>> model >>>>>>>>> or >>>>>>>>> core >>>>>>>>> use >>>>>>>>> cases. >>>>>>>>> If >>>>>>>>> I >>>>>>>>> have >>>>>>>>> an >>>>>>>>> AS-RS >>>>>>>>> set >>>>>>>>> that >>>>>>>>> won’t >>>>>>>>> accept >>>>>>>>> my >>>>>>>>> favorite >>>>>>>>> flavor >>>>>>>>> of >>>>>>>>> policy >>>>>>>>> engine >>>>>>>>> inputs, >>>>>>>>> then >>>>>>>>> I >>>>>>>>> can >>>>>>>>> decide >>>>>>>>> not >>>>>>>>> to >>>>>>>>> use >>>>>>>>> that >>>>>>>>> one. >>>>>>>>> But >>>>>>>>> this >>>>>>>>> is >>>>>>>>> a >>>>>>>>> very >>>>>>>>> different >>>>>>>>> question >>>>>>>>> than >>>>>>>>> saying >>>>>>>>> the >>>>>>>>> RS >>>>>>>>> itself >>>>>>>>> needs >>>>>>>>> to >>>>>>>>> accept >>>>>>>>> my >>>>>>>>> own >>>>>>>>> AS >>>>>>>>> — >>>>>>>>> and >>>>>>>>> we >>>>>>>>> can’t >>>>>>>>> keep >>>>>>>>> conflating >>>>>>>>> these >>>>>>>>> two >>>>>>>>> models. >>>>>>>>> >>>>>>>>> So >>>>>>>>> to >>>>>>>>> me, >>>>>>>>> GNAP >>>>>>>>> can >>>>>>>>> support >>>>>>>>> a >>>>>>>>> Zero >>>>>>>>> Trust >>>>>>>>> Architecture >>>>>>>>> by >>>>>>>>> LEVERAGING >>>>>>>>> the >>>>>>>>> AS, >>>>>>>>> not >>>>>>>>> by >>>>>>>>> subsuming >>>>>>>>> or >>>>>>>>> eliminating >>>>>>>>> it. >>>>>>>>> It >>>>>>>>> is >>>>>>>>> in >>>>>>>>> fact >>>>>>>>> the >>>>>>>>> AS, >>>>>>>>> not >>>>>>>>> the >>>>>>>>> client >>>>>>>>> and >>>>>>>>> not >>>>>>>>> the >>>>>>>>> RS, >>>>>>>>> that >>>>>>>>> will >>>>>>>>> request >>>>>>>>> and >>>>>>>>> consume >>>>>>>>> the >>>>>>>>> results >>>>>>>>> of >>>>>>>>> a >>>>>>>>> privacy-preserving >>>>>>>>> zero-trust >>>>>>>>> policy >>>>>>>>> query >>>>>>>>> thing. >>>>>>>>> Anything >>>>>>>>> that >>>>>>>>> happens >>>>>>>>> downstream >>>>>>>>> from >>>>>>>>> that >>>>>>>>> is >>>>>>>>> of >>>>>>>>> little >>>>>>>>> concern >>>>>>>>> to >>>>>>>>> the >>>>>>>>> zero-trust >>>>>>>>> components >>>>>>>>> because, >>>>>>>>> as >>>>>>>>> you >>>>>>>>> point >>>>>>>>> out, >>>>>>>>> it’s >>>>>>>>> on >>>>>>>>> the >>>>>>>>> “other >>>>>>>>> side” >>>>>>>>> of >>>>>>>>> the >>>>>>>>> line. >>>>>>>>> >>>>>>>>> >>>>>>>>> I >>>>>>>>> think >>>>>>>>> we >>>>>>>>> got >>>>>>>>> this >>>>>>>>> basic >>>>>>>>> component >>>>>>>>> model >>>>>>>>> pretty >>>>>>>>> right >>>>>>>>> in >>>>>>>>> OAuth: >>>>>>>>> the >>>>>>>>> AS >>>>>>>>> and >>>>>>>>> RS >>>>>>>>> and >>>>>>>>> client >>>>>>>>> working >>>>>>>>> together. >>>>>>>>> Where >>>>>>>>> OAuth >>>>>>>>> misses >>>>>>>>> the >>>>>>>>> mark >>>>>>>>> is >>>>>>>>> the >>>>>>>>> assumption >>>>>>>>> that >>>>>>>>> the >>>>>>>>> user >>>>>>>>> has >>>>>>>>> to >>>>>>>>> log >>>>>>>>> in >>>>>>>>> to >>>>>>>>> the >>>>>>>>> AS >>>>>>>>> through >>>>>>>>> a >>>>>>>>> webpage >>>>>>>>> and >>>>>>>>> interact >>>>>>>>> directly, >>>>>>>>> thereby >>>>>>>>> proving >>>>>>>>> they’re >>>>>>>>> the >>>>>>>>> RO. >>>>>>>>> It’s >>>>>>>>> this >>>>>>>>> latter >>>>>>>>> space >>>>>>>>> where >>>>>>>>> I >>>>>>>>> think >>>>>>>>> we >>>>>>>>> can >>>>>>>>> both >>>>>>>>> push >>>>>>>>> innovation >>>>>>>>> and >>>>>>>>> also >>>>>>>>> address >>>>>>>>> the >>>>>>>>> important >>>>>>>>> and >>>>>>>>> compelling >>>>>>>>> use >>>>>>>>> cases >>>>>>>>> like >>>>>>>>> the >>>>>>>>> ones >>>>>>>>> you’re >>>>>>>>> bringing. >>>>>>>>> >>>>>>>>>  — >>>>>>>>> Justin >>>>>>>>> >>>>>>>>>> On >>>>>>>>>> Mar >>>>>>>>>> 22, >>>>>>>>>> 2021, >>>>>>>>>> at >>>>>>>>>> 2:14 >>>>>>>>>> PM, >>>>>>>>>> Adrian >>>>>>>>>> Gropper >>>>>>>>>> >>>>>>>>> > >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> I'm >>>>>>>>>> sorry, >>>>>>>>>> Justin. >>>>>>>>>> As >>>>>>>>>> a >>>>>>>>>> Resource >>>>>>>>>> Owner, >>>>>>>>>> I >>>>>>>>>> look >>>>>>>>>> at >>>>>>>>>> the >>>>>>>>>> RS >>>>>>>>>> trust >>>>>>>>>> boundary >>>>>>>>>> (the >>>>>>>>>> dotted >>>>>>>>>> line >>>>>>>>>> in >>>>>>>>>> the >>>>>>>>>> diagram) >>>>>>>>>> as >>>>>>>>>> being >>>>>>>>>> the >>>>>>>>>> RS. >>>>>>>>>> I >>>>>>>>>> don't >>>>>>>>>> expect >>>>>>>>>> any >>>>>>>>>> visibility >>>>>>>>>> into >>>>>>>>>> what's >>>>>>>>>> going >>>>>>>>>> on >>>>>>>>>> on >>>>>>>>>> the right. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> My >>>>>>>>>> problem >>>>>>>>>> with >>>>>>>>>> the >>>>>>>>>> framing >>>>>>>>>> you >>>>>>>>>> propose >>>>>>>>>> is >>>>>>>>>> that >>>>>>>>>> requests >>>>>>>>>> are >>>>>>>>>> going >>>>>>>>>> to >>>>>>>>>> the >>>>>>>>>> RS >>>>>>>>>> (or >>>>>>>>>> the >>>>>>>>>> AS-RS) >>>>>>>>>> and >>>>>>>>>> I >>>>>>>>>> don't >>>>>>>>>> want >>>>>>>>>> to >>>>>>>>>> share >>>>>>>>>> my >>>>>>>>>> policies >>>>>>>>>> with >>>>>>>>>> the >>>>>>>>>> AS-RS. >>>>>>>>>> I >>>>>>>>>> want >>>>>>>>>> to >>>>>>>>>> keep >>>>>>>>>> the >>>>>>>>>> RS >>>>>>>>>> and >>>>>>>>>> AS-RS >>>>>>>>>> as >>>>>>>>>> ignorant >>>>>>>>>> as >>>>>>>>>> possible. >>>>>>>>>> >>>>>>>>>> Adrian >>>>>>>>>> >>>>>>>>>> On >>>>>>>>>> Mon, >>>>>>>>>> Mar >>>>>>>>>> 22, >>>>>>>>>> 2021 >>>>>>>>>> at >>>>>>>>>> 1:48 >>>>>>>>>> PM >>>>>>>>>> Justin >>>>>>>>>> Richer >>>>>>>>>> >>>>>>>>> > >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Adrian, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> What >>>>>>>>>> you’re >>>>>>>>>> discussing >>>>>>>>>> below, >>>>>>>>>> in >>>>>>>>>> terms >>>>>>>>>> of >>>>>>>>>> logging >>>>>>>>>> in >>>>>>>>>> to >>>>>>>>>> a >>>>>>>>>> site, >>>>>>>>>> is >>>>>>>>>> not >>>>>>>>>> approaching >>>>>>>>>> the >>>>>>>>>> RS. >>>>>>>>>> You >>>>>>>>>> are >>>>>>>>>> in >>>>>>>>>> fact >>>>>>>>>> approaching >>>>>>>>>> the >>>>>>>>>> client, >>>>>>>>>> and >>>>>>>>>> identifying >>>>>>>>>> both >>>>>>>>>> the >>>>>>>>>> AS >>>>>>>>>> and >>>>>>>>>> RS >>>>>>>>>> to >>>>>>>>>> the >>>>>>>>>> client. >>>>>>>>>> The >>>>>>>>>> client >>>>>>>>>> is >>>>>>>>>> a >>>>>>>>>> client >>>>>>>>>> /of >>>>>>>>>> your >>>>>>>>>> identity/ >>>>>>>>>> in >>>>>>>>>> this >>>>>>>>>> model, >>>>>>>>>> and >>>>>>>>>> the >>>>>>>>>> RS >>>>>>>>>> is >>>>>>>>>> part >>>>>>>>>> of >>>>>>>>>> the >>>>>>>>>> identity >>>>>>>>>> provider. >>>>>>>>>> It’s >>>>>>>>>> really >>>>>>>>>> important >>>>>>>>>> that >>>>>>>>>> we >>>>>>>>>> don’t >>>>>>>>>> conflate >>>>>>>>>> the >>>>>>>>>> RS >>>>>>>>>> and >>>>>>>>>> client >>>>>>>>>> in >>>>>>>>>> this >>>>>>>>>> way >>>>>>>>>> as >>>>>>>>>> it >>>>>>>>>> leads >>>>>>>>>> to >>>>>>>>>> a >>>>>>>>>> lot >>>>>>>>>> of >>>>>>>>>> confusion >>>>>>>>>> downstream >>>>>>>>>> and >>>>>>>>>> a >>>>>>>>>> lot >>>>>>>>>> of >>>>>>>>>> broken >>>>>>>>>> trust >>>>>>>>>> boundaries. >>>>>>>>>> >>>>>>>>>> With >>>>>>>>>> that >>>>>>>>>> model >>>>>>>>>> in >>>>>>>>>> mind, >>>>>>>>>> approaching >>>>>>>>>> the >>>>>>>>>> “RS" >>>>>>>>>> and >>>>>>>>>> providing >>>>>>>>>> it >>>>>>>>>> your >>>>>>>>>> identity >>>>>>>>>> is >>>>>>>>>> really >>>>>>>>>> just >>>>>>>>>> a >>>>>>>>>> case >>>>>>>>>> of >>>>>>>>>> the >>>>>>>>>> “federated >>>>>>>>>> login >>>>>>>>>> to >>>>>>>>>> AS” >>>>>>>>>> pattern >>>>>>>>>> that >>>>>>>>>> we >>>>>>>>>> discussed >>>>>>>>>> on >>>>>>>>>> the >>>>>>>>>> WG >>>>>>>>>> call. >>>>>>>>>> The >>>>>>>>>> user >>>>>>>>>> here >>>>>>>>>> approaches >>>>>>>>>> an >>>>>>>>>> RS, >>>>>>>>>> which >>>>>>>>>> has >>>>>>>>>> its >>>>>>>>>> own >>>>>>>>>> AS. >>>>>>>>>> To >>>>>>>>>> share >>>>>>>>>> things >>>>>>>>>> from >>>>>>>>>> this >>>>>>>>>> RS, >>>>>>>>>> the >>>>>>>>>> RO >>>>>>>>>> has >>>>>>>>>> to >>>>>>>>>> authenticate >>>>>>>>>> to >>>>>>>>>> the >>>>>>>>>> RS’s >>>>>>>>>> AS. >>>>>>>>>> This >>>>>>>>>> particular >>>>>>>>>> AS >>>>>>>>>> allows >>>>>>>>>> the >>>>>>>>>> RO >>>>>>>>>> to >>>>>>>>>> do >>>>>>>>>> so >>>>>>>>>> using >>>>>>>>>> an >>>>>>>>>> external >>>>>>>>>> identity >>>>>>>>>> — >>>>>>>>>> in >>>>>>>>>> which >>>>>>>>>> case, >>>>>>>>>> the >>>>>>>>>> AS >>>>>>>>>> is >>>>>>>>>> now >>>>>>>>>> a >>>>>>>>>> “client” >>>>>>>>>> of >>>>>>>>>> a >>>>>>>>>> separate, >>>>>>>>>> disconnected >>>>>>>>>> (but >>>>>>>>>> layered) >>>>>>>>>> delegation. >>>>>>>>>> The >>>>>>>>>> ultimate >>>>>>>>>> client >>>>>>>>>> that >>>>>>>>>> eventually >>>>>>>>>> calls >>>>>>>>>> the >>>>>>>>>> RS >>>>>>>>>> down >>>>>>>>>> the >>>>>>>>>> way >>>>>>>>>> may >>>>>>>>>> or >>>>>>>>>> may >>>>>>>>>> not >>>>>>>>>> know >>>>>>>>>> about >>>>>>>>>> these >>>>>>>>>> layers. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This >>>>>>>>>> same >>>>>>>>>> AS, >>>>>>>>>> which >>>>>>>>>> is >>>>>>>>>> closely >>>>>>>>>> tied >>>>>>>>>> to >>>>>>>>>> the >>>>>>>>>> RS >>>>>>>>>> and >>>>>>>>>> trusted >>>>>>>>>> by >>>>>>>>>> the >>>>>>>>>> RS, >>>>>>>>>> might >>>>>>>>>> also >>>>>>>>>> take >>>>>>>>>> in >>>>>>>>>> FIDO >>>>>>>>>> credentials, >>>>>>>>>> or >>>>>>>>>> DIDs, >>>>>>>>>> or >>>>>>>>>> any >>>>>>>>>> number >>>>>>>>>> of >>>>>>>>>> other >>>>>>>>>> proof >>>>>>>>>> mechanisms. >>>>>>>>>> The >>>>>>>>>> output >>>>>>>>>> of >>>>>>>>>> this >>>>>>>>>> is >>>>>>>>>> an >>>>>>>>>> access >>>>>>>>>> token >>>>>>>>>> the >>>>>>>>>> RS >>>>>>>>>> trusts, >>>>>>>>>> but >>>>>>>>>> the >>>>>>>>>> input >>>>>>>>>> is >>>>>>>>>> up >>>>>>>>>> to >>>>>>>>>> the >>>>>>>>>> AS. >>>>>>>>>> The >>>>>>>>>> RS >>>>>>>>>> is >>>>>>>>>> not >>>>>>>>>> what >>>>>>>>>> you’re >>>>>>>>>> logging >>>>>>>>>> in >>>>>>>>>> to. >>>>>>>>>> >>>>>>>>>>  — >>>>>>>>>> Justin >>>>>>>>>> >>>>>>>>>>> On >>>>>>>>>>> Mar >>>>>>>>>>> 22, >>>>>>>>>>> 2021, >>>>>>>>>>> at >>>>>>>>>>> 1:28 >>>>>>>>>>> PM, >>>>>>>>>>> Adrian >>>>>>>>>>> Gropper >>>>>>>>>>> >>>>>>>>>> > >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> I >>>>>>>>>>> too >>>>>>>>>>> am >>>>>>>>>>> in >>>>>>>>>>> favor >>>>>>>>>>> of >>>>>>>>>>> avoiding >>>>>>>>>>> consolidation >>>>>>>>>>> and >>>>>>>>>>> correlation. >>>>>>>>>>> Right >>>>>>>>>>> now, >>>>>>>>>>> when >>>>>>>>>>> I >>>>>>>>>>> approach >>>>>>>>>>> a >>>>>>>>>>> service >>>>>>>>>>> provider >>>>>>>>>>> (RS) >>>>>>>>>>> for >>>>>>>>>>> the >>>>>>>>>>> first >>>>>>>>>>> time, >>>>>>>>>>> I'm >>>>>>>>>>> offered >>>>>>>>>>> the >>>>>>>>>>> opportunity >>>>>>>>>>> to >>>>>>>>>>> identify >>>>>>>>>>> my >>>>>>>>>>> persona >>>>>>>>>>> as: >>>>>>>>>>> email, >>>>>>>>>>> sign-in >>>>>>>>>>> with >>>>>>>>>>> Google, >>>>>>>>>>> Facebook, >>>>>>>>>>> or >>>>>>>>>>> Apple. >>>>>>>>>>> I >>>>>>>>>>> know >>>>>>>>>>> there >>>>>>>>>>> are >>>>>>>>>>> people >>>>>>>>>>> who >>>>>>>>>>> try >>>>>>>>>>> to >>>>>>>>>>> create >>>>>>>>>>> one-off >>>>>>>>>>> email >>>>>>>>>>> addresses >>>>>>>>>>> but >>>>>>>>>>> that >>>>>>>>>>> is >>>>>>>>>>> mostly >>>>>>>>>>> a >>>>>>>>>>> waste >>>>>>>>>>> of >>>>>>>>>>> time. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> So, >>>>>>>>>>> along >>>>>>>>>>> come >>>>>>>>>>> FIDO2 >>>>>>>>>>> and >>>>>>>>>>> DID >>>>>>>>>>> wallets >>>>>>>>>>> to >>>>>>>>>>> the >>>>>>>>>>> rescue. >>>>>>>>>>> Now, >>>>>>>>>>> in >>>>>>>>>>> theory, >>>>>>>>>>> I >>>>>>>>>>> have >>>>>>>>>>> a >>>>>>>>>>> way >>>>>>>>>>> to >>>>>>>>>>> start >>>>>>>>>>> out >>>>>>>>>>> my >>>>>>>>>>> RS >>>>>>>>>>> relationship >>>>>>>>>>> pseudonymously. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> When >>>>>>>>>>> I >>>>>>>>>>> want >>>>>>>>>>> my >>>>>>>>>>> resource >>>>>>>>>>> to >>>>>>>>>>> be >>>>>>>>>>> discovered >>>>>>>>>>> or >>>>>>>>>>> shared >>>>>>>>>>> I >>>>>>>>>>> will >>>>>>>>>>> post >>>>>>>>>>> that >>>>>>>>>>> RS >>>>>>>>>>> URL >>>>>>>>>>> including >>>>>>>>>>> my >>>>>>>>>>> pseudonym. >>>>>>>>>>> If >>>>>>>>>>> I >>>>>>>>>>> then >>>>>>>>>>> want >>>>>>>>>>> to >>>>>>>>>>> introduce >>>>>>>>>>> a >>>>>>>>>>> mediator in >>>>>>>>>>> front >>>>>>>>>>> of >>>>>>>>>>> my >>>>>>>>>>> AS >>>>>>>>>>> or >>>>>>>>>>> messaging >>>>>>>>>>> service endpoint, >>>>>>>>>>> I >>>>>>>>>>> have >>>>>>>>>>> that >>>>>>>>>>> option. >>>>>>>>>>> If >>>>>>>>>>> I >>>>>>>>>>> want >>>>>>>>>>> to >>>>>>>>>>> keep >>>>>>>>>>> requests >>>>>>>>>>> away >>>>>>>>>>> from >>>>>>>>>>> the >>>>>>>>>>> mediator, >>>>>>>>>>> I >>>>>>>>>>> would >>>>>>>>>>> publish >>>>>>>>>>> an >>>>>>>>>>> encryption >>>>>>>>>>> key >>>>>>>>>>> along >>>>>>>>>>> with >>>>>>>>>>> my >>>>>>>>>>> pseudonym. >>>>>>>>>>> >>>>>>>>>>> - >>>>>>>>>>> Adrian >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On >>>>>>>>>>> Mon, >>>>>>>>>>> Mar >>>>>>>>>>> 22, >>>>>>>>>>> 2021 >>>>>>>>>>> at >>>>>>>>>>> 9:55 >>>>>>>>>>> AM >>>>>>>>>>> Justin >>>>>>>>>>> Richer >>>>>>>>>>> >>>>>>>>>> > >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> On >>>>>>>>>>> Mar >>>>>>>>>>> 21, >>>>>>>>>>> 2021, >>>>>>>>>>> at >>>>>>>>>>> 1:18 >>>>>>>>>>> PM, >>>>>>>>>>> Benjamin >>>>>>>>>>> Kaduk >>>>>>>>>>> >>>>>>>>>> > >>>>>>>>>>> wrote: >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> > >>>>>>>>>>> On >>>>>>>>>>> Sat, >>>>>>>>>>> Mar >>>>>>>>>>> 20, >>>>>>>>>>> 2021 >>>>>>>>>>> at >>>>>>>>>>> 01:07:42AM >>>>>>>>>>> -0400, >>>>>>>>>>> Adrian >>>>>>>>>>> Gropper >>>>>>>>>>> wrote: >>>>>>>>>>> >> >>>>>>>>>>> @Alan >>>>>>>>>>> Karp >>>>>>>>>>> >>>>>>>>>> > >>>>>>>>>>> shared >>>>>>>>>>> a >>>>>>>>>>> talk >>>>>>>>>>> about >>>>>>>>>>> the >>>>>>>>>>> Principle >>>>>>>>>>> Of >>>>>>>>>>> Least >>>>>>>>>>> >> >>>>>>>>>>> Authority >>>>>>>>>>> (POLA) >>>>>>>>>>> in >>>>>>>>>>> a >>>>>>>>>>> recent >>>>>>>>>>> comment >>>>>>>>>>> >> >>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-803099693 >>>>>>>>>>> >>>>>>>>>>> >> >>>>>>>>>>> I >>>>>>>>>>> recommend >>>>>>>>>>> it. >>>>>>>>>>> >> >>>>>>>>>>> >>>>>>>>>>> >> >>>>>>>>>>> We >>>>>>>>>>> might >>>>>>>>>>> expect >>>>>>>>>>> a >>>>>>>>>>> protocol >>>>>>>>>>> with >>>>>>>>>>> authorization >>>>>>>>>>> in >>>>>>>>>>> the >>>>>>>>>>> title >>>>>>>>>>> to >>>>>>>>>>> use >>>>>>>>>>> authority >>>>>>>>>>> >> >>>>>>>>>>> as >>>>>>>>>>> a >>>>>>>>>>> core >>>>>>>>>>> principle. >>>>>>>>>>> I >>>>>>>>>>> advocate >>>>>>>>>>> for >>>>>>>>>>> a >>>>>>>>>>> GNAP >>>>>>>>>>> design >>>>>>>>>>> that >>>>>>>>>>> maximizes >>>>>>>>>>> the >>>>>>>>>>> power >>>>>>>>>>> >> >>>>>>>>>>> of >>>>>>>>>>> the >>>>>>>>>>> RO, >>>>>>>>>>> to >>>>>>>>>>> be >>>>>>>>>>> seen >>>>>>>>>>> as >>>>>>>>>>> a >>>>>>>>>>> human >>>>>>>>>>> rights >>>>>>>>>>> issue >>>>>>>>>>> when >>>>>>>>>>> the >>>>>>>>>>> RO >>>>>>>>>>> is >>>>>>>>>>> a >>>>>>>>>>> human. >>>>>>>>>>> This >>>>>>>>>>> >> >>>>>>>>>>> causes >>>>>>>>>>> me >>>>>>>>>>> to >>>>>>>>>>> ask >>>>>>>>>>> how >>>>>>>>>>> to >>>>>>>>>>> combine >>>>>>>>>>> better >>>>>>>>>>> security >>>>>>>>>>> with >>>>>>>>>>> better >>>>>>>>>>> human >>>>>>>>>>> rights >>>>>>>>>>> in >>>>>>>>>>> >> >>>>>>>>>>> GNAP. >>>>>>>>>>> >> >>>>>>>>>>> >>>>>>>>>>> >> >>>>>>>>>>> Who >>>>>>>>>>> should >>>>>>>>>>> have >>>>>>>>>>> the >>>>>>>>>>> least >>>>>>>>>>> authority >>>>>>>>>>> in >>>>>>>>>>> the >>>>>>>>>>> GNAP >>>>>>>>>>> design? >>>>>>>>>>> >> >>>>>>>>>>> >>>>>>>>>>> >> >>>>>>>>>>> The >>>>>>>>>>> AS >>>>>>>>>>> derives >>>>>>>>>>> authority >>>>>>>>>>> as >>>>>>>>>>> a >>>>>>>>>>> delegate >>>>>>>>>>> of >>>>>>>>>>> the >>>>>>>>>>> RO. >>>>>>>>>>> If >>>>>>>>>>> we >>>>>>>>>>> ask >>>>>>>>>>> the >>>>>>>>>>> RO >>>>>>>>>>> to >>>>>>>>>>> >> >>>>>>>>>>> partition >>>>>>>>>>> limited >>>>>>>>>>> authority >>>>>>>>>>> across >>>>>>>>>>> dozens >>>>>>>>>>> of >>>>>>>>>>> different >>>>>>>>>>> ASs >>>>>>>>>>> by >>>>>>>>>>> domain >>>>>>>>>>> and >>>>>>>>>>> >> >>>>>>>>>>> function, >>>>>>>>>>> then >>>>>>>>>>> we >>>>>>>>>>> are >>>>>>>>>>> not >>>>>>>>>>> using >>>>>>>>>>> technology >>>>>>>>>>> to >>>>>>>>>>> empower >>>>>>>>>>> the >>>>>>>>>>> individual. >>>>>>>>>>> >> >>>>>>>>>>> Probably >>>>>>>>>>> the >>>>>>>>>>> opposite, >>>>>>>>>>> as >>>>>>>>>>> we >>>>>>>>>>> introduce >>>>>>>>>>> consent >>>>>>>>>>> fatigue >>>>>>>>>>> and >>>>>>>>>>> burden >>>>>>>>>>> normal >>>>>>>>>>> >> >>>>>>>>>>> people >>>>>>>>>>> to >>>>>>>>>>> partition >>>>>>>>>>> their >>>>>>>>>>> lives >>>>>>>>>>> into >>>>>>>>>>> non-overlapping >>>>>>>>>>> domains. >>>>>>>>>>> >> >>>>>>>>>>> >>>>>>>>>>> >> >>>>>>>>>>> My >>>>>>>>>>> experience >>>>>>>>>>> says >>>>>>>>>>> we >>>>>>>>>>> should >>>>>>>>>>> aim >>>>>>>>>>> for >>>>>>>>>>> one >>>>>>>>>>> AS >>>>>>>>>>> per >>>>>>>>>>> persona >>>>>>>>>>> because >>>>>>>>>>> that >>>>>>>>>>> maps >>>>>>>>>>> >> >>>>>>>>>>> into >>>>>>>>>>> the >>>>>>>>>>> way >>>>>>>>>>> we >>>>>>>>>>> manage >>>>>>>>>>> our >>>>>>>>>>> public >>>>>>>>>>> and >>>>>>>>>>> private >>>>>>>>>>> identities. >>>>>>>>>>> POLA >>>>>>>>>>> would >>>>>>>>>>> then >>>>>>>>>>> >> >>>>>>>>>>> teach >>>>>>>>>>> care >>>>>>>>>>> in >>>>>>>>>>> keeping >>>>>>>>>>> ASs >>>>>>>>>>> and >>>>>>>>>>> RSs >>>>>>>>>>> related >>>>>>>>>>> to >>>>>>>>>>> work >>>>>>>>>>> / >>>>>>>>>>> public >>>>>>>>>>> separate >>>>>>>>>>> from >>>>>>>>>>> >> >>>>>>>>>>> ASs >>>>>>>>>>> and >>>>>>>>>>> RSs >>>>>>>>>>> related >>>>>>>>>>> to >>>>>>>>>>> private >>>>>>>>>>> life >>>>>>>>>>> so >>>>>>>>>>> that >>>>>>>>>>> a >>>>>>>>>>> policy >>>>>>>>>>> vulnerability >>>>>>>>>>> in >>>>>>>>>>> our >>>>>>>>>>> >> >>>>>>>>>>> delegation >>>>>>>>>>> to >>>>>>>>>>> an >>>>>>>>>>> AS >>>>>>>>>>> would >>>>>>>>>>> have >>>>>>>>>>> the >>>>>>>>>>> least >>>>>>>>>>> likelihood >>>>>>>>>>> of >>>>>>>>>>> harm. >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> > >>>>>>>>>>> Thinking >>>>>>>>>>> about >>>>>>>>>>> how >>>>>>>>>>> least >>>>>>>>>>> authority/least >>>>>>>>>>> privilege >>>>>>>>>>> would >>>>>>>>>>> apply >>>>>>>>>>> to >>>>>>>>>>> GNAP >>>>>>>>>>> > >>>>>>>>>>> seems >>>>>>>>>>> like >>>>>>>>>>> a >>>>>>>>>>> useful >>>>>>>>>>> exercise.  >>>>>>>>>>> I >>>>>>>>>>> do >>>>>>>>>>> want >>>>>>>>>>> to >>>>>>>>>>> point >>>>>>>>>>> out >>>>>>>>>>> some >>>>>>>>>>> potential >>>>>>>>>>> > >>>>>>>>>>> pitfalls >>>>>>>>>>> with >>>>>>>>>>> one-AS-per-persona >>>>>>>>>>> that >>>>>>>>>>> we >>>>>>>>>>> can >>>>>>>>>>> also >>>>>>>>>>> be >>>>>>>>>>> aware >>>>>>>>>>> of.  >>>>>>>>>>> If >>>>>>>>>>> > >>>>>>>>>>> one-AS-per-persona >>>>>>>>>>> becomes >>>>>>>>>>> one-persona-per-AS >>>>>>>>>>> as >>>>>>>>>>> well, >>>>>>>>>>> then >>>>>>>>>>> the >>>>>>>>>>> AS's >>>>>>>>>>> > >>>>>>>>>>> identity >>>>>>>>>>> in >>>>>>>>>>> effect >>>>>>>>>>> also >>>>>>>>>>> serves >>>>>>>>>>> as >>>>>>>>>>> a >>>>>>>>>>> persona >>>>>>>>>>> identity >>>>>>>>>>> and >>>>>>>>>>> there >>>>>>>>>>> are >>>>>>>>>>> privacy >>>>>>>>>>> > >>>>>>>>>>> considerations >>>>>>>>>>> to >>>>>>>>>>> that.  >>>>>>>>>>> If, >>>>>>>>>>> on >>>>>>>>>>> the >>>>>>>>>>> other >>>>>>>>>>> hand, >>>>>>>>>>> the >>>>>>>>>>> > >>>>>>>>>>> multiple-personas-per-AS >>>>>>>>>>> (presumably >>>>>>>>>>> corresponding >>>>>>>>>>> to >>>>>>>>>>> multiple >>>>>>>>>>> humans) >>>>>>>>>>> > >>>>>>>>>>> route >>>>>>>>>>> is >>>>>>>>>>> taken, >>>>>>>>>>> we >>>>>>>>>>> should >>>>>>>>>>> consider >>>>>>>>>>> whether >>>>>>>>>>> that >>>>>>>>>>> would >>>>>>>>>>> lead >>>>>>>>>>> to >>>>>>>>>>> various >>>>>>>>>>> > >>>>>>>>>>> (e.g., >>>>>>>>>>> market) >>>>>>>>>>> forces >>>>>>>>>>> driving >>>>>>>>>>> consolidation >>>>>>>>>>> to >>>>>>>>>>> just >>>>>>>>>>> a >>>>>>>>>>> handful >>>>>>>>>>> of >>>>>>>>>>> > >>>>>>>>>>> super-popular >>>>>>>>>>> AS >>>>>>>>>>> services. >>>>>>>>>>> That >>>>>>>>>>> topic >>>>>>>>>>> is >>>>>>>>>>> a >>>>>>>>>>> current >>>>>>>>>>> matter >>>>>>>>>>> of >>>>>>>>>>> concern >>>>>>>>>>> to >>>>>>>>>>> > >>>>>>>>>>> some >>>>>>>>>>> IETF >>>>>>>>>>> participants. >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi >>>>>>>>>>> Ben, >>>>>>>>>>> big >>>>>>>>>>> +1 >>>>>>>>>>> to >>>>>>>>>>> this. >>>>>>>>>>> This >>>>>>>>>>> is >>>>>>>>>>> something >>>>>>>>>>> that >>>>>>>>>>> we >>>>>>>>>>> discussed >>>>>>>>>>> ages >>>>>>>>>>> ago >>>>>>>>>>> in >>>>>>>>>>> the >>>>>>>>>>> UMA >>>>>>>>>>> working >>>>>>>>>>> group, >>>>>>>>>>> and >>>>>>>>>>> it’s >>>>>>>>>>> one >>>>>>>>>>> of >>>>>>>>>>> the >>>>>>>>>>> biggest >>>>>>>>>>> problems >>>>>>>>>>> with >>>>>>>>>>> the >>>>>>>>>>> personal >>>>>>>>>>> AS >>>>>>>>>>> (and >>>>>>>>>>> personal >>>>>>>>>>> data >>>>>>>>>>> store) >>>>>>>>>>> model. >>>>>>>>>>> This >>>>>>>>>>> kind >>>>>>>>>>> of >>>>>>>>>>> thing >>>>>>>>>>> makes >>>>>>>>>>> RS-first >>>>>>>>>>> trust >>>>>>>>>>> models >>>>>>>>>>> really >>>>>>>>>>> difficult >>>>>>>>>>> in >>>>>>>>>>> practice. >>>>>>>>>>> >>>>>>>>>>> As >>>>>>>>>>> a >>>>>>>>>>> strawman, >>>>>>>>>>> let’s >>>>>>>>>>> say >>>>>>>>>>> that >>>>>>>>>>> I’ve >>>>>>>>>>> got >>>>>>>>>>> software >>>>>>>>>>> that >>>>>>>>>>> wants >>>>>>>>>>> to >>>>>>>>>>> access >>>>>>>>>>> my >>>>>>>>>>> medical >>>>>>>>>>> information. >>>>>>>>>>> It >>>>>>>>>>> calls >>>>>>>>>>> an >>>>>>>>>>> RS >>>>>>>>>>> and >>>>>>>>>>> requests >>>>>>>>>>> access, >>>>>>>>>>> but >>>>>>>>>>> it >>>>>>>>>>> hasn’t >>>>>>>>>>> been >>>>>>>>>>> granted >>>>>>>>>>> anything >>>>>>>>>>> yet. >>>>>>>>>>> Now >>>>>>>>>>> I >>>>>>>>>>> as >>>>>>>>>>> the >>>>>>>>>>> RO >>>>>>>>>>> have >>>>>>>>>>> set >>>>>>>>>>> up >>>>>>>>>>> the >>>>>>>>>>> RS >>>>>>>>>>> so >>>>>>>>>>> that >>>>>>>>>>> it >>>>>>>>>>> talks >>>>>>>>>>> to >>>>>>>>>>> my >>>>>>>>>>> personal >>>>>>>>>>> AS, >>>>>>>>>>> that >>>>>>>>>>> only >>>>>>>>>>> I >>>>>>>>>>> use. >>>>>>>>>>> In >>>>>>>>>>> addition >>>>>>>>>>> to >>>>>>>>>>> the >>>>>>>>>>> RS >>>>>>>>>>> having >>>>>>>>>>> to >>>>>>>>>>> be >>>>>>>>>>> able >>>>>>>>>>> to >>>>>>>>>>> figure >>>>>>>>>>> out >>>>>>>>>>> which >>>>>>>>>>> medical >>>>>>>>>>> records >>>>>>>>>>> are >>>>>>>>>>> being >>>>>>>>>>> requested >>>>>>>>>>> from >>>>>>>>>>> the >>>>>>>>>>> context >>>>>>>>>>> of >>>>>>>>>>> the >>>>>>>>>>> unauthenticated >>>>>>>>>>> request >>>>>>>>>>> (which >>>>>>>>>>> means >>>>>>>>>>> it >>>>>>>>>>> needs >>>>>>>>>>> identifiers >>>>>>>>>>> in >>>>>>>>>>> the >>>>>>>>>>> URL >>>>>>>>>>> or >>>>>>>>>>> something >>>>>>>>>>> similar >>>>>>>>>>> for >>>>>>>>>>> the >>>>>>>>>>> RS >>>>>>>>>>> to >>>>>>>>>>> be >>>>>>>>>>> able >>>>>>>>>>> to >>>>>>>>>>> tell, >>>>>>>>>>> assuming >>>>>>>>>>> that >>>>>>>>>>> it >>>>>>>>>>> protects >>>>>>>>>>> data >>>>>>>>>>> for >>>>>>>>>>> more >>>>>>>>>>> than >>>>>>>>>>> one >>>>>>>>>>> person). >>>>>>>>>>> So >>>>>>>>>>> this >>>>>>>>>>> client >>>>>>>>>>> software >>>>>>>>>>> doesn’t >>>>>>>>>>> know >>>>>>>>>>> who >>>>>>>>>>> I >>>>>>>>>>> am >>>>>>>>>>> and >>>>>>>>>>> doesn’t >>>>>>>>>>> know >>>>>>>>>>> my >>>>>>>>>>> medical >>>>>>>>>>> record >>>>>>>>>>> information, >>>>>>>>>>> makes >>>>>>>>>>> a >>>>>>>>>>> completely >>>>>>>>>>> unauthorized >>>>>>>>>>> request >>>>>>>>>>> to >>>>>>>>>>> the >>>>>>>>>>> RS, >>>>>>>>>>> and >>>>>>>>>>> the >>>>>>>>>>> RS >>>>>>>>>>> says >>>>>>>>>>> “Go >>>>>>>>>>> to >>>>>>>>>>> Justin’s >>>>>>>>>>> personal >>>>>>>>>>> AS >>>>>>>>>>> to >>>>>>>>>>> get >>>>>>>>>>> a >>>>>>>>>>> token”. >>>>>>>>>>> The >>>>>>>>>>> client >>>>>>>>>>> can >>>>>>>>>>> now >>>>>>>>>>> make >>>>>>>>>>> a >>>>>>>>>>> direct >>>>>>>>>>> correlation >>>>>>>>>>> between >>>>>>>>>>> the >>>>>>>>>>> data >>>>>>>>>>> that’s >>>>>>>>>>> being >>>>>>>>>>> protected >>>>>>>>>>> at >>>>>>>>>>> the >>>>>>>>>>> RS >>>>>>>>>>> and >>>>>>>>>>> the >>>>>>>>>>> person >>>>>>>>>>> running >>>>>>>>>>> the >>>>>>>>>>> AS >>>>>>>>>>> that >>>>>>>>>>> protects >>>>>>>>>>> it. >>>>>>>>>>> Importantly, >>>>>>>>>>> this >>>>>>>>>>> client >>>>>>>>>>> makes >>>>>>>>>>> this >>>>>>>>>>> call >>>>>>>>>>> with >>>>>>>>>>> no >>>>>>>>>>> prior >>>>>>>>>>> relationship >>>>>>>>>>> to >>>>>>>>>>> the >>>>>>>>>>> RS >>>>>>>>>>> and >>>>>>>>>>> no >>>>>>>>>>> really >>>>>>>>>>> auditable >>>>>>>>>>> way >>>>>>>>>>> to >>>>>>>>>>> track >>>>>>>>>>> it >>>>>>>>>>> down >>>>>>>>>>> after >>>>>>>>>>> the >>>>>>>>>>> fact. >>>>>>>>>>> This >>>>>>>>>>> is >>>>>>>>>>> a >>>>>>>>>>> design >>>>>>>>>>> feature >>>>>>>>>>> in >>>>>>>>>>> the >>>>>>>>>>> good >>>>>>>>>>> case, >>>>>>>>>>> and >>>>>>>>>>> terrifying >>>>>>>>>>> in >>>>>>>>>>> the >>>>>>>>>>> bad >>>>>>>>>>> case. >>>>>>>>>>> >>>>>>>>>>> If >>>>>>>>>>> the >>>>>>>>>>> RS >>>>>>>>>>> instead >>>>>>>>>>> says >>>>>>>>>>> “welcome >>>>>>>>>>> to >>>>>>>>>>> Medicine >>>>>>>>>>> Doctor >>>>>>>>>>> RS, >>>>>>>>>>> please >>>>>>>>>>> talk >>>>>>>>>>> to >>>>>>>>>>> the >>>>>>>>>>> Medicine >>>>>>>>>>> Doctor >>>>>>>>>>> AS >>>>>>>>>>> to >>>>>>>>>>> get >>>>>>>>>>> access”, >>>>>>>>>>> we >>>>>>>>>>> haven’t >>>>>>>>>>> exposed >>>>>>>>>>> anything >>>>>>>>>>> at >>>>>>>>>>> all. >>>>>>>>>>> And >>>>>>>>>>> from >>>>>>>>>>> the >>>>>>>>>>> perspective >>>>>>>>>>> of >>>>>>>>>>> both >>>>>>>>>>> the >>>>>>>>>>> patient >>>>>>>>>>> and >>>>>>>>>>> the >>>>>>>>>>> RS, >>>>>>>>>>> this >>>>>>>>>>> is >>>>>>>>>>> more >>>>>>>>>>> privacy-preserving, >>>>>>>>>>> and >>>>>>>>>>> it’s >>>>>>>>>>> really >>>>>>>>>>> the >>>>>>>>>>> least >>>>>>>>>>> surprising >>>>>>>>>>> option. >>>>>>>>>>> Once >>>>>>>>>>> the >>>>>>>>>>> client >>>>>>>>>>> gets >>>>>>>>>>> to >>>>>>>>>>> the >>>>>>>>>>> AS, >>>>>>>>>>> it >>>>>>>>>>> can >>>>>>>>>>> start >>>>>>>>>>> a >>>>>>>>>>> negotiation >>>>>>>>>>> of >>>>>>>>>>> figuring >>>>>>>>>>> out >>>>>>>>>>> who >>>>>>>>>>> the >>>>>>>>>>> RO >>>>>>>>>>> is >>>>>>>>>>> for >>>>>>>>>>> the >>>>>>>>>>> information >>>>>>>>>>> being >>>>>>>>>>> accessed. >>>>>>>>>>> >>>>>>>>>>> On >>>>>>>>>>> top >>>>>>>>>>> of >>>>>>>>>>> this, >>>>>>>>>>> the >>>>>>>>>>> usability >>>>>>>>>>> expectations >>>>>>>>>>> of >>>>>>>>>>> people >>>>>>>>>>> managing >>>>>>>>>>> their >>>>>>>>>>> own >>>>>>>>>>> AS, >>>>>>>>>>> or >>>>>>>>>>> set >>>>>>>>>>> of >>>>>>>>>>> AS’s >>>>>>>>>>> for >>>>>>>>>>> multiple >>>>>>>>>>> personas >>>>>>>>>>> to >>>>>>>>>>> keep >>>>>>>>>>> things >>>>>>>>>>> separate, >>>>>>>>>>> is >>>>>>>>>>> a >>>>>>>>>>> huge >>>>>>>>>>> burden. >>>>>>>>>>> Even >>>>>>>>>>> in >>>>>>>>>>> the >>>>>>>>>>> tech >>>>>>>>>>> community, >>>>>>>>>>> I >>>>>>>>>>> know >>>>>>>>>>> people >>>>>>>>>>> who >>>>>>>>>>> can’t >>>>>>>>>>> reliably >>>>>>>>>>> manage >>>>>>>>>>> more >>>>>>>>>>> than >>>>>>>>>>> one >>>>>>>>>>> email >>>>>>>>>>> address >>>>>>>>>>> for >>>>>>>>>>> different >>>>>>>>>>> purposes. >>>>>>>>>>> I >>>>>>>>>>> wouldn’t >>>>>>>>>>> expect >>>>>>>>>>> my >>>>>>>>>>> partner >>>>>>>>>>> to >>>>>>>>>>> do >>>>>>>>>>> that >>>>>>>>>>> — >>>>>>>>>>> they >>>>>>>>>>> have >>>>>>>>>>> trouble >>>>>>>>>>> enough >>>>>>>>>>> balancing >>>>>>>>>>> all >>>>>>>>>>> the >>>>>>>>>>> logins >>>>>>>>>>> and >>>>>>>>>>> sessions >>>>>>>>>>> required >>>>>>>>>>> for >>>>>>>>>>> different >>>>>>>>>>> kids >>>>>>>>>>> remote >>>>>>>>>>> schooling, >>>>>>>>>>> I >>>>>>>>>>> couldn’t >>>>>>>>>>> imagine >>>>>>>>>>> them >>>>>>>>>>> having >>>>>>>>>>> to >>>>>>>>>>> understand >>>>>>>>>>> all >>>>>>>>>>> the >>>>>>>>>>> requirements >>>>>>>>>>> for >>>>>>>>>>> managing >>>>>>>>>>> multiple >>>>>>>>>>> authorization >>>>>>>>>>> servers >>>>>>>>>>> and >>>>>>>>>>> associated >>>>>>>>>>> policies. >>>>>>>>>>> I >>>>>>>>>>> also >>>>>>>>>>> don’t >>>>>>>>>>> expect >>>>>>>>>>> any >>>>>>>>>>> person >>>>>>>>>>> to >>>>>>>>>>> “manage >>>>>>>>>>> keys” >>>>>>>>>>> — >>>>>>>>>>> I’ve >>>>>>>>>>> been >>>>>>>>>>> on >>>>>>>>>>> the >>>>>>>>>>> internet >>>>>>>>>>> for >>>>>>>>>>> decades >>>>>>>>>>> and >>>>>>>>>>> I >>>>>>>>>>> can >>>>>>>>>>> barely >>>>>>>>>>> keep >>>>>>>>>>> tabs >>>>>>>>>>> on >>>>>>>>>>> my >>>>>>>>>>> GPG >>>>>>>>>>> keys, >>>>>>>>>>> and >>>>>>>>>>> only >>>>>>>>>>> use >>>>>>>>>>> them >>>>>>>>>>> when >>>>>>>>>>> I >>>>>>>>>>> am >>>>>>>>>>> forced >>>>>>>>>>> to. >>>>>>>>>>> This >>>>>>>>>>> is >>>>>>>>>>> exactly >>>>>>>>>>> the >>>>>>>>>>> kind >>>>>>>>>>> of >>>>>>>>>>> “market >>>>>>>>>>> pressure” >>>>>>>>>>> that >>>>>>>>>>> I >>>>>>>>>>> think >>>>>>>>>>> Ben >>>>>>>>>>> mentions >>>>>>>>>>> above, >>>>>>>>>>> people >>>>>>>>>>> will >>>>>>>>>>> just >>>>>>>>>>> want >>>>>>>>>>> to >>>>>>>>>>> outsource >>>>>>>>>>> that >>>>>>>>>>> to >>>>>>>>>>> someone >>>>>>>>>>> else, >>>>>>>>>>> and >>>>>>>>>>> the >>>>>>>>>>> reality >>>>>>>>>>> will >>>>>>>>>>> be >>>>>>>>>>> a >>>>>>>>>>> few >>>>>>>>>>> popular >>>>>>>>>>> providers. >>>>>>>>>>> >>>>>>>>>>> In >>>>>>>>>>> which >>>>>>>>>>> case, >>>>>>>>>>> we >>>>>>>>>>> could >>>>>>>>>>> end >>>>>>>>>>> up >>>>>>>>>>> doing >>>>>>>>>>> a >>>>>>>>>>> ton >>>>>>>>>>> of >>>>>>>>>>> work >>>>>>>>>>> to >>>>>>>>>>> allow >>>>>>>>>>> an >>>>>>>>>>> RS >>>>>>>>>>> choice >>>>>>>>>>> only >>>>>>>>>>> to >>>>>>>>>>> end >>>>>>>>>>> up >>>>>>>>>>> with >>>>>>>>>>> a >>>>>>>>>>> world >>>>>>>>>>> where >>>>>>>>>>> the >>>>>>>>>>> RS >>>>>>>>>>> ends >>>>>>>>>>> up >>>>>>>>>>> making >>>>>>>>>>> a >>>>>>>>>>> limited >>>>>>>>>>> choice >>>>>>>>>>> anyway. >>>>>>>>>>> We >>>>>>>>>>> see >>>>>>>>>>> how >>>>>>>>>>> that >>>>>>>>>>> plays >>>>>>>>>>> out >>>>>>>>>>> with >>>>>>>>>>> OpenID >>>>>>>>>>> Connect >>>>>>>>>>> — >>>>>>>>>>> RP’s >>>>>>>>>>> could >>>>>>>>>>> allow >>>>>>>>>>> arbitrary >>>>>>>>>>> IdPs >>>>>>>>>>> but >>>>>>>>>>> they >>>>>>>>>>> choose >>>>>>>>>>> Google >>>>>>>>>>> because >>>>>>>>>>> it >>>>>>>>>>> works >>>>>>>>>>> and >>>>>>>>>>> that’s >>>>>>>>>>> where >>>>>>>>>>> the >>>>>>>>>>> users >>>>>>>>>>> are. >>>>>>>>>>> (And >>>>>>>>>>> that’s >>>>>>>>>>> not >>>>>>>>>>> to >>>>>>>>>>> say >>>>>>>>>>> anything >>>>>>>>>>> of >>>>>>>>>>> the >>>>>>>>>>> proprietary >>>>>>>>>>> OIDC-like >>>>>>>>>>> protocols, >>>>>>>>>>> but >>>>>>>>>>> that’s >>>>>>>>>>> another >>>>>>>>>>> discussion). >>>>>>>>>>> >>>>>>>>>>> For >>>>>>>>>>> further >>>>>>>>>>> reading >>>>>>>>>>> on >>>>>>>>>>> these >>>>>>>>>>> topics, >>>>>>>>>>> I >>>>>>>>>>> recommend >>>>>>>>>>> both >>>>>>>>>>> “Why >>>>>>>>>>> Johnny >>>>>>>>>>> Can’t >>>>>>>>>>> Encrypt” >>>>>>>>>>> and >>>>>>>>>>> “Why >>>>>>>>>>> CSCW >>>>>>>>>>> Systems >>>>>>>>>>> Fail”. >>>>>>>>>>> >>>>>>>>>>> So >>>>>>>>>>> what >>>>>>>>>>> does >>>>>>>>>>> this >>>>>>>>>>> have >>>>>>>>>>> to >>>>>>>>>>> do >>>>>>>>>>> with >>>>>>>>>>> GNAP? >>>>>>>>>>> I >>>>>>>>>>> think >>>>>>>>>>> we >>>>>>>>>>> can >>>>>>>>>>> be >>>>>>>>>>> clear-eyed >>>>>>>>>>> on >>>>>>>>>>> what >>>>>>>>>>> kinds >>>>>>>>>>> of >>>>>>>>>>> expectations >>>>>>>>>>> we >>>>>>>>>>> have >>>>>>>>>>> for >>>>>>>>>>> the >>>>>>>>>>> participants. >>>>>>>>>>> If >>>>>>>>>>> we >>>>>>>>>>> expect >>>>>>>>>>> users >>>>>>>>>>> (RO’s) >>>>>>>>>>> to >>>>>>>>>>> have >>>>>>>>>>> to >>>>>>>>>>> set >>>>>>>>>>> up >>>>>>>>>>> the >>>>>>>>>>> AS-RS >>>>>>>>>>> relationship, >>>>>>>>>>> or >>>>>>>>>>> expect >>>>>>>>>>> them >>>>>>>>>>> to >>>>>>>>>>> carry >>>>>>>>>>> their >>>>>>>>>>> AS, >>>>>>>>>>> or >>>>>>>>>>> manage >>>>>>>>>>> their >>>>>>>>>>> personal >>>>>>>>>>> keys >>>>>>>>>>> — >>>>>>>>>>> I >>>>>>>>>>> think >>>>>>>>>>> we’ve >>>>>>>>>>> lost >>>>>>>>>>> the >>>>>>>>>>> battle >>>>>>>>>>> for >>>>>>>>>>> relevance. >>>>>>>>>>> >>>>>>>>>>>  — >>>>>>>>>>> Justin >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> TXAuth mailing list >>>>>>> TXAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> > --------------9A2AB8EF9F419184280F8DE4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
    Hi  Justin,

    Since your response only deals with the AS, but not the RS nor the RO, it is not a response to my question which was:
    How will a RS or a RO be bootstrapped for working with a GNAP "sub" claim or a "sub_id" claim ?
    The subject identifier is whatever identifier the AS knows the subject as. If they log in using only a FIDO token and the AS asserts that key value as the identifier, then that’s what it will be. If they sign up with an email address or make a username or get assigned a random number, that’s what it will be. Or they could sign up using any number of those and the AS still assigns them a random value, because it’s always the AS that determines which value to assign the number.

    When looking at Section 3.2 (Access Tokens), the client (and hence the end-user) has currently no practical way to indicate which of its attributes should be placed into an access token,
    The only reference within Section 3.2 is pointing to the empty Section 12. Among the many examples, there is not a single example that addresses the case of attributes being placed into an access token.

    Nevertheless, it seems that in your opinion, only the AS, but NOT the client (and hence the end-user), SHALL have control at all of what kind of subject identifier claim will be placed inside the access token.

    Then after, invoking the postulate "the access token SHALL remain opaque to the client (and hence the end-user)", it seems that in your opinion, the end-user SHALL have no way to verify
    whether its privacy has been respected. If this is not an architecture built along "spy by design" principles, I don't know what else it might be.

    It is important to re-read two of the current definitions:

    Privilege: right or attribute associated with a subject.

    Access Token: data artifact representing a set of rights and/or attributes.

    In the current draft, the case of rights is indeed addressed while the case of attributes is fully ignored.

    The RS is not involved in any subject information. Identity APIs, like OpenID Connect’s UserInfo Endpoint, are out of scope for GNAP.

    Really ? Do you mean that an access token should not contain a "sub" claim nor a "sub_id" claim  and if it does, the RS SHALL ignore such claims ?

    In the "OAuth Access Token JWT Profile", there is the following sentence in Section 6 (Privacy Considerations) :

       This profile mandates the presence of the "sub" claim in every JWT
       access token, making it possible for resource servers to rely on that
       information for performing tasks such as correlating incoming
       requests with data stored locally for the authenticated principal. 

    This sentence clearly makes a relationship between the value present in the "sub" claim and "data stored locally for the authenticated principal".

    However, note that the "OAuth Access Token JWT Profile" fails to allow the client (and hence the end-user) to control his privacy, since the client
    cannot choose which value will be placed in the "sub" claim and also because access tokens are considered to be opaque for the clients in OAuth.
    If there is a subject identifier either included in or referenced by the access token, that is up to any agreements between the AS and RS
    that lead to the ability of the AS to create the tokens the RS can trust. All of this is outside the scope of the core GNAP protocol and invisible to the client.

    You are using the following words "up to any agreements between the AS and RS". This mandates prior agreements between ASs and RSs
    and in such a case the architecture will be non-scalable over the Internet. The trust relationship between a RS and an AS is unilateral:
    The RS trusts the AS to issue appropriate access tokens corresponding to the requests of its clients.

    From an end-user point of view, if there cannot be transparency because of the access token opacity, then there cannot be confidence about GNAP .

    Denis


     — Justin

    On Mar 26, 2021, at 1:27 PM, Denis <denis.ietf@free.fr> wrote:

    Hi Justin,

    Let me rephrase the last question: How will a RS or a RO be bootstrapped for working with a GNAP "sub" claim or a "sub_id" claim ?

    Denis

    GNAP doesn’t have anything too say about anybody authenticating directly to the RS. If that happens, it’s out of the view and out of scope of GNAP.

     — Justin

    On Mar 26, 2021, at 1:06 PM, Denis <denis.ietf@free.fr> wrote:

    Hi everybody,

    The content of this thread has nothing to do any more with its original title which was: "Will GNAP support Zero Trust Architecture?"
    Since I am going to use some sentences of this thread to open a new topic, I changed the title of this thread into :
    "Relationship between Authentication and Authorization ?"

    At the moment, I got the impression that nobody agrees any more about what GNAP is or is not, what it should address and what it should not address.
    The components of the model are becoming more numerous and hazy. A new terminology is sometimes being used, but is not yet present in the last published draft.

    I still can't understand any of the new terms that are being used (AS-RS and AS-RO), which are still left undefined.

    The last exchanges look more as conversations between workers during the construction of the Babel tower.

    Last year, my first remark was to mention that a section or an Annex explaining the common points and the differences with OAuth 2.0
    would be useful. Such section or Annex still does not exist.

    Justin wrote:
    If an RS allows a username/password HTTP Basic auth in addition to accepting access tokens, it can do so, but
    GNAP doesn’t have anything to say about the Basic auth use, or even its relation to any access tokens or RO’s or anything else.
    Let us split the end of this sentence into two parts:

    "GNAP doesn’t have anything to say about the Basic auth use":  If an authentication exchange  is necessary, the draft document should describe, for completeness,
    the HTTP error code that will be returned.

    "or even its relation to any access tokens or RO’s or anything else". Let us suppose that a RS supports FIDO as an authentication mechanism to authenticate its end-users.
    FIDO provides the major advantage that, for every RS, a different identifier is used by every end-user. This prevents end-users accounts correlations between RSs by using
    such identifiers. In practice, a FIDO identifier is a pseudonym.

    At this very moment, the RS is able to identify and authenticate its end-users using FIDO pseudonyms. Now, let us raise the following question:

    How will a RS be bootstrapped for working with a GNAP "sub" claim or a "sub_id" claim, whereas FIDO is already being used ?

    Denis


    Adrian,

    I disagree, I believe that what I have laid out is exactly separating the concerns into working components. 

    Like OAuth before it, GNAP is a protocol negotiate access for a client instance to an RS, using an AS as the facilitator of that delegated negotiation. (Unlike OAuth, it’s importantly also for negotiating user information to the client directly from the AS with no RS involved, but that’s an aside for the purposes of our conversation here).

    If a particular GNAP RS also allows other kinds of processes to enable access to it, that is completely fine, but outside of GNAP. If an RS allows a username/password HTTP Basic auth in addition to accepting access tokens, it can do so, but GNAP doesn’t have anything to say about the Basic auth use, or even its relation to any access tokens or RO’s or anything else. If an RS accepts structured access tokens signed by trusted keys that don’t come from an AS through a negotiated request — again, that’s fine, but GNAP is silent about the RS doing that. If the RS acts as “its own AS” then it’s really just an RS and an AS living in the same box. Again, that’s fine, and super common with OAuth today. 

    GNAP is solving the problem of connecting the client to the RS through means of an AS. Other solutions are possible and many of them can be deployed right alongside, but that’s not the corner of the world that GNAP is solving. GNAP should be concerned about how these other technologies can be used alongside it. I think there’s a lot of room for the things that you’re talking about, and more importantly for solving the use cases that you’re bringing. But GNAP should be more than a single-point solution, and so we need to balance these concerns. The conceptual framework of an AS that takes in lots of different information and spits out access tokens is exactly the abstraction layer that is necessary for making these use cases interoperable.

     — Justin

    On Mar 26, 2021, at 8:30 AM, Adrian Gropper <agropper@healthurl.com> wrote:

    @Justin, there’s no separation of concerns here. No partition between processor and controller. No data minimization. And, I see no obvious reason to make this the core of GNAP. 

    The one thing we can probably all agree on is that there’s only one RS and one RO. 

    The core of GNAP, in my opinion, can be built and explained around this simple design. The RS is a processor. The RO is a controller. The RS bears only security responsibility. The RS bears no privacy responsibility. The RO delegates this to the RS but this is not authorization as the A in GNAP.

    The RO retains all rights to delegate within the scope of things that the RS is willing to support using various token formats and endpoint options. Some of these options may do all sorts of things for all sorts of clients and user-agents  but these are options. 

    For example, if a request comes to the RS that is not in the form of an access token, then it either gets sent to the RO or their agent, or it gets logged and dumped. One such option, common in healthcare, is “Break the Glass” where the RS is acting as an authorization server because the user-agent is making a request instead of presenting an access token. GNAP can offer this as an option but it is not our core.

    Adrian



    On Fri, Mar 26, 2021 at 7:15 AM Justin Richer <jricher@mit.edu> wrote:
    I have a big problem with this line:

    > the RS and AS-RS only see access tokens. The requests (from RO') that resulted in an access token are none of their business.

    In the trust model we’ve been discussing, the requests that result in access tokens are solely the business of AS-RS, since AS-RS is the only entity that’s allowed, and trusted by the RS, to create access tokens for the RS. That is its entire job, the entire reason it exists in the system. By definition the party generating tokens for use at the RS is the AS for that RS, I don’t care how you deploy it. If RO wants to give access to someone else (who isn’t an “RO" anymore, they’re another end-user), then that end user’s client software will need to talk to AS-RS to get its own access token.

    Now here’s the trick: when the end user’s client instance talks to AS-RS, that does NOT mean that AS-RS needs to know all the details and policy reasons that it should give an access token to that client instance. It doesn’t even need to know the existence of another end user. It doesn’t need identity, it doesn’t need policy. Sure, it COULD handle all of that internally, and many will, but the protocol doesn’t demand it. 

    This means that the first client instance, the one that gets the access token, can also be given something alongside the access token that it can then hand to another piece of software (or to a person to hand eo their piece of software). This artifact is not an access token. This artifact could be something structured that the client understands, and can make derivatives of, and present back to the AS-RS for getting new access tokens. There could be multiple different flavors of this kind of artifact for different kinds of environments and groups. But what they all have in common is that they can potentially be used to request more access tokens within some context at the AS-RS.

     — Justin



    On Mar 25, 2021, at 5:50 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    My issue is with Alan's:
    "7. Another user agent (RO') can contact any holder of the access token or the service's policy agent (AS-RS) to get a delegated access token."

    I would prefer "7A. Another user agent (RO') can contact any holder of the access token." by default so that the AS-RS does not see the requests. In other words, the RS and AS-RS only see access tokens. The requests (from RO') that resulted in an access token are none of their business.

    The reality is that RO' can discover a resource RS and can share whatever information with RS-AS they want and the RO may not even know about it unless the RS decides to let them know somehow. This seems to be a drawback of the capabilities approach. 

    In terms of privacy and control, I, as the RO, want a contract with the RS that says that I or my agent (AS-RO) must sign an access token. This is a fundamental audit requirement. Without it, a rogue RS and AS-RS can do all sorts of things and the RO would never know. I understand that a rogue RS might not support an honest contemporaneous log of access tokens presented so there's a trust issue here that I seems unavoidable unless I specify in my RO-RS contract that they use a separate contemporaneous log such as AS-RO for every access token presented and risk being sued if they process an access token without also updating the separate log.

    - Adrian


    On Thu, Mar 25, 2021 at 1:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin Richer <jricher@mit.edu> wrote:
    Hi Alan,

    In all of my discussion, and in the spec itself, the RO is the :entity: in charge of approving rights. They’re probably a person. It might be software that makes a policy decision in some way, or a corporate entity, or something like that. But it’s not assumed to be a computational agent in the terms of the protocol itself. Would that recast what you’re saying below?

    Hmmm.  I guess not.  It's just that the person would be using some UI to express their decisions to what I called the user agent.  That model fits in very nicely with what we did with Polaris, our virus safe computing environment for Windows XP, https://dl.acm.org/doi/10.1145/1151030.1151033.  The person would click on the icon for a Word file, and an instance of Word would open with only the permission needed to edit that one file.  Same thing here.  The client could ask for permission to use the resource, or permission could be granted implicitly when the user selects a resource associated with a specific client.

    --------------
    Alan Karp


    On Thu, Mar 25, 2021 at 9:53 AM Justin Richer <jricher@mit.edu> wrote:
    Hi Alan,

    In all of my discussion, and in the spec itself, the RO is the :entity: in charge of approving rights. They’re probably a person. It might be software that makes a policy decision in some way, or a corporate entity, or something like that. But it’s not assumed to be a computational agent in the terms of the protocol itself. Would that recast what you’re saying below?

     — Justin

    On Mar 25, 2021, at 12:36 PM, Alan Karp <alanhkarp@gmail.com> wrote:

    There seems to be some confusion about how AS-RO comes into the picture, probably because of the "AS" part.  I'm going to try to clear up that confusion by more carefully explaining what I mean.

    I'm assuming that RO is a computational agent representing the person who is the resource owner, something called the "user agent" in operating systems lingo.  I'm also assuming that it's possible to do delegation, either locally or by token exchange with AS-RS.  All delegations are potentially sub-scoped, but you may also want to delegate with full scope to have a separately revocable access token.

      Here's an example of how things work in a capability oriented system.
    1. Someone, the service owner, creates a service.
    2. The service owner contracts with an policy agent (AS-RS) to create and manage access tokens for that service (RS).
    3. A person wishing to create a resource at RS uses their user agent (RO) to contact the service owner's policy agent (AS-RS) and gets back an access token for that resource.
    4. That user agent (RO) can 
      1. use that access token to invoke the resource, or
      2. delegate an access token to a client of the user agent's (RO) choice, or
      3. contract with a policy agent (AS-RO) to manage those delegations on behalf of the user agent (RO), or
      4. specify a policy with the service's policy agent (AS-RS).
    5. A client can contact any holder of the access token (the user agent (RO) or its policy agent (AS-RO)) or the service's policy agent (AS-RS) to get a delegated access token.
    6. That client can delegate that token to another client.
    7. Another user agent (RO') can contact any holder of the access token or the service's policy agent (AS-RS) to get a delegated access token.
    8. The other user agent (RO') can 
      1. use that access token to invoke the resource, or
      2. delegate it to a client of its choice, or
      3. contract with a policy agent (AS-RO') of its choosing to manage those delegations on its behalf, or
      4. specify a policy with the service's policy agent (AS-RS).
    9. and so on
    When any of these computational agents, user agents (ROs) or clients acting on their behalf, invokes the resource, AS-RS verifies that the access token is a valid delegation, i.e., proper sub-scoping, hasn't been revoked, and that it authorizes the request being made before telling the service (RS) to honor the request.  At no point does the service's policy agent (AS-RS) know which computational agent did any particular delegation.  (Token exchange can be done as anonymously as possible.)  In particular, the policy agents (AS-RO) need not be the same, or even compatible with, the service's policy agent (AS-RS).  GNAP specifies the protocol between requesters, invokers, delegators (for token exchange) of tokens and AS-RS.  That protocol need not be used between user agents (RO), clients, or other policy agents (AS-RO), but it is likely to be.

     -------------
    Alan Karp


    On Thu, Mar 25, 2021 at 5:45 AM Justin Richer <jricher@mit.edu> wrote:
    The way I’m thinking about Adrian’s use case is that what we’re calling the “AS-RO” isn’t an “AS” in the traditional OAuth/GNAP sense, at least not exactly. This is the agent that the RO can use to set policies and manage consent on their behalf, and I’ve been arguing that it fits better into this vaguely-defined “interaction component” aspect of the current AS definition, and it’s not currently separated from the AS definition. The “AS-RS” maps to what we’d call the “AS” in OAuth/GNAP traditionally, it’s what the RS trusts to issue tokens. In traditional OAuth the AS-RO and AS-RS are always the same thing, from a functional protocol perspective. An important point here is that from a client’s perspective, they’re only talking to the AS-RS since that’s where the client gets its tokens, because at the end of the day the client just wants to call the API at the RS and doesn’t care how that happens (from a protocol standpoint). 

    Note well: Even thought I don’t believe that “AS-RO” is an authorization server at all, I’m going to keep using that term below for consistency with previous discussion.

    So we have these fundamental relationships around getting the client to access the RS:

    1. RS trusts AS-RS to issue tokens that RS will accept, validate, and process for requests from client
    2. Client trusts AS-RS to issue tokens that client can use at RS
    3. RO trusts RS to protect RO’s api through delegated access

    On top of that, we’ve got some additional aspects that we’re discussing:

    4. RO trusts AS-RO to manage RO’s policies at runtime
    5. AS-RS trusts AS-RO to assert RO’s policies for access to RS
    6. Client trusts whatever AS-RS sends client to deal with, including possibly RO-AS at runtime, because of (2)

    What I have been saying is that 4/5/6 are optional details of how RS-AS runs things, and I think this also maps with Adrian’s view of choice, since if my RS’s AS-RS doesn’t allow me to plug in my own AS-RO then I would be motivated to pick a different RS who’s AS-RS lets me do just that. The same way I’d pick a different RS if their surrounding services didn’t accept my preferred federation login and I didn’t want to make another account. Of course, market forces being as they are, I might not have much of an actionable choice in RS, but GNAP can’t change that. 

    What we can do is make it possible for AS-RS to talk to AS-RO, both in philosophy of the protocol design and in concrete hooks to support (6) above. 

    Separately, we can approach the issue of making 1/2 above more dynamic. This was UMA2’s “federated authorization” approach, and is behind a lot of the “bring your own AS” models out there. The problem with these is that we know from many years of experience that most RS’s aren’t interested in doing anything of the sort.

    So with GNAP we can instead allow 4/5/6 to vary in a predictable and consistent way, letting the RS keep control over 1/2, thereby enabling choice in (3). We don’t have to be the ones who define the all of the details of every permutation of (5) to enable this, though. Some of this is going to be configuration out of band, some of it’s going to be communication at runtime. This is where VC’s, ZCAPs, CHAPI, DIDComm, FIDO, and a whole swath of other tech can come in and help out. I don’t think we need to put all the details for using these into core, nor do I think we’ll pull of The Great And Ultimate Abstraction for using these and other approaches. But we can at least start talking about “AS-RS” in such a way that it no longer assumes it’s always the same party dealing with the RO directly.

     — Justin

    On Mar 25, 2021, at 6:40 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    To reframe it closer to GNAP:
    - AS = AS-RO, that's where you find the RO policies. The AS issues access tokens to the client.
    - the RO policies could be a) defined locally or b) in relationship with the RS

    There have been several ideas related to the AS-RS relationship b:
    b1) the RS issues capabilities (which can be further attenuated by the RO)
    b2) Adrian also discussed a DID based solution
    b3) there was also an alternative ACL proposal from Denis (+ preflight)

    Fabien


    On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Ok so I get you correctly: 
    - what matters is the RQ (could be a RO or a end-user or both : we don't really care at a high-level, they're all treated as entities that make a request)
    - the policy is able to handle those different cases, based on its own internal delegation protocol
    - currently that requires AS-RS and AS-RO, but maybe it can be simplified

    To answer to Denis, here's what I understood:
    - RO trusts AS-RS (and then handles its own policies within AS-RO)
    - end-user trusts AS-RO (through its client)

    Could probably work but that's a fairly different model compared to OAuth2 (and of today's GNAP), with different frontiers between the AS and the RS. 

    Please do not hesitate to correct me if I'm wrong.

    Fabien 

    On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper <agropper@healthurl.com> wrote:
    I believe there are alternatives to having two kinds of ASs. The problem may be a side-effect of deciding to switch away form treating the RO as different from the RQ. That leads to downstream privacy issues. Our desire for architectural simplicity is admirable but that may have been a step too far.

    There may also be solutions based on different types of tokens, as in different capabilities (tokens signed by the RS) vs. tokens signed by the AS. I’m not sure about that but Alan might have more to say.

    Adrian

    On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks. The general problem statement is clear.

    The proposed solution a bit less (to me). I understood that from point 2, Alan involves 2 ASs. You said : "There’s no obvious reason to have two types of ASs". Do you see an alternative ?

    Regarding the last item, I don't think that naming RQ by end-user created the problem. It might just highlight the asymmetry, which fundamentally exists. 

    Fabien


    On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper <agropper@healthurl.com> wrote:
    Recap:
    1 - Justin (I think) introduced the idea of an AS on the RS trust boundary side.
    2 - I said the RO should not have to share policies with the RS.
    3 - Alan invented the concept of AS-RO and AS-RS to separate two kinds of PDPs. 

    The thing is that step 2 is not symmetrical. The RO has a legitimate privacy interest in keeping their policies private and minimizing the leakage of information about requests that are posed against those policies. 

    The RS, on the other hand, should be publishing its policies (e.g. what it’s selling or what jurisdiction it’s in or what tokens or scopes it supports). The RS has no obvious privacy interest in GNAP. It’s just an enforcer.

    There is one other privacy interest to consider around the RS and that is the requesting party (the end-user that is not the RO :-) might prefer to share attributes with the RS instead of the RO or something controlled by the RO. This case could be an “extension” to GNAP and might result in a split AS as a solution. This problem was introduced when the editors decided to replace RQ with end-user. Obviously, the RO end-user has no privacy interests relative to itself.

    Adrian




    On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    I was referring to "By my definition, this model has two ASs since both are processing requests into tokens". If there's no reason to have 2 types of ASs, that's fine then. 
    But I'm a bit lost in where we stand with the idea. 

    Could you recap? 

    Fabien 

    Le jeu. 25 mars 2021 à 08:16, Adrian Gropper <agropper@healthurl.com> a écrit :
    There’s no obvious reason to have two types of ASs. Any AS that is executing the policies of the RS can look to GNAP like the RS itself. Why would GNAP expose that interface to anyone? 

    Adrian

    On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Note : I'm not sure that's a good idea, but having 2 types of ASs is not that easy to grasp.

    Fabien 

    Le jeu. 25 mars 2021 à 08:07, Fabien Imbault <fabien.imbault@gmail.com> a écrit :
    The purpose of either handling policies locally or delegating them to the RO agent. 

    Le jeu. 25 mars 2021 à 08:04, Adrian Gropper <agropper@healthurl.com> a écrit :
    What purpose would be served by GNAP splitting the AS into two components?

    Adrian 

    On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Isn't the AS-RO a component of the AS? Same idea as the interact component, it functionnally belongs to the AS role but could be deployed either as a monolith or as a separate component?

    Fabien

    Le jeu. 25 mars 2021 à 04:26, Adrian Gropper <agropper@healthurl.com> a écrit :
    Yes, but I would say it’s not the RO that wants the access token. It’s the RO that wants the client making the request to get an access token. 

    Adrian

    On Wed, Mar 24, 2021 at 11:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Adrian Gropper <agropper@healthurl.com> wrote:

    In this design, the AS is the AS-RS and the agent is the AS-RO. By my definition, this model has two ASs since both are processing requests into tokens. The problem with this is complexity and privacy. The RO may not want to share the request information with the AS-RS.

    More precisely, RO has no choice but to present the required information to AS-RS if RO wants an access token.  However, RO does not want AS-RS to know the policy by which RO delegates tokens.  That's why RO uses AS-RO for those delegations.

    --------------
    Alan Karp


    On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper <agropper@healthurl.com> wrote:
    Thank you for creating the issue. My definition of AS is independent of AS-RO or AS-RS. https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomment-806280421 I also agree with Alan's definition based on delegation. An AS-RS would be a delegate of the RS. 

    Based on that, I see it as obvious that the policy has to be accessible (defined locally?) in order for it to be run as the code that turns a request into an access token. 

    The only other possibility is that the request is packaged by the AS and sent elsewhere (an agent) for evaluation against policy and a proto-token returned. In that case the AS is acting as a proxy and the PDP is elsewhere. I can imagine that an AS-RS would behave this way so that the proto-token could be turned into an access token by the AS-RS. Isn't this what Justin is proposing? In this design, the AS is the AS-RS and the agent is the AS-RO. By my definition, this model has two ASs since both are processing requests into tokens. The problem with this is complexity and privacy. The RO may not want to share the request information with the AS-RS.

    Adrian

    On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Isn't that what the AS is supposed to be, only with the caveat that the policy is defined locally? 

    Fabien 


    Le mer. 24 mars 2021 à 20:17, Alan Karp <alanhkarp@gmail.com> a écrit :
    AS-RO is an AS that RO trusts to delegate RO's access tokens according to RO's policies.  

    --------------
    Alan Karp


    On Wed, Mar 24, 2021 at 9:36 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan and Adrian,

    I've created issue AS-RO policy delegation (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to capture your input. 
    A first question that arises: can we give a definition to AS-RO?

    Thanks
    Fabien

    On Tue, Mar 23, 2021 at 4:15 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan, 

    Yes, but in that flow, the token relationship between AS-RS and AS-RO is only secure if the tokens issued by AS-RS are cryptographically attenuable in the first place. 
     
    Attenuated delegation is a requirement, but that doesn't have to be done cryptographically.  Token exchange works just fine.  SPKI and zcap-ld are examples of the crypto approach, and we used token exchange in the system for HP.

    --------------
    Alan Karp


    On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan, 

    Yes, but in that flow, the token relationship between AS-RS and AS-RO is only secure if the tokens issued by AS-RS are cryptographically attenuable in the first place. 

    Fabien

    On Mon, Mar 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin Richer <jricher@mit.edu> wrote:

    But with all that in mind, I think the key here is going to be looking at what the inputs to the AS are, and how those can be defined in an interoperable way for AS’s that can accept them. I think there’s a lot of room for innovation and flexibility here that doesn’t break the trust model or core use cases. If I have an AS-RS set that won’t accept my favorite flavor of policy engine inputs, then I can decide not to use that one. But this is a very different question than saying the RS itself needs to accept my own AS — and we can’t keep conflating these two models.

    I agree.  The point of having an AS-RO is to allow RO to specify a policy for which of RO's access tokens should be delegated under what conditions.  AS-RS should not need to understand those policies.  The flow would be
    • RO contacts AS-RS and gets one or more access tokens.
    • RO delegates one or more of those tokens, potentially sub-scoped, to AS-RO.
    • A different user contacts AS-RO to get a potentially sub-scoped access token from AS-RO.
    • That user presents the access token delegated by AS-RO when invoking the resource.
    AS-RS only needs to verify that the delegation chain is legitimate, e.g., no increase in scope, and that it grants permission for the request being made.  AS-RS does not need to understand the policy behind granting the delegation by AS-RO.

    --------------
    Alan Karp


    On Mon, Mar 22, 2021 at 11:40 AM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    I think this shows the problem with the terminology as it’s been applied in this conversation, which I’ve tried to shine light on before. What you and others are calling the “RS” is really the “AS and RS working together” — everything to the right of the line. When Denis had brought up “eliminating the AS” in another thread, what he’d really done is labeled everything to the right of the line as the “RS”. Of course, the irony here is that everything to the right of the line used all be called the “AS” or simply “server” in the OAuth 1 days. As you say below, I don’t want the client to have visibility on what happens on that side. 

    Note well: The Google+ logo labeled “IdP” in the diagram is not the AS, as far as GNAP is concerned. It does not issue an access token that the RS will accept. The elements to the left of the line could be a lot of things, but they are NOT the AS — by definition. The client lives over on the left, but so do any external inputs to the AS. These could be policy inputs on behalf of the RO, they could be presentation artifacts, they could be federated logins, they could be the output of policy decisions. How the AS comes to trust those things is up to the AS’s implementation. It’s something we can talk about, but ultimately GNAP won’t be in any position to dictate because in practice some AS’s are simply going to internalize all policies and we will never successfully force those open. 

    But with all that in mind, I think the key here is going to be looking at what the inputs to the AS are, and how those can be defined in an interoperable way for AS’s that can accept them. I think there’s a lot of room for innovation and flexibility here that doesn’t break the trust model or core use cases. If I have an AS-RS set that won’t accept my favorite flavor of policy engine inputs, then I can decide not to use that one. But this is a very different question than saying the RS itself needs to accept my own AS — and we can’t keep conflating these two models.

    So to me, GNAP can support a Zero Trust Architecture by LEVERAGING the AS, not by subsuming or eliminating it. It is in fact the AS, not the client and not the RS, that will request and consume the results of a privacy-preserving zero-trust policy query thing. Anything that happens downstream from that is of little concern to the zero-trust components because, as you point out, it’s on the “other side” of the line. 

    I think we got this basic component model pretty right in OAuth: the AS and RS and client working together. Where OAuth misses the mark is the assumption that the user has to log in to the AS through a webpage and interact directly, thereby proving they’re the RO. It’s this latter space where I think we can both push innovation and also address the important and compelling use cases like the ones you’re bringing.

     — Justin

    On Mar 22, 2021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I'm sorry, Justin. As a Resource Owner, I look at the RS trust boundary (the dotted line in the diagram) as being the RS. I don't expect any visibility into what's going on on the right. 

    My problem with the framing you propose is that requests are going to the RS (or the AS-RS) and I don't want to share my policies with the AS-RS. I want to keep the RS and AS-RS as ignorant as possible.

    Adrian

    On Mon, Mar 22, 2021 at 1:48 PM Justin Richer <jricher@mit.edu> wrote:
    Adrian,

    What you’re discussing below, in terms of logging in to a site, is not approaching the RS. You are in fact approaching the client, and identifying both the AS and RS to the client. The client is a client of your identity in this model, and the RS is part of the identity provider. It’s really important that we don’t conflate the RS and client in this way as it leads to a lot of confusion downstream and a lot of broken trust boundaries.

    With that model in mind, approaching the “RS" and providing it your identity is really just a case of the “federated login to AS” pattern that we discussed on the WG call. The user here approaches an RS, which has its own AS. To share things from this RS, the RO has to authenticate to the RS’s AS. This particular AS allows the RO to do so using an external identity — in which case, the AS is now a “client” of a separate, disconnected (but layered) delegation. The ultimate client that eventually calls the RS down the way may or may not know about these layers. 

    <PastedGraphic-1.png>
    This same AS, which is closely tied to the RS and trusted by the RS, might also take in FIDO credentials, or DIDs, or any number of other proof mechanisms. The output of this is an access token the RS trusts, but the input is up to the AS. The RS is not what you’re logging in to.

     — Justin

    On Mar 22, 2021, at 1:28 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I too am in favor of avoiding consolidation and correlation. Right now, when I approach a service provider (RS) for the first time, I'm offered the opportunity to identify my persona as: email, sign-in with Google, Facebook, or Apple. I know there are people who try to create one-off email addresses but that is mostly a waste of time. 

    So, along come FIDO2 and DID wallets to the rescue. Now, in theory, I have a way to start out my RS relationship pseudonymously. 

    When I want my resource to be discovered or shared I will post that RS URL including my pseudonym. If I then want to introduce a mediator in front of my AS or messaging service endpoint, I have that option. If I want to keep requests away from the mediator, I would publish an encryption key along with my pseudonym.

    - Adrian



    On Mon, Mar 22, 2021 at 9:55 AM Justin Richer <jricher@mit.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhkarp@gmail.com> shared a talk about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use authority
    >> as a core principle. I advocate for a GNAP design that maximizes the power
    >> of the RO, to be seen as a human rights issue when the RO is a human. This
    >> causes me to ask how to combine better security with better human rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO to
    >> partition limited authority across dozens of different ASs by domain and
    >> function, then we are not using technology to empower the individual.
    >> Probably the opposite, as we introduce consent fatigue and burden normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because that maps
    >> into the way we manage our public and private identities. POLA would then
    >> teach care in keeping ASs and RSs related to work / public separate from
    >> ASs and RSs related to private life so that a policy vulnerability in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP
    > seems like a useful exercise.  I do want to point out some potential
    > pitfalls with one-AS-per-persona that we can also be aware of.  If
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS's
    > identity in effect also serves as a persona identity and there are privacy
    > considerations to that.  If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)
    > route is taken, we should consider whether that would lead to various
    > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.  That topic is a current matter of concern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the UMA working group, and it’s one of the biggest problems with the personal AS (and personal data store) model. This kind of thing makes RS-first trust models really difficult in practice.

    As a strawman, let’s say that I’ve got software that wants to access my medical information. It calls an RS and requests access, but it hasn’t been granted anything yet. Now I as the RO have set up the RS so that it talks to my personal AS, that only I use. In addition to the RS having to be able to figure out which medical records are being requested from the context of the unauthenticated request (which means it needs identifiers in the URL or something similar for the RS to be able to tell, assuming that it protects data for more than one person). So this client software doesn’t know who I am and doesn’t know my medical record information, makes a completely unauthorized request to the RS, and the RS says “Go to Justin’s personal AS to get a token”. The client can now make a direct correlation between the data that’s being protected at the RS and the person running the AS that protects it. Importantly, this client makes this call with no prior relationship to the RS and no really auditable way to track it down after the fact. This is a design feature in the good case, and terrifying in the bad case.

    If the RS instead says “welcome to Medicine Doctor RS, please talk to the Medicine Doctor AS to get access”, we haven’t exposed anything at all. And from the perspective of both the patient and the RS, this is more privacy-preserving, and it’s really the least surprising option. Once the client gets to the AS, it can start a negotiation of figuring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS, or set of AS’s for multiple personas to keep things separate, is a huge burden. Even in the tech community, I know people who can’t reliably manage more than one email address for different purposes. I wouldn’t expect my partner to do that — they have trouble enough balancing all the logins and sessions required for different kids remote schooling, I couldn’t imagine them having to understand all the requirements for managing multiple authorization servers and associated policies. I also don’t expect any person to “manage keys” — I’ve been on the internet for decades and I can barely keep tabs on my GPG keys, and only use them when I am forced to. This is exactly the kind of “market pressure” that I think Ben mentions above, people will just want to outsource that to someone else, and the reality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice only to end up with a world where the RS ends up making a limited choice anyway. We see how that plays out with OpenID Connect — RP’s could allow arbitrary IdPs but they choose Google because it works and that’s where the users are. (And that’s not to say anything of the proprietary OIDC-like protocols, but that’s another discussion).

    For further reading on these topics, I recommend both “Why Johnny Can’t Encrypt” and “Why CSCW Systems Fail”.

    So what does this have to do with GNAP? I think we can be clear-eyed on what kinds of expectations we have for the participants. If we expect users (RO’s) to have to set up the AS-RS relationship, or expect them to carry their AS, or manage their personal keys — I think we’ve lost the battle for relevance.

     — Justin


    --
    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


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








    --------------9A2AB8EF9F419184280F8DE4-- From nobody Mon Mar 29 05:49:12 2021 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 76F793A10CA for ; Mon, 29 Mar 2021 05:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 Pn2nENxid24a for ; Mon, 29 Mar 2021 05:49:04 -0700 (PDT) Received: from mail-ua1-f46.google.com (mail-ua1-f46.google.com [209.85.222.46]) (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 5F68A3A10C3 for ; Mon, 29 Mar 2021 05:49:04 -0700 (PDT) Received: by mail-ua1-f46.google.com with SMTP id v23so3902780uaq.13 for ; Mon, 29 Mar 2021 05:49:04 -0700 (PDT) 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=sgHqgUCgMvtyY75qQZHRDP91OUFtCwwWzHjZJrUbEQc=; b=ltAWxfDTkx+NPoOPyBZlH6dav1FYez7idDZbBlV9eByHV9zcOLMVIUpqBosVtL3Ye2 QIFMgHH+mdaALWoLtBkcID05VGaTj0aRkFHUkVuP9KYJzI745N9gQTXKnua+vJt0PHmh XhD/tZOddyWp9EkppnTjp69qX9GVK5poFDZvXleWdy5Kh7y9y3kMNAMq/v9MHVGoIBuR TkyI++zmllL40y7R2B6qSTtmS9aGEeakD6BmZBseMjaawc3sZyBTj2z3H0JDFYuDMtCk 0Cz2lhj8CDSWCsMgucdbzV68bbZloWFZ5DPvRTV3zWinm0Yw/PTv2B0dwBu+eyyZ12Qq kE+A== X-Gm-Message-State: AOAM5322u0YIbSoia5hROR8+7K0oDRblYnToP8+bqxuQKL/aKCUs2NLf 5v1n2vQyDqa6VW/2LFxDKEQsPYX5Cs8VBKdzncY= X-Google-Smtp-Source: ABdhPJy77JVtU0eqhHaqMQA/aoOtxIejhx1N2i8WuXgmdNpO/wMiiq1eWXTAZuUDiMg2Ek/Sadr+KW6nEZmm+pDXABg= X-Received: by 2002:ab0:30a3:: with SMTP id b3mr12841575uam.0.1617022142809; Mon, 29 Mar 2021 05:49:02 -0700 (PDT) MIME-Version: 1.0 References: <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> <5773FA7B-6891-4227-A8CA-2F506909B8CD@mit.edu> <3c103293-56a1-4be5-e2a3-12eb82d13238@free.fr> <91D11E67-34AB-4426-803C-7B5A6F50537F@mit.edu> In-Reply-To: From: Adrian Gropper Date: Mon, 29 Mar 2021 08:48:50 -0400 Message-ID: To: Denis Cc: Justin Richer , txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000006a8bed05beac4edc" Archived-At: Subject: Re: [GNAP] Relationship between Authentication and Authorization ? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2021 12:49:11 -0000 --0000000000006a8bed05beac4edc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Denis, I don=E2=80=99t understand your privacy issue, and I would like to try. Let Alice be the RO and subject of a resource. at a RS. Let Bob be a party, not Alice, that seeks authorization to access the resource using an access token. Bob has discovered the resource somehow that is out of band for GNAP. (Maybe Alice sent Bob a pointer to the resource in an email). Bob makes a request for the resource at some AS. The request includes the pointer that Bob discovered to the resource, some attributes or claims about Bob, and maybe a reason for the request. How Bob discovered the AS to make the request to is unclear to me for the time being. Maybe Bob discovered the AS along with the resource. (e.g The resource is a DID and the AS is a service endpoint or mediator to an AS in that DID.) Given the scenario above, who=E2=80=99s privacy interest are you primarily concerned about? Alice or Bob? Adrian On Mon, Mar 29, 2021 at 6:39 AM Denis wrote: > Hi Justin, > > Since your response only deals with the AS, but not the RS nor the RO, it > is not a response to my question which was: > > How will a RS or a RO be bootstrapped for working with a GNAP "sub" claim > or a "sub_id" claim ? > > The subject identifier is whatever identifier the AS knows the subject as= . > If they log in using only a FIDO token and the AS asserts that key value = as > the identifier, then that=E2=80=99s what it will be. If they sign up with= an email > address or make a username or get assigned a random number, that=E2=80=99= s what it > will be. Or they could sign up using any number of those and the AS still > assigns them a random value, because it=E2=80=99s always the AS that dete= rmines > which value to assign the number. > > When looking at Section 3.2 (Access Tokens), the client (and hence the > end-user) has currently *no practical way* to indicate which of its > attributes should be placed into an access token, > The only reference within Section 3.2 is pointing to the empty Section 12= . > Among the many examples, there is not a single example that addresses the > case of attributes being placed into an access token. > > Nevertheless, it seems that in your opinion, only the AS, but NOT the > client (and hence the end-user), SHALL have control at all of what kind o= f *subject > identifier* claim will be placed inside the access token. > > Then after, invoking the postulate "the access token SHALL remain opaque > to the client (and hence the end-user)", it seems that in your opinion, t= he > end-user SHALL have no way to verify > whether its privacy has been respected. If this is not an architecture > built along "spy by design" principles, I don't know what else it might b= e. > > It is important to re-read two of the current definitions: > > *Privilege*: right *or attribute* associated with a subject. > > *Access Toke*n: data artifact representing a set of rights *a**nd/or > attributes*. > > In the current draft, the case of rights is indeed addressed while *the > case of attributes is fully ignored*. > > The RS is not involved in any subject information. Identity APIs, like > OpenID Connect=E2=80=99s UserInfo Endpoint, are out of scope for GNAP. > > Really ? Do you mean that an access token should not contain a "sub" clai= m > nor a "sub_id" claim and if it does, the RS SHALL ignore such claims ? > > In the "OAuth Access Token JWT Profile", there is the following sentence > in Section 6 (Privacy Considerations) : > > This profile mandates the presence of the "sub" claim in every JWT > access token, making it possible for resource servers to rely on that > information for performing tasks such as correlating incoming > requests with *data stored locally for the authenticated principal*. > > This sentence clearly makes a relationship between the value present in > the "sub" claim and "*data stored locally for the **authenticated * > *principal*". > > However, note that the "OAuth Access Token JWT Profile" fails to allow th= e > client (and hence the end-user) to control his privacy, since the client > cannot choose which value will be placed in the "sub" claim and also > because access tokens are considered to be opaque for the clients in OAut= h. > > If there is a subject identifier either included in or referenced by the > access token, that is *up to any agreements between the AS and RS* > that lead to the ability of the AS to create the tokens the RS can trust. > All of this is outside the scope of the core GNAP protocol and invisible = to > the client. > > You are using the following words "*up to any agreements between the AS > and RS*". This mandates prior agreements between ASs and RSs > and in such a case the architecture will be non-scalable over the > Internet. The trust relationship between a RS and an AS is unilateral: > The RS trusts the AS to issue appropriate access tokens corresponding to > the requests of its clients. > From an end-user point of view, if there cannot be *transparency* because > of the access token opacity, then there cannot be *confidence *about GNAP > . > > Denis > > =E2=80=94 Justin > > On Mar 26, 2021, at 1:27 PM, Denis wrote: > > Hi Justin, > > Let me rephrase the last question: How will a RS or a RO be bootstrapped > for working with a GNAP "sub" claim or a "sub_id" claim ? > > Denis > > GNAP doesn=E2=80=99t have anything too say about anybody authenticating d= irectly > to the RS. If that happens, it=E2=80=99s out of the view and out of scope= of GNAP. > > =E2=80=94 Justin > > On Mar 26, 2021, at 1:06 PM, Denis wrote: > > Hi everybody, > > The content of this thread has nothing to do any more with its original > title which was: "Will GNAP support Zero Trust Architecture?" > Since I am going to use some sentences of this thread to open a new topic= , > I changed the title of this thread into : > "Relationship between Authentication and Authorization ?" > > At the moment, I got the impression that nobody agrees any more about *wh= at > GNAP is or is not, what it should address and what it should not address*= . > The components of the model are becoming more numerous and hazy. A new > terminology is sometimes being used, but is not yet present in the last > published draft. > > I still can't understand any of the new terms that are being used (*AS-RS= * > and *AS-RO*), *which are still left undefined*. > > The last exchanges look more as conversations between workers during the > construction of the Babel tower. > > Last year, my first remark was to mention that a section or an Annex > explaining the common points and the differences with OAuth 2.0 > would be useful. Such section or Annex still does not exist. > > Justin wrote: > > *If an RS allows a username/password HTTP Basic auth in addition to > accepting access tokens, it can do so, but * > *GNAP doesn=E2=80=99t have anything to say about the Basic auth use, or e= ven its > relation to any access tokens or RO=E2=80=99s or anything else.* > > Let us split the end of this sentence into two parts: > > "*GNAP doesn=E2=80=99t have anything **to say about the Basic auth use*":= If an > authentication exchange is necessary, the draft document should describe= , > for completeness, > the HTTP error code that will be returned. > > "*or even its relation to any access tokens or RO=E2=80=99s or anything e= lse*". > Let us suppose that a RS supports FIDO as an authentication mechanism to > authenticate its end-users. > FIDO provides the major advantage that, for every RS, a different > identifier is used by every end-user. This prevents end-users accounts > correlations between RSs by using > such identifiers. In practice, a FIDO identifier is a pseudonym. > > At this very moment, the RS is able to identify and authenticate its > end-users using FIDO pseudonyms. Now, let us raise the following question= : > > How will a RS be bootstrapped for working with a GNAP "sub" claim or a > "sub_id" claim, whereas FIDO is already being used ? > > Denis > > > Adrian, > > I disagree, I believe that what I have laid out is exactly separating the > concerns into working components. > > Like OAuth before it, GNAP is a protocol negotiate access for a client > instance to an RS, using an AS as the facilitator of that delegated > negotiation. (Unlike OAuth, it=E2=80=99s importantly also for negotiating= user > information to the client directly from the AS with no RS involved, but > that=E2=80=99s an aside for the purposes of our conversation here). > > If a particular GNAP RS also allows other kinds of processes to enable > access to it, that is completely fine, but outside of GNAP. If an RS allo= ws > a username/password HTTP Basic auth in addition to accepting access token= s, > it can do so, but GNAP doesn=E2=80=99t have anything to say about the Bas= ic auth > use, or even its relation to any access tokens or RO=E2=80=99s or anythin= g else. If > an RS accepts structured access tokens signed by trusted keys that don=E2= =80=99t > come from an AS through a negotiated request =E2=80=94 again, that=E2=80= =99s fine, but GNAP > is silent about the RS doing that. If the RS acts as =E2=80=9Cits own AS= =E2=80=9D then it=E2=80=99s > really just an RS and an AS living in the same box. Again, that=E2=80=99s= fine, and > super common with OAuth today. > > GNAP is solving the problem of connecting the client to the RS through > means of an AS. Other solutions are possible and many of them can be > deployed right alongside, but that=E2=80=99s not the corner of the world = that GNAP > is solving. GNAP should be concerned about how these other technologies c= an > be used alongside it. I think there=E2=80=99s a lot of room for the thing= s that > you=E2=80=99re talking about, and more importantly for solving the use ca= ses that > you=E2=80=99re bringing. But GNAP should be more than a single-point solu= tion, and > so we need to balance these concerns. The conceptual framework of an AS > that takes in lots of different information and spits out access tokens i= s > exactly the abstraction layer that is necessary for making these use case= s > interoperable. > > =E2=80=94 Justin > > On Mar 26, 2021, at 8:30 AM, Adrian Gropper > wrote: > > @Justin, there=E2=80=99s no separation of concerns here. No partition bet= ween > processor and controller. No data minimization. And, I see no obvious > reason to make this the core of GNAP. > > The one thing we can probably all agree on is that there=E2=80=99s only o= ne RS and > one RO. > > The core of GNAP, in my opinion, can be built and explained around this > simple design. The RS is a processor. The RO is a controller. The RS bear= s > only security responsibility. The RS bears no privacy responsibility. The > RO delegates this to the RS but this is not authorization as the A in GNA= P. > > The RO retains all rights to delegate within the scope of things that the > RS is willing to support using various token formats and endpoint options= . > Some of these options may do all sorts of things for all sorts of clients > and user-agents but these are options. > > For example, if a request comes to the RS that is not in the form of an > access token, then it either gets sent to the RO or their agent, or it ge= ts > logged and dumped. One such option, common in healthcare, is =E2=80=9CBre= ak the > Glass=E2=80=9D where the RS is acting as an authorization server because = the > user-agent is making a request instead of presenting an access token. GNA= P > can offer this as an option but it is not our core. > > Adrian > > > > On Fri, Mar 26, 2021 at 7:15 AM Justin Richer wrote: > >> I have a big problem with this line: >> >> > the RS and AS-RS only see access tokens. The requests (from RO') that >> resulted in an access token are none of their business. >> >> In the trust model we=E2=80=99ve been discussing, the requests that resu= lt in >> access tokens are *solely the business of AS-RS*, since AS-RS is the >> only entity that=E2=80=99s allowed, and trusted by the RS, to create acc= ess tokens >> for the RS. That is its entire job, the entire reason it exists in the >> system. By definition the party generating tokens for use at the RS is t= he >> AS for that RS, I don=E2=80=99t care how you deploy it. If RO wants to g= ive access >> to someone else (who isn=E2=80=99t an =E2=80=9CRO" anymore, they=E2=80= =99re another end-user), then >> that end user=E2=80=99s client software will need to talk to AS-RS to ge= t its own >> access token. >> >> Now here=E2=80=99s the trick: when the end user=E2=80=99s client instanc= e talks to AS-RS, >> that does NOT mean that AS-RS needs to know all the details and policy >> reasons that it should give an access token to that client instance. It >> doesn=E2=80=99t even need to know the existence of another end user. It = doesn=E2=80=99t >> need identity, it doesn=E2=80=99t need policy. Sure, it COULD handle all= of that >> internally, and many will, but the protocol doesn=E2=80=99t demand it. >> >> This means that the first client instance, the one that gets the access >> token, can also be given something alongside the access token that it ca= n >> then hand to another piece of software (or to a person to hand eo their >> piece of software). This artifact is not an access token. This artifact >> could be something structured that the client understands, and can make >> derivatives of, and present back to the AS-RS for getting new access >> tokens. There could be multiple different flavors of this kind of artifa= ct >> for different kinds of environments and groups. But what they all have i= n >> common is that they can potentially be used to request more access token= s >> within some context at the AS-RS. >> >> =E2=80=94 Justin >> >> >> >> On Mar 25, 2021, at 5:50 PM, Adrian Gropper >> wrote: >> >> My issue is with Alan's: >> >> "7. Another user agent (RO') can contact any holder of the access token >> or the service's policy agent (AS-RS) to get a delegated access token." >> >> >> I would prefer "7A. Another user agent (RO') can contact any holder of >> the access token." by default so that the AS-RS does not see the request= s. >> In other words, the RS and AS-RS only see access tokens. The requests (f= rom >> RO') that resulted in an access token are none of their business. >> >> The reality is that RO' can discover a resource RS and can share whateve= r >> information with RS-AS they want and the RO may not even know about it >> unless the RS decides to let them know somehow. This seems to be a drawb= ack >> of the capabilities approach. >> >> In terms of privacy and control, I, as the RO, want a contract with the >> RS that says that I or my agent (AS-RO) must sign an access token. This = is >> a fundamental audit requirement. Without it, a rogue RS and AS-RS can do >> all sorts of things and the RO would never know. I understand that a rog= ue >> RS might not support an honest contemporaneous log of access tokens >> presented so there's a trust issue here that I seems unavoidable unless = I >> specify in my RO-RS contract that they use a separate contemporaneous lo= g >> such as AS-RO for every access token presented and risk being sued if th= ey >> process an access token without also updating the separate log. >> >> - Adrian >> >> >> On Thu, Mar 25, 2021 at 1:22 PM Alan Karp wrote: >> >>> Justin Richer wrote: >>> >>>> Hi Alan, >>>> >>>> In all of my discussion, and in the spec itself, the RO is the :entity= : >>>> in charge of approving rights. They=E2=80=99re probably a person. It m= ight be >>>> software that makes a policy decision in some way, or a corporate enti= ty, >>>> or something like that. But it=E2=80=99s not assumed to be a computati= onal agent in >>>> the terms of the protocol itself. Would that recast what you=E2=80=99r= e saying >>>> below? >>>> >>> >>> Hmmm. I guess not. It's just that the person would be using some UI t= o >>> express their decisions to what I called the user agent. That model fi= ts >>> in very nicely with what we did with Polaris, our virus safe computing >>> environment for Windows XP, >>> https://dl.acm.org/doi/10.1145/1151030.1151033. The person would click >>> on the icon for a Word file, and an instance of Word would open with on= ly >>> the permission needed to edit that one file. Same thing here. The cli= ent >>> could ask for permission to use the resource, or permission could be >>> granted implicitly when the user selects a resource associated with a >>> specific client. >>> >>> -------------- >>> Alan Karp >>> >>> >>> On Thu, Mar 25, 2021 at 9:53 AM Justin Richer wrote: >>> >>>> Hi Alan, >>>> >>>> In all of my discussion, and in the spec itself, the RO is the :entity= : >>>> in charge of approving rights. They=E2=80=99re probably a person. It m= ight be >>>> software that makes a policy decision in some way, or a corporate enti= ty, >>>> or something like that. But it=E2=80=99s not assumed to be a computati= onal agent in >>>> the terms of the protocol itself. Would that recast what you=E2=80=99r= e saying >>>> below? >>>> >>>> =E2=80=94 Justin >>>> >>>> On Mar 25, 2021, at 12:36 PM, Alan Karp wrote: >>>> >>>> There seems to be some confusion about how AS-RO comes into the >>>> picture, probably because of the "AS" part. I'm going to try to clear= up >>>> that confusion by more carefully explaining what I mean. >>>> >>>> I'm assuming that RO is a computational agent representing the person >>>> who is the resource owner, something called the "user agent" in operat= ing >>>> systems lingo. I'm also assuming that it's possible to do delegation, >>>> either locally or by token exchange with AS-RS. All delegations are >>>> potentially sub-scoped, but you may also want to delegate with full sc= ope >>>> to have a separately revocable access token. >>>> >>>> Here's an example of how things work in a capability oriented system= . >>>> >>>> 1. Someone, the service owner, creates a service. >>>> 2. The service owner contracts with an policy agent (AS-RS) to >>>> create and manage access tokens for that service (RS). >>>> 3. A person wishing to create a resource at RS uses their user >>>> agent (RO) to contact the service owner's policy agent (AS-RS) and = gets >>>> back an access token for that resource. >>>> 4. That user agent (RO) can >>>> 1. use that access token to invoke the resource, or >>>> 2. delegate an access token to a client of the user agent's (RO) >>>> choice, or >>>> 3. contract with a policy agent (AS-RO) to manage those >>>> delegations on behalf of the user agent (RO), or >>>> 4. specify a policy with the service's policy agent (AS-RS). >>>> 5. A client can contact any holder of the access token (the user >>>> agent (RO) or its policy agent (AS-RO)) or the service's policy age= nt >>>> (AS-RS) to get a delegated access token. >>>> 6. That client can delegate that token to another client. >>>> 7. Another user agent (RO') can contact any holder of the access >>>> token or the service's policy agent (AS-RS) to get a delegated acce= ss token. >>>> 8. The other user agent (RO') can >>>> 1. use that access token to invoke the resource, or >>>> 2. delegate it to a client of its choice, or >>>> 3. contract with a policy agent (AS-RO') of its choosing to >>>> manage those delegations on its behalf, or >>>> 4. specify a policy with the service's policy agent (AS-RS). >>>> 9. and so on >>>> >>>> When any of these computational agents, user agents (ROs) or clients >>>> acting on their behalf, invokes the resource, AS-RS verifies that the >>>> access token is a valid delegation, i.e., proper sub-scoping, hasn't b= een >>>> revoked, and that it authorizes the request being made before telling = the >>>> service (RS) to honor the request. At no point does the service's pol= icy >>>> agent (AS-RS) know which computational agent did any particular >>>> delegation. (Token exchange can be done as anonymously as possible.) = In >>>> particular, the policy agents (AS-RO) need not be the same, or even >>>> compatible with, the service's policy agent (AS-RS). GNAP specifies t= he >>>> protocol between requesters, invokers, delegators (for token exchange)= of >>>> tokens and AS-RS. That protocol need not be used between user agents = (RO), >>>> clients, or other policy agents (AS-RO), but it is likely to be. >>>> >>>> ------------- >>>> Alan Karp >>>> >>>> >>>> On Thu, Mar 25, 2021 at 5:45 AM Justin Richer wrote: >>>> >>>>> The way I=E2=80=99m thinking about Adrian=E2=80=99s use case is that = what we=E2=80=99re >>>>> calling the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an =E2=80=9CAS=E2= =80=9D in the traditional OAuth/GNAP sense, at >>>>> least not exactly. This is the agent that the RO can use to set polic= ies >>>>> and manage consent on their behalf, and I=E2=80=99ve been arguing tha= t it fits >>>>> better into this vaguely-defined =E2=80=9Cinteraction component=E2=80= =9D aspect of the >>>>> current AS definition, and it=E2=80=99s not currently separated from = the AS >>>>> definition. The =E2=80=9CAS-RS=E2=80=9D maps to what we=E2=80=99d cal= l the =E2=80=9CAS=E2=80=9D in OAuth/GNAP >>>>> traditionally, it=E2=80=99s what the RS trusts to issue tokens. In tr= aditional >>>>> OAuth the AS-RO and AS-RS are always the same thing, from a functiona= l >>>>> protocol perspective. An important point here is that from a client= =E2=80=99s >>>>> perspective, they=E2=80=99re only talking to the AS-RS since that=E2= =80=99s where the >>>>> client gets its tokens, because at the end of the day the client just= wants >>>>> to call the API at the RS and doesn=E2=80=99t care how that happens (= from a >>>>> protocol standpoint). >>>>> >>>>> Note well: Even thought I don=E2=80=99t believe that =E2=80=9CAS-RO= =E2=80=9D is an >>>>> authorization server at all, I=E2=80=99m going to keep using that ter= m below for >>>>> consistency with previous discussion. >>>>> >>>>> So we have these fundamental relationships around getting the client >>>>> to access the RS: >>>>> >>>>> 1. RS trusts AS-RS to issue tokens that RS will accept, validate, and >>>>> process for requests from client >>>>> 2. Client trusts AS-RS to issue tokens that client can use at RS >>>>> 3. RO trusts RS to protect RO=E2=80=99s api through delegated access >>>>> >>>>> On top of that, we=E2=80=99ve got some additional aspects that we=E2= =80=99re >>>>> discussing: >>>>> >>>>> 4. RO trusts AS-RO to manage RO=E2=80=99s policies at runtime >>>>> 5. AS-RS trusts AS-RO to assert RO=E2=80=99s policies for access to R= S >>>>> 6. Client trusts whatever AS-RS sends client to deal with, including >>>>> possibly RO-AS at runtime, because of (2) >>>>> >>>>> What I have been saying is that 4/5/6 are optional details of how >>>>> RS-AS runs things, and I think this also maps with Adrian=E2=80=99s v= iew of choice, >>>>> since if my RS=E2=80=99s AS-RS doesn=E2=80=99t allow me to plug in my= own AS-RO then I >>>>> would be motivated to pick a different RS who=E2=80=99s AS-RS lets me= do just that. >>>>> The same way I=E2=80=99d pick a different RS if their surrounding ser= vices didn=E2=80=99t >>>>> accept my preferred federation login and I didn=E2=80=99t want to mak= e another >>>>> account. Of course, market forces being as they are, I might not have= much >>>>> of an actionable choice in RS, but GNAP can=E2=80=99t change that. >>>>> >>>>> What we can do is make it possible for AS-RS to talk to AS-RO, both i= n >>>>> philosophy of the protocol design and in concrete hooks to support (6= ) >>>>> above. >>>>> >>>>> Separately, we can approach the issue of making 1/2 above more >>>>> dynamic. This was UMA2=E2=80=99s =E2=80=9Cfederated authorization=E2= =80=9D approach, and is behind >>>>> a lot of the =E2=80=9Cbring your own AS=E2=80=9D models out there. Th= e problem with these >>>>> is that we know from many years of experience that most RS=E2=80=99s = aren=E2=80=99t >>>>> interested in doing anything of the sort. >>>>> >>>>> So with GNAP we can instead allow 4/5/6 to vary in a predictable and >>>>> consistent way, letting the RS keep control over 1/2, thereby enablin= g >>>>> choice in (3). We don=E2=80=99t have to be the ones who define the al= l of the >>>>> details of every permutation of (5) to enable this, though. Some of t= his is >>>>> going to be configuration out of band, some of it=E2=80=99s going to = be >>>>> communication at runtime. This is where VC=E2=80=99s, ZCAPs, CHAPI, D= IDComm, FIDO, >>>>> and a whole swath of other tech can come in and help out. I don=E2=80= =99t think we >>>>> need to put all the details for using these into core, nor do I think= we=E2=80=99ll >>>>> pull of The Great And Ultimate Abstraction for using these and other >>>>> approaches. But we can at least start talking about =E2=80=9CAS-RS=E2= =80=9D in such a way >>>>> that it no longer assumes it=E2=80=99s always the same party dealing = with the RO >>>>> directly. >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Mar 25, 2021, at 6:40 AM, Fabien Imbault >>>>> wrote: >>>>> >>>>> To reframe it closer to GNAP: >>>>> - AS =3D AS-RO, that's where you find the RO policies. The AS issues >>>>> access tokens to the client. >>>>> - the RO policies could be a) defined locally or b) in relationship >>>>> with the RS >>>>> >>>>> There have been several ideas related to the AS-RS relationship b: >>>>> b1) the RS issues capabilities (which can be further attenuated by th= e >>>>> RO) >>>>> b2) Adrian also discussed a DID based solution >>>>> b3) there was also an alternative ACL proposal from Denis (+ prefligh= t) >>>>> >>>>> --0000000000006a8bed05beac4edc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Denis,

    I don=E2=80=99t understand your privacy issue, and I would like to try.= =C2=A0

    Let Alice be the = RO and subject of a resource. at a RS. Let Bob be a party, not Alice, that = seeks authorization to access the resource using an access token.=C2=A0

    Bob has discovered the reso= urce somehow that is out of band for GNAP. (Maybe Alice sent Bob a pointer = to the resource in an email).

    Bob makes a request for the resource at some AS. The request includes= the pointer that Bob discovered to the resource, some attributes or claims= about Bob, and maybe a reason for the request.=C2=A0

    How Bob discovered the AS to make the request= to is unclear to me for the time being. Maybe Bob discovered the AS along = with the resource. (e.g The resource is a DID and the AS is a service endpo= int or mediator to an AS in that DID.)

    Given the scenario above, who=E2=80=99s privacy interest are= you primarily concerned=C2=A0about? Alice or Bob?=C2=A0

    Adrian

    On Mon, Mar 29, 2021 at 6:39 AM= Denis <denis.ietf@free.fr>= wrote:
    =20 =20 =20
    Hi=C2=A0 Justin,

    Since your response only deals with the AS, but not the RS nor the RO, it is not a response to my question which was:
    How will a RS or a RO be bootstrapped for working with a GNAP "sub" claim or a "sub_id&quo= t; claim ?
    The subject identifier is whatever identifier the AS knows the subject as. If they log in using only a FIDO token and the AS asserts that key value as the identifier, then that=E2=80=99s what it will be. If = they sign up with an email address or make a username or get assigned a random number, that=E2=80=99s what it will be. Or they could sign up = using any number of those and the AS still assigns them a random value, because it=E2=80=99s always the AS that determines which value to ass= ign the number.

    When looking at Section 3.2 (Access Tokens), the client (and hence the end-user) has currently no practical way to indicate which of its attributes should be placed into an access token,
    The only reference within Section 3.2 is pointing to the empty Section 12. Among the many examples, there is not a single example that addresses the case of attributes being placed into an access token.

    Nevertheless, it seems that in your opinion, only the AS, but NOT the client (and hence the end-user), SHALL have control at all of what kind of subject identifier claim will be placed inside the access token.

    Then after, invoking the postulate "the access token SHALL remai= n opaque to the client (and hence the end-user)", it seems that in your opinion, the end-user SHALL have no way to verify
    whether its privacy has been respected. If this is not an architecture built along "spy by design" principles, I don&= #39;t know what else it might be.

    It is important to re-read two of the current definitions:

    Privilege: right or attribute associated with a subject.

    Access Token: data artifact representing a set of rights and/or attributes.

    In the current draft, the case of rights is indeed addressed while the case of attributes is fully ignored.

    The RS is not involved in any subject information. Identity APIs, like OpenID Connect=E2=80=99s UserInfo Endpoint, are= out of scope for GNAP.

    Really ? Do you mean that an access token should not contain a "sub" claim nor a "sub_id" claim=C2=A0 and if it = does, the RS SHALL ignore such claims ?

    In the "OAuth Access Token JWT Profile", there is the foll= owing sentence in Section 6 (Privacy Considerations) :

    =C2=A0=C2=A0 This profile mandates the presence of the "sub&q= uot; claim in every JWT
    =C2=A0=C2=A0 access token, making it possible for resource servers = to rely on that
    =C2=A0=C2=A0 information for performing tasks such as correlating i= ncoming
    =C2=A0=C2=A0 requests with data stored locally for the authentic= ated principal.=C2=A0

    This sentence clearly makes a relationship between the value present in the "sub" claim and "data stored locally for the <= /i>authenticated principal".

    However, note that the "OAuth Access Token JWT Profile" fails= to allow the client (and hence the end-user) to control his privacy, since the client
    cannot choose which value will be placed in the "sub" claim a= nd also because access tokens are considered to be opaque for the clients in OAuth.
    If there is a subject identifier either included in or referenced by the access token, that is up to any agreements between the AS and RS
    that lead to the ability of the AS to create the tokens the RS can trust. All of this is outside the scope of the core GNAP protocol and invisible to the client.

    You are using the following words "up to any agreements between the AS and RS". This mandates prior agreements between ASs and RSs
    and in such a case the architecture will be non-scalable over the Internet. The trust relationship between a RS and an AS is unilateral:
    The RS trusts the AS to issue appropriate access tokens corresponding to the requests of its clients.

    From an end-user point of view, if there cannot be transparency because of the access token opacity, then there cannot be con= fidence about GNAP .

    Denis


    =C2=A0=E2=80=94 Justin

    On Mar 26, 2021, at 1:27 PM, Denis <denis.ietf@free.fr> wrote:
    =20
    Hi Justin,

    Let me rephrase the last question: How will a RS or a RO be bootstrapped for working with a GNAP "sub" claim or a "sub_= id" claim ?

    Denis

    GNAP doesn=E2=80=99t have anythi= ng too say about anybody authenticating directly to the RS. If that happens, it=E2=80=99s out of the view and out of scope of GNAP.

    =C2=A0=E2=80=94 Justin

    On Mar 26, 2021, at 1:06 PM, Denis <denis.ietf@free.fr> wrote:

    Hi everybody,

    The content of this thread has nothing to do any more with its original title which was: "Will GNAP support Zero Trust Architecture?"
    Since I am going to use some sentences of this thread to open a new topic, I changed the title of this thread into :
    "Relationship between Authentication a= nd Authorization ?"

    At the moment, I got the impression that nobody agrees any more about what GNAP is or is not, what it should address and what it should not address.
    The components of the model are becoming more numerous and hazy. A new terminology is sometimes being used, but is not yet present in the last published draft.

    I still can't understand any of the new terms that are being used (AS-RS and AS-RO), which are still left undefined.

    The last exchanges look more as conversations between workers during the construction of the Babel tower.

    Last year, my first remark was to mention that a section or an Annex explaining the common points and the differences with OAuth 2.0
    would be useful. Such section or Annex still does not exist.

    Justin wrote:
    If an RS allows a username/password HTTP Basic auth in addition to accepting access tokens, it can do so, but
    GNAP doesn=E2=80=99t have anything to say about the Basic auth use, or even its relation to any access tokens or RO=E2=80=99s or anythi= ng else.
    Let us split the end of this sentence into two parts:

    "GNAP doesn=E2=80=99t have anything to say about the Basic auth use":= =C2=A0 If an authentication exchange=C2=A0 is necessary, the draft document should describe, for completeness,
    the HTTP error code that will be returned.

    "or even its relation to any access tokens or RO=E2=80=99s or anything else"= ;. Let us suppose that a RS supports FIDO as an authentication mechanism to authenticate its end-users.
    FIDO provides the major advantage that, for every RS, a different identifier is used by every end-user. This prevents end-users accounts correlations between RSs by using
    such identifiers. In practice, a FIDO identifier is a pseudonym.

    At this very moment, the RS is able to identify and authenticate its end-users using FIDO pseudonyms. Now, let us raise the following question:

    How will a RS be bootstrapped for working with a GNAP "sub" claim or a "sub= _id" claim, whereas FIDO is already being used ?

    Denis


    Adrian,

    I disagree, I believe that what I have laid out is exactly separating the concerns into working components.=C2=A0

    Like OAuth before it, GNAP is a protocol negotiate access for a client instance to an RS, using an AS as the facilitator of that delegated negotiation. (Unlike OAuth, it=E2=80=99s importantly also for negotiating user information to the client directly from the AS with no RS involved, but that=E2=80=99s an aside for the purposes = of our conversation here).

    If a particular GNAP RS also allows other kinds of processes to enable access to it, that is completely fine, but outside of GNAP. If an RS allows a username/password HTTP Basic auth in addition to accepting access tokens, it can do so, but GNAP doesn=E2=80=99t have anything to= say about the Basic auth use, or even its relation to any access tokens or RO=E2=80= =99s or anything else. If an RS accepts structured access tokens signed by trusted keys that don=E2=80=99t come from= an AS through a negotiated request =E2=80=94 again, that=E2=80=99s fine, but GNAP is s= ilent about the RS doing that. If the RS acts as =E2=80=9Cits own AS=E2=80=9D then= it=E2=80=99s really just an RS and an AS living in the same box. Again, that=E2=80=99s fine, and super common with OAuth today.=C2=A0

    GNAP is solving the problem of connecting the client to the RS through means of an AS. Other solutions are possible and many of them can be deployed right alongside, but that=E2=80=99s not the corner of the = world that GNAP is solving. GNAP should be concerned about how these other technologies can be used alongside it. I think there=E2=80=99s a lot of room for= the things that you=E2=80=99re talking about,= and more importantly for solving the use cases that you=E2=80=99re bringing. But G= NAP should be more than a single-point solution, and so we need to balance these concerns. The conceptual framework of an AS that takes in lots of different information and spits out access tokens is exactly the abstraction layer that is necessary for making these use cases interoperable.

    =C2=A0=E2=80=94 Justin

    On Mar 26, 2021, at 8:30 AM, Adrian Gropper <agropper@healthurl.com= > wrote:

    @Justin, there=E2=80=99s no separation of concerns here. No partition between processor and controller. No data minimization. And, I see no obvious reason to make this the core of GNAP.=C2=A0

    The one thing we can probably all agree on is that there=E2=80=99s = only one RS and one RO.=C2=A0

    The core of GNAP, in my=C2=A0opinion, can be built and explained around this simple design. The RS is a processor. The RO is a controller. The RS bears only security responsibility. The RS bears no privacy responsibility. The RO delegates this to the RS but this is not authorization as the A in GNAP.

    The RO retains all rights to delegate within the scope of things that the RS is willing to support using various token formats and endpoint options. Some of these options may do all sorts of things for all sorts of clients and user-agents =C2=A0but these are options.=C2=A0

    For example, if a request comes to the RS that is not in the form of an access token, then it either gets sent to the RO or their agent, or it gets logged and dumped. One such option, common in healthcare, is =E2=80=9CBreak the Glass=E2=80=9D= where the RS is acting as an authorization server because the user-agent is making a request instead of presenting an access token. GNAP can offer this as an option but it is not our core.

    Adrian



    On Fri, Mar 26, 2021 at 7:15 AM Justin Richer <jricher@mit.edu> wrote:
    I have a big problem with this line:

    >=C2=A0the RS and AS-RS only see access tokens. The requests (from RO') that resulted in an access token are none of their business.

    In the trust model we=E2=80= =99ve been discussing, the requests that result in access tokens are solely= the business of AS-RS, since AS-RS is the only entity that=E2=80=99s allow= ed, and trusted by the RS, to create access tokens for the RS. That is its entire job, the entire reason it exists in the system. By definition the party generating tokens for use at the RS is the AS for that RS, I don=E2=80=99t care how you deploy it. If RO wants to give access to someone else (who isn=E2=80= =99t an =E2=80=9CRO" anymor= e, they=E2=80=99re another end-user), then that end user=E2=80=99s cli= ent software will need to talk to AS-RS to get its own access token.

    Now here=E2=80=99s the trick: when the end user=E2=80=99s client instance talks to AS-RS, that does NOT mean that AS-RS needs to know all the details and policy reasons that it should give an access token to that client instance. It doesn=E2=80= =99t even need to know the existence of another end user. It doesn=E2=80= =99t need identity, it doesn=E2=80=99t need poli= cy. Sure, it COULD handle all of that internally, and many will, but the protocol doesn=E2=80=99t demand it= .=C2=A0

    This means that the first client instance, the one that gets the access token, can also be given something alongside the access token that it can then hand to another piece of software (or to a person to hand eo their piece of software). This artifact is not an access token. This artifact could be something structured that the client understands, and can make derivatives of, and present back to the AS-RS for getting new access tokens. There could be multiple different flavors of this kind of artifact for different kinds of environments and groups. But what they all have in common is that they can potentially be used to request more access tokens within some context at the AS-RS.

    =C2=A0=E2=80=94 Justin=



    On Mar 25, 2021, at 5:50 PM, Adrian Gropper <agropper@healthurl.com&g= t; wrote:

    My issue is with Alan's:
    "7. Another user agent (RO') can contact any holder of the access token or the service's policy agent (AS-RS) to get a delegated access token.&quo= t;

    I would prefer "7A.=C2= =A0Another user agent (RO') can contact any holder of the access token.&quo= t; by default so that the AS-RS does not see the requests. In other words, the RS and AS-RS only see access tokens. The requests (from RO') that resulted in an access token are none of their business.<= /font>
    The reality is that RO' can discover a resource RS and can share whatever information with RS-AS they want and the RO may not even know about it unless the RS decides to let them know somehow. This seems to be a drawback of the capabilities approach.=C2=A0
    In terms of privacy and control, I, as the RO, want a contract=C2=A0wit= h the RS that says that I or my agent (AS-RO) must sign an access token. This is a fundamental audit requirement. Without it, a rogue RS and AS-RS can do all sorts of things and the RO would never know. I understand that a rogue RS might not support an honest contemporaneous log of access tokens presented so there's a trust issue here that I seems unavoidable unless I specify in my RO-RS contract that they use a separate contemporaneous= =C2=A0log such as AS-RO for every access token presented and risk being sued if they process an access token without also updating the separate log.
    - Adrian


    On Thu, Mar 25, 2021 at 1:22 PM Alan Karp <alanhkarp@gmail.com&g= t; wrote:
    Justin Richer <jricher@mit.edu> wrote:
    Hi Alan,

    In all of my discussion, and in the spec itself, the RO is the :entity: in charge of approving rights. They=E2=80=99re probably a person. It might be software that makes a policy decision in some way, or a corporate entity, or something like that. But it=E2= =80=99s not assumed to be a computational agent in the terms of the protocol itself. Would that recast what you=E2=80=99= re saying below?
    =
    Hmmm.=C2=A0 I guess not.=C2= =A0 It's just tha= t the person would be using some UI to express their decisions to what I called the user agent.=C2=A0 That model fits in very nicely with what we did with Polaris, our virus safe computing environment for Windows XP, https://dl.= acm.org/doi/10.1145/1151030.1151033.=C2=A0 The person would click on the icon for a Word file, and an instance of Word would open with only the permission needed to edit that one file.=C2=A0 Same thing here.=C2=A0 The client could ask for permission to use the resource, or permission could be granted implicitly when the user selects a resource associated with a specific client.
    =
    -------------- Alan Karp


    On Thu, Mar 25, 2021 at 9:53 AM Justin Richer <jricher@mit.edu> wrote:
    Hi Alan,

    In all of my discussion, and in the spec itself, the RO is the :entity: in charge of approving rights. They=E2=80=99re probably a person. It might be software that makes a policy decision in some way, or a corporate entity, or something like that. But it=E2= =80=99s not assumed to be a computational agent in the terms of the protocol itself. Would that recast what you=E2=80=99= re saying below?

    =C2=A0=E2=80= =94 Justin

    On Mar 25, 2021, at 12:36 PM, Alan Karp <alanhkarp@gmail.com> wrote:

    = There seems to be some confusion about how AS-RO comes into the picture, probably because of the "AS" pa= rt.=C2=A0 I'm going to try to clear up that confusion by more carefully explaining what I mean.

    I'm assuming that RO is a computational agent representing the person who is the resource owner, something called the "user agent&= quot; in operating systems lingo.=C2=A0 I= 9;m also assuming that it's possible to do delegation, either locally or by token exchange with AS-RS.=C2=A0 All delegations are potentially sub-scoped, but you may also want to delegate with full scope to have a separately revocable access token.

    =C2=A0 Here's an example of how things work in a capability oriented system.
    1. Someone, the service owner, creates a service.
    2. The service owner contracts with an policy agent (AS-RS) to create and manage access tokens for that service (RS).
    3. A person wishing to create a resource at RS uses their user agent (RO) to contact the service owner's polic= y agent (AS-RS) and gets back an access token for that resource.
    4. That user agent (RO) can=C2=A0
      1. use that access token to invoke the resource, or
      2. delegate an access token to a client of the user agent's (RO) choice, or
      3. contract with a policy agent (AS-RO) to manage those delegations on behalf of the user agent (RO), or
      4. specify a policy with the service's policy agent (AS-RS).
    5. A client can contact any holder of the access token (the user agent (RO) or its policy agent (AS-RO)) or the service's policy agent (AS-RS) to get a delegated access token.
    6. That client can delegate that token to another client.
    7. Another user agent (RO') can contact any holder of the access token or the service's policy agent (AS-RS) to get a delegated access token.
    8. The other user agent (RO') can=C2=A0
      1. use that access token to invoke the resource, or
      2. delegate it to a client of its choice, or
      3. contract with a policy agent (AS-RO'= ) of its choosing to manage those delegations on its behalf, or
      4. specify a policy with the service's policy agent (AS-RS).
    9. and so on
    When any of these computational agents, user agents (ROs) or clients acting on their behalf, invokes the resource, AS-RS verifies that the access token is a valid delegation, i.e., proper sub-scoping, hasn't been revoked, and that it authorizes the request being made before telling the service (RS) to honor the request.=C2=A0 At no point does the service's policy agent (AS-RS) know which computational agent did any particular delegation.=C2=A0 (Token exchange can be done as anonymously as possible.)=C2=A0 = In particular, the policy agents (AS-RO) need not be the same, or even compatible with, the service's policy agent (AS-RS).=C2=A0 GN= AP specifies the protocol between requesters, invokers, delegators (for token exchange) of tokens and AS-RS.=C2=A0 That protocol need not be used between user agents (RO), clients, or other policy agents (AS-RO), but it is likely to be.

    =C2=A0------= -------
    = Alan Karp


    On Thu, Mar 25, 2021 at 5:45 AM Justin Richer <jricher@mit.edu> wrote:
    The way I=E2=80=99m thinking about Adrian=E2=80=99s = use case is that what we=E2=80=99r= e calling the =E2=80=9CAS-RO=E2= =80=9D isn=E2=80=99t an =E2=80=9CAS=E2= =80=9D in the traditional OAuth/GNAP sense, at least not exactly. This is the agent that the RO can use to set policies and manage consent on their behalf, and I=E2=80=99ve been arguing that it fits better into this vaguely-defined =E2=80=9Cinteract= ion component=E2=80= =9D aspect of the current AS definition, and it=E2=80=99s = not currently separated from the AS definition. The =E2=80=9CAS-R= S=E2=80=9D maps to what we=E2=80=99d call= the =E2=80=9CAS=E2=80= =9D in OAuth/GNAP traditionally, it=E2=80=99s what= the RS trusts to issue tokens. In traditional OAuth the AS-RO and AS-RS are always the same thing, from a functional protocol perspective. An important point here is that from a client=E2=80=99s perspective, they=E2=80=99re o= nly talking to the AS-RS since that=E2=80=99s wh= ere the client gets its tokens, because at the end of the day the client just wants to call the API at the RS and doesn=E2=80=99t c= are how that happens (from a protocol standpoint).=C2= =A0

    Note well: Even thought I don=E2=80=99t bel= ieve that =E2=80=9CAS-= RO=E2=80=9D is an authorization server at all, I=E2=80=99m going= to keep using that term below for consistency with previous discussion.

    So we have these fundamental relationships around getting the client to access the RS:

    1. RS trusts=C2=A0AS-RS= =C2=A0to issue tokens that RS will accept, validate, and process for requests from client
    2. Client trusts=C2=A0AS-RS= =C2=A0to issue tokens that client can use at RS
    3. RO trusts RS to protect RO=E2=80=99s api through delegated access

    On top of that, we=E2=80=99ve got= some additional aspects that we=E2=80=99re discussing:

    4. RO trusts=C2=A0AS-RO= =C2=A0to manage RO=E2=80= =99s policies at runtime
    5.=C2=A0AS-R= S=C2=A0trusts=C2=A0AS-RO=C2=A0to assert RO=E2=80= =99s policies for access to RS
    6. Client trusts whatever=C2=A0AS-RS=C2=A0sends client to deal with, including possibly RO-A= S at runtime, because of (2)

    What I have been saying is that 4/5/6 are optional details of how RS-AS runs things, and I think this also maps with Adrian=E2=80=99s = view of choice, since if my RS=E2=80=99s AS-R= S doesn=E2=80=99t a= llow me to plug in my own AS-RO then I would be motivated to pick a different RS who=E2=80=99s AS-= RS lets me do just that. The same way I=E2=80= =99d pick a different RS if their surrounding services didn=E2=80=99t ac= cept my preferred federation login and I didn=E2=80=99t wa= nt to make another account. Of course, market forces being as they are, I might not have much of an actionable choice in RS, but GNAP can=E2= =80=99t change that.=C2= =A0

    What we can do is make it possible for AS-RS to talk to AS-RO, both in philosophy of the protocol design and in concrete hooks to support (6) above.=C2=A0

    Separately, we can approach the issue of making 1/2 above more dynamic. This was UMA2=E2=80=99= s =E2=80=9Cfederate= d authorization=E2= =80=9D approach, and is behind a lot of the =E2=80=9Cbring yo= ur own AS=E2=80=9D m= odels out there. The problem with these is that we know from many years of experience that most RS=E2= =80=99s aren=E2=80=99t interested in doing anything of the sort.

    So with GNAP we can instead allow 4/5/6 to vary in a predictable and consistent way, letting the RS keep control over 1/2, thereby enabling choice in (3). We don=E2=80=99t = have to be the ones who define the all of the details of every permutation of (5) to enable this, though. Some of this is going to be configuration out of band, some of it=E2=80= =99s going to be communication at runtime. This is where VC=E2=80=99s, ZCA= Ps, CHAPI, DIDComm, FIDO, and a whole swath of other tech can come in and help out. I don=E2=80= =99t think we need to put all the details for using these into core, nor do I think we=E2=80=99ll pul= l of The Great And Ultimate Abstraction for using these and other approaches. But we can at least start talking about =E2=80=9CAS-RS=E2= =80=9D in such a way that it no longer assumes it=E2=80=99s alwa= ys the same party dealing with the RO directly.

    --0000000000006a8bed05beac4edc-- From nobody Mon Mar 29 06:54:11 2021 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 72A103A135F for ; Mon, 29 Mar 2021 06:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 ClRUbfVjcYMA for ; Mon, 29 Mar 2021 06:54:03 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp01.smtpout.orange.fr [80.12.242.123]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08E9B3A135C for ; Mon, 29 Mar 2021 06:54:01 -0700 (PDT) Received: from [192.168.1.11] ([90.79.53.231]) by mwinf5d54 with ME id mDtv240034zJUWJ03DtvKD; Mon, 29 Mar 2021 15:53:59 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Mon, 29 Mar 2021 15:53:59 +0200 X-ME-IP: 90.79.53.231 To: Adrian Gropper Cc: Justin Richer , txauth@ietf.org References: <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> <5773FA7B-6891-4227-A8CA-2F506909B8CD@mit.edu> <3c103293-56a1-4be5-e2a3-12eb82d13238@free.fr> <91D11E67-34AB-4426-803C-7B5A6F50537F@mit.edu> From: Denis Message-ID: Date: Mon, 29 Mar 2021 15:53:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------24DA77526879476BC8EB2489" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Relationship between Authentication and Authorization ? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2021 13:54:10 -0000 This is a multi-part message in MIME format. --------------24DA77526879476BC8EB2489 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Adrian, Thank you for the scenario. You certainly know the following sentence: "When the only tool you have is a hammer, every problem looks like a nail". Similarly:  "When the only tool you have is an AS, every problem looks like an access token issued by an AS". Let us start with exactly the same sentence that explains the goal: Let Alice be the RO and subject of a resource. at a RS. Let Bob be a party, not Alice, that seeks authorization to access the resource using an access token. Then Bob asks to Alice to issue for him an authorization to access the resource. Alice, as the RO of the resource, request from the RS an "/access token/"  which is an (unsigned) data structure which contains: a read permission on some Alice's photo directory, associated with a large random number /chosen by the RS/. Note that a validity period will also be associated in practice, but this is a minor detail for the demonstration. Alice sends back to Bob the "/access token/" issued by the RS. *Bob looks inside the access token* to make sure that it corresponds to what he requested to Alice, i.e. a read permission on some Alice's photo directory. If the content is fine, Bob presents to the RS the large random number associated together with an API GET for some sub-set of the photos contained in Alice's directory. Since the RS recognizes the large random number and that the GET API is valid according to the "access token" memorized by the RS authorization set by Alice as a RO, the access is granted. In this example, the RS will not know who is reading the photo directory. So Bob can transmit the "access token" to someone else during its validity period, which may be a desirable feature. Note that it is also possible to allow Bob only to access Alice's directory. For simplicity, this alternative is not explained. In the mean time, I solved the answer of your question which was:" /How Bob discovered the AS to make the request to is unclear to me for the time being/". The request to your question is also unclear to me for the time being, but since there is no AS involved, Bob does not need to discover any AS. :-) I am quite sure that someone else will be able to describe one or more scenarios "/using an AS as an hammer/", but is is very likely that in such a case, the AS will be able know that Bob is rather likely to access in a short time some photos placed in the Alice's directory of photo hosted on that RS. / This may be a privacy concern for Bob/. Of course, in addition, the AS and the RS must establish some prior relationships, etc ... However, all the discussion above is outside the scope of this initial thread which is: Relationship between Authentication and Authorization ? If you want to continue the discussion on the topic you mentioned, that's fine with me, but please change the title of this thread. Denis > Hi Denis, > > I don’t understand your privacy issue, and I would like to try. > > Let Alice be the RO and subject of a resource. at a RS. Let Bob be a > party, not Alice, that seeks authorization to access the resource > using an access token. > > Bob has discovered the resource somehow that is out of band for GNAP. > (Maybe Alice sent Bob a pointer to the resource in an email). > > Bob makes a request for the resource at some AS. The request includes > the pointer that Bob discovered to the resource, some attributes or > claims about Bob, and maybe a reason for the request. > > How Bob discovered the AS to make the request to is unclear to me for > the time being. Maybe Bob discovered the AS along with the resource. > (e.g The resource is a DID and the AS is a service endpoint or > mediator to an AS in that DID.) > > Given the scenario above, who’s privacy interest are you primarily > concerned about? Alice or Bob? > > Adrian > > On Mon, Mar 29, 2021 at 6:39 AM Denis > wrote: > > Hi  Justin, > > Since your response only deals with the AS, but not the RS nor the > RO, it is not a response to my question which was: > > How will a RS or a RO be bootstrapped for working with a GNAP > "sub" claim or a "sub_id" claim ? > >> The subject identifier is whatever identifier the AS knows the >> subject as. If they log in using only a FIDO token and the AS >> asserts that key value as the identifier, then that’s what it >> will be. If they sign up with an email address or make a username >> or get assigned a random number, that’s what it will be. Or they >> could sign up using any number of those and the AS still assigns >> them a random value, because it’s always the AS that determines >> which value to assign the number. > > When looking at Section 3.2 (Access Tokens), the client (and hence > the end-user) has currently /no practical way/ to indicate which > of its attributes should be placed into an access token, > The only reference within Section 3.2 is pointing to the empty > Section 12. Among the many examples, there is not a single example > that addresses the case of attributes being placed into an access > token. > > Nevertheless, it seems that in your opinion, only the AS, but NOT > the client (and hence the end-user), SHALL have control at all of > what kind of /subject identifier/ claim will be placed inside the > access token. > > Then after, invoking the postulate "the access token SHALL remain > opaque to the client (and hence the end-user)", it seems that in > your opinion, the end-user SHALL have no way to verify > whether its privacy has been respected. If this is not an > architecture built along "spy by design" principles, I don't know > what else it might be. > > It is important to re-read two of the current definitions: > > *Privilege*: right *or attribute* associated with a subject. > > *Access Toke*n: data artifact representing a set of rights > *a**nd/or attributes*. > > In the current draft, the case of rights is indeed addressed while > *the case of attributes is fully ignored*. > >> The RS is not involved in any subject information. Identity APIs, >> like OpenID Connect’s UserInfo Endpoint, are out of scope for GNAP. > > Really ? Do you mean that an access token should not contain a > "sub" claim nor a "sub_id" claim  and if it does, the RS SHALL > ignore such claims ? > > In the "OAuth Access Token JWT Profile", there is the following > sentence in Section 6 (Privacy Considerations) : > >    This profile mandates the presence of the "sub" claim in > every JWT >    access token, making it possible for resource servers to > rely on that >    information for performing tasks such as correlating incoming >    requests with /data stored locally for the authenticated > principal/. > > This sentence clearly makes a relationship between the value > present in the "sub" claim and "/data stored locally for the > //*authenticated *//principal/". > > However, note that the "OAuth Access Token JWT Profile" fails to > allow the client (and hence the end-user) to control his privacy, > since the client > cannot choose which value will be placed in the "sub" claim and > also because access tokens are considered to be opaque for the > clients in OAuth. >> If there is a subject identifier either included in or referenced >> by the access token, that is /up to any agreements between the AS >> and RS/ >> that lead to the ability of the AS to create the tokens the RS >> can trust. All of this is outside the scope of the core GNAP >> protocol and invisible to the client. > > You are using the following words "/up to any agreements between > the AS and RS/". This mandates prior agreements between ASs and RSs > and in such a case the architecture will be non-scalable over the > Internet. The trust relationship between a RS and an AS is unilateral: > The RS trusts the AS to issue appropriate access tokens > corresponding to the requests of its clients. > > From an end-user point of view, if there cannot be *transparency* > because of the access token opacity,**then there cannot be > *confidence *about GNAP . > > Denis > > >>  — Justin >> >>> On Mar 26, 2021, at 1:27 PM, Denis >> > wrote: >>> >>> Hi Justin, >>> >>> Let me rephrase the last question: How will a RS or a RO be >>> bootstrapped for working with a GNAP "sub" claim or a "sub_id" >>> claim ? >>> >>> Denis >>> >>>> GNAP doesn’t have anything too say about anybody authenticating >>>> directly to the RS. If that happens, it’s out of the view and >>>> out of scope of GNAP. >>>> >>>>  — Justin >>>> >>>>> On Mar 26, 2021, at 1:06 PM, Denis >>>> > wrote: >>>>> >>>>> Hi everybody, >>>>> >>>>> The content of this thread has nothing to do any more with its >>>>> original title which was: "Will GNAP support Zero Trust >>>>> Architecture?" >>>>> Since I am going to use some sentences of this thread to open >>>>> a new topic, I changed the title of this thread into : >>>>> "Relationship between Authentication and Authorization ?" >>>>> >>>>> At the moment, I got the impression that nobody agrees any >>>>> more about *what GNAP is or is not, what it should address and >>>>> what it should not address*. >>>>> The components of the model are becoming more numerous and >>>>> hazy. A new terminology is sometimes being used, but is not >>>>> yet present in the last published draft. >>>>> >>>>> I still can't understand any of the new terms that are being >>>>> used (*AS-RS* and *AS-RO*), _which are still left undefined_. >>>>> >>>>> The last exchanges look more as conversations between workers >>>>> during the construction of the Babel tower. >>>>> >>>>> Last year, my first remark was to mention that a section or an >>>>> Annex explaining the common points and the differences with >>>>> OAuth 2.0 >>>>> would be useful. Such section or Annex still does not exist. >>>>> >>>>> Justin wrote: >>>>> >>>>> /If an RS allows a username/password HTTP Basic auth in >>>>> addition to accepting access tokens, it can do so, but // >>>>> //GNAP doesn’t have anything to say about the Basic auth >>>>> use, or even its relation to any access tokens or RO’s or >>>>> anything else./ >>>>> >>>>> Let us split the end of this sentence into two parts: >>>>> >>>>> "/GNAP doesn’t have anything //to say about the Basic auth >>>>> use/": If an authentication exchange is necessary, the draft >>>>> document should describe, for completeness, >>>>> the HTTP error code that will be returned. >>>>> >>>>> "/or even its relation to any access tokens or RO’s or >>>>> anything else/". Let us suppose that a RS supports FIDO as an >>>>> authentication mechanism to authenticate its end-users. >>>>> FIDO provides the major advantage that, for every RS, a >>>>> different identifier is used by every end-user. This prevents >>>>> end-users accounts correlations between RSs by using >>>>> such identifiers. In practice, a FIDO identifier is a pseudonym. >>>>> >>>>> At this very moment, the RS is able to identify and >>>>> authenticate its end-users using FIDO pseudonyms. Now, let us >>>>> raise the following question: >>>>> >>>>> How will a RS be bootstrapped for working with a GNAP "sub" >>>>> claim or a "sub_id" claim, whereas FIDO is already being used ? >>>>> >>>>> Denis >>>>> >>>>> >>>>>> Adrian, >>>>>> >>>>>> I disagree, I believe that what I have laid out is exactly >>>>>> separating the concerns into working components. >>>>>> >>>>>> Like OAuth before it, GNAP is a protocol negotiate access for >>>>>> a client instance to an RS, using an AS as the facilitator of >>>>>> that delegated negotiation. (Unlike OAuth, it’s importantly >>>>>> also for negotiating user information to the client directly >>>>>> from the AS with no RS involved, but that’s an aside for the >>>>>> purposes of our conversation here). >>>>>> >>>>>> If a particular GNAP RS also allows other kinds of processes >>>>>> to enable access to it, that is completely fine, but outside >>>>>> of GNAP. If an RS allows a username/password HTTP Basic auth >>>>>> in addition to accepting access tokens, it can do so, but >>>>>> GNAP doesn’t have anything to say about the Basic auth use, >>>>>> or even its relation to any access tokens or RO’s or anything >>>>>> else. If an RS accepts structured access tokens signed by >>>>>> trusted keys that don’t come from an AS through a negotiated >>>>>> request — again, that’s fine, but GNAP is silent about the RS >>>>>> doing that. If the RS acts as “its own AS” then it’s really >>>>>> just an RS and an AS living in the same box. Again, that’s >>>>>> fine, and super common with OAuth today. >>>>>> >>>>>> GNAP is solving the problem of connecting the client to the >>>>>> RS through means of an AS. Other solutions are possible and >>>>>> many of them can be deployed right alongside, but that’s not >>>>>> the corner of the world that GNAP is solving. GNAP should be >>>>>> concerned about how these other technologies can be used >>>>>> alongside it. I think there’s a lot of room for the things >>>>>> that you’re talking about, and more importantly for solving >>>>>> the use cases that you’re bringing. But GNAP should be more >>>>>> than a single-point solution, and so we need to balance these >>>>>> concerns. The conceptual framework of an AS that takes in >>>>>> lots of different information and spits out access tokens is >>>>>> exactly the abstraction layer that is necessary for making >>>>>> these use cases interoperable. >>>>>> >>>>>>  — Justin >>>>>> >>>>>>> On Mar 26, 2021, at 8:30 AM, Adrian Gropper >>>>>>> > wrote: >>>>>>> >>>>>>> @Justin, there’s no separation of concerns here. No >>>>>>> partition between processor and controller. No data >>>>>>> minimization. And, I see no obvious reason to make this the >>>>>>> core of GNAP. >>>>>>> >>>>>>> The one thing we can probably all agree on is that there’s >>>>>>> only one RS and one RO. >>>>>>> >>>>>>> The core of GNAP, in my opinion, can be built and explained >>>>>>> around this simple design. The RS is a processor. The RO is >>>>>>> a controller. The RS bears only security responsibility. The >>>>>>> RS bears no privacy responsibility. The RO delegates this to >>>>>>> the RS but this is not authorization as the A in GNAP. >>>>>>> >>>>>>> The RO retains all rights to delegate within the scope of >>>>>>> things that the RS is willing to support using various token >>>>>>> formats and endpoint options. Some of these options may do >>>>>>> all sorts of things for all sorts of clients and user-agents >>>>>>>  but these are options. >>>>>>> >>>>>>> For example, if a request comes to the RS that is not in the >>>>>>> form of an access token, then it either gets sent to the RO >>>>>>> or their agent, or it gets logged and dumped. One such >>>>>>> option, common in healthcare, is “Break the Glass” where the >>>>>>> RS is acting as an authorization server because the >>>>>>> user-agent is making a request instead of presenting an >>>>>>> access token. GNAP can offer this as an option but it is not >>>>>>> our core. >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Mar 26, 2021 at 7:15 AM Justin Richer >>>>>>> > wrote: >>>>>>> >>>>>>> I have a big problem with this line: >>>>>>> >>>>>>> > the RS and AS-RS only see access tokens. The requests >>>>>>> (from RO') that resulted in an access token are none of >>>>>>> their business. >>>>>>> >>>>>>> In the trust model we’ve been discussing, the requests >>>>>>> that result in access tokens are *solely the business of >>>>>>> AS-RS*, since AS-RS is the only entity that’s allowed, >>>>>>> and trusted by the RS, to create access tokens for the >>>>>>> RS. That is its entire job, the entire reason it exists >>>>>>> in the system. By definition the party generating tokens >>>>>>> for use at the RS is the AS for that RS, I don’t care >>>>>>> how you deploy it. If RO wants to give access to someone >>>>>>> else (who isn’t an “RO" anymore, they’re another >>>>>>> end-user), then that end user’s client software will >>>>>>> need to talk to AS-RS to get its own access token. >>>>>>> >>>>>>> Now here’s the trick: when the end user’s client >>>>>>> instance talks to AS-RS, that does NOT mean that AS-RS >>>>>>> needs to know all the details and policy reasons that it >>>>>>> should give an access token to that client instance. It >>>>>>> doesn’t even need to know the existence of another end >>>>>>> user. It doesn’t need identity, it doesn’t need policy. >>>>>>> Sure, it COULD handle all of that internally, and many >>>>>>> will, but the protocol doesn’t demand it. >>>>>>> >>>>>>> This means that the first client instance, the one that >>>>>>> gets the access token, can also be given something >>>>>>> alongside the access token that it can then hand to >>>>>>> another piece of software (or to a person to hand eo >>>>>>> their piece of software). This artifact is not an access >>>>>>> token. This artifact could be something structured that >>>>>>> the client understands, and can make derivatives of, and >>>>>>> present back to the AS-RS for getting new access tokens. >>>>>>> There could be multiple different flavors of this kind >>>>>>> of artifact for different kinds of environments and >>>>>>> groups. But what they all have in common is that they >>>>>>> can potentially be used to request more access tokens >>>>>>> within some context at the AS-RS. >>>>>>> >>>>>>>  — Justin >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Mar 25, 2021, at 5:50 PM, Adrian Gropper >>>>>>>> >>>>>>> > wrote: >>>>>>>> >>>>>>>> My issue is with Alan's: >>>>>>>> >>>>>>>> "7. Another user agent (RO') can contact any holder >>>>>>>> of the access token or the service's policy agent >>>>>>>> (AS-RS) to get a delegated access token." >>>>>>>> >>>>>>>> >>>>>>>> I would prefer "7A.Another user agent (RO') can contact >>>>>>>> any holder of the access token." by default so that the >>>>>>>> AS-RS does not see the requests. In other words, the RS >>>>>>>> and AS-RS only see access tokens. The requests (from >>>>>>>> RO') that resulted in an access token are none of their >>>>>>>> business. >>>>>>>> >>>>>>>> The reality is that RO' can discover a resource RS and >>>>>>>> can share whatever information with RS-AS they want and >>>>>>>> the RO may not even know about it unless the RS decides >>>>>>>> to let them know somehow. This seems to be a drawback >>>>>>>> of the capabilities approach. >>>>>>>> >>>>>>>> In terms of privacy and control, I, as the RO, want a >>>>>>>> contract with the RS that says that I or my agent >>>>>>>> (AS-RO) must sign an access token. This is a >>>>>>>> fundamental audit requirement. Without it, a rogue RS >>>>>>>> and AS-RS can do all sorts of things and the RO would >>>>>>>> never know. I understand that a rogue RS might not >>>>>>>> support an honest contemporaneous log of access tokens >>>>>>>> presented so there's a trust issue here that I seems >>>>>>>> unavoidable unless I specify in my RO-RS contract that >>>>>>>> they use a separate contemporaneous log such as AS-RO >>>>>>>> for every access token presented and risk being sued if >>>>>>>> they process an access token without also updating the >>>>>>>> separate log. >>>>>>>> >>>>>>>> - Adrian >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Mar 25, 2021 at 1:22 PM Alan Karp >>>>>>>> > wrote: >>>>>>>> >>>>>>>> Justin Richer >>>>>>> > wrote: >>>>>>>> >>>>>>>> Hi Alan, >>>>>>>> >>>>>>>> In all of my discussion, and in the spec >>>>>>>> itself, the RO is the :entity: in charge of >>>>>>>> approving rights. They’re probably a person. It >>>>>>>> might be software that makes a policy decision >>>>>>>> in some way, or a corporate entity, or >>>>>>>> something like that. But it’s not assumed to be >>>>>>>> a computational agent in the terms of the >>>>>>>> protocol itself. Would that recast what you’re >>>>>>>> saying below? >>>>>>>> >>>>>>>> >>>>>>>> Hmmm.  I guess not. It's just that the person would >>>>>>>> be using some UI to express their decisions to what >>>>>>>> I called the user agent.  That model fits in very >>>>>>>> nicely with what we did with Polaris, our virus >>>>>>>> safe computing environment for Windows XP, >>>>>>>> https://dl.acm.org/doi/10.1145/1151030.1151033 >>>>>>>> . >>>>>>>> The person would click on the icon for a Word file, >>>>>>>> and an instance of Word would open with only the >>>>>>>> permission needed to edit that one file.  Same >>>>>>>> thing here. The client could ask for permission to >>>>>>>> use the resource, or permission could be granted >>>>>>>> implicitly when the user selects a resource >>>>>>>> associated with a specific client. >>>>>>>> >>>>>>>> -------------- >>>>>>>> Alan Karp >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Mar 25, 2021 at 9:53 AM Justin Richer >>>>>>>> > wrote: >>>>>>>> >>>>>>>> Hi Alan, >>>>>>>> >>>>>>>> In all of my discussion, and in the spec >>>>>>>> itself, the RO is the :entity: in charge of >>>>>>>> approving rights. They’re probably a person. It >>>>>>>> might be software that makes a policy decision >>>>>>>> in some way, or a corporate entity, or >>>>>>>> something like that. But it’s not assumed to be >>>>>>>> a computational agent in the terms of the >>>>>>>> protocol itself. Would that recast what you’re >>>>>>>> saying below? >>>>>>>> >>>>>>>>  — Justin >>>>>>>> >>>>>>>>> On Mar 25, 2021, at 12:36 PM, Alan Karp >>>>>>>>> >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> There seems to be some confusion about how >>>>>>>>> AS-RO comes into the picture, probably because >>>>>>>>> of the "AS" part. I'm going to try to clear up >>>>>>>>> that confusion by more carefully explaining >>>>>>>>> what I mean. >>>>>>>>> >>>>>>>>> I'm assuming that RO is a computational agent >>>>>>>>> representing the person who is the resource >>>>>>>>> owner, something called the "user agent" in >>>>>>>>> operating systems lingo.  I'm also assuming >>>>>>>>> that it's possible to do delegation, either >>>>>>>>> locally or by token exchange with AS-RS.  All >>>>>>>>> delegations are potentially sub-scoped, but >>>>>>>>> you may also want to delegate with full scope >>>>>>>>> to have a separately revocable access token. >>>>>>>>> >>>>>>>>>   Here's an example of how things work in a >>>>>>>>> capability oriented system. >>>>>>>>> >>>>>>>>> 1. Someone, the service owner, creates a service. >>>>>>>>> 2. The service owner contracts with an policy >>>>>>>>> agent (AS-RS) to create and manage access >>>>>>>>> tokens for that service (RS). >>>>>>>>> 3. A person wishing to create a resource at >>>>>>>>> RS uses their user agent (RO) to contact >>>>>>>>> the service owner's policy agent (AS-RS) >>>>>>>>> and gets back an access token for that >>>>>>>>> resource. >>>>>>>>> 4. That user agent (RO) can >>>>>>>>> 1. use that access token to invoke the >>>>>>>>> resource, or >>>>>>>>> 2. delegate an access token to a client >>>>>>>>> of the user agent's (RO) choice, or >>>>>>>>> 3. contract with a policy agent (AS-RO) >>>>>>>>> to manage those delegations on behalf >>>>>>>>> of the user agent (RO), or >>>>>>>>> 4. specify a policy with the service's >>>>>>>>> policy agent (AS-RS). >>>>>>>>> 5. A client can contact any holder of the >>>>>>>>> access token (the user agent (RO) or its >>>>>>>>> policy agent (AS-RO)) or the service's >>>>>>>>> policy agent (AS-RS) to get a delegated >>>>>>>>> access token. >>>>>>>>> 6. That client can delegate that token to >>>>>>>>> another client. >>>>>>>>> 7. Another user agent (RO') can contact any >>>>>>>>> holder of the access token or the >>>>>>>>> service's policy agent (AS-RS) to get a >>>>>>>>> delegated access token. >>>>>>>>> 8. The other user agent (RO') can >>>>>>>>> 1. use that access token to invoke the >>>>>>>>> resource, or >>>>>>>>> 2. delegate it to a client of its choice, or >>>>>>>>> 3. contract with a policy agent (AS-RO') >>>>>>>>> of its choosing to manage those >>>>>>>>> delegations on its behalf, or >>>>>>>>> 4. specify a policy with the service's >>>>>>>>> policy agent (AS-RS). >>>>>>>>> 9. and so on >>>>>>>>> >>>>>>>>> When any of these computational agents, user >>>>>>>>> agents (ROs) or clients acting on their >>>>>>>>> behalf, invokes the resource, AS-RS verifies >>>>>>>>> that the access token is a valid delegation, >>>>>>>>> i.e., proper sub-scoping, hasn't been revoked, >>>>>>>>> and that it authorizes the request being made >>>>>>>>> before telling the service (RS) to honor the >>>>>>>>> request.  At no point does the service's >>>>>>>>> policy agent (AS-RS) know which computational >>>>>>>>> agent did any particular delegation. (Token >>>>>>>>> exchange can be done as anonymously as >>>>>>>>> possible.)  In particular, the policy agents >>>>>>>>> (AS-RO) need not be the same, or even >>>>>>>>> compatible with, the service's policy agent >>>>>>>>> (AS-RS).  GNAP specifies the protocol between >>>>>>>>> requesters, invokers, delegators (for token >>>>>>>>> exchange) of tokens and AS-RS.  That protocol >>>>>>>>> need not be used between user agents (RO), >>>>>>>>> clients, or other policy agents (AS-RO), but >>>>>>>>> it is likely to be. >>>>>>>>> >>>>>>>>>  ------------- >>>>>>>>> Alan Karp >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Mar 25, 2021 at 5:45 AM Justin Richer >>>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> The way I’m thinking about Adrian’s use >>>>>>>>> case is that what we’re calling the >>>>>>>>> “AS-RO” isn’t an “AS” in the traditional >>>>>>>>> OAuth/GNAP sense, at least not exactly. >>>>>>>>> This is the agent that the RO can use to >>>>>>>>> set policies and manage consent on their >>>>>>>>> behalf, and I’ve been arguing that it fits >>>>>>>>> better into this vaguely-defined >>>>>>>>> “interaction component” aspect of the >>>>>>>>> current AS definition, and it’s not >>>>>>>>> currently separated from the AS >>>>>>>>> definition. The “AS-RS” maps to what we’d >>>>>>>>> call the “AS” in OAuth/GNAP traditionally, >>>>>>>>> it’s what the RS trusts to issue tokens. >>>>>>>>> In traditional OAuth the AS-RO and AS-RS >>>>>>>>> are always the same thing, from a >>>>>>>>> functional protocol perspective. An >>>>>>>>> important point here is that from a >>>>>>>>> client’s perspective, they’re only talking >>>>>>>>> to the AS-RS since that’s where the client >>>>>>>>> gets its tokens, because at the end of the >>>>>>>>> day the client just wants to call the API >>>>>>>>> at the RS and doesn’t care how that >>>>>>>>> happens (from a protocol standpoint). >>>>>>>>> >>>>>>>>> Note well: Even thought I don’t believe >>>>>>>>> that “AS-RO” is an authorization server at >>>>>>>>> all, I’m going to keep using that term >>>>>>>>> below for consistency with previous >>>>>>>>> discussion. >>>>>>>>> >>>>>>>>> So we have these fundamental relationships >>>>>>>>> around getting the client to access the RS: >>>>>>>>> >>>>>>>>> 1. RS trusts AS-RS to issue tokens that RS >>>>>>>>> will accept, validate, and process for >>>>>>>>> requests from client >>>>>>>>> 2. Client trusts AS-RS to issue tokens >>>>>>>>> that client can use at RS >>>>>>>>> 3. RO trusts RS to protect RO’s api >>>>>>>>> through delegated access >>>>>>>>> >>>>>>>>> On top of that, we’ve got some additional >>>>>>>>> aspects that we’re discussing: >>>>>>>>> >>>>>>>>> 4. RO trusts AS-RO to manage RO’s policies >>>>>>>>> at runtime >>>>>>>>> 5. AS-RS trusts AS-RO to assert RO’s >>>>>>>>> policies for access to RS >>>>>>>>> 6. Client trusts whatever AS-RS sends >>>>>>>>> client to deal with, including possibly >>>>>>>>> RO-AS at runtime, because of (2) >>>>>>>>> >>>>>>>>> What I have been saying is that 4/5/6 are >>>>>>>>> optional details of how RS-AS runs things, >>>>>>>>> and I think this also maps with Adrian’s >>>>>>>>> view of choice, since if my RS’s AS-RS >>>>>>>>> doesn’t allow me to plug in my own AS-RO >>>>>>>>> then I would be motivated to pick a >>>>>>>>> different RS who’s AS-RS lets me do just >>>>>>>>> that. The same way I’d pick a different RS >>>>>>>>> if their surrounding services didn’t >>>>>>>>> accept my preferred federation login and I >>>>>>>>> didn’t want to make another account. Of >>>>>>>>> course, market forces being as they are, I >>>>>>>>> might not have much of an actionable >>>>>>>>> choice in RS, but GNAP can’t change that. >>>>>>>>> >>>>>>>>> What we can do is make it possible for >>>>>>>>> AS-RS to talk to AS-RO, both in philosophy >>>>>>>>> of the protocol design and in concrete >>>>>>>>> hooks to support (6) above. >>>>>>>>> >>>>>>>>> Separately, we can approach the issue of >>>>>>>>> making 1/2 above more dynamic. This was >>>>>>>>> UMA2’s “federated authorization” approach, >>>>>>>>> and is behind a lot of the “bring your own >>>>>>>>> AS” models out there. The problem with >>>>>>>>> these is that we know from many years of >>>>>>>>> experience that most RS’s aren’t >>>>>>>>> interested in doing anything of the sort. >>>>>>>>> >>>>>>>>> So with GNAP we can instead allow 4/5/6 to >>>>>>>>> vary in a predictable and consistent way, >>>>>>>>> letting the RS keep control over 1/2, >>>>>>>>> thereby enabling choice in (3). We don’t >>>>>>>>> have to be the ones who define the all of >>>>>>>>> the details of every permutation of (5) to >>>>>>>>> enable this, though. Some of this is going >>>>>>>>> to be configuration out of band, some of >>>>>>>>> it’s going to be communication at runtime. >>>>>>>>> This is where VC’s, ZCAPs, CHAPI, DIDComm, >>>>>>>>> FIDO, and a whole swath of other tech can >>>>>>>>> come in and help out. I don’t think we >>>>>>>>> need to put all the details for using >>>>>>>>> these into core, nor do I think we’ll pull >>>>>>>>> of The Great And Ultimate Abstraction for >>>>>>>>> using these and other approaches. But we >>>>>>>>> can at least start talking about “AS-RS” >>>>>>>>> in such a way that it no longer assumes >>>>>>>>> it’s always the same party dealing with >>>>>>>>> the RO directly. >>>>>>>>> >>>>>>>>>  — Justin >>>>>>>>> >>>>>>>>>> On Mar 25, 2021, at 6:40 AM, Fabien >>>>>>>>>> Imbault >>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>> To reframe it closer to GNAP: >>>>>>>>>> - AS = AS-RO, that's where you find the >>>>>>>>>> RO policies. The AS issues access tokens >>>>>>>>>> to the client. >>>>>>>>>> - the RO policies could be a) defined >>>>>>>>>> locally or b) in relationship with the RS >>>>>>>>>> >>>>>>>>>> There have been several ideas related to >>>>>>>>>> the AS-RS relationship b: >>>>>>>>>> b1) the RS issues capabilities (which can >>>>>>>>>> be further attenuated by the RO) >>>>>>>>>> b2) Adrian also discussed a DID based >>>>>>>>>> solution >>>>>>>>>> b3) there was also an alternative ACL >>>>>>>>>> proposal from Denis (+ preflight) >>>>>>>>>> --------------24DA77526879476BC8EB2489 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
    Hi Adrian,

    Thank you for the scenario. You certainly know the following sentence:
    "When the only tool you have is a hammer, every problem looks like a nail".
    Similarly:  "When the only tool you have is an AS, every problem looks like an access token issued by an AS".

    Let us start with exactly the same sentence that explains the goal:
    Let Alice be the RO and subject of a resource. at a RS. Let Bob be a party, not Alice, that seeks authorization to access the resource using an access token.
    Then Bob asks to Alice to issue for him an authorization to access the resource.
    Alice, as the RO of the resource, request from the RS an "access token"  which is an (unsigned) data structure which contains:
    a read permission on some Alice's photo directory, associated with a large random number chosen by the RS.

    Note that a validity period will also be associated in practice, but this is a minor detail for the demonstration.

    Alice sends back to Bob the "access token" issued by the RS.

    Bob looks inside the access token to make sure that it corresponds to what he requested to Alice, i.e. a read permission on some Alice's photo directory.

    If the content is fine, Bob presents to the RS the large random number associated together with an API GET for some sub-set of the photos contained in Alice's directory.

    Since the RS recognizes the large random number and that the GET API is valid according to the "access token" memorized by the RS authorization set by Alice as a RO,
    the access is granted.

    In this example, the RS will not know who is reading the photo directory. So Bob can transmit the "access token" to someone else during its validity period, which may be a desirable feature.
    Note that it is also possible to allow Bob only to access Alice's directory. For simplicity, this alternative is not explained.

    In the mean time, I solved the answer of your question which was:" How Bob discovered the AS to make the request to is unclear to me for the time being".
    The request to your question is also unclear to me for the time being, but since there is no AS involved, Bob does not need to discover any AS. :-)

    I am quite sure that someone else will be able to describe one or more scenarios "using an AS as an hammer", but is is very likely that in such a case,
    the AS will be able know that Bob is rather likely to access in a short time some photos placed in the Alice's directory of photo hosted on that RS.
    This may be a privacy concern for Bob    .

    Of course, in addition, the AS and the RS must establish some prior relationships, etc ...

    However, all the discussion above is outside the scope of this initial thread which is: Relationship between Authentication and Authorization ?
    If you want to continue the discussion on the topic you mentioned, that's fine with me, but please change the title of this thread.

    Denis


    Hi Denis,

    I don’t understand your privacy issue, and I would like to try. 

    Let Alice be the RO and subject of a resource. at a RS. Let Bob be a party, not Alice, that seeks authorization to access the resource using an access token. 

    Bob has discovered the resource somehow that is out of band for GNAP. (Maybe Alice sent Bob a pointer to the resource in an email).

    Bob makes a request for the resource at some AS. The request includes the pointer that Bob discovered to the resource, some attributes or claims about Bob, and maybe a reason for the request. 

    How Bob discovered the AS to make the request to is unclear to me for the time being. Maybe Bob discovered the AS along with the resource. (e.g The resource is a DID and the AS is a service endpoint or mediator to an AS in that DID.)

    Given the scenario above, who’s privacy interest are you primarily concerned about? Alice or Bob? 

    Adrian

    On Mon, Mar 29, 2021 at 6:39 AM Denis <denis.ietf@free.fr> wrote:
    Hi  Justin,

    Since your response only deals with the AS, but not the RS nor the RO, it is not a response to my question which was:
    How will a RS or a RO be bootstrapped for working with a GNAP "sub" claim or a "sub_id" claim ?
    The subject identifier is whatever identifier the AS knows the subject as. If they log in using only a FIDO token and the AS asserts that key value as the identifier, then that’s what it will be. If they sign up with an email address or make a username or get assigned a random number, that’s what it will be. Or they could sign up using any number of those and the AS still assigns them a random value, because it’s always the AS that determines which value to assign the number.

    When looking at Section 3.2 (Access Tokens), the client (and hence the end-user) has currently no practical way to indicate which of its attributes should be placed into an access token,
    The only reference within Section 3.2 is pointing to the empty Section 12. Among the many examples, there is not a single example that addresses the case of attributes being placed into an access token.

    Nevertheless, it seems that in your opinion, only the AS, but NOT the client (and hence the end-user), SHALL have control at all of what kind of subject identifier claim will be placed inside the access token.

    Then after, invoking the postulate "the access token SHALL remain opaque to the client (and hence the end-user)", it seems that in your opinion, the end-user SHALL have no way to verify
    whether its privacy has been respected. If this is not an architecture built along "spy by design" principles, I don't know what else it might be.

    It is important to re-read two of the current definitions:

    Privilege: right or attribute associated with a subject.

    Access Token: data artifact representing a set of rights and/or attributes.

    In the current draft, the case of rights is indeed addressed while the case of attributes is fully ignored.

    The RS is not involved in any subject information. Identity APIs, like OpenID Connect’s UserInfo Endpoint, are out of scope for GNAP.

    Really ? Do you mean that an access token should not contain a "sub" claim nor a "sub_id" claim  and if it does, the RS SHALL ignore such claims ?

    In the "OAuth Access Token JWT Profile", there is the following sentence in Section 6 (Privacy Considerations) :

       This profile mandates the presence of the "sub" claim in every JWT
       access token, making it possible for resource servers to rely on that
       information for performing tasks such as correlating incoming
       requests with data stored locally for the authenticated principal. 

    This sentence clearly makes a relationship between the value present in the "sub" claim and "data stored locally for the authenticated principal".

    However, note that the "OAuth Access Token JWT Profile" fails to allow the client (and hence the end-user) to control his privacy, since the client
    cannot choose which value will be placed in the "sub" claim and also because access tokens are considered to be opaque for the clients in OAuth.
    If there is a subject identifier either included in or referenced by the access token, that is up to any agreements between the AS and RS
    that lead to the ability of the AS to create the tokens the RS can trust. All of this is outside the scope of the core GNAP protocol and invisible to the client.

    You are using the following words "up to any agreements between the AS and RS". This mandates prior agreements between ASs and RSs
    and in such a case the architecture will be non-scalable over the Internet. The trust relationship between a RS and an AS is unilateral:
    The RS trusts the AS to issue appropriate access tokens corresponding to the requests of its clients.

    From an end-user point of view, if there cannot be transparency because of the access token opacity, then there cannot be confidence about GNAP .

    Denis


     — Justin

    On Mar 26, 2021, at 1:27 PM, Denis <denis.ietf@free.fr> wrote:

    Hi Justin,

    Let me rephrase the last question: How will a RS or a RO be bootstrapped for working with a GNAP "sub" claim or a "sub_id" claim ?

    Denis

    GNAP doesn’t have anything too say about anybody authenticating directly to the RS. If that happens, it’s out of the view and out of scope of GNAP.

     — Justin

    On Mar 26, 2021, at 1:06 PM, Denis <denis.ietf@free.fr> wrote:

    Hi everybody,

    The content of this thread has nothing to do any more with its original title which was: "Will GNAP support Zero Trust Architecture?"
    Since I am going to use some sentences of this thread to open a new topic, I changed the title of this thread into :
    "Relationship between Authentication and Authorization ?"

    At the moment, I got the impression that nobody agrees any more about what GNAP is or is not, what it should address and what it should not address.
    The components of the model are becoming more numerous and hazy. A new terminology is sometimes being used, but is not yet present in the last published draft.

    I still can't understand any of the new terms that are being used (AS-RS and AS-RO), which are still left undefined.

    The last exchanges look more as conversations between workers during the construction of the Babel tower.

    Last year, my first remark was to mention that a section or an Annex explaining the common points and the differences with OAuth 2.0
    would be useful. Such section or Annex still does not exist.

    Justin wrote:
    If an RS allows a username/password HTTP Basic auth in addition to accepting access tokens, it can do so, but
    GNAP doesn’t have anything to say about the Basic auth use, or even its relation to any access tokens or RO’s or anything else.
    Let us split the end of this sentence into two parts:

    "GNAP doesn’t have anything to say about the Basic auth use":  If an authentication exchange  is necessary, the draft document should describe, for completeness,
    the HTTP error code that will be returned.

    "or even its relation to any access tokens or RO’s or anything else". Let us suppose that a RS supports FIDO as an authentication mechanism to authenticate its end-users.
    FIDO provides the major advantage that, for every RS, a different identifier is used by every end-user. This prevents end-users accounts correlations between RSs by using
    such identifiers. In practice, a FIDO identifier is a pseudonym.

    At this very moment, the RS is able to identify and authenticate its end-users using FIDO pseudonyms. Now, let us raise the following question:

    How will a RS be bootstrapped for working with a GNAP "sub" claim or a "sub_id" claim, whereas FIDO is already being used ?

    Denis


    Adrian,

    I disagree, I believe that what I have laid out is exactly separating the concerns into working components. 

    Like OAuth before it, GNAP is a protocol negotiate access for a client instance to an RS, using an AS as the facilitator of that delegated negotiation. (Unlike OAuth, it’s importantly also for negotiating user information to the client directly from the AS with no RS involved, but that’s an aside for the purposes of our conversation here).

    If a particular GNAP RS also allows other kinds of processes to enable access to it, that is completely fine, but outside of GNAP. If an RS allows a username/password HTTP Basic auth in addition to accepting access tokens, it can do so, but GNAP doesn’t have anything to say about the Basic auth use, or even its relation to any access tokens or RO’s or anything else. If an RS accepts structured access tokens signed by trusted keys that don’t come from an AS through a negotiated request — again, that’s fine, but GNAP is silent about the RS doing that. If the RS acts as “its own AS” then it’s really just an RS and an AS living in the same box. Again, that’s fine, and super common with OAuth today. 

    GNAP is solving the problem of connecting the client to the RS through means of an AS. Other solutions are possible and many of them can be deployed right alongside, but that’s not the corner of the world that GNAP is solving. GNAP should be concerned about how these other technologies can be used alongside it. I think there’s a lot of room for the things that you’re talking about, and more importantly for solving the use cases that you’re bringing. But GNAP should be more than a single-point solution, and so we need to balance these concerns. The conceptual framework of an AS that takes in lots of different information and spits out access tokens is exactly the abstraction layer that is necessary for making these use cases interoperable.

     — Justin

    On Mar 26, 2021, at 8:30 AM, Adrian Gropper <agropper@healthurl.com> wrote:

    @Justin, there’s no separation of concerns here. No partition between processor and controller. No data minimization. And, I see no obvious reason to make this the core of GNAP. 

    The one thing we can probably all agree on is that there’s only one RS and one RO. 

    The core of GNAP, in my opinion, can be built and explained around this simple design. The RS is a processor. The RO is a controller. The RS bears only security responsibility. The RS bears no privacy responsibility. The RO delegates this to the RS but this is not authorization as the A in GNAP.

    The RO retains all rights to delegate within the scope of things that the RS is willing to support using various token formats and endpoint options. Some of these options may do all sorts of things for all sorts of clients and user-agents  but these are options. 

    For example, if a request comes to the RS that is not in the form of an access token, then it either gets sent to the RO or their agent, or it gets logged and dumped. One such option, common in healthcare, is “Break the Glass” where the RS is acting as an authorization server because the user-agent is making a request instead of presenting an access token. GNAP can offer this as an option but it is not our core.

    Adrian



    On Fri, Mar 26, 2021 at 7:15 AM Justin Richer <jricher@mit.edu> wrote:
    I have a big problem with this line:

    > the RS and AS-RS only see access tokens. The requests (from RO') that resulted in an access token are none of their business.

    In the trust model we’ve been discussing, the requests that result in access tokens are solely the business of AS-RS, since AS-RS is the only entity that’s allowed, and trusted by the RS, to create access tokens for the RS. That is its entire job, the entire reason it exists in the system. By definition the party generating tokens for use at the RS is the AS for that RS, I don’t care how you deploy it. If RO wants to give access to someone else (who isn’t an “RO" anymore, they’re another end-user), then that end user’s client software will need to talk to AS-RS to get its own access token.

    Now here’s the trick: when the end user’s client instance talks to AS-RS, that does NOT mean that AS-RS needs to know all the details and policy reasons that it should give an access token to that client instance. It doesn’t even need to know the existence of another end user. It doesn’t need identity, it doesn’t need policy. Sure, it COULD handle all of that internally, and many will, but the protocol doesn’t demand it. 

    This means that the first client instance, the one that gets the access token, can also be given something alongside the access token that it can then hand to another piece of software (or to a person to hand eo their piece of software). This artifact is not an access token. This artifact could be something structured that the client understands, and can make derivatives of, and present back to the AS-RS for getting new access tokens. There could be multiple different flavors of this kind of artifact for different kinds of environments and groups. But what they all have in common is that they can potentially be used to request more access tokens within some context at the AS-RS.

     — Justin



    On Mar 25, 2021, at 5:50 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    My issue is with Alan's:
    "7. Another user agent (RO') can contact any holder of the access token or the service's policy agent (AS-RS) to get a delegated access token."

    I would prefer "7A. Another user agent (RO') can contact any holder of the access token." by default so that the AS-RS does not see the requests. In other words, the RS and AS-RS only see access tokens. The requests (from RO') that resulted in an access token are none of their business.

    The reality is that RO' can discover a resource RS and can share whatever information with RS-AS they want and the RO may not even know about it unless the RS decides to let them know somehow. This seems to be a drawback of the capabilities approach. 

    In terms of privacy and control, I, as the RO, want a contract with the RS that says that I or my agent (AS-RO) must sign an access token. This is a fundamental audit requirement. Without it, a rogue RS and AS-RS can do all sorts of things and the RO would never know. I understand that a rogue RS might not support an honest contemporaneous log of access tokens presented so there's a trust issue here that I seems unavoidable unless I specify in my RO-RS contract that they use a separate contemporaneous log such as AS-RO for every access token presented and risk being sued if they process an access token without also updating the separate log.

    - Adrian


    On Thu, Mar 25, 2021 at 1:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin Richer <jricher@mit.edu> wrote:
    Hi Alan,

    In all of my discussion, and in the spec itself, the RO is the :entity: in charge of approving rights. They’re probably a person. It might be software that makes a policy decision in some way, or a corporate entity, or something like that. But it’s not assumed to be a computational agent in the terms of the protocol itself. Would that recast what you’re saying below?

    Hmmm.  I guess not.  It's just that the person would be using some UI to express their decisions to what I called the user agent.  That model fits in very nicely with what we did with Polaris, our virus safe computing environment for Windows XP, https://dl.acm.org/doi/10.1145/1151030.1151033.  The person would click on the icon for a Word file, and an instance of Word would open with only the permission needed to edit that one file.  Same thing here.  The client could ask for permission to use the resource, or permission could be granted implicitly when the user selects a resource associated with a specific client.

    --------------
    Alan Karp


    On Thu, Mar 25, 2021 at 9:53 AM Justin Richer <jricher@mit.edu> wrote:
    Hi Alan,

    In all of my discussion, and in the spec itself, the RO is the :entity: in charge of approving rights. They’re probably a person. It might be software that makes a policy decision in some way, or a corporate entity, or something like that. But it’s not assumed to be a computational agent in the terms of the protocol itself. Would that recast what you’re saying below?

     — Justin

    On Mar 25, 2021, at 12:36 PM, Alan Karp <alanhkarp@gmail.com> wrote:

    There seems to be some confusion about how AS-RO comes into the picture, probably because of the "AS" part.  I'm going to try to clear up that confusion by more carefully explaining what I mean.

    I'm assuming that RO is a computational agent representing the person who is the resource owner, something called the "user agent" in operating systems lingo.  I'm also assuming that it's possible to do delegation, either locally or by token exchange with AS-RS.  All delegations are potentially sub-scoped, but you may also want to delegate with full scope to have a separately revocable access token.

      Here's an example of how things work in a capability oriented system.
    1. Someone, the service owner, creates a service.
    2. The service owner contracts with an policy agent (AS-RS) to create and manage access tokens for that service (RS).
    3. A person wishing to create a resource at RS uses their user agent (RO) to contact the service owner's policy agent (AS-RS) and gets back an access token for that resource.
    4. That user agent (RO) can 
      1. use that access token to invoke the resource, or
      2. delegate an access token to a client of the user agent's (RO) choice, or
      3. contract with a policy agent (AS-RO) to manage those delegations on behalf of the user agent (RO), or
      4. specify a policy with the service's policy agent (AS-RS).
    5. A client can contact any holder of the access token (the user agent (RO) or its policy agent (AS-RO)) or the service's policy agent (AS-RS) to get a delegated access token.
    6. That client can delegate that token to another client.
    7. Another user agent (RO') can contact any holder of the access token or the service's policy agent (AS-RS) to get a delegated access token.
    8. The other user agent (RO') can 
      1. use that access token to invoke the resource, or
      2. delegate it to a client of its choice, or
      3. contract with a policy agent (AS-RO') of its choosing to manage those delegations on its behalf, or
      4. specify a policy with the service's policy agent (AS-RS).
    9. and so on
    When any of these computational agents, user agents (ROs) or clients acting on their behalf, invokes the resource, AS-RS verifies that the access token is a valid delegation, i.e., proper sub-scoping, hasn't been revoked, and that it authorizes the request being made before telling the service (RS) to honor the request.  At no point does the service's policy agent (AS-RS) know which computational agent did any particular delegation.  (Token exchange can be done as anonymously as possible.)  In particular, the policy agents (AS-RO) need not be the same, or even compatible with, the service's policy agent (AS-RS).  GNAP specifies the protocol between requesters, invokers, delegators (for token exchange) of tokens and AS-RS.  That protocol need not be used between user agents (RO), clients, or other policy agents (AS-RO), but it is likely to be.

     -------------
    Alan Karp


    On Thu, Mar 25, 2021 at 5:45 AM Justin Richer <jricher@mit.edu> wrote:
    The way I’m thinking about Adrian’s use case is that what we’re calling the “AS-RO” isn’t an “AS” in the traditional OAuth/GNAP sense, at least not exactly. This is the agent that the RO can use to set policies and manage consent on their behalf, and I’ve been arguing that it fits better into this vaguely-defined “interaction component” aspect of the current AS definition, and it’s not currently separated from the AS definition. The “AS-RS” maps to what we’d call the “AS” in OAuth/GNAP traditionally, it’s what the RS trusts to issue tokens. In traditional OAuth the AS-RO and AS-RS are always the same thing, from a functional protocol perspective. An important point here is that from a client’s perspective, they’re only talking to the AS-RS since that’s where the client gets its tokens, because at the end of the day the client just wants to call the API at the RS and doesn’t care how that happens (from a protocol standpoint). 

    Note well: Even thought I don’t believe that “AS-RO” is an authorization server at all, I’m going to keep using that term below for consistency with previous discussion.

    So we have these fundamental relationships around getting the client to access the RS:

    1. RS trusts AS-RS to issue tokens that RS will accept, validate, and process for requests from client
    2. Client trusts AS-RS to issue tokens that client can use at RS
    3. RO trusts RS to protect RO’s api through delegated access

    On top of that, we’ve got some additional aspects that we’re discussing:

    4. RO trusts AS-RO to manage RO’s policies at runtime
    5. AS-RS trusts AS-RO to assert RO’s policies for access to RS
    6. Client trusts whatever AS-RS sends client to deal with, including possibly RO-AS at runtime, because of (2)

    What I have been saying is that 4/5/6 are optional details of how RS-AS runs things, and I think this also maps with Adrian’s view of choice, since if my RS’s AS-RS doesn’t allow me to plug in my own AS-RO then I would be motivated to pick a different RS who’s AS-RS lets me do just that. The same way I’d pick a different RS if their surrounding services didn’t accept my preferred federation login and I didn’t want to make another account. Of course, market forces being as they are, I might not have much of an actionable choice in RS, but GNAP can’t change that. 

    What we can do is make it possible for AS-RS to talk to AS-RO, both in philosophy of the protocol design and in concrete hooks to support (6) above. 

    Separately, we can approach the issue of making 1/2 above more dynamic. This was UMA2’s “federated authorization” approach, and is behind a lot of the “bring your own AS” models out there. The problem with these is that we know from many years of experience that most RS’s aren’t interested in doing anything of the sort.

    So with GNAP we can instead allow 4/5/6 to vary in a predictable and consistent way, letting the RS keep control over 1/2, thereby enabling choice in (3). We don’t have to be the ones who define the all of the details of every permutation of (5) to enable this, though. Some of this is going to be configuration out of band, some of it’s going to be communication at runtime. This is where VC’s, ZCAPs, CHAPI, DIDComm, FIDO, and a whole swath of other tech can come in and help out. I don’t think we need to put all the details for using these into core, nor do I think we’ll pull of The Great And Ultimate Abstraction for using these and other approaches. But we can at least start talking about “AS-RS” in such a way that it no longer assumes it’s always the same party dealing with the RO directly.

     — Justin

    On Mar 25, 2021, at 6:40 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    To reframe it closer to GNAP:
    - AS = AS-RO, that's where you find the RO policies. The AS issues access tokens to the client.
    - the RO policies could be a) defined locally or b) in relationship with the RS

    There have been several ideas related to the AS-RS relationship b:
    b1) the RS issues capabilities (which can be further attenuated by the RO)
    b2) Adrian also discussed a DID based solution
    b3) there was also an alternative ACL proposal from Denis (+ preflight)


    --------------24DA77526879476BC8EB2489-- From nobody Mon Mar 29 08:49:46 2021 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 816E73A18FA for ; Mon, 29 Mar 2021 08:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 Dz6DkK9VrAhA for ; Mon, 29 Mar 2021 08:49:40 -0700 (PDT) Received: from mail-vs1-f54.google.com (mail-vs1-f54.google.com [209.85.217.54]) (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 0ED1F3A18F9 for ; Mon, 29 Mar 2021 08:49:39 -0700 (PDT) Received: by mail-vs1-f54.google.com with SMTP id b5so6590404vsl.9 for ; Mon, 29 Mar 2021 08:49:39 -0700 (PDT) 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=v8pw0LDQnDu7vC0OPjCqrz9uPpoGHKA2aYm0NckYSAI=; b=YMswTq8JeYLsD8u59MfnmqJ/t65kLlFg7uulZih0GDff9ExpjtlGff+s0aEslTHasp J3upXeDcJwYz2BlWw8iIFoXAFcIdFNZTI2Mb1YmRekgKlyq8pW6f5yHmz4r06KT/07kB 63Iz0Gw4qUfmPlubJOYOPHoOZ5GvcpNkhUKJs+kQD/wiNaiQY2r1Gl08Z+WeZsuVpTf9 Mo7SPEWjaghQL4rbB2hIm7HekVmSKpu2iSodlEVcxf79tMSh08nvZq7Naybav61AamV9 UGamJEZL0tLvB1YJQ4bSgKIuVjGVcVUp1HLxHBozOFIuY21rN65qmFOlGnsu84ONi88q 4/JQ== X-Gm-Message-State: AOAM531qPc4M9ut7CvcCeQNh0a06JSyV8kd0tmOVFWbfGeFx5pI8WmNF ycDvIjOVQPjyg12C/9pElb1xgf9HX9krqSIqy8Y= X-Google-Smtp-Source: ABdhPJwFwTxwnuUSJJWpcc+Wzm65PgGKi0G8rF2GLC7ndu6avEgr+E2kRjmlUv+5HK9PZZ026jvswdtX7v0b0j2GgCY= X-Received: by 2002:a05:6102:222f:: with SMTP id d15mr14691357vsb.1.1617032978527; Mon, 29 Mar 2021 08:49:38 -0700 (PDT) MIME-Version: 1.0 References: <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> <5773FA7B-6891-4227-A8CA-2F506909B8CD@mit.edu> <3c103293-56a1-4be5-e2a3-12eb82d13238@free.fr> <91D11E67-34AB-4426-803C-7B5A6F50537F@mit.edu> In-Reply-To: From: Adrian Gropper Date: Mon, 29 Mar 2021 11:49:26 -0400 Message-ID: To: Denis Cc: Justin Richer , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000046790a05beaed451" Archived-At: Subject: Re: [GNAP] Relationship between Authentication and Authorization ? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2021 15:49:46 -0000 --00000000000046790a05beaed451 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This is helpful, Denis. I will focus on "Then Bob asks to Alice to issue for him an authorization to access the resource." and avoid using any hammers. Let's use something in the news and say the RS is a hospital that gave Alice a J&J COVID vaccine. Alice identified herself to the hospital with a number N. N could have been randomly chosen by Alice or the hospital or N could be Alice's driver's license number right next to her face photo. GNAP should probably deal with both cases. The hospital creates a digital credential that includes the J&J vaccine name and lot number, N, a statement about how N was derived, and a date. The hospital posts this credential at some resource URL, protected by some access token requirement, and gives Alice the "resource URL" instead of or along with a paper vaccination card with the same information as the resource. When Bob asks Alice for an access token, Bob makes a request to Alice and she can either: A - Give Bob the "resource URL" and let him try his luck turning this into an access token somewhere, B - Go to the hospital portal and authenticate somehow and grab an access token that she can return to Bob, C - Give Bob an access token for the resource URL based on some signature that is trusted by the hospital. When Bob gets the resource, it will include N along with the hospital's statement about how N was derived. Bob can decide what to do next. Adrian On Mon, Mar 29, 2021 at 9:54 AM Denis wrote: > Hi Adrian, > > Thank you for the scenario. You certainly know the following sentence: > > "When the only tool you have is a hammer, every problem looks like a nail= ". > > Similarly: "When the only tool you have is an AS, every problem looks > like an access token issued by an AS". > > Let us start with exactly the same sentence that explains the goal: > > Let Alice be the RO and subject of a resource. at a RS. Let Bob be a > party, not Alice, that seeks authorization to access the resource using a= n > access token. > > Then Bob asks to Alice to issue for him an authorization to access the > resource. > Alice, as the RO of the resource, request from the RS an "*access token*" > which is an (unsigned) data structure which contains: > a read permission on some Alice's photo directory, associated with a larg= e > random number *chosen by the RS*. > > Note that a validity period will also be associated in practice, but this > is a minor detail for the demonstration. > > Alice sends back to Bob the "*access token*" issued by the RS. > > *Bob looks inside the access token* to make sure that it corresponds to > what he requested to Alice, i.e. a read permission on some Alice's photo > directory. > > If the content is fine, Bob presents to the RS the large random number > associated together with an API GET for some sub-set of the photos > contained in Alice's directory. > > Since the RS recognizes the large random number and that the GET API is > valid according to the "access token" memorized by the RS authorization s= et > by Alice as a RO, > the access is granted. > > In this example, the RS will not know who is reading the photo directory. > So Bob can transmit the "access token" to someone else during its validit= y > period, which may be a desirable feature. > Note that it is also possible to allow Bob only to access Alice's > directory. For simplicity, this alternative is not explained. > > In the mean time, I solved the answer of your question which was:" *How > Bob discovered the AS to make the request to is unclear to me for the tim= e > being*". > The request to your question is also unclear to me for the time being, bu= t > since there is no AS involved, Bob does not need to discover any AS. :-) > > I am quite sure that someone else will be able to describe one or more > scenarios "*using an AS as an hammer*", but is is very likely that in > such a case, > the AS will be able know that Bob is rather likely to access in a short > time some photos placed in the Alice's directory of photo hosted on that > RS. > * This may be a privacy concern for Bob*. > > Of course, in addition, the AS and the RS must establish some prior > relationships, etc ... > > However, all the discussion above is outside the scope of this initial > thread which is: Relationship between Authentication and Authorization ? > If you want to continue the discussion on the topic you mentioned, that's > fine with me, but please change the title of this thread. > > Denis > > Hi Denis, > > I don=E2=80=99t understand your privacy issue, and I would like to try. > > Let Alice be the RO and subject of a resource. at a RS. Let Bob be a > party, not Alice, that seeks authorization to access the resource using a= n > access token. > > Bob has discovered the resource somehow that is out of band for GNAP. > (Maybe Alice sent Bob a pointer to the resource in an email). > > Bob makes a request for the resource at some AS. The request includes the > pointer that Bob discovered to the resource, some attributes or claims > about Bob, and maybe a reason for the request. > > How Bob discovered the AS to make the request to is unclear to me for the > time being. Maybe Bob discovered the AS along with the resource. (e.g The > resource is a DID and the AS is a service endpoint or mediator to an AS i= n > that DID.) > > Given the scenario above, who=E2=80=99s privacy interest are you primaril= y > concerned about? Alice or Bob? > > Adrian > > On Mon, Mar 29, 2021 at 6:39 AM Denis wrote: > >> Hi Justin, >> >> Since your response only deals with the AS, but not the RS nor the RO, i= t >> is not a response to my question which was: >> >> How will a RS or a RO be bootstrapped for working with a GNAP "sub" clai= m >> or a "sub_id" claim ? >> >> The subject identifier is whatever identifier the AS knows the subject >> as. If they log in using only a FIDO token and the AS asserts that key >> value as the identifier, then that=E2=80=99s what it will be. If they si= gn up with >> an email address or make a username or get assigned a random number, tha= t=E2=80=99s >> what it will be. Or they could sign up using any number of those and the= AS >> still assigns them a random value, because it=E2=80=99s always the AS th= at >> determines which value to assign the number. >> >> When looking at Section 3.2 (Access Tokens), the client (and hence the >> end-user) has currently *no practical way* to indicate which of its >> attributes should be placed into an access token, >> The only reference within Section 3.2 is pointing to the empty Section >> 12. Among the many examples, there is not a single example that addresse= s >> the case of attributes being placed into an access token. >> >> Nevertheless, it seems that in your opinion, only the AS, but NOT the >> client (and hence the end-user), SHALL have control at all of what kind = of *subject >> identifier* claim will be placed inside the access token. >> >> Then after, invoking the postulate "the access token SHALL remain opaque >> to the client (and hence the end-user)", it seems that in your opinion, = the >> end-user SHALL have no way to verify >> whether its privacy has been respected. If this is not an architecture >> built along "spy by design" principles, I don't know what else it might = be. >> >> It is important to re-read two of the current definitions: >> >> *Privilege*: right *or attribute* associated with a subject. >> >> *Access Toke*n: data artifact representing a set of rights *a**nd/or >> attributes*. >> >> In the current draft, the case of rights is indeed addressed while *the >> case of attributes is fully ignored*. >> >> The RS is not involved in any subject information. Identity APIs, like >> OpenID Connect=E2=80=99s UserInfo Endpoint, are out of scope for GNAP. >> >> Really ? Do you mean that an access token should not contain a "sub" >> claim nor a "sub_id" claim and if it does, the RS SHALL ignore such cla= ims >> ? >> >> In the "OAuth Access Token JWT Profile", there is the following sentence >> in Section 6 (Privacy Considerations) : >> >> This profile mandates the presence of the "sub" claim in every JWT >> access token, making it possible for resource servers to rely on that >> information for performing tasks such as correlating incoming >> requests with *data stored locally for the authenticated principal*. >> >> This sentence clearly makes a relationship between the value present in >> the "sub" claim and "*data stored locally for the **authenticated * >> *principal*". >> >> However, note that the "OAuth Access Token JWT Profile" fails to allow >> the client (and hence the end-user) to control his privacy, since the >> client >> cannot choose which value will be placed in the "sub" claim and also >> because access tokens are considered to be opaque for the clients in OAu= th. >> >> If there is a subject identifier either included in or referenced by the >> access token, that is *up to any agreements between the AS and RS* >> that lead to the ability of the AS to create the tokens the RS can trust= . >> All of this is outside the scope of the core GNAP protocol and invisible= to >> the client. >> >> You are using the following words "*up to any agreements between the AS >> and RS*". This mandates prior agreements between ASs and RSs >> and in such a case the architecture will be non-scalable over the >> Internet. The trust relationship between a RS and an AS is unilateral: >> The RS trusts the AS to issue appropriate access tokens corresponding to >> the requests of its clients. >> From an end-user point of view, if there cannot be *transparency* >> because of the access token opacity, then there cannot be *confidence *a= bout >> GNAP . >> >> Denis >> >> =E2=80=94 Justin >> >> On Mar 26, 2021, at 1:27 PM, Denis wrote: >> >> Hi Justin, >> >> Let me rephrase the last question: How will a RS or a RO be bootstrapped >> for working with a GNAP "sub" claim or a "sub_id" claim ? >> >> Denis >> >> GNAP doesn=E2=80=99t have anything too say about anybody authenticating = directly >> to the RS. If that happens, it=E2=80=99s out of the view and out of scop= e of GNAP. >> >> =E2=80=94 Justin >> >> On Mar 26, 2021, at 1:06 PM, Denis wrote: >> >> Hi everybody, >> >> The content of this thread has nothing to do any more with its original >> title which was: "Will GNAP support Zero Trust Architecture?" >> Since I am going to use some sentences of this thread to open a new >> topic, I changed the title of this thread into : >> "Relationship between Authentication and Authorization ?" >> >> At the moment, I got the impression that nobody agrees any more about *w= hat >> GNAP is or is not, what it should address and what it should not address= * >> . >> The components of the model are becoming more numerous and hazy. A new >> terminology is sometimes being used, but is not yet present in the last >> published draft. >> >> I still can't understand any of the new terms that are being used ( >> *AS-RS* and *AS-RO*), *which are still left undefined*. >> >> The last exchanges look more as conversations between workers during the >> construction of the Babel tower. >> >> Last year, my first remark was to mention that a section or an Annex >> explaining the common points and the differences with OAuth 2.0 >> would be useful. Such section or Annex still does not exist. >> >> Justin wrote: >> >> *If an RS allows a username/password HTTP Basic auth in addition to >> accepting access tokens, it can do so, but * >> *GNAP doesn=E2=80=99t have anything to say about the Basic auth use, or = even its >> relation to any access tokens or RO=E2=80=99s or anything else.* >> >> Let us split the end of this sentence into two parts: >> >> "*GNAP doesn=E2=80=99t have anything **to say about the Basic auth use*"= : If an >> authentication exchange is necessary, the draft document should describ= e, >> for completeness, >> the HTTP error code that will be returned. >> >> "*or even its relation to any access tokens or RO=E2=80=99s or anything = else*". >> Let us suppose that a RS supports FIDO as an authentication mechanism to >> authenticate its end-users. >> FIDO provides the major advantage that, for every RS, a different >> identifier is used by every end-user. This prevents end-users accounts >> correlations between RSs by using >> such identifiers. In practice, a FIDO identifier is a pseudonym. >> >> At this very moment, the RS is able to identify and authenticate its >> end-users using FIDO pseudonyms. Now, let us raise the following questio= n: >> >> How will a RS be bootstrapped for working with a GNAP "sub" claim or a >> "sub_id" claim, whereas FIDO is already being used ? >> >> Denis >> >> >> Adrian, >> >> I disagree, I believe that what I have laid out is exactly separating th= e >> concerns into working components. >> >> Like OAuth before it, GNAP is a protocol negotiate access for a client >> instance to an RS, using an AS as the facilitator of that delegated >> negotiation. (Unlike OAuth, it=E2=80=99s importantly also for negotiatin= g user >> information to the client directly from the AS with no RS involved, but >> that=E2=80=99s an aside for the purposes of our conversation here). >> >> If a particular GNAP RS also allows other kinds of processes to enable >> access to it, that is completely fine, but outside of GNAP. If an RS all= ows >> a username/password HTTP Basic auth in addition to accepting access toke= ns, >> it can do so, but GNAP doesn=E2=80=99t have anything to say about the Ba= sic auth >> use, or even its relation to any access tokens or RO=E2=80=99s or anythi= ng else. If >> an RS accepts structured access tokens signed by trusted keys that don= =E2=80=99t >> come from an AS through a negotiated request =E2=80=94 again, that=E2=80= =99s fine, but GNAP >> is silent about the RS doing that. If the RS acts as =E2=80=9Cits own AS= =E2=80=9D then it=E2=80=99s >> really just an RS and an AS living in the same box. Again, that=E2=80=99= s fine, and >> super common with OAuth today. >> >> GNAP is solving the problem of connecting the client to the RS through >> means of an AS. Other solutions are possible and many of them can be >> deployed right alongside, but that=E2=80=99s not the corner of the world= that GNAP >> is solving. GNAP should be concerned about how these other technologies = can >> be used alongside it. I think there=E2=80=99s a lot of room for the thin= gs that >> you=E2=80=99re talking about, and more importantly for solving the use c= ases that >> you=E2=80=99re bringing. But GNAP should be more than a single-point sol= ution, and >> so we need to balance these concerns. The conceptual framework of an AS >> that takes in lots of different information and spits out access tokens = is >> exactly the abstraction layer that is necessary for making these use cas= es >> interoperable. >> >> =E2=80=94 Justin >> >> On Mar 26, 2021, at 8:30 AM, Adrian Gropper >> wrote: >> >> @Justin, there=E2=80=99s no separation of concerns here. No partition be= tween >> processor and controller. No data minimization. And, I see no obvious >> reason to make this the core of GNAP. >> >> The one thing we can probably all agree on is that there=E2=80=99s only = one RS >> and one RO. >> >> The core of GNAP, in my opinion, can be built and explained around this >> simple design. The RS is a processor. The RO is a controller. The RS bea= rs >> only security responsibility. The RS bears no privacy responsibility. Th= e >> RO delegates this to the RS but this is not authorization as the A in GN= AP. >> >> The RO retains all rights to delegate within the scope of things that th= e >> RS is willing to support using various token formats and endpoint option= s. >> Some of these options may do all sorts of things for all sorts of client= s >> and user-agents but these are options. >> >> For example, if a request comes to the RS that is not in the form of an >> access token, then it either gets sent to the RO or their agent, or it g= ets >> logged and dumped. One such option, common in healthcare, is =E2=80=9CBr= eak the >> Glass=E2=80=9D where the RS is acting as an authorization server because= the >> user-agent is making a request instead of presenting an access token. GN= AP >> can offer this as an option but it is not our core. >> >> Adrian >> >> >> >> On Fri, Mar 26, 2021 at 7:15 AM Justin Richer wrote: >> >>> I have a big problem with this line: >>> >>> > the RS and AS-RS only see access tokens. The requests (from RO') that >>> resulted in an access token are none of their business. >>> >>> In the trust model we=E2=80=99ve been discussing, the requests that res= ult in >>> access tokens are *solely the business of AS-RS*, since AS-RS is the >>> only entity that=E2=80=99s allowed, and trusted by the RS, to create ac= cess tokens >>> for the RS. That is its entire job, the entire reason it exists in the >>> system. By definition the party generating tokens for use at the RS is = the >>> AS for that RS, I don=E2=80=99t care how you deploy it. If RO wants to = give access >>> to someone else (who isn=E2=80=99t an =E2=80=9CRO" anymore, they=E2=80= =99re another end-user), then >>> that end user=E2=80=99s client software will need to talk to AS-RS to g= et its own >>> access token. >>> >>> Now here=E2=80=99s the trick: when the end user=E2=80=99s client instan= ce talks to >>> AS-RS, that does NOT mean that AS-RS needs to know all the details and >>> policy reasons that it should give an access token to that client insta= nce. >>> It doesn=E2=80=99t even need to know the existence of another end user.= It doesn=E2=80=99t >>> need identity, it doesn=E2=80=99t need policy. Sure, it COULD handle al= l of that >>> internally, and many will, but the protocol doesn=E2=80=99t demand it. >>> >>> This means that the first client instance, the one that gets the access >>> token, can also be given something alongside the access token that it c= an >>> then hand to another piece of software (or to a person to hand eo their >>> piece of software). This artifact is not an access token. This artifact >>> could be something structured that the client understands, and can make >>> derivatives of, and present back to the AS-RS for getting new access >>> tokens. There could be multiple different flavors of this kind of artif= act >>> for different kinds of environments and groups. But what they all have = in >>> common is that they can potentially be used to request more access toke= ns >>> within some context at the AS-RS. >>> >>> =E2=80=94 Justin >>> >>> >>> >>> On Mar 25, 2021, at 5:50 PM, Adrian Gropper >>> wrote: >>> >>> My issue is with Alan's: >>> >>> "7. Another user agent (RO') can contact any holder of the access token >>> or the service's policy agent (AS-RS) to get a delegated access token." >>> >>> >>> I would prefer "7A. Another user agent (RO') can contact any holder of >>> the access token." by default so that the AS-RS does not see the reques= ts. >>> In other words, the RS and AS-RS only see access tokens. The requests (= from >>> RO') that resulted in an access token are none of their business. >>> >>> The reality is that RO' can discover a resource RS and can share >>> whatever information with RS-AS they want and the RO may not even know >>> about it unless the RS decides to let them know somehow. This seems to = be a >>> drawback of the capabilities approach. >>> >>> In terms of privacy and control, I, as the RO, want a contract with the >>> RS that says that I or my agent (AS-RO) must sign an access token. This= is >>> a fundamental audit requirement. Without it, a rogue RS and AS-RS can d= o >>> all sorts of things and the RO would never know. I understand that a ro= gue >>> RS might not support an honest contemporaneous log of access tokens >>> presented so there's a trust issue here that I seems unavoidable unless= I >>> specify in my RO-RS contract that they use a separate contemporaneous l= og >>> such as AS-RO for every access token presented and risk being sued if t= hey >>> process an access token without also updating the separate log. >>> >>> - Adrian >>> >>> >>> On Thu, Mar 25, 2021 at 1:22 PM Alan Karp wrote: >>> >>>> Justin Richer wrote: >>>> >>>>> Hi Alan, >>>>> >>>>> In all of my discussion, and in the spec itself, the RO is the >>>>> :entity: in charge of approving rights. They=E2=80=99re probably a pe= rson. It might >>>>> be software that makes a policy decision in some way, or a corporate >>>>> entity, or something like that. But it=E2=80=99s not assumed to be a = computational >>>>> agent in the terms of the protocol itself. Would that recast what you= =E2=80=99re >>>>> saying below? >>>>> >>>> >>>> Hmmm. I guess not. It's just that the person would be using some UI >>>> to express their decisions to what I called the user agent. That mode= l >>>> fits in very nicely with what we did with Polaris, our virus safe comp= uting >>>> environment for Windows XP, >>>> https://dl.acm.org/doi/10.1145/1151030.1151033. The person would >>>> click on the icon for a Word file, and an instance of Word would open = with >>>> only the permission needed to edit that one file. Same thing here. T= he >>>> client could ask for permission to use the resource, or permission cou= ld be >>>> granted implicitly when the user selects a resource associated with a >>>> specific client. >>>> >>>> -------------- >>>> Alan Karp >>>> >>>> >>>> On Thu, Mar 25, 2021 at 9:53 AM Justin Richer wrote: >>>> >>>>> Hi Alan, >>>>> >>>>> In all of my discussion, and in the spec itself, the RO is the >>>>> :entity: in charge of approving rights. They=E2=80=99re probably a pe= rson. It might >>>>> be software that makes a policy decision in some way, or a corporate >>>>> entity, or something like that. But it=E2=80=99s not assumed to be a = computational >>>>> agent in the terms of the protocol itself. Would that recast what you= =E2=80=99re >>>>> saying below? >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Mar 25, 2021, at 12:36 PM, Alan Karp wrote: >>>>> >>>>> There seems to be some confusion about how AS-RO comes into the >>>>> picture, probably because of the "AS" part. I'm going to try to clea= r up >>>>> that confusion by more carefully explaining what I mean. >>>>> >>>>> I'm assuming that RO is a computational agent representing the person >>>>> who is the resource owner, something called the "user agent" in opera= ting >>>>> systems lingo. I'm also assuming that it's possible to do delegation= , >>>>> either locally or by token exchange with AS-RS. All delegations are >>>>> potentially sub-scoped, but you may also want to delegate with full s= cope >>>>> to have a separately revocable access token. >>>>> >>>>> Here's an example of how things work in a capability oriented syste= m. >>>>> >>>>> 1. Someone, the service owner, creates a service. >>>>> 2. The service owner contracts with an policy agent (AS-RS) to >>>>> create and manage access tokens for that service (RS). >>>>> 3. A person wishing to create a resource at RS uses their user >>>>> agent (RO) to contact the service owner's policy agent (AS-RS) and= gets >>>>> back an access token for that resource. >>>>> 4. That user agent (RO) can >>>>> 1. use that access token to invoke the resource, or >>>>> 2. delegate an access token to a client of the user agent's >>>>> (RO) choice, or >>>>> 3. contract with a policy agent (AS-RO) to manage those >>>>> delegations on behalf of the user agent (RO), or >>>>> 4. specify a policy with the service's policy agent (AS-RS). >>>>> 5. A client can contact any holder of the access token (the user >>>>> agent (RO) or its policy agent (AS-RO)) or the service's policy ag= ent >>>>> (AS-RS) to get a delegated access token. >>>>> 6. That client can delegate that token to another client. >>>>> 7. Another user agent (RO') can contact any holder of the access >>>>> token or the service's policy agent (AS-RS) to get a delegated acc= ess token. >>>>> 8. The other user agent (RO') can >>>>> 1. use that access token to invoke the resource, or >>>>> 2. delegate it to a client of its choice, or >>>>> 3. contract with a policy agent (AS-RO') of its choosing to >>>>> manage those delegations on its behalf, or >>>>> 4. specify a policy with the service's policy agent (AS-RS). >>>>> 9. and so on >>>>> >>>>> When any of these computational agents, user agents (ROs) or clients >>>>> acting on their behalf, invokes the resource, AS-RS verifies that the >>>>> access token is a valid delegation, i.e., proper sub-scoping, hasn't = been >>>>> revoked, and that it authorizes the request being made before telling= the >>>>> service (RS) to honor the request. At no point does the service's po= licy >>>>> agent (AS-RS) know which computational agent did any particular >>>>> delegation. (Token exchange can be done as anonymously as possible.)= In >>>>> particular, the policy agents (AS-RO) need not be the same, or even >>>>> compatible with, the service's policy agent (AS-RS). GNAP specifies = the >>>>> protocol between requesters, invokers, delegators (for token exchange= ) of >>>>> tokens and AS-RS. That protocol need not be used between user agents= (RO), >>>>> clients, or other policy agents (AS-RO), but it is likely to be. >>>>> >>>>> ------------- >>>>> Alan Karp >>>>> >>>>> >>>>> On Thu, Mar 25, 2021 at 5:45 AM Justin Richer wrote= : >>>>> >>>>>> The way I=E2=80=99m thinking about Adrian=E2=80=99s use case is that= what we=E2=80=99re >>>>>> calling the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an =E2=80=9CAS=E2= =80=9D in the traditional OAuth/GNAP sense, at >>>>>> least not exactly. This is the agent that the RO can use to set poli= cies >>>>>> and manage consent on their behalf, and I=E2=80=99ve been arguing th= at it fits >>>>>> better into this vaguely-defined =E2=80=9Cinteraction component=E2= =80=9D aspect of the >>>>>> current AS definition, and it=E2=80=99s not currently separated from= the AS >>>>>> definition. The =E2=80=9CAS-RS=E2=80=9D maps to what we=E2=80=99d ca= ll the =E2=80=9CAS=E2=80=9D in OAuth/GNAP >>>>>> traditionally, it=E2=80=99s what the RS trusts to issue tokens. In t= raditional >>>>>> OAuth the AS-RO and AS-RS are always the same thing, from a function= al >>>>>> protocol perspective. An important point here is that from a client= =E2=80=99s >>>>>> perspective, they=E2=80=99re only talking to the AS-RS since that=E2= =80=99s where the >>>>>> client gets its tokens, because at the end of the day the client jus= t wants >>>>>> to call the API at the RS and doesn=E2=80=99t care how that happens = (from a >>>>>> protocol standpoint). >>>>>> >>>>>> Note well: Even thought I don=E2=80=99t believe that =E2=80=9CAS-RO= =E2=80=9D is an >>>>>> authorization server at all, I=E2=80=99m going to keep using that te= rm below for >>>>>> consistency with previous discussion. >>>>>> >>>>>> So we have these fundamental relationships around getting the client >>>>>> to access the RS: >>>>>> >>>>>> 1. RS trusts AS-RS to issue tokens that RS will accept, validate, an= d >>>>>> process for requests from client >>>>>> 2. Client trusts AS-RS to issue tokens that client can use at RS >>>>>> 3. RO trusts RS to protect RO=E2=80=99s api through delegated access >>>>>> >>>>>> On top of that, we=E2=80=99ve got some additional aspects that we=E2= =80=99re >>>>>> discussing: >>>>>> >>>>>> 4. RO trusts AS-RO to manage RO=E2=80=99s policies at runtime >>>>>> 5. AS-RS trusts AS-RO to assert RO=E2=80=99s policies for access to = RS >>>>>> 6. Client trusts whatever AS-RS sends client to deal with, including >>>>>> possibly RO-AS at runtime, because of (2) >>>>>> >>>>>> What I have been saying is that 4/5/6 are optional details of how >>>>>> RS-AS runs things, and I think this also maps with Adrian=E2=80=99s = view of choice, >>>>>> since if my RS=E2=80=99s AS-RS doesn=E2=80=99t allow me to plug in m= y own AS-RO then I >>>>>> would be motivated to pick a different RS who=E2=80=99s AS-RS lets m= e do just that. >>>>>> The same way I=E2=80=99d pick a different RS if their surrounding se= rvices didn=E2=80=99t >>>>>> accept my preferred federation login and I didn=E2=80=99t want to ma= ke another >>>>>> account. Of course, market forces being as they are, I might not hav= e much >>>>>> of an actionable choice in RS, but GNAP can=E2=80=99t change that. >>>>>> >>>>>> What we can do is make it possible for AS-RS to talk to AS-RO, both >>>>>> in philosophy of the protocol design and in concrete hooks to suppor= t (6) >>>>>> above. >>>>>> >>>>>> Separately, we can approach the issue of making 1/2 above more >>>>>> dynamic. This was UMA2=E2=80=99s =E2=80=9Cfederated authorization=E2= =80=9D approach, and is behind >>>>>> a lot of the =E2=80=9Cbring your own AS=E2=80=9D models out there. T= he problem with these >>>>>> is that we know from many years of experience that most RS=E2=80=99s= aren=E2=80=99t >>>>>> interested in doing anything of the sort. >>>>>> >>>>>> So with GNAP we can instead allow 4/5/6 to vary in a predictable and >>>>>> consistent way, letting the RS keep control over 1/2, thereby enabli= ng >>>>>> choice in (3). We don=E2=80=99t have to be the ones who define the a= ll of the >>>>>> details of every permutation of (5) to enable this, though. Some of = this is >>>>>> going to be configuration out of band, some of it=E2=80=99s going to= be >>>>>> communication at runtime. This is where VC=E2=80=99s, ZCAPs, CHAPI, = DIDComm, FIDO, >>>>>> and a whole swath of other tech can come in and help out. I don=E2= =80=99t think we >>>>>> need to put all the details for using these into core, nor do I thin= k we=E2=80=99ll >>>>>> pull of The Great And Ultimate Abstraction for using these and other >>>>>> approaches. But we can at least start talking about =E2=80=9CAS-RS= =E2=80=9D in such a way >>>>>> that it no longer assumes it=E2=80=99s always the same party dealing= with the RO >>>>>> directly. >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> On Mar 25, 2021, at 6:40 AM, Fabien Imbault >>>>>> wrote: >>>>>> >>>>>> To reframe it closer to GNAP: >>>>>> - AS =3D AS-RO, that's where you find the RO policies. The AS issues >>>>>> access tokens to the client. >>>>>> - the RO policies could be a) defined locally or b) in relationship >>>>>> with the RS >>>>>> >>>>>> There have been several ideas related to the AS-RS relationship b: >>>>>> b1) the RS issues capabilities (which can be further attenuated by >>>>>> the RO) >>>>>> b2) Adrian also discussed a DID based solution >>>>>> b3) there was also an alternative ACL proposal from Denis (+ >>>>>> preflight) >>>>>> >>>>>> > --00000000000046790a05beaed451 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    This is helpful, Denis.=C2=A0

    I will focus on "Then Bob asks to Alice to issue for him an au= thorization to access the resource." and avoid using any hammers.=C2= =A0

    Let's use something in the news and say th= e RS is a hospital that gave Alice a J&J COVID vaccine. Alice identifie= d herself to the hospital with a number N. N could have been randomly chose= n by Alice or the hospital or N could be Alice's driver's license n= umber right next to her face photo. GNAP should probably deal with both cas= es.=C2=A0

    The hospital creates a digital credentia= l that includes the J&J vaccine name and lot number, N, a statement abo= ut how N was derived, and a date. The hospital posts this credential at som= e resource URL, protected by some access token requirement, and gives Alice= the "resource URL" instead of or along with a paper vaccination = card with the same information as the resource.

    Wh= en Bob asks Alice for an access token, Bob makes a request to Alice and she= can either:
    A - Give Bob the "resource URL" and let hi= m try his luck turning this into an access token somewhere,
    B - G= o to the hospital portal and authenticate somehow and grab an access token = that she can return to Bob,
    C - Give Bob an access token for the = resource URL based on some signature that is trusted by the hospital.
    =

    When Bob gets the resource, it will include N along wit= h the hospital's statement about how N was derived. Bob can decide what= to do next.

    Adrian


    On M= on, Mar 29, 2021 at 9:54 AM Denis <denis.ietf@free.fr> wrote:
    =20 =20 =20
    Hi Adrian,

    Thank you for the scenario. You certainly know the following sentence:
    "When the only tool you have is a hammer, every problem looks like a nail".
    Similarly:=C2=A0 "When the only tool you have is an AS, every problem looks like an access token issued by an AS".

    Let us start with exactly the same sentence that explains the goal:
    Let Alice be the RO and subject of a resource. at a RS. Let Bob be a party, not Alice, that seeks authorization to access the resource using an access token.
    Then Bob asks to Alice to issue for him an authorization to access the resource.
    Alice, as the RO of the resource, request from the RS an "acces= s token"=C2=A0 which is an (unsigned) data structure which con= tains:
    a read permission on some Alice's photo directory, associated with = a large random number chosen by the RS.

    Note that a validity period will also be associated in practice, but this is a minor detail for the demonstration.

    Alice sends back to Bob the "access token" issued by the RS.

    Bob looks inside the access token to make sure that it corresponds to what he requested to Alice, i.e. a read permission on some Alice's photo directory.

    If the content is fine, Bob presents to the RS the large random number associated together with an API GET for some sub-set of the photos contained in Alice's directory.

    Since the RS recognizes the large random number and that the GET API is valid according to the "access token" memorized by the RS authorization set by Ali= ce as a RO,
    the access is granted.

    In this example, the RS will not know who is reading the photo directory. So Bob can transmit the "access token" to someone else during its validity period, = which may be a desirable feature.
    Note that it is also possible to allow Bob only to access Alice's directory. For simplicity, this alternative is not explained.

    In the mean time, I solved the answer of your question which was:"= How Bob discovered the AS to make the request to is unclear to me for the time being".
    The request to your question is also unclear to me for the time being, but since there is no AS involved, Bob does not need to discover any AS. :-)

    I am quite sure that someone else will be able to describe one or more scenarios "using an AS as an hammer", but is is very likely that in such a case,
    the AS will be able know that Bob is rather likely to access in a short time some photos placed in the Alice's directory of photo hosted on that RS.
    This may be a privacy concern for Bob    .

    Of course, in addition, the AS and the RS must establish some prior relationships, etc ...

    However, all the discussion above is outside the scope of this initial thread which is: Relationship between Authentication and Authorization ?
    If you want to continue the discussion on the topic you mentioned, that's fine with me, but please change the title of this thread.<= br>

    Denis


    =20
    Hi Denis,

    I don=E2=80=99t understand your privacy issue, and = I would like to try.=C2=A0

    Let Alice be the RO and subject of a resource. at a RS. Let Bob be a party, not Alice, that seeks authorization to access the resource using an access token.=C2=A0

    Bob has discovered the resource somehow that is out of band for GNAP. (Maybe Alice sent Bob a pointer to the resource in an email).

    Bob makes a request for the resource at some AS. The request includes the pointer that Bob discovered to the resource, some attributes or claims about Bob, and maybe a reason for the request.=C2=A0

    How Bob discovered the AS to make the request to is unclear to me for the time being. Maybe Bob discovered the AS along with the resource. (e.g The resource is a DID and the AS is a service endpoint or mediator to an AS in that DID.)

    Given the scenario above, who=E2=80=99s privacy int= erest are you primarily concerned=C2=A0about? Alice or Bob?=C2=A0

    Adrian

    On Mon, Mar 29, 2021 at 6:3= 9 AM Denis <denis.ietf@free.fr> wrote:
    Hi=C2=A0 Justin,

    Since your response only deals with the AS, but not the RS nor the RO, it is not a response to my question which was:
    How will a RS or a RO be bootstrapped for working with a GNAP "sub" claim or a "sub_id"= claim ?
    The subject identifier is whatever identifier the AS knows the subject as. If they log in using only a FIDO token and the AS asserts that key value as the identifier, then that=E2=80=99s what it will b= e. If they sign up with an email address or make a username or get assigned a random number, that=E2=80=99s what it will b= e. Or they could sign up using any number of those and the AS still assigns them a random value, because it=E2=80=99s alw= ays the AS that determines which value to assign the number.

    When looking at Section 3.2 (Access Tokens), the client (and hence the end-user) has currently no practical way to indicate which of its attributes should be placed into an access token,
    The only reference within Section 3.2 is pointing to the empty Section 12. Among the many examples, there is not a single example that addresses the case of attributes being placed into an access token.

    Nevertheless, it seems that in your opinion, only the AS, but NOT the client (and hence the end-user), SHALL have control at all of what kind of subject identifier claim will be placed inside the access token.

    Then after, invoking the postulate "the access token SHALL remain opaque to the client (and hence the end-user)", it seems that in your opinion, the end-use= r SHALL have no way to verify
    whether its privacy has been respected. If this is not an architecture built along "spy by design" princ= iples, I don't know what else it might be.

    It is important to re-read two of the current definitions:

    Privilege: right or attribute associated with a subject.

    Access Token: data artifact representing a set of rights and/or attributes.

    In the current draft, the case of rights is indeed addressed while the case of attributes is fully ignored.

    The RS is not involved in any subject information. Identity APIs, like OpenID Connect=E2=80=99s UserInfo Endpoint, are out of scope for GNAP.

    Really ? Do you mean that an access token should not contain a "sub" claim nor a "sub_id" cl= aim=C2=A0 and if it does, the RS SHALL ignore such claims ?

    In the "OAuth Access Token JWT Profile", there i= s the following sentence in Section 6 (Privacy Considerations) :

    =C2=A0=C2=A0 This profile mandates the presence of the &= quot;sub" claim in every JWT
    =C2=A0=C2=A0 access token, making it possible for resourc= e servers to rely on that
    =C2=A0=C2=A0 information for performing tasks such as correlating incoming
    =C2=A0=C2=A0 requests with data stored locally for the authenticated principal.=C2=A0

    This sentence clearly makes a relationship between the value present in the "sub" claim and "data = stored locally for the authenticated principa= l".

    However, note that the "OAuth Access Token JWT Profile&q= uot; fails to allow the client (and hence the end-user) to control his privacy, since the client
    cannot choose which value will be placed in the "sub&quo= t; claim and also because access tokens are considered to be opaque for the clients in OAuth.
    If there is a subject identifier either included in or referenced by the access token, that is up to any agreements between the AS and RS
    that lead to the ability of the AS to create the tokens the RS can trust. All of this is outside the scope of the core GNAP protocol and invisible to the client.

    You are using the following words "up to any agreements between the AS and RS". This mandates prior agreements between ASs and RSs
    and in such a case the architecture will be non-scalable over the Internet. The trust relationship between a RS and an AS is unilateral:
    The RS trusts the AS to issue appropriate access tokens corresponding to the requests of its clients.

    From an end-user point of view, if there cannot be transpa= rency because of the access token opacity, then there cannot be confidence about GNAP .

    Denis


    =C2=A0=E2=80=94 Justin

    On Mar 26, 2021, at 1:27 PM, Denis <denis.ietf@free.fr> wrote:

    Hi Justin,

    Let me rephrase the last question: How will a RS or a RO be bootstrapped for working with a GNAP "sub" claim or a "sub_id" claim ?

    Denis

    GNAP doesn=E2=80=99t h= ave anything too say about anybody authenticating directly to the RS. If that happens, it=E2=80=99s out of the view and out o= f scope of GNAP.

    =C2=A0=E2=80=94 Justin

    On Mar 26, 2021, at 1:06 PM, Denis <denis.ietf@free.fr> wrote:

    Hi everybody,

    The content of this thread has nothing to do any more with its original title which was: "Will GNAP support Zero Trust Architecture?"
    Since I am going to use some sentences of this thread to open a new topic, I changed the title of this thread into :
    "Relationship between Authentication and Authorization ?"

    At the moment, I got the impression that nobody agrees any more about what GNAP is or is not, what it should address and what it should not address.
    The components of the model are becoming more numerous and hazy. A new terminology is sometimes being used, but is not yet present in the last published draft.

    I still can't understand any of the new terms that are being used (AS-RS and A= S-RO), which are still left undefined.

    The last exchanges look more as conversations between workers during the construction of the Babel tower.

    Last year, my first remark was to mention that a section or an Annex explaining the common points and the differences with OAuth 2.0
    would be useful. Such section or Annex still does not exist.

    Justin wrote:
    If an RS allows a username/password HTTP Basic auth in addition to accepting access tokens, it can do so, but
    GNAP doesn=E2=80=99t hav= e anything to say about the Basic auth use, or even its relation to any access tokens or RO=E2=80=99s or any= thing else.
    Let us split the end of this sentence into two parts:

    "GNAP doesn=E2=80=99t = have anything to say about the Basic auth use&qu= ot;:=C2=A0 If an authentication exchange=C2= =A0 is necessary, the draft document should describe, for completeness,
    the HTTP error code that will be returned.

    "or even its relation = to any access tokens or RO=E2=80= =99s or anything else". Let us suppose that a RS supports FIDO as an authentication mechanism to authenticate its end-users.
    FIDO provides the major advantage that, for every RS, a different identifier is used by every end-user. This prevents end-users accounts correlations between RSs by using
    such identifiers. In practice, a FIDO identifier is a pseudonym.

    At this very moment, the RS is able to identify and authenticate its end-users using FIDO pseudonyms. Now, let us raise the following question:

    How will a RS be bootstrapped for working with a GNAP "sub" cla= im or a "sub_id" claim, where= as FIDO is already being used ?

    Denis


    Adrian,

    I disagree, I believe that what I have laid out is exactly separating the concerns into working components.=C2=A0

    Like OAuth before it, GNAP is a protocol negotiate access for a client instance to an RS, using an AS as the facilitator of that delegated negotiation. (Unlike OAuth, it=E2=80=99s importantly also for negotiating user information to the client directly from the AS with no RS involved, but that=E2=80=99s an aside for= the purposes of our conversation here).

    If a particular GNAP RS also allows other kinds of processes to enable access to it, that is completely fine, but outside of GNAP. If an RS allows a username/password HTTP Basic auth in addition to accepting access tokens, it can do so, but GNAP doesn=E2=80= =99t have anything to say about the Basic auth use, or even its relation to any access tokens or RO=E2=80=99s or anyth= ing else. If an RS accepts structured access tokens signed by trusted keys that don=E2=80=99t come from an AS through a negotiated request =E2=80=94 again, that=E2=80=99s= fine, but GNAP is silent about the RS doing that. If the RS acts as =E2=80=9Cits own AS=E2=80=9D= then it=E2=80=99s really just an RS and an AS living in the same box. Again, that=E2=80=99s fine, and super common with OAuth today.=C2=A0

    GNAP is solving the problem of connecting the client to the RS through means of an AS. Other solutions are possible and many of them can be deployed right alongside, but that=E2=80= =99s not the corner of the world that GNAP is solving. GNAP should be concerned about how these other technologies can be used alongside it. I think there=E2=80=99s a lot of = room for the things that you=E2=80= =99re talking about, and more importantly for solving the use cases that you=E2=80=99re bringing. But GNAP should be more than a single-point solution, and so we need to balance these concerns. The conceptual framework of an AS that takes in lots of different information and spits out access tokens is exactly the abstraction layer that is necessary for making these use cases interoperable.

    =C2=A0=E2=80=94 Justin

    On Mar 26, 2021, at 8:30 AM, Adrian Gropper <agropper@healthurl.com&g= t; wrote:

    @Justin= , there=E2=80=99s no separation of concerns here. No partition between processor and controller. No data minimization. And, I see no obvious reason to make this the core of GNAP.=C2=A0=

    The one thing we can probably all agree on is that there=E2=80= =99s only one RS and one RO.=C2=A0

    The core of GNAP, in my=C2=A0opinion, can be built and explained around this simple design. The RS is a processor. The RO is a controller. The RS bears only security responsibility. The RS bears no privacy responsibility. The RO delegates this to the RS but this is not authorization as the A in GNAP.

    The RO retains all rights to delegate within the scope of things that the RS is willing to support using various token formats and endpoint options. Some of these options may do all sorts of things for all sorts of clients and user-agents =C2=A0but these are options.=C2= =A0

    For example, if a request comes to the RS that is not in the form of an access token, then it either gets sent to the RO or their agent, or it gets logged and dumped. One such option, common in healthcare, is =E2=80=9CBreak the Glas= s=E2=80=9D where the RS is acting as an authorization server because the user-agent is making a request instead of presenting an access token. GNAP can offer this as an option but it is not our core.

    Adrian<= /div>



    On Fri, Mar 26, 2021 at 7:15 AM Justin Richer <jricher@mit.edu> wrote:
    I have a big problem with this line:

    >=C2=A0the RS and AS-RS only see access tokens. The requests (from RO') that resulted in an access token are none of their business.<= /div>

    In the trust model we=E2=80=99= ve been discussing, the requests that result in access tokens are solely the business of AS-RS, since AS-RS is the only entity that=E2=80= =99s allowed, and trusted by the RS, to create access tokens for the RS. That is its entire job, the entire reason it exists in the system. By definition the party generating tokens for use at the RS is the AS for that RS, I don=E2=80=99t car= e how you deploy it. If RO wants to give access to someone else (who isn=E2=80=99= t an =E2=80=9CRO"= anymore, they=E2=80=99re another end-user), then that end user=E2=80=99s cl= ient software will need to talk to AS-RS to get its own access token.

    Now here=E2=80=99s th= e trick: when the end user=E2= =80=99s client instance talks to AS-RS, that does NOT mean that AS-RS needs to know all the details and policy reasons that it should give an access token to that client instance. It doesn=E2=80=99t e= ven need to know the existence of another end user. It doesn=E2=80=99t n= eed identity, it doesn=E2=80=99t n= eed policy. Sure, it COULD handle all of that internally, and many will, but the protocol doesn=E2=80=99t d= emand it.=C2=A0

    This means that the first client instance, the one that gets the access token, can also be given something alongside the access token that it can then hand to another piece of software (or to a person to hand eo their piece of software). This artifact is not an access token. This artifact could be something structured that the client understands, and can make derivatives of, and present back to the AS-RS for getting new access tokens. There could be multiple different flavors of this kind of artifact for different kinds of environments and groups. But what they all have in common is that they can potentially be used to request more access tokens within some context at the AS-RS.

    =C2=A0=E2=80= =94 Justin



    On Mar 25, 2021, at 5:50 PM, Adrian Gropper <agropper@healthurl.com&g= t; wrote:

    My issue is with Alan's:
    "7. Another user agent (RO') can contact any holder of the access token or the service's policy agent (AS-RS) to get a delegated access token.&quo= t;

    I would prefer "7A.<= font face=3D"arial, sans-serif">=C2= =A0Another user agent (RO') can contact any holder of the access token.&quo= t; by default so that the AS-RS does not see the requests. In other words, the RS and AS-RS only see access tokens. The requests (from RO') that resulted in an access token are none of their business.<= /font>
    The reality is that RO' can discover a resource RS and can share whatever information with RS-AS they want and the RO may not even know about it unless the RS decides to let them know somehow. This seems to be a drawback of the capabilities approach.=C2=A0
    In terms of privacy and control, I, as the RO, want a contract=C2=A0wit= h the RS that says that I or my agent (AS-RO) must sign an access token. This is a fundamental audit requirement. Without it, a rogue RS and AS-RS can do all sorts of things and the RO would never know. I understand that a rogue RS might not support an honest contemporaneous log of access tokens presented so there's a trust issue here that I seems unavoidable unless I specify in my RO-RS contract that they use a separate contemporaneous= =C2=A0log such as AS-RO for every access token presented and risk being sued if they process an access token without also updating the separate log.
    - Adrian


    On Thu, Mar 25, 2021 at 1:22 PM Alan Karp <alanhkarp@gmail.com&g= t; wrote:
    Justin Richer <jricher@mit.edu> wrote:
    Hi Alan,

    In all of my discussion, and in the spec itself, the RO is the :entity: in charge of approving rights. They=E2=80=99re probably a person. It might be software that makes a policy decision in some way, or a corporate entity, or something like that. But it=E2= =80=99s not assumed to be a computational agent in the terms of the protocol itself. Would that recast what you=E2=80=99= re saying below?
    =
    Hmmm.=C2=A0 = I guess not.=C2=A0 It's just tha= t the person would be using some UI to express their decisions to what I called the user agent.=C2=A0 That model fits in very nicely with what we did with Polaris, our virus safe computing environment for Windows XP, https://dl.= acm.org/doi/10.1145/1151030.1151033.=C2=A0 The person would click on the icon for a Word file, and an instance of Word would open with only the permission needed to edit that one file.=C2=A0 Same thing here.=C2=A0 The client could ask for permission to use the resource, or permission could be granted implicitly when the user selects a resource associated with a specific client.
    =
    -------------- Alan Karp


    On Thu, Mar 25, 2021 at 9:53 AM Justin Richer <jricher@mit.edu> wrote:
    Hi Alan,

    In all of my discussion, and in the spec itself, the RO is the :entity: in charge of approving rights. They=E2=80=99re probably a person. It might be software that makes a policy decision in some way, or a corporate entity, or something like that. But it=E2= =80=99s not assumed to be a computational agent in the terms of the protocol itself. Would that recast what you=E2=80=99= re saying below?

    =C2=A0=E2=80= =94 Justin

    On Mar 25, 2021, at 12:36 PM, Alan Karp <alanhkarp@gmail.com&g= t; wrote:

    = There seems to be some confusion about how AS-RO comes into the picture, probably because of the "AS" pa= rt.=C2=A0 I'm going to try to clear up that confusion by more carefully explaining what I mean.

    I'm assuming that RO is a computational agent representing the person who is the resource owner, something called the "user agent&= quot; in operating systems lingo.=C2=A0 I= 9;m also assuming that it's possible to do delegation, either locally or by token exchange with AS-RS.=C2=A0 All delegations are potentially sub-scoped, but you may also want to delegate with full scope to have a separately revocable access token.

    =C2=A0 Here&= #39;s an example of how things work in a capability oriented system.
    1. Someone, the service owner, creates a service.
    2. The service owner contracts with an policy agent (AS-RS) to create and manage access tokens for that service (RS).
    3. A person wishing to create a resource at RS uses their user agent (RO) to contact the service owner's polic= y agent (AS-RS) and gets back an access token for that resource.
    4. That user agent (RO) can=C2=A0
      1. use that access token to invoke the resource, or
      2. delegate an access token to a client of the user agent's (RO) choice, or
      3. contract with a policy agent (AS-RO) to manage those delegations on behalf of the user agent (RO), or
      4. specify a policy with the service's policy agent (AS-RS).
    5. A client can contact any holder of the access token (the user agent (RO) or its policy agent (AS-RO)) or the service's policy agent (AS-RS) to get a delegated access token.
    6. That client can delegate that token to another client.
    7. Another user agent (RO') can contact any holder of the access token or the service's policy agent (AS-RS) to get a delegated access token.
    8. The other user agent (RO') can=C2= =A0
      1. use that access token to invoke the resource, or
      2. delegate it to a client of its choice, or
      3. contract with a policy agent (AS-RO'= ) of its choosing to manage those delegations on its behalf, or
      4. specify a policy with the service's policy agent (AS-RS).
    9. and so on
    When any of these computational agents, user agents (ROs) or clients acting on their behalf, invokes the resource, AS-RS verifies that the access token is a valid delegation, i.e., proper sub-scoping, hasn't been revoked, and that it authorizes the request being made before telling the service (RS) to honor the request.=C2=A0 At no point does the service's policy agent (AS-RS) know which computational agent did any particular delegation.=C2=A0 (Token exchange can be done as anonymously as possible.)=C2=A0 = In particular, the policy agents (AS-RO) need not be the same, or even compatible with, the service's policy agent (AS-RS).=C2=A0 GN= AP specifies the protocol between requesters, invokers, delegators (for token exchange) of tokens and AS-RS.=C2=A0 That protocol need not be used between user agents (RO), clients, or other policy agents (AS-RO), but it is likely to be.

    =C2=A0------= -------
    = Alan Karp


    On Thu, Mar 25, 2021 at 5:45 AM Justin Richer <jricher@mit.edu> wrote:
    The way I=E2=80=99m think= ing about Adrian=E2= =80=99s use case is that what we=E2=80=99re cal= ling the =E2=80=9CAS-R= O=E2=80=9D isn=E2=80=99t an = =E2=80=9CAS=E2=80=9D in the traditional OAuth/GNAP sense, at least not exactly. This is the agent that the RO can use to set policies and manage consent on their behalf, and I=E2=80=99ve been arguing that it fits better into this vaguely-defined =E2=80=9Cinteract= ion component=E2=80= =9D aspect of the current AS definition, and it=E2=80=99s = not currently separated from the AS definition. The =E2=80=9CAS-R= S=E2=80=9D maps to what we=E2=80=99d call= the =E2=80=9CAS=E2=80= =9D in OAuth/GNAP traditionally, it=E2=80=99s what= the RS trusts to issue tokens. In traditional OAuth the AS-RO and AS-RS are always the same thing, from a functional protocol perspective. An important point here is that from a client=E2=80=99s perspective, they=E2=80=99re o= nly talking to the AS-RS since that=E2=80=99s wh= ere the client gets its tokens, because at the end of the day the client just wants to call the API at the RS and doesn=E2=80=99t c= are how that happens (from a protocol standpoint).=C2= =A0

    Note well: Even thought I don=E2=80=99t bel= ieve that =E2=80=9CAS-= RO=E2=80=9D is an authorization server at all, I=E2=80=99m going= to keep using that term below for consistency with previous discussion.

    So we have these fundamental relationships around getting the client to access the RS:

    1. RS trusts=C2=A0AS-RS= =C2=A0to issue tokens that RS will accept, validate, and process for requests from client
    2. Client trusts=C2=A0AS-RS=C2=A0to issue tokens that client can use at RS
    3. RO trusts RS to protect RO=E2=80= =99s api through delegated access

    On top of that, we=E2=80=99= ve got some additional aspects that we=E2=80=99re discussing:

    4. RO trusts=C2=A0AS-RO= =C2=A0to manage RO=E2=80= =99s policies at runtime
    5.=C2=A0AS-R= S=C2=A0trusts=C2=A0AS-RO=C2=A0to assert RO=E2=80= =99s policies for access to RS
    6. Client trusts whatever=C2=A0AS-RS=C2=A0sends client to deal with, including possibly RO-A= S at runtime, because of (2)

    What I have been saying is that 4/5/6 are optional details of how RS-AS runs things, and I think this also maps with Adrian=E2=80=99s = view of choice, since if my RS=E2=80=99s AS-R= S doesn=E2=80=99t a= llow me to plug in my own AS-RO then I would be motivated to pick a different RS who=E2=80=99s AS-= RS lets me do just that. The same way I=E2=80= =99d pick a different RS if their surrounding services didn=E2=80=99t ac= cept my preferred federation login and I didn=E2=80=99t wa= nt to make another account. Of course, market forces being as they are, I might not have much of an actionable choice in RS, but GNAP can=E2= =80=99t change that.=C2= =A0

    What we can do is make it possible for AS-RS to talk to AS-RO, both in philosophy of the protocol design and in concrete hooks to support (6) above.=C2=A0

    Separately, we can approach the issue of making 1/2 above more dynamic. This was UMA2=E2=80=99= s =E2=80=9Cfederate= d authorization=E2= =80=9D approach, and is behind a lot of the =E2=80=9Cbring yo= ur own AS=E2=80=9D m= odels out there. The problem with these is that we know from many years of experience that most RS=E2= =80=99s aren=E2=80=99t interested in doing anything of the sort.

    So with GNAP we can instead allow 4/5/6 to vary in a predictable and consistent way, letting the RS keep control over 1/2, thereby enabling choice in (3). We don=E2=80=99t = have to be the ones who define the all of the details of every permutation of (5) to enable this, though. Some of this is going to be configuration out of band, some of it=E2=80= =99s going to be communication at runtime. This is where VC=E2=80=99s, ZCA= Ps, CHAPI, DIDComm, FIDO, and a whole swath of other tech can come in and help out. I don=E2=80= =99t think we need to put all the details for using these into core, nor do I think we=E2=80=99ll pul= l of The Great And Ultimate Abstraction for using these and other approaches. But we can at least start talking about =E2=80=9CAS-RS=E2= =80=9D in such a way that it no longer assumes it=E2=80=99s alwa= ys the same party dealing with the RO directly.


    --00000000000046790a05beaed451-- From nobody Mon Mar 29 10:19:11 2021 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 74F613A1B6D for ; Mon, 29 Mar 2021 10:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 MaZdn7sJCNzA for ; Mon, 29 Mar 2021 10:19:02 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp03.smtpout.orange.fr [80.12.242.125]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FBB83A1B6E for ; Mon, 29 Mar 2021 10:19:01 -0700 (PDT) Received: from [192.168.1.11] ([90.79.53.231]) by mwinf5d05 with ME id mHJt2400N4zJUWJ03HJtsT; Mon, 29 Mar 2021 19:18:59 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Mon, 29 Mar 2021 19:18:59 +0200 X-ME-IP: 90.79.53.231 To: Adrian Gropper Cc: GNAP Mailing List References: <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> <5773FA7B-6891-4227-A8CA-2F506909B8CD@mit.edu> <3c103293-56a1-4be5-e2a3-12eb82d13238@free.fr> <91D11E67-34AB-4426-803C-7B5A6F50537F@mit.edu> From: Denis Message-ID: Date: Mon, 29 Mar 2021 19:18:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2DC03CCC383D20505EC30945" Content-Language: en-GB Archived-At: Subject: [GNAP] Alice a J&J COVID vaccine X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2021 17:19:10 -0000 This is a multi-part message in MIME format. --------------2DC03CCC383D20505EC30945 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Adrian, I changed the title of this thread since your are addressing a new topic that I am unable to understand. Alice J&J vaccine is Alice's private information. For which reason would Bob ask Alice to provide an access token ? Denis > This is helpful, Denis. > > I will focus on "Then Bob asks to Alice to issue for him an > authorization to access the resource." and avoid using any hammers. > > Let's use something in the news and say the RS is a hospital that gave > Alice a J&J COVID vaccine. Alice identified herself to the hospital > with a number N. N could have been randomly chosen by Alice or the > hospital or N could be Alice's driver's license number right next to > her face photo. GNAP should probably deal with both cases. > > The hospital creates a digital credential that includes the J&J > vaccine name and lot number, N, a statement about how N was derived, > and a date. The hospital posts this credential at some resource URL, > protected by some access token requirement, and gives Alice the > "resource URL" instead of or along with a paper vaccination card with > the same information as the resource. > > When Bob asks Alice for an access token, Bob makes a request to Alice > and she can either: > A - Give Bob the "resource URL" and let him try his luck turning this > into an access token somewhere, > B - Go to the hospital portal and authenticate somehow and grab an > access token that she can return to Bob, > C - Give Bob an access token for the resource URL based on some > signature that is trusted by the hospital. > > When Bob gets the resource, it will include N along with the > hospital's statement about how N was derived. Bob can decide what to > do next. > > Adrian > > > On Mon, Mar 29, 2021 at 9:54 AM Denis > wrote: > > Hi Adrian, > > Thank you for the scenario. You certainly know the following sentence: > > "When the only tool you have is a hammer, every problem looks > like a nail". > > Similarly:  "When the only tool you have is an AS, every problem > looks like an access token issued by an AS". > > Let us start with exactly the same sentence that explains the goal: > > Let Alice be the RO and subject of a resource. at a RS. Let > Bob be a party, not Alice, that seeks authorization to access > the resource using an access token. > > Then Bob asks to Alice to issue for him an authorization to access > the resource. > Alice, as the RO of the resource, request from the RS an "/access > token/"  which is an (unsigned) data structure which contains: > a read permission on some Alice's photo directory, associated with > a large random number /chosen by the RS/. > > Note that a validity period will also be associated in practice, > but this is a minor detail for the demonstration. > > Alice sends back to Bob the "/access token/" issued by the RS. > > *Bob looks inside the access token* to make sure that it > corresponds to what he requested to Alice, i.e. a read permission > on some Alice's photo directory. > > If the content is fine, Bob presents to the RS the large random > number associated together with an API GET for some sub-set of the > photos contained in Alice's directory. > > Since the RS recognizes the large random number and that the GET > API is valid according to the "access token" memorized by the RS > authorization set by Alice as a RO, > the access is granted. > > In this example, the RS will not know who is reading the photo > directory. So Bob can transmit the "access token" to someone else > during its validity period, which may be a desirable feature. > Note that it is also possible to allow Bob only to access Alice's > directory. For simplicity, this alternative is not explained. > > In the mean time, I solved the answer of your question which was:" > /How Bob discovered the AS to make the request to is unclear to me > for the time being/". > The request to your question is also unclear to me for the time > being, but since there is no AS involved, Bob does not need to > discover any AS. :-) > > I am quite sure that someone else will be able to describe one or > more scenarios "/using an AS as an hammer/", but is is very likely > that in such a case, > the AS will be able know that Bob is rather likely to access in a > short time some photos placed in the Alice's directory of photo > hosted on that RS. / > This may be a privacy concern for Bob/. > > Of course, in addition, the AS and the RS must establish some > prior relationships, etc ... > > However, all the discussion above is outside the scope of this > initial thread which is: Relationship between Authentication and > Authorization ? > If you want to continue the discussion on the topic you mentioned, > that's fine with me, but please change the title of this thread. > > Denis > > >> Hi Denis, >> >> I don’t understand your privacy issue, and I would like to try. >> >> Let Alice be the RO and subject of a resource. at a RS. Let Bob >> be a party, not Alice, that seeks authorization to access the >> resource using an access token. >> >> Bob has discovered the resource somehow that is out of band for >> GNAP. (Maybe Alice sent Bob a pointer to the resource in an email). >> >> Bob makes a request for the resource at some AS. The request >> includes the pointer that Bob discovered to the resource, some >> attributes or claims about Bob, and maybe a reason for the request. >> >> How Bob discovered the AS to make the request to is unclear to me >> for the time being. Maybe Bob discovered the AS along with the >> resource. (e.g The resource is a DID and the AS is a service >> endpoint or mediator to an AS in that DID.) >> >> Given the scenario above, who’s privacy interest are you >> primarily concerned about? Alice or Bob? >> >> Adrian >> >> On Mon, Mar 29, 2021 at 6:39 AM Denis > > wrote: >> >> Hi  Justin, >> >> Since your response only deals with the AS, but not the RS >> nor the RO, it is not a response to my question which was: >> >> How will a RS or a RO be bootstrapped for working with a >> GNAP "sub" claim or a "sub_id" claim ? >> >>> The subject identifier is whatever identifier the AS knows >>> the subject as. If they log in using only a FIDO token and >>> the AS asserts that key value as the identifier, then that’s >>> what it will be. If they sign up with an email address or >>> make a username or get assigned a random number, that’s what >>> it will be. Or they could sign up using any number of those >>> and the AS still assigns them a random value, because it’s >>> always the AS that determines which value to assign the number. >> >> When looking at Section 3.2 (Access Tokens), the client (and >> hence the end-user) has currently /no practical way/ to >> indicate which of its attributes should be placed into an >> access token, >> The only reference within Section 3.2 is pointing to the >> empty Section 12. Among the many examples, there is not a >> single example that addresses the case of attributes being >> placed into an access token. >> >> Nevertheless, it seems that in your opinion, only the AS, but >> NOT the client (and hence the end-user), SHALL have control >> at all of what kind of /subject identifier/ claim will be >> placed inside the access token. >> >> Then after, invoking the postulate "the access token SHALL >> remain opaque to the client (and hence the end-user)", it >> seems that in your opinion, the end-user SHALL have no way to >> verify >> whether its privacy has been respected. If this is not an >> architecture built along "spy by design" principles, I don't >> know what else it might be. >> >> It is important to re-read two of the current definitions: >> >> *Privilege*: right *or attribute* associated with a subject. >> >> *Access Toke*n: data artifact representing a set of >> rights *a**nd/or attributes*. >> >> In the current draft, the case of rights is indeed addressed >> while *the case of attributes is fully ignored*. >> >>> The RS is not involved in any subject information. Identity >>> APIs, like OpenID Connect’s UserInfo Endpoint, are out of >>> scope for GNAP. >> >> Really ? Do you mean that an access token should not contain >> a "sub" claim nor a "sub_id" claim  and if it does, the RS >> SHALL ignore such claims ? >> >> In the "OAuth Access Token JWT Profile", there is the >> following sentence in Section 6 (Privacy Considerations) : >> >>    This profile mandates the presence of the "sub" claim >> in every JWT >>    access token, making it possible for resource servers >> to rely on that >>    information for performing tasks such as correlating >> incoming >>    requests with /data stored locally for the >> authenticated principal/. >> >> This sentence clearly makes a relationship between the value >> present in the "sub" claim and "/data stored locally for the >> //*authenticated *//principal/". >> >> However, note that the "OAuth Access Token JWT Profile" fails >> to allow the client (and hence the end-user) to control his >> privacy, since the client >> cannot choose which value will be placed in the "sub" claim >> and also because access tokens are considered to be opaque >> for the clients in OAuth. >>> If there is a subject identifier either included in or >>> referenced by the access token, that is /up to any >>> agreements between the AS and RS/ >>> that lead to the ability of the AS to create the tokens the >>> RS can trust. All of this is outside the scope of the core >>> GNAP protocol and invisible to the client. >> >> You are using the following words "/up to any agreements >> between the AS and RS/". This mandates prior agreements >> between ASs and RSs >> and in such a case the architecture will be non-scalable over >> the Internet. The trust relationship between a RS and an AS >> is unilateral: >> The RS trusts the AS to issue appropriate access tokens >> corresponding to the requests of its clients. >> >> From an end-user point of view, if there cannot be >> *transparency* because of the access token opacity,**then >> there cannot be *confidence *about GNAP . >> >> Denis >> >> >>>  — Justin >>> >>>> On Mar 26, 2021, at 1:27 PM, Denis >>> > wrote: >>>> >>>> Hi Justin, >>>> >>>> Let me rephrase the last question: How will a RS or a RO be >>>> bootstrapped for working with a GNAP "sub" claim or a >>>> "sub_id" claim ? >>>> >>>> Denis >>>> >>>>> GNAP doesn’t have anything too say about anybody >>>>> authenticating directly to the RS. If that happens, it’s >>>>> out of the view and out of scope of GNAP. >>>>> >>>>>  — Justin >>>>> >>>>>> On Mar 26, 2021, at 1:06 PM, Denis >>>>> > wrote: >>>>>> >>>>>> Hi everybody, >>>>>> >>>>>> The content of this thread has nothing to do any more >>>>>> with its original title which was: "Will GNAP support >>>>>> Zero Trust Architecture?" >>>>>> Since I am going to use some sentences of this thread to >>>>>> open a new topic, I changed the title of this thread into : >>>>>> "Relationship between Authentication and Authorization ?" >>>>>> >>>>>> At the moment, I got the impression that nobody agrees >>>>>> any more about *what GNAP is or is not, what it should >>>>>> address and what it should not address*. >>>>>> The components of the model are becoming more numerous >>>>>> and hazy. A new terminology is sometimes being used, but >>>>>> is not yet present in the last published draft. >>>>>> >>>>>> I still can't understand any of the new terms that are >>>>>> being used (*AS-RS* and *AS-RO*), _which are still left >>>>>> undefined_. >>>>>> >>>>>> The last exchanges look more as conversations between >>>>>> workers during the construction of the Babel tower. >>>>>> >>>>>> Last year, my first remark was to mention that a section >>>>>> or an Annex explaining the common points and the >>>>>> differences with OAuth 2.0 >>>>>> would be useful. Such section or Annex still does not exist. >>>>>> >>>>>> Justin wrote: >>>>>> >>>>>> /If an RS allows a username/password HTTP Basic auth >>>>>> in addition to accepting access tokens, it can do so, >>>>>> but // >>>>>> //GNAP doesn’t have anything to say about the Basic >>>>>> auth use, or even its relation to any access tokens >>>>>> or RO’s or anything else./ >>>>>> >>>>>> Let us split the end of this sentence into two parts: >>>>>> >>>>>> "/GNAP doesn’t have anything //to say about the Basic >>>>>> auth use/":  If an authentication exchange  is necessary, >>>>>> the draft document should describe, for completeness, >>>>>> the HTTP error code that will be returned. >>>>>> >>>>>> "/or even its relation to any access tokens or RO’s or >>>>>> anything else/". Let us suppose that a RS supports FIDO >>>>>> as an authentication mechanism to authenticate its end-users. >>>>>> FIDO provides the major advantage that, for every RS, a >>>>>> different identifier is used by every end-user. This >>>>>> prevents end-users accounts correlations between RSs by >>>>>> using >>>>>> such identifiers. In practice, a FIDO identifier is a >>>>>> pseudonym. >>>>>> >>>>>> At this very moment, the RS is able to identify and >>>>>> authenticate its end-users using FIDO pseudonyms. Now, >>>>>> let us raise the following question: >>>>>> >>>>>> How will a RS be bootstrapped for working with a GNAP >>>>>> "sub" claim or a "sub_id" claim, whereas FIDO is already >>>>>> being used ? >>>>>> >>>>>> Denis >>>>>> >>>>>> >>>>>>> Adrian, >>>>>>> >>>>>>> I disagree, I believe that what I have laid out is >>>>>>> exactly separating the concerns into working components. >>>>>>> >>>>>>> Like OAuth before it, GNAP is a protocol negotiate >>>>>>> access for a client instance to an RS, using an AS as >>>>>>> the facilitator of that delegated negotiation. (Unlike >>>>>>> OAuth, it’s importantly also for negotiating user >>>>>>> information to the client directly from the AS with no >>>>>>> RS involved, but that’s an aside for the purposes of our >>>>>>> conversation here). >>>>>>> >>>>>>> If a particular GNAP RS also allows other kinds of >>>>>>> processes to enable access to it, that is completely >>>>>>> fine, but outside of GNAP. If an RS allows a >>>>>>> username/password HTTP Basic auth in addition to >>>>>>> accepting access tokens, it can do so, but GNAP doesn’t >>>>>>> have anything to say about the Basic auth use, or even >>>>>>> its relation to any access tokens or RO’s or anything >>>>>>> else. If an RS accepts structured access tokens signed >>>>>>> by trusted keys that don’t come from an AS through a >>>>>>> negotiated request — again, that’s fine, but GNAP is >>>>>>> silent about the RS doing that. If the RS acts as “its >>>>>>> own AS” then it’s really just an RS and an AS living in >>>>>>> the same box. Again, that’s fine, and super common with >>>>>>> OAuth today. >>>>>>> >>>>>>> GNAP is solving the problem of connecting the client to >>>>>>> the RS through means of an AS. Other solutions are >>>>>>> possible and many of them can be deployed right >>>>>>> alongside, but that’s not the corner of the world that >>>>>>> GNAP is solving. GNAP should be concerned about how >>>>>>> these other technologies can be used alongside it. I >>>>>>> think there’s a lot of room for the things that you’re >>>>>>> talking about, and more importantly for solving the use >>>>>>> cases that you’re bringing. But GNAP should be more than >>>>>>> a single-point solution, and so we need to balance these >>>>>>> concerns. The conceptual framework of an AS that takes >>>>>>> in lots of different information and spits out access >>>>>>> tokens is exactly the abstraction layer that is >>>>>>> necessary for making these use cases interoperable. >>>>>>> >>>>>>>  — Justin >>>>>>> >>>>>>>> On Mar 26, 2021, at 8:30 AM, Adrian Gropper >>>>>>>> >>>>>>> > wrote: >>>>>>>> >>>>>>>> @Justin, there’s no separation of concerns here. No >>>>>>>> partition between processor and controller. No data >>>>>>>> minimization. And, I see no obvious reason to make this >>>>>>>> the core of GNAP. >>>>>>>> >>>>>>>> The one thing we can probably all agree on is that >>>>>>>> there’s only one RS and one RO. >>>>>>>> >>>>>>>> The core of GNAP, in my opinion, can be built and >>>>>>>> explained around this simple design. The RS is a >>>>>>>> processor. The RO is a controller. The RS bears only >>>>>>>> security responsibility. The RS bears no privacy >>>>>>>> responsibility. The RO delegates this to the RS but >>>>>>>> this is not authorization as the A in GNAP. >>>>>>>> >>>>>>>> The RO retains all rights to delegate within the scope >>>>>>>> of things that the RS is willing to support using >>>>>>>> various token formats and endpoint options. Some of >>>>>>>> these options may do all sorts of things for all sorts >>>>>>>> of clients and user-agents  but these are options. >>>>>>>> >>>>>>>> For example, if a request comes to the RS that is not >>>>>>>> in the form of an access token, then it either gets >>>>>>>> sent to the RO or their agent, or it gets logged and >>>>>>>> dumped. One such option, common in healthcare, is >>>>>>>> “Break the Glass” where the RS is acting as an >>>>>>>> authorization server because the user-agent is making a >>>>>>>> request instead of presenting an access token. GNAP can >>>>>>>> offer this as an option but it is not our core. >>>>>>>> >>>>>>>> Adrian >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Mar 26, 2021 at 7:15 AM Justin Richer >>>>>>>> > wrote: >>>>>>>> >>>>>>>> I have a big problem with this line: >>>>>>>> >>>>>>>> > the RS and AS-RS only see access tokens. The >>>>>>>> requests (from RO') that resulted in an access >>>>>>>> token are none of their business. >>>>>>>> >>>>>>>> In the trust model we’ve been discussing, the >>>>>>>> requests that result in access tokens are *solely >>>>>>>> the business of AS-RS*, since AS-RS is the only >>>>>>>> entity that’s allowed, and trusted by the RS, to >>>>>>>> create access tokens for the RS. That is its entire >>>>>>>> job, the entire reason it exists in the system. By >>>>>>>> definition the party generating tokens for use at >>>>>>>> the RS is the AS for that RS, I don’t care how you >>>>>>>> deploy it. If RO wants to give access to someone >>>>>>>> else (who isn’t an “RO" anymore, they’re another >>>>>>>> end-user), then that end user’s client software >>>>>>>> will need to talk to AS-RS to get its own access >>>>>>>> token. >>>>>>>> >>>>>>>> Now here’s the trick: when the end user’s client >>>>>>>> instance talks to AS-RS, that does NOT mean that >>>>>>>> AS-RS needs to know all the details and policy >>>>>>>> reasons that it should give an access token to that >>>>>>>> client instance. It doesn’t even need to know the >>>>>>>> existence of another end user. It doesn’t need >>>>>>>> identity, it doesn’t need policy. Sure, it COULD >>>>>>>> handle all of that internally, and many will, but >>>>>>>> the protocol doesn’t demand it. >>>>>>>> >>>>>>>> This means that the first client instance, the one >>>>>>>> that gets the access token, can also be given >>>>>>>> something alongside the access token that it can >>>>>>>> then hand to another piece of software (or to a >>>>>>>> person to hand eo their piece of software). This >>>>>>>> artifact is not an access token. This artifact >>>>>>>> could be something structured that the client >>>>>>>> understands, and can make derivatives of, and >>>>>>>> present back to the AS-RS for getting new access >>>>>>>> tokens. There could be multiple different flavors >>>>>>>> of this kind of artifact for different kinds of >>>>>>>> environments and groups. But what they all have in >>>>>>>> common is that they can potentially be used to >>>>>>>> request more access tokens within some context at >>>>>>>> the AS-RS. >>>>>>>> >>>>>>>>  — Justin >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Mar 25, 2021, at 5:50 PM, Adrian Gropper >>>>>>>>> >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> My issue is with Alan's: >>>>>>>>> >>>>>>>>> "7. Another user agent (RO') can contact any >>>>>>>>> holder of the access token or the service's >>>>>>>>> policy agent (AS-RS) to get a delegated access >>>>>>>>> token." >>>>>>>>> >>>>>>>>> >>>>>>>>> I would prefer "7A.Another user agent (RO') can >>>>>>>>> contact any holder of the access token." by >>>>>>>>> default so that the AS-RS does not see the >>>>>>>>> requests. In other words, the RS and AS-RS only >>>>>>>>> see access tokens. The requests (from RO') that >>>>>>>>> resulted in an access token are none of their >>>>>>>>> business. >>>>>>>>> >>>>>>>>> The reality is that RO' can discover a resource RS >>>>>>>>> and can share whatever information with RS-AS they >>>>>>>>> want and the RO may not even know about it unless >>>>>>>>> the RS decides to let them know somehow. This >>>>>>>>> seems to be a drawback of the capabilities approach. >>>>>>>>> >>>>>>>>> In terms of privacy and control, I, as the RO, >>>>>>>>> want a contract with the RS that says that I or my >>>>>>>>> agent (AS-RO) must sign an access token. This is a >>>>>>>>> fundamental audit requirement. Without it, a rogue >>>>>>>>> RS and AS-RS can do all sorts of things and the RO >>>>>>>>> would never know. I understand that a rogue RS >>>>>>>>> might not support an honest contemporaneous log of >>>>>>>>> access tokens presented so there's a trust issue >>>>>>>>> here that I seems unavoidable unless I specify in >>>>>>>>> my RO-RS contract that they use a separate >>>>>>>>> contemporaneous log such as AS-RO for every access >>>>>>>>> token presented and risk being sued if they >>>>>>>>> process an access token without also updating the >>>>>>>>> separate log. >>>>>>>>> >>>>>>>>> - Adrian >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Mar 25, 2021 at 1:22 PM Alan Karp >>>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Justin Richer >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> Hi Alan, >>>>>>>>> >>>>>>>>> In all of my discussion, and in the spec >>>>>>>>> itself, the RO is the :entity: in charge >>>>>>>>> of approving rights. They’re probably a >>>>>>>>> person. It might be software that makes a >>>>>>>>> policy decision in some way, or a >>>>>>>>> corporate entity, or something like that. >>>>>>>>> But it’s not assumed to be a computational >>>>>>>>> agent in the terms of the protocol itself. >>>>>>>>> Would that recast what you’re saying below? >>>>>>>>> >>>>>>>>> >>>>>>>>> Hmmm.  I guess not. It's just that the person >>>>>>>>> would be using some UI to express their >>>>>>>>> decisions to what I called the user agent.  >>>>>>>>> That model fits in very nicely with what we >>>>>>>>> did with Polaris, our virus safe computing >>>>>>>>> environment for Windows XP, >>>>>>>>> https://dl.acm.org/doi/10.1145/1151030.1151033 >>>>>>>>> . >>>>>>>>> The person would click on the icon for a Word >>>>>>>>> file, and an instance of Word would open with >>>>>>>>> only the permission needed to edit that one >>>>>>>>> file.  Same thing here. The client could ask >>>>>>>>> for permission to use the resource, or >>>>>>>>> permission could be granted implicitly when >>>>>>>>> the user selects a resource associated with a >>>>>>>>> specific client. >>>>>>>>> >>>>>>>>> -------------- >>>>>>>>> Alan Karp >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Mar 25, 2021 at 9:53 AM Justin Richer >>>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> Hi Alan, >>>>>>>>> >>>>>>>>> In all of my discussion, and in the spec >>>>>>>>> itself, the RO is the :entity: in charge >>>>>>>>> of approving rights. They’re probably a >>>>>>>>> person. It might be software that makes a >>>>>>>>> policy decision in some way, or a >>>>>>>>> corporate entity, or something like that. >>>>>>>>> But it’s not assumed to be a computational >>>>>>>>> agent in the terms of the protocol itself. >>>>>>>>> Would that recast what you’re saying below? >>>>>>>>> >>>>>>>>>  — Justin >>>>>>>>> >>>>>>>>>> On Mar 25, 2021, at 12:36 PM, Alan Karp >>>>>>>>>> >>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>> There seems to be some confusion about >>>>>>>>>> how AS-RO comes into the picture, >>>>>>>>>> probably because of the "AS" part. I'm >>>>>>>>>> going to try to clear up that confusion >>>>>>>>>> by more carefully explaining what I mean. >>>>>>>>>> >>>>>>>>>> I'm assuming that RO is a computational >>>>>>>>>> agent representing the person who is the >>>>>>>>>> resource owner, something called the >>>>>>>>>> "user agent" in operating systems lingo.  >>>>>>>>>> I'm also assuming that it's possible to >>>>>>>>>> do delegation, either locally or by token >>>>>>>>>> exchange with AS-RS.  All delegations are >>>>>>>>>> potentially sub-scoped, but you may also >>>>>>>>>> want to delegate with full scope to have >>>>>>>>>> a separately revocable access token. >>>>>>>>>> >>>>>>>>>>   Here's an example of how things work in >>>>>>>>>> a capability oriented system. >>>>>>>>>> >>>>>>>>>> 1. Someone, the service owner, creates a >>>>>>>>>> service. >>>>>>>>>> 2. The service owner contracts with an >>>>>>>>>> policy agent (AS-RS) to create and >>>>>>>>>> manage access tokens for that service >>>>>>>>>> (RS). >>>>>>>>>> 3. A person wishing to create a resource >>>>>>>>>> at RS uses their user agent (RO) to >>>>>>>>>> contact the service owner's policy >>>>>>>>>> agent (AS-RS) and gets back an access >>>>>>>>>> token for that resource. >>>>>>>>>> 4. That user agent (RO) can >>>>>>>>>> 1. use that access token to invoke >>>>>>>>>> the resource, or >>>>>>>>>> 2. delegate an access token to a >>>>>>>>>> client of the user agent's (RO) >>>>>>>>>> choice, or >>>>>>>>>> 3. contract with a policy agent >>>>>>>>>> (AS-RO) to manage those >>>>>>>>>> delegations on behalf of the user >>>>>>>>>> agent (RO), or >>>>>>>>>> 4. specify a policy with the >>>>>>>>>> service's policy agent (AS-RS). >>>>>>>>>> 5. A client can contact any holder of >>>>>>>>>> the access token (the user agent (RO) >>>>>>>>>> or its policy agent (AS-RO)) or the >>>>>>>>>> service's policy agent (AS-RS) to get >>>>>>>>>> a delegated access token. >>>>>>>>>> 6. That client can delegate that token >>>>>>>>>> to another client. >>>>>>>>>> 7. Another user agent (RO') can contact >>>>>>>>>> any holder of the access token or the >>>>>>>>>> service's policy agent (AS-RS) to get >>>>>>>>>> a delegated access token. >>>>>>>>>> 8. The other user agent (RO') can >>>>>>>>>> 1. use that access token to invoke >>>>>>>>>> the resource, or >>>>>>>>>> 2. delegate it to a client of its >>>>>>>>>> choice, or >>>>>>>>>> 3. contract with a policy agent >>>>>>>>>> (AS-RO') of its choosing to >>>>>>>>>> manage those delegations on its >>>>>>>>>> behalf, or >>>>>>>>>> 4. specify a policy with the >>>>>>>>>> service's policy agent (AS-RS). >>>>>>>>>> 9. and so on >>>>>>>>>> >>>>>>>>>> When any of these computational agents, >>>>>>>>>> user agents (ROs) or clients acting on >>>>>>>>>> their behalf, invokes the resource, AS-RS >>>>>>>>>> verifies that the access token is a valid >>>>>>>>>> delegation, i.e., proper sub-scoping, >>>>>>>>>> hasn't been revoked, and that it >>>>>>>>>> authorizes the request being made before >>>>>>>>>> telling the service (RS) to honor the >>>>>>>>>> request.  At no point does the service's >>>>>>>>>> policy agent (AS-RS) know which >>>>>>>>>> computational agent did any particular >>>>>>>>>> delegation. (Token exchange can be done >>>>>>>>>> as anonymously as possible.)  In >>>>>>>>>> particular, the policy agents (AS-RO) >>>>>>>>>> need not be the same, or even compatible >>>>>>>>>> with, the service's policy agent >>>>>>>>>> (AS-RS).  GNAP specifies the protocol >>>>>>>>>> between requesters, invokers, delegators >>>>>>>>>> (for token exchange) of tokens and >>>>>>>>>> AS-RS.  That protocol need not be used >>>>>>>>>> between user agents (RO), clients, or >>>>>>>>>> other policy agents (AS-RO), but it is >>>>>>>>>> likely to be. >>>>>>>>>> >>>>>>>>>>  ------------- >>>>>>>>>> Alan Karp >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Mar 25, 2021 at 5:45 AM Justin >>>>>>>>>> Richer >>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>> The way I’m thinking about Adrian’s >>>>>>>>>> use case is that what we’re calling >>>>>>>>>> the “AS-RO” isn’t an “AS” in the >>>>>>>>>> traditional OAuth/GNAP sense, at >>>>>>>>>> least not exactly. This is the agent >>>>>>>>>> that the RO can use to set policies >>>>>>>>>> and manage consent on their behalf, >>>>>>>>>> and I’ve been arguing that it fits >>>>>>>>>> better into this vaguely-defined >>>>>>>>>> “interaction component” aspect of the >>>>>>>>>> current AS definition, and it’s not >>>>>>>>>> currently separated from the AS >>>>>>>>>> definition. The “AS-RS” maps to what >>>>>>>>>> we’d call the “AS” in OAuth/GNAP >>>>>>>>>> traditionally, it’s what the RS >>>>>>>>>> trusts to issue tokens. In >>>>>>>>>> traditional OAuth the AS-RO and AS-RS >>>>>>>>>> are always the same thing, from a >>>>>>>>>> functional protocol perspective. An >>>>>>>>>> important point here is that from a >>>>>>>>>> client’s perspective, they’re only >>>>>>>>>> talking to the AS-RS since that’s >>>>>>>>>> where the client gets its tokens, >>>>>>>>>> because at the end of the day the >>>>>>>>>> client just wants to call the API at >>>>>>>>>> the RS and doesn’t care how that >>>>>>>>>> happens (from a protocol standpoint). >>>>>>>>>> >>>>>>>>>> Note well: Even thought I don’t >>>>>>>>>> believe that “AS-RO” is an >>>>>>>>>> authorization server at all, I’m >>>>>>>>>> going to keep using that term below >>>>>>>>>> for consistency with previous discussion. >>>>>>>>>> >>>>>>>>>> So we have these fundamental >>>>>>>>>> relationships around getting the >>>>>>>>>> client to access the RS: >>>>>>>>>> >>>>>>>>>> 1. RS trusts AS-RS to issue tokens >>>>>>>>>> that RS will accept, validate, and >>>>>>>>>> process for requests from client >>>>>>>>>> 2. Client trusts AS-RS to issue >>>>>>>>>> tokens that client can use at RS >>>>>>>>>> 3. RO trusts RS to protect RO’s api >>>>>>>>>> through delegated access >>>>>>>>>> >>>>>>>>>> On top of that, we’ve got some >>>>>>>>>> additional aspects that we’re discussing: >>>>>>>>>> >>>>>>>>>> 4. RO trusts AS-RO to manage RO’s >>>>>>>>>> policies at runtime >>>>>>>>>> 5. AS-RS trusts AS-RO to assert RO’s >>>>>>>>>> policies for access to RS >>>>>>>>>> 6. Client trusts whatever AS-RS sends >>>>>>>>>> client to deal with, including >>>>>>>>>> possibly RO-AS at runtime, because of (2) >>>>>>>>>> >>>>>>>>>> What I have been saying is that 4/5/6 >>>>>>>>>> are optional details of how RS-AS >>>>>>>>>> runs things, and I think this also >>>>>>>>>> maps with Adrian’s view of choice, >>>>>>>>>> since if my RS’s AS-RS doesn’t allow >>>>>>>>>> me to plug in my own AS-RO then I >>>>>>>>>> would be motivated to pick a >>>>>>>>>> different RS who’s AS-RS lets me do >>>>>>>>>> just that. The same way I’d pick a >>>>>>>>>> different RS if their surrounding >>>>>>>>>> services didn’t accept my preferred >>>>>>>>>> federation login and I didn’t want to >>>>>>>>>> make another account. Of course, >>>>>>>>>> market forces being as they are, I >>>>>>>>>> might not have much of an actionable >>>>>>>>>> choice in RS, but GNAP can’t change >>>>>>>>>> that. >>>>>>>>>> >>>>>>>>>> What we can do is make it possible >>>>>>>>>> for AS-RS to talk to AS-RO, both in >>>>>>>>>> philosophy of the protocol design and >>>>>>>>>> in concrete hooks to support (6) above. >>>>>>>>>> >>>>>>>>>> Separately, we can approach the issue >>>>>>>>>> of making 1/2 above more dynamic. >>>>>>>>>> This was UMA2’s “federated >>>>>>>>>> authorization” approach, and is >>>>>>>>>> behind a lot of the “bring your own >>>>>>>>>> AS” models out there. The problem >>>>>>>>>> with these is that we know from many >>>>>>>>>> years of experience that most RS’s >>>>>>>>>> aren’t interested in doing anything >>>>>>>>>> of the sort. >>>>>>>>>> >>>>>>>>>> So with GNAP we can instead allow >>>>>>>>>> 4/5/6 to vary in a predictable and >>>>>>>>>> consistent way, letting the RS keep >>>>>>>>>> control over 1/2, thereby enabling >>>>>>>>>> choice in (3). We don’t have to be >>>>>>>>>> the ones who define the all of the >>>>>>>>>> details of every permutation of (5) >>>>>>>>>> to enable this, though. Some of this >>>>>>>>>> is going to be configuration out of >>>>>>>>>> band, some of it’s going to be >>>>>>>>>> communication at runtime. This is >>>>>>>>>> where VC’s, ZCAPs, CHAPI, DIDComm, >>>>>>>>>> FIDO, and a whole swath of other tech >>>>>>>>>> can come in and help out. I don’t >>>>>>>>>> think we need to put all the details >>>>>>>>>> for using these into core, nor do I >>>>>>>>>> think we’ll pull of The Great And >>>>>>>>>> Ultimate Abstraction for using these >>>>>>>>>> and other approaches. But we can at >>>>>>>>>> least start talking about “AS-RS” in >>>>>>>>>> such a way that it no longer assumes >>>>>>>>>> it’s always the same party dealing >>>>>>>>>> with the RO directly. >>>>>>>>>> >>>>>>>>>>  — Justin >>>>>>>>>> >>>>>>>>>>> On Mar 25, 2021, at 6:40 AM, Fabien >>>>>>>>>>> Imbault >>>>>>>>>> > >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> To reframe it closer to GNAP: >>>>>>>>>>> - AS = AS-RO, that's where you find >>>>>>>>>>> the RO policies. The AS issues >>>>>>>>>>> access tokens to the client. >>>>>>>>>>> - the RO policies could be a) >>>>>>>>>>> defined locally or b) in >>>>>>>>>>> relationship with the RS >>>>>>>>>>> >>>>>>>>>>> There have been several ideas >>>>>>>>>>> related to the AS-RS relationship b: >>>>>>>>>>> b1) the RS issues capabilities >>>>>>>>>>> (which can be further attenuated by >>>>>>>>>>> the RO) >>>>>>>>>>> b2) Adrian also discussed a DID >>>>>>>>>>> based solution >>>>>>>>>>> b3) there was also an alternative >>>>>>>>>>> ACL proposal from Denis (+ preflight) >>>>>>>>>>> > --------------2DC03CCC383D20505EC30945 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
    Adrian,

    I changed the title of this thread since your are addressing a new topic that I am unable to understand.
    Alice J&J vaccine is Alice's private information. For which reason would Bob ask Alice to provide an access token ?

    Denis

    This is helpful, Denis. 

    I will focus on "Then Bob asks to Alice to issue for him an authorization to access the resource." and avoid using any hammers. 

    Let's use something in the news and say the RS is a hospital that gave Alice a J&J COVID vaccine. Alice identified herself to the hospital with a number N. N could have been randomly chosen by Alice or the hospital or N could be Alice's driver's license number right next to her face photo. GNAP should probably deal with both cases. 

    The hospital creates a digital credential that includes the J&J vaccine name and lot number, N, a statement about how N was derived, and a date. The hospital posts this credential at some resource URL, protected by some access token requirement, and gives Alice the "resource URL" instead of or along with a paper vaccination card with the same information as the resource.

    When Bob asks Alice for an access token, Bob makes a request to Alice and she can either:
    A - Give Bob the "resource URL" and let him try his luck turning this into an access token somewhere,
    B - Go to the hospital portal and authenticate somehow and grab an access token that she can return to Bob,
    C - Give Bob an access token for the resource URL based on some signature that is trusted by the hospital.

    When Bob gets the resource, it will include N along with the hospital's statement about how N was derived. Bob can decide what to do next.

    Adrian


    On Mon, Mar 29, 2021 at 9:54 AM Denis <denis.ietf@free.fr> wrote:
    Hi Adrian,

    Thank you for the scenario. You certainly know the following sentence:
    "When the only tool you have is a hammer, every problem looks like a nail".
    Similarly:  "When the only tool you have is an AS, every problem looks like an access token issued by an AS".

    Let us start with exactly the same sentence that explains the goal:
    Let Alice be the RO and subject of a resource. at a RS. Let Bob be a party, not Alice, that seeks authorization to access the resource using an access token.
    Then Bob asks to Alice to issue for him an authorization to access the resource.
    Alice, as the RO of the resource, request from the RS an "access token"  which is an (unsigned) data structure which contains:
    a read permission on some Alice's photo directory, associated with a large random number chosen by the RS.

    Note that a validity period will also be associated in practice, but this is a minor detail for the demonstration.

    Alice sends back to Bob the "access token" issued by the RS.

    Bob looks inside the access token to make sure that it corresponds to what he requested to Alice, i.e. a read permission on some Alice's photo directory.

    If the content is fine, Bob presents to the RS the large random number associated together with an API GET for some sub-set of the photos contained in Alice's directory.

    Since the RS recognizes the large random number and that the GET API is valid according to the "access token" memorized by the RS authorization set by Alice as a RO,
    the access is granted.

    In this example, the RS will not know who is reading the photo directory. So Bob can transmit the "access token" to someone else during its validity period, which may be a desirable feature.
    Note that it is also possible to allow Bob only to access Alice's directory. For simplicity, this alternative is not explained.

    In the mean time, I solved the answer of your question which was:" How Bob discovered the AS to make the request to is unclear to me for the time being".
    The request to your question is also unclear to me for the time being, but since there is no AS involved, Bob does not need to discover any AS. :-)

    I am quite sure that someone else will be able to describe one or more scenarios "using an AS as an hammer", but is is very likely that in such a case,
    the AS will be able know that Bob is rather likely to access in a short time some photos placed in the Alice's directory of photo hosted on that RS.
    This may be a privacy concern for Bob    .

    Of course, in addition, the AS and the RS must establish some prior relationships, etc ...

    However, all the discussion above is outside the scope of this initial thread which is: Relationship between Authentication and Authorization ?
    If you want to continue the discussion on the topic you mentioned, that's fine with me, but please change the title of this thread.

    Denis


    Hi Denis,

    I don’t understand your privacy issue, and I would like to try. 

    Let Alice be the RO and subject of a resource. at a RS. Let Bob be a party, not Alice, that seeks authorization to access the resource using an access token. 

    Bob has discovered the resource somehow that is out of band for GNAP. (Maybe Alice sent Bob a pointer to the resource in an email).

    Bob makes a request for the resource at some AS. The request includes the pointer that Bob discovered to the resource, some attributes or claims about Bob, and maybe a reason for the request. 

    How Bob discovered the AS to make the request to is unclear to me for the time being. Maybe Bob discovered the AS along with the resource. (e.g The resource is a DID and the AS is a service endpoint or mediator to an AS in that DID.)

    Given the scenario above, who’s privacy interest are you primarily concerned about? Alice or Bob? 

    Adrian

    On Mon, Mar 29, 2021 at 6:39 AM Denis <denis.ietf@free.fr> wrote:
    Hi  Justin,

    Since your response only deals with the AS, but not the RS nor the RO, it is not a response to my question which was:
    How will a RS or a RO be bootstrapped for working with a GNAP "sub" claim or a "sub_id" claim ?
    The subject identifier is whatever identifier the AS knows the subject as. If they log in using only a FIDO token and the AS asserts that key value as the identifier, then that’s what it will be. If they sign up with an email address or make a username or get assigned a random number, that’s what it will be. Or they could sign up using any number of those and the AS still assigns them a random value, because it’s always the AS that determines which value to assign the number.

    When looking at Section 3.2 (Access Tokens), the client (and hence the end-user) has currently no practical way to indicate which of its attributes should be placed into an access token,
    The only reference within Section 3.2 is pointing to the empty Section 12. Among the many examples, there is not a single example that addresses the case of attributes being placed into an access token.

    Nevertheless, it seems that in your opinion, only the AS, but NOT the client (and hence the end-user), SHALL have control at all of what kind of subject identifier claim will be placed inside the access token.

    Then after, invoking the postulate "the access token SHALL remain opaque to the client (and hence the end-user)", it seems that in your opinion, the end-user SHALL have no way to verify
    whether its privacy has been respected. If this is not an architecture built along "spy by design" principles, I don't know what else it might be.

    It is important to re-read two of the current definitions:

    Privilege: right or attribute associated with a subject.

    Access Token: data artifact representing a set of rights and/or attributes.

    In the current draft, the case of rights is indeed addressed while the case of attributes is fully ignored.

    The RS is not involved in any subject information. Identity APIs, like OpenID Connect’s UserInfo Endpoint, are out of scope for GNAP.

    Really ? Do you mean that an access token should not contain a "sub" claim nor a "sub_id" claim  and if it does, the RS SHALL ignore such claims ?

    In the "OAuth Access Token JWT Profile", there is the following sentence in Section 6 (Privacy Considerations) :

       This profile mandates the presence of the "sub" claim in every JWT
       access token, making it possible for resource servers to rely on that
       information for performing tasks such as correlating incoming
       requests with data stored locally for the authenticated principal. 

    This sentence clearly makes a relationship between the value present in the "sub" claim and "data stored locally for the authenticated principal".

    However, note that the "OAuth Access Token JWT Profile" fails to allow the client (and hence the end-user) to control his privacy, since the client
    cannot choose which value will be placed in the "sub" claim and also because access tokens are considered to be opaque for the clients in OAuth.
    If there is a subject identifier either included in or referenced by the access token, that is up to any agreements between the AS and RS
    that lead to the ability of the AS to create the tokens the RS can trust. All of this is outside the scope of the core GNAP protocol and invisible to the client.

    You are using the following words "up to any agreements between the AS and RS". This mandates prior agreements between ASs and RSs
    and in such a case the architecture will be non-scalable over the Internet. The trust relationship between a RS and an AS is unilateral:
    The RS trusts the AS to issue appropriate access tokens corresponding to the requests of its clients.

    From an end-user point of view, if there cannot be transparency because of the access token opacity, then there cannot be confidence about GNAP .

    Denis


     — Justin

    On Mar 26, 2021, at 1:27 PM, Denis <denis.ietf@free.fr> wrote:

    Hi Justin,

    Let me rephrase the last question: How will a RS or a RO be bootstrapped for working with a GNAP "sub" claim or a "sub_id" claim ?

    Denis

    GNAP doesn’t have anything too say about anybody authenticating directly to the RS. If that happens, it’s out of the view and out of scope of GNAP.

     — Justin

    On Mar 26, 2021, at 1:06 PM, Denis <denis.ietf@free.fr> wrote:

    Hi everybody,

    The content of this thread has nothing to do any more with its original title which was: "Will GNAP support Zero Trust Architecture?"
    Since I am going to use some sentences of this thread to open a new topic, I changed the title of this thread into :
    "Relationship between Authentication and Authorization ?"

    At the moment, I got the impression that nobody agrees any more about what GNAP is or is not, what it should address and what it should not address.
    The components of the model are becoming more numerous and hazy. A new terminology is sometimes being used, but is not yet present in the last published draft.

    I still can't understand any of the new terms that are being used (AS-RS and AS-RO), which are still left undefined.

    The last exchanges look more as conversations between workers during the construction of the Babel tower.

    Last year, my first remark was to mention that a section or an Annex explaining the common points and the differences with OAuth 2.0
    would be useful. Such section or Annex still does not exist.

    Justin wrote:
    If an RS allows a username/password HTTP Basic auth in addition to accepting access tokens, it can do so, but
    GNAP doesn’t have anything to say about the Basic auth use, or even its relation to any access tokens or RO’s or anything else.
    Let us split the end of this sentence into two parts:

    "GNAP doesn’t have anything to say about the Basic auth use":  If an authentication exchange  is necessary, the draft document should describe, for completeness,
    the HTTP error code that will be returned.

    "or even its relation to any access tokens or RO’s or anything else". Let us suppose that a RS supports FIDO as an authentication mechanism to authenticate its end-users.
    FIDO provides the major advantage that, for every RS, a different identifier is used by every end-user. This prevents end-users accounts correlations between RSs by using
    such identifiers. In practice, a FIDO identifier is a pseudonym.

    At this very moment, the RS is able to identify and authenticate its end-users using FIDO pseudonyms. Now, let us raise the following question:

    How will a RS be bootstrapped for working with a GNAP "sub" claim or a "sub_id" claim, whereas FIDO is already being used ?

    Denis


    Adrian,

    I disagree, I believe that what I have laid out is exactly separating the concerns into working components. 

    Like OAuth before it, GNAP is a protocol negotiate access for a client instance to an RS, using an AS as the facilitator of that delegated negotiation. (Unlike OAuth, it’s importantly also for negotiating user information to the client directly from the AS with no RS involved, but that’s an aside for the purposes of our conversation here).

    If a particular GNAP RS also allows other kinds of processes to enable access to it, that is completely fine, but outside of GNAP. If an RS allows a username/password HTTP Basic auth in addition to accepting access tokens, it can do so, but GNAP doesn’t have anything to say about the Basic auth use, or even its relation to any access tokens or RO’s or anything else. If an RS accepts structured access tokens signed by trusted keys that don’t come from an AS through a negotiated request — again, that’s fine, but GNAP is silent about the RS doing that. If the RS acts as “its own AS” then it’s really just an RS and an AS living in the same box. Again, that’s fine, and super common with OAuth today. 

    GNAP is solving the problem of connecting the client to the RS through means of an AS. Other solutions are possible and many of them can be deployed right alongside, but that’s not the corner of the world that GNAP is solving. GNAP should be concerned about how these other technologies can be used alongside it. I think there’s a lot of room for the things that you’re talking about, and more importantly for solving the use cases that you’re bringing. But GNAP should be more than a single-point solution, and so we need to balance these concerns. The conceptual framework of an AS that takes in lots of different information and spits out access tokens is exactly the abstraction layer that is necessary for making these use cases interoperable.

     — Justin

    On Mar 26, 2021, at 8:30 AM, Adrian Gropper <agropper@healthurl.com> wrote:

    @Justin, there’s no separation of concerns here. No partition between processor and controller. No data minimization. And, I see no obvious reason to make this the core of GNAP. 

    The one thing we can probably all agree on is that there’s only one RS and one RO. 

    The core of GNAP, in my opinion, can be built and explained around this simple design. The RS is a processor. The RO is a controller. The RS bears only security responsibility. The RS bears no privacy responsibility. The RO delegates this to the RS but this is not authorization as the A in GNAP.

    The RO retains all rights to delegate within the scope of things that the RS is willing to support using various token formats and endpoint options. Some of these options may do all sorts of things for all sorts of clients and user-agents  but these are options. 

    For example, if a request comes to the RS that is not in the form of an access token, then it either gets sent to the RO or their agent, or it gets logged and dumped. One such option, common in healthcare, is “Break the Glass” where the RS is acting as an authorization server because the user-agent is making a request instead of presenting an access token. GNAP can offer this as an option but it is not our core.

    Adrian



    On Fri, Mar 26, 2021 at 7:15 AM Justin Richer <jricher@mit.edu> wrote:
    I have a big problem with this line:

    > the RS and AS-RS only see access tokens. The requests (from RO') that resulted in an access token are none of their business.

    In the trust model we’ve been discussing, the requests that result in access tokens are solely the business of AS-RS, since AS-RS is the only entity that’s allowed, and trusted by the RS, to create access tokens for the RS. That is its entire job, the entire reason it exists in the system. By definition the party generating tokens for use at the RS is the AS for that RS, I don’t care how you deploy it. If RO wants to give access to someone else (who isn’t an “RO" anymore, they’re another end-user), then that end user’s client software will need to talk to AS-RS to get its own access token.

    Now here’s the trick: when the end user’s client instance talks to AS-RS, that does NOT mean that AS-RS needs to know all the details and policy reasons that it should give an access token to that client instance. It doesn’t even need to know the existence of another end user. It doesn’t need identity, it doesn’t need policy. Sure, it COULD handle all of that internally, and many will, but the protocol doesn’t demand it. 

    This means that the first client instance, the one that gets the access token, can also be given something alongside the access token that it can then hand to another piece of software (or to a person to hand eo their piece of software). This artifact is not an access token. This artifact could be something structured that the client understands, and can make derivatives of, and present back to the AS-RS for getting new access tokens. There could be multiple different flavors of this kind of artifact for different kinds of environments and groups. But what they all have in common is that they can potentially be used to request more access tokens within some context at the AS-RS.

     — Justin



    On Mar 25, 2021, at 5:50 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    My issue is with Alan's:
    "7. Another user agent (RO') can contact any holder of the access token or the service's policy agent (AS-RS) to get a delegated access token."

    I would prefer "7A. Another user agent (RO') can contact any holder of the access token." by default so that the AS-RS does not see the requests. In other words, the RS and AS-RS only see access tokens. The requests (from RO') that resulted in an access token are none of their business.

    The reality is that RO' can discover a resource RS and can share whatever information with RS-AS they want and the RO may not even know about it unless the RS decides to let them know somehow. This seems to be a drawback of the capabilities approach. 

    In terms of privacy and control, I, as the RO, want a contract with the RS that says that I or my agent (AS-RO) must sign an access token. This is a fundamental audit requirement. Without it, a rogue RS and AS-RS can do all sorts of things and the RO would never know. I understand that a rogue RS might not support an honest contemporaneous log of access tokens presented so there's a trust issue here that I seems unavoidable unless I specify in my RO-RS contract that they use a separate contemporaneous log such as AS-RO for every access token presented and risk being sued if they process an access token without also updating the separate log.

    - Adrian


    On Thu, Mar 25, 2021 at 1:22 PM Alan Karp <alanhkarp@gmail.com> wrote:
    Justin Richer <jricher@mit.edu> wrote:
    Hi Alan,

    In all of my discussion, and in the spec itself, the RO is the :entity: in charge of approving rights. They’re probably a person. It might be software that makes a policy decision in some way, or a corporate entity, or something like that. But it’s not assumed to be a computational agent in the terms of the protocol itself. Would that recast what you’re saying below?

    Hmmm.  I guess not.  It's just that the person would be using some UI to express their decisions to what I called the user agent.  That model fits in very nicely with what we did with Polaris, our virus safe computing environment for Windows XP, https://dl.acm.org/doi/10.1145/1151030.1151033.  The person would click on the icon for a Word file, and an instance of Word would open with only the permission needed to edit that one file.  Same thing here.  The client could ask for permission to use the resource, or permission could be granted implicitly when the user selects a resource associated with a specific client.

    --------------
    Alan Karp


    On Thu, Mar 25, 2021 at 9:53 AM Justin Richer <jricher@mit.edu> wrote:
    Hi Alan,

    In all of my discussion, and in the spec itself, the RO is the :entity: in charge of approving rights. They’re probably a person. It might be software that makes a policy decision in some way, or a corporate entity, or something like that. But it’s not assumed to be a computational agent in the terms of the protocol itself. Would that recast what you’re saying below?

     — Justin

    On Mar 25, 2021, at 12:36 PM, Alan Karp <alanhkarp@gmail.com> wrote:

    There seems to be some confusion about how AS-RO comes into the picture, probably because of the "AS" part.  I'm going to try to clear up that confusion by more carefully explaining what I mean.

    I'm assuming that RO is a computational agent representing the person who is the resource owner, something called the "user agent" in operating systems lingo.  I'm also assuming that it's possible to do delegation, either locally or by token exchange with AS-RS.  All delegations are potentially sub-scoped, but you may also want to delegate with full scope to have a separately revocable access token.

      Here's an example of how things work in a capability oriented system.
    1. Someone, the service owner, creates a service.
    2. The service owner contracts with an policy agent (AS-RS) to create and manage access tokens for that service (RS).
    3. A person wishing to create a resource at RS uses their user agent (RO) to contact the service owner's policy agent (AS-RS) and gets back an access token for that resource.
    4. That user agent (RO) can 
      1. use that access token to invoke the resource, or
      2. delegate an access token to a client of the user agent's (RO) choice, or
      3. contract with a policy agent (AS-RO) to manage those delegations on behalf of the user agent (RO), or
      4. specify a policy with the service's policy agent (AS-RS).
    5. A client can contact any holder of the access token (the user agent (RO) or its policy agent (AS-RO)) or the service's policy agent (AS-RS) to get a delegated access token.
    6. That client can delegate that token to another client.
    7. Another user agent (RO') can contact any holder of the access token or the service's policy agent (AS-RS) to get a delegated access token.
    8. The other user agent (RO') can 
      1. use that access token to invoke the resource, or
      2. delegate it to a client of its choice, or
      3. contract with a policy agent (AS-RO') of its choosing to manage those delegations on its behalf, or
      4. specify a policy with the service's policy agent (AS-RS).
    9. and so on
    When any of these computational agents, user agents (ROs) or clients acting on their behalf, invokes the resource, AS-RS verifies that the access token is a valid delegation, i.e., proper sub-scoping, hasn't been revoked, and that it authorizes the request being made before telling the service (RS) to honor the request.  At no point does the service's policy agent (AS-RS) know which computational agent did any particular delegation.  (Token exchange can be done as anonymously as possible.)  In particular, the policy agents (AS-RO) need not be the same, or even compatible with, the service's policy agent (AS-RS).  GNAP specifies the protocol between requesters, invokers, delegators (for token exchange) of tokens and AS-RS.  That protocol need not be used between user agents (RO), clients, or other policy agents (AS-RO), but it is likely to be.

     -------------
    Alan Karp


    On Thu, Mar 25, 2021 at 5:45 AM Justin Richer <jricher@mit.edu> wrote:
    The way I’m thinking about Adrian’s use case is that what we’re calling the “AS-RO” isn’t an “AS” in the traditional OAuth/GNAP sense, at least not exactly. This is the agent that the RO can use to set policies and manage consent on their behalf, and I’ve been arguing that it fits better into this vaguely-defined “interaction component” aspect of the current AS definition, and it’s not currently separated from the AS definition. The “AS-RS” maps to what we’d call the “AS” in OAuth/GNAP traditionally, it’s what the RS trusts to issue tokens. In traditional OAuth the AS-RO and AS-RS are always the same thing, from a functional protocol perspective. An important point here is that from a client’s perspective, they’re only talking to the AS-RS since that’s where the client gets its tokens, because at the end of the day the client just wants to call the API at the RS and doesn’t care how that happens (from a protocol standpoint). 

    Note well: Even thought I don’t believe that “AS-RO” is an authorization server at all, I’m going to keep using that term below for consistency with previous discussion.

    So we have these fundamental relationships around getting the client to access the RS:

    1. RS trusts AS-RS to issue tokens that RS will accept, validate, and process for requests from client
    2. Client trusts AS-RS to issue tokens that client can use at RS
    3. RO trusts RS to protect RO’s api through delegated access

    On top of that, we’ve got some additional aspects that we’re discussing:

    4. RO trusts AS-RO to manage RO’s policies at runtime
    5. AS-RS trusts AS-RO to assert RO’s policies for access to RS
    6. Client trusts whatever AS-RS sends client to deal with, including possibly RO-AS at runtime, because of (2)

    What I have been saying is that 4/5/6 are optional details of how RS-AS runs things, and I think this also maps with Adrian’s view of choice, since if my RS’s AS-RS doesn’t allow me to plug in my own AS-RO then I would be motivated to pick a different RS who’s AS-RS lets me do just that. The same way I’d pick a different RS if their surrounding services didn’t accept my preferred federation login and I didn’t want to make another account. Of course, market forces being as they are, I might not have much of an actionable choice in RS, but GNAP can’t change that. 

    What we can do is make it possible for AS-RS to talk to AS-RO, both in philosophy of the protocol design and in concrete hooks to support (6) above. 

    Separately, we can approach the issue of making 1/2 above more dynamic. This was UMA2’s “federated authorization” approach, and is behind a lot of the “bring your own AS” models out there. The problem with these is that we know from many years of experience that most RS’s aren’t interested in doing anything of the sort.

    So with GNAP we can instead allow 4/5/6 to vary in a predictable and consistent way, letting the RS keep control over 1/2, thereby enabling choice in (3). We don’t have to be the ones who define the all of the details of every permutation of (5) to enable this, though. Some of this is going to be configuration out of band, some of it’s going to be communication at runtime. This is where VC’s, ZCAPs, CHAPI, DIDComm, FIDO, and a whole swath of other tech can come in and help out. I don’t think we need to put all the details for using these into core, nor do I think we’ll pull of The Great And Ultimate Abstraction for using these and other approaches. But we can at least start talking about “AS-RS” in such a way that it no longer assumes it’s always the same party dealing with the RO directly.

     — Justin

    On Mar 25, 2021, at 6:40 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    To reframe it closer to GNAP:
    - AS = AS-RO, that's where you find the RO policies. The AS issues access tokens to the client.
    - the RO policies could be a) defined locally or b) in relationship with the RS

    There have been several ideas related to the AS-RS relationship b:
    b1) the RS issues capabilities (which can be further attenuated by the RO)
    b2) Adrian also discussed a DID based solution
    b3) there was also an alternative ACL proposal from Denis (+ preflight)



    --------------2DC03CCC383D20505EC30945-- From nobody Mon Mar 29 11:38:12 2021 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 0CC743A1E00 for ; Mon, 29 Mar 2021 11:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 VUGKwKK_lhpp for ; Mon, 29 Mar 2021 11:38:05 -0700 (PDT) Received: from mail-vk1-f171.google.com (mail-vk1-f171.google.com [209.85.221.171]) (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 9F2393A1DF2 for ; Mon, 29 Mar 2021 11:38:04 -0700 (PDT) Received: by mail-vk1-f171.google.com with SMTP id b10so3017351vkl.0 for ; Mon, 29 Mar 2021 11:38:04 -0700 (PDT) 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=DbOfqoAHJacEOpvHFuTf2twuI+Pf7VFlZJxwNuuMhCw=; b=qsiE5JTLS/S7kOIkgSgjyCDu+QwlMp07idP5wuzApaDMGTENzZ9Gj6KWcNq1Uo52ui rMY8C1g4/1fl03AbTpXIbrDaWFkp4JTNo9j3GY2+gJt/k6pm9gmToAcpudo4Mlb8l5le gkB/aWiPAGyAetfrN2vNAhVHVn8nP5cvPF98RJLu4F04N3lS9KPQbuXKP20eAcry6LR5 7mRw8X2u7/XIMjD6fUl//x8pm+b0MusYFFe3cmBCjYNI50YXVNfEMfkNjNKOUdlBkn6i 4IPYgpGnAsgfyqbwG/Pm/+WJ3vni9tHTL21jLaoH7Dqzm0hRBMrKqc66mCufvStbDUk/ AiHw== X-Gm-Message-State: AOAM532KRkyiTkt7881SqOnh7DcIPyxf9mDM38W3uOWd3Xhn0r8V2RYn TMq6lBUc10JSZy4RQCixx9o5T3L7xUl4XxBWYw2MTYWY82hd7Q== X-Google-Smtp-Source: ABdhPJw6/jkxjERUUlTRemEsOF6DJn0Vr7GhqaTbq57NYOoq6CmPgvBSwEQ8XZv7YVt+iJ5cLAq2CN+7exswoWM1LNQ= X-Received: by 2002:a1f:914c:: with SMTP id t73mr15405349vkd.7.1617043083283; Mon, 29 Mar 2021 11:38:03 -0700 (PDT) MIME-Version: 1.0 References: <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> <5773FA7B-6891-4227-A8CA-2F506909B8CD@mit.edu> <3c103293-56a1-4be5-e2a3-12eb82d13238@free.fr> <91D11E67-34AB-4426-803C-7B5A6F50537F@mit.edu> In-Reply-To: From: Adrian Gropper Date: Mon, 29 Mar 2021 14:37:51 -0400 Message-ID: To: Denis Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000090d2c605beb12e62" Archived-At: Subject: Re: [GNAP] Alice a J&J COVID vaccine X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2021 18:38:10 -0000 --00000000000090d2c605beb12e62 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Here's an example: https://www.governor.ny.gov/news/governor-cuomo-announces-pilot-program-tes= ting-excelsior-pass-madison-square-garden-and Bob is manning the gate at Madison Square Garden. Adrian On Mon, Mar 29, 2021 at 1:19 PM Denis wrote: > Adrian, > > I changed the title of this thread since your are addressing a new topic > that I am unable to understand. > Alice J&J vaccine is Alice's private information. For which reason would > Bob ask Alice to provide an access token ? > > Denis > > This is helpful, Denis. > > I will focus on "Then Bob asks to Alice to issue for him an authorization > to access the resource." and avoid using any hammers. > > Let's use something in the news and say the RS is a hospital that gave > Alice a J&J COVID vaccine. Alice identified herself to the hospital with = a > number N. N could have been randomly chosen by Alice or the hospital or N > could be Alice's driver's license number right next to her face photo. GN= AP > should probably deal with both cases. > > The hospital creates a digital credential that includes the J&J vaccine > name and lot number, N, a statement about how N was derived, and a date. > The hospital posts this credential at some resource URL, protected by som= e > access token requirement, and gives Alice the "resource URL" instead of o= r > along with a paper vaccination card with the same information as the > resource. > > When Bob asks Alice for an access token, Bob makes a request to Alice and > she can either: > A - Give Bob the "resource URL" and let him try his luck turning this int= o > an access token somewhere, > B - Go to the hospital portal and authenticate somehow and grab an access > token that she can return to Bob, > C - Give Bob an access token for the resource URL based on some signature > that is trusted by the hospital. > > When Bob gets the resource, it will include N along with the hospital's > statement about how N was derived. Bob can decide what to do next. > > Adrian > > > On Mon, Mar 29, 2021 at 9:54 AM Denis wrote: > >> Hi Adrian, >> >> Thank you for the scenario. You certainly know the following sentence: >> >> "When the only tool you have is a hammer, every problem looks like a >> nail". >> >> Similarly: "When the only tool you have is an AS, every problem looks >> like an access token issued by an AS". >> >> Let us start with exactly the same sentence that explains the goal: >> >> Let Alice be the RO and subject of a resource. at a RS. Let Bob be a >> party, not Alice, that seeks authorization to access the resource using = an >> access token. >> >> Then Bob asks to Alice to issue for him an authorization to access the >> resource. >> Alice, as the RO of the resource, request from the RS an "*access token*= " >> which is an (unsigned) data structure which contains: >> a read permission on some Alice's photo directory, associated with a >> large random number *chosen by the RS*. >> >> Note that a validity period will also be associated in practice, but thi= s >> is a minor detail for the demonstration. >> >> Alice sends back to Bob the "*access token*" issued by the RS. >> >> *Bob looks inside the access token* to make sure that it corresponds to >> what he requested to Alice, i.e. a read permission on some Alice's photo >> directory. >> >> If the content is fine, Bob presents to the RS the large random number >> associated together with an API GET for some sub-set of the photos >> contained in Alice's directory. >> >> Since the RS recognizes the large random number and that the GET API is >> valid according to the "access token" memorized by the RS authorization = set >> by Alice as a RO, >> the access is granted. >> >> In this example, the RS will not know who is reading the photo directory= . >> So Bob can transmit the "access token" to someone else during its validi= ty >> period, which may be a desirable feature. >> Note that it is also possible to allow Bob only to access Alice's >> directory. For simplicity, this alternative is not explained. >> >> In the mean time, I solved the answer of your question which was:" *How >> Bob discovered the AS to make the request to is unclear to me for the ti= me >> being*". >> The request to your question is also unclear to me for the time being, >> but since there is no AS involved, Bob does not need to discover any AS.= :-) >> >> I am quite sure that someone else will be able to describe one or more >> scenarios "*using an AS as an hammer*", but is is very likely that in >> such a case, >> the AS will be able know that Bob is rather likely to access in a short >> time some photos placed in the Alice's directory of photo hosted on that >> RS. >> * This may be a privacy concern for Bob*. >> >> Of course, in addition, the AS and the RS must establish some prior >> relationships, etc ... >> >> However, all the discussion above is outside the scope of this initial >> thread which is: Relationship between Authentication and Authorization ? >> If you want to continue the discussion on the topic you mentioned, that'= s >> fine with me, but please change the title of this thread. >> >> Denis >> >> Hi Denis, >> >> I don=E2=80=99t understand your privacy issue, and I would like to try. >> >> Let Alice be the RO and subject of a resource. at a RS. Let Bob be a >> party, not Alice, that seeks authorization to access the resource using = an >> access token. >> >> Bob has discovered the resource somehow that is out of band for GNAP. >> (Maybe Alice sent Bob a pointer to the resource in an email). >> >> Bob makes a request for the resource at some AS. The request includes th= e >> pointer that Bob discovered to the resource, some attributes or claims >> about Bob, and maybe a reason for the request. >> >> How Bob discovered the AS to make the request to is unclear to me for th= e >> time being. Maybe Bob discovered the AS along with the resource. (e.g Th= e >> resource is a DID and the AS is a service endpoint or mediator to an AS = in >> that DID.) >> >> Given the scenario above, who=E2=80=99s privacy interest are you primari= ly >> concerned about? Alice or Bob? >> >> Adrian >> >> On Mon, Mar 29, 2021 at 6:39 AM Denis wrote: >> >>> Hi Justin, >>> >>> Since your response only deals with the AS, but not the RS nor the RO, >>> it is not a response to my question which was: >>> >>> How will a RS or a RO be bootstrapped for working with a GNAP "sub" >>> claim or a "sub_id" claim ? >>> >>> The subject identifier is whatever identifier the AS knows the subject >>> as. If they log in using only a FIDO token and the AS asserts that key >>> value as the identifier, then that=E2=80=99s what it will be. If they s= ign up with >>> an email address or make a username or get assigned a random number, th= at=E2=80=99s >>> what it will be. Or they could sign up using any number of those and th= e AS >>> still assigns them a random value, because it=E2=80=99s always the AS t= hat >>> determines which value to assign the number. >>> >>> When looking at Section 3.2 (Access Tokens), the client (and hence the >>> end-user) has currently *no practical way* to indicate which of its >>> attributes should be placed into an access token, >>> The only reference within Section 3.2 is pointing to the empty Section >>> 12. Among the many examples, there is not a single example that address= es >>> the case of attributes being placed into an access token. >>> >>> Nevertheless, it seems that in your opinion, only the AS, but NOT the >>> client (and hence the end-user), SHALL have control at all of what kind= of *subject >>> identifier* claim will be placed inside the access token. >>> >>> Then after, invoking the postulate "the access token SHALL remain opaqu= e >>> to the client (and hence the end-user)", it seems that in your opinion,= the >>> end-user SHALL have no way to verify >>> whether its privacy has been respected. If this is not an architecture >>> built along "spy by design" principles, I don't know what else it might= be. >>> >>> It is important to re-read two of the current definitions: >>> >>> *Privilege*: right *or attribute* associated with a subject. >>> >>> *Access Toke*n: data artifact representing a set of rights *a**nd/or >>> attributes*. >>> >>> In the current draft, the case of rights is indeed addressed while *the >>> case of attributes is fully ignored*. >>> >>> The RS is not involved in any subject information. Identity APIs, like >>> OpenID Connect=E2=80=99s UserInfo Endpoint, are out of scope for GNAP. >>> >>> Really ? Do you mean that an access token should not contain a "sub" >>> claim nor a "sub_id" claim and if it does, the RS SHALL ignore such cl= aims >>> ? >>> >>> In the "OAuth Access Token JWT Profile", there is the following sentenc= e >>> in Section 6 (Privacy Considerations) : >>> >>> This profile mandates the presence of the "sub" claim in every JWT >>> access token, making it possible for resource servers to rely on tha= t >>> information for performing tasks such as correlating incoming >>> requests with *data stored locally for the authenticated principal*. >>> >>> >>> This sentence clearly makes a relationship between the value present in >>> the "sub" claim and "*data stored locally for the **authenticated * >>> *principal*". >>> >>> However, note that the "OAuth Access Token JWT Profile" fails to allow >>> the client (and hence the end-user) to control his privacy, since the >>> client >>> cannot choose which value will be placed in the "sub" claim and also >>> because access tokens are considered to be opaque for the clients in OA= uth. >>> >>> If there is a subject identifier either included in or referenced by th= e >>> access token, that is *up to any agreements between the AS and RS* >>> that lead to the ability of the AS to create the tokens the RS can >>> trust. All of this is outside the scope of the core GNAP protocol and >>> invisible to the client. >>> >>> You are using the following words "*up to any agreements between the AS >>> and RS*". This mandates prior agreements between ASs and RSs >>> and in such a case the architecture will be non-scalable over the >>> Internet. The trust relationship between a RS and an AS is unilateral: >>> The RS trusts the AS to issue appropriate access tokens corresponding t= o >>> the requests of its clients. >>> From an end-user point of view, if there cannot be *transparency* >>> because of the access token opacity, then there cannot be *confidence *= about >>> GNAP . >>> >>> Denis >>> >>> =E2=80=94 Justin >>> >>> On Mar 26, 2021, at 1:27 PM, Denis wrote: >>> >>> Hi Justin, >>> >>> Let me rephrase the last question: How will a RS or a RO be bootstrappe= d >>> for working with a GNAP "sub" claim or a "sub_id" claim ? >>> >>> Denis >>> >>> GNAP doesn=E2=80=99t have anything too say about anybody authenticating= directly >>> to the RS. If that happens, it=E2=80=99s out of the view and out of sco= pe of GNAP. >>> >>> =E2=80=94 Justin >>> >>> On Mar 26, 2021, at 1:06 PM, Denis wrote: >>> >>> Hi everybody, >>> >>> The content of this thread has nothing to do any more with its original >>> title which was: "Will GNAP support Zero Trust Architecture?" >>> Since I am going to use some sentences of this thread to open a new >>> topic, I changed the title of this thread into : >>> "Relationship between Authentication and Authorization ?" >>> >>> At the moment, I got the impression that nobody agrees any more about *= what >>> GNAP is or is not, what it should address and what it should not addres= s* >>> . >>> The components of the model are becoming more numerous and hazy. A new >>> terminology is sometimes being used, but is not yet present in the last >>> published draft. >>> >>> I still can't understand any of the new terms that are being used ( >>> *AS-RS* and *AS-RO*), *which are still left undefined*. >>> >>> The last exchanges look more as conversations between workers during th= e >>> construction of the Babel tower. >>> >>> Last year, my first remark was to mention that a section or an Annex >>> explaining the common points and the differences with OAuth 2.0 >>> would be useful. Such section or Annex still does not exist. >>> >>> Justin wrote: >>> >>> *If an RS allows a username/password HTTP Basic auth in addition to >>> accepting access tokens, it can do so, but * >>> *GNAP doesn=E2=80=99t have anything to say about the Basic auth use, or= even its >>> relation to any access tokens or RO=E2=80=99s or anything else.* >>> >>> Let us split the end of this sentence into two parts: >>> >>> "*GNAP doesn=E2=80=99t have anything **to say about the Basic auth use*= ": If >>> an authentication exchange is necessary, the draft document should >>> describe, for completeness, >>> the HTTP error code that will be returned. >>> >>> "*or even its relation to any access tokens or RO=E2=80=99s or anything= else*". >>> Let us suppose that a RS supports FIDO as an authentication mechanism t= o >>> authenticate its end-users. >>> FIDO provides the major advantage that, for every RS, a different >>> identifier is used by every end-user. This prevents end-users accounts >>> correlations between RSs by using >>> such identifiers. In practice, a FIDO identifier is a pseudonym. >>> >>> At this very moment, the RS is able to identify and authenticate its >>> end-users using FIDO pseudonyms. Now, let us raise the following questi= on: >>> >>> How will a RS be bootstrapped for working with a GNAP "sub" claim or a >>> "sub_id" claim, whereas FIDO is already being used ? >>> >>> Denis >>> >>> >>> Adrian, >>> >>> I disagree, I believe that what I have laid out is exactly separating >>> the concerns into working components. >>> >>> Like OAuth before it, GNAP is a protocol negotiate access for a client >>> instance to an RS, using an AS as the facilitator of that delegated >>> negotiation. (Unlike OAuth, it=E2=80=99s importantly also for negotiati= ng user >>> information to the client directly from the AS with no RS involved, but >>> that=E2=80=99s an aside for the purposes of our conversation here). >>> >>> If a particular GNAP RS also allows other kinds of processes to enable >>> access to it, that is completely fine, but outside of GNAP. If an RS al= lows >>> a username/password HTTP Basic auth in addition to accepting access tok= ens, >>> it can do so, but GNAP doesn=E2=80=99t have anything to say about the B= asic auth >>> use, or even its relation to any access tokens or RO=E2=80=99s or anyth= ing else. If >>> an RS accepts structured access tokens signed by trusted keys that don= =E2=80=99t >>> come from an AS through a negotiated request =E2=80=94 again, that=E2= =80=99s fine, but GNAP >>> is silent about the RS doing that. If the RS acts as =E2=80=9Cits own A= S=E2=80=9D then it=E2=80=99s >>> really just an RS and an AS living in the same box. Again, that=E2=80= =99s fine, and >>> super common with OAuth today. >>> >>> GNAP is solving the problem of connecting the client to the RS through >>> means of an AS. Other solutions are possible and many of them can be >>> deployed right alongside, but that=E2=80=99s not the corner of the worl= d that GNAP >>> is solving. GNAP should be concerned about how these other technologies= can >>> be used alongside it. I think there=E2=80=99s a lot of room for the thi= ngs that >>> you=E2=80=99re talking about, and more importantly for solving the use = cases that >>> you=E2=80=99re bringing. But GNAP should be more than a single-point so= lution, and >>> so we need to balance these concerns. The conceptual framework of an AS >>> that takes in lots of different information and spits out access tokens= is >>> exactly the abstraction layer that is necessary for making these use ca= ses >>> interoperable. >>> >>> =E2=80=94 Justin >>> >>> On Mar 26, 2021, at 8:30 AM, Adrian Gropper >>> wrote: >>> >>> @Justin, there=E2=80=99s no separation of concerns here. No partition b= etween >>> processor and controller. No data minimization. And, I see no obvious >>> reason to make this the core of GNAP. >>> >>> The one thing we can probably all agree on is that there=E2=80=99s only= one RS >>> and one RO. >>> >>> The core of GNAP, in my opinion, can be built and explained around this >>> simple design. The RS is a processor. The RO is a controller. The RS be= ars >>> only security responsibility. The RS bears no privacy responsibility. T= he >>> RO delegates this to the RS but this is not authorization as the A in G= NAP. >>> >>> The RO retains all rights to delegate within the scope of things that >>> the RS is willing to support using various token formats and endpoint >>> options. Some of these options may do all sorts of things for all sorts= of >>> clients and user-agents but these are options. >>> >>> For example, if a request comes to the RS that is not in the form of an >>> access token, then it either gets sent to the RO or their agent, or it = gets >>> logged and dumped. One such option, common in healthcare, is =E2=80=9CB= reak the >>> Glass=E2=80=9D where the RS is acting as an authorization server becaus= e the >>> user-agent is making a request instead of presenting an access token. G= NAP >>> can offer this as an option but it is not our core. >>> >>> Adrian >>> >>> >>> >>> On Fri, Mar 26, 2021 at 7:15 AM Justin Richer wrote: >>> >>>> I have a big problem with this line: >>>> >>>> > the RS and AS-RS only see access tokens. The requests (from RO') >>>> that resulted in an access token are none of their business. >>>> >>>> In the trust model we=E2=80=99ve been discussing, the requests that re= sult in >>>> access tokens are *solely the business of AS-RS*, since AS-RS is the >>>> only entity that=E2=80=99s allowed, and trusted by the RS, to create a= ccess tokens >>>> for the RS. That is its entire job, the entire reason it exists in the >>>> system. By definition the party generating tokens for use at the RS is= the >>>> AS for that RS, I don=E2=80=99t care how you deploy it. If RO wants to= give access >>>> to someone else (who isn=E2=80=99t an =E2=80=9CRO" anymore, they=E2=80= =99re another end-user), then >>>> that end user=E2=80=99s client software will need to talk to AS-RS to = get its own >>>> access token. >>>> >>>> Now here=E2=80=99s the trick: when the end user=E2=80=99s client insta= nce talks to >>>> AS-RS, that does NOT mean that AS-RS needs to know all the details and >>>> policy reasons that it should give an access token to that client inst= ance. >>>> It doesn=E2=80=99t even need to know the existence of another end user= . It doesn=E2=80=99t >>>> need identity, it doesn=E2=80=99t need policy. Sure, it COULD handle a= ll of that >>>> internally, and many will, but the protocol doesn=E2=80=99t demand it. >>>> >>>> This means that the first client instance, the one that gets the acces= s >>>> token, can also be given something alongside the access token that it = can >>>> then hand to another piece of software (or to a person to hand eo thei= r >>>> piece of software). This artifact is not an access token. This artifac= t >>>> could be something structured that the client understands, and can mak= e >>>> derivatives of, and present back to the AS-RS for getting new access >>>> tokens. There could be multiple different flavors of this kind of arti= fact >>>> for different kinds of environments and groups. But what they all have= in >>>> common is that they can potentially be used to request more access tok= ens >>>> within some context at the AS-RS. >>>> >>>> =E2=80=94 Justin >>>> >>>> >>>> >>>> On Mar 25, 2021, at 5:50 PM, Adrian Gropper >>>> wrote: >>>> >>>> My issue is with Alan's: >>>> >>>> "7. Another user agent (RO') can contact any holder of the access toke= n >>>> or the service's policy agent (AS-RS) to get a delegated access token.= " >>>> >>>> >>>> I would prefer "7A. Another user agent (RO') can contact any holder of >>>> the access token." by default so that the AS-RS does not see the reque= sts. >>>> In other words, the RS and AS-RS only see access tokens. The requests = (from >>>> RO') that resulted in an access token are none of their business. >>>> >>>> The reality is that RO' can discover a resource RS and can share >>>> whatever information with RS-AS they want and the RO may not even know >>>> about it unless the RS decides to let them know somehow. This seems to= be a >>>> drawback of the capabilities approach. >>>> >>>> In terms of privacy and control, I, as the RO, want a contract with th= e >>>> RS that says that I or my agent (AS-RO) must sign an access token. Thi= s is >>>> a fundamental audit requirement. Without it, a rogue RS and AS-RS can = do >>>> all sorts of things and the RO would never know. I understand that a r= ogue >>>> RS might not support an honest contemporaneous log of access tokens >>>> presented so there's a trust issue here that I seems unavoidable unles= s I >>>> specify in my RO-RS contract that they use a separate contemporaneous = log >>>> such as AS-RO for every access token presented and risk being sued if = they >>>> process an access token without also updating the separate log. >>>> >>>> - Adrian >>>> >>>> >>>> On Thu, Mar 25, 2021 at 1:22 PM Alan Karp wrote: >>>> >>>>> Justin Richer wrote: >>>>> >>>>>> Hi Alan, >>>>>> >>>>>> In all of my discussion, and in the spec itself, the RO is the >>>>>> :entity: in charge of approving rights. They=E2=80=99re probably a p= erson. It might >>>>>> be software that makes a policy decision in some way, or a corporate >>>>>> entity, or something like that. But it=E2=80=99s not assumed to be a= computational >>>>>> agent in the terms of the protocol itself. Would that recast what yo= u=E2=80=99re >>>>>> saying below? >>>>>> >>>>> >>>>> Hmmm. I guess not. It's just that the person would be using some UI >>>>> to express their decisions to what I called the user agent. That mod= el >>>>> fits in very nicely with what we did with Polaris, our virus safe com= puting >>>>> environment for Windows XP, >>>>> https://dl.acm.org/doi/10.1145/1151030.1151033. The person would >>>>> click on the icon for a Word file, and an instance of Word would open= with >>>>> only the permission needed to edit that one file. Same thing here. = The >>>>> client could ask for permission to use the resource, or permission co= uld be >>>>> granted implicitly when the user selects a resource associated with a >>>>> specific client. >>>>> >>>>> -------------- >>>>> Alan Karp >>>>> >>>>> >>>>> On Thu, Mar 25, 2021 at 9:53 AM Justin Richer wrote= : >>>>> >>>>>> Hi Alan, >>>>>> >>>>>> In all of my discussion, and in the spec itself, the RO is the >>>>>> :entity: in charge of approving rights. They=E2=80=99re probably a p= erson. It might >>>>>> be software that makes a policy decision in some way, or a corporate >>>>>> entity, or something like that. But it=E2=80=99s not assumed to be a= computational >>>>>> agent in the terms of the protocol itself. Would that recast what yo= u=E2=80=99re >>>>>> saying below? >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> On Mar 25, 2021, at 12:36 PM, Alan Karp wrote: >>>>>> >>>>>> There seems to be some confusion about how AS-RO comes into the >>>>>> picture, probably because of the "AS" part. I'm going to try to cle= ar up >>>>>> that confusion by more carefully explaining what I mean. >>>>>> >>>>>> I'm assuming that RO is a computational agent representing the perso= n >>>>>> who is the resource owner, something called the "user agent" in oper= ating >>>>>> systems lingo. I'm also assuming that it's possible to do delegatio= n, >>>>>> either locally or by token exchange with AS-RS. All delegations are >>>>>> potentially sub-scoped, but you may also want to delegate with full = scope >>>>>> to have a separately revocable access token. >>>>>> >>>>>> Here's an example of how things work in a capability oriented >>>>>> system. >>>>>> >>>>>> 1. Someone, the service owner, creates a service. >>>>>> 2. The service owner contracts with an policy agent (AS-RS) to >>>>>> create and manage access tokens for that service (RS). >>>>>> 3. A person wishing to create a resource at RS uses their user >>>>>> agent (RO) to contact the service owner's policy agent (AS-RS) an= d gets >>>>>> back an access token for that resource. >>>>>> 4. That user agent (RO) can >>>>>> 1. use that access token to invoke the resource, or >>>>>> 2. delegate an access token to a client of the user agent's >>>>>> (RO) choice, or >>>>>> 3. contract with a policy agent (AS-RO) to manage those >>>>>> delegations on behalf of the user agent (RO), or >>>>>> 4. specify a policy with the service's policy agent (AS-RS). >>>>>> 5. A client can contact any holder of the access token (the user >>>>>> agent (RO) or its policy agent (AS-RO)) or the service's policy a= gent >>>>>> (AS-RS) to get a delegated access token. >>>>>> 6. That client can delegate that token to another client. >>>>>> 7. Another user agent (RO') can contact any holder of the access >>>>>> token or the service's policy agent (AS-RS) to get a delegated ac= cess token. >>>>>> 8. The other user agent (RO') can >>>>>> 1. use that access token to invoke the resource, or >>>>>> 2. delegate it to a client of its choice, or >>>>>> 3. contract with a policy agent (AS-RO') of its choosing to >>>>>> manage those delegations on its behalf, or >>>>>> 4. specify a policy with the service's policy agent (AS-RS). >>>>>> 9. and so on >>>>>> >>>>>> When any of these computational agents, user agents (ROs) or clients >>>>>> acting on their behalf, invokes the resource, AS-RS verifies that th= e >>>>>> access token is a valid delegation, i.e., proper sub-scoping, hasn't= been >>>>>> revoked, and that it authorizes the request being made before tellin= g the >>>>>> service (RS) to honor the request. At no point does the service's p= olicy >>>>>> agent (AS-RS) know which computational agent did any particular >>>>>> delegation. (Token exchange can be done as anonymously as possible.= ) In >>>>>> particular, the policy agents (AS-RO) need not be the same, or even >>>>>> compatible with, the service's policy agent (AS-RS). GNAP specifies= the >>>>>> protocol between requesters, invokers, delegators (for token exchang= e) of >>>>>> tokens and AS-RS. That protocol need not be used between user agent= s (RO), >>>>>> clients, or other policy agents (AS-RO), but it is likely to be. >>>>>> >>>>>> ------------- >>>>>> Alan Karp >>>>>> >>>>>> >>>>>> On Thu, Mar 25, 2021 at 5:45 AM Justin Richer >>>>>> wrote: >>>>>> >>>>>>> The way I=E2=80=99m thinking about Adrian=E2=80=99s use case is tha= t what we=E2=80=99re >>>>>>> calling the =E2=80=9CAS-RO=E2=80=9D isn=E2=80=99t an =E2=80=9CAS=E2= =80=9D in the traditional OAuth/GNAP sense, at >>>>>>> least not exactly. This is the agent that the RO can use to set pol= icies >>>>>>> and manage consent on their behalf, and I=E2=80=99ve been arguing t= hat it fits >>>>>>> better into this vaguely-defined =E2=80=9Cinteraction component=E2= =80=9D aspect of the >>>>>>> current AS definition, and it=E2=80=99s not currently separated fro= m the AS >>>>>>> definition. The =E2=80=9CAS-RS=E2=80=9D maps to what we=E2=80=99d c= all the =E2=80=9CAS=E2=80=9D in OAuth/GNAP >>>>>>> traditionally, it=E2=80=99s what the RS trusts to issue tokens. In = traditional >>>>>>> OAuth the AS-RO and AS-RS are always the same thing, from a functio= nal >>>>>>> protocol perspective. An important point here is that from a client= =E2=80=99s >>>>>>> perspective, they=E2=80=99re only talking to the AS-RS since that= =E2=80=99s where the >>>>>>> client gets its tokens, because at the end of the day the client ju= st wants >>>>>>> to call the API at the RS and doesn=E2=80=99t care how that happens= (from a >>>>>>> protocol standpoint). >>>>>>> >>>>>>> Note well: Even thought I don=E2=80=99t believe that =E2=80=9CAS-RO= =E2=80=9D is an >>>>>>> authorization server at all, I=E2=80=99m going to keep using that t= erm below for >>>>>>> consistency with previous discussion. >>>>>>> >>>>>>> So we have these fundamental relationships around getting the clien= t >>>>>>> to access the RS: >>>>>>> >>>>>>> 1. RS trusts AS-RS to issue tokens that RS will accept, validate, >>>>>>> and process for requests from client >>>>>>> 2. Client trusts AS-RS to issue tokens that client can use at RS >>>>>>> 3. RO trusts RS to protect RO=E2=80=99s api through delegated acces= s >>>>>>> >>>>>>> On top of that, we=E2=80=99ve got some additional aspects that we= =E2=80=99re >>>>>>> discussing: >>>>>>> >>>>>>> 4. RO trusts AS-RO to manage RO=E2=80=99s policies at runtime >>>>>>> 5. AS-RS trusts AS-RO to assert RO=E2=80=99s policies for access to= RS >>>>>>> 6. Client trusts whatever AS-RS sends client to deal with, includin= g >>>>>>> possibly RO-AS at runtime, because of (2) >>>>>>> >>>>>>> What I have been saying is that 4/5/6 are optional details of how >>>>>>> RS-AS runs things, and I think this also maps with Adrian=E2=80=99s= view of choice, >>>>>>> since if my RS=E2=80=99s AS-RS doesn=E2=80=99t allow me to plug in = my own AS-RO then I >>>>>>> would be motivated to pick a different RS who=E2=80=99s AS-RS lets = me do just that. >>>>>>> The same way I=E2=80=99d pick a different RS if their surrounding s= ervices didn=E2=80=99t >>>>>>> accept my preferred federation login and I didn=E2=80=99t want to m= ake another >>>>>>> account. Of course, market forces being as they are, I might not ha= ve much >>>>>>> of an actionable choice in RS, but GNAP can=E2=80=99t change that. >>>>>>> >>>>>>> What we can do is make it possible for AS-RS to talk to AS-RO, both >>>>>>> in philosophy of the protocol design and in concrete hooks to suppo= rt (6) >>>>>>> above. >>>>>>> >>>>>>> Separately, we can approach the issue of making 1/2 above more >>>>>>> dynamic. This was UMA2=E2=80=99s =E2=80=9Cfederated authorization= =E2=80=9D approach, and is behind >>>>>>> a lot of the =E2=80=9Cbring your own AS=E2=80=9D models out there. = The problem with these >>>>>>> is that we know from many years of experience that most RS=E2=80=99= s aren=E2=80=99t >>>>>>> interested in doing anything of the sort. >>>>>>> >>>>>>> So with GNAP we can instead allow 4/5/6 to vary in a predictable an= d >>>>>>> consistent way, letting the RS keep control over 1/2, thereby enabl= ing >>>>>>> choice in (3). We don=E2=80=99t have to be the ones who define the = all of the >>>>>>> details of every permutation of (5) to enable this, though. Some of= this is >>>>>>> going to be configuration out of band, some of it=E2=80=99s going t= o be >>>>>>> communication at runtime. This is where VC=E2=80=99s, ZCAPs, CHAPI,= DIDComm, FIDO, >>>>>>> and a whole swath of other tech can come in and help out. I don=E2= =80=99t think we >>>>>>> need to put all the details for using these into core, nor do I thi= nk we=E2=80=99ll >>>>>>> pull of The Great And Ultimate Abstraction for using these and othe= r >>>>>>> approaches. But we can at least start talking about =E2=80=9CAS-RS= =E2=80=9D in such a way >>>>>>> that it no longer assumes it=E2=80=99s always the same party dealin= g with the RO >>>>>>> directly. >>>>>>> >>>>>>> =E2=80=94 Justin >>>>>>> >>>>>>> On Mar 25, 2021, at 6:40 AM, Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>> >>>>>>> To reframe it closer to GNAP: >>>>>>> - AS =3D AS-RO, that's where you find the RO policies. The AS issue= s >>>>>>> access tokens to the client. >>>>>>> - the RO policies could be a) defined locally or b) in relationship >>>>>>> with the RS >>>>>>> >>>>>>> There have been several ideas related to the AS-RS relationship b: >>>>>>> b1) the RS issues capabilities (which can be further attenuated by >>>>>>> the RO) >>>>>>> b2) Adrian also discussed a DID based solution >>>>>>> b3) there was also an alternative ACL proposal from Denis (+ >>>>>>> preflight) >>>>>>> >>>>>>> >> > --00000000000090d2c605beb12e62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    Bob is manning the= gate at Madison Square Garden.=C2=A0

    Adrian
    =

    = On Mon, Mar 29, 2021 at 1:19 PM Denis <denis.ietf@free.fr> wrote:
    =20 =20 =20
    Adrian,

    I changed the title of this thread since your are addressing a new topic that I am unable to understand.
    Alice J&J vaccine is Alice's private information. For which reason would Bob ask Alice to provide an access token ?

    Denis

    =20
    This is helpful, Denis.=C2=A0

    I will focus on "Then Bob asks to Alice to issue for hi= m an authorization to access the resource." and avoid using any hammers.=C2=A0

    Let's use something in the news and say the RS is a hospital that gave Alice a J&J COVID vaccine. Alice identified herself to the hospital with a number N. N could have been randomly chosen by Alice or the hospital or N could be Alice's driver's license number right next to = her face photo. GNAP should probably deal with both cases.=C2=A0

    The hospital creates a digital credential that includes the J&J vaccine name and lot number, N, a statement about how N was derived, and a date. The hospital posts this credential at some resource URL, protected by some access token requirement, and gives Alice the "resource URL" instead of or along with a paper vaccination card with the same information as the resource.

    When Bob asks Alice for an access token, Bob makes a request to Alice and she can either:
    A - Give Bob the "resource URL" and let him try hi= s luck turning this into an access token somewhere,
    B - Go to the hospital portal and authenticate somehow and grab an access token that she can return to Bob,
    C - Give Bob an access token for the resource URL based on some signature that is trusted by the hospital.

    When Bob gets the resource, it will include N along with the hospital's statement about how N was derived. Bob can decide what to do next.

    Adrian


    On Mon, Mar 29, 2021 at 9:54 AM Denis <denis.ietf@free.fr> wrote:
    Hi Adrian,

    Thank you for the scenario. You certainly know the following sentence:
    "When the only tool you have is a hammer, every problem looks like a nail".
    Similarly:=C2=A0 "When the only tool you have is an A= S, every problem looks like an access token issued by an AS"= ;.

    Let us start with exactly the same sentence that explains the goal:
    Let Alice be the RO and subject of a resource. at a RS. Let Bob be a party, not Alice, that seeks authorization to access the resource using an access token.
    Then Bob asks to Alice to issue for him an authorization to access the resource.
    Alice, as the RO of the resource, request from the RS an "= access token"=C2=A0 which is an (unsigned) data structure w= hich contains:
    a read permission on some Alice's photo directory, associated with a large random number chosen by the RS.

    Note that a validity period will also be associated in practice, but this is a minor detail for the demonstration.

    Alice sends back to Bob the "access token"= ; issued by the RS.

    Bob looks inside the access token to make sure that it corresponds to what he requested to Alice, i.e. a read permission on some Alice's photo directory.

    If the content is fine, Bob presents to the RS the large random number associated together with an API GET for some sub-set of the photos contained in Alice's directory.

    Since the RS recognizes the large random number and that the GET API is valid according to the "access token= " memorized by the RS authorization set by Alice as a RO,
    the access is granted.

    In this example, the RS will not know who is reading the photo directory. So Bob can transmit the "access token" to someone else during its validity period, which may be a desirable feature.
    Note that it is also possible to allow Bob only to access Alice's directory. For simplicity, this alternativ= e is not explained.

    In the mean time, I solved the answer of your question which was:" How Bob discovered the AS to make the request to is unclear to me for the time being".
    The request to your question is also unclear to me for the time being, but since there is no AS involved, Bob does not need to discover any AS. :-)

    I am quite sure that someone else will be able to describe one or more scenarios "using an AS as an hammer", but is is very likely that in such a case= ,
    the AS will be able know that Bob is rather likely to access in a short time some photos placed in the Alice's directory of photo hosted on that RS.
    This may be a privacy concern for Bob    .

    Of course, in addition, the AS and the RS must establish some prior relationships, etc ...

    However, all the discussion above is outside the scope of this initial thread which is: Relationship between Authentication and Authorization ?
    If you want to continue the discussion on the topic you mentioned, that's fine with me, but please change the title of this thread.

    Denis


    Hi Denis,

    I don=E2=80=99t understand your privacy iss= ue, and I would like to try.=C2=A0

    Let Alice be the RO and subject of a resource. at a RS. Let Bob be a party, not Alice, that seeks authorization to access the resource using an access token.=C2=A0

    Bob has discovered the resource somehow that is out of band for GNAP. (Maybe Alice sent Bob a pointer to the resource in an email).

    Bob makes a request for the resource at some AS. The request includes the pointer that Bob discovered to the resource, some attributes or claims about Bob, and maybe a reason for the request.=C2=A0

    How Bob discovered the AS to make the request to is unclear to me for the time being. Maybe Bob discovered the AS along with the resource. (e.g The resource is a DID and the AS is a service endpoint or mediator to an AS in that DID.)

    Given the scenario above, who=E2=80=99s pri= vacy interest are you primarily concerned=C2=A0about? Alice or Bob?=C2=A0

    Adrian

    On Mon, Mar 29, 202= 1 at 6:39 AM Denis <denis.ietf@free.fr> wrote:
    Hi=C2=A0 Justin,

    Since your response only deals with the AS, but not the RS nor the RO, it is not a response to my question which was:
    How will a RS or a RO be bootstrapped for working with a GNAP "sub" claim or a &q= uot;sub_id" claim ?
    The subject identifier is whatever identifier the AS knows the subject as. If they log in using only a FIDO token and the AS asserts that key value as the identifier, then that=E2=80=99s what it will be. If they sign u= p with an email address or make a username or get assigned a random number, that=E2=80=99s what it wi= ll be. Or they could sign up using any number of those and the AS still assigns them a random value, because it=E2=80=99s always the AS that determines which value to assign the number.

    When looking at Section 3.2 (Access Tokens), the client (and hence the end-user) has currently no practical way to indicate which of its attributes should be placed into an access token,
    The only reference within Section 3.2 is pointing to the empty Section 12. Among the many examples, there is not a single example that addresses the case of attributes being placed into an access token.

    Nevertheless, it seems that in your opinion, only the AS, but NOT the client (and hence the end-user), SHALL have control at all of what kind of subject identifier claim will be placed inside the access token.

    Then after, invoking the postulate "the access token SHALL remain opaque to the client (and hence the end-user)", it seems that in your opinion, the end-user SHALL have no way to verify
    whether its privacy has been respected. If this is not an architecture built along "spy by design" principles, I don't know what else= it might be.

    It is important to re-read two of the current definitions:

    Privilege: right or attribute associated with a subject.

    Access Token: data artifact representing a set of rights and/or attributes.<= /span>

    In the current draft, the case of rights is indeed addressed while the case of attributes is fully ignored.

    The RS is not involved in any subject information. Identity APIs, like OpenID Connect=E2=80=99s UserInfo Endpoint, are out of s= cope for GNAP.

    Really ? Do you mean that an access token should not contain a "sub" claim nor a &q= uot;sub_id" claim=C2=A0 and if it does, the RS SHALL ignore suc= h claims ?

    In the "OAuth Access Token JWT Profile",= there is the following sentence in Section 6 (Privacy Considerations) :

    =C2=A0=C2=A0 This profile mandates the presence = of the "sub" claim in every JWT
    =C2=A0=C2=A0 access token, making it possible for resource servers to rely on that
    =C2=A0=C2=A0 information for performing tasks suc= h as correlating incoming
    =C2=A0=C2=A0 requests with data stored locally= for the authenticated principal.=C2=A0

    This sentence clearly makes a relationship between the value present in the "sub" claim and &q= uot;data stored locally for the authenticated principal".

    However, note that the "OAuth Access Token JWT Profile" fails to allow the client (and hence th= e end-user) to control his privacy, since the client
    cannot choose which value will be placed in the "sub" claim and also because access tokens = are considered to be opaque for the clients in OAuth.
    If there is a subject identifier either included in or referenced by the access token, that is up to any agreements between the AS and RS
    that lead to the ability of the AS to create the tokens the RS can trust. All of this is outside the scope of the core GNAP protocol and invisible to the client.

    You are using the following words "up to a= ny agreements between the AS and RS". This mandates prior agreements between ASs and RSs
    and in such a case the architecture will be non-scalable over the Internet. The trust relationship between a RS and an AS is unilateral:
    The RS trusts the AS to issue appropriate access tokens corresponding to the requests of its clients.

    From an end-user point of view, if there cannot be transparency because of the access token opacity, then there cannot be confidence about GNAP .

    Denis


    =C2=A0=E2=80=94 Justin

    On Mar 26, 2021, at 1:27 PM, Denis <denis.ietf@free.fr> wrote:

    Hi Justin,

    Let me rephrase the last question: How will a RS or a RO be bootstrapped for working with a GNAP "sub" claim or a "sub_id= " claim ?

    Denis

    GNAP doesn=E2= =80=99t have anything too say about anybody authenticating directly to the RS. If that happens, it=E2=80=99s out of th= e view and out of scope of GNAP.

    =C2=A0=E2=80=94 Justin

    On Mar 26, 2021, at 1:06 PM, Denis <denis.ietf@free.fr> wrote:

    Hi everybody,

    The content of this thread has nothing to do any more with its original title which was: "Will GNAP support Zero Trust Architecture?"
    Since I am going to use some sentences of this thread to open a new topic, I changed the title of this thread into :
    "Relationship betwee= n Authentication and Authorization ?"

    At the moment, I got the impression that nobody agrees any more about what GNAP is or is not, what it should address and what it should not address.=
    The components of the model are becoming more numerous and hazy. A new terminology is sometimes being used, but is not yet present in the last published draft.

    I still can't understand any of the new terms that are being used (AS-RS and AS-RO), whi= ch are still left undefined.

    The last exchanges look more as conversations between workers during the construction of the Babel tower.

    Last year, my first remark was to mention that a section or an Annex explaining the common points and the differences with OAuth 2.0
    would be useful. Such section or Annex still does not exist.

    Justin wrote:
    If an RS allows a username/password HTTP Basic auth in addition to accepting access tokens, it can do so, but
    GNAP doesn=E2=80= =99t have anything to say about the Basic auth use, or even its relation to any access tokens or RO=E2=80=99= s or anything else.
    Let us split the end of this sentence into two parts:

    "GNAP doesn=E2= =80=99t have anything to say about the Basic auth use":=C2= =A0 If an authentication exchange=C2=A0 is necessary, the draft document should describe, for completeness,
    the HTTP error code that will be returned.

    "or even its relation to any access tokens or RO=E2=80=99s or anythin= g else". Let us suppose that a RS supports FIDO as an authentication mechanism to authenticate its end-users.
    FIDO provides the major advantage that, for every RS, a different identifier is used by every end-user. This prevents end-users accounts correlations between RSs by using
    such identifiers. In practice, a FIDO identifier is a pseudonym.

    At this very moment, the RS is able to identify and authenticate its end-users using FIDO pseudonyms. Now, let us raise the following question:

    How will a RS be bootstrapped for working with a GNAP "sub" claim o= r a "sub_id" clai= m, whereas FIDO is already being used ?

    Denis


    Adrian,

    I disagree, I believe that what I have laid out is exactly separating the concerns into working components.=C2= =A0

    Like OAuth before it, GNAP is a protocol negotiate access for a client instance to an RS, using an AS as the facilitator of that delegated negotiation. (Unlike OAuth, it=E2=80=99s importantly also for negotiating user information to the client directly from the AS with no RS involved, but that=E2= =80=99s an aside for the purposes of our conversation here).

    If a particular GNAP RS also allows other kinds of processes to enable access to it, that is completely fine, but outside of GNAP. If an RS allows a username/password HTTP Basic auth in addition to accepting access tokens, it can do so, but GNAP doesn=E2= =80=99t have anything to say about the Basic auth use, or even its relation to any access tokens or RO=E2=80=99s or anythin= g else. If an RS accepts structured access tokens signed by trusted keys that don=E2=80=99t come from= an AS through a negotiated request =E2= =80=94 again, that=E2=80=99s f= ine, but GNAP is silent about the RS doing that. If the RS acts as =E2=80=9Cits own AS= =E2=80=9D then it=E2=80=99s really jus= t an RS and an AS living in the same box. Again, that=E2=80=99s f= ine, and super common with OAuth today.=C2=A0=

    GNAP is solving the problem of connecting the client to the RS through means of an AS. Other solutions are possible and many of them can be deployed right alongside, but that=E2=80=99s not the corner of the world that GNAP is solving. GNAP should be concerned about how these other technologies can be used alongside it. I think there=E2=80=99s a= lot of room for the things that you=E2=80= =99re talking about, and more importantly for solving the use cases that you=E2=80=99= re bringing. But GNAP should be more than a single-point solution, and so we need to balance these concerns. The conceptual framework of an AS that takes in lots of different information and spits out access tokens is exactly the abstraction layer that is necessary for making these use cases interoperable.

    =C2=A0=E2=80=94 Just= in

    On Mar 26, 2021, at 8:30 AM, Adrian Gropper <agropper@healthurl.c= om> wrote:

    @Justin, there=E2=80=99s n= o separation of concerns here. No partition between processor and controller. No data minimization. And, I see no obvious reason to make this the core of GNAP.=C2=A0

    The one thing we can probably all agree on is that there=E2=80=99s o= nly one RS and one RO.=C2=A0

    The core of GNAP, in my=C2=A0opinio= n, can be built and explained around this simple design. The RS is a processor. The RO is a controller. The RS bears only security responsibility. The RS bears no privacy responsibility. The RO delegates this to the RS but this is not authorization as the A in GNAP.

    The RO retains all rights to delegate within the scope of things that the RS is willing to support using various token formats and endpoint options. Some of these options may do all sorts of things for all sorts of clients and user-agents =C2=A0but these a= re options.=C2=A0

    For example, if a request comes to the RS that is not in the form of an access token, then it either gets sent to the RO or their agent, or it gets logged and dumped. One such option, common in healthcare, is =E2=80=9CBreak th= e Glass=E2=80=9D wh= ere the RS is acting as an authorization server because the user-agent is making a request instead of presenting an access token. GNAP can offer this as an option but it is not our core.

    Adrian



    On Fri, Mar 26, 2021 at 7:15 AM Justin Richer <jricher@mit.edu> wrote:
    I have a big problem with this line:

    >=C2=A0the RS and AS-RS only see access tokens. The requests (from RO') that resulted in an access token are none of their business.<= /div>

    In the trust model we=E2=80=99= ve been discussing, the requests that result in access tokens are solely the business of AS-RS, since AS-RS is the only entity that=E2=80= =99s allowed, and trusted by the RS, to create access tokens for the RS. That is its entire job, the entire reason it exists in the system. By definition the party generating tokens for use at the RS is the AS for that RS, I don=E2=80=99t car= e how you deploy it. If RO wants to give access to someone else (who isn=E2=80=99= t an =E2=80=9CRO"= anymore, they=E2=80=99re another end-user), then that end user=E2=80=99s cl= ient software will need to talk to AS-RS to get its own access token.

    Now here=E2=80=99s th= e trick: when the end user=E2= =80=99s client instance talks to AS-RS, that does NOT mean that AS-RS needs to know all the details and policy reasons that it should give an access token to that client instance. It doesn=E2=80=99t e= ven need to know the existence of another end user. It doesn=E2=80=99t n= eed identity, it doesn=E2=80=99t n= eed policy. Sure, it COULD handle all of that internally, and many will, but the protocol doesn=E2=80=99t d= emand it.=C2=A0

    This means that the first client instance, the one that gets the access token, can also be given something alongside the access token that it can then hand to another piece of software (or to a person to hand eo their piece of software). This artifact is not an access token. This artifact could be something structured that the client understands, and can make derivatives of, and present back to the AS-RS for getting new access tokens. There could be multiple different flavors of this kind of artifact for different kinds of environments and groups. But what they all have in common is that they can potentially be used to request more access tokens within some context at the AS-RS.

    =C2=A0=E2=80= =94 Justin



    On Mar 25, 2021, at 5:50 PM, Adrian Gropper <agropper@healthurl.com&g= t; wrote:

    My issue is with Alan's:
    "7. Another user agent (RO') can contact any holder of the access token or the service's policy agent (AS-RS) to get a delegated access token.&quo= t;

    I would prefer "7A.<= font face=3D"arial, sans-serif">=C2= =A0Another user agent (RO') can contact any holder of the access token.&quo= t; by default so that the AS-RS does not see the requests. In other words, the RS and AS-RS only see access tokens. The requests (from RO') that resulted in an access token are none of their business.<= /font>
    The reality is that RO' can discover a resource RS and can share whatever information with RS-AS they want and the RO may not even know about it unless the RS decides to let them know somehow. This seems to be a drawback of the capabilities approach.=C2=A0
    In terms of privacy and control, I, as the RO, want a contract=C2=A0wit= h the RS that says that I or my agent (AS-RO) must sign an access token. This is a fundamental audit requirement. Without it, a rogue RS and AS-RS can do all sorts of things and the RO would never know. I understand that a rogue RS might not support an honest contemporaneous log of access tokens presented so there's a trust issue here that I seems unavoidable unless I specify in my RO-RS contract that they use a separate contemporaneous= =C2=A0log such as AS-RO for every access token presented and risk being sued if they process an access token without also updating the separate log.
    - Adrian


    On Thu, Mar 25, 2021 at 1:22 PM Alan Karp <alanhkarp@gmail.com&g= t; wrote:
    Justin Richer <jricher@mit.edu> wrote:
    Hi Alan,

    In all of my discussion, and in the spec itself, the RO is the :entity: in charge of approving rights. They=E2=80=99re probably a person. It might be software that makes a policy decision in some way, or a corporate entity, or something like that. But it=E2= =80=99s not assumed to be a computational agent in the terms of the protocol itself. Would that recast what you=E2=80=99= re saying below?
    =
    Hmmm.=C2=A0 = I guess not.=C2=A0 It's just tha= t the person would be using some UI to express their decisions to what I called the user agent.=C2=A0 That model fits in very nicely with what we did with Polaris, our virus safe computing environment for Windows XP, https://dl.= acm.org/doi/10.1145/1151030.1151033.=C2=A0 The person would click on the icon for a Word file, and an instance of Word would open with only the permission needed to edit that one file.=C2=A0 Same thing here.=C2=A0 The client could ask for permission to use the resource, or permission could be granted implicitly when the user selects a resource associated with a specific client.
    =
    -------------- Alan Karp


    On Thu, Mar 25, 2021 at 9:53 AM Justin Richer <jricher@mit.edu> wrote:
    Hi Alan,

    In all of my discussion, and in the spec itself, the RO is the :entity: in charge of approving rights. They=E2=80=99re probably a person. It might be software that makes a policy decision in some way, or a corporate entity, or something like that. But it=E2= =80=99s not assumed to be a computational agent in the terms of the protocol itself. Would that recast what you=E2=80=99= re saying below?

    =C2=A0=E2=80= =94 Justin

    On Mar 25, 2021, at 12:36 PM, Alan Karp <alanhkarp@gmail.com&g= t; wrote:

    = There seems to be some confusion about how AS-RO comes into the picture, probably because of the "AS" pa= rt.=C2=A0 I'm going to try to clear up that confusion by more carefully explaining what I mean.

    I'm assuming that RO is a computational agent representing the person who is the resource owner, something called the "user agent&= quot; in operating systems lingo.=C2=A0 I= 9;m also assuming that it's possible to do delegation, either locally or by token exchange with AS-RS.=C2=A0 All delegations are potentially sub-scoped, but you may also want to delegate with full scope to have a separately revocable access token.

    =C2=A0 Here&= #39;s an example of how things work in a capability oriented system.
    1. Someone, the service owner, creates a service.
    2. The service owner contracts with an policy agent (AS-RS) to create and manage access tokens for that service (RS).
    3. A person wishing to create a resource at RS uses their user agent (RO) to contact the service owner's polic= y agent (AS-RS) and gets back an access token for that resource.
    4. That user agent (RO) can=C2=A0
      1. use that access token to invoke the resource, or
      2. delegate an access token to a client of the user agent's (RO) choice, or
      3. contract with a policy agent (AS-RO) to manage those delegations on behalf of the user agent (RO), or
      4. specify a policy with the service's policy agent (AS-RS).
    5. A client can contact any holder of the access token (the user agent (RO) or its policy agent (AS-RO)) or the service's policy agent (AS-RS) to get a delegated access token.
    6. That client can delegate that token to another client.
    7. Another user agent (RO') can contact any holder of the access token or the service's policy agent (AS-RS) to get a delegated access token.
    8. The other user agent (RO') can=C2= =A0
      1. use that access token to invoke the resource, or
      2. delegate it to a client of its choice, or
      3. contract with a policy agent (AS-RO'= ) of its choosing to manage those delegations on its behalf, or
      4. specify a policy with the service's policy agent (AS-RS).
    9. and so on
    When any of these computational agents, user agents (ROs) or clients acting on their behalf, invokes the resource, AS-RS verifies that the access token is a valid delegation, i.e., proper sub-scoping, hasn't been revoked, and that it authorizes the request being made before telling the service (RS) to honor the request.=C2=A0 At no point does the service's policy agent (AS-RS) know which computational agent did any particular delegation.=C2=A0 (Token exchange can be done as anonymously as possible.)=C2=A0 = In particular, the policy agents (AS-RO) need not be the same, or even compatible with, the service's policy agent (AS-RS).=C2=A0 GN= AP specifies the protocol between requesters, invokers, delegators (for token exchange) of tokens and AS-RS.=C2=A0 That protocol need not be used between user agents (RO), clients, or other policy agents (AS-RO), but it is likely to be.

    =C2=A0------= -------
    = Alan Karp


    On Thu, Mar 25, 2021 at 5:45 AM Justin Richer <jricher@mit.edu> wrote:
    The way I=E2=80=99m think= ing about Adrian=E2= =80=99s use case is that what we=E2=80=99re cal= ling the =E2=80=9CAS-R= O=E2=80=9D isn=E2=80=99t an = =E2=80=9CAS=E2=80=9D in the traditional OAuth/GNAP sense, at least not exactly. This is the agent that the RO can use to set policies and manage consent on their behalf, and I=E2=80=99ve been arguing that it fits better into this vaguely-defined =E2=80=9Cinteract= ion component=E2=80= =9D aspect of the current AS definition, and it=E2=80=99s = not currently separated from the AS definition. The =E2=80=9CAS-R= S=E2=80=9D maps to what we=E2=80=99d call= the =E2=80=9CAS=E2=80= =9D in OAuth/GNAP traditionally, it=E2=80=99s what= the RS trusts to issue tokens. In traditional OAuth the AS-RO and AS-RS are always the same thing, from a functional protocol perspective. An important point here is that from a client=E2=80=99s perspective, they=E2=80=99re o= nly talking to the AS-RS since that=E2=80=99s wh= ere the client gets its tokens, because at the end of the day the client just wants to call the API at the RS and doesn=E2=80=99t c= are how that happens (from a protocol standpoint).=C2= =A0

    Note well: Even thought I don=E2=80=99t bel= ieve that =E2=80=9CAS-= RO=E2=80=9D is an authorization server at all, I=E2=80=99m going= to keep using that term below for consistency with previous discussion.

    So we have these fundamental relationships around getting the client to access the RS:

    1. RS trusts=C2=A0AS-RS= =C2=A0to issue tokens that RS will accept, validate, and process for requests from client
    2. Client trusts=C2=A0AS-RS=C2=A0to issue tokens that client can use at RS
    3. RO trusts RS to protect RO=E2=80= =99s api through delegated access

    On top of that, we=E2=80=99= ve got some additional aspects that we=E2=80=99re discussing:

    4. RO trusts=C2=A0AS-RO= =C2=A0to manage RO=E2=80= =99s policies at runtime
    5.=C2=A0AS-R= S=C2=A0trusts=C2=A0AS-RO=C2=A0to assert RO=E2=80= =99s policies for access to RS
    6. Client trusts whatever=C2=A0AS-RS=C2=A0sends client to deal with, including possibly RO-A= S at runtime, because of (2)

    What I have been saying is that 4/5/6 are optional details of how RS-AS runs things, and I think this also maps with Adrian=E2=80=99s = view of choice, since if my RS=E2=80=99s AS-R= S doesn=E2=80=99t a= llow me to plug in my own AS-RO then I would be motivated to pick a different RS who=E2=80=99s AS-= RS lets me do just that. The same way I=E2=80= =99d pick a different RS if their surrounding services didn=E2=80=99t ac= cept my preferred federation login and I didn=E2=80=99t wa= nt to make another account. Of course, market forces being as they are, I might not have much of an actionable choice in RS, but GNAP can=E2= =80=99t change that.=C2= =A0

    What we can do is make it possible for AS-RS to talk to AS-RO, both in philosophy of the protocol design and in concrete hooks to support (6) above.=C2=A0

    Separately, we can approach the issue of making 1/2 above more dynamic. This was UMA2=E2=80=99= s =E2=80=9Cfederate= d authorization=E2= =80=9D approach, and is behind a lot of the =E2=80=9Cbring yo= ur own AS=E2=80=9D m= odels out there. The problem with these is that we know from many years of experience that most RS=E2= =80=99s aren=E2=80=99t interested in doing anything of the sort.

    So with GNAP we can instead allow 4/5/6 to vary in a predictable and consistent way, letting the RS keep control over 1/2, thereby enabling choice in (3). We don=E2=80=99t = have to be the ones who define the all of the details of every permutation of (5) to enable this, though. Some of this is going to be configuration out of band, some of it=E2=80= =99s going to be communication at runtime. This is where VC=E2=80=99s, ZCA= Ps, CHAPI, DIDComm, FIDO, and a whole swath of other tech can come in and help out. I don=E2=80= =99t think we need to put all the details for using these into core, nor do I think we=E2=80=99ll pul= l of The Great And Ultimate Abstraction for using these and other approaches. But we can at least start talking about =E2=80=9CAS-RS=E2= =80=9D in such a way that it no longer assumes it=E2=80=99s alwa= ys the same party dealing with the RO directly.



    --00000000000090d2c605beb12e62--

    On Thu, Mar 25, 2021 at 4:15 A= M Fabien Imbault <fabien.imb= ault@gmail.com> wrote:
    Thanks. The general problem statement is clear.

    <= div>The=C2=A0proposed solution a bit less (to me). I understood that from p= oint 2, Alan involves 2 ASs. You said : "There=E2=80=99s no obvious reason to have two types of ASs".=C2= =A0Do you see an alternative ?

    Regarding the last item, I don't think that naming RQ by e= nd-user created the problem. It might just highlight the asymmetry,=C2=A0wh= ich fundamentally exists.=C2=A0

    Fabien


    On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper &l= t;agropper@heal= thurl.com> wrote:
    Recap:
    1 - Justin (I th= ink) introduced the idea of an AS on the RS trust boundary side.
    2 - I said the RO should not have to share policies with the R= S.
    3 - Alan invented the concept of AS-RO and AS-RS = to separate two kinds of PDPs.=C2=A0

    The thing is that step 2 is not symmetrical. The RO has a legi= timate privacy interest in keeping their policies private and minimizing th= e leakage of information about requests that are posed against those polici= es.=C2=A0

    The RS, on the= other hand, should be publishing its policies (e.g. what it=E2=80=99s sell= ing or what jurisdiction it=E2=80=99s in or what tokens or scopes it suppor= ts). The RS has no obvious privacy interest in GNAP. It=E2=80=99s just an e= nforcer.

    There is one ot= her privacy interest to consider around the RS and that is the requesting p= arty (the end-user that is not the RO :-) might prefer to share attributes = with the RS instead of the RO or something controlled by the RO. This case = could be an =E2=80=9Cextension=E2=80=9D to GNAP and might result in a split= AS as a solution. This problem was introduced when the editors decided to = replace RQ with end-user. Obviously, the RO end-user has no privacy interes= ts relative to itself.

    A= drian




    On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault <fabien.imbault@gma= il.com> wrote:
    I was referring to "By my definition, this model has two ASs since both are p= rocessing requests into tokens". If there's no reason to have 2 ty= pes of ASs, that's fine then.=C2=A0
    But I'm a bit lost in where we stand with the idea= .=C2=A0

    =
    Could you recap?=C2=A0

    Fabien=C2= =A0

    Le jeu. 25 mars 2021 =C3=A0 08:16, Adrian Gropper <= agropper@health= url.com> a =C3=A9crit=C2=A0:
    There=E2=80=99s no obvious reason to = have two types of ASs. Any AS that is executing the policies of the RS can = look to GNAP like the RS itself. Why would GNAP expose that interface to an= yone?=C2=A0

    Adrian
    =

    O= n Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault <fabien.imbault@gmai= l.com> wrote:
    Note : I'm not sure that's a good idea, but = having 2 types of ASs is not that easy to grasp.

    Fabien=C2=A0

    Le jeu. 25 mar= s 2021 =C3=A0 08:07, Fabien Imbault <fabien.imbault@gmail.com&= gt; a =C3=A9crit=C2=A0:
    The purpose of either handling policies locally o= r delegating them to the RO agent.=C2=A0

    Le jeu. 25 mars 2021 =C3=A0 08:04, = Adrian Gropper <agropper@healthurl.com> a =C3=A9cr= it=C2=A0:
    What purpose would be served by GNAP splitting the AS into two = components?

    Adrian=C2=A0=

    On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbau= lt <fabien.imbault@gmail.com> wrote:<= br>
    Isn't the AS-RO a component of the AS? Same idea as the interact comp= onent, it functionnally belongs to the AS role but could be deployed either= as a monolith or as a separate component?

    Fabien

    Le jeu. 25 mars 2021 =C3= =A0 04:26, Adrian Gropper <agropper@healthurl.= com> a =C3=A9crit=C2=A0:
    Yes, but I would say it=E2=80=99s not the= RO that wants the access token. It=E2=80=99s the RO that wants the client = making the request to get an access token.=C2=A0
    Adrian

    On Wed, Mar 24, 2021 at 11:22 PM Alan K= arp <alanhkarp@gmail.com> wrote= :
    Adrian Gropper &l= t;agropper@healthurl.com> wrote= :

    In this design, the AS is the AS-RS and = the agent is the AS-RO. By my definition, this model has two ASs since both= are processing requests into tokens. The problem with this is complexity a= nd privacy. The RO may not want to share the request information with the A= S-RS.

    More precisely, RO has no choice but to present the required information= to AS-RS if RO wants an access token.=C2=A0 However, RO does not want AS-R= S to know the policy by which RO delegates tokens.=C2=A0 That's why RO = uses AS-RO for those delegations.

    --------------<= br>Alan Karp


    On Wed, Mar 24, 2021 at = 7:41 PM Adrian Gropper <agropper@he= althurl.com> wrote:
    Thank you for creating the iss= ue. My definition of AS is independent of AS-RO or AS-RS.=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecom= ment-806280421 I also agree with Alan's definition based on delegat= ion. An AS-RS would be a delegate of the RS.=C2=A0
    Based on that, I see it as obvious=C2=A0that the policy has to= be accessible (defined locally?) in order for it to be run as the code tha= t turns a request into an access token.=C2=A0

    The = only other possibility is that the request is packaged by the AS and sent e= lsewhere (an agent) for evaluation against policy and a proto-token returne= d. In that case the AS is acting as a proxy and the PDP is elsewhere. I can= imagine that an AS-RS would behave this way so that the proto-token could = be turned into an access token by the AS-RS. Isn't this what Justin is = proposing? In this design, the AS is the AS-RS and the agent is the AS-RO. = By my definition, this model has two ASs since both are processing requests= into tokens. The problem with this is complexity and privacy. The RO may n= ot want to share the request information with the AS-RS.

    Adrian

    On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Isn't that what the AS is supposed to be, only with the caveat th= at the policy is defined locally?=C2=A0

    Fabien=C2=A0


    Le mer. 24 mars 2021 =C3=A0 20:17, Alan Karp <= alanhkarp@gmail.com> a =C3=A9crit= =C2=A0:
    AS-RO is an AS that RO trusts to delegate RO'= s access tokens according to RO's policies.=C2=A0=C2=A0

    --------------
    Alan Karp


    On W= ed, Mar 24, 2021 at 9:36 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Alan and = Adrian,

    I've created issue AS-RO policy delegation (= https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to = capture your input.=C2=A0
    A first question that arises: can we gi= ve a definition to AS-RO?

    Thanks
    Fabien<= /div>

    On Tue, Mar 23, 2021 at 4:15 PM Alan Karp <alanhkarp@gmail.com> wrote:
    <= div dir=3D"ltr">
    Fabi= en Imbault <fabien.imb= ault@gmail.com> wrote:
    Hi Alan,=C2=A0

    Yes, but i= n that flow, the token relationship between AS-RS and AS-RO is only secure = if the tokens issued by AS-RS are cryptographically attenuable in the first= place.=C2=A0
    =C2=A0
    Attenuated delegation is a requirement, but that doesn't have to be d= one cryptographically.=C2=A0 Token exchange works just fine.=C2=A0 SPKI and= zcap-ld are examples of the crypto approach, and we used token exchange in= the system for HP.

    --------------
    Alan Ka= rp


    On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault <fabien.imbault@gmail.com>= ; wrote:
    Hi Alan,=C2=A0

    Yes, but in that flow, the toke= n relationship between AS-RS and AS-RO is only secure if the tokens issued = by AS-RS are cryptographically attenuable in the first place.=C2=A0

    Fabien

    On Mon, Mar 22, 2021 at 9:26 PM Alan Karp <= ;alanhkarp@gmail.com> w= rote:
    Justin Rich= er <jricher@mit.edu> wro= te:
    But with all that in mind, I think the key here is going to be= looking at what the inputs to the AS are, and how those can be defined in = an interoperable way for AS=E2=80=99s that can accept them. I think there= =E2=80=99s a lot of room for innovation and flexibility here that doesn=E2= =80=99t break the trust model or core use cases. If I have an AS-RS set tha= t won=E2=80=99t accept my favorite flavor of policy engine inputs, then I c= an decide not to use that one. But this is a very different question than s= aying the RS itself needs to accept my own AS =E2=80=94 and we can=E2=80=99= t keep conflating these two models.

    =
    I agree.=C2=A0 The point of having an AS-RO is to allow RO to specify = a policy for which of RO's access tokens should be delegated under what= conditions.=C2=A0 AS-RS should not need to understand those policies.=C2= =A0 The flow would be
    • RO contacts AS-RS and gets one or m= ore access tokens.
    • RO delegates one or more of those tokens, potent= ially sub-scoped, to AS-RO.
    • A different user contacts AS-RO to get = a potentially sub-scoped access token from AS-RO.
    • That user present= s the access token delegated by AS-RO when invoking the resource.
    =
    AS-RS only needs to verify that the delegation chain is leg= itimate, e.g., no increase in scope, and that it grants permission for the = request being made.=C2=A0 AS-RS does not need to understand the policy behi= nd granting the delegation by AS-RO.

    ------------= --
    Alan Karp


    On Mon, Mar 22, 2021 at 11:40 AM Justin Rich= er <jricher@mit.edu> wro= te:
    Adrian,=

    I think this shows the problem with the terminology as = it=E2=80=99s been applied in this conversation, which I=E2=80=99ve tried to= shine light on before. What you and others are calling the =E2=80=9CRS=E2= =80=9D is really the =E2=80=9CAS and RS working together=E2=80=9D =E2=80=94= everything to the right of the line. When Denis had brought up =E2=80=9Cel= iminating the AS=E2=80=9D in another thread, what he=E2=80=99d really done = is labeled everything to the right of the line as the =E2=80=9CRS=E2=80=9D.= Of course, the irony here is that everything to the right of the line used= all be called the =E2=80=9CAS=E2=80=9D or simply =E2=80=9Cserver=E2=80=9D = in the OAuth 1 days. As you say below, I don=E2=80=99t want the client to h= ave visibility on what happens on that side.=C2=A0

    Note well: The Google+ logo labeled =E2=80=9CIdP=E2=80=9D in the diagram i= s not the AS, as far as GNAP is concerned. It does not issue an access toke= n that the RS will accept. The elements to the left of the line could be a = lot of things, but they are NOT the AS =E2=80=94 by definition. The client = lives over on the left, but so do any external inputs to the AS. These coul= d be policy inputs on behalf of the RO, they could be presentation artifact= s, they could be federated logins, they could be the output of policy decis= ions. How the AS comes to trust those things is up to the AS=E2=80=99s impl= ementation. It=E2=80=99s something we can talk about, but ultimately GNAP w= on=E2=80=99t be in any position to dictate because in practice some AS=E2= =80=99s are simply going to internalize all policies and we will never succ= essfully force those open.=C2=A0

    But with all that= in mind, I think the key here is going to be looking at what the inputs to= the AS are, and how those can be defined in an interoperable way for AS=E2= =80=99s that can accept them. I think there=E2=80=99s a lot of room for inn= ovation and flexibility here that doesn=E2=80=99t break the trust model or = core use cases. If I have an AS-RS set that won=E2=80=99t accept my favorit= e flavor of policy engine inputs, then I can decide not to use that one. Bu= t this is a very different question than saying the RS itself needs to acce= pt my own AS =E2=80=94 and we can=E2=80=99t keep conflating these two model= s.

    So to me, GNAP can support a Zero Trust Archite= cture by LEVERAGING the AS, not by subsuming or eliminating it. It is in fa= ct the AS, not the client and not the RS, that will request and consume the= results of a privacy-preserving zero-trust policy query thing. Anything th= at happens downstream from that is of little concern to the zero-trust comp= onents because, as you point out, it=E2=80=99s on the =E2=80=9Cother side= =E2=80=9D of the line.=C2=A0

    I think we got this b= asic component model pretty right in OAuth: the AS and RS and client workin= g together. Where OAuth misses the mark is the assumption that the user has= to log in to the AS through a webpage and interact directly, thereby provi= ng they=E2=80=99re the RO. It=E2=80=99s this latter space where I think we = can both push innovation and also address the important and compelling use = cases like the ones you=E2=80=99re bringing.

    =C2= =A0=E2=80=94 Justin

    On Mar 22, 2= 021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    I'm sorry, Justin. As a Resource Owner, I look at the RS trust bound= ary (the dotted line in the diagram) as being the RS. I don't expect an= y visibility into what's going on on the=C2=A0right.=C2=A0

    My problem with the framing you propose is that requests are going t= o the RS (or the AS-RS) and I don't want to share my policies with the = AS-RS. I want to keep the RS and AS-RS as ignorant as possible.
    <= br>
    Adrian

    On Mon, Mar 22, 2021 at 1:48 PM Justin Richer <= ;jricher@mit.edu> wrote:
    Adrian,
    <= br>
    What you=E2=80=99re discussing below, in terms of logging in = to a site, is not approaching the RS. You are in fact approaching the clien= t, and identifying both the AS and RS to the client. The client is a client= of your identity in this model, and the RS is part of the identity = provider. It=E2=80=99s really important that we don=E2=80=99t conflate the = RS and client in this way as it leads to a lot of confusion downstream and = a lot of broken trust boundaries.

    With that model = in mind, approaching the =E2=80=9CRS" and providing it your identity i= s really just a case of the =E2=80=9Cfederated login to AS=E2=80=9D pattern= that we discussed on the WG call. The user here approaches an RS, which ha= s its own AS. To share things from this RS, the RO has to authenticate to t= he RS=E2=80=99s AS. This particular AS allows the RO to do so using an exte= rnal identity =E2=80=94 in which case, the AS is now a =E2=80=9Cclient=E2= =80=9D of a separate, disconnected (but layered) delegation. The ultimate c= lient that eventually calls the RS down the way may or may not know about t= hese layers.=C2=A0

    <Pas= tedGraphic-1.png>
    This same AS, which is closely tied t= o the RS and trusted by the RS, might also take in FIDO credentials, or DID= s, or any number of other proof mechanisms. The output of this is an access= token the RS trusts, but the input is up to the AS. The RS is not what you= =E2=80=99re logging in to.

    =C2=A0=E2=80=94 Justin<= br>

    On Mar 22, 2021, at 1:28 PM, Adr= ian Gropper <agropper@he= althurl.com> wrote:

    I too am in favor= of avoiding consolidation and correlation. Right now, when I approach a se= rvice provider (RS) for the first time, I'm offered the opportunity to = identify my persona as: email, sign-in with Google, Facebook, or Apple. I k= now there are people who try to create one-off email addresses but that is = mostly a waste of time.=C2=A0

    So, along come FIDO2 and D= ID wallets to the rescue. Now, in theory, I have a way to start out my RS r= elationship pseudonymously.=C2=A0

    When I want my r= esource to be discovered or shared I will post that RS URL including my pse= udonym. If I then want to introduce a mediator=C2=A0in front of my AS or me= ssaging service=C2=A0endpoint, I have that option. If I want to keep reques= ts away from the mediator, I would publish an encryption key along with my = pseudonym.

    - Adrian


    <= /div>

    On Mon, Mar 22, 2021 at 9:55 AM Justin Richer <jricher@mit.edu> wrote:
    On Mar 21, 2021, at 1:18 PM, Benjamin K= aduk <kaduk@mit.edu> wrote= :
    >
    > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
    >> @Alan Karp <alanhk= arp@gmail.com> shared a talk about the Principle Of Least
    >> Authority (POLA) in a recent comment
    >> https://github.com/ietf-wg-= gnap/gnap-core-protocol/issues/145#issuecomment-803099693
    >> I recommend it.
    >>
    >> We might expect a protocol with authorization in the title to use = authority
    >> as a core principle. I advocate for a GNAP design that maximizes t= he power
    >> of the RO, to be seen as a human rights issue when the RO is a hum= an. This
    >> causes me to ask how to combine better security with better human = rights in
    >> GNAP.
    >>
    >> Who should have the least authority in the GNAP design?
    >>
    >> The AS derives authority as a delegate of the RO. If we ask the RO= to
    >> partition limited authority across dozens of different ASs by doma= in and
    >> function, then we are not using technology to empower the individu= al.
    >> Probably the opposite, as we introduce consent fatigue and burden = normal
    >> people to partition their lives into non-overlapping domains.
    >>
    >> My experience says we should aim for one AS per persona because th= at maps
    >> into the way we manage our public and private identities. POLA wou= ld then
    >> teach care in keeping ASs and RSs related to work / public separat= e from
    >> ASs and RSs related to private life so that a policy vulnerability= in our
    >> delegation to an AS would have the least likelihood of harm.
    >
    > Thinking about how least authority/least privilege would apply to GNAP=
    > seems like a useful exercise.=C2=A0 I do want to point out some potent= ial
    > pitfalls with one-AS-per-persona that we can also be aware of.=C2=A0 I= f
    > one-AS-per-persona becomes one-persona-per-AS as well, then the AS'= ;s
    > identity in effect also serves as a persona identity and there are pri= vacy
    > considerations to that.=C2=A0 If, on the other hand, the
    > multiple-personas-per-AS (presumably corresponding to multiple humans)=
    > route is taken, we should consider whether that would lead to various<= br> > (e.g., market) forces driving consolidation to just a handful of
    > super-popular AS services.=C2=A0 That topic is a current matter of con= cern to
    > some IETF participants.
    >

    Hi Ben, big +1 to this. This is something that we discussed ages ago in the= UMA working group, and it=E2=80=99s one of the biggest problems with the p= ersonal AS (and personal data store) model. This kind of thing makes RS-fir= st trust models really difficult in practice.

    As a strawman, let=E2=80=99s say that I=E2=80=99ve got software that wants = to access my medical information. It calls an RS and requests access, but i= t hasn=E2=80=99t been granted anything yet. Now I as the RO have set up the= RS so that it talks to my personal AS, that only I use. In addition to the= RS having to be able to figure out which medical records are being request= ed from the context of the unauthenticated request (which means it needs id= entifiers in the URL or something similar for the RS to be able to tell, as= suming that it protects data for more than one person). So this client soft= ware doesn=E2=80=99t know who I am and doesn=E2=80=99t know my medical reco= rd information, makes a completely unauthorized request to the RS, and the = RS says =E2=80=9CGo to Justin=E2=80=99s personal AS to get a token=E2=80=9D= . The client can now make a direct correlation between the data that=E2=80= =99s being protected at the RS and the person running the AS that protects = it. Importantly, this client makes this call with no prior relationship to = the RS and no really auditable way to track it down after the fact. This is= a design feature in the good case, and terrifying in the bad case.

    If the RS instead says =E2=80=9Cwelcome to Medicine Doctor RS, please talk = to the Medicine Doctor AS to get access=E2=80=9D, we haven=E2=80=99t expose= d anything at all. And from the perspective of both the patient and the RS,= this is more privacy-preserving, and it=E2=80=99s really the least surpris= ing option. Once the client gets to the AS, it can start a negotiation of f= iguring out who the RO is for the information being accessed.

    On top of this, the usability expectations of people managing their own AS,= or set of AS=E2=80=99s for multiple personas to keep things separate, is a= huge burden. Even in the tech community, I know people who can=E2=80=99t r= eliably manage more than one email address for different purposes. I wouldn= =E2=80=99t expect my partner to do that =E2=80=94 they have trouble enough = balancing all the logins and sessions required for different kids remote sc= hooling, I couldn=E2=80=99t imagine them having to understand all the requi= rements for managing multiple authorization servers and associated policies= . I also don=E2=80=99t expect any person to =E2=80=9Cmanage keys=E2=80=9D = =E2=80=94 I=E2=80=99ve been on the internet for decades and I can barely ke= ep tabs on my GPG keys, and only use them when I am forced to. This is exac= tly the kind of =E2=80=9Cmarket pressure=E2=80=9D that I think Ben mentions= above, people will just want to outsource that to someone else, and the re= ality will be a few popular providers.

    In which case, we could end up doing a ton of work to allow an RS choice on= ly to end up with a world where the RS ends up making a limited choice anyw= ay. We see how that plays out with OpenID Connect =E2=80=94 RP=E2=80=99s co= uld allow arbitrary IdPs but they choose Google because it works and that= =E2=80=99s where the users are. (And that=E2=80=99s not to say anything of = the proprietary OIDC-like protocols, but that=E2=80=99s another discussion)= .

    For further reading on these topics, I recommend both =E2=80=9CWhy Johnny C= an=E2=80=99t Encrypt=E2=80=9D and =E2=80=9CWhy CSCW Systems Fail=E2=80=9D.<= br>
    So what does this have to do with GNAP? I think we can be clear-eyed on wha= t kinds of expectations we have for the participants. If we expect users (R= O=E2=80=99s) to have to set up the AS-RS relationship, or expect them to ca= rry their AS, or manage their personal keys =E2=80=94 I think we=E2=80=99ve= lost the battle for relevance.

    =C2=A0=E2=80=94 Justin


    --
    TXAuth 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
    On Fri, Mar 12, 2021 at 6:07 PM Justin Richer &l= t;jricher@mit.edu> wrote:
    As discussed at the IETF meeting, the editors proposed t= hat one of our next big topic areas was going to be the nature of the AS ro= le within the GNAP protocol, especially how it relates to the device-driven= use cases that have been brought up. Apologies in advance for the long pos= t, but there are a lot of parts to this discussion that I=E2=80=99m hoping = we can kick off here.

    My core proposal is that we see th= e AS as the component that has the following properties:
    =C2=A0- = receives delegation requests from the client instance for access to an RS v= ia access tokens, and for access to subject information returned directly t= o the client instance
    =C2=A0- collects consent and authorization = from the RO for the delegation
    =C2=A0- issues access tokens that = its downstream RS=E2=80=99s can interpret (and validate/accept)
    = =C2=A0- issues subject information asserted by the AS=C2=A0

    This framing of the parties is really important in making a consist= ent understanding of how the protocol works, and a consistent understanding= is vital if we=E2=80=99re going to function as a working group in both dis= cussing the problem space and executing the solution space. For a historica= l example, a naive approach to adding identity on top of a protocol like OA= uth 2 (or GNAP) is to declare that the resource server is the thing the use= r is logging in to. This seems reasonable at first (and some people tried d= oing this) but it violates all kinds of trust boundaries and puts new expec= tations on the different parties that do not make sense. It stops looking a= nything like OAuth very quickly and turns into another protocol. If instead= we say the user is logging in to the client, things suddenly make a lot mo= re sense and we can do a lot more with it. (See this blog post from 2013 fo= r one take on that discussion:=C2=A0https://www.c= loudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/)
    I think we=E2=80=99ve got a similar situation here when we sta= rt to talk about the user bringing their own AS with them. I think this is = a reasonable-seeming assumption but it=E2=80=99s based on a false premise t= hat the RO has to log into the AS to approve the request, and the AS has fu= ll control and view over everything in the network. While OAuth doesn=E2=80= =99t require this, it=E2=80=99s largely assumed that=E2=80=99s how it works= . After all, all of the early OAuth deployments worked exactly this way: th= e user logs in and clicks the =E2=80=9COK=E2=80=9D button. However, cloud d= eployments have shown us that it=E2=80=99s perfectly reasonable for an OAut= h AS to take in its consent and user information from an external trusted s= ource, and so this model is not even accurate in OAuth.

    In short, I think we can do a better job here of defining things in t= erms that both accept the reality we face and enable new ideas in ways that= make sense. It=E2=80=99s my stance that the user shouldn=E2=80=99t need to= bring the AS with them in order to have the kind of input and control of t= he system that people are asking for. Instead, the AS should be able to tak= e inputs from things that the user controls in order for the AS to do its j= ob.

    People have discussed privacy concerns with th= e AS knowing =E2=80=9Ctoo much=E2=80=9D, but in many of those discussions t= he knowledge is simply pushed to the RS instead. What I=E2=80=99m observing= here is really just pushing portions of the AS role into the =E2=80=9CRS= =E2=80=9D deployment. This doesn=E2=80=99t make it less of an =E2=80=9CAS= =E2=80=9D role, it=E2=80=99s just being fulfilled closely to where the RS r= ole is fulfilled. As such, my proposal is really not that different in prac= tice, but the labels are different and better aligned with the capabilities= of the protocol.=C2=A0

    We=E2=80=99ve previo= usly talked about separating the user-facing portions of the AS into anothe= r component, and I think now might be the time to do that. This is a very f= lammable strawman proposal, but what if we had the AS defined, as above, an= d the =E2=80=9Cconsent and authorization=E2=80=9D gathering portion is augm= ented by another named component. Here let=E2=80=99s call it an Interaction= Component. This can take several forms based on the kind of interaction mo= de in use:

    =C2=A0- Hosted at a URL the user is red= irected to; it can then make the user log in, consent, and whatever else th= ey need to do
    =C2=A0- Hosted at a URL the user will load separate= ly and enter in an access code
    =C2=A0- An app on the user=E2=80= =99s device that the user interacts with directly and which sends informati= on back to the AS
    =C2=A0- An app reachable by a messaging endpoin= t that the AS sends and receives structured information from
    =C2= =A0- The client itself that is given an indication as to what information t= he AS needs in order to fulfill the request; this could be MFA challenge/re= sponse, user credentials, signed claims, etc.

    It= =E2=80=99s the AS=E2=80=99s job to accept any and all of these that it supp= orts and churn those into an access token.=C2=A0

    T= he AS itself doesn=E2=80=99t ever need to have the user log in. The AS does= n=E2=80=99t necessarily need to even know who the user is in any way. The A= S just needs to know from a trusted source that the request is approved.

    From a practical standpoint, I think this will have = some small changes in how we talk about the components and how we talk abou= t the interaction phase of the grant negotiation process. Everything I=E2= =80=99m laying out here is currently allowed by the spec, but I think we=E2= =80=99ve carried through the same assumptions from OAuth 2 about deployment= that are both inaccurate and confusing.=C2=A0

    =C2= =A0=E2=80=94 Justin
    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --00000000000049c73a05bd5a2754-- From nobody Fri Mar 12 13:34:21 2021 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 AD6423A145B for ; Fri, 12 Mar 2021 13:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 yN5-6AVMheaB for ; Fri, 12 Mar 2021 13:34:16 -0800 (PST) Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com [209.85.217.53]) (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 681E53A1443 for ; Fri, 12 Mar 2021 13:34:16 -0800 (PST) Received: by mail-vs1-f53.google.com with SMTP id a12so13247936vsd.3 for ; Fri, 12 Mar 2021 13:34:16 -0800 (PST) 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=wxJp0o3ofDK6Zy+v7IrZVs1/fUy/ULlZudPwnHjFCUU=; b=FI2EJHsqKDhSZmBvZZdNfG6xFwuunig9XkBJeKZMrS4yUglsH52bOzbbIwJNIrD56i Ijjelayc67DfT264+hInsIlxyCRNG4ridfvqcatT7Vxge9bPPwevAA9VwLCslOR9qdhZ AljxeBKiaF34d2NMpaVXEnD2Y++B0nc5F4dLC7Tq+hHCmwPaHVt7PtRREgRVW7y5fCz9 jrBeniSfgZTpLdlU2y+0Iq71XYtoi4SR+1VC2mrqbf84xVNyoUxPruszgJfkslBPIgTi uSmyifahYT0kfZ3op21zE5p7VOsCaAd2O+ciJmVXwzYJKVBmOe9fhjU6Qexlwq7A63gt s5TQ== X-Gm-Message-State: AOAM532WkdeKgjccj1qM9jN9oFxxub1draerFUwWyC4dmSJTKUEoRmqa RoNx4NviakuCLyJQRGkBofPayF5DQz+j1kbGCIQ= X-Google-Smtp-Source: ABdhPJzsWth9lfbAX8T2ckpx3VTBKupwbqSo/30yEEO8lXIL1RMWsSG6ecPC/GCFzDEje3/xs8i9O2Q8EMDbRZjKBPQ= X-Received: by 2002:a67:cb87:: with SMTP id h7mr187797vsl.33.1615584855297; Fri, 12 Mar 2021 13:34:15 -0800 (PST) MIME-Version: 1.0 References: <205ACFE1-7D4C-4D7C-B394-4AD8A4D4D080@mit.edu> In-Reply-To: From: Adrian Gropper Date: Fri, 12 Mar 2021 16:34:04 -0500 Message-ID: To: Fabien Imbault Cc: Justin Richer , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000006791f205bd5da90f" Archived-At: Subject: Re: [GNAP] GNAP Architecture and the role of the AS X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2021 21:34:20 -0000 --0000000000006791f205bd5da90f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Let=E2=80=99s try to map a real-world use-case into the names and roles we = are discussing. The use-case is documented as the API Task Force Recommendations (2016) https://www.healthit.gov/sites/default/files/facas/SingleSourceofTruth-APIT= FRecommendations.pdf and I=E2=80=99ve copied below the most relevant section. Bold highlight is = in the original. I=E2=80=99ve added bold italic because it may be important to our discussion. - ONC should clarify that while API Providers may impose security related restrictions on app access (e.g. rate limiting, encryption, and expirati= on of access tokens), it is inappropriate for API providers to set limitati= ons on what a patient authorized app can do with data downstream. - Given the nature of patient access rights, the provider is not in a legal position to prevent the registration of apps that would aggregate or share data, for example (though the provider might certainly decide to warn the patient, or endeavor to educate and explain these issue to the patient, as part of the provider hosted app approval workflow). - ONC should clarify that API providers are not obligated to protect patients by identifying "suspicious" apps. API providers may suspend API access to an app that has breached the API provider's terms of service , or appears to have been compromised, or if the app poses a threat to the provider's own system. However, patients must be able to override this suspension (except in the case where an app poses threat to the provider's own system or violates allowable terms of service). The key requirements from a patient rights and privacy perspective are: 1. To delegate a scope-limited access capability to anyone anywhere without having to explain or justify that to the API Provider. 2. To allow the patient to automate the issue of a scope-limited access capability by delegating the authority to process API access requests to some agent. The API Provider has no say in who or where this agent is. 3. The automation of the agent is based on policies provided by the patient. The agent is able to process access requests from anyone and is responsible only to the patient. The agent responds to successful reques= ts by issuing a filtered capability to the requesting party. 4. To ensure that the requesting party can delegate the capability using an institutional workflow system that they trust and the patient doesn=E2= =80=99t know or care about. In many cases, the workflow system will pass the capabili= ty to some other person, who we might call the end user. In other cases, th= e requesting party may forward the capability directly to another person using, for example, an email. Either way, the client app used by the end-user to access the API is of no concern to the patient or to the patient=E2=80=99s agent. 5. To ensure that the API Provider does not censor the client app that presents the capability or solicits too much information about the clien= t app or the end-user of the client app. 6. If the API Provider decides, for any reason, to be =E2=80=9Csuspicious= =E2=80=9D (as above) of the access transaction based on the information it has, it sho= uld be possible for the API Provider to warn the patient and to accept an override of the warning by the patient. This effectively means that the end-user will provide as much information as they think will be necessar= y in order to either avoid =E2=80=9Csuspicion=E2=80=9D or risk waiting for= patient override. 7. The policies by which the patient or the decides to grant a capability to the requesting party are never shared outside of the patient-agent tr= ust relationship. In other words, neither the patient nor the agent is asked= to share or explain their reason for an access decision. 8. Access requests to the agent are presumed confidential among the patient, the agent, and whatever client the requesting party uses to present an access request. The API Provider does not get to see the requests and no entity in the GNAP authorization process, other than the patient or the agent, gets to correlate across requests by different requesting party clients. Note that I am not saying all 8 requirements are in scope for GNAP but I am asking for GNAP to allow for this level of privacy on the part of self-sovereign patients using self-sovereign agents and the self-sovereign licensed professionals they deal with. Adrian On Fri, Mar 12, 2021 at 2:50 PM Fabien Imbault wrote: > Hi Justin, > > Just a quick word to say I very much agree with both the observations and > the framing. > > Fabien > > On Fri, Mar 12, 2021 at 6:07 PM Justin Richer wrote: > >> As discussed at the IETF meeting, the editors proposed that one of our >> next big topic areas was going to be the nature of the AS role within th= e >> GNAP protocol, especially how it relates to the device-driven use cases >> that have been brought up. Apologies in advance for the long post, but >> there are a lot of parts to this discussion that I=E2=80=99m hoping we c= an kick off >> here. >> >> My core proposal is that we see the AS as the component that has the >> following properties: >> - receives delegation requests from the client instance for access to a= n >> RS via access tokens, and for access to subject information returned >> directly to the client instance >> - collects consent and authorization from the RO for the delegation >> - issues access tokens that its downstream RS=E2=80=99s can interpret (= and >> validate/accept) >> - issues subject information asserted by the AS >> >> This framing of the parties is really important in making a consistent >> understanding of how the protocol works, and a consistent understanding = is >> vital if we=E2=80=99re going to function as a working group in both disc= ussing the >> problem space and executing the solution space. For a historical example= , a >> naive approach to adding identity on top of a protocol like OAuth 2 (or >> GNAP) is to declare that the resource server is the thing the user is >> logging in to. This seems reasonable at first (and some people tried doi= ng >> this) but it violates all kinds of trust boundaries and puts new >> expectations on the different parties that do not make sense. It stops >> looking anything like OAuth very quickly and turns into another protocol= . >> If instead we say the user is logging in to the client, things suddenly >> make a lot more sense and we can do a lot more with it. (See this blog p= ost >> from 2013 for one take on that discussion: >> https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/) >> >> I think we=E2=80=99ve got a similar situation here when we start to talk= about >> the user bringing their own AS with them. I think this is a >> reasonable-seeming assumption but it=E2=80=99s based on a false premise = that the RO >> has to log into the AS to approve the request, and the AS has full contr= ol >> and view over everything in the network. While OAuth doesn=E2=80=99t req= uire this, >> it=E2=80=99s largely assumed that=E2=80=99s how it works. After all, all= of the early OAuth >> deployments worked exactly this way: the user logs in and clicks the =E2= =80=9COK=E2=80=9D >> button. However, cloud deployments have shown us that it=E2=80=99s perfe= ctly >> reasonable for an OAuth AS to take in its consent and user information f= rom >> an external trusted source, and so this model is not even accurate in OA= uth. >> >> In short, I think we can do a better job here of defining things in term= s >> that both accept the reality we face and enable new ideas in ways that m= ake >> sense. It=E2=80=99s my stance that the user shouldn=E2=80=99t need to br= ing the AS with >> them in order to have the kind of input and control of the system that >> people are asking for. Instead, the AS should be able to take inputs fro= m >> things that the user controls in order for the AS to do its job. >> >> People have discussed privacy concerns with the AS knowing =E2=80=9Ctoo = much=E2=80=9D, >> but in many of those discussions the knowledge is simply pushed to the R= S >> instead. What I=E2=80=99m observing here is really just pushing portions= of the AS >> role into the =E2=80=9CRS=E2=80=9D deployment. This doesn=E2=80=99t make= it less of an =E2=80=9CAS=E2=80=9D role, >> it=E2=80=99s just being fulfilled closely to where the RS role is fulfil= led. As >> such, my proposal is really not that different in practice, but the labe= ls >> are different and better aligned with the capabilities of the protocol. >> >> We=E2=80=99ve previously talked about separating the user-facing portion= s of the >> AS into another component, and I think now might be the time to do that. >> This is a very flammable strawman proposal, but what if we had the AS >> defined, as above, and the =E2=80=9Cconsent and authorization=E2=80=9D g= athering portion is >> augmented by another named component. Here let=E2=80=99s call it an Inte= raction >> Component. This can take several forms based on the kind of interaction >> mode in use: >> >> - Hosted at a URL the user is redirected to; it can then make the user >> log in, consent, and whatever else they need to do >> - Hosted at a URL the user will load separately and enter in an access >> code >> - An app on the user=E2=80=99s device that the user interacts with dire= ctly and >> which sends information back to the AS >> - An app reachable by a messaging endpoint that the AS sends and >> receives structured information from >> - The client itself that is given an indication as to what information >> the AS needs in order to fulfill the request; this could be MFA >> challenge/response, user credentials, signed claims, etc. >> >> It=E2=80=99s the AS=E2=80=99s job to accept any and all of these that it= supports and >> churn those into an access token. >> >> The AS itself doesn=E2=80=99t ever need to have the user log in. The AS = doesn=E2=80=99t >> necessarily need to even know who the user is in any way. The AS just ne= eds >> to know from a trusted source that the request is approved. >> >> From a practical standpoint, I think this will have some small changes i= n >> how we talk about the components and how we talk about the interaction >> phase of the grant negotiation process. Everything I=E2=80=99m laying ou= t here is >> currently allowed by the spec, but I think we=E2=80=99ve carried through= the same >> assumptions from OAuth 2 about deployment that are both inaccurate and >> confusing. >> >> =E2=80=94 Justin >> -- >> 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 > --0000000000006791f205bd5da90f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    Let=E2=80=99s try to map a real-worl= d use-case into the names and roles we are discussing. The use-case is docu= mented as the API Task Force Recommendations (2016) https://www.healthit.gov/sites/default/files/facas/SingleSou= rceofTruth-APITFRecommendations.pdf and I=E2=80=99ve copied below the most= relevant section. Bold highlight is in the original. I=E2=80=99v= e added bold italic because it may be important= to our discussion.=C2=A0


    <quote>

    • ONC should clarify that while API Providers may impose security related= restrictions on app access (e.g. rate limiting, encryption, and expiration= of access tokens), it is inappropriate for API providers to set limitation= s on what a patient authorized app can do with data downstream.

      <= /li>

      • Given the nature of patient access= rights, the provider is not in a legal position to prevent the registratio= n of apps that would aggregate or share data, for example (though the provi= der might certainly decide to warn the patient, or endeavor to educate and = explain these issue to the patient, as part of the provider hosted app appr= oval workflow).

    • ONC should clarify that API providers are not obligated<= /span> to protect patients b= y identifying "suspicious" apps. API providers may suspend API access<= /span> to an app that has br= eached the API provider's terms of service , or appears to have been co= mpromised, or if the app poses a threat to the provider's own system. H= owever, patients must be able to override this suspension (except in the case where= an app poses threat to the provider's own system or violates allowable= terms of service).


      The key requirements from a patient rights and privacy perspecti= ve are:


      1. To delegate a s= cope-limited access capability to anyone anywhere without having to explain= or justify that to the API Provider.

      2. To allow the patient to automa= te the issue of a scope-limited access capability by delegating the authori= ty to process API access requests to some agent. The API Provider has no sa= y in who or where this agent is.

      3. The automation of the agent is bas= ed on policies provided by the patient. The agent is able to process access= requests from anyone and is responsible only to the patient. The agent res= ponds to successful requests by issuing a filtered capability to the reques= ting party.

      4. To ensure that the requesting party can delegate the capa= bility using an institutional workflow system that they trust and the patie= nt doesn=E2=80=99t know or care about. In many cases, the workflow system w= ill pass the capability to some other person, who we might call the end use= r. In other cases, the requesting party may forward the capability directly= to another person using, for example, an email. Either way, the client app= used by the end-user to access the API is of no concern to the patient or = to the patient=E2=80=99s agent.=C2=A0

      5. To ensure that the API Provide= r does not censor the client app that presents the capability or solicits t= oo much information about the client app or the end-user of the client app.= =C2=A0

      6. If the API Provider decides, for any reason, to be =E2=80=9Csu= spicious=E2=80=9D (as above) of the access transaction based on the informa= tion it has, it should be possible for the API Provider to warn the patient= and to accept an override of the warning by the patient. This effectively = means that the end-user will provide as much information as they think will= be necessary in order to either avoid =E2=80=9Csuspicion=E2=80=9D or risk = waiting for patient override.

      7. The policies by which the patient or th= e decides to grant a capability to the requesting party are never shared ou= tside of the patient-agent trust relationship. In other words, neither the = patient nor the agent is asked to share or explain their reason for an acce= ss decision.=C2=A0

      8. Access requests to the agent are presumed confid= ential among the patient, the agent, and whatever client the requesting par= ty uses to present an access request. The API Provider does not get to see = the requests and no entity in the GNAP authorization process, other than th= e patient or the agent, gets to correlate across requests by different requ= esting party clients.


      Note that I am not saying all 8 require= ments are in scope for GNAP but I am asking for GNAP to allow for this leve= l of privacy on the part of self-sovereign patients using self-sovereign ag= ents and the self-sovereign licensed professionals they deal with.

      Adri= an



    On Fri, Mar 12, 2021 at 2:50 PM Fabien Imbault <= fabien.imbault@gmail.com>= ; wrote:
    Hi Justin,=C2=A0
    Just a quick word to say I very much agree with both the obser= vations and the framing.

    Fabien

    On Fri, Mar 1= 2, 2021 at 6:07 PM Justin Richer <jricher@mit.edu> wrote:
    As discussed at the IETF meeting, the editors proposed that one of our ne= xt big topic areas was going to be the nature of the AS role within the GNA= P protocol, especially how it relates to the device-driven use cases that h= ave been brought up. Apologies in advance for the long post, but there are = a lot of parts to this discussion that I=E2=80=99m hoping we can kick off h= ere.

    My core proposal is that we see the AS as the compo= nent that has the following properties:
    =C2=A0- receives delegati= on requests from the client instance for access to an RS via access tokens,= and for access to subject information returned directly to the client inst= ance
    =C2=A0- collects consent and authorization from the RO for t= he delegation
    =C2=A0- issues access tokens that its downstream RS= =E2=80=99s can interpret (and validate/accept)
    =C2=A0- issues sub= ject information asserted by the AS=C2=A0

    This frami= ng of the parties is really important in making a consistent understanding = of how the protocol works, and a consistent understanding is vital if we=E2= =80=99re going to function as a working group in both discussing the proble= m space and executing the solution space. For a historical example, a naive= approach to adding identity on top of a protocol like OAuth 2 (or GNAP) is= to declare that the resource server is the thing the user is logging in to= . This seems reasonable at first (and some people tried doing this) but it = violates all kinds of trust boundaries and puts new expectations on the dif= ferent parties that do not make sense. It stops looking anything like OAuth= very quickly and turns into another protocol. If instead we say the user i= s logging in to the client, things suddenly make a lot more sense and we ca= n do a lot more with it. (See this blog post from 2013 for one take on that= discussion:=C2=A0https://www.cloudidentity.com/b= log/2013/01/02/oauth-2-0-and-sign-in-4/)

    I thi= nk we=E2=80=99ve got a similar situation here when we start to talk about t= he user bringing their own AS with them. I think this is a reasonable-seemi= ng assumption but it=E2=80=99s based on a false premise that the RO has to = log into the AS to approve the request, and the AS has full control and vie= w over everything in the network. While OAuth doesn=E2=80=99t require this,= it=E2=80=99s largely assumed that=E2=80=99s how it works. After all, all o= f the early OAuth deployments worked exactly this way: the user logs in and= clicks the =E2=80=9COK=E2=80=9D button. However, cloud deployments have sh= own us that it=E2=80=99s perfectly reasonable for an OAuth AS to take in it= s consent and user information from an external trusted source, and so this= model is not even accurate in OAuth.

    In short, I = think we can do a better job here of defining things in terms that both acc= ept the reality we face and enable new ideas in ways that make sense. It=E2= =80=99s my stance that the user shouldn=E2=80=99t need to bring the AS with= them in order to have the kind of input and control of the system that peo= ple are asking for. Instead, the AS should be able to take inputs from thin= gs that the user controls in order for the AS to do its job.

    =
    People have discussed privacy concerns with the AS knowing =E2= =80=9Ctoo much=E2=80=9D, but in many of those discussions the knowledge is = simply pushed to the RS instead. What I=E2=80=99m observing here is really = just pushing portions of the AS role into the =E2=80=9CRS=E2=80=9D deployme= nt. This doesn=E2=80=99t make it less of an =E2=80=9CAS=E2=80=9D role, it= =E2=80=99s just being fulfilled closely to where the RS role is fulfilled. = As such, my proposal is really not that different in practice, but the labe= ls are different and better aligned with the capabilities of the protocol.= =C2=A0

    We=E2=80=99ve previously talked about= separating the user-facing portions of the AS into another component, and = I think now might be the time to do that. This is a very flammable strawman= proposal, but what if we had the AS defined, as above, and the =E2=80=9Cco= nsent and authorization=E2=80=9D gathering portion is augmented by another = named component. Here let=E2=80=99s call it an Interaction Component. This = can take several forms based on the kind of interaction mode in use:
    <= div>
    =C2=A0- Hosted at a URL the user is redirected to; it ca= n then make the user log in, consent, and whatever else they need to do
    =C2=A0- Hosted at a URL the user will load separately and enter in a= n access code
    =C2=A0- An app on the user=E2=80=99s device that th= e user interacts with directly and which sends information back to the AS
    =C2=A0- An app reachable by a messaging endpoint that the AS sends= and receives structured information from
    =C2=A0- The client itse= lf that is given an indication as to what information the AS needs in order= to fulfill the request; this could be MFA challenge/response, user credent= ials, signed claims, etc.

    It=E2=80=99s the AS=E2= =80=99s job to accept any and all of these that it supports and churn those= into an access token.=C2=A0

    The AS itself doesn= =E2=80=99t ever need to have the user log in. The AS doesn=E2=80=99t necess= arily need to even know who the user is in any way. The AS just needs to kn= ow from a trusted source that the request is approved.

    =
    From a practical standpoint, I think this will have some small changes= in how we talk about the components and how we talk about the interaction = phase of the grant negotiation process. Everything I=E2=80=99m laying out h= ere is currently allowed by the spec, but I think we=E2=80=99ve carried thr= ough the same assumptions from OAuth 2 about deployment that are both inacc= urate and confusing.=C2=A0

    =C2=A0=E2=80=94 Justin<= /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
    --0000000000006791f205bd5da90f-- From nobody Sat Mar 13 00:26:40 2021 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 632E83A0A35 for ; Sat, 13 Mar 2021 00:26:38 -0800 (PST) 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 M1Dm_p-yO6NO for ; Sat, 13 Mar 2021 00:26:34 -0800 (PST) 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 4BDDE3A0A2B for ; Sat, 13 Mar 2021 00:26:34 -0800 (PST) Received: by mail-il1-x12d.google.com with SMTP id k2so4806198ili.4 for ; Sat, 13 Mar 2021 00:26:34 -0800 (PST) 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=NKoCEegTthxwmRVMCkNKxA3bDGsnXy0vTI8rL9UAsQY=; b=C2ldXSdeMTuwHsPFcgKOR3rt6lOOlSlxX8P6Uzi7TD2svY7xiefiubTa/kA53jk0dZ Soos/YMiHeOwiq5Zql55bFbcKVnvyerKvVR+3FDORhXpRV1cyBFGnwJJMYrd5CdYrdWD kmmlT66BtSz109CHd907hdAvXn9RbPG1yuDC4E693OMlONtYItaqWw/m8M44YIOURosc eBi4L7KPA0Sk+qbAkMoT7OalCR7Q9LfbhoKx8Pz9V+LQCoj+71dHGJW+q/YdY6olDuAI mvFYQOAebV2bjoLRwTKOY2eB6qSl8aW+T0u9t3dVjNIj7TRkdzo8Ob2UB/VhHafLLuf/ qqUA== 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=NKoCEegTthxwmRVMCkNKxA3bDGsnXy0vTI8rL9UAsQY=; b=MuiljXoYm80ScQuxRSWg9/Z+qR6oQmM8FlH9HYdzCSME/O53kzOE94i+5dDRG+3GKX LwlgAuGjp+9PLjNTQDT365owHhCdh+9O6xjMxANlrUpUYnAhxyhzeCQNN/JQulzp43Iy qQXDdSKs2ju69zIdhmjgqdyh7m788Zg6+jjwhyfXcmyS9vh51K0kuehPe5/huU+eC59i 4MnEIfl77euwubvmHM6ocbtws1z+lwby19C+Fz26ySl0olRWKJ7HV/wnKY4WM4ecKz3J JcFtRIoquudyGgfrzfcFJiIk+f4cI+uV1M31o8K+qAheVuIDgGEmjIGORpv02SPQ5+kT OtOg== X-Gm-Message-State: AOAM530n9kRwK5upLEBkBxNGQt8ZOY92QKjhNjzhVCO1h3KcQyaXV3Av PN6or7inGWpk1ni/D7kdgWLnCOo6hOhGpo5j9ns= X-Google-Smtp-Source: ABdhPJz0yTYp53+QEOnG6rESzVmRuC6EQzS1sapcksFNx2zG/kiUOmYOvHMiKXYL5jcGmFtehu/s8iFbSO9135SYzbE= X-Received: by 2002:a05:6e02:1ca7:: with SMTP id x7mr5641115ill.68.1615623992437; Sat, 13 Mar 2021 00:26:32 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Sat, 13 Mar 2021 09:26:19 +0100 Message-ID: To: Justin Richer Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000028f1c605bd66c629" Archived-At: Subject: Re: [GNAP] DID as sub_id or assertion? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2021 08:26:38 -0000 --00000000000028f1c605bd66c629 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Justin, A last word on end-user! =3DRO (again just as food for thought). As soon as hints.automated is set to true, it takes priority over async, which means it's the same model as the one you describe : the AS has precedence over any other remote contact. So that confirms the global view that the AS is the one with the authority, and that it might know more than the client. Cheers Fabien Le jeu. 11 mars 2021 =C3=A0 11:44, Fabien Imbault a =C3=A9crit : > Hi Justin, > > I think that's interesting: > "For the user !=3D RO cases, I think that potentially having a way to sig= nal > those two items separately in the request and response could be useful. > Right now all the user/subject stuff is about identifying =E2=80=9Cthe us= er that=E2=80=99s > currently here at the client instance=E2=80=9D, in a variety of forms tha= t the > client instance and AS can negotiate. If the client or AS has some other > notion about who the RO is and how that could be separate from the curren= t > user, we could provide a way to signal that like you=E2=80=99re proposing= below. In > my mental model, there are going to be a lot of use cases where the =E2= =80=9CRO=E2=80=9D > isn=E2=80=99t known to the client at all, but rather to the AS and is bas= ed on what > the client=E2=80=99s asking for. So I could identify the current user and= ask for a > specific medical record, and the AS realizes it has to go bug a particula= r > doctor to approve things directly. This is instead of interacting with th= e > current user and failing in an awkward way when the current user doesn=E2= =80=99t > have the rights to do things, but someone else would. But we=E2=80=99d wa= nt the > system to be able to detect if the current user is the doctor, so we can > just interact with them directly. Does that all track?" > > I agree with the general idea. In the end, that's the AS's responsibility > (and also a big part of its value as a policy engine). > > Even in the cases - as I suggested - where the client would be able to > signal what it knows (or thinks it knows) about the subject, the AS still > needs to validate what it can. The client could be an attacker lying to t= he > AS. Or there could be an unintended bug. > > The client still seems like a straightforward source to gather > optional/declarative hints. Which is what request.user is already doing i= n > spirit. In many cases, the AS should go a step further. Validate > cryptographic statements from a more reputable issuer, whatever helps. > > Contacts might be one of the possibilities. I'm not suggesting > interact/fail scenarii at all, which I see as anti-ergonomic (composabili= ty > with timeouts and fallback is the answer to that). The failure I was > considering is only for async calls explicitly requested by the client > (which is considered in sequence 1.4.3, and not coming from me), there's > obviously no way to ensure a remote RO would actually respond when the > client expects it. If that sequence is considered, realistic failure mode= s > should be anticipated and dealt with internally (just like any distribute= d > program would do), is all I'm saying. And so from the outside, there's no > interact/fail. > That's the same as in real life: when booking a business trip, an employe= e > could either follow the generic rule (2nd class train ticket) or reach ou= t > to his manager, explaining that it's a long trip and that 1st class would > be better. The employee knows the manager might not instantly respond, an= d > knows that the absence of an answer means he'll have to go for the 2nd > class. > > There will be cases when the client doesn't know the RO. I'm not sure if > that's a majority of cases, but it will definitely happen. It could happe= n > when you interact with an organization or a team and have no idea who's > responsible or what delegations are in place (some of those cases have be= en > described by Adrian for instance). > There could also be cases where the ownership could be distributed (an > example was provided when considering remote ROs). Again in real life, it= 's > not unusual for a decision to fallback on a deputy when the main decision > maker is unavailable. Or there could be an open governance even, but mayb= e > that's one step too far. > > Of course, if the AS has internal knowledge or other ways to get the > information it should use it. Remains to be seen how we can specify that > (cf issue #49 on should/must). The example with doctor/patient is fine if > hardcoded, but it becomes a problem when we fail to understand the real > relationships in environments of various sensitive nature. How the AS > identifies that a specific record requires approval from Doctor Bob might > be context dependent (sometimes it could be a nurse, a team of doctors, > another medical organization, etc.). Maybe you could have various levels = of > authorizations (extreme example: military style classifications), so that > it might even be impossible to tell who can be contacted. > > That's also why I was suggesting assertions could go beyond authenticatio= n > events, and include cryptographic assertions for authorization purposes. > Maybe we can even imagine a risk based approach, as in some cases we won'= t > know for sure. > > The difficulty will be to be sufficiently generic but simple enough. Mayb= e > we can rule out some cases. Maybe remote async contacts are out of > scope, because we only want instantaneous authorizations. Most of those > cases are way beyond what OAuth2 does. I don't know. But what's certain i= s > that the WG should decide what support for cases where end-user !=3D RO i= t > intends to provide. My discussion was just a very small Chesterston's Fen= ce > contribution, even if that seems to have surprised. > > Fabien > > > On Wed, Mar 10, 2021 at 8:18 PM Justin Richer wrote: > >> Hi Fabien, >> >> First, thanks for doing the heavy lift of writing this topic up. Of thes= e >> options, I would strongly prefer option (1). The difference between >> assertions and identifiers is that an assertion is a fully packaged set = of >> attributes, one of which can be an identifier. They are, generally >> speaking, cryptographically protected bundles. They=E2=80=99re designed = to carry a >> bunch of different information about a user and the authentication event= in >> a form that=E2=80=99s independently verifiable and auditable. SAML asser= tions (XML >> document) and ID Tokens (signed JWTs) are the most common ones we see >> today, but other formats exist and will keep being invented. >> >> An identifier is a different kind of creature. It is a single statement >> that identifies the party in question in the context of the party doing = the >> identification. It=E2=80=99s this full context that the receiver of the = identifier >> needs to interpret it in. When using a federated identity protocol, each= RP >> is going to have :some: kind of local user information store that they= =E2=80=99re >> going to tie into, some field in a database they=E2=80=99ll key off of. = It=E2=80=99s just >> never going to be the case that all RPs will be able to use server-provi= ded >> opaque identifiers for all cases. Account recovery and binding is one su= ch >> use case where a user-facing identifier like an email address makes a LO= T >> of sense, for one small example. This is an array in the request and >> response precisely because a user could be known by several different >> identifiers to a party, and an RP will have a better idea about what kin= ds >> of things it wants to correlate against, and it=E2=80=99s up to the AS t= o provide >> that mapping. I think that if we don=E2=80=99t define a way to describe = the format, >> the =E2=80=9Cas_id=E2=80=9D field is going to get structure back-patched= onto it like is >> being proposed here: >> >> https://mattrglobal.github.io/oidc-portable-identities/ >> >> I=E2=80=99m personally not a fan of that approach as it mixes the data l= ayering >> too much, and you end up making guesses about whether a field is meaning= ful >> or a pointer. I think GNAP will be much better served by using a data >> structure for this from the start. DIDs should be another =E2=80=9Cforma= t=E2=80=9D of the >> subject identifier. I don=E2=80=99t think GNAP should define this format= , and I=E2=80=99ve >> dropped a note to the SECEVENT mailing list asking about adding DIDs to = the >> subject identifiers draft before it gets published. DIDs are not >> assertions, even in the cases where they point to fully functional DID >> documents with user information in them. (And for what it=E2=80=99s wort= h, I think >> the OIDC world should also use the SECEVENT draft inside ID Tokens to so= lve >> the use case of the draft above). >> >> For the user !=3D RO cases, I think that potentially having a way to sig= nal >> those two items separately in the request and response could be useful. >> Right now all the user/subject stuff is about identifying =E2=80=9Cthe u= ser that=E2=80=99s >> currently here at the client instance=E2=80=9D, in a variety of forms th= at the >> client instance and AS can negotiate. If the client or AS has some other >> notion about who the RO is and how that could be separate from the curre= nt >> user, we could provide a way to signal that like you=E2=80=99re proposin= g below. In >> my mental model, there are going to be a lot of use cases where the =E2= =80=9CRO=E2=80=9D >> isn=E2=80=99t known to the client at all, but rather to the AS and is ba= sed on what >> the client=E2=80=99s asking for. So I could identify the current user an= d ask for a >> specific medical record, and the AS realizes it has to go bug a particul= ar >> doctor to approve things directly. This is instead of interacting with t= he >> current user and failing in an awkward way when the current user doesn= =E2=80=99t >> have the rights to do things, but someone else would. But we=E2=80=99d w= ant the >> system to be able to detect if the current user is the doctor, so we can >> just interact with them directly. Does that all track? >> >> =E2=80=94 Justin >> >> On Mar 10, 2021, at 4:10 AM, Fabien Imbault >> wrote: >> >> Hello, >> >> Notice the question mark in the title. Not to be considered as an >> editor's comment. >> This thread intends to provide a detailed comment on the >> interesting feedback by Kristina: "I would catch up on the thread to >> understand why DIDs are thought to be treated as assertions". >> In the chat, I answered: "Happy to get the discussion on DIDs. Actually, >> could be either or, depending on what we intend to do." Let me expand a = bit >> on that, to make it understandable (didn't have the time during the >> meeting, unfortunately). >> >> This relates to the items described on slides 20 and 34, which I'll >> explain further. I'll highlight as transparently as possible what I thin= k >> would be the benefits and downsides of each. Both are probably viable >> options, but they correspond to different scopes and objectives. I'll sp= end >> a bit more time on option 2, since it is a different approach compared t= o >> the current draft. >> >> *1. The first possibility is to use SECEVENT throughout. * >> In that case, DIDs should be a part of sub_ids (in the core or in the >> extension registry, depending on what Annabelle's WG decides). More >> generally, the WG would have to decide which additional sub_ids it needs >> (as per Yaron's comment). >> >> That's obviously the closest to what is described in draft-04. It allows >> a communication of subject information between the client and the AS, by >> using global identifiers (mail, phone, etc.), or using a local opaque >> reference - i.e. governed by the AS (that's probably what we would put i= n >> the examples, unless someone has a better idea - cf issues #16 and #42). >> >> Assertions relate for instance to the proof of presence of the RO. The >> current draft-04 therefore plans for id_tokens and saml2, maybe there co= uld >> be other needs later (extension registry). >> >> - Benefits: identifiers are a key component of GNAP, which makes >> integration easier. Possibly one could choose to use DIDs throughout. >> - Downsides: email/phone identifiers will probably be used throughout by >> most devs (since that's correlation information they have in their user >> DB). Which means we should limit what assertions contain, to avoid doing >> links between weak global identifiers and hopefully stronger assertions. >> That's not really a problem if it's limited to authentication events mos= tly >> (in that perspective, samlv2 could make sense in the core). An assertion= is >> probably a single value then (not an array). >> >> Option 1 can be summarized as: >> >> "subject": { >> "sub_ids": { }, // request and response (SECEVENT -> including DID >> possibly) >> "assertions": [ ], // request and response (id_token or >> samlv2) >> } >> ("hints" do not exist currently, but are partially covered separately vi= a >> "request.user" / the relevance of "principal", discussed in the slide, i= s a >> question mark too - which is a different discussion on end-user !=3D RO)= . >> >> >> *2. An alternate possibility is to use SECEVENT only as input/hint* >> In that case, DIDs should be a part of assertions (which have a differen= t >> meaning compared to option 1). >> >> The AS only returns an local opaque reference as_ref (while in option 1, >> it was only one of many possibilities). Its only job is to help the clie= nt >> differentiate the response subject. The AS policy might further define t= he >> scope of that reference, as suggested in >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210, although >> I personally viewed that by default as (2) "as_id" an identifier locally >> unique to that AS for all the RSs. >> >> SECEVENTS are still useful as an input, that's what I presented in >> request.hints.self.sub_ids (but it's the responsibility of the AS to mat= ch >> it with its own reference system - from instance from the email to AS's >> local record XUT2MFM1XBIKJKSDU8Q). Note: since the slides, a new >> draft-ietf-secevent-subject-identifiers-07 has been published. Notably t= his >> includes an opaque identifier, which the client can use to pass the as_r= ef >> hint to the AS. Thus we wouldn't need any further addition to >> SECEVENT, although hints would benefit from further additions (like DIDs >> for instance). Notice also that subject_types_supported becomes less >> important, because in the worst case scenario, it's simply a hint that >> wouldn't be understood and therefore taken into account by the AS. >> >> The assertions array has a more important role than in option 1 (with th= e >> explicit aim of separating between client hints and validated info asser= ted >> by the AS). It serves as a generic/extendible mapping structure, e.g. "t= he >> AS asserts that opaque reference XUT2MFM1XBIKJKSDU8Q is matching with >> these (more or less verifiable) statements." The name assertion therefor= e >> corresponds to the responsibility of the AS in delivering those statemen= ts >> (cf should/must, issue #49). Some of these statements relate to identity= or >> auth events (ex: DID, id_token), some might directly be useful for >> authorization decisions (like ZKP example in the parental control exampl= e). >> Possibly some of these validated assertions could be reused in next >> interactions. >> >> Another question that popped-up is the scope of sub_ids. Should they be >> about the same user? (I think so). In the case of remote ROs especially,= it >> might be important that DID be considered as an assertion (about someone >> else's) and not as sub_ids, because the AS needs to be careful about who >> the client wants to reach (avoid spam, etc.). This is consistent with th= e >> rest of discussion on what to do when end-user !=3D RO, although using >> DIDComm might seem a bit early (the paint is very fresh). >> >> Option 2 was summarized as: >> >> // (suggestion only, not as an editor) >> "subject": { >> "as_ref": { // response only (wouldn=E2=80=99t require SECEVENT) >> =E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1.as.com=E2=80=9D, >> =E2=80=9Cref=E2=80=9D: =E2=80=9CXUT2MFM1XBIKJKSDU8QM=E2=80=9D >> }, >> "assertions": [ ], // request and response >> (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validated by the = AS) >> >> "hints": { // request only (optional) >> "self": { // replaces request.user (support SECEVENT here) >> =E2=80=9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque in draf= t-07 - that >> could contain the ref) >> =E2=80=9Cassertions=E2=80=9D: [ ] // see examples: VC on DOB or ZKP o= n age (wider >> scope, possibly through extensions) >> }, >> "principal": { // new proposal presented at IETF110 (just an idea) >> =E2=80=9Cautomated=E2=80=9D: true, // rule engine >> =E2=80=9Casync=E2=80=9D: { } // remote ROs >> } >> } >> } >> >> - Benefits: as_ref is self supporting (no strong coupling with SECEVENT)= , >> but can still take SECEVENT as an input hint for the AS. It avoids the r= isk >> of making an official association between a weak global identifier (e.g. >> email, used elsewhere) and hopefully stronger local assertions. GNAP wou= ld >> be fully agnostic to whatever identity system is used, only facilitating >> interoperability through assertions (second only in importance compared = to >> the AS opaque reference). Some assertions (possibly extensions) could al= so >> be useful for the AS decision (e.g. VC or ZKP). >> - Downsides: opaqueness of as_ref is a feature, not a bug. The opaque >> reference is fully managed by the AS, therefore not inherently portable = (cf >> portability discussions in OIDC currently). There's no explicit binding = to >> an official identity, only a contextual mapping to AS validated assertio= ns. >> It makes it more difficult to match the identifiers from one AS to anoth= er >> or to correlate with the client user DB (still possible via assertions, = if >> the AS allows it). Assertions are much more generic (possibly via >> extensions), but might require a more advanced mechanism to >> request/response only the most relevant information (which makes the AS >> policy critical here). >> >> I hope that clarifies the reasoning for both options. Again I'm not >> saying option 2 is better, just saying the trade-offs are different (+ >> knowing that we need to keep it simple). >> - option 1 puts more in sub_ids and less in assertions >> - option 2 puts less in the reference and more in assertions >> All of this is open to discussion. More generally speaking, on every par= t >> in orange and question mark (?) I would love your ideas and criticisms. >> What I intended as an editor is only to highlight where the WG has >> important choices to make, before we can make the related PRs. >> >> A further side comment: IETF EAT RATS was suggested for assertions, but >> relates more to the client attestations. It was added as a comment in >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, which is a >> distinct topic we'll work on. >> >> Fabien (editor's hat off) >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> --00000000000028f1c605bd66c629 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Justin,=C2=A0

    A last word on end-user! =3DRO (again just as food for thou= ght).=C2=A0

    As soon as h= ints.automated is set to true, it takes priority over async, which means it= 's the same model as the one you describe : the AS has precedence over = any other remote contact.=C2=A0

    So that confirms the global view that the AS is the one with the = authority, and that it might know more than the client.=C2=A0

    Cheers
    Fabien= =C2=A0

    <= div dir=3D"ltr" class=3D"gmail_attr">Le jeu. 11 mars 2021 =C3=A0 11:44, Fab= ien Imbault <fabien.imbault@= gmail.com> a =C3=A9crit=C2=A0:
    Hi Justin,

    I think that's intere= sting:
    "For the user !=3D RO cases, I think that potent= ially having a way to signal those two items separately in the request and = response could be useful. Right now all the user/subject stuff is about ide= ntifying =E2=80=9Cthe user that=E2=80=99s currently here at the client inst= ance=E2=80=9D, in a variety of forms that the client instance and AS can ne= gotiate. If the client or AS has some other notion about who the RO is and = how that could be separate from the current user, we could provide a way to= signal that like you=E2=80=99re proposing below. In my mental model, there= are going to be a lot of use cases where the =E2=80=9CRO=E2=80=9D isn=E2= =80=99t known to the client at all, but rather to the AS and is based on wh= at the client=E2=80=99s asking for. So I could identify the current user an= d ask for a specific medical record, and the AS realizes it has to go bug a= particular doctor to approve things directly. This is instead of interacti= ng with the current user and failing in an awkward way when the current use= r doesn=E2=80=99t have the rights to do things, but someone else would. But= we=E2=80=99d want the system to be able to detect if the current user is t= he doctor, so we can just interact with them directly. Does that all track?= "

    I agree with the general idea. In the end, = that's the AS's responsibility (and also a big part of its value as= a policy engine). =C2=A0

    Even in the cases - as I= suggested - where the client would be able to signal what it knows (or thi= nks it knows) about the subject, the AS still needs to validate what it can= . The client could be an attacker lying to the AS. Or there could be an uni= ntended bug.=C2=A0

    The=C2=A0client still seems lik= e a straightforward source to gather optional/declarative hints. Which is w= hat request.user is already doing in spirit. In many cases, the AS should g= o a step further. Validate cryptographic statements from a more reputable i= ssuer, whatever helps.

    Contacts might be one of th= e possibilities. I'm not suggesting interact/fail scenarii at all, whic= h I see as anti-ergonomic (composability with timeouts and fallback is the = answer to that). The failure I was considering is only for async calls expl= icitly requested by the client (which is considered in sequence 1.4.3, and = not coming from me), there's obviously no way to ensure a remote RO wou= ld actually respond when the client expects it. If that sequence is conside= red, realistic failure modes should be anticipated and dealt with internall= y (just like any distributed program would do), is all I'm saying. And = so from the outside, there's no interact/fail.=C2=A0=C2=A0
    Th= at's the same as in real life: when booking a business trip, an employe= e could either follow the generic rule (2nd class train ticket) or reach ou= t to his manager, explaining that it's a long trip and that 1st class w= ould be better. The employee knows the manager might not instantly respond,= and knows that the absence of an answer means he'll have to go for the= 2nd class.=C2=A0

    There will be cases when the= =C2=A0client doesn't know the=C2=A0RO. I'm not sure if that's a= majority of cases, but it will definitely happen. It could happen when you= interact with an organization or a team and have no idea who's respons= ible or what delegations are in place (some of those cases have been descri= bed by Adrian for instance).=C2=A0
    There could also be cases wher= e the ownership could be distributed (an example was provided when consider= ing remote ROs). Again in real life, it's not unusual for a decision to= fallback on a deputy when the main decision maker is unavailable. Or there= could be an open governance even, but maybe that's one step too far.

    Of course, if the AS has internal knowledge or othe= r ways to get the information it should use it. Remains to be seen how we c= an specify that (cf issue #49 on should/must). The example with doctor/pati= ent is fine if hardcoded, but it becomes a problem when we fail to understa= nd the real relationships in environments of various sensitive nature. How = the AS identifies that a specific record requires approval from Doctor Bob = might be context dependent (sometimes it could be a nurse, a team of doctor= s, another medical organization, etc.). Maybe you could have various levels= of authorizations (extreme example: military style classifications), so th= at it might even be impossible to tell who can be contacted.=C2=A0

    That's also why I was suggesting assertions could go b= eyond authentication events, and include cryptographic assertions for autho= rization purposes. Maybe we can even imagine a risk based approach, as in s= ome cases we won't know for sure.=C2=A0

    The di= fficulty will be to be sufficiently generic but simple enough. Maybe we can= rule out some cases. Maybe remote async contacts are out of scope,=C2=A0be= cause we only want instantaneous authorizations. Most of those cases are wa= y beyond what OAuth2 does. I don't know. But what's certain is that= the WG should decide what support for cases where end-user !=3D RO it inte= nds to provide. My discussion was just a very small Chesterston's Fence= contribution, even if that seems to have surprised.

    Fabien

    On Wed, = Mar 10, 2021 at 8:18 PM Justin Richer <jricher@mit.edu> wrote:
    Hi Fabien,
    <= br>
    First, thanks for doing the heavy lift of writing this topic = up. Of these options, I would strongly prefer option (1). The difference be= tween assertions and identifiers is that an assertion is a fully packaged s= et of attributes, one of which can be an identifier. They are, generally sp= eaking, cryptographically protected bundles. They=E2=80=99re designed to ca= rry a bunch of different information about a user and the authentication ev= ent in a form that=E2=80=99s independently verifiable and auditable. SAML a= ssertions (XML document) and ID Tokens (signed JWTs) are the most common on= es we see today, but other formats exist and will keep being invented.=C2= =A0

    An identifier is a different kind of creature.= It is a single statement that identifies the party in question in the cont= ext of the party doing the identification. It=E2=80=99s this full context t= hat the receiver of the identifier needs to interpret it in. When using a f= ederated identity protocol, each RP is going to have :some: kind of local u= ser information store that they=E2=80=99re going to tie into, some field in= a database they=E2=80=99ll key off of. It=E2=80=99s just never going to be= the case that all RPs will be able to use server-provided opaque identifie= rs for all cases. Account recovery and binding is one such use case where a= user-facing identifier like an email address makes a LOT of sense, for one= small example. This is an array in the request and response precisely beca= use a user could be known by several different identifiers to a party, and = an RP will have a better idea about what kinds of things it wants to correl= ate against, and it=E2=80=99s up to the AS to provide that mapping. I think= that if we don=E2=80=99t define a way to describe the format, the =E2=80= =9Cas_id=E2=80=9D field is going to get structure back-patched onto it like= is being proposed here:

    =
    I=E2=80=99m personally not a fan of that approach as it mixe= s the data layering too much, and you end up making guesses about whether a= field is meaningful or a pointer. I think GNAP will be much better served = by using a data structure for this from the start. DIDs should be another = =E2=80=9Cformat=E2=80=9D of the subject identifier. I don=E2=80=99t think G= NAP should define this format, and I=E2=80=99ve dropped a note to the SECEV= ENT mailing list asking about adding DIDs to the subject identifiers draft = before it gets published. DIDs are not assertions, even in the cases where = they point to fully functional DID documents with user information in them.= (And for what it=E2=80=99s worth, I think the OIDC world should also use t= he SECEVENT draft inside ID Tokens to solve the use case of the draft above= ).

    For the user !=3D RO cases, I think that potent= ially having a way to signal those two items separately in the request and = response could be useful. Right now all the user/subject stuff is about ide= ntifying =E2=80=9Cthe user that=E2=80=99s currently here at the client inst= ance=E2=80=9D, in a variety of forms that the client instance and AS can ne= gotiate. If the client or AS has some other notion about who the RO is and = how that could be separate from the current user, we could provide a way to= signal that like you=E2=80=99re proposing below. In my mental model, there= are going to be a lot of use cases where the =E2=80=9CRO=E2=80=9D isn=E2= =80=99t known to the client at all, but rather to the AS and is based on wh= at the client=E2=80=99s asking for. So I could identify the current user an= d ask for a specific medical record, and the AS realizes it has to go bug a= particular doctor to approve things directly. This is instead of interacti= ng with the current user and failing in an awkward way when the current use= r doesn=E2=80=99t have the rights to do things, but someone else would. But= we=E2=80=99d want the system to be able to detect if the current user is t= he doctor, so we can just interact with them directly. Does that all track?=

    =C2=A0=E2=80=94 Justin

    On Mar 10, 2021, at 4:10 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    H= ello,

    Notice the question mark in the title. Not to be c= onsidered as an editor's comment.
    This thread intends to prov= ide a detailed comment on the interesting=C2=A0feedback by Kristina: "= I would catch up on the thread to understand why DIDs are thought to be tre= ated as assertions".
    In the chat, I answered: "Happy to= get the discussion on DIDs. Actually, could be either or, depending on wha= t we intend to do." Let me expand a bit on that, to make it understand= able (didn't have the time during the meeting, unfortunately).

    This relates to the items described on slides 20 and 34, w= hich I'll explain further. I'll highlight as transparently as possi= ble what I think would be the benefits and downsides of each. Both are prob= ably viable options, but they correspond to different scopes and objectives= . I'll spend a bit more time on option 2, since it is a different appro= ach compared to the current draft.

    1. The first possibility is t= o use SECEVENT throughout.=C2=A0
    In that case, DIDs should be= a part of sub_ids (in the core or in the extension registry, depending on = what Annabelle's WG decides). More generally, the WG would have to deci= de which additional sub_ids it needs (as per Yaron's comment).

    That's obviously the closest to what is described in d= raft-04. It allows a communication of subject information between the clien= t and the AS, by using global identifiers (mail, phone, etc.), or using a l= ocal opaque reference=C2=A0- i.e. governed by the AS (that's probably w= hat we would=C2=A0put in the examples, unless someone has a better idea - c= f issues #16 and #42).=C2=A0

    Assertions relate for= instance to the proof of presence of the RO. The current draft-04 therefor= e plans for id_tokens and saml2, maybe there could be other needs later (ex= tension registry).

    - Benefits: identifiers are a k= ey component of GNAP, which makes integration easier. Possibly one could ch= oose to use DIDs throughout.
    - Downsides: email/phone identifiers= will probably be used throughout by most devs (since that's correlatio= n information they=C2=A0have in their user DB). Which means we should limit= what assertions contain, to avoid doing links between weak global identifi= ers and hopefully stronger assertions. That's not really a problem if i= t's limited to authentication events mostly (in that perspective, samlv= 2 could make sense in the core). An assertion is probably a single value th= en (not an array).=C2=A0 =C2=A0

    Option 1 can = be summarized as:=C2=A0

    "subject": {
    =C2=A0=C2=A0=C2=A0"sub_i= ds": { }, // request and response (SECEVENT= -> including DID possibly)=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=C2= =A0=C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0"assertions": [ ], =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request and response (= id_token or samlv2)
    }
    ("hints" do not exist cur= rently, but are partially covered separately via "request.user" /= the relevance of "principal", discussed in the slide, is a quest= ion mark too - which is a different discussion on end-user !=3D RO).
    <= div style=3D"line-height:1.2;margin-top:0pt;margin-bottom:0pt">

    2. An alternate possibility is to u= se SECEVENT only as input/hint
    In that case, DIDs should be a= part of assertions (which have a different meaning compared to option 1).<= /div>

    The AS only returns an local opaque reference as_r= ef (while in option 1, it was only one of many possibilities). Its only job= is to help the client differentiate the response subject. The AS policy mi= ght further define the scope of that reference, as suggested in=C2=A0https://github.com/ietf-wg-gnap/gnap-core-pr= otocol/issues/210, although I personally=C2=A0viewed that by default as= =C2=A0(2) "as_id" an identifier locally unique to that AS for all= the RSs.

    SECEVENTS are still useful as an input, = that's what I presented in request.hints.self.sub_ids (but it's the= responsibility=C2=A0of the AS to match it with its own reference system - = from instance from the email to AS's local record XUT2MFM1XBIKJKSDU8Q).= =C2=A0Note: since the slides, a new draft-ietf-secevent-subject-identifiers= -07 has been published. Notably this includes an opaque identifier, which t= he client can use to pass the as_ref hint to the AS. Thus we wouldn't n= eed any further addition to SECEVENT,=C2=A0although hints would benefit fro= m further additions (like DIDs for instance). Notice also that subject_type= s_supported becomes less important, because in the worst case scenario, it&= #39;s simply=C2=A0a hint that wouldn't be understood and therefore take= n into account by the AS.

    The assertions array has= a more important role than in option 1 (with the explicit aim of separatin= g between client hints and validated info asserted by the AS). It serves as= a generic/extendible mapping structure, e.g. "the AS asserts that opa= que reference=C2=A0XUT2MFM1XBIKJKSDU8Q=C2=A0is matching with these (more or l= ess verifiable) statements." The name assertion therefore corresponds = to the responsibility=C2=A0of the AS in delivering those statements (cf sho= uld/must, issue #49). Some of these statements relate to identity or auth e= vents (ex: DID, id_token), some might directly be useful for authorization = decisions (like ZKP example in the parental control example). Possibly some= of these validated assertions could be reused in next interactions.
    <= div>
    Another question that popped-up is the scope of sub_ids.= Should they be about the same user? (I think so). In the case of remote RO= s especially, it might be important that DID be considered as an assertion= =C2=A0(about someone else's) and not as sub_ids, because the AS needs t= o be careful about who the client wants to reach (avoid spam, etc.). This i= s consistent with the rest of discussion on what to do when end-user !=3D R= O, although using DIDComm might seem a bit early (the paint is very fresh).= =C2=A0

    Option 2 was summarized as:=C2=A0

    // = (suggestion only, not as an editor)
    "subject": {=
    =C2=A0=C2=A0=C2=A0"as_ref": { <= /span> // response only (wouldn=E2=80=99t requir= e SECEVENT)
    =E2=80=9Cas=E2=80=9D: =E2=80=9Chttps://ex1= .as.com=E2=80=9D,
    =E2=80=9Cref=E2=80=9D: =E2= =80=9CXU= T2MFM1XBIKJKSDU8QM=E2=80=9D=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=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"asserti= ons": [ ], =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // req= uest and response (id_token/jwkthumb/DID/VC/etc. -> whatever info can be= validated by the AS)

    =C2=A0=C2=A0=C2= =A0"hints": { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 // request only (optional)
    =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"self": { // replaces request.user (= support SECEVENT here)
    =C2=A0=C2=A0=C2=A0=E2=80= =9Csub_ids=E2=80=9D: { }, // SECEVENT (including opaque in draft-07 - that could cont= ain the ref)
    =C2=A0=C2=A0=C2=A0=E2=80=9Cassertio= ns=E2=80=9D: [ ] // see examples: VC on DOB or ZKP on age (wider= scope, possibly through extensions)
    },=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=C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0&= quot;principal": { // new proposal presente= d at IETF110 (just an idea)
    = = =C2=A0 =E2=80=9Cautomated=E2=80=9D: true, // rule engine
    =C2=A0 =E2=80=9Casync=E2=80=9D: { } // remote ROs
    }=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=C2=A0=C2=A0}
    }

    - Benefits: as_ref is self supporting (no strong coupling with SEC= EVENT), but can still take SECEVENT as an input hint for the AS. It avoids = the risk of making an official association between a weak global identifier= (e.g. email, used elsewhere) and hopefully stronger local assertions. GNAP= would be fully agnostic to whatever identity system is used, only facilita= ting interoperability through assertions (second only in importance=C2=A0co= mpared to the AS opaque reference). Some assertions (possibly extensions) c= ould also be useful for the AS decision (e.g. VC or ZKP).
    - Downs= ides: opaqueness of as_ref is a feature, not a bug. The opaque reference is= fully managed by the AS, therefore not inherently portable (cf portability= discussions in OIDC currently). There's no explicit binding to an offi= cial identity, only a contextual mapping to AS validated assertions. It mak= es it more difficult to match the identifiers from one AS to another or to = correlate with the client user DB (still possible via assertions, if the AS= allows it). Assertions are much more generic (possibly via extensions), bu= t might require a more advanced mechanism=C2=A0to request/response only the= most relevant information (which makes the AS policy critical here).
    =

    I hope that clarifies the=C2=A0reasoning for both optio= ns. Again I'm not saying option 2 is better, just saying the trade-offs= are different (+ knowing that we need to keep it simple).
    - opti= on 1 puts more in sub_ids and less in assertions
    - option 2 puts = less in the reference and more in assertions=C2=A0
    All of this is= open to discussion. More generally speaking, on every part in orange and q= uestion mark (?) I would love your ideas and criticisms. What I intended as= an editor is only to highlight where the WG has important choices to make,= before we can make the related PRs.

    A further sid= e comment: IETF EAT RATS was suggested for assertions, but relates more to = the client attestations. It was added as a comment in=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issue= s/44, which is a distinct topic we'll work on.

    =
    Fabien (editor's hat off)

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

    =