From nobody Sun May 2 00:42: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 406393A223D for ; Sun, 2 May 2021 00:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 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_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=UNzIEeV/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GcmF1Jaj Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vphzPl_Zn5D8 for ; Sun, 2 May 2021 00:42:44 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4B6E3A22B7 for ; Sun, 2 May 2021 00:42:25 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 357E25C0044 for ; Sun, 2 May 2021 03:42:21 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sun, 02 May 2021 03:42:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm2; bh=RDJu7HYOIdr ri+g6GtijPUcYJHUJm8XQgFVMZ2MmQFc=; b=UNzIEeV/+KbdFemyoGW9yMCMC1d Pvjc7SzunnGlYm7lTKsmuJO3iFJI0Vb8d6V92oFC9pTCDYSb3MaR4gyx+H0UMu8C O7R9A/XyVPQCHGXRC35T3m+Zbtl5t1ksl/x94wjyaV+1PtxdccEK06Q2wOMJQZIl 1sIBr0HniWdlS+IR2o5vOwrG7I6kgeFfuiKwVmh9BJYGMY3eb2r8qAnHWZZbJ0cY TwLPESJHy7mlZpxGI0B3netDzEf/Ad4WreTwPF7/lqxP1HVxlg3Rhg3BvyfkOdjG ct4/5/QCossrHupK0LnRkLF8RWLCMEFOYJq1KPVM7g+5NNLav5jwULM0UbA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:from:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=RDJu7HYOIdrri+g6GtijPUcYJHUJm8XQgFVMZ2MmQFc=; b=GcmF1Jaj e3VhPi/4dW3uiluxXRU1mQODNJlBgU/zaAU2jo5bo+h1DNPLdeCHj8dpKLozAn/W +/OwVfYt+h1KwySCKdbPzcAOAVjnyr3iMAbI8RSXctlfdchu3hfnuCLY3u6JXdko S2bsvRbakHn+w/e6TTYZtzeFl0oHztk4+l/xcVVLfyz6HNQp5Yi4lDfQitXpO4Re nFb2eiWzI95obssNWSQ/c7t2e1Zo6WeY4S/z2QaMO4XlBdcG3J4muLl8BmWnxvz4 ckJdgwqEIsdHgdPT6BuZvIGpxuVfmO4fTt9FoKp1oIF6S0kqJX8rYRf4+D6cG705 +7Hw0o53CSiuXg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdefuddggeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucfkphepudefrdekvddruddrudekleenucevlhhushhtvghrufhiiigvpedvnecu rfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvg ht X-ME-Proxy: Received: from fv-az201-515.ett4tu3jvdse5ovc2mkgjqcs5a.bx.internal.cloudapp.net (unknown [13.82.1.189]) by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 2 May 2021 03:42:20 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============4620797281156523158==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20210502074225.C4B6E3A22B7@ietfa.amsl.com> Date: Sun, 2 May 2021 00:42:25 -0700 (PDT) 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, 02 May 2021 07:42:49 -0000 --===============4620797281156523158== 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/-10/=F0=9F=92=AC3) 2 issues created: - REQUIRED vs OPTIONAL request/response elements (by tplooker) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/257=20 - Security consideration: warn about the potential for creating phishing = links (by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/255=20 2 issues received 3 new comments: - #257 REQUIRED vs OPTIONAL request/response elements (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/257=20 - #255 Security consideration: warn about the potential for creating phis= hing links (2 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/255=20 10 issues closed: - Be consistent with OAuth 2.0 (not OAuth 2) https://github.com/ietf-wg-g= nap/gnap-core-protocol/issues/248 [Editorial]=20 - Make sure prose and property names are consistent https://github.com/ie= tf-wg-gnap/gnap-core-protocol/issues/205 [Editorial]=20 - "Bad" use of Subject Identifiers https://github.com/ietf-wg-gnap/gnap-c= ore-protocol/issues/16=20 - subject identifiers as portable identifiers https://github.com/ietf-wg-= gnap/gnap-core-protocol/issues/171=20 - Proving Possession of a Key for the AS and RS https://github.com/ietf-w= g-gnap/gnap-core-protocol/issues/196=20 - Create verifier text https://github.com/ietf-wg-gnap/gnap-core-protocol= /issues/231=20 - Update HTTP Message Signature Formats https://github.com/ietf-wg-gnap/g= nap-core-protocol/issues/218=20 - Include body hash in Detached JWS https://github.com/ietf-wg-gnap/gnap-= core-protocol/issues/201=20 - Simplify access token hash https://github.com/ietf-wg-gnap/gnap-core-pr= otocol/issues/216=20 - Update "htu" claim name in JOSE methods https://github.com/ietf-wg-gnap= /gnap-core-protocol/issues/230=20 Pull requests ------------- * ietf-wg-gnap/core-protocol (+1/-3/=F0=9F=92=AC1) 1 pull requests submitted: - Release 05 (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/256 [Editorial]= =20 1 pull requests received 1 new comments: - #256 Release 05 (1 by netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/256 [Editorial]= =20 3 pull requests merged: - Release 05 https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/256 [Editorial]= =20 - Cryptographic Key Proofing Updates https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/250 [Pending Me= rge]=20 - clarify scope of spec in introduction https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/254 [Editorial]= =20 * ietf-wg-gnap/gnap-resource-servers (+1/-1/=F0=9F=92=AC1) 1 pull requests submitted: - clean up document for 00 release (by jricher) https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/1=20 1 pull requests received 1 new comments: - #1 clean up document for 00 release (1 by netlify) https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/1=20 1 pull requests merged: - clean up document for 00 release https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/1 [Editorial= ]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol * https://github.com/ietf-wg-gnap/gnap-resource-servers --===============4620797281156523158== 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 May 02, 2021

Events without label "editorial"

Issues

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

2 issues created:

2 issues received 3 new comments:

10 issues closed:

Pull requests

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

1 pull requests submitted:

1 pull requests received 1 new comments:

3 pull requests merged:

ietf-wg-gnap/gnap-resource-servers (+1/-1/=F0=9F=92=AC1)

1 pull requests submitted:

1 pull requests received 1 new comments:

1 pull requests merged:

Repositories tracked by this digest:

--===============4620797281156523158==-- From nobody Thu May 6 07:30: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 24E893A243A for ; Thu, 6 May 2021 07:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.4, 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 2bpjaSOCWcW6 for ; Thu, 6 May 2021 07:29:55 -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 0F7D33A2437 for ; Thu, 6 May 2021 07:29:54 -0700 (PDT) Received: from [192.168.1.11] ([90.26.94.159]) by mwinf5d67 with ME id 1SVq250053SJSnu03SVqow; Thu, 06 May 2021 16:29:53 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Thu, 06 May 2021 16:29:53 +0200 X-ME-IP: 90.26.94.159 To: "txauth@ietf.org" From: Denis Message-ID: <0536f389-ea4f-358c-7142-91d41fe8924a@free.fr> Date: Thu, 6 May 2021 16:29:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------22A20F4D6D1D5E47F0901CD5" Content-Language: en-GB Archived-At: Subject: [GNAP] Some remaining issues about the core-protocol 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, 06 May 2021 14:30:00 -0000 This is a multi-part message in MIME format. --------------22A20F4D6D1D5E47F0901CD5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello, The mailing list has been pretty silent these last days. Hereafter is a quick overview about some of the remaining issues classified by order of  importance (from my point of view). 1. User choice and consent, and user notice #215 smartopain wote: To draw a parallel: Since the publication of the EU GDPR (General Data Protection Regulation) the use of the cookies has changed. An end-user is allowed to accept them all, to deny them all (except functional cookies) and even to make some choices. The end-users can know which legal entity will collect the cookies and what for. The same kind of screens should be proposed to the end-user. *From a technical perspective, specific end-points should be defined and used, since this kind of dialog is done using APIs.*  I agree with smartopain. *2. Trust relationships **#214* There are still left undefined. AS-RS trust relationships are important. RO relationships with both ASs and RSs are veryimportant but unfortunately are discussed nowhere in the current draft (except in text proposals about this issue) *3. **Interaction (1) between the Client Instance and the RS as described in the first figure **#252* Still on the table but not progressing. 4. The first figure in section 1.4 should be split and revisited #192 This is still not done. 5. Unlinkability #241 Still on the table but not progressing. 6. Requesting User Information #197 This is still a hazy topic.  Denis --------------22A20F4D6D1D5E47F0901CD5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello,

The mailing list has been pretty silent these last days.

Hereafter is a quick overview about some of the remaining issues classified by order of  importance (from my point of view).

1. User choice and consent, and user notice #215

smartopain wote:

To draw a parallel: Since the publication of the EU GDPR (General Data Protection Regulation) the use of the cookies has changed.
An end-user is allowed to accept them all, to deny them all (except functional cookies) and even to make some choices.
The end-users can know which legal entity will collect the cookies and what for.

The same kind of screens should be proposed to the end-user.
From a technical perspective, specific end-points should be defined and used, since this kind of dialog is done using APIs.

 I agree with smartopain.

2. Trust relationships #214

There are still left undefined. AS-RS trust relationships are important. RO relationships with both ASs and RSs are very important
but unfortunately are discussed nowhere in the current draft (except in text proposals about this issue)

3. Interaction (1) between the Client Instance and the RS as described in the first figure #252

Still on the table but not progressing.

4. The first figure in section 1.4 should be split and revisited #192

This is still not done.

5. Unlinkability #241

Still on the table but not progressing.

6. Requesting User Information #197

This is still a hazy topic.


 Denis

--------------22A20F4D6D1D5E47F0901CD5-- From nobody Thu May 6 07:43: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 F11A23A24A4 for ; Thu, 6 May 2021 07:43:36 -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.4, NICE_REPLY_A=-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 1FbsTRAigWKF for ; Thu, 6 May 2021 07:43:35 -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 77FB23A24A2 for ; Thu, 6 May 2021 07:43:34 -0700 (PDT) Received: from [192.168.1.11] ([90.26.94.159]) by mwinf5d67 with ME id 1SjY2500G3SJSnu03SjYpN; Thu, 06 May 2021 16:43:32 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Thu, 06 May 2021 16:43:32 +0200 X-ME-IP: 90.26.94.159 To: txauth@ietf.org References: <0536f389-ea4f-358c-7142-91d41fe8924a@free.fr> From: Denis Message-ID: Date: Thu, 6 May 2021 16:43:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <0536f389-ea4f-358c-7142-91d41fe8924a@free.fr> Content-Type: multipart/alternative; boundary="------------CC4C7856F6591E6DCBAEE8A9" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Some remaining issues about the core-protocol 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, 06 May 2021 14:43:37 -0000 This is a multi-part message in MIME format. --------------CC4C7856F6591E6DCBAEE8A9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Quite strange, between the time I prepared my message and now, the following issue has disappeared: 5. Unlinkability #241 Is there a way to have a look at missing or closed issues ? Denis > Hello, > > The mailing list has been pretty silent these last days. > > Hereafter is a quick overview about some of the remaining issues > classified by order of  importance (from my point of view). > > > 1. User choice and consent, and user notice #215 > > smartopain wote: > > To draw a parallel: Since the publication of the EU GDPR (General Data > Protection Regulation) the use of the cookies has changed. > An end-user is allowed to accept them all, to deny them all (except > functional cookies) and even to make some choices. > The end-users can know which legal entity will collect the cookies and > what for. > > The same kind of screens should be proposed to the end-user. > *From a technical perspective, specific end-points should be defined > and used, since this kind of dialog is done using APIs.* > >  I agree with smartopain. > > *2. Trust relationships **#214* > > There are still left undefined. AS-RS trust relationships are > important. RO relationships with both ASs and RSs are veryimportant > but unfortunately are discussed nowhere in the current draft (except > in text proposals about this issue) > > *3. **Interaction (1) between the Client Instance and the RS as > described in the first figure **#252* > > Still on the table but not progressing. > > > 4. The first figure in section 1.4 should be split and revisited #192 > > This is still not done. > > > 5. Unlinkability #241 > > Still on the table but not progressing. > > > 6. Requesting User Information #197 > > This is still a hazy topic. > > >  Denis > > --------------CC4C7856F6591E6DCBAEE8A9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Quite strange, between the time I prepared my message and now, the following issue has disappeared:

5. Unlinkability #241

Is there a way to have a look at missing or closed issues ?

Denis

Hello,

The mailing list has been pretty silent these last days.

Hereafter is a quick overview about some of the remaining issues classified by order of  importance (from my point of view).

1. User choice and consent, and user notice #215

smartopain wote:

To draw a parallel: Since the publication of the EU GDPR (General Data Protection Regulation) the use of the cookies has changed.
An end-user is allowed to accept them all, to deny them all (except functional cookies) and even to make some choices.
The end-users can know which legal entity will collect the cookies and what for.

The same kind of screens should be proposed to the end-user.
From a technical perspective, specific end-points should be defined and used, since this kind of dialog is done using APIs.

 I agree with smartopain.

2. Trust relationships #214

There are still left undefined. AS-RS trust relationships are important. RO relationships with both ASs and RSs are very important
but unfortunately are discussed nowhere in the current draft (except in text proposals about this issue)

3. Interaction (1) between the Client Instance and the RS as described in the first figure #252

Still on the table but not progressing.

4. The first figure in section 1.4 should be split and revisited #192

This is still not done.

5. Unlinkability #241

Still on the table but not progressing.

6. Requesting User Information #197

This is still a hazy topic.


 Denis



--------------CC4C7856F6591E6DCBAEE8A9-- From nobody Thu May 6 07:47: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 3F28E3A24BC for ; Thu, 6 May 2021 07:47: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 TTNIPdmz51jy for ; Thu, 6 May 2021 07:47:31 -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 E3BAE3A24BD for ; Thu, 6 May 2021 07:47:30 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id b17so4972030ilh.6 for ; Thu, 06 May 2021 07:47:30 -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=pCy6QFHY2hHnJgxljOZZwk93UVR5aa/7aJO2WiKSt9s=; b=CaxBVb9biy/vPc6R+UcuGzT4HOelswqGPQaa3tf+AaqEDNOrccUTvghqH51qTZfPKF YxINnBEwVrwcsz3Okt8KOfufJeCaGudhw5E9F67ZFRneNIxo1xrbHVNKeA7ol3sEV7RI +lB3Gu5UP3pUwM9HuImJCfYjvS31zzcOp/3PjPO6Oys9lIp4bsgR0JqlvQR+yaQ4+ly9 JbuqgLqbXuaApWL6Q/cjxV0c4S0DZ9mXMPT0Nyxpbh+A4It+iOwvT+pCtOLMm1fGaPXx 2FC4DC6HmL40oGn5XiGSxOGHPjNI5OLJIE+b3bJURi7UfccqI0KCleqFhG6ZnNBvOSiL heQg== 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=pCy6QFHY2hHnJgxljOZZwk93UVR5aa/7aJO2WiKSt9s=; b=QH2WPa+FR3fZ6ckkrKgJqNMwnQrFfR/VHy6HjEElvwmOh+Jk3MyyJQsTlWly1NGPp7 IBvHCNcsNaQIHCnUezK3j9tVsk6g2AjgDdZxHxW1m6/6V3c6q77sKrdbtvJUHn43I4H0 K+wjDjqGdMzDfg+XMmJzjPhZhqSyFOLBWR4UtA9jUp1RXA0MjbermL5pJztb/L/YWF51 dC2VFg+CoU7ke0Q7GvmwTcTYX++3tdhnsEigcmWHKu/rg1AD2OEvsv1mwXoxfx+mSwVb DWVJQKJ3MHRJMZJvCcnqnwVSAJdCKxLjgLhYCMEY4AM0wn2ifU8arJIcmqu4deHzPupK iVJA== X-Gm-Message-State: AOAM532yIY/Vn+F9DB8D8hfh27a7ixkkjxnHCHSHMmMKBzIxI36hgdK1 Icu1hXxamzDh0qmQyVf3ybWYVc8IWvtomE9aOwU= X-Google-Smtp-Source: ABdhPJzZRB5BpJfZTSQgC38yywmHsz00R7Kl2J36ksA219hiW4jEpt7um6NkB1FOOMLotR1inW+8hWyt/a67Q/Fv8Bc= X-Received: by 2002:a92:de4c:: with SMTP id e12mr4822014ilr.178.1620312449455; Thu, 06 May 2021 07:47:29 -0700 (PDT) MIME-Version: 1.0 References: <0536f389-ea4f-358c-7142-91d41fe8924a@free.fr> In-Reply-To: From: Fabien Imbault Date: Thu, 6 May 2021 16:47:18 +0200 Message-ID: To: Denis Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000f99c5805c1aa630a" Archived-At: Subject: Re: [GNAP] Some remaining issues about the core-protocol 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, 06 May 2021 14:47:35 -0000 --000000000000f99c5805c1aa630a Content-Type: text/plain; charset="UTF-8" Hi Denis This specific issue was pending close 22 days ago and then closed 15 days ago (which follows the editorial process). Best Fabien On Thu, May 6, 2021 at 4:43 PM Denis wrote: > Quite strange, between the time I prepared my message and now, the > following issue has disappeared: > 5. Unlinkability #241 > > Is there a way to have a look at missing or closed issues ? > > Denis > > Hello, > > The mailing list has been pretty silent these last days. > > Hereafter is a quick overview about some of the remaining issues > classified by order of importance (from my point of view). > > 1. User choice and consent, and user notice #215 > > smartopain wote: > > To draw a parallel: Since the publication of the EU GDPR (General Data > Protection Regulation) the use of the cookies has changed. > An end-user is allowed to accept them all, to deny them all (except > functional cookies) and even to make some choices. > The end-users can know which legal entity will collect the cookies and > what for. > > The same kind of screens should be proposed to the end-user. > *From a technical perspective, specific end-points should be defined and > used, since this kind of dialog is done using APIs.* > > I agree with smartopain. > > *2. Trust relationships **#214* > > There are still left undefined. AS-RS trust relationships are important. > RO relationships with both ASs and RSs are very important > but unfortunately are discussed nowhere in the current draft (except in > text proposals about this issue) > > *3. **Interaction (1) between the Client Instance and the RS as described > in the first figure **#252* > > Still on the table but not progressing. > 4. The first figure in section 1.4 should be split and revisited #192 > > This is still not done. > 5. Unlinkability #241 > > Still on the table but not progressing. > 6. Requesting User Information #197 > > This is still a hazy topic. > > > Denis > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000f99c5805c1aa630a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Denis
This specific issue was pending close 2= 2 days ago and then closed 15 days ago (which follows the editorial process= ).
Best
Fabien

On Thu, May 6, 2021 at 4:43 PM Denis <= denis.ietf@free.fr> wrote:
=
=20 =20 =20
Quite strange, between the time I prepared my message and now, the following issue has disappeared:

5. Unlinkability #241

Is there a way to have a look at missing or closed issues ?

Denis

=20

Hello,

The mailing list has been pretty silent these last days.

Hereafter is a quick overview about some of the remaining issues classified by order of=C2=A0 importance (from my point of view).

1. User choice and consent, and user notice #215

smartopain wote:

To draw a parallel: Since the publication of the EU GDPR (General Data Protection Regulation) the use of the cookies has changed.
An end-user is allowed to accept them all, to deny them all (except functional cookies) and even to make some choices.
The end-users can know which legal entity will collect the cookies and what for.

The same kind of screens should be proposed to the end-user.
From a technical perspective, specific end-points should be defined and used, since this kind of dialog is done using APIs.

=C2=A0I agree with smartopain.

2. Trust relationships= #214

There are still left undefined. AS-RS trust relationships are important. RO relationships with both ASs and RSs are very important
but unfortunately are discussed nowhere in the current draft (except in text proposals about this issue)

3. Interaction (1) between the Clien= t Instance and the RS as described in the first figure <= /b>#252

Still on the table but not progressing.

4. The first figure in section 1.4 should be split and revisited #192

This is still not done.

5. Unlinkability #241

Still on the table but not progressing.

6. Requesting User Information <= span>#197

This is still a hazy topic.


=C2=A0Denis



--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000f99c5805c1aa630a-- From nobody Thu May 6 07:48: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 6EBFB3A24CE for ; Thu, 6 May 2021 07:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki.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 T9sYHoZwKgwo for ; Thu, 6 May 2021 07:48:44 -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 95E1F3A24E2 for ; Thu, 6 May 2021 07:48:44 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id f6so5055645iow.2 for ; Thu, 06 May 2021 07:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=opW+76T7Kq6oBYAqtZZZJE/xy6dw1hj8Iefew5Ju3ZQ=; b=Vrpgda6jzBMlm4To5TFCGMK3pKxf/e9gkxvkZWncGCSBgK1JMSIlDSHEMhGSu8TBh3 attXGvarADwb/EAA5IBSyKhK6/1Fh+ixum1m1GH8F5P0NkFrtIKQAdIuoDeZtJQ/ufSE QFsb6lIohuYrz0ckqua/wbGyIfsOBurakvchXdy4EmfDR5kMRl/jQvYSBmW//T8onhDz 8G5TBgkTSnxVCHFO04wpnMWGsc6J3VP1xRrovnBNvhhnRgRzNj6/uQOqEzWI7DzcDp4p qXUmt9Kmp87rd3pC0tpX+TBAgg6CQtbDX+CHSWR+VevO6pWjaQWehEvh/iWywAUeD8VH 7CHg== 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=opW+76T7Kq6oBYAqtZZZJE/xy6dw1hj8Iefew5Ju3ZQ=; b=px4E1r7LCYIjqJFKXfzatNeRflyVUj+gGWbjXQMf4dJClkdM8QtyV6kNLNvnT+tiYP buCqj+6VMMCc/GyOFC16KO6IXBMiqZjwDBsSnRM6AaR2jQn3QTOwbfNu2xSuAWNL/QWQ d1U/FFXG5FQTK6M2VN3WDBH6dQAVoxfJpNFgaG4vqfcoBYIkAajzkkr9mt36/uRwWhsU uJP225KqxDOBB99InlCQgB5WHujxTWQgSVkwb4RIJoJHKNnZLt7Z4yfFLycRx9GlsmmK 1e8ECU0ba3r0l/TMeA6CUyI8JuoJjn3Zi9FoAdE7JYrG4k7oAUDx5QRAgUpFgMlVahLT mpXw== X-Gm-Message-State: AOAM530Til6uog7PEuiajTqU5amgekAlNyRtovL3zFtirOu+JBAA155I YcGnzq3cLncvD4U8cFTrQywZ88VaxPeFVQ== X-Google-Smtp-Source: ABdhPJxOgumNASlMQEnNLTImnMXWbYuQ0KNbV+h3OUTvF8DEwz1vTM1uqlGwao+UDz8nYkUK+mFHdg== X-Received: by 2002:a05:6602:718:: with SMTP id f24mr3489850iox.59.1620312522126; Thu, 06 May 2021 07:48:42 -0700 (PDT) Received: from mail-io1-f45.google.com (mail-io1-f45.google.com. [209.85.166.45]) by smtp.gmail.com with ESMTPSA id k17sm1047166ioa.44.2021.05.06.07.48.41 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 May 2021 07:48:41 -0700 (PDT) Received: by mail-io1-f45.google.com with SMTP id l21so5050544iob.1 for ; Thu, 06 May 2021 07:48:41 -0700 (PDT) X-Received: by 2002:a6b:6013:: with SMTP id r19mr3619756iog.208.1620312521262; Thu, 06 May 2021 07:48:41 -0700 (PDT) MIME-Version: 1.0 References: <0536f389-ea4f-358c-7142-91d41fe8924a@free.fr> In-Reply-To: From: Aaron Parecki Date: Thu, 6 May 2021 07:48:30 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Denis Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000414efa05c1aa6877" Archived-At: Subject: Re: [GNAP] Some remaining issues about the core-protocol 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, 06 May 2021 14:48:49 -0000 --000000000000414efa05c1aa6877 Content-Type: text/plain; charset="UTF-8" This issue? https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/241 On Thu, May 6, 2021 at 7:43 AM Denis wrote: > Quite strange, between the time I prepared my message and now, the > following issue has disappeared: > 5. Unlinkability #241 > > Is there a way to have a look at missing or closed issues ? > > Denis > > Hello, > > The mailing list has been pretty silent these last days. > > Hereafter is a quick overview about some of the remaining issues > classified by order of importance (from my point of view). > > 1. User choice and consent, and user notice #215 > > smartopain wote: > > To draw a parallel: Since the publication of the EU GDPR (General Data > Protection Regulation) the use of the cookies has changed. > An end-user is allowed to accept them all, to deny them all (except > functional cookies) and even to make some choices. > The end-users can know which legal entity will collect the cookies and > what for. > > The same kind of screens should be proposed to the end-user. > *From a technical perspective, specific end-points should be defined and > used, since this kind of dialog is done using APIs.* > > I agree with smartopain. > > *2. Trust relationships **#214* > > There are still left undefined. AS-RS trust relationships are important. > RO relationships with both ASs and RSs are very important > but unfortunately are discussed nowhere in the current draft (except in > text proposals about this issue) > > *3. **Interaction (1) between the Client Instance and the RS as described > in the first figure **#252* > > Still on the table but not progressing. > 4. The first figure in section 1.4 should be split and revisited #192 > > This is still not done. > 5. Unlinkability #241 > > Still on the table but not progressing. > 6. Requesting User Information #197 > > This is still a hazy topic. > > > Denis > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000414efa05c1aa6877 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, May 6= , 2021 at 7:43 AM Denis <denis.iet= f@free.fr> wrote:
=20 =20 =20
Quite strange, between the time I prepared my message and now, the following issue has disappeared:

5. Unlinkability #241

Is there a way to have a look at missing or closed issues ?

Denis

=20

Hello,

The mailing list has been pretty silent these last days.

Hereafter is a quick overview about some of the remaining issues classified by order of=C2=A0 importance (from my point of view).

1. User choice and consent, and user notice #215

smartopain wote:

To draw a parallel: Since the publication of the EU GDPR (General Data Protection Regulation) the use of the cookies has changed.
An end-user is allowed to accept them all, to deny them all (except functional cookies) and even to make some choices.
The end-users can know which legal entity will collect the cookies and what for.

The same kind of screens should be proposed to the end-user.
From a technical perspective, specific end-points should be defined and used, since this kind of dialog is done using APIs.

=C2=A0I agree with smartopain.

2. Trust relationships= #214

There are still left undefined. AS-RS trust relationships are important. RO relationships with both ASs and RSs are very important
but unfortunately are discussed nowhere in the current draft (except in text proposals about this issue)

3. Interaction (1) between the Clien= t Instance and the RS as described in the first figure <= /b>#252

Still on the table but not progressing.

4. The first figure in section 1.4 should be split and revisited #192

This is still not done.

5. Unlinkability #241

Still on the table but not progressing.

6. Requesting User Information <= span>#197

This is still a hazy topic.


=C2=A0Denis



--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000414efa05c1aa6877-- From nobody Thu May 6 07:53: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 3D2BD3A24F9 for ; Thu, 6 May 2021 07:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.4, 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 X3a0InKv8IdJ for ; Thu, 6 May 2021 07:53:40 -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 46BB63A24F4 for ; Thu, 6 May 2021 07:53:39 -0700 (PDT) Received: from [192.168.1.11] ([90.26.94.159]) by mwinf5d67 with ME id 1Stc2500U3SJSnu03StdNU; Thu, 06 May 2021 16:53:37 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Thu, 06 May 2021 16:53:37 +0200 X-ME-IP: 90.26.94.159 To: Aaron Parecki Cc: GNAP Mailing List References: <0536f389-ea4f-358c-7142-91d41fe8924a@free.fr> From: Denis Message-ID: <69399062-01a3-28b2-d992-c53ba6f10bf2@free.fr> Date: Thu, 6 May 2021 16:53:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0A42BBD538E0450963C4A3FC" Content-Language: fr Archived-At: Subject: Re: [GNAP] Some remaining issues about the core-protocol 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, 06 May 2021 14:53:44 -0000 This is a multi-part message in MIME format. --------------0A42BBD538E0450963C4A3FC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thank you Aaron, The issue was pending closed but has been reopened by Justin. However, when I list all issues, this is what I can see: Issue 241 does not appear. This is still strange. Denis > This issue? > > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/241 > > > > On Thu, May 6, 2021 at 7:43 AM Denis > wrote: > > Quite strange, between the time I prepared my message and now, the > following issue has disappeared: > > > 5. Unlinkability #241 > > Is there a way to have a look at missing or closed issues ? > > Denis > >> Hello, >> >> The mailing list has been pretty silent these last days. >> >> Hereafter is a quick overview about some of the remaining issues >> classified by order of  importance (from my point of view). >> >> >> 1. User choice and consent, and user notice #215 >> >> smartopain wote: >> >> To draw a parallel: Since the publication of the EU GDPR (General >> Data Protection Regulation) the use of the cookies has changed. >> An end-user is allowed to accept them all, to deny them all >> (except functional cookies) and even to make some choices. >> The end-users can know which legal entity will collect the >> cookies and what for. >> >> The same kind of screens should be proposed to the end-user. >> *From a technical perspective, specific end-points should be >> defined and used, since this kind of dialog is done using APIs.* >> >>  I agree with smartopain. >> >> *2. Trust relationships **#214* >> >> There are still left undefined. AS-RS trust relationships are >> important. RO relationships with both ASs and RSs are veryimportant >> but unfortunately are discussed nowhere in the current draft >> (except in text proposals about this issue) >> >> *3. **Interaction (1) between the Client Instance and the RS as >> described in the first figure **#252* >> >> Still on the table but not progressing. >> >> >> 4. The first figure in section 1.4 should be split and >> revisited #192 >> >> This is still not done. >> >> >> 5. Unlinkability #241 >> >> Still on the table but not progressing. >> >> >> 6. Requesting User Information #197 >> >> This is still a hazy topic. >> >> >>  Denis >> >> > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > --------------0A42BBD538E0450963C4A3FC Content-Type: multipart/related; boundary="------------8404BEBA7B8EF9467AF73F89" --------------8404BEBA7B8EF9467AF73F89 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Thank you Aaron,

The issue was pending closed but has been reopened by Justin.

However, when I list all issues, this is what I can see:

Issue 241 does not appear.

This is still strange.

Denis


On Thu, May 6, 2021 at 7:43 AM Denis <denis.ietf@free.fr> wrote:
Quite strange, between the time I prepared my message and now, the following issue has disappeared:

5. Unlinkability #241

Is there a way to have a look at missing or closed issues ?

Denis

Hello,

The mailing list has been pretty silent these last days.

Hereafter is a quick overview about some of the remaining issues classified by order of  importance (from my point of view).

1. User choice and consent, and user notice #215

smartopain wote:

To draw a parallel: Since the publication of the EU GDPR (General Data Protection Regulation) the use of the cookies has changed.
An end-user is allowed to accept them all, to deny them all (except functional cookies) and even to make some choices.
The end-users can know which legal entity will collect the cookies and what for.

The same kind of screens should be proposed to the end-user.
From a technical perspective, specific end-points should be defined and used, since this kind of dialog is done using APIs.

 I agree with smartopain.

2. Trust relationships #214

There are still left undefined. AS-RS trust relationships are important. RO relationships with both ASs and RSs are very important
but unfortunately are discussed nowhere in the current draft (except in text proposals about this issue)

3. Interaction (1) between the Client Instance and the RS as described in the first figure #252

Still on the table but not progressing.

4. The first figure in section 1.4 should be split and revisited #192

This is still not done.

5. Unlinkability #241

Still on the table but not progressing.

6. Requesting User Information #197

This is still a hazy topic.


 Denis



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


--------------8404BEBA7B8EF9467AF73F89 Content-Type: image/png; name="kdeacaelngpkogkb.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="kdeacaelngpkogkb.png" iVBORw0KGgoAAAANSUhEUgAAAYQAAAEICAYAAABfz4NwAAAgAElEQVR4nO2d61NU15r/57+Y qnlp9Zt+0111iioLfRGqUtFS8ovESk7wnBxCnIQYEipmPGI85mIwUpLogBI4XprEGBMjEMFL jwNRk8CgklaM1zgniqMIJN4geITpqX3q+3ux1969L2vt3g3d0K3fT9WuxN173dd+vms9z+rm nwDg+s1fQAgh5NHmnwAKAiGEEAoCIYQQgSkIt+6M8OLFixevR/jiDoEQQggAuowIIYQIKAiE EEIAUBAIIYQIKAiEEEIAUBAIIYQIKAiEEEIAUBAIIYQIKAiEEEIAUBAIIYQIKAiEEEIAUBAI IYQIMiYIA6NDWPdNHQojL2BW9RzMqp6DwsgLWPdNHQZGh9JeHiGEkKmREUGo6qw1RaCsZRXq uiKo64qgrGWVeX/dN3VpLZMQQsjUSLsgLIyUYFb1HNR1RfDbxJjr898mxlDXFTF3DIQQQrKD tAqCsTNoOXso6bMtZw9hVvUcVHXWpqXsZAwc/DfMzvs96k6PT0t5Oc94H+oW52P2G4cw4PHY QOsyBIIh1PROW80cDGL/GwUIL25ALBuGVhvFqR3LMW9uCIHgMjTfnOkKqYihJhhC4OV9nuP7 4HQDnsorwGsHB6etZqkxiOaXQwgEa3FyOopTvBfx/ijefX4+wsEQAhtjOdBvctImCAOjQ+bO wElVZ63U8Bs7Bb8xhZMbQwgELVfefDxZsQkd/fHk9csZQdAwcvUotlWWCaMSQiBYgHlL69B9 bxqrQUGYFHp/LMD67lFomSokPoyuHatRUlhgvguzC8vw2aVUMslmQTCMvHF5GfssEITxGGqe CCHw8h5cFabokRcEY3cgcxMV7y5H8e5y1/3fJsZS2iXogpBYdcXvnMcn5fkI5FXg66xdiaXC fZzZuhThYAFeqO/Btfv67NImbuFsaxM6srCN0ysI/Ti8djme/PN+TyM2c2jo2RBCIPgRejKl BtoNNIs5/8m5u4gDgDaBge4t2H06lYz8CUImuHfqM6xYugh1nnPGr6HPoCBc7cQ7Fc9geVsS o36jBX8KhvCnvTfSXYNpJ22CsDBSgrKWVdLPVIIAAGUtq3zHEpyCAAD4eReeDoZQsPVCijXO Pm4dfgvhYD7KWm9kbnWZZqZXEGbOiPljGlar57ejIBjC0zuvTDGjmetLf3MmCwShtxaBYAgv tiYRBL/P5QBpEwSVuwjwFgTDbeQHqSDc3IcXhd8OSEy29Xs78G5xgfm8bRKKlyq8rhsPLFnp z+Rjbdc4gEF8u8WyLc+bj+L39+En2wZIw8jFfXh36SLMNl07X+Bi/5d4LhhC4L3vbfk/6KpG OBjC6wdvS1p3AQ1PhBD445e4mrQn4hjqbsIKw2cZLMC8ik04cPl+4hFjkjYdRfP7pXgsT3/u mfc7cN1UGw2/Hnfks/4YdM+UxGDEr6Hjw9fMvOZVNGDP5pdcL7c2eslW5jybW894gT/CnsMf 4Jm5iTIenG/HOxXPiHQhzC5cjrrjt3RxFO2xXS/vw4DCIMSHe7CtstSW14aDl5EYPqN9n6Kz 9QMUP56vP1f8AaI3EnI8djmKDRXG+Objsee/wEXZkBjz0FW/VMcrim3L9OekBlMsgMLvfQ/3 XlxHanAd70mi/S04dbwB5WKehx9/LdHn1npZjZ02igvWPitcjg3fXIPVcavPgYTbU3dpOV1B IQ9hUIxr/1FsEP0TmLsI5fUt+PdS+fjXGeOWNx/FlV/i1KjRquRj73JPm31gfy9kz9X0Tq7f VLbL9xxMA9MiCKoYAjB1QdB+/CsKLB1vdGogrwJ7LLEF+0tyDbv+GEIgrxYnzZkvJuATf8UZ DQB+xFem20bDyPFazHeIyMDBf8PsYD7+sDWGO3EA8bs4u3M/Ykb+wSocM/3a4/huXT4CedX4 TubrFtvO5DsdDddbKxAOFmHtkZsY1wBt4ir2CDdCs2HMDAOaV4E9VyagIY6reysQDobw3O5r ek7nt2N+MITnGs5gRAO0iZvo3H1EGDGnINxGdKVwVVwchQYNIxd3oSzP8VKPxVBTGML8dUcx FAcQvybqZrQ7YRTC5S2mzxUAho/uQvO5WxjXLOmCJdjVbzwhW9W6DYd2Yx/K8vQ6DExogDaB n/dWOHZfIq9gPsr2XsW4BsT7W/T2GKJ8uwNv5oUQXnlQtMUYXxUyI5bieAWLUHPcK/5wGx2r deM9+1834YDhNrKQkiDk5eOpjT1i/hp9XoSG8/Z6JQzbfZzcWIRAYTU6h+OAOa+MhRSAm4fw 2twQwiXb0atnjDvnduHr0x7189OXxniU78KFUU03sDsrhMg6xz8fZTsv6fN69ARqCq2LLR9j L227Ja11Dsqem0S/SW1XynNwakyLy8iLspZVWBgp8fWsXRA0jN+KoaEkH4HCWpwUyyWjU51b auckvLq7BIFgPmp6xcQXL0zBx2cVL+MVfPJsCIEntuMcAIx3Y22eest96+AKBIIhvP2teEnG v8fbXvn73XYa5f7lqH2FKOof3hizrahtAiPqEFjZgXsAhtsqEAiGsOo/ZQbIMfHFyvTppsuW ZzWc+XiBpF9X4IBlE6Qd/wiBYAhvHh5B4kVfgk9+9m7qg2+rLOkkdQLgNhxCeIPvoNPWQeI5 cxEg8jLGU6Q99l4IgeBbiN4DcHoLwsEQnt52yWV05UiMWIrj5dxVStFGcaF1LZ4SYhxevBYH lIsfe3luQXAsUJwuWOe8FLtf2y5XO4H15rwy+l99wmqygvC3nUsQCC7B9suW2aqdxZYnJONv Lux0ru99CYHgAjSct7Tda+xlbbf2W6qCkLTfFLYr5Tk4NaYlqLwwUiKNE0wuqGy55i5Cyfv7 9NWCQDXZXPdvR/G6xUDrn1tXo3EM/bAPW2tWo+TZJZYTP2LiCbeTMpBkGALxguvGbQG2/KhY +/n1DYsJ4hYOx0T1M5lvd+G9QmMbuhrbjlzFiCZ/1hCP9cft9bf36y/4uty9hbZvudU+X230 Kjo//xjvVCzB4iLDvWJtgx9B6MMmhVDbFxRyH7rtGe1nfFZi2d63xvRVmhJJ26Y0Xt5oEzfR u1sIg2W3kZrLyNlP4n75fgxL6mXMA+n18j4MGK7P0hZcV9R7coJgzC1nwF4x/oo66mX6GHtJ 25X95kMQkvebol9SnoNTY1qOnS6MlEh3AZM7dup9ttu3IOA2DrxhuIjEpHojilvG8236du4P tUdxefgeRiZu2Cde0hfYWD1X4di4WH14xQeM1bulDlLSKQgAEL+Ly0easKJY+JDL94kYg/1Z f/2aiA+oT9koBGG8D5sKQwgUvo1dP1zH3bv3EXe1YZoFAdBP8PywL+G3tuxGfbUtg4JgoP28 S49ZbThhWdxMUhCMeWjsVBz1Mv3cx1UDnDxYPTlBUC0knPdF+R6CNBOCkLzfPPolpTk4NXLq i2npFYTEqr3hsP6yJLZzksnn3Jre68CbyQz4+e0oCOZjbds+vOncLrrQcG5rEQLBItT03lc/ ZpSrcEGYLim/k9kkjlN1C9zbauNZY+tq28EY7oFEv57busB7J6R6sSX1NdxuqQnCCKIrQ2qX kelK8GkUTDT80r7C4cLy0bYpjZeE8yfQ4zQGDiNud9EJhCvIJQgO14oRkzPiTK56iZ2s2rVq 9L/dbWhlsi6jWG0+XK5GYyfuGn91+TMhCMn7zU+/+JmDUyNjP12xubtJ+dMVm7ubMKt6ju/Y gUG6BcGYTE8/u8ThSzUm1TJ83h9XBK8MA56Psp3nzaBy79avLAEfPbgczstPMkEF5hnz3+OD Q3/DrxP61Infv47e3cb3EDSc2/F7V5By38oFCMx9Gx1GGT4m80BnE5qNoKQZ/H0bHffcz0K7 gIbCkC1IfadbD7Tb+vXmfj04ZwbP9O+LNH96THdBqATBeGE29GBEA+LDR7G20OkyEnGcvCoc M6eWJKh8vglPOYPK7W+hIFiAyk6jg3wYhdNfYVO33sfQRtGzURfsbcovgMmDypMfLwm9tQgU vm2OmzZxC10bHQsJ4Q41vygVH8bh9/RYj0sQgtbg6yVsf9nRv656DeJrEXhee2RYzJ27ONu6 C98MG/2vH1YIl+/CWSOo/MN283sSRmzouZ1XPILnsnE18m3BzxMaEL8r2m5/7sHpLWb5ujtZ w/hAD+qaf7S3PZkgSE90TTaonLzfpDYq5Tk4NTL+43avtK7C5u4mbO5uwiutiR+3m8xPVqRd EKDh5EZ9hWsG94xPfv0eG8QxwfDjpXi39aj+sthe9vv46eAm88ieHtM4YptkxirXecRViTaK Cwc3odziQw8//gxKKr/COVOwHOXmzUdxZRN6frW0wIcg3PuvOsu3XZ1HId0TX/v1BOqsR/4+ /BY9e939Gu8/ajkmpx85XPHlBdF+1db/Pn7a/RcRq9GPtPbs/8jVhrEfm/CSOLYXfuMQhhX5 uY/qrcY263FKP0bhaqtlHGR5OPFo26TGS8LYZRz4cDmeFH1gfFv/wMVRW7D/1+MNZj/NLlyO bQc/lbuMSiPYZ/7URj4eW+b45r+sXvFr6PhweSKuNneRY346+78A85Z+kPhipXYD0fefNz+r O6PqR+NKLMKc7dpw7AT2SER45PSXlmO++XisaDk2fO+105TZl/s4s8M4Zp2P1w7+Ik/rSxCS 95vURqU8B6dGRn/+uqqz1twxGDuCqs7aR+rnr+8dfiuJC4WQLOYh+tIVSQ7/QE5GEcHkwu04 Rz0gOYi+oMnHppR+FoPkKhSEjKFh5PRWPBdcgPXHPYLEhGQr8Wv4/GUuaB4lKAgZQfgZ5z6P dw/nzu8SEaJjnPnPx2PLGuyxDvJQQ0EghBACgIJACCFEQEEghBACgIJACCFEQEEghBACgIJA CCFEQEEghBACgIJACCFEQEEghBACgIJACCFEQEEghBACIBcFYTCK+vYhAH2ob+wTN4fQtuZV FJfqV33MkSYWQXFpFdrMX/DtQ32p8bz1frbTh3ppfVXtT9IvKZWR7Uyx3oNRVKrSe32WrvIJ yQJyThAG26t0w2YKA4BYNPEixiIoLo1Y/mrZENoaq2wvdKzxVVSKtIPtVSheE0VuvMcKo6Nq v2e/pFhG1jPT9Z7p8gmZOrkjCLGIudK1XS5j7ngxYxFUtkct9/pQbzOMufQi+6mr6hm/7cyl /rAy0/We6fIJmTq5IwgA9NW+LgCxRsVqdzCKSlMkhtC2JoKY7WV1CoLuVpG6UwajqCyVuVxE frHE58aOw53OKEukaU8IW/I09vt2YVNga7+P+0nKiDVaxLexT95fsYgQ5uQuKnd+PtqpHAcr qjHxqq8k/WDi/+sbq8RYOI29rJ2TnxOJcgiZWXJMEIy4QUIY7Dhe/lhEGB3rC60/Y76sYufh NjJ6nMG8b/MjixiEYVRcnzl3KEOJNIYRtLlwvNMYdRhsr0oS81CJm4fo+S7DUkezX0V1G0V6 x31vnAZYVQevcXC3QzomqvomqU/CoHvMH1X5KYyvOy9CZoYcEQT7iqxYsVqMNVpXnUNoW6Mw 0tbVWmPU8pyFwSgqHau2hCFxuwfMzxyr2cRK2JnG8m9VGteq3tstYW9/8vtmO73KsLnqZLus PtTbjHASAyfLz6sOnuNgxWNMVPVVpk82VrLV/CTGl24mkmXkiCDomAFlc4Vl/8xu9KwniTxO FKle8JQEwbICn7TBUNTBpyC42+9931cZtnoN2YRzsL0Kle1D5n9dZcp2Xar8MiII9l2RV33d 6TMhCH7SEDKz5JQgxBr1l8cUBvMDmU/YivdxTbWBcLoqrC4ASzqvz5R18HJRyOugdOeo2p+0 X5KUYU3vdNUMRlG5JoJ62e4KkBteZX6puoxUxlU1Jsnr61sQPF1GkxlfCgLJHnJKEOTI3Un2 FaT75ZQGdp3Ytvrul10PBkrKc7oIkrmMlGlgc7HIg8qq9vvpFyQpw5KHxJi6XFE2d5DMaHvk 59VO5ThYSTImsvpK0icXBOPfiqBySuNLQSDZxUMgCDMBX2RA5bpJA8pdwNTwrq/z9Bkhjx4U hElBQfA8xjpFYo2y75dMkWT19eVeI+ThhoIwKR5lQTDcPulsv9O9lc6VepL6mq6cR3U8CUlA QSCEEAKAgkAIIURAQSCEEAKAgkAIIURAQSCEEAKAgkAIIURAQSCEEAKAgkAIIURAQSCEEALA Igi37ozw4sWLF69H+OIOgRBCCAC6jAghhAgoCIQQQgBQEAghhAgoCIQQQgBQEAghhAgoCIQQ QgBQEAghhAgoCIQQQgBQEAghhAgoCIQQQgBQEAghhAgyJggDo0NY900dCiMvYFb1HMyqnoPC yAtY900dBkaH0l4eIYSQqZERQajqrDVFoKxlFeq6IqjriqCsZZV5f903dWktkxBCyNRIuyAs jJRgVvUc1HVF8NvEmOvz3ybGUNcVMXcMhBBCsoO0CoKxM2g5eyjpsy1nD2FW9RxUddampeyU 0UZxasdyzJsbQiC4DM03Z6Ya3gxi/xsFCC9uQGx8BqvRW4tAMIQXWwfTm+94H+oW52P2G4cw kN6cZ4BBNL8cQiBYi5MZLineH8W7z89HOBhCYGMsw6WRR4m0CcLA6JC5M3BS1VkrNfzGTsFv TOHkxhACQeuVj8eKlqOuexjxVOvbugyB4AKs7x6FlmLa6YOCkDtMkyCMx1DzRAiBl/fgaqqT npAkpE0QjN2BzE1UvLscxbvLXfd/mxhLaZegC0JiNa9NXMWe8nwEgvl48/DtFGqroWdDCIHg R+hJoxrcO/UZVixdhLre9OU53UjbkClBmDT9OLx2OZ788/4sEpJpEoQbLfhTMIQ/7b2RyVJI Gsklu5A2QVgYKUFZyyrpZypBAICyllW+YwlOQQBgGqvUts6ZeXn1XUcINTkw8Cqkbcg6QYih JhhC4OV9j54gZN1YkGTkkl1ImyCo3EWAtyAYbiM/yARBO/4RAsEQwrV9lifjGOpuQHlhgf7Z 46VY8fkZjGgAbu7Di0GH60kYlgfn2/FOxTN4LE+/P7twOeqO37K5lLTRS2h+v0zEHkKYXViG zy4ZxsB+mRNAG8WFg5vM+gTy5qO4sgk9vyZyNibN+r0deLe4QLTTbWTM5/afQF3FIswW+b20 4yysezObn3nuIpTXt+DfS70MlkcbDCPUdBTN75eK/inAM+934Lq9c3Ch9QMUP55v9t+Gb655 uPOcht3496fotOZT/AGiN0RBxgJAMn6e425J+2JTFNuW6X1T0+u/Twe+/xgrlorPg/l47PkP 0Hz5vqP/LP07dhkHPlxuzpXw46X47JKyM6CNXnI9v2LHCRjTxO0yVRuZyc9l41PRl0ViDuXN x5Prj+GeLW1iLsyr2ISO/sRIj12OYkOFta++wEU9JX493oQVxtwMFmCeJV87Rp9+hD2HP8Az c1MYawDx/qPYsCxR/5ck74DXItMqupNrbxK7kIVMiyCoYgjA1ARBG72ET8rzEcirQLNhMKDh emsFwnkV+OTiKDRoGDlei/nBEJ7bfU08I1/NDR/dheZztzCuAYhfE+6oEuzqFw/cPITX5oYQ LtmO3jtxAHHcObcLX5/WP5avBO7j5MYiBPIq8Mm5u4gDiN/pQU1hCIHCWpwcs6cN5FVgjznR 1IIQKKxF1504oI2iZ2MRAsF8rO0SgYbbHXgzL4Rw+S5cGNV0Q72zQryA3itYrx1CwOzTOK5+ oT+X6FPRzsJqdA7rfXN1bwXC1nq5UAhCMB9le69iXAPi/S0oywsh8McvcVWZDvA17qaYFKHm eCJ25KtPAfQ1N6Drf+4jDkAbPaGPYV41vhuXjdVtRFfmI5C3Gm3D7rniYiyGmkJ9zM4ac6tb r//8jbGEMPncIUxtLo8jVv97hINFqDyoj4M2cROdu4/o/S3qOn/dUQzFLfkbfWHMv5UHxed3 cXbnfsQAaOe362PSoBtvW74uEgY1XN5iiZn4GGuf74AvQZhCe4FHdIfg5TLyoqxlFRZGSnw9 K1shLfjgP3Bl1LIsGO/G2rwQCj4+a1kN3cCe0hACT2zHOQB+t/cPvq1CIBjCm4dHAIzju3X5 nieSpAPf/yWeC4bwdNNl++qstxZhy6Qz0j6984rlKbUg6HUS/LwLTwdDKNh6AQDwt51LEAgu wfbLlhK1s9jyxNQEIbwxlmjD+Pd4OxhCoHw/hi3tfP2gJZajncD6YAiBlR2KFaBCEMxxAoBx HHsvhEDwLUTvqdLB37gbgvDe93ggabNXn8rQ+3kBGs4D7rHqw6a8EALPRnDBR/D36u4S95hB w8mNjjk3SZdRSnNZjGXBxpitn+x1XYED1qEWO/U3D48Ap7cgHAzh6W2XXLvD4bYKBIIhrPpP P4c5jD5dgk9+ttz2MdbGO2BLJ3kH/AjCVNoLPKKC4BVUXhgpkcYJphRUjg+jc12RY3cAc3Bc bgXbykAuCNroVXR+/jHeqViCxcZW2ZwYF9DwRAiB0hZcV9RPNvDGC+CaDIbrSsQ+5JNGLQi2 52x5jSC6UhYw9yeC/mMIdqNstFN6KX39KpeR/Xn3Syt5zs+4K4xp8j7ViQ/H0Lz9I6xYugSL Dfefmc7Zvxr++/OlCZfdh/vQO6xShl/wdbl8bFx18ykIU5nL9w6/pbvQjstMtlFX+fVi6yCg /YzPSixuw9aYvnIGgNtdeK/QcKusxrYjV21uHjuKOZt0rI06Jn8HkgvCFNuLR1QQvI6dLoyU SHcBkzt2ahm8sRNY/0QIgcLtOOfwE3ufwpBMtPE+bCoMIVD4Nnb9cB13795H3DYxkgcys0MQ VIY/s4Jg+uGlRkRFGgXBz7hPRRBu7kdZXgjhki3o/O9h3B2dwHVbOln/ahgfiKH5w9eE77kI Nb334SbNgjDFuextwBJ+fc8TetoEBn7Yl/DhW9yjiN/F5SNNWFEs/P/l++yxKFdZjn5JOtb+ 34HkgjD19j6SggBk/otpssG7dXAFAsEQntt5Rd8+3uvAm8EQAm9EcUuZk2TCSF40I2/9nrHy tm8drUgH/vx2FHi4jAwXS/oEwXAzOLfZwsWTIUEw2mnfxicjjYLgZ9ynIAjuZzSc+XhBEkFI oP1yAK8H1e6zc1sXQO0yssw5P4Iw1bmcZCz1ui7Alh/9jLSGX9r1sm0uOQBAHKfq9Lx0t5sT RZ/6GOtYrewd0F1N1vyu733JVb7hXjP6b6rtfWQFAUj8dMXm7iblT1ds7m7CrOo5vmMHBlI1 1y6goTCEQF4Fvr4JAOOI1eoBwbKdl/TtqDaBge4GfHXGSCSZaMZLsKEHIxoQHz6KtYUh28Qw AmK2wN8P27FbBAqNiWSKEwDgNjpWFziCyjFsWRJCeHGTubNJnyBY6ykCcYZ7zYcgSNvgRxAw iK/L8xEIFmHtEfFFwfhdnG3dhW+GVaVNVhCu4JNnQwjkVeGYOcV8jPsUBMFwo7z4xTXEoWHk 4i492K0UhD7sru3BwIQGWIKe83f8JO+K20dQOdc5t/6KZ4P5eGrHhSRj4WDKc1kExINFWHvk pggqX8WBHSL4K3ZLiQMEQPzOeTR/ekyPJ53+Cpu69XSJAH0Rtl0CBjqb0Czeg0Rw9m10SINM KpFNPtbud+Auujb+HmGHIGg//tXWV9roJWx/2d5XU2kvoLIL2UnGf9zuldZV2NzdhM3dTXil NfHjdpP5yQqpIAAY+7YK4WAI4ZUd+opBG8Wpz1ebxxYDefPxZMUmfGumk020+/hp91/EEbwC zKtoQM/+j1wvn/14WQHmLf0AHUa+2g1E33/e/KzOMETaLfTssNRn7iKUfxjFTxa9TKcg6Ef7 GvCS7fhnDz73c05e1gZfggAgfg0dlmOTgbmLUFL5Fc4pv2U9WUEAxn5sMtsXfuOQ/mImG/ep uIy0Wzj2kTh2mDcfxe/vQ2eTl8uoH19Zjn06j5BKu/7XE9hWWWo7Krrh4GXb0Vd/MYR0zGX7 nA0//gzKP71gBpnj/UctafUjqyu+FJ9fbU0cVzViBeLI673/qkOJGX/Rj28euCxzo8n61NpZ yd5x+zsQfvw1bDh2Antk732rONIqjhJH97r7arLt1auisAtZSEZ//rqqs9bcMRg7gqrOWv78 9YwgVtVZ9WUuQqaT6fu9qVyFfyDnUeF2FK+n7OMn5GGCgpAMCsLDyM0j2LY7Zvqvx2+dN7/A 93VW/qorIdMBBSEZFISHkXun8bHFf6378pvQpTwHT8ijAAUhGRQEQgghACgIhBBCBBQEQggh ACgIhBBCBBQEQgghACgIhBBCBBQEQgghACgIhBBCBBQEQgghACgIhBBCBLknCINR1LcPAehD fWOfuDmEtjWvorhUv+pjjjSxCIpLq9Dm/MVg1f2spQ/10vqq2t+H+lLjvt92qsrIdtJQ71hE 76s1UQwORlE5qfzS3X+5Oh4kF8k5QRhsr9INnikMAGLRxAsTi6C4NIKEJgyhrbFK8nKr7mcz CuOgaH+s8VVUmn0U0Q3dZMvIeqZab108XYuJaa+HV365OjYkV8gdQTBWb87LZeQcL00sgsr2 qPtFUt3PavwYBOOZIbStsTw7GEUlBSGD6dOdjyy/XB0bkivkjiAA0Ff1ulGLNVp3ARZshm8I bWsiiLleJNV9SV6lKldMFdpiic/NlbgrnVFPkaY9IWzJ09jv+xIwa/vN3UKS1a9HGbFGi/g2 9sFwT9nyMncfSVx30vx8tFM5DlZUY+JVX2vaVx3jIjHElrzrY/pu1T2W3nND3n7nPJSJgL2O tr4jJE3kmCAYcYOEMNhxvPyxiHhx3LsG6X1nWVbjY/Mpi5fTMCquz5w7lKFEGuNFtrm2vNMY ddANkJcgOI2f1UArBNR3GZY6mv0nqtso0jvue+M0eqo6eI2Dux3SMVHVV1kfef2KbULrcMfZ xlI1N7zan0wQZM8Rkl5yRBDsK0/rZX2xY43WlZPVZWJ9kVT3HQxGUekwoglD4k5nfuZYzSZW cx4vvSqNy83jbRDc7XeIo0wUkpVhc9VZ+95hZOwAABvTSURBVM1iAG3Gz7HzcVVSkp9XHTzH wYrHmKjq65ner8FO9qyjvsr+pCCQmSdHBEHHDCibK2j7Z/bVqWOLbb6AqvvOwlIRBIvxlaRL 1MdLECZhrJO23xFcX6Nopy9jbE8/2F6FyvYh87+uushcO6r8MiIIdkH0qq88fboEQTU3vBYm FAQyM+SUIMQa9ZfBFAbzg2QnaFQvUqouI7tbwDQsXp8py3K7JORpfLhzpO33qr/PMqz5Ol0f g1FUromgXiYygNzwKvNL1WWkbod8TJLXN72CoKiHsv2y3RwFgUw/OSUIcuTuJPsKcjKCAIcr x20A6hur5OU5XUDJXEbKNLC5GORBZY/2+wrGepVhyVtiTO0uKjjcITKj7ZGfVzuV42AlyZjI 6itJn64dgrwe/tpf3BhRlm0GpRlUJhngIRCEmYArNUDlukkDyl3A1MhYfQl5SKAgTAoKgv/v NaROrFH2/ZIpksH6EvKwQEGYFI+yIBhuj3S23+n2SufuIBP1JeThhIJACCEEAAWBEEKIgIJA CCEEAAWBEEKIgIJACCEEAAWBEEKIgIJACCEEAAWBEEKIgIJACCEEgEUQbt0Z4cWLFy9ej/DF HQIhhBAAdBkRQggRUBAIIYQAoCAQQggRUBAIIYQAoCAQQggRUBAIIYQAoCAQQggRUBAIIYQA oCAQQggRUBAIIYQAoCAQQggRZEwQBkaHsO6bOhRGXsCs6jmYVT0HhZEXsO6bOgyMDqW9PEII IVMjI4JQ1VlrikBZyyrUdUVQ1xVBWcsq8/66b+rSWiYhhJCpkXZBWBgpwazqOajriuC3iTHX 579NjKGuK2LuGAghhGQHaRUEY2fQcvZQ0mdbzh7CrOo5qOqsTUvZjzy9tQgEQ3ixdVD/93gf 6hbnY/YbhzAwk/VIyiCaXw4hEKzFyYxWzD8PTjfgqbwCvHbQbxsIeThImyAMjA6ZOwMnVZ21 UsNv7BRSjylcw64/hhAIhlDw8Vloskfiw+jasRolhQUIBPVnZxeW4bNLyXM/uTFkptGvfDxW tBx13cOIS8rpbd2E8qL5CBvPPr8a22TPZhIKQtqgIJBHlbQJgrE7kLmJineXo3h3uev+bxNj k9sl9H+J54IhhPPyEcirxnfjjs+1G2guz0cgrwKfnLurG2ZtAgPdW7D7dPLsdUFYhuabIruJ q9hTno9AMB9vHr6deHAshk2L8xEofBvNjnL+kBfC/HXduC0rIBOkbIizpR4zKwj3Tn2GFUsX oa53BgonJMtImyAsjJSgrGWV9DOVIABAWcuqFGMJGs58vACBYBUOHqpCIJiPtV0ORTi/HQXB EJ7eeSWFfBM4BQGAaegCG2Pixn0ce08XneYb7j3K2PGPUOAUkExCQZgUA63LEAiGUENBICR9 gqByFwHegmC4jXyjxVCTF0Lgve/xYLwba/NCCLwRxS3rMz/vwtPBEMLvfQ/3fiU5MkHQjn+E QDCEcG2ffuPmPrzo5bLCBTQ8EULg2V34m6Ic0xgduYzm90vxWF4IgWABnnl/H36yVTyOoe4m rHjecEsVYF7FJhy4fD/xiMsQx1ATDCHw8j6Ly0jDyMV9eHfpIsw28ln6BS6KHVfgve/xwFLq g65qhIMhvH5QIWraKE59vhrPzDVcZR+guekdlyBoo5ds7ZtXsQkd/YZDTS4I8eEe1FWIeubN R3Hllzg1aunp+DUcsOXZgD2bX3IY90F8u8XiNsybj2Kzb41y7VdNr6wv9bZeOLgJ5da8KpvQ 82uiTsZ4rt9/wlb3l3acndQ8JGS6mRZBUMUQgNQFQTdSxq5gHN+ty0cguAIHbDbrNjpW6y/u 7H/dhAOGO8cnLpfR6CV8Um7fDTz4tgqBYAhvf+v0VxmM49h7IQSCbyF6T/6EYUACeRXYc2UC GjSMHK/F/GAI4ZUdQuQ0XG+tQDhYhLVHbmJcs7iwrLsTH4IwcPDfMDuYjz9sjeFOHED8Ls7u 3I+YGZOpwjGzOaJvZS45Ua9zW4sQCBZh7RE9XhIfPoq1hSF7PcZiqCkMYf66oxiKA4hfE3U3 8nULgnZjH8ry8lG28xJGNEAbPYGawhACf/wSVwEAtxFdKVyCF0f1fru4C2V5IYcg/Iiv6ntw 7X4csPbtum5T+KQ7BFdf3sfJjUU2F2T8To9ep8JanBxzjGdhLbruxAFtFD0bi+S7WEKykGlx GXlR1rIKCyMlPp++jQNvhGxGSuutRTgYwnO7r9kf1UZxoXUtnhJGIrx4LQ70+5MFd1A5hAUf /AeujLpXg16uBqnryYKRh9294hASYxf0l6P2VabYoYQ3xvQdSjJBMPKx7RgS3Dq4wi5w49/j ba8dkPjcWS8jH6MeV3eXuATb2G29eXgEbkEQQvTEX3HGUvD1vS8hEFyAhvMwd4BPN1221M1w JXqNyRV88mwIgSe245y440sQxA7KXl5i7hnPGXnp7RKIuhZsvaCqFCFZw7QElRdGSqRxgpSD yrejeN2xwjNdSArXjDZxE727hTBIVtTmZTGUNkMeH0bnuiJXrODe4beS7BA09GxwrrrtqERF v5+PTacBnN5iMzoJHAY/mSCIuMqf9t6QV8YQDOE20ndAC7DlR7lDzKiXKz9bPX7B1+VucTUu /RmnIPRhU546TU1vou/XH7fXzd2fcQz9sA9ba1aj5NklmDfXyCexG/EjCMNtFXKhEaJsxJWk eTmeISSbmZZjpwsjJdJdQKrHTvXVpspYeBgvANrPu3Q/+YYTCp9/AtfKfuwE1j8RQqBwO84Z icWqMWkMQbEiB9SC8LedSxAILsEnPyN9gpA02JsI1h8bF7sU00UjQZWf7b5h7D9Cj7LTnYIg 6l3aguuKFN5Cmrg/0FaBcDAff6g9isvD9zAyccPlnqIgEJIgh76YJrb7Ep+29uNfUWB1n5w/ gR7nRsVwcTgCpzJkrh7DFfLczitCAAw/9luISmKuY99WIRzMx9vf3nd/KDAMiD1o63CL3evA mxLXjCuonUwQjHycAXgr57ejIJiPtW378KZXMBkAhvejTNKfhmgb9Ti3dUESsXYKwgiiK0OS uFACw1VjP0VmuNoMgywJVmtnseWJ1AXBPLWmcBkZ/URBILlOxn66YnN3k/KnKzZ3N2FW9ZwU YgcWo291F5kfihfdMKK9tbbvBmgTt9C1UQ+A1vSqDbSB1PevXUBDoe52+trcOegB0/DiD9H5 P/f1wHX8Pq51b8Ef8vLxVG3M83RJIghZjc7hOIA4rra/hQKb8Gg4t+P3rqDyvpULEJj7NjoM o5k0qGwEgfNRtvO8GVTu3foVEqZKDy6H82SBeidCEINFqOm+izg0jF9pMQO7Zj1u7tfvmW0E 4nfOo/nTYxgGIDPcD05v0YO/5btwYVQDoGF8oAd1zT+6xmJPv95vQ0eqMd96UsgUlmX4vF8P 8F7YWSFOaVnKEocDEv0t60txSMEWVI5hy5IQwoubzF0jBYHkOhn/cbtXWldhc3cTNnc34ZXW xI/bpfZlNOM0UT5qeuUrTX0lKlZrY5dx4MPlePLxfPOI4JMVm3Dg4mhSdxGgDgbrq37rCSBI vhFdgHlL/X1T2TAgVV9E8a5xpHTu83i3VT9dk+A+fkpy5NHfsVNHPnMXoeT9IzaXlrETkgqv k7HLaH7/edvR0DNH3K6keP9RbDCOYQb1b4yv+PKCyF927FTDyOkvLcds9W+Kb/jecpT11xOo W2b02SKUf3gUXV/YDbL26/fYIPIIP16Kd1uPYrtr13ADUaMNwQLUnZH1JQDtFnp2rEaxMafm LkL5h1Hb8WAKAsl1Mvrz11WdteaOwdgRVHXW8uevBdn4pSg9YOsdj8lW9NiL+lQXIcQb/oGc GST7BEH44a3B85xBxF4cx1UJIf6hIMwg2SUIGkZOb8VzwQVYfzx5nGVmGUTHji/ROzABDXqM 6OxO/URRWRt/kI6QyUJBmEGyRxBEvGHu83j38A1fcZaZZQSxRkuMKIW4DSFEDQWBEEIIAAoC IYQQAQWBEEIIAAoCIYQQAQWBEEIIAAoCIYQQAQWBEEIIAAoCIYQQAQWBEEIIAAoCIYQQAQWB EEIIgFwUhMEo6tuHAPShvrFP3BxC25pXUVyqX/XmT88r7sci5j3789lOH+pLq5CZ329T9aEg FkGxsuw+1Je+imJzPOwMtld5pPVDGtptjPmaKAYHo6icVH7p7v9MjichqZNzgjDYXqUbK1MY AMSiiZcqFkFxaUT/K2CK+4ODlr/HYH0+68mgAVH1IQBgCG2NVR5GVK9X5RrZ50IsZlQQ9DpM XfgzKQgUBzLz5I4gOFb15rUmCvs7pHqxvO5TEDzLiUVQ2R71KFt/vr6xCpXtjj9+FIuguDGS BoM+wzuMtOYjy4+CQGae3BEEAPpKVReAWKPCiA9GUekSCfX9wfYqpasDg1FUSl1L4uWNJT63 GUJbOqOeIk17QtiSp7Hf9zTKyeqqKlfVbrOvhtC2JoKYp8EyPnOK6xDa1hj3E2ljjRZBN/s+ ISruHZuqv3U3l23lH4s4FgnGDsWaTmKILXnXxww3l7O/vMfdq12JfpOJgL2OyvlISIbJMUEw 4gYJYbAjMRDS+xZ/ufLlc7gZbH5n8QIbhsf1mXN1PZRIY5Rnc8t4pzHqoPbF+6irtFwZjr6K RURaP4KgG0VbPdZEMehr16bXUy5WHv1t1k9Ut1E2/smMsiVvsRM16+EaJ9W4e7UrmSDIniNk +skRQbAHPFUB4Vij3MCr7usfKgzkYBSVjvsJY+N+ec3PHCv1hOh4GAZVGteuRmE0Uqqrt+Gx 95Wxwk+WztGWNcYuTlEHm/svxfyl7bMYbNnu0LdRTvVZhwD5ahcFgWQvOSIIOmZA2VxB2z+T GX1PlxCA9BhZy6pakk5ejlMQFKI0jYLg7iuHK0MZHLbmKUQkZq27qq2TEBwznX3nVNk+ZP43 efp0CYJq3L3aRUEg2UtOCUKsUX9hTGEwP3D6jZPc9/WMzA1jdx2YxsfrM1t+3m4LeZrJuowU 7iiV4UnaVykYbKfbxfq5tRwvV5ukffL+Fv9eE0G99JRTsj5IVRAU9VC2S+KCoyCQLCWnBEGO 3J1UH/N738OfbnPluI2EHgCVnNt3uoCSuYyUaWBzQ/gPKvs1cMn60PpMqit4a786dxDGCTGr EU+ev7K/kcQtmOYdgrweqnbB7kqynbhSBNsZVCYzxEMgCDMBV3PZhjyYTAhJBQrCpKAgZBWq o8aEkJSgIEwKCkJ2YLhpOBaEpAMKAiGEEAAUBEIIIQIKAiGEEAAUBEIIIQIKAiGEEAAUBEII IQIKAiGEEAAUBEIIIQIKAiGEEAAWQbh1Z4QXL168eD3CF3cIhBBCANBlRAghREBBIIQQAoCC QAghREBBIIQQAoCCQAghREBBIIQQAoCCQAghREBBIIQQAoCCQHKA+FdH8Pel1fjtd0sx8i+L MPLP/+/hvP5lEX773VL8fWk14l8dmeluJ48gFASStcS/OqKLwEwb6hm6fvvdUgoDmVYoCCQr GV+9dcYNcrZc46u3zvRwkEeEjAnCwOgQ1n1Th8LIC5hVPQezquegMPIC1n1Th4HRobSXRx4e KAYUBTIzZEQQqjprTREoa1mFuq4I6roiKGtZZd5f901dWsskDwfxr47MuPHN1ovuI5Jp0i4I CyMlmFU9B3VdEfw2Meb6/LeJMdR1RcwdAyFWHuWYQbLrt98tnenhIQ85aRUEY2fQcvZQ0mdb zh7CrOo5qOqsTUvZOcd4H+oW52P2G4cw4PHYQOsyBIIh1PROR6UGsf+NAoQXNyA2brkdv4YD 75fisbwQAsFanPRZ91RJvjv4GP8HAEc/ltwfwv8+mQ7D6z+vB0fl7fjH9pUZEwXuEkgmSZsg DIwOmTsDJ1WdtVLDb+wU/MYUTm4MIRC0Xvl4rKgMK3YcxZVRLfHgzX140frcxlhq6aeDnBGE cZzcuACB4DJ83h8XtzIjCH9fWu3LWP+jH/i/P8+8IKSvfP/p/760Oo09ToidtAmCsTuQuYmK d5ejeHe56/5vE2Mp7RJ0g74MzTfFDW0CI//Tg7p/LUAg7/fY1Hs/8bAhCkIMUk6fJWROEPpx eO1yPPnn/UmM+g3sKQ0hUNqC6+mugoPk7iJhOP98AP/oP4D7j6Ag0G1EMknaBGFhpARlLauk n6kEAQDKWlb5jiW4DLqBdgN7Xg4hkFeFY4Ye+REEr/RZQuYEIYaaYAiBl/clEQS/z02d5F86 SxjOB0etrhmHQX3yAP5h5noKD/7Z//1/bD9gyWsl/rc/UT/7rsSHQXeVp+dn1vvPp4D+s7Dt TV3uMMf1L4sy0/mEII2CoHIXAd6CYLiN/KA06AAefFuFQDCENw+P6DdSEQRZegkPzrfjnYpn hC89hNmFy1F3/FbihR67jAMfLse8ufrn4cdL8dklVW4SQxu/ho4PXxP5F2BeRQP2bH7JJQja 6CU0mz79Asyr2IQOw52DQTS/HEIg+BHajjegvLBA1OU1bPtR7IB6ax2uM6MeRtpanFQ9tzEm rzviGOq2lleKFZ+fwYjROSKvF5ui2LZsPsISkUtFEPz9v250dQPsdT9h7O9vHwKM5/58KrmB VgqCV3mn8MD8b4o7DAoCySDTIgiqGAKQPkFwCUCKgiB73snw0V1oPncL4xqA+DXsKc9HIFiC Xf0AcBvRlfkI5K1G23AcQBx3zu3C16dVuTmNqpG+Ap9cHIUGDSMXd6FMiI9pPMdiqCkMYf66 oxiKW+qRV43vxoGEIIQwf2MP7sQBbfQEagpDlmdk5VvTCkFQPue8p+F6awXC1rofr8X8YAjP 7b6mJzHFpQg1x0chi9j4dhlZjKxusC33batywdGPve+r3E8iTfIgscSgq8oz6g3rjoMuI5Id TIvLyIuyllVYGCnx9exMC4IT+66iD5vyQgg8G8GFeNKkcBnVn3fh6WAITzddthhLDWc+XmAT hKu7SxAIrsCB24mctOMfWephGPW3EL2XeOZvO5cgEFyAhvOK8gFMWhDGu7E2L4SCj63uDxF7 eGI7zgEJQXjvezxQ9IjfoHLCcOoumP/7s9OIW9xBNgOtuJ8kHqHvGlJ0GanKm6IgMKhMMsm0 BJUXRkqkcYIpB5Wt3GjBn4IhFGy9oP87VUFwppegjV5F5+cf452KJVhcpLs9AsEQXmwdBKDh vz9fqt+buwjlH+5D77CXMtiN6nBbBQLBENYft6+d7TGEX/B1ufOkVOLS6yEz6rJYRBoF4fQW sy/cl939pNdRjr9jp6qVuNVlJFvVe9+Xuowsz93fPuSxU1C5jFTlTd5lxGOnJJNMy7HThZES 6S5gcsdO5Qb91sEVCAQXYMuPwqCmKAiu9E7G+7CpMIRA4dvY9cN13L17H3GXkdMwPhBDsxkH KEKN8uSS3aiqgsf2+4n4QI/ylOwMCILohz/tvaGqlC9BAJK5jeSG02XEne4aw1Wjui9W7IAj qGy5D9Vq38ugu8prtQWV728fAsTuxPxOg0fMgu4ikmly6otpSoMu/OrhcssRylQEQZbeicSg 6SIiN3LaLwfwejCEwMoO3HN9CqhW2U/vvGJ5Zhzfrcu3GfJzWxd4C9dMCMK9DrwZDCHwRhS3 FLXyKwj86QruDsjMkbGfrtjc3aT86YrN3U2YVT3Hd+zAQPY9gl/P7cNfFucjXLIdZ6zF+fwe gjK9k/PbURAMoWBDD0Y0ID58FGsLra6aPuyu7cHAhAZYgqrzd/ykyNBhVLULaCgMIZBXgT1X JqAhjjvdeh42Q35zvx5oLqxGp3BJxe+cR/OnxzAMwL8gXMEnzzqP2k42qDyOWG0RAsF8lO28 pJ8s0iYw0N2Ar86IJD4FAeCP28ku/rgdmQ4y/uN2r7SuwubuJmzubsIrrYkft5vMT1a4vmmc Nx9PVqzDZ0euJo43Av6/qaxKL+U+ftr9F3GkVD8S2rP/I4uR68dXliOp4cdLsWLHCfyqzNdt aLVfT6BOHMnU4xDfomev25UU7z+KDRWLMDtoHH8tw4ovL4hgrV9BAMZ+bMJLj+s7kPAbhzA8 aUEAoI3i1OerUSzy0/t2E741xDcFQQAoChQDMhNk9OevqzprzR2DsSOo6qzlz18TX/AP5PAP 5JDphX8gh2Q9/BOahEwPFARCCCEAKAiEEEIEFARCCCEAKAiEEEIEFARCCCEAKAiEEEIEFARC CCEAKAiEEEIEFARCCCEAKAiEEEIEFARCCCEAKAiEEEIEuScIg1HUtw8B6EN9Y5+4OYS2Na+i uFS/6s0/gaC6DyAWQXFpFdr8/RpzltCH+kzWWdonfagvNfpQVbZ4xhwPO4PtVVPs6zS0OxbR 27AmisHBKConlV+6+z/D40lIiuScIAy2V+mG3RQGALFo4qWKRVBcGkFMeV+IRGMkB1/GTBkQ dZ/EGl9FpdnPEd2gKupVuUZWN0NQZlIQ9DrYFgQzUg+v/CgOZObJHUEwVnjOy2WgVC+W834u voCZrrMz/yG0WY38YBSVHoJQ31iVEA+DWCQN4psOQUhHv1EQyMNN7ggCAGAIbY26QYo1il2A E5XRct338QIORlFZKnM5ibSxxOc2Q2hLZ9RTpGlPCFvyNPb7le1RdZ2T1VVVrg1Jn5g7K69V tpGuD/XWupuCYs831mgRdNPNlBAVW/s9+1vf2bhcga5xftXRdokhtuRdHzPcXM7+8h53r3bJ FyLWfpOlJWR6yTFBMOIGCWGwIzEQyvvJBMFhAG1+Z/ECG4bH9Zkl31jEYoQsL7vVtZUkjVEH tS/eR12l5cryceZvjcMkTxdrdNRjTRSDvnZtej3lYuXR37GIzYDayle2y12umbfYidrcZLZx Uo27V7uSCYLsOUKmnxwRBHtw2HpZX/5Yo3x1Jb+f5AUcjKLSYQATxsad1vzMsVJPrPg8DIMq jd9dTUp19Wq3zGVk6WOlmDjassbYxSnqYHP/+TGIHv0N666kD/UeLq3kRjnVZx0C5KtdFASS veSIIOiYAWVzBW3/TCYGqvvpFQSL4ZSkk5fnFARJmhkXBJULyCudeCZmrbuqrdb8Ji9Ug+16 7ML4r792pUMQVOPu1S4KAsleckoQYo36C2MKg/mB4vSL8lQMMDmXkd11YBofr8+U5flxl0zF ZaRwR6UsCKp8PdI53S7Wz61j4uVqk7RP3t/i32siqJeKVbI+SFUQFPVQtku2y6IgkOwkpwRB jtydVB9L4b5KNGyuHLeR0AOgku84OF1AyVxGyjSwuSH8B5X9GjiPPrQZN8V3OaDKcwhta6zC 4dxBGGVYjXhyoVL2N9TuwuR9kPoOQV4PVbtgdyXZTlwpgu0MKpMZ4iEQhJmAq7lsQx5MJoSk AgVhUlAQsgrl9yMIIalAQZgUFITswHDTcCwISQcUBEIIIQAoCIQQQgQUBEIIIQAoCIQQQgQU BEIIIQAoCIQQQgQUBEIIIQAoCIQQQgQUBEIIIQAsgnDrzggvXrx48XqEL+4QCCGEAKDLiBBC iICCQAghBAAFgRBCiICCQAghBAAFgRBCiOD/AxyUGVRENXIEAAAAAElFTkSuQmCC --------------8404BEBA7B8EF9467AF73F89-- --------------0A42BBD538E0450963C4A3FC-- From nobody Thu May 6 07:58: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 932363A2522 for ; Thu, 6 May 2021 07:58:23 -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.4, 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 bx6gdeoDhYhE for ; Thu, 6 May 2021 07:58:19 -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 35E9D3A251C for ; Thu, 6 May 2021 07:58: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 146EwDlw015122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 6 May 2021 10:58:14 -0400 From: Justin Richer Message-Id: <2D3BC282-158D-435A-ACDB-E7FFFDAF50AA@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_21F8E9E0-D469-48D6-B596-6A4AF87F5ED7" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\)) Date: Thu, 6 May 2021 10:58:13 -0400 In-Reply-To: <69399062-01a3-28b2-d992-c53ba6f10bf2@free.fr> Cc: Aaron Parecki , GNAP Mailing List To: Denis References: <0536f389-ea4f-358c-7142-91d41fe8924a@free.fr> <69399062-01a3-28b2-d992-c53ba6f10bf2@free.fr> X-Mailer: Apple Mail (2.3608.120.23.2.6) Archived-At: Subject: Re: [GNAP] Some remaining issues about the core-protocol 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, 06 May 2021 14:58:24 -0000 --Apple-Mail=_21F8E9E0-D469-48D6-B596-6A4AF87F5ED7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Denis, That issue was closed and was not re-opened by me (or anyone), and so it = remains closed. =E2=80=94 Justin > On May 6, 2021, at 10:53 AM, Denis wrote: >=20 > Thank you Aaron, >=20 > The issue was pending closed but has been reopened by Justin. >=20 > However, when I list all issues, this is what I can see: >=20 > > Issue 241 does not appear. >=20 > This is still strange. >=20 > Denis >=20 >> This issue? >>=20 >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/241 = >>=20 >>=20 >> On Thu, May 6, 2021 at 7:43 AM Denis > wrote: >> Quite strange, between the time I prepared my message and now, the = following issue has disappeared: >> 5. Unlinkability #241 >>=20 >> Is there a way to have a look at missing or closed issues ? >>=20 >> Denis >>=20 >>> Hello, >>>=20 >>> The mailing list has been pretty silent these last days. >>>=20 >>> Hereafter is a quick overview about some of the remaining issues = classified by order of importance (from my point of view). >>>=20 >>>=20 >>> 1. User choice and consent, and user notice #215 >>>=20 >>> smartopain wote: >>>=20 >>> To draw a parallel: Since the publication of the EU GDPR (General = Data Protection Regulation) the use of the cookies has changed.=20 >>> An end-user is allowed to accept them all, to deny them all (except = functional cookies) and even to make some choices.=20 >>> The end-users can know which legal entity will collect the cookies = and what for. >>>=20 >>> The same kind of screens should be proposed to the end-user.=20 >>> =46rom a technical perspective, specific end-points should be = defined and used, since this kind of dialog is done using APIs. >>>=20 >>> I agree with smartopain. >>>=20 >>> 2. Trust relationships #214 >>>=20 >>> There are still left undefined. AS-RS trust relationships are = important. RO relationships with both ASs and RSs are very important=20 >>> but unfortunately are discussed nowhere in the current draft (except = in text proposals about this issue) >>>=20 >>> 3. Interaction (1) between the Client Instance and the RS as = described in the first figure #252 >>>=20 >>> Still on the table but not progressing. >>>=20 >>> 4. The first figure in section 1.4 should be split and revisited = #192 >>>=20 >>> This is still not done. >>>=20 >>> 5. Unlinkability #241 >>>=20 >>> Still on the table but not progressing. >>>=20 >>> 6. Requesting User Information #197 >>>=20 >>> This is still a hazy topic. >>>=20 >>>=20 >>>=20 >>> Denis >>>=20 >>>=20 >>>=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=_21F8E9E0-D469-48D6-B596-6A4AF87F5ED7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Denis,

