From nobody Sun Jan 3 00:06:01 2021 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020D63A0AD4 for ; Sun, 3 Jan 2021 00:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.219 X-Spam-Level: X-Spam-Status: No, score=-0.219 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_MSPIKE_H3=-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=oKNDg4t4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=G0tz3uR8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82wStFBRWqu6 for ; Sun, 3 Jan 2021 00:05:58 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45A6F3A0AF7 for ; Sun, 3 Jan 2021 00:05:58 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id C43DC71B for ; Sun, 3 Jan 2021 02:56:28 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 03 Jan 2021 02:56:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=z5QUthlN0vaaLGf8IJRrunalg31JsOZDSacLmJPlZXA=; b=oKNDg4t4 RkfpqYyOQG8Cms6lQbFVSpKDqO6o+G87BwtoVrviGPPjao1K1fx9tJQoJbsGX+GW rHB7fV6GNzU+fspok57gvr17fCnAgusKVD7cTySNnFS8Uel1BuT1meH3wbLv4QIb ITbxMTYiRLDdyydlUinslFTXIjQeh+OkGwJRxWubVNvq1ZuJhiNHPkmkkmdPMJkJ W1BbD4VWflibCARypwN8ysdeJ05p+0/Qq/6jy5p/9+zNgE6NLq6q9dQ9XExuWHTH AUVHjYdtMwRWmX8x/lZvnefGCpGN5SuP/2M1mycceRllxraG1Ln+iPDNpnZ1x/ci lBECbmRgw8xVow== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=z5QUthlN0vaaLGf8IJRrunalg31Js OZDSacLmJPlZXA=; b=G0tz3uR8Xo94e4Cp2pQBXr0svPFzTV65XZfu6gfzftafr 7r+RLK9Rtw0utC1C+sIfi8J8q8I4Rk/28g6C9d9xFQ1jal6snbug78M19GR+Wtd1 639LcZ3P3Ka4qjiHnHSGKvBRegmq2xhhHj37g3DRHUcN5e95W8JsE9l61Y1AMZ6I mLGawRtvWi9oeiBCocH6wiMa7gj2tPfzd8gK84fcWeVBXWDU4JV3qKxUA2Gq+D1k y/SDtz1WkquzCOUnwH2NHz4X7jbpxSn94rUnMT3Dg+YjnPi7WYCGgoFqzBuWrQTs 0a1hviXj9zvoC3x+wBzTDWUg0REvVVVlk5HrZix2Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdeftddgudduhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeehvddrvdehgedrkeegrd ejfeenucevlhhushhtvghrufhiiigvpeefnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az50-739.internal.cloudapp.net (unknown [52.254.84.73]) by mail.messagingengine.com (Postfix) with ESMTPA id 422101080057 for ; Sun, 3 Jan 2021 02:56:28 -0500 (EST) Content-Type: multipart/alternative; boundary="===============3245434048161017176==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20210103075628.422101080057@mailuser.nyi.internal> Date: Sun, 3 Jan 2021 02:56:28 -0500 (EST) Archived-At: Subject: [GNAP] Weekly github digest (GNAP Weekly GitHub Activity Summary) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2021 08:06:00 -0000 --===============3245434048161017176== 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=AC0) 1 issues created: - Common means to dereference key references (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/154=20 Pull requests ------------- * ietf-wg-gnap/core-protocol (+1/-0/=F0=9F=92=AC2) 1 pull requests submitted: - fix small bug about sub_ids in grant response (by nerocrux) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/153=20 2 pull requests received 2 new comments: - #153 fix small bug about sub_ids in grant response (1 by yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/153 [Editorial]= =20 - #152 Refactor "key" section (1 by github-actions) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/152=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol --===============3245434048161017176== 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 January 03, 2021

Events without label "editorial"

Issues

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

1 issues created:

Pull requests

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

1 pull requests submitted:

2 pull requests received 2 new comments:

Repositories tracked by this digest:

--===============3245434048161017176==-- From nobody Tue Jan 5 05:04:17 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 D35803A0C3A for ; Tue, 5 Jan 2021 05:04:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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] 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 G8gI-VjuExBy for ; Tue, 5 Jan 2021 05:04:14 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7211D3A0EC4 for ; Tue, 5 Jan 2021 05:04:14 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id i18so28125641ioa.1 for ; Tue, 05 Jan 2021 05:04:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=VrhT/pkOfCD9un0Sr+UNqLNna8HJxeVpkdfo2z2l9gI=; b=Dt/zYmgsbmS72ViT026z71fCMvhFrg5ON6qhlcD8VecX8EuXJhDxkeT/S3i5fmP+A5 nJgMaxJTLfaRl+AHNLC2+igrAcLdnc7mvnSGg6FIUtfeUNh7DgN5nL8GhAsyqS6tygM7 hNK4An2eX2ouM5/HTQoH1PXqjWXjVorKUtp82lviQIyNjFZeo78SyytOYwONHx92Q7Rq Wd6PMdQMFyPCbdWviZUDiKPgEWsReknoUwxiA5I0ylUVnEB9AHctLNm12Im3fYQOK08Q Hk6yZzBcrhOB3nf/+uMeWQO1UcawtbhI2tw+9z1DxHQowVg/20D9ROGmahJPBxrViKih yxFw== 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=VrhT/pkOfCD9un0Sr+UNqLNna8HJxeVpkdfo2z2l9gI=; b=S4bYnA9oJkAsugfG3ncYmturp6i9MvlkvPgnKN47B7gPKaZBTT25NSIpxG7/NVbI0q 9xPpb9nWstMEvlHZQGxUzexG6EloJj0kc4e3W/STQWy07gEkSHBc9/0UE3/smejHo6tO fkCxLhHMuDVDWI48y2jlx+oLBL+AMaCivM3tgWdQnv2CR6lxwQm08TrYVm+Fmr8j42UN gSP42mH8+A0zvcGe1ZvxzY7kLngoEqB7oI67UbjnvB4sRhN/ADeWUgKA52A+BgGG810M qmaX4rWNj/foCouBF4epdMqszhbwQ3idNiVrkjvjvUT7eJknoRg4xxmQR2O4wGmIyE9D eQiQ== X-Gm-Message-State: AOAM53320lejNKqcfFx+Wz3JMLC8s14gWt+JXVczxwE7uLqe4XHF38hc K+38pgqsRUdkhJnOfLD5FUy7yBgKwFDS0UgkwJfaYwQTZhxAPKnc X-Google-Smtp-Source: ABdhPJz+0FlUrW8tC5jSrib069UbDlBnJwHB2KPut/y7X/6lRnSaLHcXK7SDnvxB8Zntq4/hUwac5vSbuTabuse2zpU= X-Received: by 2002:a6b:7a0c:: with SMTP id h12mr63266588iom.162.1609851853488; Tue, 05 Jan 2021 05:04:13 -0800 (PST) MIME-Version: 1.0 From: Fabien Imbault Date: Tue, 5 Jan 2021 14:04:01 +0100 Message-ID: To: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000de474705b826d792" Archived-At: Subject: [GNAP] Terminology PR X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 13:04:16 -0000 --000000000000de474705b826d792 Content-Type: text/plain; charset="UTF-8" Hi everyone, I wish you all a happy new year. I just created a PR ( https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/155) that takes into account the various feedbacks. The automatic build process is not working, but you can see the diffs and build the html locally if you prefer. The definitions have also been updated on the wiki ( https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology) if you prefer to check there. Feedbacks welcome before we move to pending merge later on. Cheers Fabien --000000000000de474705b826d792 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,=C2=A0

I wish you all a= happy new year.

I just created a PR (https://github.= com/ietf-wg-gnap/gnap-core-protocol/pull/155) that takes into account t= he various feedbacks. The automatic build process is not working, but you c= an see the diffs and build the html locally if you prefer. The definitions = have also been updated on the wiki (https://github.com/ietf-wg-gnap/gn= ap-core-protocol/wiki/Terminology) if you prefer to check there.=C2=A0<= /div>

Feedbacks welcome before we move to pending merge = later on.

Cheers
Fabien
--000000000000de474705b826d792-- From nobody Tue Jan 5 11:38:28 2021 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D923A1051 for ; Tue, 5 Jan 2021 11:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=openconsent.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzTg5FDR14iy for ; Tue, 5 Jan 2021 11:38:25 -0800 (PST) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2108.outbound.protection.outlook.com [40.107.220.108]) (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 D7DA13A0FED for ; Tue, 5 Jan 2021 11:38:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HQmOxX9MYCbgakhfSybgOKtgZAq11jlNMTYPVjsXfsAf5kmbyLU0cwt/v+KJnUWHxwdx73PgllodPvyH3AZSVa0gjYIw8FwRUKpspyH0po44Zy42RMXS5+LkESkhT+Y2nBHASw70guYyD5VHBWC1XuIHf1FjdKZzVHzMHN1KCjx+Fb6p1bOA2X4Q8HQo5koYYYMGXg2vf+83j7zzTOI7seOXNUEhaCKVGTP4nNfrLoO4AiP5iiyuMy0nqXBlsEBIHoDq2dBYfTY+7F5yMjPadnovIIvzLXBLER7oHcjel4zuEgdcmT5MF5A9kSRCnzNp9PHpfoo1BS8uidsP7eBlIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jUDJjVeyo8muDGRi9+p2u2bOAsb6M1nYpwda0VOwm+4=; b=PiKvdt1eKG/mJRgETLkek8JqOH2rwC0eFjC4VCMt/JHNBePmJjXZ/CVKrWvfpjpG8wrLa+m4nghYf3kVSiQHLzOWbN/mWax/2ctHr/ogAgS3VgcgmwYPn5nWA8nbEnUl1DbI1rkTDsay5uqNodcPSIps363CuUeb+AcK5LDP5ciqlwd+lH4NKGY4B1RyqdjOU3hAdPC68djA4bqJ1wORJe5bKhfpb289+A1zJI4MECOHS/awoB3gpaguiyngftDY1hRew+PZs6nttxpH1SXxvfTYX4x2jBDpu1a8o9v6W7EAEwtisC2RWn3GLVfH774eALSe5ta33N/Uz16fr6He+A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=openconsent.com; dmarc=pass action=none header.from=openconsent.com; dkim=pass header.d=openconsent.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openconsent.onmicrosoft.com; s=selector1-openconsent-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jUDJjVeyo8muDGRi9+p2u2bOAsb6M1nYpwda0VOwm+4=; b=DxBV4oX2AZcGXC8JsYmfalveNH8uH2i3OLSPHjFLFJh+wxKJIVedFgUusgDmou00vvUTu5/OwcfnCt3a5zjH8gljaqNH0tB6OoqknrbOMgF2+CviFH6zs3+A4ccOGP/6taB6SD/OTKyU4+sc1N3tj9DJy6KxY2fp+b/6fI3iILd3sa7pJpj/0yDUWGQmfECbLcAuN9WLMwqo8VNMiyy2sKP20rYWENK0uojCJj6pFDuJpsaASyZSJgDvqkTQWKXO4SyWB26uxSaS7Q4QPOtGjIKKG5aQ3NuBd0dml2oaicinMoQJNplwhRIkOpvOU7qD0n210R357fUVRlp3zqazCA== Received: from DM6PR14MB2652.namprd14.prod.outlook.com (2603:10b6:5:11e::10) by DM5PR14MB1242.namprd14.prod.outlook.com (2603:10b6:3:8a::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3721.20; Tue, 5 Jan 2021 19:38:21 +0000 Received: from DM6PR14MB2652.namprd14.prod.outlook.com ([fe80::204c:cbc4:657f:cc52]) by DM6PR14MB2652.namprd14.prod.outlook.com ([fe80::204c:cbc4:657f:cc52%6]) with mapi id 15.20.3721.024; Tue, 5 Jan 2021 19:38:21 +0000 From: Mark Lizar To: Fabien Imbault CC: GNAP Mailing List Thread-Topic: [GNAP] Terminology PR Thread-Index: AQHW42NLM5ZFUPNG80uup/zfJmIKUKoZbdyA Date: Tue, 5 Jan 2021 19:38:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=openconsent.com; x-originating-ip: [193.148.18.103] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 380531c9-9c67-459c-45bf-08d8b1b175c9 x-ms-traffictypediagnostic: DM5PR14MB1242: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: cOv050NacC/wW/ySdKkdJh/9wxNz2jaoYPeNK1mLDyaJEsDxzn1K3s7GMhNsmd95cYLlChbfzow56pVrkCGt7SifUNkG+opHnQ+dGk/6TgVjxh5EyuE8nsbntjvQ33aEYvN8+RUSiV7Sti2tP+RZ7UYGSi8zAfKYgziCpg+LexhBc1RNUM6EAec95Eu0HHsygZFutRdZXQBU+gDDqiJ55kFPgJsg6MI9rBNhjCxaSC60a0BdhIOFx2HrHoHThkp0KM44ZRCRUhJtfxr0sX+UdjAlA+yixv0PEa4kbX+Rp2zFaYvDIF+drBOkN6xdZMym1v2sdxVGtXy9hoo4z/JSFlub+lDoUCT3KxCmi8gysTtz2j4qR0CGED1OF6j6SAhKh7jomYUA+dwqNN57spGTgI7lOiowtWUwQd62Pb/O836Z8+cR4OZn67nSprHhCOCNqAljFNidtEcMcnyna6PhdR8H23WWRZffLK2J9miabyR0m8goY7DULIPagF53B5Ex/6We6en+zyAdnlwqsXxZuQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR14MB2652.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(366004)(39830400003)(376002)(136003)(396003)(83380400001)(166002)(71200400001)(6916009)(6512007)(53546011)(4326008)(36756003)(33656002)(26005)(186003)(66476007)(6506007)(8936002)(316002)(86362001)(66946007)(5660300002)(64756008)(66556008)(91956017)(966005)(478600001)(6486002)(76116006)(2906002)(8676002)(66446008)(2616005)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?MHlYRm9SejJoQmN1MHgveW5BWnBsUy9KbVdWRkxLSzFyYjJ6MjRzWjRQMVRP?= =?utf-8?B?MWdzV2pqQlR4ZW1POW5MZDNiYlVDR1RPRHozanFEakFvMVI3RWVkVWZxSTdO?= =?utf-8?B?dXZOVit5MnhFb0loc3FlTTl1YW5EMk1SU1B6RVkxakllbHMvU3Y4cXU0cTI4?= =?utf-8?B?T1NvdG9PZk1KZTlXL1NmUnprOWo0ZHlLZFdrcFFjUDllV1Q2b3kveldKdEd4?= =?utf-8?B?L1lzTlZxekkyNzF2TEMrSDh1Z3lhSU1SeUR2dzVnVlVhTEZSaVNHTmZEc2NQ?= =?utf-8?B?U1NUaXRuU3c0RWQ3SGVNQnYrL21NZVh3Z1B6Ri9lSHFCM1N2Z3BHWGFTb2E1?= =?utf-8?B?a0ozMFVhQWRaZ29odnVnUGUwWURkWnlTdmRnQjdxM0RGQlhidzlwNURZMVJt?= =?utf-8?B?b3RjKzdpL21TNTVFT0xINlZtcDhQYUwrUy9Jc2kzdW1EM0pDVmhFd2tncXRS?= =?utf-8?B?NGtMMVNGeUFiS0pQdGNXZGwydTRHRkJmYnhPWWVXY1dKcXc4Y25xT2pDbTJ3?= =?utf-8?B?a3l0aFFxeFpzRnBWdDh0WHVvUUJQcVVpZDhHa0hRcVl3M2tETjhKMnpiTlRH?= =?utf-8?B?YWhNOWxZbzNMMldEVkt0WTRZMjBqMVFvNEVTR0JkWW8zbmFkczYwd1dhcVpa?= =?utf-8?B?aTRXR2ZLQzA4MktrTDVxL3M2c2plSENsOWVkdGNDaGFOUUhEaldwQ2s2cW5G?= =?utf-8?B?aURTT3VObG9OMXFrRWZRUUUzWWl1ajZITVVaWi82eUhVd0xPLzVZaXluVEJX?= =?utf-8?B?eFB1MXdRT3pySVFyd0xNUXI3aE13WWFyWTBwOWJuWmZVY1RacHZzczRXa3Y2?= =?utf-8?B?dWgzdWM3czBsZjlFRjd3TER3eHl2RzY5RXJTejlWSklPWTU0cWo4U2ZRcTdq?= =?utf-8?B?MVhiWVl4STBLRHRWR2tucHVQK2RtdUVYWVhpUkRSRDJMejF6SmlIczNWM0Rr?= =?utf-8?B?NGhFOUdQTGxVajdacmQ4czhJQnJqYk0zM0Focm4zdkVZemZYQklOWTRlK2NT?= =?utf-8?B?a3BpMUNiYjhxejhXQ2dMSGErdm5lSEU1VERBYjVPYURMOFFiNDFHOFJVTFNY?= =?utf-8?B?VVpFMWdkRmtFMWovVEg0UnY1L3JTTENrdzh6bmcrL3RpMlZEejJaak55ME8y?= =?utf-8?B?RzVzY0czNFB1MmtmcW4zdFNhYzZtMjRRNFpiSHRMTFVHNzB1RkV6Z2V1bDAz?= =?utf-8?B?UEVvY0VGbWRidTY3T3RieEt0NVdYYzRpQUpUVmNpK2o2VFdYYXZmdUtEL1dv?= =?utf-8?B?eDRMbktOTzU0a0lLcGcxbStOckQ0NTN3T21sT0Y5YWFRNHRSeGVWY1ltSFVN?= =?utf-8?Q?v3rP9HgfGsxXLDtsoWSDnE9o9PFwL5p5WK?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DAB2E8D3DC9F45028D6E5BE2066AEF88openconsentcom_" MIME-Version: 1.0 X-OriginatorOrg: openconsent.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR14MB2652.namprd14.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 380531c9-9c67-459c-45bf-08d8b1b175c9 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2021 19:38:21.5848 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d6e4f995-32e4-4f49-9949-0abe865e4152 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: QaqXVgFeYQSy7abJAFYeJ/1ZFxW+eIXvtixqTgD5/1+Th5pmzrDhu/inGJG55iqIbuL3UeNUWRy2NUdqIq6XoQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR14MB1242 Archived-At: Subject: Re: [GNAP] Terminology PR X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 19:38:27 -0000 --_000_DAB2E8D3DC9F45028D6E5BE2066AEF88openconsentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRmFiaWVuLCAgZXQgYWwsDQoNCkdyZWF0IHN0YXJ0ISENCg0KQ291bGQgeW91IGNsYXJpZnkg dGhlIHVzZSBhbmQgYXBwbGljYXRpb24gb2YgdGhlIHRlcm0gc3ViamVjdCwgYXMgdGhlIHRlcm0g aXMgdXNlZCBpbiBzb21lIGxlZ2FsIHN0YW5kYXJkcyBmb3Igc2VtYW50aWNzIGFuZCBJIHdvbmRl ciBpZiB0aGlzIGlzIHJlbGF0ZWQgdG8gdGhlIGxlZ2FsIHNlbWFudGljIGF0dHJpYnV0aW9uIG9m IGRhdGEgc3ViamVjdC4NCg0KSW4gdGhlIGdsb3NzYXJ5LCAgaXQgYWxzbyBzZWVtcyB0aGUgU3Vi amVjdCBFbnRpdHkgaXMgcmVmZXJyaW5nIHRvIHdoYXQgaXMgY29tbW9ubHkga25vdyBhcyBsZWdh bCBlbnRpdHkuICAgQW5kIHRoZSB0ZXJtIHN1YmplY3QgY2FuIHJlZmVyIHRvIGEgZmV3IHRoaW5n cyBhdCB0aGlzIHRlY2huaWNhbCBsZXZlbC7igJQgZS5nLiAgYSBzZW1hbnRpYyB0ZXJtIHJlZmVy ZW5jaW5nIGluIGdlbmVyYWwgdGhlIHRvcGljIG9mIHRoZSByZXNvdXJjZSAgb3IgaXMgaXQgdGhl IGxlZ2FsIGVudGl0eSAvIGNyZWRlbnRpYWwgdGhhdCBjb3JyZXNwb25kcyB0byB0aGUgYWNjb3Vu dGFibGUgY29udHJvbGxlciBvZiBhIHJlc291cmNlID8NCg0KLSBNYXJrDQoNCk9uIDUgSmFuIDIw MjEsIGF0IDA4OjA0LCBGYWJpZW4gSW1iYXVsdCA8ZmFiaWVuLmltYmF1bHRAZ21haWwuY29tPG1h aWx0bzpmYWJpZW4uaW1iYXVsdEBnbWFpbC5jb20+PiB3cm90ZToNCg0KSGkgZXZlcnlvbmUsDQoN Ckkgd2lzaCB5b3UgYWxsIGEgaGFwcHkgbmV3IHllYXIuDQoNCkkganVzdCBjcmVhdGVkIGEgUFIg KGh0dHBzOi8vZ2l0aHViLmNvbS9pZXRmLXdnLWduYXAvZ25hcC1jb3JlLXByb3RvY29sL3B1bGwv MTU1KSB0aGF0IHRha2VzIGludG8gYWNjb3VudCB0aGUgdmFyaW91cyBmZWVkYmFja3MuIFRoZSBh dXRvbWF0aWMgYnVpbGQgcHJvY2VzcyBpcyBub3Qgd29ya2luZywgYnV0IHlvdSBjYW4gc2VlIHRo ZSBkaWZmcyBhbmQgYnVpbGQgdGhlIGh0bWwgbG9jYWxseSBpZiB5b3UgcHJlZmVyLiBUaGUgZGVm aW5pdGlvbnMgaGF2ZSBhbHNvIGJlZW4gdXBkYXRlZCBvbiB0aGUgd2lraSAoaHR0cHM6Ly9naXRo dWIuY29tL2lldGYtd2ctZ25hcC9nbmFwLWNvcmUtcHJvdG9jb2wvd2lraS9UZXJtaW5vbG9neSkg aWYgeW91IHByZWZlciB0byBjaGVjayB0aGVyZS4NCg0KRmVlZGJhY2tzIHdlbGNvbWUgYmVmb3Jl IHdlIG1vdmUgdG8gcGVuZGluZyBtZXJnZSBsYXRlciBvbi4NCg0KQ2hlZXJzDQpGYWJpZW4NCi0t DQpUWEF1dGggbWFpbGluZyBsaXN0DQpUWEF1dGhAaWV0Zi5vcmc8bWFpbHRvOlRYQXV0aEBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoDQoNCg== --_000_DAB2E8D3DC9F45028D6E5BE2066AEF88openconsentcom_ Content-Type: text/html; charset="utf-8" Content-ID: <68B70129F1C72E4685453B60CE992AB3@namprd14.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpIEZhYmllbiwgJm5ic3A7ZXQgYWwsDQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+R3JlYXQgc3RhcnQhITwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Db3VsZCB5b3UgY2xhcmlmeSB0aGUgdXNlIGFu ZCBhcHBsaWNhdGlvbiBvZiB0aGUgdGVybSBzdWJqZWN0LCBhcyB0aGUgdGVybSBpcyB1c2VkIGlu IHNvbWUgbGVnYWwgc3RhbmRhcmRzIGZvciBzZW1hbnRpY3MgYW5kIEkgd29uZGVyIGlmIHRoaXMg aXMgcmVsYXRlZCB0byB0aGUgbGVnYWwgc2VtYW50aWMgYXR0cmlidXRpb24gb2YgZGF0YSBzdWJq ZWN0LiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+SW4gdGhlIGdsb3NzYXJ5LCAmbmJzcDtpdCBhbHNvIHNlZW1zIHRoZSBTdWJq ZWN0IEVudGl0eSBpcyByZWZlcnJpbmcgdG8gd2hhdCBpcyBjb21tb25seSBrbm93IGFzIGxlZ2Fs IGVudGl0eS4gJm5ic3A7IEFuZCB0aGUgdGVybSBzdWJqZWN0IGNhbiByZWZlciB0byBhIGZldyB0 aGluZ3MgYXQgdGhpcyB0ZWNobmljYWwgbGV2ZWwu4oCUIGUuZy4gJm5ic3A7YSBzZW1hbnRpYyB0 ZXJtIHJlZmVyZW5jaW5nIGluIGdlbmVyYWwgdGhlDQo8aSBjbGFzcz0iIj50b3BpYzwvaT4gb2Yg dGhlIHJlc291cmNlICZuYnNwO29yIGlzIGl0IHRoZTxpIGNsYXNzPSIiPiBsZWdhbCBlbnRpdHkg LyZuYnNwO2NyZWRlbnRpYWwmbmJzcDs8L2k+dGhhdCBjb3JyZXNwb25kcyB0byB0aGUgYWNjb3Vu dGFibGUgY29udHJvbGxlciBvZiBhIHJlc291cmNlID8gJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4tIE1hcmsmbmJzcDs8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+T24gNSBKYW4gMjAyMSwgYXQgMDg6MDQsIEZhYmllbiBJbWJhdWx0ICZs dDs8YSBocmVmPSJtYWlsdG86ZmFiaWVuLmltYmF1bHRAZ21haWwuY29tIiBjbGFzcz0iIj5mYWJp ZW4uaW1iYXVsdEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBw bGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIg Y2xhc3M9IiI+SGkgZXZlcnlvbmUsJm5ic3A7PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSB3aXNoIHlvdSBhbGwgYSBoYXBw eSBuZXcgeWVhci48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPkkganVzdCBjcmVhdGVkIGEgUFIgKDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHVi LmNvbS9pZXRmLXdnLWduYXAvZ25hcC1jb3JlLXByb3RvY29sL3B1bGwvMTU1IiBjbGFzcz0iIj5o dHRwczovL2dpdGh1Yi5jb20vaWV0Zi13Zy1nbmFwL2duYXAtY29yZS1wcm90b2NvbC9wdWxsLzE1 NTwvYT4pIHRoYXQgdGFrZXMgaW50byBhY2NvdW50IHRoZSB2YXJpb3VzIGZlZWRiYWNrcy4gVGhl IGF1dG9tYXRpYyBidWlsZCBwcm9jZXNzIGlzDQogbm90IHdvcmtpbmcsIGJ1dCB5b3UgY2FuIHNl ZSB0aGUgZGlmZnMgYW5kIGJ1aWxkIHRoZSBodG1sIGxvY2FsbHkgaWYgeW91IHByZWZlci4gVGhl IGRlZmluaXRpb25zIGhhdmUgYWxzbyBiZWVuIHVwZGF0ZWQgb24gdGhlIHdpa2kgKDxhIGhyZWY9 Imh0dHBzOi8vZ2l0aHViLmNvbS9pZXRmLXdnLWduYXAvZ25hcC1jb3JlLXByb3RvY29sL3dpa2kv VGVybWlub2xvZ3kiIGNsYXNzPSIiPmh0dHBzOi8vZ2l0aHViLmNvbS9pZXRmLXdnLWduYXAvZ25h cC1jb3JlLXByb3RvY29sL3dpa2kvVGVybWlub2xvZ3k8L2E+KQ0KIGlmIHlvdSBwcmVmZXIgdG8g Y2hlY2sgdGhlcmUuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj5GZWVkYmFja3Mgd2VsY29tZSBiZWZvcmUgd2UgbW92ZSB0byBw ZW5kaW5nIG1lcmdlIGxhdGVyIG9uLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q2hlZXJzPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkZhYmll bjwvZGl2Pg0KPC9kaXY+DQotLSA8YnIgY2xhc3M9IiI+DQpUWEF1dGggbWFpbGluZyBsaXN0PGJy IGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOlRYQXV0aEBpZXRmLm9yZyIgY2xhc3M9IiI+VFhB dXRoQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdHhhdXRoPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DAB2E8D3DC9F45028D6E5BE2066AEF88openconsentcom_-- From nobody Wed Jan 6 05:20:42 2021 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C48C3A0955 for ; Wed, 6 Jan 2021 05:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vStqTFhZ5-75 for ; Wed, 6 Jan 2021 05:20:38 -0800 (PST) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D66E3A0927 for ; Wed, 6 Jan 2021 05:20:38 -0800 (PST) Received: by mail-il1-x12f.google.com with SMTP id q1so3108801ilt.6 for ; Wed, 06 Jan 2021 05:20:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oT9w64fWj+/AzkaaAESUrjVYbIN8YVxPHKzfKMDNsTU=; b=VG5rEw2R5QiVJX3ov1mrS5mCdrv3Bhy44x1sLIEu1d4WXAPlqm3LHiV/hKcu8LWjAF H2DMulS0T1djI4tBw7CGecBEM3SUnHXWbdzl2z7WI8oGhA/3z3VWwiP5NjwFaucRnCjo RCvne8vTJG+i26D/Ytv4gZMCWqxyyVZ9jP0gIK4sOSKrOgg7U+TLGnhWOExvmeNddWKi ut1BXOrNc5dvSmGHKv74z59HLBzvfOzxmcaWY+hFwRDAkMdy7xAJIzKZycEKt1kWZlV5 15yHTcvsSevDr+9dWYXhsxZ4o4+8x79nmrm2udDYHxJJK6s8ftOLFv9mtkyTThVj3q3K q/pQ== 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=oT9w64fWj+/AzkaaAESUrjVYbIN8YVxPHKzfKMDNsTU=; b=tGlGxV9ICYuqlzV1lUfI3NTCAkoLRBpyWaqh6ZKonWDNwwTW7+eEUXEjlMnlYqMGsp IoYoiccN2Hw1D+DdEmt6YaO+bbr3R7xt4zv2IXmxszOIsrU2KImaw84zOk2M6CJL8bGR h6nncqXs40ZxQz4HBIrbccvI5LiAx9phBQb/1/+xf6jdTys51ZUxq/idqisV1JE9HkIz kkqBc+Am91utYCDLTluAk8GpyF1IydS/8X2QyWMyv12+ChGHaLf5LRc7IMxhrRPN4j/p xg9rRCyRX1bno/qGyqnsdxcqkOxJAdYR6/Ii3fYSFMWalhUiamD4yre3t2eteJUu6uYt mCMQ== X-Gm-Message-State: AOAM532BJdmJ/6JQIUikiJAiR3CT+VCgnvi2GoMUoJxDcZxtrxnZ5IPl ekzhYtF+Dyp3DsYoVcBFaIf5dxwNwtxniUgLZvk= X-Google-Smtp-Source: ABdhPJxxNrKiWLqrU8caCYLIbclwV3q8Vv4CoQ6vWHUaTwoLgRnyG8+lRDXqycFYF47uW0MW8Z6W1+hw6w828mcD2K8= X-Received: by 2002:a92:d8c1:: with SMTP id l1mr945981ilo.178.1609939237772; Wed, 06 Jan 2021 05:20:37 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Wed, 6 Jan 2021 14:20:26 +0100 Message-ID: To: Mark Lizar Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000060a74d05b83b30d5" Archived-At: Subject: Re: [GNAP] Terminology PR 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, 06 Jan 2021 13:20:41 -0000 --00000000000060a74d05b83b30d5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mark, Thanks for the feedback. The original requirement for "subject" comes from the reference to https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-06 (used in the main text). The objective was to try to avoid various terms which are synonyms. You're right, it's close to a legal entity, except from the fact that it is defined more broadly (person, organization or device), which is something we can encounter for the RO for instance. For instance we had previous discussions where the RO was defined as : "personal or organizational entity" which I replaced in the latest draft by "subject entity" (since it is defined) For "Subject Information", the question whether this refers to the end-user or the RO is currently left open. Please let me know your thoughts. Cheers Fabien On Tue, Jan 5, 2021 at 8:38 PM Mark Lizar wrote: > Hi Fabien, et al, > > Great start!! > > Could you clarify the use and application of the term subject, as the ter= m > is used in some legal standards for semantics and I wonder if this is > related to the legal semantic attribution of data subject. > > In the glossary, it also seems the Subject Entity is referring to what i= s > commonly know as legal entity. And the term subject can refer to a few > things at this technical level.=E2=80=94 e.g. a semantic term referencin= g in > general the *topic* of the resource or is it the* legal entity > / credential *that corresponds to the accountable controller of a > resource ? > > - Mark > > On 5 Jan 2021, at 08:04, Fabien Imbault wrote: > > Hi everyone, > > I wish you all a happy new year. > > I just created a PR ( > https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/155) that takes > into account the various feedbacks. The automatic build process is not > working, but you can see the diffs and build the html locally if you > prefer. The definitions have also been updated on the wiki ( > https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology) if > you prefer to check there. > > Feedbacks welcome before we move to pending merge later on. > > Cheers > Fabien > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --00000000000060a74d05b83b30d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mark,=C2=A0

Thanks = for the feedback.

The original requirement for &qu= ot;subject" comes from the reference to https://tools.ietf.org= /html/draft-ietf-secevent-subject-identifiers-06 (used in the main text= ). The objective was to try to avoid various terms which are synonyms.

You're right, it's close to a legal entity, ex= cept from the fact that it is defined more broadly (person, organization or= device), which is something we can encounter for the RO for instance.=C2= =A0

For instance we had previous discussions where= the RO was defined as :=C2=A0
"personal or organizational e= ntity"
which I replaced in the latest draft by=C2=A0
"subject entity" (since it is defined)

For "Subject Information", the question whether this refers to = the end-user or the RO is currently left open.

Please let me know your thoughts.

Cheers
<= div>Fabien
On Tue, Jan 5, 2021 at 8:38 PM Mark Lizar <mark@openconsent.com> wrote:
Hi Fabien, =C2=A0et al,

Great start!!

Could you clarify the use and application of the term subject, as the = term is used in some legal standards for semantics and I wonder if this is = related to the legal semantic attribution of data subject.=C2=A0

In the glossary, =C2=A0it also seems the Subject Entity is referring t= o what is commonly know as legal entity. =C2=A0 And the term subject can re= fer to a few things at this technical level.=E2=80=94 e.g. =C2=A0a semantic= term referencing in general the topic of the resource =C2=A0or is it the legal entity /=C2=A0cred= ential=C2=A0that corresponds to the accountable controller of a resourc= e ? =C2=A0

- Mark=C2=A0

On 5 Jan 2021, at 08:04, Fabien Imbault <fabien.imbault@gmail.com> wrote:=

Hi everyone,=C2=A0

I wish you all a happy new year.

I just created a PR (https://github.com/ietf-wg-gnap/gn= ap-core-protocol/pull/155) that takes into account the various feedback= s. The automatic build process is not working, but you can see the diffs and build the html locally if you p= refer. The definitions have also been updated on the wiki (https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology<= /a>) if you prefer to check there.=C2=A0

Feedbacks welcome before we move to pending merge later on.

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

--00000000000060a74d05b83b30d5-- From nobody Wed Jan 6 08:02:23 2021 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B447B3A0F0A for ; Wed, 6 Jan 2021 08:02:21 -0800 (PST) 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 Sg2Zi4UulDZB for ; Wed, 6 Jan 2021 08:02:20 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB1E63A0FC3 for ; Wed, 6 Jan 2021 08:01:50 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id m23so3219541ioy.2 for ; Wed, 06 Jan 2021 08:01:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YoNBSjtLtKbjXk8nuAyeDfi1u7Z2xu2B2pOPSfs3xKM=; b=NHSAcBJ+wlsh8CAD9O9uoxBb+fo8/wLsvmNpg1YcT0tZzn1PuDOidET93GCpF1bbwV yN8fVJjQ4F541aJiOltKZvoQYlfe8+Xu6nRiIXdVQsq8e1wETUA6oOfjVDzthTruVaPF GQ8/vJu2whWImSqX9Ga5IaG+IDanjGMYzSjHr6bJiACplhKa0AN/qdsXuDIbgo+ApW9l y484h4ObfrSQxYtlwvf2gcYQNXWUuiSIsrbN4wX9RXuj0aF4kBWHa+c7nHcQknyW0dCf n+lawsI3NjnwogWjcm6FAZIqlpoKoQ+bg7Nxj5U+8VkX0S7Grwa5hoYlKxmVEfqEKupH oWkA== 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=YoNBSjtLtKbjXk8nuAyeDfi1u7Z2xu2B2pOPSfs3xKM=; b=qlTBaREfUr8c1X7hYpjuHVpPFpNMob05godzPtdZxQsZK8UKi1QwwnId5EBuHSQcKL RQiYwRwxlz/YLR88BNens313vlg61THG4vo4Yz5dcjH2Vg2IKFMVvmFV4qLkv1HBDVMP 9PcByjwW4k2FUfsrriyfum2C7pgo2qoinsVj1hlq9aLZ0aisby/oLr2ICEArcMRGEGdR 0xkOAhkmdqlesoTu/4TYGo1OfWqMkPArT5rZEQySbFQW66w8FUGyC0WBK9YvBYQ4/7g5 3NdJTrbKvUJnq/9nTFVcGlok0b9CSR8G8oh2sTKjuT9XMA8Q/M2dTFgTg1DYcZQ2nOTA zdHg== X-Gm-Message-State: AOAM532VrWUTUgbd3zUVVnyLJbRqc8Spi4hMUFk0dykVbmF4nCKe1wuD qxisBSsGJO69d/+S0zGyC8hNVenbx07iMH17Enc= X-Google-Smtp-Source: ABdhPJzXaSsvCQ9tPvOqtmL7GhuBgnMKg34ZtCrCaBddgtVpK1I+Pa/yIDK/QCE4U2T8mjs0sNQOw7Oq5K4PpsNbUN8= X-Received: by 2002:a5e:a916:: with SMTP id c22mr3313748iod.144.1609948909898; Wed, 06 Jan 2021 08:01:49 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Wed, 6 Jan 2021 17:01:38 +0100 Message-ID: To: Mark Lizar Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000e190a005b83d70e5" Archived-At: Subject: Re: [GNAP] Terminology PR 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, 06 Jan 2021 16:02:22 -0000 --000000000000e190a005b83d70e5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi everyone, I've committed some changes (based on the useful comments made on the PR, from Justin), visible in the PR itself or on the wiki. Cheers Fabien The generation of the html doesn't work on a forked project, because the netlify token doesn't match. On Wed, Jan 6, 2021 at 2:20 PM Fabien Imbault wrote: > Hi Mark, > > Thanks for the feedback. > > The original requirement for "subject" comes from the reference to > https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-06 > (used in the main text). The objective was to try to avoid various terms > which are synonyms. > > You're right, it's close to a legal entity, except from the fact that it > is defined more broadly (person, organization or device), which is > something we can encounter for the RO for instance. > > For instance we had previous discussions where the RO was defined as : > "personal or organizational entity" > which I replaced in the latest draft by > "subject entity" (since it is defined) > > For "Subject Information", the question whether this refers to the > end-user or the RO is currently left open. > > Please let me know your thoughts. > > Cheers > Fabien > > On Tue, Jan 5, 2021 at 8:38 PM Mark Lizar wrote: > >> Hi Fabien, et al, >> >> Great start!! >> >> Could you clarify the use and application of the term subject, as the >> term is used in some legal standards for semantics and I wonder if this = is >> related to the legal semantic attribution of data subject. >> >> In the glossary, it also seems the Subject Entity is referring to what >> is commonly know as legal entity. And the term subject can refer to a = few >> things at this technical level.=E2=80=94 e.g. a semantic term referenci= ng in >> general the *topic* of the resource or is it the* legal entity >> / credential *that corresponds to the accountable controller of a >> resource ? >> >> - Mark >> >> On 5 Jan 2021, at 08:04, Fabien Imbault wrote= : >> >> Hi everyone, >> >> I wish you all a happy new year. >> >> I just created a PR ( >> https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/155) that takes >> into account the various feedbacks. The automatic build process is not >> working, but you can see the diffs and build the html locally if you >> prefer. The definitions have also been updated on the wiki ( >> https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology) if >> you prefer to check there. >> >> Feedbacks welcome before we move to pending merge later on. >> >> Cheers >> Fabien >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> --000000000000e190a005b83d70e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

I've committed=C2=A0so= me changes (based on the useful comments made on the PR, from Justin), visi= ble in the PR itself or on the wiki.=C2=A0

Cheers<= /div>
Fabien

The generation of the html doesn&= #39;t work on a forked project, because the netlify token doesn't match= .

On Wed, Jan 6, 2021 at 2:20 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
=
Hi Mark,=C2=A0

Thanks for the feedback.

The original requirement for "subject" comes fr= om the reference to https://tools.ietf.org/html/d= raft-ietf-secevent-subject-identifiers-06 (used in the main text). The = objective was to try to avoid various terms which are synonyms.
<= br>
You're right, it's close to a legal entity, except fr= om the fact that it is defined more broadly (person, organization or device= ), which is something we can encounter for the RO for instance.=C2=A0
=

For instance we had previous discussions where the RO w= as defined as :=C2=A0
"personal or organizational entity&quo= t;
which I replaced in the latest draft by=C2=A0
"= subject entity" (since it is defined)

For &qu= ot;Subject Information", the question whether this refers to the end-u= ser or the RO is currently left open.

Please= let me know your thoughts.

Cheers
Fabie= n

On Tue, Jan 5, 2021 at 8:38 PM Mark Lizar <mark@openconsent.com> wrote:
=
Hi Fabien, =C2=A0et al,

Great start!!

Could you clarify the use and application of the term subject, as the = term is used in some legal standards for semantics and I wonder if this is = related to the legal semantic attribution of data subject.=C2=A0

In the glossary, =C2=A0it also seems the Subject Entity is referring t= o what is commonly know as legal entity. =C2=A0 And the term subject can re= fer to a few things at this technical level.=E2=80=94 e.g. =C2=A0a semantic= term referencing in general the topic of the resource =C2=A0or is it the legal entity /=C2=A0cred= ential=C2=A0that corresponds to the accountable controller of a resourc= e ? =C2=A0

- Mark=C2=A0

On 5 Jan 2021, at 08:04, Fabien Imbault <fabien.imbault@gmail.com> wrote:=

Hi everyone,=C2=A0

I wish you all a happy new year.

I just created a PR (https://github.com/ietf-wg-gnap/gn= ap-core-protocol/pull/155) that takes into account the various feedback= s. The automatic build process is not working, but you can see the diffs and build the html locally if you p= refer. The definitions have also been updated on the wiki (https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology<= /a>) if you prefer to check there.=C2=A0

Feedbacks welcome before we move to pending merge later on.

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

--000000000000e190a005b83d70e5-- From nobody Wed Jan 6 09:32:15 2021 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010A23A105F for ; Wed, 6 Jan 2021 09:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 7_gz1A9VVj2v for ; Wed, 6 Jan 2021 09:32:13 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 127743A105E for ; Wed, 6 Jan 2021 09:32:12 -0800 (PST) Received: from [192.168.1.22] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 106HWAjN026469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 6 Jan 2021 12:32:11 -0500 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_EC549DDD-7E74-410A-AA10-5983A1ED2B83" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <7B80A30F-9582-4181-BA72-EFC87511036B@mit.edu> Date: Wed, 6 Jan 2021 12:32:10 -0500 To: txauth gnap X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [GNAP] Pending Pull Requests 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, 06 Jan 2021 17:32:15 -0000 --Apple-Mail=_EC549DDD-7E74-410A-AA10-5983A1ED2B83 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Two pull requests are currently marked Pending Merge: #152 Refactor "key" section https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/152 = #155 update terminology https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/155 = Please review the proposed changes. These will be merged in seven days = unless there are specific and actionable objections. =E2=80=94 Justin, Aaron, and Fabien= --Apple-Mail=_EC549DDD-7E74-410A-AA10-5983A1ED2B83 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Two = pull requests are currently marked Pending Merge:

#152 Refactor "key" section
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/152=

#155 update = terminology
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/155=

Please review = the proposed changes. These will be merged in seven days unless there = are specific and actionable objections.

 =E2=80=94 Justin, Aaron, and = Fabien
= --Apple-Mail=_EC549DDD-7E74-410A-AA10-5983A1ED2B83-- From nobody Wed Jan 6 11:09: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 13AE53A11B1 for ; Wed, 6 Jan 2021 11:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.527 X-Spam-Level: X-Spam-Status: No, score=-0.527 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=1.569, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJ5l4X35kkyK for ; Wed, 6 Jan 2021 11:09:17 -0800 (PST) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 83E493A11F3 for ; Wed, 6 Jan 2021 11:09:17 -0800 (PST) Received: by mail-wr1-x429.google.com with SMTP id a12so3375536wrv.8 for ; Wed, 06 Jan 2021 11:09:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version; bh=zLc3/aSBcLOuPpW71AFG9HCF6V+WjepyeVqfnOtuWLY=; b=Hpw3G8q3kroew8AgCStKIoQpWfnvHzjmmho8Q8iSCZkwv05ujaJx30goWGxXCnQLN3 nH33Ne4uE7F63ifrst1Qnm+3nbjz/NsCskmd6bMGKBUy97XC2vLpyf8kOb2CZIQslPF3 kCX3W7jjKo0Jg4K2d1SrtYmxcNX0SlIBQdzdBo26iNQEyHC2iBXJG8q7IzY3DhG/BgO7 QpJmem1CMw1Hp5jkIj0OoMOHhiZIL87vrdbpGzD4VDJQNS+e6IttKKuTj+w3zkma4Zhg vsakerkBY3Y5odE9JMpyNSWUtfepoessqvXK6NaCflOodQGD4uAM5f4Q+C3wj5cZOgIk KggA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version; bh=zLc3/aSBcLOuPpW71AFG9HCF6V+WjepyeVqfnOtuWLY=; b=DExu/epayiMKOoi9lVevii8A8KTggpyYeHZsSKBWAgHiQ+qlSwylcQlOD75EvK6e3X 03jo5mkduJecJCFfetLrRkbulbvzJJy/MDGyPMYNJia0583JS/SYIwHmMKVfzYoNe0b7 cP+YswZgNWQi+G1OQD/w1gex4QoxfI7YsEO76qHolnDqE8o4MIr6PGQ+myAN7suPoCBc dt9cOgJIi7w9RzO6yrYXVyIwzIAlTgg/G6gqXNZxLa5Y1dNkTvDDYsBa+UjEUl2jtkPV EbHoGxa1jLml0rt8CrvVKTK6zW6mtlH4iAP0FDDcR18Zub5i7CF5z+2mc3Uz4fIsL64B 87qw== X-Gm-Message-State: AOAM532ffibZwzD7p2Rs2Wbb0EdWs9/OQS895b8VrYhu4XnoutO7jubd sbRyRN6rA04FJ9xZcgN/UYuHQt6kKhiROMKI X-Google-Smtp-Source: ABdhPJxV7cP5D8BbU1Poj5EF9sbIhsYTAdpWOvLJyTMqPtz0k1hQT8FDxURJzwV26+XDQ/GTKujAaQ== X-Received: by 2002:a5d:4c4e:: with SMTP id n14mr5650640wrt.209.1609960155904; Wed, 06 Jan 2021 11:09:15 -0800 (PST) Received: from [172.26.49.35] (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id w8sm4109709wrl.91.2021.01.06.11.09.14 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jan 2021 11:09:15 -0800 (PST) User-Agent: Microsoft-MacOutlook/16.44.20121301 Date: Wed, 06 Jan 2021 21:09:13 +0200 From: Yaron Sheffer To: GNAP Mailing List Message-ID: Thread-Topic: Interim meeting next Tuesday Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3692812154_1291794894" Archived-At: Subject: [GNAP] Interim meeting next Tuesday 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, 06 Jan 2021 19:09:25 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3692812154_1291794894 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reminder: we will be meeting next week to review the latest with the GNAP c= ore protocol and discuss issues. =20 See you all there! =20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Leif and Yaron =20 =20 Jan. 12 2021, 17:00-18:30 UTC Join with Zoom Working group status (chairs) Draft update (Aaron) Terminology update Open issues:=20 Access token request/response format Interaction request/response format AOB and next steps =20 --B_3692812154_1291794894 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Reminder: we will be meeting next week to review the lates= t with the GNAP core protocol and discuss issues.

 

See you all there!=

 

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

 

<= span style=3D'font-size:11.0pt'> 

Jan. 12 2021, 1= 7:00-18:30 UTC

Join with Zoom

 

--B_3692812154_1291794894-- From nobody Wed Jan 6 12:56:38 2021 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6223A0EA1 for ; Wed, 6 Jan 2021 12:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 q9NUgkCu_ZnF for ; Wed, 6 Jan 2021 12:56:36 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640090.outbound.protection.outlook.com [40.107.64.90]) (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 DE14F3A09C1 for ; Wed, 6 Jan 2021 12:56:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XNqjOXAydkY/H5VSKGmsALCsxowS4AEuLk3P+rKA6n48S9eaeMeuBjsZKYktjdYOg23QDWKdS1kzRNkCQLoP0v7mncT5HLrDWs4kTMhJerhox7aFXVJbzc0cOQYcKeegJSdVGEFHXOPkPuiiVx5maQut1dr6CplsCJx53vUsOnccl8KtPkn9l2uccNK0oxU2Z/oDkP/Dbc49+Q8vXcYUrqRaojWLB74jgPqDOVkys9zX0cNOdrop8m0pwbEI8MlR7i6S94etC73HGJn/5vQ+NYbykgAhrLbDxCgdnfWHGAsa6d5jYkRAcNm482X52dlefvydMIp8g8ef21B4nz/MRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zT3EU+qGYdSfrdmtCaoIpMfC+DgYl1LP43J4m2SMBLA=; b=PUG0GS6fo6Kfp1pYRA+pM9HL6mr1LolvUewRWqCiz1nivnBIGwuid8feJ7ATDHunMkB1wifYGpIatgbo1fCRnFsiHw7hkFI7LWc0Spz6H09ngH+Qh3Gfd85vvC1wTah4GttPzpq6hoOyZecyiwK5Onnjf+Oc2mQ+YvBSraMlHfNA6v/texuiyrnYk7ZQlUFAlwSRcmQUmxRVS+ybtJEVCM3mofac40Mxa35ApvnKeamX6mG3KNi+SeDatH4ziAc1AVpTtmdghiRpgYvZrRs2C/H0KPP7kKPaBYbGdHW3CZBVl5PE2OQ00//d1/sdlF28xH2qgy92CopzRPQ4YyHy3g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zT3EU+qGYdSfrdmtCaoIpMfC+DgYl1LP43J4m2SMBLA=; b=iv8oAiTAfQFCFDLD2BWNyGyYEQK4Iz7tLcl0uwKCmumet5FkQrxJvalC/auNWysajoOp+fB6wqskx7X2jGfJzjPvq9I/ckDZ6aJ5XlR4v0c2JYh7WxucVD1922By6fkS/olXbTZLvvU0PeoXgYVuqtweFuy+sVt7bC20mkcA03M= Received: from (2603:10b6:4:a0::35) by DM6PR00MB0633.namprd00.prod.outlook.com (2603:10b6:5:166::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3772.0; Wed, 6 Jan 2021 20:56:26 +0000 Received: from DM5PR00MB0423.namprd00.prod.outlook.com ([fe80::b95c:ecd0:e138:be7d]) by DM5PR00MB0423.namprd00.prod.outlook.com ([fe80::b95c:ecd0:e138:be7d%7]) with mapi id 15.20.3773.000; Wed, 6 Jan 2021 20:56:26 +0000 From: Mike Jones To: "yaronf.ietf@gmail.com" , "txauth@ietf.org" Thread-Topic: Interim meeting next Tuesday Thread-Index: AQHW5F9+dmASAc3fs0m7UN5hp96ACqobE68g Date: Wed, 6 Jan 2021 20:56:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-01-06T20:55:08Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=eb4bc24d-a700-40ca-badc-908ab83954f7; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.35.9.28] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: c7a0c491-ce38-42be-80b4-08d8b28588c4 x-ms-traffictypediagnostic: DM6PR00MB0633: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4125; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Zf6hSXH9bbqtcp5bTRFbIZspbv6G0XGimwphgXUT3pvB7m6djCIB+659ucXlI2kzzqwK/dbjPlo+qt/HMKTxYENYOwrDDpzi+qEvggMvD37jvKtQpwUk/iwP6JURCJrQqk5k4WFhUwTbox3f5ylN3Iz5XGybE+f0xjxphFgAUvR1gajQtsa4mnFULL32ZZ0dpPx06Y/puKrHTJ90WDVW0ULvZJPsdeyY1LnRDMrGItrJ0McZvZAAR4eVJCeyCRLgXP/ZMorur/4wOp/AohYUQMFvQA4MLhgm/w6pcTSkNQw85IBRKd6KJ9hS0gb0ZWgxbE9ZaLSXGo55qqqNgyow5UZamrfzVL+sZx4iinPQ6aNGB/iXCdtToVLLUtEMimYlOYRq4WowNlAAzwpKtds1VsQCi17H4ZnO7U1fVJlrP22OmFJgFyfzw08/luFMYCaRpCZVqG00xbEvh/FIU3jgWQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR00MB0423.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(39860400002)(366004)(376002)(136003)(346002)(83380400001)(66556008)(7696005)(8936002)(55016002)(478600001)(10290500003)(71200400001)(26005)(5660300002)(316002)(110136005)(52536014)(53546011)(2906002)(6506007)(3480700007)(64756008)(8990500004)(186003)(4744005)(33656002)(82960400001)(82950400001)(9686003)(76116006)(66476007)(166002)(66446008)(66946007)(86362001)(8676002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?bm1mYnIzNEVrbEJjbEl6Sno1WlVFT2crbGdSS2NDbFFaU1hETmhJeGdGRVdK?= =?utf-8?B?NGk1L2haU1hhemRkRWNzOWFFVWNVcVZHNmhtNnl1YU9lRHdqUEY3ZUdXT3Rq?= =?utf-8?B?cUg4aitLMHZmQldHTVdObFFqZzBtUSsyczdpbnpnZ1lXRHpXQkZwb2k5cFZY?= =?utf-8?B?OXVUNHNLWG9iREo0Y0tyOXpaT21OWFowZ2dCa2FBNllNeUh2SE05ckl4cHBS?= =?utf-8?B?RllyeDgxN3pBSHNqeXNGRHVSOUppSWM0dUtldHhaU2dWUkJLL05PMXplYUty?= =?utf-8?B?OVN6b3cyZHo1WVZXejJySlpXZnZEMEZnaHdGaVdtV1NVczcrbndkOGxoR0Ny?= =?utf-8?B?ZS9XTlE1ODVDQk9uOEhPeDFXS2lqZHBlcVBJeFJxemNoZ0Z4dU5lSWpaOHVM?= =?utf-8?B?SVBoNkh2ckdXZ0RVWGwrNEpsdkdpVU9GcmpBZXl6cjZkaDRndFpHeXFLakkv?= =?utf-8?B?Y21zS0FhT1RsMDBBNFd6OFd1RGpGUTNWbFg0dHU1bHgrY3o1SE45YUFubmJ0?= =?utf-8?B?N0oyd2ljN2RIMGRmZlo1RmFUbWdsRVU1SThlZW42NVNPa010ZFM1UTl3ME1R?= =?utf-8?B?aHg1TGVDNGFrcDhiVThzSW5KclB4YkxpMWpJWHRSSWhueGRuaUMyeWtoNVds?= =?utf-8?B?MUY1QVI1ZlAzcGUzNHUvc3NoSkhqcnZNcW9aMVA4KzMrQjhlOWxSWEdhVmpy?= =?utf-8?B?STk5VTU0U0ZhREFNNkNZSlNIS29xWnphNzFtaUZ4NGJSZlQyNkQ0b2ttUDNH?= =?utf-8?B?allNOWpGYnAvVFhqUDZYbThVVDVrY1dWc2VFVksrUURXSEZmY2RXYThuWll4?= =?utf-8?B?a2doaytKMXhKd3B6ZCt6UHJkQ1BISm05aGZqSUNTY21ydlRRWHZINVRnZmRi?= =?utf-8?B?MHd1bzNRRDNaamZxTHZGMlBxU3EzMkZnY2pTYUczNlp5V3BiU1orc0VPUUk2?= =?utf-8?B?Z1lMaktPNXJMRkRrUDFWRUhwcE15ZkM4dnQ2UC9IdHF3ZGVBYnM1NVo2cEZu?= =?utf-8?B?dktDVzJOMkRBZTdjb0diUENtcEFqYWdSK3JxaWFMdkUvMHNOSVVsYUNpK2k4?= =?utf-8?B?cmhCbWl4cUNkbmhBS1lsQlR1Wm9kTzM3SzlUckN2TnoyeHhNRkt2NWlsZkcz?= =?utf-8?B?N3ZTdVBUckMzaUNpRTU3cmZ0YUpJSitKSTBGSmUya0RZOStGN1BTaFRISEpy?= =?utf-8?B?aktZclRJWDZsdzlYc094clFaRlMrdDdpSSt5NHB2M2xnMXhucUg2TUVRWUR0?= =?utf-8?B?b0N0WVVWWmJMeFZtSStvak9Wbk9DNGpud0dkNmxWUnNyOCt2ZXZCUDRXU25O?= =?utf-8?B?Q00zZHhIODVaaC9XSWVIUkJGSlpRcDQvd2FLNjhLdzRRSnNMYnZwdVNjK3k2?= =?utf-8?Q?yZDheDQC2L2S7IAWycVAKxvSxJbu2nf0=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM5PR00MB0423215C1A6C04FCD8E7AD3BF5D09DM5PR00MB0423namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR00MB0423.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c7a0c491-ce38-42be-80b4-08d8b28588c4 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2021 20:56:26.6819 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 25H28pzJks4evbtUz/3V5kjLC74SnuOVSSM6Ji2fHatcSDka+CKu2Lg1xxPIB4tlXdelnVhmgDNMZeZOk3cyBw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0633 Archived-At: Subject: Re: [GNAP] Interim meeting next Tuesday 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, 06 Jan 2021 20:56:37 -0000 --_000_DM5PR00MB0423215C1A6C04FCD8E7AD3BF5D09DM5PR00MB0423namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q291bGQgeW91IHNlbmQgYSBjYWxlbmRhciBpbnZpdGF0aW9uIGZvciB0aGlzIGluY2x1ZGluZyB0 aGUgam9pbiBsaW5rIHNvIGl04oCZcyBpbiBwZW9wbGXigJlzIGNhbGVuZGFycz8NCg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoYW5rcywN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAt LSBNaWtlDQoNCkZyb206IFRYQXV0aCA8dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFs ZiBPZiBZYXJvbiBTaGVmZmVyDQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgNiwgMjAyMSAxMTow OSBBTQ0KVG86IEdOQVAgTWFpbGluZyBMaXN0IDx0eGF1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBb RVhURVJOQUxdIFtHTkFQXSBJbnRlcmltIG1lZXRpbmcgbmV4dCBUdWVzZGF5DQoNClJlbWluZGVy OiB3ZSB3aWxsIGJlIG1lZXRpbmcgbmV4dCB3ZWVrIHRvIHJldmlldyB0aGUgbGF0ZXN0IHdpdGgg dGhlIEdOQVAgY29yZSBwcm90b2NvbCBhbmQgZGlzY3VzcyBpc3N1ZXMuDQoNClNlZSB5b3UgYWxs IHRoZXJlIQ0KDQogICAgICAgICAgICAgICAgTGVpZiBhbmQgWWFyb24NCg0KDQoNCkphbi4gMTIg MjAyMSwgMTc6MDAtMTg6MzAgVVRDDQoNCkpvaW4gd2l0aCBab29tPGh0dHBzOi8vaW50dWl0Lnpv b20udXMvai85OTUzMzEwMTgzMj9mcm9tPWFkZG9uPg0KDQogICogICBXb3JraW5nIGdyb3VwIHN0 YXR1cyAoY2hhaXJzKQ0KICAqICAgRHJhZnQgdXBkYXRlIChBYXJvbikNCiAgKiAgIFRlcm1pbm9s b2d5IHVwZGF0ZQ0KICAqICAgT3BlbiBpc3N1ZXM6DQogICAgICogICBBY2Nlc3MgdG9rZW4gcmVx dWVzdC9yZXNwb25zZSBmb3JtYXQ8aHR0cHM6Ly9naXRodWIuY29tL2lldGYtd2ctZ25hcC9nbmFw LWNvcmUtcHJvdG9jb2wvaXNzdWVzLzQwPg0KICAgICAqICAgSW50ZXJhY3Rpb24gcmVxdWVzdC9y ZXNwb25zZSBmb3JtYXQ8aHR0cHM6Ly9naXRodWIuY29tL2lldGYtd2ctZ25hcC9nbmFwLWNvcmUt cHJvdG9jb2wvaXNzdWVzLzEyMj4NCiAgKiAgIEFPQiBhbmQgbmV4dCBzdGVwcw0KDQo= --_000_DM5PR00MB0423215C1A6C04FCD8E7AD3BF5D09DM5PR00MB0423namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9u cyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NjI2Mzk5MDY2Ow0KCW1zby1saXN0LXRlbXBs YXRlLWlkczo3MDIyMDgyNDA7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Oi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVs Ng0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1s aXN0LWlkOjE1MTMxODAxMjg7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjQzOTkwMTAyODt9DQpA bGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6 bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIiBz dHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OiMwMDIwNjAiPkNvdWxkIHlvdSBzZW5kIGEgY2FsZW5kYXIgaW52aXRhdGlvbiBmb3IgdGhpcyBp bmNsdWRpbmcgdGhlIGpvaW4gbGluayBzbyBpdOKAmXMgaW4gcGVvcGxl4oCZcyBjYWxlbmRhcnM/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRo YW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIw NjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4g VFhBdXRoICZsdDt0eGF1dGgtYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8 L2I+WWFyb24gU2hlZmZlcjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEphbnVhcnkgNiwg MjAyMSAxMTowOSBBTTxicj4NCjxiPlRvOjwvYj4gR05BUCBNYWlsaW5nIExpc3QgJmx0O3R4YXV0 aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0VYVEVSTkFMXSBbR05BUF0gSW50 ZXJpbSBtZWV0aW5nIG5leHQgVHVlc2RheTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5SZW1pbmRlcjog d2Ugd2lsbCBiZSBtZWV0aW5nIG5leHQgd2VlayB0byByZXZpZXcgdGhlIGxhdGVzdCB3aXRoIHRo ZSBHTkFQIGNvcmUgcHJvdG9jb2wgYW5kIGRpc2N1c3MgaXNzdWVzLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+U2VlIHlvdSBhbGwgdGhlcmUhPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgTGVpZiBhbmQgWWFyb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwPkphbi4gMTIgMjAyMSwg MTc6MDAtMTg6MzAgVVRDPG86cD48L286cD48L3A+DQo8cD5Kb2luIHdpdGggPGEgaHJlZj0iaHR0 cHM6Ly9pbnR1aXQuem9vbS51cy9qLzk5NTMzMTAxODMyP2Zyb209YWRkb24iPlpvb208L2E+PG86 cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21z by1saXN0OmwwIGxldmVsMSBsZm8zIj4NCldvcmtpbmcgZ3JvdXAgc3RhdHVzIChjaGFpcnMpPG86 cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzMiPg0KRHJhZnQgdXBkYXRlIChBYXJvbik8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+DQpUZXJtaW5vbG9neSB1cGRhdGU8bzpw PjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZv MyI+DQpPcGVuIGlzc3VlczogPG86cD48L286cD48L2xpPjx1bCB0eXBlPSJjaXJjbGUiPg0KPGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDIgbGZvMyI+DQo8YSBocmVmPSJo dHRwczovL2dpdGh1Yi5jb20vaWV0Zi13Zy1nbmFwL2duYXAtY29yZS1wcm90b2NvbC9pc3N1ZXMv NDAiPkFjY2VzcyB0b2tlbiByZXF1ZXN0L3Jlc3BvbnNlIGZvcm1hdDwvYT48bzpwPjwvbzpwPjwv bGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDIgbGZvMyI+DQo8YSBo cmVmPSJodHRwczovL2dpdGh1Yi5jb20vaWV0Zi13Zy1nbmFwL2duYXAtY29yZS1wcm90b2NvbC9p c3N1ZXMvMTIyIj5JbnRlcmFjdGlvbiByZXF1ZXN0L3Jlc3BvbnNlIGZvcm1hdDwvYT48bzpwPjwv bzpwPjwvbGk+PC91bD4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzMiPg0KQU9CIGFuZCBuZXh0IHN0ZXBzPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM5PR00MB0423215C1A6C04FCD8E7AD3BF5D09DM5PR00MB0423namp_-- From nobody Wed Jan 6 13:03:43 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 9BCF23A1263; Wed, 6 Jan 2021 13:03:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: txauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: txauth@ietf.org Message-ID: <160996702159.31593.2950593661940424556@ietfa.amsl.com> Date: Wed, 06 Jan 2021 13:03:41 -0800 Archived-At: Subject: [GNAP] I-D Action: draft-ietf-gnap-core-protocol-03.txt 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, 06 Jan 2021 21:03:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Grant Negotiation and Authorization Protocol WG of the IETF. Title : Grant Negotiation and Authorization Protocol Authors : Justin Richer Aaron Parecki Fabien Imbault Filename : draft-ietf-gnap-core-protocol-03.txt Pages : 111 Date : 2021-01-06 Abstract: GNAP defines a mechanism for delegating authorization to a piece of software, and conveying that delegation to the software. This delegation can include access to a set of APIs as well as information passed directly to the software. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-gnap-core-protocol/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-03.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-gnap-core-protocol-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 6 13:27:31 2021 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060C43A129F for ; Wed, 6 Jan 2021 13:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMcRRBdzeCxT for ; Wed, 6 Jan 2021 13:27:28 -0800 (PST) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1588E3A129A for ; Wed, 6 Jan 2021 13:27:28 -0800 (PST) Received: by mail-ot1-x32a.google.com with SMTP id d20so4426158otl.3 for ; Wed, 06 Jan 2021 13:27:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k6neiv+ialfwmhxoXN0cXrP0wZKpDNKjJ4rDkaTbUqs=; b=o7v/OtEwogi2ERslXQomcnj5C5am5Pw4wCXgkkdYIrgtkmQ30bYObsSuKe6WoyV6MK I5+A+vY1fyHB89SNGEyTOX/sCS6GV3+3H4BhPjb/GUM2iUmC7sDpEu6vJZtX36ryGAlO 9f2c8Rx2JzKS87IuCFdg1XB8Ii2Ka37RMcuXfiy8KcGb1xkupQcL8soUGqRFODcf1rVD kf5n9AbLtYtm3ljMUkppL783b3205G1eA/KEs0zpOIg9ryID2moqa6etIt4RNEWsSKPF bsRzo8tdtdyxB9fT19GaYJCbzlfF2PEcq+wEfnaxQiHZpUe77B/Vn93By9MT/buTwQ3X AFgQ== 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=k6neiv+ialfwmhxoXN0cXrP0wZKpDNKjJ4rDkaTbUqs=; b=dUKd9n6bQpyK3PociQTr/VIhCEac3CDXVgcn6y8q1vgmzkQ8gsMwuTTRvEjf/FdlgD KPbIf1nNL1pGHHq624nT7eNJjWUhoWEZoU9wMUaQJNg0N/hAb3RG28zQ6TCrjZ1yGTtN NiQn/KeeQB/r/gWOnEbUNZWQbSjwmPFdQRzStg4MZkpClE8vg73HtRUOIlbuYkDggnEm e0Jk2cWlmMm8rR89dGrN1dzM7t1JWxWXIAhVGz3W+1ZcLzrsyyLsp8TZaZaS8iKUBGVR OLW1HTEPqflxxIqEe+E1FMbAHm41JA+SD8Vp9RSQq2FWOOHtojrjgtk3HJILAW7UPWi9 7+bw== X-Gm-Message-State: AOAM531Os+BcUJXveknDD9rjaRyWBirbkkfWn0g1/JkkQzYY5rummWnJ EvZZDh7SziWE89Sf8JMICWPaDiT1PQDrqQ/N2i4= X-Google-Smtp-Source: ABdhPJzAujTKbX6PFt0Vbdgyy8ijND/OAajzttfcfOb9MBlt8SBWOQlmkz24D8G8EPdMdzjvfy4Pbzp24k78tHux6YA= X-Received: by 2002:a9d:4816:: with SMTP id c22mr4496298otf.358.1609968447246; Wed, 06 Jan 2021 13:27:27 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tom Jones Date: Wed, 6 Jan 2021 13:27:16 -0800 Message-ID: To: Fabien Imbault Cc: Mark Lizar , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000065d51d05b841fdb9" Archived-At: Subject: Re: [GNAP] Terminology PR 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, 06 Jan 2021 21:27:30 -0000 --00000000000065d51d05b841fdb9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Right - the correct term should be *subjects' information* as there are potentially two subjects, the RO and the "end-user" (really terribly confusing name). If you consider the case where the end-user is the parent of a child, or of their spouse, both subjects will be asked to supply information in order to be authenticated. Peace ..tom On Wed, Jan 6, 2021 at 5:20 AM Fabien Imbault wrote: > Hi Mark, > > Thanks for the feedback. > > The original requirement for "subject" comes from the reference to > https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-06 > (used in the main text). The objective was to try to avoid various terms > which are synonyms. > > You're right, it's close to a legal entity, except from the fact that it > is defined more broadly (person, organization or device), which is > something we can encounter for the RO for instance. > > For instance we had previous discussions where the RO was defined as : > "personal or organizational entity" > which I replaced in the latest draft by > "subject entity" (since it is defined) > > For "Subject Information", the question whether this refers to the > end-user or the RO is currently left open. > > Please let me know your thoughts. > > Cheers > Fabien > > On Tue, Jan 5, 2021 at 8:38 PM Mark Lizar wrote: > >> Hi Fabien, et al, >> >> Great start!! >> >> Could you clarify the use and application of the term subject, as the >> term is used in some legal standards for semantics and I wonder if this = is >> related to the legal semantic attribution of data subject. >> >> In the glossary, it also seems the Subject Entity is referring to what >> is commonly know as legal entity. And the term subject can refer to a = few >> things at this technical level.=E2=80=94 e.g. a semantic term referenci= ng in >> general the *topic* of the resource or is it the* legal entity >> / credential *that corresponds to the accountable controller of a >> resource ? >> >> - Mark >> >> On 5 Jan 2021, at 08:04, Fabien Imbault wrote= : >> >> Hi everyone, >> >> I wish you all a happy new year. >> >> I just created a PR ( >> https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/155) that takes >> into account the various feedbacks. The automatic build process is not >> working, but you can see the diffs and build the html locally if you >> prefer. The definitions have also been updated on the wiki ( >> https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology) if >> you prefer to check there. >> >> Feedbacks welcome before we move to pending merge later on. >> >> Cheers >> Fabien >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000065d51d05b841fdb9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Right - the correct term should be subjects' inform= ation as there are potentially two subjects, the RO and the "end-u= ser" (really terribly confusing name). If you consider the case where = the end-user is the parent of a child, or of their spouse, both subjects wi= ll be asked to supply information in order to be authenticated.
Peace ..tom

=

= On Wed, Jan 6, 2021 at 5:20 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Mark,=C2=A0

Thanks for the feedback.

=
The original requirement for "subject" comes from the = reference to https://tools.ietf.org/html/draft-ie= tf-secevent-subject-identifiers-06 (used in the main text). The objecti= ve was to try to avoid various terms which are synonyms.

You're right, it's close to a legal entity, except from the = fact that it is defined more broadly (person, organization or device), whic= h is something we can encounter for the RO for instance.=C2=A0
For instance we had previous discussions where the RO was defi= ned as :=C2=A0
"personal or organizational entity"
which I replaced in the latest draft by=C2=A0
"subject= entity" (since it is defined)

For "Subj= ect Information", the question whether this refers to the end-user or = the RO is currently left open.

Please let me= know your thoughts.

Cheers
Fabien
=
On Tue= , Jan 5, 2021 at 8:38 PM Mark Lizar <mark@openconsent.com> wrote:
Hi Fabien, =C2=A0et al,

Great start!!

Could you clarify the use and application of the term subject, as the = term is used in some legal standards for semantics and I wonder if this is = related to the legal semantic attribution of data subject.=C2=A0

In the glossary, =C2=A0it also seems the Subject Entity is referring t= o what is commonly know as legal entity. =C2=A0 And the term subject can re= fer to a few things at this technical level.=E2=80=94 e.g. =C2=A0a semantic= term referencing in general the topic of the resource =C2=A0or is it the legal entity /=C2=A0cred= ential=C2=A0that corresponds to the accountable controller of a resourc= e ? =C2=A0

- Mark=C2=A0

On 5 Jan 2021, at 08:04, Fabien Imbault <fabien.imbault@gmail.com> wrote:=

Hi everyone,=C2=A0

I wish you all a happy new year.

I just created a PR (https://github.com/ietf-wg-gnap/gn= ap-core-protocol/pull/155) that takes into account the various feedback= s. The automatic build process is not working, but you can see the diffs and build the html locally if you p= refer. The definitions have also been updated on the wiki (https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology<= /a>) if you prefer to check there.=C2=A0

Feedbacks welcome before we move to pending merge later on.

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

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000065d51d05b841fdb9-- From nobody Wed Jan 6 13:52: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 1615B3A12C6 for ; Wed, 6 Jan 2021 13:52:04 -0800 (PST) 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.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 2Cg8I3CLSlZI for ; Wed, 6 Jan 2021 13:52:02 -0800 (PST) Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C3453A12BE for ; Wed, 6 Jan 2021 13:52:02 -0800 (PST) Received: by mail-vs1-f48.google.com with SMTP id s85so2593428vsc.3 for ; Wed, 06 Jan 2021 13:52:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=skenW4qrCzSsS5xPAwhW6h4INXfO5T0/yHMeWO40OEo=; b=ZhCm/6zRohMDrPmBo8Jjyru8yc9XjmmLFllokqGk3pE37XlAj9yMJ45jjJJUFl9H4e qXXfVUWBmoigRVFuZGE31XKqT39dhZgQteZ6/26kdkRKZ/C+xHQE7wtHm5Ykn/Gip8mI TsNJTAIUlJOBRrx5BuVXxTeHaM0MFWssj3QPEHGMRx2KKYd/l+0w/Kkq5DcRYOT79wxU 5NZ2AhO+RAWmD2HfeNyhqTD7b08BWqGaOKjJkQ3kSX9l2E+5cLQ6cbGdA+BlNR3zidzy sb0tj6928fTJGDEi+yQaDFe8c0HBzrXg5IuhjUbU0HDbg947Vr2d0deY+Npt68Js3+Mz yXgA== X-Gm-Message-State: AOAM532KnS9djHcPZg3dWRBKGpv4/gLXsfWJIVprnQ2UU3y4Ne/QvrWV 1ajI1lqTfo6EzfJlTljhrHTGOBsCEPRcZs9v7/Q= X-Google-Smtp-Source: ABdhPJxPQYp2DhA/1e5umw34pNOysSmuCpejlnYQmB/zbXDPlblWbc7wzpa0xR6BDf580/I4y2+klqdvzrJwqM3Z0OI= X-Received: by 2002:a67:2e16:: with SMTP id u22mr5252733vsu.12.1609969921220; Wed, 06 Jan 2021 13:52:01 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Adrian Gropper Date: Wed, 6 Jan 2021 16:51:50 -0500 Message-ID: To: Tom Jones Cc: Fabien Imbault , Mark Lizar , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000040e73f05b84255f6" Archived-At: Subject: Re: [GNAP] Terminology PR 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, 06 Jan 2021 21:52:04 -0000 --00000000000040e73f05b84255f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm new to the GNAP list so please forgive me as I get up to speed. RO is a role and the 'subject' of a piece of data is not. I don't see any problem in keeping this distinction straight throughout the spec. - Adrian On Wed, Jan 6, 2021 at 4:27 PM Tom Jones wrote: > Right - the correct term should be *subjects' information* as there are > potentially two subjects, the RO and the "end-user" (really terribly > confusing name). If you consider the case where the end-user is the paren= t > of a child, or of their spouse, both subjects will be asked to supply > information in order to be authenticated. > Peace ..tom > > > On Wed, Jan 6, 2021 at 5:20 AM Fabien Imbault > wrote: > >> Hi Mark, >> >> Thanks for the feedback. >> >> The original requirement for "subject" comes from the reference to >> https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-06 >> (used in the main text). The objective was to try to avoid various terms >> which are synonyms. >> >> You're right, it's close to a legal entity, except from the fact that it >> is defined more broadly (person, organization or device), which is >> something we can encounter for the RO for instance. >> >> For instance we had previous discussions where the RO was defined as : >> "personal or organizational entity" >> which I replaced in the latest draft by >> "subject entity" (since it is defined) >> >> For "Subject Information", the question whether this refers to the >> end-user or the RO is currently left open. >> >> Please let me know your thoughts. >> >> Cheers >> Fabien >> >> On Tue, Jan 5, 2021 at 8:38 PM Mark Lizar wrote: >> >>> Hi Fabien, et al, >>> >>> Great start!! >>> >>> Could you clarify the use and application of the term subject, as the >>> term is used in some legal standards for semantics and I wonder if this= is >>> related to the legal semantic attribution of data subject. >>> >>> In the glossary, it also seems the Subject Entity is referring to what >>> is commonly know as legal entity. And the term subject can refer to a= few >>> things at this technical level.=E2=80=94 e.g. a semantic term referenc= ing in >>> general the *topic* of the resource or is it the* legal entity >>> / credential *that corresponds to the accountable controller of a >>> resource ? >>> >>> - Mark >>> >>> On 5 Jan 2021, at 08:04, Fabien Imbault >>> wrote: >>> >>> Hi everyone, >>> >>> I wish you all a happy new year. >>> >>> I just created a PR ( >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/155) that takes >>> into account the various feedbacks. The automatic build process is not >>> working, but you can see the diffs and build the html locally if you >>> prefer. The definitions have also been updated on the wiki ( >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology) if >>> you prefer to check there. >>> >>> Feedbacks welcome before we move to pending merge later on. >>> >>> Cheers >>> Fabien >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >>> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000040e73f05b84255f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm new to the GNAP list so please forgive me as I get= up to speed.

RO is a role and the 'subject' of = a piece of data is not. I don't see any problem in keeping this distinc= tion straight throughout the spec.

- Adrian
<= /div>
O= n Wed, Jan 6, 2021 at 4:27 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
Right - the correct term should be subjects= ' information as there are potentially two subjects, the RO and the= "end-user" (really terribly confusing name). If you consider the= case where the end-user is the parent of a child, or of their spouse, both= subjects will be asked to supply information in order to be authenticated.=
Peace ..tom


On Wed, Jan 6, 2021 at 5:20 AM Fabien Imbault <= ;fabien.imbau= lt@gmail.com> wrote:
Hi Mark,=C2=A0

Thanks for the feedback.

The original requirement for "subject" come= s from the reference to https://tools.ietf.org/ht= ml/draft-ietf-secevent-subject-identifiers-06 (used in the main text). = The objective was to try to avoid various terms which are synonyms.

You're right, it's close to a legal entity, excep= t from the fact that it is defined more broadly (person, organization or de= vice), which is something we can encounter for the RO for instance.=C2=A0

For instance we had previous discussions where the = RO was defined as :=C2=A0
"personal or organizational entity= "
which I replaced in the latest draft by=C2=A0
&q= uot;subject entity" (since it is defined)

For= "Subject Information", the question whether this refers to the e= nd-user or the RO is currently left open.

Pl= ease let me know your thoughts.

Cheers
F= abien

On Tue, Jan 5, 2021 at 8:38 PM Mark Lizar <mark@openconsent.com> wrote:
Hi Fabien, =C2=A0et al,

Great start!!

Could you clarify the use and application of the term subject, as the = term is used in some legal standards for semantics and I wonder if this is = related to the legal semantic attribution of data subject.=C2=A0

In the glossary, =C2=A0it also seems the Subject Entity is referring t= o what is commonly know as legal entity. =C2=A0 And the term subject can re= fer to a few things at this technical level.=E2=80=94 e.g. =C2=A0a semantic= term referencing in general the topic of the resource =C2=A0or is it the legal entity /=C2=A0cred= ential=C2=A0that corresponds to the accountable controller of a resourc= e ? =C2=A0

- Mark=C2=A0

On 5 Jan 2021, at 08:04, Fabien Imbault <fabien.imbault@gmail.com> wrote:=

Hi everyone,=C2=A0

I wish you all a happy new year.

I just created a PR (https://github.com/ietf-wg-gnap/gn= ap-core-protocol/pull/155) that takes into account the various feedback= s. The automatic build process is not working, but you can see the diffs and build the html locally if you p= refer. The definitions have also been updated on the wiki (https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology<= /a>) if you prefer to check there.=C2=A0

Feedbacks welcome before we move to pending merge later on.

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

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000040e73f05b84255f6-- From nobody Wed Jan 6 14:08: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 3E0053A1338 for ; Wed, 6 Jan 2021 14:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNmORQaSB2-w for ; Wed, 6 Jan 2021 14:08:01 -0800 (PST) Received: from mail-oo1-xc2d.google.com (mail-oo1-xc2d.google.com [IPv6:2607:f8b0:4864:20::c2d]) (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 43AE03A1332 for ; Wed, 6 Jan 2021 14:08:01 -0800 (PST) Received: by mail-oo1-xc2d.google.com with SMTP id x23so1128458oop.1 for ; Wed, 06 Jan 2021 14:08:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EgF6orgxNlquD9IihN6i38+mh5BEie+OUatpQldNtU4=; b=MKhWgrg/B9vz0zZIfQSRCOgrBn3xwuRXCWrS2igHWhu5MmLzF9FABVCDvQt8oqmB2R aoj+jhPWctQY6jrvMZgBS4A9X+zui323U0XsmsgrtxKtD1GvJIUClcODpAwMdjp154Qz GMv0YdkBtf9boQrGqKso1lFEdzmLQ5DcQ/r2+d2B1uDj/EmqNBlM1liInluOAa6ytrZb QG9ryXOZwMq1kEZ12THB9WYsGOpIKc6lG3XuG5HvXOyqciMplqPN/YQdiBMx5jq2abTk 2X7g52wjyELIj3cWwrH0jbXgpqxTonwVEHFUGJtcFzVwTKANorMwWs1veLfyMfI/wnqu w7bA== 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=EgF6orgxNlquD9IihN6i38+mh5BEie+OUatpQldNtU4=; b=Z0c2a3Q3mqmRBJnRC8XzH/Ko9xGFqK3GWf97BDXKoI4e3orZ0FsBSAvJs+nS1hwi7V 3KE2Np3Mx66Y2fmrYUU9UY+vqK5kuSmYXoL42UUgtEGrZavjWFWWtogc44kecBifLCG4 PnsrtY4i+FNGw9p0LYmSUTwd4otm2HeHgsHgU0mL1lEgw2Pijc8patr9i6miyDfojHiv D8WhqDeEVMfb52miwG/LT4Zy6XINkrMQvVHqjp+SmGAtCOr6w6gHSJBXQ0ZjoBz597SB IL/FSFcwKQO3uYsr0unAEpMpgdrAboKyKVYDwBEKoSjFFog8vUbSGkrjfd++9d7urkeF gpuw== X-Gm-Message-State: AOAM5309NUYb6BfCbP29B3p8EDyo5eLV9M8DhVkyCfWkOrCGMdyG3WJ+ m1uMdiGcH+SwqC+jXljRTCZ+KtdmgYuNFfxJkIo= X-Google-Smtp-Source: ABdhPJzh/KoaHDQX9kilfwcDMpeR5OF56vBNsFEBKS5c8+NoHslHsdYT/VByhWYFu5AQqQCnC5wQUd0gMkWqOB1URCw= X-Received: by 2002:a4a:a88a:: with SMTP id q10mr4227963oom.27.1609970880465; Wed, 06 Jan 2021 14:08:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tom Jones Date: Wed, 6 Jan 2021 14:07:49 -0800 Message-ID: To: Adrian Gropper Cc: Fabien Imbault , Mark Lizar , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000006dcd0505b8428e25" Archived-At: Subject: Re: [GNAP] Terminology PR 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, 06 Jan 2021 22:08:03 -0000 --0000000000006dcd0505b8428e25 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable you miss the point. There can be more than one subject and more that one collection of subject data. Peace ..tom On Wed, Jan 6, 2021 at 1:52 PM Adrian Gropper wrote: > I'm new to the GNAP list so please forgive me as I get up to speed. > > RO is a role and the 'subject' of a piece of data is not. I don't see any > problem in keeping this distinction straight throughout the spec. > > - Adrian > > On Wed, Jan 6, 2021 at 4:27 PM Tom Jones > wrote: > >> Right - the correct term should be *subjects' information* as there are >> potentially two subjects, the RO and the "end-user" (really terribly >> confusing name). If you consider the case where the end-user is the pare= nt >> of a child, or of their spouse, both subjects will be asked to supply >> information in order to be authenticated. >> Peace ..tom >> >> >> On Wed, Jan 6, 2021 at 5:20 AM Fabien Imbault >> wrote: >> >>> Hi Mark, >>> >>> Thanks for the feedback. >>> >>> The original requirement for "subject" comes from the reference to >>> https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-06 >>> (used in the main text). The objective was to try to avoid various term= s >>> which are synonyms. >>> >>> You're right, it's close to a legal entity, except from the fact that i= t >>> is defined more broadly (person, organization or device), which is >>> something we can encounter for the RO for instance. >>> >>> For instance we had previous discussions where the RO was defined as : >>> "personal or organizational entity" >>> which I replaced in the latest draft by >>> "subject entity" (since it is defined) >>> >>> For "Subject Information", the question whether this refers to the >>> end-user or the RO is currently left open. >>> >>> Please let me know your thoughts. >>> >>> Cheers >>> Fabien >>> >>> On Tue, Jan 5, 2021 at 8:38 PM Mark Lizar wrote: >>> >>>> Hi Fabien, et al, >>>> >>>> Great start!! >>>> >>>> Could you clarify the use and application of the term subject, as the >>>> term is used in some legal standards for semantics and I wonder if thi= s is >>>> related to the legal semantic attribution of data subject. >>>> >>>> In the glossary, it also seems the Subject Entity is referring to wha= t >>>> is commonly know as legal entity. And the term subject can refer to = a few >>>> things at this technical level.=E2=80=94 e.g. a semantic term referen= cing in >>>> general the *topic* of the resource or is it the* legal entity >>>> / credential *that corresponds to the accountable controller of a >>>> resource ? >>>> >>>> - Mark >>>> >>>> On 5 Jan 2021, at 08:04, Fabien Imbault >>>> wrote: >>>> >>>> Hi everyone, >>>> >>>> I wish you all a happy new year. >>>> >>>> I just created a PR ( >>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/155) that >>>> takes into account the various feedbacks. The automatic build process = is >>>> not working, but you can see the diffs and build the html locally if y= ou >>>> prefer. The definitions have also been updated on the wiki ( >>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology) >>>> if you prefer to check there. >>>> >>>> Feedbacks welcome before we move to pending merge later on. >>>> >>>> Cheers >>>> Fabien >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> >>>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --0000000000006dcd0505b8428e25 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
you miss the point.=C2=A0 There can be more than=C2=A0one = subject and more that one collection of subject data.
Peace ..tom


=
On Wed, Ja= n 6, 2021 at 1:52 PM Adrian Gropper <agropper@healthurl.com> wrote:
I'm new to the GNAP list = so please forgive me as I get up to speed.

RO is a role = and the 'subject' of a piece of data is not. I don't see any pr= oblem in keeping this distinction straight throughout the spec.
<= br>
- Adrian

On Wed, Jan 6, 2021 at 4:27 PM Tom Jones <= thomascli= nganjones@gmail.com> wrote:
Right - the correct term should be s= ubjects' information as there are potentially two subjects, the RO = and the "end-user" (really terribly confusing name). If you consi= der the case where the end-user is the parent of a child, or of their spous= e, both subjects will be asked to supply information in order to be authent= icated.
Peace = ..tom


On Wed, Jan 6, 2021 at 5:20 AM Fabien Imba= ult <fabie= n.imbault@gmail.com> wrote:
Hi Mark,=C2=A0
Thanks for the feedback.

The original = requirement for "subject" comes from the reference to https://tools.ietf.org/html/draft-ietf-secevent-subject-iden= tifiers-06 (used in the main text). The objective was to try to avoid v= arious terms which are synonyms.

You're right,= it's close to a legal entity, except from the fact that it is defined = more broadly (person, organization or device), which is something we can en= counter for the RO for instance.=C2=A0

For instanc= e we had previous discussions where the RO was defined as :=C2=A0
"personal or organizational entity"
which I replaced i= n the latest draft by=C2=A0
"subject entity" (since it = is defined)

For "Subject Information", t= he question whether this refers to the end-user or the RO is currently left= open.

Please let me know your thoughts.

Cheers
Fabien

On Tue, Jan 5, 2021 at 8:38 PM= Mark Lizar <m= ark@openconsent.com> wrote:
Hi Fabien, =C2=A0et al,

Great start!!

Could you clarify the use and application of the term subject, as the = term is used in some legal standards for semantics and I wonder if this is = related to the legal semantic attribution of data subject.=C2=A0

In the glossary, =C2=A0it also seems the Subject Entity is referring t= o what is commonly know as legal entity. =C2=A0 And the term subject can re= fer to a few things at this technical level.=E2=80=94 e.g. =C2=A0a semantic= term referencing in general the topic of the resource =C2=A0or is it the legal entity /=C2=A0cred= ential=C2=A0that corresponds to the accountable controller of a resourc= e ? =C2=A0

- Mark=C2=A0

On 5 Jan 2021, at 08:04, Fabien Imbault <fabien.imbault@gmail.com> wrote:=

Hi everyone,=C2=A0

I wish you all a happy new year.

I just created a PR (https://github.com/ietf-wg-gnap/gn= ap-core-protocol/pull/155) that takes into account the various feedback= s. The automatic build process is not working, but you can see the diffs and build the html locally if you p= refer. The definitions have also been updated on the wiki (https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology<= /a>) if you prefer to check there.=C2=A0

Feedbacks welcome before we move to pending merge later on.

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

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000006dcd0505b8428e25-- From nobody Wed Jan 6 14:14:29 2021 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BADD83A1338 for ; Wed, 6 Jan 2021 14:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zm_PRb8if2Jc for ; Wed, 6 Jan 2021 14:14:25 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 B24BD3A12B5 for ; Wed, 6 Jan 2021 14:14:25 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id p187so4218658iod.4 for ; Wed, 06 Jan 2021 14:14:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1bbARDpRXl7NYfv1QwwqEh2OopknFNpKPCILo+HAExw=; b=sit9l2nKRjeXfq7WxmBMBtgBbVZ9Gb+3mF4RBQbvZ49DLo8FLWw2yyuSZ1AB2YQdnm 9cP+IwJ1LpZCfAf1GyBU8YrxRoIbRoep5lyVChPjhyu3PbomJkR9ojanxxMMV704LlIR jf6bJEdGb/VAwI26xyxe2L9GHw99jspEMZ78lKA9jCBdkOtwrASavZJ04FRhOyaicJEV pFQjJfdnxWnp7ZHSUcxrZ54ftqaJ+d60dfG/DqKo7r/UnzCHrItsaUt2EmdsyBHNFM4Y HUHirL1leUNLxmndgLkWgdupUJyIXbTaa+7spzCgQ2ziYZfOZnZCyo8kH1jja6JiZttZ Eirw== 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=1bbARDpRXl7NYfv1QwwqEh2OopknFNpKPCILo+HAExw=; b=Md77wBf7nsK8N+NAhpAmVBsIE+8C+NUixw/3Xl+UMcYyLvhQJtET2FfSVzAtkyAtZ2 3XsNJ7L6Z3UQfpQjwCq6I+pAet0ZPQAyNwU+UmJnNfYl8hU++bY+ppm61Y3EbTp8JO1f HhCuqS9tLOLmLC9Daz05K7cQ5mZ0DTdfwaRN6rTp2DITHKCavteKqB8rczugDyVmVPTk jJqhhcjk714E5e87NXr2z4w8AQSWJrlL2TMVthkEPX0k/XhNxvlbpVoeWPxCo3xDZTzD fUd7bEu9a3xTKnUZYSP/jSQfszQAJK5GhYC48PCmwqdM6YramNoMSdXkET7fYUWY9bLT 900Q== X-Gm-Message-State: AOAM5315df+9/xnVn6mge3JA+Al1Uvo+O2UqIfmsQsCf5/aKmMlSNiMu /g++pMc+XfaEIerZhZftMXgtlJzWLA1ZRDQmTb0= X-Google-Smtp-Source: ABdhPJz6w5sRxJuDHVmhLMD7zVVz8JvO+Se01CloFSAkcc4ZPKbgXQHPPf+3ucg00lKIIhi4KXU++eB5+VNv8XnDN98= X-Received: by 2002:a05:6602:214b:: with SMTP id y11mr4500079ioy.78.1609971265113; Wed, 06 Jan 2021 14:14:25 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Wed, 6 Jan 2021 23:14:13 +0100 Message-ID: To: Tom Jones Cc: Adrian Gropper , Mark Lizar , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000005b12dc05b842a51e" Archived-At: Subject: Re: [GNAP] Terminology PR 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, 06 Jan 2021 22:14:28 -0000 --0000000000005b12dc05b842a51e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Adrian, welcome, always happy to see new people coming in. Tom, I agree this is a possibility but do we need that in the definition itself (for a somewhat specific use case)? I don't see any loss of generality in the current proposal. On Wed, Jan 6, 2021 at 11:08 PM Tom Jones wrote: > you miss the point. There can be more than one subject and more that one > collection of subject data. > Peace ..tom > > > On Wed, Jan 6, 2021 at 1:52 PM Adrian Gropper > wrote: > >> I'm new to the GNAP list so please forgive me as I get up to speed. >> >> RO is a role and the 'subject' of a piece of data is not. I don't see an= y >> problem in keeping this distinction straight throughout the spec. >> >> - Adrian >> >> On Wed, Jan 6, 2021 at 4:27 PM Tom Jones >> wrote: >> >>> Right - the correct term should be *subjects' information* as there are >>> potentially two subjects, the RO and the "end-user" (really terribly >>> confusing name). If you consider the case where the end-user is the par= ent >>> of a child, or of their spouse, both subjects will be asked to supply >>> information in order to be authenticated. >>> Peace ..tom >>> >>> >>> On Wed, Jan 6, 2021 at 5:20 AM Fabien Imbault >>> wrote: >>> >>>> Hi Mark, >>>> >>>> Thanks for the feedback. >>>> >>>> The original requirement for "subject" comes from the reference to >>>> https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-06 >>>> (used in the main text). The objective was to try to avoid various ter= ms >>>> which are synonyms. >>>> >>>> You're right, it's close to a legal entity, except from the fact that >>>> it is defined more broadly (person, organization or device), which is >>>> something we can encounter for the RO for instance. >>>> >>>> For instance we had previous discussions where the RO was defined as : >>>> "personal or organizational entity" >>>> which I replaced in the latest draft by >>>> "subject entity" (since it is defined) >>>> >>>> For "Subject Information", the question whether this refers to the >>>> end-user or the RO is currently left open. >>>> >>>> Please let me know your thoughts. >>>> >>>> Cheers >>>> Fabien >>>> >>>> On Tue, Jan 5, 2021 at 8:38 PM Mark Lizar wrote= : >>>> >>>>> Hi Fabien, et al, >>>>> >>>>> Great start!! >>>>> >>>>> Could you clarify the use and application of the term subject, as the >>>>> term is used in some legal standards for semantics and I wonder if th= is is >>>>> related to the legal semantic attribution of data subject. >>>>> >>>>> In the glossary, it also seems the Subject Entity is referring to >>>>> what is commonly know as legal entity. And the term subject can ref= er to >>>>> a few things at this technical level.=E2=80=94 e.g. a semantic term = referencing in >>>>> general the *topic* of the resource or is it the* legal entity >>>>> / credential *that corresponds to the accountable controller of a >>>>> resource ? >>>>> >>>>> - Mark >>>>> >>>>> On 5 Jan 2021, at 08:04, Fabien Imbault >>>>> wrote: >>>>> >>>>> Hi everyone, >>>>> >>>>> I wish you all a happy new year. >>>>> >>>>> I just created a PR ( >>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/155) that >>>>> takes into account the various feedbacks. The automatic build process= is >>>>> not working, but you can see the diffs and build the html locally if = you >>>>> prefer. The definitions have also been updated on the wiki ( >>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology) >>>>> if you prefer to check there. >>>>> >>>>> Feedbacks welcome before we move to pending merge later on. >>>>> >>>>> Cheers >>>>> Fabien >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>>> >>>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> --0000000000005b12dc05b842a51e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Adrian, welcome, always happy to see new people coming in.= =C2=A0

Tom, I agree this is a possibility but do we need= that in the definition itself (for a somewhat specific use case)? I don= 9;t see any loss of generality in the current proposal.=C2=A0 =C2=A0
<= /div>
O= n Wed, Jan 6, 2021 at 11:08 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
you miss the= point.=C2=A0 There can be more than=C2=A0one subject and more that one col= lection of subject data.
Peace ..tom


On Wed, Jan 6, 2021 at 1:= 52 PM Adrian Gropper <agropper@healthurl.com> wrote:
I'm new to the GNAP = list so please forgive me as I get up to speed.

RO is a = role and the 'subject' of a piece of data is not. I don't see a= ny problem in keeping this distinction straight throughout the spec.
<= div>
- Adrian

On Wed, Jan 6, 2021 at 4:27 PM Tom Jones &= lt;thomas= clinganjones@gmail.com> wrote:
Right - the correct term should be <= u>subjects' information as there are potentially two subjects, the = RO and the "end-user" (really terribly confusing name). If you co= nsider the case where the end-user is the parent of a child, or of their sp= ouse, both subjects will be asked to supply information in order to be auth= enticated.
Pea= ce ..tom


On Wed, Jan 6, 2021 at 5:20 AM Fabien I= mbault <fa= bien.imbault@gmail.com> wrote:
Hi Mark,=C2=A0
=
Thanks for the feedback.

The origin= al requirement for "subject" comes from the reference to https://tools.ietf.org/html/draft-ietf-secevent-subject-= identifiers-06 (used in the main text). The objective was to try to avo= id various terms which are synonyms.

You're ri= ght, it's close to a legal entity, except from the fact that it is defi= ned more broadly (person, organization or device), which is something we ca= n encounter for the RO for instance.=C2=A0

For ins= tance we had previous discussions where the RO was defined as :=C2=A0
=
"personal or organizational entity"
which I replac= ed in the latest draft by=C2=A0
"subject entity" (since= it is defined)

For "Subject Information"= ;, the question whether this refers to the end-user or the RO is currently = left open.

Please let me know your thoughts.=

Cheers
Fabien

On Tue, Jan 5, 2021 at 8:3= 8 PM Mark Lizar <mark@openconsent.com> wrote:
Hi Fabien, =C2=A0et al,

Great start!!

Could you clarify the use and application of the term subject, as the = term is used in some legal standards for semantics and I wonder if this is = related to the legal semantic attribution of data subject.=C2=A0

In the glossary, =C2=A0it also seems the Subject Entity is referring t= o what is commonly know as legal entity. =C2=A0 And the term subject can re= fer to a few things at this technical level.=E2=80=94 e.g. =C2=A0a semantic= term referencing in general the topic of the resource =C2=A0or is it the legal entity /=C2=A0cred= ential=C2=A0that corresponds to the accountable controller of a resourc= e ? =C2=A0

- Mark=C2=A0

On 5 Jan 2021, at 08:04, Fabien Imbault <fabien.imbault@gmail.com> wrote:=

Hi everyone,=C2=A0

I wish you all a happy new year.

I just created a PR (https://github.com/ietf-wg-gnap/gn= ap-core-protocol/pull/155) that takes into account the various feedback= s. The automatic build process is not working, but you can see the diffs and build the html locally if you p= refer. The definitions have also been updated on the wiki (https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology<= /a>) if you prefer to check there.=C2=A0

Feedbacks welcome before we move to pending merge later on.

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

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000005b12dc05b842a51e-- From nobody Wed Jan 6 14:16: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 33F0C3A1338 for ; Wed, 6 Jan 2021 14:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZ_t_oCMWo0O for ; Wed, 6 Jan 2021 14:16:23 -0800 (PST) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ACF23A1358 for ; Wed, 6 Jan 2021 14:16:14 -0800 (PST) Received: by mail-oi1-x231.google.com with SMTP id d203so5232242oia.0 for ; Wed, 06 Jan 2021 14:16:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3Ug2G5uquHbOvuZpHVyheJS4JG9eua4kMdlUUgsVvW8=; b=OovBsZCyUlYNa6gNs5sViiy2lz3l5LKxvca5gsYj0kyB0nbQbp7ve9mx3RP7rOtPmU P7Det69qeHLIhrNtckd+YK1iJ3386SHiU2FZO03RkU6w7fOm61DpSJ2jHQ5teJlFPif+ iWdMiUxUYNjyJI4wDycxJ88kNrENRBpsXl8KBVRZeix7rsF0heHDI+6YX1Jtn3GeeC+2 8dPdUyQ+Z5+8vbAGA2NAxygIubqcMZeyGSdPqqcz55zmrG8yj+fWPhiIeI8zWRbfRC43 K9HKH+7fqwHJTfXyFCCS4q1LpSrc5yMS0HaUd/htCUPoY2lhd5huDqMhnS2AE2eAOTCR 22hA== 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=3Ug2G5uquHbOvuZpHVyheJS4JG9eua4kMdlUUgsVvW8=; b=gCqXxoPvM6MBZ80CVgc5liwjD8nSobnvnc98o/tv+Gcur/Ycg0wR0ew5RJc6Cp479l FUghvbIIlWgkj3wmMZgti8STnl/Ysr1eOQu8oJiXJ6mDWfMWicSa3xYD0plm56HrH+5a W2CQo7bDz7wC4JxLLwMx6qwj9BOcAU77EhWwcEaFe4EAV+08nltTR4XEwO0UX1Ocgnng 5LN9fnH9/Om+zZidUxDXbkzrocBbcQ1IESX8n+cIUgxsxL/LBtr9cb2k/+0uxuP6/ukM vGnESSGp7EQ4YIhEtZUgyvNfD/Ae9taE64h9uLXAdgmdiAWcjVR+6rIIkoxOVhWitVMV 7UCw== X-Gm-Message-State: AOAM53066j3qi6KGkLFwcb6nh72GbYEKEG0CzpybjNVxLU3TpC+phcxV oOsiXNvMMNuU7FBQ0rVQdP+8Seta3vZBdSCpOlk= X-Google-Smtp-Source: ABdhPJxL76r19ggEgGYiobrFBElFLZRiW7ZcKUQEFCStElvMhp3rvHs3uaQeddXdpbej1aUHgYeZRi15FFpyRAhvUMs= X-Received: by 2002:aca:47cb:: with SMTP id u194mr4683762oia.63.1609971373584; Wed, 06 Jan 2021 14:16:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tom Jones Date: Wed, 6 Jan 2021 14:16:02 -0800 Message-ID: To: Fabien Imbault Cc: Adrian Gropper , Mark Lizar , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000d235b205b842ab10" Archived-At: Subject: Re: [GNAP] Terminology PR 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, 06 Jan 2021 22:16:25 -0000 --000000000000d235b205b842ab10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable you yourself brought up the problem. We do not know that the term "subject data" refers to. My suggestion is to make subject plural. Peace ..tom On Wed, Jan 6, 2021 at 2:14 PM Fabien Imbault wrote: > Adrian, welcome, always happy to see new people coming in. > > Tom, I agree this is a possibility but do we need that in the definition > itself (for a somewhat specific use case)? I don't see any loss of > generality in the current proposal. > > On Wed, Jan 6, 2021 at 11:08 PM Tom Jones > wrote: > >> you miss the point. There can be more than one subject and more that on= e >> collection of subject data. >> Peace ..tom >> >> >> On Wed, Jan 6, 2021 at 1:52 PM Adrian Gropper >> wrote: >> >>> I'm new to the GNAP list so please forgive me as I get up to speed. >>> >>> RO is a role and the 'subject' of a piece of data is not. I don't see >>> any problem in keeping this distinction straight throughout the spec. >>> >>> - Adrian >>> >>> On Wed, Jan 6, 2021 at 4:27 PM Tom Jones >>> wrote: >>> >>>> Right - the correct term should be *subjects' information* as there >>>> are potentially two subjects, the RO and the "end-user" (really terrib= ly >>>> confusing name). If you consider the case where the end-user is the pa= rent >>>> of a child, or of their spouse, both subjects will be asked to supply >>>> information in order to be authenticated. >>>> Peace ..tom >>>> >>>> >>>> On Wed, Jan 6, 2021 at 5:20 AM Fabien Imbault >>>> wrote: >>>> >>>>> Hi Mark, >>>>> >>>>> Thanks for the feedback. >>>>> >>>>> The original requirement for "subject" comes from the reference to >>>>> https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-0= 6 >>>>> (used in the main text). The objective was to try to avoid various te= rms >>>>> which are synonyms. >>>>> >>>>> You're right, it's close to a legal entity, except from the fact that >>>>> it is defined more broadly (person, organization or device), which is >>>>> something we can encounter for the RO for instance. >>>>> >>>>> For instance we had previous discussions where the RO was defined as = : >>>>> "personal or organizational entity" >>>>> which I replaced in the latest draft by >>>>> "subject entity" (since it is defined) >>>>> >>>>> For "Subject Information", the question whether this refers to the >>>>> end-user or the RO is currently left open. >>>>> >>>>> Please let me know your thoughts. >>>>> >>>>> Cheers >>>>> Fabien >>>>> >>>>> On Tue, Jan 5, 2021 at 8:38 PM Mark Lizar >>>>> wrote: >>>>> >>>>>> Hi Fabien, et al, >>>>>> >>>>>> Great start!! >>>>>> >>>>>> Could you clarify the use and application of the term subject, as th= e >>>>>> term is used in some legal standards for semantics and I wonder if t= his is >>>>>> related to the legal semantic attribution of data subject. >>>>>> >>>>>> In the glossary, it also seems the Subject Entity is referring to >>>>>> what is commonly know as legal entity. And the term subject can re= fer to >>>>>> a few things at this technical level.=E2=80=94 e.g. a semantic term= referencing in >>>>>> general the *topic* of the resource or is it the* legal entity >>>>>> / credential *that corresponds to the accountable controller of a >>>>>> resource ? >>>>>> >>>>>> - Mark >>>>>> >>>>>> On 5 Jan 2021, at 08:04, Fabien Imbault >>>>>> wrote: >>>>>> >>>>>> Hi everyone, >>>>>> >>>>>> I wish you all a happy new year. >>>>>> >>>>>> I just created a PR ( >>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/155) that >>>>>> takes into account the various feedbacks. The automatic build proces= s is >>>>>> not working, but you can see the diffs and build the html locally if= you >>>>>> prefer. The definitions have also been updated on the wiki ( >>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology) >>>>>> if you prefer to check there. >>>>>> >>>>>> Feedbacks welcome before we move to pending merge later on. >>>>>> >>>>>> Cheers >>>>>> Fabien >>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>>> >>>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> --000000000000d235b205b842ab10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
you yourself brought up the problem. We do not know that t= he term "subject data" refers to.=C2=A0 My suggestion is to make = subject plural.
Peace ..tom<= /div>


On Wed, Jan 6, 2021 at 2:14 PM Fabien Imbault &l= t;fabien.imbault@gmail.com&= gt; wrote:
Adrian, welcome, always happy to see new people coming in.=C2= =A0

Tom, I agree this is a possibility but do we need th= at in the definition itself (for a somewhat specific use case)? I don't= see any loss of generality in the current proposal.=C2=A0 =C2=A0

On W= ed, Jan 6, 2021 at 11:08 PM Tom Jones <thomasclinganjones@gmail.com> wrote= :
you miss the point.=C2=A0 There can be more than=C2=A0one subject and mo= re that one collection of subject data.
Peace ..tom


=
On Wed, Ja= n 6, 2021 at 1:52 PM Adrian Gropper <agropper@healthurl.com> wrote:
I'm new= to the GNAP list so please forgive me as I get up to speed.

=
RO is a role and the 'subject' of a piece of data is not. I do= n't see any problem in keeping this distinction straight throughout the= spec.

- Adrian

On Wed, Jan 6, 2021 at 4:27 P= M Tom Jones <thomasclinganjones@gmail.com> wrote:
Right - the correct ter= m should be subjects' information as there are potentially two s= ubjects, the RO and the "end-user" (really terribly confusing nam= e). If you consider the case where the end-user is the parent of a child, o= r of their spouse, both subjects will be asked to supply information in ord= er to be authenticated.
Peace ..tom


On Wed, Jan 6, 2021 at 5:2= 0 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Ma= rk,=C2=A0

Thanks for the feedback.

<= div>The original requirement for "subject" comes from the referen= ce to https://tools.ietf.org/html/draft-ietf-sece= vent-subject-identifiers-06 (used in the main text). The objective was = to try to avoid various terms which are synonyms.

= You're right, it's close to a legal entity, except from the fact th= at it is defined more broadly (person, organization or device), which is so= mething we can encounter for the RO for instance.=C2=A0

For instance we had previous discussions where the RO was defined as = :=C2=A0
"personal or organizational entity"
w= hich I replaced in the latest draft by=C2=A0
"subject entity= " (since it is defined)

For "Subject Inf= ormation", the question whether this refers to the end-user or the RO = is currently left open.

Please let me know y= our thoughts.

Cheers
Fabien

On Tue, Jan 5= , 2021 at 8:38 PM Mark Lizar <mark@openconsent.com> wrote:
Hi Fabien, =C2=A0et al,

Great start!!

Could you clarify the use and application of the term subject, as the = term is used in some legal standards for semantics and I wonder if this is = related to the legal semantic attribution of data subject.=C2=A0

In the glossary, =C2=A0it also seems the Subject Entity is referring t= o what is commonly know as legal entity. =C2=A0 And the term subject can re= fer to a few things at this technical level.=E2=80=94 e.g. =C2=A0a semantic= term referencing in general the topic of the resource =C2=A0or is it the legal entity /=C2=A0cred= ential=C2=A0that corresponds to the accountable controller of a resourc= e ? =C2=A0

- Mark=C2=A0

On 5 Jan 2021, at 08:04, Fabien Imbault <fabien.imbault@gmail.com> wrote:=

Hi everyone,=C2=A0

I wish you all a happy new year.

I just created a PR (https://github.com/ietf-wg-gnap/gn= ap-core-protocol/pull/155) that takes into account the various feedback= s. The automatic build process is not working, but you can see the diffs and build the html locally if you p= refer. The definitions have also been updated on the wiki (https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology<= /a>) if you prefer to check there.=C2=A0

Feedbacks welcome before we move to pending merge later on.

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

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000d235b205b842ab10-- From nobody Wed Jan 6 14:20:13 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 539703A1340 for ; Wed, 6 Jan 2021 14:20:12 -0800 (PST) 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 hIywhfdp4sa1 for ; Wed, 6 Jan 2021 14:20:10 -0800 (PST) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4D73A133A for ; Wed, 6 Jan 2021 14:20:10 -0800 (PST) Received: by mail-io1-xd36.google.com with SMTP id w18so4259711iot.0 for ; Wed, 06 Jan 2021 14:20:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uvXYsB0hHmEiXXlW060FuYlEA3Y/qrP4wKjTJA9MXRo=; b=kWWTgSJOmLqytICWnGswdd/80kPk0EUdSNr2khH7g3lwiaNT266brSegGQxIupymZY +qfzBgxtlfmm4X3RInw/tAUN2qXqHLDDsiTckgCrJwB03zMEp5Zg4qzrmjmP3Bp5lEI6 W9rrIL0zPtYQZAOgEAxg5velCO+SBRS++G6ExIn0DPGPQUAaQUOEVAVAxGwEqrD919Yy ostPXZPVIhb6UNDqG5PIVhWYq81cL99TZyyQf8kdj5njw5zF9T6hGW1PtbZeL7PzNQ/Y JoGk1IvQ4Yz+0c6mp4VYiMS55QdWrkFndFI9OEUyzFJipdmHYOzdiYsClVQ0+SyaR3oN n+Cw== 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=uvXYsB0hHmEiXXlW060FuYlEA3Y/qrP4wKjTJA9MXRo=; b=VdKf8asrCAW5uW59xPSDP8+RB2YswNWd+beL5mc8AmekciDtzC77AY6n3q1jIrcQkS Yv+pHkLRuFrMW4v8Whoybzk5s2J7hLt92B92zlIFEbN8Rs5wbUQxf00m4g0nM2uW4Ll5 XcU/t7QGP8YLgHmlo42eFBcHaoFucIkqEs+XBYlS8jBC0Zsnkq5b4tJeC8L++6ZiQqoC OC7bWCYz2gjO46Wrfb9vlhimpqD8EBR3s/oP6vWW2CouX0HENE0tlzKmUu9FFZZSD4ql oXZN3JoYMFTk4LtuFVGtQn7edA3z1SpOByibs7+MQkVBY2JpNpoECLNPo4J0Ca2w+aH8 gfRQ== X-Gm-Message-State: AOAM530bk6FwjsByW41+j9IX3mHFYwh/k+KRk2h4wTR/aql3VKDLDl5Y MPlSiWlMr1uNAZdkM/g0gRIpsFLlcT24c98+weo= X-Google-Smtp-Source: ABdhPJzTZ4XU9muW4uha7fGrscKswuLfWh9qL9U9fnYTm9K8aFYP32smRNw61zXD2FN87iB7XLOq2Ydx2kS6Jd0MG7w= X-Received: by 2002:a6b:7a0c:: with SMTP id h12mr4483544iom.162.1609971609314; Wed, 06 Jan 2021 14:20:09 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Wed, 6 Jan 2021 23:19:56 +0100 Message-ID: To: Tom Jones Cc: Adrian Gropper , Mark Lizar , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000df300b05b842b9ff" Archived-At: Subject: Re: [GNAP] Terminology PR 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, 06 Jan 2021 22:20:12 -0000 --000000000000df300b05b842b9ff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't think I spoke about subject data. I did speak about subject, as an alternative to using either person/org/device. We also already have subject information. Which is just really defined as a statement about the subject. Is that what you call subject data here? Le mer. 6 janv. 2021 =C3=A0 23:16, Tom Jones = a =C3=A9crit : > you yourself brought up the problem. We do not know that the term "subjec= t > data" refers to. My suggestion is to make subject plural. > Peace ..tom > > > On Wed, Jan 6, 2021 at 2:14 PM Fabien Imbault > wrote: > >> Adrian, welcome, always happy to see new people coming in. >> >> Tom, I agree this is a possibility but do we need that in the definition >> itself (for a somewhat specific use case)? I don't see any loss of >> generality in the current proposal. >> >> On Wed, Jan 6, 2021 at 11:08 PM Tom Jones >> wrote: >> >>> you miss the point. There can be more than one subject and more that >>> one collection of subject data. >>> Peace ..tom >>> >>> >>> On Wed, Jan 6, 2021 at 1:52 PM Adrian Gropper >>> wrote: >>> >>>> I'm new to the GNAP list so please forgive me as I get up to speed. >>>> >>>> RO is a role and the 'subject' of a piece of data is not. I don't see >>>> any problem in keeping this distinction straight throughout the spec. >>>> >>>> - Adrian >>>> >>>> On Wed, Jan 6, 2021 at 4:27 PM Tom Jones >>>> wrote: >>>> >>>>> Right - the correct term should be *subjects' information* as there >>>>> are potentially two subjects, the RO and the "end-user" (really terri= bly >>>>> confusing name). If you consider the case where the end-user is the p= arent >>>>> of a child, or of their spouse, both subjects will be asked to supply >>>>> information in order to be authenticated. >>>>> Peace ..tom >>>>> >>>>> >>>>> On Wed, Jan 6, 2021 at 5:20 AM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Hi Mark, >>>>>> >>>>>> Thanks for the feedback. >>>>>> >>>>>> The original requirement for "subject" comes from the reference to >>>>>> https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-= 06 >>>>>> (used in the main text). The objective was to try to avoid various t= erms >>>>>> which are synonyms. >>>>>> >>>>>> You're right, it's close to a legal entity, except from the fact tha= t >>>>>> it is defined more broadly (person, organization or device), which i= s >>>>>> something we can encounter for the RO for instance. >>>>>> >>>>>> For instance we had previous discussions where the RO was defined as >>>>>> : >>>>>> "personal or organizational entity" >>>>>> which I replaced in the latest draft by >>>>>> "subject entity" (since it is defined) >>>>>> >>>>>> For "Subject Information", the question whether this refers to the >>>>>> end-user or the RO is currently left open. >>>>>> >>>>>> Please let me know your thoughts. >>>>>> >>>>>> Cheers >>>>>> Fabien >>>>>> >>>>>> On Tue, Jan 5, 2021 at 8:38 PM Mark Lizar >>>>>> wrote: >>>>>> >>>>>>> Hi Fabien, et al, >>>>>>> >>>>>>> Great start!! >>>>>>> >>>>>>> Could you clarify the use and application of the term subject, as >>>>>>> the term is used in some legal standards for semantics and I wonder= if this >>>>>>> is related to the legal semantic attribution of data subject. >>>>>>> >>>>>>> In the glossary, it also seems the Subject Entity is referring to >>>>>>> what is commonly know as legal entity. And the term subject can r= efer to >>>>>>> a few things at this technical level.=E2=80=94 e.g. a semantic ter= m referencing in >>>>>>> general the *topic* of the resource or is it the* legal entity >>>>>>> / credential *that corresponds to the accountable controller of a >>>>>>> resource ? >>>>>>> >>>>>>> - Mark >>>>>>> >>>>>>> On 5 Jan 2021, at 08:04, Fabien Imbault >>>>>>> wrote: >>>>>>> >>>>>>> Hi everyone, >>>>>>> >>>>>>> I wish you all a happy new year. >>>>>>> >>>>>>> I just created a PR ( >>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/155) that >>>>>>> takes into account the various feedbacks. The automatic build proce= ss is >>>>>>> not working, but you can see the diffs and build the html locally i= f you >>>>>>> prefer. The definitions have also been updated on the wiki ( >>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology= ) >>>>>>> if you prefer to check there. >>>>>>> >>>>>>> Feedbacks welcome before we move to pending merge later on. >>>>>>> >>>>>>> Cheers >>>>>>> Fabien >>>>>>> -- >>>>>>> TXAuth mailing list >>>>>>> TXAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >>>>>>> >>>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> --000000000000df300b05b842b9ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't think I spoke about subject data. I did = speak about subject, as an alternative to using either person/org/device.= =C2=A0

We also already h= ave subject information. Which is just really defined as a statement about = the subject. Is that what you call subject data here?=C2=A0

Le me= r. 6 janv. 2021 =C3=A0 23:16, Tom Jones <thomasclinganjones@gmail.com> a =C3=A9crit=C2=A0:
you yourself brough= t up the problem. We do not know that the term "subject data" ref= ers to.=C2=A0 My suggestion is to make subject plural.
Peace ..tom


On Wed, Jan 6, 2021 at 2:14 PM Fabi= en Imbault <fabien.imbault@gmail.com> wrote:
Adrian, welco= me, always happy to see new people coming in.=C2=A0

Tom,= I agree this is a possibility but do we need that in the definition itself= (for a somewhat specific use case)? I don't see any loss of generality= in the current proposal.=C2=A0 =C2=A0

On Wed, Jan 6, 2021 at 11:08 PM= Tom Jones <thomasclinganjones@gmail.com> wrote:
you m= iss the point.=C2=A0 There can be more than=C2=A0one subject and more that = one collection of subject data.
Peace ..tom


On Wed, Jan 6, 202= 1 at 1:52 PM Adrian Gropper <agropper@healthurl.com> wrote:
= I'm new to the GNAP list so please forgive me as I get up to speed.
RO is a role and the 'subject' of a piece of data i= s not. I don't see any problem in keeping this distinction straight thr= oughout the spec.

- Adrian

On Wed, Jan 6, 202= 1 at 4:27 PM Tom Jones <thomasclinganjones@gmail.com> w= rote:
Right - the correct term should be subjects' information as there are potentially two subjects, the RO and the "end-user"= ; (really terribly confusing name). If you consider the case where the end-= user is the parent of a child, or of their spouse, both subjects will be as= ked to supply information in order to be authenticated.
Peace ..tom


On Wed, Jan 6, 2021 at 5:20 AM Fabien Imbault <fabien.imbaul= t@gmail.com> wrote:
Hi Mark,=C2=A0

<= div>Thanks for the feedback.

The original requirem= ent for "subject" comes from the reference to https://tools.ietf.org/html/draft-ietf-secevent-s= ubject-identifiers-06 (used in the main text). The objective was to try= to avoid various terms which are synonyms.

You= 9;re right, it's close to a legal entity, except from the fact that it = is defined more broadly (person, organization or device), which is somethin= g we can encounter for the RO for instance.=C2=A0

= For instance we had previous discussions where the RO was defined as :=C2= =A0
"personal or organizational entity"
which= I replaced in the latest draft by=C2=A0
"subject entity&quo= t; (since it is defined)

For "Subject Informa= tion", the question whether this refers to the end-user or the RO is c= urrently left open.

Please let me know your = thoughts.

Cheers
Fabien

On Tue, Jan 5, 20= 21 at 8:38 PM Mark Lizar <mark@openconsent.com> wrote:
Hi Fabien, =C2=A0et al,

Great start!!

Could you clarify the use and application of the term subject, as the = term is used in some legal standards for semantics and I wonder if this is = related to the legal semantic attribution of data subject.=C2=A0

In the glossary, =C2=A0it also seems the Subject Entity is referring t= o what is commonly know as legal entity. =C2=A0 And the term subject can re= fer to a few things at this technical level.=E2=80=94 e.g. =C2=A0a semantic= term referencing in general the topic of the resource =C2=A0or is it the legal entity /=C2=A0cred= ential=C2=A0that corresponds to the accountable controller of a resourc= e ? =C2=A0

- Mark=C2=A0

On 5 Jan 2021, at 08:04, Fabien Imbault <fabien.imbault@gmail= .com> wrote:

Hi everyone,=C2=A0

I wish you all a happy new year.

I just created a PR (https://github.= com/ietf-wg-gnap/gnap-core-protocol/pull/155) that takes into account t= he various feedbacks. The automatic build process is not working, but you can see the diffs and build the html locally if you p= refer. The definitions have also been updated on the wiki (https://github.com/ietf-wg-gnap/gnap-core-protoco= l/wiki/Terminology) if you prefer to check there.=C2=A0

Feedbacks welcome before we move to pending merge later on.

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

--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--000000000000df300b05b842b9ff-- From nobody Wed Jan 6 14:58:19 2021 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2C23A1354 for ; Wed, 6 Jan 2021 14:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.527 X-Spam-Level: X-Spam-Status: No, score=-0.527 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=1.569, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeIRbshG7h7S for ; Wed, 6 Jan 2021 14:58:16 -0800 (PST) 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 4C4B53A1353 for ; Wed, 6 Jan 2021 14:58:16 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id y17so3810534wrr.10 for ; Wed, 06 Jan 2021 14:58:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version; bh=DEAzvsFRMYLMdAKUUMuQm/0qYtL97RMcHIJLgGQ3NgY=; b=C7WOIk7GjZj6s2J2uy7ByykBHJY58LRI/bfpxxwgSYtFSnj+q0NlPeOu29JJsENYCa n7nCVOvXQsUdYWNjA0tRtelkEA2rCJg+Kmjytlp7tclia5kdmOxta1SxFjg8bFKVBdO2 xCXe3nSFfd4lLAcZTGMzQxf7/NGYFLRe8QwCOtuQcDkCRvPCGSFgoxHkHtH+L+m2K+5W inrQjZO9wqFACu4csUIgii0Jfrq6dvPYCzncBg4uYXRfk9goUXlE5mGSfxsXn4sUkxhJ JV5h0D1+nNSZQvOPNpHYrAk9q6LwKWS0JgwCPzLuD3rHY5nECJOSDMfPaLYGz14AuMWX qkpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version; bh=DEAzvsFRMYLMdAKUUMuQm/0qYtL97RMcHIJLgGQ3NgY=; b=ppf9fw1rPFyJxUJJFnS3uXHj9ivYH/TnAX/0DaX/yi3MkSQwhIyudwW7ZrqI1TTy13 PwACQ0qiCi4XKGhkzwGqUrY20CLfKWp+c/1CZgGDnnj2lNMFaAVPRozMs1y03AZw0EbS Qf6hm+cmAK9FIPLHBaesH56NTAUQ8e2fWrv16G/S1FiKm+ReuHo0NVRxTgn0T8R6QTIb VsRW57w3HGtpVqRmqjytfJi3iiYWqdw1X3bVZo60mioISOsXlYzhhJ0APcrxCTUHO2Rt 7HWh7WvArLjKLLvRbXOAh11/z9ZUXn88PvlCX2Go7efyLw1Z2IrYS6zBgJAljRTINSHR F4MQ== X-Gm-Message-State: AOAM530oM2gYcoWuU7Sor+3LjUyCxEOE42mq9Jo+QDjh+HnKtd/4EEUY 5kOBc+PQpCZQKWqNfK3+WBA= X-Google-Smtp-Source: ABdhPJyDBrRWxgtembRaO/hUQV+zwNnLXUbU8chGz+OGTpst5gOXpIBgdlh06JXHim+vEgGBSPT2XQ== X-Received: by 2002:adf:a388:: with SMTP id l8mr6188947wrb.354.1609973894478; Wed, 06 Jan 2021 14:58:14 -0800 (PST) Received: from [172.26.49.35] (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id m17sm5422174wrn.0.2021.01.06.14.58.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jan 2021 14:58:13 -0800 (PST) User-Agent: Microsoft-MacOutlook/16.44.20121301 Date: Thu, 07 Jan 2021 00:58:12 +0200 From: Yaron Sheffer To: Mike Jones , "txauth@ietf.org" Message-ID: <07976434-A2A4-428A-A146-037A044AA9FC@gmail.com> Thread-Topic: Interim meeting next Tuesday References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3692825893_326702617" Archived-At: Subject: Re: [GNAP] Interim meeting next Tuesday 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, 06 Jan 2021 22:58:18 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3692825893_326702617 Content-type: multipart/alternative; boundary="B_3692825893_1619116179" --B_3692825893_1619116179 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I=E2=80=99m not sure this=E2=80=99ll work, but let=E2=80=99s try. =20 From: Mike Jones Date: Wednesday, January 6, 2021 at 22:56 To: "yaronf.ietf@gmail.com" , GNAP Mailing List Subject: RE: Interim meeting next Tuesday =20 Could you send a calendar invitation for this including the join link so it= =E2=80=99s in people=E2=80=99s calendars? =20 Thanks, -- Mike =20 From: TXAuth On Behalf Of Yaron Sheffer Sent: Wednesday, January 6, 2021 11:09 AM To: GNAP Mailing List Subject: [EXTERNAL] [GNAP] Interim meeting next Tuesday =20 Reminder: we will be meeting next week to review the latest with the GNAP c= ore protocol and discuss issues. =20 See you all there! =20 Leif and Yaron =20 =20 Jan. 12 2021, 17:00-18:30 UTC Join with Zoom Working group status (chairs) Draft update (Aaron) Terminology update Open issues:=20 Access token request/response format Interaction request/response format AOB and next steps =20 --B_3692825893_1619116179 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

I=E2=80=99m not sure this=E2=80=99ll work, but let=E2=80=99s try.

 <= /span>

From: Mike Jones <Michael.Jones@microsoft.com>= ;
Date: Wednesday, January 6, 2021 at 22:56
To: "ya= ronf.ietf@gmail.com" <yaronf.ietf@gmail.com>, GNAP Mailing List &= lt;txauth@ietf.org>
Subject: RE: Interim meeting next Tuesday

 

Could you send a calendar invitation for this inc= luding the join link so it=E2=80=99s in people=E2=80=99s calendars?

 

            = ;            &nb= sp;            &= nbsp;            = ;     Thanks,

     &nb= sp;            &= nbsp;            = ;            &nb= sp;           -- Mike

 

From: TXAuth = <txauth-bounces@ietf.org> On Behalf Of Yaron Sheffer
Sent= : Wednesday, January 6, 2021 11:09 AM
To: GNAP Mailing List &l= t;txauth@ietf.org>
Subject: [EXTERNAL] [GNAP] Interim meeting n= ext Tuesday

 <= /o:p>

Reminder: we will= be meeting next week to review the latest with the GNAP core protocol and d= iscuss issues.

 

See you all there!

 

        =         Leif and Yaron<= /p>

 

 

Jan. 12 2021, 17:00-18:30 UTC

Join with Zoom

 

--B_3692825893_1619116179-- --B_3692825893_326702617 Content-type: text/calendar; name="GNAP interim.ics"; x-mac-creator="4F50494D"; x-mac-type="49637320" Content-disposition: attachment; filename="GNAP interim.ics" Content-transfer-encoding: base64 QkVHSU46VkNBTEVOREFSDQpWRVJTSU9OOjIuMA0KUFJPRElEOi0vL01pY3Jvc29mdCBDb3Jw b3JhdGlvbi8vT3V0bG9vayBmb3IgTWFjIE1JTUVESVIvL0VODQpNRVRIT0Q6UFVCTElTSA0K QkVHSU46VlRJTUVaT05FDQpUWklEOkplcnVzYWxlbQ0KWC1FTlRPVVJBR0UtQ0ZUSU1FWk9O RTpBc2lhL0plcnVzYWxlbQ0KWC1FTlRPVVJBR0UtVFpJRDoxNA0KQkVHSU46U1RBTkRBUkQN ClJSVUxFOkZSRVE9WUVBUkxZO0lOVEVSVkFMPTE7QllTRUNPTkQ9MDtCWU1JTlVURT0wO0JZ SE9VUj0yO0JZREFZPS0xU1U7QllNDQogT05USD0xMA0KVFpPRkZTRVRGUk9NOiswMzAwDQpU Wk9GRlNFVFRPOiswMjAwDQpEVFNUQVJUOjIwMjAxMDI1VDAyMDAwMA0KRU5EOlNUQU5EQVJE DQpCRUdJTjpEQVlMSUdIVA0KUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWVNFQ09O RD0wO0JZTUlOVVRFPTA7QllIT1VSPTI7QllEQVk9LTFGUjtCWU0NCiBPTlRIPTMNClRaT0ZG U0VURlJPTTorMDIwMA0KVFpPRkZTRVRUTzorMDMwMA0KRFRTVEFSVDoyMDIwMDMyN1QwMjAw MDANCkVORDpEQVlMSUdIVA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpVSUQ6MDQw MDAwMDA4MjAwRTAwMDc0QzVCNzEwMUE4MkUwMDgwMDAwMDAwMEQwRDdFNkU5NzFDQ0Q2MDEw MDAwMDAwMDAwMDAwMA0KIDAwMTAwMDAwMDAwOThBMTVGRkUzQ0MzODRGODdCMzQzQjZCQkZC QTlBOQ0KWC1FTlRPVVJBR0VfVVVJRDo1NzMzODE1MC1FMTUwLTQ5ODAtOEZDNS1BRUNBNEFG QTQ4RDYNClgtTUlDUk9TT0ZULUVYQ0hBTkdFLUlEOkFBTWtBR1F3Tm1GaVpqTXhMVFExT0dF dE5EWXlaaTFoWTJVMkxUTmtOell5TnpZd01UDQogWmhPQUJHQUFBQUFBQWR4Si05R2ZtYlM2 R0thMU4tRkh0bEJ3Q2xMVy1xVXdQR1FZUW1aY29BNWRVTEFBQUFrbDJIQUFERFlmT0wNCiB3 aDg1UnJaMHJkWjU3d3NKQUFRVzdBZkRBQUE9DQpYLU1JQ1JPU09GVC1FWENIQU5HRS1DSEFO R0VLRVk6dzJIemk4SWZPVWEyZEszV2VlOExDUUFFS1E0WTB3PT0NCkRUU1RBTVA6MjAyMTAx MDZUMjI1NTE2Wg0KRFRTVEFSVDtUWklEPUplcnVzYWxlbToyMDIxMDExMlQxOTAwMDANCkRU RU5EO1RaSUQ9SmVydXNhbGVtOjIwMjEwMTEyVDIwMzAwMA0KTEFTVC1NT0RJRklFRDoyMDIx MDEwNlQyMjU1MTZaDQpTVU1NQVJZOkdOQVAgaW50ZXJpbQ0KREVTQ1JJUFRJT046IEpvaW4g d2l0aCBab29tXG5Xb3JraW5nIGdyb3VwIHN0YXR1cyAoY2hhaXJzKVxuXG5EcmFmdCB1cGRh dGUNCiAgKEFhcm9uKVxuXG5UZXJtaW5vbG9neSB1cGRhdGVcblxuT3BlbiBpc3N1ZXM6IFxu QWNjZXNzIHRva2VuDQogIHJlcXVlc3QvcmVzcG9uc2UgZm9ybWF0XG5cbkludGVyYWN0aW9u IHJlcXVlc3QvcmVzcG9uc2UgZm9ybWF0XG5BT0IgYW5kDQogIG5leHQgc3RlcHNcblxuIFxu XG4gXG5cbiBcblxuSGkgdGhlcmVcLFxuWWFyb24gU2hlZmZlciBpcyBpbnZpdGluZyB5b3UN CiAgdG8gYSBzY2hlZHVsZWQgWm9vbSBtZWV0aW5nLiBcbkNsaWNrIHRvIEpvaW4gWm9vbSBN ZWV0aW5nIFxuTWVldGluZyBVUkw6DQogIFxuaHR0cHM6Ly9pbnR1aXQuem9vbS51cy9qLzk5 NTMzMTAxODMyP2Zyb209YWRkb25cbk9uZSB0YXAgbW9iaWxlOlxuVVM6DQogICsxNjQ2NTU4 ODY1NlwsXCw5OTUzMzEwMTgzMiMgb3IgKzE2Njk5MDA2ODMzXCxcLDk5NTMzMTAxODMyIyBc bkRpYWwtSW4NCiAgT25seTogXG5Gb3IgaGlnaGVyIHF1YWxpdHlcLCBkaWFsIGEgbnVtYmVy IGJhc2VkIG9uIHlvdXIgY3VycmVudA0KICBsb2NhdGlvbi4gXG5EaWFsOiBcblxuVVM6ICsx IDY0NiA1NTggODY1NiBvciArMSA2NjkgOTAwIDY4MzMgb3IgKzEgMjUzDQogIDIxNSA4Nzgy IG9yICsxIDMwMSA3MTUgODU5MiBvciArMSAzMTIgNjI2IDY3OTkgb3IgKzEgMzQ2IDI0OCA3 Nzk5IG9yIDg3Nw0KICA4NTMgNTI1NyAoVG9sbCBGcmVlKSBvciA4ODggNDc1IDQ0OTkgKFRv bGwgRnJlZSkgXG5NZWV0aW5nIElEOiBcbjk5NQ0KICAzMzEwIDE4MzJcbkludGVybmF0aW9u YWwgbnVtYmVyc1xuRnJvbSBhbiBJbnR1aXQgUm9vbSBTeXN0ZW06IFxuRGlhbDoNCiAgXG4y MiA5OTUzMzEwMTgzMiBcbkZyb20gYSBub24gSW50dWl0IFJvb20gU3lzdGVtOiBcbkRpYWw6 DQogIFxuOTk1MzMxMDE4MzJAem9vbWNyYy5jb20gXG5Kb2luIGJ5IEgzMjM6IFxuRGlhbDog XG4xNjIuMjU1LjM3LjExIChVUw0KICBXZXN0KVxuMTYyLjI1NS4zNi4xMSAoVVMgRWFzdClc bjExNS4xMTQuMTMxLjcgKEluZGlhDQogIE11bWJhaSlcbjExNS4xMTQuMTE1LjcgKEluZGlh IEh5ZGVyYWJhZClcbjIxMy4xOS4xNDQuMTEwIChBbXN0ZXJkYW0NCiAgTmV0aGVybGFuZHMp XG4yMTMuMjQ0LjE0MC4xMTAgKEdlcm1hbnkpXG4xMDMuMTIyLjE2Ni41NQ0KICAoQXVzdHJh bGlhKVxuNjQuMjExLjE0NC4xNjAgKEJyYXppbClcbjY5LjE3NC41Ny4xNjANCiAgKENhbmFk YSlcbjIwNy4yMjYuMTMyLjExMCAoSmFwYW4pXG5NZWV0aW5nIElEOiBcbjk5NSAzMzEwDQog IDE4MzJcblJlY29yZGluZyBQb2xpY3k6IFxuT25seSB0aGUgbWVldGluZyBob3N0IG9yIGRl c2lnbmF0ZWQgY28taG9zdA0KICBtYXkgcmVjb3JkIHRoaXMgbWVldGluZy4gVXRpbGl6aW5n IGFueSByZWNvcmRpbmcgY2FwYWJpbGl0eVwsIHdoZXRoZXINCiAgdGhyb3VnaCBab29tIG9y IGEgdGhpcmQtcGFydHkgaW50ZWdyYXRpb25cLCB3aXRob3V0IHRoZSBrbm93bGVkZ2UgYW5k DQogIGNvbnNlbnQgb2YgYWxsIG1lZXRpbmcgYXR0ZW5kZWVzXCwgbWF5IGNvbnN0aXR1dGUg YSBjcmltaW5hbCBvZmZlbnNlXCwNCiAgdW5kZXIgaW50ZXJuYXRpb25hbFwsIGZlZGVyYWxc LCBzdGF0ZSBvciBsb2NhbCBsYXdzIG9yIHJlZ3VsYXRpb25zLiBTdWNoDQogIHJlY29yZGlu ZyBhbHNvIGNvbnN0aXR1dGVzIGEgdmlvbGF0aW9uIG9mIEludHVpdCdzIEFjY2VwdGFibGUg VXNlDQogIFBvbGljeVwsIERhdGEgR292ZXJuYW5jZSBQcmluY2lwbGVzXCwgYW5kIG91ciBQ cml2YWN5IFBvbGljeSBcblxuIFxuDQpMT0NBVElPTjpodHRwczovL2ludHVpdC56b29tLnVz L2ovOTk1MzMxMDE4MzI/ZnJvbT1hZGRvbg0KT1JHQU5JWkVSOk1BSUxUTzpZYXJvbl9TaGVm ZmVyQGludHVpdC5jb20NClNFUVVFTkNFOjANCkFUVEVOREVFO1JPTEU9UkVRLVBBUlRJQ0lQ QU5UO1JTVlA9RkFMU0U7Q049IkdOQVAgTWFpbGluZw0KICBMaXN0IjtQQVJUU1RBVD1ORUVE Uy1BQ1RJT046TUFJTFRPOnR4YXV0aEBpZXRmLm9yZw0KWC1NSUNST1NPRlQtQ0RPLUJVU1lT VEFUVVM6QlVTWQ0KWC1NSUNST1NPRlQtQ0RPLUFMTERBWUVWRU5UOkZBTFNFDQpYLU1JQ1JP U09GVC1ESVNBTExPVy1DT1VOVEVSOkZBTFNFDQpYLU1JQ1JPU09GVC1ET05PVEZPUldBUkRN RUVUSU5HOkZBTFNFDQpYLU1JQ1JPU09GVC1DRE8tSU5TVFRZUEU6MA0KQkVHSU46VkFMQVJN DQpBQ1RJT046RElTUExBWQ0KREVTQ1JJUFRJT046UkVNSU5ERVINClRSSUdHRVI7UkVMQVRF RD1TVEFSVDotUFQwMEgxNU0wMFMNCkVORDpWQUxBUk0NCkVORDpWRVZFTlQNCkVORDpWQ0FM RU5EQVINCg== --B_3692825893_326702617-- From nobody Sun Jan 10 00:11:10 2021 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6555F3A0D06 for ; Sun, 10 Jan 2021 00:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.819 X-Spam-Level: X-Spam-Status: No, score=-2.819 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-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=hyoP6dcZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ffp7EC0R Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TsGgxIm6cNm for ; Sun, 10 Jan 2021 00:11:02 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B46693A0EB5 for ; Sun, 10 Jan 2021 00:11:02 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 657882700 for ; Sun, 10 Jan 2021 03:04:14 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 10 Jan 2021 03:04:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=hJez6wfV/dXRpVL20BhJ7lFD7+0tzLytl9O+miR7IBQ=; b=hyoP6dcZ S5RFYa2pF84zzUzjA6HWN1IrqZCdNFMRaG0+nQY6iqw3VVE5/RaNbxD71B6UEkeb oM5adTCRl+Ht+jgOm0CZ7n4RCSzpV/wWLmPI0qOsvMiFH+KZh5sktj7GEmlw4GFV qfgYbmFduhfPLUZQQuhPcicfYLdeFjAUu4P/w24+hWLwiMn6KiJCDT7sRrXsoqn5 eIkEd67SxoRb6/dmtaT5H1J4albLz9R9akMZB9BcG+TmuOHaE61/LRRWGiNSfQ+/ IJ3a1b7pTJtSUQhDCr5bP1iaK+tuEyVx5UeYE1JCsQjvgIqNV4k+tG7+HHtR3w3G d6zmzN8QWDaL4w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=hJez6wfV/dXRpVL20BhJ7lFD7+0tz Lytl9O+miR7IBQ=; b=ffp7EC0Rx/XasmNDKJWltOV6J9WxYveDU/YgVe4Gg844Y uUzRfyqD7cf5k91ebxz/woNDitp1rjAI0TYlkZUqP1UhTVPlDm3MWkJ3kZTffdLW NmHU9iJTEy0jBSs4A9PfMvDzjDBkh0CSelDVddj2oL0zPmxi408kI8VbyaqzXIbD PseZ/S5QuLgZOYPKTU2RB3mrrT33K9MOE4p5LOmsUQzLxT2D0oqwFr4XhtuexauM haCQCGXukVtPhp3T/qKVZH380ytlBOqTr9Tc0hRRnN2W5HPO/jbVMlGa9mb9swCv ALF1wYOryPhnVLYjdt6yEs3T5fqqqARPSDCl9yllw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdegkedgudduiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeehvddrvdegvddrledurd duhedvnecuvehluhhsthgvrhfuihiivgepheenucfrrghrrghmpehmrghilhhfrhhomhep ughopghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az184-39.internal.cloudapp.net (unknown [52.242.91.152]) by mail.messagingengine.com (Postfix) with ESMTPA id B7DA624005B for ; Sun, 10 Jan 2021 03:04:13 -0500 (EST) Content-Type: multipart/alternative; boundary="===============8086392129628113047==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20210110080413.B7DA624005B@mailuser.nyi.internal> Date: Sun, 10 Jan 2021 03:04:13 -0500 (EST) Archived-At: Subject: [GNAP] Weekly github digest (GNAP Weekly GitHub Activity Summary) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2021 08:11:05 -0000 --===============8086392129628113047== 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 (+0/-0/=F0=9F=92=AC1) 1 issues received 1 new comments: - #145 Non opaque access token (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145=20 Pull requests ------------- * ietf-wg-gnap/core-protocol (+3/-2/=F0=9F=92=AC3) 3 pull requests submitted: - move design team background to acknowledgements (by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/157=20 - Netlify testing (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/156=20 - update terminology (by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/155=20 2 pull requests received 3 new comments: - #155 update terminology (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/155=20 - #152 Refactor "key" section (2 by github-actions) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/152=20 2 pull requests merged: - move design team background to acknowledgements https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/157 [Editorial]= =20 - fix small bug about sub_ids in grant response https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/153 [Editorial]= =20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol --===============8086392129628113047== 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 January 10, 2021

Events without label "editorial"

Issues

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

1 issues received 1 new comments:

Pull requests

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

3 pull requests submitted:

2 pull requests received 3 new comments:

2 pull requests merged:

Repositories tracked by this digest:

--===============8086392129628113047==-- From nobody Mon Jan 11 07:27:03 2021 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07CF03A0EF2 for ; Mon, 11 Jan 2021 07:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.009, NICE_REPLY_A=-0.262, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 x3hyplsXFrXw for ; Mon, 11 Jan 2021 07:26:58 -0800 (PST) Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E4673A0EF3 for ; Mon, 11 Jan 2021 07:26:56 -0800 (PST) Received: from [192.168.1.11] ([90.79.54.243]) by mwinf5d62 with ME id FTSq2400M5Eqqlm03TSrKe; Mon, 11 Jan 2021 16:26:53 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Mon, 11 Jan 2021 16:26:53 +0100 X-ME-IP: 90.79.54.243 To: Fabien Imbault , GNAP Mailing List References: From: Denis Message-ID: Date: Mon, 11 Jan 2021 16:26:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------74425B63628D908F81F28F00" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Terminology PR 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, 11 Jan 2021 15:27:01 -0000 This is a multi-part message in MIME format. --------------74425B63628D908F81F28F00 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I have used the text of the wiki to respond. Latest discussion update Here we consolidate the latest proposal(s) from the group. We also include the discussion items (individual feedbacks). [Denis] I don't have the feeling that we are converging. There are duplications for some definitions that are spread over the document instead of being grouped together. This does not help to converge. We need to clearly separate the role of the "end-user" from the role of a RO. Attempting to collapse these two concepts under the term "user" creates confusion. Attempting to use the term "subject" creates even more confusion. Trying to incorporate design choices inside the definition section is not appropriate, hence why I propose to remove several notes. In my proposals below, I have followed the ISO style for the definitions (a single sentence as short as possible). Authorization Server (AS) server that grants delegated privileges to a particular instance of client software in the form of an access token and other information (such as subject information). [Denis] Authorization Server (AS):server that grants access privileges to a particular instance of a client software in the form of an access token and provides information about the end user Some explanations: In addition to the granting of access tokens, end-users may query the AS about the privileges they store about them. We should identify in the main body of the document thse two distinct operations. Client application operated by an end-user that consumes resources from one or several RSs, possibly requiring access privileges from one or several ASs. Example: a client can be a mobile application, a web application, etc. Note: this specification differentiates between a specific instance (the client instance, identified by its unique key) and the software running the instance (the client software). For some kinds of client software, there could be many instances of that software, each instance with a different key. [Denis] Change in the Note: (the client instance, identified by its unique key) into: (the client instance, identified by a unique key) Some explanations: The key is unique, but may change. Resource Server (RS) server that provides operations on protected resources, where operations require a valid access token issued by an AS. [Denis] Change into: Resource Server (RS) : server that provides operations on resources, where operations on protected resources require a valid access token issued by one or more ASs Some explanations: a resource server may also support resources available to the public. Resource Owner (RO) subject entity that may grant or deny operations on resources it has authority upon. Note: the act of granting or denying an operation may be manual (i.e. through an interaction with a physical person) or automatic (i.e. through predefined organizational rules). [Denis] Change into: Resource Owner (RO): /entity/that may grant or deny operations on resources it has authority upon Some explanations: the term "entity" (without the word "subject") is being used which is a very general term: it may or may not be a human being. End-user natural person that operates _/the/_//client instance. Note: that natural person may or may not be the same entity as the RO. When it is explicit that the end-user and the RO are the same entity, the generic term user may be used. [Denis] Change into: *End-user*: natural person that operates _/a/_ client instance Remove the Note which is confusing. Attribute characteristics related to a subject. [Denis] Change into: Attribute: characteristics related to an end-user Access Token a data artifact representing a set of rights and/or attributes. Note: an access token can be first issued to an client instance (requiring authorization by the RO) and subsequently rotated. [Denis] Remove the Note which has nothing to do in this section. Grant (verb): to permit an instance of client software to exercise some set of delegated rights to access a protected resource and/or to receive some attributes at a specific time and during a specific duration. (noun): the act of granting. [Denis] Change into: *Grant* (verb): to receive some attributes from an AS at a specific time and valid for a specific duration and/or to permit an instance of client software to exercise this attributes to perform an operation on a protected resource (noun): the act of granting Some explanations: The current text identifies two cases. I have switched these two cases. Privilege right or attribute associated with a subject. [Denis] *Privilege*: right or attribute associated with an end-user Note: the RO defines and maintains the rights and attributes associated to the protected resource, and might temporarily delegate some set of those privileges to an end-user. This process is refered to as privilege delegation. [Denis] Remove the Note which is unrelated to the definition. Protected Resource protected API (Application Programming Interface) served by a RS and that can be accessed by a client, if and only if a valid access token is provided. Note: to avoid complex sentences, the specification document may simply refer to resource instead of protected resource. Right ability given to /a subject/ to perform a given operation on a resource under the control of a RS. [Denis] Change into: *Right*: ability given to /an end-user/ to perform a given operation on a resource under the control of a RS Subject person, organization or device. [Denis] Remove this definition since this terms is confusing and unnecessary. Subject Information statement asserted locally by an AS about a subject. [Denis] Remove this definition since this terms is confusing and unnecessary. Current spec Here we find all the terms and definitions from the current version of the draft (01), as a reference. Roles Authorization Server (AS) Manages the requested delegations for the RO. The AS issues tokens and directly delegated information to the RC. The AS is defined by its grant endpoint, a single URL that accepts a POST request with a JSON payload. The AS could also have other endpoints, including interaction endpoints and user code endpoints, and these are introduced to the RC as needed during the delegation process. [Denis] Already discussed above (and far too long for a definition). Resource Client (RC, aka "client") Requests tokens from the AS and uses tokens at the RS. An instance of the RC software is identified by its key, which can be known to the AS prior to the first request. The AS determines which policies apply to a given RC, including what it can request and on whose behalf. ** ** [Denis] Already discussed above. Resource Server (RS, aka "API") Accepts tokens from the RC issued by the AS and serves delegated resources on behalf of the RO. There could be multiple RSs protected by the AS that the RC will call. [Denis] Already discussed above. Resource Owner (RO) Authorizes the request from the RC to the RS, often interactively at the AS. [Denis] Already discussed above. Requesting Party (RQ, aka "user") Operates and interacts with the RC. [Denis] Remove. Already discussed above under the term "*end-user" * *Elements* Access Token A credential representing a set of access rights delegated to the RC. The access token is created by the AS, consumed and verified by the RS, and issued to and carried by the RC. The contents and format of the access token are opaque to the RC. [Denis] Already discussed above. Grant The process by which the RC requests and is given delegated access to the RS by the AS through the authority of the RO. [Denis] Already discussed above. Cryptographic Key A cryptographic element binding a request to a holder of the key. Access tokens and RC instances can be associated with specific keys. [Denis] Change into: *Binding key*: a cryptographic key used by a client to bind an access token to a client instance Some explanations: cryptographic key is a general term. In the context of GNAP we want that key to achieve a specific function: to *bind *an access token to a client instance. Resource A protected API served by the RS and accessed by the RC. Access to this resource is delegated by the RO as part of the grant process. [Denis] We don't need this definition. Already discussed above under the wording" Protected Resource". Subject Information Information about the RO that is returned directly to the RC from the AS without the RC making a separate call to an RS. Access to this information is delegated by the RO as part of the grant process. [Denis] We don't need this definition. Some explanations: an end-user may wish to know the attributes stored for him by the AS. However, no information needs to be returned to a client about a RO. Denis > Hi everyone, > > I wish you all a happy new year. > > I just created a PR > (https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/155 > ) that > takes into account the various feedbacks. The automatic build process > is not working, but you can see the diffs and build the html locally > if you prefer. The definitions have also been updated on the wiki > (https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology > ) > if you prefer to check there. > > Feedbacks welcome before we move to pending merge later on. > > Cheers > Fabien > --------------74425B63628D908F81F28F00 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
I have used the text of the wiki to respond.

Latest discussion update

Here we consolidate the latest proposal(s) from the group. We also include the discussion items (individual feedbacks).

 

[Denis] I don't have the feeling that we are converging. There are duplications for some definitions that are spread over the document
instead of being grouped together. This does not help to converge.

 

We need to clearly separate the role of the "end-user" from the role of a RO. Attempting to collapse these two concepts under the term "user"
creates confusion. Attempting to use the term "subject" creates even more confusion.


Trying to incorporate design choices inside the definition section is not appropriate, hence why I propose to remove several notes.

 

In my proposals below, I have followed the ISO style for the definitions (a single sentence as short as possible).

 

Authorization Server (AS)

server that grants delegated privileges to a particular instance of client software in the form of an access token and other information (such as subject information).

 

[Denis]

Authorization Server (AS): server that grants access privileges to a particular instance of a client software in the form of an access token and provides information about the end user

Some explanations: In addition to the granting of access tokens, end-users may query the AS about the privileges they store about them.

We should identify in the main body of the document thse two distinct operations.

Client

application operated by an end-user that consumes resources from one or several RSs, possibly requiring access privileges from one or several ASs.

 

Example: a client can be a mobile application, a web application, etc.

 

Note: this specification differentiates between a specific instance (the client instance, identified by its unique key) and the software running the instance (the client software). For some kinds of client software, there could be many instances of that software, each instance with a different key.

 

[Denis] Change in the Note:

(the client instance, identified by its unique key)

into:

(the client instance, identified by a unique key)

Some explanations: The key is unique, but may change.

Resource Server (RS)

server that provides operations on protected resources, where operations require a valid access token issued by an AS.

 

[Denis] Change into: 

Resource Server (RS) : server that provides operations on resources, where operations on protected resources require
a valid access token issued by one or more ASs

 Some explanations: a resource server may also support resources available to the public.

 

Resource Owner (RO)

subject entity that may grant or deny operations on resources it has authority upon.

Note: the act of granting or denying an operation may be manual (i.e. through an interaction with a physical person) or automatic (i.e. through predefined organizational rules).

 

[Denis] Change into:

Resource Owner (RO):  entity that may grant or deny operations on resources it has authority upon

 Some explanations: the term "entity" (without the word "subject") is being used which is a very general term: it may or may not be a human being.

 

End-user

natural person that operates the client instance.

 

Note: that natural person may or may not be the same entity as the RO. When it is explicit that the end-user and the RO are the same entity, the generic term user may be used.

[Denis] 

Change into:

End-user: natural person that operates a client instance

Remove the Note which is confusing.

Attribute

characteristics related to a subject.

 

[Denis] Change into:

Attribute: characteristics related to an end-user

Access Token

a data artifact representing a set of rights and/or attributes.

 

Note: an access token can be first issued to an client instance (requiring authorization by the RO) and subsequently rotated.

 

[Denis] Remove the Note which has nothing to do in this section.

Grant

(verb): to permit an instance of client software to exercise some set of delegated rights to access a protected resource and/or
to receive some attributes at a specific time and during a specific duration. (noun): the act of granting.

 

[Denis] Change into:

Grant

 

(verb): to receive some attributes from an AS at a specific time and valid for a specific duration and/or
to permit an instance of client software to exercise this attributes to perform an operation on a protected resource

 

(noun): the act of granting

 Some explanations: The current text identifies two cases. I have switched these two cases.

Privilege

right or attribute associated with a subject.

 

[Denis]

Privilege: right or attribute associated with an end-user

 Note: the RO defines and maintains the rights and attributes associated to the protected resource, and might temporarily delegate

some set of those privileges to an end-user. This process is refered to as privilege delegation.

 

[Denis] Remove the Note which is unrelated to the definition.

 

Protected Resource

protected API (Application Programming Interface) served by a RS and that can be accessed by a client, if and only if a valid access token is provided.

 

Note: to avoid complex sentences, the specification document may simply refer to resource instead of protected resource.

Right

ability given to a subject to perform a given operation on a resource under the control of a RS.

 

[Denis] Change into:

Right: ability given to an end-user to perform a given operation on a resource under the control of a RS

Subject

person, organization or device.

 

[Denis] Remove this definition since this terms is confusing and unnecessary.

Subject Information

statement asserted locally by an AS about a subject.

 

[Denis] Remove this definition since this terms is confusing and unnecessary.

Current spec

Here we find all the terms and definitions from the current version of the draft (01), as a reference.

Roles

Authorization Server (AS)

Manages the requested delegations for the RO. The AS issues tokens and directly delegated information to the RC.
The AS is defined by its grant endpoint, a single URL that accepts a POST request with a JSON payload.
The AS could also have other endpoints, including interaction endpoints and user code endpoints, and these are introduced
to the RC as needed during the delegation process.

 

[Denis] Already discussed above (and far too long for a definition).

 

Resource Client (RC, aka "client")

Requests tokens from the AS and uses tokens at the RS. An instance of the RC software is identified by its key, which can be known
to the AS prior to the first request. The AS determines which policies apply to a given RC, including what it can request and on whose behalf.

 

[Denis] Already discussed above.

 

Resource Server (RS, aka "API")

Accepts tokens from the RC issued by the AS and serves delegated resources on behalf of the RO.
There could be multiple RSs protected by the AS that the RC will call.

 

[Denis] Already discussed above.

 

Resource Owner (RO)

Authorizes the request from the RC to the RS, often interactively at the AS.

 

[Denis] Already discussed above.

 

Requesting Party (RQ, aka "user")

Operates and interacts with the RC.

 

[Denis] Remove. Already discussed above under the term "end-user"

Elements

Access Token

A credential representing a set of access rights delegated to the RC. The access token is created by the AS, consumed and verified by the RS,
and issued to and carried by the RC. The contents and format of the access token are opaque to the RC.

 

[Denis] Already discussed above.

 

Grant

The process by which the RC requests and is given delegated access to the RS by the AS through the authority of the RO.

 

[Denis] Already discussed above.

 

Cryptographic Key

A cryptographic element binding a request to a holder of the key. Access tokens and RC instances can be associated with specific keys.

 

[Denis] Change into:

Binding key: a cryptographic key used by a client to bind an access token to a client instance

Some explanations: cryptographic key is a general term. In the context of GNAP we want that key to achieve a specific function:
to bind an access token to a client instance.

Resource

A protected API served by the RS and accessed by the RC. Access to this resource is delegated by the RO as part of the grant process.

 

[Denis] We don't need this definition. Already discussed above under the wording" Protected Resource".

 

Subject Information

Information about the RO that is returned directly to the RC from the AS without the RC making a separate call to an RS.
Access to this information is delegated by the RO as part of the grant process.

[Denis] We don't need this definition.

Some explanations: an end-user may wish to know the attributes stored for him by the AS.
However, no information needs to be returned to a client about a RO.

Denis

Hi everyone, 

I wish you all a happy new year.

I just created a PR (https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/155) that takes into account the various feedbacks. The automatic build process is not working, but you can see the diffs and build the html locally if you prefer. The definitions have also been updated on the wiki (https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology) if you prefer to check there. 

Feedbacks welcome before we move to pending merge later on.

Cheers
Fabien


--------------74425B63628D908F81F28F00-- From nobody Mon Jan 11 09:28:40 2021 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59CD3A10AA for ; Mon, 11 Jan 2021 09:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 QDfzIZzwCTLz for ; Mon, 11 Jan 2021 09:28:35 -0800 (PST) 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 A1CC53A10A7 for ; Mon, 11 Jan 2021 09:28:35 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id u26so407164iof.3 for ; Mon, 11 Jan 2021 09:28:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y8Fmeak/8Dg7xhHaShY8233MiUsDi3POuyq5HSDnT/A=; b=azeBqV8NDTOgbWvwnsKMZqKTV7DUAF8gdAsNpeRCznTPkGPBDcAi8m7FCXPmiJUBHm 1N9d3PPw73wRq+rMk5YjKUe9auGKSraAZwZ81eHtM1srgGnoO8TCfX1997EP4/lbhMKM PsXgfCx7/bDKWwpLxIRw6cJZPmLdDeIuECgYuTcYGnHHmNEt26Jn4ymVozk/Zxi0nnDG 0qc2sRBBe5+vTn1zkT0YRk275N4ITUM5gsW+2QEP7GzJrii1025L75Iws6VRLXMW/zLR 2EjMqKPJEm7hdIebHfqXEfYuHbMAHicXcGVmkKGjx26WSLIBZqUIJ5xQ6QYXE6yALNkT +raA== 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=Y8Fmeak/8Dg7xhHaShY8233MiUsDi3POuyq5HSDnT/A=; b=saGD9p/4JDICRJDjFJpN/gQc4NBuk7pKH4sOW6cR1UmNymTC2yHfcMz1oh12sXbAIX PlEHpNhqXVRllMN5imteyN+2m4IqsxatbbHmqiDd8+bnu+FVqANmzvJZxjKiIyox0tNk 91JF1Bwi42U9HQfXCOQ5CW+RK6FXG0LnvB2V+2uC/RYDxKUBpoBPr15ssAcBZAqSU5IG k5dqnUiMDkOzivaJ9C9idEgRzU0ZsvJwg+Pm8UjqYowZ/Aac2L1xhvyOd237kXZ9IxQO iN4sDrWL7HgjwPAYuRqBTJtIfjwqAumzTP84J39kr7mfwbdSew/Bg4TczpybZ7qJqEzE AHrg== X-Gm-Message-State: AOAM531Pr0RpJOG93IMLmNurnDxitmtE+VgPhfYAGsRXNrUA+ed2K0pe XPTpAgBDxwchDIwqVg6YlhQD58J9wmrJkarh5ro= X-Google-Smtp-Source: ABdhPJyt7MTryP5TTNMi593d9vCe/PXTJwBzQad5aHDvOCPCI+VpTsx3aP5l2qK63IPm22mMqqflBj1ur23Ci4aEq2A= X-Received: by 2002:a5e:a815:: with SMTP id c21mr231028ioa.141.1610386114808; Mon, 11 Jan 2021 09:28:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Mon, 11 Jan 2021 18:28:20 +0100 Message-ID: To: Denis Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000530ed605b8a33c12" Archived-At: Subject: Re: [GNAP] Terminology PR 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, 11 Jan 2021 17:28:39 -0000 --000000000000530ed605b8a33c12 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Denis, The part called "current spec" corresponds to the text before the PR, it's just here for reference. We made the distinction between the end-user and the RO as clear as we could. There is indeed a case where we still keep "user", to indicate that the RO=3Dend-user (and tried to make it clear in the text). I don't see an obvious way to change that. >From your comment I don't see why subject would be a problem. We indeed tried to avoid the embedding of requirements into the definitions= . The rest of my comments are embedded into your message, and marked with FI for convenience. Fabien Le lun. 11 janv. 2021 =C3=A0 16:27, Denis a =C3=A9crit= : > I have used the text of the wiki to respond. Latest discussion update > > Here we consolidate the latest proposal(s) from the group. We also includ= e > the discussion items (individual feedbacks). > > > > [Denis] I don't have the feeling that we are converging. There are > duplications for some definitions that are spread over the document > instead of being grouped together. This does not help to converge. > > > > We need to clearly separate the role of the "end-user" from the role of a > RO. Attempting to collapse these two concepts under the term "user" > creates confusion. Attempting to use the term "subject" creates even more > confusion. > > > Trying to incorporate design choices inside the definition section is not > appropriate, hence why I propose to remove several notes. > > > > In my proposals below, I have followed the ISO style for the definitions > (a single sentence as short as possible). > > > Authorization Server (AS) > > server that grants delegated privileges to a particular instance of clien= t > software in the form of an access token and other information (such as > subject information). > > > > [Denis] > > Authorization Server (AS): server that grants access privileges to a > particular instance of a client software in the form of an access token a= nd > provides information about the end user > > Some explanations: In addition to the granting of access tokens, end-user= s > may query the AS about the privileges they store about them. > > We should identify in the main body of the document thse two distinct > operations. > [FI] so far the type of additional information we would send is specified as subject information, hence its use in the definition. > Client > > application operated by an end-user that consumes resources from one or > several RSs, possibly requiring access privileges from one or several ASs= . > > > > Example: a client can be a mobile application, a web application, etc. > > > > Note: this specification differentiates between a specific instance (the > client instance, identified by its unique key) and the software running t= he > instance (the client software). For some kinds of client software, there > could be many instances of that software, each instance with a different > key. > > > > [Denis] Change in the Note: > > (the client instance, identified by its unique key) > > into: > > (the client instance, identified by a unique key) > > Some explanations: The key is unique, but may change. > [FI] not sure that your proposal changes much the meaning (at any point in time, its key is unique, and yes, it may be changed over time) > Resource Server (RS) > > server that provides operations on protected resources, where operations > require a valid access token issued by an AS. > > > > [Denis] Change into: > > Resource Server (RS) : server that provides operations on resources, > where operations on protected resources require > a valid access token issued by one or more ASs > > Some explanations: a resource server may also support resources > available to the public. > > > [FI] yes, but we don't really care about public resources (there's no need for a protocol for that). As for "one or more ASs", this seems to embed a requirement (support multiplicity). > Resource Owner (RO) > > subject entity that may grant or deny operations on resources it has > authority upon. > > Note: the act of granting or denying an operation may be manual (i.e. > through an interaction with a physical person) or automatic (i.e. through > predefined organizational rules). > > > > [Denis] Change into: > > Resource Owner (RO): *entity* that may grant or deny operations on > resources it has authority upon > > Some explanations: the term "entity" (without the word "subject") is > being used which is a very general term: it may or may not be a human bei= ng. > > > [FI] subject is defined as either human or not. > End-user > > natural person that operates *the* client instance. > > > > Note: that natural person may or may not be the same entity as the RO. > When it is explicit that the end-user and the RO are the same entity, the > generic term user may be used. > [Denis] Change into: > > *End-user*: natural person that operates *a* client instance > > Remove the Note which is confusing. > [FI] "a" might indeed be better. Regarding the note, it seems that you'd rather not have "user" (and the rest is still useful I think). This is actually used in other parts of the spec (cf diagrams) to refer to either RO or end-user, undistinctively. What would you use otherwise? > Attribute > > characteristics related to a subject. > > > > [Denis] Change into: > > Attribute: characteristics related to an end-user > > [FI] are we 100% sure we'll never send anything else? > Access Token > > a data artifact representing a set of rights and/or attributes. > > > > Note: an access token can be first issued to an client instance (requirin= g > authorization by the RO) and subsequently rotated. > > > > [Denis] Remove the Note which has nothing to do in this section. > [FI] the note serves the purpose of explaining the lifecycle of an access token, which I believe is useful to the reader. Cf the large litt=C3=A9ratu= re about access vs refresh in the oauth2 world. > Grant > > (verb): to permit an instance of client software to exercise some set of > delegated rights to access a protected resource and/or > to receive some attributes at a specific time and during a specific > duration. (noun): the act of granting. > > > > [Denis] Change into: > > *Grant* > > > > (verb): to receive some attributes from an AS at a specific time and vali= d > for a specific duration and/or > to permit an instance of client software to exercise this attributes to > perform an operation on a protected resource > > > > (noun): the act of granting > > Some explanations: The current text identifies two cases. I have > switched these two cases. > [FI] how is that better? > Privilege > > right or attribute associated with a subject. > > > > [Denis] > > *Privilege*: right or attribute associated with an end-user > > Note: the RO defines and maintains the rights and attributes associated > to the protected resource, and might temporarily delegate > > some set of those privileges to an end-user. This process is refered to a= s > privilege delegation. > > > > [Denis] Remove the Note which is unrelated to the definition. > [FI] this is useful to understand what we call "delegated privileges" in the AS definition. > > Protected Resource > > protected API (Application Programming Interface) served by a RS and that > can be accessed by a client, if and only if a valid access token is > provided. > > > > Note: to avoid complex sentences, the specification document may simply > refer to resource instead of protected resource. > Right > > ability given to *a subject* to perform a given operation on a resource > under the control of a RS. > > > > [Denis] Change into: > > *Right*: ability given to *an end-user* to perform a given operation on a > resource under the control of a RS > > [FI] it's not rights about the end-user per say, it's rights delegated by the RO. And so in this context, subject seems a better description and avoids the potential misunderstanding. And least that's the intent. > Subject > > person, organization or device. > > > > [Denis] Remove this definition since this terms is confusing and > unnecessary. > [FI] I'm not sure what is confusing. This is useful at the bare minimum in context with the next definition. I think it can be used as a basic definition for other terms, and that's what is proposed. > Subject Information > > statement asserted locally by an AS about a subject. > > > > [Denis] Remove this definition since this terms is confusing and > unnecessary. > [FI] this is used in the main text, so needs to be defined (or removed from the main text, but that's a different debate). > Current spec > > Here we find all the terms and definitions from the current version of th= e > draft (01), as a reference. > Roles Authorization Server (AS) > > Manages the requested delegations for the RO. The AS issues tokens and > directly delegated information to the RC. > The AS is defined by its grant endpoint, a single URL that accepts a POST > request with a JSON payload. > The AS could also have other endpoints, including interaction endpoints > and user code endpoints, and these are introduced > to the RC as needed during the delegation process. > > > > [Denis] Already discussed above (and far too long for a definition). > > > Resource Client (RC, aka "client") > > Requests tokens from the AS and uses tokens at the RS. An instance of the > RC software is identified by its key, which can be known > to the AS prior to the first request. The AS determines which policies > apply to a given RC, including what it can request and on whose behalf. > > > > [Denis] Already discussed above. > > > Resource Server (RS, aka "API") > > Accepts tokens from the RC issued by the AS and serves delegated resource= s > on behalf of the RO. > There could be multiple RSs protected by the AS that the RC will call. > > > > [Denis] Already discussed above. > > > Resource Owner (RO) > > Authorizes the request from the RC to the RS, often interactively at the > AS. > > > > [Denis] Already discussed above. > > > Requesting Party (RQ, aka "user") > > Operates and interacts with the RC. > > > > [Denis] Remove. Already discussed above under the term " > > *end-user" * > > *Elements* > Access Token > > A credential representing a set of access rights delegated to the RC. The > access token is created by the AS, consumed and verified by the RS, > and issued to and carried by the RC. The contents and format of the acces= s > token are opaque to the RC. > > > > [Denis] Already discussed above. > > > Grant > > The process by which the RC requests and is given delegated access to the > RS by the AS through the authority of the RO. > > > > [Denis] Already discussed above. > > > Cryptographic Key > > A cryptographic element binding a request to a holder of the key. Access > tokens and RC instances can be associated with specific keys. > > > > [Denis] Change into: > > *Binding key*: a cryptographic key used by a client to bind an access > token to a client instance > > Some explanations: cryptographic key is a general term. In the context of > GNAP we want that key to achieve a specific function: > to *bind *an access token to a client instance. > Resource > > A protected API served by the RS and accessed by the RC. Access to this > resource is delegated by the RO as part of the grant process. > > > > [Denis] We don't need this definition. Already discussed above under the > wording" Protected Resource". > > > Subject Information > > Information about the RO that is returned directly to the RC from the AS > without the RC making a separate call to an RS. > Access to this information is delegated by the RO as part of the grant > process. > > [Denis] We don't need this definition. > > Some explanations: an end-user may wish to know the attributes stored for > him by the AS. > However, no information needs to be returned to a client about a RO. > Denis > > Hi everyone, > > I wish you all a happy new year. > > I just created a PR ( > https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/155) that takes > into account the various feedbacks. The automatic build process is not > working, but you can see the diffs and build the html locally if you > prefer. The definitions have also been updated on the wiki ( > https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology) if > you prefer to check there. > > Feedbacks welcome before we move to pending merge later on. > > Cheers > Fabien > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000530ed605b8a33c12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Denis,

The part called "current spec" corresponds to the text before th= e PR, it's just here for reference.=C2=A0

We made the distinction between the end-user and the = RO as clear as we could.=C2=A0
There is indeed a cas= e where we still keep "user", to indicate that the RO=3Dend-user = (and tried to make it clear in the text). I don't see an obvious way to= change that.=C2=A0

From= your comment I don't see why subject would be a problem.=C2=A0

We indeed tried to avoid the em= bedding of requirements into the definitions.

The rest of my comments are embedded into your messag= e, and marked with FI for convenience.=C2=A0

Fabien


Le lun. 11 janv. 2021 =C3=A0 16= :27, Denis <denis.ietf@free.fr= > a =C3=A9crit=C2=A0:
=20 =20 =20
= I have used the text of the wiki to respond.

Latest discussion update

Here we consolidate the latest proposal(s) from the group. We also include the discussion items (individual feedbacks).

=C2=A0

[Denis] I don't have the feeling that we are converging. There are duplications for some definitions that are spread over the document
instead of being grouped together. This does not help to converge.

=C2=A0

We need to clearly separate the role of the "end-user" from the role of a RO. Attempting to collapse these two concepts under the term "user"
creates confusion. Attempting to use the term "subject" creates even more confusion.


Trying to incorporate design choices inside the definition section is not appropriate, hence why I propose to remove several notes.

=C2=A0

In my proposals below, I have followed the ISO style for the definitions (a single sentence as short as possible).

=C2=A0

Authorization Server (AS)

server that grants delegated privileges to a particular instance of client software in the form of an access token and other information (such as subject information).

=C2=A0

[Denis]

Authorization Server (AS): server that grants access privileges to a particular instance of a client software in the form of an access token and provides information about the end user

Some explanations: In addition to the granting of access tokens, end-users may query the AS about the privileges they store about them.

We should identify in the main body of the document thse two distinct operations.


[FI] so far the type of addition= al information we would send is specified as subject information, hence its= use in the definition.=C2=A0
=

Client

application operated by an end-user that consumes resources from one or several RSs, possibly requiring access privileges from one or several ASs.

=C2=A0

Example: a client can be a mobile application, a web application, etc.

=C2=A0

Note: this specification differentiates between a specific instance (the client instance, identified by its unique key) and the software running the instance (the client software). For some kinds of client software, there could be many instances of that software, each instance with a different key.

=C2=A0

[Denis] Change in the Note:

(the client instance, identified by its unique key)

into:

(the client instance, identified by a unique key)

Some explanations: The key is unique, but may change.


[FI] not sure that your proposal chan= ges much the meaning (at any point in time, its key is unique, and yes, it = may be changed over time)

Resource Server (RS)

server that provides operations on protected resources, where operations require a valid access token issued by an AS.

=C2=A0

[Denis] Change into:=C2=A0

Resource Server (RS)= : server that provides operations on resources, where operations on protected resources require
a valid access token issued by one or more ASs<= /p>

=C2=A0Some explanations: a resource server may also support resources available to the public.

=C2=A0

<= div dir=3D"auto">[FI] yes, but we don't really care about public resour= ces (there's no need for a protocol for that). As for "one or more= ASs", this seems to embed a requirement (support multiplicity).=C2=A0=
Resource Owner (RO)

subject entity that may grant or deny operations on resources it has authority upon.

Note: the act of granting or denying an operation may be manual (i.e. through an interaction with a physical person) or automatic (i.e. through predefined organizational rules).<= /p>

=C2=A0

[Denis] Change into:

Resource Owner (RO)<= /span>:=C2=A0 entity that may grant or deny operations on resources it has authority upon

=C2=A0Some explanations: the term "entity" (without the word "subject") is bein= g used which is a very general term: it may or may not be a human being.

=C2=A0

<= div dir=3D"auto">[FI] subject is defined as either human or not.=C2=A0

End-user

natural person that operates the client instance.

=C2=A0

Note: that natural person may or may not be the same entity as the RO. When it is explicit that the end-user and the RO are the same entity, the generic term user may be used.

[Denis]=C2=A0<= span style=3D"font-size:12.0pt;font-family:Arial;color:blue;font-weight:nor= mal" lang=3D"EN-US">

Change into:

End-user: natural person that operates a client instance

Remove the Note which is confusing.

<= /div>

[FI] "a" might= indeed be better.
Regarding the note, it seems that= you'd rather not have "user" (and the rest is still useful I= think). This is actually used in other parts of the spec (cf diagrams) to = refer to either RO or end-user, undistinctively. What would you use otherwi= se?=C2=A0

Attribute

characteristics related to a subject.

=C2=A0

[Denis] Change into:

Attribute: characteristics related to an end-user

[FI] are we 100% s= ure we'll never send anything else?=C2=A0

Access Token

a data artifact representing a set of rights and/or attributes.

=C2=A0

Note: an access token can be first issued to an client instance (requiring authorization by the RO) and subsequently rotated.

=C2=A0

[Denis] Remove the Note which has nothing to do in this section.


[FI] the note serves the purpose of expla= ining the lifecycle of an access token, which I believe is useful to the re= ader. Cf the large litt=C3=A9rature about access vs refresh in the oauth2 w= orld.=C2=A0

Grant

(verb): to permit an instance of client software to exercise some set of delegated rights to access a protected resource and/or
to receive some attributes at a specific time and during a specific duration. (noun): the act of granting.

=C2=A0

[Denis] Change into:

Grant

=C2=A0

(verb): to receive some attributes from an AS at a specific time and valid for a specific duration and/or
to permit an instance of client software to exercise this attributes to perform an operation on a protected resource

=C2=A0

(noun): the act of granting

=C2=A0Some explanations: The current text identifies two cases. I have switched these two cases.


[FI] how is that better?=C2=A0

Privilege

right or attribute associated with a subject.

=C2=A0

[Denis]

Privilege: right or attribute associated with an end-user

=C2=A0Note: the RO defines and maintains the rights and attributes associated to the protected resource, and might temporarily delegate

some set of those privileges to an end-user. This process is refered to as privilege delegation.

=C2=A0

[Denis] Remove the Note which is unrelated to the definition.

<= /div>

[FI] this is useful to u= nderstand what we call "delegated privileges" in the AS definitio= n.=C2=A0

=C2=A0

Protected Resource

protected API (Application Programming Interface) served by a RS and that can be accessed by a client, if and only if a valid access token is provided.

=C2=A0

Note: to avoid complex sentences, the specification document may simply refer to resource instead of protected resource.

Right

ability given to a subject to perform a given operation on a resource under the control of a RS.

=C2=A0

[Denis] Change into:

Right: ability given to an end-user to perform a given operation on a resource under the control of a RS


[FI] it's not = rights about the end-user per say, it's rights delegated by the RO. And= so in this context, subject seems a better description and avoids the pote= ntial misunderstanding. And least that's the intent.=C2=A0
<= blockquote>

Subject

person, organization or device.

=C2=A0

[Denis] Remove this definition since this terms is confusing and unnecessary.


[FI] I'm= not sure what is confusing. This is useful at the bare minimum in context = with the next definition.=C2=A0
I think it can be us= ed as a basic definition for other terms, and that's what is proposed.= =C2=A0

Subject Information

statement asserted locally by an AS about a subject.

=C2=A0

[Denis] Remove this definition since this terms is confusing and unnecessary.


[FI] this is= used in the main text, so needs to be defined (or removed from the main te= xt, but that's a different debate).=C2=A0

Current spec

Here we find all the terms and definitions from the current version of the draft (01), as a reference.

Roles

Authorization Server (AS)

Manages the requested delegations for the RO. The AS issues tokens and directly delegated information to the RC.
The AS is defined by its grant endpoint, a single URL that accepts a POST request with a JSON payload.
The AS could also have other endpoints, including interaction endpoints and user code endpoints, and these are introduced
to the RC as needed during the delegation process.

=C2=A0

[Denis] Already discussed above (and far too long for a definition).

=C2=A0

Resource Client (RC, aka "client")

Requests tokens from the AS and uses tokens at the RS. An instance of the RC software is identified by its key, which can be known
to the AS prior to the first request. The AS determines which policies apply to a given RC, including what it can request and on whose behalf.

=C2=A0

[Denis] Already discussed= above.

=C2=A0

Resource Server (RS, aka "API")

Accepts tokens from the RC issued by the AS and serves delegated resources on behalf of the RO.
There could be multiple RSs protected by the AS that the RC will call.

=C2=A0

[Denis] Already discussed= above.

=C2=A0

Resource Owner (RO)

Authorizes the request from the RC to the RS, often interactively at the AS.

=C2=A0

[Denis] Already discussed above.

=C2=A0

Requesting Party (RQ, aka "user")

Operates and interacts with the RC.

=C2=A0

[Denis] Remove. Alre= ady discussed above under the term "end-user"

Elements

Access Token

A credential representing a set of access rights delegated to the RC. The access token is created by the AS, consumed and verified by the RS,
and issued to and carried by the RC. The contents and format of the access token are opaque to the RC.

=C2=A0

[Denis] Already discussed above.

=C2=A0

Grant

The process by which the RC requests and is given delegated access to the RS by the AS through the authority of the RO.

=C2=A0

[Denis] Already discussed above.

=C2=A0

Cryptographic Key

A cryptographic element binding a request to a holder of the key. Access tokens and RC instances can be associated with specific keys.

=C2=A0

[Denis] Change into:

Binding key: a cryptographic key used by a client to bind an access token to a client instance=

Some explanations: cryptographic key is a general term. In the context of GNAP we want that key to achieve a specific function:
to bind an access token to a client instance.

Resource

A protected API served by the RS and accessed by the RC. Access to this resource is delegated by the RO as part of the grant process.

=C2=A0

[Denis] We don't need this definition. Already discussed above under the wording" Protected Resource".

=C2=A0

Subject Information

Information about the RO that is returned directly to the RC from the AS without the RC making a separate call to an RS.
Access to this information is delegated by the RO as part of the grant process.

[Denis] We don't need this definition.

Some explanations: an end-user may wish to know the attributes stored for him by the AS.
However, no information needs to be returned to a client about a RO.

Denis

=20
Hi everyone,=C2=A0

I wish you all a happy new year.

I just created a PR (https:/= /github.com/ietf-wg-gnap/gnap-core-protocol/pull/155) that takes into account the various feedbacks. The automatic build process is not working, but you can see the diffs and build the html locally if you prefer. The definitions have also been updated on the wiki (https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology= ) if you prefer to check there.=C2=A0

Feedbacks welcome before we move to pending merge later on.

Cheers
Fabien


--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--000000000000530ed605b8a33c12-- From nobody Tue Jan 12 07:29:30 2021 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B723A03F8 for ; Tue, 12 Jan 2021 07:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.009, NICE_REPLY_A=-0.262, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ny3RA1znF0ZP for ; Tue, 12 Jan 2021 07:29:17 -0800 (PST) Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8B423A03EB for ; Tue, 12 Jan 2021 07:29:15 -0800 (PST) Received: from [192.168.1.11] ([90.79.54.243]) by mwinf5d40 with ME id FrVR2400T5Eqqlm03rVSpx; Tue, 12 Jan 2021 16:29:27 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Tue, 12 Jan 2021 16:29:27 +0100 X-ME-IP: 90.79.54.243 To: Fabien Imbault Cc: GNAP Mailing List References: From: Denis Message-ID: Date: Tue, 12 Jan 2021 16:29:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E71063FD73426280BCA3C531" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Terminology PR X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2021 15:29:21 -0000 This is a multi-part message in MIME format. --------------E71063FD73426280BCA3C531 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello Fabien, The end-user and the RO are two roles. The case where (as you write) RO=end-user does not exist. The case where these two roles are supported by the same entity may exist. Since the document is supposed to describe operations between roles, I don't see the need to use a specific vocabulary for that specific case. Other comments are below. One of them attempts to explain (in a Note 2), the relationship between a RO and an end-user > Hello Denis, > > The part called "current spec" corresponds to the text before the PR, > it's just here for reference. > > We made the distinction between the end-user and the RO as clear as we > could. > There is indeed a case where we still keep "user", to indicate that > the RO=end-user (and tried to make it clear in the text). I don't see > an obvious way to change that. > > From your comment I don't see why subject would be a problem. > > We indeed tried to avoid the embedding of requirements into the > definitions. > > The rest of my comments are embedded into your message, and marked > with FI for convenience. > > Fabien > > > Le lun. 11 janv. 2021 à 16:27, Denis > a écrit : > I have used the text of the wiki to respond. > > > Latest discussion update > > Here we consolidate the latest proposal(s) from the group. We also > include the discussion items (individual feedbacks). > > [Denis] I don't have the feeling that we are converging. There are > duplications for some definitions that are spread over the document > instead of being grouped together. This does not help to converge. > > We need to clearly separate the role of the "end-user" from the > role of a RO. Attempting to collapse these two concepts under the > term "user" > creates confusion. Attempting to use the term "subject" creates > even more confusion. > > > Trying to incorporate design choices inside the definition section > is not appropriate, hence why I propose to remove several notes. > > In my proposals below, I have followed the ISO style for the > definitions (a single sentence as short as possible). > > > Authorization Server (AS) > > server that grants delegated privileges to a particular instance > of client software in the form of an access token and other > information (such as subject information). > > [Denis] > > Authorization Server (AS):server that grants access privileges > to a particular instance of a client software in the form of > an access token and provides information about the end user > > Some explanations: In addition to the granting of access tokens, > end-users may query the AS about the privileges they store about > them. > > We should identify in the main body of the document thse two > distinct operations. > > > [FI] so far the type of additional information we would send is > specified as subject information, hence its use in the definition. [Denis] Since a subject is currently defined in the draft as "person, organization or device", I don't believe that an AS "grants other other information (such as subject information)" because it does not manage organizations nor devices. In the context of an AS, the AS only manages end-user information hence why it is unnecessary to introduce the term "subject". > > > Client > > application operated by an end-user that consumes resources from > one or several RSs, possibly requiring access privileges from one > or several ASs. > > Example: a client can be a mobile application, a web application, > etc. > > Note: this specification differentiates between a specific > instance (the client instance, identified by its unique key) and > the software running the instance (the client software). For some > kinds of client software, there could be many instances of that > software, each instance with a different key. > > [Denis] Change in the Note: > > (the client instance, identified by its unique key) > > into: > > (the client instance, identified by a unique key) > > Some explanations: The key is unique, but may change. > > > [FI] not sure that your proposal changes much the meaning (at any > point in time, its key is unique, and yes, it may be changed over time). [Denis] It does change it. Since it seems you can live with that change, this is fine. > > > Resource Server (RS) > > server that provides operations on protected resources, where > operations require a valid access token issued by an AS. > > [Denis] Change into: > > Resource Server (RS) : server that provides operations on > resources, where operations on protected resources require > a valid access token issued by one or more ASs > > Some explanations: a resource server may also support resources > available to the public. > > [FI] yes, but we don't really care about public resources (there's no > need for a protocol for that). As for "one or more ASs", this seems to > embed a requirement (support multiplicity). [Denis] A RS may support both public and private resources. At the time an operation is performed by a client on a resource,             it is unknown whether that operation is allowed for the public or not. > > Resource Owner (RO) > > subject entity that may grant or deny operations on resources it > has authority upon. > > Note: the act of granting or denying an operation may be manual > (i.e. through an interaction with a physical person) or automatic > (i.e. through predefined organizational rules). > > [Denis] Change into: > > Resource Owner (RO): /entity/that may grant or deny operations > on resources it has authority upon > > Some explanations: the term "entity" (without the word "subject") > is being used which is a very general term: it may or may not be a > human being. > > [FI] subject is defined as either human or not. [Denis] No, a subject is currently defined in the draft as "person, organization or device". We don't need to use the term "subject". > > End-user > > natural person that operates _/the/_//client instance. > > Note: that natural person may or may not be the same entity as the > RO. When it is explicit that the end-user and the RO are the same > entity, the generic term user may be used. > > > [Denis] > > > Change into: > > > *End-user*: natural person that operates _/a/_ client instance > > Remove the Note which is confusing. > > > [FI] "a" might indeed be better. [Denis] Thanks ! > Regarding the note, it seems that you'd rather not have "user" (and > the rest is still useful I think). > This is actually used in other parts of the spec (cf diagrams) to > refer to either RO or end-user, undistinctively. What would you use > otherwise? [Denis] The Note should be removed because it leads to confusion. The Note considers only the case where the RO is a natural person, however a RO may also be a process. The Note may be adequate when the RO is being defined. In such a case, I would propose: Resource Owner (RO): /entity/ that may grant or deny operations on resources it has authority upon Note 1: The act of granting or denying an operation may be automatic (i.e. through predefined rules) or manual (i.e. through an interaction with a physical person).. Note 2: In the later case, the same physical person may support simultaneously the role of the RO and the role of the end-user. > > Attribute > > characteristics related to a subject. > > [Denis] Change into: > > Attribute: characteristics related to an end-user > > [FI] are we 100% sure we'll never send anything else? [Denis] See the discussion above for the reason for not using the term "subject". > > Access Token > > a data artifact representing a set of rights and/or attributes. > > Note: an access token can be first issued to an client instance > (requiring authorization by the RO) and subsequently rotated. > > [Denis] Remove the Note which has nothing to do in this section. > > > [FI] the note serves the purpose of explaining the lifecycle of an > access token, which I believe is useful to the reader. Cf the large > littérature about access vs refresh in the oauth2 world. [Denis] We are in the definition section. Explaining the lifecycle of an access token may indeed be very useful             but a dedicated section in the main body of the document would much better address this topic. > > Grant > > (verb): to permit an instance of client software to exercise some > set of delegated rights to access a protected resource and/or > to receive some attributes at a specific time and during a > specific duration. (noun): the act of granting. > > [Denis] Change into: > > *Grant* > > (verb): to receive some attributes from an AS at a specific > time and valid for a specific duration and/or > to permit an instance of client software to exercise this > attributes to perform an operation on a protected resource > > (noun): the act of granting > > Some explanations: The current text identifies two cases. I have > switched these two cases. > > > [FI] how is that better? [Denis] Before being able to use an access token, it is necessary to get it. So the proposed definition follows a chronological order. > Privilege > > right or attribute associated with a subject. > > [Denis] > > *Privilege*: right or attribute associated with an end-user > > Note: the RO defines and maintains the rights and attributes > associated to the protected resource, and might temporarily delegate > > some set of those privileges to an end-user. This process is > refered to as privilege delegation. > > [Denis] Remove the Note which is unrelated to the definition. > > > [FI] this is useful to understand what we call "delegated privileges" > in the AS definition. [Denis] Reading the original proposed definition again, the Note considers the RO. I consider that a right is a capability to perform an operation on a protected resource. Such capabilities is given by a RO to an end-user. I consider that an attribute is a characteristics related to an end-user (e.g. a name, a group membership) Privilege = right or attribute associated with an end-user which allows to support respectively                               either a capability scheme or an attributed-based access control (ABAC) using ACLs. A RO maintains rights but it does not maintain attributes. It might be useful to define in addition: *control attributes*: set of attributes associated to a protected resource used to control operations on that resource Note: a RO defines and maintains the control attributes associated to a protected resource > Protected Resource > > protected API (Application Programming Interface) served by a RS > and that can be accessed by a client, if and only if a valid > access token is provided. > > Note: to avoid complex sentences, the specification document may > simply refer to resource instead of protected resource. > > > Right > > ability given to /a subject/ to perform a given operation on a > resource under the control of a RS. > > [Denis] Change into: > > *Right*: ability given to /an end-user/ to perform a given > operation on a resource under the control of a RS > > > [FI] it's not rights about the end-user per say, it's rights delegated > by the RO. > And so in this context, subject seems a better description and avoids > the potential misunderstanding. And least that's the intent. [Denis]  A right is not given to an organization or to a device, but only to an end-user. > > Subject > > person, organization or device. > > [Denis] Remove this definition since this terms is confusing and > unnecessary. > > > [FI] I'm not sure what is confusing. This is useful at the bare > minimum in context with the next definition. > I think it can be used as a basic definition for other terms, and > that's what is proposed. [Denis] See the arguments raised above. > > Subject Information > > statement asserted locally by an AS about a subject. > > [Denis] Remove this definition since this terms is confusing and > unnecessary. > > > [FI] this is used in the main text, so needs to be defined (or removed > from the main text, but that's a different debate). [Denis] See the arguments raised above. > > Current spec > > Here we find all the terms and definitions from the current > version of the draft (01), as a reference. > > > Roles > > > Authorization Server (AS) > > Manages the requested delegations for the RO. The AS issues tokens > and directly delegated information to the RC. > The AS is defined by its grant endpoint, a single URL that accepts > a POST request with a JSON payload. > The AS could also have other endpoints, including interaction > endpoints and user code endpoints, and these are introduced > to the RC as needed during the delegation process. > > [Denis] Already discussed above (and far too long for a definition). > > > Resource Client (RC, aka "client") > > Requests tokens from the AS and uses tokens at the RS. An instance > of the RC software is identified by its key, which can be known > to the AS prior to the first request. The AS determines which > policies apply to a given RC, including what it can request and on > whose behalf. > > ** > > ** > > [Denis] Already discussed above. > > > Resource Server (RS, aka "API") > > Accepts tokens from the RC issued by the AS and serves delegated > resources on behalf of the RO. > There could be multiple RSs protected by the AS that the RC will call. > > [Denis] Already discussed above. > > > Resource Owner (RO) > > Authorizes the request from the RC to the RS, often interactively > at the AS. > > [Denis] Already discussed above. > > > Requesting Party (RQ, aka "user") > > Operates and interacts with the RC. > > [Denis] Remove. Already discussed above under the term "*end-user" > > * > > *Elements* > > > Access Token > > A credential representing a set of access rights delegated to the > RC. The access token is created by the AS, consumed and verified > by the RS, > and issued to and carried by the RC. The contents and format of > the access token are opaque to the RC. > > [Denis] Already discussed above. > > > Grant > > The process by which the RC requests and is given delegated access > to the RS by the AS through the authority of the RO. > > [Denis] Already discussed above. > > > Cryptographic Key > > A cryptographic element binding a request to a holder of the key. > Access tokens and RC instances can be associated with specific keys. > > [Denis] Change into: > > *Binding key*: a cryptographic key used by a client to bind an > access token to a client instance > > Some explanations: cryptographic key is a general term. In the > context of GNAP we want that key to achieve a specific function: > to *bind *an access token to a client instance. > > > Resource > > A protected API served by the RS and accessed by the RC. Access to > this resource is delegated by the RO as part of the grant process. > > [Denis] We don't need this definition. Already discussed above > under the wording" Protected Resource". > > > Subject Information > > Information about the RO that is returned directly to the RC from > the AS without the RC making a separate call to an RS. > Access to this information is delegated by the RO as part of the > grant process. > > [Denis] We don't need this definition. > > Some explanations: an end-user may wish to know the attributes > stored for him by the AS. > However, no information needs to be returned to a client about a RO. > Denis > Denis > >> Hi everyone, >> >> I wish you all a happy new year. >> >> I just created a PR >> (https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/155 >> ) >> that takes into account the various feedbacks. The automatic >> build process is not working, but you can see the diffs and build >> the html locally if you prefer. The definitions have also been >> updated on the wiki >> (https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology >> ) >> if you prefer to check there. >> >> Feedbacks welcome before we move to pending merge later on. >> >> Cheers >> Fabien >> > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > --------------E71063FD73426280BCA3C531 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hello Fabien,

The end-user and the RO are two roles.
The case where (as you write) RO=end-user does not exist. The case where these two roles are supported by the same entity may exist.
Since the document is supposed to describe operations between roles, I don't see the need to use a specific vocabulary for that specific case.
Other comments are below. One of them attempts to explain (in a Note 2), the relationship between a RO and an end-user


I have used the text of the wiki to respond.

Latest discussion update

Here we consolidate the latest proposal(s) from the group. We also include the discussion items (individual feedbacks).

 

[Denis] I don't have the feeling that we are converging. There are duplications for some definitions that are spread over the document
instead of being grouped together. This does not help to converge.

 

We need to clearly separate the role of the "end-user" from the role of a RO. Attempting to collapse these two concepts under the term "user"
creates confusion. Attempting to use the term "subject" creates even more confusion.


Trying to incorporate design choices inside the definition section is not appropriate, hence why I propose to remove several notes.

 

In my proposals below, I have followed the ISO style for the definitions (a single sentence as short as possible).

 

Authorization Server (AS)

server that grants delegated privileges to a particular instance of client software in the form of an access token and other information (such as subject information).

 

[Denis]

Authorization Server (AS): server that grants access privileges to a particular instance of a client software in the form of an access token and provides information about the end user

Some explanations: In addition to the granting of access tokens, end-users may query the AS about the privileges they store about them.

We should identify in the main body of the document thse two distinct operations.


[FI] so far the type of additional information we would send is specified as subject information, hence its use in the definition.
[Denis] Since a subject is currently defined in the draft as "person, organization or device", I don't believe that an AS "grants other other information
(such as subject information)" because it does not manage organizations nor devices. In the context of an AS, the AS only manages end-user information
hence why it is unnecessary to introduce the term "subject".

Client

application operated by an end-user that consumes resources from one or several RSs, possibly requiring access privileges from one or several ASs.

 

Example: a client can be a mobile application, a web application, etc.

 

Note: this specification differentiates between a specific instance (the client instance, identified by its unique key) and the software running the instance (the client software). For some kinds of client software, there could be many instances of that software, each instance with a different key.

 

[Denis] Change in the Note:

(the client instance, identified by its unique key)

into:

(the client instance, identified by a unique key)

Some explanations: The key is unique, but may change.


[FI] not sure that your proposal changes much the meaning (at any point in time, its key is unique, and yes, it may be changed over time).
[Denis] It does change it. Since it seems you can live with that change, this is fine.

Resource Server (RS)

server that provides operations on protected resources, where operations require a valid access token issued by an AS.

 

[Denis] Change into: 

Resource Server (RS) : server that provides operations on resources, where operations on protected resources require
a valid access token issued by one or more ASs

 Some explanations: a resource server may also support resources available to the public.

 

[FI] yes, but we don't really care about public resources (there's no need for a protocol for that). As for "one or more ASs", this seems to embed a requirement (support multiplicity).

[Denis] A RS may support both public and private resources. At the time an operation is performed by a client on a resource,
            it is unknown whether that operation is allowed for the public or not.

Resource Owner (RO)

subject entity that may grant or deny operations on resources it has authority upon.

Note: the act of granting or denying an operation may be manual (i.e. through an interaction with a physical person) or automatic (i.e. through predefined organizational rules).

 

[Denis] Change into:

Resource Owner (RO):  entity that may grant or deny operations on resources it has authority upon

 Some explanations: the term "entity" (without the word "subject") is being used which is a very general term: it may or may not be a human being.

 

[FI] subject is defined as either human or not.

[Denis] No, a subject is currently defined in the draft as "person, organization or device". We don't need to use the term "subject".

 

End-user

natural person that operates the client instance.

 

Note: that natural person may or may not be the same entity as the RO. When it is explicit that the end-user and the RO are the same entity, the generic term user may be used.

[Denis] 

Change into:

End-user: natural person that operates a client instance

Remove the Note which is confusing.


[FI] "a" might indeed be better.
[Denis] Thanks !

Regarding the note, it seems that you'd rather not have "user" (and the rest is still useful I think).
This is actually used in other parts of the spec (cf diagrams) to refer to either RO or end-user, undistinctively. What would you use otherwise?

[Denis] The Note should be removed because it leads to confusion. The Note considers only the case where the RO is a natural person, however a RO may also be a process.
The Note may be adequate when the RO is being defined. In such a case, I would propose:

Resource Owner (RO):  entity that may grant or deny operations on resources it has authority upon


Note 1: The act of granting or denying an operation may be automatic (i.e. through predefined rules) or manual (i.e. through an interaction with a physical person)..


Note 2: In the later case, the same physical person may support simultaneously the role of the RO and the role of the end-user.

Attribute

characteristics related to a subject.

 

[Denis] Change into:

Attribute: characteristics related to an end-user

[FI] are we 100% sure we'll never send anything else?

[Denis] See the discussion above for the reason for not using the term "subject".

Access Token

a data artifact representing a set of rights and/or attributes.

 

Note: an access token can be first issued to an client instance (requiring authorization by the RO) and subsequently rotated.

 

[Denis] Remove the Note which has nothing to do in this section.


[FI] the note serves the purpose of explaining the lifecycle of an access token, which I believe is useful to the reader. Cf the large littérature about access vs refresh in the oauth2 world.

[Denis] We are in the definition section. Explaining the lifecycle of an access token may indeed be very useful
            but a dedicated section in the main body of the document would much better address this topic.

Grant

(verb): to permit an instance of client software to exercise some set of delegated rights to access a protected resource and/or
to receive some attributes at a specific time and during a specific duration. (noun): the act of granting.

 

[Denis] Change into:

Grant

 

(verb): to receive some attributes from an AS at a specific time and valid for a specific duration and/or
to permit an instance of client software to exercise this attributes to perform an operation on a protected resource

 

(noun): the act of granting

 Some explanations: The current text identifies two cases. I have switched these two cases.


[FI] how is that better?

[Denis] Before being able to use an access token, it is necessary to get it. So the proposed definition follows a chronological order.


Privilege

right or attribute associated with a subject.

 

[Denis]

Privilege: right or attribute associated with an end-user

 Note: the RO defines and maintains the rights and attributes associated to the protected resource, and might temporarily delegate

some set of those privileges to an end-user. This process is refered to as privilege delegation.

 

[Denis] Remove the Note which is unrelated to the definition.


[FI] this is useful to understand what we call "delegated privileges" in the AS definition.

[Denis] Reading the original proposed definition again, the Note considers the RO.

I consider that a right is a capability to perform an operation on a protected resource. Such capabilities is given by a RO to an end-user.
I consider that an attribute is a characteristics related to an end-user (e.g. a name, a group membership)

            Privilege = right or attribute associated with an end-user which allows to support respectively
                              either a capability scheme or an attributed-based access control (ABAC) using ACLs.

A RO maintains rights but it does not maintain attributes.

It might be useful to define in addition:

control attributes: set of attributes associated to a protected resource used to control operations on that resource

Note: a RO defines and maintains the control attributes associated to a protected resource

 

 Protected Resource

protected API (Application Programming Interface) served by a RS and that can be accessed by a client, if and only if a valid access token is provided.

 

Note: to avoid complex sentences, the specification document may simply refer to resource instead of protected resource.

Right

ability given to a subject to perform a given operation on a resource under the control of a RS.

 

[Denis] Change into:

Right: ability given to an end-user to perform a given operation on a resource under the control of a RS


[FI] it's not rights about the end-user per say, it's rights delegated by the RO.
And so in this context, subject seems a better description and avoids the potential misunderstanding. And least that's the intent.

[Denis]  A right is not given to an organization or to a device, but only to an end-user.

Subject

person, organization or device.

 

[Denis] Remove this definition since this terms is confusing and unnecessary.


[FI] I'm not sure what is confusing. This is useful at the bare minimum in context with the next definition. 
I think it can be used as a basic definition for other terms, and that's what is proposed.

[Denis] See the arguments raised above.

Subject Information

statement asserted locally by an AS about a subject.

 

[Denis] Remove this definition since this terms is confusing and unnecessary.


[FI] this is used in the main text, so needs to be defined (or removed from the main text, but that's a different debate).

[Denis] See the arguments raised above.

Current spec

Here we find all the terms and definitions from the current version of the draft (01), as a reference.

Roles

Authorization Server (AS)

Manages the requested delegations for the RO. The AS issues tokens and directly delegated information to the RC.
The AS is defined by its grant endpoint, a single URL that accepts a POST request with a JSON payload.
The AS could also have other endpoints, including interaction endpoints and user code endpoints, and these are introduced
to the RC as needed during the delegation process.

 

[Denis] Already discussed above (and far too long for a definition).

 

Resource Client (RC, aka "client")

Requests tokens from the AS and uses tokens at the RS. An instance of the RC software is identified by its key, which can be known
to the AS prior to the first request. The AS determines which policies apply to a given RC, including what it can request and on whose behalf.

 

[Denis] Already discussed above.

 

Resource Server (RS, aka "API")

Accepts tokens from the RC issued by the AS and serves delegated resources on behalf of the RO.
There could be multiple RSs protected by the AS that the RC will call.

 

[Denis] Already discussed above.

 

Resource Owner (RO)

Authorizes the request from the RC to the RS, often interactively at the AS.

 

[Denis] Already discussed above.

 

Requesting Party (RQ, aka "user")

Operates and interacts with the RC.

 

[Denis] Remove. Already discussed above under the term "end-user"

Elements

Access Token

A credential representing a set of access rights delegated to the RC. The access token is created by the AS, consumed and verified by the RS,
and issued to and carried by the RC. The contents and format of the access token are opaque to the RC.

 

[Denis] Already discussed above.

 

Grant

The process by which the RC requests and is given delegated access to the RS by the AS through the authority of the RO.

 

[Denis] Already discussed above.

 

Cryptographic Key

A cryptographic element binding a request to a holder of the key. Access tokens and RC instances can be associated with specific keys.

 

[Denis] Change into:

Binding key: a cryptographic key used by a client to bind an access token to a client instance

Some explanations: cryptographic key is a general term. In the context of GNAP we want that key to achieve a specific function:
to bind an access token to a client instance.

Resource

A protected API served by the RS and accessed by the RC. Access to this resource is delegated by the RO as part of the grant process.

 

[Denis] We don't need this definition. Already discussed above under the wording" Protected Resource".

 

Subject Information

Information about the RO that is returned directly to the RC from the AS without the RC making a separate call to an RS.
Access to this information is delegated by the RO as part of the grant process.

[Denis] We don't need this definition.

Some explanations: an end-user may wish to know the attributes stored for him by the AS.
However, no information needs to be returned to a client about a RO.

Denis


Denis

Hi everyone, 

I wish you all a happy new year.

I just created a PR (https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/155) that takes into account the various feedbacks. The automatic build process is not working, but you can see the diffs and build the html locally if you prefer. The definitions have also been updated on the wiki (https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology) if you prefer to check there. 

Feedbacks welcome before we move to pending merge later on.

Cheers
Fabien


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


--------------E71063FD73426280BCA3C531-- From nobody Tue Jan 12 07:55:29 2021 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5453A09EF for ; Tue, 12 Jan 2021 07:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTjwUn8BlnW7 for ; Tue, 12 Jan 2021 07:55:23 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 231833A09E9 for ; Tue, 12 Jan 2021 07:55:23 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id 81so5004002ioc.13 for ; Tue, 12 Jan 2021 07:55:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WgPHtrhvvO5xXgZW0IQhGtbq6dUVqacT4fj/4jEB4DQ=; b=TDp6fpI9gkc1H88TNQI4vL7eM4tSnynGXR5xuyqI4DaREtG93OQcouSL+Q6HXiKxKk zCvxMEy7xIDcF5gnsKEOhhHp7sRuAKN0IIkejXNlPK6aKmaV+w+WOooxc+nlLxxnT5IE 7CZuyScOfUjKnPLgAsgb1Ef4akzZ8HqkT2OOPWENwSM5eiylJPApBCf9Z29b1Rnyr5Tf vKOwfV2dT2G4xCdyviICsCv83Ju7pMZZHZmDeChnoA4PTncWSgBHHST14Qw7vdFc7R5l 77aJZvUK9/ep+QNr9De2t0v7sxIwQqA+uJC6cyqRD51l0rak/SPT1VWGd/dWslflqkDQ sNkQ== 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=WgPHtrhvvO5xXgZW0IQhGtbq6dUVqacT4fj/4jEB4DQ=; b=Z4dWhEsSGo3g6z1eTDCx/M4skW8lYrSh/yJnyZlkQ04ArbHg2jA5cOvw0IC6zzVZQt CmfhjRbhE9W892yM4JjJfgK/LaIdO8eI9X4bCsPB84dSLgApWytb6PaSQ9Gp90SkWRul yKAGYkuCzlimF62fwQx3vYjh3tfBmt4rGGoP0/cJ3l53RvfWTTDAMrIGmbxYpAOUZtpn 4LAaooZukvZ5yOozF7LRxOwbfwWkp+vEDDErmkp+VTE8MEfWbgOLk0Ej0sHNG1taQwxU joaFZIntaSQcgir1kJeofRlqVku/88NWCfQ0F3jhclgVDjZwBSY3lEK8mB95VVOPM+IN MIzQ== X-Gm-Message-State: AOAM5305m8UhgitdSbMotaf1tZXPHKurQ2MFJNAstVpnCFcHQhsapgwa 9QYFm6utOtNe5v6YT9trLSYGqIFTv4/W61i+mTc= X-Google-Smtp-Source: ABdhPJwfJRVMq9+k4fnLvf7mh2a+bgktg0a7wY7roELX5zruaB2C8OVCd6uCVUKwjuLduRouN4VrSSx3HQ6AxQYnoOw= X-Received: by 2002:a92:b503:: with SMTP id f3mr4579161ile.123.1610466922409; Tue, 12 Jan 2021 07:55:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Tue, 12 Jan 2021 16:55:10 +0100 Message-ID: To: Denis Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000d534e605b8b60ccf" Archived-At: Subject: Re: [GNAP] Terminology PR X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2021 15:55:27 -0000 --000000000000d534e605b8b60ccf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Denis, We could try to remove the term "user" and systematically list RO and end-user instead. It's not a critical term and is used for convenience (cf for instance diagram in section 1.4.1, where we have a part labelled "RO + RQ (User)" in version 3 of the draft, and we have the accompanying text that explains it too). I have noted the small change in the end-user definition ("a"), which would be an update to the PR. Other comments embed with [FI] in red. Most of them are related to the use of "subject", which I still find more accurate than RO or end-user in the general case (that is without being specific about one particular use case or without embedding requirements in the definition). As previously mentioned, this also comes from the use of "subject entity" in relationship to https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-06 (= used in the main text), so that we don't use different synonyms in the definitions. Same answer as what Mark asked for earlier. Cheers Fabien On Tue, Jan 12, 2021 at 4:29 PM Denis wrote: > Hello Fabien, > > The end-user and the RO are two roles. > The case where (as you write) RO=3Dend-user does not exist. The case wher= e > these two roles are supported by the same entity may exist. > Since the document is supposed to describe operations between roles, I > don't see the need to use a specific vocabulary for that specific case. > Other comments are below. One of them attempts to explain (in a Note 2), > the relationship between a RO and an end-user > > Hello Denis, > > The part called "current spec" corresponds to the text before the PR, it'= s > just here for reference. > > We made the distinction between the end-user and the RO as clear as we > could. > There is indeed a case where we still keep "user", to indicate that the > RO=3Dend-user (and tried to make it clear in the text). I don't see an > obvious way to change that. > > From your comment I don't see why subject would be a problem. > > We indeed tried to avoid the embedding of requirements into the > definitions. > > The rest of my comments are embedded into your message, and marked with F= I > for convenience. > > Fabien > > > Le lun. 11 janv. 2021 =C3=A0 16:27, Denis a =C3=A9cr= it : > > > I have used the text of the wiki to respond. Latest discussion update >> >> Here we consolidate the latest proposal(s) from the group. We also >> include the discussion items (individual feedbacks). >> >> >> >> [Denis] I don't have the feeling that we are converging. There are >> duplications for some definitions that are spread over the document >> instead of being grouped together. This does not help to converge. >> >> >> >> We need to clearly separate the role of the "end-user" from the role of = a >> RO. Attempting to collapse these two concepts under the term "user" >> creates confusion. Attempting to use the term "subject" creates even mor= e >> confusion. >> >> >> Trying to incorporate design choices inside the definition section is no= t >> appropriate, hence why I propose to remove several notes. >> >> >> >> In my proposals below, I have followed the ISO style for the definitions >> (a single sentence as short as possible). >> >> >> Authorization Server (AS) >> >> server that grants delegated privileges to a particular instance of >> client software in the form of an access token and other information (su= ch >> as subject information). >> >> >> >> [Denis] >> >> Authorization Server (AS): server that grants access privileges to a >> particular instance of a client software in the form of an access token = and >> provides information about the end user >> >> Some explanations: In addition to the granting of access tokens, >> end-users may query the AS about the privileges they store about them. >> >> We should identify in the main body of the document thse two distinct >> operations. >> > > [FI] so far the type of additional information we would send is specified > as subject information, hence its use in the definition. > > [Denis] Since a subject is currently defined in the draft as "person, > organization or device", I don't believe that an AS "grants other other > information > (such as subject information)" because it does not manage organizations > nor devices. In the context of an AS, the AS only manages end-user > information > hence why it is unnecessary to introduce the term "subject". > [FI] In most cases, it will be only about the end-user and its access token. But regarding the use of subject and whether we could send other information such as subject information, this would be the case if we include client posture (which is something planned). > Client >> >> application operated by an end-user that consumes resources from one or >> several RSs, possibly requiring access privileges from one or several AS= s. >> >> >> >> Example: a client can be a mobile application, a web application, etc. >> >> >> >> Note: this specification differentiates between a specific instance (the >> client instance, identified by its unique key) and the software running = the >> instance (the client software). For some kinds of client software, there >> could be many instances of that software, each instance with a different >> key. >> >> >> >> [Denis] Change in the Note: >> >> (the client instance, identified by its unique key) >> >> into: >> >> (the client instance, identified by a unique key) >> >> Some explanations: The key is unique, but may change. >> > > [FI] not sure that your proposal changes much the meaning (at any point i= n > time, its key is unique, and yes, it may be changed over time). > > [Denis] It does change it. Since it seems you can live with that change, > this is fine. > > Resource Server (RS) >> >> server that provides operations on protected resources, where operations >> require a valid access token issued by an AS. >> >> >> >> [Denis] Change into: >> >> Resource Server (RS) : server that provides operations on resources, >> where operations on protected resources require >> a valid access token issued by one or more ASs >> >> Some explanations: a resource server may also support resources >> available to the public. >> >> >> > [FI] yes, but we don't really care about public resources (there's no nee= d > for a protocol for that). As for "one or more ASs", this seems to embed a > requirement (support multiplicity). > > [Denis] A RS may support both public and private resources. At the time > an operation is performed by a client on a resource, > it is unknown whether that operation is allowed for the publi= c > or not. > [FI] yes indeed the RS may support public or private resources, but the RS definition still seems valid > > Resource Owner (RO) >> >> subject entity that may grant or deny operations on resources it has >> authority upon. >> >> Note: the act of granting or denying an operation may be manual (i.e. >> through an interaction with a physical person) or automatic (i.e. throug= h >> predefined organizational rules). >> >> >> >> [Denis] Change into: >> >> Resource Owner (RO): *entity* that may grant or deny operations on >> resources it has authority upon >> >> Some explanations: the term "entity" (without the word "subject") is >> being used which is a very general term: it may or may not be a human be= ing. >> >> >> > [FI] subject is defined as either human or not. > > [Denis] No, a subject is currently defined in the draft as "person, > organization or device". We don't need to use the term "subject". > [FI] sorry, I don't get your point. Entity alone doesn't make me understand it can also be a human. > > >> End-user >> >> natural person that operates *the* client instance. >> >> >> >> Note: that natural person may or may not be the same entity as the RO. >> When it is explicit that the end-user and the RO are the same entity, th= e >> generic term user may be used. >> [Denis] Change into: >> >> *End-user*: natural person that operates *a* client instance >> >> Remove the Note which is confusing. >> > > [FI] "a" might indeed be better. > > [Denis] Thanks ! > [FI] will update the PR > > > Regarding the note, it seems that you'd rather not have "user" (and the > rest is still useful I think). > This is actually used in other parts of the spec (cf diagrams) to refer t= o > either RO or end-user, undistinctively. What would you use otherwise? > > [Denis] The Note should be removed because it leads to confusion. The Not= e > considers only the case where the RO is a natural person, however a RO ma= y > also be a process. > The Note may be adequate when the RO is being defined. In such a case, I > would propose: > > Resource Owner (RO): *entity* that may grant or deny operations on > resources it has authority upon > > > Note 1: The act of granting or denying an operation may be automatic (i.e= . > through predefined rules) or manual (i.e. through an interaction with a > physical person).. > > Note 2: In the later case, the same physical person may support > simultaneously the role of the RO and the role of the end-user. > > Attribute >> >> characteristics related to a subject. >> >> >> >> [Denis] Change into: >> >> Attribute: characteristics related to an end-user >> >> [FI] are we 100% sure we'll never send anything else? > > [Denis] See the discussion above for the reason for not using the term > "subject". > > Access Token >> >> a data artifact representing a set of rights and/or attributes. >> >> >> >> Note: an access token can be first issued to an client instance >> (requiring authorization by the RO) and subsequently rotated. >> >> >> >> [Denis] Remove the Note which has nothing to do in this section. >> > > [FI] the note serves the purpose of explaining the lifecycle of an access > token, which I believe is useful to the reader. Cf the large litt=C3=A9ra= ture > about access vs refresh in the oauth2 world. > > [Denis] We are in the definition section. Explaining the lifecycle of an > access token may indeed be very useful > but a dedicated section in the main body of the document woul= d > much better address this topic. > [FI] we could do that too. As any note, it's not critical anyway. It's here mostly for convenience, but if we feel it's better in the main text, so be it. > > Grant >> >> (verb): to permit an instance of client software to exercise some set of >> delegated rights to access a protected resource and/or >> to receive some attributes at a specific time and during a specific >> duration. (noun): the act of granting. >> >> >> >> [Denis] Change into: >> >> *Grant* >> >> >> >> (verb): to receive some attributes from an AS at a specific time and >> valid for a specific duration and/or >> to permit an instance of client software to exercise this attributes to >> perform an operation on a protected resource >> >> >> >> (noun): the act of granting >> >> Some explanations: The current text identifies two cases. I have >> switched these two cases. >> > > [FI] how is that better? > > [Denis] Before being able to use an access token, it is necessary to get > it. So the proposed definition follows a chronological order. > [FI] ok clearer now, thanks. > Privilege >> >> right or attribute associated with a subject. >> >> >> >> [Denis] >> >> *Privilege*: right or attribute associated with an end-user >> >> Note: the RO defines and maintains the rights and attributes associated >> to the protected resource, and might temporarily delegate >> >> some set of those privileges to an end-user. This process is refered to >> as privilege delegation. >> >> >> >> [Denis] Remove the Note which is unrelated to the definition. >> > > [FI] this is useful to understand what we call "delegated privileges" in > the AS definition. > > [Denis] Reading the original proposed definition again, the Note consider= s > the RO. > [FI] it's not easy to describe. It considers the RO and its delegation. > > > I consider that a right is a capability to perform an operation on a > protected resource. Such capabilities is given by a RO to an end-user. > I consider that an attribute is a characteristics related to an end-user > (e.g. a name, a group membership) > > Privilege =3D right or attribute associated with an end-user > which allows to support respectively > either a capability scheme or an > attributed-based access control (ABAC) using ACLs. > > A RO maintains rights but it does not maintain attributes. > [FI] which is why subject is more general, and can accomodate both use cases. Anyway, the exact requirement should be left to the main text. > It might be useful to define in addition: > > *control attributes*: set of attributes associated to a protected > resource used to control operations on that resource > > Note: a RO defines and maintains the control attributes associated to a > protected resource > > [FI] we'll try to really limit new definitions to the bare minimum. So if we see that's useful, we'll include it. But so far I don't think that adds much. > > > Protected Resource >> >> protected API (Application Programming Interface) served by a RS and tha= t >> can be accessed by a client, if and only if a valid access token is >> provided. >> >> >> >> Note: to avoid complex sentences, the specification document may simply >> refer to resource instead of protected resource. >> Right >> >> ability given to *a subject* to perform a given operation on a resource >> under the control of a RS. >> >> >> >> [Denis] Change into: >> >> *Right*: ability given to *an end-user* to perform a given operation on >> a resource under the control of a RS >> >> > [FI] it's not rights about the end-user per say, it's rights delegated by > the RO. > And so in this context, subject seems a better description and avoids the > potential misunderstanding. And least that's the intent. > > [Denis] A right is not given to an organization or to a device, but only > to an end-user. > [FI] not always. Could have an automated policy, which assigns rights to user groups, which is an organizational construct. Device policies might matter too. Of course at runtime, it ends up being consumed by an end-user. > Subject >> >> person, organization or device. >> >> >> >> [Denis] Remove this definition since this terms is confusing and >> unnecessary. >> > > [FI] I'm not sure what is confusing. This is useful at the bare minimum i= n > context with the next definition. > I think it can be used as a basic definition for other terms, and that's > what is proposed. > > [Denis] See the arguments raised above. > > Subject Information >> >> statement asserted locally by an AS about a subject. >> >> >> >> [Denis] Remove this definition since this terms is confusing and >> unnecessary. >> > > [FI] this is used in the main text, so needs to be defined (or removed > from the main text, but that's a different debate). > > [Denis] See the arguments raised above. > > Current spec >> >> Here we find all the terms and definitions from the current version of >> the draft (01), as a reference. >> Roles Authorization Server (AS) >> >> Manages the requested delegations for the RO. The AS issues tokens and >> directly delegated information to the RC. >> The AS is defined by its grant endpoint, a single URL that accepts a POS= T >> request with a JSON payload. >> The AS could also have other endpoints, including interaction endpoints >> and user code endpoints, and these are introduced >> to the RC as needed during the delegation process. >> >> >> >> [Denis] Already discussed above (and far too long for a definition). >> >> >> Resource Client (RC, aka "client") >> >> Requests tokens from the AS and uses tokens at the RS. An instance of th= e >> RC software is identified by its key, which can be known >> to the AS prior to the first request. The AS determines which policies >> apply to a given RC, including what it can request and on whose behalf. >> >> >> >> [Denis] Already discussed above. >> >> >> Resource Server (RS, aka "API") >> >> Accepts tokens from the RC issued by the AS and serves delegated >> resources on behalf of the RO. >> There could be multiple RSs protected by the AS that the RC will call. >> >> >> >> [Denis] Already discussed above. >> >> >> Resource Owner (RO) >> >> Authorizes the request from the RC to the RS, often interactively at the >> AS. >> >> >> >> [Denis] Already discussed above. >> >> >> Requesting Party (RQ, aka "user") >> >> Operates and interacts with the RC. >> >> >> >> [Denis] Remove. Already discussed above under the term " >> >> *end-user" * >> >> *Elements* >> Access Token >> >> A credential representing a set of access rights delegated to the RC. Th= e >> access token is created by the AS, consumed and verified by the RS, >> and issued to and carried by the RC. The contents and format of the >> access token are opaque to the RC. >> >> >> >> [Denis] Already discussed above. >> >> >> Grant >> >> The process by which the RC requests and is given delegated access to th= e >> RS by the AS through the authority of the RO. >> >> >> >> [Denis] Already discussed above. >> >> >> Cryptographic Key >> >> A cryptographic element binding a request to a holder of the key. Access >> tokens and RC instances can be associated with specific keys. >> >> >> >> [Denis] Change into: >> >> *Binding key*: a cryptographic key used by a client to bind an access >> token to a client instance >> >> Some explanations: cryptographic key is a general term. In the context o= f >> GNAP we want that key to achieve a specific function: >> to *bind *an access token to a client instance. >> Resource >> >> A protected API served by the RS and accessed by the RC. Access to this >> resource is delegated by the RO as part of the grant process. >> >> >> >> [Denis] We don't need this definition. Already discussed above under the >> wording" Protected Resource". >> >> >> Subject Information >> >> Information about the RO that is returned directly to the RC from the AS >> without the RC making a separate call to an RS. >> Access to this information is delegated by the RO as part of the grant >> process. >> >> [Denis] We don't need this definition. >> >> Some explanations: an end-user may wish to know the attributes stored fo= r >> him by the AS. >> However, no information needs to be returned to a client about a RO. >> > Denis > > Denis >> >> Hi everyone, >> >> I wish you all a happy new year. >> >> I just created a PR ( >> https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/155) that takes >> into account the various feedbacks. The automatic build process is not >> working, but you can see the diffs and build the html locally if you >> prefer. The definitions have also been updated on the wiki ( >> https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology) if >> you prefer to check there. >> >> Feedbacks welcome before we move to pending merge later on. >> >> Cheers >> Fabien >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000d534e605b8b60ccf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Denis,=C2=A0

We could try= to remove the term "user" and systematically list RO and end-use= r instead. It's not a critical term and is used for convenience (cf for= instance diagram in section 1.4.1, where we have a part labelled "RO= =C2=A0+ RQ (User)" in version 3 of the draft, and we have the accompan= ying text that explains it too).

I have noted the = small change in the end-user definition ("a"), which would be an = update to the PR.=C2=A0

Other comments embed with = [FI] in red. Most of them are related to the use of "subject", wh= ich I still find more accurate than RO or end-user in the general case (tha= t is without being specific about one particular use case or without embedd= ing requirements in the definition). As previously mentioned, this also com= es from the use of "subject entity" in relationship to=C2=A0https://tools.ietf.org/html/draft-ietf-secevent-subjec= t-identifiers-06=C2=A0(used in the main text), so that we don't use= different synonyms in the definitions. Same answer as what Mark asked for = earlier.=C2=A0

Cheers
Fabien
<= br>

On Tue, Jan 12, 2021 at 4:29 PM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20
Hello Fabien,

The end-user and the RO are two roles.
The case where (as you write) RO=3Dend-user does not exist. The case where these two roles are supported by the same entity may exist.
Since the document is supposed to describe operations between roles, I don't see the need to use a specific vocabulary for that specific case.
Other comments are below. One of them attempts to explain (in a Note 2), the relationship between a RO and an end-user

=20
Hello Denis,

The part called "current spec" correspo= nds to the text before the PR, it's just here for reference.=C2=A0

We made the distinction between the end-user and the RO as clear as we could.=C2=A0
There is indeed a case where we still keep "user", to indicate that the RO=3Dend-user (and tried t= o make it clear in the text). I don't see an obvious way to change that.=C2=A0

From your comment I don't see why subject wou= ld be a problem.=C2=A0

We indeed tried to avoid the embedding of requirements into the definitions.

The rest of my comments are embedded into your message, and marked with FI for convenience.=C2=A0

Fabien


Le lun. 11 janv. 2021 =C3= =A0 16:27, Denis <denis.ietf@free.fr> a =C3=A9crit=C2=A0:

I have used the text of the wiki to respond.

Latest discussion update

Here we consolidate the latest proposal(s) from the group. We also include the discussion items (individual feedbacks).

=C2=A0

[Denis] I don't have the feeling that we are converging. There are duplications for some definitions that are spread over the document
instead of being grouped together. This does not help to converge.

=C2=A0

We need to clearly separate the role of the "end-user= " from the role of a RO. Attempting to collapse these two concepts under the term "user"
creates confusion. Attempting to use the term "subject" creates even more confusion.=


Trying to incorporate design choices inside the definition section is not appropriate, hence why I propose to remove several notes.

=C2=A0

In my proposals below, I have followed the ISO style for the definitions (a single sentence as short as possible).

=C2=A0

Authorization Server (AS)

server that grants delegated privileges to a particular instance of client software in the form of an access token and other information (such as subject information).

=C2=A0

[Denis]

Authorization Server (AS): server that grants access privileges to a particular instance of a client software in the form of an access token and provides information about the end user

Some explanations: In addition to the granting of access tokens, end-users may query the AS about the privileges they store about them.

We should identify in the main body of the document thse two distinct operations.


[FI] so far the type of additional information we would send is specified as subject information, hence its use in the definition.
[Denis] Since a subject is currently defined in the draft as "person, organization or device", I don't = believe that an AS "grants other other information
(such as subject information)" because it does not manage orga= nizations nor devices. In the context of an AS, the AS only manages end-user information
hence why it is unnecessary to introduce the term "subject"= .

= [FI] In most cases, it will be only about the end-user and its access token= . But regarding the use of subject and whether we could send other informat= ion such as subject information, this would be the case if we include clien= t posture (which is something planned).=C2=A0 =C2=A0

Client

application operated by an end-user that consumes resources from one or several RSs, possibly requiring access privileges from one or several ASs.

=C2=A0

Example: a client can be a mobile application, a web application, etc.

=C2=A0

Note: this specification differentiates between a specific instance (the client instance, identified by its unique key) and the software running the instance (the client software). For some kinds of client software, there could be many instances of that software, each instance with a different key.

=C2=A0

[Denis] Change in the Note:

(the client instance, identified by its unique key)=

into:

(the client instance, identified by a unique key)

Some explanations: The key is unique, but may change.=


[FI] not sure that your proposal changes much the meaning (at any point in time, its key is unique, and yes, it may be changed over time).
[Denis] It does change it. Since it seems you can live with that change, this is fine.

Resource Server (RS)

server that provides operations on protected resources, where operations require a valid access token issued by an AS.

=C2=A0

[Denis] Change into:=C2=A0

Resource Server (RS= ) : server that provides operations on resources, where operations on protected resources require
a valid access token issued by one or more ASs

=C2=A0Some explanations: a resource server may also support resources available to the public.

=C2=A0

[FI] yes, but we don't really care about publ= ic resources (there's no need for a protocol for that). As for "one or more ASs", this seems to embed a requirement (s= upport multiplicity).

[Denis] A RS may support both public and private resources. At the time an operation is performed by a client on a resource,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = it is unknown whether that operation is allowed for the public or not.=C2=A0

[FI] yes indeed the RS may support public or private resour= ces, but the RS definition still seems valid


Resource Owner (RO)

subject entity that may grant or deny operations on resources it has authority upon.

Note: the act of granting or denying an operation may be manual (i.e. through an interaction with a physical person) or automatic (i.e. through predefined organizational rules).

=C2=A0

[Denis] Change into:

Resource Owner (RO)= :=C2=A0 entity that may grant or deny operations on resources it has authority upon

=C2=A0Some explanations: the term "entity" (without the = word "subject") is being used which is a very gene= ral term: it may or may not be a human being.

=C2=A0

[FI] subject is defined as either human or not.

[Denis] No, a subject is currently defined in the draft as "person, organization or device". We don'= ;t need to use the term "subject".

=
[FI] sorry, I don't get your point. Entity= alone doesn't make me understand it can also be a human.
<= 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">

=C2=A0

End-user

natural person that operates the client instance.

=C2=A0

Note: that natural person may or may not be the same entity as the RO. When it is explicit that the end-user and the RO are the same entity, the generic term user may be used.

[Denis]=C2=A0=

Change into:

End-user: natural person th= at operates a client instance

Remove the Note which is confusing.


[FI] "a" might indeed be better.
[Denis] Thanks !
[FI] will update the PR=C2=A0


Regarding the note, it seems that you'd rathe= r not have "user" (and the rest is still useful I think).=
This is actually used in other parts of the spec (cf diagrams) to refer to either RO or end-user, undistinctively. What would you use otherwise?

[Denis] The Note should be removed because it leads to confusion. The Note considers only the case where the RO is a natural person, however a RO may also be a process.
The Note may be adequate when the RO is being defined. In such a case, I would propose:

Resource Owner (RO):=C2=A0 entity that may grant or deny operations on resources it has authority upon


Note 1: The act of granti= ng or denying an operation may be automatic (i.e. through predefined rules) or manual (i.e. throug= h an interaction with a physical person)..


Note 2: In the later case, the same physical person may support simultaneously the role of the RO and the role of the end-user.

Attribute

characteristics related to a subject.

=C2=A0

[Denis] Change into:

Attribute: characte= ristics related to an end-user

[FI] are we 100% sure we'll never send anythi= ng else?

[Denis] See the discussion above for the reason for not using the term "subject".

Access Token

a data artifact representing a set of rights and/or attributes.

=C2=A0

Note: an access token can be first issued to an client instance (requiring authorization by the RO) and subsequently rotated.

=C2=A0

[Denis] Remove the Note which has nothing to do in this section.


[FI] the note serves the purpose of explaining the lifecycle of an access token, which I believe is useful to the reader. Cf the large litt=C3=A9rature about access vs refresh in the oauth2 world.

[Denis] We are in the definition section. Explaining the lifecycle of an access token may indeed be very useful
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = but a dedicated section in the main body of the document would much better address this topic.

[FI] we could do that too. As any not= e, it's not critical anyway. It's here mostly for convenience, but = if we feel it's better in the main text, so be it.


Grant

(verb): to permit an instance of client software to exercise some set of delegated rights to access a protected resource and/or
to receive some attributes at a specific time and during a specific duration. (noun): the act of granting.

=C2=A0

[Denis] Change into:

Grant

=C2=A0

(verb): to receive some attributes from an AS at a specific time and valid for a specific duration and/or
to permit an instance of client software to exercise this attributes to perform an operation on a protected resource

=C2=A0

(noun): the act of granting

=C2=A0Some explanations: The current text identifies two cases. I have switched these two cases.


[FI] how is that better?

[Denis] Before being able to use an access token, it is necessary to get it. So the proposed definition follows a chronological order.

[FI] ok clearer now, thanks.

Privilege

right or attribute associated with a subject.

=C2=A0

[Denis]

Privilege: right or attribute associated with an end-user

=C2=A0Note: the RO defines and maintains the rights and attributes associated to the protected resource, and might temporarily delegate

some set of those privileges to an end-user. This process is refered to as privilege delegation.

=C2=A0

[Denis] Remove the Note which is unrelated to the definition.


[FI] this is useful to understand what we call "delegated privileges" in the AS definition.

[Denis] Reading the original proposed definition again, the Note considers the RO.

[FI] it's not easy to describe. It= considers the RO and its delegation.



I consider that a right is a capability to perform an operation on a protected resource. Such capabilities is given by a RO to an end-user.
I consider that an attribute is a characteristics related to an end-user (e.g. a name, a group membership)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Privilege =3D right or attribute associated with an end-user which allows to support respectively
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 either a capability scheme or an attributed-based access control (ABAC) using ACLs.

A RO maintains rights but it does not maintain attributes.

[FI] which is why subject is more general, and can accomodate both use c= ases. Anyway, the exact requirement should be left to the main text.=

It might be useful to define in addition:

control attributes: set of attributes associated to a protected resource used to control operations on that resource

Note: a RO defines and maintains the control attributes associated to a protected resource

[FI] we'll try to really limit new definitions to the ba= re minimum. So if we see that's useful, we'll include it. But so fa= r I don't think that adds much.=C2=A0

=C2=A0

=C2=A0Protected Resource

protected API (Application Programming Interface) served by a RS and that can be accessed by a client, if and only if a valid access token is provided.

=C2=A0

Note: to avoid complex sentences, the specification document may simply refer to resource instead of protected resource.

Right

ability given to a subject to perform a given operation on a resource under the control of a RS.

=C2=A0

[Denis] Change into:

Right: ability given to an end-user to perform a given operation on a resource under the control of a RS


[FI] it's not rights about the end-user per s= ay, it's rights delegated by the RO.
And so in this context, subject seems a better description and avoids the potential misunderstanding. And least that's the intent.

[Denis]=C2=A0 A right is not given to an organization or to a device, but only to an end-user.

[FI] not always. Could hav= e an automated policy, which assigns rights to user groups, which is an org= anizational construct. Device policies might matter too.
<= font color=3D"#ff0000">Of course at runtime, it ends up being consumed by a= n end-user.=C2=A0

Subject

person, organization or device.

=C2=A0

[Denis] Remove this definition since this terms is confusing and unnecessary.


[FI] I'm not sure what is confusing. This is useful at the bare minimum in context with the next definition.=C2=A0
I think it can be used as a basic definition for other terms, and that's what is proposed.

[Denis] See the arguments raised above.<= br>

Subject Information

statement asserted locally by an AS about a subject.

=C2=A0

[Denis] Remove this definition since this terms is confusing and unnecessary.


[FI] this is used in the main text, so needs to be defined (or removed from the main text, but that's a different debate).

[Denis] See the arguments raised above.<= /p>

Current spec

Here we find all the terms and definitions from the current version of the draft (01), as a reference.

Roles

Authorization Server (AS)

Manages the requested delegations for the RO. The AS issues tokens and directly delegated information to the RC.
The AS is defined by its grant endpoint, a single URL that accepts a POST request with a JSON payload.
The AS could also have other endpoints, including interaction endpoints and user code endpoints, and these are introduced
to the RC as needed during the delegation process.

=C2=A0

[Denis] Already discussed above (and far too long for a definition).

=C2=A0

Resource Client (RC, aka "client")

Requests tokens from the AS and uses tokens at the RS. An instance of the RC software is identified by its key, which can be known
to the AS prior to the first request. The AS determines which policies apply to a given RC, including what it can request and on whose behalf.

=C2=A0

[Denis] Already discusse= d above.

=C2=A0

Resource Server (RS, aka "API")

Accepts tokens from the RC issued by the AS and serves delegated resources on behalf of the RO.
There could be multiple RSs protected by the AS that the RC will call.

=C2=A0

[Denis] Already discusse= d above.

=C2=A0

Resource Owner (RO)

Authorizes the request from the RC to the RS, often interactively at the AS.

=C2=A0

[Denis] Already discussed above.

=C2=A0

Requesting Party (RQ, aka "user")

Operates and interacts with the RC.

=C2=A0

[Denis] Remove. Already discussed above under the term "end-user"=

Elements

Access Token

A credential representing a set of access rights delegated to the RC. The access token is created by the AS, consumed and verified by the RS,
and issued to and carried by the RC. The contents and format of the access token are opaque to the RC.

=C2=A0

[Denis] Already discussed above.

=C2=A0

Grant

The process by which the RC requests and is given delegated access to the RS by the AS through the authority of the RO.

=C2=A0

[Denis] Already discussed above.

=C2=A0

Cryptographic Key

A cryptographic element binding a request to a holder of the key. Access tokens and RC instances can be associated with specific keys.

=C2=A0

[Denis] Change into:

Binding key: a cryptographic key used by a client to bind an access token to a client instance

Some explanations: cryptographic key is a general term. In the context of GNAP we want that key to achieve a specific function:
to bind an access token to a client instance.

Resource

A protected API served by the RS and accessed by the RC. Access to this resource is delegated by the RO as part of the grant process.

=C2=A0

[Denis] We don't need this definition. Already discussed above under the wording" Protected Resource".=

=C2=A0

Subject Information

Information about the RO that is returned directly to the RC from the AS without the RC making a separate call to an RS.
Access to this information is delegated by the RO as part of the grant process.

[Denis] We don't need this definition.

Some explanations: an end-user may wish to know the attributes stored for him by the AS.
However, no information needs to be returned to a client about a RO.

Denis


Denis
Hi everyone,=C2=A0

I wish you all a happy new year.

I just created a PR (https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/155) that takes into account the various feedbacks. The automatic build process is not working, but you can see the diffs and build the html locally if you prefer. The definitions have also been updated on the wiki (htt= ps://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology) if you prefer to check there.=C2=A0

Feedbacks welcome before we move to pending merge later on.

Cheers
Fabien


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


--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000d534e605b8b60ccf-- From nobody Tue Jan 12 08:18:48 2021 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D816F3A0ADA for ; Tue, 12 Jan 2021 08:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.009, NICE_REPLY_A=-0.262, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eO-1BwZNGk8D for ; Tue, 12 Jan 2021 08:18:45 -0800 (PST) Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 817FC3A0AD6 for ; Tue, 12 Jan 2021 08:18:44 -0800 (PST) Received: from [192.168.1.11] ([90.79.54.243]) by mwinf5d40 with ME id FsJr2400e5Eqqlm03sJtKe; Tue, 12 Jan 2021 17:18:56 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Tue, 12 Jan 2021 17:18:56 +0100 X-ME-IP: 90.79.54.243 To: "yaronf.ietf@gmail.com" , Leif Johansson References: Cc: Mike Jones , "txauth@ietf.org" From: Denis Message-ID: Date: Tue, 12 Jan 2021 17:18:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------74E38276B69D2AE97ED9609A" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Interim meeting next Tuesday X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2021 16:18:47 -0000 This is a multi-part message in MIME format. --------------74E38276B69D2AE97ED9609A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit +1 There is less than one hour left. Denis > Could you send a calendar invitation for this including the join link > so it’s in people’s calendars? > > Thanks, > > -- Mike > > *From:*TXAuth *On Behalf Of *Yaron Sheffer > *Sent:* Wednesday, January 6, 2021 11:09 AM > *To:* GNAP Mailing List > *Subject:* [EXTERNAL] [GNAP] Interim meeting next Tuesday > > Reminder: we will be meeting next week to review the latest with the > GNAP core protocol and discuss issues. > > See you all there! > > Leif and Yaron > > Jan. 12 2021, 17:00-18:30 UTC > > Join with Zoom > > * Working group status (chairs) > * Draft update (Aaron) > * Terminology update > * Open issues: > o Access token request/response format > > o Interaction request/response format > > * AOB and next steps > > --------------74E38276B69D2AE97ED9609A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
+1

There is less than one hour left.

Denis

Could you send a calendar invitation for this including the join link so it’s in people’s calendars?

 

                                                       Thanks,

                                                       -- Mike

 

From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Yaron Sheffer
Sent: Wednesday, January 6, 2021 11:09 AM
To: GNAP Mailing List <txauth@ietf.org>
Subject: [EXTERNAL] [GNAP] Interim meeting next Tuesday

 

Reminder: we will be meeting next week to review the latest with the GNAP core protocol and discuss issues.

 

See you all there!

 

                Leif and Yaron

 

 

Jan. 12 2021, 17:00-18:30 UTC

Join with Zoom

 



--------------74E38276B69D2AE97ED9609A-- From nobody Tue Jan 12 08:35:36 2021 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EA33A0B39 for ; Tue, 12 Jan 2021 08:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 EP_hFfDpjqu7 for ; Tue, 12 Jan 2021 08:35:33 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD7BC3A0B3A for ; Tue, 12 Jan 2021 08:35:33 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id o6so5303372iob.10 for ; Tue, 12 Jan 2021 08:35:33 -0800 (PST) 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=7fEMAkkkBL4TZOSxfH36rPEEl96fmh3DnnlOg7r41AU=; b=kJgR30VcryFExAS/gOG59AW3wkOBlesnWJkG6aVif8hXT1rJP7eWlHvuEyr1OzSLOk OpS2Sk5mLPibAjIbyN4iRT9Vu/ArgnVEDIdiD1OjV/r/NOtCt7Bn3IjZhmJA5GCYG87q KWdIJYVNMdOU7lEqs9srhTrWxf29dUqRecUjzNWWTABb5QitiGqpEAPKm+mc1fzQRDBh uQ95tdjenQwJWRyn61fVFoYrwYwMH2pjSI8x0EhKyVLGeJp6jHpiqNRrweMP6sjzvlcp zJKb5utdiIdoWmWrt4s1v59W9g8Wwt+qy0XLRmZzL1dm81GtN6FzS2wAn6OOyCHT3bxF goGQ== 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=7fEMAkkkBL4TZOSxfH36rPEEl96fmh3DnnlOg7r41AU=; b=Ue5lTvlxH13DG5L08rkfIxoY16jvTwaOIsNG7EgL60Kt3GFOphPpjE8i23jBXayM7O b2JnzLdqZC1b9zGrAVFwe8I+50xk7o91iPFgb3IGppdF+3yWL6NXDUbdOD+Bl1KbnDjP V+ONkNIQ8ACaqs9iTk+wm1e9ELFZ5JWT3Hy9Y3rMtm80S5CPhbjhTh8vmqK2iRtC8kID wPdaMXBfSzZIdIp7PIp8VRz6+OP/OdKYNrA1pEItHt7KiNSc+4yFvvjTd/cNtCaDZbf1 z729WZh4wyDpDgUfRMzTSW12dJqP8uNtSTwBIjYdgm8fUjdABbsQKYdSc4fTtMC2EVZe OSgw== X-Gm-Message-State: AOAM532QzEZpWNE5e6enJzkPCTefLC8YbxiZ0VuaXK+a0RRJw12AdjWJ F2h6tSQOeL5QMK9y2uH7dwSL2pEdhg8pSg== X-Google-Smtp-Source: ABdhPJxLcxpMO+A2mqpHwf4jUzt5A3suPBeiz22x7MqQqzH6jhPjYauUJh21Q6612ZymJUPv6KCquw== X-Received: by 2002:a02:cf30:: with SMTP id s16mr173178jar.144.1610469332160; Tue, 12 Jan 2021 08:35:32 -0800 (PST) Received: from mail-io1-f49.google.com (mail-io1-f49.google.com. [209.85.166.49]) by smtp.gmail.com with ESMTPSA id a9sm2014018ion.53.2021.01.12.08.35.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Jan 2021 08:35:31 -0800 (PST) Received: by mail-io1-f49.google.com with SMTP id r9so5335014ioo.7 for ; Tue, 12 Jan 2021 08:35:31 -0800 (PST) X-Received: by 2002:a92:da85:: with SMTP id u5mr3582486iln.249.1610469330804; Tue, 12 Jan 2021 08:35:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Parecki Date: Tue, 12 Jan 2021 08:35:19 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Denis Cc: "yaronf.ietf@gmail.com" , Leif Johansson , Mike Jones , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000062669305b8b69c54" Archived-At: Subject: Re: [GNAP] Interim meeting next Tuesday X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2021 16:35:36 -0000 --00000000000062669305b8b69c54 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Denis, the meeting link is in the email Yaron sent last week. I also added the meeting to the events.oauth.net website and the link will appear there 15 minutes before the start: https://events.oauth.net/2021/01/gnap-interim-meeting-Z7Nw3hc8AIOM You can also subscribe to the ics feed linked from this page if you want all the GNAP events on your calendar: https://events.oauth.net/tag/gnap Direct ics link to add to your calendar: https://events.oauth.net/ics/tag/gnap.ics Aaron On Tue, Jan 12, 2021 at 8:18 AM Denis wrote: > +1 > > There is less than one hour left. > > Denis > > Could you send a calendar invitation for this including the join link so > it=E2=80=99s in people=E2=80=99s calendars? > > > > Thanks, > > -- Mike > > > > *From:* TXAuth *On > Behalf Of *Yaron Sheffer > *Sent:* Wednesday, January 6, 2021 11:09 AM > *To:* GNAP Mailing List > *Subject:* [EXTERNAL] [GNAP] Interim meeting next Tuesday > > > > Reminder: we will be meeting next week to review the latest with the GNAP > core protocol and discuss issues. > > > > See you all there! > > > > Leif and Yaron > > > > > > Jan. 12 2021, 17:00-18:30 UTC > > Join with Zoom > > - Working group status (chairs) > - Draft update (Aaron) > - Terminology update > - Open issues: > - Access token request/response format > > - Interaction request/response format > > - AOB and next steps > > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000062669305b8b69c54 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Denis, the meeting link is in the email Yaron sent last we= ek.

I also added the meeting to the events.oauth.net website and the link will appear there= 15 minutes before the start:


= On Tue, Jan 12, 2021 at 8:18 AM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20
+1

There is less than one hour left.

Denis

=20 =20 =20

Could you send a calendar invitation for this including the join link so it=E2= =80=99s in people=E2=80=99s calendars?

=C2=A0

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

=C2=A0

From:<= /span> TXAuth <txauth-bounces@ietf.org> On Behalf Of Yaron Sheffer
Sent: Wednesday, January 6, 2021 11:09 AM
To: GNAP Mailing List <txauth@ietf.org>
Subject: [EXTERNAL] [GNAP] Interim meeting next Tuesday

=C2=A0

Reminder: we will be meeting next week to review the latest with the GNAP core protocol and discuss issues.

=C2=A0=

See you all there!

=C2=A0=

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

=C2=A0=

=C2=A0=

Jan. 12 2021, 17:00-18:30 UTC

Join with Zoom

=C2=A0=



--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000062669305b8b69c54-- From nobody Tue Jan 12 09:03:20 2021 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2451A3A0CDC for ; Tue, 12 Jan 2021 09:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQ63mhhhwk0F for ; Tue, 12 Jan 2021 09:03:15 -0800 (PST) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8B1E3A0CE5 for ; Tue, 12 Jan 2021 09:03:15 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id q1so5516184ion.8 for ; Tue, 12 Jan 2021 09:03:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oK5xi4XieMKdteFxzvWgEtbC0qmImi9jRRAIktMFwfs=; b=jfZmGZFcZqFED1oFWTX1yAeU30nvFUWmmW7KvX5LS8pAYzgJ80AX5Qo+XEOcB4rzG2 g3yIX3WnNdr1mi8EnyLdcU04Dq4UfqchGZ0qBA+BAQmkjBf2CF58umUKsKKXLbTujjOn Kn5vSEPnAXuLHHKo8Fa7AziAppHqGP71TpnI4sPHODyPtzd7owod/UdyFqDJEh+Zs3nX OYOS1ORNyfZ20SvrYSyhXDV+hEh0BDhMptmghvVdAnAiv3/LK3miSoipu+zCqqBPGxjZ 7mdLW0h/JGf1jOzI5xnMgUApZ/N3kWyGoxro1klxT0y2Zt940Re2Jq50u0AjOfPVXwai Vb8g== 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=oK5xi4XieMKdteFxzvWgEtbC0qmImi9jRRAIktMFwfs=; b=Fu7mRAow0pO/cr0KIbgHzy+p6NR2FrNdvFdqpMClhBj2g8ctQQuPH20dq6fwawVk61 3BK14nXPnMCqRraMbXCzlEFyXQ9+zrKebguCVCmCnAt9qlfpyZd0SAb/v2f/OgIL+Ud4 PCWgbO/wDz3XaV+utIYz6VpjPNk7seSX8K7ClSusl/w0fLlg/tq/wo48ejRq3V2pjy6o 3GDHWD6WFtjgjt27kHLBMFEy1XWxFwMkooG7bzSaOtwoSxxPefMJzeO22VItj+0UnqFS l3cOIrCNpdnP+MrsxaBq/b7Nph0u/GXQ1HntXEQmgkL4QGjqVKEAW0tGK4i1/dIbx+9h CfGw== X-Gm-Message-State: AOAM530ddq8XOAUukGTdcVZo8qxepS4qvCIszsL8skqU+ZXyimv4wixY TSKzDtJkXEB5T/eJGjC5iaDThdLo9RuT+6MUAv8= X-Google-Smtp-Source: ABdhPJzue4xDNrlALB9qxBez/pasV6hbNRwNLoMQMlPdXCmyv3wn52+XICizFCc34YAPaO9RNvfJBftetvqTDEf/AYo= X-Received: by 2002:a02:5148:: with SMTP id s69mr305901jaa.8.1610470993467; Tue, 12 Jan 2021 09:03:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Tue, 12 Jan 2021 18:03:02 +0100 Message-ID: To: Aaron Parecki Cc: Denis , "yaronf.ietf@gmail.com" , "txauth@ietf.org" , Leif Johansson , Mike Jones Content-Type: multipart/related; boundary="0000000000007e75ad05b8b6fff3" Archived-At: Subject: Re: [GNAP] Interim meeting next Tuesday X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2021 17:03:18 -0000 --0000000000007e75ad05b8b6fff3 Content-Type: multipart/alternative; boundary="0000000000007e75ac05b8b6fff2" --0000000000007e75ac05b8b6fff2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi there, It seems it's asking for some intuit authentication, is that normal ? [image: image.png] On Tue, Jan 12, 2021 at 5:35 PM Aaron Parecki wrote: > Denis, the meeting link is in the email Yaron sent last week. > > I also added the meeting to the events.oauth.net website and the link > will appear there 15 minutes before the start: > > https://events.oauth.net/2021/01/gnap-interim-meeting-Z7Nw3hc8AIOM > > You can also subscribe to the ics feed linked from this page if you want > all the GNAP events on your calendar: > > https://events.oauth.net/tag/gnap > > Direct ics link to add to your calendar: > https://events.oauth.net/ics/tag/gnap.ics > > Aaron > > > On Tue, Jan 12, 2021 at 8:18 AM Denis wrote: > >> +1 >> >> There is less than one hour left. >> >> Denis >> >> Could you send a calendar invitation for this including the join link so >> it=E2=80=99s in people=E2=80=99s calendars? >> >> >> >> Thanks, >> >> -- Mike >> >> >> >> *From:* TXAuth *On >> Behalf Of *Yaron Sheffer >> *Sent:* Wednesday, January 6, 2021 11:09 AM >> *To:* GNAP Mailing List >> *Subject:* [EXTERNAL] [GNAP] Interim meeting next Tuesday >> >> >> >> Reminder: we will be meeting next week to review the latest with the GNA= P >> core protocol and discuss issues. >> >> >> >> See you all there! >> >> >> >> Leif and Yaron >> >> >> >> >> >> Jan. 12 2021, 17:00-18:30 UTC >> >> Join with Zoom >> >> - Working group status (chairs) >> - Draft update (Aaron) >> - Terminology update >> - Open issues: >> - Access token request/response format >> >> - Interaction request/response format >> >> - AOB and next steps >> >> >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000007e75ac05b8b6fff2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi there,=C2=A0

It seems it's a= sking for some intuit authentication, is that normal ?

=
3D"image.png"

On Tue, Jan 12, 2021 at 5:35 PM Aaron Parecki <aaron@parecki.com> wrote:
Denis, the= meeting link is in the email Yaron sent last week.

I al= so added the meeting to the events.oauth.net website and the link will appear there 15 minut= es before the start:


You can also subscribe to the ics feed linked from this p= age if you want all the GNAP events on your calendar:

<= div>https:/= /events.oauth.net/tag/gnap

Direct ics link= to add to your calendar: https://events.oauth.net/ics/tag/gnap.ics
<= div>
Aaron


On Tue, Jan 12, 2021 at 8:18 A= M Denis <denis.i= etf@free.fr> wrote:
=20 =20 =20
+1

There is less than one hour left.

Denis

=20 =20 =20

Could you send a calendar invitation for this including the join link so it=E2= =80=99s in people=E2=80=99s calendars?

=C2=A0

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

=C2=A0

From:<= /span> TXAuth <txauth-bounces@ietf.org> On Behalf Of Yaron Sheffer
Sent: Wednesday, January 6, 2021 11:09 AM
To: GNAP Mailing List <txauth@ietf.org>
Subject: [EXTERNAL] [GNAP] Interim meeting next Tuesday

=C2=A0

Reminder: we will be meeting next week to review the latest with the GNAP core protocol and discuss issues.

=C2=A0=

See you all there!

=C2=A0=

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

=C2=A0=

=C2=A0=

Jan. 12 2021, 17:00-18:30 UTC

Join with Zoom

=C2=A0=



--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000007e75ac05b8b6fff2-- --0000000000007e75ad05b8b6fff3 Content-Type: image/png; name="image.png" Content-Disposition: inline; filename="image.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_kju8tbar0 iVBORw0KGgoAAAANSUhEUgAAAdMAAAFHCAIAAAB1azGvAAAgAElEQVR4Ae2dfWwj533nDf9joIDt GL3EF+CuzqEJkksK5JoLcGjRNofLoQHSA053OcaIWlx0CBTXp+Ks3h9ab+TkrDjRurFcR7YTIbbS vZPbc10rL93pZHwsxTVFiUvTO6JlabmyudTKJLU0JZriLjlLkcvVc3jmjcPhUJohORxR8yWI3eHw ef085IfP/OaZ0R35vet4ggAIgAAI9JLAHb2sDHWBAAiAAAjk967DvJjygwAIgECvCcC8vSaOH3wQ AAEQgHlhXhAAARDoNQGYt9fE8WsPAiAAAjAvzAsCIAACvSYA8/aaOH7tQQAEQADmhXlBAARAoNcE YN5eE8evPQiAAAjAvDAvCIAACPSaAMzba+L4tQcBEAABmBfmBQEQAIFeE4B5e00cv/YgAAIg0L55 ryQ2L/IrS8shPEEABEDAhQQu8itXEpvt/Yq0ad4ric1Y7LIgCAQPEAABEHAlAUEQYrHL7cm3TfNe vLgC7bryw4ZOgwAI1AkIgnCRX2lj2tumeZeWQ/XKsQUCIAACbiWwtByCed06+Og3CICAQwRgXofA o1oQAAEXE4B5XTz46DoIgIBDBGBeh8CjWhAAARcTgHldPPjoOgiAgEMEYF6HwKNaEAABFxOAeV08 +Og6CICAQwRgXofAo1oQAAEXE4B5XTz46DoIgIBDBGBeh8CjWhAAARcTgHldPPjoOgiAgEMEYF6H wKNaEAABFxOAeV08+Og6CICAQwRgXofAo1oQAAEXE4B5XTz46DoIgIBDBGBeh8CjWhAAARcTgHld PPjoOgiAgEMEYF6HwKNaEAABFxOAeV08+Og6CICAQwRgXofAo1oQAAEXE4B5XTz46DoIgIBDBGBe h8CjWhAAARcTgHldPPjoOgiAgEMEYF6HwKNaEAABFxOAeV08+Og6CICAQwRgXofAo1oQAAEXE4B5 XTz46DoIgIBDBGDeroE/ODhIF/afDyYHfvrWn//inWj6RrV20LXS7SyoVKmxl3b/y9m3/vilt3/+ 9k6hfMvO2lA2CIAAgXm79iG4snvz96Yjd59akJ7/4ong3JvXula6bQXVbh8M/+2lD4+fl5p976P+ //Z/13Olqm0VomAQAAGYt3ufgYf+LqZqV9p4YGKxWrvdvRpsKemVaEbX7PtO+3+5tmNLZSgUBEBA JIA5b9c+CJ+aXNIp7O5TC5H3rnetAnsK+rP5y83NnngtYU9tKBUEQIASgHm79jn4rSeXmxUWTd/o WgX2FPQ/f7nR3OzvezftqQ2lggAIUAIwb9c+B3+xcPVDp/1ai/3+s5Hbt4/7SbalzcJHHpODvFLj /9n/Ciwm8l3jgoJAAASaCMC8TUja3fGBUP2vf7OmmvfzT4cvbBXaLax3+Q4OyE/D6d+YWJRaft9p /1++vrV/67iHp3sHCDWBgA0EYN5uQr19cLB4Jf+Uf+uvL167sV/rZtE2l7WZu/lMYOv5YDK+K9hc FYoHARBAtAGfARAAARDoOQHMeevIq7WD4v6t3VI1uVfOC9VSpXardZT24IC096zX59BWe80+ODju AWuHcKJaEGiHwMkx79Pntx5/7Yr6/MHC1dReWYfkx0tJNcHjr1158UK6KMYE8jer/yey/Sd/vfaZ J5c//NjrHzrtv//br//2Uxe+8fL6q9H3hYo+bvCBUH36/NZp5l2rz8d+dWXtWlFt1WuXd7Xtefy1 K+/sHHawf/aNbW3673s3V7frpUnFzl5I69LE3i+pNf4qtmu1zVL6F0IptRBsgAAIdEjg5Jj300+G 7jm1oD4/NrHYvJb2d374hprgnlMLX/zRxeyNyvXyra/81Vv/RLmISz1FJm3c/+3Xv/HyJd3k9718 +XNTF3Qpzbz89fHzf6+5SOFbbFzbnntOLbx2OXfIiH75Jyva9B957PWX+Ywu/R/OXNSlObdevyzi O7+6YqadzWn+wwtRXUV4CQIg0DaBE2VerS8+9l1j82rTfPFHF/nU9X/7/JvanYbbXzn7VrZYUSl3 0by66o4w7wsr2vQfHj//8oqBeXVpumTeFbX72AABEOiQgKvN+wfPRv7zX72l9VSr7ftO+7/vrV/W BfN2+LFDdhBwOQFXm/dDp/3qtQ///PHAZ38Q+t3pyL9+Ovyx78qLW7Ui/vj3gmrAt3/N+202ru2U +e0/egFzXpe7At3vJgFXm1fyzr2PLvzJS2vLm3s7pWrl1u1C+dabyeuDc283W+n54HsS+91S9Tvc lYdeiWmfX2maPv+rpy5oEzz0Suy/v3qZT9Xv5PCtJg/aHW2Yf+t9XZMeeiV2X+Oldx/9zutfm3tb l+wvX5f73s1PH8oCAbcSgHkXvvwTXp3Mqh+Dm9XaF56r3/JRsvDnn76gJmjeeGPr+r2PNlw9/Gc/ u9ycTLun9+bV1i5tHxwcfPQ7Ae3PzG89GTp8iUVzIdgDAiBgiYDbzfvJyaXM9fqpMy276cX3dCa9 59GFvZst7xoe3iro0o/Mx7QFNm8fB/PWbuvN+5knl2He5sHCHhDoIgG3m3ecjbeiGbiSb15qlsjd bJUe5m1FBvtBAAR0BFxt3l//1nn20q6OiPoyviv802+/rj0Mv/vUwuX39VcuqOlhXhUFNkAABA4n 4Grzfuy7wdDVlrcTy1zf/2iTeTey9evBdGRhXh0QvAQBEGhFwNXm/fj3gpH3Wpo3W6zAvK0+N9gP AiDQCQGYF+bFGbZOvkHICwLtEIB5+8q8P+n06uHmzwjWNjQzwR4QsJsAzHu8zPuz1fcPGfLP/iCk PePXxn0bmguHeZuZYA8I2E0A5nXSvONN17A9v9jyUrFssaJbLwzz2v31QPkgYBMBmNdJ8/7FwlXt HPbuUwtfm3u71UiffWNblxjmbcUK+0HgmBOAeZ0079+uZO55dEHr0488dn7T6GKN3VL1iz++qE15 96kFmPeYf7vQPBBoRQDmddK84a3Cbzyuvy/ag/97NVeqqgN2cECyNyrffCWm0y7MqyLCBgj0HQGY 10nz7pYqv/es/r489532/9ELK88H3+Mu7/589f3v/r/E7zelkSyMOW/ffd/QYBCQCMC8TpqXEPLs 4nvNk1nDPfc8uvCfftpwH/demrdUqeVv3qrU8HcwoQ4Q6AIBmNdh896s3ja8F7BOvvc86v/a3Ns/ W31fu79n5l27VvzxUurRf3j3+eB7h9ytrQufRxQBAu4gAPM6bF5CyPs3Ks1nz7SGvfvUwu/88I2t fPnVt5wx7/OLydcu7/7xS2tr14pvJlsSc8dXBr0EgS4QODnm/Xc/uvjpM8vq83d/+MZb6Rs6QgM/ jaoJPn1m+Q+ejTSnUbPslqqffzqsTf8vJ5fiuy3/Kns0feMzT9Yb8Okzy4/9quUtKNVapI3twv43 X4l9anLp3sY/D3H3qYVPTS79j59d/kCg59z+4dKutj2/PXXh7zV/V1gq6mtzq9o0n3vqgu+dD3TV aV/ePjj43NQFbZZ//2NedzPMpcTe3/DXJl678lwwuaP5S6DacrANAiBgnsDJMW8id/PdHUF9XtkV yrdu60Bs5ctqgnd3hETuZnMaNUvt9kF8t16glLFS05eppi/fuq0t/N0d4f0bxvdcV7NoN2q3Dzay pVdW3v/zX7zz5Z+s/OEM//Crl19eybyzI1SVSq+Xb2mriO/evF7W36n9vXwDh/juzeJ+TVtR87a2 zHd3hM0Pblaa0F3ZFa7s3rx2fb85O/aAAAhYJXByzGu150gPAiAAAk4RgHmdIo96QQAE3EsA5nXv 2KPnIAACThGAeZ0ij3pBAATcSwDmde/Yo+cgAAJOEYB5nSKPekEABNxLAOZ179ij5yAAAk4RgHmd Io96QQAE3EsA5nXv2KPnIAACThGAeZ0ij3pBAATcSwDmde/Yo+cgAAJOEYB5nSKPekEABNxLAOZ1 79ij5yAAAk4RgHmdIo96QQAE3EsA5nXv2KPnIAACThGAeZ0ij3pBAATcSwDmde/Yo+cgAAJOEYB5 nSKPekEABNxLAOZ179ij5yAAAk4RgHmdIo96QQAE3EsA5nXv2KPnIAACThGAeZ0ij3pBAATcSwDm de/Yo+cgAAJOEYB5nSKPekEABNxLAOZ179ij5yAAAk4RgHmdIo96QQAE3EsA5nXv2KPnIAACThGA eZ0ij3pBAATcSwDmde/Yo+cgAAJOEYB5nSKPekEABNxLAOZ179ij5yAAAk4RgHmdIo96QQAE3EsA 5nXv2KPnIAACThGAeZ0ij3pBAATcSwDmde/Yo+cgAAJOEYB5nSKPekEABNxLAOZ179ij5yAAAk4R gHmdIo96QQAE3EsA5nXv2KPnIAACThGAeZ0ij3pBAATcSwDmde/Yo+cgAAJOEYB5nSKPekEABNxL AOZ179i7q+f81ODAwIBnKuyubqO3x5QAzHtMB8aeZq3NDA2YeYyey9rTAOdKddi8pc3wuZnJ8ZHh IY9HHAHP4NDw6PjkzLlwqtSCSn5jcX56YmxkaLAhz9Qsx2crLfIQQvKbi/NiVXI2z+DQyOjEUbla l4d37CAA89pB9diWadK8nrE2zUvL90wstFKJk1wq+dTm5mYqf4iy7GpeaW1ujE64VeMODw8PD0kC pvuGJriUvlnZ8PSImoJammYZrO8Znlo0+HEsbZybHFYTyTVq/hscnVlsqsqubqPcwwjAvIfROXHv yeYdnU/Z0rXU/OjAcTWvLR02U2h+YULU7uDozMKGVvyV/MbirKzk4dkNrXtT86OiP4fGZxc3G/Jk 17hp6T2PfhRL/Iws68GRybkFfjNfEsuslLIbYW5mXFby4Pi5TW1dZvqANF0nAPN2HelxLtBe85YW Jzwwr278s+fG6KRzcDJseCRQ2Zgdoe83HClszg7TfcMza4aKLIWnxKDR0DRffz+/OCkK3jMyHTaY DRNCKpvnxqVgU6uCdU3HSxsJwLw2wj1+RVs3b0W06YAYfsivzU+NjYiHvJ7B4dHJ2fqRq+wXzYHt wPDshgqgkuXPzUyMDkuHyzTzxPQ5fbBS8s3Q9BopbcxPivWMzG3SwCU3Tgumwef82rnpcRr4HBig 4cvx6XNrebUWQojUDs/EYqWyyU2N0kN6WiAhxCjOW0mF56cnRuXYq8czZNguKi0z7de2o74tIx/j GtpZf5/kN8KL/IY2DFIJT9IZr2dysS5WTQbazbXFcEOeytqMKGvP2LnDDmdK5pI1VoZXdhCAee2g emzLtG5eIllgdJ5fnBwaGKByGh0dUYKUgxML0vyqxM9NTcrHs0OjE5OTk5MzSiCytDYrHx8PDo+N j4+Pjw5LUU/PyAyvmQim5ujsb3BqYVGa0g0MDEjmLS3QufTAyPT81LDHMzw+NTM7OzM9MSqVMjy1 WJeaLOlxLiyZiEZRW5i3siE3a4CegRobG1O75Rmb0x77m22/8ahvir0aaJifGqes712bFuemUu/r u1tvVaTflYGhFrPkes68xFImW9+PrR4TgHl7DNzZ6tox7xS13uDw8NDI1IJ6dqayOT8mRiK1dtgQ D5IbjpsJyS+KYU7P6CxfF2QlG5ZikoOTi6p7xSjxgGd0fGxwZIpbS2Xz2awYqZTNK5+LqhPM89Pi RG9oShV4aUGaHo+NDQ5PnuM3s/l8VoqT6ue88ix9uOHYvJJanKJFak4xmm9/vWENW5tSOGFgaHyu 9TKGhhykwkvqHRiemNcfGTSmlF9J5JUfGcMkyk4FZrsnUZVy8H9nBGDezvj1We62zatMP+v9rYTF BbID4/WVDEbmlaZ8nnGuKfYoG6luAMm8ovYaj5il+HGDD+V25Llx8XdhMiwfl8vmHRgYaTxl1Rxt CIu/KMMz9ZCIVGZlg5udO8etye210P46m8atysa8urTBMzgyPjUzz4XXUtLpr8ak6qv62TJ6nEHX hM0vhDey6q+UmlDcUGw63jKkoUkvT8IHpUMBzRvY7CUBmLeXtB2vSzavNhzbvN04aZUMNaA/kU6I LErNGwbmlRMZKkGK63pUdctpPeML9cmxSEwx7+h8k77lPGpMWTGvplUydP2cV0LhGZ3daKEzMZ+V 9h8yupUsPy9FnTW4RQvPcnyL9byV1OLc5IgUUVFzeYZGx6fnFtYa1/PmpbN4nkkzl4nUE7eKIh/S EbzVLQIwb7dI9kU5Js1bjwAQIpnX4EstH66PzKkT1GbzyueKBgZHxpofcrh3eJaeRSOqytXXKlHZ vIMG15/JJwDVk1GyeQeneDW3vKE3b2VzToo+DwyNTs6co4uwmk1kqf36GptfV+jyrvmZqXHx1J+q 08HR6fq5Sn2uUmpt8dzc9OS4GlwX8w2NzYbVH6g8J66f8KhTf30h2tfyuJlLrM2I7W4SgHm7SfPY l9V2tMFAZWbMq0xBVckYbMhnwFTzNs9sZfMONUUGiPLDoMY85ArVOXB9RPTmJYSU1uYn65cr0Gj2 yPjU3KJmEmyp/fW6zGxV8pv8wtyUfJqQnoE7bO4tlSguzJ2dkNvsUSMqlUVxMcRA6wUUmhbJS9aG ZsQlH5o3sNlLAjBvL2k7XpdD5jV3twT5yL4e+FVwqeY1cIUcDFGum1PNK8+jlSKa47zKO3Qeem5u ekIzDR0cnV2TNCgXZ679SonW/ldOE3pMaVMqOyuuMxHXnUntVGK3U5oFvi2aUVoQQ+MDhgGgFnmw u/sEYN7uMz3GJfbavBVZjKa+5keZ1zOlnEerE5bPLamHztbNWy+LlFL8OfkCMXkRmKX2a0qytCkf PAxON0VIWhejXGuhRGrkgR2cMr5eo16QsqqsORBeT4OtHhCAeXsA+fhU0WvzKqfhBrVXW7XCcZR5 Dc7yEXmyp65t68i8YsNkNckH43KbTLXfqF+bCzOT46OjU9rIuT6dzrylDW6a5pk5bP4qm1fttwJi YKRhKbK+KvWCi6azmPqUeG0zAZjXZsDHq/hemFeNuYpdV46DJzSXO0hMSvz06OjENKeGVY80b7N6 5Sz1yxTMmre0wc1MTUzMa6+YkIeKn6brCZTos4X2Gw11lpOWPQ+3DOMqZ/rqSzrkKj2jLSWqXIo2 qDkKUC4pNrz/jti0SoqbEK/Q8IyKlwYatRf7ekUA5u0V6WNRj73mlZUxNK293YByP4HBsTnNhb75 tXnxHgKe0Xk1InuUeT0eT0Mh9D4E4qKr4RlVoGbNS6TVxJ4R3aqC0sa8WGb9Cg/z7TccYXpfBvGS E8/wxOzCmnYFGT3Hxk3Lp9hGNFefleQrRAY8I5Pziw2reCv5zfD8lFyihh2tu7ShrNagdXHqHXNI iVY0OyHfMWdoUr7u0LC92NkjAjBvj0Afj2pk8xqsMNDtqq9lkCK19ddqR5rXNqiXXnkGh0eGhyfk dbnq1bcD9IYNY+NjytXD4vRMLU+JTLQ8wzY8PU8t5hkaodcgjxlegmzavETXqrHxMdouUZIDjXLS pWzZ/npPGrfyvHJHMhGyxzM4NDSo3HKX7hocndHd5KaSWtTcJJLeo0LKUx+lobE5zTWBSoWlTU7W cj2ldmto3CiXkhv/95AAzNtD2M5XZdq89bP5FsxL12nNTYj68gwOjU7Xz/bo7zgzJC7f2mxcR3XU nJcuFSttLih33qF3zJmYqQcrRLrmzaveB0e88zjVk0e6k8/8oq5dakrFzOK9eqbmDNK1HOFKiudm p4zucn4u3FydVIx8M/VRel9e6Rehfo9z9TJugxrVfJo7o49NNF9/YZAVu3pGAObtGWpU1C4BeVVZ 85W+7RaIfCDgNAGY1+kRQP1HEoB5j0SEBP1GAObttxFzYXthXhcO+knvMsx70kf4BPQP5j0Bg4gu NBKAeRt54NUxJADzHsNBQZM6IwDzdsYPuUEABEDAOgGY1zoz5AABEACBzgjAvJ3xQ24QAAEQsE4A 5rXODDlAAARAoDMCMG9n/JAbBEAABKwTgHmtM0MOEAABEOiMAMzbGT/kBgEQAAHrBGBe68yQAwRA AAQ6IwDzdsYPuUEABEDAOgGY1zoz5AABEACBzgjAvJ3xQ24QAAEQsE4A5rXODDlAAARAoDMCMG9n /JAbBEAABKwTgHmtM0MOEAABEOiMAMzbGT/kBgEQAAHrBGBe68yQAwRAAAQ6IwDzdsYPuUEABEDA OgGY1zoz5AABEACBzgjAvJ3xQ24QAAEQsE4A5rXODDlAAARAoDMCMG9n/JAbBEAABKwTgHmtM0MO EAABEOiMwIky7/b2NX4lurQcwhMEQAAEOiHAr0S3t691ZtfDcp8c825vX1tbv5RKpTN4gAAIgEBn BFKp9Nr6Jfvke3LMy69EJe3u7Ozk8AABEACBdgns7OxkMplUKs2vRA+buHbw3skx79JyKJPJ7Ozs lEql/f39Ch4gAAIgYJ3A/v5+qVSS5Lu0HOrArodlPWnmzeVy+/v7t2/fPsADBEAABKwTuH379v7+ fi6Xy2QyMO9hvx7Se9KcN5fLVSqVg4ODozMgBQiAAAg0ETg4OKhUKjBvE5gWO2DeFmCwGwRAwAIB mNcCLEIIzGuNF1KDAAgYEYB5jai03gfztmaDd0AABMwSgHnNkpLSmTZvNZ9cjwR9HMsyDMv5AuHV rXzZWl3HN3WW5xhvNKdrYC0dYRl/rKDb3Z2XQiLIMKGtqlia+IJRHizn9Qcj6yeIb3eQoZTjTADm tTY65swrpCM+huH8kfUEveQimViP+DmG8UbSgrXq7E9dS4e5UFISmunajoV5A6uZbC6Xy2YpXz7A MQwXiudrpjuBhCDgIAGY1xp8M+YVtkIsw4USRa0FasVEiGO4SMai5Kw1z3rq/KqP7U/zhrYajiHK 2aifZXzRrJa6dR7IAQI9IQDzWsNswryFmJ9hAvFiU8HlQl5QtFDOxXkaixBDEUE+kZeFTI+jvdFk OurnWO9qjuTXfYxvNZ1eFROznC+0mqnPm4VsLBLwiqV4/aHVZEEqXl8IIURMKdbHsN5AJJal1qql w8oRO8PxWdrgWjG5GvJ7pXaFokqJur6YmfMK6fWwWBANtmh62LKKbJRjgvFMPORlWZ1VaQeaog1N aWq5qJdhw1Yn8Lq+4SUI9IIAzGuN8tHmLW8FGcYfaxavpqJiPMCyvshWrigIxWwi4mO40JYoVJqb 9QVC0a1sviBUSWHdT80VjufKNVITMlE/wwYTYtJanr4XiCbzRUEoZGIhjvFKU2p9IVRbLOPnk7lC USjmklE/y4WT1L1VIRFimFCiWK1SaZfTES/DBdczBbFdYS8NkDTMLKVOHG1eIR5kxYJo23JbvI+V p/utq6De9PmD4Vgmly82VWrCvITQdsk/IRra2ASB40cA5rU2Jkebl7qSCSeVya1R8blVL8PxGTVJ NRmmp6aorMtbIYbKQ3lPLM2/rp61KtNIRiAuEFLLRDjGt55XK6BukiaL+kIIqZUFoayUSYR4gNZP c1aTYYZRog10v+J18c10hGNkz6vV0I2jzUtTaOb9NSGfK9AGHFIFpSJ1raEu+YUp8xbp4QYmvUb8 sO+YEYB5rQ2ICfMe+e1vkIhYPTUGG07XZPNqjqPFOW+kLmmSX/VJ07qmdwhVlzeabS6EkFohGZWC CEp4gY3Q6hrMK69N0MzWy1TmUsIGTEebt5yJeBnWF16NJ7OicqX8h1UhNV+/YEKptwGa/KJpYkwD Pezhv3pKefgfBBwlAPNaw3+0eat01qqZpTaXX/es8l5dK+J0VeMO6teG9VuqcOnBuehZpRApMkEt rS+kluWlIEJRjCmIMVMD84otV8xc/z+YaDIcDck2tEpsQy2tTt3payGbiIYDNGTMsL7Qqris47Aq qHm1c3i1X+JGHVE96Ktvl3gYQKPjeIDAcScA81oboaPNS4rxAFVvPQyg1CCkY/FMsdZ4skh8s+5i vTSpaLWBCXFiy9GJrapgpXgiuTgnz3k1+s5SSWuEJGVtMeddzxYbH0LzagyxgKajetpxVllyq7aq Vi5k4hEfy9LggzTnNa6iY/NWafylAZbaCGyAwDEjAPNaGxAT5iXlZJhj2EBMWa8g1lArxIPKKTA5 YqDGXctJMXirxnk10qSO086g6fG/FHptivPK4is3mzfDc5orHGq5VR+jBBGkOK9ygQKN/zaseysL Bt4lRFpFEJLO9MkAq7moT40SV4vZdFYTtqBzXZZOx8UQs3EVHZq3nOF99NSmGhK3NrBIDQI9JQDz WsNtxryECGlqAXqMHU+mM+lkYjXsYxnWv5qV5o/FRJBl/XwyL5Tp2oawl5HXGjQFCsTZpdcXWk8X hLKQ34r46LRSXdvAsoFV8Z1CJhbk6GpWWoF+4iyelvNF08UyXQMRDvJ8iGX86+JyiUyEZbx8Ml+g ywnEhQfecDxLKyvQRReslzdcgSymZLyh1UQyk82kt9YjfpZhg3F5XRv98WH9/Fa2IAhCMZ9eDXLy qbvWVVg1r3wlRY5WH5OvpEjI9VsbVKQGgZ4TgHmtITdnXnrqqpBcDwfkFbScLxiJpbVXVlRzCXU9 r1+zblYvTWpebzSZWQ/5OZauLwuti0txpVZL63nFSKrXH17PyMuF9YXQJbQ8jbjSlbXRZLFWzUR9 LMsFYnlSza0HOJZlvRFxmVl9PS/DapcIG1ASsnE+SFslXR4dWW/oYH3BMq1VWUFMi2lVhVXz1iPR YlOjiZw+7mvQaOwCgeNBAOa1Ng6mzWut2JapJfPinFFLQHgDBPqSAMxrbdhgXmu8kBoEQMCIAMxr RKX1Ppi3NRu8AwIgYJYAzGuWlJSu1+a11jqkBgEQ6A8CMK+1cYJ5rfFCahAAASMCMK8Rldb7YN7W bPAOCICAWQIwr1lSUjrVvPir79b/0DVygAAIyATwV9/bMe/Ozk6pVNrf36/gAQIgAALWCezv75dK pZ2dnUwms7QcsqYh06mXlkP5vetWn3dYzSClt68bhBB+JZpK0b/ws7Ozk8MDBEAABNolIGk3lUrz K1HTLrWW8OSYd3v72tr6JUm+GTxAAARAoEe44u0AAA4tSURBVAMCqVR6bf3S9vY1a0I1nfrkmJcQ sr19jV+JLi2H8AQBEACBTgjwK1H7tEsIOVHmNf17g4QgAAIg4CQBmNdJ+qgbBEDAnQRgXneOO3oN AiDgJAGY10n6qBsEQMCdBGBed447eg0CIOAkgRNlXqxt6ORkLvKCAAioBLC2wezvEtbzdrB4EVlB AAQaCGA9r1nz4hq2di/YQT4QAIEGAriGzax2pZXJ0qXDuG+D9UvVkQMEQEAmgPs2WNCuat5cLod7 leGuUyAAAm0TwL3K2jRvpVI5ODiwlhmpQQAEQEAkgPvzWvsgqPfnhXmtgUNqEAABDQGYVwPDxCbM awISkoAACBxBAOY9ApDubZhXBwQvQQAE2iAA81qDZsK8tWSYaXiwnC8QiWUEazU5nbqWDrNMMFF2 uh2oHwROIgGY19qomjWvj09mpbV72Ww6sRryMowvmq1aq8zR1DCvo/hR+QknAPNaG2Cz5vXHitqC a7lVH8OGk32kXphXO4DYBoHuEoB5rfFs07xEDEEEZB1Xcwk+6ONYhmFYrz+8rgYiaoVkNOSX3uB8 oWiyUBObZ7S/vBVi2UhaSkBINsoxjD9WkLtT3gqyHJ+h71YLW9GQWJsY9ohn5QACzRGMZ+IhL8uG tsqE1IrpqNgs1huIxHNbiDZY+2wgNQiYJwDzmmdFU7Zr3mLMz7ChLTrnraYjHOMNJ7KFolDMp1cD LBtMiDPk/LqP8Ybj2YIgCIVsPOxlfKu5GiHG+4vxAONdzUntL6z7Oa9XMighpJaJcNIUW0iGaW1i ocVckvezbEDycy7qZXz+YDiWyeWLZUIKtIn+aDIvCMXcFv1pYBDntfbpQGoQMEsA5jVLSkpn3rzy dJWQWrmYWQ9yDBdJS7PNWlUQyspclVSTIYYJ0TiEOC+W7CxWVi3m88VD9udXfWwgLp64ExJBLrS+ HuAi4jSX0LeCCYEQ0fjhpHqerJblvbKvc6tehpHzE0nvXH0OLSaEea19OpAaBMwSgHnNkpLSmTVv w+IGhmF94XheCfLWhMx6OOAVgwpyuiA92ifCVohjOH9kPZHOUeUqjxb7a1lenthW02EuEC9mo17f ap4QUowHWDHSLAZrlSCHWFx5KyRPZal5vVF5zky1zzKBeD06XVUTKs3A/yAAAt0iAPNaI2nWvL5o Oi8/CkVBY1E6uRSP6tMFad4rznQl89JQaybOy5Fezh+OKTFZ4/3VZJj1RrM0yOv1reaIJGCB0P2S guueVbpZS4fpTLdICDWvb52Kmj6aUooJsapMxoP/QKC7BGBeazzNmle3tkFTCQ2nKkEBultIBBlG Ma+SrlbOp2MhLw0Nq4EC+p5ufzkRZP2xQiHml+IENOgQTpazPMfxWRrPOGrOWzdvla5C1s55y1u0 XVjPqwwJ/geBbhKAea3R7Ny8+VWf5iCfFGIBRjZcuZBJ5zTXWxRjATFlq/00rBDzs6FYLMjK6s6v +rx8fNXPKQvY6Gk47Wq2WobnGGk+3DjnpaFhGopW4s/VTARn2Kx9NpAaBMwTgHnNs6IpOzevtLQh spUXysVsIhIM83QNA58RqoV4kOUCq8lcUaDLC5JRP0tnsKTYYj9tT27VR9c0KMvJ6JoGr9eriJhG EaS1DYlcsVymSxZ86koKnXnlKAifzBWLhWwiEvB5Mee19uFAahAwTQDmNY1KTNi5eQkRMqtBL0vX 8gYiiXy1ll8PcCzri2aJkIlFAvJCX84X5BM5KULcaj9dPsZzDCMGe8X2iTECpuGcWk27njfIJ5Qz fXrzklphiw9IDfNH4rk0zzHi+ghrhJAaBEDgaAIw79GMtClMmFebHNsgAAIgYEAA5jWAcsgumPcQ OHgLBEDAJAGY1yQoORnMa40XUoMACBgRgHmNqLTeB/O2ZoN3QAAEzBKAec2SktLBvNZ4ITUIgIAR AZjXiErrfTBvazZ4BwRAwCwBmNcsKSmdal781fe2/941MoIACOCvvrdj3p2dnVKptL+/X8EDBEAA BKwT2N/fL5VKOzs7mUxmaTlkTUOmUy8th/J7160+77CaQUpvXzcIIfxKNJVKZzKZnZ0d6a/94F8Q AAEQaIOApN1UKs2vRE271FrCk2Pe7e1ra+uXJPlm8AABEACBDgikUum19Uvb29esCdV06pNjXkLI 9vY1fiW6tBzCEwRAAAQ6IcCvRO3TrnSfmTYiB8cx2mD6xwYJQQAEQMBhAidqzuswS1QPAiAAAuYI wLzmOCEVCIAACHSPAMzbPZYoCQRAAATMEYB5zXFCKhAAARDoHgGYt3ssURIIgAAImCMA85rjhFQg AAIg0D0CMG/3WKIkEAABEDBHAOY1xwmpQAAEQKB7BGDe7rFESSAAAiBgjgDMa44TUoFA/xCo/HKq 9PAnbnz1HjzbI1B6+BOVXz5l64DDvLbiReEg0GsClV8+JXzzQ7XTd5LH78CzPQK103cK3/xQ5Rc/ sG/wYF772KJkEHCAQOnhj0O77QlXm6t2+s7Sn/6mfeMH89rHFiWDgAMEbnz1Hq1BsN02AUrStgfM axtaFAwCThCAedtWrS4jzOvE5xd1gkB/EoB5dQJt+yXM25/fALQaBJwgAPO2rVpdRpjXic8v6gSB /iQA8+oE2vZLmLc/vwFoNQg4QQDmbVu1uowwrxOfX9QJAv1JAObVCbTtlzBvf34D0GoQcIIAzNu2 anUZYV4nPr+oEwT6k4Dz5n3mEXLrKnnxLp3I+u4lzNuf3wC0GgScINA78848SOJRUi7TXpYz5OoM mRFt+8QD5KUvkDOdXbt8dobcipLnOiuks+unYV4nPr+oEwT6k0CPzPvEl8hemcRPkZkHyJn7yYsP kqsZsneWPNElV8K8e9fzTc87mneZ2bO0HOrPDzNaDQJ9Q6BH5p05Q25dJjMazz7zJcI9SKe62mjD c18nmQy5VSa7HHn1jDyNfeohuvGLUyRzmRT3yB5Hzt6rj0XUzXsXiV4llx8hb54nexk6uY5+XZ+4 s7ltq9Iw5+2bDz0aCgKOE+iRec88SOMMa183iCrUzfsASZXJ1VPkqbvIzEMks0eIGEA48xB18dUz Yt77yeUMufqIXn9a8755lVr+1QdomhfPkFsZcrYXQWSY1/EPMxoAAn1DoEfmffwO8tIZGnAgeyRz nrx5ipz9pGxP1bzUsHvkZcWSzPkG876qzHO582RvRh+m0Jl394xc+BNfIsUyYZS89sx2pbpg3r75 0KOhIOA4gd6Zl1rvLvLifyT/OENPtd0idHr7hCbaoItIvPiMHG2gRr5an7cy5w0CxDrzXn1IMe8X qO6Z++WXMC/ivI5/5dAAECCE9Na8mjgv9azoRHXOS/dE67FgmFfzAcVdIjUwsAkC/U+gR+Z9dUZ/ pkuKA/zjA/UzbPRMWoa8ZBhtwJw3ZGa2qkuDtQ39/wVFD04ogR6Z9+wzNIa79gh58ZPkmQdozGHt Mrl1gc5w1Tnv458lmTKJP0LPpM2IixzqZ9hgXpj3hH4D0S13EuiReekZtlMkdZlGGOQrKc6Ss2L4 tW7eO8iLj5DdPZom8zJ5FXHe+kcS0YY6C2yBwAkg0Dvzmjq7dVd90cLZs+TWeYNVaKbK0QSUe5We krTtAfPahhYFg4ATBI6Tee8nV/dI6gx55i7y1L+hF7mlmtbt9kqjbayFgHmd+PyiThDoTwLHybx3 kOceJFev0gVnt/bojR2eU862HWPhqo6GefvzG4BWg4ATBI6XefvBsKpqdRswrxOfX9QJAv1JAObV CbTtlzBvf34D0GoQcIIAzNu2anUZYV4nPr+oEwT6kwDMqxNo2y9h3v78BqDVIOAEAZi3bdXqMsK8 Tnx+UScI9CcBmFcn0LZfwrz9+Q1Aq0HACQIwb9uq1WWEeZ34/KJOEOhPAqWHP147fadOInhplUDt 9J2lP/1N+z4CuIbNPrYoGQQcIFD5+RnhG78G+VpVrTZ97fSdwjd+rfJ3j9s3fjCvfWxRMgg4Q6Ay /73Sw5+48dV78GyPQOnhT1Tmn7B18GBeW/GicBAAARAwIADzGkDBLhAAARCwlQDMayteFA4CIAAC BgRgXgMo2AUCIAACthKAeW3Fi8JBAARAwIAAzGsABbtAAARAwFYCMK+teFE4CIAACBgQgHkNoGAX CIAACNhKAOa1FS8KBwEQAAEDAjCvARTsAgEQAAFbCcC8tuJF4SAAAiBgQADmNYCCXSAAAiBgKwGY 11a8KBwEQAAEDAjAvAZQsAsEQAAEbCUA89qKF4WDAAiAgAEBmNcACnaBAAiAgK0EYF5b8aJwEAAB EDAgAPMaQMEuEAABELCVAMxrK14UDgIgAAIGBGBeAyjYBQIgAAK2EoB5bcWLwkEABEDAgADMawAF u0AABEDAVgIwr614UTgIgAAIGBCAeQ2gYBcIgAAI2EoA5rUVLwoHARAAAQMCMK8BFOwCARAAAVsJ wLy24kXhIAACIGBAAOY1gIJdIAACIGArAZjXVrwoHARAAAQMCMC8BlCwCwRAAARsJQDz2ooXhYMA CICAAQGY1wAKdoEACICArQRgXlvxonAQAAEQMCDQU/NevLgiCIJBK7ALBEAABFxDQBCEi/xKfu+6 1ecdVjNI6a8krsYub0C+rvmAoaMgAAJ6AoIgxC5vJDavtmHRNs2b37t+JXH1Ir+ytBzCEwRAAARc SOAiv3Il0Y5283vX2zdvG5pHFhAAARAAAZjXcnQGHxoQAAEQ6JwA5ryQLwiAAAj0mgDM22vinf9a ogQQAIF+JwDzwrwgAAIg0GsCMG+viff7bzXaDwIg0DkBmBfmBQEQAIFeE4B5e028819LlAACINDv BGBemBcEQAAEek3g/wMznemci7e/SgAAAABJRU5ErkJggg== --0000000000007e75ad05b8b6fff3-- From nobody Tue Jan 12 09:08:22 2021 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0AAC3A0D3D for ; Tue, 12 Jan 2021 09:08:20 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnt-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zp1saydgNcvo for ; Tue, 12 Jan 2021 09:08:19 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 12E733A0D07 for ; Tue, 12 Jan 2021 09:08:18 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id u21so3690480lja.0 for ; Tue, 12 Jan 2021 09:08:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnt-se.20150623.gappssmtp.com; s=20150623; h=to:from:subject:autocrypt:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=o37Wq06IhmAkPxZMwzGzDjKeunFKzRvB1uNcv2TxFL0=; b=057iDJZpVnsu5uA8RjEenOHrRvYmBXG0pPEJSPy5m3qFpMdgSVDRkYcX3RqQtMQlxh GqqBHHo5HQ54jh3cNu1LUF73J1RuB4P2lhc++nHjaqtfnyjk38u5OivYwDD6c14vw7vJ 4O3jCUYhufLosRI9zavqDSow8dkf3qUr0MikFRmTssVmrJaVhQnVda1SbtNFaBvHJm+X rVVczf8Db/7MNhmjHT7WmHYl0KSEiqdYkSycOAjZHgAOV9CTYq9jmKrzEwysjecZW7rH GWAVT4+i8cV8jgJT1iJqiLmRSq8clFEo6LSJDEgkjrZ7AH0faHN+YxnNJ5zWsljHVvfc Xd8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:autocrypt:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=o37Wq06IhmAkPxZMwzGzDjKeunFKzRvB1uNcv2TxFL0=; b=Z+UEl81YNCL1ahjZ1BDbZLucR3WIwTPgqd2OWIMH5+Svu6O6GUx8Y30x6ypqZhoKiA Az5pz1mjAUkAvBBNC8xu5LOWixyi0jLZlPiu/jZmHhL6YqVxfnkRTjVYzLZ1Ddi5rIjD 9RjNhrp39q/tsXlcypj+8ZzZ2uv9fuYdCPyLyQhUVu7AkYQXM7QkH458Dm9r+GSvq3IG Mxy/6x9M6X6G2QuXVuNhkC+xKlfikhSH/XLg8DWYQVI+3vzYihs+R65THQ0MColrM7Tk oOisbG2V26CNVhHU4mq/FS2uq68v0xN0bQVUlMSo9buANwmKzyH4vcU9PIBH9vKfa/A7 qixQ== X-Gm-Message-State: AOAM531mxReCtwfUwEdScql36G+eOb2sPT82ggizwfJramA9T89cm4Qn 0GEso05LNhn/2jUkVauUfVMFo2CRoqcfng== X-Google-Smtp-Source: ABdhPJx6p86stgQYk8KP6d59MOGPmyF6vrYdfwzY6ZzaApRMuxxI7fZp/63Pgd3nH8r4XnbOKatjvg== X-Received: by 2002:a2e:720c:: with SMTP id n12mr120124ljc.2.1610471294694; Tue, 12 Jan 2021 09:08:14 -0800 (PST) Received: from [10.0.0.173] (h-158-174-22-56.NA.cust.bahnhof.se. [158.174.22.56]) by smtp.gmail.com with ESMTPSA id r16sm413217ljj.52.2021.01.12.09.08.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Jan 2021 09:08:14 -0800 (PST) To: txauth@ietf.org From: Leif Johansson Autocrypt: addr=leifj@mnt.se; prefer-encrypt=mutual; keydata= mQGiBD7DfnwRBADpIpOw6bXfx2Yo3vac/j5WzVcWNZKuiYc4uuFnBYxH8zTA5cdwytuOYNte cX1yrPgmObfPVU0EFktdBMFgLE5TNRUMeJZTmAl3QYDm8N32SeSUEb6GPFsUTGgxsCW3GVAo q6DBopKqhR9HT0+crQakbc7XkS4FjeBWiXjuNf/IqwCgyoa2Qfq8UdjbcH+DRGzPnRTeqzEE ALIEsCzDp4HQqXqqNLCoExbgmCrEHvnqFmilCHJVnyuY8LXmcpq2uwJaiIdsTqLeQ8WrMxWg mZc6F9QSdLP6MVZT3v+5OqOZMUDsu4nGom3HH+tG238vMSEF+klGdrI0wdscrY+28Oshjhqj 4FZxCwdNU9RTU8xQ9IoObiEo1yOHBADK9a5GhkLT+d2cb48orETGtG7i//HOnstouw/TmEUX reZPtT6wpIdN9Jf3W80GA6A34VEGA/I+/5e+9nFvINpLvEF2ghJBH+sWwQ8EXpo0M/yir9oG eJI7gpOHRj5Mq9uqFG0wcamInuWgbMP1cefjXusHbHyDFKr7ydWSsZHqXrQdTGVpZiBKb2hh bnNzb24gPGxlaWZqQG1udC5zZT6IYAQTEQIAIAUCSnC8wwIbIwYLCQgHAwIEFQIIAwQWAgMB Ah4BAheAAAoJEPCcfBbWzGZ3x8MAnimIMTFOH4LLfp8bQnSPWm6BQyA6AKCk4S46++PpqtTM 0wIZ+kuYaBtky7kCDQQ+w36FEAgAr1zK1qIIXmoeEqFulgFi17FRpSibNwwge9bkG2+IO7MO m4Ih+f4CRkqaP5U5diiWb4nyQc/Yqzf3TTSE+CH0ghvDCwfZHrzUsVl9t57S2RFKaQhDUUw3 lz0TgKN66z1IRnQEARuz9PFd96pIhLaJBOn0e55Cu5qqJVwGpst3+I3jqT/cxjymRxPz2O6R 9k/ZOOiOGROZYAjNHKcdoeBr7OaIHcPRCi1R8MBKE4HOK1SwaVvs26Fd2enixIOBmyFTkrue 3VgaAd3zrJauD0qa/u5y2kGEyFFJwNsKnoX0aCmNNIG+aKvnSCWfba8bmYOAsbxS2lo4MKmu DM0rrVyLhwADBQf/VzM77aviZ3Ir7qXj0uV/62wyrg8/5flXl8XjuATewD+hTaux1lg5LgPU 9cokMHYHrTsnp79nhEB9qOpsQLX+npae7a27x3zyqLP0V7neyKy1ycuBI9KU9B3ivgSMRlKR 91GcmUpRnKiSnxPYNtq018mY72YYHCpfAh0OOUA88bxbYIuF5cv9dYyOBhNEkI8xB1VOWev1 CPkPb0DwDABHdOBq9e0hT3OUOaat2JPwCEHU2NTGsYFuZRysq8xnxFgHd00+h2OJZ50UYVpB jDxaCj5gvHHFFnmfCLD5VqjEJGi4k2znZHg67i2pw0f5BSq8fsfdUML35LzL/aaZPMzlg4hG BBgRAgAGBQI+w36FAAoJEPCcfBbWzGZ3djcAnAxF3084vKlsRNGcyj/rn5lA4Q+nAKCnjZYX snFG51wbu8OI88aj3LJE5w== Message-ID: <9a0d7503-e52c-f1f1-5702-328de2c34023@mnt.se> Date: Tue, 12 Jan 2021 18:08:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [GNAP] reminder - interrim starting X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2021 17:08:21 -0000 The interrim is starting. Zoom: https://intuit.zoom.us/j/99533101832?from=addon Materials: https://datatracker.ietf.org/meeting/interim-2021-gnap-01/agenda/gnap-drafts.pdf Cheers Leif & Yaron From nobody Tue Jan 12 13:10: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 E6C3E3A121C for ; Tue, 12 Jan 2021 13:10:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.527 X-Spam-Level: X-Spam-Status: No, score=-0.527 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=1.569, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Z2DvMhdhbtJ for ; Tue, 12 Jan 2021 13:10:27 -0800 (PST) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C29C43A1216 for ; Tue, 12 Jan 2021 13:10:26 -0800 (PST) Received: by mail-wr1-x434.google.com with SMTP id r3so3989361wrt.2 for ; Tue, 12 Jan 2021 13:10:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=ZFCWUIsyGpvzhu8pBPG4GLFH7gALGnyaBpQEx/Og1rU=; b=BV1ds8LVEbuQiZwep6xWDRnQMJqQHQo9PJd/pweIlLy+ntocWBEH9aslGIUkpmgpWQ iSoLq+h3LiK2RgM/zpgr0YELkK0kystJEtvsAbMOvNAS7zmimh3ziUu9bx+Mr8wjAaHC bly5/UxwhWapTyHd1BrznIik3sSJ10RW1M0dLsKjPSIVdl4wkChNSpUSWJ+gNkw/xLFZ cRqFqKfAyxuoHORfmtggMqhpEjKV3wHwROE0nISQe0Y6zUA80N9Al4sfWEKvi66fBYwl 2rcIoFtvKBKGYs3Y4XLcgWnsFGjHgCmSNonD8wEMdKT0s7d7dFpx2uk/7lvyEuK3N+eS H4pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=ZFCWUIsyGpvzhu8pBPG4GLFH7gALGnyaBpQEx/Og1rU=; b=KrnBa/1Vwk/xkIORU7RGsfeGsbclidFv+pK4I1As+wvLsmaFUDzoLrbMDxjGA2Ucf0 8HrLFilk2sspouva0jeNfmcGNz2DlN4rM5EotSxX4gEnZLqGxBwrkLpjPon8s9EMfzUF 6JSkmyXHA5z4a1jxJCU3ifqduGp7QWpm/yYYbk03DTyjF25sjomg50zcv/2seQH9UcvE Vebr85ZpVxnqr3C20LDxJM0Z23n0B6yDbETcSUb+weylAZHzR230gn+qsp2xyQV1wfJD jhelqGdgL1PX4OWa6CPytOsracuJfn6NFx7Bql1Vq2w2fBiqzFOVX0rWggXHjX59c7As GMNA== X-Gm-Message-State: AOAM5321TGtbn0UGsQZFR2GmTeY6dPypNgdeuOriR5KvVJDdHJIgHdzL DzU9GOkz9Z/TaiuHxSQ96LY= X-Google-Smtp-Source: ABdhPJyXoFo9gOjGqb9ruVn6AqwGJXbOlw8KhvgVX3tA16I8Ydn+FySySFLTDRkbLgpg17MldadoJQ== X-Received: by 2002:adf:ee51:: with SMTP id w17mr693031wro.97.1610485825046; Tue, 12 Jan 2021 13:10:25 -0800 (PST) Received: from [192.168.68.105] (bzq-79-183-113-247.red.bezeqint.net. [79.183.113.247]) by smtp.gmail.com with ESMTPSA id w189sm5802901wmg.31.2021.01.12.13.10.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jan 2021 13:10:24 -0800 (PST) User-Agent: Microsoft-MacOutlook/16.44.20121301 Date: Tue, 12 Jan 2021 23:10:22 +0200 From: Yaron Sheffer To: Aaron Parecki , Denis CC: Leif Johansson , Mike Jones , "txauth@ietf.org" Message-ID: <16581957-CEEB-41D7-87F3-CFDF24056750@gmail.com> Thread-Topic: [GNAP] Interim meeting next Tuesday References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3693337823_1500075589" Archived-At: Subject: Re: [GNAP] Interim meeting next Tuesday X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2021 21:10:29 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3693337823_1500075589 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Meeting recording: =20 https://intuit.zoom.us/rec/share/OacWRqLROJrBAHJ-MNxO-zlk6yJgxquPpvBCyf_3H2= nkSnD7RZ7BBVnN2BK0Alnh.kdEnxr5_GsRnIXx_ Passcode: h1.8^MkS=20 =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 From: Aaron Parecki Date: Tuesday, January 12, 2021 at 18:35 To: Denis Cc: "yaronf.ietf@gmail.com" , Leif Johansson , Mike Jones , GNAP M= ailing List Subject: Re: [GNAP] Interim meeting next Tuesday =20 Denis, the meeting link is in the email Yaron sent last week. =20 I also added the meeting to the events.oauth.net website and the link will = appear there 15 minutes before the start: =20 https://events.oauth.net/2021/01/gnap-interim-meeting-Z7Nw3hc8AIOM =20 You can also subscribe to the ics feed linked from this page if you want al= l the GNAP events on your calendar: =20 https://events.oauth.net/tag/gnap =20 Direct ics link to add to your calendar: https://events.oauth.net/ics/tag/g= nap.ics =20 Aaron =20 =20 On Tue, Jan 12, 2021 at 8:18 AM Denis wrote: +1 =20 There is less than one hour left. =20 Denis =20 Could you send a calendar invitation for this including the join link so it= =E2=80=99s in people=E2=80=99s calendars? =20 Thanks, -- Mike =20 From: TXAuth On Behalf Of Yaron Sheffer Sent: Wednesday, January 6, 2021 11:09 AM To: GNAP Mailing List Subject: [EXTERNAL] [GNAP] Interim meeting next Tuesday =20 Reminder: we will be meeting next week to review the latest with the GNAP c= ore protocol and discuss issues. =20 See you all there! =20 Leif and Yaron =20 =20 Jan. 12 2021, 17:00-18:30 UTC Join with Zoom Working group status (chairs) Draft update (Aaron) Terminology update Open issues:=20 Access token request/response format Interaction request/response format AOB and next steps =20 =20 --=20 TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth --B_3693337823_1500075589 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Meeting recording:

 

https://in= tuit.zoom.us/rec/share/OacWRqLROJrBAHJ-MNxO-zlk6yJgxquPpvBCyf_3H2nkSnD7RZ7BB= VnN2BK0Alnh.kdEnxr5_GsRnIXx_ Passcode: h1.8^MkS 

 

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ya= ron

 

From: Aaron Parecki <aaron@parecki.com>=
Date: Tuesday, January 12, 2021 at 18:35
To: Denis <= denis.ietf@free.fr>
Cc: "yaronf.ietf@gmail.com" <y= aronf.ietf@gmail.com>, Leif Johansson <leifj@sunet.se>, Mike Jones = <Michael.Jones=3D40microsoft.com@dmarc.ietf.org>, GNAP Mailing List <= txauth@ietf.org>
Subject: Re: [GNAP] Interim meeting next Tuesd= ay

 

<= /div>

Denis, the meeting link is in the email Yaron s= ent last week.

 

I also added the meeting to the events.oauth.net website and the link will appear ther= e 15 minutes before the start:

<= o:p> 

 

You can als= o subscribe to the ics feed linked from this page if you want all the GNAP e= vents on your calendar:

&nb= sp;

 

Direct i= cs link to add to your calendar: https://events.oauth.net/ics/tag/gnap.ics

<= div>

 

Aa= ron

 

<= /div>

 

On= Tue, Jan 12, 2021 at 8:18 AM Denis <= denis.ietf@free.fr> wrote:

+1

 

There is less than one hour left.

 

Denis

<= /div>

 

Coul= d you send a calendar invitation for this including the join link so it=E2=80=99s = in people=E2=80=99s calendars?

=  

   =             &nbs= p;            &n= bsp;            =             &nbs= p; Thanks,

  &n= bsp;            =             &nbs= p;            &n= bsp;            =   -- Mike

 

From: TXAuth <txauth-bounces@ietf.org> On Be= half Of Yaron Sheffer
Sent: Wednesday, January 6, 2021 11:09 A= M
To: GNAP Mailing List <txauth@ietf.org>
Subject: [EXTERNAL] [GNAP] Inte= rim meeting next Tuesday

 

= Reminder: we will be meeting next week to review the latest with the GNAP co= re protocol and discuss issues.

 

See y= ou all there!

 

    = ;            Leif and= Yaron

 

 

Jan. 1= 2 2021, 17:00-18:30 UTC

Join with Zoom

  • Working group status (chairs)
  • Draft update (Aaron)
  • Terminology update
  • Open issues:
  • AOB and next steps

 



 

<= /div>

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

--B_3693337823_1500075589-- From nobody Wed Jan 13 08:19: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 A15573A119D for ; Wed, 13 Jan 2021 08:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1x8D0toqaY0s for ; Wed, 13 Jan 2021 08:19:39 -0800 (PST) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B8833A119A for ; Wed, 13 Jan 2021 08:19:39 -0800 (PST) Received: by mail-io1-xd32.google.com with SMTP id d13so2017468ioy.4 for ; Wed, 13 Jan 2021 08:19:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=N//wS8iCfMAR2b+A8629Hg9IICcZug0RMh5diOapa2I=; b=ConPcotIcwQ0jtIQWGaPyQcUklqrwiep6+EoYz/0BYwSj5MG1bPFxQbifO1buy3V4N 0iCwcQVjmoVUdMIgmiHCPUSoHa3dj/Wd9RcWTK8rQGJOy5Kc/6IU+d30eGT50PrUmpGG QQ58dmmA+cCH1gWOPvzqg7k0q6v52eGCL7sBrtdoSXT4zpTA/Xit4kx1+Y3WBpXruGRS qQUygDMLBKZmBt6UeDvE68cmDi8e5+j+u38f/DQ8+MNZDAECmHHmlViqEe6a1tYgpuhw Bcoy/SXQvjL8SsrPbClwYe1z0QspOkBRQkgamKR68fmv5uUvvsvrQ8xbd1jdJUd7l2qV gq5A== 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=N//wS8iCfMAR2b+A8629Hg9IICcZug0RMh5diOapa2I=; b=caD4uxL3RxSiPd6BHG7RVEHHQkMhyleOZaQIAcLvsLmFLjbYwHsvAT4Uo6eXYJpTH/ LmMjaQVV75K2mO7wrrwTzJxL1TTGvit6VOmb5iSgL4PZFihfgFRuXhvyzrBVIj2VRCoY ov17axhg5PKiAIfxllkzyM7YfR7Se3YopTx6XSD+Z4anXBrsdOrchJCySdN4Euaj7apB BZlbl7d0H/nQBHGqk01k5CauQt58P9fDKnT61naqKT8BpKIrDgp1Lt9HlipBR9tb0hLR xO9a4sR7JSN0oE6OW5VBJ+gHyNLmPEtitpg79gpwch9maMuZPwXzbUpki5EFl3xH7Fcs oBJg== X-Gm-Message-State: AOAM533gStMR6IDglhMAbswSfLQxX93efFb++Dd8lCxNRS+Vb6SiJzzT 3UtwyDQnK8H+sqhSo331sCdzaFCheYf1miKnjxk= X-Google-Smtp-Source: ABdhPJxyH0uBkNPOWmSmMT+ZQD8sQAf65cHI5x9ixiv5ajNFoKBtXusdZx1Kjs/TxdrtLvB9245cAOkoQ8Dy/wuwS/A= X-Received: by 2002:a6b:fe19:: with SMTP id x25mr2337536ioh.78.1610554778767; Wed, 13 Jan 2021 08:19:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Wed, 13 Jan 2021 17:19:27 +0100 Message-ID: To: Denis Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000007ad7eb05b8ca8103" Archived-At: Subject: Re: [GNAP] Terminology PR 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, 13 Jan 2021 16:19:44 -0000 --0000000000007ad7eb05b8ca8103 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Denis, Thanks to your feedback, I've committed the 3 changes to the PR, which is the basis for merge. >From the discussion, "subject" seems the most viable option, as explained in the previous thread. At least it is consistent and doesn't imply a specific use case, and if we find better later on we can still improve it then. And also merging it now enables more surgical changes with dedicated issue (without the risk of breaking what we improved), instead of a very broad meta issue 29 (which will be closed). For the new proposed term (controlled attribute), this should follow the same process as other potential additions (which we'll try to limit to the bare minimum), by entering a new dedicated issue. Could you reexplain why you think that is useful ? (you started during the call but it's better to have the time to think about it). Likewise, we have potential discussion for : - Interaction server (as an optional component dedicated to front end interaction) - Key proof (or more precisely key proof of possession) Each time it will be submitted to the WG for consensus call. So as a summary : - most updates from the mailing list and the git have been included - PR #155 is merged and terminology issue #29 is closed - please consider using new dedicated issues on that topic Fabien On Tue, Jan 12, 2021 at 4:55 PM Fabien Imbault wrote: > Hi Denis, > > We could try to remove the term "user" and systematically list RO and > end-user instead. It's not a critical term and is used for convenience (c= f > for instance diagram in section 1.4.1, where we have a part labelled "RO = + > RQ (User)" in version 3 of the draft, and we have the accompanying text > that explains it too). > > I have noted the small change in the end-user definition ("a"), which > would be an update to the PR. > > Other comments embed with [FI] in red. Most of them are related to the us= e > of "subject", which I still find more accurate than RO or end-user in the > general case (that is without being specific about one particular use cas= e > or without embedding requirements in the definition). As previously > mentioned, this also comes from the use of "subject entity" in relationsh= ip > to https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-06= (used > in the main text), so that we don't use different synonyms in the > definitions. Same answer as what Mark asked for earlier. > > Cheers > Fabien > > > On Tue, Jan 12, 2021 at 4:29 PM Denis wrote: > >> Hello Fabien, >> >> The end-user and the RO are two roles. >> The case where (as you write) RO=3Dend-user does not exist. The case whe= re >> these two roles are supported by the same entity may exist. >> Since the document is supposed to describe operations between roles, I >> don't see the need to use a specific vocabulary for that specific case. >> Other comments are below. One of them attempts to explain (in a Note 2), >> the relationship between a RO and an end-user >> >> Hello Denis, >> >> The part called "current spec" corresponds to the text before the PR, >> it's just here for reference. >> >> We made the distinction between the end-user and the RO as clear as we >> could. >> There is indeed a case where we still keep "user", to indicate that the >> RO=3Dend-user (and tried to make it clear in the text). I don't see an >> obvious way to change that. >> >> From your comment I don't see why subject would be a problem. >> >> We indeed tried to avoid the embedding of requirements into the >> definitions. >> >> The rest of my comments are embedded into your message, and marked with >> FI for convenience. >> >> Fabien >> >> >> Le lun. 11 janv. 2021 =C3=A0 16:27, Denis a =C3=A9c= rit : >> >> >> I have used the text of the wiki to respond. Latest discussion update >>> >>> Here we consolidate the latest proposal(s) from the group. We also >>> include the discussion items (individual feedbacks). >>> >>> >>> >>> [Denis] I don't have the feeling that we are converging. There are >>> duplications for some definitions that are spread over the document >>> instead of being grouped together. This does not help to converge. >>> >>> >>> >>> We need to clearly separate the role of the "end-user" from the role of >>> a RO. Attempting to collapse these two concepts under the term "user" >>> creates confusion. Attempting to use the term "subject" creates even >>> more confusion. >>> >>> >>> Trying to incorporate design choices inside the definition section is >>> not appropriate, hence why I propose to remove several notes. >>> >>> >>> >>> In my proposals below, I have followed the ISO style for the definition= s >>> (a single sentence as short as possible). >>> >>> >>> Authorization Server (AS) >>> >>> server that grants delegated privileges to a particular instance of >>> client software in the form of an access token and other information (s= uch >>> as subject information). >>> >>> >>> >>> [Denis] >>> >>> Authorization Server (AS): server that grants access privileges to a >>> particular instance of a client software in the form of an access token= and >>> provides information about the end user >>> >>> Some explanations: In addition to the granting of access tokens, >>> end-users may query the AS about the privileges they store about them. >>> >>> We should identify in the main body of the document thse two distinct >>> operations. >>> >> >> [FI] so far the type of additional information we would send is specifie= d >> as subject information, hence its use in the definition. >> >> [Denis] Since a subject is currently defined in the draft as "person, >> organization or device", I don't believe that an AS "grants other other >> information >> (such as subject information)" because it does not manage organizations >> nor devices. In the context of an AS, the AS only manages end-user >> information >> hence why it is unnecessary to introduce the term "subject". >> > > [FI] In most cases, it will be only about the end-user and its access > token. But regarding the use of subject and whether we could send other > information such as subject information, this would be the case if we > include client posture (which is something planned). > >> Client >>> >>> application operated by an end-user that consumes resources from one or >>> several RSs, possibly requiring access privileges from one or several A= Ss. >>> >>> >>> >>> Example: a client can be a mobile application, a web application, etc. >>> >>> >>> >>> Note: this specification differentiates between a specific instance (th= e >>> client instance, identified by its unique key) and the software running= the >>> instance (the client software). For some kinds of client software, ther= e >>> could be many instances of that software, each instance with a differen= t >>> key. >>> >>> >>> >>> [Denis] Change in the Note: >>> >>> (the client instance, identified by its unique key) >>> >>> into: >>> >>> (the client instance, identified by a unique key) >>> >>> Some explanations: The key is unique, but may change. >>> >> >> [FI] not sure that your proposal changes much the meaning (at any point >> in time, its key is unique, and yes, it may be changed over time). >> >> [Denis] It does change it. Since it seems you can live with that change, >> this is fine. >> >> Resource Server (RS) >>> >>> server that provides operations on protected resources, where operation= s >>> require a valid access token issued by an AS. >>> >>> >>> >>> [Denis] Change into: >>> >>> Resource Server (RS) : server that provides operations on resources, >>> where operations on protected resources require >>> a valid access token issued by one or more ASs >>> >>> Some explanations: a resource server may also support resources >>> available to the public. >>> >>> >>> >> [FI] yes, but we don't really care about public resources (there's no >> need for a protocol for that). As for "one or more ASs", this seems to >> embed a requirement (support multiplicity). >> >> [Denis] A RS may support both public and private resources. At the time >> an operation is performed by a client on a resource, >> it is unknown whether that operation is allowed for the >> public or not. >> > [FI] yes indeed the RS may support public or private resources, but the R= S > definition still seems valid > >> >> Resource Owner (RO) >>> >>> subject entity that may grant or deny operations on resources it has >>> authority upon. >>> >>> Note: the act of granting or denying an operation may be manual (i.e. >>> through an interaction with a physical person) or automatic (i.e. throu= gh >>> predefined organizational rules). >>> >>> >>> >>> [Denis] Change into: >>> >>> Resource Owner (RO): *entity* that may grant or deny operations on >>> resources it has authority upon >>> >>> Some explanations: the term "entity" (without the word "subject") is >>> being used which is a very general term: it may or may not be a human b= eing. >>> >>> >>> >> [FI] subject is defined as either human or not. >> >> [Denis] No, a subject is currently defined in the draft as "person, >> organization or device". We don't need to use the term "subject". >> > [FI] sorry, I don't get your point. Entity alone doesn't make me > understand it can also be a human. > >> >> >>> End-user >>> >>> natural person that operates *the* client instance. >>> >>> >>> >>> Note: that natural person may or may not be the same entity as the RO. >>> When it is explicit that the end-user and the RO are the same entity, t= he >>> generic term user may be used. >>> [Denis] Change into: >>> >>> *End-user*: natural person that operates *a* client instance >>> >>> Remove the Note which is confusing. >>> >> >> [FI] "a" might indeed be better. >> >> [Denis] Thanks ! >> > [FI] will update the PR > >> >> >> Regarding the note, it seems that you'd rather not have "user" (and the >> rest is still useful I think). >> This is actually used in other parts of the spec (cf diagrams) to refer >> to either RO or end-user, undistinctively. What would you use otherwise? >> >> [Denis] The Note should be removed because it leads to confusion. The >> Note considers only the case where the RO is a natural person, however a= RO >> may also be a process. >> The Note may be adequate when the RO is being defined. In such a case, I >> would propose: >> >> Resource Owner (RO): *entity* that may grant or deny operations on >> resources it has authority upon >> >> >> Note 1: The act of granting or denying an operation may be automatic >> (i.e. through predefined rules) or manual (i.e. through an interaction >> with a physical person).. >> >> Note 2: In the later case, the same physical person may support >> simultaneously the role of the RO and the role of the end-user. >> >> Attribute >>> >>> characteristics related to a subject. >>> >>> >>> >>> [Denis] Change into: >>> >>> Attribute: characteristics related to an end-user >>> >>> [FI] are we 100% sure we'll never send anything else? >> >> [Denis] See the discussion above for the reason for not using the term >> "subject". >> >> Access Token >>> >>> a data artifact representing a set of rights and/or attributes. >>> >>> >>> >>> Note: an access token can be first issued to an client instance >>> (requiring authorization by the RO) and subsequently rotated. >>> >>> >>> >>> [Denis] Remove the Note which has nothing to do in this section. >>> >> >> [FI] the note serves the purpose of explaining the lifecycle of an acces= s >> token, which I believe is useful to the reader. Cf the large litt=C3=A9r= ature >> about access vs refresh in the oauth2 world. >> >> [Denis] We are in the definition section. Explaining the lifecycle of an >> access token may indeed be very useful >> but a dedicated section in the main body of the document >> would much better address this topic. >> > [FI] we could do that too. As any note, it's not critical anyway. It's > here mostly for convenience, but if we feel it's better in the main text, > so be it. > >> >> Grant >>> >>> (verb): to permit an instance of client software to exercise some set o= f >>> delegated rights to access a protected resource and/or >>> to receive some attributes at a specific time and during a specific >>> duration. (noun): the act of granting. >>> >>> >>> >>> [Denis] Change into: >>> >>> *Grant* >>> >>> >>> >>> (verb): to receive some attributes from an AS at a specific time and >>> valid for a specific duration and/or >>> to permit an instance of client software to exercise this attributes to >>> perform an operation on a protected resource >>> >>> >>> >>> (noun): the act of granting >>> >>> Some explanations: The current text identifies two cases. I have >>> switched these two cases. >>> >> >> [FI] how is that better? >> >> [Denis] Before being able to use an access token, it is necessary to get >> it. So the proposed definition follows a chronological order. >> > [FI] ok clearer now, thanks. > >> Privilege >>> >>> right or attribute associated with a subject. >>> >>> >>> >>> [Denis] >>> >>> *Privilege*: right or attribute associated with an end-user >>> >>> Note: the RO defines and maintains the rights and attributes >>> associated to the protected resource, and might temporarily delegate >>> >>> some set of those privileges to an end-user. This process is refered to >>> as privilege delegation. >>> >>> >>> >>> [Denis] Remove the Note which is unrelated to the definition. >>> >> >> [FI] this is useful to understand what we call "delegated privileges" in >> the AS definition. >> >> [Denis] Reading the original proposed definition again, the Note >> considers the RO. >> > [FI] it's not easy to describe. It considers the RO and its delegation. > >> >> >> I consider that a right is a capability to perform an operation on a >> protected resource. Such capabilities is given by a RO to an end-user. >> I consider that an attribute is a characteristics related to an end-user >> (e.g. a name, a group membership) >> >> Privilege =3D right or attribute associated with an end-user >> which allows to support respectively >> either a capability scheme or an >> attributed-based access control (ABAC) using ACLs. >> >> A RO maintains rights but it does not maintain attributes. >> > [FI] which is why subject is more general, and can accomodate both use > cases. Anyway, the exact requirement should be left to the main text. > >> It might be useful to define in addition: >> >> *control attributes*: set of attributes associated to a protected >> resource used to control operations on that resource >> >> Note: a RO defines and maintains the control attributes associated to a >> protected resource >> >> [FI] we'll try to really limit new definitions to the bare minimum. So i= f > we see that's useful, we'll include it. But so far I don't think that add= s > much. > >> >> >> Protected Resource >>> >>> protected API (Application Programming Interface) served by a RS and >>> that can be accessed by a client, if and only if a valid access token i= s >>> provided. >>> >>> >>> >>> Note: to avoid complex sentences, the specification document may simply >>> refer to resource instead of protected resource. >>> Right >>> >>> ability given to *a subject* to perform a given operation on a resource >>> under the control of a RS. >>> >>> >>> >>> [Denis] Change into: >>> >>> *Right*: ability given to *an end-user* to perform a given operation on >>> a resource under the control of a RS >>> >>> >> [FI] it's not rights about the end-user per say, it's rights delegated b= y >> the RO. >> And so in this context, subject seems a better description and avoids th= e >> potential misunderstanding. And least that's the intent. >> >> [Denis] A right is not given to an organization or to a device, but onl= y >> to an end-user. >> > [FI] not always. Could have an automated policy, which assigns rights to > user groups, which is an organizational construct. Device policies might > matter too. > Of course at runtime, it ends up being consumed by an end-user. > >> Subject >>> >>> person, organization or device. >>> >>> >>> >>> [Denis] Remove this definition since this terms is confusing and >>> unnecessary. >>> >> >> [FI] I'm not sure what is confusing. This is useful at the bare minimum >> in context with the next definition. >> I think it can be used as a basic definition for other terms, and that's >> what is proposed. >> >> [Denis] See the arguments raised above. >> >> Subject Information >>> >>> statement asserted locally by an AS about a subject. >>> >>> >>> >>> [Denis] Remove this definition since this terms is confusing and >>> unnecessary. >>> >> >> [FI] this is used in the main text, so needs to be defined (or removed >> from the main text, but that's a different debate). >> >> [Denis] See the arguments raised above. >> >> Current spec >>> >>> Here we find all the terms and definitions from the current version of >>> the draft (01), as a reference. >>> Roles Authorization Server (AS) >>> >>> Manages the requested delegations for the RO. The AS issues tokens and >>> directly delegated information to the RC. >>> The AS is defined by its grant endpoint, a single URL that accepts a >>> POST request with a JSON payload. >>> The AS could also have other endpoints, including interaction endpoints >>> and user code endpoints, and these are introduced >>> to the RC as needed during the delegation process. >>> >>> >>> >>> [Denis] Already discussed above (and far too long for a definition). >>> >>> >>> Resource Client (RC, aka "client") >>> >>> Requests tokens from the AS and uses tokens at the RS. An instance of >>> the RC software is identified by its key, which can be known >>> to the AS prior to the first request. The AS determines which policies >>> apply to a given RC, including what it can request and on whose behalf. >>> >>> >>> >>> [Denis] Already discussed above. >>> >>> >>> Resource Server (RS, aka "API") >>> >>> Accepts tokens from the RC issued by the AS and serves delegated >>> resources on behalf of the RO. >>> There could be multiple RSs protected by the AS that the RC will call. >>> >>> >>> >>> [Denis] Already discussed above. >>> >>> >>> Resource Owner (RO) >>> >>> Authorizes the request from the RC to the RS, often interactively at th= e >>> AS. >>> >>> >>> >>> [Denis] Already discussed above. >>> >>> >>> Requesting Party (RQ, aka "user") >>> >>> Operates and interacts with the RC. >>> >>> >>> >>> [Denis] Remove. Already discussed above under the term " >>> >>> *end-user" * >>> >>> *Elements* >>> Access Token >>> >>> A credential representing a set of access rights delegated to the RC. >>> The access token is created by the AS, consumed and verified by the RS, >>> and issued to and carried by the RC. The contents and format of the >>> access token are opaque to the RC. >>> >>> >>> >>> [Denis] Already discussed above. >>> >>> >>> Grant >>> >>> The process by which the RC requests and is given delegated access to >>> the RS by the AS through the authority of the RO. >>> >>> >>> >>> [Denis] Already discussed above. >>> >>> >>> Cryptographic Key >>> >>> A cryptographic element binding a request to a holder of the key. Acces= s >>> tokens and RC instances can be associated with specific keys. >>> >>> >>> >>> [Denis] Change into: >>> >>> *Binding key*: a cryptographic key used by a client to bind an access >>> token to a client instance >>> >>> Some explanations: cryptographic key is a general term. In the context >>> of GNAP we want that key to achieve a specific function: >>> to *bind *an access token to a client instance. >>> Resource >>> >>> A protected API served by the RS and accessed by the RC. Access to this >>> resource is delegated by the RO as part of the grant process. >>> >>> >>> >>> [Denis] We don't need this definition. Already discussed above under th= e >>> wording" Protected Resource". >>> >>> >>> Subject Information >>> >>> Information about the RO that is returned directly to the RC from the A= S >>> without the RC making a separate call to an RS. >>> Access to this information is delegated by the RO as part of the grant >>> process. >>> >>> [Denis] We don't need this definition. >>> >>> Some explanations: an end-user may wish to know the attributes stored >>> for him by the AS. >>> However, no information needs to be returned to a client about a RO. >>> >> Denis >> >> Denis >>> >>> Hi everyone, >>> >>> I wish you all a happy new year. >>> >>> I just created a PR ( >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/155) that takes >>> into account the various feedbacks. The automatic build process is not >>> working, but you can see the diffs and build the html locally if you >>> prefer. The definitions have also been updated on the wiki ( >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology) if >>> you prefer to check there. >>> >>> Feedbacks welcome before we move to pending merge later on. >>> >>> Cheers >>> Fabien >>> >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --0000000000007ad7eb05b8ca8103 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Denis,=C2=A0

Thanks to your feedback= , I've committed=C2=A0the 3 changes to the PR, which is the basis for m= erge.

From the discussion, "subject" see= ms the most viable option, as explained in the previous thread. At least it= is consistent and doesn't imply a specific use case, and if we find be= tter later on we can still improve it then. And also merging it now enables= more surgical changes with=C2=A0dedicated issue (without the risk of break= ing what we improved), instead of a very broad meta issue 29 (which will be= closed).=C2=A0

For the new proposed term (control= led attribute), this should follow the same process as other potential addi= tions (which we'll try to limit to the bare minimum), by entering a new= dedicated issue. Could you reexplain why you think that is useful ? (you s= tarted during the call but it's better to have the time to think about = it).=C2=A0

Likewise, we have potential discussion = for :=C2=A0
- Interaction server (as an optional component dedica= ted to front end interaction)
- Key proof (or more precisely key = proof of possession)

Each time it will be submitte= d to the WG for consensus call.=C2=A0=C2=A0

So as = a summary :=C2=A0
- most updates from the mailing list and the gi= t have been included
- PR #155 is merged and terminology issue #2= 9 is closed
- please consider using new dedicated issues on that = topic

Fabien


On Tue, Jan 12, 2= 021 at 4:55 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Denis,=C2=A0
=
We could try to remove the term "user" and systema= tically list RO and end-user instead. It's not a critical term and is u= sed for convenience (cf for instance diagram in section 1.4.1, where we hav= e a part labelled "RO=C2=A0+ RQ (User)" in version 3 of the draft= , and we have the accompanying text that explains it too).

I have noted the small change in the end-user definition ("a&= quot;), which would be an update to the PR.=C2=A0

= Other comments embed with [FI] in red. Most of them are related to the use = of "subject", which I still find more accurate than RO or end-use= r in the general case (that is without being specific about one particular = use case or without embedding requirements in the definition). As previousl= y mentioned, this also comes from the use of "subject entity" in = relationship to=C2=A0https://tools.ietf.org/html/= draft-ietf-secevent-subject-identifiers-06=C2=A0(used in the main text)= , so that we don't use different synonyms in the definitions. Same answ= er as what Mark asked for earlier.=C2=A0

Cheers
Fabien


On Tue, Jan 12, 2021 at 4:29 PM Denis <denis.ietf@free.fr= > wrote:
=20 =20 =20
Hello Fabien,

The end-user and the RO are two roles.
The case where (as you write) RO=3Dend-user does not exist. The case where these two roles are supported by the same entity may exist.
Since the document is supposed to describe operations between roles, I don't see the need to use a specific vocabulary for that specific case.
Other comments are below. One of them attempts to explain (in a Note 2), the relationship between a RO and an end-user

=20
Hello Denis,

The part called "current spec" correspo= nds to the text before the PR, it's just here for reference.=C2=A0

We made the distinction between the end-user and the RO as clear as we could.=C2=A0
There is indeed a case where we still keep "user", to indicate that the RO=3Dend-user (and tried t= o make it clear in the text). I don't see an obvious way to change that.=C2=A0

From your comment I don't see why subject wou= ld be a problem.=C2=A0

We indeed tried to avoid the embedding of requirements into the definitions.

The rest of my comments are embedded into your message, and marked with FI for convenience.=C2=A0

Fabien


Le lun. 11 janv. 2021 =C3= =A0 16:27, Denis <denis.ietf@free.fr> a =C3=A9crit=C2=A0:

I have used the text of the wiki to respond.

Latest discussion update

Here we consolidate the latest proposal(s) from the group. We also include the discussion items (individual feedbacks).

=C2=A0

[Denis] I don't have the feeling that we are converging. There are duplications for some definitions that are spread over the document
instead of being grouped together. This does not help to converge.

=C2=A0

We need to clearly separate the role of the "end-user= " from the role of a RO. Attempting to collapse these two concepts under the term "user"
creates confusion. Attempting to use the term "subject" creates even more confusion.=


Trying to incorporate design choices inside the definition section is not appropriate, hence why I propose to remove several notes.

=C2=A0

In my proposals below, I have followed the ISO style for the definitions (a single sentence as short as possible).

=C2=A0

Authorization Server (AS)

server that grants delegated privileges to a particular instance of client software in the form of an access token and other information (such as subject information).

=C2=A0

[Denis]

Authorization Server (AS): server that grants access privileges to a particular instance of a client software in the form of an access token and provides information about the end user

Some explanations: In addition to the granting of access tokens, end-users may query the AS about the privileges they store about them.

We should identify in the main body of the document thse two distinct operations.


[FI] so far the type of additional information we would send is specified as subject information, hence its use in the definition.
[Denis] Since a subject is currently defined in the draft as "person, organization or device", I don't = believe that an AS "grants other other information
(such as subject information)" because it does not manage orga= nizations nor devices. In the context of an AS, the AS only manages end-user information
hence why it is unnecessary to introduce the term "subject"= .

= [FI] In most cases, it will be only about the end-user and its access token= . But regarding the use of subject and whether we could send other informat= ion such as subject information, this would be the case if we include clien= t posture (which is something planned).=C2=A0 =C2=A0

Client

application operated by an end-user that consumes resources from one or several RSs, possibly requiring access privileges from one or several ASs.

=C2=A0

Example: a client can be a mobile application, a web application, etc.

=C2=A0

Note: this specification differentiates between a specific instance (the client instance, identified by its unique key) and the software running the instance (the client software). For some kinds of client software, there could be many instances of that software, each instance with a different key.

=C2=A0

[Denis] Change in the Note:

(the client instance, identified by its unique key)=

into:

(the client instance, identified by a unique key)

Some explanations: The key is unique, but may change.=


[FI] not sure that your proposal changes much the meaning (at any point in time, its key is unique, and yes, it may be changed over time).
[Denis] It does change it. Since it seems you can live with that change, this is fine.

Resource Server (RS)

server that provides operations on protected resources, where operations require a valid access token issued by an AS.

=C2=A0

[Denis] Change into:=C2=A0

Resource Server (RS= ) : server that provides operations on resources, where operations on protected resources require
a valid access token issued by one or more ASs

=C2=A0Some explanations: a resource server may also support resources available to the public.

=C2=A0

[FI] yes, but we don't really care about publ= ic resources (there's no need for a protocol for that). As for "one or more ASs", this seems to embed a requirement (s= upport multiplicity).

[Denis] A RS may support both public and private resources. At the time an operation is performed by a client on a resource,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = it is unknown whether that operation is allowed for the public or not.=C2=A0

[FI] yes indeed the RS may support public or private resour= ces, but the RS definition still seems valid


Resource Owner (RO)

subject entity that may grant or deny operations on resources it has authority upon.

Note: the act of granting or denying an operation may be manual (i.e. through an interaction with a physical person) or automatic (i.e. through predefined organizational rules).

=C2=A0

[Denis] Change into:

Resource Owner (RO)= :=C2=A0 entity that may grant or deny operations on resources it has authority upon

=C2=A0Some explanations: the term "entity" (without the = word "subject") is being used which is a very gene= ral term: it may or may not be a human being.

=C2=A0

[FI] subject is defined as either human or not.

[Denis] No, a subject is currently defined in the draft as "person, organization or device". We don'= ;t need to use the term "subject".

=
[FI] sorry, I don't get your point. Entity= alone doesn't make me understand it can also be a human.
<= 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">

=C2=A0

End-user

natural person that operates the client instance.

=C2=A0

Note: that natural person may or may not be the same entity as the RO. When it is explicit that the end-user and the RO are the same entity, the generic term user may be used.

[Denis]=C2=A0=

Change into:

End-user: natural person th= at operates a client instance

Remove the Note which is confusing.


[FI] "a" might indeed be better.
[Denis] Thanks !
[FI] will update the PR=C2=A0


Regarding the note, it seems that you'd rathe= r not have "user" (and the rest is still useful I think).=
This is actually used in other parts of the spec (cf diagrams) to refer to either RO or end-user, undistinctively. What would you use otherwise?

[Denis] The Note should be removed because it leads to confusion. The Note considers only the case where the RO is a natural person, however a RO may also be a process.
The Note may be adequate when the RO is being defined. In such a case, I would propose:

Resource Owner (RO):=C2=A0 entity that may grant or deny operations on resources it has authority upon


Note 1: The act of granti= ng or denying an operation may be automatic (i.e. through predefined rules) or manual (i.e. throug= h an interaction with a physical person)..


Note 2: In the later case, the same physical person may support simultaneously the role of the RO and the role of the end-user.

Attribute

characteristics related to a subject.

=C2=A0

[Denis] Change into:

Attribute: characte= ristics related to an end-user

[FI] are we 100% sure we'll never send anythi= ng else?

[Denis] See the discussion above for the reason for not using the term "subject".

Access Token

a data artifact representing a set of rights and/or attributes.

=C2=A0

Note: an access token can be first issued to an client instance (requiring authorization by the RO) and subsequently rotated.

=C2=A0

[Denis] Remove the Note which has nothing to do in this section.


[FI] the note serves the purpose of explaining the lifecycle of an access token, which I believe is useful to the reader. Cf the large litt=C3=A9rature about access vs refresh in the oauth2 world.

[Denis] We are in the definition section. Explaining the lifecycle of an access token may indeed be very useful
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = but a dedicated section in the main body of the document would much better address this topic.

[FI] we could do that too. As any not= e, it's not critical anyway. It's here mostly for convenience, but = if we feel it's better in the main text, so be it.


Grant

(verb): to permit an instance of client software to exercise some set of delegated rights to access a protected resource and/or
to receive some attributes at a specific time and during a specific duration. (noun): the act of granting.

=C2=A0

[Denis] Change into:

Grant

=C2=A0

(verb): to receive some attributes from an AS at a specific time and valid for a specific duration and/or
to permit an instance of client software to exercise this attributes to perform an operation on a protected resource

=C2=A0

(noun): the act of granting

=C2=A0Some explanations: The current text identifies two cases. I have switched these two cases.


[FI] how is that better?

[Denis] Before being able to use an access token, it is necessary to get it. So the proposed definition follows a chronological order.

[FI] ok clearer now, thanks.

Privilege

right or attribute associated with a subject.

=C2=A0

[Denis]

Privilege: right or attribute associated with an end-user

=C2=A0Note: the RO defines and maintains the rights and attributes associated to the protected resource, and might temporarily delegate

some set of those privileges to an end-user. This process is refered to as privilege delegation.

=C2=A0

[Denis] Remove the Note which is unrelated to the definition.


[FI] this is useful to understand what we call "delegated privileges" in the AS definition.

[Denis] Reading the original proposed definition again, the Note considers the RO.

[FI] it's not easy to describe. It= considers the RO and its delegation.



I consider that a right is a capability to perform an operation on a protected resource. Such capabilities is given by a RO to an end-user.
I consider that an attribute is a characteristics related to an end-user (e.g. a name, a group membership)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Privilege =3D right or attribute associated with an end-user which allows to support respectively
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 either a capability scheme or an attributed-based access control (ABAC) using ACLs.

A RO maintains rights but it does not maintain attributes.

[FI] which is why subject is more general, and can accomodate both use c= ases. Anyway, the exact requirement should be left to the main text.=

It might be useful to define in addition:

control attributes: set of attributes associated to a protected resource used to control operations on that resource

Note: a RO defines and maintains the control attributes associated to a protected resource

[FI] we'll try to really limit new definitions to the ba= re minimum. So if we see that's useful, we'll include it. But so fa= r I don't think that adds much.=C2=A0

=C2=A0

=C2=A0Protected Resource

protected API (Application Programming Interface) served by a RS and that can be accessed by a client, if and only if a valid access token is provided.

=C2=A0

Note: to avoid complex sentences, the specification document may simply refer to resource instead of protected resource.

Right

ability given to a subject to perform a given operation on a resource under the control of a RS.

=C2=A0

[Denis] Change into:

Right: ability given to an end-user to perform a given operation on a resource under the control of a RS


[FI] it's not rights about the end-user per s= ay, it's rights delegated by the RO.
And so in this context, subject seems a better description and avoids the potential misunderstanding. And least that's the intent.

[Denis]=C2=A0 A right is not given to an organization or to a device, but only to an end-user.

[FI] not always. Could hav= e an automated policy, which assigns rights to user groups, which is an org= anizational construct. Device policies might matter too.
<= font color=3D"#ff0000">Of course at runtime, it ends up being consumed by a= n end-user.=C2=A0

Subject

person, organization or device.

=C2=A0

[Denis] Remove this definition since this terms is confusing and unnecessary.


[FI] I'm not sure what is confusing. This is useful at the bare minimum in context with the next definition.=C2=A0
I think it can be used as a basic definition for other terms, and that's what is proposed.

[Denis] See the arguments raised above.<= br>

Subject Information

statement asserted locally by an AS about a subject.

=C2=A0

[Denis] Remove this definition since this terms is confusing and unnecessary.


[FI] this is used in the main text, so needs to be defined (or removed from the main text, but that's a different debate).

[Denis] See the arguments raised above.<= /p>

Current spec

Here we find all the terms and definitions from the current version of the draft (01), as a reference.

Roles

Authorization Server (AS)

Manages the requested delegations for the RO. The AS issues tokens and directly delegated information to the RC.
The AS is defined by its grant endpoint, a single URL that accepts a POST request with a JSON payload.
The AS could also have other endpoints, including interaction endpoints and user code endpoints, and these are introduced
to the RC as needed during the delegation process.

=C2=A0

[Denis] Already discussed above (and far too long for a definition).

=C2=A0

Resource Client (RC, aka "client")

Requests tokens from the AS and uses tokens at the RS. An instance of the RC software is identified by its key, which can be known
to the AS prior to the first request. The AS determines which policies apply to a given RC, including what it can request and on whose behalf.

=C2=A0

[Denis] Already discusse= d above.

=C2=A0

Resource Server (RS, aka "API")

Accepts tokens from the RC issued by the AS and serves delegated resources on behalf of the RO.
There could be multiple RSs protected by the AS that the RC will call.

=C2=A0

[Denis] Already discusse= d above.

=C2=A0

Resource Owner (RO)

Authorizes the request from the RC to the RS, often interactively at the AS.

=C2=A0

[Denis] Already discussed above.

=C2=A0

Requesting Party (RQ, aka "user")

Operates and interacts with the RC.

=C2=A0

[Denis] Remove. Already discussed above under the term "end-user"=

Elements

Access Token

A credential representing a set of access rights delegated to the RC. The access token is created by the AS, consumed and verified by the RS,
and issued to and carried by the RC. The contents and format of the access token are opaque to the RC.

=C2=A0

[Denis] Already discussed above.

=C2=A0

Grant

The process by which the RC requests and is given delegated access to the RS by the AS through the authority of the RO.

=C2=A0

[Denis] Already discussed above.

=C2=A0

Cryptographic Key

A cryptographic element binding a request to a holder of the key. Access tokens and RC instances can be associated with specific keys.

=C2=A0

[Denis] Change into:

Binding key: a cryptographic key used by a client to bind an access token to a client instance

Some explanations: cryptographic key is a general term. In the context of GNAP we want that key to achieve a specific function:
to bind an access token to a client instance.

Resource

A protected API served by the RS and accessed by the RC. Access to this resource is delegated by the RO as part of the grant process.

=C2=A0

[Denis] We don't need this definition. Already discussed above under the wording" Protected Resource".=

=C2=A0

Subject Information

Information about the RO that is returned directly to the RC from the AS without the RC making a separate call to an RS.
Access to this information is delegated by the RO as part of the grant process.

[Denis] We don't need this definition.

Some explanations: an end-user may wish to know the attributes stored for him by the AS.
However, no information needs to be returned to a client about a RO.

Denis


Denis
Hi everyone,=C2=A0

I wish you all a happy new year.

I just created a PR (https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/155) that takes into account the various feedbacks. The automatic build process is not working, but you can see the diffs and build the html locally if you prefer. The definitions have also been updated on the wiki (htt= ps://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology) if you prefer to check there.=C2=A0

Feedbacks welcome before we move to pending merge later on.

Cheers
Fabien


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


--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000007ad7eb05b8ca8103-- From nobody Sun Jan 17 00:21: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 306C93A0C7D for ; Sun, 17 Jan 2021 00:21:04 -0800 (PST) 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_H3=-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=LfwEtpbm; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=q9IvSzvg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uo-duiNcCJri for ; Sun, 17 Jan 2021 00:21:02 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B73C3A0C7E for ; Sun, 17 Jan 2021 00:21:02 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B28615C00DE for ; Sun, 17 Jan 2021 03:13:22 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 17 Jan 2021 03:13:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=qEIPKkHyZaT9fLmzII1ueykZHnvFMM2pyCG5pfS7Ylo=; b=LfwEtpbm k7p+LNVwO4g326XPZFvwMUJXOpXrc1nt8Gn8FmwiRMU1xsqXhpEIRSk1GeKgq2rt dtVi/ahZv1Vkm7YfwGF7Nacu2QTI2hiHTcb48Jih6WtmW0E6DXwOqBda6VN7DlZn DpRL7GVYzYbY5KDINyech8We2Q58ZrZNSJ3kCEHmjmc0olEPxRFT6JBHYGvLkThA ARSdbV2Yp9M14kwBVQoH6gt0u32p3OrY8XG4imCnYodrYBJc/7HED06Ql1sDWnXY +vsIk1rN3qAKhWobxULdElzJMaqSpOYFkm9BP4ScbS62L1svLeFp7p3tPJdFcUb8 z2HSyxK3vg5V2g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=qEIPKkHyZaT9fLmzII1ueykZHnvFM M2pyCG5pfS7Ylo=; b=q9IvSzvgXv/SBrYMLy7s0XGbyXatGQPb4Sq1xZTF5HXC7 N52gSTCMTH8Yu/n87Xj1vAPq8S1plSh8+6q0Fbj60EKf6/kjjFmv6BVSaJTPojIA WZ725GQz7DmBWnc7bWVQwUl/KtrEmjGprqA4ZwaadVaQ8Gh5pHiDPZaC2JJHIN+f nRAX60iC5Ow6O8nwxgJLiinQDuzuTPj/358S5L+go2spE61EsQvfAJspebch6HmR FWYv3/LU2LFDJG6gBL0XOVgzbutjSFiV5pyDYsnT+sgG0yWAZFKDqFPO1FADZj5l WYwLho28iDfydbp5Iniv2+OKa7nYKSbEE+mgvjnOg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrtdehgdduudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphepuddtgedrvddtledrudekke drgedtnecuvehluhhsthgvrhfuihiivgepgeenucfrrghrrghmpehmrghilhhfrhhomhep ughopghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az59-669.internal.cloudapp.net (unknown [104.209.188.40]) by mail.messagingengine.com (Postfix) with ESMTPA id 8A52924005C for ; Sun, 17 Jan 2021 03:13:22 -0500 (EST) Content-Type: multipart/alternative; boundary="===============6461211107571961530==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20210117081322.8A52924005C@mailuser.nyi.internal> Date: Sun, 17 Jan 2021 03:13:22 -0500 (EST) Archived-At: Subject: [GNAP] Weekly github digest (GNAP Weekly GitHub Activity Summary) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2021 08:21:04 -0000 --===============6461211107571961530== 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/-2/=F0=9F=92=AC11) 1 issues created: - Definition for key proof (by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/159=20 3 issues received 11 new comments: - #159 Definition for key proof (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/159=20 - #145 Non opaque access token (9 by Denisthemalice, fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145=20 - #29 Terminology (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/29 [Design]=20 2 issues closed: - Refactor key presentation https://github.com/ietf-wg-gnap/gnap-core-pro= tocol/issues/130=20 - Terminology https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/2= 9 [Design]=20 Pull requests ------------- * ietf-wg-gnap/core-protocol (+2/-3/=F0=9F=92=AC1) 2 pull requests submitted: - Clean up changelog, add missing items (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/160 [Editorial]= =20 - Simplify rendered preview deployment process (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/158=20 1 pull requests received 1 new comments: - #160 Clean up changelog, add missing items (1 by netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/160 [Editorial]= =20 3 pull requests merged: - Refactor "key" section https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/152 [Pending Me= rge]=20 - update terminology https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/155 [Pending Me= rge]=20 - Simplify rendered preview deployment process https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/158 [Editorial]= =20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol --===============6461211107571961530== 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 January 17, 2021

Events without label "editorial"

Issues

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

1 issues created:

3 issues received 11 new comments:

2 issues closed:

Pull requests

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

2 pull requests submitted:

1 pull requests received 1 new comments:

3 pull requests merged:

Repositories tracked by this digest:

--===============6461211107571961530==-- From nobody Sun Jan 24 00:21:18 2021 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 641D73A10A9 for ; Sun, 24 Jan 2021 00:21:13 -0800 (PST) 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_H3=-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=LNude+Jq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ASNlH4ra Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLAB1ta7Pi57 for ; Sun, 24 Jan 2021 00:21:11 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0901B3A10AA for ; Sun, 24 Jan 2021 00:21:10 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 0E27C5C00F4 for ; Sun, 24 Jan 2021 03:14:22 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 24 Jan 2021 03:14:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=1Sbw20k/FXgqx7R02C7FwAnPS52xF23l1IiE7AosnX4=; b=LNude+Jq BeEEdWMCQS4gZ6DT3FE1RyCoaHYnZL8gfLncMS2nlajxmaWOsOTWUCx4X0uRQfWj +o2wl3JJ2ZXh6iAQH3agWBNmzDpBNJtC5UmR1NoZwG44WrdkEKJs8V9SYR4UGvQA iFZy/NOHspZnotTnCpvN5oZ2m86V8Fy5b3GfgFlrcUacY/i/K5qtLF7z9URco1u2 W1oTPtTzhGUe0x8dyTSVIpR5OIazH508FsCHeGOlvZZoLj1q/YDsRnWL9oW2+3+o ee8Nay4pMt/HQq+Gh6y0ZM6LagzQV41/9UAOZAXL1R399kjlxMM3KzarC1qhZ51Z pmTGDStuFFJ3TA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=1Sbw20k/FXgqx7R02C7FwAnPS52xF 23l1IiE7AosnX4=; b=ASNlH4raKl2tFv3bqhH3FGLfBZXwQl/bOpvrn4iMj1nJ/ kgDTf9orw5AdZ6jBqWyPI+m36zSFpZn18fHm3ejFrxXyN6sDLG/jfFBzgf5NFHX2 ydL0HvCYlK+kN5diIJrLFRAN3l3aEN7JODQHDUiukPWi36/lPNLMvNPjPptBwVZU XNgWiG+cmhn0bTyMhXFUMAuf2/radziCsi5f6cmW/kUCprYb9O/UIHiTvyaSZUd4 migmVFMIvBuNLAA6VRjCTWVzyODJbAz2RpsGMzWWwBT6aUNkdyn3nIx2W+gNTLi4 kli4g5+cchu6OKtTxoReYVYUCY0dU5eifnVW+WIjA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvddtgddukecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicuueho thcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtthgvrh hnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudeiteen ucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeehvddrvddvhedrvddvvddrge eknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepugho pghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az60-880.internal.cloudapp.net (unknown [52.225.222.48]) by mail.messagingengine.com (Postfix) with ESMTPA id D5BF524005A for ; Sun, 24 Jan 2021 03:14:21 -0500 (EST) Content-Type: multipart/alternative; boundary="===============4990155251718982278==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20210124081421.D5BF524005A@mailuser.nyi.internal> Date: Sun, 24 Jan 2021 03:14:21 -0500 (EST) Archived-At: Subject: [GNAP] Weekly github digest (GNAP Weekly GitHub Activity Summary) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2021 08:21:13 -0000 --===============4990155251718982278== 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=AC10) 1 issues created: - Terminology : revoke / rotate (by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/161=20 5 issues received 10 new comments: - #161 Terminology : revoke / rotate (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/161=20 - #159 Terminology: definition for "key proof" (1 by yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/159=20 - #154 Common means to dereference key references (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/154=20 - #149 Special label for access token used for continuation (3 by fimbaul= t, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/149=20 - #146 Persistent Grant Identifier (4 by fimbault, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/146=20 Pull requests ------------- * ietf-wg-gnap/core-protocol (+0/-1/=F0=9F=92=AC0) 1 pull requests merged: - Clean up changelog, add missing items https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/160 [Editorial]= =20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol --===============4990155251718982278== 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 January 24, 2021

Events without label "editorial"

Issues

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

1 issues created:

5 issues received 10 new comments:

Pull requests

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

1 pull requests merged:

Repositories tracked by this digest:

--===============4990155251718982278==-- From nobody Tue Jan 26 13:49:19 2021 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FA13A0FD8 for ; Tue, 26 Jan 2021 13:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.019 X-Spam-Level: X-Spam-Status: No, score=-0.019 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2V-Mnx8AFxrK for ; Tue, 26 Jan 2021 13:49:15 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 268E83A1101 for ; Tue, 26 Jan 2021 13:49:00 -0800 (PST) Received: from [192.168.1.22] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 10QLmx9N016256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 26 Jan 2021 16:48:59 -0500 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_0593F814-F2FB-473D-A3A1-F6A88FEB98F1" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: Date: Tue, 26 Jan 2021 16:48:58 -0500 To: txauth gnap X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [GNAP] Proposed Access Token Request/Response Syntax 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: Tue, 26 Jan 2021 21:49:18 -0000 --Apple-Mail=_0593F814-F2FB-473D-A3A1-F6A88FEB98F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As discussed on the last call, the editors have put together a proposed = syntax change for requesting and receiving access tokens, both single = and multiple. The proposed changes are found here: https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/162 = You can see both the diffs and the rendered preview there, as always. = There=E2=80=99s a lot going on in this one, but it=E2=80=99s all around = access tokens: - The old =E2=80=9Cresources=E2=80=9D array that signaled requesting an = access token, which used to exist at the top level of the request, has = now been moved into an =E2=80=9Caccess_token=E2=80=9D object within the = request and renamed =E2=80=9Caccess=E2=80=9D.=20 - This top level object now has additional fields including =E2=80=9Cflags= =E2=80=9D, to encompass the old =E2=80=9Ctoken flag=E2=80=9D = functionality that had been previously rolled into the =E2=80=9Cresources=E2= =80=9D array - The token request and response now have a =E2=80=9Clabel=E2=80=9D = field for directing the client instance on what to do with each token it = gets back (required in the multiple token state). - Bound tokens are now the default for the protocol. To request a bearer = token, you now have to include the flag =E2=80=9Cbearer=E2=80=9D = explicitly - The token response object now has both a =E2=80=9Cbound=E2=80=9D and = =E2=80=9Ckey=E2=80=9D field, to encompass functionality that was = previously in the =E2=80=9Ckey=E2=80=9D field alone. - The token response object now has a =E2=80=9Cdurable=E2=80=9D field = that allows the AS to signal token rotation behavior. The client no = longer has a means to request changes in this behavior (but a flag could = be defined if this signaling is desired).=20 - The old =E2=80=9Cmultiple_access_token=E2=80=9D response field is = replaced by the =E2=80=9Caccess_token=E2=80=9D field being able to = return an array with mandatory internal =E2=80=9Clabel=E2=80=9D fields = on each token object. Examples should all be updated.=20 The editors think this is moving in the right direction and there are = many advantages to this new approach: - Parallelism for single and multiple tokens - Parallelism for request and response - Clear place to put extensions (flags and new object members in request = and response) - Flexibility for directing the client instance where to use a token = (labels today, possibly other fields in the future) - Arguably clearer use of polymorphic structures, e.g. either a an = object or an array of those same objects Even so, there are a few of noted downsides to these changes that people = should be aware of: - The internal =E2=80=9Clabel=E2=80=99 field now needs to be checked for = both presence and uniqueness in the multiple access token case. = (Previously, this was enforced by syntax.) - The combination of =E2=80=9Cbound=E2=80=9D and =E2=80=9Ckey=E2=80=9D = now need to be checked, including an explicitly disallowed combination = of =E2=80=9Cbound: false=E2=80=9D with an explicit key. (Previously, = this was enforced by syntax.) - Flags now need to be parsed as strings instead of object member names.=20= - The syntax for requesting a single =E2=80=9Cscope=E2=80=9D equivalent = for a single access token is now much more complex.=20 For that last one, previously a request would look like this: { =E2=80=9Cresources": [ =E2=80=9Cscope=E2=80=9D ] } But now, it needs to look like this: { =E2=80=9Caccess_token=E2=80=9D: { =E2=80=9Caccess": [ =E2=80=9Cscope=E2=80=9D ] } } While more explicit and more flexible overall, you can see that it=E2=80=99= s also verbose for the simple use case that OAuth 2 systems will = particularly be bringing to the table. There are some things we can = probably optimize to make this simpler for this case, using polymorphism = in limited and unambiguous ways, but those all need to be explored in = more depth. As such, the editors recommend addressing any optimizations = of this verbosity problem after the base syntax can be agreed on. Thank you, =E2=80=94 Justin= --Apple-Mail=_0593F814-F2FB-473D-A3A1-F6A88FEB98F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 As = discussed on the last call, the editors have put together a proposed = syntax change for requesting and receiving access tokens, both single = and multiple. The proposed changes are found here:

https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/162=

You can = see both the diffs and the rendered preview there, as always. There=E2=80=99= s a lot going on in this one, but it=E2=80=99s all around access = tokens:

- The = old =E2=80=9Cresources=E2=80=9D array that signaled requesting an access = token, which used to exist at the top level of the request, has now been = moved into an =E2=80=9Caccess_token=E2=80=9D object within the request = and renamed =E2=80=9Caccess=E2=80=9D. 
- This = top level object now has additional fields including =E2=80=9Cflags=E2=80=9D= , to encompass the old =E2=80=9Ctoken flag=E2=80=9D functionality that = had been previously rolled into the =E2=80=9Cresources=E2=80=9D = array
- The token request and response now have a = =E2=80=9Clabel=E2=80=9D field for directing the client instance on what = to do with each token it gets back (required in the multiple token = state).
- Bound tokens are now the default for the = protocol. To request a bearer token, you now have to include the flag = =E2=80=9Cbearer=E2=80=9D explicitly
- The token = response object now has both a =E2=80=9Cbound=E2=80=9D and =E2=80=9Ckey=E2= =80=9D field, to encompass functionality that was previously in the = =E2=80=9Ckey=E2=80=9D field alone.
- The token = response object now has a =E2=80=9Cdurable=E2=80=9D field that allows = the AS to signal token rotation behavior. The client no longer has a = means to request changes in this behavior (but a flag could be defined = if this signaling is desired). 
- The old = =E2=80=9Cmultiple_access_token=E2=80=9D response field is replaced by = the =E2=80=9Caccess_token=E2=80=9D field being able to return an array = with mandatory internal =E2=80=9Clabel=E2=80=9D fields on each token = object.

Examples= should all be updated. 

The editors think this is moving in the = right direction and there are many advantages to this new = approach:

- = Parallelism for single and multiple tokens
- = Parallelism for request and response
- Clear place = to put extensions (flags and new object members in request and = response)
- Flexibility for directing the client = instance where to use a token (labels today, possibly other fields in = the future)
- Arguably clearer use of polymorphic = structures, e.g. either a an object or an array of those same = objects

Even = so, there are a few of noted downsides to these changes that people = should be aware of:

- The internal =E2=80=9Clabel=E2=80=99 field now needs to be = checked for both presence and uniqueness in the multiple access token = case. (Previously, this was enforced by syntax.)
- = The combination of =E2=80=9Cbound=E2=80=9D and =E2=80=9Ckey=E2=80=9D now = need to be checked, including an explicitly disallowed combination of = =E2=80=9Cbound: false=E2=80=9D with an explicit key. (Previously, this = was enforced by syntax.)
- Flags now need to be = parsed as strings instead of object member names. 
- The syntax for requesting a single =E2=80=9Cscope=E2=80=9D = equivalent for a single access token is now much more = complex. 

For that last one, previously a request would look like = this:

{
    =E2=80=9Cresources": [ = =E2=80=9Cscope=E2=80=9D ]
}

But now, it needs to = look like this:

{
    = =E2=80=9Caccess_token=E2=80=9D: {
    =     =E2=80=9Caccess": [ =E2=80=9Cscope=E2=80=9D ]
    }
}

While more explicit and = more flexible overall, you can see that it=E2=80=99s also verbose for = the simple use case that OAuth 2 systems will particularly be bringing = to the table. There are some things we can probably optimize to make = this simpler for this case, using polymorphism in limited and = unambiguous ways, but those all need to be explored in more depth. As = such, the editors recommend addressing any optimizations of this = verbosity problem after the base syntax can be agreed on.

Thank you,

 =E2=80=94 = Justin
= --Apple-Mail=_0593F814-F2FB-473D-A3A1-F6A88FEB98F1-- From nobody Wed Jan 27 03:39:29 2021 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35FFC3A0EA5 for ; Wed, 27 Jan 2021 03:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 7scv-_UIpTN0 for ; Wed, 27 Jan 2021 03:39:27 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 04E8B3A0EA1 for ; Wed, 27 Jan 2021 03:39:27 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id 16so1520356ioz.5 for ; Wed, 27 Jan 2021 03:39:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=lFuh8X+wbhwbggjZqLjq+kSl9h94Gqrk/BpO8mkZcMY=; b=JYv9WVSUJSuElxAnbE9fbBPcwHVqNkikOiK1AOMDrwV9JY+TMLvPdZdMEIEEvr3sBj d+fmYJ50Mr+6r4i+q3qpqS1trH+pjro467397CvEIMSvqkYMq29OXTIEwmPp+En9XT+i RtKCF1MNkoUVE/zkaP2MMmRFjLk65TxvVVbOd4BYKObNhaTzXLEbznSOyTCMI728idv7 gXDZ08WVS3xfq7QZp7JfNLCYc5b0iEgTYxVnQXOZLVZ1cZYyB5crAal0EKyXmz4p1/Fc 1X4aw9P1CgXJptlyW9NXHwP4VXWFAZ1Fpc50Plz/iigqbmb/NhrwljafTYzK6DwmF26Y /kRQ== 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=lFuh8X+wbhwbggjZqLjq+kSl9h94Gqrk/BpO8mkZcMY=; b=ZVN0uEYStvlcwck58/p+4yOSY0EK8+xfGZel8d1exX2jPakTakyuTriONcglFzJUm+ JaDkabCU8zr4mHnzBNq8SehusHWaSI5rxVc1hucRZnhk1TWxxTkMVaz3k6a/YirygPGk BXL5DM3zbyTYAmAPOwnJ5KfvkYOB2Z2ole99VXYC/3mipRsrYOyvOExT79ugoO3neHHY 5JLVt9j4ex1H/hCbpJswmFIL2gEK8wt0tdfPMfRLxBSoqsvp1uQWK4Pwi4F8sq8Bzrdo XFYqflkiKv2a/XQ200htNH5Jh5OnmmA/jv90KrgopjL1IkFa43o2+HGL5KG18vVDgzBx 6rgw== X-Gm-Message-State: AOAM5336azlacMZ+gmNAD4hewdksSANyV1aDCU+sD6tEAOVKwihJ5tL8 2RRNdVb5n9fm6aqDrKpTldWkkxOyL5TiAw47k3/jDTCdkFoNSw== X-Google-Smtp-Source: ABdhPJzWpoWnPWRjXI2Fdx0BhvX9gooYah2XnI/ii2oaPAj7WOs1yQ9uLBB0E+mPqzy5V1mPfbvy0vWkYstx/L21H+M= X-Received: by 2002:a02:5148:: with SMTP id s69mr8752874jaa.8.1611747566165; Wed, 27 Jan 2021 03:39:26 -0800 (PST) MIME-Version: 1.0 From: Fabien Imbault Date: Wed, 27 Jan 2021 12:39:14 +0100 Message-ID: To: GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000026214105b9e039d9" Archived-At: Subject: [GNAP] git/github tutorial for GNAP 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, 27 Jan 2021 11:39:28 -0000 --00000000000026214105b9e039d9 Content-Type: text/plain; charset="UTF-8" Hi everyone, The chairs and editors have communicated at various occasions on how/why we use github. Some of you asked for more information as to how to participate to issues, PR etc. So we'd propose a short training relative to git/github and its use for the GNAP working group. The date still needs to be defined but I can guess we could use a 30min window at the end of a scheduled meeting. The goal is to record it so that newcomers can refer if needed. Please let us know if there are specific questions that you'd like to be covered. Best Fabien --00000000000026214105b9e039d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

The chairs and editors= have communicated at various occasions on how/why we use github. Some of y= ou asked for more information as to how to participate to=C2=A0issues, PR e= tc. So we'd propose a short training relative=C2=A0to git/github and it= s use for the GNAP working group.
The date still needs to be defi= ned but I can guess we could use a 30min window at the end of a scheduled m= eeting. The goal is to record it so that newcomers can refer if needed.

Please let us know if there are specific questions th= at you'd like to be covered.

Best
Fa= bien


--00000000000026214105b9e039d9-- From nobody Thu Jan 28 06:13:33 2021 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451753A1187 for ; Thu, 28 Jan 2021 06:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 Ik5EE39sQIzV for ; Thu, 28 Jan 2021 06:13:30 -0800 (PST) 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 C382B3A1085 for ; Thu, 28 Jan 2021 06:13:30 -0800 (PST) Received: by mail-il1-x136.google.com with SMTP id l4so5312743ilo.11 for ; Thu, 28 Jan 2021 06:13:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=D1suZKCx9oOJpWR+hYXn5fnAXm9EqTsQl8DhHeT51s0=; b=aVkJYWGvAAW3IrLNkTMy2AyVBmMbV9lCCUI6dMgkYFAolaLlGQDD5G1M5Igj7jhqCD hAiqCGXYB9E0z+9jzpRrW1rumEkVUbqXtmwjMX/V2kcCuoqgB5BZEmse/op7mj0OJDu9 kmip5D8hakhm7dGn3YP6vZMQ/2oP9ncq7tcB/CD37noZfhFPfQOuC43SNOfwToKBjQ2a rSw4ljsMWtPYHnrs3LN6EJv3GagarsLWAd3WMnhPwsgWzKTw41aGTqXEDPo10/5evr3g 2NoRYd6KyEAtNfbnXYX5pWPbkQrfL4qkkL6YH8dDEi+vLZXuDA0ekwFmNfM9L+p3VUNr O8ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=D1suZKCx9oOJpWR+hYXn5fnAXm9EqTsQl8DhHeT51s0=; b=O+j151Z8JlkewK8LqTLvjlTxY0edKxky5r288RNvDFJ/zlInsRBwvMHrnnjIK0mhEZ VCwX9hAdLvSmqj1h449DrKbcfFnxsY+JrjG8byFhymfKsI4hXMforqzcQupVLPCvFLee DJ+sfj1Hbqd1yptHSFB2zHkQRjmBfOPYq6viOXXmssqYv3z1q9pfH0kzFp7jTj3FqfsE TzoK+P1FZJXVzODC1dswz9X5zKmTz1MQWGOb8iJ1a602o6eZJCBt4brIT4g70qt1SxXC xyxJupyD16NSFlolzteOogUYLVEyjCZTAV2yUirRJYdJ/rd6w5MPy5SeXhlHiPKavjOi NjPw== X-Gm-Message-State: AOAM530rzqwCv3A/05gieAiuxmfLT6iI8rW74kGsQDJHDdG0PYYIpTae QgXdHdUGkw9g0Oa6AxNa/V6Trc3E/zjHPGU1LzbRvjEcXYXzhPqK X-Google-Smtp-Source: ABdhPJwnOjw5P5vkJJd0rrjnC8Gg5yBuI4I8JhIE/LHJ95tbz/4sIHEhTZQuJ45wD0C3BRYzN5+FNlI5sCGgNdk00Fc= X-Received: by 2002:a92:b646:: with SMTP id s67mr13092575ili.178.1611843210005; Thu, 28 Jan 2021 06:13:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Thu, 28 Jan 2021 15:13:16 +0100 Message-ID: To: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000f7514305b9f67d17" Archived-At: Subject: Re: [GNAP] git/github tutorial for GNAP 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, 28 Jan 2021 14:13:32 -0000 --000000000000f7514305b9f67d17 Content-Type: text/plain; charset="UTF-8" Hi there, Based on feedback received, we'll start by a wiki to explain. The goal is to help everyone with issues, PRs etc. We'll only focus on what is important in the context of GNAP. Here's the link : https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Git-tutorial (of course it's just a starting point). Feel free to contribute and enrich the content. Cheers. Fabien On Wed, Jan 27, 2021 at 12:39 PM Fabien Imbault wrote: > Hi everyone, > > The chairs and editors have communicated at various occasions on how/why > we use github. Some of you asked for more information as to how to > participate to issues, PR etc. So we'd propose a short training relative to > git/github and its use for the GNAP working group. > The date still needs to be defined but I can guess we could use a 30min > window at the end of a scheduled meeting. The goal is to record it so that > newcomers can refer if needed. > > Please let us know if there are specific questions that you'd like to be > covered. > > Best > Fabien > > > --000000000000f7514305b9f67d17 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi there,=C2=A0

Based on feedback r= eceived, we'll start by a wiki to explain. The goal is to help everyone= with issues, PRs etc. We'll only focus on what is important in the con= text of GNAP.

Here's the link :=C2=A0h= ttps://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Git-tutorial
(of course it's just a starting point).

Feel free to contribute and enrich the content.=C2=A0
Cheers.

Fabien

On Wed, Jan 27, 2021 at 12:39 PM Fabien = Imbault <fabien.imbault@gmai= l.com> wrote:
Hi everyone,

The chairs and ed= itors have communicated at various occasions on how/why we use github. Some= of you asked for more information as to how to participate to=C2=A0issues,= PR etc. So we'd propose a short training relative=C2=A0to git/github a= nd its use for the GNAP working group.
The date still needs to be= defined but I can guess we could use a 30min window at the end of a schedu= led meeting. The goal is to record it so that newcomers can refer if needed= .

Please let us know if there are specific questio= ns that you'd like to be covered.

Best
Fabien


--000000000000f7514305b9f67d17-- From nobody Fri Jan 29 10:15:57 2021 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E743A11E8 for ; Fri, 29 Jan 2021 10:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqWyNEn-yANm for ; Fri, 29 Jan 2021 10:15:54 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFE743A11E6 for ; Fri, 29 Jan 2021 10:15:53 -0800 (PST) Received: from [192.168.1.22] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 10TIFosq007361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 29 Jan 2021 13:15:51 -0500 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_C3264081-DA17-48D2-9DA6-B54F2EE05DCD" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 29 Jan 2021 13:15:50 -0500 References: To: txauth gnap In-Reply-To: Message-Id: <970EDEB0-7285-4AC6-B1D8-6D431598788B@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Proposed Access Token Request/Response Syntax 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: Fri, 29 Jan 2021 18:15:56 -0000 --Apple-Mail=_C3264081-DA17-48D2-9DA6-B54F2EE05DCD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 To provide some =E2=80=9Crunning code=E2=80=9D to the proposal, I=E2=80=99= ve put together a preliminary set of changes that implement the new = Access Token syntax in the XYZ Java implementation. You can see the = draft set here: https://github.com/bspk/oauth.xyz-java/pull/11 = It works for a handful of basic tests, but I have some more cleanups and = a few more changes to do before it=E2=80=99s ready for merge there. = Still, it does run if you want to check it out yourself! Overall it seems to have made the whole JSON parsing simpler to manage = (though to be fair, I did also discover a somewhat hidden Jackson = feature this week that lets me hook into the parser at a different layer = than before and still get reliable behavior). This PR also makes the = change to the =E2=80=9Ckey=E2=80=9D field and incorporates checking for = the bearer flag on token generation, defaulting to bound tokens when the = flag isn=E2=80=99t present. In any event, you can try out the code on the branch if you want to see = what this looks like under an actual implementation on both client and = server side. The client code in particular prints the relevant HTTP = messages to the console. =E2=80=94 Justin > On Jan 26, 2021, at 4:48 PM, Justin Richer wrote: >=20 > As discussed on the last call, the editors have put together a = proposed syntax change for requesting and receiving access tokens, both = single and multiple. The proposed changes are found here: >=20 > https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/162 = >=20 > You can see both the diffs and the rendered preview there, as always. = There=E2=80=99s a lot going on in this one, but it=E2=80=99s all around = access tokens: >=20 > - The old =E2=80=9Cresources=E2=80=9D array that signaled requesting = an access token, which used to exist at the top level of the request, = has now been moved into an =E2=80=9Caccess_token=E2=80=9D object within = the request and renamed =E2=80=9Caccess=E2=80=9D.=20 > - This top level object now has additional fields including = =E2=80=9Cflags=E2=80=9D, to encompass the old =E2=80=9Ctoken flag=E2=80=9D= functionality that had been previously rolled into the =E2=80=9Cresources= =E2=80=9D array > - The token request and response now have a =E2=80=9Clabel=E2=80=9D = field for directing the client instance on what to do with each token it = gets back (required in the multiple token state). > - Bound tokens are now the default for the protocol. To request a = bearer token, you now have to include the flag =E2=80=9Cbearer=E2=80=9D = explicitly > - The token response object now has both a =E2=80=9Cbound=E2=80=9D and = =E2=80=9Ckey=E2=80=9D field, to encompass functionality that was = previously in the =E2=80=9Ckey=E2=80=9D field alone. > - The token response object now has a =E2=80=9Cdurable=E2=80=9D field = that allows the AS to signal token rotation behavior. The client no = longer has a means to request changes in this behavior (but a flag could = be defined if this signaling is desired).=20 > - The old =E2=80=9Cmultiple_access_token=E2=80=9D response field is = replaced by the =E2=80=9Caccess_token=E2=80=9D field being able to = return an array with mandatory internal =E2=80=9Clabel=E2=80=9D fields = on each token object. >=20 > Examples should all be updated.=20 >=20 > The editors think this is moving in the right direction and there are = many advantages to this new approach: >=20 > - Parallelism for single and multiple tokens > - Parallelism for request and response > - Clear place to put extensions (flags and new object members in = request and response) > - Flexibility for directing the client instance where to use a token = (labels today, possibly other fields in the future) > - Arguably clearer use of polymorphic structures, e.g. either a an = object or an array of those same objects >=20 > Even so, there are a few of noted downsides to these changes that = people should be aware of: >=20 > - The internal =E2=80=9Clabel=E2=80=99 field now needs to be checked = for both presence and uniqueness in the multiple access token case. = (Previously, this was enforced by syntax.) > - The combination of =E2=80=9Cbound=E2=80=9D and =E2=80=9Ckey=E2=80=9D = now need to be checked, including an explicitly disallowed combination = of =E2=80=9Cbound: false=E2=80=9D with an explicit key. (Previously, = this was enforced by syntax.) > - Flags now need to be parsed as strings instead of object member = names.=20 > - The syntax for requesting a single =E2=80=9Cscope=E2=80=9D = equivalent for a single access token is now much more complex.=20 >=20 > For that last one, previously a request would look like this: >=20 > { > =E2=80=9Cresources": [ =E2=80=9Cscope=E2=80=9D ] > } >=20 > But now, it needs to look like this: >=20 > { > =E2=80=9Caccess_token=E2=80=9D: { > =E2=80=9Caccess": [ =E2=80=9Cscope=E2=80=9D ] > } > } >=20 > While more explicit and more flexible overall, you can see that it=E2=80= =99s also verbose for the simple use case that OAuth 2 systems will = particularly be bringing to the table. There are some things we can = probably optimize to make this simpler for this case, using polymorphism = in limited and unambiguous ways, but those all need to be explored in = more depth. As such, the editors recommend addressing any optimizations = of this verbosity problem after the base syntax can be agreed on. >=20 > Thank you, >=20 > =E2=80=94 Justin > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_C3264081-DA17-48D2-9DA6-B54F2EE05DCD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 To = provide some =E2=80=9Crunning code=E2=80=9D to the proposal, I=E2=80=99ve = put together a preliminary set of changes that implement the new Access = Token syntax in the XYZ Java implementation. You can see the draft set = here:

https://github.com/bspk/oauth.xyz-java/pull/11

It works for a handful = of basic tests, but I have some more cleanups and a few more changes to = do before it=E2=80=99s ready for merge there. Still, it does run if you = want to check it out yourself!

Overall it seems to have made the whole = JSON parsing simpler to manage (though to be fair, I did also discover a = somewhat hidden Jackson feature this week that lets me hook into the = parser at a different layer than before and still get reliable = behavior). This PR also makes the change to the =E2=80=9Ckey=E2=80=9D = field and incorporates checking for the bearer flag on token generation, = defaulting to bound tokens when the flag isn=E2=80=99t = present.

In = any event, you can try out the code on the branch if you want to see = what this looks like under an actual implementation on both client and = server side. The client code in particular prints the relevant HTTP = messages to the console.

 =E2=80=94 Justin


On Jan 26, 2021, at 4:48 PM, = Justin Richer <jricher@mit.edu> wrote:

As discussed on the = last call, the editors have put together a proposed syntax change for = requesting and receiving access tokens, both single and multiple. The = proposed changes are found here:

https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/162=

You can = see both the diffs and the rendered preview there, as always. There=E2=80=99= s a lot going on in this one, but it=E2=80=99s all around access = tokens:

- The = old =E2=80=9Cresources=E2=80=9D array that signaled requesting an access = token, which used to exist at the top level of the request, has now been = moved into an =E2=80=9Caccess_token=E2=80=9D object within the request = and renamed =E2=80=9Caccess=E2=80=9D. 
- This = top level object now has additional fields including =E2=80=9Cflags=E2=80=9D= , to encompass the old =E2=80=9Ctoken flag=E2=80=9D functionality that = had been previously rolled into the =E2=80=9Cresources=E2=80=9D = array
- The token request and response now have a = =E2=80=9Clabel=E2=80=9D field for directing the client instance on what = to do with each token it gets back (required in the multiple token = state).
- Bound tokens are now the default for the = protocol. To request a bearer token, you now have to include the flag = =E2=80=9Cbearer=E2=80=9D explicitly
- The token = response object now has both a =E2=80=9Cbound=E2=80=9D and =E2=80=9Ckey=E2= =80=9D field, to encompass functionality that was previously in the = =E2=80=9Ckey=E2=80=9D field alone.
- The token = response object now has a =E2=80=9Cdurable=E2=80=9D field that allows = the AS to signal token rotation behavior. The client no longer has a = means to request changes in this behavior (but a flag could be defined = if this signaling is desired). 
- The old = =E2=80=9Cmultiple_access_token=E2=80=9D response field is replaced by = the =E2=80=9Caccess_token=E2=80=9D field being able to return an array = with mandatory internal =E2=80=9Clabel=E2=80=9D fields on each token = object.

Examples= should all be updated. 

The editors think this is moving in the = right direction and there are many advantages to this new = approach:

- = Parallelism for single and multiple tokens
- = Parallelism for request and response
- Clear place = to put extensions (flags and new object members in request and = response)
- Flexibility for directing the client = instance where to use a token (labels today, possibly other fields in = the future)
- Arguably clearer use of polymorphic = structures, e.g. either a an object or an array of those same = objects

Even = so, there are a few of noted downsides to these changes that people = should be aware of:

- The internal =E2=80=9Clabel=E2=80=99 field now needs to be = checked for both presence and uniqueness in the multiple access token = case. (Previously, this was enforced by syntax.)
- = The combination of =E2=80=9Cbound=E2=80=9D and =E2=80=9Ckey=E2=80=9D now = need to be checked, including an explicitly disallowed combination of = =E2=80=9Cbound: false=E2=80=9D with an explicit key. (Previously, this = was enforced by syntax.)
- Flags now need to be = parsed as strings instead of object member names. 
- The syntax for requesting a single =E2=80=9Cscope=E2=80=9D = equivalent for a single access token is now much more = complex. 

For that last one, previously a request would look like = this:

{
    =E2=80=9Cresources": [ = =E2=80=9Cscope=E2=80=9D ]
}

But now, it needs to = look like this:

{
    = =E2=80=9Caccess_token=E2=80=9D: {
    =     =E2=80=9Caccess": [ =E2=80=9Cscope=E2=80=9D ]
    }
}

While more explicit and = more flexible overall, you can see that it=E2=80=99s also verbose for = the simple use case that OAuth 2 systems will particularly be bringing = to the table. There are some things we can probably optimize to make = this simpler for this case, using polymorphism in limited and = unambiguous ways, but those all need to be explored in more depth. As = such, the editors recommend addressing any optimizations of this = verbosity problem after the base syntax can be agreed on.

Thank you,

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

= --Apple-Mail=_C3264081-DA17-48D2-9DA6-B54F2EE05DCD-- From nobody Fri Jan 29 10:20:09 2021 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1873A1225 for ; Fri, 29 Jan 2021 10:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEsM-68SdvMh for ; Fri, 29 Jan 2021 10:19:58 -0800 (PST) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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 A7E223A11F4 for ; Fri, 29 Jan 2021 10:19:57 -0800 (PST) Received: by mail-ej1-x630.google.com with SMTP id g3so14389242ejb.6 for ; Fri, 29 Jan 2021 10:19:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8LUobGTaZhXD4Nrc0fZPOPd9IT0c/+OOw+IlPufeHn8=; b=VKs5afAlm/headFhzIaZgDet8VrrenNo4Ffz4jxpp0/lyGaa55trTI6OmvjZsSs+fq igUyCGykcEA4CfV1SDHQi2iY8SchYY1ag+dqANiZqeIUV1SUhr5Xjle7ivSzNr6XW4sC B8aSox1V2fB6+nEmZ3MBtl/b8meFacMtlULiBBwbvnJxkOVAcKzk7Cg+YafkTsZKg8a1 LLpIKihsaLF79zHnpdUVhNYFV9NTSlagAowOgM3PDJCEUm4iXmXClBpBLNb9vXUXzCF6 Xq4B48Q/Aw1/MO3+aZ8EhqIdWRrXED1+JDqmGipwz+isRHbYvODCnXULGXaqIX7ZY4+t 2y8Q== 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=8LUobGTaZhXD4Nrc0fZPOPd9IT0c/+OOw+IlPufeHn8=; b=OUw1ctyqewbt0XlLRo/jaMdUPMSGzXcQ/OE+mgRL4ZrfLCW3Aj39dJnkrmgnlD4K8o Bf0SsdbmQGqWbXJ0WUOqTJK45It1C3P1AQ8wfY5dFA/HmXH4ws1NjkrXbFecD98SSy7d Tl2DGWLpt6HYdOwZlBW1lmjPssxjeQaMJ5INDYDRQdaIyEhYs5HDR7zoEjBLk3AcwX49 bt50kFLn8bKQziRBTIyZaiE7LD4fUwIEM8MsnobCoaNQ5k+7jlZYtBe8kHI2zPqNOsqE lySJ3MNRyVqlh1vM37yUyw7P01LeM+RBCj5g/egXwdFUWVfjYsol9nqUsPuDYlHQOAYh 0HhQ== X-Gm-Message-State: AOAM533CByt2NoarLFk1JflfHVbxZgy0aAp+ZbbF9LDQTDGD28VmFpFb kv8ocDspGhzROeTSIu0prHjfL+aTBMMHwgriOxs= X-Google-Smtp-Source: ABdhPJxjRUO1dlFzPz8I/Iy+UiaSWlrk8LVIcM3J3ygDmw54e8IT2JZx2Mb+JArltCyQMN37AwQJJ9iHyAEd5D2z664= X-Received: by 2002:a17:906:1c13:: with SMTP id k19mr6010302ejg.338.1611944396175; Fri, 29 Jan 2021 10:19:56 -0800 (PST) MIME-Version: 1.0 References: <970EDEB0-7285-4AC6-B1D8-6D431598788B@mit.edu> In-Reply-To: <970EDEB0-7285-4AC6-B1D8-6D431598788B@mit.edu> From: Fabien Imbault Date: Fri, 29 Jan 2021 19:19:43 +0100 Message-ID: To: Justin Richer Cc: txauth gnap Content-Type: multipart/alternative; boundary="00000000000021bd2b05ba0e0d3e" Archived-At: Subject: Re: [GNAP] Proposed Access Token Request/Response Syntax 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: Fri, 29 Jan 2021 18:20:06 -0000 --00000000000021bd2b05ba0e0d3e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Justin. Will try! Le ven. 29 janv. 2021 =C3=A0 19:16, Justin Richer a =C3= =A9crit : > To provide some =E2=80=9Crunning code=E2=80=9D to the proposal, I=E2=80= =99ve put together a > preliminary set of changes that implement the new Access Token syntax in > the XYZ Java implementation. You can see the draft set here: > > https://github.com/bspk/oauth.xyz-java/pull/11 > > It works for a handful of basic tests, but I have some more cleanups and = a > few more changes to do before it=E2=80=99s ready for merge there. Still, = it does > run if you want to check it out yourself! > > Overall it seems to have made the whole JSON parsing simpler to manage > (though to be fair, I did also discover a somewhat hidden Jackson feature > this week that lets me hook into the parser at a different layer than > before and still get reliable behavior). This PR also makes the change to > the =E2=80=9Ckey=E2=80=9D field and incorporates checking for the bearer = flag on token > generation, defaulting to bound tokens when the flag isn=E2=80=99t presen= t. > > In any event, you can try out the code on the branch if you want to see > what this looks like under an actual implementation on both client and > server side. The client code in particular prints the relevant HTTP > messages to the console. > > =E2=80=94 Justin > > > On Jan 26, 2021, at 4:48 PM, Justin Richer wrote: > > As discussed on the last call, the editors have put together a proposed > syntax change for requesting and receiving access tokens, both single and > multiple. The proposed changes are found here: > > https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/162 > > You can see both the diffs and the rendered preview there, as always. > There=E2=80=99s a lot going on in this one, but it=E2=80=99s all around a= ccess tokens: > > - The old =E2=80=9Cresources=E2=80=9D array that signaled requesting an a= ccess token, > which used to exist at the top level of the request, has now been moved > into an =E2=80=9Caccess_token=E2=80=9D object within the request and rena= med =E2=80=9Caccess=E2=80=9D. > - This top level object now has additional fields including =E2=80=9Cflag= s=E2=80=9D, to > encompass the old =E2=80=9Ctoken flag=E2=80=9D functionality that had bee= n previously > rolled into the =E2=80=9Cresources=E2=80=9D array > - The token request and response now have a =E2=80=9Clabel=E2=80=9D field= for directing > the client instance on what to do with each token it gets back (required = in > the multiple token state). > - Bound tokens are now the default for the protocol. To request a bearer > token, you now have to include the flag =E2=80=9Cbearer=E2=80=9D explicit= ly > - The token response object now has both a =E2=80=9Cbound=E2=80=9D and = =E2=80=9Ckey=E2=80=9D field, to > encompass functionality that was previously in the =E2=80=9Ckey=E2=80=9D = field alone. > - The token response object now has a =E2=80=9Cdurable=E2=80=9D field tha= t allows the AS > to signal token rotation behavior. The client no longer has a means to > request changes in this behavior (but a flag could be defined if this > signaling is desired). > - The old =E2=80=9Cmultiple_access_token=E2=80=9D response field is repla= ced by the > =E2=80=9Caccess_token=E2=80=9D field being able to return an array with m= andatory internal > =E2=80=9Clabel=E2=80=9D fields on each token object. > > Examples should all be updated. > > The editors think this is moving in the right direction and there are man= y > advantages to this new approach: > > - Parallelism for single and multiple tokens > - Parallelism for request and response > - Clear place to put extensions (flags and new object members in request > and response) > - Flexibility for directing the client instance where to use a token > (labels today, possibly other fields in the future) > - Arguably clearer use of polymorphic structures, e.g. either a an object > or an array of those same objects > > Even so, there are a few of noted downsides to these changes that people > should be aware of: > > - The internal =E2=80=9Clabel=E2=80=99 field now needs to be checked for = both presence and > uniqueness in the multiple access token case. (Previously, this was > enforced by syntax.) > - The combination of =E2=80=9Cbound=E2=80=9D and =E2=80=9Ckey=E2=80=9D no= w need to be checked, including > an explicitly disallowed combination of =E2=80=9Cbound: false=E2=80=9D wi= th an explicit > key. (Previously, this was enforced by syntax.) > - Flags now need to be parsed as strings instead of object member names. > - The syntax for requesting a single =E2=80=9Cscope=E2=80=9D equivalent f= or a single > access token is now much more complex. > > For that last one, previously a request would look like this: > > { > =E2=80=9Cresources": [ =E2=80=9Cscope=E2=80=9D ] > } > > > But now, it needs to look like this: > > { > =E2=80=9Caccess_token=E2=80=9D: { > =E2=80=9Caccess": [ =E2=80=9Cscope=E2=80=9D ] > } > } > > > While more explicit and more flexible overall, you can see that it=E2=80= =99s also > verbose for the simple use case that OAuth 2 systems will particularly be > bringing to the table. There are some things we can probably optimize to > make this simpler for this case, using polymorphism in limited and > unambiguous ways, but those all need to be explored in more depth. As suc= h, > the editors recommend addressing any optimizations of this verbosity > problem after the base syntax can be agreed on. > > Thank you, > > =E2=80=94 Justin > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000021bd2b05ba0e0d3e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Justin. Will try!=C2=A0

Le ven. 29 janv. 2021 =C3= =A0 19:16, Justin Richer <jricher@mit= .edu> a =C3=A9crit=C2=A0:
To provide s= ome =E2=80=9Crunning code=E2=80=9D to the proposal, I=E2=80=99ve put togeth= er a preliminary set of changes that implement the new Access Token syntax = in the XYZ Java implementation. You can see the draft set here:


It works for a handful of basic tests, but = I have some more cleanups and a few more changes to do before it=E2=80=99s = ready for merge there. Still, it does run if you want to check it out yours= elf!

Overall it seems to have made the whole JSON = parsing simpler to manage (though to be fair, I did also discover a somewha= t hidden Jackson feature this week that lets me hook into the parser at a d= ifferent layer than before and still get reliable behavior). This PR also m= akes the change to the =E2=80=9Ckey=E2=80=9D field and incorporates checkin= g for the bearer flag on token generation, defaulting to bound tokens when = the flag isn=E2=80=99t present.

In any event, you = can try out the code on the branch if you want to see what this looks like = under an actual implementation on both client and server side. The client c= ode in particular prints the relevant HTTP messages to the console.

=C2=A0=E2=80=94 Justin


On Jan 26, 2021, at 4:48 PM, Justin Richer <= ;jr= icher@mit.edu> wrote:

As discuss= ed on the last call, the editors have put together a proposed syntax change= for requesting and receiving access tokens, both single and multiple. The = proposed changes are found here:


You can see both the diffs and the rend= ered preview there, as always. There=E2=80=99s a lot going on in this one, = but it=E2=80=99s all around access tokens:

- The o= ld =E2=80=9Cresources=E2=80=9D array that signaled requesting an access tok= en, which used to exist at the top level of the request, has now been moved= into an =E2=80=9Caccess_token=E2=80=9D object within the request and renam= ed =E2=80=9Caccess=E2=80=9D.=C2=A0
- This top level object now ha= s additional fields including =E2=80=9Cflags=E2=80=9D, to encompass the old= =E2=80=9Ctoken flag=E2=80=9D functionality that had been previously rolled= into the =E2=80=9Cresources=E2=80=9D array
- The token request a= nd response now have a =E2=80=9Clabel=E2=80=9D field for directing the clie= nt instance on what to do with each token it gets back (required in the mul= tiple token state).
- Bound tokens are now the default for the pr= otocol. To request a bearer token, you now have to include the flag =E2=80= =9Cbearer=E2=80=9D explicitly
- The token response object now has= both a =E2=80=9Cbound=E2=80=9D and =E2=80=9Ckey=E2=80=9D field, to encompa= ss functionality that was previously in the =E2=80=9Ckey=E2=80=9D field alo= ne.
- The token response object now has a =E2=80=9Cdurable=E2=80= =9D field that allows the AS to signal token rotation behavior. The client = no longer has a means to request changes in this behavior (but a flag could= be defined if this signaling is desired).=C2=A0
- The old =E2=80= =9Cmultiple_access_token=E2=80=9D response field is replaced by the =E2=80= =9Caccess_token=E2=80=9D field being able to return an array with mandatory= internal =E2=80=9Clabel=E2=80=9D fields on each token object.
Examples should all be updated.=C2=A0

The editors think this is moving in the right direction and there are many= advantages to this new approach:

- Parallelism fo= r single and multiple tokens
- Parallelism for request and respon= se
- Clear place to put extensions (flags and new object members = in request and response)
- Flexibility for directing the client i= nstance where to use a token (labels today, possibly other fields in the fu= ture)
- Arguably clearer use of polymorphic structures, e.g. eith= er a an object or an array of those same objects

E= ven so, there are a few of noted downsides to these changes that people sho= uld be aware of:

- The internal =E2=80=9Clabel=E2= =80=99 field now needs to be checked for both presence and uniqueness in th= e multiple access token case. (Previously, this was enforced by syntax.)
- The combination of =E2=80=9Cbound=E2=80=9D and =E2=80=9Ckey=E2=80= =9D now need to be checked, including an explicitly disallowed combination = of =E2=80=9Cbound: false=E2=80=9D with an explicit key. (Previously, this w= as enforced by syntax.)
- Flags now need to be parsed as strings = instead of object member names.=C2=A0
- The syntax for requesting= a single =E2=80=9Cscope=E2=80=9D equivalent for a single access token is n= ow much more complex.=C2=A0

For that last one, pre= viously a request would look like this:

{
=C2= =A0 =C2=A0 =E2=80=9Cresources": [ =E2=80=9Cscope=E2=80=9D ]
= }

But now, it needs to look like this= :

{
=C2=A0 =C2=A0 =E2=80=9Caccess_token=E2=80= =9D: {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=9Caccess": [ =E2= =80=9Cscope=E2=80=9D ]
=C2=A0 =C2=A0 }
}

While more explicit and more flexible overall, you = can see that it=E2=80=99s also verbose for the simple use case that OAuth 2= systems will particularly be bringing to the table. There are some things = we can probably optimize to make this simpler for this case, using polymorp= hism in limited and unambiguous ways, but those all need to be explored in = more depth. As such, the editors recommend addressing any optimizations of = this verbosity problem after the base syntax can be agreed on.
Thank you,

=C2=A0=E2=80=94 Justin
-- =
TXAuth mailing list
TXAuth@ietf.org
https://w= ww.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--00000000000021bd2b05ba0e0d3e-- From nobody Sat Jan 30 23:51:17 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 CAFA23A0BDE for ; Sat, 30 Jan 2021 23:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_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=HCmvMxKZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cNlrSuQb Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Upbzv_KQkczQ for ; Sat, 30 Jan 2021 23:51:09 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1DFB3A0BDF for ; Sat, 30 Jan 2021 23:51:09 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id E5577B6B for ; Sun, 31 Jan 2021 02:44:18 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 31 Jan 2021 02:44:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=Z2ABKHl7V1IvBY0jpacFaVV+SZ+svbteJ/s9wDiyrRQ=; b=HCmvMxKZ nQ8beqIqMM89h4qrhYaLTWjomgDJ6293j8LKA0lmQeJLins6a6EkD8Ny/a9/oKse XxWiZkF8hNdUOqjh6KxOEs5U3qnTSYu0IKozRIlKKl2X/rndB8qsAyQylNW/AAg5 mbJ0LFK4+P5Cy+aCe2Z/9oVM4l6h+O9xfPorXAm/m5eFuEUTAGtyiEOZ2DNLkjAt /7KwiN8F8nEkVfWgApWqxoiczzPyylr39E4sVAPo2jozbCqqQsCGVXRjSiziiqez ENg4luL+Ul0HekRA0c79gBa3ri02PFbUo5n4VW/Fd0U/NtGhaLr1Qbj6k1iIwLw6 bYdmWg+Uw3TgjQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=Z2ABKHl7V1IvBY0jpacFaVV+SZ+sv bteJ/s9wDiyrRQ=; b=cNlrSuQb9Elnh9HTBJvnfq/S38zzwqCrM5IiwUX4dF3cG 9agrjHrAjC+r7yYMPC6w7crvu31/StjIfjApFof1QMegbrlgZFh9DBFovFNSqh66 zzdur1P3B9N/bKxlPEEWW3vu/J3mcCbmhuaD2120c0VEoNbxrr7Q2HEvRwKkq59X DgLah6pwtZ4/xwYVL2eR6PgU86n67LzUEi247G23d7U/Qdixv91DZUImulY0XZrC nZQHMuIpzVBqA1AeMpyznOV3YoG8+tB4q8mmB5Zh0iHZ4qPY35yH6BeuQRMyKgTm 3uKB6etVesgR15CKEQHTwZrZ+85OBjXrHxKVv1arA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeehgddutdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphephedvrdduieejrdduheeird dufeelnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep ughopghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az59-841.internal.cloudapp.net (unknown [52.167.156.139]) by mail.messagingengine.com (Postfix) with ESMTPA id 6672C24005A for ; Sun, 31 Jan 2021 02:44:18 -0500 (EST) Content-Type: multipart/alternative; boundary="===============4057915581628287438==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20210131074418.6672C24005A@mailuser.nyi.internal> Date: Sun, 31 Jan 2021 02:44:18 -0500 (EST) Archived-At: Subject: [GNAP] Weekly github digest (GNAP Weekly GitHub Activity Summary) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2021 07:51:13 -0000 --===============4057915581628287438== 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=AC25) 1 issues created: - Split redirect and post callback into separate modes (by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/163=20 2 issues received 25 new comments: - #122 Group interaction mode flags (24 by aaronpk, agropper, fimbault, j= richer) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/122=20 - #6 Polymorphism (1 by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/6=20 Pull requests ------------- * ietf-wg-gnap/core-protocol (+3/-1/=F0=9F=92=AC5) 3 pull requests submitted: - prevent PR label check from running on closed PRs (by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/165 [Editorial]= =20 - initial attempt at grouping interaction modes (by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/164=20 - Reformat access token request and response format. (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/162=20 3 pull requests received 5 new comments: - #165 prevent PR label check from running on closed PRs (3 by aaronpk, n= etlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/165 [Editorial]= =20 - #164 initial attempt at grouping interaction modes (1 by netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/164=20 - #162 Reformat access token request and response format. (1 by netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/162=20 1 pull requests merged: - prevent PR label check from running on closed PRs https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/165 [Editorial]= =20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol --===============4057915581628287438== 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 January 31, 2021

Events without label "editorial"

Issues

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

1 issues created:

2 issues received 25 new comments:

Pull requests

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

3 pull requests submitted:

3 pull requests received 5 new comments:

1 pull requests merged:

Repositories tracked by this digest:

--===============4057915581628287438==--