That issue = was closed and was not re-opened by me (or anyone), and so it remains = closed.

 =E2=80=94 Justin

On May = 6, 2021, at 10:53 AM, Denis <denis.ietf@free.fr> wrote:

=20
Thank you Aaron,

The issue was pending closed but has been reopened by Justin.

However, when I list all issues, this is what I can see:

<kdeacaelngpkogkb.png>
Issue 241 does not appear.

This is still strange.

Denis

=20
This issue?

https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/241


On Thu, May 6, 2021 at = 7:43 AM Denis <denis.ietf@free.fr> wrote:
Quite strange, between the time I prepared = my message and now, the following issue has disappeared:

5. Unlinkability #241

Is there a way to = have a look at missing or closed issues ?

Denis

Hello,

The mailing list has been pretty = silent these last days.

Hereafter is a quick overview about some = of the remaining issues classified by order of  importance (from my point of view).


1. User choice and consent, and user notice #215

smartopain = wote:

To draw a parallel: Since the publication of the EU GDPR (General Data Protection Regulation) the use of the cookies has changed.
An end-user is allowed to accept them all, to deny them all (except functional cookies) and even to make some choices.
The end-users can know which legal entity will collect the cookies and what for.

The same kind of screens should be proposed to the end-user.
=46rom a technical perspective, specific = end-points should be defined and used, since this kind of dialog is done using APIs.

 I agree with smartopain.

2. Trust relationships #214

There are still = left undefined. AS-RS trust relationships are important. RO relationships with both ASs and RSs are very = important
but unfortunately are discussed nowhere in the current draft (except in text proposals about this issue) =

3. = Interaction (1) between the Client Instance and the RS as described in the first figure #252

Still on the table = but not progressing.

4. The first figure in section 1.4 should be split and revisited #192

This is still not = done.

5. Unlinkability #241

Still on the table = but not progressing.

6. Requesting User Information #197

This is still a = hazy topic.


 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=_21F8E9E0-D469-48D6-B596-6A4AF87F5ED7-- From nobody Thu May 6 08:10: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 5C8863A2573 for ; Thu, 6 May 2021 08:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 AA5EeBPtLPcj for ; Thu, 6 May 2021 08:10:43 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0C993A257E for ; Thu, 6 May 2021 08:10:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4E77B300BDE for ; Thu, 6 May 2021 11:10:41 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id dWIq3ztkvJ58 for ; Thu, 6 May 2021 11:10:36 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 2659E300B02 for ; Thu, 6 May 2021 11:10:36 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.20\)) Date: Thu, 6 May 2021 11:10:36 -0400 References: <161738286447.31292.8790971017092614075@ietfa.amsl.com> To: txauth@ietf.org In-Reply-To: <161738286447.31292.8790971017092614075@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.20) Archived-At: Subject: Re: [GNAP] Grant Negotiation and Authorization Protocol (gnap) WG Virtual Meeting: 2021-05-06 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, 06 May 2021 15:10:48 -0000 I am unable to get into the zoom meeting. When I click "Join from = Browser", I get prompted for Intuit Corporate User ID and password. Of = course, I do not have such... Russ > On Apr 2, 2021, at 1:01 PM, IESG Secretary = wrote: >=20 > The Grant Negotiation and Authorization Protocol (gnap) WG will hold > a virtual interim meeting on 2021-05-06 from 15:00 to 16:00 UTC. >=20 > Agenda: > (No agenda submitted) >=20 > Information about remote participation: > https://intuit.zoom.us/j/91960243935?from=3Daddon From nobody Thu May 6 08:15: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 BDD963A25A0 for ; Thu, 6 May 2021 08:15: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, 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 FrL7L9PKhsHF for ; Thu, 6 May 2021 08:15:40 -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 BA44A3A25AD for ; Thu, 6 May 2021 08:15:40 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id p8so5089884iol.11 for ; Thu, 06 May 2021 08:15: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=WWXTzo4ZpjVisOs3egulUhdPWbC1ayCyADOhQLDj73c=; b=lbPKUsgcDtt5esruXs92mYrgpnxTU/z3k8n01V/y4HseKN/vScZNLEm2i5dLlYwhaw q1RSkAyY7L7PO816Qg504Oq93250EVUN6jZzrulGpD4nxq7QBJXRwbkeZpl5fLALd0su YMb12z9mJJ5nmZlXM97o3vkbVXLRF4rAcQ8sNUtgcEte7ppWFP5t76Dbtr299+gtp+ZD PliidMMUazo8QtpCRi+BsQbev1Awl4AApJ9uUWWDSCmQwUdwCedRpy09lKz4zgYdsHiQ TmllGMFYJZ+0DjKfWIXDc1md8xwYr7oxELMXymD2aFdDIm+5ah/iVkXDCZx3CNsDzwl4 Vb+Q== 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=WWXTzo4ZpjVisOs3egulUhdPWbC1ayCyADOhQLDj73c=; b=FS2Wu+dw1b7m3PPWq9PAee5JFR2d8dAgFnYFztacPRzkpOOXIXoKD60l06XC2MLM8m vzzuFXbtU2O1kbCbCZhhRiX4gQVxXJXa2zPjGbOq42aDcjl1CXvzVnQKCmztaFC6Pp2e l8z8S+9qbvI7jR0GkYMjOrMMZYYXHxvhxyJzZcO7kZdjlHnTIizpZy6D0ggcHgNgm2rq jyI/AlqOxxloVuYng8xM4O5oH06dDuDD4PlwIZ72jLZodoLjecdeoFGydtjJGC6fx6hZ UXpsxXlKQvdi3GM9M/SxRAs1XJ0EbaFJq8cjPFFEQgHAJkgs9+lQzGO14lLp96zaV8he mWAw== X-Gm-Message-State: AOAM531xD7qc2Aphqv8egbD1twx28Qb2YrJhBCULHZf9cudfM8KfH3/C HM/Bo7vLDfE4ABGVUR2OIPRsw81JecVeeCq6KowBpVeSxXg= X-Google-Smtp-Source: ABdhPJy0LByTNX4cf40HoTrYh+H/tvclxnS8OlNE76gaSBZVTawbplk74s9tJf85B6+xiNcJnzg2wB/pf9cmpxPXKNY= X-Received: by 2002:a6b:f311:: with SMTP id m17mr3676307ioh.162.1620314138851; Thu, 06 May 2021 08:15:38 -0700 (PDT) MIME-Version: 1.0 References: <161738286447.31292.8790971017092614075@ietfa.amsl.com> In-Reply-To: From: Fabien Imbault Date: Thu, 6 May 2021 17:15:27 +0200 Message-ID: To: Russ Housley Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000abbf6005c1aac821" Archived-At: Subject: Re: [GNAP] Grant Negotiation and Authorization Protocol (gnap) WG Virtual Meeting: 2021-05-06 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, 06 May 2021 15:15:46 -0000 --000000000000abbf6005c1aac821 Content-Type: text/plain; charset="UTF-8" Hi Russ, I had the same issue via my browser, and had to connect through the zoom app. Fabien On Thu, May 6, 2021 at 5:10 PM Russ Housley wrote: > I am unable to get into the zoom meeting. When I click "Join from > Browser", I get prompted for Intuit Corporate User ID and password. Of > course, I do not have such... > > Russ > > > > On Apr 2, 2021, at 1:01 PM, IESG Secretary > wrote: > > > > The Grant Negotiation and Authorization Protocol (gnap) WG will hold > > a virtual interim meeting on 2021-05-06 from 15:00 to 16:00 UTC. > > > > Agenda: > > (No agenda submitted) > > > > Information about remote participation: > > https://intuit.zoom.us/j/91960243935?from=addon > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000abbf6005c1aac821 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Russ,=C2=A0

I had the same issue via= my browser, and had to connect through the zoom app.

<= div>Fabien

On Thu, May 6, 2021 at 5:10 PM Russ Housley <housley@vigilsec.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">I am unable to get into th= e zoom meeting.=C2=A0 When I click "Join from Browser", I get pro= mpted for Intuit Corporate User ID and password.=C2=A0 Of course, I do not = have such...

Russ


> On Apr 2, 2021, at 1:01 PM, IESG Secretary <iesg-secretary@ietf.org> wrote= :
>
> The Grant Negotiation and Authorization Protocol (gnap) WG will hold > a virtual interim meeting on 2021-05-06 from 15:00 to 16:00 UTC.
>
> Agenda:
> (No agenda submitted)
>
> Information about remote participation:
> https://intuit.zoom.us/j/91960243935?from=3Dad= don

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000abbf6005c1aac821-- From nobody Thu May 6 08:34: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 653D43A2643 for ; Thu, 6 May 2021 08:34: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, 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 2EKKkyxtN6xN for ; Thu, 6 May 2021 08:34:42 -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 873BD3A2640 for ; Thu, 6 May 2021 08:34:42 -0700 (PDT) Received: by mail-il1-x12e.google.com with SMTP id j12so5113253ils.4 for ; Thu, 06 May 2021 08:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=eNlIQ6RFfd4SAorZooqezQXidRYsPtBOsQNVrJGoHvI=; b=XobVB4dJDuHB2D8HxXopoqcGuo5TB2s6HTd8zG6/uvu1DMkZi02n1K43gRsfeoXtev sPEuJa86RFAjPoXgVkhP2+DdByknl0WQI92rV+HQLN2vP8TdcK7brr56rd3u5NcC3BqM hLx2UC7j7Aq4NYRI5PEjfXAvB2GF48mWt0AHx0vs3dTLiDEngyRI8/5h3JiAvw2UeTWy lUvVWT6Y7UJDYhJgxE+wwjvXGag0XYDoa6fQGKENrx/3x4DPfS4dbHRMOnjN+qgEOcYU 4D1BPT/eTEZ0n0sOtyNAv2cPKbRA9P3n97/30U59ttUEHS22nwVtt4pVeyCxGwexUEHb tGTg== 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=eNlIQ6RFfd4SAorZooqezQXidRYsPtBOsQNVrJGoHvI=; b=cF31/UkmASwPtnHubuJ/GgkyBQa75Nw7A2r9joksIb06wh5QUtE9O1mQz/qogQZRhx E3a6DAtY2e1FJww3F/HibockzrxLKrC13K1hGWfikqrZxjnn6HCh363ycdvgi8zr5/sc 5sAsZxPaanMmAZVHwLKRPnoP67wxt+cMQiZg3MpD/oQbiv0pJCDIQvNq5Exfe5lkWE/f KcSb1js7qdiIxKvpgw9KoE+oMmSEThhri0aeeKgdgh2sva6tzP7VNtpuFq4eJ6i7YMuO lPmfemvHgTciu8vbdKOqywInZQvnYVbJBvlax9poTToDnZwBN4E6a+U4kgY1n6/o48bx wd6g== X-Gm-Message-State: AOAM530Pmy1eGqMLnUEqH08pxr5m+Q0bUqt834b0MLAlaMMrXZBiriUc u9Ik3OSMFOWqxZD1ovCjJ8Sp+zexPa6mFwRYN0XVdlBl35ntcA== X-Google-Smtp-Source: ABdhPJwP789TElYa6dimY3fkPjXWu+HKAbVERm/O50DgzV1myNpTFZ1045Dm1ETGlMf80YJa1F9g4zvBgliTMc4rfrQ= X-Received: by 2002:a05:6e02:1708:: with SMTP id u8mr5129006ill.188.1620315280627; Thu, 06 May 2021 08:34:40 -0700 (PDT) MIME-Version: 1.0 From: Fabien Imbault Date: Thu, 6 May 2021 17:34:29 +0200 Message-ID: To: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000b9dd4305c1ab0cfb" Archived-At: Subject: [GNAP] Rationale for GNAP - a blog post 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, 06 May 2021 15:34:47 -0000 --000000000000b9dd4305c1ab0cfb Content-Type: text/plain; charset="UTF-8" Hi everyone, As discussed during the call, please find the blog post (I believe we should setup a more official GNAP blog if we can). https://blog.fimbault.com/managing-authorization-grants-beyond-oauth-2 The intent is to start communicating more on GNAP, and give more details than Annex B. It will be presented at https://oid2021.compute.dtu.dk/ and will be published as a shorter article (6 pages) by LNI. Fabien --000000000000b9dd4305c1ab0cfb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,=C2=A0

As discussed dur= ing the call, please find the blog post (I believe we should setup a more o= fficial GNAP blog if we can).=C2=A0
The intent = is to start communicating more on GNAP, and give more details than Annex B.=

It will be presented at https://oid2021.compute.dtu.dk/ and will be publishe= d as a shorter article (6 pages) by LNI.=C2=A0

Fab= ien
--000000000000b9dd4305c1ab0cfb-- From nobody Fri May 7 01:19: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 3C2BA3A10AD for ; Fri, 7 May 2021 01:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, 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 q7RgG8VyIF8B for ; Fri, 7 May 2021 01:19:01 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 5CF9F3A10BF for ; Fri, 7 May 2021 01:17:24 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id v12so8230284wrq.6 for ; Fri, 07 May 2021 01:17:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:date:from:subject:thread-topic:message-id:to :content-transfer-encoding; bh=3pqyIcUl4lfH7Mge2E+yHsDWown6lY1rmHVsDKBDfT4=; b=dKhh7K+uzSEJ5SKhUnsrTeAUaPd6uLjaBtY2LODAywloAebnr/IwRFSYm8zNkoWLN4 kIDS6QYia6NG2j4rbrxt/c5AgTEVJq9HZ8tRIqhFes/NPp0wBSInGgoZ9VM5OOnNMYNO Gv7UCkPU/y9vv2KtRclErwF06ZWLCRRJqBpXRUGe+O5CIP2+s+kma54rqNHBemAPK8QU De+y7AkdlFrQAfaRbD58tRvZCTHxuPo5iV1dijCQM06Yp243jDStaiQHen175c53dke5 3+Jp0EKSSihs1xaSyDPXGN65L9pwOnYWbYb84Mjmo2CFQJA9FInci0JjRHLTJzPj/rrm ghSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:from:subject:thread-topic :message-id:to:content-transfer-encoding; bh=3pqyIcUl4lfH7Mge2E+yHsDWown6lY1rmHVsDKBDfT4=; b=I186fWI0Aa5YPSkjlAxvf+q7CrNISKOB3oPfiI4YNKlU834LHINH23Evjkyorf6Ivz XCAFAI7oWLOTiDr0S8DXNUm1zIEkMPAzSvQ15Nl8XW8dVORAitNmwwMWJ3h5TgDxl4Ng f74xJvvYYRCJJ1RAGGP00JkUboWS40Np91JmqPzE+elCCfeErfINaFwBEa9huZgjfy2n 460AWZ21wOPiZ1N5KOfeYBYSq5EIMGl7gII1mrLR5Sjq2LVLuRhML4XLiy/A3ox/VNVY 3pzOUyvrSKsXhkfhREF9NJTLck8kQS9HDCe44Pb0h0h9cW5kHW9s+9vOkpiDjo8SNiRa w+cQ== X-Gm-Message-State: AOAM533nldCpFNDuXmjIaYE+p6bJ9FU9oZVWZAto82FIuURGN8nCmWhy TrdSPcv9F/anqJu5afiCojkuy9T3c9o= X-Google-Smtp-Source: ABdhPJw9VWkV8ORDjZnurH/ygMIM6iuzFfhnVFhjcCsPNP0MNEVhbVIcf3uz10/73H7j4QK2bB8l3A== X-Received: by 2002:a5d:58d8:: with SMTP id o24mr10866357wrf.288.1620375442013; Fri, 07 May 2021 01:17:22 -0700 (PDT) Received: from INTUL183d7d6fa (bzq-79-183-39-51.red.bezeqint.net. [79.183.39.51]) by smtp.gmail.com with ESMTPSA id z14sm8767723wrt.54.2021.05.07.01.17.21 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 May 2021 01:17:21 -0700 (PDT) MIME-Version: 1.0 Date: Fri, 7 May 2021 11:17:18 +0300 From: Yaron Sheffer Thread-Topic: Interim minutes Message-ID: <70A61B2C-7EFD-8541-A227-69D714FA118B@hxcore.ol> To: GNAP Mailing List Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Archived-At: Subject: [GNAP] Interim minutes 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, 07 May 2021 08:19:06 -0000

= I have uploaded the minutes of yesterday= =E2=80=99s interim meeting.

 

https://datatracker.ietf.org/mee= ting/interim-2021-gnap-03/session/gnap

 

Thank you Aaron for takin= g notes!

 

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

<= /html>= From nobody Sun May 9 01:16: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 AF7A03A20B7 for ; Sun, 9 May 2021 01:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.897 X-Spam-Level: X-Spam-Status: No, score=-0.897 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=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=q5ZX2KX/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=vIzAXpsH Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOXicYPpsrob for ; Sun, 9 May 2021 01:16:03 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F34E73A20B9 for ; Sun, 9 May 2021 01:16:02 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id AD2C7191A for ; Sun, 9 May 2021 03:40:43 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 09 May 2021 03:40:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm2; bh=w9+rmnVpw9l AXqcdlHerPl9Z0uea9ZD0bjynGBm278E=; b=q5ZX2KX/NlkJDbQXivE3hf3z0KA rhAd1AqlIlMjt8TMFYAKZLij3A6J1YkzgS44ladhIOtAZbhvFBCCR5p3446HXklJ iSS41UDbUH7xr5rNSO9cTkrY3TJqf18r936Mpcg/Ahj18BjNRvpCi80rs1+SS5Qa t/k7hx56wFfLfZAyH6IJsADX61AvMUCOnoklgQGiKNEKCMUFjKCGT0M9asPQD6Gq IAVomOHnx1KtW27DaKqywFY0rQePeOiRNEwXFlfqdZvG+C31rM4xU2KFj4jo0LxZ b1IqmNYjWTrVkkPgYZ9n6PGCfNoXOwhHdAxwIyNMuLTv+d96jKyq7Wsc+ag== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:from:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=w9+rmnVpw9lAXqcdlHerPl9Z0uea9ZD0bjynGBm278E=; b=vIzAXpsH /FD8tsd9oRcfnzEOf2CTKVsvfmrn13INozsEbgOUS6n7/aV0ye+RI2pZDr6fXpmb o6d0Zoz7Nvp0QCNZqPel2QZVA3qMx7aqJq1xvetlRDN/8TizSP0pcE0jSS5SDH3K Aji2M6BHP+4fqeqGufOsd23sVy0cfwuLWj81bJ4TzHWeffpbfAp4KogqjgGYN4/8 baTOhHvd8IB2YG4c26SZ55See9OXS1T8KVagan4kq9QVB2uYToxMoykOdE5m/xpI Ni+0CzgtYw/oEnxihLpA8HdHBasqak7ThjnckWQTwr/O/3WCj3mc14x68MF/a5GQ cWMn6O4LRN1YFA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeghedguddvgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecupfhoucgurghtvgcufhhivghlugculdegledmne cujfgurheptggghffvufesrgdttdertddtjeenucfhrhhomheptfgvphhoshhithhorhih ucettghtihhvihhthicuufhumhhmrghrhicuuehothcuoeguohgpnhhothgprhgvphhlhi esmhhnohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeekfedvudetjedvfeekheeiveeu gfefhfetteevgeffkefffeetffdvleehudeiteenucffohhmrghinhepghhithhhuhgsrd gtohhmnecukfhppedvtddrudekhedrkeekrdduiedunecuvehluhhsthgvrhfuihiivgep feenucfrrghrrghmpehmrghilhhfrhhomhepughopghnohhtpghrvghplhihsehmnhhoth drnhgvth X-ME-Proxy: Received: from fv-az154-953.kzav01uq0i3u1f1hch3ggm0mbb.bx.internal.cloudapp.net (unknown [20.185.88.161]) by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 9 May 2021 03:40:43 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============1819254188690117535==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20210509081602.F34E73A20B9@ietfa.amsl.com> Date: Sun, 9 May 2021 01:16:02 -0700 (PDT) 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, 09 May 2021 08:16:09 -0000 --===============1819254188690117535== 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 (+1/-0/=F0=9F=92=AC4) 1 issues created: - Add an "implementation status" section (by yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/258=20 3 issues received 4 new comments: - #257 Format of defining REQUIRED vs OPTIONAL request/response elements = (1 by tplooker) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/257 [Editoria= l]=20 - #221 DID as identifier (2 by agropper, fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/221 [Needs Te= xt]=20 - #168 message based interaction / DIDComm (1 by agropper) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/168=20 * ietf-wg-gnap/gnap-resource-servers (+9/-2/=F0=9F=92=AC6) 9 issues created: - Section 2.3.4 should be normative (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/10=20 - Capabilities only (i.e. actions) are supported. ACLs (i.e. attributes a= ssociated with a subject) should also be supported (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/9=20 - A model where the AS and the RS do not need to establish a prior relati= on relationship should be able to co-exist (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/8=20 - Trust relationships between a RS and an AS (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/7=20 - The text should say when the RS SHALL respond to the client with an aut= hentication header indicating an error (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/6=20 - The privacy drawbacks when implementing an introspection service should= be mentioned (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/5=20 - Calls from a RS to an AS are optional (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/4=20 - Token formats can also be advertised both by AS and RS (by Denisthemali= ce) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/3=20 - The Abstract and the Introduction should be aligned (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/2=20 6 issues received 6 new comments: - #10 Section 2.3.4 should be normative (1 by jricher) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/10=20 - #8 A model where the AS and the RS do not need to establish a prior rel= ation relationship should be able to co-exist (1 by jricher) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/8=20 - #7 Trust relationships between a RS and an AS (1 by jricher) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/7=20 - #6 The text should say when the RS SHALL respond to the client with an = authentication header indicating an error (1 by jricher) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/6=20 - #5 The privacy drawbacks when implementing an introspection service sho= uld be mentioned (1 by jricher) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/5=20 - #4 Calls from a RS to an AS are optional (1 by jricher) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/4=20 2 issues closed: - Section 2.3.4 should be normative https://github.com/ietf-wg-gnap/gnap-= resource-servers/issues/10=20 - Calls from a RS to an AS are optional https://github.com/ietf-wg-gnap/g= nap-resource-servers/issues/4=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol * https://github.com/ietf-wg-gnap/gnap-resource-servers --===============1819254188690117535== 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 May 09, 2021

Events without label "editorial"

Issues

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

1 issues created:

3 issues received 4 new comments:

ietf-wg-gnap/gnap-resource-servers (+9/-2/=F0=9F=92=AC6)

9 issues created:

6 issues received 6 new comments:

2 issues closed:

Repositories tracked by this digest:

--===============1819254188690117535==-- From nobody Sun May 9 07:00: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 C65C33A0E1B for ; Sun, 9 May 2021 06:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, 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 UX65fUJ3ZKIt for ; Sun, 9 May 2021 06:59:57 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450: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 277063A0E1A for ; Sun, 9 May 2021 06:59:57 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id v12so13873259wrq.6 for ; Sun, 09 May 2021 06:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:date:from:subject:thread-topic:message-id:to :content-transfer-encoding; bh=vP96Zlvce/wPLMmlxX46tLy5w177XjI02tDoXUxpux8=; b=JcqqpdjNN0cfkiS/le3YYpmHl1SNhCaPbW6LD7tXl5rA0Po9kqQZ+sE7D2PD0jDA6W ECtnvYMwz+1ZNenBQYMH9TLQa9X8Ce3KiHpUWQ6++vQ/j1mkS4i5qytJMriJq5FH6eDe fUuKQqGDWQJhDSBOb/I+y+tqmS9diNIVoLlZekDMGbywxMAjv6cbI/7IqvqiqRSywxI/ Ww6oTpwQZvt4Riz8DnfEWY9714e2fSrvW8y+mWsp788IOYavbI3prr7aRB20PhAITUlr mXO3MKyxhuq/wKimXgAYsfTlme+k31wSJo/44mDCMxjdVxlGVB42nlmzkt3ZO2O1GCXt Hc5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:from:subject:thread-topic :message-id:to:content-transfer-encoding; bh=vP96Zlvce/wPLMmlxX46tLy5w177XjI02tDoXUxpux8=; b=qqR9TEGuow+P5/WpltxJrX6x/mLyunh4kmSEvbjtxyFHDBvrb8fIDanFBgiTx+PrHM ww/UKz8mNRvik5/4bBQxQk/H83PMS7K7m2uLmv0KD+1pAXcKPzPGaVct0sOAZnKy6k7d ImSj4fijoChXsEXW9joDYh2jRweVUWOexYG2CJRyXpmmWlFYCEPmH3pAAB1Xp3Y7J+rX keDJ4IGGNWHP7OW+jzr3QQ1lfxvFIyYOccWk+CV6nFdi1ziUJHpL6wS9QaHgzAbOeP9t Tbo5HffvTFamiA8VFm+A9rij15CilWdxiH1YayLwmfVaXdydIwC9vUcKx7Lvr56B9N1t /R+Q== X-Gm-Message-State: AOAM533htfK6ih9g7tRoO+/v8/SerGzJr5CUmIiPzOpoGh3w54AQYx7c YO5iCzKurW0GoB0xytPC5tHD8nfk40py0w== X-Google-Smtp-Source: ABdhPJzCBckKl4Xb/h+0jrJwk81pmMR+Ekw22JstIbX0Ur6KZjZM8T57xUstaCOo9bObLps4mEKC6g== X-Received: by 2002:adf:fe8e:: with SMTP id l14mr25372505wrr.305.1620568794722; Sun, 09 May 2021 06:59:54 -0700 (PDT) Received: from INTUL183d7d6fa (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id f20sm17199888wmh.41.2021.05.09.06.59.53 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 May 2021 06:59:54 -0700 (PDT) MIME-Version: 1.0 Date: Sun, 9 May 2021 16:59:50 +0300 From: Yaron Sheffer Thread-Topic: Resource Servers draft Message-ID: <8517AD16-92CD-7743-92CC-D8ABC4DAAEC9@hxcore.ol> To: GNAP Mailing List Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Archived-At: Subject: [GNAP] Resource Servers draft 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, 09 May 2021 13:59:59 -0000

= Hi Editors,

 

<= p class=3DMsoNormal>Here=E2=80=99s a bunch= of comments to the latest version (Editor=E2=80=99s Draft as of today). Pl= ease respond with what is easy to fix, and what I should open an issue for.=

 

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

 

  • Abst= ract: better use more concrete terms than "piece of software". Ev= en if this creates a dependency on the Terminology section.
  • Typo: by (AS).
  • "client-facing discovery me= chanism" - I'm not seeing any client-facing protocol in the document (= and it wouldn't belong here anyway).
  • Terminology: include a reference to the Terminology s= ection of the Core doc.
  • Access Token Formats: IMO we should specify a minimal, generic form= at in an appendix, as a non-normative starting point for developers. It wou= ld be better than having each implementation make its own mistakes.
  • Macaroons, biscuits, ot= her baked goods: add a reference.
  • AS Discovery: why do we need a "well known" URI= ? Either we use GNAP Core to pass the AS address to the RS, and then we cou= ld pass a full URI, or we don't, and then how does the RS even know how to = find the AS?
  • Pro= tecting RS requests to the AS: the RS, by definition, owns resources. This = means that it needs to have a persistent identity, in addition to the (ephe= meral) keys being presented. Otherwise (especially with TOFU registration) = we could easily have Resource Servers squatting on other people=E2=80=99s r= esources. It is very hard to manage the mapping of RS to resources if we do= n't have such a persistent identity.
  • Token Introspection: it is not clear to what depth we= are defining the API: is it only the existence of the "introspect&quo= t; endpoint? Or do we define a minimal set of standard attributes that need= to be returned? The API would not be useful for interoperability unless we= define some of the returned attributes. At the very least: "active&qu= ot;.
  • "clien= t instance's request" - should be "Resource Server's request"= ;.
  • And we should= add: the AS MUST validate that the token is appropriate for the RS that pr= esented it, and return an error otherwise.
  • Typo: internal link to "token format"= .
  • IANA Considera= tions: the "well known" URL should be registered (BTW, it's a wel= l-known *URI*). Also, please list the registries that we need to establish.=
= From nobody Sun May 9 11:33: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 566B43A19E5 for ; Sun, 9 May 2021 11:33: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 JmFbE5kilRt9 for ; Sun, 9 May 2021 11:33:49 -0700 (PDT) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04D723A19E4 for ; Sun, 9 May 2021 11:33:48 -0700 (PDT) Received: by mail-il1-x12c.google.com with SMTP id z1so4280437ils.0 for ; Sun, 09 May 2021 11:33: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=X6waPKyEzr6esxVQPXwRYhuy4DJToOw5sm1nzbqzVhY=; b=tzTRiJKXOu24JTeU3FkmPgFN7WLhqu5tfjzMxtjo8AQ1cRGNhWi48MpuoVVyUahQ/E 5NhijvXU1zIFoBiNMEvDXE/JXGzDZ7V681YOGFD3kY/wf/JJOPVqd5l82RfjwFypVYgN 5Ip9i+TaafEN7+o14kQpF8LQ2bGQtb3fJjHk7PHW5mAWP56QsC+61pIG9O4MG7lOTofr 3Mzgwdke/QJYCm7ypIUNOwCNRVmi+CTSypvl12wlntZeNyJybOhYToMNOyVoU7X1ECg+ 5e2HkKoeVIpSNWbfA0qmIto6DtAnL3qDRX3iCCqVaK6pKNC8r5qRaE8hH4kLauj4bdmR 9Fiw== 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=X6waPKyEzr6esxVQPXwRYhuy4DJToOw5sm1nzbqzVhY=; b=bL5M98Tj9oF3q2/SypWMOBzbE6tEQxw+jvfZ0t+nNADqkos7Z/wmqlbOBVgrJVD3Oz vojRDbrrivfUT9UQ+ZKPXcznUyUyjAq+gKXMl/aH9XfS+cCbHyw+fq2Z10vsBg5j5022 puYw/R7FLRRn3x3W1pF5srHiynxWtN5z0n8OQFt48hYcu1fNNs9MZb9jDPGgsX5s60LZ pJMOOumxVbiYzcZxvU34ywyyFtgHVLoUxQ7W23HOf9/de8R2Rw77cVI8u9x1va3wrWcF B+ec+nW+hk0mc6kyKFSAevkyEVMotrHTPSJZThBiUQRi1Z4PO9v9REhUS6bpo+emFqSb ceDA== X-Gm-Message-State: AOAM532CfaUS9j8OKVrSzYwmr9RfqgsZErEBTVz4cCI3wMvcPTRyVDba EPmD8LqAOfsLoSFQrAxe95dpswGMblg91q86RIw= X-Google-Smtp-Source: ABdhPJwJMi4WHkLUUrZJdOuW3jyP40ybJHOeLEV2phHtoAREDLMZeW9it2V+fZpnT17TwU+eq9fk6xsBQOAHhujpUy0= X-Received: by 2002:a92:6a04:: with SMTP id f4mr17532897ilc.289.1620585226699; Sun, 09 May 2021 11:33:46 -0700 (PDT) MIME-Version: 1.0 References: <8517AD16-92CD-7743-92CC-D8ABC4DAAEC9@hxcore.ol> In-Reply-To: <8517AD16-92CD-7743-92CC-D8ABC4DAAEC9@hxcore.ol> From: Fabien Imbault Date: Sun, 9 May 2021 20:33:35 +0200 Message-ID: To: Yaron Sheffer Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000c408f905c1e9e626" Archived-At: Subject: Re: [GNAP] Resource Servers draft 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, 09 May 2021 18:33:53 -0000 --000000000000c408f905c1e9e626 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yaron, A comment on access token formats: I don't think we should define our own format, but we can reference other documents such as https://datatracker.ietf.org/doc/html/draft-bertocci-oauth-access-token-jwt and the references to macaroons, biscuits. The rest I believe makes good issues, most of which should be quick to fix. Cheers Fabien On Sun, May 9, 2021 at 4:00 PM Yaron Sheffer wrote: > Hi Editors, > > > > Here=E2=80=99s a bunch of comments to the latest version (Editor=E2=80=99= s Draft as of > today). Please respond with what is easy to fix, and what I should open a= n > issue for. > > > > Thanks, > > Yaron > > > > - Abstract: better use more concrete terms than "piece of software". > Even if this creates a dependency on the Terminology section. > - Typo: by (AS). > - "client-facing discovery mechanism" - I'm not seeing any > client-facing protocol in the document (and it wouldn't belong here an= yway). > - Terminology: include a reference to the Terminology section of the > Core doc. > - Access Token Formats: IMO we should specify a minimal, generic > format in an appendix, as a non-normative starting point for developer= s. It > would be better than having each implementation make its own mistakes. > - Macaroons, biscuits, other baked goods: add a reference. > - AS Discovery: why do we need a "well known" URI? Either we use GNAP > Core to pass the AS address to the RS, and then we could pass a full U= RI, > or we don't, and then how does the RS even know how to find the AS? > - Protecting RS requests to the AS: the RS, by definition, owns > resources. This means that it needs to have a persistent identity, in > addition to the (ephemeral) keys being presented. Otherwise (especiall= y > with TOFU registration) we could easily have Resource Servers squattin= g on > other people=E2=80=99s resources. It is very hard to manage the mappin= g of RS to > resources if we don't have such a persistent identity. > - Token Introspection: it is not clear to what depth we are defining > the API: is it only the existence of the "introspect" endpoint? Or do = we > define a minimal set of standard attributes that need to be returned? = The > API would not be useful for interoperability unless we define some of = the > returned attributes. At the very least: "active". > - "client instance's request" - should be "Resource Server's request". > - And we should add: the AS MUST validate that the token is > appropriate for the RS that presented it, and return an error otherwis= e. > - Typo: internal link to "token format". > - IANA Considerations: the "well known" URL should be registered (BTW, > it's a well-known *URI*). Also, please list the registries that we nee= d to > establish. > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000c408f905c1e9e626 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Yaron,=C2=A0

A comm= ent on access token formats: I don't think we should define our own for= mat, but we can reference other documents such as=C2=A0= https://datatracker.ietf.org/doc/html/draft-bertocci-oauth-access-token-jwt= and the references to macaroons, biscuits.

Th= e rest I believe makes good issues, most of which should be quick to fix.

Cheers
Fabien

On Sun, May 9, 2021 = at 4:00 PM Yaron Sheffer <yaron= f.ietf@gmail.com> wrote:

Hi Editors,

=C2=A0<= /p>

Here=E2=80=99s a b= unch of comments to the latest version (Editor=E2=80=99s Draft as of today)= . Please respond with what is easy to fix, and what I should open an issue = for.

=C2=A0

Thanks,

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

=C2=A0<= /u>

  • Abstract: better use more concrete terms than "p= iece of software". Even if this creates a dependency on the Terminolog= y section.
  • Typo: by (AS).
  • "client-facing discovery mechanism" - I'm not seeing an= y client-facing protocol in the document (and it wouldn't belong here a= nyway).
  • Te= rminology: include a reference to the Terminology section of the Core doc.<= u>
  • Access Tok= en Formats: IMO we should specify a minimal, generic format in an appendix,= as a non-normative starting point for developers. It would be better than = having each implementation make its own mistakes.
    • =
  • Macaroons, biscuits, other baked go= ods: add a reference.
  • AS Discovery: why do we need a "well known" URI? Eith= er we use GNAP Core to pass the AS address to the RS, and then we could pas= s a full URI, or we don't, and then how does the RS even know how to fi= nd the AS?
  • Protecting RS requests to the AS: the RS, by definition, owns resources. T= his means that it needs to have a persistent identity, in addition to the (= ephemeral) keys being presented. Otherwise (especially with TOFU registrati= on) we could easily have Resource Servers squatting on other people=E2=80= =99s resources. It is very hard to manage the mapping of RS to resources if= we don't have such a persistent identity.
    • Token Introspection: it is not clear t= o what depth we are defining the API: is it only the existence of the "= ;introspect" endpoint? Or do we define a minimal set of standard attri= butes that need to be returned? The API would not be useful for interoperab= ility unless we define some of the returned attributes. At the very least: = "active".
  • "client instance's request" - should be "Resou= rce Server's request".
  • And we should add: the AS MUST validate that the toke= n is appropriate for the RS that presented it, and return an error otherwis= e.
  • Typo: i= nternal link to "token format".
  • IANA Considerations: the "well known&q= uot; URL should be registered (BTW, it's a well-known *URI*). Also, ple= ase list the registries that we need to establish.
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000c408f905c1e9e626-- From nobody Sun May 9 11:53: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 B62E03A1ADB for ; Sun, 9 May 2021 11:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.499 X-Spam-Level: X-Spam-Status: No, score=0.499 tagged_above=-999 required=5 tests=[FREEMAIL_FORGED_FROMDOMAIN=0.248, 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 4u7jNN4HwoT2 for ; Sun, 9 May 2021 11:53:42 -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 6BB043A1AD7 for ; Sun, 9 May 2021 11:53:42 -0700 (PDT) Received: by mail-vs1-f43.google.com with SMTP id 66so7308102vsk.9 for ; Sun, 09 May 2021 11:53:42 -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=G7LRWTiLHCPWzBPK06ymkvmlTbnBErMnqSvCOKDLCqw=; b=j4x8/UNIQYeIdFzwvLkWE9XAqR/COaA7oG/YsxntNHCJdV/hm1PSDYFvv1EiOiHU1H LRTNP3PVgzJZv1K9VtZAT0lkd7hypUHaEQeFnhCzvy6GrkZtNb2kxy+AR4NzBc4rZpi7 hH9X1NsjRk/ZPbc7ZonTFOyHHCKhb2flfk7wmHmoyMwJK87L0tbclzHCcRkNxOg+U4Xm OgFdVsHezCYdcUbAviBUhi9xc3fWB8CR7hq/pvt1KX+QBkFqfFxsFKuDtAUmcoCbPwDi 6kzrbfuXgb6csJXfLRxWmb+OvhkObZ+fgKQVR8KTF8lD3yBcJUYdFVGqK7QP2E1iKd4+ adrw== X-Gm-Message-State: AOAM5320VaXbaodG8uEZ3Ib36meE3p+A1ibKqmLQmvi1FvWNkhb+H6Zc LBV3cS4pr8FGRl6d5NbmywMxbjixhK1KBn0nG9s= X-Google-Smtp-Source: ABdhPJxbDemv5NxI6pgjoV13o4ZiGBJR/Ab+dvdlh+L76X3zkOfedwPkIMzWNB3Blx7haSNUV8BCLOisCEzlQMilBJk= X-Received: by 2002:a67:c283:: with SMTP id k3mr17680319vsj.12.1620586420640; Sun, 09 May 2021 11:53:40 -0700 (PDT) MIME-Version: 1.0 References: <8517AD16-92CD-7743-92CC-D8ABC4DAAEC9@hxcore.ol> In-Reply-To: From: Adrian Gropper Date: Sun, 9 May 2021 14:53:29 -0400 Message-ID: To: Fabien Imbault Cc: Yaron Sheffer , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000ee1ed605c1ea2d05" Archived-At: Subject: Re: [GNAP] Resource Servers draft 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, 09 May 2021 18:53:47 -0000 --000000000000ee1ed605c1ea2d05 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable macaroons, biscuits, and ZCAP-LD - Adrian On Sun, May 9, 2021 at 2:34 PM Fabien Imbault wrote: > Hi Yaron, > > A comment on access token formats: I don't think we should define our own > format, but we can reference other documents such as > https://datatracker.ietf.org/doc/html/draft-bertocci-oauth-access-token-j= wt > and the references to macaroons, biscuits. > > The rest I believe makes good issues, most of which should be quick to fi= x. > > Cheers > Fabien > > On Sun, May 9, 2021 at 4:00 PM Yaron Sheffer > wrote: > >> Hi Editors, >> >> >> >> Here=E2=80=99s a bunch of comments to the latest version (Editor=E2=80= =99s Draft as of >> today). Please respond with what is easy to fix, and what I should open = an >> issue for. >> >> >> >> Thanks, >> >> Yaron >> >> >> >> - Abstract: better use more concrete terms than "piece of software". >> Even if this creates a dependency on the Terminology section. >> - Typo: by (AS). >> - "client-facing discovery mechanism" - I'm not seeing any >> client-facing protocol in the document (and it wouldn't belong here a= nyway). >> - Terminology: include a reference to the Terminology section of the >> Core doc. >> - Access Token Formats: IMO we should specify a minimal, generic >> format in an appendix, as a non-normative starting point for develope= rs. It >> would be better than having each implementation make its own mistakes= . >> - Macaroons, biscuits, other baked goods: add a reference. >> - AS Discovery: why do we need a "well known" URI? Either we use GNAP >> Core to pass the AS address to the RS, and then we could pass a full = URI, >> or we don't, and then how does the RS even know how to find the AS? >> - Protecting RS requests to the AS: the RS, by definition, owns >> resources. This means that it needs to have a persistent identity, in >> addition to the (ephemeral) keys being presented. Otherwise (especial= ly >> with TOFU registration) we could easily have Resource Servers squatti= ng on >> other people=E2=80=99s resources. It is very hard to manage the mappi= ng of RS to >> resources if we don't have such a persistent identity. >> - Token Introspection: it is not clear to what depth we are defining >> the API: is it only the existence of the "introspect" endpoint? Or do= we >> define a minimal set of standard attributes that need to be returned?= The >> API would not be useful for interoperability unless we define some of= the >> returned attributes. At the very least: "active". >> - "client instance's request" - should be "Resource Server's request"= . >> - And we should add: the AS MUST validate that the token is >> appropriate for the RS that presented it, and return an error otherwi= se. >> - Typo: internal link to "token format". >> - IANA Considerations: the "well known" URL should be registered >> (BTW, it's a well-known *URI*). Also, please list the registries that= we >> need to establish. >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000ee1ed605c1ea2d05 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
macaroons, biscuits, and ZCAP-LD

- Adri= an

On Sun, May 9, 2021 at 2:34 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Yaron,=C2=A0
A comment on access token formats: I don't think we should = define our own format, but we can reference other documents such as=C2=A0https://datatracker.ietf.org/doc/html/d= raft-bertocci-oauth-access-token-jwt and the references to macaroons, b= iscuits.

The rest I believe makes good issues, mos= t of which should be quick to fix.

Cheers
Fabien

On Sun, May 9, 2021 at 4:00 PM Yaron Sheffer <yaronf.ietf@gmail.com&= gt; wrote:

Hi Editors,

=C2=A0

Here=E2= =80=99s a bunch of comments to the latest version (Editor=E2=80=99s Draft a= s of today). Please respond with what is easy to fix, and what I should ope= n an issue for.

=C2=A0

<= span style=3D"font-size:11pt">Thanks,

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

= =C2=A0

  • Abstract: better use m= ore concrete terms than "piece of software". Even if this creates= a dependency on the Terminology section.
  • Typo: by (AS).<= u>
  • "client-facing discovery mechanism" - I'm not seeing any = client-facing protocol in the document (and it wouldn't belong here any= way).
  • Terminology: include a reference to the Terminology sectio= n of the Core doc.
  • <= span style=3D"font-size:11pt">Access Token Formats: IMO we should specify a= minimal, generic format in an appendix, as a non-normative starting point = for developers. It would be better than having each implementation make its= own mistakes.
  • Macaroons, biscuits, other baked goods: add a ref= erence.
  • AS Discovery: why do we need a "well known" U= RI? Either we use GNAP Core to pass the AS address to the RS, and then we c= ould pass a full URI, or we don't, and then how does the RS even know h= ow to find the AS?
  • <= span style=3D"font-size:11pt">Protecting RS requests to the AS: the RS, by = definition, owns resources. This means that it needs to have a persistent i= dentity, in addition to the (ephemeral) keys being presented. Otherwise (es= pecially with TOFU registration) we could easily have Resource Servers squa= tting on other people=E2=80=99s resources. It is very hard to manage the ma= pping of RS to resources if we don't have such a persistent identity.
  • Token Introspection: it is not clear to what depth we are definin= g the API: is it only the existence of the "introspect" endpoint?= Or do we define a minimal set of standard attributes that need to be retur= ned? The API would not be useful for interoperability unless we define some= of the returned attributes. At the very least: "active".<= u>
  • "client instance's request" - should be "Resource Se= rver's request".
  • And we should add: the AS MUST validat= e that the token is appropriate for the RS that presented it, and return an= error otherwise.
  • Typo: internal link to "token format"= ;.
  • IANA Considerations: the "well known" URL should be= registered (BTW, it's a well-known *URI*). Also, please list the regis= tries that we need to establish.
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000ee1ed605c1ea2d05-- From nobody Mon May 10 00:04: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 9911B3A0901 for ; Mon, 10 May 2021 00:04: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 SSSUEo63Faif for ; Mon, 10 May 2021 00:04:04 -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 DCDCE3A08FE for ; Mon, 10 May 2021 00:04:03 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id k25so13806130iob.6 for ; Mon, 10 May 2021 00:04: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=xAC9hQipMhqK9SWH3HmQ2Fj2ev8GSOm5KlQKElN/g38=; b=IKrlzKkLHvNyMhS6MAR63vQN1e1Zm7tfIPrG77ShNeFjPxiDqQiS+sEWK6COWfNAcA ywqXvxu43B0aSc+9KSm9/gTwI8m4wIjM5iNbNR1SYZI//gpnpCkPNtbnqkyxMn27y35g h85PZJ8g38qmyZFhzph64DRnBUdYRGsktD2Pk+JebK86tr8c67ww7YbSyA/OCZL1g8L5 F1C/3e40oz+N5CcMuAN/qmngMpbFU8KLPbWZq5Rnwe/U0hPRPjfDOIXS8FHr+Be8MgpT 8G26hqbfjiIz+n6WVQAjZr+Cz7cTt44Sgc0wjrbI6aYdBWhhkSeJEV8M++NUwyMLtSp0 rHLg== 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=xAC9hQipMhqK9SWH3HmQ2Fj2ev8GSOm5KlQKElN/g38=; b=GmlIBpnN0xlbJEyppiDwSbF9oz8ClpP1xtsxFSe29cNlcnr1CmoIGKYW5+k7swwPY0 GdtMYFZtXEb4Vx1u+g3VdnvKRvF5rGfLoweMUVstb6W3oua+BaSgj0w87znAcmIZ5BsX YDn5LEgz0RUL7yLGPyDhH55gtVVrp3d4N0VtDGzv57l8U/SCpDs12hUFQp0lKHk8xD3N pDnKvvJ73PSL/g1tWj4NDqd41Ls29HBrWw/AKS3WlSh5wRN6juYQHs9jp61YSqxevmr+ jCsxvHrUgiShQKmtluoqIDE/ROlASwPtUy9j/yy8y1ouCY9Uj63QuzZ4i+N3e2WBBfUj 3ZyA== X-Gm-Message-State: AOAM530jVbgW3A5cIcoC1V9en8nvC+/1U5ToIjEMzfHOU0VvAJITAw0j 3tTmOAm47q1t0dPFEuCsTd5wr2VyXSTRG+pSLKw= X-Google-Smtp-Source: ABdhPJwKZFSwHCcMMSuluuFJ1l888qJcgXfLTWdvvGdBH6kxN6ItNbJgukzM1f76gSP5fSnSsPBdvvXXkTDlUzuZlJo= X-Received: by 2002:a02:7f57:: with SMTP id r84mr20835295jac.108.1620630242051; Mon, 10 May 2021 00:04:02 -0700 (PDT) MIME-Version: 1.0 References: <8517AD16-92CD-7743-92CC-D8ABC4DAAEC9@hxcore.ol> In-Reply-To: From: Fabien Imbault Date: Mon, 10 May 2021 09:03:50 +0200 Message-ID: To: Adrian Gropper Cc: Yaron Sheffer , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000e3cb2c05c1f461c8" Archived-At: Subject: Re: [GNAP] Resource Servers draft 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, 10 May 2021 07:04:09 -0000 --000000000000e3cb2c05c1f461c8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, seems a good place for an extension registry. The most important is that we can support both simple tokens (jwt or equivalent, ex paseto) as well a capability tokens (biscuit, macaroon, zcap-ld), and define what's commonly supported. Yet it seems easier to keep to the rule of not including linked data as a dependency in the main documents (but that's a personal opinion). Fabien Le dim. 9 mai 2021 =C3=A0 20:53, Adrian Gropper a =C3=A9crit : > macaroons, biscuits, and ZCAP-LD > > - Adrian > > On Sun, May 9, 2021 at 2:34 PM Fabien Imbault > wrote: > >> Hi Yaron, >> >> A comment on access token formats: I don't think we should define our ow= n >> format, but we can reference other documents such as >> https://datatracker.ietf.org/doc/html/draft-bertocci-oauth-access-token-= jwt >> and the references to macaroons, biscuits. >> >> The rest I believe makes good issues, most of which should be quick to >> fix. >> >> Cheers >> Fabien >> >> On Sun, May 9, 2021 at 4:00 PM Yaron Sheffer >> wrote: >> >>> Hi Editors, >>> >>> >>> >>> Here=E2=80=99s a bunch of comments to the latest version (Editor=E2=80= =99s Draft as of >>> today). Please respond with what is easy to fix, and what I should open= an >>> issue for. >>> >>> >>> >>> Thanks, >>> >>> Yaron >>> >>> >>> >>> - Abstract: better use more concrete terms than "piece of software". >>> Even if this creates a dependency on the Terminology section. >>> - Typo: by (AS). >>> - "client-facing discovery mechanism" - I'm not seeing any >>> client-facing protocol in the document (and it wouldn't belong here = anyway). >>> - Terminology: include a reference to the Terminology section of the >>> Core doc. >>> - Access Token Formats: IMO we should specify a minimal, generic >>> format in an appendix, as a non-normative starting point for develop= ers. It >>> would be better than having each implementation make its own mistake= s. >>> - Macaroons, biscuits, other baked goods: add a reference. >>> - AS Discovery: why do we need a "well known" URI? Either we use >>> GNAP Core to pass the AS address to the RS, and then we could pass a= full >>> URI, or we don't, and then how does the RS even know how to find the= AS? >>> - Protecting RS requests to the AS: the RS, by definition, owns >>> resources. This means that it needs to have a persistent identity, i= n >>> addition to the (ephemeral) keys being presented. Otherwise (especia= lly >>> with TOFU registration) we could easily have Resource Servers squatt= ing on >>> other people=E2=80=99s resources. It is very hard to manage the mapp= ing of RS to >>> resources if we don't have such a persistent identity. >>> - Token Introspection: it is not clear to what depth we are defining >>> the API: is it only the existence of the "introspect" endpoint? Or d= o we >>> define a minimal set of standard attributes that need to be returned= ? The >>> API would not be useful for interoperability unless we define some o= f the >>> returned attributes. At the very least: "active". >>> - "client instance's request" - should be "Resource Server's >>> request". >>> - And we should add: the AS MUST validate that the token is >>> appropriate for the RS that presented it, and return an error otherw= ise. >>> - Typo: internal link to "token format". >>> - IANA Considerations: the "well known" URL should be registered >>> (BTW, it's a well-known *URI*). Also, please list the registries tha= t we >>> need to establish. >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --000000000000e3cb2c05c1f461c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, seems a good place for an extension registry. T= he most important is that we can support both simple tokens (jwt or equival= ent, ex paseto) as well a capability tokens (biscuit, macaroon, zcap-ld), a= nd define what's commonly supported. Yet it seems easier to keep to the= rule of not including linked data as a dependency in the main documents (b= ut that's a personal opinion).=C2=A0

<= div dir=3D"auto">Fabien=C2=A0

Le dim. 9 mai 2021 =C3=A0 20:53, Ad= rian Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
=
macaroons, biscuits, = and ZCAP-LD

- Adrian

On Sun, May 9, 2021 at 2:34 PM= Fabien Imbault <fabien.imbault@gmail.com> wrote= :
Hi Yaron,=C2= =A0

A comment on access token formats: I don't think= we should define our own format, but we can reference other documents such= as=C2=A0https://datatracker.ietf.org/doc/html/draft-bertocci-oauth-access-token-j= wt and the references to macaroons, biscuits.

= The rest I believe makes good issues, most of which should be quick to fix.=

Cheers
Fabien

On Sun, May 9, 2021 = at 4:00 PM Yaron Sheffer <yaronf.ietf@gmail.com> = wrote:

Hi Editors,

=C2=A0

Here=E2=80=99= s a bunch of comments to the latest version (Editor=E2=80=99s Draft as of t= oday). Please respond with what is easy to fix, and what I should open an i= ssue for.

=C2=A0

Thanks,

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

=C2=A0<= u>

  • Abstract: better use more con= crete terms than "piece of software". Even if this creates a depe= ndency on the Terminology section.
  • Typo: by (AS).<= /span>
  • &qu= ot;client-facing discovery mechanism" - I'm not seeing any client-= facing protocol in the document (and it wouldn't belong here anyway).
  • Terminology: include a reference to the Terminology section of th= e Core doc.
  • Access Token Formats: IMO we should specify a minima= l, generic format in an appendix, as a non-normative starting point for dev= elopers. It would be better than having each implementation make its own mi= stakes.
  • Macaroons, biscuits, other baked goods: add a reference= .
  • AS Discovery: why do we need a "well known" URI? Eit= her we use GNAP Core to pass the AS address to the RS, and then we could pa= ss a full URI, or we don't, and then how does the RS even know how to f= ind the AS?
  • Protecting RS requests to the AS: the RS, by definit= ion, owns resources. This means that it needs to have a persistent identity= , in addition to the (ephemeral) keys being presented. Otherwise (especiall= y with TOFU registration) we could easily have Resource Servers squatting o= n other people=E2=80=99s resources. It is very hard to manage the mapping o= f RS to resources if we don't have such a persistent identity.
  • Token Introspection: it is not clear to what depth we are defining the A= PI: is it only the existence of the "introspect" endpoint? Or do = we define a minimal set of standard attributes that need to be returned? Th= e API would not be useful for interoperability unless we define some of the= returned attributes. At the very least: "active".<= /span>
  • &qu= ot;client instance's request" - should be "Resource Server= 9;s request".
  • <= span style=3D"font-size:11pt">And we should add: the AS MUST validate that = the token is appropriate for the RS that presented it, and return an error = otherwise.
  • Typo: internal link to "token format".
  • IANA Considerations: the "well known" URL should be regist= ered (BTW, it's a well-known *URI*). Also, please list the registries t= hat we need to establish.
--
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
--000000000000e3cb2c05c1f461c8-- From nobody Mon May 10 00:18:06 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 3B6983A0A31 for ; Mon, 10 May 2021 00:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, 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 wfpJt6sIQYuj for ; Mon, 10 May 2021 00:17:59 -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 A56BB3A0A2E for ; Mon, 10 May 2021 00:17:59 -0700 (PDT) Received: by mail-vs1-f42.google.com with SMTP id 66so7905166vsk.9 for ; Mon, 10 May 2021 00:17:59 -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=j/LTmdGix/QQRmY0csoVgJ4gV+oO7UefQonXgCvZlQs=; b=UuxF/JHT9nP/oCmdvbIiEo4iDrbnsPMKFidjEHQpFezb42FmeuT+8N9rq664Gg3ZDr dXUEDHSGok/8X0cMrwzaA5s8svjXh0vkPsjItkIL1fK/Er4ct4alhbwQCyhGuMeJwaMB 1KmWA9HrUeGB0IekC29aJ/NVjb/3Oi7d8WzI9yV9Dvvyca7WnP5CnEhxEP7wkS46n14q sqf1zs6rwwStNJ3XkF3pEuHO9i+apt1qqE+bo9qdejSu+GsBNjKi0bDReTpQsi/18eM4 f5Hn6O5jpyw7aSD32JeE6SZL7rW+5mfYDRRfRTG4GYZmyIo6Yz2ptnGh9wZSj4C8wvJr Iq0Q== X-Gm-Message-State: AOAM532dBNjjfeHvrZ+B3hA8mGS1diqyNsREF/HJT6oj5Dp//y5jzBR+ b59iPRfkIMXlmaBEQOfeu5jO9SkTIFPmP7JPDE0= X-Google-Smtp-Source: ABdhPJxkQjuruPN1XwTGr8x+YlH8p/9u7GhOGIBS00w456N+TKm0Dn9SRJSi0z89Eux0pORmuTibhMZh/58ytJPo7Vo= X-Received: by 2002:a67:c283:: with SMTP id k3mr18538349vsj.12.1620631078505; Mon, 10 May 2021 00:17:58 -0700 (PDT) MIME-Version: 1.0 References: <8517AD16-92CD-7743-92CC-D8ABC4DAAEC9@hxcore.ol> In-Reply-To: From: Adrian Gropper Date: Mon, 10 May 2021 03:17:47 -0400 Message-ID: To: Fabien Imbault Cc: GNAP Mailing List , Yaron Sheffer Content-Type: multipart/alternative; boundary="000000000000bf0f9b05c1f49396" Archived-At: Subject: Re: [GNAP] Resource Servers draft 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, 10 May 2021 07:18:04 -0000 --000000000000bf0f9b05c1f49396 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with not making LD a dependency but the SSI folks are in love so it=E2=80=99s nice to respect that. Adrian On Mon, May 10, 2021 at 3:04 AM Fabien Imbault wrote: > Yes, seems a good place for an extension registry. The most important is > that we can support both simple tokens (jwt or equivalent, ex paseto) as > well a capability tokens (biscuit, macaroon, zcap-ld), and define what's > commonly supported. Yet it seems easier to keep to the rule of not > including linked data as a dependency in the main documents (but that's a > personal opinion). > > Fabien > > Le dim. 9 mai 2021 =C3=A0 20:53, Adrian Gropper = a > =C3=A9crit : > >> macaroons, biscuits, and ZCAP-LD >> >> - Adrian >> >> On Sun, May 9, 2021 at 2:34 PM Fabien Imbault >> wrote: >> >>> Hi Yaron, >>> >>> A comment on access token formats: I don't think we should define our >>> own format, but we can reference other documents such as >>> https://datatracker.ietf.org/doc/html/draft-bertocci-oauth-access-token= -jwt >>> and the references to macaroons, biscuits. >>> >>> The rest I believe makes good issues, most of which should be quick to >>> fix. >>> >>> Cheers >>> Fabien >>> >>> On Sun, May 9, 2021 at 4:00 PM Yaron Sheffer >>> wrote: >>> >>>> Hi Editors, >>>> >>>> >>>> >>>> Here=E2=80=99s a bunch of comments to the latest version (Editor=E2=80= =99s Draft as of >>>> today). Please respond with what is easy to fix, and what I should ope= n an >>>> issue for. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Yaron >>>> >>>> >>>> >>>> - Abstract: better use more concrete terms than "piece of >>>> software". Even if this creates a dependency on the Terminology sec= tion. >>>> - Typo: by (AS). >>>> - "client-facing discovery mechanism" - I'm not seeing any >>>> client-facing protocol in the document (and it wouldn't belong here= anyway). >>>> - Terminology: include a reference to the Terminology section of >>>> the Core doc. >>>> - Access Token Formats: IMO we should specify a minimal, generic >>>> format in an appendix, as a non-normative starting point for develo= pers. It >>>> would be better than having each implementation make its own mistak= es. >>>> - Macaroons, biscuits, other baked goods: add a reference. >>>> - AS Discovery: why do we need a "well known" URI? Either we use >>>> GNAP Core to pass the AS address to the RS, and then we could pass = a full >>>> URI, or we don't, and then how does the RS even know how to find th= e AS? >>>> - Protecting RS requests to the AS: the RS, by definition, owns >>>> resources. This means that it needs to have a persistent identity, = in >>>> addition to the (ephemeral) keys being presented. Otherwise (especi= ally >>>> with TOFU registration) we could easily have Resource Servers squat= ting on >>>> other people=E2=80=99s resources. It is very hard to manage the map= ping of RS to >>>> resources if we don't have such a persistent identity. >>>> - Token Introspection: it is not clear to what depth we are >>>> defining the API: is it only the existence of the "introspect" endp= oint? Or >>>> do we define a minimal set of standard attributes that need to be r= eturned? >>>> The API would not be useful for interoperability unless we define s= ome of >>>> the returned attributes. At the very least: "active". >>>> - "client instance's request" - should be "Resource Server's >>>> request". >>>> - And we should add: the AS MUST validate that the token is >>>> appropriate for the RS that presented it, and return an error other= wise. >>>> - Typo: internal link to "token format". >>>> - IANA Considerations: the "well known" URL should be registered >>>> (BTW, it's a well-known *URI*). Also, please list the registries th= at we >>>> need to establish. >>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> --000000000000bf0f9b05c1f49396 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with not making LD a dependency but the SSI folks= are in love so it=E2=80=99s nice to respect that.
<= br>
Adrian

=
On Mon, May 10, 2021 at 3:04 AM Fabie= n Imbault <fabien.imbault@gm= ail.com> wrote:
Yes, seems a good place for an extension registry. The most impo= rtant is that we can support both simple tokens (jwt or equivalent, ex pase= to) as well a capability tokens (biscuit, macaroon, zcap-ld), and define wh= at's commonly supported. Yet it seems easier to keep to the rule of not= including linked data as a dependency in the main documents (but that'= s a personal opinion).=C2=A0

Fabien=C2=A0

Le dim. 9 mai 2021 =C3= =A0 20:53, Adrian Gropper <agropper@healthurl.com> a =C3=A9cr= it=C2=A0:
macaroon= s, biscuits, and ZCAP-LD

- Adrian

On Sun, May 9, 20= 21 at 2:34 PM Fabien Imbault <fabien.imbault@gmail.com<= /a>> wrote:
On Sun, = May 9, 2021 at 4:00 PM Yaron Sheffer <yaronf.ietf@gmail.co= m> wrote:

Hi Editors,

=C2=A0=

Her= e=E2=80=99s a bunch of comments to the latest version (Editor=E2=80=99s Dra= ft as of today). Please respond with what is easy to fix, and what I should= open an issue for.

=C2=A0

Thanks,

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

=C2=A0

    Abstract: better = use more concrete terms than "piece of software". Even if this cr= eates a dependency on the Terminology section.Typo: by (AS).=
  • "client-facing discovery mechanism" - I'm not seeing= any client-facing protocol in the document (and it wouldn't belong her= e anyway).
  • Terminology: include a reference to the Terminology s= ection of the Core doc.
  • Access Token Formats: IMO we should spec= ify a minimal, generic format in an appendix, as a non-normative starting p= oint for developers. It would be better than having each implementation mak= e its own mistakes.
  • = Macaroons, biscuits, other baked goods: add = a reference.
  • AS Discovery: why do we need a "well known&quo= t; URI? Either we use GNAP Core to pass the AS address to the RS, and then = we could pass a full URI, or we don't, and then how does the RS even kn= ow how to find the AS?
  • Protecting RS requests to the AS: the RS,= by definition, owns resources. This means that it needs to have a persiste= nt identity, in addition to the (ephemeral) keys being presented. Otherwise= (especially with TOFU registration) we could easily have Resource Servers = squatting on other people=E2=80=99s resources. It is very hard to manage th= e mapping of RS to resources if we don't have such a persistent identit= y.
  • Token Introspection: it is not clear to what depth we are def= ining the API: is it only the existence of the "introspect" endpo= int? Or do we define a minimal set of standard attributes that need to be r= eturned? The API would not be useful for interoperability unless we define = some of the returned attributes. At the very least: "active".<= /u>
  • "client instance's request" - should be "Resourc= e Server's request".
  • And we should add: the AS MUST val= idate that the token is appropriate for the RS that presented it, and retur= n an error otherwise.
  • Typo: internal link to "token format&= quot;.
  • IANA Considerations: the "well known" URL sho= uld be registered (BTW, it's a well-known *URI*). Also, please list the= registries that we need to establish.
=
--
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
--000000000000bf0f9b05c1f49396-- From nobody Mon May 10 00:27: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 5A30F3A0AEE for ; Mon, 10 May 2021 00:27:28 -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 hwhBEFWYw5SK for ; Mon, 10 May 2021 00:27:24 -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 3494E3A0AF3 for ; Mon, 10 May 2021 00:27:24 -0700 (PDT) Received: by mail-il1-x130.google.com with SMTP id m7so3886510ilg.9 for ; Mon, 10 May 2021 00:27: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=R2yJPS81GA0A3L5Ly3FCvYqG39gvG61lJyLQvb4rum4=; b=aO8bZZz8xhPDNnNyHg4lbT6b7JuZGL2ZJXBxjmzsrf71McsoolzEFnH/N/AAOcqONB aEPyn5g0SFWb1sEqtRUKL1hU+3SzphJ1gSBYikxWpiV+iLArT6LMjWdOx2yt71r4oHwc 4jWrxb1L8kKHspmcQW+uU8ad1PBiTNGWd7P0yDolX7JlFODbPx8JHfI9Ip/XictWZ+YU x/8ZKTE9x/BUBiuR0eA3cdk2XtoU7frsmFnhnBUhaZw8Z3/vbkEsvrm+LWVNQl/UH1YS Ds67XXLS8kvvtrzXFCUEckM2FEUKT2VEOJbeYPSnin3Ugdf9BOZQ9Ju2FHBX8rjk94T8 4bwQ== 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=R2yJPS81GA0A3L5Ly3FCvYqG39gvG61lJyLQvb4rum4=; b=X2qy7HDABypGhGKEn0X567idf4KI5CIaTyl3ORf3jR7Pc6faPiHbYKDGOSWu+0oIXw 7YBVvDjfKXjL1locRzuFm2qpVJya5LTStgpLtr7A1AK66mMGdQ3A7bwjiA3QbSJUTvAi dMllRN5vYJVF9Fp23H34U9jbYNEd82+pCpTq9yl6Cp5nCyFg4cc1H5pXH1zhmnFp/ohG 1v4RUighT1JTE79ef/58tLUrJ0qWUnXS6DaFu+CwgYQKlaNQqDS9eAF32TVmkrHC6j/9 MWKibVMWygghrPVlUkUwPGmAonfdI3orPa2q+i4sdqxV6KqWpuGn4T5iALr8E2sgUdcc QTaA== X-Gm-Message-State: AOAM533ukWCkV2T9GOo1gNksXIHccw/KqPNQfmpqZbAoExtPis23zbpl arMMe5uU7vBV7roUflzkZDqN19NM2vRWiE9wJOA= X-Google-Smtp-Source: ABdhPJwdGgD/qjCFW5qtAlEmOPB4R2lCfsJe3ocvyxWOVwOnHBosLWyjfZrtXseGFBaPuRBIf9QipYRUG0UglG8qTKc= X-Received: by 2002:a05:6e02:1708:: with SMTP id u8mr21141460ill.188.1620631642635; Mon, 10 May 2021 00:27:22 -0700 (PDT) MIME-Version: 1.0 References: <8517AD16-92CD-7743-92CC-D8ABC4DAAEC9@hxcore.ol> In-Reply-To: From: Fabien Imbault Date: Mon, 10 May 2021 09:27:11 +0200 Message-ID: To: Adrian Gropper Cc: GNAP Mailing List , Yaron Sheffer Content-Type: multipart/alternative; boundary="0000000000005f013805c1f4b563" Archived-At: Subject: Re: [GNAP] Resource Servers draft 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, 10 May 2021 07:27:29 -0000 --0000000000005f013805c1f4b563 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, for DIDs it makes sense as it's very established now. But capability tokens don't have that chance yet, so a registry seems to me like a better idea, especially if they require that kind of extra dependency. None of them have been defined as an RFC yet. I could propose to do the work for biscuits, together with the good folks of CleverCloud. Fabien On Mon, May 10, 2021 at 9:17 AM Adrian Gropper wrote: > I agree with not making LD a dependency but the SSI folks are in love so > it=E2=80=99s nice to respect that. > > Adrian > > On Mon, May 10, 2021 at 3:04 AM Fabien Imbault > wrote: > >> Yes, seems a good place for an extension registry. The most important is >> that we can support both simple tokens (jwt or equivalent, ex paseto) as >> well a capability tokens (biscuit, macaroon, zcap-ld), and define what's >> commonly supported. Yet it seems easier to keep to the rule of not >> including linked data as a dependency in the main documents (but that's = a >> personal opinion). >> >> Fabien >> >> Le dim. 9 mai 2021 =C3=A0 20:53, Adrian Gropper = a >> =C3=A9crit : >> >>> macaroons, biscuits, and ZCAP-LD >>> >>> - Adrian >>> >>> On Sun, May 9, 2021 at 2:34 PM Fabien Imbault >>> wrote: >>> >>>> Hi Yaron, >>>> >>>> A comment on access token formats: I don't think we should define our >>>> own format, but we can reference other documents such as >>>> https://datatracker.ietf.org/doc/html/draft-bertocci-oauth-access-toke= n-jwt >>>> and the references to macaroons, biscuits. >>>> >>>> The rest I believe makes good issues, most of which should be quick to >>>> fix. >>>> >>>> Cheers >>>> Fabien >>>> >>>> On Sun, May 9, 2021 at 4:00 PM Yaron Sheffer >>>> wrote: >>>> >>>>> Hi Editors, >>>>> >>>>> >>>>> >>>>> Here=E2=80=99s a bunch of comments to the latest version (Editor=E2= =80=99s Draft as of >>>>> today). Please respond with what is easy to fix, and what I should op= en an >>>>> issue for. >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yaron >>>>> >>>>> >>>>> >>>>> - Abstract: better use more concrete terms than "piece of >>>>> software". Even if this creates a dependency on the Terminology se= ction. >>>>> - Typo: by (AS). >>>>> - "client-facing discovery mechanism" - I'm not seeing any >>>>> client-facing protocol in the document (and it wouldn't belong her= e anyway). >>>>> - Terminology: include a reference to the Terminology section of >>>>> the Core doc. >>>>> - Access Token Formats: IMO we should specify a minimal, generic >>>>> format in an appendix, as a non-normative starting point for devel= opers. It >>>>> would be better than having each implementation make its own mista= kes. >>>>> - Macaroons, biscuits, other baked goods: add a reference. >>>>> - AS Discovery: why do we need a "well known" URI? Either we use >>>>> GNAP Core to pass the AS address to the RS, and then we could pass= a full >>>>> URI, or we don't, and then how does the RS even know how to find t= he AS? >>>>> - Protecting RS requests to the AS: the RS, by definition, owns >>>>> resources. This means that it needs to have a persistent identity,= in >>>>> addition to the (ephemeral) keys being presented. Otherwise (espec= ially >>>>> with TOFU registration) we could easily have Resource Servers squa= tting on >>>>> other people=E2=80=99s resources. It is very hard to manage the ma= pping of RS to >>>>> resources if we don't have such a persistent identity. >>>>> - Token Introspection: it is not clear to what depth we are >>>>> defining the API: is it only the existence of the "introspect" end= point? Or >>>>> do we define a minimal set of standard attributes that need to be = returned? >>>>> The API would not be useful for interoperability unless we define = some of >>>>> the returned attributes. At the very least: "active". >>>>> - "client instance's request" - should be "Resource Server's >>>>> request". >>>>> - And we should add: the AS MUST validate that the token is >>>>> appropriate for the RS that presented it, and return an error othe= rwise. >>>>> - Typo: internal link to "token format". >>>>> - IANA Considerations: the "well known" URL should be registered >>>>> (BTW, it's a well-known *URI*). Also, please list the registries t= hat we >>>>> need to establish. >>>>> >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> --0000000000005f013805c1f4b563 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, for DIDs it makes sense as it's very established = now.=C2=A0
But capability tokens don't have that chance yet, so a r= egistry seems to me like a better idea, especially if they require that kin= d of extra dependency. None of them have been defined as an RFC yet. I coul= d propose to do the work for biscuits,=C2=A0together with the good folks of= CleverCloud.=C2=A0

Fabien

On Mon, May 10, 20= 21 at 9:17 AM Adrian Gropper <= agropper@healthurl.com> wrote:
I agree with not making LD a depend= ency but the SSI folks are in love so it=E2=80=99s nice to respect that.

Adrian

On Mon, May 10,= 2021 at 3:04 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Yes, = seems a good place for an extension registry. The most important is that we= can support both simple tokens (jwt or equivalent, ex paseto) as well a ca= pability tokens (biscuit, macaroon, zcap-ld), and define what's commonl= y supported. Yet it seems easier to keep to the rule of not including linke= d data as a dependency in the main documents (but that's a personal opi= nion).=C2=A0

Fabien=C2=A0

Le dim. 9 mai 2021 =C3=A0 20:53, Adrian= Gropper <agropper@healthurl.com> a =C3=A9crit=C2=A0:
macaro= ons, biscuits, and ZCAP-LD

- Adrian

On Sun, May 9, = 2021 at 2:34 PM Fabien Imbault <fabien.imbault@gmail.co= m> wrote:
Hi Yaron,=C2=A0

A com= ment on access token formats: I don't think we should define our own fo= rmat, but we can reference other documents such as=C2=A0https://datatracker.ietf.o= rg/doc/html/draft-bertocci-oauth-access-token-jwt and the references to= macaroons, biscuits.

The rest I believe makes goo= d issues, most of which should be quick to fix.

Ch= eers
Fabien

On Sun, May 9, 2021 at 4:00 PM Yaron Sheffer <= ;yaronf.ietf@gmail.com> wrote:

Hi Editors,

=C2=A0=

Here=E2=80= =99s a bunch of comments to the latest version (Editor=E2=80=99s Draft as o= f today). Please respond with what is easy to fix, and what I should open a= n issue for.

=C2=A0

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron<= /span>

=C2= =A0

  • Abstract: better use mo= re concrete terms than "piece of software". Even if this creates = a dependency on the Terminology section.
  • Typo: by (AS).
  • "client-facing discovery mechanism" - I'm not seeing any c= lient-facing protocol in the document (and it wouldn't belong here anyw= ay).
  • Terminology: include a reference to the Terminology section= of the Core doc.
  • Access Token Formats: IMO we should specify a = minimal, generic format in an appendix, as a non-normative starting point f= or developers. It would be better than having each implementation make its = own mistakes.
  • Macaroons, biscuits, other baked goods: add a refe= rence.
  • AS Discovery: why do we need a "well known" U= RI? Either we use GNAP Core to pass the AS address to the RS, and then we c= ould pass a full URI, or we don't, and then how does the RS even know h= ow to find the AS?
  • <= span style=3D"font-size:11pt">Protecting RS requests to the AS: the RS, by = definition, owns resources. This means that it needs to have a persistent i= dentity, in addition to the (ephemeral) keys being presented. Otherwise (es= pecially with TOFU registration) we could easily have Resource Servers squa= tting on other people=E2=80=99s resources. It is very hard to manage the ma= pping of RS to resources if we don't have such a persistent identity.
  • Token Introspection: it is not clear to what depth we are definin= g the API: is it only the existence of the "introspect" endpoint?= Or do we define a minimal set of standard attributes that need to be retur= ned? The API would not be useful for interoperability unless we define some= of the returned attributes. At the very least: "active".<= u>
  • "client instance's request" - should be "Resource Se= rver's request".
  • And we should add: the AS MUST validat= e that the token is appropriate for the RS that presented it, and return an= error otherwise.
  • Typo: internal link to "token format"= ;.
  • IANA Considerations: the "well known" URL should be= registered (BTW, it's a well-known *URI*). Also, please list the regis= tries that we need to establish.
--
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
--0000000000005f013805c1f4b563-- From nobody Wed May 12 10:33: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 F031A3A1233 for ; Wed, 12 May 2021 10:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki.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 AQ_73VDApO4k for ; Wed, 12 May 2021 10:33:40 -0700 (PDT) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B9D33A1229 for ; Wed, 12 May 2021 10:33:39 -0700 (PDT) Received: by mail-il1-x12c.google.com with SMTP id c16so1946341ilo.1 for ; Wed, 12 May 2021 10:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=tlXZEcJ80IenQgAbqC93ZtbGEE3S0NwiDTLDq2LGa5E=; b=klVzilP+Ex1F77qSjWOvTiZsKt9bd3Vvt2du7K//dNiff7MKTYDLKZykah7rF5Dj6j cfKV9aY7F8Yq+06BRy5ZcjQxBd7Fa4BgMVv9/sBQLe70h90JGXa9ZLQjRIEyBPiL9jdV 7uLCovu9NlPYVPJuo2+xAdKB/HTz9c4ktCulqRuAf2ZHZAl9hd2PVKuvnx5bZDqNmv4T 0dyEtS8nrvBwhNMFtZfcDN6ECpHNGmzD4x7YpGbvFuMSQBdktTdmU+q4J3QJEqOj6N7U QDwj4kU4i5+wlWOmnrFHRKx/k/OOiuK1yAjHpRtG8vcDL+tCkMVZnK3dvyulpS7Skecu uWrQ== 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=tlXZEcJ80IenQgAbqC93ZtbGEE3S0NwiDTLDq2LGa5E=; b=kGo7PJYcaw5cXpj8HG2Hz+2O+Ty1a6OpvglvyzW17A0nxf6vzFoq/NqNCLEmraAaE4 Q/7QYN0Sy/G3RtK89vJuRrP3PBzAPZq+dB16tL4dDcThp0mVjjLT20fgOjhvkItTDAdd mw11uij7jHvKSzSzqMTFhbo48f+rsEjHLKEgVuDRjWzAaztq+3tbKJzFBg385oSzQAmY rSrgOar3RffrSqrSq9/RZcQA/v5L8IBDhzRqmwL7ulnSxzyveTIFQr+QErEHKkk72OCy QWdF2oFopDugWVxGvzVrtogxCfvLdMTeAcFbqDh/48tTObrO60Twiz9tCUT2wHiL9jqa Kt7w== X-Gm-Message-State: AOAM533iBwC6WC+E/dSdn/KdEY3Ro6AYZvYvxj5PspCiAsRWF4gu/RBG EPOC4R/P3HLSKG8S8cpBu0zHZiA2TFIrBg== X-Google-Smtp-Source: ABdhPJwab1KhZdW+LyD0b16BwoQFf4bsXzb6fMsjHv7dog3Eb+/in3nhIpOSuGo/I5MEAV/9QfP8FA== X-Received: by 2002:a05:6e02:1be6:: with SMTP id y6mr21626264ilv.242.1620840817890; Wed, 12 May 2021 10:33:37 -0700 (PDT) Received: from mail-il1-f178.google.com (mail-il1-f178.google.com. [209.85.166.178]) by smtp.gmail.com with ESMTPSA id g11sm195749ilq.38.2021.05.12.10.33.37 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 May 2021 10:33:37 -0700 (PDT) Received: by mail-il1-f178.google.com with SMTP id o9so15694042ilh.6 for ; Wed, 12 May 2021 10:33:37 -0700 (PDT) X-Received: by 2002:a05:6e02:148:: with SMTP id j8mr20858115ilr.196.1620840817038; Wed, 12 May 2021 10:33:37 -0700 (PDT) MIME-Version: 1.0 From: Aaron Parecki Date: Wed, 12 May 2021 10:33:25 -0700 X-Gmail-Original-Message-ID: Message-ID: To: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000231b8d05c22569a5" Archived-At: Subject: [GNAP] Editor's Updates 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, 12 May 2021 17:33:45 -0000 --000000000000231b8d05c22569a5 Content-Type: text/plain; charset="UTF-8" The editors met today and processed a number of issues and pull requests. The following pull requests have been reviewed by the editors and are marked Pending Merge: #259: add "privileges" field https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/259 An editorial pull request was merged: #11: minor editorial fixes https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/11 Several issues have been moved from the core repo to the resource servers repo. The following issues have been marked Pending Close: #3: Token formats can be advertised by both AS and RS https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/3 #192: The first figure in section 1.4 should be split and revisited https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/192 The editors also closed several issues as duplicates of previous discussions https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/252 https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/13 https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/9 https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/8 https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/6 --- Aaron Parecki https://aaronparecki.com --000000000000231b8d05c22569a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The editors met today and processed a number of issue= s and pull requests.

The following pull requests h= ave been reviewed by the editors and are marked Pending Merge:
#259: add "privileges" field

An editorial pull request was merged:

#11: minor= editorial fixes

Several issues have been move= d from the core repo to the resource servers repo.

The following issues have been marked Pending Close:

<= div>
#3: Token formats can be advertised by both AS and RS
ht= tps://github.com/ietf-wg-gnap/gnap-resource-servers/issues/3
<= div>

#192:=C2=A0The first figure in section = 1.4 should be split and revisited

The editors = also closed several=C2=A0issues as duplicates of previous discussions
=


---
Aaron Parecki

<= /div>
--000000000000231b8d05c22569a5-- From nobody Sun May 16 15:36: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 47FD43A1BC2 for ; Sun, 16 May 2021 15:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 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_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=HY4QbloL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MYPNuRN9 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbSsNOqkU9Js for ; Sun, 16 May 2021 15:36:00 -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 EB5E33A1BC4 for ; Sun, 16 May 2021 15:35:59 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 1DE695C01F1 for ; Sun, 16 May 2021 18:20:10 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sun, 16 May 2021 18:20:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm2; bh=pvM51f/4IOW F7/vPJE1IoATfNEykYSvVYlV7iR5Xi/k=; b=HY4QbloL6t8iKSQN3TNo/G/Ysvn DNSMq6xtVdCaKONRwBpD9Qn8j5TU1V+5wWW6HTCm+cDfZewJhUAHYxz4SNGYlrMx LwFV9yDNOeaugFYPAtZ6E/6Gi6Nv+uYtRiSIrRxf69M27DY7lCDOFtmFnPOfHvPc VSQvD19Y5d7ylxxq8BSlsKgJ/kriApDLZYuxSyK0DsSWjo40JYvNN1awIj+J8YCt m3P+iot+XBcjjfX+SaudYrOuU1ch/QpKfcIe9CVFymCxDVLTgVFxpotG4cYqYgeM pduyt/aI6MvU3PMIz8oR7CErjwWkz/jGsKCum7YnFLkcoaNsqw/lv0FLD9A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:from:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=pvM51f/4IOWF7/vPJE1IoATfNEykYSvVYlV7iR5Xi/k=; b=MYPNuRN9 LtgSCAufAuYUUtUoW0RigLGI7NZq+/4Ox0jmqGjKUdBUmIn9SVlqecgXXNrJDYF6 3R2qHnYuUcVMXImKjRYcbENE+teJIgy2feXzKNyTfBQZpl/F70/8LHwMejAlnxBc 6DMYC/ncNsxA3CJxlbDSkIcS25UwFQk6qqFtGIZqp/23pWNAhP5VefvxPZtSqKVZ wpYDmX99FlHELR9HB+Cz6WPPkq74xvphSaLn/6cM9pfHs9S0mFr1XiHYoNZ42xjU M61ykfBCBuKWNyRpzYfcB+30MSV9jWVSWRJpVE9bK6LqWHSJd0jtc7SxG8dxtRBZ TSfXMDJ2CG6FIg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeigedgtdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucfkphepuddtgedrvddugedrfeekrddvvdenucevlhhushhtvghrufhiiigvpeef necurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvphhlhiesmhhnohhtrd hnvght X-ME-Proxy: Received: from fv-az290-521.z45yk40qnouupoc55gb0v1wkoc.jx.internal.cloudapp.net (unknown [104.214.38.22]) by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 16 May 2021 18:20:09 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============7459442105598016719==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20210516223559.EB5E33A1BC4@ietfa.amsl.com> Date: Sun, 16 May 2021 15:35:59 -0700 (PDT) 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, 16 May 2021 22:36:06 -0000 --===============7459442105598016719== 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 (+1/-1/=F0=9F=92=AC15) 1 issues created: - Move client-facing sections back from RS draft (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/260=20 3 issues received 15 new comments: - #252 Interaction (1) between the Client Instance and the RS as describe= d in the first figure (1 by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/252=20 - #244 Refactoring the internals of access request (12 by Denisthemalice,= agropper, fimbault, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/244=20 - #192 The first figure in section 1.4 should be split and revisited (2 b= y Denisthemalice, aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/192 [Pending = Close]=20 1 issues closed: - Interaction (1) between the Client Instance and the RS as described in = the first figure https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/= 252=20 * ietf-wg-gnap/gnap-resource-servers (+14/-4/=F0=9F=92=AC36) 14 issues created: - AS-RO policy delegation (by fimbault) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/25=20 - Token Introspection (by jricher) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/24=20 - RS Token derivation (by jricher) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/23=20 - RS-registered resource reference handle arity (by jricher) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/22=20 - IANA Considerations (by yaronf) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/21=20 - Token Introspection security check (by yaronf) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/20=20 - Token Introspection API: level of detail (by yaronf) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/19=20 - RS persistent identity (by yaronf) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/18=20 - What do we mean by AS discovery? (by yaronf) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/17=20 - References to existing AT formats (by yaronf) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/16=20 - Propose a generic access token format (by yaronf) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/15=20 - Ref in Terminology (by yaronf) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/14=20 - Description of discovery mechanism in Intro (by yaronf) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/13=20 - More precision in Abstract (by yaronf) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/12=20 13 issues received 36 new comments: - #25 AS-RO policy delegation (6 by Denisthemalice, agropper, fimbault) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/25=20 - #20 Token Introspection security check (3 by Denisthemalice, jricher, y= aronf) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/20=20 - #19 Token Introspection API: level of detail (1 by jricher) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/19=20 - #18 RS persistent identity (3 by aaronpk, jricher, yaronf) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/18=20 - #17 What do we mean by AS discovery? (4 by jricher, yaronf) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/17=20 - #16 References to existing AT formats (2 by aaronpk, fimbault) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/16=20 - #15 Propose an access token model (5 by aaronpk, fimbault, yaronf) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/15=20 - #13 Description of discovery mechanism in Intro (1 by aaronpk) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/13=20 - #9 Capabilities only (i.e. actions) are supported. ACLs (i.e. attribute= s associated with a subject) should also be supported (1 by aaronpk) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/9=20 - #8 A model where the AS and the RS do not need to establish a prior rel= ation relationship should be able to co-exist (2 by Denisthemalice, aaronpk) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/8=20 - #7 Trust relationships between a RS and an AS (1 by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/7=20 - #6 The text should say when the RS SHALL respond to the client with an = authentication header indicating an error (2 by Denisthemalice, aaronpk) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/6=20 - #3 Token formats can also be advertised both by AS and RS (5 by Denisth= emalice, aaronpk, jricher) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/3 [Pending= Close]=20 4 issues closed: - Description of discovery mechanism in Intro https://github.com/ietf-wg-= gnap/gnap-resource-servers/issues/13=20 - Capabilities only (i.e. actions) are supported. ACLs (i.e. attributes a= ssociated with a subject) should also be supported https://github.com/ietf= -wg-gnap/gnap-resource-servers/issues/9=20 - A model where the AS and the RS do not need to establish a prior relati= on relationship should be able to co-exist https://github.com/ietf-wg-gnap/= gnap-resource-servers/issues/8=20 - The text should say when the RS SHALL respond to the client with an aut= hentication header indicating an error https://github.com/ietf-wg-gnap/gnap= -resource-servers/issues/6=20 Pull requests ------------- * ietf-wg-gnap/core-protocol (+2/-0/=F0=9F=92=AC5) 2 pull requests submitted: - re-import rs-first discovery method from gnap-rs, closes #260 (by jrich= er) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/261=20 - add access field (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/259=20 2 pull requests received 5 new comments: - #261 re-import rs-first discovery method from gnap-rs, closes #260 (1 b= y netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/261=20 - #259 add privileges field (4 by fimbault, jricher, netlify, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/259 [Pending Me= rge]=20 * ietf-wg-gnap/gnap-resource-servers (+2/-1/=F0=9F=92=AC2) 2 pull requests submitted: - move client-facing rs-first discovery back to gnap core, addresses ietf= -wg-gnap/gnap-core-protocol#260 (by jricher) https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/26=20 - Minor edits (by yaronf) https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/11=20 2 pull requests received 2 new comments: - #26 move client-facing rs-first discovery back to gnap core, addresses = ietf-wg-gnap/gnap-core-protocol#260 (1 by netlify) https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/26=20 - #11 Minor edits (1 by netlify) https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/11=20 1 pull requests merged: - Minor edits https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/11 [Editoria= l]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol * https://github.com/ietf-wg-gnap/gnap-resource-servers --===============7459442105598016719== 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 May 16, 2021

Events without label "editorial"

Issues

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

1 issues created:

3 issues received 15 new comments:

1 issues closed:

ietf-wg-gnap/gnap-resource-servers (+14/-4/=F0=9F=92=AC36)

14 issues created:

13 issues received 36 new comments:

4 issues closed:

Pull requests

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

2 pull requests submitted:

2 pull requests received 5 new comments:

ietf-wg-gnap/gnap-resource-servers (+2/-1/=F0=9F=92=AC2)

2 pull requests submitted:

2 pull requests received 2 new comments:

1 pull requests merged:

Repositories tracked by this digest:

--===============7459442105598016719==-- From nobody Sun May 23 01:46: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 1ED033A0A79 for ; Sun, 23 May 2021 01:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 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, 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=CtAks0xq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jT6vnk1J Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvrscSAfvvgt for ; Sun, 23 May 2021 01:46:06 -0700 (PDT) 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 6BE783A0A88 for ; Sun, 23 May 2021 01:46:06 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id F1D5D11F5 for ; Sun, 23 May 2021 03:46:40 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sun, 23 May 2021 03:46:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm2; bh=A//I2FP2ryE 8tolFmshqXl1z3XmC7CuPArwyyf+mHzY=; b=CtAks0xqPUK5feIL2GzSA0zNx2P apWeUI+v9MWQCJ+HsqQYT8dhqsTb8RxtDH5VgO5L2oyHK6PKhOBUiesCEfZVD/zk ZAqQBbko9ZNIXVmM7K7Kc2XrTkeLXG6MLNjApxfqSkyuCwugMFyXLKWls9lK2lb0 kzgUPPRv2AtJHjFGUZQNnODnvaf0bvX1HAO5J9VgPInXl2YW4u+TZg1na+Vv5RSL nBBGvY4imGRsJKn8nCGnDYXlod9Gr1yVWSlpxzdp9gTxLuIbLiAuAaRVa4TNVb0z 5obQ5u+5q7T1SWJ7U4ZWSBPI1tkETR8JizSiY3Vdl2/mMSxeQs68J3Aw9ug== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:from:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=A//I2FP2ryE8tolFmshqXl1z3XmC7CuPArwyyf+mHzY=; b=jT6vnk1J DPvGfPOaxgG2TeB9Y/Udi0/B7DCAXnlpgMB+2LAwGxU/No9NDqYfeoBP55Kt1NW2 V+JlsGy9rPlBFwjjBYdRUSNlXXtErgjSJ0nyO6xpE18NETsFSglPa0WMYxIhH5F9 Ajov1SbLvccES5AOZVY0V+jy2j367+Bit8AcXgvYYRbvTlH/qUxOboWFt+KlZosz Jlh8OtAxOwmSAVKN5NUnurKvugdPxkjK1DXsO41n5jlm7gCaM+e42OfrpT4sAk1r FDuBbypuBCy8+gGXzdJoARI+nhC+61LzDiBSrbUA2cnYGLDphmrdwQNDgzldjohR Gy7PdUTUFVFUDg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdejiedguddvgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecupfhoucgurghtvgcufhhivghlugculdegledmne cujfgurheptggghffvufesrgdttdertddtjeenucfhrhhomheptfgvphhoshhithhorhih ucettghtihhvihhthicuufhumhhmrghrhicuuehothcuoeguohgpnhhothgprhgvphhlhi esmhhnohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeekfedvudetjedvfeekheeiveeu gfefhfetteevgeffkefffeetffdvleehudeiteenucffohhmrghinhepghhithhhuhgsrd gtohhmnecukfhppedvfedruddtvddrudekiedrudehheenucevlhhushhtvghrufhiiigv pedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvphhlhiesmhhnoh htrdhnvght X-ME-Proxy: Received: from fv-az290-665.z45yk40qnouupoc55gb0v1wkoc.jx.internal.cloudapp.net (unknown [23.102.186.155]) by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 23 May 2021 03:46:40 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============0479981708882765675==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20210523084606.6BE783A0A88@ietfa.amsl.com> Date: Sun, 23 May 2021 01:46:06 -0700 (PDT) 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, 23 May 2021 08:46:20 -0000 --===============0479981708882765675== 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/gnap-resource-servers (+0/-0/=F0=9F=92=AC4) 2 issues received 4 new comments: - #25 AS-RO policy delegation (3 by Denisthemalice, fimbault) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/25=20 - #16 References to existing AT formats (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/16=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol * https://github.com/ietf-wg-gnap/gnap-resource-servers --===============0479981708882765675== 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 May 23, 2021

Events without label "editorial"

Issues

ietf-wg-gnap/gnap-resource-servers (+0/-0/=F0=9F=92=AC4)

2 issues received 4 new comments:

Repositories tracked by this digest:

--===============0479981708882765675==-- From nobody Wed May 26 10:41:24 2021 Return-Path: X-Original-To: txauth@ietf.org Delivered-To: txauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B5C3A11A4; Wed, 26 May 2021 10:41:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: txauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162205087774.30077.7094192531095249364@ietfa.amsl.com> Date: Wed, 26 May 2021 10:41:17 -0700 Archived-At: Subject: [GNAP] Grant Negotiation and Authorization Protocol (gnap) WG Virtual Meeting: 2021-06-15 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2021 17:41:18 -0000 The Grant Negotiation and Authorization Protocol (gnap) WG will hold a virtual interim meeting on 2021-06-15 from 19:00 to 20:00 Asia/Jerusalem (16:00 to 17:00 UTC). Agenda: TBD Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=514cd706-0d04-4076-aa10-428f41ca57f5 From nobody Thu May 27 01:57: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 9D3DE3A146F for ; Thu, 27 May 2021 01:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 0qliRDTOoTY8 for ; Thu, 27 May 2021 01:57:13 -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 C55063A1471 for ; Thu, 27 May 2021 01:57:13 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id m1so3437812ilg.10 for ; Thu, 27 May 2021 01:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=PNnCSAAotsdk0cbVepZNJ1WOyNzPcxm9BgpSvig9iuo=; b=sTY5Tltd/OS2upoN4DBQxEsQhO5T8bFnVizLAmUuz8vcUqkEflSLDSgNtBjgTzt+jC XKx1eNc+QANCF8y6r7p6n7EFCFJdDOti1JbcsVAe6PtKlsg45LKss3rDC6antA2gMYyS jHjxFewl5mBSeOdo6IPbPf1Bw9v2JkDw4u5Ysf6wI5r9hByGoSCDSal6DujNf2PmUTFs hQtKs5Ui7XUsfie+5OVERf8at3buwQAGNTbKrCf+ipnfkSEtiia7k8F6qjfTDAncxLlP OmO2+S2bO0ApOK6OywhLNi4m4ntSRe6AgqTf8qg/rAjWnGxlwgCaJU5CmTU6CtdhzTAg GG/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:from:date:message-id:subject:to; bh=PNnCSAAotsdk0cbVepZNJ1WOyNzPcxm9BgpSvig9iuo=; b=ZzfyAHA11JVkzbO/vNFoql3rvh77YiHLV+RpbGZ2r3dYalXfMKQarUUbWa/BlGaKnL p/KTuA8+YHBPxJHAlyeq39QlxYhdqqLTFZ4ga/ogpPYquAQsyQsuL7rQtqZCY2m9AETT tF+8r9Ls6l8iReT1bPbjQ7+qh9DcCcWJmkCQdI5lIfMzWxb9GoR2sawnldyQNqBdlYVs dPVgxXjSTLgYNEqGUCagP4D8uOEcD3ni+bypqCyps9dRywHkeoIsCmDRIl9XdD+4QWez ABqEmlgS6micmvu2d8y8xarhQkwO+2V9MB6F740lX3G3lnHbJ1ZZ+ZWfxcxb2sWHVDTE mP0A== X-Gm-Message-State: AOAM530wSaW0vQZ+EVr3GdT8YLVoKGfPzQH8EVEUh34cq/z8ECOTcGxP roCyqylqrGroGywalDXK696p3GmsLLbgqJ/Ik1TYWZWAnSl6/g== X-Google-Smtp-Source: ABdhPJyMQLbemxhwOLTbjxw4bGBwrAUQrqkzUuntBWLnXQzz1HiGJjDtPUdQzCJVZrEyBvJTe9H4JMKNqITmUkF4X0c= X-Received: by 2002:a92:d34a:: with SMTP id a10mr2023962ilh.123.1622105832171; Thu, 27 May 2021 01:57:12 -0700 (PDT) MIME-Version: 1.0 From: Fabien Imbault Date: Thu, 27 May 2021 10:57:01 +0200 Message-ID: To: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000ea2cf405c34bf1b5" Archived-At: Subject: [GNAP] Editor's 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: Thu, 27 May 2021 08:57:16 -0000 --000000000000ea2cf405c34bf1b5 Content-Type: text/plain; charset="UTF-8" Hello everyone, The editorial team has put 2 related PRs in pending merge for your review: https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/261 https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/26 Based on feedback received (issues 260 and 118), those changes clarify the split between the 2 documents (core and RS), and reintroduce client facing sections (and especially "RS-first Method of AS Discovery") in the core document. Best regards, Justin, Aaron and Fabien --000000000000ea2cf405c34bf1b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,=C2=A0

The editorial= team has put 2 related PRs in pending merge for your review:=C2=A0
= https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/261
https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/26

Based on feedback received (issues 260 and 118), thos= e changes clarify the split between the 2 documents (core and RS), and rein= troduce client facing sections (and especially "RS-first Method of AS Dis= covery") in the core document.

Best re= gards,
Justin, Aaron and Fabien

=C2=A0

--000000000000ea2cf405c34bf1b5-- From nobody Fri May 28 12:29: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 0E70C3A32E6 for ; Fri, 28 May 2021 12:29:25 -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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Se08nZcKQOVR for ; Fri, 28 May 2021 12:29:23 -0700 (PDT) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 AC13E3A32E5 for ; Fri, 28 May 2021 12:29:23 -0700 (PDT) Received: by mail-vs1-xe34.google.com with SMTP id f11so2750629vst.0 for ; Fri, 28 May 2021 12:29:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=IkX/FlUPeBP/XbMTTfTi/Bm051WeeIQZKSPcz72rvhQ=; b=ZUACPYMWmLpa8dnpToF/Fhs8pRRV6xMPLqil/ViJYXWpVTaUr4bJouPR7xFQQFni/M L6T/ritBO1P3KcPdbuoAQbIoGxLnrzptw5DoV/md41z5gLTMO8lwiDqP12wXuSg3Ea/b Q16VQ21VVD4TX4dAGjUbmGrUAG1ecY/xCmuhWpgXURmEPVn7COE+3I8ODBf6eCz2/7I/ zBt/X1GVaprk1i6m6Vv2Vo9ff02UORhrL97tMILiquGSAZGI3Q0DtzPWw8odO/566VzW g5afHILBXyMVTf/fdYbGQSKE4MNrnLbsnwuQePN745dxB+DywIuqsC0X9PcrgNQQutw9 /+mA== 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=IkX/FlUPeBP/XbMTTfTi/Bm051WeeIQZKSPcz72rvhQ=; b=ZRekK2dkc0huMNDVntwz8BOPiesDdjtW1dWHiCTDl1Fa/Z/lnrumSojzkeeY9L4EG5 wUoQU0zC5T2KHoZXm8INnX0yentTdJErWmFJZCMfFKNetvYZUrxN738xV/hAHOqZAl2d NRvVQzJ1i4RgCHkKCr1M/kD1uaPNN/3bJz72V/5SF/+Hxz+H/6UIKTrm+O1TSs+qKTy+ an2fCN29VrbHcixokpnfW7t/+kuzkA0fIYd9QfGB8RatOsOqO3j/YB454r80dVGvPeim iq5PMSdVmlNlwoT08W6SvTelHmLFogplycpzBFNNi8c6UgcL+5PEePhHbftiE4T5ct4i XiLQ== X-Gm-Message-State: AOAM531Ds90wQcwLD81MO/34JBaW9jkMmpJnq3Rca7CyLFuHPMdWrtD9 g6MHfY7RpFPpEk+Nec6sA0ZZQpafYIk+Onq165+PBokSdsg= X-Google-Smtp-Source: ABdhPJw6beksx9tsBVwuwD+3PmhtNId8uwB79Al52ASgU7QmZeSY44hyEkB76skzEdebAMPYQ5aTVrYv6LihZ2bH1Ck= X-Received: by 2002:a67:b709:: with SMTP id h9mr8881372vsf.39.1622230160675; Fri, 28 May 2021 12:29:20 -0700 (PDT) MIME-Version: 1.0 From: Kathleen Moriarty Date: Fri, 28 May 2021 15:28:44 -0400 Message-ID: To: GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000078974005c368e4a9" Archived-At: Subject: [GNAP] Defense protection 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, 28 May 2021 19:29:25 -0000 --00000000000078974005c368e4a9 Content-Type: text/plain; charset="UTF-8" Hello! In light of recent attacks against SAML and OAuth, I'd like to see what defense mechanisms and detection could be built into the spec. One example would be from the recent SAML attack. If there was a detection of instances of authorization without authentication, the SAML attack used in SolarWinds might have been detected sooner. If you think along the lines of fraud detection, where you detect unusual events, there may be some specific to GNAP that could enable early detection of abuse, misuse, or exploits. Are there some planned? Would people like to brainstorm on this? Thanks! -- Best regards, Kathleen --00000000000078974005c368e4a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello!

In light of recent attacks again= st SAML and OAuth, I'd like to see what defense mechanisms and detectio= n could be built into the spec.=C2=A0 One example would be from the recent = SAML attack.=C2=A0 If there was a detection of instances of authorization w= ithout authentication, the SAML attack used in SolarWinds might have been d= etected sooner.

If you think along the lines of fr= aud detection, where you detect unusual events, there may be some specific = to GNAP that could enable early detection of abuse, misuse, or exploits.

Are there some planned?=C2=A0 Would people like to b= rainstorm on this?
Thanks!

--

Best regards,
Kathleen
<= /div>
--00000000000078974005c368e4a9-- From nobody Fri May 28 12:42: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 1CD223A3148 for ; Fri, 28 May 2021 12:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 hxHF-SVY8IBU for ; Fri, 28 May 2021 12:42:00 -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 CF5F83A334A for ; Fri, 28 May 2021 12:41:59 -0700 (PDT) Received: by mail-vs1-f42.google.com with SMTP id x22so2751132vsn.2 for ; Fri, 28 May 2021 12:41:59 -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=eKzqubUY9h1cNNQ1miBmvbcShahtkI4bLT37gi1mD0Q=; b=I9TZo+UXWyRKFiL7aRH72eoIgWxIQaoAHIeJcP0KP0n8dBVruApaIokyd6hsAzNSBi pC7Hs72zM00AmngLasNneIVCI541LgOtpwjkXyjGCRB58PP3xiYEnJ1cFdIpaPgUKQyq 65371kX2DxDfuJPn0eYtOKFgY7eLN1qoeuLjSxtOVorWrys9afqp+4ik0ZBS/pl6bjN4 vAK8y1jhIndNDN3536jbJXLm0gIo7yIkAvZ/EkK72tIe6oKeY5gLF2xuaIPUoyi6bMMm IcBcdh5PRGITNI8FQT+cNzvKagTBR6NdqYwFqzXCBC9A4NBg3aamHKTdryTLoHQzdkaL uHbQ== X-Gm-Message-State: AOAM5306WRobcdyDhgL+hjs/WdUuZv8soQtkll3jCJaXWvJI5zE1R1vA 2iiCKT4lGmSQYOzqpt93Z7z9ukJVN0nHw0CGkIs= X-Google-Smtp-Source: ABdhPJweNBENZzuEBwqsLeOc2knaenn3CGDsDyPb+gSRGTK+u5J1jm4ncc+how88Tos9NdXDK4X6UmF7t5r0tfjdloY= X-Received: by 2002:a67:cd0d:: with SMTP id u13mr9235343vsl.1.1622230918486; Fri, 28 May 2021 12:41:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Adrian Gropper Date: Fri, 28 May 2021 15:41:46 -0400 Message-ID: To: Kathleen Moriarty Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000a3df8205c36911c1" Archived-At: Subject: Re: [GNAP] Defense protection 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, 28 May 2021 19:42:04 -0000 --000000000000a3df8205c36911c1 Content-Type: text/plain; charset="UTF-8" Hi Kathleen, I am not aware of the attacks on SAML and OAuth and would appreciate a link or two. I hope we can provide guidance on how GNAP can facilitate Zero Trust Architecture and believe that includes guidance on how to audit various things as systems use GNAP protocols to separate concerns among independent actors. Count me in for a brainstorming sessio, - Adrian On Fri, May 28, 2021 at 3:29 PM Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hello! > > In light of recent attacks against SAML and OAuth, I'd like to see what > defense mechanisms and detection could be built into the spec. One example > would be from the recent SAML attack. If there was a detection of > instances of authorization without authentication, the SAML attack used in > SolarWinds might have been detected sooner. > > If you think along the lines of fraud detection, where you detect unusual > events, there may be some specific to GNAP that could enable early > detection of abuse, misuse, or exploits. > > Are there some planned? Would people like to brainstorm on this? > Thanks! > > > -- > > Best regards, > Kathleen > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000a3df8205c36911c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Kathleen,

I am not aware of the attacks on SAML and OAuth and would appre= ciate a link or two.

I h= ope we can provide guidance on how GNAP can facilitate Zero Trust Architect= ure and believe that includes guidance on how to audit various things as sy= stems use GNAP protocols to separate concerns among independent actors.=C2= =A0

Count me in for a br= ainstorming=C2=A0sessio,

- Adrian


On Fri, May 28, 2021 at 3:29 PM Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>= wrote:
Hello!
In light of recent attacks against SAML and OAuth, I'd = like to see what defense mechanisms and detection could be built into the s= pec.=C2=A0 One example would be from the recent SAML attack.=C2=A0 If there= was a detection of instances of authorization without authentication, the = SAML attack used in SolarWinds might have been detected sooner.
<= br>
If you think along the lines of fraud detection, where you de= tect unusual events, there may be some specific to GNAP that could enable e= arly detection of abuse, misuse, or exploits.

Are = there some planned?=C2=A0 Would people like to brainstorm on this?
Thanks!


--

Best regards,
Kathleen
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000a3df8205c36911c1-- From nobody Fri May 28 12:51: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 EFDD13A339D for ; Fri, 28 May 2021 12:51:25 -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 QAQXJEosiBBe for ; Fri, 28 May 2021 12:51:21 -0700 (PDT) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 D721A3A3397 for ; Fri, 28 May 2021 12:51:20 -0700 (PDT) Received: by mail-vs1-xe2c.google.com with SMTP id x22so2763555vsn.2 for ; Fri, 28 May 2021 12:51: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=rlXXTtzvDJ/yRI4m8FmVC6ak8aJdD/R5YxLDLKKpJW4=; b=FVaVeZ/cAExXOgrDu8BjC2fmA50sgouu/qbsHSrdfTywYruKegqIEMwCf5RAhgQYCQ P1g+Q1mRhCHkcBxqXuNF6CAHqIkreltu4lY7BWNxiaI6cYoXXJcvXYrW4qf7xHlYkyCl Zm3DqNCHFxkd4mtfsR8SlZnIC5TZDpRdTXvYouiF6lAx/Z/KruTCKlowT7hIMfTGWlYa 9qaXkaZM26SSjF+4dkE9Dq8BuMXPLa8nF3CiXFLOKtykJdpkDMi2XCAcBBUZBSOJGMex jmdGFISdlctXCVwD6Yy0LrfVKqIcWAkwf3qATmCD+9n7XGd2RJfO3FA+eWPLxzAHBsQA Ixyg== 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=rlXXTtzvDJ/yRI4m8FmVC6ak8aJdD/R5YxLDLKKpJW4=; b=tAFkv/Y1kC55RQ3h9tZrNRSIuOsGwLDSqpoElb6Hu9tqizw3xPmwuzr0dNWJ0YshW/ sizujd9TrZ61iBBy0BzJWOe41Zm5DfRZvlMJKXhB5amL+jF8YxdddtzLoXz3bWgjlDaq brliGQxUhtzJEKKqLdvWh7ePhOkiCNqdmp4N3KIng0wOXuQZBFAWt338TM6oUvFmMe63 PmCN+cVyT/coaaPfu+2LmseN+/j+Xwvi9GVvdEjg332Ft1bVEZst4bFwPk3gMqGXvY8D 9axAS2Hh527Rj32swKAUIEwF8foK0sdEOTay9s6o9UKyAeLCXiy1elYfIc1iiu/3HNCv AyGA== X-Gm-Message-State: AOAM533VhorU3MLtxQurOXoTwR/W+dAAVaZEK7S+AUUMynj97XuxeHJk WbYIRgxMmJj5H/u434ENWd/5RDMzguhxuGPRWhg= X-Google-Smtp-Source: ABdhPJzIUfXD0gZ9NlbqmBxhhlE747jFSGOV7kZYWB9GoYFVAJHlrcqjy9h2pvfTULj2GUDujh8kqGo2jMcjMMdPNTI= X-Received: by 2002:a67:d017:: with SMTP id r23mr9366778vsi.12.1622231479157; Fri, 28 May 2021 12:51:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kathleen Moriarty Date: Fri, 28 May 2021 15:50:43 -0400 Message-ID: To: Adrian Gropper Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000000f091805c3693302" Archived-At: Subject: Re: [GNAP] Defense protection 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, 28 May 2021 19:51:26 -0000 --0000000000000f091805c3693302 Content-Type: text/plain; charset="UTF-8" Hi Adrian, Thanks for your interest! This is a helpful link that describes how the attackers were able to bypass MFA by stealing the signing key for SAML assertions: https://www.darkreading.com/attacks-breaches/solarwinds-campaign-focuses-attention-on-golden-saml-attack-vector/d/d-id/1339794 https://owasp.org/www-chapter-singapore/assets/presos/Deconstructing_the_Solarwinds_Supply_Chain_Attack_and_Deterring_it_Honing_in_on_the_Golden_SAML_Attack_Technique.pdf I did read one that was a bit better, but can't find the link at the moment. And one on shared OAuth credentials/token issuance: https://www.csoonline.com/article/3607348/how-to-defend-against-oauth-enabled-cloud-based-attacks.html It would be good to think about attack vectors and if not prevention, minimally detection. Best regards, Kathleen On Fri, May 28, 2021 at 3:41 PM Adrian Gropper wrote: > Hi Kathleen, > > I am not aware of the attacks on SAML and OAuth and would appreciate a > link or two. > > I hope we can provide guidance on how GNAP can facilitate Zero Trust > Architecture and believe that includes guidance on how to audit various > things as systems use GNAP protocols to separate concerns among independent > actors. > > Count me in for a brainstorming sessio, > > - Adrian > > > On Fri, May 28, 2021 at 3:29 PM Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >> Hello! >> >> In light of recent attacks against SAML and OAuth, I'd like to see what >> defense mechanisms and detection could be built into the spec. One example >> would be from the recent SAML attack. If there was a detection of >> instances of authorization without authentication, the SAML attack used in >> SolarWinds might have been detected sooner. >> >> If you think along the lines of fraud detection, where you detect unusual >> events, there may be some specific to GNAP that could enable early >> detection of abuse, misuse, or exploits. >> >> Are there some planned? Would people like to brainstorm on this? >> Thanks! >> >> >> -- >> >> Best regards, >> Kathleen >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- Best regards, Kathleen --0000000000000f091805c3693302 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Adrian,

Thanks for your interest!

This is a helpful link that describes how the attack= ers were able to bypass MFA by stealing the signing key for SAML assertions= :

I did read one that was a bit better, but can't find the link a= t the moment.

And one on shared OAuth credentials/= token issuance:

It would be good to thi= nk about attack vectors and if not prevention, minimally detection.

Best regards,
Kathleen

On Fri, May 28, 202= 1 at 3:41 PM Adrian Gropper <a= gropper@healthurl.com> wrote:
Hi=C2=A0Kathleen,

I am not aware of the attacks on SAML and = OAuth and would appreciate a link or two.

=
I hope we can provide guidance on how GNAP can facilitate= Zero Trust Architecture and believe that includes guidance on how to audit= various things as systems use GNAP protocols to separate concerns among in= dependent actors.=C2=A0

= Count me in for a brainstorming=C2=A0sessio,

- Adrian


On Fri, May 28, 2021 at 3:29 PM Kathleen Moriarty &= lt;ka= thleen.moriarty.ietf@gmail.com> wrote:
Hello!

In= light of recent attacks against SAML and OAuth, I'd like to see what d= efense mechanisms and detection could be built into the spec.=C2=A0 One exa= mple would be from the recent SAML attack.=C2=A0 If there was a detection o= f instances of authorization without authentication, the SAML attack used i= n SolarWinds might have been detected sooner.

If y= ou think along the lines of fraud detection, where you detect unusual event= s, there may be some specific to GNAP that could enable early detection of = abuse, misuse, or exploits.

Are there some planned= ?=C2=A0 Would people like to brainstorm on this?
Thanks!


--

Best regards,
Kathleen
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth


--

Best regards,
Kathleen
--0000000000000f091805c3693302-- From nobody Fri May 28 13:03: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 BAC893A33F8 for ; Fri, 28 May 2021 13:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=rhosys.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLdTzg_d-Pfp for ; Fri, 28 May 2021 13:03:00 -0700 (PDT) Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4CCB3A33F6 for ; Fri, 28 May 2021 13:03:00 -0700 (PDT) Received: by mail-yb1-xb2f.google.com with SMTP id e10so7092039ybb.7 for ; Fri, 28 May 2021 13:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6na7g4CG1FkHa0/5C2ItfYwdJAnyJu4ckZvlkX+H3Os=; b=AJy4nTo0fnZeKm/OG5vZydTlPNwARh+YJnWrChqPdokjnmQ6UPHRQSpL+NrkC02rtb kZF9Wd/CatV3DWQs+/jcrUx6d4Ok6K6INn4vdRLiuWVZgWXSADYgZhdkggdM3Je+DCwH qJsTNRoj2Eu/M85WhX7EX92oIsWMSnhMtxbMieDEgbbhuQC1thuG4z8tp+gUmWVqAAH7 fj6Hm/w6EMfYdOT2ko44cZYkm1LQ8ln21xWoOGggN6ZvMYFVIv3tZ8hguiR24zcbH0TT RkIWnTpKMYtnV5nMoQbXLRtPYnANW+byvObVOXxNem14X5SeIGSUAXysQZGr9JzAk2ZP qeeA== 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=6na7g4CG1FkHa0/5C2ItfYwdJAnyJu4ckZvlkX+H3Os=; b=I+YZOBstdcE1UJf+Xj7ADX+JFW5jI/qB3p6N4yB26RCG7uPX1FEGa9WABF+vaoc1e8 1uBfCe1r/EKJ9SLMYYm6NSoNwtfWjH4i1DT6//nMc7sZ8BjuYD5ECHGdJJT4sS7pG3p8 i1nM1oce9vvhkuTU9o5WLSmU4uxXZG44GE+wXhV9byypWWuaDjUHkKVuzkf5lyhpJqnl w8n2QxZfV45Fqjx+q++hUZ5wSVjHhHwAY70bkhnhxtrbl37lSxrxR9fTMlrfAK9N/lpU 0n/OReGpeC1FYjHCxdPU3doWTIX+6qm2Mz+nU/65tKgpokya9AVi4Gup2k3q0OuM12Ex MRUw== X-Gm-Message-State: AOAM533clbA7/QhpVS7TL3VBoqkwpAvhCdK4xY+4BGnaTATMu61Hmauy vB3v+7K1w83WxDjefYlm0Cq7dFC3rNmPwXnxv33B X-Google-Smtp-Source: ABdhPJyA9N4YN5k/+39na+JlO7Oy7yT76Ye4XzV0LGqa0N4M2m1r19VS0C0blMQXoDFls4ZaJ37X3xaO6f9IbTNk1fU= X-Received: by 2002:a25:a003:: with SMTP id x3mr14851194ybh.182.1622232178077; Fri, 28 May 2021 13:02:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warren Parad Date: Fri, 28 May 2021 22:02:47 +0200 Message-ID: To: Kathleen Moriarty Cc: Adrian Gropper , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000b7c77205c3695ca1" Archived-At: Subject: Re: [GNAP] Defense protection 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, 28 May 2021 20:03:06 -0000 --000000000000b7c77205c3695ca1 Content-Type: text/plain; charset="UTF-8" Correct me if I'm mistaken, it sounds like the Golden SAML attack amounts to getting control of the signer's private key. I'm going to go out on a limb here and say, I'm not sure any protocol solution would help solve this problem. But I would love to be mistaken. It's possible to make this harder by allowing multiparty signers to be required (or at least allowed/enabled) to prevent single vulnerable issues. There are other issues with that sort of solution, such as then requiring more nodes to sign each request and thus providing more physical attack surfaces. It's hard for me to evaluate the trade off there. In the case of the OAuth article it seems to suggest, phishing is the problem. The solution here is preventing the user from entering their "password" in malicious locations. I'm hoping that browsers will better support first-class login apis and sanitization for better protection here, however, nothing first comes to mind about what protocol could do to stop that. I would say here, browsers need to get better, device OSs need to be better. Maybe there are better solutions lurking out there. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress . On Fri, May 28, 2021 at 9:51 PM Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hi Adrian, > > Thanks for your interest! > > This is a helpful link that describes how the attackers were able to > bypass MFA by stealing the signing key for SAML assertions: > > https://www.darkreading.com/attacks-breaches/solarwinds-campaign-focuses-attention-on-golden-saml-attack-vector/d/d-id/1339794 > > https://owasp.org/www-chapter-singapore/assets/presos/Deconstructing_the_Solarwinds_Supply_Chain_Attack_and_Deterring_it_Honing_in_on_the_Golden_SAML_Attack_Technique.pdf > > I did read one that was a bit better, but can't find the link at the > moment. > > And one on shared OAuth credentials/token issuance: > > https://www.csoonline.com/article/3607348/how-to-defend-against-oauth-enabled-cloud-based-attacks.html > > It would be good to think about attack vectors and if not prevention, > minimally detection. > > Best regards, > Kathleen > > On Fri, May 28, 2021 at 3:41 PM Adrian Gropper > wrote: > >> Hi Kathleen, >> >> I am not aware of the attacks on SAML and OAuth and would appreciate a >> link or two. >> >> I hope we can provide guidance on how GNAP can facilitate Zero Trust >> Architecture and believe that includes guidance on how to audit various >> things as systems use GNAP protocols to separate concerns among independent >> actors. >> >> Count me in for a brainstorming sessio, >> >> - Adrian >> >> >> On Fri, May 28, 2021 at 3:29 PM Kathleen Moriarty < >> kathleen.moriarty.ietf@gmail.com> wrote: >> >>> Hello! >>> >>> In light of recent attacks against SAML and OAuth, I'd like to see what >>> defense mechanisms and detection could be built into the spec. One example >>> would be from the recent SAML attack. If there was a detection of >>> instances of authorization without authentication, the SAML attack used in >>> SolarWinds might have been detected sooner. >>> >>> If you think along the lines of fraud detection, where you detect >>> unusual events, there may be some specific to GNAP that could enable early >>> detection of abuse, misuse, or exploits. >>> >>> Are there some planned? Would people like to brainstorm on this? >>> Thanks! >>> >>> >>> -- >>> >>> Best regards, >>> Kathleen >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> > > -- > > Best regards, > Kathleen > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000b7c77205c3695ca1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Correct me if I'm mistaken, it sounds like the Golden = SAML attack amounts to getting control of the signer's private key. I&#= 39;m going to go out on a limb here and say, I'm not sure any protocol = solution would help solve this problem. But I would love to be mistaken. It= 's possible to make this harder by allowing multiparty signers to be re= quired (or at least allowed/enabled) to prevent single vulnerable issues. T= here are other issues with that sort of solution, such as then requiring mo= re nodes to sign each request and thus providing more physical attack surfa= ces. It's hard for me to evaluate the trade off there.

In the case of the OAuth article it seems to suggest, phishing is the pr= oblem. The solution here is preventing the user from entering their "p= assword" in malicious locations. I'm hoping that browsers will bet= ter support first-class login apis and sanitization for better protection h= ere, however, nothing first comes to mind about what protocol could do to s= top that. I would say here, browsers need to get better, device OSs need to= be better. Maybe there are better solutions lurking out there.
<= br clear=3D"all">

Warren Parad

Founde= r, CTO

Secure your user data with IAM authorization as a service. Impleme= nt=C2=A0Authress.


On Fri, May 28, 2021 at 9:51 PM Kathleen Mori= arty <kathleen.moria= rty.ietf@gmail.com> wrote:
Hi Adrian,

Thanks for= your interest!

This is a helpful link that descri= bes how the attackers were able to bypass MFA by stealing the signing key f= or SAML assertions:

I did read on= e that was a bit better, but can't find the link at the moment.

And one on shared OAuth credentials/token issuance:
=

It would be good to think = about attack vectors and if not prevention, minimally detection.
=
Best regards,
Kathleen

On Fri, May 28, 2021= at 3:41 PM Adrian Gropper <agropper@healthurl.com> wrote:
Hi=C2=A0Kathleen,

I am not aware of the att= acks on SAML and OAuth and would appreciate a link or two.

I hope we can provide guidance on how GN= AP can facilitate Zero Trust Architecture and believe that includes guidanc= e on how to audit various things as systems use GNAP protocols to separate = concerns among independent actors.=C2=A0

<= div dir=3D"auto">Count me in for a brainstorming=C2=A0sessio,

- Adrian

<= /div>

On Fri, May 28, 2021 at 3:29 PM Ka= thleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
Hello!
=
In light of recent attacks against SAML and OAuth, I'd l= ike to see what defense mechanisms and detection could be built into the sp= ec.=C2=A0 One example would be from the recent SAML attack.=C2=A0 If there = was a detection of instances of authorization without authentication, the S= AML attack used in SolarWinds might have been detected sooner.
If you think along the lines of fraud detection, where you det= ect unusual events, there may be some specific to GNAP that could enable ea= rly detection of abuse, misuse, or exploits.

Are t= here some planned?=C2=A0 Would people like to brainstorm on this?
Thanks!


= --

Best regards,
K= athleen
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth


--

Best regards,
Kathleen
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000b7c77205c3695ca1-- From nobody Fri May 28 13:09: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 1B96B3A3429 for ; Fri, 28 May 2021 13:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 c6048eaC5IFP for ; Fri, 28 May 2021 13:09:41 -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 573963A3428 for ; Fri, 28 May 2021 13:09:41 -0700 (PDT) Received: by mail-vs1-f43.google.com with SMTP id x2so2777937vss.3 for ; Fri, 28 May 2021 13:09: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=uNtlSM6/qpwYppkLNrCXhKIko3W2Qu9TpBg8E3WoODY=; b=NEuKQ09fnTMa/TpDgMWeYFUQtGzm89hj+iZGsyzq9sq7PJQNnGlpLmfkUioM52W2Z9 umN5s+Ni7HkxKb9L7VM2dV1oT3DmkqCSJRG8D63u0GtgJACPtzb2so1uFiGRGAPzMY9a gNMEPQaRL6+KKgZgUKK/Dc8zJUkArCdB4yjt56bAPqT7EKSip553Y5W7l1nudAV19K/i rx1/O2FJ1hQhsFed/aNC95IaMRqho8bAksBHc2uuDy4D/PcsKzXUShJHtfkVM+sZVFap qtJMVk5DLQcV538lnr62b3s5JRIDDXiF25TtZUuQhzcSW3qRtitlFXnKtixjlk/uoKkP RDmQ== X-Gm-Message-State: AOAM530TH3CvxLoHSpWg2LyVCmzeLSF6uY5P8+TD2HqgIafU2IrjOkga DRqtpXjPN+dIWV9Ho4Rs6wIkS2fv8Qc8V6P0UnY= X-Google-Smtp-Source: ABdhPJxqSrM6PtPmneNLTS7WX66ThFjaDVmoc2SRubzu+tSOpbDwbuu8O02x9dZvxv7D4TlLXLE/TzSgCPouBtaiIFY= X-Received: by 2002:a67:cd0d:: with SMTP id u13mr9320944vsl.1.1622232580070; Fri, 28 May 2021 13:09:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Adrian Gropper Date: Fri, 28 May 2021 16:09:28 -0400 Message-ID: To: Kathleen Moriarty Cc: Alan Karp , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000ada47505c369740c" Archived-At: Subject: Re: [GNAP] Defense protection 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, 28 May 2021 20:09:46 -0000 --000000000000ada47505c369740c Content-Type: text/plain; charset="UTF-8" Thanks to Alan Karp, I have come to believe that delegation is essential and GNAP needs to speak of capabilities as first-class tokens and encourage their use. This will become the main driver for adoption of GNAP over SAML or OAuth. - Adrian On Fri, May 28, 2021 at 3:51 PM Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hi Adrian, > > Thanks for your interest! > > This is a helpful link that describes how the attackers were able to > bypass MFA by stealing the signing key for SAML assertions: > > https://www.darkreading.com/attacks-breaches/solarwinds-campaign-focuses-attention-on-golden-saml-attack-vector/d/d-id/1339794 > > https://owasp.org/www-chapter-singapore/assets/presos/Deconstructing_the_Solarwinds_Supply_Chain_Attack_and_Deterring_it_Honing_in_on_the_Golden_SAML_Attack_Technique.pdf > > I did read one that was a bit better, but can't find the link at the > moment. > > And one on shared OAuth credentials/token issuance: > > https://www.csoonline.com/article/3607348/how-to-defend-against-oauth-enabled-cloud-based-attacks.html > > It would be good to think about attack vectors and if not prevention, > minimally detection. > > Best regards, > Kathleen > > On Fri, May 28, 2021 at 3:41 PM Adrian Gropper > wrote: > >> Hi Kathleen, >> >> I am not aware of the attacks on SAML and OAuth and would appreciate a >> link or two. >> >> I hope we can provide guidance on how GNAP can facilitate Zero Trust >> Architecture and believe that includes guidance on how to audit various >> things as systems use GNAP protocols to separate concerns among independent >> actors. >> >> Count me in for a brainstorming sessio, >> >> - Adrian >> >> >> On Fri, May 28, 2021 at 3:29 PM Kathleen Moriarty < >> kathleen.moriarty.ietf@gmail.com> wrote: >> >>> Hello! >>> >>> In light of recent attacks against SAML and OAuth, I'd like to see what >>> defense mechanisms and detection could be built into the spec. One example >>> would be from the recent SAML attack. If there was a detection of >>> instances of authorization without authentication, the SAML attack used in >>> SolarWinds might have been detected sooner. >>> >>> If you think along the lines of fraud detection, where you detect >>> unusual events, there may be some specific to GNAP that could enable early >>> detection of abuse, misuse, or exploits. >>> >>> Are there some planned? Would people like to brainstorm on this? >>> Thanks! >>> >>> >>> -- >>> >>> Best regards, >>> Kathleen >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> > > -- > > Best regards, > Kathleen > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000ada47505c369740c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks to Alan Karp, I have come to believe that delegati= on is essential and GNAP needs to speak of capabilities as first-class toke= ns and encourage their use.=C2=A0 This will become the main driver for adop= tion of GNAP over SAML or OAuth.=C2=A0

- Adrian

=

On Fri, May 28, 2021 at 3:51 PM Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
https://owasp.org/www-chapter-s= ingapore/assets/presos/Deconstructing_the_Solarwinds_Supply_Chain_Attack_an= d_Deterring_it_Honing_in_on_the_Golden_SAML_Attack_Technique.pdf

I did read one that was a bit better, but can't = find the link at the moment.

And one on shared OAu= th credentials/token issuance:

<= /div>
It would be good to think about attack vectors and if not prevent= ion, minimally detection.

Best regards,
= Kathleen

On Fri, May 28, 2021 at 3:41 PM Adrian Gropper <agropper@healthurl.com= > wrote:
=
Hi=C2=A0Kathleen,

I am not aware of the attacks on SAML and OAuth and would appre= ciate a link or two.

I h= ope we can provide guidance on how GNAP can facilitate Zero Trust Architect= ure and believe that includes guidance on how to audit various things as sy= stems use GNAP protocols to separate concerns among independent actors.=C2= =A0

Count me in for a br= ainstorming=C2=A0sessio,

- Adrian


On Fri, May 28, 2021 at 3:29 PM Kathleen Moriarty <kathleen.moriarty.ietf= @gmail.com> wrote:
Hello!

In light of recent at= tacks against SAML and OAuth, I'd like to see what defense mechanisms a= nd detection could be built into the spec.=C2=A0 One example would be from = the recent SAML attack.=C2=A0 If there was a detection of instances of auth= orization without authentication, the SAML attack used in SolarWinds might = have been detected sooner.

If you think along the = lines of fraud detection, where you detect unusual events, there may be som= e specific to GNAP that could enable early detection of abuse, misuse, or e= xploits.

Are there some planned?=C2=A0 Would peopl= e like to brainstorm on this?
Thanks!


--

Best regards,
Kathleen
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth


--

Best regards,
Kathleen
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000ada47505c369740c-- From nobody Fri May 28 13:44: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 5B90B3A352B for ; Fri, 28 May 2021 13:44:49 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 3rsJQjuEw8Sg for ; Fri, 28 May 2021 13:44:44 -0700 (PDT) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (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 47B963A3529 for ; Fri, 28 May 2021 13:44:44 -0700 (PDT) Received: by mail-vs1-xe35.google.com with SMTP id j12so2819973vsq.9 for ; Fri, 28 May 2021 13:44: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=vYqxjqq6ow4/809N8pFM2mIrww5RdQjXx9Ikp1UTaRE=; b=Un0bHq+ECESoUbop5nreMPH85AkRmJ5zbrv/6YQefqMOstEUNmRMTYRzBVlg9wjKaQ 5RKqdiRmFGVG1ONhfK36WZZpUGfbz6s/ndaOn9LkwQ5pOqVcO8RufkbKui3jC2dsWehC QUrZZwLzIvCJ8fAsKIeDmlRktNttFRCbVnVWR0Bl+4/W1Bx+sq5LdBnEVtHQ1xZB83K5 QkgKKaIbsF70zN085lYxf3vjVR6YRnnvIlmYUM+/CKI0Kvcg2UN3jj9UgDVooSEPdYJl dKDnI5Q8ft5Wpuka43MxwFDYeQ0QjKCXN+dPLLpXGwmRbp7yby0Ck7mapWFFDE9w//t4 Ettw== 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=vYqxjqq6ow4/809N8pFM2mIrww5RdQjXx9Ikp1UTaRE=; b=CGdYF0e8Qs/TtE6flLBB1sAabFSmeW+EXEmNxJd4AZOAwbJw3KdUgABlhvCxW40juY cZjC18JrGt9/z9kMkOvzOmEBUUQ5bnGFU8dcQC/8ljToFfawl286dibgzyJZaP6lNHBu f3BU3Ns2m/SkMxDz1ID3Q9gdG1Ha9Ig2Ydz0jayFVe5caC1C7jJ5RKRDTVl7Qy7uWnDx r+tkySEBPBY0P6padn1hiPhOE+xLopLNxO+q/HRBvIjquti4viq46ZgkSGrx0t41Km7z Wl46f17K6Arp9tSszt9lRQgBUMkXlit40EqUZHlLF/HA8N0rz5WYhCnhLZrtK/dL7IMl hzFQ== X-Gm-Message-State: AOAM5303Ahj4tjLcTmy3rETmnsQtC5I4/8+Wd8Jfwe8wZqRBFK/oa96Y 9RKhDcl9mlsCCIgYUXjg13uGwqp3AQrWk6fIJqs= X-Google-Smtp-Source: ABdhPJxAxeZW23tnh2Ti0PsUyc6/eWP8IvWFNznMyR6SiL7Z5VHIADK0acJ3mJMMig4pMYWN5u4LpZBG9Z6JrlIV7Eo= X-Received: by 2002:a05:6102:1168:: with SMTP id k8mr8969004vsg.41.1622234681714; Fri, 28 May 2021 13:44:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kathleen Moriarty Date: Fri, 28 May 2021 16:44:05 -0400 Message-ID: To: Warren Parad Cc: Adrian Gropper , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000f22c4205c369f103" Archived-At: Subject: Re: [GNAP] Defense protection 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, 28 May 2021 20:44:49 -0000 --000000000000f22c4205c369f103 Content-Type: text/plain; charset="UTF-8" Warren, We can think about advice on detection and having that be built into the security considerations. There is a clear example given in the SAML case. I'm raising this as food for thought and to see what we can do. Security needs to be better, more scalable, and easier on the user base. That's not a simple combination. These attacks are only a sample of what is to come. If there is a vulnerability or a blind spot, it will be used. Best regards, Kathleen On Fri, May 28, 2021 at 4:02 PM Warren Parad wrote: > Correct me if I'm mistaken, it sounds like the Golden SAML attack amounts > to getting control of the signer's private key. I'm going to go out on a > limb here and say, I'm not sure any protocol solution would help solve this > problem. But I would love to be mistaken. It's possible to make this harder > by allowing multiparty signers to be required (or at least allowed/enabled) > to prevent single vulnerable issues. There are other issues with that sort > of solution, such as then requiring more nodes to sign each request and > thus providing more physical attack surfaces. It's hard for me to evaluate > the trade off there. > > In the case of the OAuth article it seems to suggest, phishing is the > problem. The solution here is preventing the user from entering their > "password" in malicious locations. I'm hoping that browsers will better > support first-class login apis and sanitization for better protection here, > however, nothing first comes to mind about what protocol could do to stop > that. I would say here, browsers need to get better, device OSs need to be > better. Maybe there are better solutions lurking out there. > > Warren Parad > > Founder, CTO > Secure your user data with IAM authorization as a service. Implement > Authress . > > > On Fri, May 28, 2021 at 9:51 PM Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >> Hi Adrian, >> >> Thanks for your interest! >> >> This is a helpful link that describes how the attackers were able to >> bypass MFA by stealing the signing key for SAML assertions: >> >> https://www.darkreading.com/attacks-breaches/solarwinds-campaign-focuses-attention-on-golden-saml-attack-vector/d/d-id/1339794 >> >> https://owasp.org/www-chapter-singapore/assets/presos/Deconstructing_the_Solarwinds_Supply_Chain_Attack_and_Deterring_it_Honing_in_on_the_Golden_SAML_Attack_Technique.pdf >> >> I did read one that was a bit better, but can't find the link at the >> moment. >> >> And one on shared OAuth credentials/token issuance: >> >> https://www.csoonline.com/article/3607348/how-to-defend-against-oauth-enabled-cloud-based-attacks.html >> >> It would be good to think about attack vectors and if not prevention, >> minimally detection. >> >> Best regards, >> Kathleen >> >> On Fri, May 28, 2021 at 3:41 PM Adrian Gropper >> wrote: >> >>> Hi Kathleen, >>> >>> I am not aware of the attacks on SAML and OAuth and would appreciate a >>> link or two. >>> >>> I hope we can provide guidance on how GNAP can facilitate Zero Trust >>> Architecture and believe that includes guidance on how to audit various >>> things as systems use GNAP protocols to separate concerns among independent >>> actors. >>> >>> Count me in for a brainstorming sessio, >>> >>> - Adrian >>> >>> >>> On Fri, May 28, 2021 at 3:29 PM Kathleen Moriarty < >>> kathleen.moriarty.ietf@gmail.com> wrote: >>> >>>> Hello! >>>> >>>> In light of recent attacks against SAML and OAuth, I'd like to see what >>>> defense mechanisms and detection could be built into the spec. One example >>>> would be from the recent SAML attack. If there was a detection of >>>> instances of authorization without authentication, the SAML attack used in >>>> SolarWinds might have been detected sooner. >>>> >>>> If you think along the lines of fraud detection, where you detect >>>> unusual events, there may be some specific to GNAP that could enable early >>>> detection of abuse, misuse, or exploits. >>>> >>>> Are there some planned? Would people like to brainstorm on this? >>>> Thanks! >>>> >>>> >>>> -- >>>> >>>> Best regards, >>>> Kathleen >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> >> >> -- >> >> Best regards, >> Kathleen >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- Best regards, Kathleen --000000000000f22c4205c369f103 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Warren,

We can think about advice on de= tection and having that be built into the security considerations.=C2=A0 Th= ere is a clear example given in the=C2=A0SAML case.=C2=A0 I'm raising t= his as food for thought and to see what we can do.=C2=A0 Security needs to = be better, more scalable, and easier on the user base.=C2=A0 That's not= a simple combination.=C2=A0 These attacks are only a sample=C2=A0of what i= s to come.=C2=A0 If there is a vulnerability=C2=A0or a blind spot, it will = be used.

Best regards,
Kathleen

On = Fri, May 28, 2021 at 4:02 PM Warren Parad <wparad@rhosys.ch> wrote:
Correct me if I'm mistaken, it = sounds like the Golden SAML attack amounts to getting control of the signer= 's private key. I'm going to go out on a limb here and say, I'm= not sure any protocol solution would help solve this problem. But I would = love to be mistaken. It's possible to make this harder by allowing mult= iparty signers to be required (or at least allowed/enabled) to prevent sing= le vulnerable issues. There are other issues with that sort of solution, su= ch as then requiring more nodes to sign each request and thus providing mor= e physical attack surfaces. It's hard for me to evaluate the trade off = there.

In the case of the OAuth article it seems to sugg= est, phishing is the problem. The solution here is preventing the user from= entering their "password" in malicious locations. I'm hoping= that browsers will better support first-class login apis and sanitization = for better protection here, however, nothing first comes to mind about what= protocol could do to stop that. I would say here, browsers need to get bet= ter, device OSs need to be better. Maybe there are better solutions lurking= out there.

<= td style=3D"border-width:1pt;border-style:solid;border-color:rgb(255,255,25= 5) rgb(204,204,204) rgb(255,255,255) rgb(255,255,255);vertical-align:top;pa= dding:5pt;overflow:hidden">

Warren= Parad

= Founder, CTO

Secure your user data with IAM authorization as a service. I= mplement=C2=A0Authress.


On Fri, May 28, 2021 at 9:51 PM Kathlee= n Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
Hi Adrian,
Thanks for your interest!

This is = a helpful link that describes how the attackers were able to bypass MFA by = stealing the signing key for SAML assertions:
I did read one that was a bit better, but can't find the l= ink at the moment.

And one on shared OAuth credent= ials/token issuance:

= It would be good to think about attack vectors and if not prevention, minim= ally detection.

Best regards,
Kathleen

On Fri, May 28, 2021 at 3:41 PM Adrian Gropper <agropper@healthurl.com> wrot= e:
Hi=C2=A0Kathleen,

I= am not aware of the attacks on SAML and OAuth and would appreciate a link = or two.

I hope we can pr= ovide guidance on how GNAP can facilitate Zero Trust Architecture and belie= ve that includes guidance on how to audit various things as systems use GNA= P protocols to separate concerns among independent actors.=C2=A0

Count me in for a brainstorming=C2= =A0sessio,

- Adrian


=
On Fri, Ma= y 28, 2021 at 3:29 PM Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com= > wrote:
Hello!

In light of recent attacks against S= AML and OAuth, I'd like to see what defense mechanisms and detection co= uld be built into the spec.=C2=A0 One example would be from the recent SAML= attack.=C2=A0 If there was a detection of instances of authorization witho= ut authentication, the SAML attack used in SolarWinds might have been detec= ted sooner.

If you think along the lines of fraud = detection, where you detect unusual events, there may be some specific to G= NAP that could enable early detection of abuse, misuse, or exploits.
<= div>
Are there some planned?=C2=A0 Would people like to brain= storm on this?
Thanks!


--

B= est regards,
Kathleen
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth


--

Best regards,
Kathleen
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth


--

Best regards,
Kathleen
--000000000000f22c4205c369f103-- From nobody Fri May 28 22:46: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 CD8C93A134D for ; Fri, 28 May 2021 22:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_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 Ud4pr-mkS_h6 for ; Fri, 28 May 2021 22:45:59 -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 543DA3A1342 for ; Fri, 28 May 2021 22:45:59 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id h20so6277902qko.11 for ; Fri, 28 May 2021 22:45: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=IAOJd3RRSCIOo8LBqS8KctuaaBEW4OimwKr6IWL5FFw=; b=B0ovhfeQiBEhEVjbNG2c4uIl8Msa6o1JDWfVvf4cvpuyEFHa2OkDWmf/Po+e3i4+KM hGOnLhRIY5AfUSm5iWql+Q50FtJt8aDd7WIfnjbB+LoFsMq2MtuBuSAd36hatOAtdVsj /rqILQCWA0yC/wqQnN370BoIwNi1K04Xz8o9czIEmDao7I1dw+DqC6Y03lW7PQIEbdzt UIrHUBAh0AbxMKA8z6q2wP5DCuwc7utBVHCc7gZGxeXPvdAJP70RB+B2t4DmYOPIVAH3 HopAqQdHvxnYyd+81asUfU7riKq5jWCcC6Q7YEm873ovHBRTtQ+pwD0kQ4rORfNA0+7I IJAA== 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=IAOJd3RRSCIOo8LBqS8KctuaaBEW4OimwKr6IWL5FFw=; b=OsnOqoWF1ns2Xpxj/1cvkeaVugSPEOFFlk2Yh0pl2du/00qAadHgHqUtyYtMjIyHqI PtzMzwlPZqetrV+ukHY6oXZrIyxcWrPavn/VIf5VcIXEtXUXLt9iE0TU2/q7BK+om2NN fTs36f5V3FTmiGntGujV6NspV8GJYIetYsfHy1IwGYHNn79Fbd3vxg3ch8R76CF74JMb mAxHp63Jugil6F+vwBPQUsNBYeXoj2RyeCexSRYKeuTLiB5R0Hp2zdQDkTBkJ6e3xlnF oSgOnwnwp5x1tUtLJwuwJCQc4ltd8fPRTLVwO+XmP5PzOEVrmjovKz5lVpyCIpk245GK jiRQ== X-Gm-Message-State: AOAM532Mg5IUMKTLX4XiP1oP0pXXi5jXnTuGCgYvQnNPcU2MntiFivf3 Ubvk/w/LErWjytNbsPo1I8zG867/pALe9yJEBXo= X-Google-Smtp-Source: ABdhPJz2z14vMNZrV14WFdzi47HxelFbRgSaj7vNGOLts9OQrUX8IFfSrh1gmHZiRe2YjNGs8Bxoc/T+ADT80JVn57g= X-Received: by 2002:a05:620a:24cf:: with SMTP id m15mr7023068qkn.435.1622267157848; Fri, 28 May 2021 22:45:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alan Karp Date: Fri, 28 May 2021 22:45:45 -0700 Message-ID: To: Adrian Gropper Cc: Kathleen Moriarty , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000aca57105c3718185" Archived-At: Subject: Re: [GNAP] Defense protection 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, 29 May 2021 05:46:05 -0000 --000000000000aca57105c3718185 Content-Type: text/plain; charset="UTF-8" On Fri, May 28, 2021 at 1:09 PM Adrian Gropper wrote: > Thanks to Alan Karp, I have come to believe that delegation is essential > and GNAP needs to speak of capabilities as first-class tokens and encourage > their use. This will become the main driver for adoption of GNAP over SAML > or OAuth. > I would say attenuated delegation instead of just delegation. Revocation is important, too. -------------- Alan Karp On Fri, May 28, 2021 at 1:09 PM Adrian Gropper wrote: > Thanks to Alan Karp, I have come to believe that delegation is essential > and GNAP needs to speak of capabilities as first-class tokens and encourage > their use. This will become the main driver for adoption of GNAP over SAML > or OAuth. > > - Adrian > > > > On Fri, May 28, 2021 at 3:51 PM Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >> Hi Adrian, >> >> Thanks for your interest! >> >> This is a helpful link that describes how the attackers were able to >> bypass MFA by stealing the signing key for SAML assertions: >> >> https://www.darkreading.com/attacks-breaches/solarwinds-campaign-focuses-attention-on-golden-saml-attack-vector/d/d-id/1339794 >> >> https://owasp.org/www-chapter-singapore/assets/presos/Deconstructing_the_Solarwinds_Supply_Chain_Attack_and_Deterring_it_Honing_in_on_the_Golden_SAML_Attack_Technique.pdf >> >> I did read one that was a bit better, but can't find the link at the >> moment. >> >> And one on shared OAuth credentials/token issuance: >> >> https://www.csoonline.com/article/3607348/how-to-defend-against-oauth-enabled-cloud-based-attacks.html >> >> It would be good to think about attack vectors and if not prevention, >> minimally detection. >> >> Best regards, >> Kathleen >> >> On Fri, May 28, 2021 at 3:41 PM Adrian Gropper >> wrote: >> >>> Hi Kathleen, >>> >>> I am not aware of the attacks on SAML and OAuth and would appreciate a >>> link or two. >>> >>> I hope we can provide guidance on how GNAP can facilitate Zero Trust >>> Architecture and believe that includes guidance on how to audit various >>> things as systems use GNAP protocols to separate concerns among independent >>> actors. >>> >>> Count me in for a brainstorming sessio, >>> >>> - Adrian >>> >>> >>> On Fri, May 28, 2021 at 3:29 PM Kathleen Moriarty < >>> kathleen.moriarty.ietf@gmail.com> wrote: >>> >>>> Hello! >>>> >>>> In light of recent attacks against SAML and OAuth, I'd like to see what >>>> defense mechanisms and detection could be built into the spec. One example >>>> would be from the recent SAML attack. If there was a detection of >>>> instances of authorization without authentication, the SAML attack used in >>>> SolarWinds might have been detected sooner. >>>> >>>> If you think along the lines of fraud detection, where you detect >>>> unusual events, there may be some specific to GNAP that could enable early >>>> detection of abuse, misuse, or exploits. >>>> >>>> Are there some planned? Would people like to brainstorm on this? >>>> Thanks! >>>> >>>> >>>> -- >>>> >>>> Best regards, >>>> Kathleen >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> >> >> -- >> >> Best regards, >> Kathleen >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --000000000000aca57105c3718185 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On = Fri, May 28, 2021 at 1:09 PM Adrian Gropper <agropper@healthurl.com> wrote:
<= /div>
Th= anks to Alan Karp, I have come to believe that delegation is essential and = GNAP needs to speak of capabilities as first-class tokens and encourage the= ir use.=C2=A0 This will become the main driver for adoption of GNAP over SA= ML or OAuth.=C2=A0

I wo= uld say attenuated delegation instead of just delegation.=C2=A0 Revocation = is important, too.

--------------
Alan Karp


On Fri, May 28, 2021 at 1:0= 9 PM Adrian Gropper <agropper@healthurl.com> wrote:
Thanks to Alan Karp, I h= ave come to believe that delegation is essential and GNAP needs to speak of= capabilities as first-class tokens and encourage their use.=C2=A0 This wil= l become the main driver for adoption of GNAP over SAML or OAuth.=C2=A0

- Adrian



On Fri, May 28, 2021 at 3:51 PM K= athleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
I did read one that was a bit better, but can't find t= he link at the moment.

And one on shared OAuth cre= dentials/token issuance:

<= div>It would be good to think about attack vectors and if not prevention, m= inimally detection.

Best regards,
Kathle= en

On Fri, May 28, 2021 at 3:41 PM Adrian Gropper <agropper@healthurl.com> = wrote:
Hi=C2=A0Kathleen,

I am not aware of the attacks on SAML and OAuth and would appreciate a = link or two.

I hope we c= an provide guidance on how GNAP can facilitate Zero Trust Architecture and = believe that includes guidance on how to audit various things as systems us= e GNAP protocols to separate concerns among independent actors.=C2=A0
=

Count me in for a brainstormi= ng=C2=A0sessio,

- Adrian=


On Fr= i, May 28, 2021 at 3:29 PM Kathleen Moriarty <kathleen.moriarty.ietf@gmail.co= m> wrote:
Hello!

In light of recent attacks agai= nst SAML and OAuth, I'd like to see what defense mechanisms and detecti= on could be built into the spec.=C2=A0 One example would be from the recent= SAML attack.=C2=A0 If there was a detection of instances of authorization = without authentication, the SAML attack used in SolarWinds might have been = detected sooner.

If you think along the lines of f= raud detection, where you detect unusual events, there may be some specific= to GNAP that could enable early detection of abuse, misuse, or exploits.

Are there some planned?=C2=A0 Would people like to = brainstorm on this?
Thanks!


--

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


--

Best regards,
Kathleen
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000aca57105c3718185-- From nobody Sat May 29 08:01: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 35A9C3A1393 for ; Sat, 29 May 2021 08:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.704 X-Spam-Level: X-Spam-Status: No, score=-0.704 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, MIME_QP_LONG_LINE=0.001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cendyne.dev Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAZvCeTqUPPO for ; Sat, 29 May 2021 08:01:26 -0700 (PDT) Received: from mail.cendyne.dev (unknown [198.23.146.242]) (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 7D3793A1390 for ; Sat, 29 May 2021 08:01:26 -0700 (PDT) Received: by mail.cendyne.dev (Postfix) with ESMTPSA id 483821F492; Sat, 29 May 2021 16:01:24 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cendyne.dev; s=default; t=1622300484; bh=xul8dpIE39OSJjp/p0d370h5R/GowfDMDhy9xOGjTIg=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From; b=WGR5IV58lsuY6mDSa0RZpGBXPhZ272IOK1xSysvPxysyWTuPX5dVKdHzDLZV0+abe dCIbz663KUci7kVCmtrxdqAQvu6jm2/grf249ifTwqF08sUQrS+njnrCebZQ+uvri2 1rMuyF6ev9ul44mkEk6ok7/ourVo0qaYX2C+8IRiaFtE3Me16Px0KbHy1243UMLT3c nZRvR0e6hPMH0oFXmOe9/7O2bYeaVLAo5/PsLs9N3KrLguac/uhPY6s28xqTv+tkOC 56xLDwOKjdh0lDm0tuz0jC6dx8xFCCmEcBcO0rZrbMORPtE3v2P4wD6nR4Cn68yLGT eV09Lurk1NVqA== Content-Type: multipart/alternative; boundary=Apple-Mail-5A47A149-6F50-4B37-8762-F146CC6C22F3 Content-Transfer-Encoding: 7bit From: Cendyne Mime-Version: 1.0 Date: Sat, 29 May 2021 10:01:22 -0500 Message-Id: <4B21A65B-6FBD-4D03-8D79-DCC7C8E42551@cendyne.dev> References: Cc: Adrian Gropper , Kathleen Moriarty , GNAP Mailing List In-Reply-To: To: Alan Karp X-Mailer: Cendyne 1.0 Archived-At: Subject: Re: [GNAP] Defense protection 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, 29 May 2021 15:01:31 -0000 --Apple-Mail-5A47A149-6F50-4B37-8762-F146CC6C22F3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Alan, What does attenuated delegation mean and entail? I am not finding a definitive definition online. > On May 29, 2021, at 12:46 AM, Alan Karp wrote: >=20 > =EF=BB=BF >> On Fri, May 28, 2021 at 1:09 PM Adrian Gropper w= rote: >> Thanks to Alan Karp, I have come to believe that delegation is essential a= nd GNAP needs to speak of capabilities as first-class tokens and encourage t= heir use. This will become the main driver for adoption of GNAP over SAML o= r OAuth.=20 >=20 > I would say attenuated delegation instead of just delegation. Revocation i= s important, too. >=20 > -------------- > Alan Karp >=20 >=20 >> On Fri, May 28, 2021 at 1:09 PM Adrian Gropper w= rote: >> Thanks to Alan Karp, I have come to believe that delegation is essential a= nd GNAP needs to speak of capabilities as first-class tokens and encourage t= heir use. This will become the main driver for adoption of GNAP over SAML o= r OAuth.=20 >>=20 >> - Adrian >>=20 >>=20 >>=20 >>> On Fri, May 28, 2021 at 3:51 PM Kathleen Moriarty wrote: >>> Hi Adrian, >>>=20 >>> Thanks for your interest! >>>=20 >>> This is a helpful link that describes how the attackers were able to byp= ass MFA by stealing the signing key for SAML assertions: >>> https://www.darkreading.com/attacks-breaches/solarwinds-campaign-focuses= -attention-on-golden-saml-attack-vector/d/d-id/1339794 >>> https://owasp.org/www-chapter-singapore/assets/presos/Deconstructing_the= _Solarwinds_Supply_Chain_Attack_and_Deterring_it_Honing_in_on_the_Golden_SAM= L_Attack_Technique.pdf >>>=20 >>> I did read one that was a bit better, but can't find the link at the mom= ent. >>>=20 >>> And one on shared OAuth credentials/token issuance: >>> https://www.csoonline.com/article/3607348/how-to-defend-against-oauth-en= abled-cloud-based-attacks.html >>>=20 >>> It would be good to think about attack vectors and if not prevention, mi= nimally detection. >>>=20 >>> Best regards, >>> Kathleen >>>=20 >>>> On Fri, May 28, 2021 at 3:41 PM Adrian Gropper = wrote: >>>> Hi Kathleen, >>>>=20 >>>> I am not aware of the attacks on SAML and OAuth and would appreciate a l= ink or two. >>>>=20 >>>> I hope we can provide guidance on how GNAP can facilitate Zero Trust Ar= chitecture and believe that includes guidance on how to audit various things= as systems use GNAP protocols to separate concerns among independent actors= .=20 >>>>=20 >>>> Count me in for a brainstorming sessio, >>>>=20 >>>> - Adrian >>>>=20 >>>>=20 >>>>> On Fri, May 28, 2021 at 3:29 PM Kathleen Moriarty wrote: >>>>> Hello! >>>>>=20 >>>>> In light of recent attacks against SAML and OAuth, I'd like to see wha= t defense mechanisms and detection could be built into the spec. One exampl= e would be from the recent SAML attack. If there was a detection of instanc= es of authorization without authentication, the SAML attack used in SolarWin= ds might have been detected sooner. >>>>>=20 >>>>> If you think along the lines of fraud detection, where you detect unus= ual events, there may be some specific to GNAP that could enable early detec= tion of abuse, misuse, or exploits. >>>>>=20 >>>>> Are there some planned? Would people like to brainstorm on this? >>>>> Thanks! >>>>>=20 >>>>>=20 >>>>> --=20 >>>>>=20 >>>>> Best regards, >>>>> Kathleen >>>>> --=20 >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>=20 >>>=20 >>> --=20 >>>=20 >>> Best regards, >>> Kathleen >>> --=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-5A47A149-6F50-4B37-8762-F146CC6C22F3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Alan,

What does attenuated delegatio= n mean and entail?
I am not finding a definitive definition online.

= On May 29, 2021, at 12:46 AM, Alan Karp <alanhkarp@gmail.com> wrote:
=EF=BB=BF=
On Fri= , May 28, 2021 at 1:09 PM Adrian Gropper <agropper@healthurl.com> wrote:
=
Thanks to= Alan Karp, I have come to believe that delegation is essential and GNAP nee= ds to speak of capabilities as first-class tokens and encourage their use.&n= bsp; This will become the main driver for adoption of GNAP over SAML or OAut= h. 

I would say attenu= ated delegation instead of just delegation.  Revocation is important, t= oo.

-----------= ---
Alan Karp


On Fri, May 28, 2021 at 1:09 PM Adrian Groppe= r <agropper@h= ealthurl.com> wrote:
Thanks to Alan Karp, I have come to believe that= delegation is essential and GNAP needs to speak of capabilities as first-cl= ass tokens and encourage their use.  This will become the main driver f= or adoption of GNAP over SAML or OAuth. 

- Adrian



On Fri, May 28, 2021 at 3:51 PM Kathleen Moriarty <kathleen.moriart= y.ietf@gmail.com> wrote:
Hi Adrian,

Thanks for your= interest!

This is a helpful link that describes ho= w the attackers were able to bypass MFA by stealing the signing key for SAML= assertions:

I did read one that was a bit b= etter, but can't find the link at the moment.

And o= ne on shared OAuth credentials/token issuance:
https://www.csoonline.com/article/3607= 348/how-to-defend-against-oauth-enabled-cloud-based-attacks.html

It would be good to think about attack vectors and if n= ot prevention, minimally detection.

Best regards,
Kathleen

On Fri, May 28, 2021 at 3:41 PM Adrian Gropper <agropper@healthurl.c= om> wrote:
=
Hi Kathleen,

I am not aware of the attacks on SAML and OAuth and would appreci= ate a link or two.

I hope= we can provide guidance on how GNAP can facilitate Zero Trust Architecture a= nd believe that includes guidance on how to audit various things as systems u= se GNAP protocols to separate concerns among independent actors. 
=

Count me in for a brainstormin= g sessio,

- Adrian


On Fri, M= ay 28, 2021 at 3:29 PM Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com&= gt; wrote:
Hello!

In light of recent attacks against SAML a= nd OAuth, I'd like to see what defense mechanisms and detection could be bui= lt into the spec.  One example would be from the recent SAML attack.&nb= sp; If there was a detection of instances of authorization without authentic= ation, the SAML attack used in SolarWinds might have been detected sooner.

If you think along the lines of fraud detection, whe= re you detect unusual events, there may be some specific to GNAP that could e= nable early detection of abuse, misuse, or exploits.

Are there some planned?  Would people like to brainstorm on this?
Thanks!


<= /div>--

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


--
=

Best regards,
Kathleen
= --
TXAuth mailing list
TXAuth@ietf.org
= https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.or= g
https://www.ietf.org/mailman/listinfo/txauth
= --Apple-Mail-5A47A149-6F50-4B37-8762-F146CC6C22F3-- From nobody Sun May 30 01:52: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 E7A1F3A34D3 for ; Sun, 30 May 2021 01:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 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, 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=FnirDTA9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=n4zikjkW Received: 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-buPyktK97m for ; Sun, 30 May 2021 01:51:56 -0700 (PDT) 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 3AB7F3A34D1 for ; Sun, 30 May 2021 01:51:56 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 6CFDFE1F for ; Sun, 30 May 2021 04:26:58 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sun, 30 May 2021 04:26:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm2; bh=ntqmAGYa1O0 y8A8wV7uyPFgEtUwfQi4eoAvMnNSSc2I=; b=FnirDTA9ufBSIH/YtciLYOtaV1p 7PhowlrV3VQ3z2k7QjkfAcmwysOqwyf1GL2tvA00cUYRo4zUx4WRz5cm+h6XCRP4 BG6LLaehFIq2CIoQQd2o4qhI1sFLIWEsSmHp+kTG9q6G9sesmJ4z8zJndVIhaGH2 TwMub6JW4Xob6yeu99uSEC3vGUV3K9fNPgOlZrShNVe7gjMy7sS9RycdBB/Mqhqh 30e6lDpxxzh2sn/henB3q3o3/L75cEoFOr5IyHnABiS8HR1RGTSGKo/7UN4qjedI 6tdVR2Zj9Pw97Mj5tsH/mMr17vE6oAQuBdd1XMxr3wxzt5bpVdKWchNsKAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:from:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=ntqmAGYa1O0y8A8wV7uyPFgEtUwfQi4eoAvMnNSSc2I=; b=n4zikjkW /3NN+MigdXQ4n0wiW4/88GX7rXvWei015NxAeI/ASjdpk42xVBd4hGdtYUxllFcw 7xrmByRB9VE8WwAIOWCMiArkFZQubhM+VBYz907ELj714rHxvOoPrKq1NFSi1n++ BbjUr8zWab01QNnRCp80V3MKNFPVc5zWq9p+3rbEve+RJntmcv3q7iz7l5CqGAdL iRCxB/aABRruzC4CcmxormCF6MG05uM5NzRCvpTZNIdoXMNs/neGvU2tPEmwZIKk Lnn9BJlY1PW6ZgcXgb/HptxtBJNkfxlAE8sL25hby3/2rl9x0kjK+30sDjlMFwwH uVdHdhxsSLRdUQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeluddgtdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucfkphepudefrdekvddrkeefrddvvdeknecuvehluhhsthgvrhfuihiivgepfeen ucfrrghrrghmpehmrghilhhfrhhomhepughopghnohhtpghrvghplhihsehmnhhothdrnh gvth X-ME-Proxy: Received: from fv-az201-811.ett4tu3jvdse5ovc2mkgjqcs5a.bx.internal.cloudapp.net (unknown [13.82.83.228]) by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 30 May 2021 04:26:57 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============4982331355697448104==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20210530085156.3AB7F3A34D1@ietfa.amsl.com> Date: Sun, 30 May 2021 01:51:56 -0700 (PDT) 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, 30 May 2021 08:52:01 -0000 --===============4982331355697448104== 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/-1/=F0=9F=92=AC0) 5 issues created: - The access token verifications to be perfomed by the RS should be descr= ibed (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/266=20 - What kind of control may a client have about the content of a returned = access token ? (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/265=20 - How can an AS determine "what is needed" to fulfill the request ? (by D= enisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/264=20 - Negotiation of the token format by the client should be mentioned in se= ction 1.4 (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/263=20 - Should the reader understand that a RS can only be protected by a singl= e AS ? (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/262=20 1 issues closed: - The first figure in section 1.4 should be split and revisited https://g= ithub.com/ietf-wg-gnap/gnap-core-protocol/issues/192 [Pending Close]=20 * ietf-wg-gnap/gnap-resource-servers (+3/-1/=F0=9F=92=AC0) 3 issues created: - A section describing the structure of the list of token formats is curr= ently missing (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/29=20 - Examples about Macaroons and Biscuits are currently inappropriate (by = Denisthemalice) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/28=20 - Access Token Formats Negotiation (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/27=20 1 issues closed: - Token formats can also be advertised both by AS and RS https://github.c= om/ietf-wg-gnap/gnap-resource-servers/issues/3 [Pending Close]=20 Pull requests ------------- * ietf-wg-gnap/core-protocol (+0/-1/=F0=9F=92=AC0) 1 pull requests merged: - add privileges field https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/259 [Pending Me= rge]=20 * ietf-wg-gnap/gnap-resource-servers (+0/-0/=F0=9F=92=AC1) 1 pull requests received 1 new comments: - #26 move client-facing rs-first discovery back to gnap core, addresses = ietf-wg-gnap/gnap-core-protocol#260 (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/26=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol * https://github.com/ietf-wg-gnap/gnap-resource-servers --===============4982331355697448104== 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 May 30, 2021

Events without label "editorial"

Issues

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

5 issues created:

1 issues closed:

ietf-wg-gnap/gnap-resource-servers (+3/-1/=F0=9F=92=AC0)

3 issues created:

1 issues closed:

Pull requests

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

1 pull requests merged:

ietf-wg-gnap/gnap-resource-servers (+0/-0/=F0=9F=92=AC1)

1 pull requests received 1 new comments:

Repositories tracked by this digest:

--===============4982331355697448104==--